From nobody Sun Nov 1 23:54:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B7A3A044E for ; Sun, 1 Nov 2020 23:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackmanit.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEmcPp-0KEDV for ; Sun, 1 Nov 2020 23:54:21 -0800 (PST) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 9D4AE3A044A for ; Sun, 1 Nov 2020 23:54:21 -0800 (PST) Received: by mail-oo1-xc2b.google.com with SMTP id n16so3152192ooj.2 for ; Sun, 01 Nov 2020 23:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=references:to:from:cc:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ygzt3N1HqmUnKYBYK2ym+uvfUTb7le0wQieXQref9CM=; b=f5OfB/RWOpvdfnrN6wUJthnlKSifzpDTUrj+K6q+OFlcFPnhkdnxhKAMf8px7mJW/5 2LDKswtr/x5Uh+U6+hulO72WFEf35sXUw+7luqbfqkVxQHZd1PRTXKZtysSXwQ79EuFc uBhvHziX04NORnFnLRzsVG53mYz1r93kkrfOom8gjBkU8rB562wxw16TgP9lrmS9vMf/ tnwDHFSn2aic2ft/sw5KgvA5cLkt3VXgjB8pcUOZ9GNer5h44WT3Y82SyubhV/KP2ItM kOxxTBTteuR/wqmSlNVsckZmEVOcQ3dtWCmrbw3GTrWwmL6sMvMqRMxJa3b1uSv/ZK/A Pz0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:to:from:cc:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ygzt3N1HqmUnKYBYK2ym+uvfUTb7le0wQieXQref9CM=; b=TighUJvGieFTWPvbJbUqYtJo5Yo1hWGlIinwmYE9O2tlWKf90WmSyaen5IlzP/2As2 jvGCihtLiXLeCpa4vWe+lsFvtFo0bug7nujlTo84NI7+QTiIxUs5m749LIVojlVnrb44 tEZbMfXU1WWQH303V/mEi3uCbi4C5XUjEXCCVaf7/HRL9sz9TxgmCIXswZ9WuqgYxqdJ lGKNeoJ7+2+qx5ssx95zKegvMBmTS9O5kdHLddM0/EHfhWC0D0YpuZhU5JcxHxIYZ8b0 XTDni8wlyNytSAthcVrZFPDJ0PbHS49PcITC1CNhXcv9rSfJOAk47lIAnw3XXsqi9bUS rzYw== X-Gm-Message-State: AOAM5319alZGGWYG5PE4jO8xr6/7sA5rz25p8uA70iBKI+rQXIribT0O 03MWKDc7407p9KWOg+yy69Bd+A== X-Google-Smtp-Source: ABdhPJxcDdQPLioqmoT6IVENu/7IFtJ4TGuAbEvxC0PyjLyBAAWHlMXLAgzEsKdHgJUOqBa5J57vJg== X-Received: by 2002:a4a:b40a:: with SMTP id y10mr11025479oon.71.1604303660482; Sun, 01 Nov 2020 23:54:20 -0800 (PST) Received: from [192.168.178.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id q24sm674629otm.22.2020.11.01.23.54.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Nov 2020 23:54:19 -0800 (PST) References: <160430230298.9780.18195581822860811409@ietfa.amsl.com> To: oauth@ietf.org From: Karsten Meyer zu Selhausen X-Forwarded-Message-Id: <160430230298.9780.18195581822860811409@ietfa.amsl.com> Message-ID: Date: Mon, 2 Nov 2020 08:54:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <160430230298.9780.18195581822860811409@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------B768C6A5413BDE6AADCA153F" Content-Language: en-US Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 07:54:24 -0000 This is a multi-part message in MIME format. --------------B768C6A5413BDE6AADCA153F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, Daniel and I published a new version of the "iss" response parameter=20 draft to address the feedback from the WG. Changes in -01: * Incorporated first WG feedback * Clarifications for use with OIDC * Added note that clients supporting just one AS are not vulnerable * Renamed metadata parameter * Various editorial changes We would like to ask you for further feedback and comments on the new=20 draft version. Best regards, Karsten -------- Forwarded Message -------- Subject: New Version Notification for=20 draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt Date: Sun, 01 Nov 2020 23:31:42 -0800 From: internet-drafts@ietf.org To: Karsten Meyer zu Selhausen , = Karsten zu Selhausen , Daniel=20 Fett A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt has been successfully submitted by Karsten Meyer zu Selhausen and posted = to the IETF repository. Name: draft-meyerzuselhausen-oauth-iss-auth-resp Revision: 01 Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization = Response Document date: 2020-11-01 Group: Individual Submission Pages: 10 URL:=20 https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res= p-01.txt Status:=20 https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-re= sp/ Html:=20 https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res= p-01.html Htmlized:=20 https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01= Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth= -resp-01 Abstract: This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. If implemented correctly, the "iss" parameter serves as an effective countermeasure to "mix-up attacks". 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. The IETF Secretariat --=20 Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Does your OAuth or OpenID Connect implementation use PKCE to strengthen t= he security? Learn more about the procetion PKCE provides and its limitat= ions in our new blog post: https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-con= fidential-oauth-client Hackmanit GmbH Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz --------------B768C6A5413BDE6AADCA153F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

Daniel and I published a new version of the "iss" response parameter draft to address the feedback from the WG.

Changes in -01:

  • Incorporated first WG feedback
  • Clarifications for use with OIDC
  • Added note that clients supporting just one AS are not vulnerable
  • Renamed metadata parameter
  • Various editorial changes

We would like to ask you for further feedback and comments on the new draft version.

Best regards,
Karsten

-------- Forwarded Message --------
Subject: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
Date: Sun, 01 Nov 2020 23:31:42 -0800
From: internet-drafts@ietf.org
To: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>, Karsten zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>, Daniel Fett <mail@danielfett.de>



A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
has been successfully submitted by Karsten Meyer zu Selhausen and posted to the
IETF repository.

Name: draft-meyerzuselhausen-oauth-iss-auth-resp
Revision: 01
Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response
Document date: 2020-11-01
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
Status: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
Html: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
Htmlized: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01

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



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


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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
--------------B768C6A5413BDE6AADCA153F-- From nobody Mon Nov 2 10:13:16 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09653A0138 for ; Mon, 2 Nov 2020 10:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfFiUlzIc0ht for ; Mon, 2 Nov 2020 10:13:12 -0800 (PST) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 06C703A0128 for ; Mon, 2 Nov 2020 10:13:11 -0800 (PST) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id ZeKMkuiqipwZiZeKMkXiGa; Mon, 02 Nov 2020 11:13:11 -0700 X-CMAE-Analysis: v=2.4 cv=aop3tQVV c=1 sm=1 tr=0 ts=5fa04c37 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=9YbGl7VAAAAA:8 a=_AN3Pt4R-2FjQDy6KPIA:9 a=QEXdDO2ut3YA:10 a=idCLnkAckNQA:10 a=13CRv-QaNUMA:10 a=KREwD_BkcL0IhII0V08A:9 a=654eqtDvKENbJWor:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=AcK2Xwxry4XOpw9gWFIK:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: <160430230298.9780.18195581822860811409@ietfa.amsl.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com> Date: Mon, 2 Nov 2020 20:13:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010001050500050300090402" X-CMAE-Envelope: MS4xfDQ4nJn2kKswor5HVnQ/gLR5HcLu1gxNju4O3Vsdb4WrMxBTG7QRRPQIjFhRIKfxNJimZX4IQV+pIpIW5l1eXpal8zl9qReg4ZrE23STKmM7HRY3caEZ WzJpxNAwfKDOyROaWS10dxnrhsw/TMeelthaa0XaXn2ARUUeJ2jlek0uFvGcoxlXV3sb+Ijk6YxUag== Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:13:14 -0000 This is a cryptographically signed message in MIME format. --------------ms010001050500050300090402 Content-Type: multipart/alternative; boundary="------------C06AFB6A9163B045AFD7C621" Content-Language: en-US This is a multi-part message in MIME format. --------------C06AFB6A9163B045AFD7C621 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Karsten, looks good to me now, no further comments. Vladimir On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote: > > Hi all, > > Daniel and I published a new version of the "iss" response parameter > draft to address the feedback from the WG. > > Changes in -01: > > * Incorporated first WG feedback > * Clarifications for use with OIDC > * Added note that clients supporting just one AS are not vulnerable > * Renamed metadata parameter > * Various editorial changes > > > We would like to ask you for further feedback and comments on the new > draft version. > > Best regards, > Karsten > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt > Date: Sun, 01 Nov 2020 23:31:42 -0800 > From: internet-drafts@ietf.org > To: Karsten Meyer zu Selhausen > , Karsten zu Selhausen > , Daniel Fett > > > > > A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt= > has been successfully submitted by Karsten Meyer zu Selhausen and > posted to the > IETF repository. > > Name: draft-meyerzuselhausen-oauth-iss-auth-resp > Revision: 01 > Title: OAuth 2.0 Authorization Server Issuer Identifier in > Authorization Response > Document date: 2020-11-01 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-r= esp-01.txt > Status: > https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-= resp/ > Html: > https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-r= esp-01.html > Htmlized: > https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-= 01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-au= th-resp-01 > > Abstract: > This document specifies a new parameter "iss" that is used to > explicitly include the issuer identifier of the authorization server > in the authorization response of an OAuth authorization flow. If > implemented correctly, the "iss" parameter serves as an effective > countermeasure to "mix-up attacks". > > > > 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 > > > --=20 > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing= , Security Training > > Does your OAuth or OpenID Connect implementation use PKCE to strengthen= the security? Learn more about the procetion PKCE provides and its limit= ations in our new blog post: > https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-c= onfidential-oauth-client > > Hackmanit GmbH > Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) > 44789 Bochum > > Registergericht: Amtsgericht Bochum, HRB 14896 > Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj= Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------C06AFB6A9163B045AFD7C621 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks Karsten, looks good to me now, no further comments.

Vladimir

On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:

Hi all,

Daniel and I published a = new version of the "iss" response parameter draft to address the feedback from the WG.

Changes in -01:

  • Incorporated first WG feedback
  • Clarifications for use= with OIDC
  • Added note that client= s supporting just one AS are not vulnerable
  • Renamed metadata parameter
  • Various editorial chan= ges

We would like to ask you for further feedback and comments on the new draft version.

Best regards,
Karsten

-------- Forwarded Message --------
S= ubject: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
D= ate: Sun, 01 Nov 2020 23:31:42 -0800
F= rom: internet-drafts@ietf.org
T= o: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@h= ackmanit.de>, Karsten zu Selhausen <karsten.meyerzuselhausen@h= ackmanit.de>, Daniel Fett <mail@danielfett.de>=



A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
has been successfully submitted by Karsten Meyer zu Selhausen and posted to the
IETF repository.

Name: draft-meyerzuselhausen-oauth-iss-auth-resp
Revision: 01
Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response
Document date: 2020-11-01
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/archive/id/draft-= meyerzuselhausen-oauth-iss-auth-resp-01.txt
Status: https://datatracker.ietf.org/doc/draft= -meyerzuselhausen-oauth-iss-auth-resp/
Html: https://www.ietf.org/archive/id/draft-= meyerzuselhausen-oauth-iss-auth-resp-01.html
Htmlized: https://tools.ietf.org/html/draft-meye= rzuselhausen-oauth-iss-auth-resp-01
Diff: https://www.ietf.org/rfcdiff?url2=3Ddr= aft-meyerzuselhausen-oauth-iss-auth-resp-01

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



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


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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitat=
ions in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cann=
ot-protect-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

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


  


--------------C06AFB6A9163B045AFD7C621--

--------------ms010001050500050300090402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMDIxODEzMDlaMC8G
CSqGSIb3DQEJBDEiBCC8bcOrxGTVCRc6/hH5/UT4ELEIKW75R03ENBMCozXcBDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAChhiEk8dtZgO5L1BUUMR42eiuVC3edqV+N3+C35rs3mbr8q
lC6N6NgNK6X6sF6K6Dt0mpVMLXfV8d8gaGCH/32Ad6tqZYKyusSMdfvKhZBWibL5qfmkQml3
cO/HWBjxJ/IduHbKp+1htBGdWa6Q6dDC6kohRHdmVEKwZqWmq2WvEQZQyJIfkaa+ix65TGvl
NYlA22WIhVogXUIZAPOAJmWvj0HpgTVsFOKYcRMzGohbwC+W2uyZmHna98M4bYCfPROtRsAe
+TKEYUWii0KvMP7uSWfaOj7ITuUWnAWsRpekwMcp3qd+YO724qcAxmk1YDKgcrc1xF9iqhI6
ifUXHEIAAAAAAAA=
--------------ms010001050500050300090402--


From nobody Mon Nov  2 10:50:38 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4B33A08F6 for ; Mon,  2 Nov 2020 10:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2VuGOnXPkw3 for ; Mon,  2 Nov 2020 10:50:34 -0800 (PST)
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 D52B53A08C5 for ; Mon,  2 Nov 2020 10:50:33 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id 205so2750391wma.4 for ; Mon, 02 Nov 2020 10:50:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=yQypZvdGezdFPkYg0bdzL7T4RbcwvnK2iM7zNnHSWqM=; b=OO5FjyW/dMYpFqrqzjk83ZX8jo1z8ESkIz4wDbhgKINx5ljeE28dD7eHWwT+t8BsSs EHgMgml8N0ZfpHFqLKySxhe5l7l8TEeEYQ6AB80KyTuQ0HtmIvFIAm0Te2X11snDGmkc 0SDo9pe5Br+/cS9rsagMAeHNgGFsKdpCIJLWoQbI3UgByfILlSNIZbUOJuIEf4kKCo6W D7jegugaRRALj7j84HnRW2GNYWAX2n3wMIm6Uo873+gmOE7xnB8WnBOpfOZeRX3IGBnp MthgcdaTuYOXJHV+D6jndCzhPc9lmjXBmSKA42D1xxDjYZn6SJA9zYDBDGknkLQFNepO nxbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yQypZvdGezdFPkYg0bdzL7T4RbcwvnK2iM7zNnHSWqM=; b=bkyOC7B/opBBlB7Nmpqj0yw0foKxqKXXUYndWM500UeV0VJadQgpAJTR2na8lOb0pU WH2O8/9cjG/6ChrnVD30FV9SsOctwQTIt1QOeBtTcrIiNxC3JnyXClbn1kzmzfaZDUX+ eGjBtaC7Rqwx3so5lygfutEFZeHCfHDFARElXLSjz55U7upTFNFs/x9OBEJmvrJzIlZa P0CuOLQtT0zG3Piz4zNEIMz3gEOZlrQCAcnXZsFhQ8+pqopNfq/0XChO2re8GYZCkHN7 BptV5Rp6YwlKeMaG+gmmXkT5PTFl7sM2bnPafUG+ne48SAJoO392Te2a6I7EslxWwh6k qhqA==
X-Gm-Message-State: AOAM533PNBx1JPKcUrG5m/p9JOxpMqeyVjL/BenrLu5jvdnS7Gt5OWbP /iS6tdXibxnTWHDQRE5yipMFehf7cwRBGKd0XonDYXa6KGA=
X-Google-Smtp-Source: ABdhPJyUsmCNUEiI9/gUHjj16jsPOE1W+y/Ym2pKLURaALfed3roFZM6e/MD9Zno8W1gewhDrKqSIbXAiBKCOy7VVHQ=
X-Received: by 2002:a1c:b387:: with SMTP id c129mr7898385wmf.58.1604343032010;  Mon, 02 Nov 2020 10:50:32 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Mon, 2 Nov 2020 13:50:21 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000855c5905b324382a"
Archived-At: 
Subject: Re: [OAUTH-WG] Reminder - Interim Meeting to discuss IsLoggedIn/WebId
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, 02 Nov 2020 18:50:37 -0000

--000000000000855c5905b324382a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All,

You can find the meeting minutes and recording here:
https://www.ietf.org/proceedings/interim-2020-oauth-12/minutes/minutes-inte=
rim-2020-oauth-12-202011021200-00
https://codimd.ietf.org/s/notes-ietf-interim-2020-oauth-12-oauth#OAuth-WG-I=
nterim-Meeting---IsLoggedInWebID

Thanks to* Se=C3=A1n Kelleher* for taking the notes.

Regards,
 Rifaat



On Sat, Oct 31, 2020 at 6:39 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> You can find the slides for this meeting at the following link:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-12/session/oauth
>
> Regards,
>  Rifaat & Hannes
>
>
> On Fri, Oct 30, 2020 at 11:45 AM Rifaat Shekh-Yusef <
> rifaat.s.ietf@gmail.com> wrote:
>
>> All,
>>
>> This is a reminder that we have an Interim meeting this coming Monday,
>> Nov 2nd @ 12:00 Eastern Time, to discuss *IsLoggedIn* and *WebId*
>> initiatives.
>>
>> As mentioned before, the goal of the meeting is *not* to describe the
>> details of these initiatives, but rather provide a summary of these
>> initiatives and their impact on the identity use cases, and spend most o=
f
>> the time discussing ways that could help us address the issues cause by =
the
>> IsloggedIn/WebId proposed solutions.
>>
>> For this reason, we encourage you to watch the following presentations a=
s
>> they will provide you with the background needed to allow us to have a
>> productive discussion without spending too much time on this background
>> information.
>>
>> https://identiverse.gallery.video/detail/video/6184443037001/browser-fea=
tures-vs-identity-protocols
>>
>> https://www.niso.org/events/2020/05/browser-changes-and-identity-federat=
ion-impact-identity-flows
>>
>> Regards,
>>  Rifaat & Hannes
>>
>

--000000000000855c5905b324382a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks to Se=C3=A1n Kelleher for taking the notes.=


Regards,
=C2=A0Rifaat



On Sat, Oct 31, 2020 at 6:39 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wr=
ote:
All,

You can find the slides for this meeting at t=
he following link:
Regards,
=C2=A0Rifaat & Hannes


On Fri, Oct 30, 2020 at 11:45 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>=
; wrote:
All,

This is a reminder that we have an Interi=
m meeting this coming Monday, Nov 2nd @ 12:00 Eastern Time, to discuss I=
sLoggedIn and WebId initiatives.

As men=
tioned before, the=C2=A0goal of the=C2=A0meeting is not to describe =
the details of these initiatives, but rather provide a summary of these ini=
tiatives=C2=A0and their impact on the identity use cases, and spend most of=
 the time discussing ways that could help us address the issues cause by th=
e IsloggedIn/WebId proposed solutions.

For this re=
ason, we encourage you to watch the following=C2=A0presentations as they wi=
ll provide you with the background needed to allow us to have a productive=
=C2=A0discussion without spending too=C2=A0much time on this background inf=
ormation.
Regards,
=C2=A0Rifaat & Hannes






--000000000000855c5905b324382a--


From nobody Mon Nov  2 12:34:41 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148D03A11EA for ; Mon,  2 Nov 2020 12:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdz_SCYIGAXc for ; Mon,  2 Nov 2020 12:34:38 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B223A11E9 for ; Mon,  2 Nov 2020 12:34:37 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id x7so16141170wrl.3 for ; Mon, 02 Nov 2020 12:34:37 -0800 (PST)
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; bh=D5jojqimb0iuH4EEi4ITR/fRL7gj40b3GrgMSrsHHhY=; b=yItB5BavK7R1d95z8zBDide8+Vzne5JvKxQzElT1v746eznTDKTFrn3cX3GPSjZWnW RSrOXLqVKlGgpqsA2+VoElOlRHkv3oSfk+rmQ2EbV9mDdme3ef+jWg508ATqrFtOoEQV T17TOUcSCrwqw1vOWZKIfXKK7+KHFpuuWAYN/ZRtK6sPCoeEcyvJkmy311d+oa4HV5KW ve/HGO1NifpEOyk5AeO/x6fONqInaPwqoRDn6H5980ABmrgzdEf530McINPOpwuofAQa qEArWgDj9ylIIyVnvHQZbjPv0CvenPVnG7xc/ak47EdY96lO4HRgv0uJ0apJF362Mc67 f52A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D5jojqimb0iuH4EEi4ITR/fRL7gj40b3GrgMSrsHHhY=; b=MKS/NlLrmaamWYmhMD9zQSFCmCuuTigVDkPurK6dOFISaL0WWRJK7PS4YmRqB2NOYs LcSaoPl2k/yKJL/aKPJiT/HGKVXQmElus6bd58YCt0QKmsghkyPcrh4LhhV0coWkQoWo xWDHBOvza+P8cC605hKejk26Repftn4kjl+tmKS6GYFujIzy6JNB8jUHCzEIzAoK0N9e WrV/l5R56MK+qYR6GDGkRJJ7q9EoOp8GfthqvOAYOUWAM2+J/Qzt4IV98Lla90XfDJaO ojNQla2IL3WZpb1X0X5m6tZ1ihIvx4/0gkPFqFudFStnaUl7nPLH/8XAmGT7Z/z6NlMq clrA==
X-Gm-Message-State: AOAM5315V9Z5stxzu1oTc0g423w1DerkxVRpyjQSkOBQq8NTpNDx2t1V qWywfRZk0c1GNo2EWUBHNeDpy1k7AJu0HEHl84yTo7RDpfo=
X-Google-Smtp-Source: ABdhPJwbBIWCVee2FbWFXTs+e6DVoPlEL7LMt7A2EVESQqesSe1QB4LElBTqzy1YkbUtfTSnY/QFyYYEFoeKhr1Mu78=
X-Received: by 2002:adf:e384:: with SMTP id e4mr22327729wrm.227.1604349275596;  Mon, 02 Nov 2020 12:34:35 -0800 (PST)
MIME-Version: 1.0
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>
In-Reply-To: <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>
From: Takahiko Kawasaki 
Date: Tue, 3 Nov 2020 05:34:37 +0900
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000aafc3b05b325ac6b"
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 02 Nov 2020 20:34:40 -0000

--000000000000aafc3b05b325ac6b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Karsten,

The specification mentions JARM. Does this specification require the iss
response parameter even when JARM is used? That is, should an authorization
response look like below?

HTTP/1.1 302 Found
Location: https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUER}

Or, can the iss response parameter be omitted when JARM is used?

A small feedback for the 3rd paragraph in Section 4: s/identifes/identifies=
/

Best Regards,
Taka


On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov 
wrote:

> Thanks Karsten, looks good to me now, no further comments.
>
> Vladimir
> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>
> Hi all,
>
> Daniel and I published a new version of the "iss" response parameter draf=
t
> to address the feedback from the WG.
>
> Changes in -01:
>
>    - Incorporated first WG feedback
>    - Clarifications for use with OIDC
>    - Added note that clients supporting just one AS are not vulnerable
>    - Renamed metadata parameter
>    - Various editorial changes
>
>
> We would like to ask you for further feedback and comments on the new
> draft version.
>
> Best regards,
> Karsten
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
> Date: Sun, 01 Nov 2020 23:31:42 -0800
> From: internet-drafts@ietf.org
> To: Karsten Meyer zu Selhausen 
> , Karsten zu Selhausen
> 
> , Daniel Fett 
> 
>
>
> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
> has been successfully submitted by Karsten Meyer zu Selhausen and posted
> to the
> IETF repository.
>
> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
> Revision: 01
> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization
> Response
> Document date: 2020-11-01
> Group: Individual Submission
> Pages: 10
> URL:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-re=
sp/
> Html:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-01.html
> Htmlized:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth=
-resp-01
>
> Abstract:
> This document specifies a new parameter "iss" that is used to
> explicitly include the issuer identifier of the authorization server
> in the authorization response of an OAuth authorization flow. If
> implemented correctly, the "iss" parameter serves as an effective
> countermeasure to "mix-up attacks".
>
>
>
> 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
>
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:	+49 (0)234 / 54456499
> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, =
Security Training
>
> Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitatio=
ns in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce-c=
annot-protect-your-confidential-oauth-client
>
> Hackmanit GmbH
> Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000aafc3b05b325ac6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Karsten,

The specification mentions =
JARM. Does this specification require the iss response parameter even when =
JARM is used? That is, should an authorization response look like below?

HTTP/1.1 302 Found

<=
/div>
Or, can the iss response parameter be omitted when JARM is used?<=
/div>

A small feedback for the 3rd paragraph in Section =
4: s/identifes/identifies/

Best Regards,
Taka
=C2=A0

On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuv=
inov <vladimir@connect2id.com=
> wrote:

 =20
   =20
 =20
  

    
Thanks Karsten, looks good to me now, no further comments.

    

    
Vladimir

    

    
On 02/11/2020 09:54, Karsten Meyer zu
      Selhausen wrote:

    

    

     =20
      
Hi all,

      
Daniel and I published a ne=
w
          version of the "iss" response parameter draft to addres=
s the
          feedback from the WG.

      
Changes in -01:

      
    
        
  • Incorporated first WG
            feedback
    • 
        
  • Clarifications for use
            with OIDC
    • 
        
  • Added note that clients
            supporting just one AS are not vulnerable
    • 
        
  • Renamed metadata
            parameter
    • 
        
  • Various editorial change=
s
    
          
    • 
      

      


        We would like to ask you for further
              feedback and comments on the new draft version.

            

      


        

      
Best regards,

      
Karsten

      


      

      
-------- Forwarded Message
        --------
        

          
            

              Subject:
              
              New Version Notification for
                draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
            

            

              Date:
              
              Sun, 01 Nov 2020 23:31:42 -0800
            

            

              From:
              
              internet-drafts@ietf.org
            

            

              To: 
              Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@h=
ackmanit.de>,
                Karsten zu Selhausen <karsten.meyerzuselhausen@hackmanit=
.de>,
                Daniel Fett <mail@danielfett.de>
            

          
        

        

        

        

        A new version of I-D,
        draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

        has been successfully submitted by Karsten Meyer zu Selhausen
        and posted to the

        IETF repository.

        

        Name: draft-meyerzuselhausen-oauth-iss-auth-resp

        Revision: 01

        Title: OAuth 2.0 Authorization Server Issuer Identifier in
        Authorization Response

        Document date: 2020-11-01

        Group: Individual Submission

        Pages: 10

        URL:
        https://www.ietf.org/archive/i=
d/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

        Status:
        https://datatracker.ietf.org/doc/dr=
aft-meyerzuselhausen-oauth-iss-auth-resp/

        Html:
        https://www.ietf.org/archive/=
id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html

        Htmlized:
        https://tools.ietf.org/html/draft-meye=
rzuselhausen-oauth-iss-auth-resp-01

        Diff:
        https://www.ietf.org/rfcdiff?u=
rl2=3Ddraft-meyerzuselhausen-oauth-iss-auth-resp-01

        

        Abstract:

        This document specifies a new parameter "iss" that is use=
d to

        explicitly include the issuer identifier of the authorization
        server

        in the authorization response of an OAuth authorization flow. If
        implemented correctly, the "iss" parameter serves as an
        effective

        countermeasure to "mix-up attacks".

        

        

        

        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<=
/a>.

        

        The IETF Secretariat

        

        

      

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the=
 security? Learn more about the procetion PKCE provides and its limitations=
 in our new blog post:
https://www.hackmanit.de=
/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

      

      

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


    

    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000aafc3b05b325ac6b--


From nobody Mon Nov  2 23:01:41 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A813A1500 for ; Mon,  2 Nov 2020 23:01:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level: 
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksHA6CtnnZMH for ; Mon,  2 Nov 2020 23:01:37 -0800 (PST)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 6DA473A14FD for ; Mon,  2 Nov 2020 23:01:37 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id ZqJzkwytrpwZiZqK0kY9lR; Tue, 03 Nov 2020 00:01:36 -0700
X-CMAE-Analysis: v=2.4 cv=aop3tQVV c=1 sm=1 tr=0 ts=5fa10050 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=A1X0JdhQAAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=9YbGl7VAAAAA:8 a=KREwD_BkcL0IhII0V08A:9 a=QEXdDO2ut3YA:10 a=idCLnkAckNQA:10 a=13CRv-QaNUMA:10 a=pGLkceISAAAA:8 a=Ut8TGLPefVTxC3LAW0AA:9 a=de76rt2Y0RwqnPhm:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=Df3jFdWbhGDLdZNm0fyq:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22 a=AcK2Xwxry4XOpw9gWFIK:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com> 
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: 
Date: Tue, 3 Nov 2020 09:01:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020400010707020803010600"
X-CMAE-Envelope: MS4xfPUye1TNbgR/jeUx/ROBnu8Ey5M15XrKyNN8X29jrsp2Mc+mVlrq6PwsemPAsgWftzJ+7JMBTP3ZlLTMwDPIHH0op+bkveIxTD78j/Gfh8A9UAiMBUJL zE17hfY3LLp91HYr1ZH3P8bUdGlLEJmTB942dwWFFr2D5AnRqzCgWM04A4wfdLcH1uHE3P/G/cLwwQ==
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Nov 2020 07:01:40 -0000

This is a cryptographically signed message in MIME format.

--------------ms020400010707020803010600
Content-Type: multipart/alternative;
 boundary="------------4F24FA0EF4E424EBD1071847"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------4F24FA0EF4E424EBD1071847
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

This can potentially occur. If JARM is used "iss" becomes redundant. To
me JARM is an "enhanced" iss.

If both are included a sensible client should make sure the iss and the
JARM iss match.

My suggestion is to not require iss when a JARM is present, but in case
both do occur to have the client check both.

Vladimir

On 02/11/2020 22:34, Takahiko Kawasaki wrote:
> Hi Karsten,
>
> The specification mentions JARM. Does this specification require the
> iss response parameter even when JARM is used? That is, should an
> authorization response look like below?
>
> HTTP/1.1 302 Found
> Location: https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUER}=

>
> Or, can the iss response parameter be omitted when JARM is used?
>
> A small feedback for the 3rd paragraph in Section 4:
> s/identifes/identifies/
>
> Best Regards,
> Taka
> =C2=A0
>
> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov
> > wrote:
>
>     Thanks Karsten, looks good to me now, no further comments.
>
>     Vladimir
>
>     On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>
>>     Hi all,
>>
>>     Daniel and I published a new version of the "iss" response
>>     parameter draft to address the feedback from the WG.
>>
>>     Changes in -01:
>>
>>       * Incorporated first WG feedback
>>       * Clarifications for use with OIDC
>>       * Added note that clients supporting just one AS are not vulnera=
ble
>>       * Renamed metadata parameter
>>       * Various editorial changes
>>
>>
>>     We would like to ask you for further feedback and comments on the
>>     new draft version.
>>
>>     Best regards,
>>     Karsten
>>
>>     -------- Forwarded Message --------
>>     Subject: 	New Version Notification for
>>     draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>     Date: 	Sun, 01 Nov 2020 23:31:42 -0800
>>     From: 	internet-drafts@ietf.org 
>>     To: 	Karsten Meyer zu Selhausen
>>     
>>     , Karsten zu
>>     Selhausen 
>>     , Daniel Fett
>>      
>>
>>
>>
>>
>>     A new version of I-D,
>>     draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>     has been successfully submitted by Karsten Meyer zu Selhausen and
>>     posted to the
>>     IETF repository.
>>
>>     Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>     Revision: 01
>>     Title: OAuth 2.0 Authorization Server Issuer Identifier in
>>     Authorization Response
>>     Document date: 2020-11-01
>>     Group: Individual Submission
>>     Pages: 10
>>     URL:
>>     https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-a=
uth-resp-01.txt
>>     Status:
>>     https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-=
auth-resp/
>>     Html:
>>     https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-a=
uth-resp-01.html
>>     Htmlized:
>>     https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-=
resp-01
>>     Diff:
>>     https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-i=
ss-auth-resp-01
>>
>>     Abstract:
>>     This document specifies a new parameter "iss" that is used to
>>     explicitly include the issuer identifier of the authorization serv=
er
>>     in the authorization response of an OAuth authorization flow. If
>>     implemented correctly, the "iss" parameter serves as an effective
>>     countermeasure to "mix-up attacks".
>>
>>
>>
>>     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
>>
>>
>>     --=20
>>     Karsten Meyer zu Selhausen
>>     IT Security Consultant
>>     Phone:	+49 (0)234 / 54456499
>>     Web:	https://hackmanit.de | IT Security Consulting, Penetration Te=
sting, Security Training
>>
>>     Does your OAuth or OpenID Connect implementation use PKCE to stren=
gthen the security? Learn more about the procetion PKCE provides and its =
limitations in our new blog post:
>>     https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-y=
our-confidential-oauth-client
>>
>>     Hackmanit GmbH
>>     Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
>>     44789 Bochum
>>
>>     Registergericht: Amtsgericht Bochum, HRB 14896
>>     Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. =
Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>
>>     _______________________________________________
>>     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
>


--------------4F24FA0EF4E424EBD1071847
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
This can potentially occur. If JARM is used "iss" becomes
      redundant. To me JARM is an "enhanced" iss.

    
If both are included a sensible client should make sure the iss
      and the JARM iss match.

    
My suggestion is to not require iss when a JARM is present, but
      in case both do occur to have the client check both.

    

    
Vladimir

    

    
On 02/11/2020 22:34, Takahiko Kawasaki=

      wrote:

    

    

      
      
Hi Karsten,
        


        

        
The specification mentions JARM. Does this specification
          require the iss response parameter even when JARM is used?
          That is, should an authorization response look like below?
        


        

        
HTTP/1.1 302 Found

        
        


        

        
Or, can the iss response parameter be omitted when JARM is
          used?

        


        

        
A small feedback for the 3rd paragraph in Section 4:
          s/identifes/identifies/

        


        

        
Best Regards,

        
Taka

        
=C2=A0

      

      

      

        
On Tue, Nov 3, 2020 at 3:13=
 AM
          Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        
=

          

            
Thanks Karsten, looks good to me now, no further
              comments.

            

            
Vladimir

            

            
On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
            

            

              
Hi all,
              
Daniel and I
                  published a new version of the "iss" response
                  parameter draft to address the feedback from the WG.

              
Changes in -01:

              
    
                
  • Incorporated
                    first WG feedback
    • 
                
  • Clarifications=

                    for use with OIDC
    • 
                
  • Added note tha=
t
                    clients supporting just one AS are not vulnerable
    • 
                
  • Renamed metada=
ta
                    parameter
    • 
                
  • Various editor=
ial
                    changes
    
                  
    • 
              

              


                =
We would like to ask you for
                      further feedback and comments on the new draft
                      version.

                    

              


                

              
Best regards,

              
Karsten<=
/div>
              


              

              
-------- Forwarded Message --------
                

                  
                    

                      Subject: 
                      New Version Notification for
                        draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt=

                    

                    

                      Date: 
                      Sun, 01 Nov 2020 23:31:42 -0800
                    

                    

                      From: 
                      inte=
rnet-drafts@ietf.org
                    

                    

                      To: 
                      Karsten Meyer zu Selhausen <=
karsten.meyerzuselhausen@hackmanit.de>,
                        Karsten zu Selhausen <=
karsten.meyerzuselhausen@hackmanit.de>,
                        Daniel Fett <=
mail@danielfett.de>
                    

                  
                

                

                

                

                A new version of I-D,
                draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                has been successfully submitted by Karsten Meyer zu
                Selhausen and posted to the

                IETF repository.

                

                Name: draft-meyerzuselhausen-oauth-iss-auth-resp

                Revision: 01

                Title: OAuth 2.0 Authorization Server Issuer Identifier
                in Authorization Response

                Document date: 2020-11-01

                Group: Individual Submission

                Pages: 10

                URL: https://www.=
ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt=


                Status: https://data=
tracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

                Html: https://www.=
ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html

                Htmlized: https://tool=
s.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01

                Diff: https://www.=
ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth-resp-01=


                

                Abstract:

                This document specifies a new parameter "iss" that is
                used to

                explicitly include the issuer identifier of the
                authorization server

                in the authorization response of an OAuth authorization
                flow. If

                implemented correctly, the "iss" parameter serves as an
                effective

                countermeasure to "mix-up attacks".

                

                

                

                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

                

                

              

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitat=
ions in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-you=
r-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

              

              

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



            

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mailman/listinfo/oauth

        

      

    

    

  


--------------4F24FA0EF4E424EBD1071847--

--------------ms020400010707020803010600
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMDMwNzAxMzVaMC8G
CSqGSIb3DQEJBDEiBCANswYrjX3d1o3Nwrxn/4JdOQ5FsO1+cyWOz2Z7anLJcjBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBALo3AQnar00yf5LZrLk7XQ12ezoB8PGhfeictjq/T9xpEdnV
6KFOuVLkl/W06+MiLi9HH1bTf0w1HDbO/VqoNYDuZXN/vecX0434FQrnfzgi2AvKVLI0nX0F
B9AqBC2Uq+HBD87z9/Mz1LS15fc5hzwCmbAuN7VS+ixBoZGMzSdKsf5VFJGw2n2VWTsqQY/a
3nJtpZWL2iX2kCbkmNfx25YeKQ1KpLDFLyL4ZqeN+KJugpT1R06TkfANGuoJeeUXjUNZhRqC
K/7DAL1X5APUSkF7keWmv8tlqs7CFVjFflHG6jHz4f9KsNGH7BXzbzYjHYXfjZSRN+CrVqVE
QYH+U+wAAAAAAAA=
--------------ms020400010707020803010600--


From nobody Tue Nov  3 05:46:50 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA013A0AA1 for ; Tue,  3 Nov 2020 05:46:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVXcrHCgSBKl for ; Tue,  3 Nov 2020 05:46:46 -0800 (PST)
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 EA8E53A0A9C for ; Tue,  3 Nov 2020 05:46:45 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id v5so12807577wmh.1 for ; Tue, 03 Nov 2020 05:46:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=hw16jBlCJ0UxSZgjIGj8UWyAOBQ0qOC4UdLDxd6JDZ8=; b=kc2ggRb7LzkDtLahSnIWOksLgFSFBILounhh5PJgUHJ/1lonru9RLqLSSfsZKW+h2Q O0ABLyDwFUoqtJaCQFTOG0qF5tdKUNvl0KNFHmxe3DEftrrue0o1L+R6f8Ec7pmD4+QZ mY3BBGxudkeIz4raH5oSNk4HlhO8rOtOJEjc1/Q/LTmGp7TASEUQCSUMNg4s/z5EBGtI 292xBPypMKnGU8FJJvgvSi+JMhZsvBVenZ6SpC/hK2nfAe+hzPZTFfQPsiEZr3Zpoh1G jmKgxBGFzZeYN3qXelm41UKG5+5T+8zLIBpOrMZs9TYufVoQxmPh7IAIRG/ltWMIavPp FRkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=hw16jBlCJ0UxSZgjIGj8UWyAOBQ0qOC4UdLDxd6JDZ8=; b=KCh4eIjOtnKqp2sFUse0MVA+5bWTyKa0/CW+F8ICN7IvVeMvXI1PwzRdgFfqtUe7II FcpAhv8T+RWtXpNoVeYLBKlHrP8/wFcz+xylRKpqK8BDW7IeIzwihVrTRrF4gXJpMYYg bhC8zjyBU+XXAM349VVddCKSyBaZM8DannZJm4IrX8TPo1Au06yF1JpyB9ZraXKQlDLA lGriEroJMObAS8jEQ+idmIadW1c4pU1oD4AB9XvHVoCLSbChEXmCTWCPK/boj0lbmC9q Jsoc4sieJQpn9vCBMc7Ps+hlWqWA1yXRMkRJwHDFI+VAdensyqo1YPdfUGfzunXyAUPz xl4A==
X-Gm-Message-State: AOAM530kOl0LIxxJOdV0k4Z8GCWgPE3TsnItBZ7uHyxB+fk2T5zoQd8j VQRjTkLpBEtxzLBOiGopMtjq5bx1GI0QloeQ
X-Google-Smtp-Source: ABdhPJzG404lWqjDybrj6g7eJdUS1d5s7RogXgg0XhHD86gqZByrfbcgo8OGn3QWX35LjouEU6AgFw==
X-Received: by 2002:a1c:f214:: with SMTP id s20mr3667437wmc.71.1604411203769;  Tue, 03 Nov 2020 05:46:43 -0800 (PST)
Received: from dhcp121.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id v6sm2945271wmj.6.2020.11.03.05.46.42 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 05:46:42 -0800 (PST)
From: Joseph Heenan 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C632B5E8-753D-4798-9732-2B00F319404E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 3 Nov 2020 13:46:41 +0000
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>  
To: oauth 
In-Reply-To: 
Message-Id: <69B0850B-D863-4792-905E-54EE20823323@authlete.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Nov 2020 13:46:48 -0000

--Apple-Mail=_C632B5E8-753D-4798-9732-2B00F319404E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree, it is in redundant in the JARM case.

I find the text in =
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp=
-01.html#name-security-considerations (the 4th paragraph where JARM & =
JWTs) are mentioned a bit confusing - I think it would be good to say =
something along the lines of:

Although integrity protection is not necessary to prevent mixup, any =
authorization response method that includes a JWT with an =E2=80=98iss' =
(for example, JARM or OIDC hybrid flow) will prevent the attack =
(assuming the client is validating the iss).


I=E2=80=99m not entirely sure I understand what "MUST NOT allow multiple =
authorization servers to return the same issuer identifier during =
registration=E2=80=9D means as I don=E2=80=99t think =
https://tools.ietf.org/html/rfc7591 returns the issuer?

It might be clearer to say something like =E2=80=9CWhen =
https://tools.ietf.org/html/rfc8414 is used the client MUST implement =
the validation described in =
https://tools.ietf.org/html/rfc8414#section-3.3. When authorization =
server details can be manually configured in the client, the client must =
verify that all issuer values are unique.=E2=80=9D (Or at least =
something along those lines, I=E2=80=99m sure my wording can be =
improved. But if the client is correctly implementing rfc8414 or OIDC =
discovery [and does not have any manually configured authorization =
servers] then there=E2=80=99s no requirement for any further checks that =
the issuer is unique.)

Joseph


> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov  =
wrote:
>=20
> This can potentially occur. If JARM is used "iss" becomes redundant. =
To me JARM is an "enhanced" iss.
>=20
> If both are included a sensible client should make sure the iss and =
the JARM iss match.
>=20
> My suggestion is to not require iss when a JARM is present, but in =
case both do occur to have the client check both.
>=20
> Vladimir
>=20
> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>> Hi Karsten,
>>=20
>> The specification mentions JARM. Does this specification require the =
iss response parameter even when JARM is used? That is, should an =
authorization response look like below?
>>=20
>> HTTP/1.1 302 Found
>> Location: https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUER}=
 
>>=20
>> Or, can the iss response parameter be omitted when JARM is used?
>>=20
>> A small feedback for the 3rd paragraph in Section 4: =
s/identifes/identifies/
>>=20
>> Best Regards,
>> Taka
>> =20
>>=20
>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov =
> wrote:
>> Thanks Karsten, looks good to me now, no further comments.
>>=20
>> Vladimir
>>=20
>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>> Hi all,
>>>=20
>>> Daniel and I published a new version of the "iss" response parameter =
draft to address the feedback from the WG.
>>>=20
>>> Changes in -01:
>>>=20
>>> Incorporated first WG feedback
>>> Clarifications for use with OIDC
>>> Added note that clients supporting just one AS are not vulnerable
>>> Renamed metadata parameter
>>> Various editorial changes
>>>=20
>>> We would like to ask you for further feedback and comments on the =
new draft version.
>>>=20
>>> Best regards,
>>> Karsten
>>>=20
>>> -------- Forwarded Message --------
>>> Subject:	New Version Notification for =
draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> Date:	Sun, 01 Nov 2020 23:31:42 -0800
>>> From:	internet-drafts@ietf.org =

>>> To:	Karsten Meyer zu Selhausen =
 =
, Karsten zu Selhausen =
 =
, Daniel Fett =
 
>>>=20
>>>=20
>>> A new version of I-D, =
draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> has been successfully submitted by Karsten Meyer zu Selhausen and =
posted to the
>>> IETF repository.
>>>=20
>>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>> Revision: 01
>>> Title: OAuth 2.0 Authorization Server Issuer Identifier in =
Authorization Response
>>> Document date: 2020-11-01
>>> Group: Individual Submission
>>> Pages: 10
>>> URL: =
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp=
-01.txt =

>>> Status: =
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-res=
p/ =

>>> Html: =
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp=
-01.html =

>>> Htmlized: =
https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01 =

>>> Diff: =
https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth-=
resp-01 =

>>>=20
>>> Abstract:
>>> This document specifies a new parameter "iss" that is used to
>>> explicitly include the issuer identifier of the authorization server
>>> in the authorization response of an OAuth authorization flow. If
>>> implemented correctly, the "iss" parameter serves as an effective
>>> countermeasure to "mix-up attacks".
>>>=20
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of =
submission
>>> until the htmlized version and diff are available at tools.ietf.org =
.
>>>=20
>>> The IETF Secretariat
>>>=20
>>>=20
>>> --=20
>>> Karsten Meyer zu Selhausen
>>> IT Security Consultant
>>> Phone:	+49 (0)234 / 54456499
>>> Web:	https://hackmanit.de  | IT =
Security Consulting, Penetration Testing, Security Training
>>>=20
>>> Does your OAuth or OpenID Connect implementation use PKCE to =
strengthen the security? Learn more about the procetion PKCE provides =
and its limitations in our new blog post:
>>> =
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-conf=
idential-oauth-client =

>>>=20
>>> Hackmanit GmbH
>>> Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
>>> 44789 Bochum
>>>=20
>>> Registergericht: Amtsgericht Bochum, HRB 14896
>>> Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. =
Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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


--Apple-Mail=_C632B5E8-753D-4798-9732-2B00F319404E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
agree, it is in redundant in the JARM case.

I find the text in https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-is=
s-auth-resp-01.html#name-security-considerations (the 4th paragraph =
where JARM & JWTs) are mentioned a bit confusing - I think it would =
be good to say something along the lines of:

Although integrity protection is not =
necessary to prevent mixup, any authorization response method that =
includes a JWT with an =E2=80=98iss' (for example, JARM or OIDC hybrid =
flow) will prevent the attack (assuming the client is validating the =
iss).


I=E2=80=99m not entirely sure I =
understand what "MUST NOT allow multiple authorization servers to return =
the same issuer identifier during registration=E2=80=9D means as I =
don=E2=80=99t think https://tools.ietf.org/html/rfc7591 returns the =
issuer?

It =
might be clearer to say something like =E2=80=9CWhen https://tools.ietf.org/html/rfc8414 is used the client =
MUST implement the validation described in https://tools.ietf.org/html/rfc8414#section-3.3. When =
authorization server details can be manually configured in the client, =
the client must verify that all issuer values are unique.=E2=80=9D (Or =
at least something along those lines, I=E2=80=99m sure my wording can be =
improved. But if the client is correctly implementing rfc8414 or OIDC =
discovery [and does not have any manually configured authorization =
servers] then there=E2=80=99s no requirement for any further checks that =
the issuer is unique.)

Joseph


On 3 Nov =
2020, at 07:01, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  
This can potentially occur. If JARM is =
used "iss" becomes
      redundant. To me JARM is an "enhanced" iss.
If =
both are included a sensible client should make sure the iss
      and the JARM iss match.
My suggestion is to not =
require iss when a JARM is present, but
      in case both do occur to have the client check both.

    
Vladimir

    

    
On 02/11/2020 22:34, Takahiko =
Kawasaki
      wrote:

    

    

      
      
Hi Karsten,
        


        

        
The specification mentions JARM. Does this =
specification
          require the iss response parameter even when JARM is used?
          That is, should an authorization response look like =
below?

        


        

        
HTTP/1.1 302 Found

        
Location: https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUE=
R}

        


        

        
Or, can the iss response parameter be omitted =
when JARM is
          used?

        


        

        
A small feedback for the 3rd paragraph in =
Section 4:
          s/identifes/identifies/

        


        

        
Best Regards,

        
Taka

        
 

      

      

      

        
On Tue, Nov 3, 2020 at =
3:13 AM
          Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        

          
Thanks Karsten, looks good to me =
now, no further
              comments.

            
Vladimir

            

            
On 02/11/2020 09:54, Karsten Meyer zu =
Selhausen wrote:

            

            
Hi all,
Daniel and =
I
                  published a new version of the "iss" response
                  parameter draft to address the feedback from the =
WG.
Changes in -01:

              
    
                
  • Incorporated
                    first WG feedback
    • 
                
  • Clarifications
                    for use with OIDC
    • 
                
  • Added note that
                    clients supporting just one AS are not =
vulnerable
    • 
                
  • Renamed metadata
                    parameter
    • 
                
  • Various editorial
                    changes
    
                  
    • 
              

              


                We would =
like to ask you for
                      further feedback and comments on the new draft
                      version.

                    

              


                

              
Best regards,

              
Karsten

              


              

              
-------- Forwarded Message --------
                

                  
                    

                      Subject: 
                      New Version Notification for
                        =
draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
                    

                    

                      Date: 
                      Sun, 01 Nov 2020 23:31:42 =
-0800
                    

                    

                      From: 
                      internet-drafts@ietf.org
                    

                    

                      To: 
                      Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>,
                        Karsten zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>,
                        Daniel Fett <mail@danielfett.de>
                    

                  
                

                

                

                

                A new version of I-D,
                draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                has been successfully submitted by Karsten Meyer zu
                Selhausen and posted to the

                IETF repository.

                

                Name: draft-meyerzuselhausen-oauth-iss-auth-resp

                Revision: 01

                Title: OAuth 2.0 Authorization Server Issuer Identifier
                in Authorization Response

                Document date: 2020-11-01

                Group: Individual Submission

                Pages: 10

                URL: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-is=
s-auth-resp-01.txt

                Status: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-i=
ss-auth-resp/

                Html: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-is=
s-auth-resp-01.html

                Htmlized: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-au=
th-resp-01

                Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oaut=
h-iss-auth-resp-01

                

                Abstract:

                This document specifies a new parameter "iss" that is
                used to

                explicitly include the issuer identifier of the
                authorization server

                in the authorization response of an OAuth authorization
                flow. If

                implemented correctly, the "iss" parameter serves as an
                effective

                countermeasure to "mix-up attacks".

                

                

                

                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

                

                

              

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen =
the security? Learn more about the procetion PKCE provides and its =
limitations in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protec=
t-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj =
Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

              

              

              
_______________________________________________
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

=

--Apple-Mail=_C632B5E8-753D-4798-9732-2B00F319404E--


From nobody Tue Nov  3 11:09:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DB93A0100 for ; Tue,  3 Nov 2020 11:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE5WzGnF6Swv for ; Tue,  3 Nov 2020 11:09:21 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 CEB4D3A0D3A for ; Tue,  3 Nov 2020 11:09:08 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id d142so356910wmd.4 for ; Tue, 03 Nov 2020 11:09:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y6IjfSSCGbTA+euPQFy/p5TCIU1Fb8btHrHfN3mhuLk=; b=0zG/m9vvbAGKnWwS8aUOcbbaYcUjUAgQO52uCXu3bJpOPVsnhto5TQgkg+KAZ92lFq cNusqg7uPIh6A4l11CqcKPda2Y+A7Ty2fD0lK9VmBXtRaq8zimhmzowpW8FTn8qi3qhN md6pFFXkNXNwGq3hyhYzsGMzWmDS3+CpwQ3ylFzFBU6NBM2mAlf8aNH2LIGwuVOPmYLd 0JcvwZdElFbZ7O1nIi9MlOt1ShyrYLxkjMAjYQYGil2nc94OgagFFI+7BEdjjY2B6cyk dvyOpzroife0w1iUxdh0HZwZ3B5114wbZBVJS4OPgTbzwzp9RLFgphLfN933mZcbHOXD jklg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Y6IjfSSCGbTA+euPQFy/p5TCIU1Fb8btHrHfN3mhuLk=; b=ncXPuIn+MPRxG90iIW9IDbk2HbcvFW1t2Ac6patFzTzPBwL//I/F2vPXR/FtujHywp enAcVopERe6TGrwE/9I23SsyR9GZgbvg+ZXz3CpCuti5Hhtp3VSus/1yGBGRKOP4b1Nv Wrl+sEkPd39m+FceO5BS43aeCdJPJwP9ngFFozCwhdlU0tsB9KkpKP6lfxS5q4JRybrg nIer2Duu6a8XpOcXtQ3+VLFCXLnjCaXz/1liHaPaFTxnf+5J/7xKzzRitzsGe7b6UtRM +R7SR6sHoYHXGvxZPCXqFCN5KKiHAHOoqtaMvNj7fG3JWsEuPemRgh3an8A5oGI60S0j 1wKQ==
X-Gm-Message-State: AOAM533nfFvY014GR+K3lYnRpdGc/qCKy/e5AU0icgfQsoWfruESBHX3 2ghnCWZ0WsD344odD1iGwuQRmg==
X-Google-Smtp-Source: ABdhPJzYBgckhefTGYqV+N0DBroN8ZxeQoSBMKvx7URb8FgR0snqqjnTpGn9LD3AhYVuJaCRdNAhmQ==
X-Received: by 2002:a1c:9d94:: with SMTP id g142mr694974wme.66.1604430546050;  Tue, 03 Nov 2020 11:09:06 -0800 (PST)
Received: from dhcp121.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id z5sm27310274wrw.87.2020.11.03.11.09.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 11:09:05 -0800 (PST)
From: Joseph Heenan 
Message-Id: <65B3EF09-25F4-4F3E-96DD-05FA60F044D0@authlete.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2366112A-8B23-42F3-B891-2A22A73F908C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 3 Nov 2020 19:09:04 +0000
In-Reply-To: 
Cc: oauth 
To: Dick Hardt 
References: 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
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, 03 Nov 2020 19:09:23 -0000

--Apple-Mail=_2366112A-8B23-42F3-B891-2A22A73F908C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Dick

I didn=E2=80=99t attend the call so don=E2=80=99t know the background of =
this and the exact situation, but the general problem is mostly where =
the Authorization Server=E2=80=99s app is *not* installed. In that case =
Android falls back to much weaker mechanisms that allow other apps to =
get a look in. App links also aren=E2=80=99t consistently supported =
across all commonly used android browsers which causes further problems.

In general to do app2app oauth redirections securely on Android it=E2=80=99=
s necessary for both apps to fetch the /.well-known/assetlinks.json for =
the url they want to redirect to, and verify that the intent the app =
intends to launch to handle the url is signed using the expected =
certificate. Web2app flows are trickier, on both iOS and on Android. =
There were lengthy discussions on at least the Android case at OAuth =
Security Workshop this year (recordings available).

Joseph


> On 20 Oct 2020, at 00:09, Dick Hardt  wrote:
>=20
> Hey Vittorio
>=20
> (cc'ing OAuth list as this was brought up in the office hours today)
>=20
> https://developer.android.com/training/app-links =

>=20
> An app is the default handler and the developer has verified ownership =
of the HTTPS URL. While a user can override the app being the default =
handler in the system settings -- I don't see how a malicious app can be =
the default setting.
>=20
> What am I missing?
>=20
> /Dick
> =E1=90=A7
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_2366112A-8B23-42F3-B891-2A22A73F908C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Dick

I didn=E2=80=99t =
attend the call so don=E2=80=99t know the background of this and the =
exact situation, but the general problem is mostly where the =
Authorization Server=E2=80=99s app is *not* installed. In that case =
Android falls back to much weaker mechanisms that allow other apps to =
get a look in. App links also aren=E2=80=99t consistently supported =
across all commonly used android browsers which causes further =
problems.

In =
general to do app2app oauth redirections securely on Android it=E2=80=99s =
necessary for both apps to fetch the /.well-known/assetlinks.json for =
the url they want to redirect to, and verify that the intent the app =
intends to launch to handle the url is signed using the expected =
certificate. Web2app flows are trickier, on both iOS and on Android. =
There were lengthy discussions on at least the Android case at OAuth =
Security Workshop this year (recordings available).

Joseph


On 20 Oct 2020, at 00:09, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours =
today)

https://developer.android.com/training/app-links

An =
app is the default handler and the developer has verified ownership of =
the HTTPS URL. While a user can override the app being the default =
handler in the system settings -- I don't see how a malicious app can be =
the default setting.

What am I missing?

/Dick
3D""=E1=90=A7

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

=

--Apple-Mail=_2366112A-8B23-42F3-B891-2A22A73F908C--


From nobody Tue Nov  3 11:14:08 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEC93A010A for ; Tue,  3 Nov 2020 11:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vv5-mzIFtzM for ; Tue,  3 Nov 2020 11:14:04 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F983A0100 for ; Tue,  3 Nov 2020 11:14:04 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id h6so23727343lfj.3 for ; Tue, 03 Nov 2020 11:14:03 -0800 (PST)
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=3kZTwNbqU2LsGNzRSy3umbglKHE95RxrL3Q+baSOGwk=; b=eiWYuZ2M6MdDyo6tk2oYR/baAY5IIgFkpUx799Y00BbHcW8mvQwRiHls+E1aGotcsh zYiPupOmQgiKCiDwz7treLJdLJg7sHjFntNynvuCJf8b09iKjLbWJpKSmQlEQF+AMRPz 8UmQN9YmNnvjF6MyCmgMWwbTNktnpypYNkzWOa/UdTNOZYGcR3CjaA+4iKT/BNeklNv7 mXeyGWNEFoR7N8CHC3nq4e81j9ae0QhC5cHS1w6Ga8WXAd1Afcw9otK04gnXqO6IblzG BY0HWLE/jG3p/pdLet0035KozlryfVrVnBszLY1nX3HArWsURUREkeLvLwOp9uQH5UEC 1xHA==
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=3kZTwNbqU2LsGNzRSy3umbglKHE95RxrL3Q+baSOGwk=; b=Av4BGczovaJtVbahuw+CfOeuc/9Gl+7HTaPyxwoLPOusxPSkEQ4WpsfErpE0yYqsdl 1Q6Nt5RMBenApcySVKqKBeaTS4OqdOxkJTEB3VDq7VyGF2i2fV0gi+QMxJBTojwsPq8F K/NYB1j41+ZkGxZlB1DlMYBDQwI6qYjL12ThXYYkPLrH8atc57LGvWfghBdRuuc+uMPe cXFL+V7NCqQy0LFlW9eRgkak9CBSPADWJKWqZb3cQK+jlRYle1SdIYCET7QU4jlgk2iE Dhz1BmMC+FDeOrVdOgh4XKoZK3pI455N0tynO+9R4MDrgATXsj8t9XtM5VumZgszyxCn XWDA==
X-Gm-Message-State: AOAM5319kwBi5gy5gpKm8Lel1wcmkeCeovCyUoVpMm6+y9oEE2dQbUMR HZHpHMTscndtlaHHjPW/RQAvFDZ0xudsZdmo6JU=
X-Google-Smtp-Source: ABdhPJzpexYjeKRnb+51XM2QMoEqVq6Y4HAs/CFJVn1CuF3m7zS3HZaNkstJ7SGj0j4e7Ry97BpOD6WLATrB//xLkFc=
X-Received: by 2002:a19:6b1a:: with SMTP id d26mr7705813lfa.162.1604430841982;  Tue, 03 Nov 2020 11:14:01 -0800 (PST)
MIME-Version: 1.0
References:  <65B3EF09-25F4-4F3E-96DD-05FA60F044D0@authlete.com>
In-Reply-To: <65B3EF09-25F4-4F3E-96DD-05FA60F044D0@authlete.com>
From: Dick Hardt 
Date: Tue, 3 Nov 2020 11:13:26 -0800
Message-ID: 
To: Joseph Heenan , George Fletcher 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000006733cb05b338aa9b"
Archived-At: 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
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, 03 Nov 2020 19:14:06 -0000

--0000000000006733cb05b338aa9b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

=E1=90=A7

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  wrote:

> Hi Dick
>
> I didn=E2=80=99t attend the call so don=E2=80=99t know the background of =
this and the
> exact situation, but the general problem is mostly where the Authorizatio=
n
> Server=E2=80=99s app is *not* installed. In that case Android falls back =
to much
> weaker mechanisms that allow other apps to get a look in. App links also
> aren=E2=80=99t consistently supported across all commonly used android br=
owsers
> which causes further problems.
>
> In general to do app2app oauth redirections securely on Android it=E2=80=
=99s
> necessary for both apps to fetch the /.well-known/assetlinks.json for the
> url they want to redirect to, and verify that the intent the app intends =
to
> launch to handle the url is signed using the expected certificate. Web2ap=
p
> flows are trickier, on both iOS and on Android. There were lengthy
> discussions on at least the Android case at OAuth Security Workshop this
> year (recordings available).
>
> Joseph
>
>
> On 20 Oct 2020, at 00:09, Dick Hardt  wrote:
>
> Hey Vittorio
>
> (cc'ing OAuth list as this was brought up in the office hours today)
>
> https://developer.android.com/training/app-links
>
> An app is the default handler and the developer has verified ownership of
> the HTTPS URL. While a user can override the app being the default handle=
r
> in the system settings -- I don't see how a malicious app can be the
> default setting.
>
> What am I missing?
>
> /Dick
> =E1=90=A7
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--0000000000006733cb05b338aa9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Joseph.

George Fletcher ran a gr=
eat session on the topic at the last IIW as well.=C2=A0

George: do you have a link?

3D""=E1=90=
=A7

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan <joseph@authlete.com> wrote:
Hi Dick

I didn=E2=80=99t attend the call so do=
n=E2=80=99t know the background of this and the exact situation, but the ge=
neral problem is mostly where the Authorization Server=E2=80=99s app is *no=
t* installed. In that case Android falls back to much weaker mechanisms tha=
t allow other apps to get a look in. App links also aren=E2=80=99t consiste=
ntly supported across all commonly used android browsers which causes furth=
er problems.

In general to do app2app oauth redire=
ctions securely on Android it=E2=80=99s necessary for both apps to fetch th=
e /.well-known/assetlinks.json for the url they want to redirect to, and ve=
rify that the intent the app intends to launch to handle the url is signed =
using the expected certificate. Web2app flows are trickier, on both iOS and=
 on Android. There were lengthy discussions on at least the Android case at=
 OAuth Security Workshop this year (recordings available).

Joseph


On 20=
 Oct 2020, at 00:09, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Vittorio

(cc'ing OAuth list as this w=
as brought up in the office hours today)


<=
div>An app is the default handler and the developer has verified ownership =
of the HTTPS URL. While a user can override the app being the default handl=
er in the system settings -- I don't see how a malicious app can be the=
 default setting.

What am I missing?
/Dick
3D""=E1=90=A7

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


--0000000000006733cb05b338aa9b--


From nobody Tue Nov  3 11:17:09 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FAB3A0E81 for ; Tue,  3 Nov 2020 11:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level: 
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=1.533, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTN4xpYK6Z1M for ; Tue,  3 Nov 2020 11:17:05 -0800 (PST)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650098.outbound.protection.outlook.com [40.107.65.98]) (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 777E43A0E5B for ; Tue,  3 Nov 2020 11:17:05 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UmzOPqjZUTHiQiWrXoMlVA8PsqL/Ulh0xH/DPuO5nBQYerHNaYI+rtQQd9mKI5Mnx57W6Oa3CXPF0JZLwVnJfepanjrom2O+2dF3cKbl3BWIAcl/uHNP+lDLCe09J7+0JtDghr044O4VMuGAwuBK87SmV8F0z8lvJM/n/Uu/8SQfBD2fhL0ovlB3QRKnsCj2INsn9uIW6DiJwP7Wk9w9Yl2UbfFaGGSJm/sArHUPf07eGKxFV1cEOJU7GNCYtrOf23VdimPxcOMCSd7s3hJ5rsxGr7NVc1EMYRo+p2L0sQCziTtbDFUaNXUJJQthvJyGOCdCuibxHmi1hceZuQAlzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YKHCQdWg/3saX6FVGcpTMqENoLV4pCBJXhyX0jhbfwE=; b=FGfs39PhgTYYF5sByWyfu/qZKgIy42PZB8purIVg7QIuE8zXVXsw7KCAs9cXg6dixk/Uq/Y2YJPU1O9a6bdEIxUwotj5tbw1iVjrB6YL6JA3Q/TZnWef/+Dv71OIVukz/1FYUp8CFrx7kisNOVJjymMknB+LR2/8UwEcXcE1HFhBQR0Ht2xGUogWLxPy0mTKImtbzRsS9bJ15LXJn5b/Kbauy9l0uyBB9m8nfOArhw7bH598SbegxXRXBB1o6xfMsoYds5oaqqRXy3etYou4eyHF1b4l45AIY6RIJ7HbtuFSY9YCkrZ01WrDhS5qpFwZpcelwO1zvRb/laJOft/MIg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YKHCQdWg/3saX6FVGcpTMqENoLV4pCBJXhyX0jhbfwE=; b=WIo5yWu/QPQis4NvG41MLclscP5rd6oyUgnPp5i86/3jqaJYm0+PdF6c0CdRWD76QW1HwrwLOVcBNoFA1VtBuBxoBGrWb4n++tQYpWORPDwHPjboYWGwXATuF0qraN+CUOAEHE4KLilxK3oVAvL868Kfa/u5Ke5ABB0rd7sxqzI=
Received: from (2603:10b6:208:39::11) by MN2PR00MB0702.namprd00.prod.outlook.com (2603:10b6:208:1d5::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3575.0; Tue, 3 Nov 2020 19:17:03 +0000
Received: from MN2PR00MB0623.namprd00.prod.outlook.com ([fe80::7c1b:4b71:3ddd:b5c5]) by MN2PR00MB0623.namprd00.prod.outlook.com ([fe80::7c1b:4b71:3ddd:b5c5%7]) with mapi id 15.20.3582.000; Tue, 3 Nov 2020 19:17:03 +0000
From: Tim Cappalli 
To: dick.hardt , Joseph Heenan , George Fletcher 
CC: oauth 
Thread-Topic: [OAUTH-WG] Android App Links (AKA Universal Links)
Thread-Index: AQHWpm0OwTBvOIoC706ztYCtV/v35Km23L0AgAABOACAAACjgA==
Date: Tue, 3 Nov 2020 19:17:03 +0000
Message-ID: 
References:  <65B3EF09-25F4-4F3E-96DD-05FA60F044D0@authlete.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [100.0.202.137]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8c08f4b1-4d74-4f54-7cbf-08d8802d0c01
x-ms-traffictypediagnostic: MN2PR00MB0702:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:2657;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +3FJoojgsYw5h3WJ4vAd7YSe0tFK5p4cUvYsigpAzR9lXy6d578jqDD8mPcW1HT23gXTB3a4elijBFMcB8wOe+cwICecH37EXU8WXElREsDzXUgZTzE2q865ql2QyfjZmp9aw8F6iY8J4xbDlgt4WqhVur3qktNrJPxBOcKBonAwQIu6J4zU9jB51ReyMYe/ygq/f12BzEG3CYHMzz1e3yccvLvJKhfAAiNosdQKXfpiCFwFwh75GKWvgKFPz8I78hhUSxlVdbyA1unLEdSUImltBDOlYx870whWDJczbUu2BpCRtLpBpXjHXLf0hCkRZ1LQ7DwBDj7ZR++qIJdQJZxNnwrriBeB7bCOU256S3ovD7BkMIaAbX9w8m8c/rj3i7ysjgQi3SLR181pVxwbHKPBM6/0kLRXMBQnuKWVoQ8sxvejP2ffJCHWZVdXMn6Hdvxht41X6Nq4MTqYCpDfbA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0623.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(346002)(366004)(376002)(39860400002)(396003)(136003)(8990500004)(33656002)(66946007)(8676002)(86362001)(4326008)(52536014)(9686003)(76116006)(53546011)(6506007)(66476007)(55016002)(71200400001)(316002)(478600001)(186003)(66556008)(5660300002)(8936002)(66446008)(82960400001)(166002)(83380400001)(966005)(2906002)(10290500003)(7696005)(110136005)(64756008)(26005)(82950400001)(99710200001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: cKgIvHoe7sPxeqokiP8GuOB+P8gEPRd2GvZBiyghixW4XUH36PfFaNItT4KP62jvuNLDvdJUei37T3kE80ssVOshrEqvTWn+h9M6GWBKbCj5NKgnQtLRofqVm97ecDWcmrm8/EBIyJ1eoH1IWNgdXIELJ9QlJ7CGSE4MwGzvYjwhSTr9L5MFflXQflFJQi3LHAzHFXvBULnRkqy0NVvphBYn8VSBgyxiinKREkTHjpGSN7MuiDLIdLfYXspFvhLNR/+eKiWwA+qMNO5V5xEGxCeZhurEbX1W1UMdnL7tqLgH4G6hv6B2pjO+rsQJ6X3xR01V3dDt5ZSJaBrEORHXQqNzJP3VIoafPnju5mKtmpethFW8FPlgncFrdoCLzd2ncbb2N56kgNP79H4k9SG8j23E5xT8SlxXSASwQMlLRIfZnak4+j+1mE5P/tWbAjZo8qPZcWY1ckMh2j3GjwvGGNT+jmcwg5wPWt3F9sGm2Lvv/NfyCRI6JN6huc6QtUKootHjLj1AZMmeOhCJqCjImPJoIcfF7bcYihWNmA1hMHjM0OrGtn3eOytkEZv4rCSFE8QuUlZScpBSpAQbdPVosw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB062386FAA9778F909EE8330B95111MN2PR00MB0623namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0623.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c08f4b1-4d74-4f54-7cbf-08d8802d0c01
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2020 19:17:03.4431 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zymgUjHDuKYM6buCNmxRs9eJAZAHGLCHz8R8Y+FT5jG59fWPGi0RMxAQBM5zO1juBet174EVx+UzPeK/46mDkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0702
Archived-At: 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
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, 03 Nov 2020 19:17:07 -0000

--_000_MN2PR00MB062386FAA9778F909EE8330B95111MN2PR00MB0623namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVyZeKAmXMgdGhlIE9TVyByZWNvcmRpbmcgb24gYXBwMmFwcC4NCg0KaHR0cHM6Ly93d3cueW91
dHViZS5jb20vd2F0Y2g/dj12a3R5WTVDWHdqZw0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnPg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMywgMjAyMCBhdCAxNDoxNA0K
VG86IEpvc2VwaCBIZWVuYW4gPGpvc2VwaEBhdXRobGV0ZS5jb20+LCBHZW9yZ2UgRmxldGNoZXIg
PGdmZmxldGNoQGFvbC5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog
UmU6IFtPQVVUSC1XR10gQW5kcm9pZCBBcHAgTGlua3MgKEFLQSBVbml2ZXJzYWwgTGlua3MpDQpU
aGFua3MgSm9zZXBoLg0KDQpHZW9yZ2UgRmxldGNoZXIgcmFuIGEgZ3JlYXQgc2Vzc2lvbiBvbiB0
aGUgdG9waWMgYXQgdGhlIGxhc3QgSUlXIGFzIHdlbGwuDQoNCkdlb3JnZTogZG8geW91IGhhdmUg
YSBsaW5rPw0KDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xq
YXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTI2ZjExZTU0
LTA2YmItNDVmMC1iYTgzLTVmZjYyN2VkNTU3OV3hkKcNCg0KT24gVHVlLCBOb3YgMywgMjAyMCBh
dCAxMTowOSBBTSBKb3NlcGggSGVlbmFuIDxqb3NlcGhAYXV0aGxldGUuY29tPG1haWx0bzpqb3Nl
cGhAYXV0aGxldGUuY29tPj4gd3JvdGU6DQpIaSBEaWNrDQoNCkkgZGlkbuKAmXQgYXR0ZW5kIHRo
ZSBjYWxsIHNvIGRvbuKAmXQga25vdyB0aGUgYmFja2dyb3VuZCBvZiB0aGlzIGFuZCB0aGUgZXhh
Y3Qgc2l0dWF0aW9uLCBidXQgdGhlIGdlbmVyYWwgcHJvYmxlbSBpcyBtb3N0bHkgd2hlcmUgdGhl
IEF1dGhvcml6YXRpb24gU2VydmVy4oCZcyBhcHAgaXMgKm5vdCogaW5zdGFsbGVkLiBJbiB0aGF0
IGNhc2UgQW5kcm9pZCBmYWxscyBiYWNrIHRvIG11Y2ggd2Vha2VyIG1lY2hhbmlzbXMgdGhhdCBh
bGxvdyBvdGhlciBhcHBzIHRvIGdldCBhIGxvb2sgaW4uIEFwcCBsaW5rcyBhbHNvIGFyZW7igJl0
IGNvbnNpc3RlbnRseSBzdXBwb3J0ZWQgYWNyb3NzIGFsbCBjb21tb25seSB1c2VkIGFuZHJvaWQg
YnJvd3NlcnMgd2hpY2ggY2F1c2VzIGZ1cnRoZXIgcHJvYmxlbXMuDQoNCkluIGdlbmVyYWwgdG8g
ZG8gYXBwMmFwcCBvYXV0aCByZWRpcmVjdGlvbnMgc2VjdXJlbHkgb24gQW5kcm9pZCBpdOKAmXMg
bmVjZXNzYXJ5IGZvciBib3RoIGFwcHMgdG8gZmV0Y2ggdGhlIC8ud2VsbC1rbm93bi9hc3NldGxp
bmtzLmpzb24gZm9yIHRoZSB1cmwgdGhleSB3YW50IHRvIHJlZGlyZWN0IHRvLCBhbmQgdmVyaWZ5
IHRoYXQgdGhlIGludGVudCB0aGUgYXBwIGludGVuZHMgdG8gbGF1bmNoIHRvIGhhbmRsZSB0aGUg
dXJsIGlzIHNpZ25lZCB1c2luZyB0aGUgZXhwZWN0ZWQgY2VydGlmaWNhdGUuIFdlYjJhcHAgZmxv
d3MgYXJlIHRyaWNraWVyLCBvbiBib3RoIGlPUyBhbmQgb24gQW5kcm9pZC4gVGhlcmUgd2VyZSBs
ZW5ndGh5IGRpc2N1c3Npb25zIG9uIGF0IGxlYXN0IHRoZSBBbmRyb2lkIGNhc2UgYXQgT0F1dGgg
U2VjdXJpdHkgV29ya3Nob3AgdGhpcyB5ZWFyIChyZWNvcmRpbmdzIGF2YWlsYWJsZSkuDQoNCkpv
c2VwaA0KDQoNCg0KT24gMjAgT2N0IDIwMjAsIGF0IDAwOjA5LCBEaWNrIEhhcmR0IDxkaWNrLmhh
cmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGV5
IFZpdHRvcmlvDQoNCihjYydpbmcgT0F1dGggbGlzdCBhcyB0aGlzIHdhcyBicm91Z2h0IHVwIGlu
IHRoZSBvZmZpY2UgaG91cnMgdG9kYXkpDQoNCmh0dHBzOi8vZGV2ZWxvcGVyLmFuZHJvaWQuY29t
L3RyYWluaW5nL2FwcC1saW5rczxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkZXZlbG9wZXIuYW5kcm9pZC5jb20lMkZ0cmFp
bmluZyUyRmFwcC1saW5rcyZkYXRhPTA0JTdDMDElN0N0aW0uY2FwcGFsbGklNDBtaWNyb3NvZnQu
Y29tJTdDZDJkNjExNGNmYjNlNGE3MjNjZTMwOGQ4ODAyY2E4ZmUlN0M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3NDAwMjc2NjA0NjcwMTA5JTdDVW5rbm93biU3
Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2
SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9VkFOWUdYRUI0TTVpJTJGOW5EVyUy
QnpoZzY5UVNKWGQ1UkElMkJ3ekpuZU8xQXo4byUzRCZyZXNlcnZlZD0wPg0KDQpBbiBhcHAgaXMg
dGhlIGRlZmF1bHQgaGFuZGxlciBhbmQgdGhlIGRldmVsb3BlciBoYXMgdmVyaWZpZWQgb3duZXJz
aGlwIG9mIHRoZSBIVFRQUyBVUkwuIFdoaWxlIGEgdXNlciBjYW4gb3ZlcnJpZGUgdGhlIGFwcCBi
ZWluZyB0aGUgZGVmYXVsdCBoYW5kbGVyIGluIHRoZSBzeXN0ZW0gc2V0dGluZ3MgLS0gSSBkb24n
dCBzZWUgaG93IGEgbWFsaWNpb3VzIGFwcCBjYW4gYmUgdGhlIGRlZmF1bHQgc2V0dGluZy4NCg0K
V2hhdCBhbSBJIG1pc3Npbmc/DQoNCi9EaWNrDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3Qu
Y29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29u
dGVudCZndWlkPTc1M2E0ZWFlLTRjNTQtNDBmMC1hNjAzLTA5ZWE2Y2RmZTQzNF3hkKcNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG
bWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmZGF0YT0wNCU3QzAxJTdDdGltLmNhcHBhbGxpJTQw
bWljcm9zb2Z0LmNvbSU3Q2QyZDYxMTRjZmIzZTRhNzIzY2UzMDhkODgwMmNhOGZlJTdDNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzQwMDI3NjYwNDY3MDEwOSU3
Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16
SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPTBZeGRRTUNnbkxN
VUxRUWF5VWpHd2hDR2QyZnFQNHk5Y0ZTQ0sxalk5eGslM0QmcmVzZXJ2ZWQ9MD4NCg0K

--_000_MN2PR00MB062386FAA9778F909EE8330B95111MN2PR00MB0623namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAy
IDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6
d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu
IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0
aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N
CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv
dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286
c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V
UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SGVyZeKA
mXMgdGhlIE9TVyByZWNvcmRpbmcgb24gYXBwMmFwcC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh
bnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9dmt0eVk1
Q1h3amciPmh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9dmt0eVk1Q1h3amc8L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w
cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJy
Pg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE5vdmVtYmVyIDMsIDIwMjAgYXQgMTQ6MTQ8YnI+DQo8
Yj5UbzogPC9iPkpvc2VwaCBIZWVuYW4gJmx0O2pvc2VwaEBhdXRobGV0ZS5jb20mZ3Q7LCBHZW9y
Z2UgRmxldGNoZXIgJmx0O2dmZmxldGNoQGFvbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5vYXV0
aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgt
V0ddIEFuZHJvaWQgQXBwIExpbmtzIChBS0EgVW5pdmVyc2FsIExpbmtzKTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBKb3Nl
cGguPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HZW9yZ2Ug
RmxldGNoZXIgcmFuIGEgZ3JlYXQgc2Vzc2lvbiBvbiB0aGUgdG9waWMgYXQgdGhlIGxhc3QgSUlX
IGFzIHdlbGwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkdlb3JnZTogZG8geW91IGhhdmUgYSBsaW5rPzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVy
PSIwIiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNv
bS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9j
b250ZW50JmFtcDtndWlkPTI2ZjExZTU0LTA2YmItNDVmMC1iYTgzLTVmZjYyN2VkNTU3OSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMywgMjAyMCBhdCAxMTowOSBBTSBK
b3NlcGggSGVlbmFuICZsdDs8YSBocmVmPSJtYWlsdG86am9zZXBoQGF1dGhsZXRlLmNvbSI+am9z
ZXBoQGF1dGhsZXRlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y
aWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIERpY2s8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbuKAmXQgYXR0ZW5kIHRo
ZSBjYWxsIHNvIGRvbuKAmXQga25vdyB0aGUgYmFja2dyb3VuZCBvZiB0aGlzIGFuZCB0aGUgZXhh
Y3Qgc2l0dWF0aW9uLCBidXQgdGhlIGdlbmVyYWwgcHJvYmxlbSBpcyBtb3N0bHkgd2hlcmUgdGhl
IEF1dGhvcml6YXRpb24gU2VydmVy4oCZcyBhcHAgaXMgKm5vdCogaW5zdGFsbGVkLiBJbiB0aGF0
IGNhc2UgQW5kcm9pZCBmYWxscyBiYWNrIHRvIG11Y2ggd2Vha2VyIG1lY2hhbmlzbXMNCiB0aGF0
IGFsbG93IG90aGVyIGFwcHMgdG8gZ2V0IGEgbG9vayBpbi4gQXBwIGxpbmtzIGFsc28gYXJlbuKA
mXQgY29uc2lzdGVudGx5IHN1cHBvcnRlZCBhY3Jvc3MgYWxsIGNvbW1vbmx5IHVzZWQgYW5kcm9p
ZCBicm93c2VycyB3aGljaCBjYXVzZXMgZnVydGhlciBwcm9ibGVtcy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZ2VuZXJhbCB0byBkbyBh
cHAyYXBwIG9hdXRoIHJlZGlyZWN0aW9ucyBzZWN1cmVseSBvbiBBbmRyb2lkIGl04oCZcyBuZWNl
c3NhcnkgZm9yIGJvdGggYXBwcyB0byBmZXRjaCB0aGUgLy53ZWxsLWtub3duL2Fzc2V0bGlua3Mu
anNvbiBmb3IgdGhlIHVybCB0aGV5IHdhbnQgdG8gcmVkaXJlY3QgdG8sIGFuZCB2ZXJpZnkgdGhh
dCB0aGUgaW50ZW50IHRoZSBhcHAgaW50ZW5kcyB0byBsYXVuY2ggdG8gaGFuZGxlDQogdGhlIHVy
bCBpcyBzaWduZWQgdXNpbmcgdGhlIGV4cGVjdGVkIGNlcnRpZmljYXRlLiBXZWIyYXBwIGZsb3dz
IGFyZSB0cmlja2llciwgb24gYm90aCBpT1MgYW5kIG9uIEFuZHJvaWQuIFRoZXJlIHdlcmUgbGVu
Z3RoeSBkaXNjdXNzaW9ucyBvbiBhdCBsZWFzdCB0aGUgQW5kcm9pZCBjYXNlIGF0IE9BdXRoIFNl
Y3VyaXR5IFdvcmtzaG9wIHRoaXMgeWVhciAocmVjb3JkaW5ncyBhdmFpbGFibGUpLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb3NlcGg8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAgT2N0IDIw
MjAsIGF0IDAwOjA5LCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBn
bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGV5IFZp
dHRvcmlvPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oY2Mn
aW5nIE9BdXRoIGxpc3QgYXMgdGhpcyB3YXMgYnJvdWdodCB1cCBpbiB0aGUgb2ZmaWNlIGhvdXJz
IHRvZGF5KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su
Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZkZXZlbG9wZXIuYW5kcm9pZC5jb20lMkZ0cmFpbmluZyUy
RmFwcC1saW5rcyZhbXA7ZGF0YT0wNCU3QzAxJTdDdGltLmNhcHBhbGxpJTQwbWljcm9zb2Z0LmNv
bSU3Q2QyZDYxMTRjZmIzZTRhNzIzY2UzMDhkODgwMmNhOGZlJTdDNzJmOTg4YmY4NmYxNDFhZjkx
YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzQwMDI3NjYwNDY3MDEwOSU3Q1Vua25vd24lN0NU
V0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklr
MWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1WQU5ZR1hFQjRNNWklMkY5bkRX
JTJCemhnNjlRU0pYZDVSQSUyQnd6Sm5lTzFBejhvJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly9kZXZlbG9wZXIuYW5kcm9pZC5jb20vdHJhaW5pbmcvYXBwLWxpbmtz
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5BbiBhcHAgaXMgdGhlIGRlZmF1bHQgaGFuZGxlciBhbmQgdGhlIGRldmVsb3BlciBoYXMgdmVy
aWZpZWQgb3duZXJzaGlwIG9mIHRoZSBIVFRQUyBVUkwuIFdoaWxlIGEgdXNlciBjYW4gb3ZlcnJp
ZGUgdGhlIGFwcCBiZWluZyB0aGUgZGVmYXVsdCBoYW5kbGVyIGluIHRoZSBzeXN0ZW0gc2V0dGlu
Z3MgLS0gSSBkb24ndCBzZWUgaG93IGEgbWFsaWNpb3VzIGFwcCBjYW4gYmUgdGhlIGRlZmF1bHQg
c2V0dGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+V2hhdCBhbSBJIG1pc3Npbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAw
X2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkds
amF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlk
PTc1M2E0ZWFlLTRjNTQtNDBmMC1hNjAzLTA5ZWE2Y2RmZTQzNCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy
RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTA0
JTdDMDElN0N0aW0uY2FwcGFsbGklNDBtaWNyb3NvZnQuY29tJTdDZDJkNjExNGNmYjNlNGE3MjNj
ZTMwOGQ4ODAyY2E4ZmUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw
JTdDNjM3NDAwMjc2NjA0NjcwMTA5JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0
d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3
QzMwMDAmYW1wO3NkYXRhPTBZeGRRTUNnbkxNVUxRUWF5VWpHd2hDR2QyZnFQNHk5Y0ZTQ0sxalk5
eGslM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_MN2PR00MB062386FAA9778F909EE8330B95111MN2PR00MB0623namp_--


From nobody Tue Nov  3 11:46:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A1D3A10FE for ; Tue,  3 Nov 2020 11:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_JunxZ6hnT4 for ; Tue,  3 Nov 2020 11:46:13 -0800 (PST)
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 6CEB73A10FD for ; Tue,  3 Nov 2020 11:46:13 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id h62so416803wme.3 for ; Tue, 03 Nov 2020 11:46:13 -0800 (PST)
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; bh=4DSDgf2O6JgaVUtQwHQFNtS3GwdVNqac6Ig6SAMd/a8=; b=xyRCxec3cHemLLqXvJH1+6+rUdp2PTG6yDf3yXcrOtyyo7L31QEYKp+MuWIYJrOUeV ahp7f1P0bLJv38Qf2/houh/uFOCCL5VjTpIVwL1Q4q8IUC73ZnS0aau/8DqK1djmnrNA SrSahgs2j/lcW4loSfZ2htvyTIDok4MLYNI6YhGVcjK6+iSXOv3+MZn5JdvLlwDqZHS5 MvD/urZG5yuThmxcJEltu75u7PPHBjf9zapAaSVEINGVlQeRS/J9tEdgkuRN+erzWMdo dAilXJzSSxGMzX0Bm7oW8grrCLTbNBIe4kSdEyf2vDga/z1fPpVdTfbeZMDGFAFnbTOR LBww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4DSDgf2O6JgaVUtQwHQFNtS3GwdVNqac6Ig6SAMd/a8=; b=DS8AV6Y/n6JXQ9w2lPjB2yIOhredLXeitMsaFpjsyfv0wGJGuSkQhjziXS2n9J1Klj Korn6M2LZxy+0z948XuyhXLKfWxXo6uBeCH9ZL1fYi5RW53bE4QIqkizB9oH+K3nuRvV /Mf5vidtW/kTMGTNjdEqN84U4JuSnePCUXmybVrvtQ9PQl1pxNUQ0oJ0FVshhOyWynQ/ UCUEu3jsUMd01P87X8ezH0Yu8YbFMaTIuhhGRMLzA/FVPNZKARz2yu5HpxzfZr1aqfB6 ft/Vn+PybOBbEzVeafgj36hst+odsDcY4S86eCikFhjxTjsgRC4ZIEN6VygI+8z8/znP g2iA==
X-Gm-Message-State: AOAM531Aa3vWmbPaVYkmpPVOh7eQlwpH8zxdOaK5FNBmdzmobzdhpS6Y tQuJRScMsCSREbw25dQ9FdNSnHTyATIfDZgIjX4GWOAWIHGDzA==
X-Google-Smtp-Source: ABdhPJwOUNEKLRP41S5rxZvgqNbJ0NE9gVjCqU8N+5rdTpS1H9gnjTBsHXS/Wbjts/7S/m21ZqhkHbTNl4V9DdbMeLE=
X-Received: by 2002:a1c:2b05:: with SMTP id r5mr741968wmr.179.1604432771226; Tue, 03 Nov 2020 11:46:11 -0800 (PST)
MIME-Version: 1.0
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>   <69B0850B-D863-4792-905E-54EE20823323@authlete.com>
In-Reply-To: <69B0850B-D863-4792-905E-54EE20823323@authlete.com>
From: Takahiko Kawasaki 
Date: Wed, 4 Nov 2020 04:46:12 +0900
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000065390d05b3391d96"
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Nov 2020 19:46:18 -0000

--00000000000065390d05b3391d96
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It sounds that the Security Considerations section or somewhere appropriate
should have a paragraph like below.

When an authorization response includes a JWT whose `iss` claim represents
the issuer identifier of the authorization server, the `iss` claim can be
used as a substitute for the `iss` parameter. Therefore, such authorization
response does not have to have the `iss` parameter outside the JWT
separately. Examples of such JWTs include the value of the `id_token`
parameter in OIDC and the value of `response` parameter in JARM.

Taka

On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan  wrote:

> I agree, it is in redundant in the JARM case.
>
> I find the text in
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-01.html#name-security-considerations
> (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I
> think it would be good to say something along the lines of:
>
> Although integrity protection is not necessary to prevent mixup, any
> authorization response method that includes a JWT with an =E2=80=98iss' (=
for
> example, JARM or OIDC hybrid flow) will prevent the attack (assuming the
> client is validating the iss).
>
>
> I=E2=80=99m not entirely sure I understand what "MUST NOT allow multiple
> authorization servers to return the same issuer identifier during
> registration=E2=80=9D means as I don=E2=80=99t think https://tools.ietf.o=
rg/html/rfc7591
> returns the issuer?
>
> It might be clearer to say something like =E2=80=9CWhen
> https://tools.ietf.org/html/rfc8414 is used the client MUST implement the
> validation described in https://tools.ietf.org/html/rfc8414#section-3.3.
> When authorization server details can be manually configured in the clien=
t,
> the client must verify that all issuer values are unique.=E2=80=9D (Or at=
 least
> something along those lines, I=E2=80=99m sure my wording can be improved.=
 But if
> the client is correctly implementing rfc8414 or OIDC discovery [and does
> not have any manually configured authorization servers] then there=E2=80=
=99s no
> requirement for any further checks that the issuer is unique.)
>
> Joseph
>
>
> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov 
> wrote:
>
> This can potentially occur. If JARM is used "iss" becomes redundant. To m=
e
> JARM is an "enhanced" iss.
>
> If both are included a sensible client should make sure the iss and the
> JARM iss match.
>
> My suggestion is to not require iss when a JARM is present, but in case
> both do occur to have the client check both.
>
> Vladimir
> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>
> Hi Karsten,
>
> The specification mentions JARM. Does this specification require the iss
> response parameter even when JARM is used? That is, should an authorizati=
on
> response look like below?
>
> HTTP/1.1 302 Found
> Location: https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUER}
>
> Or, can the iss response parameter be omitted when JARM is used?
>
> A small feedback for the 3rd paragraph in Section 4:
> s/identifes/identifies/
>
> Best Regards,
> Taka
>
>
> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov 
> wrote:
>
>> Thanks Karsten, looks good to me now, no further comments.
>>
>> Vladimir
>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>
>> Hi all,
>>
>> Daniel and I published a new version of the "iss" response parameter
>> draft to address the feedback from the WG.
>>
>> Changes in -01:
>>
>>    - Incorporated first WG feedback
>>    - Clarifications for use with OIDC
>>    - Added note that clients supporting just one AS are not vulnerable
>>    - Renamed metadata parameter
>>    - Various editorial changes
>>
>>
>> We would like to ask you for further feedback and comments on the new
>> draft version.
>>
>> Best regards,
>> Karsten
>>
>> -------- Forwarded Message --------
>> Subject: New Version Notification for
>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> Date: Sun, 01 Nov 2020 23:31:42 -0800
>> From: internet-drafts@ietf.org
>> To: Karsten Meyer zu Selhausen 
>> , Karsten zu Selhausen
>> 
>> , Daniel Fett 
>> 
>>
>>
>> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> has been successfully submitted by Karsten Meyer zu Selhausen and posted
>> to the
>> IETF repository.
>>
>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>> Revision: 01
>> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization
>> Response
>> Document date: 2020-11-01
>> Group: Individual Submission
>> Pages: 10
>> URL:
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-re=
sp-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-r=
esp/
>> Html:
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-re=
sp-01.html
>> Htmlized:
>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-0=
1
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-aut=
h-resp-01
>>
>> Abstract:
>> This document specifies a new parameter "iss" that is used to
>> explicitly include the issuer identifier of the authorization server
>> in the authorization response of an OAuth authorization flow. If
>> implemented correctly, the "iss" parameter serves as an effective
>> countermeasure to "mix-up attacks".
>>
>>
>>
>> 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
>>
>>
>> --
>> Karsten Meyer zu Selhausen
>> IT Security Consultant
>> Phone:	+49 (0)234 / 54456499
>> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing,=
 Security Training
>>
>> Does your OAuth or OpenID Connect implementation use PKCE to strengthen =
the security? Learn more about the procetion PKCE provides and its limitati=
ons in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce-=
cannot-protect-your-confidential-oauth-client
>>
>> Hackmanit GmbH
>> Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
>> 44789 Bochum
>>
>> Registergericht: Amtsgericht Bochum, HRB 14896
>> Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj =
Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa=
uth
>>
>> _______________________________________________
>> 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
>

--00000000000065390d05b3391d96
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It sounds that the Security Considerations section or some=
where appropriate should have a paragraph like below.

When an author=
ization response includes a JWT whose `iss` claim represents the issuer ide=
ntifier of the authorization server, the `iss` claim can be used as a subst=
itute for the `iss` parameter. Therefore, such authorization response does =
not have to have the `iss` parameter outside the JWT separately. Examples o=
f such JWTs include the value of the `id_token` parameter in OIDC and the v=
alue of `response` parameter in JARM.

Taka

On Tue, Nov 3, 2020 =
at 10:46 PM Joseph Heenan <joseph=
@authlete.com> wrote:
I agree, it is in re=
dundant in the JARM case.

I find the text in=C2=A0https://www.ie=
tf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-s=
ecurity-considerations (the 4th paragraph where JARM & JWTs) are me=
ntioned a bit confusing - I think it would be good to say something along t=
he lines of:

Although integrity protection is not =
necessary to prevent mixup, any authorization response method that includes=
 a JWT with an =E2=80=98iss' (for example, JARM or OIDC hybrid flow) wi=
ll prevent the attack (assuming the client is validating the iss).


I=E2=80=99m not entirely sure I understand =
what "MUST NOT allow multiple authorization servers to return the same=
 issuer identifier during registration=E2=80=9D means as I don=E2=80=99t th=
ink https=
://tools.ietf.org/html/rfc7591 returns the issuer?

=

It might be clearer to say something like =E2=80=9CWhen https://tools.ietf.org/=
html/rfc8414 is used the client MUST implement the validation described=
 in https://tools.ietf.org/html/rfc8414#section-3.3. When authorizat=
ion server details can be manually configured in the client, the client mus=
t verify that all issuer values are unique.=E2=80=9D (Or at least something=
 along those lines, I=E2=80=99m sure my wording can be improved. But if the=
 client is correctly implementing rfc8414 or OIDC discovery [and does not h=
ave any manually configured authorization servers] then there=E2=80=99s no =
requirement for any further checks that the issuer is unique.)
Joseph


O=
n 3 Nov 2020, at 07:01, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

 =20
   =20
 =20
  
This can potentially occur. If JARM is used "iss" becom=
es
      redundant. To me JARM is an "enhanced" iss.
If both a=
re included a sensible client should make sure the iss
      and the JARM iss match.
My suggestion is to not require iss whe=
n a JARM is present, but
      in case both do occur to have the client check both.

    
Vladimir

    

    
On 02/11/2020 22:34, Takahiko Kawasaki
      wrote:

    

    

     =20
      
Hi Karsten,
        


        

        
The specification mentions JARM. Does this specification
          require the iss response parameter even when JARM is used?
          That is, should an authorization response look like below?

        


        

        
HTTP/1.1 302 Found

        
        


        

        
Or, can the iss response parameter be omitted when JARM is
          used?

        


        

        
A small feedback for the 3rd paragraph in Section 4:
          s/identifes/identifies/

        


        

        
Best Regards,

        
Taka

        
=C2=A0

      

      

      

        
On Tue, Nov 3, 2020 at 3:13 A=
M
          Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        

          
Thanks Karsten, looks good to me now, no further
              comments.

            
Vladimir

            

            
On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:

            

            
Hi all,
Daniel and=
 I
                  published a new version of the "iss" response
                  parameter draft to address the feedback from the WG.
Changes in -01:

              
    
                
  • Incorporated
                    first WG feedback
    • 
                
  • Clarifications
                    for use with OIDC
    • 
                
  • Added note that
                    clients supporting just one AS are not vulnerable
    • 
                
  • Renamed metadata
                    parameter
    • 
                
  • Various editoria=
l
                    changes
    
                  
    • 
              

              


                We would like to ask you for
                      further feedback and comments on the new draft
                      version.

                    

              


                

              
Best regards,

              
Karsten
              


              

              
-------- Forwarded Message --------
                

                  
                    

                      Subjec=
t: 
                      New Version Notification for
                        draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
                    

                    

                      Date: =

                      Sun, 01 Nov 2020 23:31:42 -0800
                    

                    

                      From: =

                      internet-drafts@ietf.org
                    

                    

                      To: 
                      Karsten Meyer zu Selhausen <karsten.meyerzusel=
hausen@hackmanit.de>,
                        Karsten zu Selhausen <karsten.meyerzuselhausen@h=
ackmanit.de>,
                        Daniel Fett <mail@danielfett.de>
                    

                  
                

                

                

                

                A new version of I-D,
                draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                has been successfully submitted by Karsten Meyer zu
                Selhausen and posted to the

                IETF repository.

                

                Name: draft-meyerzuselhausen-oauth-iss-auth-resp

                Revision: 01

                Title: OAuth 2.0 Authorization Server Issuer Identifier
                in Authorization Response

                Document date: 2020-11-01

                Group: Individual Submission

                Pages: 10

                URL: https://www.ietf.=
org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                Status: https://datatracker=
.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

                Html: https://www.iet=
f.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html

                Htmlized: https://tools.ietf.o=
rg/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01

                Diff: https://www.ietf=
.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth-resp-01

                

                Abstract:

                This document specifies a new parameter "iss" tha=
t is
                used to

                explicitly include the issuer identifier of the
                authorization server

                in the authorization response of an OAuth authorization
                flow. If

                implemented correctly, the "iss" parameter serves=
 as an
                effective

                countermeasure to "mix-up attacks".

                

                

                

                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

                

                

              

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the=
 security? Learn more about the procetion PKCE provides and its limitations=
 in our new blog post:
https://www.hackmanit.de=
/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

              

              

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


            

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.or=
g

          https://www.ietf.org/mailman/listinfo/oauth=


        

      

    

    

  


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

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--00000000000065390d05b3391d96--


From nobody Tue Nov  3 14:12:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0A53A1245 for ; Tue,  3 Nov 2020 14:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.345
X-Spam-Level: 
X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGIm3ESpj2jm for ; Tue,  3 Nov 2020 14:12:15 -0800 (PST)
Received: from sonic311-24.consmr.mail.ne1.yahoo.com (sonic311-24.consmr.mail.ne1.yahoo.com [66.163.188.205]) (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 AD47F3A1243 for ; Tue,  3 Nov 2020 14:12:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1604441534; bh=YMZ9iJWzIqMweQrAkgmoOp7kEgylPA1usdG7CBQ2vKA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=gIrRjbp5dzyX5mILLm4ikVW1NGcNw5buyDNrriSNBZOPjIWggcP6uIgtsBoTMiXFG5JOtyMtSLVOiMB7FrOhoYTXj66gGj/43Rr5mwMbWPGVLaamrunhkHQ2KkpU6r8LQ/j+I6panm2b2aYXnMcKKyNSbUcc2kbk7ON2fW1Jcq1NjjDh8oDiRCLxzm9SMvz8ReDU/20udjoGRM7kmq8x0VkSKyjW0nyQGfe89P7Pg6jima2TJQImoJwDCJmXMAmjQUHD68yVrZIHIDkhrBH/zeK89g6yuoiBW8JQEAXrWTKwoyKaxFFRacgKTPqMiCirTldR6sj1mSmv2EC3E7YlVQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1604441534; bh=4NQmLvQremcOeEEO3zrPYAWYffmT8eAIGpcKz5rE1ZO=;  h=Subject:To:From:Date; b=PHwOP8N7+529kmBQwFb/lsYxbEvZvP2oKmLN/7x+DhX/FP+YOsoq8GHb/tbYE+VBn0zAcGVoMLV0uDP0fwfpalnhe6RWrntNkFsppGP/mriOzR3cuHB0ugOPpkcvGMYdh2sEda4sFIRie7CF3kttD6AwWIKxzap7ehEO3yFqKon0PQqM8kDl0e207KEUEfbI4pQS3UpIUyPDJeh0JE8EvIrNyisKgoP+ayS2D/Yv1NyXUJSbL5b8LyTwBbZJWs1nOPLgJtuferwW09CilvmJWaHv0EdEasocaXXsFdEmHE2bYHMLPE34vyrdbxitKmSMFmn4hht02eErtDO48csC7A==
X-YMail-OSG: 4COef60VM1mEDHCpet3Kd0TKeDyuGO1OrsAiCDvmsODENTyHeoSgyTmO40Tsu2K QtHVLSjqdefcoiSGXFGvAFujQDQrPh1DzlmlF2bL1qWbAWh5j2qWtFdCqUktX1QyS3v_DHA4tmiZ _CqnaZkGgKk0FSaUjfxCUxGZFwTEgE9CEC0vRm6WDGdK9HS6wzBspIV3Y51PpKP6F7yDIbVSoG0C G5cjfaHbm3JpIpRTMbYVcqLMqwcZp3pBvT_iuh9DITyqzcPVFKjaPFRKLC.4SIuHHqKFo9RZTtUB aSVMIKCo_FucID8G_HPIHo5nwo8pYP2iGKfpVOeuo.TJM5DGvtoFeUXGpZvrFarint_RJYYq2i.I Hj0On6SuuFhWXVEfBj1wdrDvTyzX5sotr.IXgcTN1gKob1EsyhmgS2SWoGkVbe.DcrlD1JyCqVtT G5RaAGDlBWzDRVLSJRTGcADYqmxeKj4u2uxsKQbYALKjyTULOR.R_b7GS39o_zbe6o_AORfLSUQq IofD5wI0DoEPDoOBDFAkEx1nboVeahmoSzSd8fKNw2OidO451iPLzSPsXq9kXAKyh_81wWWif11y g8szPZIt1Pif64Q2UU18GoF_5r_hbvYXznEfyuiOKGd9yb0efGdrhBwXay7UHCSmv6X2O.SAKYCG xMGjbb9hR1HSaDEra96SPESRN2CQYWegWttg1XJET6ON6JnycNuutNAwR3E_UoGeCerkzcs_UeDN 3.6C4QLgygD_LjUbIpHcT5j4UAImpx4qCpEeochYS01CNag9E3Gf_yarzfDR8RC2yumw1vHKQjMW P4SQJdxS1leDfuGlwLsBT1RZ3czkr_uSoR8XVI8G2Kos_QPzeHowoPijwFF476vdDMPDqFbvIV_D 2IDpBCpmGoWf5eOcMKlimlKKvp0mdQZNOhj_rCfykx2w7jC5uWsf1ajdTA5HevbsW286tO9_JBZR CC64KsrFSlDxD4PHzOv9Mq3x3ONgaA1IglaMAMdkhAtTF_T8YxJEubX8NyMIOnzRAeRDpSg4e0tR 6YkP9dZywuwFpWqDfhpLyOt2Mq3luDvbzcgROsvtvnDCcl9Nt_3qFw9CGmp.H1Y26SN92c1fwP.E 75u_jTuKrZmXnqzlxM7OAC34u_mEkBdxpjBSqzDK5axuGwwZYaK5Q5mqMCe6gRfXlF5buqcAXBXA NZMGT1AjMg7jCJbdyhfcclzd32gcZSBJ5N8z4FInnPtxQfvaIggtI5CLzAyBS8Wmpmd8GwinlcHw NckkO94iZSAV7rrEXkVga3GcSAKWI_GAtymVFBnWfvHImrLFz2KEE7ACosr8.O0Je9c6KT7g5hLi 90sF47Kn9ewkFsNbXVbQKpKUDEH1Vz5KPQp9WghCV13LkHx.vbQqS6u5ILHszKvXYUF5ljhiEH2w klH6_OF_7hVkRIxmEscgQSZUA.q8O5bYXHLpW42qC9oRB29kXSlfHejKa4VA8fobiFzPmL_YW7wD pNCYLv9AlXAkksgSxPBYtYWE9xRtvCxKM65UKI5B6A47h_8LuRu.F7LPewoHjdtXnmKkUciWHVpZ BzY7dQBK4i9LG4.1NqfOBqoDGvSz00HoIRmi9NySV4OAVeXHKCCAtDuEjwU_mZZyjlSvLhrw.Qnp FZKEaEdbZ1_vYUmXq2gaFuSe1COH5_iYwMIJ.VCdxK8qepwiDi2SpDynfzNMZOIq8.qDlIEg8aWI K5DOF7g9wyPR.DJt.w4aaRelaZ1S87prMLWfHmImkj.LPyvBkNnimnJplmyLOfDnulPQKKkaHaQ4 LjXiS.FVWRVgn0VJ3yDGpZvltIhLAWeYxJb563o_R9SSaUORPKODth3e5FCSnUa7fU.UZwfbheGR uBKE_F.kWGItCUzswTQqQy4QFFfHH.yL2_FYU5coH9Mi01GAUJif6Qyj2wN9FwRdJIOh88s4hQsS b6izLx3b.Zqxh.l3id..Zl_9ZFetbYAiEfFnpherMWxPXow4eW4mXZTTOuWOK2fZKOuVMqr_bwqv eTV2CUZeuDqX2WaQW4UF_MwCr67Bfor5OZJDbJxruEakP7GvKh.8LICgilLa75JeqAM.X09IHat5 YhWdd1CidZ0X5ban6hIzUwdeRO5L9eU4g134Z.aEP3ZI.LdsdaRO..ifYoMFJSSs4mjyPOsLUJMd zqM_xLZXw6QvRwgnEqN2Ken54VFBeKLJQt2wsIL03nsZmymhpCL.Cczbpc4tQjNIGxbjqbyFCu1y mTw4WVDHohhXgADZDw8WQllmS8qqXTxoCExdiJdJPbA0tF3OkkiAdguCX8Oajcgaeegykaz4lsc5 4aX77Y9x_FjT.p4fWi1fHcsjltKcZjAO4d2l_lQ7JyBc52D1eN32S5p5HTE1RLmCt8KIAuw.c.Hw 2y2IWOeRoYu.L0wtE1IW25vbovB9Q86bBTPW3IW.el5oGNkTR0eJ_P5Z7EbfoKwsZ0yn4g5wA_LC dsJ_oaGr2wm01KuxNkfORm8mO_Dlia8I3E.6_lE0QROpiCDFx2A2c1759CO2oyFpiK.4U21xIH8R CrbRfosB2K8Bl6se6I_QFds8i1AGdsYoqoGT.HSWeuv7c5gVFE0aC.Mu7qCQRUnnpP_k2H1CoiEQ pvj3n
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Tue, 3 Nov 2020 22:12:14 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 35702428fa64ed2895eb7118d8a6fc5b;  Tue, 03 Nov 2020 22:12:10 +0000 (UTC)
To: Dick Hardt , Joseph Heenan 
Cc: oauth 
References:  <65B3EF09-25F4-4F3E-96DD-05FA60F044D0@authlete.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <49d1a3ce-619e-abe7-5c4f-7c2fec8c8889@aol.com>
Date: Tue, 3 Nov 2020 17:12:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------CAFF1A199B99CAF066810B61"
Content-Language: en-US
X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
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, 03 Nov 2020 22:12:17 -0000

This is a multi-part message in MIME format.
--------------CAFF1A199B99CAF066810B61
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I sent in some notes but I don't have a link for the recording. I don't 
believe the recordings were being kept much past the end of the 
conference. I'm pretty sure I heard that the recordings would be removed 
after N days (I don't remember what N was stated as:)

Joseph explanation is better than I could have given and matches my 
understanding as well.

Thanks,
George

On 11/3/20 2:13 PM, Dick Hardt wrote:
> Thanks Joseph.
>
> George Fletcher ran a great session on the topic at the last IIW as well.
>
> George: do you have a link?
>
> ᐧ
>
> On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  wrote:
>
>> Hi Dick
>>
>> I didn’t attend the call so don’t know the background of this and the
>> exact situation, but the general problem is mostly where the Authorization
>> Server’s app is *not* installed. In that case Android falls back to much
>> weaker mechanisms that allow other apps to get a look in. App links also
>> aren’t consistently supported across all commonly used android browsers
>> which causes further problems.
>>
>> In general to do app2app oauth redirections securely on Android it’s
>> necessary for both apps to fetch the /.well-known/assetlinks.json for the
>> url they want to redirect to, and verify that the intent the app intends to
>> launch to handle the url is signed using the expected certificate. Web2app
>> flows are trickier, on both iOS and on Android. There were lengthy
>> discussions on at least the Android case at OAuth Security Workshop this
>> year (recordings available).
>>
>> Joseph
>>
>>
>> On 20 Oct 2020, at 00:09, Dick Hardt  wrote:
>>
>> Hey Vittorio
>>
>> (cc'ing OAuth list as this was brought up in the office hours today)
>>
>> https://developer.android.com/training/app-links
>>
>> An app is the default handler and the developer has verified ownership of
>> the HTTPS URL. While a user can override the app being the default handler
>> in the system settings -- I don't see how a malicious app can be the
>> default setting.
>>
>> What am I missing?
>>
>> /Dick
>> ᐧ
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>


--------------CAFF1A199B99CAF066810B61
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I sent in some notes but I
      don't have a link for the recording. I don't believe the
      recordings were being kept much past the end of the conference.
      I'm pretty sure I heard that the recordings would be removed after
      N days (I don't remember what N was stated as:)

      

      Joseph explanation is better than I could have given and matches
      my understanding as well.

      

      Thanks,

      George

    

    
On 11/3/20 2:13 PM, Dick Hardt wrote:

    

    

      
Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan <joseph@authlete.com> wrote:



      

        
Hi Dick

I didn’t attend the call so don’t know the background of this and the
exact situation, but the general problem is mostly where the Authorization
Server’s app is *not* installed. In that case Android falls back to much
weaker mechanisms that allow other apps to get a look in. App links also
aren’t consistently supported across all commonly used android browsers
which causes further problems.

In general to do app2app oauth redirections securely on Android it’s
necessary for both apps to fetch the /.well-known/assetlinks.json for the
url they want to redirect to, and verify that the intent the app intends to
launch to handle the url is signed using the expected certificate. Web2app
flows are trickier, on both iOS and on Android. There were lengthy
discussions on at least the Android case at OAuth Security Workshop this
year (recordings available).

Joseph


On 20 Oct 2020, at 00:09, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://developer.android.com/training/app-links

An app is the default handler and the developer has verified ownership of
the HTTPS URL. While a user can override the app being the default handler
in the system settings -- I don't see how a malicious app can be the
default setting.

What am I missing?

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





      

      

    

    

  


--------------CAFF1A199B99CAF066810B61--


From nobody Wed Nov  4 04:29:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5D43A1091 for ; Wed,  4 Nov 2020 04:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E161EhkkK1xA for ; Wed,  4 Nov 2020 04:29:45 -0800 (PST)
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 9AB163A1086 for ; Wed,  4 Nov 2020 04:29:45 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id d142so2154825wmd.4 for ; Wed, 04 Nov 2020 04:29:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=snzPMuzoJdxf9I280WIaegM1xW0e7QoR3H74Df94978=; b=G4K4Xsz3uVu4ao7knbAALCEGh0JyoyRGRmaXF/D0p045+e2hofDhMtGR/MBcbfc4mA Dli6fdQ2KY+tEpCidrNsIPL9waEAoBGWUN57T/LoP6cwf3GsZQZsZB96NiMHoLcDi1tD GvsBg8QFChUjhmEWHz1l3JoiajmGNki8OJ2yIOXOO/reSccDsd/2tQNsiO8GiMSF6m0x HPh3Yg8FoWNKXH9/+OU3DWP/NpYJj3e12Ev2Sb/2ajM5lsEw9e/vEnp2GBTgenWQWilg Ep1+Ww607SJfqGr1O8k5cfaYzGzRaK2bPs1O+Io+SaZaujnRZy+hcpqiL6Yw6j04JnMI T5aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=snzPMuzoJdxf9I280WIaegM1xW0e7QoR3H74Df94978=; b=pHkEoc3EViFKAj5XevlxfwUTe4muYmX7Z/fbdJO6b9xGDezAWl/aVqPpgLCZtQ9yQ3 RMG7smibXAQ1Mb7TB/rX2Oyqwaer5a3eCrJqIfyxZyvVk8oaIFHnxKJ8TioxJPDCkJzH n0EIzVd9lvPPGPVC1wjheiKznCF2bNbab/4cTTAF6INwQAHPjoxrtKIvbJeLhJMIO9Pn MyvtdCQUnvPJQrF5CJ+oyzl874o3GUHKNSDhE1+dh121L013wbK7/ZQDkciNuF/nFxja H8/5rG+mzHob+lMcrRaISmWwnbPxXwkJ+MGmK2OpUG9OeIGMyAEoOmOhQcZe0VeY1fqk 6GJQ==
X-Gm-Message-State: AOAM531uQEwyDJSuEmWf4O1eUo+aStTfJwYCW9wZkNNypXQsq1WdNEVZ U5ukYKZ2O1R1fKH72+YKti2mUj1lOBDbbMr+
X-Google-Smtp-Source: ABdhPJwBWk85hs8oP6Fk/oO5Jgu6sh+6opxK+QxCsivjazz1YG4kSxIT+fyM7Qc7q4iBTkvMKK0drA==
X-Received: by 2002:a7b:cbc3:: with SMTP id n3mr4422145wmi.68.1604492983883; Wed, 04 Nov 2020 04:29:43 -0800 (PST)
Received: from dhcp121.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id l16sm2259921wrx.5.2020.11.04.04.29.42 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2020 04:29:43 -0800 (PST)
From: Joseph Heenan 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E04E49A-5E37-4E7E-9FFB-28D418646B04"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 4 Nov 2020 12:29:42 +0000
References:  <65B3EF09-25F4-4F3E-96DD-05FA60F044D0@authlete.com>  <49d1a3ce-619e-abe7-5c4f-7c2fec8c8889@aol.com>
To: oauth 
In-Reply-To: <49d1a3ce-619e-abe7-5c4f-7c2fec8c8889@aol.com>
Message-Id: 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
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, 04 Nov 2020 12:29:48 -0000

--Apple-Mail=_0E04E49A-5E37-4E7E-9FFB-28D418646B04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks George :) That=E2=80=99s a shame, I would have liked to listen to =
the recording.

My email below was thinking of the OSW interactive sessions (we had =
about 2 hours of technical discussion on some of the issues with =
implementing app2app in practice particularly on Android), but now =
I=E2=80=99ve looked I think perhaps the recordings of those weren=E2=80=99=
t published. I have been working on a blog post with others that delves =
more into the Android side of things, hopefully we will publish that in =
the not too distant future.

I did an identiverse session too, which although it starts out quite =
similar diverges after about 10 minutes, delving less into the detail of =
security and covering more of the higher level what/why/how: =
https://identiverse.gallery.video/detail/video/6186099813001/

Joseph

> On 3 Nov 2020, at 22:12, George Fletcher  wrote:
>=20
> I sent in some notes but I don't have a link for the recording. I =
don't believe the recordings were being kept much past the end of the =
conference. I'm pretty sure I heard that the recordings would be removed =
after N days (I don't remember what N was stated as:)
>=20
> Joseph explanation is better than I could have given and matches my =
understanding as well.
>=20
> Thanks,
> George
>=20
> On 11/3/20 2:13 PM, Dick Hardt wrote:
>> Thanks Joseph.
>>=20
>> George Fletcher ran a great session on the topic at the last IIW as =
well.
>>=20
>> George: do you have a link?
>>=20
>> =E1=90=A7
>>=20
>> On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  =
 wrote:
>>=20
>>> Hi Dick
>>>=20
>>> I didn=E2=80=99t attend the call so don=E2=80=99t know the =
background of this and the
>>> exact situation, but the general problem is mostly where the =
Authorization
>>> Server=E2=80=99s app is *not* installed. In that case Android falls =
back to much
>>> weaker mechanisms that allow other apps to get a look in. App links =
also
>>> aren=E2=80=99t consistently supported across all commonly used =
android browsers
>>> which causes further problems.
>>>=20
>>> In general to do app2app oauth redirections securely on Android =
it=E2=80=99s
>>> necessary for both apps to fetch the /.well-known/assetlinks.json =
for the
>>> url they want to redirect to, and verify that the intent the app =
intends to
>>> launch to handle the url is signed using the expected certificate. =
Web2app
>>> flows are trickier, on both iOS and on Android. There were lengthy
>>> discussions on at least the Android case at OAuth Security Workshop =
this
>>> year (recordings available).
>>>=20
>>> Joseph
>>>=20
>>>=20
>>> On 20 Oct 2020, at 00:09, Dick Hardt  =
 wrote:
>>>=20
>>> Hey Vittorio
>>>=20
>>> (cc'ing OAuth list as this was brought up in the office hours today)
>>>=20
>>> https://developer.android.com/training/app-links =

>>>=20
>>> An app is the default handler and the developer has verified =
ownership of
>>> the HTTPS URL. While a user can override the app being the default =
handler
>>> in the system settings -- I don't see how a malicious app can be the
>>> default setting.
>>>=20
>>> What am I missing?
>>>=20
>>> /Dick
>>> =E1=90=A7
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>>>=20
>>>=20
>>>=20
>=20


--Apple-Mail=_0E04E49A-5E37-4E7E-9FFB-28D418646B04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks George :) That=E2=80=99s a shame, I would have liked =
to listen to the recording.

My email below was thinking of the OSW interactive sessions =
(we had about 2 hours of technical discussion on some of the issues with =
implementing app2app in practice particularly on Android), but now =
I=E2=80=99ve looked I think perhaps the recordings of those weren=E2=80=99=
t published. I have been working on a blog post with others that delves =
more into the Android side of things, hopefully we will publish that in =
the not too distant future.

I did an identiverse session too, which although it starts =
out quite similar diverges after about 10 minutes, delving less into the =
detail of security and covering more of the higher level =
what/why/how: https://identiverse.gallery.video/detail/video/6186099813001/


On 3 Nov 2020, at 22:12, George Fletcher =
<gffletch@aol.com> wrote:


 =20
    
 =20
  

    I sent in =
some notes but I
      don't have a link for the recording. I don't believe the
      recordings were being kept much past the end of the conference.
      I'm pretty sure I heard that the recordings would be removed after
      N days (I don't remember what N was stated as:)

      

      Joseph explanation is better than I could have given and matches
      my understanding as well.

      

      Thanks,

      George

    

    
On 11/3/20 2:13 PM, Dick Hardt =
wrote:

    

    

      
Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as =
well.

George: do you have a link?

=E1=90=A7

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan <joseph@authlete.com> =
wrote:



      

        
Hi Dick

I didn=E2=80=99t attend the call so don=E2=80=99t know the background of =
this and the
exact situation, but the general problem is mostly where the =
Authorization
Server=E2=80=99s app is *not* installed. In that case Android falls back =
to much
weaker mechanisms that allow other apps to get a look in. App links also
aren=E2=80=99t consistently supported across all commonly used android =
browsers
which causes further problems.

In general to do app2app oauth redirections securely on Android it=E2=80=99=
s
necessary for both apps to fetch the /.well-known/assetlinks.json for =
the
url they want to redirect to, and verify that the intent the app intends =
to
launch to handle the url is signed using the expected certificate. =
Web2app
flows are trickier, on both iOS and on Android. There were lengthy
discussions on at least the Android case at OAuth Security Workshop this
year (recordings available).

Joseph


On 20 Oct 2020, at 00:09, Dick Hardt <dick.hardt@gmail.com> =
wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://develope=
r.android.com/training/app-links

An app is the default handler and the developer has verified ownership =
of
the HTTPS URL. While a user can override the app being the default =
handler
in the system settings -- I don't see how a malicious app can be the
default setting.

What am I missing?

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





      

      

    

    

  




=

--Apple-Mail=_0E04E49A-5E37-4E7E-9FFB-28D418646B04--


From nobody Wed Nov  4 06:55:16 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE553A11CF for ; Wed,  4 Nov 2020 06:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.345
X-Spam-Level: 
X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xik_jPKSZFUs for ; Wed,  4 Nov 2020 06:55:12 -0800 (PST)
Received: from sonic312-23.consmr.mail.ne1.yahoo.com (sonic312-23.consmr.mail.ne1.yahoo.com [66.163.191.204]) (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 055973A0B3E for ; Wed,  4 Nov 2020 06:55:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1604501709; bh=0hBF2OW9nfw61whxNi2keVfiVSS0nVz3y/9FTArUzQs=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=i3rN/XMRC2Sf4h2YO0UrJLaxeFM0pID3yFhc5g/h0tbyPQSVkec2Tcp8fVQs56K0jdAPdeo6gWKE2xoZ25Jn0im3wZea1Xun+RxE0Xasb4c19BMh6eEK5HjjdCeZbiDmMbt3WcAdpSLl5UCc3sHLbbmfUBPp0z2QhaKxJs3+7LUHuWuCjOXs0O27A5rAkiwXmUektBNKA3AhSRaNXus+mUKkXDgeHfvGV8hTpkdKf47qkx/qzDUHsDvyMkufT4lYO9uMnmfxQXCkKWDMURdzAFoFlr6/PL2eMEwk/Xdtb6GUmOH+Kdo6gOe+LDBTr4nVIA3rCL7y1RGyRDo9KjWoVQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1604501709; bh=3VmwtNxACHxcXHp3YUJq/hO2o/tIRQntoduEdwKm9ZH=;  h=Subject:To:From:Date; b=AViuzxOVCRniLRd/rw2x1zwhUI/YreyjXNclb0z0aD/ncpkExIdt1fnJUlR1K/VWCuRmTxxuY0JxtxljZhC4btGYc3ADc/jU/J1NfJjEl/9qXn/MSXYeURAEsuKVrvsNQEQyBFgha3hUj5Zo6TaWbs3bDvsZ4qkaByVfpr5B4KNSKhILG5tIEmkJ5dif/njCnX/grDpuxX+UQ5T9RHoyHAHwEfA/3YoxWPGeB0/Rry1g+G0+f1FNroJ7DAIFyKIQHmWQjvb4AUm//loKViW1Gg8oV7ct0nftj2EArE/Dd+6l29PXuynvWxd3fkcDglABltgrruBvRDo1Hxz1Eql1xA==
X-YMail-OSG: pUpGg.IVM1mSjcYTN4AM.1QngRFTegHvw8VojBCna4RcddmToDQeX8duiboTsa5 NxmLoXWGBmOx5uIVqdDojy7hqjoKHbJlojXkY7N_NdDZwOlaJ5dPxAN3.0oGss64QH_TLTcqDTHN 9YZcczSKcsSlPyCgHeXFasAjUyET89iREVoNvYg5x6V6iWm80N4xoMkMDILgmKa9c4ERVehtLDe0 NhaL2QPRoSzyzF9qKP4oisn9BoPXXOyvlJrymwcRcrvQS0hykOu7Iv5A4oSVebCH8h6xaw9TIMYH X42iT7UxoXjzD5HtlJ8jbwKZNB8wrVu.Xu0BjhEvePGDaaJwMUtZtZEbe_HaJSl3tCw5mSJWv15t WgX6SG231ISacWJv.o6e1DYPrksorKTAcV0kplqpSY9e9MWRu9vVUD8BKoX2W_kh8ezocijV5XRW fEgDriMIw4yQtHdWeT0B5M3ynCcPr6LnjT_2eZsYNvAgzgZtbMGM5JJBEH9xnSZtiGhAMwp8UttY H0lJD9b.vg4L8Is4IKmUsZZyqw9gDh3T491q4f4eZnJH_9GaNNeXH3o0t713IlxUGquhtIZ9VjJw KUaxUQ.J0grmH8Tkva2yYgODJBnFh0YFaBftniAngIKxeWWYKt6Vb1Gzr2QzWHXxNkMMt0QS7Nx8 XW8VaLjHkiFPtsaUfhVlbPE5JKvFqKmmOzzn_twSJn3cnGuVglgCw6s.XNYpMqQIFDLNubQPd.mg GYA2.njtkHjGK04vwDfkVyEY2CNu1bsWhCwePDSBb46nfFDw6olwS70owiY3yC3KMdJq4NRcbk2H dXFs3eijmDOT6eHadTak5CKlz3ih.rR7sQnTZh1ak5O._yBGC.k6ObsZUCS4q2VDk6VioJRBFHdO LIPvDWMfwRfxXj_i4CtEttj7yK0NyYG.YmH55yTTS2venDY7sMjlBDwxgbwdXcQzua0VrjtQctXr _6cwNm6w3U07CcJ3UdpXhATYpGAwSdTaZp6MDe1eBIKJnOHSYbDebNmamDde3NQmaNTCLGmkPmA8 Jl7wPkXWPwJ9e7caeNkjt9jZnDYvgG58DFXXoEC7RL2D3jDLJI9xZpydyYNQSnkPayjXjFAy24qC s1a3iynhdWyslvZqhJlYNxZIPFa2zKYw4_jKdncN7_kQnPYb547glJ8nw762waDCip9XMI15NWOn OLF7YsvZsCqRP0y32w94itx617xzARi.eBl1GwMCrReZbeIAgD76.PpQdmydkqDBYSNIzKQPja0Q biOfJqch.7lfAXpqwfJQudrmgMJiDRyxMfuaJMDxtDVBN__eG_kkGOEg8dl5btLAIdgTEwIj.aFa rforPDBSTrIXwNEI20sF0SLOP7VtUvndUMsoUvhOqODSTXCzsYUOFednh.Ip6hbvwEvaPlX2p_SH RNqpLLIH2Y4XnmtSPMWRrMCVRfm3Ab6fF3GARo5ZjQW48cQcZo70CpDJ9PJEXu5NCFfuQkGstQBn PqV_1j3J_4zVNBA0VExmfGfAcnSZxw0EY3xeUFTtxI13wnHSXOznC0Y.2y5APAf87m5.NNwIJ4X5 I99x1SNZgemz0ks4LVYgcvXu7uY1Cmrkqhh5xCOKlCtjeZlfzvZtmX4uxl9RDUwsfzXmbgl.lcZV Vb8r2bHijejO1zwojWUra3Gdqd65eLEjYdfOzGngiv8rMsq25p31805YDjfl5NSR229Xl6VyTF1C oaQoZcSvqEM8T3ZX2VZ3f153XMyegG04qOoZdzX9Ngat1QdCy.c2yXFAwosgSWGztqciQ6.k4V70 KCKm4rN50DWld3asqljbmfu6l5jk95hWXGX2Kz5HlAXAi4r2rEfjzrgpDlwDj665B1fzPf9I0wQl gK8XoapsEhUvS6OdnExiPcy1LM_nEIFyRHkhyDkU388o.yvzI_yo8uj.SwxAQkEX9NAo6TE.OyRl c3tN3NV6tcYvXBRnAzN8937mF1QoAkY9vIx0XfGI5eGbrI6AmdAUyN8jF3SxpppgCFOZLsRO9oxN cZ_covW_ja3P44.0Ol_NiMHvwLbLkbKmp48z7t4KleZthaA9D6rlplkzCGZsETxf1bEAQgBkSao8 xw.cI32ezgMBnx0XyCJJ_6n2fsRHFZPcNaAnOppNjyVjfnBM5EPwNCvSnddJpMrBsmZ.hGT2ANEn KF6klBuCmmEOJ56cs1Bp5Sif2zq9h5BvK76wm4i1CyEQ4PHM0W2Ctn4nwTr.s0TEyXCSqMBWZp15 O.nR4FzYGL4BDM7wBLI4GaBRhr5QpLLGb7noz8z2VhFvAJ1BZ0Fk0gPUn_5cEVxKrUWaniVeeMU1 8zj8EMNmVkX1DpWqpQNplI7CM3J.beplpOVqDKxY6NvhWTb3mnQ7nYUjKPN.qbR7sBHKwm8uh3ks YCjdb5mSGmaCYusnR..yDx06LQ0mNYipCLqb7.JeCiJ6N0VrF.mwxcYKY31WeXio1rJhTV3NdzDE 19WUgjBrUBspoGu6h8.0Sjk3Q7znwdWhg2rF2DMI_NVoF8CfbGskLhfOjeZmQKnGj0.b4veBHvdH kOK9KHyxs7bfGfgeUv060e.SgyDgGOI9KLBnLtjizZstNSUMXuiDQ9g--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Wed, 4 Nov 2020 14:55:09 +0000
Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6469a37451147b72d4890447cdaebef9;  Wed, 04 Nov 2020 14:45:01 +0000 (UTC)
To: Joseph Heenan , oauth 
References:  <65B3EF09-25F4-4F3E-96DD-05FA60F044D0@authlete.com>  <49d1a3ce-619e-abe7-5c4f-7c2fec8c8889@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Wed, 4 Nov 2020 09:44:59 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------69303C135213BECB591B3F41"
Content-Language: en-US
X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: 
Subject: Re: [OAUTH-WG] Android App Links (AKA Universal Links)
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, 04 Nov 2020 14:55:14 -0000

This is a multi-part message in MIME format.
--------------69303C135213BECB591B3F41
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The focus of the IIW session was "Mobile App Impersonation" and what can 
be done about it. Obviously moving to Universal Links (iOS) and App 
Links (Android) is an important first step but not sufficient on Android 
as you point out. Other areas of exploration are around dynamic client 
registration (forces the app impersonator to call a specific endpoint 
which can increase the ability to detect the impersonation). Also 
possibly combining device attestation and app attestation into the mix 
could provide a mechanism to ensure only the intended apps can get 
access. However, this is a fair amount of work for developers to prevent 
app impersonation. There is a big question regarding ROI of closing this 
attack vector:)

I'm especially interested in whether anyone has even looked at their 
logs and tried to detect app impersonation of their public clients. Feel 
free to message me privately if you don't want to share with the group :)

Thanks,
George

On 11/4/20 7:29 AM, Joseph Heenan wrote:
> Thanks George :) That’s a shame, I would have liked to listen to the recording.
>
> My email below was thinking of the OSW interactive sessions (we had about 2 hours of technical discussion on some of the issues with implementing app2app in practice particularly on Android), but now I’ve looked I think perhaps the recordings of those weren’t published. I have been working on a blog post with others that delves more into the Android side of things, hopefully we will publish that in the not too distant future.
>
> I did an identiverse session too, which although it starts out quite similar diverges after about 10 minutes, delving less into the detail of security and covering more of the higher level what/why/how: https://identiverse.gallery.video/detail/video/6186099813001/
>
> Joseph
>
>> On 3 Nov 2020, at 22:12, George Fletcher  wrote:
>>
>> I sent in some notes but I don't have a link for the recording. I don't believe the recordings were being kept much past the end of the conference. I'm pretty sure I heard that the recordings would be removed after N days (I don't remember what N was stated as:)
>>
>> Joseph explanation is better than I could have given and matches my understanding as well.
>>
>> Thanks,
>> George
>>
>> On 11/3/20 2:13 PM, Dick Hardt wrote:
>>> Thanks Joseph.
>>>
>>> George Fletcher ran a great session on the topic at the last IIW as well.
>>>
>>> George: do you have a link?
>>>
>>> ᐧ
>>>
>>> On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan   wrote:
>>>
>>>> Hi Dick
>>>>
>>>> I didn’t attend the call so don’t know the background of this and the
>>>> exact situation, but the general problem is mostly where the Authorization
>>>> Server’s app is *not* installed. In that case Android falls back to much
>>>> weaker mechanisms that allow other apps to get a look in. App links also
>>>> aren’t consistently supported across all commonly used android browsers
>>>> which causes further problems.
>>>>
>>>> In general to do app2app oauth redirections securely on Android it’s
>>>> necessary for both apps to fetch the /.well-known/assetlinks.json for the
>>>> url they want to redirect to, and verify that the intent the app intends to
>>>> launch to handle the url is signed using the expected certificate. Web2app
>>>> flows are trickier, on both iOS and on Android. There were lengthy
>>>> discussions on at least the Android case at OAuth Security Workshop this
>>>> year (recordings available).
>>>>
>>>> Joseph
>>>>
>>>>
>>>> On 20 Oct 2020, at 00:09, Dick Hardt   wrote:
>>>>
>>>> Hey Vittorio
>>>>
>>>> (cc'ing OAuth list as this was brought up in the office hours today)
>>>>
>>>> https://developer.android.com/training/app-links 
>>>>
>>>> An app is the default handler and the developer has verified ownership of
>>>> the HTTPS URL. While a user can override the app being the default handler
>>>> in the system settings -- I don't see how a malicious app can be the
>>>> default setting.
>>>>
>>>> What am I missing?
>>>>
>>>> /Dick
>>>> ᐧ
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth 
>>>>
>>>>
>>>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------69303C135213BECB591B3F41
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    The focus of the IIW
      session was "Mobile App Impersonation" and what can be done about
      it. Obviously moving to Universal Links (iOS) and App Links
      (Android) is an important first step but not sufficient on Android
      as you point out. Other areas of exploration are around dynamic
      client registration (forces the app impersonator to call a
      specific endpoint which can increase the ability to detect the
      impersonation). Also possibly combining device attestation and app
      attestation into the mix could provide a mechanism to ensure only
      the intended apps can get access. However, this is a fair amount
      of work for developers to prevent app impersonation. There is a
      big question regarding ROI of closing this attack vector:)

      

      I'm especially interested in whether anyone has even looked at
      their logs and tried to detect app impersonation of their public
      clients. Feel free to message me privately if you don't want to
      share with the group :)

      

      Thanks,

      George

    

    
On 11/4/20 7:29 AM, Joseph Heenan
      wrote:

    

    

      
Thanks George :) That’s a shame, I would have liked to listen to the recording.

My email below was thinking of the OSW interactive sessions (we had about 2 hours of technical discussion on some of the issues with implementing app2app in practice particularly on Android), but now I’ve looked I think perhaps the recordings of those weren’t published. I have been working on a blog post with others that delves more into the Android side of things, hopefully we will publish that in the not too distant future.

I did an identiverse session too, which although it starts out quite similar diverges after about 10 minutes, delving less into the detail of security and covering more of the higher level what/why/how: https://identiverse.gallery.video/detail/video/6186099813001/

Joseph



      

        
On 3 Nov 2020, at 22:12, George Fletcher <gffletch@aol.com> wrote:

I sent in some notes but I don't have a link for the recording. I don't believe the recordings were being kept much past the end of the conference. I'm pretty sure I heard that the recordings would be removed after N days (I don't remember what N was stated as:)

Joseph explanation is better than I could have given and matches my understanding as well.

Thanks,
George

On 11/3/20 2:13 PM, Dick Hardt wrote:


        

          
Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan <joseph@authlete.com> <mailto:joseph@authlete.com> wrote:



          

            
Hi Dick

I didn’t attend the call so don’t know the background of this and the
exact situation, but the general problem is mostly where the Authorization
Server’s app is *not* installed. In that case Android falls back to much
weaker mechanisms that allow other apps to get a look in. App links also
aren’t consistently supported across all commonly used android browsers
which causes further problems.

In general to do app2app oauth redirections securely on Android it’s
necessary for both apps to fetch the /.well-known/assetlinks.json for the
url they want to redirect to, and verify that the intent the app intends to
launch to handle the url is signed using the expected certificate. Web2app
flows are trickier, on both iOS and on Android. There were lengthy
discussions on at least the Android case at OAuth Security Workshop this
year (recordings available).

Joseph


On 20 Oct 2020, at 00:09, Dick Hardt <dick.hardt@gmail.com> <mailto:dick.hardt@gmail.com> wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://developer.android.com/training/app-links <https://developer.android.com/training/app-links>

An app is the default handler and the developer has verified ownership of
the HTTPS URL. While a user can override the app being the default handler
in the system settings -- I don't see how a malicious app can be the
default setting.

What am I missing?

/Dick
ᐧ
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>





          

        

        

      

      



      

      

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


    

    

  


--------------69303C135213BECB591B3F41--


From nobody Wed Nov  4 18:33:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA693A15FD for ; Wed,  4 Nov 2020 18:33:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ArY8fVAfoDE for ; Wed,  4 Nov 2020 18:33:36 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7053A15FA for ; Wed,  4 Nov 2020 18:33:36 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id t13so586282ljk.12 for ; Wed, 04 Nov 2020 18:33:36 -0800 (PST)
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=gOlhj0fE3otscKRuRfx1VYEJfVtTDdBaNriOgNy3yTk=; b=k0iTky8venGD6jN8jjy+jDlPCT6m/xWKlijr2VQz6OzW5qJpZfETGdtTv6274sI2yx JiIjtAzSfa3ePufSW9ud83XWfQaufjw0D3lyQeOrpaU4IiIGgWsm8ci4qzTogs2rSvwq NACXmFE4s1RdBMDN11Kx5ak/4rGT8GvtEFBaSoisZfYEowZ1/T9AuRm0WVOM6y7tnyeH sa8TxlbelANvQYp70xjF2+yToyPnllddqKAp7kcbMljJYtncT0167tcx0pIPX6B1J0m8 4B+Gha66cumfqsCgvs1x72tvSYtHtDezDHxUuW6kPHAYfGfoWfCHxQ+KJnbtI8c+BX+t 4Czg==
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=gOlhj0fE3otscKRuRfx1VYEJfVtTDdBaNriOgNy3yTk=; b=jUsi45x2d9CZAPkSED08kWv1olL22MdmAMH7WguhHO+npPkydDR8CxtrSFFjoE4P3Q eb+kw1gIPRSvfUx1AVPy+ufSHAkXSJ9RSPxli/TMbX7/3ANg7EaIWliokMDk+AwYGV1Y WTOsAdxK9RZhvpwx6YcdW5cDHE3IBqJWSXPfWCTK4g+Xka7x7XTN3Y1rXAq1f2v3hAcc as1spIU0l41eBot8BSRJA4KfXrOM61loKDskusn7PrUlDtelhSU6sYQZznyn0TeoFYiz hffMS6vnl9758b/zQFhP9sluPmjvvdx1T0b7stRGomfjLku6cryPhsWnbaiz8uNBXI27 jvYQ==
X-Gm-Message-State: AOAM53354vbTixfHqO7q0x3AkPqJz7bpQ5IGWJS4AV8O3iUatfXF0iNZ 22biStiiZCRVt5JU+vqsDdExc1JtJHH2QIEqwezcI53jydcUNw==
X-Google-Smtp-Source: ABdhPJynGJaZt+2MBTGQbv5h/Ft0b7o9vwMZTQdXo06B6WisTz2Amgy+iZaaunYwq2myCw2fVDooV5WMmxm5+SqWJeQ=
X-Received: by 2002:a2e:808a:: with SMTP id i10mr45178ljg.427.1604543613913; Wed, 04 Nov 2020 18:33:33 -0800 (PST)
MIME-Version: 1.0
From: Sascha Preibisch 
Date: Wed, 4 Nov 2020 18:33:23 -0800
Message-ID: 
To: IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000224ceb05b352ecf7"
Archived-At: 
Subject: [OAUTH-WG] oauth par - authorize request with client_id
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, 05 Nov 2020 02:33:38 -0000

--000000000000224ceb05b352ecf7
Content-Type: text/plain; charset="UTF-8"

Hi all!

A while ago I implemented draft 00 of this spec:
- https://tools.ietf.org/html/draft-ietf-oauth-par-04

Now, in draft 04, I see that a request to the /authorize endpoint is
defined with client_id and request_uri. The client_id was added since draft
00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).

I am not sure if 'client_id' is now required, that's all.

Thanks for clarification,

regards,
Sascha

--000000000000224ceb05b352ecf7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all!=


A while ago I implemented draft 00 of this spec:
<=
div>- https=
://tools.ietf.org/html/draft-ietf-oauth-par-04

=

Now, in draft 04, I see that a request to the /authorize endpoint is d=
efined with client_id and request_uri. The client_id was added since draft =
00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).=


I am not sure if 'client_id' is now requi=
red, that's all.

Thanks for clarification,

regards,
Sascha


--000000000000224ceb05b352ecf7--


From nobody Wed Nov  4 19:15:30 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190D43A1661 for ; Wed,  4 Nov 2020 19:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j364zw6lN_kX for ; Wed,  4 Nov 2020 19:15:27 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310923A165D for ; Wed,  4 Nov 2020 19:15:27 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id h22so141721wmb.0 for ; Wed, 04 Nov 2020 19:15:26 -0800 (PST)
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=G5AtZszUI9a/YU8/MVAEgtulToeqELC3z5V6CAYS+sA=; b=eR3O3JVeIttOjwlGMIynkE1J6OV9N17Xvnpy3ZCBeSK7Hm5zQ9l7ayKOOCt4/MUN5i zbV3Q98mZc8P1rc4bYbWAib4j8a0eODehwaOvAg6qo9axrVDZVFARrE8fe54E9Fo8Nmh aUxfGVsSAgXe+2+LysjlTEB4Cj2KtWh66X5DtYk/29PW7CVgQt4ceWQZa/L8kqAum6Xy gmT7fnFD+2KLZJMJCNZyj49fICBXBN5H9g+/PFYMFxiKQ8MraGpjqdzhP10GkwNPGVPp k2SUGN0cugX2ZuFHDFbvEQH5YSBb8rw7EQCgBd3RoL60nfgLWsBCx2+ik0dC6lgyGD9e vCLg==
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=G5AtZszUI9a/YU8/MVAEgtulToeqELC3z5V6CAYS+sA=; b=uBNbuzCPLoUFKm8lPw/m9yG49JaxraMrNgbEQnCKiyY9Waye7jasVgX4/IwFk36k7y Zc7xbAuFL78pCBs0VWzB+jSRv7iy9fXd7b7ZQYDHAmYO9qPnl3CSXFCd0fOekILJzUrU n9HgmrI9U3C0tZuEGa7Aq/JcpYW2lPw4RMRLLdY+Gpqxn3/EEr8/M8TNaJcYMLN0d0yT iP2ToGYvL0Pgq1GWq8xRy+4Qbom60pg5mC5qvt6b+S37FJP5gYDZMsSohBQ5PMCcm3Z8 FEfboO94ErJUZvmN5ymy2bfMXs0MMLqtgg8RzzheZWVR0CYRd8OMvJi+grTWQPKqMoFw 8KNw==
X-Gm-Message-State: AOAM530fLnm6O+o3OALD6ROI+ctV2mSXvTjR3SvKAicMY8EH++XuaySV 6cFAz372c+SAYxKWxxF8mA5OvRkshQ7Yqa8bifFuRA==
X-Google-Smtp-Source: ABdhPJxVz0+vIRXmItvL6yK3px64Q6KePShQgDv/sqhCM8OtzzZbEnB3QcFnE6C/JF87atScvWd7sIF8QoQM5nsRGkI=
X-Received: by 2002:a1c:9910:: with SMTP id b16mr240410wme.64.1604546125148; Wed, 04 Nov 2020 19:15:25 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Takahiko Kawasaki 
Date: Thu, 5 Nov 2020 12:15:14 +0900
Message-ID: 
To: Sascha Preibisch 
Cc: IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000d0c6c405b35381ae"
Archived-At: 
Subject: Re: [OAUTH-WG] oauth par - authorize request with client_id
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, 05 Nov 2020 03:15:29 -0000

--000000000000d0c6c405b35381ae
Content-Type: text/plain; charset="UTF-8"

Hi Sascha,

The change you found in the draft 04 is the change made to the JAR (JWT
Secured Authorization Request). Now, "client_id" is mandatory. I summarized
technical details about JAR in the article below. It describes the reasons
for the necessity of "client_id". PAR is mentioned there, too.

Implementer's note about JAR (JWT Secured Authorization Request)
https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe

Best Regards,
Taka

On Thu, Nov 5, 2020 at 11:33 AM Sascha Preibisch 
wrote:

> Hi all!
>
> A while ago I implemented draft 00 of this spec:
> - https://tools.ietf.org/html/draft-ietf-oauth-par-04
>
> Now, in draft 04, I see that a request to the /authorize endpoint is
> defined with client_id and request_uri. The client_id was added since draft
> 00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).
>
> I am not sure if 'client_id' is now required, that's all.
>
> Thanks for clarification,
>
> regards,
> Sascha
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000d0c6c405b35381ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Sascha,

The change you found in the draft 04 is =
the change made to the JAR (JWT Secured Authorization Request). Now, "=
client_id" is mandatory. I summarized technical details about JAR in t=
he article below. It describes the reasons for the necessity of "clien=
t_id". PAR is mentioned there, too.

Implementer's note abou=
t JAR (JWT Secured Authorization Request)
https://darutk.medium.com/=
implementers-note-about-jar-fff4cbd158fe

Best Regards,
Taka

On Thu, Nov 5, 2020 at 11:33 AM Sascha Preibisch <saschapreibisch@gmail.com> wrote:
=

Hi all!

A whi=
le ago I implemented draft 00 of this spec:

No=
w, in draft 04, I see that a request to the /authorize endpoint is defined =
with client_id and request_uri. The client_id was added since draft 00 (see=
: https://tools.ietf.org/html/draft-ietf-oauth-par-04#sect=
ion-4).

I am not sure if 'client_id' i=
s now required, that's all.

Thanks for clarifi=
cation,

regards,
Sascha

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000d0c6c405b35381ae--


From alexkalps@gmail.com  Wed Nov  4 16:22:31 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5893A11A7 for ; Wed,  4 Nov 2020 16:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.062
X-Spam-Level: 
X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, WEIRD_PORT=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 5alOzuucYuBS for ; Wed,  4 Nov 2020 16:22:30 -0800 (PST)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 41DD73A11A8 for ; Wed,  4 Nov 2020 16:22:30 -0800 (PST)
Received: by mail-pf1-x441.google.com with SMTP id 13so71209pfy.4 for ; Wed, 04 Nov 2020 16:22:30 -0800 (PST)
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=8kg1aAI2H3MNJ6xFgfTGx42agPNG4kiGvESJnd/jytI=; b=pP1jJueO4CrJTGjY0qVayksy1iQKZnyvPZV6kdlSCbMNSwGY8jShAYk89U01TXwkix kDK5N4bUB2VTFFTQ6HS9WJHojI3y1IynjUXqcb1gk6lB8MjIfPK3x0ykvk2uqBD383jY huHPbjDD9J523n6BD3+Y5EDA1iOwxs3Rx90CTaem6IHyL+maH+rF8bGjjxZ+4yLBdcyR G16MwUG3skfuh7mRfjwxMrhQI+ShlSb3XVuzM73UOz/VtagoT4UXaptOngzHcT3pddm3 r5awJK6gYpbYppco49pzgDnPXiEJXKLCQMpcT7obMpkdlrZhYKIQcJDY777RL3bZy5Oo tC4Q==
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=8kg1aAI2H3MNJ6xFgfTGx42agPNG4kiGvESJnd/jytI=; b=b9Rx6B6XZeuTYFaAb0sy0FMqniuVkA3IUPq8HR9eIrmoHP1XE969b8OpMGZmss6hH8 CfS5RmxFwLKarwKnUw1WoVL7U+xOXIUJF8f6pvl4qJuPcsqfhE3SKXjwjFuvQHKkBgmO N2x6rkjUVyyRCRwssEeu+2uHSp40fAv999kTLBXTawjh5I6ClksqQwluqjId35Xdh9A/ G8hJCfOfkmz0/XE7H5R9YgZxa9TRhzWRgBJIbBUX89fXkxzefXJ61JDBWr6THXLktSXI bi/3avfl3M2fWUWHc++n9N0JjpdT3JRXzQnelOh6JlJexVvYrZbvv8osu4EH64fFsDA4 R8Ew==
X-Gm-Message-State: AOAM533aMHfYFXQV32z0afQVHkaCaiNwVO+8eaOEVD8PNjJSMYDp2Nym RYOn3mFbX72mMJXIxbrmPcrQes/SL93vt01QQWs0QXdfFVRra1Fp
X-Google-Smtp-Source: ABdhPJwxhlwPuES9kUh+yS6czhynjAz3YHAHX+Ypzf9yOv43jv6VYDg1enHAlE5n5MwUpS9OBZB8qZOXYCi4BNDPINU=
X-Received: by 2002:a62:8449:0:b029:18b:16d2:9ea0 with SMTP id k70-20020a6284490000b029018b16d29ea0mr17309pfd.26.1604535749388; Wed, 04 Nov 2020 16:22:29 -0800 (PST)
MIME-Version: 1.0
From: Alex Kalp 
Date: Wed, 4 Nov 2020 16:23:19 -0800
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005f2b3b05b3511717"
Archived-At: 
Subject: [OAUTH-WG] The response from the Google 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: Thu, 05 Nov 2020 04:33:44 -0000

--0000000000005f2b3b05b3511717
Content-Type: text/plain; charset="UTF-8"

Hi All,

While trying out the OAuth 2.0 authorization code grant type with Google, I
got the following response to my registered redirect_uri.

https://localhost:9000/app_uri?*state*=caf324471khs872&%20*code*
=4/5wFzvDar86R-AJWCIE&%20*scope*=profile%20openid%20
https://www.googleapis.com/auth/userinfo.profile&%20*authuser*=0&%20*prompt*
=consent

As per the RFC6749 section 4.1.2, the authorization response from the
authorization endpoint only includes code and state.

Appreciate if you can share any insights on why Google adds scope, authuser
and prompt parameters to the response, which are not in the OAuth 2.0 RFC -
and do we consider those additional parameters as a violation of the
RFC6749?

Thanks!
-Alex

--0000000000005f2b3b05b3511717
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

While trying out the=
 OAuth 2.0 authorization code grant type with Google, I got the following r=
esponse to my registered redirect_uri.

https://localhost:9000/app_uri?state=
=3Dcaf324471khs872&%20code=3D4/5wFzvDar86R-AJWCIE&%20=
scope=3Dprofile%20openid%20https://www.googleapis.com/auth/userinfo.profile&a=
mp;%20authuser=3D0&%20prompt=3Dconsent

=

As per the RFC6749 section 4.1.2, the authorization response fro=
m the authorization endpoint only includes code and state.

Appreciate if you can share any insights on why Google adds scope,=
 authuser and prompt parameters to the response, which are not in the OAuth=
 2.0 RFC - and do we consider those additional parameters as a violation of=
 the  RFC6749?

Thanks!
-Alex




--0000000000005f2b3b05b3511717--


From nobody Wed Nov  4 20:49:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727953A16A2 for ; Wed,  4 Nov 2020 20:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuxEWa87-Sw1 for ; Wed,  4 Nov 2020 20:49:22 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B253A166A for ; Wed,  4 Nov 2020 20:49:22 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id s30so379931lfc.4 for ; Wed, 04 Nov 2020 20:49:22 -0800 (PST)
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=qnUkeCVsmY7iBRtMzRhG5Z2WMRe5Dl7CRw6j1wHXEz0=; b=NZ4kPkT3VnPJ1u+PPW+yTfpzVIgwJuvrCwNbt37/LrNbKPA3RSNEGdyjAro5fLFZ/4 AOxVE9qAKL6G4Rx6RHtuPTDUDYj2HxvXEVTiWggh/rsHHmIdDTiJ0fB09izIG3bxol+I Ib0uQMilwl2EJEVYFK5xtURRWQPEJ3yT+YCcRmUYBa77G8wUZg5oMFaZ7EhSQ9fXxTDZ tnHZP0iZHe8YIzfAIiU2hxY9+1+gFUfM1h3rhfsGs35PaJznmlooKQcU5roQOq0VvNJC 8KSG5UX+g5Em7g7cFUOY3GauyHl6kToBgU67ChMwrP1e2GuDU+MIs/clx1tdekBgcCS8 N3qw==
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=qnUkeCVsmY7iBRtMzRhG5Z2WMRe5Dl7CRw6j1wHXEz0=; b=rttgg38Lrks0NKFI59F/WHflTPzOMQkLt3BOJSzj46xMy4Pvif51yYtvXRLjzbo6pk W2MACFj+tUchEllIFHE9zYZYRjk3dS2Bp0lyHBUG1P8XFaCn4GtcVuO6edfJfWxoj0lV wQ/PIGYsfYt3JY+5+xMDcQC5JXjq3dXeXyjWK2fGiGbA30WZ/qDKLqbqgREHfZ4mtx82 auawfLALkZUUazEr5C95bB23ttkXbaF2TlX4l0latfJS61HE9gHFxhq6GlkD296RcZLp b8z2ZEVWz8dtmFz0NlUr2TVw4P9qfk4Kdw3xnW7x6+43Ty3uUztsWqpiuN8+xVRlMwol BY5A==
X-Gm-Message-State: AOAM530sD9XdAowk+DskW7zfZB00p4qpKcV+A7Ha+CjlyzOrDAHFGyoY 3h0kBdeYONnWpcsSwBHKS+PuOoUXK8EIh8Pvxn4=
X-Google-Smtp-Source: ABdhPJzbc5WW5owUAASo42uv1Blflx0ymTLX7mC32CM6bcN2P0PoIB8bSf3tZfWFLj4ytY1o+sgO+zdGXY6Gbs3b45A=
X-Received: by 2002:ac2:5ca5:: with SMTP id e5mr186639lfq.497.1604551760371; Wed, 04 Nov 2020 20:49:20 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Sascha Preibisch 
Date: Wed, 4 Nov 2020 20:49:10 -0800
Message-ID: 
To: Takahiko Kawasaki 
Cc: IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000b3650505b354d1a5"
Archived-At: 
Subject: Re: [OAUTH-WG] oauth par - authorize request with client_id
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, 05 Nov 2020 04:49:24 -0000

--000000000000b3650505b354d1a5
Content-Type: text/plain; charset="UTF-8"

Thank you, Taka!

I will check out the referenced document.

Regards,
Sascha

On Wed., Nov. 4, 2020, 19:15 Takahiko Kawasaki,  wrote:

> Hi Sascha,
>
> The change you found in the draft 04 is the change made to the JAR (JWT
> Secured Authorization Request). Now, "client_id" is mandatory. I summarized
> technical details about JAR in the article below. It describes the reasons
> for the necessity of "client_id". PAR is mentioned there, too.
>
> Implementer's note about JAR (JWT Secured Authorization Request)
> https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe
>
> Best Regards,
> Taka
>
> On Thu, Nov 5, 2020 at 11:33 AM Sascha Preibisch <
> saschapreibisch@gmail.com> wrote:
>
>> Hi all!
>>
>> A while ago I implemented draft 00 of this spec:
>> - https://tools.ietf.org/html/draft-ietf-oauth-par-04
>>
>> Now, in draft 04, I see that a request to the /authorize endpoint is
>> defined with client_id and request_uri. The client_id was added since draft
>> 00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).
>>
>> I am not sure if 'client_id' is now required, that's all.
>>
>> Thanks for clarification,
>>
>> regards,
>> Sascha
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--000000000000b3650505b354d1a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you, Taka!

I will check out the referenced document.

Regards,
Sascha
On Wed., Nov. 4, 2020, 19:15 Takahiko Kawasaki, <taka@authlete.com> wrote:
Hi Sascha,

The change you found=
 in the draft 04 is the change made to the JAR (JWT Secured Authorization R=
equest). Now, "client_id" is mandatory. I summarized technical de=
tails about JAR in the article below. It describes the reasons for the nece=
ssity of "client_id". PAR is mentioned there, too.

Impleme=
nter's note about JAR (JWT Secured Authorization Request)
https://darutk.medium.com/implementers-note-=
about-jar-fff4cbd158fe

Best Regards,
Taka

On Thu, Nov 5, 2=
020 at 11:33 AM Sascha Preibisch <saschapreibisch@gmail.com&g=
t; wrote:
Hi all!
<=
br>
A while ago I implemented draft 00 of this spec:

Now, in draft 04, I see that a request =
to the /authorize endpoint is defined with client_id and request_uri. The c=
lient_id was added since draft 00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).
<=
div>
I am not sure if 'client_id' is now required, th=
at's all.

Thanks for clarification,
=

regards,
Sascha

_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






--000000000000b3650505b354d1a5--


From nobody Wed Nov  4 21:00:18 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB173A13FC for ; Wed,  4 Nov 2020 21:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level: 
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 c3Y120LPqP22 for ; Wed,  4 Nov 2020 21:00:14 -0800 (PST)
Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D296F3A13C6 for ; Wed,  4 Nov 2020 21:00:14 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id aXNckSBJJeeHMaXNdk3hqs; Wed, 04 Nov 2020 22:00:14 -0700
X-CMAE-Analysis: v=2.4 cv=DvKTREz+ c=1 sm=1 tr=0 ts=5fa386de a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=3g80flMcAAAA:8 a=zHeJ4rh2_G29r4bs79cA:9 a=QEXdDO2ut3YA:10 a=gUXmQ8eWAGYA:10 a=pGLkceISAAAA:8 a=Ra6_U-IGWkj3or_LB4wA:9 a=s7g4-kuPmEnZGRM9:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Alex Kalp , oauth@ietf.org
References: 
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com>
Date: Thu, 5 Nov 2020 07:00:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020602020201020507010002"
X-CMAE-Envelope: MS4xfMWv+XV3547FaFaUUzZmtc0Uuq6DEzqYdqOOo8ShOEHzW2va5AMjCmKe54RdW575vHce2DXJP5lD5xdJ1Cn16WDf/omzJ2Zf7tPUaXExDOUHREKIFyfD QRlXc5K2dKz573azZhGthuSUOe1UvHG5GEiuaXDRu+rR1gs6uUBd2Awaw+6ecMz6iQyuGVMQW0KIE65d58kpWXqj7BgRJbYEuI0vhzvj1Jm8ZfAFD/0nx24T
Archived-At: 
Subject: Re: [OAUTH-WG] The response from the Google 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: Thu, 05 Nov 2020 05:00:16 -0000

This is a cryptographically signed message in MIME format.

--------------ms020602020201020507010002
Content-Type: multipart/alternative;
 boundary="------------D8373E19AE136D4799CBB7EB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------D8373E19AE136D4799CBB7EB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Alex,

OAuth 2.0 doesn't forbid other params to be present in the response. If
you find such - ignore them.

https://tools.ietf.org/html/rfc6749#section-4.1.2

> The client MUST ignore unrecognized response parameters.
I have a theory why those 3 extra params (scope, authuser, prompt) are
there, but I don't think it would matter in your case.

Vladimir

On 05/11/2020 02:23, Alex Kalp wrote:
> Hi All,
>
> While trying out the OAuth 2.0 authorization code grant type with
> Google, I got the following response to my registered redirect_uri.
>
> https://localhost:9000/app_uri?*state*=3Dcaf324471khs872&%20*code*=3D4/=
5wFzvDar86R-AJWCIE&%20*scope*=3Dprofile%20openid%20https://www.googleapis=
=2Ecom/auth/userinfo.profile&%20*authuser*=3D0&%20*prompt*=3Dconsent
>
> As per the RFC6749 section 4.1.2, the authorization response from the
> authorization endpoint only includes code and state.
>
> Appreciate if you can share any insights on why Google adds scope,
> authuser and prompt parameters to the response, which are not in the
> OAuth 2.0 RFC - and do we consider those additional parameters as a
> violation of the RFC6749?
>
> Thanks!
> -Alex
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov


--------------D8373E19AE136D4799CBB7EB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Alex,

    
OAuth 2.0 doesn't forbid other params to be present in the
      response. If you find such - ignore them.

    
https://tools.ietf.org/html/rfc6749#section-4=
=2E1.2

    

      

        
The client MUST ignore unrecognized respon=
se parameters.

      

      I have a theory why those 3 extra params (scope, authuser, prompt)
      are there, but I don't think it would matter in your case.

    

    
Vladimir

    

    
On 05/11/2020 02:23, Alex Kalp wrote:<=
br>
    

    

      
      

        
Hi All,

        


        

        
While trying out the OAuth 2.0 authorization code grant
          type with Google, I got the following response to my
          registered redirect_uri.

        


        

        
https://localhost:9000/app_uri?<=
b>state=3Dcaf324471khs872&%20code=3D4/5wFzvDar86R-AJWCIE&a=
mp;%20scope=3Dprofile%20openid%20https://www.googleapis.com/auth/user=
info.profile&%20authuser=3D0&%20prompt=3Dconsen=
t

        


        

        
As per the RFC6749 section 4.1.2, the authorization
          response from the authorization endpoint only includes code
          and state.

        


        

        
Appreciate if you can share any insights on why Google adds
          scope, authuser and prompt parameters to the response, which
          are not in the OAuth 2.0 RFC - and do we consider those
          additional parameters as a violation of the RFC6749?

        


        

        
Thanks!

        
-Alex

        

        


        

        


        

      

      

      

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


    

    
--=20
Vladimir Dzhuvinov

  


--------------D8373E19AE136D4799CBB7EB--

--------------ms020602020201020507010002
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMDUwNTAwMTJaMC8G
CSqGSIb3DQEJBDEiBCBkhQy9ulOrTGgkR1JthGApIeHGvhS9AwPFe+W3jIYfvDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAGHrtcqetWhXwCHtLOYcWCawm/SjdOEFF7xLhVATcn3Lok9D
kwfaBfv3CAlsdJWPyE0BcwOdJ5VTThSzcmxKfgDa2COwl+jeN+EE2zKNsXFqMfftYeu2TmCG
X80XbST2IisB78AKnnNHrEBKG0oZ3rbzfQteHuVZlyhIPBFcn/qP3VCXw4wPROqYlOFw1iRl
s2/hGXPncKrzcsTvYBiZron+r258oyu9/BBF5DHS/bxKyhvfiBbWfB+ogcy2YSy/rHDy22Hs
ysns70m2l3pYZTEWgZAiDx+7dOGhIfcetPDv69ySAWs8GYzi+kZHcUPOCF3+FrtIni3u9Lvi
OgThWvQAAAAAAAA=
--------------ms020602020201020507010002--


From nobody Thu Nov  5 05:47:09 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC18B3A114D for ; Thu,  5 Nov 2020 05:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 2AwjjSKy819Z for ; Thu,  5 Nov 2020 05:47:07 -0800 (PST)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBA63A1136 for ; Thu,  5 Nov 2020 05:47:06 -0800 (PST)
Received: by mail-wr1-x436.google.com with SMTP id y12so1834092wrp.6 for ; Thu, 05 Nov 2020 05:47:06 -0800 (PST)
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=AnY+kWzP77FnFP4YETbg3LaivzfNM76XuLQ+vzTfpg8=; b=C/VkP/RkCkVri2V3VPJRNFvRslWbzf/DudQ7e1zemnqEwAiW2uZa87NSkVLkRCGa5G 9Byxj660FV38M258O4fwSE2gncO6pNnb4CQ03AgOphec0om3OL46cdLHwnTE+omJky95 eXQudBE/rMCr/kg9qKIK0DbwOVBrY5FOQ80ycjf5RgV3OMOx/d1JGNzmXzdzeDGOFPSx IzIZmiGuGSIVMqglVAiCHR86faiEAJPla6Sdlvyofyocd373TPWfu6OP+NrTUCbHLX7i 7fjlpJaghchiSKy/8p6s6Y6I5zPLD2tBdLNzO+LvVtDdWCZIkgHaEJqTodaW0VzaUVSR YWdg==
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=AnY+kWzP77FnFP4YETbg3LaivzfNM76XuLQ+vzTfpg8=; b=G5Rd+739RwzNIFZuCglscoENWAyGG5yTlzweMdDPeWrkcg0WdHuem9ImzMHdS1WtZS nMKLsH3dceAYcJjFhXVRT6+bg0oOKqqsEkhaIfCRI8GR6b4HFiod7XqfpJV+XsmyEvYj upt4XONkR4mnD7R1zYomYLUZu6rslgoIyC0zocDI0KoyYzjGvANbDBgOMVStAkU9Lf4d 2603zPt+kj/6RWG1nLnzskYhJJPAmweXFwC910gZFfg5TZ0nbNSMQnHAGNRENY5Yn+ct 4otT8NJrgRqK9Q+hFldeGyz4/KCweNBnguU9Ha1TV1mCXLJc1QKt4o6Tnpk/Ot/A1q/h O+Fg==
X-Gm-Message-State: AOAM533SCzn/4aniECujOvELnG4liqLNRqGSHSH82WgIJ6XHbA3PKP5A xdOd1yQQKEU3lHpvLJziJI5e+6ZjlprmbIAF9RRJqiMxnZSUPA==
X-Google-Smtp-Source: ABdhPJxuR3w8hh0qwKuMzr8VNqwe3OurpF1wvvw2pDfIyJkImb71PEU9E5JUAfFk/kmVdOJBcX+btxoFn/pTAwBx33c=
X-Received: by 2002:a5d:5703:: with SMTP id a3mr3108564wrv.67.1604584025301; Thu, 05 Nov 2020 05:47:05 -0800 (PST)
MIME-Version: 1.0
References:  <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com>
In-Reply-To: <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com>
From: Alex Kalp 
Date: Thu, 5 Nov 2020 05:47:56 -0800
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d726bc05b35c5447"
Archived-At: 
Subject: Re: [OAUTH-WG] The response from the Google 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: Thu, 05 Nov 2020 13:47:09 -0000

--000000000000d726bc05b35c5447
Content-Type: text/plain; charset="UTF-8"

Hi Vladimir,

Thanks for the reply. Would be great if you can share your insights on how
those parameters are being used.

I could not find any public docs explaining their usage, so thought they
probably are being used by the Google applications by themselves.

Thanks!


On Wed, Nov 4, 2020 at 9:00 PM Vladimir Dzhuvinov 
wrote:

> Hi Alex,
>
> OAuth 2.0 doesn't forbid other params to be present in the response. If
> you find such - ignore them.
>
> https://tools.ietf.org/html/rfc6749#section-4.1.2
>
> The client MUST ignore unrecognized response parameters.
>
> I have a theory why those 3 extra params (scope, authuser, prompt) are
> there, but I don't think it would matter in your case.
>
> Vladimir
> On 05/11/2020 02:23, Alex Kalp wrote:
>
> Hi All,
>
> While trying out the OAuth 2.0 authorization code grant type with Google,
> I got the following response to my registered redirect_uri.
>
> https://localhost:9000/app_uri?*state*=caf324471khs872&%20*code*
> =4/5wFzvDar86R-AJWCIE&%20*scope*=profile%20openid%20
> https://www.googleapis.com/auth/userinfo.profile&%20*authuser*=0&%20
> *prompt*=consent
>
> As per the RFC6749 section 4.1.2, the authorization response from the
> authorization endpoint only includes code and state.
>
> Appreciate if you can share any insights on why Google adds scope,
> authuser and prompt parameters to the response, which are not in the OAuth
> 2.0 RFC - and do we consider those additional parameters as a violation of
> the RFC6749?
>
> Thanks!
> -Alex
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>
>

--000000000000d726bc05b35c5447
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Vladimir,

Thanks for the =
reply. Would be great if you can share your insights on how those parameter=
s are being used.

I could not find any public docs=
 explaining their usage, so thought they probably are being used by the Goo=
gle applications by themselves.

Thanks!
<=
div>

On Wed, Nov 4, 2020 at 9:00 PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote=
:

 =20
   =20
 =20
  

    
Hi Alex,

    
OAuth 2.0 doesn't forbid other params to be present in the
      response. If you find such - ignore them.

    
https://tools.ietf.org/html/rfc6749#section-4.1.2

    

      

        
The client MUST ignore unrecognized response parameters.

      

      I have a theory why those 3 extra params (scope, authuser, prompt)
      are there, but I don't think it would matter in your case.

    

    
Vladimir

    

    
On 05/11/2020 02:23, Alex Kalp wrote:

    

    

     =20
      

        
Hi All,

        


        

        
While trying out the OAuth 2.0 authorization code grant
          type with Google, I got the following response to my
          registered redirect_uri.

        


        

        
h=
ttps://localhost:9000/app_uri?state=3Dcaf324471khs872&%20=
code=3D4/5wFzvDar86R-AJWCIE&%20scope=3Dprofile%20openid%20https://www.googleapis.com/auth/userinfo.profile&%20=
authuser=3D0&%20prompt=3Dconsent

        


        

        
As per the RFC6749 section 4.1.2, the authorization
          response from the authorization endpoint only includes code
          and state.

        


        

        
Appreciate if you can share any insights on why Google adds
          scope, authuser and prompt parameters to the response, which
          are not in the OAuth 2.0 RFC - and do we consider those
          additional parameters as a violation of the RFC6749?

        


        

        
Thanks!

        
-Alex

        

        


        

        


        

      

      

      

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


    

    
--=20
Vladimir Dzhuvinov

  





--000000000000d726bc05b35c5447--


From nobody Thu Nov  5 06:02:03 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E5D3A11A6 for ; Thu,  5 Nov 2020 06:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 PLFBFJlESq3u for ; Thu,  5 Nov 2020 06:01:40 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 3AE843A119D for ; Thu,  5 Nov 2020 06:01:40 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id k9so1648074edo.5 for ; Thu, 05 Nov 2020 06:01:40 -0800 (PST)
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=2nZhatwqvu7na2YgxCmRpVSs4iQ90l6W64JbbuMOAcM=; b=mPwj8FG/SVg1bljUwEn1fuFWgTIo1JL/xAr1UGAIIbXIakpp5h/h8Tj7BLJBDYCQaw OjOf+N0MKVMQhCb3Y0zz44eR+F0ag69E/2yqKd1vOlsW9tAIrhpe8MWKBY3sakJEdr8q C+FzXseu0l3FolhTHemC0nR56PvQebEFM2wKz9FiBTNdL07fi8X3ClKI/ni7Vnf3wjh8 I4GZA8ZcJgdWDKfR7IkPrPjhzYqrwTONsyUWn+onZHJnIyFWm3dn7E1bAO7uOuc1Fm4q kvTmnlyeLdHdNIfCS5RYScLBUgdInnahsWEXgcqhm/sQ16YZZLF3/C+NP967xvnFyzkt yrVA==
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=2nZhatwqvu7na2YgxCmRpVSs4iQ90l6W64JbbuMOAcM=; b=cIeGD1q+hFo+/5JNk1V9c+BGK9d3Vpq/F5Ecxo4d/4IqDaOJVP6m4nyw8IlbU7b/u0 XYTWqwRteWja9fqXwSC7rhp5h2xlGt7RbPrEop7jFBayVbDk6sfpxHYs0xXWvip/J9ks brm5e/WrR+185MAb+yrNJBrtBu76vZ4E/RDXvCzCiUCJczbo6zr+wyHqbJUFhvkRVb+L btmOeDqTrrF5eGUKbL8jYuQVHJNoKP7EIrDFrs1N4EnZnY6MsCH949PwIh6RcM9H4AUf /fx1WIYEK/5gEQlCwV/OlNQafU0e/LzQbVU8mK7iDrIYyETRwsQNzyxtSp5JGBwIIH6e EXIQ==
X-Gm-Message-State: AOAM5300EREUechxufSnqmtT2kQbwVghxHAzrfENrCEDmQ/bUBtEy+mN r8qj4rGQ0ok3eT7q4xfC3oXt1zsd+Zm003yGiOU=
X-Google-Smtp-Source: ABdhPJzMeKeUXhVRSYwQl+aO67csUA5gtnArjZaaKkqauoSmLkxMvcK4thPCG4LqxwiLagUND/tG+Z9fPwGxWbFzLMk=
X-Received: by 2002:a05:6402:b68:: with SMTP id cb8mr2693636edb.198.1604584898563;  Thu, 05 Nov 2020 06:01:38 -0800 (PST)
MIME-Version: 1.0
References:  <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com>
In-Reply-To: <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com>
From: Bunh Tha Chau 
Date: Thu, 5 Nov 2020 21:01:23 +0700
Message-ID: 
To: Dzhuvinov 
Cc: Alex Kalp , oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e4133d05b35c888f"
Archived-At: 
Subject: Re: [OAUTH-WG] The response from the Google 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: Thu, 05 Nov 2020 14:01:42 -0000

--000000000000e4133d05b35c888f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

V=C3=A0o 12:00, Th 5, 5 thg 11, 2020 Vladimir Dzhuvinov 
=C4=91=C3=A3 vi=E1=BA=BFt:

> Hi Alex,
>
> OAuth 2.0 doesn't forbid other params to be present in the response. If
> you find such - ignore them.
>
> https://tools.ietf.org/html/rfc6749#section-4.1.2
>
> The client MUST ignore unrecognized response parameters.
>
> I have a theory why those 3 extra params (scope, authuser, prompt) are
> there, but I don't think it would matter in your case.
>
> Vladimir
> On 05/11/2020 02:23, Alex Kalp wrote:
>
> Hi All,
>
> While trying out the OAuth 2.0 authorization code grant type with Google,
> I got the following response to my registered redirect_uri.
>
> https://localhost:9000/app_uri?*state*=3Dcaf324471khs872&%20*code*
> =3D4/5wFzvDar86R-AJWCIE&%20*scope*=3Dprofile%20openid%20
> https://www.googleapis.com/auth/userinfo.profile&%20*authuser*=3D0&%20
> *prompt*=3Dconsent
>
> As per the RFC6749 section 4.1.2, the authorization response from the
> authorization endpoint only includes code and state.
>
> Appreciate if you can share any insights on why Google adds scope,
> authuser and prompt parameters to the response, which are not in the OAut=
h
> 2.0 RFC - and do we consider those additional parameters as a violation o=
f
> the RFC6749?
>
> Thanks!
> -Alex
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000e4133d05b35c888f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



V=
=C3=A0o 12:00, Th 5, 5 thg 11, 2020 Vladimir Dzhuvinov <vladimir@connect2id.com> =C4=91=C3=A3 vi=
=E1=BA=BFt:

 =20
   =20
 =20
  

    
Hi Alex,

    
OAuth 2.0 doesn't forbid other params to be present in the
      response. If you find such - ignore them.

    
https://tools.ietf.org/html/rfc6749#section-=
4.1.2

    

      

        
The client MUST ignore unrecognized response parameters.

      

      I have a theory why those 3 extra params (scope, authuser, prompt)
      are there, but I don't think it would matter in your case.

    

    
Vladimir

    

    
On 05/11/2020 02:23, Alex Kalp wrote:

    

    

     =20
      

        
Hi All,

        


        

        
While trying out the OAuth 2.0 authorization code grant
          type with Google, I got the following response to my
          registered redirect_uri.

        


        

        
https://localhost:9000/app_uri?state=3Dcaf3244=
71khs872&%20code=3D4/5wFzvDar86R-AJWCIE&%20scope=3Dpr=
ofile%20openid%20https://www.googleapis.com/=
auth/userinfo.profile&%20authuser=3D0&%20prompt=
=3Dconsent

        


        

        
As per the RFC6749 section 4.1.2, the authorization
          response from the authorization endpoint only includes code
          and state.

        


        

        
Appreciate if you can share any insights on why Google adds
          scope, authuser and prompt parameters to the response, which
          are not in the OAuth 2.0 RFC - and do we consider those
          additional parameters as a violation of the RFC6749?

        


        

        
Thanks!

        
-Alex

        

        


        

        


        

      

      

      

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


    

    
--=20
Vladimir Dzhuvinov

  


_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000e4133d05b35c888f--


From nobody Fri Nov  6 11:40:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912D03A0B8A for ; Fri,  6 Nov 2020 11:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level: 
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 6fI2T8EFgdy5 for ; Fri,  6 Nov 2020 11:40:22 -0800 (PST)
Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (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 2CA963A0B86 for ; Fri,  6 Nov 2020 11:40:22 -0800 (PST)
Received: from [192.168.1.12] ([95.43.118.112]) by :SMTPAUTH: with ESMTPSA id b7askIyac5Lb5b7aukeSX7; Fri, 06 Nov 2020 12:40:21 -0700
X-CMAE-Analysis: v=2.4 cv=LcD5VhTi c=1 sm=1 tr=0 ts=5fa5a6a5 a=cEjntNAGV8NWJ0nI97Ft9A==:117 a=cEjntNAGV8NWJ0nI97Ft9A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=3g80flMcAAAA:8 a=VFy3eAyCrIdP2oCrexYA:9 a=QEXdDO2ut3YA:10 a=gUXmQ8eWAGYA:10 a=pGLkceISAAAA:8 a=n-2D4-zkyGu7lSdpoK0A:9 a=3L8A9djZ4PH1a049:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Alex Kalp 
Cc: oauth@ietf.org
References:  <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com> 
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: 
Date: Fri, 6 Nov 2020 21:40:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070204040200040704050709"
X-CMAE-Envelope: MS4xfM4WZip0lnfTFQtezC+v2r8TDf9OVtTTHdmhMqgb9BZsLx5htArN7HQlTMxSLD6NgM0W0oZPJPq8z/ocrCYicXv1a0ulNkU0zsSu25g6+OoSQSG58HR3 I/oU90ZQyJ4n22NKAu18MZuqhm2Rat9e6ro2R80nvpP61znVAANCVrz9tvhBTp9dl0rk/OEytpG3gDRSFV1qzrKMMiieZMyJRe48tcJXwO9L1U1GQUgexygC
Archived-At: 
Subject: Re: [OAUTH-WG] The response from the Google 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: Fri, 06 Nov 2020 19:40:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms070204040200040704050709
Content-Type: multipart/alternative;
 boundary="------------F63749A8C14EF3293EFDAAFC"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------F63749A8C14EF3293EFDAAFC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I suspect those params are to signal the client if the user was
(re)authenticated, prompted for consent and the consented scope. But
being non-std and non-documented params it would be best to ignore them.

Vladimir

On 05/11/2020 15:47, Alex Kalp wrote:
> Hi Vladimir,
>
> Thanks for the reply. Would be great if you can share your insights on
> how those parameters are being used.
>
> I could not find any public docs explaining their usage, so thought
> they probably are being used by the Google applications by themselves.
>
> Thanks!
>
>
> On Wed, Nov 4, 2020 at 9:00 PM Vladimir Dzhuvinov
> > wrote:
>
>     Hi Alex,
>
>     OAuth 2.0 doesn't forbid other params to be present in the
>     response. If you find such - ignore them.
>
>     https://tools.ietf.org/html/rfc6749#section-4.1.2
>
>>     The client MUST ignore unrecognized response parameters.
>     I have a theory why those 3 extra params (scope, authuser, prompt)
>     are there, but I don't think it would matter in your case.
>
>     Vladimir
>
>     On 05/11/2020 02:23, Alex Kalp wrote:
>>     Hi All,
>>
>>     While trying out the OAuth 2.0 authorization code grant type with
>>     Google, I got the following response to my registered redirect_uri=
=2E
>>
>>     https://localhost:9000/app_uri?*state*=3Dcaf324471khs872&%20*code*=
=3D4/5wFzvDar86R-AJWCIE&%20*scope*=3Dprofile%20openid%20https://www.googl=
eapis.com/auth/userinfo.profile&%20*authuser*=3D0&%20*prompt*=3Dconsent
>>
>>     As per the RFC6749 section 4.1.2, the authorization response from
>>     the authorization endpoint only includes code and state.
>>
>>     Appreciate if you can share any insights on why Google adds
>>     scope, authuser and prompt parameters to the response, which are
>>     not in the OAuth 2.0 RFC - and do we consider those additional
>>     parameters as a violation of the RFC6749?
>>
>>     Thanks!
>>     -Alex
>>


--------------F63749A8C14EF3293EFDAAFC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I suspect those params are to signal the client if the user was
      (re)authenticated, prompted for consent and the consented scope.
      But being non-std and non-documented params it would be best to
      ignore them.

    
Vladimir

    

    
On 05/11/2020 15:47, Alex Kalp wrote:<=
br>
    

    

      
      

        
Hi Vladimir,

        


        

        
Thanks for the reply. Would be great if you can share your
          insights on how those parameters are being used.

        


        

        
I could not find any public docs explaining their usage, so
          thought they probably are being used by the Google
          applications by themselves.

        


        

        
Thanks!

        

        


        

      

      

      

        
On Wed, Nov 4, 2020 at 9:00=
 PM
          Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        
=

          

            
Hi Alex,

            
OAuth 2.0 doesn't forbid other params to be present in
              the response. If you find such - ignore them.

            
https://tools.=
ietf.org/html/rfc6749#section-4.1.2

            
 

            

              
The client MUST ignore unrecognized response parameter=
s.

            

            I have a theory why those 3 extra params (scope, authuser,
            prompt) are there, but I don't think it would matter in your
            case.

            
Vladimir

            

            
On 05/11/2020 02:23, Alex Kalp wrote:

            

            

              

                
Hi All,

                


                

                
While trying out the OAuth 2.0 authorization code
                  grant type with Google, I got the following response
                  to my registered redirect_uri.

                


                

                
https://lo=
calhost:9000/app_uri?state=3Dcaf324471khs872&%20code=3D4/5wFzvDar86R-AJWCIE&%20scope=3Dprofile%20openid%20https://ww=
w.googleapis.com/auth/userinfo.profile&%20authuser=3D0&=
;%20prompt=3Dconsent

                


                

                
As per the RFC6749 section 4.1.2, the authorization
                  response from the authorization endpoint only includes
                  code and state.

                


                

                
Appreciate if you can share any insights on why
                  Google adds scope, authuser and prompt parameters to
                  the response, which are not in the OAuth 2.0 RFC - and
                  do we consider those additional parameters as a
                  violation of the RFC6749?

                


                

                
Thanks!

                
-Alex

                

                


                

              

            

          

        

      

    

    

  


--------------F63749A8C14EF3293EFDAAFC--

--------------ms070204040200040704050709
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMDYxOTQwMTdaMC8G
CSqGSIb3DQEJBDEiBCBCWV2Hv77Vb3tMe7y/Y8N4a092KRvduIfJcFrZA40gQzBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAJOuVk/drR35Gp+uwSCzRuburROWch54AWCIof6qV/wkRF4j
O+HvczZwlNM6h+PVnTufVyL4Ae/6rx8/M6ApNoKEiw0up3BeWYVaAXxurCULO4GBJ4t69i9m
lLxqpjHLIgkCbLlHUpKii6tTpzzNP/6ieGB5OvvUbHkYmJ1VGPzu0NH9pp19i0N6QSZESesE
fuBs20LUKaLJ85WhLw1R68vll0FPwxP6UGNSXFCiqjBHxQLkpEoI+Ev9AOxvlZZ/rMUtUahK
0h3/ibvHfbwhXFqGsZICZgtI66xkRIZ0pVTqnCppCNx1lF3amuwWqnFuPI5S/drosjWcxjZW
wT4XnWUAAAAAAAA=
--------------ms070204040200040704050709--


From nobody Fri Nov  6 13:34:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902533A0EB9 for ; Fri,  6 Nov 2020 13:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L0Ff0XQkIiO for ; Fri,  6 Nov 2020 13:34:39 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA13E3A0E52 for ; Fri,  6 Nov 2020 13:34:33 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id w14so2743122wrs.9 for ; Fri, 06 Nov 2020 13:34:33 -0800 (PST)
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; bh=cAxiV8IScBvxdgm/bfZlkOjnUAWN6fq10UOB/fcf5to=; b=pLPdy3OMPZyDMnMpHGOPJRu7TK6BJVYa67DlwiHw8ve/fcys7dJgKH1VD3A26dVmOv yBqpH7llHO5jASlin7qQORrY4xH/Z5wAwaqJob1NRuUE0M7HbewPXXlTkBBt3LN8ZR0T WbN80pqY+iGrodIo3rkBPX7UzQ8b+TA+rhNXwf4TuDAf8pvgJ7JzRMK9+dlVsnGeyzg+ FFsxVUNcWRkzVpuM0yX9VAnH4NJp4SwkFYLI41e9lqO2E8dPkZX3LgjJLiqIC1gFgcZL FRhZPzgyAAsU5aOXzprNqZqxCV8vzFb8Kr8vHo/t17urgwI4KxnHONOk1XwgF2yqsEfN 1QaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cAxiV8IScBvxdgm/bfZlkOjnUAWN6fq10UOB/fcf5to=; b=GQLDbvFdg1V/J+7lfJEyFXBxNldUSXZI7x0Z4eUkZUdOnFKaF0SX35hgyOblB1kT+K s6ja/kLZU1gHXiDam/Ri6ax3LgizvoKCM452Svdgkzr7dYAZRcV5gsdOGKIeQu+8GiU4 l1G1BiLO+00R9zmKhmBhUo7NSBjcCmbRevJ+2R/ds4Mfq9fkLZIL7twElRPm7AQxwKYq fkxxOWP+WQCjQJKprf0IrZ0nHVhdF4Hrk7ZToIEk9JbsTGyzaTapt/mSBEmztFe8n3Wf ojjIjERwW2oO7qAf+BmqBtE5UwGJ209INbQyhRuzZtBkxBD3E0Ez7SkEIBgiNF0Km2q8 AW4w==
X-Gm-Message-State: AOAM5302Ga16dNmidwx5Mh8Xt61X3m7t41olHiVUDC52weZVyc7KCeJo n6fZ0Hsm3YBmF2kzY0SRf7wWfYADmnoH7evHpUVFYwCR/YRSlg==
X-Google-Smtp-Source: ABdhPJwGOdFYf55Hs/pyflgxB8JgS5PZpaLK4IE3KT0nzlTletH38AhHr1ipfzdEz3tvyOfGu7ULKB7zHOeS4ukQjsE=
X-Received: by 2002:adf:ea0b:: with SMTP id q11mr4731254wrm.80.1604698471724;  Fri, 06 Nov 2020 13:34:31 -0800 (PST)
MIME-Version: 1.0
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>   <69B0850B-D863-4792-905E-54EE20823323@authlete.com> 
In-Reply-To: 
From: Takahiko Kawasaki 
Date: Sat, 7 Nov 2020 06:34:20 +0900
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000006110de05b376faa1"
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Nov 2020 21:34:48 -0000

--0000000000006110de05b376faa1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I implemented the draft quickly and found no big hurdle for authorization
server implementations. The current snapshot of my implementation does not
add the `iss` parameter when JARM is used. However, for interoperability, I
feel that the spec should describe expected behaviors when a JWT is
included in an authorization response. The following is an implementer's
comment for some cases.

Case 1: When JARM is used

An `iss` claim is included in the response JWT as one of top-level entries
together with response parameters. It is not so unnatural to regard the
`iss` claim as a response parameter. Conclusion would be "When JARM is
used, the `iss` parameter is not necessary."

Case 2: When an ID token is issued

It is unnatural to regard the `iss` claim in an ID token as a response
parameter. However, because FAPI Part 2 has already been using an ID token
as detached signature for integrity protection, it would be difficult to
find a convincing reason to prohibit using the `iss` claim in an ID token
as a countermeasure to mix-up attacks. Conclusion would be "When an ID
token is issued, the `iss` parameter is not necessary."

Case 3: When an unencrypted JWT access token is issued

It is technically possible to use the `iss` claim in an unencrypted JWT
access token as the `iss` parameter. However, requiring the client to check
the `iss` claim means "The access token is no longer opaque to the client."
Conclusion would be "Even when an access token is issued and its format is
JWT, the `iss` parameter is necessary."

BTW, I found that a certain system raises an error when an unknown response
parameter (that is, the `iss` parameter) is included in error authorization
responses. To ask the administrator of the system to regard the `iss`
parameter as a known one, at least the spec draft needs to be adopted by
the community as a working draft. I hope that "call for adoption" for the
draft will be conducted soon.

Best Regards,
Taka

On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki  wrote:

> It sounds that the Security Considerations section or somewhere
> appropriate should have a paragraph like below.
>
> When an authorization response includes a JWT whose `iss` claim represent=
s
> the issuer identifier of the authorization server, the `iss` claim can be
> used as a substitute for the `iss` parameter. Therefore, such authorizati=
on
> response does not have to have the `iss` parameter outside the JWT
> separately. Examples of such JWTs include the value of the `id_token`
> parameter in OIDC and the value of `response` parameter in JARM.
>
> Taka
>
> On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan  wrote=
:
>
>> I agree, it is in redundant in the JARM case.
>>
>> I find the text in
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-re=
sp-01.html#name-security-considerations
>> (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I
>> think it would be good to say something along the lines of:
>>
>> Although integrity protection is not necessary to prevent mixup, any
>> authorization response method that includes a JWT with an =E2=80=98iss' =
(for
>> example, JARM or OIDC hybrid flow) will prevent the attack (assuming the
>> client is validating the iss).
>>
>>
>> I=E2=80=99m not entirely sure I understand what "MUST NOT allow multiple
>> authorization servers to return the same issuer identifier during
>> registration=E2=80=9D means as I don=E2=80=99t think https://tools.ietf.=
org/html/rfc7591
>> returns the issuer?
>>
>> It might be clearer to say something like =E2=80=9CWhen
>> https://tools.ietf.org/html/rfc8414 is used the client MUST implement
>> the validation described in
>> https://tools.ietf.org/html/rfc8414#section-3.3. When authorization
>> server details can be manually configured in the client, the client must
>> verify that all issuer values are unique.=E2=80=9D (Or at least somethin=
g along
>> those lines, I=E2=80=99m sure my wording can be improved. But if the cli=
ent is
>> correctly implementing rfc8414 or OIDC discovery [and does not have any
>> manually configured authorization servers] then there=E2=80=99s no requi=
rement for
>> any further checks that the issuer is unique.)
>>
>> Joseph
>>
>>
>> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov 
>> wrote:
>>
>> This can potentially occur. If JARM is used "iss" becomes redundant. To
>> me JARM is an "enhanced" iss.
>>
>> If both are included a sensible client should make sure the iss and the
>> JARM iss match.
>>
>> My suggestion is to not require iss when a JARM is present, but in case
>> both do occur to have the client check both.
>>
>> Vladimir
>> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>>
>> Hi Karsten,
>>
>> The specification mentions JARM. Does this specification require the iss
>> response parameter even when JARM is used? That is, should an authorizat=
ion
>> response look like below?
>>
>> HTTP/1.1 302 Found
>> Location: https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUER}
>>
>> Or, can the iss response parameter be omitted when JARM is used?
>>
>> A small feedback for the 3rd paragraph in Section 4:
>> s/identifes/identifies/
>>
>> Best Regards,
>> Taka
>>
>>
>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>>
>>> Thanks Karsten, looks good to me now, no further comments.
>>>
>>> Vladimir
>>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>>
>>> Hi all,
>>>
>>> Daniel and I published a new version of the "iss" response parameter
>>> draft to address the feedback from the WG.
>>>
>>> Changes in -01:
>>>
>>>    - Incorporated first WG feedback
>>>    - Clarifications for use with OIDC
>>>    - Added note that clients supporting just one AS are not vulnerable
>>>    - Renamed metadata parameter
>>>    - Various editorial changes
>>>
>>>
>>> We would like to ask you for further feedback and comments on the new
>>> draft version.
>>>
>>> Best regards,
>>> Karsten
>>>
>>> -------- Forwarded Message --------
>>> Subject: New Version Notification for
>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> Date: Sun, 01 Nov 2020 23:31:42 -0800
>>> From: internet-drafts@ietf.org
>>> To: Karsten Meyer zu Selhausen 
>>> , Karsten zu Selhausen
>>> 
>>> , Daniel Fett
>>>  
>>>
>>>
>>> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>> has been successfully submitted by Karsten Meyer zu Selhausen and poste=
d
>>> to the
>>> IETF repository.
>>>
>>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>> Revision: 01
>>> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorizatio=
n
>>> Response
>>> Document date: 2020-11-01
>>> Group: Individual Submission
>>> Pages: 10
>>> URL:
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-r=
esp-01.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-=
resp/
>>> Html:
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-r=
esp-01.html
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-=
01
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-au=
th-resp-01
>>>
>>> Abstract:
>>> This document specifies a new parameter "iss" that is used to
>>> explicitly include the issuer identifier of the authorization server
>>> in the authorization response of an OAuth authorization flow. If
>>> implemented correctly, the "iss" parameter serves as an effective
>>> countermeasure to "mix-up attacks".
>>>
>>>
>>>
>>> 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
>>>
>>>
>>> --
>>> Karsten Meyer zu Selhausen
>>> IT Security Consultant
>>> Phone:	+49 (0)234 / 54456499
>>> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing=
, Security Training
>>>
>>> Does your OAuth or OpenID Connect implementation use PKCE to strengthen=
 the security? Learn more about the procetion PKCE provides and its limitat=
ions in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce=
-cannot-protect-your-confidential-oauth-client
>>>
>>> Hackmanit GmbH
>>> Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
>>> 44789 Bochum
>>>
>>> Registergericht: Amtsgericht Bochum, HRB 14896
>>> Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj=
 Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o=
auth
>>>
>>> _______________________________________________
>>> 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
>>
>

--0000000000006110de05b376faa1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I implemented the draft quickly and found no big hurdle fo=
r authorization server implementations. The current snapshot of my implemen=
tation does not add the `iss` parameter when JARM is used. However, for int=
eroperability, I feel that the spec should describe expected behaviors when=
 a JWT is included in an authorization response. The following is an implem=
enter's comment for some cases.

Case 1: When JARM is used
An `iss` claim is included in the response JWT as one of top-level entries=
 together with response parameters. It is not so unnatural to regard the `i=
ss` claim as a response parameter. Conclusion would be "When JARM is u=
sed, the `iss` parameter is not necessary."

Case 2: When an ID =
token is issued

It is unnatural to regard the `iss` claim in an ID t=
oken as a response parameter. However, because FAPI Part 2 has already been=
 using an ID token as detached signature for integrity protection, it would=
 be difficult to find a convincing reason to prohibit using the `iss` claim=
 in an ID token as a countermeasure to mix-up attacks. Conclusion would be =
"When an ID token is issued, the `iss` parameter is not necessary.&quo=
t;

Case 3: When an unencrypted JWT access token is issued

It =
is technically possible to use the `iss` claim in an unencrypted JWT access=
 token as the `iss` parameter. However, requiring the client to check the `=
iss` claim means "The access token is no longer opaque to the client.&=
quot; Conclusion would be "Even when an access token is issued and its=
 format is JWT, the `iss` parameter is necessary."

BTW, I found=
 that a certain system raises an error when an unknown response parameter (=
that is, the `iss` parameter) is included in error authorization responses.=
 To ask the administrator of the system to regard the `iss` parameter as a =
known one, at least the spec draft needs to be adopted by the community as =
a working draft. I hope that "call for adoption" for the draft wi=
ll be conducted soon.

Best Regards,
Taka

On Wed, Nov 4, 2020 =
at 4:46 AM Takahiko Kawasaki <taka@=
authlete.com> wrote:
It sounds that the Security Considerations sec=
tion or somewhere appropriate should have a paragraph like below.

Wh=
en an authorization response includes a JWT whose `iss` claim represents th=
e issuer identifier of the authorization server, the `iss` claim can be use=
d as a substitute for the `iss` parameter. Therefore, such authorization re=
sponse does not have to have the `iss` parameter outside the JWT separately=
. Examples of such JWTs include the value of the `id_token` parameter in OI=
DC and the value of `response` parameter in JARM.

Taka

=

On Tue, No=
v 3, 2020 at 10:46 PM Joseph Heenan <joseph@authlete.com> wrote:
I agree, it is in redundant i=
n the JARM case.

I find the text in=C2=A0https://www.ietf.org/ar=
chive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-c=
onsiderations (the 4th paragraph where JARM & JWTs) are mentioned a=
 bit confusing - I think it would be good to say something along the lines =
of:

Although integrity protection is not necessary=
 to prevent mixup, any authorization response method that includes a JWT wi=
th an =E2=80=98iss' (for example, JARM or OIDC hybrid flow) will preven=
t the attack (assuming the client is validating the iss).


I=E2=80=99m not entirely sure I understand what &quo=
t;MUST NOT allow multiple authorization servers to return the same issuer i=
dentifier during registration=E2=80=9D means as I don=E2=80=99t think https://tools.=
ietf.org/html/rfc7591 returns the issuer?

It m=
ight be clearer to say something like =E2=80=9CWhen https://tools.ietf.org/html/rfc8=
414 is used the client MUST implement the validation described in ht=
tps://tools.ietf.org/html/rfc8414#section-3.3. When authorization serve=
r details can be manually configured in the client, the client must verify =
that all issuer values are unique.=E2=80=9D (Or at least something along th=
ose lines, I=E2=80=99m sure my wording can be improved. But if the client i=
s correctly implementing rfc8414 or OIDC discovery [and does not have any m=
anually configured authorization servers] then there=E2=80=99s no requireme=
nt for any further checks that the issuer is unique.)

<=
div>Joseph


On 3 Nov 2=
020, at 07:01, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
   =20
 =20
  
This can potentially occur. If JARM is used "iss" becom=
es
      redundant. To me JARM is an "enhanced" iss.
If both a=
re included a sensible client should make sure the iss
      and the JARM iss match.
My suggestion is to not require iss whe=
n a JARM is present, but
      in case both do occur to have the client check both.

    
Vladimir

    

    
On 02/11/2020 22:34, Takahiko Kawasaki
      wrote:

    

    

     =20
      
Hi Karsten,
        


        

        
The specification mentions JARM. Does this specification
          require the iss response parameter even when JARM is used?
          That is, should an authorization response look like below?

        


        

        
HTTP/1.1 302 Found

        
        


        

        
Or, can the iss response parameter be omitted when JARM is
          used?

        


        

        
A small feedback for the 3rd paragraph in Section 4:
          s/identifes/identifies/

        


        

        
Best Regards,

        
Taka

        
=C2=A0

      

      

      

        
On Tue, Nov 3, 2020 at 3:13 A=
M
          Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        

          
Thanks Karsten, looks good to me now, no further
              comments.

            
Vladimir

            

            
On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:

            

            
Hi all,
Daniel and=
 I
                  published a new version of the "iss" response
                  parameter draft to address the feedback from the WG.
Changes in -01:

              
    
                
  • Incorporated
                    first WG feedback
    • 
                
  • Clarifications
                    for use with OIDC
    • 
                
  • Added note that
                    clients supporting just one AS are not vulnerable
    • 
                
  • Renamed metadata
                    parameter
    • 
                
  • Various editoria=
l
                    changes
    
                  
    • 
              

              


                We would like to ask you for
                      further feedback and comments on the new draft
                      version.

                    

              


                

              
Best regards,

              
Karsten
              


              

              
-------- Forwarded Message --------
                

                  
                    

                      Subjec=
t: 
                      New Version Notification for
                        draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
                    

                    

                      Date: =

                      Sun, 01 Nov 2020 23:31:42 -0800
                    

                    

                      From: =

                      internet-drafts@ietf.org
                    

                    

                      To: 
                      Karsten Meyer zu Selhausen <karsten.meyerzusel=
hausen@hackmanit.de>,
                        Karsten zu Selhausen <karsten.meyerzuselhausen@h=
ackmanit.de>,
                        Daniel Fett <mail@danielfett.de>
                    

                  
                

                

                

                

                A new version of I-D,
                draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                has been successfully submitted by Karsten Meyer zu
                Selhausen and posted to the

                IETF repository.

                

                Name: draft-meyerzuselhausen-oauth-iss-auth-resp

                Revision: 01

                Title: OAuth 2.0 Authorization Server Issuer Identifier
                in Authorization Response

                Document date: 2020-11-01

                Group: Individual Submission

                Pages: 10

                URL: https://www.ietf.=
org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                Status: https://datatracker=
.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

                Html: https://www.iet=
f.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html

                Htmlized: https://tools.ietf.o=
rg/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01

                Diff: https://www.ietf=
.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth-resp-01

                

                Abstract:

                This document specifies a new parameter "iss" tha=
t is
                used to

                explicitly include the issuer identifier of the
                authorization server

                in the authorization response of an OAuth authorization
                flow. If

                implemented correctly, the "iss" parameter serves=
 as an
                effective

                countermeasure to "mix-up attacks".

                

                

                

                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

                

                

              

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the=
 security? Learn more about the procetion PKCE provides and its limitations=
 in our new blog post:
https://www.hackmanit.de=
/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

              

              

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


            

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.or=
g

          https://www.ietf.org/mailman/listinfo/oauth=


        

      

    

    

  


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

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--0000000000006110de05b376faa1--


From nobody Fri Nov  6 13:46:34 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8173A0D79 for ; Fri,  6 Nov 2020 13:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level: 
X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vu7iea-syib for ; Fri,  6 Nov 2020 13:46:30 -0800 (PST)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 93E843A0D73 for ; Fri,  6 Nov 2020 13:46:30 -0800 (PST)
Received: by mail-yb1-xb36.google.com with SMTP id i193so2402332yba.1 for ; Fri, 06 Nov 2020 13:46:30 -0800 (PST)
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=7zBNd/cZxXflq7PFSD7rwRABvysygC8BML4lUkkyTPI=; b=LdXt9nt7TDe2mNsUazuIeCCRv6kUYTAJr87vaF9KlPsN5rJN6knHzyfJDkFwnD6xBe oQy2y4ImPxyYRGMnq+b/JbT69P++0jU5BrJHn4yZRDdvVTJaCZV7L5PEfH8pfBTwWKxJ 9kHgnQkFOFqtJ84R5i7Y4hyga+3jABfHuAwFT72X1Ygjt0H2Z/5sif6SnlWz21sNrHrc 0/+vTE15E4zOCPYjVqHf1jndN7KH9RyxfIGjBimnjxTtFZZyqBZBW+lHr//N3s7Cn4v4 unWf7h77aVuAUb8VEvj81rohoBxlwLT6QdGAyNXYlaiuu2xvmx5DcoAoWRTatQqcmXsm G6xQ==
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=7zBNd/cZxXflq7PFSD7rwRABvysygC8BML4lUkkyTPI=; b=Zwo1h+ARHPCfM0TwkZl1zYnBHUACniRcj38pMGQ3Puj0/iS+EjlIPZyqlB98Oxla51 fJAXZR82M3DJg4JVcorC28J6U0RAEXeszMFIrQ80uxIggK8OvNWa/9F4I1JuX3t8APNf ZGs/2GzFKhynfRfXVSngfkURrtTHtH/2OZc93p0lElxNIkbgiUiaox8iWnOAcbpT3Rts 0sKksV7Rs287HzPOxO58KxxkaVSBpEXwFeYwTG4D9FZ2Q+JtH2IgLEmQryT/GyOCV7wh ld8INulKNYaxUmEqd4BqVWF7Fe/CJzEwdj4SnZF6T8+NAAdu48MqTTPjVCCbVxKuNWut pgyA==
X-Gm-Message-State: AOAM531BvQsGMPW/ZrCiQQuWn48bxFRpttJUMDY7XY6OtuEZVwrJII9W IFWfzLS+Yi4M5is8x37mPSSRmzYo+dN3u4+7Q67cu+lx
X-Google-Smtp-Source: ABdhPJzXivHUEnuLYeY8h1UD+ujmd4OLsEVipWGRF2Ztc7HQNCtzGcKUHSxPaDjZcYHOLk+Vnbp6M5QMM4t6kbPyX8U=
X-Received: by 2002:a25:900b:: with SMTP id s11mr5945396ybl.468.1604699189621;  Fri, 06 Nov 2020 13:46:29 -0800 (PST)
MIME-Version: 1.0
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com> 
In-Reply-To: 
From: Pretty Little Wife 
Date: Fri, 6 Nov 2020 14:46:19 -0700
Message-ID: 
To: Karsten Meyer zu Selhausen 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002b375905b377259f"
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Nov 2020 21:46:33 -0000

--0000000000002b375905b377259f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Karsten,

I'm not sure why I'm on this email chain.  Would you kindly remove my email=
?

Thanks,
Kristen

On Mon, Nov 2, 2020, 12:54 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhausen@hackmanit.de> wrote:

> Hi all,
>
> Daniel and I published a new version of the "iss" response parameter draf=
t
> to address the feedback from the WG.
>
> Changes in -01:
>
>    - Incorporated first WG feedback
>    - Clarifications for use with OIDC
>    - Added note that clients supporting just one AS are not vulnerable
>    - Renamed metadata parameter
>    - Various editorial changes
>
>
> We would like to ask you for further feedback and comments on the new
> draft version.
>
> Best regards,
> Karsten
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
> Date: Sun, 01 Nov 2020 23:31:42 -0800
> From: internet-drafts@ietf.org
> To: Karsten Meyer zu Selhausen 
> , Karsten zu Selhausen
> 
> , Daniel Fett 
> 
>
>
> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
> has been successfully submitted by Karsten Meyer zu Selhausen and posted
> to the
> IETF repository.
>
> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
> Revision: 01
> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization
> Response
> Document date: 2020-11-01
> Group: Individual Submission
> Pages: 10
> URL:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-re=
sp/
> Html:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-01.html
> Htmlized:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth=
-resp-01
>
> Abstract:
> This document specifies a new parameter "iss" that is used to
> explicitly include the issuer identifier of the authorization server
> in the authorization response of an OAuth authorization flow. If
> implemented correctly, the "iss" parameter serves as an effective
> countermeasure to "mix-up attacks".
>
>
>
> 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
>
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:	+49 (0)234 / 54456499
> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, =
Security Training
>
> Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitatio=
ns in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce-c=
annot-protect-your-confidential-oauth-client
>
> Hackmanit GmbH
> Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000002b375905b377259f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0Karsten,

I'm not sure why I'm on this email chain.=C2=A0 Would you kind=
ly remove my email?

Than=
ks,
Kristen

On Mon, Nov 2, 2020, 12:54 AM Karst=
en Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> wrote:

 =20

   =20
 =20
  

    
Hi all,

    
Daniel and I published a new
        version of the "iss" response parameter draft to address =
the
        feedback from the WG.

    
Changes in -01:

    
    
      
  • Incorporated first WG
          feedback
    • 
      
  • Clarifications for use wit=
h
          OIDC
    • 
      
  • Added note that clients
          supporting just one AS are not vulnerable
    • 
      
  • Renamed metadata parameter=

    • 
      
  • Various editorial changes<=
br>
        
    • 
    

    


      We would like to ask you for further
            feedback and comments on the new draft version.

          

    


      

    
Best regards,

    
Karsten

    


    

    
-------- Forwarded Message
      --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
          

          

            Date: 
            Sun, 01 Nov 2020 23:31:42 -0800
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Karsten Meyer zu Selhausen
              <karsten.meyerzuselhausen@hackmanit.de&=
gt;, Karsten zu
              Selhausen <karsten.meyerzuselhausen@hac=
kmanit.de>,
              Daniel Fett <mail@danielfett.de>
          

        
      

      

      

      

      A new version of I-D,
      draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

      has been successfully submitted by Karsten Meyer zu Selhausen and
      posted to the

      IETF repository.

      

      Name: draft-meyerzuselhausen-oauth-iss-auth-resp

      Revision: 01

      Title: OAuth 2.0 Authorization Server Issuer Identifier in
      Authorization Response

      Document date: 2020-11-01

      Group: Individual Submission

      Pages: 10

      URL:
https://www.ietf.or=
g/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

      Status:
https://datatracker.ietf=
.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

      Html:
https://www.ietf.o=
rg/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html

      Htmlized:
https://tools.ietf.org/html=
/draft-meyerzuselhausen-oauth-iss-auth-resp-01

      Diff:
https://www.ietf.or=
g/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth-resp-01

      

      Abstract:

      This document specifies a new parameter "iss" that is used =
to

      explicitly include the issuer identifier of the authorization
      server

      in the authorization response of an OAuth authorization flow. If

      implemented correctly, the "iss" parameter serves as an eff=
ective

      countermeasure to "mix-up attacks".

      

      

      

      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

      

      

    

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the=
 security? Learn more about the procetion PKCE provides and its limitations=
 in our new blog post:
https=
://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidenti=
al-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

  


_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--0000000000002b375905b377259f--


From nobody Fri Nov  6 14:02:39 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C8D3A0DA6 for ; Fri,  6 Nov 2020 14:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxuhfDFfwIel for ; Fri,  6 Nov 2020 14:02:36 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD323A0DA5 for ; Fri,  6 Nov 2020 14:02:35 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id l2so3996765lfk.0 for ; Fri, 06 Nov 2020 14:02:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4wo+1Fwi9V6M4K5sEuLyEeNkBN2egRoBpk9SE4ZR1N4=; b=CLWXrkGc5rXBvr9VuCUexwsUXe/Jf2ucmeRLNewEJosYFCXhnDgNxMdG1B+0xuJPz3 bbyELUdnT0mD3MWJx2aZckSjW/v6+jCjajIw27AlfkyphYb/dvbz+zENK1MyLcicjGH7 CV/dNtMyD+N8ba7d2a9iWYIdUp23WXGjG4JggmQiLyyeyYJu4WQY3GFfUlb3Xprt+Rbh MHZyItZPQ8iKOSa3qncbGWMzTG8HyOX1gcm5JjrPohtj4t54UFMQOU4sraa3OtNVR0I/ l6a+z4+Ve8c5sOu2qBPRqLuznWUf5iMM55baDqNUeuIUA2DRhqVKZdw+o3orZ55ND4mk 0hCA==
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=4wo+1Fwi9V6M4K5sEuLyEeNkBN2egRoBpk9SE4ZR1N4=; b=sipJHYdSYiwpvrx2E+DrepXfPYjaBSKGpANvur7vJOzz2jf14cerjdyll0BzGY88bW WwqOngYAcER2hPAXteMHKQFx6WObCRFh8b+vBWy4zhW6K6U1rYTDmAKR2Wp07ROAYzgt Q8YoJZEZhdTdFtGRuzwh4BJ5TlPEjl36bl9TP6PQ88W+pCMlLKpebdG6FYXIMrHZ5Vhh 0AQLFKriYxoWEifLZzZclJ2HS+Fgg/ey4YtGF8PJsNu1j6DRtLrFHtqL9waiY235QLmQ q0wZzmL/+Q15IZ1eXI47PhDnkSJIYzBeDZUXTgACP84jITGIpV9XuL5fVemfabg30w7e +aFA==
X-Gm-Message-State: AOAM531Rd81EQpR5WipH/OXVn+ItEd66ZJCknqVOS8aOOKCGz7Z7IxRq 2+S4I5/6bXh1Ae/A1ADFqkcg7ffGHxd+LedeHidaCrvzqs6oJgOwKHcIblOz1KjSjkLBa7jqUCW KpY9hKZ8AheVP6g==
X-Google-Smtp-Source: ABdhPJx1yQ1lVi8AM1xSVvTkKKO24H+PH+FfCjNCtjYebMaWvUCwXzvjqV6srxzn7pFWOBXEW6waegkTgnzSeM+Hjrw=
X-Received: by 2002:a05:6512:3485:: with SMTP id v5mr1790639lfr.181.1604700154007;  Fri, 06 Nov 2020 14:02:34 -0800 (PST)
MIME-Version: 1.0
References: <158835743733.12112.7484502726888997082@ietfa.amsl.com>  <55D70F29-CF65-405B-AAE0-4978C25C8FCF@forgerock.com> 
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 6 Nov 2020 15:02:07 -0700
Message-ID: 
To: Neil Madden 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000a6b75b05b3775e2d"
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Nov 2020 22:02:38 -0000

--000000000000a6b75b05b3775e2d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 5, 2020 at 2:52 PM Brian Campbell 
wrote:

>
>
>> 9.1:
>> This would be a good place to mention BREACH as an example of how a DPoP
>> proof (and AT) might leak, despite only being sent over a direct HTTPS
>> channel. Note though that adding a random jti is an effective defence
>> against this even if the server doesn=E2=80=99t check it.
>>
>
> Thanks for that note as a good reason to keep jti even if the requirement=
s
> on checking it are relaxed.
>

In trying to add some text that makes such mention I realized (again) that
I don't have a very good understanding of BREACH. With a bit of reading of
the overview and paper at http://breachattack.com/ it seems that BREACH is
applicable to attacking compression for leaking sensitive information in
HTTP responses. Whereas a DPoP proof is only defined to be sent in an HTTP
request. And ATs are only in a response once and then used in requests.
Perhaps it's a limitation of my own imagination or intellect but I don't
see how BREACH is relevant here. If you can explain it to me "for dummies"
style or better yet propose some text, we can certainly look at adding it.
Short of that though, I'm not equipped to write anything legitimate about
it and will just omit any such mention.

--=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._

--000000000000a6b75b05b3775e2d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, May 5, 2020 at 2:52 PM Brian =
Campbell <bcampbell@pingid=
entity.com> wrote:

9.1:
This would be a good place to mention BREACH as =
an example of how a DPoP proof (and AT) might leak, despite only being sent=
 over a direct HTTPS channel. Note though that adding a random jti is an ef=
fective defence against this even if the server doesn=E2=80=99t check it.

Thanks for that note as a =
good reason to keep jti even if the requirements on checking it are relaxed=
. 

In trying to add s=
ome text that makes such mention I realized (again) that I don't have a=
 very good understanding of BREACH. With a bit of reading of the overview a=
nd paper at http://breachattack.com/ it seems that BREACH is applicable to attacking compression for leaking =
sensitive information in HTTP responses. Whereas a DPoP proof is only defin=
ed to be sent in an HTTP request. And ATs are only in a response once and t=
hen used in requests. Perhaps it's a limitation of my own imagination o=
r intellect but I don't see how BREACH is relevant here. If you can exp=
lain it to me "for dummies" style or better yet propose some text=
, we can certainly look at adding it. Short of that though, I'm not equ=
ipped to write anything legitimate about it and will just omit any such men=
tion.=C2=A0 




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000a6b75b05b3775e2d--


From nobody Fri Nov  6 14:12:49 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9AF3A0DB2 for ; Fri,  6 Nov 2020 14:12:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_gpVniIGWfY for ; Fri,  6 Nov 2020 14:12:46 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4583A0DAD for ; Fri,  6 Nov 2020 14:12:46 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id f9so4013883lfq.2 for ; Fri, 06 Nov 2020 14:12:46 -0800 (PST)
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=JRwAlbW9pwadt5o9BtGPomG7s2nigpObjZBKRLfydHo=; b=dTnl6pYw9bnfLHHwlyASqmIASAz8kLT4iJEkwTA1sTzQ14h/nN2yE+NXN6MYRG1Qzg 6fk/OMcqWH22LrNX5//vw8BoSVPcN1kaPShpXJ1e0X4BeRaQBc22G2tuxPX7YbfHHZzo bLKiXwIfLptNYzfXexJHZqy7wBlB/qvLWmSnaN3n6MIXi4fKOTN+qdormKR03y85DcFt C3az0HR10u/kdXMxkLLq38ZBkHQUV1YC7polCJrwZHZMoULxpkPoyHXjELIQXlDYlQ9E OU5iJkfR1RX/YCdYahw1zwq3EPSYGe25QGcytuBYX+SaWPidCGo+p3BQ1ySxCN+UIKg8 hbsw==
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=JRwAlbW9pwadt5o9BtGPomG7s2nigpObjZBKRLfydHo=; b=fKV4QkOolbMFXR+75A+d9l/fRGn8GycJb7CK0czHnXuRpWdRiYxxl48RSdIi9gvAoV DXqHHdev84xqlotFISURb0xktzfJ/WcmDJMxEv+r9D760mjL5qsw9GyVCQ1XH9JlaNz7 TY3N2Otfu40WOZuvm47dlZgDuCYvEHNu2bgPjnJIxPAFKyU6QvwBxC5jso/P8XVVCA+5 41EPm7sap44O9kmgegmOxIBO64iIjZkrhSrOPuSJlOmNo5k8v6lEE1BjqZQTcVu2JVlr hnvomB5J83QspzYctJU0x3IwKblVW4JvXk/HxFnX7K+7+BZcKePawAIDlY1efX2OqVaA 5qww==
X-Gm-Message-State: AOAM532rXkzC+of9YgrYgLJuFuIo2dr8LdBKrpk+tiTImsctchG3V/Y0 kJFzcHXpHVupqoSqDS4E3hS9dOhmQVwoUryC6ay/n3BOZKG5ig==
X-Google-Smtp-Source: ABdhPJzlEM8wzMnuHFnscpX5cKh2uURwPaLDUWs+XUTfakGKgPPFXvRkdaH3h/FfD1W1WvOYX0PoqIvNoAS90LKnKPQ=
X-Received: by 2002:a19:740c:: with SMTP id v12mr1520874lfe.221.1604700764062;  Fri, 06 Nov 2020 14:12:44 -0800 (PST)
MIME-Version: 1.0
From: Dick Hardt 
Date: Fri, 6 Nov 2020 14:12:07 -0800
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000003485105b377837b"
Archived-At: 
Subject: [OAUTH-WG] DPoP Binding JWT proposal
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, 06 Nov 2020 22:12:49 -0000

--00000000000003485105b377837b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello

After reviewing the DPoP spec, and reflecting on implementations I have
worked with, I wanted to see if there was interest in a DPoP Binding JWT.

The use case is to enable existing deployments to add support for DPoP
without having to replace their existing refresh token and access tokens,
and the processing of them as the DPoP Binding JWT processing can be added
as an independent software layer.

The processing overhead is minimized as the DPoP Binding JWT
verification can be cached for an access token,
adding only one JWT verification for the lifetime of the access token.

DPoP Binding JWTs using asymmetric cryptographic algorithms, provide the
increased security of public / private key for existing deployments using
access tokens signed with shared secrets such as HMAC.

/Dick


*X. DPoP Binding JWT*
    Deployments that do not want to modify their existing access tokens or
resource tokens to contain
    the DPoP thumbprint can include DPoP Binding JWTs in the response from
the AS and present them in
    calls to the RS. A DPoP Binding JWT contains the DPoP thumbprint and a
hash of the access token
    or refresh token, and is signed by the AS.

    The use of DPoP Binding JWTs enables existing deployments to add
proof-of-possession assurance to
    existing deployments by adding a middle layer service or software
without modifying the processing
    of refresh tokens or access tokens.



*X.1 DPoP Binding JWT Syntax*
    * "typ": type header, value "dpop-binding+jwt"

    * "jti": unique id
    * "iat": time created
    * "jkt": JWK SHA-256 Thumbprint of the DPoP public key

    If binding an access token
        * "ath": SHA-256 hash of the access token

    If binding an refresh token
        * "rth": SHA-256 hash of the refresh token

    Example DPoP Binding JWT for an access token:

    {
        "typ":"dpop-binding+jwt",
        "alg":"ES256",
        "jwk": {
        "kty":"EC",
        "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
        "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
        "crv":"P-256"
        }
    }.{
        "jti":"-BwC3ESc6acc2lTc",
        "iat":1562262616,
        "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I",
        "ath":"N0d2HglBV3uiguA4I0ZcOCORZNYy-DWpqq30jZyJGHT"
    }



*X.2 Checking DPoP Bindings*
    Check the DPoP Binding JWT is valid
    Check the DPoP Binding JWT "jkt" value matches the thumbprint of the
DPoP public key
    Check the DPoP Binding JWT "ath" value matches the SHA-256 hash of the
access token
      or
    Check the DPoP Binding JWT "rth" value matches the SHA-256 hash of the
refresh token


*X.3 Token Response*
    The AS sets the "token_type" parameter to "DPoP-Binding".
    The AS returns the DPoP Binding JWT for the access token in the
"access_token_binding" parameter,
    and the DPoP Binding JWT for the refresh token in the
"refresh_token_binding" parameter.

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=3DUTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "access_token_binding":"eyJ0eXAiOiJkcG9w....",
       "token_type":"DPoP-Binding",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
       "refresh_token_binding":"eyJ0eXAiOiJkcG9w....."
       "example_parameter":"example_value"
     }


*X.4 Resource access*
    The client presents the access token DPoP Binding JWT in the
"DPoP-Binding" HTTP header.

    GET /protectedresource HTTP/1.1
    Host: resource.example.org
    Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWI
        iOiJzb21lb25lQGV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbX
        BsZS5jb20iLCJhdWQiOiJodHRwczovL3Jlc291cmNlLmV4YW1wbGUub3JnIiwibmJmI
        joxNTYyMjYyNjExLCJleHAiOjE1NjIyNjYyMTYsImNuZiI6eyJqa3QiOiIwWmNPQ09S
        Wk5ZeS1EV3BxcTMwalp5SkdIVE4wZDJIZ2xCVjN1aWd1QTRJIn19.vsFiVqHCyIkBYu
        50c69bmPJsj8qYlsXfuC6nZcLl8YYRNOhqMuRXu6oSZHe2dGZY0ODNaGg1cg-kVigzY
        hF1MQ
    DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
        VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
        nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
        QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj
        oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
        WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCiGB
        NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4UCbQ
    DPoP-Binding: eyJ_an_example_DPoP_binding_JWT_0eXAiOiJkcG9wK2p3dCIsI
        VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
        nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
        QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj
        oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
        WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCiGB
        NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4UCbQ



=E1=90=A7

--00000000000003485105b377837b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello

After reviewing the DP=
oP spec, and reflecting on implementations I have worked with, I wanted to =
see if there was interest in a=C2=A0DPoP Binding JWT.

<=
div>The use case is to enable existing deployments to add support for DPoP =
without having to replace their existing refresh token and access tokens, a=
nd the processing of them as the DPoP Binding JWT processing can be added a=
s an independent=C2=A0software layer.=C2=A0

The pr=
ocessing overhead is minimized as the DPoP Binding JWT verification=C2=A0ca=
n be cached for an access token,=C2=A0
adding only one JWT verifi=
cation for the lifetime of the access token.

DPoP =
Binding JWTs using asymmetric cryptographic algorithms, provide the increas=
ed security of public / private key for existing deployments using access t=
okens signed with shared secrets such as HMAC.

/Di=
ck

X. DPoP Binding JWT

=C2=A0 =C2=A0=
 Deployments that do not want to modify their existing access tokens or res=
ource tokens to contain 
=C2=A0 =C2=A0 the DPoP thumbprint can include D=
PoP Binding JWTs in the response from the AS and present them in 
=C2=A0=
 =C2=A0 calls to the RS. A DPoP Binding JWT contains the DPoP thumbprint an=
d a hash of the access token
=C2=A0 =C2=A0 or refresh token, and is sign=
ed by the AS. 

=C2=A0 =C2=A0 The use of DPoP Binding JWTs enables ex=
isting deployments to add proof-of-possession assurance to 
=C2=A0 =C2=
=A0 existing deployments by adding a middle layer service or software witho=
ut modifying the processing
=C2=A0 =C2=A0 of refresh tokens or access to=
kens.


X.1 DPoP Binding JWT Syntax

=C2=A0 =C2=A0 * =
"typ": type header, value "dpop-binding+jwt" 

=
=C2=A0 =C2=A0 * "jti": unique id
=C2=A0 =C2=A0 * "iat&quo=
t;: time created
=C2=A0 =C2=A0 * "jkt": JWK SHA-256 Thumbprint=
 of the DPoP public key 

=C2=A0 =C2=A0 If binding an access token=C2=A0 =C2=A0 =C2=A0 =C2=A0 * "ath": SHA-256 hash of the access =
token

=C2=A0 =C2=A0 If binding an refresh token
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 * "rth": SHA-256 hash of the refresh token

=C2=
=A0 =C2=A0 Example DPoP Binding=C2=A0JWT for an access token:

=C2=A0=
 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "typ":"dpop-binding=
+jwt",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "alg":"ES256"=
;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "jwk": {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "kty":"EC",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
quot;x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt=
6v9TDVrU0CdvGRDA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "crv":&quo=
t;P-256"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }.{
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "jti":"-BwC3ESc6acc2lTc",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "iat":1562262616,
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uig=
uA4I",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ath":"N0d2HglBV3=
uiguA4I0ZcOCORZNYy-DWpqq30jZyJGHT"
=C2=A0 =C2=A0 }


X.=
2 Checking DPoP Bindings

=C2=A0 =C2=A0 Check the DPoP Binding JW=
T is valid
=C2=A0 =C2=A0 Check the DPoP Binding JWT "jkt" valu=
e matches the thumbprint of the DPoP public key
=C2=A0 =C2=A0 Check the =
DPoP Binding JWT "ath" value matches the SHA-256 hash of the acce=
ss token
=C2=A0 =C2=A0 =C2=A0 or
=C2=A0 =C2=A0 Che=
ck the DPoP Binding JWT "rth" value matches the SHA-256 hash of t=
he refresh token

X.3 Token Response

=C2=
=A0 =C2=A0 The AS sets the "token_type" parameter to "DPoP-B=
inding". 
=C2=A0 =C2=A0 The AS returns the DPoP Binding JWT for the=
 access token in the "access_token_binding" parameter, 
=C2=A0=
 =C2=A0 and the DPoP Binding JWT for the refresh token in the "refresh=
_token_binding" parameter.

=C2=A0 =C2=A0 =C2=A0HTTP/1.1 200 OK<=
br>=C2=A0 =C2=A0 =C2=A0Content-Type: application/json;charset=3DUTF-8
=
=C2=A0 =C2=A0 =C2=A0Cache-Control: no-store
=C2=A0 =C2=A0 =C2=A0Pragma: =
no-cache

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"a=
ccess_token":"2YotnFZFEjr1zCsicMWpAA",
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0"access_token_binding":"eyJ0eXAiOiJkcG9w...."=
,
=C2=A0 =C2=A0 =C2=A0 =C2=A0"token_type":"DPoP-Binding&q=
uot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0"expires_in":3600,
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA&=
quot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0"refresh_token_binding":"=
;eyJ0eXAiOiJkcG9w....."
=C2=A0 =C2=A0 =C2=A0 =C2=A0"example_pa=
rameter":"example_value"
=C2=A0 =C2=A0 =C2=A0}

=
X.4 Resource access

=C2=A0 =C2=A0 The client presents the access=
 token DPoP Binding JWT in the "DPoP-Binding" HTTP header.
=C2=A0 =C2=A0 GET /protectedresource HTTP/1.1
=C2=A0 =C2=A0 Host: resource.example.org
=C2=A0 =C2=
=A0 Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWI=C2=A0 =C2=A0 =C2=A0 =C2=A0 iOiJzb21lb25lQGV4YW1wbGUuY29tIiwiaXNzIjoiaHR0c=
HM6Ly9zZXJ2ZXIuZXhhbX
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BsZS5jb20iLCJhdWQiOiJo=
dHRwczovL3Jlc291cmNlLmV4YW1wbGUub3JnIiwibmJmI
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 joxNTYyMjYyNjExLCJleHAiOjE1NjIyNjYyMTYsImNuZiI6eyJqa3QiOiIwWmNPQ09S
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Wk5ZeS1EV3BxcTMwalp5SkdIVE4wZDJIZ2xCVjN1aWd1QTR=
JIn19.vsFiVqHCyIkBYu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 50c69bmPJsj8qYlsXfuC6nZ=
cLl8YYRNOhqMuRXu6oSZHe2dGZY0ODNaGg1cg-kVigzY
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 hF1MQ
=C2=A0 =C2=A0 DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwia=
ndrIjp7Imt0eSI6Ik
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VDIiwieCI6Imw4dEZyaHgtMzR0=
VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nM=
iLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1M=
QUVCIiwiaHRtIj
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9=
yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WRyZX=
NvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCiGB
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4=
UCbQ
=C2=A0 =C2=A0 DPoP-Binding: eyJ_an_example_DPoP_binding_JWT_0eXAiOi=
JkcG9wK2p3dCIsI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VDIiwieCI6Imw4dEZyaHgtMzR0Vj=
NoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nMiL=
CJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQ=
UVCIiwiaHRtIj
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9y=
ZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WRyZXN=
vdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCiGB
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4UCb=
Q



3D""=E1=90=A7


--00000000000003485105b377837b--


From nobody Sat Nov  7 07:30:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742CB3A07D7 for ; Sat,  7 Nov 2020 07:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeiYMheGkuIk for ; Sat,  7 Nov 2020 07:30:19 -0800 (PST)
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 9F04A3A00C4 for ; Sat,  7 Nov 2020 07:30:19 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id h2so4212612wmm.0 for ; Sat, 07 Nov 2020 07:30:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=WBM6sBWiXYjB9di9+7QBZLyTEpMF4tfTa62YauiWP0c=; b=dRnY7mUupptk4UuhWZyxKBDavqjsGtj7AndlVQK0ikUBG5y2xTGYgBoT9gSZbTju8k Rx9/IgOg80WJmCAdlVgkunn9cfkJGuXIKE9OsPG7RKYQO5LNITmEXiGxS4qy7JN554hu 9JPYuK1EVhvaAD2KQOJx+0IlsyeVFLk/x/LZg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=WBM6sBWiXYjB9di9+7QBZLyTEpMF4tfTa62YauiWP0c=; b=pzFoOejD/VcuxrgOTT1GjD2vkhMuN3ftU527XgDdgj6d4kuAURnq0sIpLmjRpD75Dj 09Boad5e/nEUNkc84DAMdYk9PvL+nsV3RoF6DDg8A6r90FID9XS6itQivWgTv4umtzcs Z5HaGgW7qWZVKsAAJ70liGaM57gZ10tysdOO0vlMaJ1nrS1pHiE7pNfRUlpV+aR65tKI gPfEJL4AXnjDkmGXze+fbgtt2pJZitsDD6ZpEpi84/Yogvo9gHFEWCkg74U7TI/OhJ7g JPwyosqleIFB6UZhv7zJBNOTcbU8BHdFgHmKIAIK78S8NSUxm3kXksZLcYONXAgO1EUg 1Jzw==
X-Gm-Message-State: AOAM532BU9iF2Y7M2V+IOIOlILmTEGziynYh6Ry2EuiAHB2X0ZCEFOC/ E/HeVv6xEd/imP12PZ5nVOB9Hiid05yYIa0Z4gHUeqF3wGpd6cCr03AeXZ028sDA9CBmKFzbiQ= =
X-Google-Smtp-Source: ABdhPJxPPRvb26ab9O35zZv/Jvv45tmMtQN41o9PtkSBhEI5viDXi6BqXZgVvU13rOVBpt4s/Vge6g==
X-Received: by 2002:a05:600c:21d5:: with SMTP id x21mr5538817wmj.133.1604763017463;  Sat, 07 Nov 2020 07:30:17 -0800 (PST)
Received: from [10.0.0.5] ([213.31.218.193]) by smtp.gmail.com with ESMTPSA id b17sm6881860wru.12.2020.11.07.07.30.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Nov 2020 07:30:15 -0800 (PST)
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Sat, 7 Nov 2020 15:30:14 +0000
Message-Id: 
References: 
Cc: oauth 
In-Reply-To: 
To: Brian Campbell 
X-Mailer: iPhone Mail (17H35)
Content-Type: multipart/alternative; boundary=Apple-Mail-574B9628-E63C-4315-9F83-DA702C673342
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 07 Nov 2020 15:30:22 -0000

--Apple-Mail-574B9628-E63C-4315-9F83-DA702C673342
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



> On 6 Nov 2020, at 22:02, Brian Campbell  wrot=
e:
>=20
> =EF=BB=BF
>=20
>=20
>> On Tue, May 5, 2020 at 2:52 PM Brian Campbell  wrote:
>>=20
>>>=20
>>> 9.1:
>>> This would be a good place to mention BREACH as an example of how a DPo=
P proof (and AT) might leak, despite only being sent over a direct HTTPS ch=
annel. Note though that adding a random jti is an effective defence against=
 this even if the server doesn=E2=80=99t check it.
>>=20
>> Thanks for that note as a good reason to keep jti even if the requiremen=
ts on checking it are relaxed.=20
>=20
> In trying to add some text that makes such mention I realized (again) tha=
t I don't have a very good understanding of BREACH. With a bit of reading o=
f the overview and paper at http://breachattack.com/ it seems that BREACH i=
s applicable to attacking compression for leaking sensitive information in =
HTTP responses. Whereas a DPoP proof is only defined to be sent in an HTTP =
request. And ATs are only in a response once and then used in requests. Per=
haps it's a limitation of my own imagination or intellect but I don't see h=
ow BREACH is relevant here. If you can explain it to me "for dummies" style=
 or better yet propose some text, we can certainly look at adding it. Short=
 of that though, I'm not equipped to write anything legitimate about it and=
 will just omit any such mention. =20
> =20

BREACH was primarily attacking web browser clients, which do indeed usually=
 only allow compression in responses. But OAuth is used for other API clien=
ts and compression of requests, although by no means widespread, is sometim=
es used. For example [1] where it=E2=80=99s recommended that clients use co=
mpression for both requests and responses, and a Google search shows variou=
s other cases.=20

So in these cases a BREACH-like attack could be used to recover a bearer to=
ken in those requests. However, on reflection it=E2=80=99s not a hugely lik=
ely attack vector for a number of reasons:

1. HTTP compression only compresses the request entity, not the headers or =
request URI. So this would only be a risk when sending the access token in =
the body as in [2]. And it=E2=80=99s not a risk for a DPoP proof as that=E2=
=80=99s always in a header.=20

2. In order for the attack to work the attacker needs to be able to influen=
ce some part of the requests, which is generally a bit harder than influenc=
ing responses from a server. The most likely vector IMO would be XSS, in wh=
ich case there are likely to be more direct ways to steal the token.=20

I wouldn=E2=80=99t want to say that this is never a risk, but it perhaps do=
esn=E2=80=99t rise to the level that it=E2=80=99s worth spelling out.=20

[1]: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_re=
st/intro_rest_compression.htm

[2]: https://tools.ietf.org/html/rfc6750#section-2.2

=E2=80=94 Neil
--=20
ForgeRock values your Privacy 

--Apple-Mail-574B9628-E63C-4315-9F83-DA702C673342
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On 6 Nov 2020, at 22:02, Brian Campbell =
<bcampbell@pingidentity.com> wrote:

=EF=BB=BF


On Tue, May 5, 2020 at 2:52 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
<=
/div>


9.1:
This=
 would be a good place to mention BREACH as an example of how a DPoP proof =
(and AT) might leak, despite only being sent over a direct HTTPS channel. N=
ote though that adding a random jti is an effective defence against this ev=
en if the server doesn=E2=80=99t check it.

Thanks for that note as a good reason to keep jti even if=
 the requirements on checking it are relaxed. 

In trying to add some text that makes such mentio=
n I realized (again) that I don't have a very good understanding of BREACH.=
 With a bit of reading of the overview and paper at http://breachattack.com/ it seems that BREACH is applicab=
le to attacking compression for leaking sensitive information in HTTP respo=
nses. Whereas a DPoP proof is only defined to be sent in an HTTP request. A=
nd ATs are only in a response once and then used in requests. Perhaps it's =
a limitation of my own imagination or intellect but I don't see how BREACH =
is relevant here. If you can explain it to me "for dummies" style or better=
 yet propose some text, we can certainly look at adding it. Short of that t=
hough, I'm not equipped to write anything legitimate about it and will just=
 omit any such mention.  
 
=

BREACH was primarily attacking web browser clients, w=
hich do indeed usually only allow compression in responses. But OAuth is us=
ed for other API clients and compression of requests, although by no means =
widespread, is sometimes used. For example [1] where it=E2=80=99s recommend=
ed that clients use compression for both requests and responses, and a Goog=
le search shows various other cases. 

So in t=
hese cases a BREACH-like attack could be used to recover a bearer token in =
those requests. However, on reflection it=E2=80=99s not a hugely likely att=
ack vector for a number of reasons:

1. HTTP compre=
ssion only compresses the request entity, not the headers or request URI. S=
o this would only be a risk when sending the access token in the body as in=
 [2]. And it=E2=80=99s not a risk for a DPoP proof as that=E2=80=99s always=
 in a header. 

2. In order for the attack to =
work the attacker needs to be able to influence some part of the requests, =
which is generally a bit harder than influencing responses from a server. T=
he most likely vector IMO would be XSS, in which case there are likely to b=
e more direct ways to steal the token. 

I wou=
ldn=E2=80=99t want to say that this is never a risk, but it perhaps doesn=
=E2=80=99t rise to the level that it=E2=80=99s worth spelling out. 



=E2=80=94 Neil



ForgeRock values your Privacy
--Apple-Mail-574B9628-E63C-4315-9F83-DA702C673342--


From nobody Mon Nov  9 05:26:31 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FC83A10CC for ; Mon,  9 Nov 2020 05:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eueI9ZFuIwO for ; Mon,  9 Nov 2020 05:26:26 -0800 (PST)
Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD293A10C4 for ; Mon,  9 Nov 2020 05:26:26 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id c7BgknPF9s03rc7Bgkkly0; Mon, 09 Nov 2020 06:26:25 -0700
X-CMAE-Analysis: v=2.4 cv=BK92EHcG c=1 sm=1 tr=0 ts=5fa94381 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=is3RsFX7AAAA:8 a=ddEIn7SpAAAA:8 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=A1X0JdhQAAAA:8 a=9YbGl7VAAAAA:8 a=4ezpLM88s8vack6FeQoA:9 a=9TZmf1GdRN-sQNED:21 a=OkXOjrVIByJe2-6Z:21 a=QEXdDO2ut3YA:10 a=LBoxaBkYVh4A:10 a=idCLnkAckNQA:10 a=13CRv-QaNUMA:10 a=pGLkceISAAAA:8 a=94LdQcbE46jLBJERA_0A:9 a=AvLyLvJS67_e691E:21 a=-CVsevPRWKxegHmW:21 a=-bhPNmUlWenlCia9:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=CvJ-9y_HEmGQg9NJmnFv:22 a=0LcYgHMQs7_kImmFrmno:22 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=AcK2Xwxry4XOpw9gWFIK:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>   <69B0850B-D863-4792-905E-54EE20823323@authlete.com>  
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com>
Date: Mon, 9 Nov 2020 15:26:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000706080109010803080109"
X-CMAE-Envelope: MS4xfFqp3mEhz5HoM4L9tulA9IfqRwOqJFxsQRxsE6UrZven9SuQ+lAa/agbeozhsbfYKZB7ZX585IFFsEOaqBdpNXW1Q+cnbGo8GqpHWpg2BM7z7p6WYbCx 7Y6unQhZfO9Knl09s5N05akepBCv/VNuW/KObK4RVh/XPp+g5eQvkdWdki7Jf5lxd9MZvGUHUcxVow==
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Nov 2020 13:26:29 -0000

This is a cryptographically signed message in MIME format.

--------------ms000706080109010803080109
Content-Type: multipart/alternative;
 boundary="------------A12E0AC585395CF2C73B33DF"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------A12E0AC585395CF2C73B33DF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Re Case 1: When JARM is used:

A colleague pointed me to the following statement in the JARMs spec, so
I'd suggest to say the "iss" MUST NOT be included when JARM is used:

https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-respon=
se-mode

> All response parameters defined for a given response type are conveyed
> in a JWT

Now, there isn't a proper normative keyword in this JARM spec sentence,
so I guess some may interpret this as a strong check for no other query
params, while others may not. Hence the MUST NOT to prevent potential
unintended errors.

What are your thoughts on this?

Vladimir

On 06/11/2020 23:34, Takahiko Kawasaki wrote:
> I implemented the draft quickly and found no big hurdle for
> authorization server implementations. The current snapshot of my
> implementation does not add the `iss` parameter when JARM is used.
> However, for interoperability, I feel that the spec should describe
> expected behaviors when a JWT is included in an authorization
> response. The following is an implementer's comment for some cases.
>
> Case 1: When JARM is used
>
> An `iss` claim is included in the response JWT as one of top-level
> entries together with response parameters. It is not so unnatural to
> regard the `iss` claim as a response parameter. Conclusion would be
> "When JARM is used, the `iss` parameter is not necessary."
>
> Case 2: When an ID token is issued
>
> It is unnatural to regard the `iss` claim in an ID token as a response
> parameter. However, because FAPI Part 2 has already been using an ID
> token as detached signature for integrity protection, it would be
> difficult to find a convincing reason to prohibit using the `iss`
> claim in an ID token as a countermeasure to mix-up attacks. Conclusion
> would be "When an ID token is issued, the `iss` parameter is not
> necessary."
>
> Case 3: When an unencrypted JWT access token is issued
>
> It is technically possible to use the `iss` claim in an unencrypted
> JWT access token as the `iss` parameter. However, requiring the client
> to check the `iss` claim means "The access token is no longer opaque
> to the client." Conclusion would be "Even when an access token is
> issued and its format is JWT, the `iss` parameter is necessary."
>
> BTW, I found that a certain system raises an error when an unknown
> response parameter (that is, the `iss` parameter) is included in error
> authorization responses. To ask the administrator of the system to
> regard the `iss` parameter as a known one, at least the spec draft
> needs to be adopted by the community as a working draft. I hope that
> "call for adoption" for the draft will be conducted soon.
>
> Best Regards,
> Taka
>
> On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki  > wrote:
>
>     It sounds that the Security Considerations section or somewhere
>     appropriate should have a paragraph like below.
>
>     When an authorization response includes a JWT whose `iss` claim
>     represents the issuer identifier of the authorization server, the
>     `iss` claim can be used as a substitute for the `iss` parameter.
>     Therefore, such authorization response does not have to have the
>     `iss` parameter outside the JWT separately. Examples of such JWTs
>     include the value of the `id_token` parameter in OIDC and the
>     value of `response` parameter in JARM.
>
>     Taka
>
>     On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan      > wrote:
>
>         I agree, it is in redundant in the JARM case.
>
>         I find the text
>         in=C2=A0https://www.ietf.org/archive/id/draft-meyerzuselhausen-=
oauth-iss-auth-resp-01.html#name-security-considerations
>         (the 4th paragraph where JARM & JWTs) are mentioned a bit
>         confusing - I think it would be good to say something along
>         the lines of:
>
>         Although integrity protection is not necessary to prevent
>         mixup, any authorization response method that includes a JWT
>         with an =E2=80=98iss' (for example, JARM or OIDC hybrid flow) w=
ill
>         prevent the attack (assuming the client is validating the iss).=

>
>
>         I=E2=80=99m not entirely sure I understand what "MUST NOT allow=

>         multiple authorization servers to return the same issuer
>         identifier during registration=E2=80=9D means as I don=E2=80=99=
t think
>         https://tools.ietf.org/html/rfc7591 returns the issuer?
>
>         It might be clearer to say something like =E2=80=9CWhen
>         https://tools.ietf.org/html/rfc8414 is used the client MUST
>         implement the validation described in
>         https://tools.ietf.org/html/rfc8414#section-3.3. When
>         authorization server details can be manually configured in the
>         client, the client must verify that all issuer values are
>         unique.=E2=80=9D (Or at least something along those lines, I=E2=
=80=99m sure my
>         wording can be improved. But if the client is correctly
>         implementing rfc8414 or OIDC discovery [and does not have any
>         manually configured authorization servers] then there=E2=80=99s=
 no
>         requirement for any further checks that the issuer is unique.)
>
>         Joseph
>
>
>>         On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov
>>         > wro=
te:
>>
>>         This can potentially occur. If JARM is used "iss" becomes
>>         redundant. To me JARM is an "enhanced" iss.
>>
>>         If both are included a sensible client should make sure the
>>         iss and the JARM iss match.
>>
>>         My suggestion is to not require iss when a JARM is present,
>>         but in case both do occur to have the client check both.
>>
>>         Vladimir
>>
>>         On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>>>         Hi Karsten,
>>>
>>>         The specification mentions JARM. Does this specification
>>>         require the iss response parameter even when JARM is used?
>>>         That is, should an authorization response look like below?
>>>
>>>         HTTP/1.1 302 Found
>>>         Location:
>>>         https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUER}=

>>>         
>>>
>>>         Or, can the iss response parameter be omitted when JARM is us=
ed?
>>>
>>>         A small feedback for the 3rd paragraph in Section 4:
>>>         s/identifes/identifies/
>>>
>>>         Best Regards,
>>>         Taka
>>>         =C2=A0
>>>
>>>         On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov
>>>         >
>>>         wrote:
>>>
>>>             Thanks Karsten, looks good to me now, no further comments=
=2E
>>>
>>>             Vladimir
>>>
>>>             On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>>>
>>>>             Hi all,
>>>>
>>>>             Daniel and I published a new version of the "iss"
>>>>             response parameter draft to address the feedback from
>>>>             the WG.
>>>>
>>>>             Changes in -01:
>>>>
>>>>               * Incorporated first WG feedback
>>>>               * Clarifications for use with OIDC
>>>>               * Added note that clients supporting just one AS are
>>>>                 not vulnerable
>>>>               * Renamed metadata parameter
>>>>               * Various editorial changes
>>>>
>>>>
>>>>             We would like to ask you for further feedback and
>>>>             comments on the new draft version.
>>>>
>>>>             Best regards,
>>>>             Karsten
>>>>
>>>>             -------- Forwarded Message --------
>>>>             Subject: 	New Version Notification for
>>>>             draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>             Date: 	Sun, 01 Nov 2020 23:31:42 -0800
>>>>             From: 	internet-drafts@ietf.org
>>>>             
>>>>             To: 	Karsten Meyer zu Selhausen
>>>>             
>>>>             , Karsten
>>>>             zu Selhausen 
>>>>             , Daniel
>>>>             Fett  
>>>>
>>>>
>>>>
>>>>
>>>>             A new version of I-D,
>>>>             draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>             has been successfully submitted by Karsten Meyer zu
>>>>             Selhausen and posted to the
>>>>             IETF repository.
>>>>
>>>>             Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>>>             Revision: 01
>>>>             Title: OAuth 2.0 Authorization Server Issuer Identifier
>>>>             in Authorization Response
>>>>             Document date: 2020-11-01
>>>>             Group: Individual Submission
>>>>             Pages: 10
>>>>             URL:
>>>>             https://www.ietf.org/archive/id/draft-meyerzuselhausen-o=
auth-iss-auth-resp-01.txt
>>>>             Status:
>>>>             https://datatracker.ietf.org/doc/draft-meyerzuselhausen-=
oauth-iss-auth-resp/
>>>>             Html:
>>>>             https://www.ietf.org/archive/id/draft-meyerzuselhausen-o=
auth-iss-auth-resp-01.html
>>>>             Htmlized:
>>>>             https://tools.ietf.org/html/draft-meyerzuselhausen-oauth=
-iss-auth-resp-01
>>>>             Diff:
>>>>             https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhaus=
en-oauth-iss-auth-resp-01
>>>>
>>>>             Abstract:
>>>>             This document specifies a new parameter "iss" that is
>>>>             used to
>>>>             explicitly include the issuer identifier of the
>>>>             authorization server
>>>>             in the authorization response of an OAuth authorization
>>>>             flow. If
>>>>             implemented correctly, the "iss" parameter serves as an
>>>>             effective
>>>>             countermeasure to "mix-up attacks".
>>>>
>>>>
>>>>
>>>>             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
>>>>
>>>>
>>>>             --=20
>>>>             Karsten Meyer zu Selhausen
>>>>             IT Security Consultant
>>>>             Phone:	+49 (0)234 / 54456499
>>>>             Web:	https://hackmanit.de  | IT S=
ecurity Consulting, Penetration Testing, Security Training
>>>>
>>>>             Does your OAuth or OpenID Connect implementation use PKC=
E to strengthen the security? Learn more about the procetion PKCE provide=
s and its limitations in our new blog post:
>>>>             https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot=
-protect-your-confidential-oauth-client
>>>>
>>>>             Hackmanit GmbH
>>>>             Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
>>>>             44789 Bochum
>>>>
>>>>             Registergericht: Amtsgericht Bochum, HRB 14896
>>>>             Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, =
Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>>>
>>>>             _______________________________________________
>>>>             OAuth mailing list
>>>>             OAuth@ietf.org 
>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org 
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov


--------------A12E0AC585395CF2C73B33DF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Re Case 1: When JARM is used:

    
A colleague pointed me to the following statement in the JARMs
      spec, so I'd suggest to say the "iss" MUST NOT be included when
      JARM is used:

    

    
https://openid=
=2Enet//specs/openid-financial-api-jarm.html#jwt-based-response-mode<=
/p>
    

      
All response parameters defined for a
        given response type are conveyed in a JWT

    

    
Now, there isn't a proper normative keyword in this JARM spec
      sentence, so I guess some may interpret this as a strong check for
      no other query params, while others may not. Hence the MUST NOT to
      prevent potential unintended errors.

    
What are your thoughts on this?

    

    
Vladimir

    

    
On 06/11/2020 23:34, Takahiko Kawasaki=

      wrote:

    

    

      
      
I implemented the draft quickly and found no big
        hurdle for authorization server implementations. The current
        snapshot of my implementation does not add the `iss` parameter
        when JARM is used. However, for interoperability, I feel that
        the spec should describe expected behaviors when a JWT is
        included in an authorization response. The following is an
        implementer's comment for some cases.

        

        Case 1: When JARM is used

        

        An `iss` claim is included in the response JWT as one of
        top-level entries together with response parameters. It is not
        so unnatural to regard the `iss` claim as a response parameter.
        Conclusion would be "When JARM is used, the `iss` parameter is
        not necessary."

        

        Case 2: When an ID token is issued

        

        It is unnatural to regard the `iss` claim in an ID token as a
        response parameter. However, because FAPI Part 2 has already
        been using an ID token as detached signature for integrity
        protection, it would be difficult to find a convincing reason to
        prohibit using the `iss` claim in an ID token as a
        countermeasure to mix-up attacks. Conclusion would be "When an
        ID token is issued, the `iss` parameter is not necessary."

        

        Case 3: When an unencrypted JWT access token is issued

        

        It is technically possible to use the `iss` claim in an
        unencrypted JWT access token as the `iss` parameter. However,
        requiring the client to check the `iss` claim means "The access
        token is no longer opaque to the client." Conclusion would be
        "Even when an access token is issued and its format is JWT, the
        `iss` parameter is necessary."

        

        BTW, I found that a certain system raises an error when an
        unknown response parameter (that is, the `iss` parameter) is
        included in error authorization responses. To ask the
        administrator of the system to regard the `iss` parameter as a
        known one, at least the spec draft needs to be adopted by the
        community as a working draft. I hope that "call for adoption"
        for the draft will be conducted soon.

        

        Best Regards,

        Taka

      

      

      

        
On Wed, Nov 4, 2020 at 4:46=
 AM
          Takahiko Kawasaki <taka@authlete.com> wrote:
=

        

        
=

          
It sounds that the Security Considerations
            section or somewhere appropriate should have a paragraph
            like below.

            

            When an authorization response includes a JWT whose `iss`
            claim represents the issuer identifier of the authorization
            server, the `iss` claim can be used as a substitute for the
            `iss` parameter. Therefore, such authorization response does
            not have to have the `iss` parameter outside the JWT
            separately. Examples of such JWTs include the value of the
            `id_token` parameter in OIDC and the value of `response`
            parameter in JARM.

            

            Taka

          

          

          

            
On Tue, Nov 3, 2020 at
              10:46 PM Joseph Heenan <joseph@authlete.com>
              wrote:

            

            

              
I agree, it is in redundant in the JARM case.
                


                

                
I find the text in=C2=A0https://ww=
w.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#=
name-security-considerations
                  (the 4th paragraph where JARM & JWTs) are
                  mentioned a bit confusing - I think it would be good
                  to say something along the lines of:

                


                

                
Although integrity protection is not necessary to
                  prevent mixup, any authorization response method that
                  includes a JWT with an =E2=80=98iss' (for example, JARM=
 or
                  OIDC hybrid flow) will prevent the attack (assuming
                  the client is validating the iss).

                


                

                


                

                
I=E2=80=99m not entirely sure I understand what "MUS=
T NOT
                  allow multiple authorization servers to return the
                  same issuer identifier during registration=E2=80=9D mea=
ns as I
                  don=E2=80=99t think https://to=
ols.ietf.org/html/rfc7591
                  returns the issuer?

                


                

                
It might be clearer to say something like =E2=80=9CW=
hen https://to=
ols.ietf.org/html/rfc8414
                  is used the client MUST implement the validation
                  described in https://to=
ols.ietf.org/html/rfc8414#section-3.3.
                  When authorization server details can be manually
                  configured in the client, the client must verify that
                  all issuer values are unique.=E2=80=9D (Or at least som=
ething
                  along those lines, I=E2=80=99m sure my wording can be
                  improved. But if the client is correctly implementing
                  rfc8414 or OIDC discovery [and does not have any
                  manually configured authorization servers] then
                  there=E2=80=99s no requirement for any further checks t=
hat the
                  issuer is unique.)

                


                

                
Joseph

                


                  


                    

                      
On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov
                        <vlad=
imir@connect2id.com>
                        wrote:

                      

                      

                        

                          
This can potentially occur. If JARM is used
                            "iss" becomes redundant. To me JARM is an
                            "enhanced" iss.

                          
If both are included a sensible client
                            should make sure the iss and the JARM iss
                            match.

                          
My suggestion is to not require iss when a
                            JARM is present, but in case both do occur
                            to have the client check both.

                          

                          
Vladimir

                          

                          
On 02/11/2020 22:34, Takahiko Kawasaki
                            wrote:

                          

                          

                            
Hi Karsten,
                              


                              

                              
The specification mentions JARM. Does
                                this specification require the iss
                                response parameter even when JARM is
                                used? That is, should an authorization
                                response look like below?

                              


                              

                              
HTTP/1.1 302 Found

                              
                              


                              

                              
Or, can the iss response parameter be
                                omitted when JARM is used?

                              


                              

                              
A small feedback for the 3rd
                                paragraph in Section 4:
                                s/identifes/identifies/

                              


                              

                              
Best Regards,

                              
Taka

                              
=C2=A0

                            

                            

                            

                              
On Tu=
e,
                                Nov 3, 2020 at 3:13 AM Vladimir
                                Dzhuvinov <vladimir@connect2id.com>
                                wrote:

                              

                              

                                

                                  
Thanks Karsten, looks good to me
                                    now, no further comments.

                                  

                                  
Vladimir

                                  

                                  
On 02/11/2020 09:54, Karsten
                                    Meyer zu Selhausen wrote:

                                  

                                  

                                    
Hi all,

                                    
Daniel and I published a
                                        new version of the "iss"
                                        response parameter draft to
                                        address the feedback from the
                                        WG.

                                    
Changes in -01:

                                    
    
                                      
  • Incorporated first WG
                                          feedback
    • 
                                      
  • Clarifications for use
                                          with OIDC
    • 
                                      
  • Added note that clients
                                          supporting just one AS are not
                                          vulnerable
    • 
                                      
  • Renamed metadata
                                          parameter
    • 
                                      
  • Various editorial
                                          changes
    
                                        
    • 
                                    

                                    


                                      We would like to ask
                                            you for further feedback and
                                            comments on the new draft
                                            version.

                                          

                                    


                                      

                                    
Best regards,

                                    
Karsten

                                    


                                    

                                    
-------- Forwarded Message
                                      --------
                                      =

                                            =

                                            

                                        
                                          

                                            Subject: 
                                            New Version Notification
                                              for
                                              draft-meyerzuselhausen-oaut=
h-iss-auth-resp-01.txt
                                          

                                          

                                            Date: Sun, 01 Nov 2020
                                              23:31:42 -0800
                                          

                                          

                                            From: =
internet-drafts@ietf.org
                                          

                                          

                                            To: 
                                            Karsten Meyer zu
                                              Selhausen =
<karsten.meyerzuselhausen@hackmanit.de>,
                                              Karsten zu Selhausen =
<karsten.meyerzuselhausen@hackmanit.de>,
                                              Daniel Fett =
<mail@danielfett.de>
                                          

                                        
                                      

                                      

                                      

                                      

                                      A new version of I-D,
                                      draft-meyerzuselhausen-oauth-iss-au=
th-resp-01.txt

                                      has been successfully submitted by
                                      Karsten Meyer zu Selhausen and
                                      posted to the

                                      IETF repository.

                                      

                                      Name:
                                      draft-meyerzuselhausen-oauth-iss-au=
th-resp

                                      Revision: 01

                                      Title: OAuth 2.0 Authorization
                                      Server Issuer Identifier in
                                      Authorization Response

                                      Document date: 2020-11-01

                                      Group: Individual Submission

                                      Pages: 10

                                      URL: https://=
www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt=


                                      Status: https://=
datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/<=
br>
                                      Html: https://=
www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.htm=
l

                                      Htmlized: https://=
tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
=

                                      Diff: https://=
www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth-resp-01=


                                      

                                      Abstract:

                                      This document specifies a new
                                      parameter "iss" that is used to
=

                                      explicitly include the issuer
                                      identifier of the authorization
                                      server

                                      in the authorization response of
                                      an OAuth authorization flow. If
=

                                      implemented correctly, the "iss"
                                      parameter serves as an effective
                                      countermeasure to "mix-up
                                      attacks".

                                      

                                      

                                      

                                      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.ie=
tf.org.

                                      

                                      The IETF Secretariat

                                      

                                      

                                    

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitat=
ions in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-you=
r-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

                                    

                                    

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



                                  

                                

_______________________________________________

                                OAuth mailing list

                                OAuth@ietf.org

                                https://www.ie=
tf.org/mailman/listinfo/oauth

                              

                            

                          

                          

                        

                        _______________________________________________
                        OAuth mailing list

                        OAuth@ietf.org
=

                        http=
s://www.ietf.org/mailman/listinfo/oauth

                      

                    

                  

                  

                

              

              _______________________________________________

              OAuth mailing list

              OAuth@ietf.org

              https://www.ietf.org/mailman/listinfo/oauth

            

          

        

      

      

      

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


    

    
--=20
Vladimir Dzhuvinov

  


--------------A12E0AC585395CF2C73B33DF--

--------------ms000706080109010803080109
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMDkxMzI2MjNaMC8G
CSqGSIb3DQEJBDEiBCB+3f/TUB+NUFuE+60U+FsMq4lvZJfLNeZMIC5V0apsCTBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAHofUGEz3dk3QlwsY8Xm19bkutghew11h4HFE+CJ2zRGuTwY
qE9yhE7cvb47eSYvTvdjepprx9GUkSQWURZQPJ31mSgVbrkY93eqCFJt0pF5GhPpNfscGWOU
2IVQQ02WspeYdGH0Ouh65aXn3bUVcw4hCp8c82mXaSUkF3fT3VQsy9Fn5Engo+r/HQg1KxKx
z4QyIGYMpnuEi6mVFtN9fmDvFjiImu5NZeDqRinuDT3XyEidUJRWh4kGE2QB99RCZaI3yoaz
lu8Mo7EWVk/EWDJ5Ke8DUHs96abBe1gqw7YrrcWW4dcJ10SqdZA2T8UKnEVLn2ZNHfFX6LPU
0UCx+AMAAAAAAAA=
--------------ms000706080109010803080109--


From nobody Tue Nov 10 01:44:30 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471843A0E25 for ; Tue, 10 Nov 2020 01:44:26 -0800 (PST)
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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=xucEqFen; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=xucEqFen
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 QIkJeS29Oi1g for ; Tue, 10 Nov 2020 01:44:24 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2074.outbound.protection.outlook.com [40.107.20.74]) (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 BFE963A0E6B for ; Tue, 10 Nov 2020 01:44:23 -0800 (PST)
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=UIx3nzp7OgdiIRln0llEBChzPbDk77zvRMt3/mipiws=; b=xucEqFensAxPg8VxyYjcY2hdCifcEae+pMMfKSDkxObzpznyWZf8vU4A3PyTyh2wDGn9nbkVVd0VwKUOr/WuR0LiLPsDcwgVLUtbn1yhcAir44AXO3w41wdL9i8xh0kxKc1d/Fyxat8vfFkXxpCFn7K6srqXKApBx/G0Z8ouvzY=
Received: from AM6P192CA0097.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:8d::38) by AM6PR08MB3781.eurprd08.prod.outlook.com (2603:10a6:20b:8b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Tue, 10 Nov 2020 09:44:20 +0000
Received: from AM5EUR03FT008.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8d:cafe::84) by AM6P192CA0097.outlook.office365.com (2603:10a6:209:8d::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Tue, 10 Nov 2020 09:44:20 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT008.mail.protection.outlook.com (10.152.16.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.17 via Frontend Transport; Tue, 10 Nov 2020 09:44:20 +0000
Received: ("Tessian outbound fcd5bc555ddc:v71"); Tue, 10 Nov 2020 09:44:19 +0000
X-CR-MTA-TID: 64aa7808
Received: from 2071969bf669.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3DCACEF7-8FB5-402E-B196-16B3398D2567.1;  Tue, 10 Nov 2020 09:44:14 +0000
Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2071969bf669.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 10 Nov 2020 09:44:14 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jouAE/DQHlZ+yr/x2XSc8mtW9JMbi0d7sywhODGrQC9vC67EuE6SKbAL2lIMqBvgn9o3itw4FoqpivS1/JxxttLGDq74z6Adi3EKFJNEA5dvrSGX5cfXvPVqUqEeoxda+b8OLoHwK6yEcH+ZfiSHHMY3m9V3qwCGLhI94AQ9HKBeq877DIlVO66znG9hxggtxnNxp1520QDYKDn/zTi7Y+0Dr0flF4www4p9Xht/Jw/EEcqxcrs8DWIOHHr/l9Z4eNn1ZLq+MwN44gys1hGghH8NIrSsQOQLijlux3wrwW0pyDsuo0kHqV40JOt2OWKLkjFWuqYsVhhwY50suCmCbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UIx3nzp7OgdiIRln0llEBChzPbDk77zvRMt3/mipiws=; b=EupJPfOb6CM+im7jb12tAHPek7yXqg5szbCbSFW4qDriDwaL7FTy5Wt+AWbAPeXEpEEzcaqrnwZpSOTLL8RuhpVGpeJHI5Czk8NLESrqDfZceFnHoIU/Seijpi0aGCyvuvUCbFeq7zH050+fyshyjSVLffMdE3jvcai9M68zWM+Th+JRs4tBCFgiQ1KFt9hS6KLV4wXRBdg2fduTosA4DoJQnrAykBmMXGXkhh/jQaXEEdnS6EDb+896mFb3tv4XSAeRfwPXgdCQW9sDzHKFTEQBRnH4emzLe5F7XhWkr42l2fOe7R/CpIDqHYbLNk4O1V7kpu41JjBHPde4X1MngQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
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=UIx3nzp7OgdiIRln0llEBChzPbDk77zvRMt3/mipiws=; b=xucEqFensAxPg8VxyYjcY2hdCifcEae+pMMfKSDkxObzpznyWZf8vU4A3PyTyh2wDGn9nbkVVd0VwKUOr/WuR0LiLPsDcwgVLUtbn1yhcAir44AXO3w41wdL9i8xh0kxKc1d/Fyxat8vfFkXxpCFn7K6srqXKApBx/G0Z8ouvzY=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5250.eurprd08.prod.outlook.com (2603:10a6:208:160::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Tue, 10 Nov 2020 09:44:11 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48%7]) with mapi id 15.20.3541.025; Tue, 10 Nov 2020 09:44:10 +0000
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Thread-Topic: PAR Shepherd Review
Thread-Index: Ada3PjLEiisVikQjQlmWgblyDvRIzA==
Date: Tue, 10 Nov 2020 09:44:10 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ts-tracking-id: 2FFCD49B80283D4595E5689A8C771414.0
x-checkrecipientchecked: true
Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com;
x-originating-ip: [195.149.218.242]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: fbd1032e-d430-4ac5-cfae-08d8855d32df
x-ms-traffictypediagnostic: AM0PR08MB5250:|AM6PR08MB3781:
X-Microsoft-Antispam-PRVS: 
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: JW4BSiBML4HKCdeVPSU+GfZGi+OkZQpinGhu9QugbpR807DXOY0Jp+3pgizqFGxKJFIp32DzWdZ5LyaW5R/cv+jO3JDUQ2Eu8Pd5uVc1TbaYd7OMQls3o1uaWyCzjQM136p3EoXDS9MWaQ3RjPETRd92bd6mRShlDvHYxMJb3+NvsoynoP17lTB0TzhJtKsHOSB2cG6Pow4qFf4IegS23KwD+UffzuSvWmSMcPCIndU4X/ZGrzpLtyi/tx/ggXgzcYF3wM9xqwyokaUbNK/Xg+PxACb05Qi6WMTyODfXtjjcKp8C0MGMhnMlbTkfcNDOJM9jd4FWBisFBQfa+eMOrw==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(71200400001)(478600001)(83380400001)(55016002)(66446008)(3480700007)(64756008)(76116006)(66946007)(33656002)(66556008)(66476007)(5660300002)(52536014)(86362001)(8936002)(316002)(8676002)(6916009)(9686003)(7116003)(2906002)(186003)(7696005)(26005)(6506007); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: SEQIsX81+0nknT2x3KkGwIJNfQb212dclVo9pCmH3rg3juldCCmrbTdwBVuU6PpMLuHWJq8oqnilHXY8aZ0kTR24C372CqwGrht1bOMqhRk2zHw39eev3L50GiJh2NXUGbHvbCHCYwcPDCZfNuuzRyndJ7LUQVLcl9XfASdgG96h1LGnvcA2rk9CK5R1HUY/aWWqQ/B62Afw8slhf5ALZkmMiGy4suHAtFey/C+wWr4cp1HP4Jnko3x/Eydxn9M0sW7Q71BWA+hZ1eFrXa28Ux08Fq0yY5q3Afx0Zat52b4USjYw8D6f/sOmOh1rzDQaooTvgtSfnL2fFSMKfaKvY9HSeCjzGcj/79In50ogGfj7IaDYAEGC/jS11BvR7KPquldAlTEiqchud2GO/MLcMdJOyNRNItbVqpY+FZU63O4Aa2480FyQJ9kXWGWQK40FPtQPwmLAqPjFmnIatA3Q1dSlOGt/ZDZCtlGXJzIfwrcv9pgv8O5GDCTKxRVl+vy3Z9kLLECfxE7LPeCiKUswlOIHbsu1+DHoou73WX8Jfd07wPRM3T3pEIl7wsmskM/4sG5p99vASzkZx50c7iMLBMGVMTe6jwsALoV+Ss5Ha3SNA0dntA56v7UYT9dYzJ1EjFTuwsC7BPo3HRjlRc4rUA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37165B2123C9848795F47477FAE90AM0PR08MB3716eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5250
Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT008.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: b7cdf867-d330-428d-60b1-08d8855d2d0b
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: TjWggMyv7QOsrbH66ho+ZNyKFkm2JA9pmZ0GbBOQOPxu2NY3qx2v/BYp+H4pINHinDbVuol8dxQ79nyAbm00ucaOMVJRQ3YO7HXpCGoY/ZKfpp8tb4YGY7Z8uqGOCiR48NotEnlcgZCobKXof7kCk/WoYYW+d5V7q/DJo8foyADw6BhyiCes2HLrJu9DLzLPco/sYDzqU1EpR43YqHxMEtnj7LBaptK6zrhrrOhHdRKdR5JnFsEeQVFiyNO7oVISOzNh9k6jXSri5xP3F+vYrvaZku2MLQUVHtj3GzLpgEX42CYxTue7TQaFlBZLT5hRvXeVcx3Js19WKsnb8hUxRfw3yK823l5sP8pWzM52ILlxK+UhkBCcT0mRjgJ3eBEAgEKl9YU8S+OQua9QAjEz+g==
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;  IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;  PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(136003)(396003)(376002)(39860400002)(46966005)(8676002)(8936002)(6916009)(55016002)(70206006)(9686003)(336012)(356005)(81166007)(82740400003)(47076004)(3480700007)(83380400001)(2906002)(86362001)(82310400003)(7116003)(186003)(478600001)(26005)(36906005)(33656002)(316002)(7696005)(52536014)(5660300002)(6506007)(70586007); DIR:OUT; SFP:1101; 
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2020 09:44:20.4356 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fbd1032e-d430-4ac5-cfae-08d8855d32df
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];  Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT008.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3781
Archived-At: 
Subject: [OAUTH-WG] PAR Shepherd Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Nov 2020 09:44:28 -0000

--_000_AM0PR08MB37165B2123C9848795F47477FAE90AM0PR08MB3716eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I am in the process of writing my shepherd write-up for the PAR document an=
d wanted to make sure that I properly understand the document.
The introduction says:

"

   This document [PAR] complements JAR by providing an interoperable way to
   push the payload of an authorization request directly to the
   authorization server in exchange for a "request_uri" value usable at
   the authorization server in a subsequent authorization request.
"

JAR provides the ability to send Authorization Request parameters in a JWT =
format protected with JWS and optionally JWE. It allows the JAR to be conve=
yed by value and by reference but does not define how the client would uplo=
ad the JAR and how to obtain the reference.

PAR defines how the client uploads the request object and how to obtain the=
 reference. It relies primarily on TLS to protect the communication but men=
tions that it is possible to also use the JWT-based approach suggested by J=
AR.

Both drafts claim to have solved the security issues of protecting the comm=
unication through the user agent.

Is this a correct summary?

Ciao
Hannes

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_AM0PR08MB37165B2123C9848795F47477FAE90AM0PR08MB3716eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all, 


 


I am in the process of writing my shepherd write-up =
for the PAR document and wanted to make sure that I properly understand the=
 document.



The introduction says: 


 


“


 


   This document [PAR]
complements J=
AR by providing an interoperable way to


   push the payload of an authorization request =
directly to the


   authorization server in exchange for a "=
request_uri" value usable at


   the authorization server in a subsequent auth=
orization request.


“


 


JAR provides the ability to send Authorization Reque=
st parameters in a JWT format protected with JWS and optionally JWE. It all=
ows the JAR to be conveyed by value and by reference but does not define ho=
w the client would upload the JAR
 and how to obtain the reference. 


 


PAR defines how the client uploads the request objec=
t and how to obtain the reference. It relies primarily on TLS to protect th=
e communication but mentions that it is possible to also use the JWT-based =
approach suggested by JAR.   


 


Both drafts claim to have solved the security issues=
 of protecting the communication through the user agent.


 


Is this a correct summary? 


 


Ciao


Hannes


 



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_AM0PR08MB37165B2123C9848795F47477FAE90AM0PR08MB3716eurp_--


From nobody Tue Nov 10 08:11:00 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616703A0967 for ; Tue, 10 Nov 2020 08:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyXZ9TkccCdl for ; Tue, 10 Nov 2020 08:10:57 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7513A0978 for ; Tue, 10 Nov 2020 08:10:56 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id y16so15323443ljk.1 for ; Tue, 10 Nov 2020 08:10:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7KUgikBpJ2zbItwOa5KvbReAtxrcPpcx5XalG4dt1R4=; b=aAShRT92JlV5xtfTj4dnseJohk4FRAtP6WCim6O4fMulMvaSTlnpsc/ikMRNrI01NB yeClX3Yr3Yt3V0URQCCnGyiYI/+hioUxg4IIpWDXdBL8wJNyJ6x8kwaYECtnT0ax0Rf4 LursZ5WuJfWNqxu3xHZqPQcE8SRC/QpH7UN6ipd/B5FZU8t7Z7/bxOdW1fIDAJ5Qakgy fZlC1UHsDRuin1hdflba14/CM7UQFamrQEcu7zLn6Hq1KbgqC8PZJmeFuB0TnV8BBmfw OxwhJ7CFSj/r3z7QqJdRXgWGC2WpNbZOqFITDH1fYqX65D/4V/J1ESzlbhVKIQzDiTs4 0zBQ==
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=7KUgikBpJ2zbItwOa5KvbReAtxrcPpcx5XalG4dt1R4=; b=aRoNm/aP0jneXIoF7RRr9U+nOeuilcY+7MaPQF0UgvdiM98wX+o6ZAKe8Z8jaEXVkt jdKN3CNYN/Bhhe4FFdFKC3xvabfO2o+1PyfTyyejniqrcgHMerJPYDR4tRvp4LeJicfO mf+ism4sAFpG3nDSaSp+ZA/i6nms+SYOPJuln1+RpAJDphjHF4X/CnuwHx9crFuT4y0Q ZgFX3FU1vJMx3wY9jmCfTioqpvXBT+ezqSVAFjXQq6pzg4G9U8fVq4K0vM2HSHQkVZL6 QaoMfXQMVCe+khcHembqCsV407edre0/DpmmdWg5+6fKxJR+VxoQ4jekpg1BD1Yr2C8l tubA==
X-Gm-Message-State: AOAM532wgD2qA3khkdmmhutVVqg1+CWXKgm6iAF747XPaljqRPcAbU5/ VKnlTLi5BajETz91Zx7XJgze7P/ud3ywbMeLqRJT5BHAc3yAeTreqnyA2yHExZ3zvB7LaoN9pdI muIMP/ai7IRieKg==
X-Google-Smtp-Source: ABdhPJyKdR8rgGe272udnHFOY2SbCmctzl5uiJa6qengFMedK5fDSlB8iStoE8iYXXOYMuDIoxvUgTvE5I4W+pE3yzc=
X-Received: by 2002:a2e:8681:: with SMTP id l1mr7657665lji.170.1605024655109;  Tue, 10 Nov 2020 08:10:55 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Tue, 10 Nov 2020 09:10:28 -0700
Message-ID: 
To: Hannes Tschofenig 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000006c9c1c05b3c2ecff"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR Shepherd Review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Nov 2020 16:10:59 -0000

--0000000000006c9c1c05b3c2ecff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 10, 2020 at 2:44 AM Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> I am in the process of writing my shepherd write-up for the PAR document
> and wanted to make sure that I properly understand the document.
>
> The introduction says:
>
>
>
> =E2=80=9C
>
>
>
>    This document [PAR] complements JAR by providing an interoperable way
> to
>
>    push the payload of an authorization request directly to the
>
>    authorization server in exchange for a "request_uri" value usable at
>
>    the authorization server in a subsequent authorization request.
>
> =E2=80=9C
>
>
>
> JAR provides the ability to send Authorization Request parameters in a JW=
T
> format protected with JWS and optionally JWE. It allows the JAR to be
> conveyed by value and by reference but does not define how the client wou=
ld
> upload the JAR and how to obtain the reference.
>

For pass-by-reference JAR really only covers the case where the client
hosts the request object at some HTTPS URL that it controls and the value
of that URL is the request_uri. PAR defines how the AS can host/hold the
authorization request data and how a client can deliver it directly to the
AS.



>
>
> PAR defines how the client uploads the request object and how to obtain
> the reference. It relies primarily on TLS to protect the communication bu=
t
> mentions that it is possible to also use the JWT-based approach suggested
> by JAR.
>

Primarily TLS but also client authentication. A JWT request object can also
be used.


>
> Both drafts claim to have solved the security issues of protecting the
> communication through the user agent.
>

JAR is really the one that solved that. PAR provides a simple interoperable
way for a client to use JAR's request_uri by 'pushing' the content of an
authorization request directly to the AS and getting a request_uri
reference value in exchange.


>
>
> Is this a correct summary?
>

I think so, yes, along with my notes/clarifications.

--=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._

--0000000000006c9c1c05b3c2ecff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 10, 2020 at 2:44 AM Hanne=
s Tschofenig <Hannes.Tschof=
enig@arm.com> wrote:











Hi all, 


=C2=A0


I am in the process of writing my shepherd write-up =
for the PAR document and wanted to make sure that I properly understand the=
 document.



The introduction says: 


=C2=A0


=E2=80=9C


=C2=A0


=C2=A0=C2=A0 This document [PAR]
complements JAR by providing an interoperable way to


=C2=A0=C2=A0 push the payload of an authorization request di=
rectly to the


=C2=A0=C2=A0 authorization server in exchange for a "re=
quest_uri" value usable at


=C2=A0=C2=A0 the authorization server in a subsequent author=
ization request.


=E2=80=9C


=C2=A0


JAR provides the ability to send Authorization Reque=
st parameters in a JWT format protected with JWS and optionally JWE. It all=
ows the JAR to be conveyed by value and by reference but does not define ho=
w the client would upload the JAR
 and how to obtain the reference. 

For pass-by-reference JAR really only covers the case where the cli=
ent hosts the request object at some HTTPS URL that it controls and the val=
ue of that URL is the request_uri. PAR defines how the AS can host/hold the=
 authorization request data and how a client can deliver it directly to the=
 AS. 

=C2=A0


=C2=A0


PAR defines how the client uploads the request objec=
t and how to obtain the reference. It relies primarily on TLS to protect th=
e communication but mentions that it is possible to also use the JWT-based =
approach suggested by JAR. =C2=A0=C2=A0
Primarily TLS but also client authentication. A JWT request ob=
ject can also be used.



=C2=A0


Both drafts claim to have solved the security issues=
 of protecting the communication through the user agent.

JAR is really the one that solved that. PAR p=
rovides a simple interoperable way for a client to use JAR's request_ur=
i by 'pushing' the content of an authorization request directly to =
the AS and getting a request_uri reference value in exchange.=C2=A0 
<=
div>=C2=A0


=C2=A0


Is this a correct summary? 

I think so, yes, along with my notes/clarificat=
ions.=C2=A0 




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000006c9c1c05b3c2ecff--


From nobody Tue Nov 10 12:25:31 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53843A0F2F for ; Tue, 10 Nov 2020 12:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DniCjIa2mG4K for ; Tue, 10 Nov 2020 12:25:27 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DEF3A0F49 for ; Tue, 10 Nov 2020 12:25:26 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id c9so4480045wml.5 for ; Tue, 10 Nov 2020 12:25:26 -0800 (PST)
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; bh=AAc/u2TL/9O2muMAEc/nnrVXv2QTu7YYT++VIs19tAc=; b=Anvew7d0DXSsDE6jXS7B3EqO8CljlyODeng/jxPsRpmhlQ8THJKwWTALN1YXaM3VFk SJs2koUQhB66g+4ZoBfuaIR/qlSMy3JRMNWAZkOnW25JXPwoFkGTvansmwWs0Xgj++eg 79uU+h+SYCCGKwfmx9MNRMj72LkxdVUU9Cdbe4Gv6OJfTSV+mWUrrf1OlWIeKlivrDzU FJjH8fXkaj6Qq7UYxvWEUYwim81Kwm9/88lIpU10jedkBad3+u8iOCkrPKfysk3Rz90w a2icJA6RjjhJWLcPwyfRLynTgEdZkuAf88PPwZkX6docZ9cqV5+vi0WHbLLfS85slgU+ OIeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AAc/u2TL/9O2muMAEc/nnrVXv2QTu7YYT++VIs19tAc=; b=BYw+/scDjKFQLflwt9RejyS+n+pdjZ+8W2/UizXCUn3V3fcrL5N1ACk3s6cBnyDrnE V+FU4fNYEhpNN5twNm5KXmmFq0vg9C8WXsXobikhDvbqotG7h0jLnOOefPfYE47AMS9n Dp9epbA4AGGJ/3NBeXuGbutSFGmsz3Yqqm4QjXFUyQB/d9WuvE5qC/MI6IZmyGxFtWQi 9PzU3SyaytqthciUSrzVYWF2/A2tafI2Y3+jngXbG7+Km9oE3Dmh+brUvdE340mvGN1T MVZX6MF9TpvvtK7gOdin39uNgPlBm4X5PYKlv6ds3TUqz7bwusXB9z5sbW380mI4/X9w enuQ==
X-Gm-Message-State: AOAM530FBDF6om1QtFtO8QH5wfSPqXQVYwYfsms0YBZd+IDL66MqoSiS G4l7fHSBYYdomP3SFDg7XxGzSEN+9CU6vEm1QsOP0i1zIqg=
X-Google-Smtp-Source: ABdhPJz4vtm90qrBa8Ul0q+Gm7yetH8c6psuh4Am2w3hiT+o8PNFBJm+L0HuOG8RVuccJu5e5XwnZzDW3/UeuYP+OmY=
X-Received: by 2002:a1c:5f45:: with SMTP id t66mr907080wmb.132.1605039924367;  Tue, 10 Nov 2020 12:25:24 -0800 (PST)
MIME-Version: 1.0
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>   <69B0850B-D863-4792-905E-54EE20823323@authlete.com>   <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com>
In-Reply-To: <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com>
From: Takahiko Kawasaki 
Date: Wed, 11 Nov 2020 05:25:13 +0900
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000008aef7705b3c67a14"
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Nov 2020 20:25:30 -0000

--0000000000008aef7705b3c67a14
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Vladimir,

Good point. Considering the similarity to JAR (JWT Secured Authorization
Response), if we apply the same logic, our discussion will eventually reach
"response parameters outside the response JWT are almost meaningless in the
context of JARM". For interoperability and simplicity, it may be good to
say "MUST NOT" as you suggested.

Taka

On Mon, Nov 9, 2020 at 10:26 PM Vladimir Dzhuvinov 
wrote:

> Re Case 1: When JARM is used:
>
> A colleague pointed me to the following statement in the JARMs spec, so
> I'd suggest to say the "iss" MUST NOT be included when JARM is used:
>
>
> https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-respon=
se-mode
>
> All response parameters defined for a given response type are conveyed in
> a JWT
>
> Now, there isn't a proper normative keyword in this JARM spec sentence, s=
o
> I guess some may interpret this as a strong check for no other query
> params, while others may not. Hence the MUST NOT to prevent potential
> unintended errors.
>
> What are your thoughts on this?
>
> Vladimir
> On 06/11/2020 23:34, Takahiko Kawasaki wrote:
>
> I implemented the draft quickly and found no big hurdle for authorization
> server implementations. The current snapshot of my implementation does no=
t
> add the `iss` parameter when JARM is used. However, for interoperability,=
 I
> feel that the spec should describe expected behaviors when a JWT is
> included in an authorization response. The following is an implementer's
> comment for some cases.
>
> Case 1: When JARM is used
>
> An `iss` claim is included in the response JWT as one of top-level entrie=
s
> together with response parameters. It is not so unnatural to regard the
> `iss` claim as a response parameter. Conclusion would be "When JARM is
> used, the `iss` parameter is not necessary."
>
> Case 2: When an ID token is issued
>
> It is unnatural to regard the `iss` claim in an ID token as a response
> parameter. However, because FAPI Part 2 has already been using an ID toke=
n
> as detached signature for integrity protection, it would be difficult to
> find a convincing reason to prohibit using the `iss` claim in an ID token
> as a countermeasure to mix-up attacks. Conclusion would be "When an ID
> token is issued, the `iss` parameter is not necessary."
>
> Case 3: When an unencrypted JWT access token is issued
>
> It is technically possible to use the `iss` claim in an unencrypted JWT
> access token as the `iss` parameter. However, requiring the client to che=
ck
> the `iss` claim means "The access token is no longer opaque to the client=
."
> Conclusion would be "Even when an access token is issued and its format i=
s
> JWT, the `iss` parameter is necessary."
>
> BTW, I found that a certain system raises an error when an unknown
> response parameter (that is, the `iss` parameter) is included in error
> authorization responses. To ask the administrator of the system to regard
> the `iss` parameter as a known one, at least the spec draft needs to be
> adopted by the community as a working draft. I hope that "call for
> adoption" for the draft will be conducted soon.
>
> Best Regards,
> Taka
>
> On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki 
> wrote:
>
>> It sounds that the Security Considerations section or somewhere
>> appropriate should have a paragraph like below.
>>
>> When an authorization response includes a JWT whose `iss` claim
>> represents the issuer identifier of the authorization server, the `iss`
>> claim can be used as a substitute for the `iss` parameter. Therefore, su=
ch
>> authorization response does not have to have the `iss` parameter outside
>> the JWT separately. Examples of such JWTs include the value of the
>> `id_token` parameter in OIDC and the value of `response` parameter in JA=
RM.
>>
>> Taka
>>
>> On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan 
>> wrote:
>>
>>> I agree, it is in redundant in the JARM case.
>>>
>>> I find the text in
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-r=
esp-01.html#name-security-considerations
>>> (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I
>>> think it would be good to say something along the lines of:
>>>
>>> Although integrity protection is not necessary to prevent mixup, any
>>> authorization response method that includes a JWT with an =E2=80=98iss'=
 (for
>>> example, JARM or OIDC hybrid flow) will prevent the attack (assuming th=
e
>>> client is validating the iss).
>>>
>>>
>>> I=E2=80=99m not entirely sure I understand what "MUST NOT allow multipl=
e
>>> authorization servers to return the same issuer identifier during
>>> registration=E2=80=9D means as I don=E2=80=99t think https://tools.ietf=
.org/html/rfc7591
>>> returns the issuer?
>>>
>>> It might be clearer to say something like =E2=80=9CWhen
>>> https://tools.ietf.org/html/rfc8414 is used the client MUST implement
>>> the validation described in
>>> https://tools.ietf.org/html/rfc8414#section-3.3. When authorization
>>> server details can be manually configured in the client, the client mus=
t
>>> verify that all issuer values are unique.=E2=80=9D (Or at least somethi=
ng along
>>> those lines, I=E2=80=99m sure my wording can be improved. But if the cl=
ient is
>>> correctly implementing rfc8414 or OIDC discovery [and does not have any
>>> manually configured authorization servers] then there=E2=80=99s no requ=
irement for
>>> any further checks that the issuer is unique.)
>>>
>>> Joseph
>>>
>>>
>>> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov 
>>> wrote:
>>>
>>> This can potentially occur. If JARM is used "iss" becomes redundant. To
>>> me JARM is an "enhanced" iss.
>>>
>>> If both are included a sensible client should make sure the iss and the
>>> JARM iss match.
>>>
>>> My suggestion is to not require iss when a JARM is present, but in case
>>> both do occur to have the client check both.
>>>
>>> Vladimir
>>> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>>>
>>> Hi Karsten,
>>>
>>> The specification mentions JARM. Does this specification require the is=
s
>>> response parameter even when JARM is used? That is, should an authoriza=
tion
>>> response look like below?
>>>
>>> HTTP/1.1 302 Found
>>> Location: https://client.example.com/cb?response=3D{JWT}&iss=3D{ISSUER}
>>>
>>> Or, can the iss response parameter be omitted when JARM is used?
>>>
>>> A small feedback for the 3rd paragraph in Section 4:
>>> s/identifes/identifies/
>>>
>>> Best Regards,
>>> Taka
>>>
>>>
>>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov <
>>> vladimir@connect2id.com> wrote:
>>>
>>>> Thanks Karsten, looks good to me now, no further comments.
>>>>
>>>> Vladimir
>>>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Daniel and I published a new version of the "iss" response parameter
>>>> draft to address the feedback from the WG.
>>>>
>>>> Changes in -01:
>>>>
>>>>    - Incorporated first WG feedback
>>>>    - Clarifications for use with OIDC
>>>>    - Added note that clients supporting just one AS are not vulnerable
>>>>    - Renamed metadata parameter
>>>>    - Various editorial changes
>>>>
>>>>
>>>> We would like to ask you for further feedback and comments on the new
>>>> draft version.
>>>>
>>>> Best regards,
>>>> Karsten
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: New Version Notification for
>>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>> Date: Sun, 01 Nov 2020 23:31:42 -0800
>>>> From: internet-drafts@ietf.org
>>>> To: Karsten Meyer zu Selhausen 
>>>> , Karsten zu Selhausen
>>>> 
>>>> , Daniel Fett
>>>>  
>>>>
>>>>
>>>> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.tx=
t
>>>> has been successfully submitted by Karsten Meyer zu Selhausen and
>>>> posted to the
>>>> IETF repository.
>>>>
>>>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>>> Revision: 01
>>>> Title: OAuth 2.0 Authorization Server Issuer Identifier in
>>>> Authorization Response
>>>> Document date: 2020-11-01
>>>> Group: Individual Submission
>>>> Pages: 10
>>>> URL:
>>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-=
resp-01.txt
>>>> Status:
>>>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth=
-resp/
>>>> Html:
>>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-=
resp-01.html
>>>> Htmlized:
>>>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp=
-01
>>>> Diff:
>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-a=
uth-resp-01
>>>>
>>>> Abstract:
>>>> This document specifies a new parameter "iss" that is used to
>>>> explicitly include the issuer identifier of the authorization server
>>>> in the authorization response of an OAuth authorization flow. If
>>>> implemented correctly, the "iss" parameter serves as an effective
>>>> countermeasure to "mix-up attacks".
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> --
>>>> Karsten Meyer zu Selhausen
>>>> IT Security Consultant
>>>> Phone:	+49 (0)234 / 54456499
>>>> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testin=
g, Security Training
>>>>
>>>> Does your OAuth or OpenID Connect implementation use PKCE to strengthe=
n the security? Learn more about the procetion PKCE provides and its limita=
tions in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkc=
e-cannot-protect-your-confidential-oauth-client
>>>>
>>>> Hackmanit GmbH
>>>> Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
>>>> 44789 Bochum
>>>>
>>>> Registergericht: Amtsgericht Bochum, HRB 14896
>>>> Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Jura=
j Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/=
oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000008aef7705b3c67a14
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Vladimir,

Good point. Considering th=
e similarity to JAR (JWT Secured Authorization Response), if we apply the s=
ame logic, our discussion will eventually reach "response parameters o=
utside the response JWT are almost meaningless in the context of JARM"=
. For interoperability and simplicity, it may be good to say "MUST NOT=
" as you suggested.

Taka

On Mon, Nov 9, =
2020 at 10:26 PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

 =20
   =20
 =20
  

    
Re Case 1: When JARM is used:

    
A colleague pointed me to the following statement in the JARMs
      spec, so I'd suggest to say the "iss" MUST NOT be inclu=
ded when
      JARM is used:

    

    
https://openid.net//specs/openid=
-financial-api-jarm.html#jwt-based-response-mode

    

      
All response parameters defined for a
        given response type are conveyed in a JWT

    

    
Now, there isn't a proper normative keyword in this JARM spec
      sentence, so I guess some may interpret this as a strong check for
      no other query params, while others may not. Hence the MUST NOT to
      prevent potential unintended errors.

    
What are your thoughts on this?

    

    
Vladimir

    

    
On 06/11/2020 23:34, Takahiko Kawasaki
      wrote:

    

    

     =20
      
I implemented the draft quickly and found no big
        hurdle for authorization server implementations. The current
        snapshot of my implementation does not add the `iss` parameter
        when JARM is used. However, for interoperability, I feel that
        the spec should describe expected behaviors when a JWT is
        included in an authorization response. The following is an
        implementer's comment for some cases.

        

        Case 1: When JARM is used

        

        An `iss` claim is included in the response JWT as one of
        top-level entries together with response parameters. It is not
        so unnatural to regard the `iss` claim as a response parameter.
        Conclusion would be "When JARM is used, the `iss` parameter is
        not necessary."

        

        Case 2: When an ID token is issued

        

        It is unnatural to regard the `iss` claim in an ID token as a
        response parameter. However, because FAPI Part 2 has already
        been using an ID token as detached signature for integrity
        protection, it would be difficult to find a convincing reason to
        prohibit using the `iss` claim in an ID token as a
        countermeasure to mix-up attacks. Conclusion would be "When an
        ID token is issued, the `iss` parameter is not necessary."

        

        Case 3: When an unencrypted JWT access token is issued

        

        It is technically possible to use the `iss` claim in an
        unencrypted JWT access token as the `iss` parameter. However,
        requiring the client to check the `iss` claim means "The acces=
s
        token is no longer opaque to the client." Conclusion would be
        "Even when an access token is issued and its format is JWT, th=
e
        `iss` parameter is necessary."

        

        BTW, I found that a certain system raises an error when an
        unknown response parameter (that is, the `iss` parameter) is
        included in error authorization responses. To ask the
        administrator of the system to regard the `iss` parameter as a
        known one, at least the spec draft needs to be adopted by the
        community as a working draft. I hope that "call for adoption&q=
uot;
        for the draft will be conducted soon.

        

        Best Regards,

        Taka

      

      

      

        
On Wed, Nov 4, 2020 at 4:46 A=
M
          Takahiko Kawasaki <taka@authlete.com> wrote:

        

        

          
It sounds that the Security Considerations
            section or somewhere appropriate should have a paragraph
            like below.

            

            When an authorization response includes a JWT whose `iss`
            claim represents the issuer identifier of the authorization
            server, the `iss` claim can be used as a substitute for the
            `iss` parameter. Therefore, such authorization response does
            not have to have the `iss` parameter outside the JWT
            separately. Examples of such JWTs include the value of the
            `id_token` parameter in OIDC and the value of `response`
            parameter in JARM.

            

            Taka

          

          

          

            
On Tue, Nov 3, 2020 at
              10:46 PM Joseph Heenan <joseph@authlete.com>
              wrote:

            

            

              
I agree, it is in redundant in the JARM case.
                


                

                
                


                

                
Although integrity protection is not necessary to
                  prevent mixup, any authorization response method that
                  includes a JWT with an =E2=80=98iss' (for example, JA=
RM or
                  OIDC hybrid flow) will prevent the attack (assuming
                  the client is validating the iss).

                


                

                


                

                
                


                

                
It might be clearer to say something like =E2=80=9CWhe=
n https:/=
/tools.ietf.org/html/rfc8414
                  is used the client MUST implement the validation
                  described in https://tools.ietf.org/html/rfc8414#secti=
on-3.3.
                  When authorization server details can be manually
                  configured in the client, the client must verify that
                  all issuer values are unique.=E2=80=9D (Or at least somet=
hing
                  along those lines, I=E2=80=99m sure my wording can be
                  improved. But if the client is correctly implementing
                  rfc8414 or OIDC discovery [and does not have any
                  manually configured authorization servers] then
                  there=E2=80=99s no requirement for any further checks tha=
t the
                  issuer is unique.)

                


                

                
Joseph

                


                  


                    

                      
On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov
                        <vladimir@connect2id.com>
                        wrote:

                      

                      

                        

                          
This can potentially occur. If JARM is used
                            "iss" becomes redundant. To me JARM i=
s an
                            "enhanced" iss.

                          
If both are included a sensible client
                            should make sure the iss and the JARM iss
                            match.

                          
My suggestion is to not require iss when a
                            JARM is present, but in case both do occur
                            to have the client check both.

                          

                          
Vladimir

                          

                          
On 02/11/2020 22:34, Takahiko Kawasaki
                            wrote:

                          

                          

                            
Hi Karsten,
                              


                              

                              
The specification mentions JARM. Does
                                this specification require the iss
                                response parameter even when JARM is
                                used? That is, should an authorization
                                response look like below?

                              


                              

                              
HTTP/1.1 302 Found

                              
                              


                              

                              
Or, can the iss response parameter be
                                omitted when JARM is used?

                              


                              

                              
A small feedback for the 3rd
                                paragraph in Section 4:
                                s/identifes/identifies/

                              


                              

                              
Best Regards,

                              
Taka

                              
=C2=A0

                            

                            

                            

                              
On Tue,
                                Nov 3, 2020 at 3:13 AM Vladimir
                                Dzhuvinov <vladimir@connect2id.com>
                                wrote:

                              

                              

                                

                                  
Thanks Karsten, looks good to me
                                    now, no further comments.

                                  

                                  
Vladimir

                                  

                                  
On 02/11/2020 09:54, Karsten
                                    Meyer zu Selhausen wrote:

                                  

                                  

                                    
Hi all,

                                    
Daniel and I published a
                                        new version of the "iss"
                                        response parameter draft to
                                        address the feedback from the
                                        WG.

                                    
Changes in -01:

                                    
    
                                      
  • Incorporated first WG
                                          feedback
    • 
                                      
  • Clarifications for use
                                          with OIDC
    • 
                                      
  • Added note that clients
                                          supporting just one AS are not
                                          vulnerable
    • 
                                      
  • Renamed metadata
                                          parameter
    • 
                                      
  • Various editorial
                                          changes
    
                                        
    • 
                                    

                                    


                                      We would like to ask
                                            you for further feedback and
                                            comments on the new draft
                                            version.

                                          

                                    


                                      

                                    
Best regards,

                                    
Karsten

                                    


                                    

                                    
-------- Forwarded Message
                                      --------
                                      

                                        
                                          

                                            Subject: 
                                            New Version Notification
                                              for
                                              draft-meyerzuselhausen-oauth-=
iss-auth-resp-01.txt
                                          

                                          

                                            Date: 
                                            Sun, 01 Nov 2020
                                              23:31:42 -0800
                                          

                                          

                                            From: 
                                            internet-drafts@ietf.org
                                          

                                          

                                            To: 
                                            Karsten Meyer zu
                                              Selhausen <karsten.meyerzu=
selhausen@hackmanit.de>,
                                              Karsten zu Selhausen <kar=
sten.meyerzuselhausen@hackmanit.de>,
                                              Daniel Fett <mail@danielfett.de>
                                          

                                        
                                      

                                      

                                      

                                      

                                      A new version of I-D,
                                      draft-meyerzuselhausen-oauth-iss-auth=
-resp-01.txt

                                      has been successfully submitted by
                                      Karsten Meyer zu Selhausen and
                                      posted to the

                                      IETF repository.

                                      

                                      Name:
                                      draft-meyerzuselhausen-oauth-iss-auth=
-resp

                                      Revision: 01

                                      Title: OAuth 2.0 Authorization
                                      Server Issuer Identifier in
                                      Authorization Response

                                      Document date: 2020-11-01

                                      Group: Individual Submission

                                      Pages: 10

                                      URL: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-=
resp-01.txt

                                      Status: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-r=
esp/

                                      Html: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-aut=
h-resp-01.html

                                      Htmlized: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01=


                                      Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-=
auth-resp-01

                                      

                                      Abstract:

                                      This document specifies a new
                                      parameter "iss" that is use=
d to

                                      explicitly include the issuer
                                      identifier of the authorization
                                      server

                                      in the authorization response of
                                      an OAuth authorization flow. If

                                      implemented correctly, the "iss&=
quot;
                                      parameter serves as an effective

                                      countermeasure to "mix-up
                                      attacks".

                                      

                                      

                                      

                                      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

                                      

                                      

                                    

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the=
 security? Learn more about the procetion PKCE provides and its limitations=
 in our new blog post:
https://www.hackmanit.de=
/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

                                    

                                    

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


                                  

                                

_______________________________________________

                                OAuth mailing list

                                OAuth@ietf.org

                                https://www.ietf.org/mail=
man/listinfo/oauth

                              

                            

                          

                          

                        

                        _______________________________________________

                        OAuth mailing list

                        OAuth@ietf.org

                        https://www.ietf.org/mailman/listinfo/oauth

                      

                    

                  

                  

                

              

              _______________________________________________

              OAuth mailing list

              OAuth@iet=
f.org

              https://www.ietf.org/mailman/listinfo/oau=
th

            

          

        

      

      

      

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


    

    
--=20
Vladimir Dzhuvinov

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--0000000000008aef7705b3c67a14--


From nobody Wed Nov 11 10:13:51 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955533A10D2 for ; Wed, 11 Nov 2020 10:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnmizD_Lpje1 for ; Wed, 11 Nov 2020 10:13:48 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6593A11F7 for ; Wed, 11 Nov 2020 10:07:49 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id s8so3393846wrw.10 for ; Wed, 11 Nov 2020 10:07:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=QXaUat/GNCHOtOHXqSzSt92F6PndpWR8F2vdxrhzL0g=; b=M0tXiNad0+s+oKNZlg6szHcLk+BlvcCEKssgAel/2sKWnlA+nBdU30FbIlUNOLphFw 4um/xv+nHZD/pCy+z1nlhrclEq33FbSVrx5HqbOllN1FAe1hh0bgkyF+QDhcIUb0zn88 USSIyV/CW+4W53D+equr1The8c8UoH8I2PxdIXXNYJoUALbw3GeZnslITx1jz8lgywOq pDAn3ONv4yII4fzzUZtwvOjBdhY27Db4367JOGwOde5IpzsaqIcpmDJoOcKgkb4L1+Sb CL0Cuad/byT8v85r9OfuyGQuocZSbo9+CB9up1IeYrTLdZymlKekCuNC8tPdrFiJOJEw 0/vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=QXaUat/GNCHOtOHXqSzSt92F6PndpWR8F2vdxrhzL0g=; b=Z7KU74bGazMHwgi7G1wh0hN26yEbGdSS3pN8o+09SNMHYwcYutXkuNRp9nc8bfHu+B d+bHII3yv0kPzoIcdN9ZORrkyOkgaoU6gYnF+ML5YnsSYlUvG9oMFalBDrtMdA7plLgo R/GbdNmRb0v6xtxP0eprz/izQ4r85J5Kt0IHYhKf1z7SMZsvkNn94CemWHxRKLgTNB7k c63ZPLu1GQlhAQ3K90jLcZIwuStIU/zeqUTrjdZ47ZBtnSUL0mbrA7oBJa7M9eiHOvEF BqFN5/y90BnWX6WmURuZCJ0Xy7A6EYZzxUsZzfqVpzAcLB1C4OP3BXTvG9hSn0ZeFU5d fPqA==
X-Gm-Message-State: AOAM533xTQMBHq81UeHWFpXIhSjZVhQkFOSgea89P6CFS1B1N4MZbyU+ yjHdkgG+8kapWg2FpbaHDAvQe8bfsN56DpHFPVFaka4P
X-Google-Smtp-Source: ABdhPJwOFXzb+qsJGlLLWu9VQggtkXIrm7+u/zJt93OyMqnFXnu5cuvrFdP9T+rUOG+rw30NF8WzWY4NtHupPG0AZKo=
X-Received: by 2002:a2e:90c1:: with SMTP id o1mr6800783ljg.130.1605117585133;  Wed, 11 Nov 2020 09:59:45 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Wed, 11 Nov 2020 12:59:34 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000007c12e805b3d88f33"
Archived-At: 
Subject: [OAUTH-WG] Fwd: Requesting NomCom feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Nov 2020 18:13:50 -0000

--0000000000007c12e805b3d88f33
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All,

Please, consider providing feedback to the NomCom.
Take a look at the following message from the NomCom chair for more details=
.

Regards,
 Rifaat & Hannes

----------------------------
NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC
Board, and IETF Trust. We need more input from the community both on
specific nominees and on over-arching topics regarding what the community
wants from these specific groups and wants from its leadership in general.
We need *your* input.

** Deadline for community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues raised there
have been brought up in interviews.

We've also asked questions of nominees based on feedback received, and
based on the "Topics" that people said were important.
We're listening to you.

But most of the input to date has come from a few consistently vocal
people. We need to hear from more of you.

I scheduled our office hours during the 2 weeks before next week's IETF,
because IETF week is so busy. We have one more left (18:00-19:00 UTC
November 11). No-one but NomCom members showed up for our first 3. =E2=98=
=B9 If
there is demand for more office hours, I'll schedule them; but this really
doesn't seem to be the preferred format for input.

Most input is coming in as either
 - email to nomcom20@ietf.org
 - feedback on https://datatracker.ietf.org/nomcom/2020/feedback/
On the feedback page, the specific nominees are all listed at the top.
General Topics are at the bottom.
We pay attention to all the comments we get through these channels.

I'll also try to hang out in Gather.Town during IETF breaks next week.
I'm not going to have a specific NomCom area in Gather.Town, because it was
really lonely hanging out there during IETF 108.
But please feel free to hunt me down and bend my ear -- on NomCom issues or
just to chat.
I miss seeing all of y'all!
Barbara

Barbara Stark
NomCom 2020 Chair

--0000000000007c12e805b3d88f33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,<=
/div>

Please, =
consider providing feedback to the NomCom.=C2=A0
Take a look at the following message from the NomCom chair for more de=
tails.

R=
egards,
=C2=A0Rifaat & Hannes

------------------=
----------

NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board=
, and IETF Trust. We need more input from the community both on specific no=
minees and on over-arching topics regarding what the community wants from t=
hese specific groups and wants from its leadership in general. We need *you=
r* input.



** Deadline for community feedback is Friday November 20. **



We've paid attention to discussions on the ietf list. Issues raised the=
re have been brought up in interviews.



We've also asked questions of nominees based on feedback received, and =
based on the "Topics" that people said were important.

We're listening to you. 



But most of the input to date has come from a few consistently vocal people=
. We need to hear from more of you.



I scheduled our office hours during the 2 weeks before next week's IETF=
, because IETF week is so busy. We have one more left (18:00-19:00 UTC Nove=
mber 11). No-one but NomCom members showed up for our first 3. =E2=98=B9 If=
 there is demand for more office hours, I'll schedule them; but this re=
ally doesn't seem to be the preferred format for input.



Most input is coming in as either 

=C2=A0- email to nom=
com20@ietf.org

=C2=A0- feedback on https://datatracker.ietf.org/n=
omcom/2020/feedback/

On the feedback page, the specific nominees are all listed at the top. Gene=
ral Topics are at the bottom.

We pay attention to all the comments we get through these channels.



I'll also try to hang out in Gather.Town during IETF breaks next week. =


I'm not going to have a specific NomCom area in Gather.Town, because it=
 was really lonely hanging out there during IETF 108.

But please feel free to hunt me down and bend my ear -- on NomCom issues or=
 just to chat.

I miss seeing all of y'all!

Barbara



Barbara Stark

NomCom 2020 Chair












--0000000000007c12e805b3d88f33--


From nobody Thu Nov 12 13:31:24 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2262F3A0995 for ; Thu, 12 Nov 2020 13:31:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level: 
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ITbKrIwtGobO for ; Thu, 12 Nov 2020 13:31:19 -0800 (PST)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 76BEE3A0989 for ; Thu, 12 Nov 2020 13:31:19 -0800 (PST)
Received: by mail-yb1-xb34.google.com with SMTP id v92so6765729ybi.4 for ; Thu, 12 Nov 2020 13:31:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zQRBe0Vf5I79WKmNp8dZTDCnJqSm30AXPWOYesmY6zE=; b=qfMkiv0KPAcUlTY0dVuLMSmNZiEPDm8A5CsgBVneSGeC64BGZAjaEpBPhZsHb7QFpy Akadf2qfNC+1067dXIgVw0cp7N3v/OFINLbnBp/TVTGjgIPFwG+pLOuTqc28JBxajFQw 3tZGdZ1FLzej9m0iVZ+CEuHJgdoDLlYg1npmCG73PDLmKPB6QB3CrzwRovhjE9uH3KkB eSvhGB+DXPzp+ZZHnSqX7NxcHT7L1YT4Pmk5D0yZFcNPpAGUos/C2uQ2UQPg1QJEvqBC o8sXV18aioq/EAbtW1nHbhl2ti4eRg6UiRx4GN2QyrS3oZIaWdCHBxsoxbA30hlsQQv9 nDFA==
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=zQRBe0Vf5I79WKmNp8dZTDCnJqSm30AXPWOYesmY6zE=; b=n8ESjaHURUVpuTPCT3nHL3TMnFwjjFYD6mi9aareu9QyTCK3IVM/hVbIdq4RnA9056 zGqA+0miJZSmbMfo8OrAZ44k0cwdv/RRJVHgwOuHR1KGya+vQGy9hhnka501wkDN0OH6 CkjOAmYaKdv3TgvUHRhoODMphyyvbW6MzPs7E/uGA8zIH7ev3N9QvZ9x5jC+vb0yJt6f JJ4/x7tT/PYRw/Pycy5SfK3FVNiI30R7RH21RPiGTnpM9Ji3F2Qoj+Ro1rEVbgTpGZYt j5GfDWuJHCByW1h0+XcMylb6sZLyq1PxiK8Dh2y3wvcqJ9xVLU2Etfh0aSX+nCUmYzYH fbLw==
X-Gm-Message-State: AOAM531+2Ichp1AIz04ysBoqbEG7JuGgz3uL5OfU16mHdWuHHcz/q24H sukzKq/opSon/d3FT70oVCY+W+csYcgroVv66lN5/Zs9+wI=
X-Google-Smtp-Source: ABdhPJwqBWEWcdAVVa1SldkIlYC+QzE5WRZYYfFvwfe32/147GN0IHIqWFjlHyBnoIPo/zHTkl0VUqto2oiVcjl0uH8=
X-Received: by 2002:a25:558b:: with SMTP id j133mr2211575ybb.224.1605216678228;  Thu, 12 Nov 2020 13:31:18 -0800 (PST)
MIME-Version: 1.0
From: Jeff Craig 
Date: Thu, 12 Nov 2020 15:31:07 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000e520b205b3efa17b"
Archived-At: 
Subject: [OAUTH-WG] Examples of Auth with Profiles
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, 12 Nov 2020 21:31:22 -0000

--000000000000e520b205b3efa17b
Content-Type: text/plain; charset="UTF-8"

Hello OAuth WG,

I am currently doing some research on APIs that have a Profile concept,
something akin to Netflix's profile support where there is a single account
with multiple sub-profiles. I am trying to determine how current APIs
handle this use case, and evaluate any common patterns or practices that
may exist today.

Thanks.

--000000000000e520b205b3efa17b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello OAuth WG,

I am currently doing so=
me research=C2=A0on APIs that have a Profile concept, something akin to Net=
flix's profile support where there is a single account with multiple su=
b-profiles. I am trying to determine how current APIs handle this use case,=
 and evaluate any common patterns or practices that may exist today.
<=
div>
Thanks.


--000000000000e520b205b3efa17b--


From nobody Thu Nov 12 15:10:22 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FFB3A0FF6 for ; Thu, 12 Nov 2020 15:10:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.994
X-Spam-Level: 
X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2J-YJzbmy4Mu for ; Thu, 12 Nov 2020 15:10:14 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 36A423A1043 for ; Thu, 12 Nov 2020 15:10:09 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id j205so11033339lfj.6 for ; Thu, 12 Nov 2020 15:10:09 -0800 (PST)
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=k+FrJa7/miX4/O/swPcY3izG+UXHBSNgye+/pL+UPKM=; b=pTMt6yE+4DmLy4Um3UOaAAWyuCMYG9ZbO3P0ayE7KHyfLMTCWAaOugCYCAT4kQHO+q /4ydgWh+fuomCHObJ2I43w8LqTfmZ2y8DhYQVVi2QeoCIm8uMQH+nNgrxlIX/8zFdv/e GXhozrazzEBUf5u0bx9YvMdtWXbmt+ROVq6HTHzHmvW9eUDSxD3pSv2rmJrB9fQJLSCx pL7qQZeBQN629ccXLhfow5qbZ7906VUWrPS8/vpWKNxML9uGDXoi+ECm+GYOFjbgqJrd TuKx1r4UQHVWbc9THI7i/54ExwVBdzliLntmkmX5SlTkOiEecXOlROaDEeLsxdc0PsJ6 Ju9A==
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=k+FrJa7/miX4/O/swPcY3izG+UXHBSNgye+/pL+UPKM=; b=f7nl6l/derri+SqNFbwSopCet0a3HDp3gRyi9b5lMq17Jr9lGnwgv4JrrhsCMCg3q2 6GHrVzn7zc3pHi+Vu76BnDNu+k42JW+RSoeDJNAWKrB5VbIbNzxCAOY2526ouhHPTK1i 7h1pIo9SrKytcElme2lJPs2CtWINzzU6365tXfVRnlPHk9Cy4o7I1jwct5LkWAFPnslE domT+1I3+kw2ZzJH4YQr9Etd8So3TKE7S657lnHfb+2qW4WoBOXtHdIdhtT028IK7c0R KvL18hNnftelDt0lgDRE8EZZrEMfoVkjzZgiQ8hKFk+WHVTTi8DxnlKqA0PtDIm8HEw4 BhhQ==
X-Gm-Message-State: AOAM530RXLeSPWayAsXFLVjgDihrX7A5yZK4JmvXXvO8lWwi2gIqNWCm oAxyAHMD3hwn9M/673AEYSDrdNIaKWDL2FrRRiJeISMbNY4=
X-Google-Smtp-Source: ABdhPJzidtq6XhrkiFVJYYhthNPutnQQeWzgjg1WPmkO4NloJWmQzBoXlQG3fW1p2pbScIDs/cRVPvpsvNBL+6v0YD0=
X-Received: by 2002:a19:6e4c:: with SMTP id q12mr642893lfk.162.1605222606866;  Thu, 12 Nov 2020 15:10:06 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 12 Nov 2020 15:09:31 -0800
Message-ID: 
To: Jeff Craig 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000448ff805b3f103e5"
Archived-At: 
Subject: Re: [OAUTH-WG] Examples of Auth with Profiles
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, 12 Nov 2020 23:10:21 -0000

--000000000000448ff805b3f103e5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Since there is no security boundary between profiles, the profile is just
passed as a parameter to APIs rather than have it in the access token.


=E1=90=A7

On Thu, Nov 12, 2020 at 1:31 PM Jeff Craig  wrote:

> Hello OAuth WG,
>
> I am currently doing some research on APIs that have a Profile concept,
> something akin to Netflix's profile support where there is a single accou=
nt
> with multiple sub-profiles. I am trying to determine how current APIs
> handle this use case, and evaluate any common patterns or practices that
> may exist today.
>
> Thanks.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000448ff805b3f103e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Since there is no security boundary between profiles, the =
profile is just passed as a parameter to APIs rather than have it in the ac=
cess token.


3D""=E1=90=A7
On =
Thu, Nov 12, 2020 at 1:31 PM Jeff Craig <jeffcraig=3D40google.com@dmarc.ietf.org> wrote:
<=
/div>
Hel=
lo OAuth WG,

I am currently doing some research=C2=A0on =
APIs that have a Profile concept, something akin to Netflix's profile s=
upport where there is a single account with multiple sub-profiles. I am try=
ing to determine how current APIs handle this use case, and evaluate any co=
mmon patterns or practices that may exist today.

T=
hanks.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000448ff805b3f103e5--


From nobody Sun Nov 15 08:38:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548CA3A0876 for ; Sun, 15 Nov 2020 08:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R74L7A-JPR4L for ; Sun, 15 Nov 2020 08:38:50 -0800 (PST)
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 7D9983A0869 for ; Sun, 15 Nov 2020 08:38:49 -0800 (PST)
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 0AFGcmGn035392 for ; Sun, 15 Nov 2020 11:38:48 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 0AFGcmGn035392
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1605458328; bh=vnAtwLOsBjsdNn5vbbaK3je81UZ5Qtgm3PYpxQcqh6s=; h=From:To:Subject:Date:From; b=OcqMEhhn8/9jFzp6rFLT1RXL6FfiyKy5RakgF06SNpe+XY8/yn4VKdCTTpYETgp6F KlenP9rm2Fzf7yj2Ji58RkYDXocd+Sqn71lqy2zeDoaUNAMioty9uNv9lt9MtqR86X xxgfa0yr0GnfJFhTtihFmMbZjCGRDla9aVzDags0=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0AFGcm3n011812 for ; Sun, 15 Nov 2020 11:38:48 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sun, 15 Nov 2020 11:38:48 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Sun, 15 Nov 2020 11:38:48 -0500
From: Roman Danyliw 
To: "oauth@ietf.org" 
Thread-Topic: AD Review of draft-ietf-oauth-access-token-jwt-10
Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQ==
Date: Sun, 15 Nov 2020 16:38:45 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
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, 15 Nov 2020 16:38:52 -0000

Hi!

I conducted an AD review of draft-ietf-oauth-access-token-jwt-10.  Thanks f=
or the work in getting this document written.  My detailed feedback is belo=
w all are minor or editorial.

** Section 1.2.  Editorial.  Per "JWT access token   An OAuth 2.0 ...", may=
be put a colon between these two phrase to making it clearer that "JWT acce=
ss token" is being defined.

** Section 2.1.  As they are introduced here for the first time, provide a =
citation for OpenID Connect ID Tokens

** Section 2.2.  Typo. s/application.See/Application. See/

** Section 2.2.1.  Editorial.  Section 2.2 seems to list one, claim per lin=
e.  "acr" and "amr" are together.

** Section 2.2.2.  Editorial.  s/userinfo/UserInfo/

** Section 2.2.2.  Per "Any additional attributes whose semantics   Any add=
itional attributes whose semantics are well described by the attribute's de=
scription found in Section 5.1 of [OpenID.Core] SHOULD be codified in JWT a=
ccess tokens via the corresponding claim names in that section of the OpenI=
D Connect specification The same holds for  attributes defined in [RFC7662]=
 and other identity related specifications registering claims in the JSON W=
eb Token (JWT) IANA registry introduced in [RFC7519].", I didn't follow all=
 of the guidance here.

-- What does "... SHOULD be codified in JWT access tokens via the correspon=
ding claim names in that section of the OpenID Connect specification ..." m=
ean practically?  Is it that the those OpenId.Core claim names should be th=
e names used in this profile?

-- What does "... the same holds for attributes ... in the JSON Web Token (=
JWT) IANA registry ..." mean too?
Maybe my read it wrong, but it seems like this text saying that beyond the =
required claims listed in section 2.2, you can use any of the other claims =
as long as they are in the IANA JWT registry.  Isn't that simpler, since th=
e Section 5.1. OpenID.Core attributes are registered?

** Section 3.  What would be the case where it would not be appropriate for=
 the resource parameter value to be the same as the aud claim in the access=
 token (the text currently says SHOULD, why not MUST?)?

** Section 3.  Nit.  Move the trailing & from the second to third line, so =
this third link opens with "&state ..."

** Section 4.  Editorial. Per "For the purpose of facilitating validation d=
ata retrieval, it is ...", there is missing word here

** Section 4.  Please provide a reference to the "OpenID Connect discovery =
document"

** Section 4. Per the validation guidelines on access token validation, is =
there parallel text needed to discuss the RS use of the token say: checking=
 that the acr has a value that is appropriate (so it can have confidence in=
 the security of the authentication used between client/AS)? Or that the ri=
ght entitlements/groups/etc were present for the requested operation?

** Section 5.  Editorial.  The reference to [Oauth2.Security.BestPractices]=
 to cover the danger if clients selecting their own sub is in Section 4.14 =
(s/Section 4.13 of/Section 4.14 of/).

** Section 5.  This text seems to restate much of the text from [OAuth2.Sec=
urity.BestPractices].  Do other section apply here?  Perhaps also add that =
the SecCons of individual claims apply here too if used in the profile (as =
this profile allows pretty much anything in the JWT registry to be used).

** Appendix A.  Typo. s/lenght/length/

Regards,
Roman


From nobody Mon Nov 16 23:56:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84923A11BD for ; Mon, 16 Nov 2020 23:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA_G_SwNbh-u for ; Mon, 16 Nov 2020 23:56:07 -0800 (PST)
Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (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 A50B23A11AC for ; Mon, 16 Nov 2020 23:56:07 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id evqPkjvaxle7revqQk7AmA; Tue, 17 Nov 2020 00:56:07 -0700
X-CMAE-Analysis: v=2.4 cv=f6KNuM+M c=1 sm=1 tr=0 ts=5fb38217 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=ddEIn7SpAAAA:8 a=A1X0JdhQAAAA:8 a=9YbGl7VAAAAA:8 a=AGt6jbFzJ15_AqTjfE4A:9 a=ZzQglzhH7yfu32qe:21 a=58bV5VuECqQEJRzP:21 a=QEXdDO2ut3YA:10 a=idCLnkAckNQA:10 a=LBoxaBkYVh4A:10 a=13CRv-QaNUMA:10 a=pGLkceISAAAA:8 a=aZL1-Zqr0g_DdfdxC8cA:9 a=VqviYuB2Ter2sWrc:21 a=r7aulU3LGZCx6iQa:21 a=YxgiVD8eB8PxfBR3:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=0LcYgHMQs7_kImmFrmno:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=AcK2Xwxry4XOpw9gWFIK:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>   <69B0850B-D863-4792-905E-54EE20823323@authlete.com>   <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com> 
From: Vladimir Dzhuvinov 
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <61f07b70-f9b2-f5c3-19a2-122062ad1055@connect2id.com>
Date: Tue, 17 Nov 2020 09:56:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040302080401090304080507"
X-CMAE-Envelope: MS4xfNgUZHx5sJSB5JaBiaLflEFFk2FSU/3TbP8t0liEwDJpER+YzuP2WfkaHeW9dwcG5IhRebfO4zEjyGmH6XwGWSCTi7SYVeAIdRIKXA9wAcp8waaG1BAJ ExD1XScpt9X2v2ZFLO+IRkuhvT1pJo1evPTm7fy75RciIs2XiW9DxhvncgRNQR3JrwLXLTwUmXqIBA==
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Nov 2020 07:56:11 -0000

This is a cryptographically signed message in MIME format.

--------------ms040302080401090304080507
Content-Type: multipart/alternative;
 boundary="------------9D5469F03FBD79A74994286C"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------9D5469F03FBD79A74994286C
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Noting two unrelated comments that came up:

 1. The iss value in the example doesn't appear to be URL encoded:

    https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth=
-resp-01.html#name-example-authorization-respo


 2. There was the question from a developer whether error responses
    should also have the iss. I suggest the spec to be more explicit
    that iss is added to both success and error responses, and even
    include a second example, with an error response.

Vladimir

On 10/11/2020 22:25, Takahiko Kawasaki wrote:
> Hi Vladimir,
>
> Good point. Considering the similarity to JAR (JWT Secured
> Authorization Response), if we apply the same logic, our discussion
> will eventually reach "response parameters outside the response JWT
> are almost meaningless in the context of JARM". For interoperability
> and simplicity, it may be good to say "MUST NOT" as you suggested.
>
> Taka
>
> On Mon, Nov 9, 2020 at 10:26 PM Vladimir Dzhuvinov
> > wrote:
>
>     Re Case 1: When JARM is used:
>
>     A colleague pointed me to the following statement in the JARMs
>     spec, so I'd suggest to say the "iss" MUST NOT be included when
>     JARM is used:
>
>     https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-=
response-mode
>
>>     All response parameters defined for a given response type are
>>     conveyed in a JWT
>
>     Now, there isn't a proper normative keyword in this JARM spec
>     sentence, so I guess some may interpret this as a strong check for
>     no other query params, while others may not. Hence the MUST NOT to
>     prevent potential unintended errors.
>
>     What are your thoughts on this?
>
>     Vladimir
>
>     On 06/11/2020 23:34, Takahiko Kawasaki wrote:
>>     I implemented the draft quickly and found no big hurdle for
>>     authorization server implementations. The current snapshot of my
>>     implementation does not add the `iss` parameter when JARM is
>>     used. However, for interoperability, I feel that the spec should
>>     describe expected behaviors when a JWT is included in an
>>     authorization response. The following is an implementer's comment
>>     for some cases.
>>
>>     Case 1: When JARM is used
>>
>>     An `iss` claim is included in the response JWT as one of
>>     top-level entries together with response parameters. It is not so
>>     unnatural to regard the `iss` claim as a response parameter.
>>     Conclusion would be "When JARM is used, the `iss` parameter is
>>     not necessary."
>>
>>     Case 2: When an ID token is issued
>>
>>     It is unnatural to regard the `iss` claim in an ID token as a
>>     response parameter. However, because FAPI Part 2 has already been
>>     using an ID token as detached signature for integrity protection,
>>     it would be difficult to find a convincing reason to prohibit
>>     using the `iss` claim in an ID token as a countermeasure to
>>     mix-up attacks. Conclusion would be "When an ID token is issued,
>>     the `iss` parameter is not necessary."
>>
>>     Case 3: When an unencrypted JWT access token is issued
>>
>>     It is technically possible to use the `iss` claim in an
>>     unencrypted JWT access token as the `iss` parameter. However,
>>     requiring the client to check the `iss` claim means "The access
>>     token is no longer opaque to the client." Conclusion would be
>>     "Even when an access token is issued and its format is JWT, the
>>     `iss` parameter is necessary."
>>
>>     BTW, I found that a certain system raises an error when an
>>     unknown response parameter (that is, the `iss` parameter) is
>>     included in error authorization responses. To ask the
>>     administrator of the system to regard the `iss` parameter as a
>>     known one, at least the spec draft needs to be adopted by the
>>     community as a working draft. I hope that "call for adoption" for
>>     the draft will be conducted soon.
>>
>>     Best Regards,
>>     Taka
>>
>>     On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki
>>     > wrote:
>>
>>         It sounds that the Security Considerations section or
>>         somewhere appropriate should have a paragraph like below.
>>
>>         When an authorization response includes a JWT whose `iss`
>>         claim represents the issuer identifier of the authorization
>>         server, the `iss` claim can be used as a substitute for the
>>         `iss` parameter. Therefore, such authorization response does
>>         not have to have the `iss` parameter outside the JWT
>>         separately. Examples of such JWTs include the value of the
>>         `id_token` parameter in OIDC and the value of `response`
>>         parameter in JARM.
>>
>>         Taka
>>
>>         On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan
>>         > wrote:
>>
>>             I agree, it is in redundant in the JARM case.
>>
>>             I find the text
>>             in=C2=A0https://www.ietf.org/archive/id/draft-meyerzuselha=
usen-oauth-iss-auth-resp-01.html#name-security-considerations
>>             (the 4th paragraph where JARM & JWTs) are mentioned a bit
>>             confusing - I think it would be good to say something
>>             along the lines of:
>>
>>             Although integrity protection is not necessary to prevent
>>             mixup, any authorization response method that includes a
>>             JWT with an =E2=80=98iss' (for example, JARM or OIDC hybri=
d flow)
>>             will prevent the attack (assuming the client is
>>             validating the iss).
>>
>>
>>             I=E2=80=99m not entirely sure I understand what "MUST NOT =
allow
>>             multiple authorization servers to return the same issuer
>>             identifier during registration=E2=80=9D means as I don=E2=80=
=99t think
>>             https://tools.ietf.org/html/rfc7591 returns the issuer?
>>
>>             It might be clearer to say something like =E2=80=9CWhen
>>             https://tools.ietf.org/html/rfc8414 is used the client
>>             MUST implement the validation described in
>>             https://tools.ietf.org/html/rfc8414#section-3.3. When
>>             authorization server details can be manually configured
>>             in the client, the client must verify that all issuer
>>             values are unique.=E2=80=9D (Or at least something along t=
hose
>>             lines, I=E2=80=99m sure my wording can be improved. But if=
 the
>>             client is correctly implementing rfc8414 or OIDC
>>             discovery [and does not have any manually configured
>>             authorization servers] then there=E2=80=99s no requirement=
 for
>>             any further checks that the issuer is unique.)
>>
>>             Joseph
>>
>>
>>>             On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov
>>>             >>             > wrote:
>>>
>>>             This can potentially occur. If JARM is used "iss"
>>>             becomes redundant. To me JARM is an "enhanced" iss.
>>>
>>>             If both are included a sensible client should make sure
>>>             the iss and the JARM iss match.
>>>
>>>             My suggestion is to not require iss when a JARM is
>>>             present, but in case both do occur to have the client
>>>             check both.
>>>
>>>             Vladimir
>>>
>>>             On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>>>>             Hi Karsten,
>>>>
>>>>             The specification mentions JARM. Does this
>>>>             specification require the iss response parameter even
>>>>             when JARM is used? That is, should an authorization
>>>>             response look like below?
>>>>
>>>>             HTTP/1.1 302 Found
>>>>             Location:
>>>>             https://client.example.com/cb?response=3D{JWT}&iss=3D{IS=
SUER}
>>>>             
>>>>
>>>>             Or, can the iss response parameter be omitted when JARM
>>>>             is used?
>>>>
>>>>             A small feedback for the 3rd paragraph in Section 4:
>>>>             s/identifes/identifies/
>>>>
>>>>             Best Regards,
>>>>             Taka
>>>>             =C2=A0
>>>>
>>>>             On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov
>>>>             >>>             > wrote:
>>>>
>>>>                 Thanks Karsten, looks good to me now, no further
>>>>                 comments.
>>>>
>>>>                 Vladimir
>>>>
>>>>                 On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrot=
e:
>>>>>
>>>>>                 Hi all,
>>>>>
>>>>>                 Daniel and I published a new version of the "iss"
>>>>>                 response parameter draft to address the feedback
>>>>>                 from the WG.
>>>>>
>>>>>                 Changes in -01:
>>>>>
>>>>>                   * Incorporated first WG feedback
>>>>>                   * Clarifications for use with OIDC
>>>>>                   * Added note that clients supporting just one AS
>>>>>                     are not vulnerable
>>>>>                   * Renamed metadata parameter
>>>>>                   * Various editorial changes
>>>>>
>>>>>
>>>>>                 We would like to ask you for further feedback and
>>>>>                 comments on the new draft version.
>>>>>
>>>>>                 Best regards,
>>>>>                 Karsten
>>>>>
>>>>>                 -------- Forwarded Message --------
>>>>>                 Subject: 	New Version Notification for
>>>>>                 draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>>                 Date: 	Sun, 01 Nov 2020 23:31:42 -0800
>>>>>                 From: 	internet-drafts@ietf.org
>>>>>                 
>>>>>                 To: 	Karsten Meyer zu Selhausen
>>>>>                 
>>>>>                 ,
>>>>>                 Karsten zu Selhausen
>>>>>                 
>>>>>                 ,
>>>>>                 Daniel Fett 
>>>>>                 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 A new version of I-D,
>>>>>                 draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>>                 has been successfully submitted by Karsten Meyer
>>>>>                 zu Selhausen and posted to the
>>>>>                 IETF repository.
>>>>>
>>>>>                 Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>>>>                 Revision: 01
>>>>>                 Title: OAuth 2.0 Authorization Server Issuer
>>>>>                 Identifier in Authorization Response
>>>>>                 Document date: 2020-11-01
>>>>>                 Group: Individual Submission
>>>>>                 Pages: 10
>>>>>                 URL:
>>>>>                 https://www.ietf.org/archive/id/draft-meyerzuselhau=
sen-oauth-iss-auth-resp-01.txt
>>>>>                 Status:
>>>>>                 https://datatracker.ietf.org/doc/draft-meyerzuselha=
usen-oauth-iss-auth-resp/
>>>>>                 Html:
>>>>>                 https://www.ietf.org/archive/id/draft-meyerzuselhau=
sen-oauth-iss-auth-resp-01.html
>>>>>                 Htmlized:
>>>>>                 https://tools.ietf.org/html/draft-meyerzuselhausen-=
oauth-iss-auth-resp-01
>>>>>                 Diff:
>>>>>                 https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuse=
lhausen-oauth-iss-auth-resp-01
>>>>>
>>>>>                 Abstract:
>>>>>                 This document specifies a new parameter "iss" that
>>>>>                 is used to
>>>>>                 explicitly include the issuer identifier of the
>>>>>                 authorization server
>>>>>                 in the authorization response of an OAuth
>>>>>                 authorization flow. If
>>>>>                 implemented correctly, the "iss" parameter serves
>>>>>                 as an effective
>>>>>                 countermeasure to "mix-up attacks".
>>>>>
>>>>>
>>>>>
>>>>>                 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
>>>>>
>>>>>
>>>>>                 --=20
>>>>>                 Karsten Meyer zu Selhausen
>>>>>                 IT Security Consultant
>>>>>                 Phone:	+49 (0)234 / 54456499
>>>>>                 Web:	https://hackmanit.de  |=
 IT Security Consulting, Penetration Testing, Security Training
>>>>>
>>>>>                 Does your OAuth or OpenID Connect implementation us=
e PKCE to strengthen the security? Learn more about the procetion PKCE pr=
ovides and its limitations in our new blog post:
>>>>>                 https://www.hackmanit.de/en/blog-en/123-when-pkce-c=
annot-protect-your-confidential-oauth-client
>>>>>
>>>>>                 Hackmanit GmbH
>>>>>                 Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
>>>>>                 44789 Bochum
>>>>>
>>>>>                 Registergericht: Amtsgericht Bochum, HRB 14896
>>>>>                 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schw=
enk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemiet=
z
>>>>>
>>>>>                 _______________________________________________
>>>>>                 OAuth mailing list
>>>>>                 OAuth@ietf.org 
>>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>>                 _______________________________________________
>>>>                 OAuth mailing list
>>>>                 OAuth@ietf.org 
>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>             _______________________________________________
>>             OAuth mailing list
>>             OAuth@ietf.org 
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>     --=20
>     Vladimir Dzhuvinov
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>


--------------9D5469F03FBD79A74994286C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Noting two unrelated comments that came up:

    
    
      
  1. The iss value in the example doesn't appear to be URL encoded:
        
    
        
    
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oaut=
h-iss-auth-resp-01.html#name-example-authorization-respo
    
        
    
        
    
      
    2. 
      
  2. There was the question from a developer whether error
        responses should also have the iss. I suggest the spec to be
        more explicit that iss is added to both success and error
        responses, and even include a second example, with an error
        response. 
    
      
    3. 
    

    
Vladimir

    

    
On 10/11/2020 22:25, Takahiko Kawasaki=

      wrote:

    

    

      
      
Hi Vladimir,
        


        

        
Good point. Considering the similarity to JAR (JWT Secured
          Authorization Response), if we apply the same logic, our
          discussion will eventually reach "response parameters outside
          the response JWT are almost meaningless in the context of
          JARM". For interoperability and simplicity, it may be good to
          say "MUST NOT" as you suggested.

        


        

        
Taka

      

      

      

        
On Mon, Nov 9, 2020 at 10:2=
6
          PM Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        
=

          

            
Re Case 1: When JARM is used:

            
A colleague pointed me to the following statement in the
              JARMs spec, so I'd suggest to say the "iss" MUST NOT be
              included when JARM is used:

            

            
https://openid=
=2Enet//specs/openid-financial-api-jarm.html#jwt-based-response-mode<=
/p>
            
 

            
All response parameters defined for=

              a given response type are conveyed in a JWT

            
Now, there isn't a proper normative keyword in this JARM
              spec sentence, so I guess some may interpret this as a
              strong check for no other query params, while others may
              not. Hence the MUST NOT to prevent potential unintended
              errors.

            
What are your thoughts on this?

            

            
Vladimir

            

            
On 06/11/2020 23:34, Takahiko Kawasaki wrote:

            

            

              
I implemented the draft quickly and found
                no big hurdle for authorization server implementations.
                The current snapshot of my implementation does not add
                the `iss` parameter when JARM is used. However, for
                interoperability, I feel that the spec should describe
                expected behaviors when a JWT is included in an
                authorization response. The following is an
                implementer's comment for some cases.

                

                Case 1: When JARM is used

                

                An `iss` claim is included in the response JWT as one of
                top-level entries together with response parameters. It
                is not so unnatural to regard the `iss` claim as a
                response parameter. Conclusion would be "When JARM is
                used, the `iss` parameter is not necessary."

                

                Case 2: When an ID token is issued

                

                It is unnatural to regard the `iss` claim in an ID token
                as a response parameter. However, because FAPI Part 2
                has already been using an ID token as detached signature
                for integrity protection, it would be difficult to find
                a convincing reason to prohibit using the `iss` claim in
                an ID token as a countermeasure to mix-up attacks.
                Conclusion would be "When an ID token is issued, the
                `iss` parameter is not necessary."

                

                Case 3: When an unencrypted JWT access token is issued
                

                It is technically possible to use the `iss` claim in an
                unencrypted JWT access token as the `iss` parameter.
                However, requiring the client to check the `iss` claim
                means "The access token is no longer opaque to the
                client." Conclusion would be "Even when an access token
                is issued and its format is JWT, the `iss` parameter is
                necessary."

                

                BTW, I found that a certain system raises an error when
                an unknown response parameter (that is, the `iss`
                parameter) is included in error authorization responses.
                To ask the administrator of the system to regard the
                `iss` parameter as a known one, at least the spec draft
                needs to be adopted by the community as a working draft.
                I hope that "call for adoption" for the draft will be
                conducted soon.

                

                Best Regards,

                Taka

              

              

              

                
On Wed, Nov 4, 2020=
 at
                  4:46 AM Takahiko Kawasaki <taka@authlete.com>
                  wrote:

                

                

                  
It sounds that the Security
                    Considerations section or somewhere appropriate
                    should have a paragraph like below.

                    

                    When an authorization response includes a JWT whose
                    `iss` claim represents the issuer identifier of the
                    authorization server, the `iss` claim can be used as
                    a substitute for the `iss` parameter. Therefore,
                    such authorization response does not have to have
                    the `iss` parameter outside the JWT separately.
                    Examples of such JWTs include the value of the
                    `id_token` parameter in OIDC and the value of
                    `response` parameter in JARM.

                    

                    Taka

                  

                  

                  

                    
On Tue, Nov 3,
                      2020 at 10:46 PM Joseph Heenan <joseph=
@authlete.com>
                      wrote:

                    

                    

                      
I agree, it is in redundant in the JARM case.
                        


                        

                        
I find the text in=C2=A0ht=
tps://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-=
01.html#name-security-considerations
                          (the 4th paragraph where JARM & JWTs) are
                          mentioned a bit confusing - I think it would
                          be good to say something along the lines of:
                        


                        

                        
Although integrity protection is not
                          necessary to prevent mixup, any authorization
                          response method that includes a JWT with an
                          =E2=80=98iss' (for example, JARM or OIDC hybrid=
 flow)
                          will prevent the attack (assuming the client
                          is validating the iss).

                        


                        

                        


                        

                        
I=E2=80=99m not entirely sure I understand w=
hat
                          "MUST NOT allow multiple authorization servers
                          to return the same issuer identifier during
                          registration=E2=80=9D means as I don=E2=80=99t =
think ht=
tps://tools.ietf.org/html/rfc7591
                          returns the issuer?

                        


                        

                        
It might be clearer to say something like
                          =E2=80=9CWhen ht=
tps://tools.ietf.org/html/rfc8414
                          is used the client MUST implement the
                          validation described in ht=
tps://tools.ietf.org/html/rfc8414#section-3.3.
                          When authorization server details can be
                          manually configured in the client, the client
                          must verify that all issuer values are
                          unique.=E2=80=9D (Or at least something along t=
hose
                          lines, I=E2=80=99m sure my wording can be impro=
ved.
                          But if the client is correctly implementing
                          rfc8414 or OIDC discovery [and does not have
                          any manually configured authorization servers]
                          then there=E2=80=99s no requirement for any fur=
ther
                          checks that the issuer is unique.)

                        


                        

                        
Joseph

                        


                          


                            

                              
On 3 Nov 2020, at 07:01, Vladimir
                                Dzhuvinov <vladimir@connect2id.com>
                                wrote:

                              

                              

                                

                                  
This can potentially occur. If JARM
                                    is used "iss" becomes redundant. To
                                    me JARM is an "enhanced" iss.

                                  
If both are included a sensible
                                    client should make sure the iss and
                                    the JARM iss match.

                                  
My suggestion is to not require iss
                                    when a JARM is present, but in case
                                    both do occur to have the client
                                    check both.

                                  

                                  
Vladimir

                                  

                                  
On 02/11/2020 22:34, Takahiko
                                    Kawasaki wrote:

                                  

                                  

                                    
Hi Karsten,
                                      


                                      

                                      
The specification mentions
                                        JARM. Does this specification
                                        require the iss response
                                        parameter even when JARM is
                                        used? That is, should an
                                        authorization response look like
                                        below?

                                      


                                      

                                      
HTTP/1.1 302 Found

                                      
                                      


                                      

                                      
Or, can the iss response
                                        parameter be omitted when JARM
                                        is used?

                                      


                                      

                                      
A small feedback for the 3rd
                                        paragraph in Section 4:
                                        s/identifes/identifies/

                                      


                                      

                                      
Best Regards,

                                      
Taka

                                      
=C2=A0

                                    

                                    

                                    

                                      
On
                                        Tue, Nov 3, 2020 at 3:13 AM
                                        Vladimir Dzhuvinov <vladim=
ir@connect2id.com>
                                        wrote:

                                      

                                      

                                            
Hi
                                                all,

                                            
Dani=
el
                                                and I published a new
                                                version of the "iss"
                                                response parameter draft
                                                to address the feedback
                                                from the WG.

                                            
Chan=
ges
                                                in -01:

                                            
    
                                              
  • In=
corporated
                                                  first WG feedback
    • 
                                              
  • Cl=
arifications
                                                  for use with OIDC
    • 
                                              
  • Ad=
ded
                                                  note that clients
                                                  supporting just one AS
                                                  are not vulnerable
    • 
                                              
  • Re=
named
                                                  metadata parameter
    • 
                                              
  • Va=
rious
                                                  editorial changes
    
                                                
    • 
                                            

                                            


                                              =
We
                                                    would like to ask
                                                    you for further
                                                    feedback and
                                                    comments on the new
                                                    draft version.

                                                  
                                            

=

                                              

                                            
Best=

                                                regards,

                                            
Kars=
ten

                                            


                                            

                                            
-------- Forwarded
                                              Message --------
                                              =

                                                  

                                                
                                                  

                                                    Sub=
ject:
                                                    
                                                    New Version
                                                      Notification for
                                                      draft-meyerzuselhau=
sen-oauth-iss-auth-resp-01.txt
                                                  

                                                  

                                                    Dat=
e:
                                                    
                                                    Sun, 01 Nov 2020
                                                      23:31:42 -0800

                                                  

                                                    Fro=
m:
                                                    
                                                    internet-drafts@ietf.org
                                                  

                                                  

                                                    To:=

                                                    
                                                    Karsten Meyer zu
                                                      Selhausen <karsten.meyerzuselhausen@hackmanit.de>,
                                                      Karsten zu
                                                      Selhausen <karsten.meyerzuselhausen@hackmanit.de>,
                                                      Daniel Fett <mail@danielfett.de>
                                                  

                                                
                                              

                                              

                                              

                                              

                                              A new version of I-D,
                                              draft-meyerzuselhausen-oaut=
h-iss-auth-resp-01.txt

                                              has been successfully
                                              submitted by Karsten Meyer
                                              zu Selhausen and posted to
                                              the

                                              IETF repository.

                                              

                                              Name:
                                              draft-meyerzuselhausen-oaut=
h-iss-auth-resp

                                              Revision: 01

                                              Title: OAuth 2.0
                                              Authorization Server
                                              Issuer Identifier in
                                              Authorization Response

                                              Document date: 2020-11-01
                                              Group: Individual
                                              Submission

                                              Pages: 10

                                              URL: =
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-01.txt

                                              Status: =
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-re=
sp/

                                              Html: =
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-01.html

                                              Htmlized: =
https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01=


                                              Diff: =
https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth=
-resp-01

                                              

                                              Abstract:

                                              This document specifies a
                                              new parameter "iss" that
                                              is used to

                                              explicitly include the
                                              issuer identifier of the
                                              authorization server

                                              in the authorization
                                              response of an OAuth
                                              authorization flow. If

                                              implemented correctly, the
                                              "iss" parameter serves as
                                              an effective

                                              countermeasure to "mix-up
                                              attacks".

                                              

                                              

                                              

                                              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

                                              

                                              

                                            

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitat=
ions in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-you=
r-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

                                            

                                            

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



                                          

                                        

_______________________________________________

                                        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/mai=
lman/listinfo/oauth

                    

                  

                

              

              

              

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



            
            
--=20
Vladimir Dzhuvinov

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mailman/listinfo/oauth

        
      

    
    

  


--------------9D5469F03FBD79A74994286C--

--------------ms040302080401090304080507
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw
MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E
1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w
/GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr
xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ
U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f
/8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8
C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P
AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj
dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG
CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u
bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq
BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu
wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap
xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM
9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv
cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG
SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE
BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE
AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw
MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx
PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno
1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK
8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k
N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee
1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8
kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G
A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz
cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd
F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7
4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0
sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ
JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH
xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe
roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85
F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU
E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY
dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe
5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMTcwNzU2MDVaMC8G
CSqGSIb3DQEJBDEiBCAEtKF8lFcIjlnJpBUYXP2g1mOz2beUv5DNZl5R+WGXrjBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAB+i4qN9oEpkWimtogIQqBD9sLkDRszrsQ3nDRqZ8U8huWwq
WFLXPFwkEpC3Dqf2cQaAYAB989msqNGtmHclP5j0F86dbQUBeip7pQbxb6dd+WvQsi+NxXpG
82JNFsIjEyo0HV+Ux0BpF1v+KD/t9OG14kORU4mN/ifKZNQpq2YQkPG6gx5ck/pPJV7POn+U
ENAbyqZSJTLVA5BwbTWm+HqzI+tnP/+4dS8PHTTPOrCpN3qARJms7k+8N0On4/NwW0p2VrCZ
HOwU/j/IxFxL6gS54+BS0klzEqz5FJc/s3/Ix5uPIjXR4neu7/x7p6EzouBK7Ntk3e5NfeiQ
CmPbf5cAAAAAAAA=
--------------ms040302080401090304080507--


From nobody Tue Nov 17 01:35:57 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3BA3A0D7E for ; Tue, 17 Nov 2020 01:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVmyZCxGuxsi for ; Tue, 17 Nov 2020 01:35:54 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 0B4293A0D7B for ; Tue, 17 Nov 2020 01:35:41 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id n12so20475114ioc.2 for ; Tue, 17 Nov 2020 01:35:41 -0800 (PST)
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=KY+RZcVTDTOY4QyoQ9IpAWDd2sWtohtaCSbriU5cbHI=; b=TY/2LRaLTfXode94sReOV7/fSv6nUSnXMv2t049vrY9FjxaGUpkSSek1pU8Pcrlr+d qSEh+yqbkuzVzc7S26BpQdRplLcEnaSaUjKruXaKowuZSHw620nY1bS59y0/TVKPZZy1 wJMZSXM8wlHLJN1M0WL/mUb+VMttdhR7wAobPWndFM8f6VoB2w+jVNmro1BaZxsy2c70 O9z8/FugJ1Y9Cm5CMCBJiB2mzKMPtA/Q9XU2hjkA9haefeFxMd6NKLQlNcRmyJS1eFFC ZwBCsm6Oh50pBtxhs3rsHe9Z6dqtGCVkQBWAwxeAEEwuiFB6hGYOndYEAlrq+BgWm6v6 N3sw==
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=KY+RZcVTDTOY4QyoQ9IpAWDd2sWtohtaCSbriU5cbHI=; b=eKt3sLNYFzMUuHWWg4Z58m4c3WOwoEHVAdAMAmSeSyOP2/+x/ye09yvvtRbGeKMEzJ NNm5bsFmpr8etDM3AB7HpNS7gWo4lLpfqyAsN6MugmHuVWFeGm/5QWDFkAN5EHFQBVnq BWoyglEv3O+vmCKiR2xwFWmiszpuWVo7rkAWu5lRlj5HiniZTyuUzxNzq2hsRVXTPebb Kq3dNGuGjvAIokPcZq4RtnipZCM1MEkN9V18BaXzq8IM5FS7ExXDCzloE1ZO+NP5sSaW YV/txs2pGjUd/j6I+WGf64aAr0o6G+UX8ug6OqkRmVLL/hPfdBj7kQym6ulxWk7S/1QY kq4g==
X-Gm-Message-State: AOAM532TbGH+Mfz2GieHZjRjCOPrzmSDnyVazcrYo6jSDWLU6glbkou7 7E15bwKhRmjOldnDsW3kcGAWDcZt73FOWEsN3bvT/PgNHBaaKg==
X-Google-Smtp-Source: ABdhPJxctLwFihMGKOZ7/NLA/g0YHp+prkgj5xBMXjetWJ3l1nra45ryLLQRSeSqbmF46UsgCXtEsfOsgJPkYV4W70Q=
X-Received: by 2002:a6b:920b:: with SMTP id u11mr10744727iod.191.1605605741110;  Tue, 17 Nov 2020 01:35:41 -0800 (PST)
MIME-Version: 1.0
From: Roberto Polli 
Date: Tue, 17 Nov 2020 10:35:30 +0100
Message-ID: 
To: oauth@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.1: improving terminology and relationship with other specs
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, 17 Nov 2020 09:35:56 -0000

Hi @all,

I have recently started looking at OAuth2.1 spec and I proposed
to align the terminology with the HTTP spec:

- https://github.com/aaronpk/oauth-v2-1/pull/22

I suspect that more work on this field would improve the spec, eg:

- https://github.com/aaronpk/oauth-v2-1/issues/created_by/ioggstream

but I'd like to hear from you.
Have a nice day,
R.


From nobody Tue Nov 17 02:58:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1F03A0FBD for ; Tue, 17 Nov 2020 02:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgEQ1LIsk72Z for ; Tue, 17 Nov 2020 02:58:20 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3B13A0DAD for ; Tue, 17 Nov 2020 02:58:20 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 90AE1161CA for ; Tue, 17 Nov 2020 10:58:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1605610698; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=232744lVyJOIkQvPqDOLzcIpKFTScw55Sg5fJj86FkU=; b=nMgKO/MLIf6zz/euMflJ1ozIvY2TnGgqp4irTAIYCiVIuCQi04H5bFzsIFf3bCoH2UGw8C 3AVnI0XeT8GIyL5gcEiVZMcU5OPb+VulAYKUeI+EaPYyAGIBha84+rPA2/OwlqU3XYiN+A GRXzfhg4Mfxv5zoj3TwuxqnGQrwOPQw=
To: oauth@ietf.org
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com>  <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com>   <69B0850B-D863-4792-905E-54EE20823323@authlete.com>   <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com>  <61f07b70-f9b2-f5c3-19a2-122062ad1055@connect2id.com>
From: Daniel Fett 
Message-ID: <08f76711-8fd8-da78-9ddc-ebc370bc9ef3@danielfett.de>
Date: Tue, 17 Nov 2020 11:56:07 +0100
MIME-Version: 1.0
In-Reply-To: <61f07b70-f9b2-f5c3-19a2-122062ad1055@connect2id.com>
Content-Type: multipart/alternative; boundary="------------AC2CE8544FD1CF24150EBA31"
Content-Language: en-US
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1605610698; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=232744lVyJOIkQvPqDOLzcIpKFTScw55Sg5fJj86FkU=; b=cybh2abDmXI3KJhyMHueSlZNElxyl1HbQLApsdI+SaLnUG9iP6v5kmBu9WWZdu5V0+oAtF oIOM93RMvVD3ja6zzSd123gHro1vWR22AMVL/RLxWzNeEThUvuzBqQH2AM57C6WOkeTBFu nvfe7TSocVQWhS75KV/eu0U+uNrg2Go=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1605610698; a=rsa-sha256; cv=none; b=s43hj67cZqGEmgYEXx1hbAQusCd1nq3zQwL/RJtThVZdCBewBBLIz4mtTI41ocl/weQTOp jJdIK8QdwF6dvRvvhLaQzajKmSYyk+SVf3CJ338cRiE053+deqLUuLdCj0VrZyAKcJou7t b++hEOuYRJgVOEWnd7hqezaBnrLP31c=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Nov 2020 10:58:24 -0000

This is a multi-part message in MIME format.
--------------AC2CE8544FD1CF24150EBA31
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Thanks Vladimir and Takahiko, we incorporated your proposals into the
next version of the draft.

-Daniel

Am 17.11.20 um 08:56 schrieb Vladimir Dzhuvinov:
>
> Noting two unrelated comments that came up:
>
>  1. The iss value in the example doesn't appear to be URL encoded:
>
>     https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-example-authorization-respo
>
>
>  2. There was the question from a developer whether error responses
>     should also have the iss. I suggest the spec to be more explicit
>     that iss is added to both success and error responses, and even
>     include a second example, with an error response.
>
> Vladimir
>
> On 10/11/2020 22:25, Takahiko Kawasaki wrote:
>> Hi Vladimir,
>>
>> Good point. Considering the similarity to JAR (JWT Secured
>> Authorization Response), if we apply the same logic, our discussion
>> will eventually reach "response parameters outside the response JWT
>> are almost meaningless in the context of JARM". For interoperability
>> and simplicity, it may be good to say "MUST NOT" as you suggested.
>>
>> Taka
>>
>> On Mon, Nov 9, 2020 at 10:26 PM Vladimir Dzhuvinov
>> > wrote:
>>
>>     Re Case 1: When JARM is used:
>>
>>     A colleague pointed me to the following statement in the JARMs
>>     spec, so I'd suggest to say the "iss" MUST NOT be included when
>>     JARM is used:
>>
>>     https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-response-mode
>>
>>>     All response parameters defined for a given response type are
>>>     conveyed in a JWT
>>
>>     Now, there isn't a proper normative keyword in this JARM spec
>>     sentence, so I guess some may interpret this as a strong check
>>     for no other query params, while others may not. Hence the MUST
>>     NOT to prevent potential unintended errors.
>>
>>     What are your thoughts on this?
>>
>>     Vladimir
>>
>>     On 06/11/2020 23:34, Takahiko Kawasaki wrote:
>>>     I implemented the draft quickly and found no big hurdle for
>>>     authorization server implementations. The current snapshot of my
>>>     implementation does not add the `iss` parameter when JARM is
>>>     used. However, for interoperability, I feel that the spec should
>>>     describe expected behaviors when a JWT is included in an
>>>     authorization response. The following is an implementer's
>>>     comment for some cases.
>>>
>>>     Case 1: When JARM is used
>>>
>>>     An `iss` claim is included in the response JWT as one of
>>>     top-level entries together with response parameters. It is not
>>>     so unnatural to regard the `iss` claim as a response parameter.
>>>     Conclusion would be "When JARM is used, the `iss` parameter is
>>>     not necessary."
>>>
>>>     Case 2: When an ID token is issued
>>>
>>>     It is unnatural to regard the `iss` claim in an ID token as a
>>>     response parameter. However, because FAPI Part 2 has already
>>>     been using an ID token as detached signature for integrity
>>>     protection, it would be difficult to find a convincing reason to
>>>     prohibit using the `iss` claim in an ID token as a
>>>     countermeasure to mix-up attacks. Conclusion would be "When an
>>>     ID token is issued, the `iss` parameter is not necessary."
>>>
>>>     Case 3: When an unencrypted JWT access token is issued
>>>
>>>     It is technically possible to use the `iss` claim in an
>>>     unencrypted JWT access token as the `iss` parameter. However,
>>>     requiring the client to check the `iss` claim means "The access
>>>     token is no longer opaque to the client." Conclusion would be
>>>     "Even when an access token is issued and its format is JWT, the
>>>     `iss` parameter is necessary."
>>>
>>>     BTW, I found that a certain system raises an error when an
>>>     unknown response parameter (that is, the `iss` parameter) is
>>>     included in error authorization responses. To ask the
>>>     administrator of the system to regard the `iss` parameter as a
>>>     known one, at least the spec draft needs to be adopted by the
>>>     community as a working draft. I hope that "call for adoption"
>>>     for the draft will be conducted soon.
>>>
>>>     Best Regards,
>>>     Taka
>>>
>>>     On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki
>>>     > wrote:
>>>
>>>         It sounds that the Security Considerations section or
>>>         somewhere appropriate should have a paragraph like below.
>>>
>>>         When an authorization response includes a JWT whose `iss`
>>>         claim represents the issuer identifier of the authorization
>>>         server, the `iss` claim can be used as a substitute for the
>>>         `iss` parameter. Therefore, such authorization response does
>>>         not have to have the `iss` parameter outside the JWT
>>>         separately. Examples of such JWTs include the value of the
>>>         `id_token` parameter in OIDC and the value of `response`
>>>         parameter in JARM.
>>>
>>>         Taka
>>>
>>>         On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan
>>>         > wrote:
>>>
>>>             I agree, it is in redundant in the JARM case.
>>>
>>>             I find the text
>>>             in https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
>>>             (the 4th paragraph where JARM & JWTs) are mentioned a
>>>             bit confusing - I think it would be good to say
>>>             something along the lines of:
>>>
>>>             Although integrity protection is not necessary to
>>>             prevent mixup, any authorization response method that
>>>             includes a JWT with an ‘iss' (for example, JARM or OIDC
>>>             hybrid flow) will prevent the attack (assuming the
>>>             client is validating the iss).
>>>
>>>
>>>             I’m not entirely sure I understand what "MUST NOT allow
>>>             multiple authorization servers to return the same issuer
>>>             identifier during registration” means as I don’t think
>>>             https://tools.ietf.org/html/rfc7591 returns the issuer?
>>>
>>>             It might be clearer to say something like “When
>>>             https://tools.ietf.org/html/rfc8414 is used the client
>>>             MUST implement the validation described in
>>>             https://tools.ietf.org/html/rfc8414#section-3.3. When
>>>             authorization server details can be manually configured
>>>             in the client, the client must verify that all issuer
>>>             values are unique.” (Or at least something along those
>>>             lines, I’m sure my wording can be improved. But if the
>>>             client is correctly implementing rfc8414 or OIDC
>>>             discovery [and does not have any manually configured
>>>             authorization servers] then there’s no requirement for
>>>             any further checks that the issuer is unique.)
>>>
>>>             Joseph
>>>
>>>
>>>>             On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov
>>>>             >>>             > wrote:
>>>>
>>>>             This can potentially occur. If JARM is used "iss"
>>>>             becomes redundant. To me JARM is an "enhanced" iss.
>>>>
>>>>             If both are included a sensible client should make sure
>>>>             the iss and the JARM iss match.
>>>>
>>>>             My suggestion is to not require iss when a JARM is
>>>>             present, but in case both do occur to have the client
>>>>             check both.
>>>>
>>>>             Vladimir
>>>>
>>>>             On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>>>>>             Hi Karsten,
>>>>>
>>>>>             The specification mentions JARM. Does this
>>>>>             specification require the iss response parameter even
>>>>>             when JARM is used? That is, should an authorization
>>>>>             response look like below?
>>>>>
>>>>>             HTTP/1.1 302 Found
>>>>>             Location:
>>>>>             https://client.example.com/cb?response={JWT}&iss={ISSUER}
>>>>>             
>>>>>
>>>>>             Or, can the iss response parameter be omitted when
>>>>>             JARM is used?
>>>>>
>>>>>             A small feedback for the 3rd paragraph in Section 4:
>>>>>             s/identifes/identifies/
>>>>>
>>>>>             Best Regards,
>>>>>             Taka
>>>>>              
>>>>>
>>>>>             On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov
>>>>>             >>>>             > wrote:
>>>>>
>>>>>                 Thanks Karsten, looks good to me now, no further
>>>>>                 comments.
>>>>>
>>>>>                 Vladimir
>>>>>
>>>>>                 On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>>>>>
>>>>>>                 Hi all,
>>>>>>
>>>>>>                 Daniel and I published a new version of the "iss"
>>>>>>                 response parameter draft to address the feedback
>>>>>>                 from the WG.
>>>>>>
>>>>>>                 Changes in -01:
>>>>>>
>>>>>>                   * Incorporated first WG feedback
>>>>>>                   * Clarifications for use with OIDC
>>>>>>                   * Added note that clients supporting just one
>>>>>>                     AS are not vulnerable
>>>>>>                   * Renamed metadata parameter
>>>>>>                   * Various editorial changes
>>>>>>
>>>>>>
>>>>>>                 We would like to ask you for further feedback and
>>>>>>                 comments on the new draft version.
>>>>>>
>>>>>>                 Best regards,
>>>>>>                 Karsten
>>>>>>
>>>>>>                 -------- Forwarded Message --------
>>>>>>                 Subject: 	New Version Notification for
>>>>>>                 draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>>>                 Date: 	Sun, 01 Nov 2020 23:31:42 -0800
>>>>>>                 From: 	internet-drafts@ietf.org
>>>>>>                 
>>>>>>                 To: 	Karsten Meyer zu Selhausen
>>>>>>                 
>>>>>>                 ,
>>>>>>                 Karsten zu Selhausen
>>>>>>                 
>>>>>>                 ,
>>>>>>                 Daniel Fett 
>>>>>>                 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 A new version of I-D,
>>>>>>                 draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>>>                 has been successfully submitted by Karsten Meyer
>>>>>>                 zu Selhausen and posted to the
>>>>>>                 IETF repository.
>>>>>>
>>>>>>                 Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>>>>>                 Revision: 01
>>>>>>                 Title: OAuth 2.0 Authorization Server Issuer
>>>>>>                 Identifier in Authorization Response
>>>>>>                 Document date: 2020-11-01
>>>>>>                 Group: Individual Submission
>>>>>>                 Pages: 10
>>>>>>                 URL:
>>>>>>                 https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>>>                 Status:
>>>>>>                 https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>>>>>>                 Html:
>>>>>>                 https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
>>>>>>                 Htmlized:
>>>>>>                 https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>>>>>                 Diff:
>>>>>>                 https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>>>>>
>>>>>>                 Abstract:
>>>>>>                 This document specifies a new parameter "iss"
>>>>>>                 that is used to
>>>>>>                 explicitly include the issuer identifier of the
>>>>>>                 authorization server
>>>>>>                 in the authorization response of an OAuth
>>>>>>                 authorization flow. If
>>>>>>                 implemented correctly, the "iss" parameter serves
>>>>>>                 as an effective
>>>>>>                 countermeasure to "mix-up attacks".
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 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
>>>>>>
>>>>>>
>>>>>>                 -- 
>>>>>>                 Karsten Meyer zu Selhausen
>>>>>>                 IT Security Consultant
>>>>>>                 Phone:	+49 (0)234 / 54456499
>>>>>>                 Web:	https://hackmanit.de  | IT Security Consulting, Penetration Testing, Security Training
>>>>>>
>>>>>>                 Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post:
>>>>>>                 https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client
>>>>>>
>>>>>>                 Hackmanit GmbH
>>>>>>                 Universitätsstraße 60 (Exzenterhaus)
>>>>>>                 44789 Bochum
>>>>>>
>>>>>>                 Registergericht: Amtsgericht Bochum, HRB 14896
>>>>>>                 Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>>>>>
>>>>>>                 _______________________________________________
>>>>>>                 OAuth mailing list
>>>>>>                 OAuth@ietf.org 
>>>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>>>                 _______________________________________________
>>>>>                 OAuth mailing list
>>>>>                 OAuth@ietf.org 
>>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>>             _______________________________________________
>>>>             OAuth mailing list
>>>>             OAuth@ietf.org 
>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     -- 
>>     Vladimir Dzhuvinov
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------AC2CE8544FD1CF24150EBA31
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Vladimir and Takahiko, we
      incorporated your proposals into the next version of the draft.

    


    

    
-Daniel

    

    


    

    
Am 17.11.20 um 08:56 schrieb Vladimir
      Dzhuvinov:

    

    

      
      
Noting two unrelated comments that came up:

      
    
        
  1. The iss value in the example doesn't appear to be URL
          encoded: 
    
          
    
          https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-example-authorization-respo
    
          
    
          
    
        
    2. 
        
  2. There was the question from a developer whether error
          responses should also have the iss. I suggest the spec to be
          more explicit that iss is added to both success and error
          responses, and even include a second example, with an error
          response. 
    
        
    3. 
      

      
Vladimir

      

      
On 10/11/2020 22:25, Takahiko
        Kawasaki wrote:

      

      

        
        
Hi Vladimir,
          


          

          
Good point. Considering the similarity to JAR (JWT
            Secured Authorization Response), if we apply the same logic,
            our discussion will eventually reach "response parameters
            outside the response JWT are almost meaningless in the
            context of JARM". For interoperability and simplicity, it
            may be good to say "MUST NOT" as you suggested.

          


          

          
Taka

        

        

        

          
On Mon, Nov 9, 2020 at 10:26
            PM Vladimir Dzhuvinov <vladimir@connect2id.com>
            wrote:

          

          

            

              
Re Case 1: When JARM is used:

              
A colleague pointed me to the following statement in
                the JARMs spec, so I'd suggest to say the "iss" MUST NOT
                be included when JARM is used:

              

              
https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-response-mode

              
 

              
All response parameters defined
                for a given response type are conveyed in a JWT

              
Now, there isn't a proper normative keyword in this
                JARM spec sentence, so I guess some may interpret this
                as a strong check for no other query params, while
                others may not. Hence the MUST NOT to prevent potential
                unintended errors.

              
What are your thoughts on this?

              

              
Vladimir

              

              
On 06/11/2020 23:34, Takahiko Kawasaki wrote:

              

              

                
I implemented the draft quickly and found
                  no big hurdle for authorization server
                  implementations. The current snapshot of my
                  implementation does not add the `iss` parameter when
                  JARM is used. However, for interoperability, I feel
                  that the spec should describe expected behaviors when
                  a JWT is included in an authorization response. The
                  following is an implementer's comment for some cases.

                  

                  Case 1: When JARM is used

                  

                  An `iss` claim is included in the response JWT as one
                  of top-level entries together with response
                  parameters. It is not so unnatural to regard the `iss`
                  claim as a response parameter. Conclusion would be
                  "When JARM is used, the `iss` parameter is not
                  necessary."

                  

                  Case 2: When an ID token is issued

                  

                  It is unnatural to regard the `iss` claim in an ID
                  token as a response parameter. However, because FAPI
                  Part 2 has already been using an ID token as detached
                  signature for integrity protection, it would be
                  difficult to find a convincing reason to prohibit
                  using the `iss` claim in an ID token as a
                  countermeasure to mix-up attacks. Conclusion would be
                  "When an ID token is issued, the `iss` parameter is
                  not necessary."

                  

                  Case 3: When an unencrypted JWT access token is issued

                  

                  It is technically possible to use the `iss` claim in
                  an unencrypted JWT access token as the `iss`
                  parameter. However, requiring the client to check the
                  `iss` claim means "The access token is no longer
                  opaque to the client." Conclusion would be "Even when
                  an access token is issued and its format is JWT, the
                  `iss` parameter is necessary."

                  

                  BTW, I found that a certain system raises an error
                  when an unknown response parameter (that is, the `iss`
                  parameter) is included in error authorization
                  responses. To ask the administrator of the system to
                  regard the `iss` parameter as a known one, at least
                  the spec draft needs to be adopted by the community as
                  a working draft. I hope that "call for adoption" for
                  the draft will be conducted soon.

                  

                  Best Regards,

                  Taka

                

                

                

                  
On Wed, Nov 4, 2020
                    at 4:46 AM Takahiko Kawasaki <taka@authlete.com>
                    wrote:

                  

                  

                    
It sounds that the Security
                      Considerations section or somewhere appropriate
                      should have a paragraph like below.

                      

                      When an authorization response includes a JWT
                      whose `iss` claim represents the issuer identifier
                      of the authorization server, the `iss` claim can
                      be used as a substitute for the `iss` parameter.
                      Therefore, such authorization response does not
                      have to have the `iss` parameter outside the JWT
                      separately. Examples of such JWTs include the
                      value of the `id_token` parameter in OIDC and the
                      value of `response` parameter in JARM.

                      

                      Taka

                    

                    

                    

                      
On Tue, Nov 3,
                        2020 at 10:46 PM Joseph Heenan <joseph@authlete.com>
                        wrote:

                      

                      

                        
I agree, it is in redundant in the JARM
                          case.
                          


                          

                          
I find the text in https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
                            (the 4th paragraph where JARM & JWTs)
                            are mentioned a bit confusing - I think it
                            would be good to say something along the
                            lines of:

                          


                          

                          
Although integrity protection is not
                            necessary to prevent mixup, any
                            authorization response method that includes
                            a JWT with an ‘iss' (for example, JARM or
                            OIDC hybrid flow) will prevent the attack
                            (assuming the client is validating the iss).

                          


                          

                          


                          

                          
I’m not entirely sure I understand what
                            "MUST NOT allow multiple authorization
                            servers to return the same issuer identifier
                            during registration” means as I don’t think
                            https://tools.ietf.org/html/rfc7591
                            returns the issuer?

                          


                          

                          
It might be clearer to say something like
                            “When https://tools.ietf.org/html/rfc8414
                            is used the client MUST implement the
                            validation described in https://tools.ietf.org/html/rfc8414#section-3.3.
                            When authorization server details can be
                            manually configured in the client, the
                            client must verify that all issuer values
                            are unique.” (Or at least something along
                            those lines, I’m sure my wording can be
                            improved. But if the client is correctly
                            implementing rfc8414 or OIDC discovery [and
                            does not have any manually configured
                            authorization servers] then there’s no
                            requirement for any further checks that the
                            issuer is unique.)

                          


                          

                          
Joseph

                          


                            


                              

                                
On 3 Nov 2020, at 07:01, Vladimir
                                  Dzhuvinov <vladimir@connect2id.com>
                                  wrote:

                                

                                

                                  

                                    
This can potentially occur. If
                                      JARM is used "iss" becomes
                                      redundant. To me JARM is an
                                      "enhanced" iss.

                                    
If both are included a sensible
                                      client should make sure the iss
                                      and the JARM iss match.

                                    
My suggestion is to not require
                                      iss when a JARM is present, but in
                                      case both do occur to have the
                                      client check both.

                                    

                                    
Vladimir

                                    

                                    
On 02/11/2020 22:34, Takahiko
                                      Kawasaki wrote:

                                    

                                    

                                      
Hi Karsten,
                                        


                                        

                                        
The specification mentions
                                          JARM. Does this specification
                                          require the iss response
                                          parameter even when JARM is
                                          used? That is, should an
                                          authorization response look
                                          like below?

                                        


                                        

                                        
HTTP/1.1 302 Found

                                        
                                        


                                        

                                        
Or, can the iss response
                                          parameter be omitted when JARM
                                          is used?

                                        


                                        

                                        
A small feedback for the
                                          3rd paragraph in Section 4:
                                          s/identifes/identifies/

                                        


                                        

                                        
Best Regards,

                                        
Taka

                                        
 

                                      

                                      

                                      

                                        
On Tue, Nov
                                          3, 2020 at 3:13 AM Vladimir
                                          Dzhuvinov <vladimir@connect2id.com>
                                          wrote:

                                        

                                        

                                          

                                            
Thanks Karsten, looks
                                              good to me now, no further
                                              comments.

                                            

                                            
Vladimir

                                            

                                            
On 02/11/2020 09:54,
                                              Karsten Meyer zu Selhausen
                                              wrote:

                                            

                                            

                                              
Hi
                                                  all,

                                              
Daniel
                                                  and I published a new
                                                  version of the "iss"
                                                  response parameter
                                                  draft to address the
                                                  feedback from the WG.

                                              
Changes
                                                  in -01:

                                              
    
                                                
  • Incorporated
                                                    first WG feedback
    • 
                                                
  • Clarifications
                                                    for use with OIDC
    • 
                                                
  • Added
                                                    note that clients
                                                    supporting just one
                                                    AS are not
                                                    vulnerable
    • 
                                                
  • Renamed
                                                    metadata parameter
    • 
                                                
  • Various
                                                    editorial changes
    
                                                  
    • 
                                              

                                              


                                                We
                                                      would like to ask
                                                      you for further
                                                      feedback and
                                                      comments on the
                                                      new draft version.

                                                    

                                              


                                                

                                              
Best
                                                  regards,

                                              
Karsten

                                              


                                              

                                              
-------- Forwarded
                                                Message --------
                                                

                                                  
                                                    

                                                      Subject:
                                                      
                                                      New Version
                                                        Notification for
draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
                                                    

                                                    

                                                      Date:
                                                      
                                                      Sun, 01 Nov
                                                        2020 23:31:42
                                                        -0800
                                                    

                                                    

                                                      From:
                                                      
                                                      internet-drafts@ietf.org
                                                    

                                                    

                                                      To:
                                                      
                                                      Karsten Meyer
                                                        zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>,
                                                        Karsten zu
                                                        Selhausen <karsten.meyerzuselhausen@hackmanit.de>,
                                                        Daniel Fett <mail@danielfett.de>
                                                    

                                                  
                                                

                                                

                                                

                                                

                                                A new version of I-D,
                                                draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                                                has been successfully
                                                submitted by Karsten
                                                Meyer zu Selhausen and
                                                posted to the

                                                IETF repository.

                                                

                                                Name:
                                                draft-meyerzuselhausen-oauth-iss-auth-resp

                                                Revision: 01

                                                Title: OAuth 2.0
                                                Authorization Server
                                                Issuer Identifier in
                                                Authorization Response

                                                Document date:
                                                2020-11-01

                                                Group: Individual
                                                Submission

                                                Pages: 10

                                                URL: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

                                                Status: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

                                                Html: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html

                                                Htmlized: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01

                                                Diff: https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01

                                                

                                                Abstract:

                                                This document specifies
                                                a new parameter "iss"
                                                that is used to

                                                explicitly include the
                                                issuer identifier of the
                                                authorization server

                                                in the authorization
                                                response of an OAuth
                                                authorization flow. If

                                                implemented correctly,
                                                the "iss" parameter
                                                serves as an effective

                                                countermeasure to
                                                "mix-up attacks".

                                                

                                                

                                                

                                                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

                                                

                                                

                                              

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

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

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

                                              

                                              

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


                                            

                                          

_______________________________________________

                                          OAuth mailing list

                                          OAuth@ietf.org

                                          https://www.ietf.org/mailman/listinfo/oauth

                                        

                                      

                                    

                                    

                                  

_______________________________________________

                                  OAuth mailing list

                                  OAuth@ietf.org

                                  https://www.ietf.org/mailman/listinfo/oauth

                                

                              

                            

                            

                          

                        

                        _______________________________________________

                        OAuth mailing list

                        OAuth@ietf.org

                        https://www.ietf.org/mailman/listinfo/oauth

                      

                    

                  

                

                

                

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


              

              
-- 
Vladimir Dzhuvinov

            

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

            https://www.ietf.org/mailman/listinfo/oauth

          

        

      

      

      

      

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


    

    


    

  


--------------AC2CE8544FD1CF24150EBA31--


From nobody Tue Nov 17 03:48:13 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB1E3A1113 for ; Tue, 17 Nov 2020 03:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackmanit.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CL297qnCM2T for ; Tue, 17 Nov 2020 03:48:10 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 21D483A1130 for ; Tue, 17 Nov 2020 03:47:52 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id p1so22825522wrf.12 for ; Tue, 17 Nov 2020 03:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AWwg1lqybXTe3gjkMxSFrst7iixrY5tNa+BYeKZ3BwU=; b=H+ryFeyJOBmKhYyXdaZZb8acasF9kwtCAJklPCXu5Wo2OaHmcT+kf7a8TzCRvfSYTm M6yROv+Z5SzsN0jVCBESZT0Cnh/Yv19y0iwUXA+wS6pbL2dU25s5ILfxLmw0F9lFtQJF P4K6LKJrwNLbdrkQLCy6b/mEd4CVCC8jiMApgqxAMT8GgS0vDCXEQbHxqRd3RBbkxzeb Kf7nuHhiZBXLuvX/7RimrOY2m5bHMx9LQ4+CqOTXy7j7CVg+Hyg3EjmbRFpZj8QZQ+vY BTA/SniP0AaSnvoZYe0Nz9pk8iSgyit3kWus3OaBLF4BYiyS9NFp9ZWk5FC0+nrR/rSF PkMQ==
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; bh=AWwg1lqybXTe3gjkMxSFrst7iixrY5tNa+BYeKZ3BwU=; b=rSsW9IZD7IoXvEuyOmgEot/wi2IckTqaMcV5ul7LKyDGJ7i+uCs9/cRaP59pTTTzN1 EWWfl2S7dlOja7oEFtCl7zTdaJLD6J2UUE18q3n6MK++rUC5lhgLWRAXAO/5oa8XrEH9 aTFfWDwZEe4pKWvfdDDdb4MIgHM171InTz0iDzpcLcbHStpbqBV+d41jBBzVITHBEK7L vINhW6dPerbH0XebW2RugWt06Q3mbWysXAkIbqXnt2mxLu+8P2LzBhtm4UZrzGRbzCO0 x80D1dRT4kDDXMbPtMTIHG87z6V+epybVulYwyoFunKn6dw7JTO5VXMNoNWO6H1pKXaE yGVw==
X-Gm-Message-State: AOAM530RRnWAArNhVNraglFVXMtoY719K0E+hcAi2TIi+/Y5ni6fGZPK 0nfL1GvrvhWSU4mSLB0aLHV/1PfLMKw8/g==
X-Google-Smtp-Source: ABdhPJz4IOVfkIzGjsMKihPzOqBXtzEsAbJ2WwBOIPGFVlS7UKQnVCTUd6GBv4HxFrYG0YoNrQX/eQ==
X-Received: by 2002:adf:f906:: with SMTP id b6mr24448749wrr.244.1605613670649;  Tue, 17 Nov 2020 03:47:50 -0800 (PST)
Received: from [192.168.178.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id n67sm3273122wmf.25.2020.11.17.03.47.49 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Nov 2020 03:47:50 -0800 (PST)
References: <160561332226.11634.7029583323888283532@ietfa.amsl.com>
To: oauth@ietf.org
From: Karsten Meyer zu Selhausen 
X-Forwarded-Message-Id: <160561332226.11634.7029583323888283532@ietfa.amsl.com>
Message-ID: <4b0a35e1-523f-d631-7bfe-7a81c1337f92@hackmanit.de>
Date: Tue, 17 Nov 2020 12:47:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <160561332226.11634.7029583323888283532@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------9445F8558E5A44908D9CC479"
Content-Language: en-US
Archived-At: 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Nov 2020 11:48:13 -0000

This is a multi-part message in MIME format.
--------------9445F8558E5A44908D9CC479
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi all,

thank you for your valuable feedback on the last draft version. Daniel 
and I tried to address all comments in the new version.

Changes in -02:

  * Incorporated WG feedback
  * Clarifications for unique issuer identifier
  * Clarifications when multiple issuer identifier could be present
  * Added note that iss parameter MUST NOT be used with JARM
  * Added note on error responses and example for error response
  * Editorial changes


We would like to ask you for further feedback and comments on the new 
draft version.

Best regards,
Karsten


-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
Date: 	Tue, 17 Nov 2020 03:42:02 -0800
From: 	internet-drafts@ietf.org
To: 	Karsten zu Selhausen , 
Daniel Fett , Karsten Meyer zu Selhausen 





A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
has been successfully submitted by Karsten Meyer zu Selhausen and posted 
to the
IETF repository.

Name: draft-meyerzuselhausen-oauth-iss-auth-resp
Revision: 02
Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization 
Response
Document date: 2020-11-17
Group: Individual Submission
Pages: 10
URL: 
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
Html: 
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-02.html
Htmlized: 
https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-02
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-02

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



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


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

Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:
https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021

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

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz


--------------9445F8558E5A44908D9CC479
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hi all,

    
thank you for your valuable
        feedback on the last draft version. Daniel and I tried to
        address all comments in the new version.

      

    
Changes in -02:

    
    
      
  • Incorporated WG
            feedback
    • 
      
  • Clarifications for
            unique issuer identifier
    • 
      
  • Clarifications when
            multiple issuer identifier could be present
    • 
      
  • Added note that iss
            parameter MUST NOT be used with JARM
    • 
      
  • Added note on error
            responses and example for error response
    • 
      
  • Editorial changes
    • 
    

    


      We would like to ask you for further
            feedback and comments on the new draft version.

          

    


      

    
Best regards,

    
Karsten

    


      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
          

          

            Date: 
            Tue, 17 Nov 2020 03:42:02 -0800
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Karsten zu Selhausen
              <karsten.meyerzuselhausen@hackmanit.de>, Daniel Fett
              <mail@danielfett.de>, Karsten Meyer zu Selhausen
              <karsten.meyerzuselhausen@hackmanit.de>
          

        
      

      

      

      

      A new version of I-D,
      draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt

      has been successfully submitted by Karsten Meyer zu Selhausen and
      posted to the

      IETF repository.

      

      Name: draft-meyerzuselhausen-oauth-iss-auth-resp

      Revision: 02

      Title: OAuth 2.0 Authorization Server Issuer Identifier in
      Authorization Response

      Document date: 2020-11-17

      Group: Individual Submission

      Pages: 10

      URL:
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt

      Status:
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

      Html:
https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-02.html

      Htmlized:
https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-02

      Diff:
https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-02

      

      Abstract:

      This document specifies a new parameter "iss" that is used to

      explicitly include the issuer identifier of the authorization
      server

      in the authorization response of an OAuth authorization flow. If

      implemented correctly, the "iss" parameter serves as an effective

      countermeasure to "mix-up attacks".

      

      

      

      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

      

      

    

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

Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:
https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021

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

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

  


--------------9445F8558E5A44908D9CC479--


From nobody Wed Nov 18 14:26:31 2020
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4BA3A0D9B; Wed, 18 Nov 2020 14:26:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <160573838909.19462.5961557297479283727@ietfa.amsl.com>
Date: Wed, 18 Nov 2020 14:26:29 -0800
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Nov 2020 22:26:29 -0000

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

        Title           : OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)
        Authors         : Daniel Fett
                          Brian Campbell
                          John Bradley
                          Torsten Lodderstedt
                          Michael Jones
                          David Waite
	Filename        : draft-ietf-oauth-dpop-02.txt
	Pages           : 29
	Date            : 2020-11-18

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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



From nobody Wed Nov 18 15:38:45 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E4B3A0E9C for ; Wed, 18 Nov 2020 15:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVBanTZhPljc for ; Wed, 18 Nov 2020 15:38:42 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD323A0EA0 for ; Wed, 18 Nov 2020 15:38:31 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id z21so5515424lfe.12 for ; Wed, 18 Nov 2020 15:38:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=x1iWIwrSkQmpudmDQH+eKCSUK2E3CsjFE+tUBAYAfc8=; b=GIGinX15baJIDQ6qCWHrrHN5q5Vih4zevhbBmhuC/LATAtd5wz/fEfFr/lTwc5aHCL Zb0A6LoclSCmK4hJaqXKJZ0YbkP5HJTKtQOnWktI9mkoHu+gCB2y/UhZmRiRNnWOgedx SXdYGVHVthVYZuD9Z7JQXclF3n78tJgXkRKH1gCJifwPm0fPN5wTgnChPsfw4FVq4gNH fVrlsYE1Ldd7pDumnPQU3Hk4qflfWbwiaqWj06Gt7bVLSnfhz9D0gJeesYEhRksxdOX+ vZgw8aM/wPbX6JK/8Fypr41f06XkX0+vR13mVvwVQI4u1sF8dScQzaeL0aoDz8PzO38m 0Oxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=x1iWIwrSkQmpudmDQH+eKCSUK2E3CsjFE+tUBAYAfc8=; b=l0IAuqbsMn9gTLVazTSvxl38nINEzgsc0jpbVaNmJPjEsHgpwav679ezu7l0e3N2Wk EYL1WqxMeKCzur1WMDSBRan3St/15puPuU4+ZX6iT3s28wQ64XHlspr1IOYvCrCoY8/2 bT2m8dRl0rnc0i88AU08AaiSGiUrG27Og/412QvrRVMPdU4iWg0N65ScG38BB1EV4fnc J8wxlVMEkm2Kgk67p3WICHs2+CZOPJvAxSg0GSJARict7tE118Oyy7ZJhSEUKDP31tQL bOxJY5gPRhGGGNC/jQGAPnXLTgADPtMfWb85h/p+nTWs/6O2vaYZzu3/aBfngAFpyRo9 7QYQ==
X-Gm-Message-State: AOAM532a10WDJKZzsWKM5+up3FFoEpq7i97+FAXY+xBnDQ4WHGZQOr0/ 3eA+wWcAoGSow2AxgpAQK4299uZEGqWj64Qt23A5JG3gKeMLRIF+Kd6BQdHdZ9eaDAmF7bFZn3j 4gNHDsuP9kf5d+u6Y+o0vpw==
X-Google-Smtp-Source: ABdhPJys9Pmg76XF70jO7YG3FxEX0pYXp32YyMFhNCE6J/dJKzO1AAVThTc5gA0opHgj49DPoLoaRy3r4NjUpV1NMvc=
X-Received: by 2002:ac2:4349:: with SMTP id o9mr4399434lfl.194.1605742707769;  Wed, 18 Nov 2020 15:38:27 -0800 (PST)
MIME-Version: 1.0
References: <160573838909.19462.5961557297479283727@ietfa.amsl.com>
In-Reply-To: <160573838909.19462.5961557297479283727@ietfa.amsl.com>
From: Brian Campbell 
Date: Wed, 18 Nov 2020 16:38:01 -0700
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000b29c7a05b46a1ba6"
Archived-At: 
Subject: [OAUTH-WG] Fwd:  I-D Action: draft-ietf-oauth-dpop-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Nov 2020 23:38:44 -0000

--000000000000b29c7a05b46a1ba6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I've published a somewhat overdue -02 revision of DPoP.  The changes in
this revision, which aim to address feedback and discussion from the list
and prior interim, are summarized below in text copied from the Document
History.The changes are a bit difficult to summarize though because, while
the document has gotten a bit of an overhaul, the actual protocol bits are
mostly unchanged. I do hope and think, however, that this new revision will
be easier to digest.

Note also that DPoP is the topic for the next interim meeting later this
month
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth
whre I plan to do a similarly poor job explaining the recent updates.

  Changes in -02:

   *  Lots of editorial updates and additions including expanding on the
      objectives, better defining the key confirmation representations,
      example updates and additions, better describing mixed bearer/dpop
      token type deployments, clarify RT binding only being done for
      public clients and why, more clearly allow for a bound RT but with
      bearer AT, explain/justify the choice of SHA-256 for key binding,
      and more

   *  Require that a protected resource supporting bearer and DPoP at
      the same time must reject an access token received as bearer, if
      that token is DPoP-bound

   *  Remove the case-insensitive qualification on the "htm" claim check

   *  Relax the jti tracking requirements a bit and qualify it by URI

---------- Forwarded message ---------
From: 
Date: Wed, Nov 18, 2020 at 3:26 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-02.txt
To: 
Cc: 



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

        Title           : OAuth 2.0 Demonstrating Proof-of-Possession at
the Application Layer (DPoP)
        Authors         : Daniel Fett
                          Brian Campbell
                          John Bradley
                          Torsten Lodderstedt
                          Michael Jones
                          David Waite
        Filename        : draft-ietf-oauth-dpop-02.txt
        Pages           : 29
        Date            : 2020-11-18

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-02


Please note that it may take a couple of minutes from the time of submissio=
n
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/


_______________________________________________
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._

--000000000000b29c7a05b46a1ba6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



I've published a somewhat overdue =
-02 revision of DPoP.=C2=A0 The changes in this r=
evision, which aim to address feedback and discussion from the list and pri=
or interim, are summarized below in text copied from the Document History.T=
he changes are a bit difficult to summarize though because, while the docum=
ent has gotten a bit of an overhaul, the actual protocol bits are mostly un=
changed. I do hope and think, however, that this new revision will be easie=
r to digest. 

Note also that DPoP is the topic=
 for the next interim meeting later this month https://datatracke=
r.ietf.org/meeting/interim-2020-oauth-16/session/oauth whre I plan to d=
o a similarly poor job explaining the recent updates. 

=
=C2=A0 Changes in -02:

=C2=A0 =C2=A0* =C2=A0Lots of edito=
rial updates and additions including expanding on the
=C2=A0 =C2=A0 =C2=
=A0 objectives, better defining the key confirmation representations,
=
=C2=A0 =C2=A0 =C2=A0 example updates and additions, better describing mixed=
 bearer/dpop
=C2=A0 =C2=A0 =C2=A0 token type deployments, clarify RT bin=
ding only being done for
=C2=A0 =C2=A0 =C2=A0 public clients and why, mo=
re clearly allow for a bound RT but with
=C2=A0 =C2=A0 =C2=A0 bearer AT,=
 explain/justify the choice of SHA-256 for key binding,
=C2=A0 =C2=A0 =
=C2=A0 and more

=C2=A0 =C2=A0* =C2=A0Require that a protected resour=
ce supporting bearer and DPoP at
=C2=A0 =C2=A0 =C2=A0 the same time must=
 reject an access token received as bearer, if
=C2=A0 =C2=A0 =C2=A0 that=
 token is DPoP-bound

=C2=A0 =C2=A0* =C2=A0Remove the case-insensitiv=
e qualification on the "htm" claim check

=C2=A0 =C2=A0* =
=C2=A0Relax the jti tracking requirements a bit and qualify it by URI
=

------=
---- Forwarded message ---------
From: <internet-drafts@ietf.or=
g>
Date: Wed, Nov 18, 2020 at 3:26 PM
Subject: [OAUTH-W=
G] I-D Action: draft-ietf-oauth-dpop-02.txt
To:  <i-d-announce@ietf.org>
Cc=
:  <oauth@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Web Authorization Protocol WG of the IETF.=




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP=
)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dani=
el Fett

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Brian Campbell

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 John Bradley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Torsten Lodderstedt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Michael Jones

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 David Waite

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-dpop-02.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 29

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2020-11-18



Abstract:

=C2=A0 =C2=A0This document describes a mechanism for sender-constraining OA=
uth 2.0

=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application =
level.

=C2=A0 =C2=A0This mechanism allows for the detection of replay attacks with=
 access

=C2=A0 =C2=A0and refresh tokens.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-o=
auth-dpop/



There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-i=
etf-oauth-dpop-02.html



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddraf=
t-ietf-oauth-dpop-02





Please note that it may take a couple of minutes from the time of submissio=
n

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/





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000b29c7a05b46a1ba6--


From nobody Thu Nov 19 00:45:04 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191563A11DE for ; Thu, 19 Nov 2020 00:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 HcABAjOWu7tE for ; Thu, 19 Nov 2020 00:44:57 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 97A823A11F4 for ; Thu, 19 Nov 2020 00:44:57 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id 62so3584675pgg.12 for ; Thu, 19 Nov 2020 00:44:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=W3qbSZMG5R33Ce5NOlwfYMx6lWupHX60ddIj1Xdwjc4=; b=HjrDF6JMbo3x9nO4Wda1cFTsFpfV2cpBJs+J7UnX48zqoDjeWc944NkYcV7Vzgic6O Kg0/aoMpVeR4Cp/NzvQ+iazi/0ShbHLJ1FtepNm0duHJ2Yfx3seom1ThwTMIZQynHbKW Uw5Nth0Q408bfjqfZIleLHmV69RWeGjpk69Uh/Xhdj9cObbRuKaTEKFZ3E1kd1Ax1YIi fZ85R8QkirDlh6e6j7Qkw8zsmdPlEZH81tuUkzWNwNr/AzY9hS+G56QpUAYe9qXTFVAh ZqH10ZnjLc2x49e+c/nIoastx61kIyz8cX68B3SMOL2vBQ9oOqDo5q6SRAfpYm+6gb64 MQFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=W3qbSZMG5R33Ce5NOlwfYMx6lWupHX60ddIj1Xdwjc4=; b=spNZt49p1Yl0BRX8hhmjkJxSPKCkl8iwoxu6bdlZNyP7fS0H8+L8Y3ozhYz1rSDJBv ePyov9/auH1clr/N26jIhPzslwPh9HHqhjbBWa7zIl6GtO23zbDWmgvt21iMgCMfq6Us /Cxwn++k1fjVmJd/57w6Bq3WgQijpTN5iFTxUjanbi9S9rzBUk0TG8xT74MdrLop1257 c+Nw69EeAX8XIeFVILYHFqvh18r5+qiTY3u7a3lOinZ/q0y6tLVNv3hUxQociRYmBXzi yYyxeC7ayIzJDVtpv+yA8qcZZ1V4fbfgf2IJoRdMXx8cePCJHOFyc6Q8h8srBJRkS43D 76EA==
X-Gm-Message-State: AOAM532Sgyjte3SQro9gTTnWK2e/P+NTSKGuxuOEbEyRcdIVgy6f8YOd LGRzRIH+98zbHF3juPQi5L53kPyj8b26SQ==
X-Google-Smtp-Source: ABdhPJyVHovzgGRQscNqpgZrur7Wdsij2m5F/lQzf5sw6BTTQthVTS2jdEoJNoPNoCIoIsZte4VLYQ==
X-Received: by 2002:a17:90a:de0c:: with SMTP id m12mr2675529pjv.224.1605775496653;  Thu, 19 Nov 2020 00:44:56 -0800 (PST)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id ga18sm5609978pjb.5.2020.11.19.00.44.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 00:44:55 -0800 (PST)
From: Vittorio Bertocci 
To: Roman Danyliw , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQC4rcyE
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 19 Nov 2020 08:44:54 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10
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, 19 Nov 2020 08:44:59 -0000

VGhhbmsgeW91IFJvbWFuIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3IQ0KSSBhcHBsaWVkIGFsbCB0
aGUgZWRpdG9yaWFsIGFuZCB0eXBvIGZpeGVzLiBJIGhhdmUgYSBmZXcgcXVlc3Rpb25zIG9uIHNv
bWUgY29tbWVudHMsIG9uY2Ugc29sdmVkIEknbGwgdXBkYXRlIGFjY29yZGluZ2x5IGFuZCBwdXNo
IGEgbmV3IHZlcnNpb24uDQpUaGFua3MhDQpJbmxpbmUNCg0KDQrvu78+T24gMTEvMTUvMjAsIDA4
OjM5LCAiT0F1dGggb24gYmVoYWxmIG9mIFJvbWFuIERhbnlsaXciIDxvYXV0aC1ib3VuY2VzQGll
dGYub3JnIG9uIGJlaGFsZiBvZiByZGRAY2VydC5vcmc+IHdyb3RlOg0KPlsuLl0gICAgDQo+ICAg
ICoqIFNlY3Rpb24gMi4yLjIuICBQZXIgIkFueSBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgd2hvc2Ug
c2VtYW50aWNzICAgQW55IGFkZGl0aW9uYWwgYXR0cmlidXRlcyB3aG9zZSBzZW1hbnRpY3MgYXJl
IHdlbGwgZGVzY3JpYmVkIGJ5IHRoZSBhdHRyaWJ1dGUncyBkZXNjcmlwdGlvbiBmb3VuZCBpbiBT
ZWN0aW9uIDUuMSBvZiBbLi5dDQo+ICAgTWF5YmUgbXkgcmVhZCBpdCB3cm9uZywgYnV0IGl0IHNl
ZW1zIGxpa2UgdGhpcyB0ZXh0IHNheWluZyB0aGF0IGJleW9uZCB0aGUgcmVxdWlyZWQgY2xhaW1z
IGxpc3RlZCBpbiBzZWN0aW9uIDIuMiwgeW91IGNhbiB1c2UgYW55IG9mIHRoZSBvdGhlciBjbGFp
bXMgYXMgbG9uZyBhcyB0aGV5IGFyZSBpbiB0aGUgSUFOQSBKV1QgcmVnaXN0cnkuICBJc24ndCB0
aGF0IHNpbXBsZXIsIHNpbmNlIHRoZSBTZWN0aW9uIDUuMS4gT3BlbklELkNvcmUgYXR0cmlidXRl
cyBhcmUgcmVnaXN0ZXJlZD8NCiBZb3UgYXJlIHJpZ2h0LCB0aGF0J3Mgbm90IHZlcnkgY2xlYXIu
IA0KSW4gYSBudXRzaGVsbCwgd2hhdCBJIGFtIHRyeWluZyB0byBzYXkgaXMgImlmIHlvdSB3YW50
IHRvIGV4cHJlc3MgYW4gYXR0cmlidXRlIGZvciB3aGljaCB0aGVyZSdzIGFscmVhZHkgYSB3ZWxs
LWVzdGFibGlzaGVkIGNsYWltIGF2YWlsYWJsZSwgdXNlIHRoYXQgcmF0aGVyIHRoYW4gaW52ZW50
aW5nICBuZXcgb25lLiIuDQpUaGF0IHN0aWxsIGFsbG93cyBmb3Igbm9uLUlBTkEgY2xhaW1zIHRv
IGJlIGludHJvZHVjZWQsIGFzIGxvbmcgYXMgdGhlIGltcGxlbWVudGVyIGhhcyBkb25lIHRoZSBk
dWUgZGlsaWdlbmNlIGFuZCB2ZXJpZmllZCB0aGF0IHRoZSBhdHRyaWJ1dGUgdGhleSBjb252ZXkg
aXNuJ3QgY292ZXJlZCBpbiB0aGUgSUFOQSBKV1QgcmVnaXN0cnkuDQpJIGV4cGxpY2l0bHkgbWVu
dGlvbiBPcGVuSUQgQ29ubmVjdCBhcyBzb3VyY2Ugb2YgY2xhaW1zIG1vc3RseSB0byBlbnN1cmUg
dGhhdCB0aGUgcmVhZGVyIHdpbGwgdW5kZXJzdGFuZCBhdCBmaXJzdCBnbGFuY2UgdGhhdCB3aGVu
IGl0IGNvbWVzIHRvIHVzZXIgaW5mb3JtYXRpb24gYSBKV1QgQVQgY2FuIGNvbnZleSB0aGUgc2Ft
ZSBpbmZvcm1hdGlvbiBvYnRhaW5lZCB2aWEgT3BlbklEIENvbm5lY3QsIHdpdGhvdXQgdGhlIG5l
ZWQgdG8gZm9sbG93IHRoZSBsaW5rIGFuZCBjb25zdWx0IHRoZSBjaGFuZ2UgY29udHJvbGxlci9y
ZWZlcmVuY2UgY29sdW1uIG9mIHRoZSBjbGFpbXMgdG8gcmVhbGl6ZSB0aGF0LiBPbmUgb2YgdGhl
IGdvYWxzIEkgYW0gaG9waW5nIHRoaXMgc3BlYyB3aWxsIGFjaGlldmUgaXMgdG8gc3RvcCBwZW9w
bGUgZnJvbSBhYnVzaW5nIElEIHRva2VucyBhbmQgdXNpbmcgdGhlbSBpbiBsaWV1IG9mIGFjY2Vz
cyB0b2tlbnMgKGFzIEt1YmVybmV0ZXMgcm91dGluZWx5IGRvZXMsIGZvciBleGFtcGxlKSwgaGVu
Y2UgdGhlICJkZW5vcm1hbGl6ZWQiIGxhbmd1YWdlIG9mIHRoYXQgc2VjdGlvbi4NCkhlcmUncyBh
biBhbHRlcm5hdGl2ZSBmb3JtdWxhdGlvbiB0aGF0IHRyaWVzIHRvIHByZXNlcnZlIHRoYXQgY2xh
cml0eSB3aGlsZSByZWZlcnJpbmcgdG8gdGhlIHJlZ2lzdHJ5OiANCg0KIkFueSBhZGRpdGlvbmFs
IGlkZW50aXR5IGF0dHJpYnV0ZSB3aG9zZSBzZW1hbnRpYyBpcyB3ZWxsIGRlc2NyaWJlZCBieSBh
biBlbnRyeSBpbiB0aGUgSlNPTiBXZWIgVG9rZW4gKEpXVCkgSUFOQSByZWdpc3RyeSBpbnRyb2R1
Y2VkIGluIFtSRkM3NTE5XSBTSE9VTEQgYmUgZW5jb2RlZCB1c2luZyB0aGUgY29ycmVzcG9uZGlu
ZyBjbGFpbSBuYW1lLg0KTm90ZSB0aGF0IHRoZSBKV1QgSUFOQSByZWdpc3RyeSBpbmNsdWRlcyB0
aGUgY2xhaW1zIGZvdW5kIGluIFNlY3Rpb24gNS4xIG9mIFtPcGVuSUQuQ29yZV0uIg0KICAgDQpX
aGF0IGRvIHlvdSB0aGluaz8gV2FpdGluZyBmb3IgeW91ciBmZWVkYmFjayBiZWZvcmUgY2hhbmdp
bmcgdGhlIGxhbmd1YWdlIGluIHRoZSBkcmFmdC4NCiAgIA0KPiAgICAqKiBTZWN0aW9uIDMuICBX
aGF0IHdvdWxkIGJlIHRoZSBjYXNlIHdoZXJlIGl0IHdvdWxkIG5vdCBiZSBhcHByb3ByaWF0ZSBm
b3IgdGhlIHJlc291cmNlIHBhcmFtZXRlciB2YWx1ZSB0byBiZSB0aGUgc2FtZSBhcyB0aGUgYXVk
IGNsYWltIGluIHRoZSBhY2Nlc3MgdG9rZW4gKHRoZSB0ZXh0IGN1cnJlbnRseSBzYXlzIFNIT1VM
RCwgd2h5IG5vdCBNVVNUPyk/DQpUaGlzIHdhcyBhY3R1YWxseSBhIE1VU1QgdW50aWwgZHJhZnQg
MywgdGhlbiBCcmlhbiBwb2ludGVkIG91dCB0aGF0IHRoaXMgd291bGQgaGF2ZSBtYWRlIHRoaXMg
cHJvZmlsZSBtb3JlIHJlc3RyaWN0aXZlIHRoYW4gcmVzb3VyY2UgaW5kaWNhdG9ycyBpdHNlbGYt
IHdoaWNoIGxlZCBtZSB0byBzb2Z0ZW4gdGhlIHJlcXVpcmVtZW50IGFjY29yZGluZ2x5LiBCcmlh
bidzIGNvbW1lbnQgaW4gaXRzIGVudGlyZXR5Og0KfFJlc291cmNlIEluZGljYXRvcnMgaXMgYWJv
dXQgaG93IHRoZSBjbGllbnQgY29udmV5cyB0aGUgdGFyZ2V0IHRvIHRoZSBBUyBhbmQgc2F5cyAi
IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBtYXkgdXNlIHRoZSBleGFjdCAncmVzb3VyY2UnIHZh
bHVlIGFzIHRoZSBhdWRpZW5jZSBvciBpdCBtYXkgbWFwIGZyb20gdGhhdCB2YWx1ZSB0byBhIG1v
cmUgZ2VuZXJhbCBVUkkgb3IgYWJzdHJhY3QgaWRlbnRpZmllciBmb3IgdGhlIGdpdmVuIHJlc291
cmNlIi4gVGhlIGZvbGxvd2luZyBmcm9tIHxzZWMgMyBpcyBtb3JlIHJlc3RyaWN0aXZlIC8gcHJl
c2NyaXB0aXZlLCB3aGljaCBzZWVtcyB0byByZWFjaCBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBK
V1QgYWNjZXNzIHRva2VuIHByb2ZpbGUuIA0KfHwgICJJZiB0aGUgcmVxdWVzdCBpbmNsdWRlcyBh
IHJlc291cmNlIHBhcmFtZXRlciAoYXMgZGVmaW5lZCBpbg0KfHwgW1Jlc291cmNlSW5kaWNhdG9y
c10pLCB0aGUgcmVzdWx0aW5nIEpXVCBhY2Nlc3MgdG9rZW4gYXVkIGNsYWltIE1VU1QNCnx8ICAg
aGF2ZSB0aGUgc2FtZSB2YWx1ZSBhcyB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGluIHRoZSByZXF1
ZXN0LiIgICAgDQogDQo+ICAgICoqIFNlY3Rpb24gNC4gUGVyIHRoZSB2YWxpZGF0aW9uIGd1aWRl
bGluZXMgb24gYWNjZXNzIHRva2VuIHZhbGlkYXRpb24sIGlzIHRoZXJlIHBhcmFsbGVsIHRleHQg
bmVlZGVkIHRvIGRpc2N1c3MgdGhlIFJTIHVzZSBvZiB0aGUgdG9rZW4gc2F5OiBjaGVja2luZyB0
aGF0IHRoZSBhY3IgaGFzIGEgdmFsdWUgdGhhdCBpcyBhcHByb3ByaWF0ZSAoc28gaXQgY2FuIGhh
dmUgY29uZmlkZW5jZSBpbiB0aGUgc2VjdXJpdHkgb2YgPiB0aGUgYXV0aGVudGljYXRpb24gdXNl
ZCBiZXR3ZWVuIGNsaWVudC9BUyk/IE9yIHRoYXQgdGhlIHJpZ2h0IGVudGl0bGVtZW50cy9ncm91
cHMvZXRjIHdlcmUgcHJlc2VudCBmb3IgdGhlIHJlcXVlc3RlZCBvcGVyYXRpb24/ICAgDQpUaGF0
J3MgYSBnb29kIHBvaW50LiBUaGUgbGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0IHdhcyBtZWFu
dCB0byBiZSBhIGNhdGNoLWFsbCBmb3IgdGhvc2UgY2FzZXMsIG1lbnRpb25pbmcgZW50aXRsZW1l
bnRzIHVuZGVyIHRoZSAiYXV0aG9yaXphdGlvbiBjbGFpbXMiIHVtYnJlbGxhIGFuZCBldmVyeXRo
aW5nIGVsc2UgYXMgImFueSBvdGhlciBjb250ZXh0dWFsIGluZm9ybWF0aW9uIi4gVGhlIHRoaW5n
IHRoYXQgbWFrZXMgbWUgaGVzaXRhdGUgYmVmb3JlIGdldHRpbmcgbW9yZSBzcGVjaWZpYyB0aGFu
IHRoYXQgaXMgdGhhdCBpdCBjYW4gYmUgYSBzbGlwcGVyeSBzbG9wZSAoYWNyLCBhbXIsIGVudGl0
bGVtZW50cyBldGMgYXJlIGdvb2QgY2FuZGlkYXRlcywgYnV0IHRoZSBzYW1lIG1pZ2h0IGJlIHNh
aWQgYWJvdXQgYXV0aF90aW1lIGZvciBtYXhfYWdlIGxpa2Ugc2NlbmFyaW9zLCBmb3IgZXhhbXBs
ZS4uLiB3aGVyZSB0byBkcmF3IHRoZSBsaW5lPykgYW5kIGJlaW5nIHRob3NlIG9wdGlvbmFsLCBu
b3QgZXZlcnlvbmUgbWlnaHQgcmVhZGlseSB1bmRlcnN0YW5kIHdpdGhvdXQgYWRkaW5nIG1vcmUg
Y29sb3IvY29udGV4dC4gQ29tYmluZWQgd2l0aCBob3cgZGlmZmljdWx0IHJlYWNoaW5nIGNvbnNl
bnN1cyBmb3IgdGhlIGluY2x1c2lvbiBvZiBzZXNzaW9uIHByb3BlcnRpZXMgaW4gYWNjZXNzIHRv
a2VucywgcGx1cyB0aGUgZmFjdCB0aGF0UkZDNjc1MCBkb2VzIG5vdCBnaXZlIFJTIHNwZWNpZmlj
IGd1aWRhbmNlIGZvciBob3cgdG8gYWN0IG9uIGF1dGhvcml6YXRpb24gaW5mbyAoc2NvcGVzKSwg
SSBvcHRlZCBmb3IgZ2VuZXJpYyBsYW5ndWFnZS4NCklmIHlvdSBmZWVsIHN0cm9uZ2x5IGFib3V0
IG1vcmUgc3BlY2lmaWMgZ3VpZGFuY2UgYmVpbmcgcmVxdWlyZWQgZm9yIHRob3NlIGNsYWltcywg
SSBjYW4gcHJvcG9zZSBtb3JlIHNwZWNpZmljIGxhbmd1YWdlLSBidXQgYmVmb3JlIGRvaW5nIHNv
LCBJIHdhbnRlZCB0byBvZmZlciB0aGUgY29udGV4dCBhYm92ZSB0byBzZWUgaWYgaXQgY2hhbmdl
cyB0aGluZ3MuICAgDQogDQogICAgDQogPiAgICoqIFNlY3Rpb24gNS4gIFRoaXMgdGV4dCBzZWVt
cyB0byByZXN0YXRlIG11Y2ggb2YgdGhlIHRleHQgZnJvbSBbT0F1dGgyLlNlY3VyaXR5LkJlc3RQ
cmFjdGljZXNdLiAgRG8gb3RoZXIgc2VjdGlvbiBhcHBseSBoZXJlPyAgUGVyaGFwcyBhbHNvIGFk
ZCB0aGF0IHRoZSBTZWNDb25zIG9mIGluZGl2aWR1YWwgY2xhaW1zIGFwcGx5IGhlcmUgdG9vIGlm
IHVzZWQgaW4gdGhlIHByb2ZpbGUgKGFzIHRoaXMgcHJvZmlsZSBhbGxvd3MgcHJldHR5IG11Y2gg
YW55dGhpbmcgaW4gdGhlIEpXVCByZWdpc3RyeSB0byBiZSB1c2VkKS4NCkkgY29tYmVkIGRyYWZ0
LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE2IGFuZCBiZXNpZGVzIHRoZSBwYXJ0cyBhYm91
dCBzdWIsIGNsaWVudF9pZCBhbmQgYXVkIChhbHJlYWR5IHJlZmVyZW5jZWQgYnkgdGhlIGN1cnJl
bnQgc3BlYywgb3IgZnVydGhlciByZXN0cmljdGVkLSBhcyBpdCB0aGUgY2FzZSBmb3IgdGhlIGF1
ZGllbmNlIGNvbnNpZGVyYXRpb25zKSwgdGhlIEJDUCBkb2VzbuKAmXQgYXBwZWFyIHRvIG9mZmVy
IGZ1cnRoZXIgZ3VpZGFuY2UgdGhhdCB3b3VsZCB2YXJ5IGRlcGVuZGluZyBvbiB0aGUgY29udGVu
dCBvZiB0aGUgdG9rZW4uIFRoZSBndWlkYW5jZSBzZWVtcyBtb3N0bHkgb24gaG93IHRoZSB0b2tl
biBpcyBvYnRhaW5lZCwgYW5kIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBvcGVyYXRlIGF0IHRo
ZSBtZXNzYWdlIGxldmVsIGhlbmNlIGFwcGx5IHRvIEpXVCBhY2Nlc3MgdG9rZW5zIGFuZCBvcGFx
dWUgdG9rZW5zIGluIHRoZSBzYW1lIHdheS4gRGlkIHlvdSBoYXZlIGFueSBzcGVjaWZpYyBzZWN0
aW9uIG9mIHRoZSBCQ1AgaW4gbWluZD8gDQpJIGFsc28gdG9vayBhIGxvb2sgYXQgcmZjNzUxOSBT
ZWNDb24gYW5kIGl0IGRvZXNu4oCZdCBhcHBlYXIgdG8gb2ZmZXIgY2xhaW1zLXNwZWNpZmljIGNv
bnNpZGVyYXRpb25zLiBGaW5hbGx5LCBJIGNvbWJlZCB0aHJ1IHJmYzg3MjUgYW5kIGl0IHNlZW1z
IHRoZSBjdXJyZW50IHNwZWMgY292ZXJzIGFsbCB0aGUgY29udGVudCBzcGVjaWZpYyByZWNvbW1l
bmRhdGlvbnMgdGhhdCBhcHBseSB0byB0aGlzIHNjZW5hcmlvLCBuYW1lbHkgaW4gc2VjdGlvbiA0
IGZvciB0aGUgYXVkaWVuY2UsIGlzc3VlIGFuZCBzdWJqZWN0IHZhbGlkYXRpb24sIGFuZCBzZWN0
aW9uIDIuMSBhbmQgNCBmb3IgdGhlIHN0cm9uZyB0eXBpbmcuDQpCb3R0b20gbGluZTogSSBjb3Vs
ZCBhZGQgYSBnZW5lcmljIHJlY29tbWVuZGF0aW9uIHRvIGNvbnNpZGVyIE9BdXRoMi5TZWN1cml0
eS5CZXN0UHJhY3RpY2VzLCByZmM3NTE5IGFuZCByZmM4NzI1IHdoZW4gY29uc2lkZXJpbmcgdGhl
IHNlY3VyaXR5IG9mIGEgSldUIGFjY2VzcyB0b2tlbiwgYnV0IHRoZSBvbmx5IHNlY3Rpb24gdGhh
dCBzZWVtIGRpcmVjdGx5IGFwcGxpY2FibGUgc2VlbXMgdGhlIDQuMTQgd2UgYWxyZWFkeSByZWZl
cmVuY2UuIFdoYXQgZG8geW91IHRoaW5rPyBEbyB3ZSBuZWVkIHRoYXQgYmxhbmtldCByZWZlcmVu
Y2U/DQogIA0KICAgICANCg==


From nobody Fri Nov 20 11:26:31 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E373A0ED5 for ; Fri, 20 Nov 2020 11:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNMng-1p09er for ; Fri, 20 Nov 2020 11:26:28 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055B63A0ED2 for ; Fri, 20 Nov 2020 11:26:27 -0800 (PST)
Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AKJQPlK000330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 20 Nov 2020 14:26:26 -0500
From: Justin Richer 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
Date: Fri, 20 Nov 2020 14:26:25 -0500
To: oauth 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: [OAUTH-WG] Token substitution in DPoP
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, 20 Nov 2020 19:26:30 -0000

While working on an implementation of DPoP recently, I realized that the =
value of the access token itself is not covered by the DPoP signature at =
all. What I=E2=80=99m wondering is whether or not this constitutes an =
attack surface that we care about here. Here=E2=80=99s how it works:


Let=E2=80=99s say that a client creates a DPoP key and uses that key to =
request two tokens, T1 and T2, for different users, Alice and Bob, =
respectively. Alice is malicious and wants to get Bob=E2=80=99s stuff. =
Alice manages to get a hold of Bob=E2=80=99s token value, T2, through =
some means. Normally DPoP wouldn=E2=80=99t let Alice create a new =
request using T2 since Alice doesn=E2=80=99t have the client=E2=80=99s =
key. However, if Alice gets the client to create a request for her using =
T1, she can copy the signature from that request onto a new request =
using T2. Since the signature doesn=E2=80=99t cover the token value and =
the key is the same, the RS should accept both requests, right?

An important aspect is that the parts needed to make this attack work =
are a little weird: you=E2=80=99d need access to a valid signed request =
from the client with T1 as well as access to a valid T2 attached to the =
same key in order to make this substitution. However, this is =
effectively the same attack area that bearer tokens have in a lot of =
ways, since it doesn=E2=80=99t require the attacker gaining access to =
the singing key to generate or modify a signature, nor does it require =
the attacker to generate or modify an access token (merely obtain one).


I=E2=80=99d like to understand if this is an actual attack against DPoP. =
If it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we =
discuss in the DPoP draft? I didn=E2=80=99t see a mention of it there. =
If it=E2=80=99s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access =
token itself inside the signature body instead of a second header. =
Another option would be to include a hash of the token value (such as =
OIDC=E2=80=99s =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in =
the DPoP payload. With either of these approaches, Alice having access =
to T1, T2, and a signed message for T1 does not allow her to use T2 =
effectively.

 =E2=80=94 Justin=


From nobody Fri Nov 20 18:30:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E393A0FD9 for ; Fri, 20 Nov 2020 18:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aueb.gr
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wXz-s-_GP1q for ; Fri, 20 Nov 2020 18:30:21 -0800 (PST)
Received: from blade-b3-vm-relay.servers.aueb.gr (blade-b3-vm-relay.servers.aueb.gr [195.251.255.106]) by ietfa.amsl.com (Postfix) with ESMTP id C25523A0FD8 for ; Fri, 20 Nov 2020 18:30:19 -0800 (PST)
Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [195.251.255.217]) by blade-b3-vm-relay.servers.aueb.gr (Postfix) with ESMTP id 49C68DDD; Sat, 21 Nov 2020 04:30:18 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aueb.gr; s=201901; t=1605925818; bh=h0Rg2gXfv/h+rmZGYGu3UwP0ku4gem9vfExqqkn18n0=; h=From:To:References:In-Reply-To:Subject:Date:From; b=GfKPb3LmfxE3ex3OsiwkxZ1yaS2GOyxR/S4HARdy2s5Je5+V1/E6sr//w3l9x2SXO Owxj0QZA1/2fso6zu/oHc01xROcWIFOUIC/6vuOTiE+Q8PlNTF9w2+PNn0nP9HxyIm ZDPt6Hh2UCeAJqryxeN4a4IU9tGKxSZ4w+azzJFWgRKrVLmAhaPKL/m4RjlkTCK8cK +s2wvT1jU9XlyXnKzzdoMz8dlQzdacYuovyEHN6FeT6TXGGGRfN8mCAVbFiTF4jBaC GimxuVnTXdNazPZgUiK/f0hMnV5a3/ssZXL6SzDrH0X7RnBVnw1p3MQX35W00RDFPV buHJcg/bwO0jw==
Received: from DESKTOP7VDSLBL (athedsl-4546155.home.otenet.gr [94.70.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fotiou@aueb.gr) by blade-a1-vm-smtp.servers.aueb.gr (Postfix) with ESMTPSA id DC3E35DE; Sat, 21 Nov 2020 04:30:17 +0200 (EET)
From: "Nikos Fotiou" 
To: "'Justin Richer'" , "'oauth'" 
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
In-Reply-To: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
Date: Sat, 21 Nov 2020 04:30:17 +0200
Message-ID: <016f01d6bfae$407e6bd0$c17b4370$@aueb.gr>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFsNp1WzMQLqWr/LSN3K9lSN/t1H6qm7huQ
Content-Language: el
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_016B_01D6BFBF.0343C4C0"; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 21 Nov 2020 02:30:23 -0000

This is a multipart message in MIME format.

------=_NextPart_000_016B_01D6BFBF.0343C4C0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,
The token is granted to a client based on the authorization grant and =
not the client's key. Therefore, a client may use a different key per =
token. At least this is an approach we are following.=20

Best,
Nikos

-----Original Message-----
From: OAuth  On Behalf Of Justin Richer
Sent: Friday, November 20, 2020 9:26 PM
To: oauth 
Subject: [OAUTH-WG] Token substitution in DPoP

While working on an implementation of DPoP recently, I realized that the =
value of the access token itself is not covered by the DPoP signature at =
all. What I=E2=80=99m wondering is whether or not this constitutes an =
attack surface that we care about here. Here=E2=80=99s how it works:


Let=E2=80=99s say that a client creates a DPoP key and uses that key to =
request two tokens, T1 and T2, for different users, Alice and Bob, =
respectively. Alice is malicious and wants to get Bob=E2=80=99s stuff. =
Alice manages to get a hold of Bob=E2=80=99s token value, T2, through =
some means. Normally DPoP wouldn=E2=80=99t let Alice create a new =
request using T2 since Alice doesn=E2=80=99t have the client=E2=80=99s =
key. However, if Alice gets the client to create a request for her using =
T1, she can copy the signature from that request onto a new request =
using T2. Since the signature doesn=E2=80=99t cover the token value and =
the key is the same, the RS should accept both requests, right?

An important aspect is that the parts needed to make this attack work =
are a little weird: you=E2=80=99d need access to a valid signed request =
from the client with T1 as well as access to a valid T2 attached to the =
same key in order to make this substitution. However, this is =
effectively the same attack area that bearer tokens have in a lot of =
ways, since it doesn=E2=80=99t require the attacker gaining access to =
the singing key to generate or modify a signature, nor does it require =
the attacker to generate or modify an access token (merely obtain one).


I=E2=80=99d like to understand if this is an actual attack against DPoP. =
If it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we =
discuss in the DPoP draft? I didn=E2=80=99t see a mention of it there. =
If it=E2=80=99s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access =
token itself inside the signature body instead of a second header. =
Another option would be to include a hash of the token value (such as =
OIDC=E2=80=99s =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in =
the DPoP payload. With either of these approaches, Alice having access =
to T1, T2, and a signed message for T1 does not allow her to use T2 =
effectively.

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

------=_NextPart_000_016B_01D6BFBF.0343C4C0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEj4w
ggQxMIIDGaADAgECAgEAMA0GCSqGSIb3DQEBBQUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7
SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3Jp
dHkxQDA+BgNVBAMTN0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg
Um9vdENBIDIwMTEwHhcNMTExMjA2MTM0OTUyWhcNMzExMjAxMTM0OTUyWjCBlTELMAkGA1UEBhMC
R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg
Q2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2gg
SW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
qVMA4y6m9o76YNgtlT74LCpUTs25hGGUWE+PPYvkQ/N1iY1R5MM30oqITXketxLdQ3hKipLm10jV
D6Q6KUQ1uAf2aB1VzThR8IwkMYWvg8l96Xev7Rp7nRf5s504UA+mWnmRgK83rqbTMfu1JgmdPFrv
UcUr35Zd6zIeAtpwSexuDMiaN4338TZgSyYsgp7QePMND2OkUTDh+SsnEgfY6r0YYpiwWTd9vu7z
IFFCWoPvk7ppFfFinZ+ZOYKht3Qui9TFC3sv8MgK2j15CpqTHKUocnORQ5qn0U2FhLmpdI8UQMfc
3qxBZGy0GZsCY20kZI9EsiXqzl10DGMyXI2H5QIDAQABo4GJMIGGMA8GA1UdEwEB/wQFMAMBAf8w
CwYDVR0PBAQDAgEGMB0GA1UdDgQWBBSmkUL9E2FKI54IpCnl2BMEI+5BJTBHBgNVHR4EQDA+oDww
BYIDLmdyMAWCAy5ldTAGggQuZWR1MAaCBC5vcmcwBYEDLmdyMAWBAy5ldTAGgQQuZWR1MAaBBC5v
cmcwDQYJKoZIhvcNAQEFBQADggEBAB/veUHhe24/soyGN0JKThw3Ho1muiSByU8SDyHAA5eGJW1d
0yIpqGyiDanrPQZbmTrHzMOaNH+rDshOHOH65NzNDb6/JP5s52vCDcgGnk6NYSimav3l9mLqGDxO
oFOdsjqc66WckRa2TYLgDAVIqWz1zPjLnUm08AKl/XAD7Yohpa4ThknDM3O+hzt0ixdFJkwWkYP+
Z33NTWNn+vMDEpZ4Bo2xZ+2OP76fTwL1swkv80yH3yrLlXwBzKw2er+ic3r3j8G1mqEUso8znw3v
Itxme4S9RRcGPTzKuXc0j8rqzz8xPuOI44BJJciXtZ2amU2wPPhKAJtk3Z85S9En17gwggbQMIIE
uKADAgECAhBAB3aGT+I5a2zJV9kPcbUZMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQGEwJHUjFE
MEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0
LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQg
QnVzaW5lc3MgQ0EgUjIwHhcNMTkxMjEyMTQxNzU4WhcNMjExMjExMTQxNzU4WjCCAQkxCzAJBgNV
BAYTAkdSMQ8wDQYDVQQHDAZBdGhlbnMxNDAyBgNVBAoMK0F0aGVucyBVbml2ZXJzaXR5IG9mIEVj
b25vbWljcyBhbmQgQnVzaW5lc3MxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtleSBjcmVh
dGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMQ8wDQYDVQQEDAZGT1RJT1kxETAPBgNVBCoM
CE5JS09MQU9TMRMwEQYDVQQFEwozODY2OTQxMjIxMRgwFgYDVQQDDA9OSUtPTEFPUyBGT1RJT1kx
HTAbBgkqhkiG9w0BCQEWDmZvdGlvdUBhdWViLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAgLLzGBqZBB4A0EYdBSjLSUYjNMZYSS14Z4+Esf6iK7wrSw8pOfjLBMqtJOywazPxWgmm
vhk6PaCLhZYgwPqdGQk3z+m3Hm2ao9fnFghTIBhXyypOJVCEVNblcY1r6+HZZLZZ/Z5NnMLuNKK+
uWQ7dRR/GZDOFGcnOtcmMx9GKrgSrawVOsghzBRg5wLbvCaCNJsJ90mRYsyUjkg9OglG2dzZ7Bi0
2BzozUwP69dFaKG7ml12C9FwQiaBURg3dDbgl7AuGY1AZcqBAPwKNni0Jkpl5XL2JzjbzQj73EbT
FMrsgG1PbGw/uZgQyCqAVHS1HiIJhyMTn7cttd5CobkMMwIDAQABo4IBqTCCAaUwHwYDVR0jBBgw
FoAUd2BZxxknkkBQvIKZbY8+SdAQ9CowbQYIKwYBBQUHAQEEYTBfMDoGCCsGAQUFBzAChi5odHRw
Oi8vcmVwby5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhQXVlYkNBUjIuY3J0MCEGCCsGAQUFBzABhhVo
dHRwOi8vb2NzcC5oYXJpY2EuZ3IwGQYDVR0RBBIwEIEOZm90aW91QGF1ZWIuZ3IwWAYDVR0gBFEw
TzAIBgYEAI96AQEwQwYNKwYBBAGBzxEBAQICATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3JlcG8u
aGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgor
BgEEAYI3CgMMMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmx2MS5oYXJpY2EuZ3IvSGFyaWNh
QXVlYkNBUjIvY3JsdjEuZGVyLmNybDAdBgNVHQ4EFgQUcMJMYLF3+xjl9x4Fc4V2qRdAoVIwDgYD
VR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAo/QEb7ED5Z7e3qdVPfIdKRpnLQ+JH3V7w
4CKouEZkSjH2m+y0WOtMoF4cPCNrMH90n/IH9QuGcyYALRQTXAKsgF5s5TIeHc8fpFAesjoVjTHT
ijK94b4ekh81jU/o8sRhsfWjPzAjzhSogWuh9yYox7fx0pvnux9lGE2+mVhE0xJqzP4N6zGmVsYY
Og6YfOtjYK46lvT5WOKkdK9lD9S3vmws0BPOCirvIqc9/fzKngZMTcsXMEZp91z40SuUxn48P370
TKgvzIkmnDVB/iOobkdErAgp5j2o6s/Bt2m91VwLW3xOIV4F9y8BGOxsRqvRkv7wMKmhTjkAT+MV
F7uw1S+vmeTeL+pdFUBAKJRizEqjCL6D7ZwpKszeMhi6Sx31ooOPpTOWtPh/fLfRRJBYNFcrYgMl
Br0WWe1nIYajWskliR+5HNyNY8/zQApm9SGqr4VjaYdEwnU+NVLiZ2pikWyrg5B8QyqcJCNdZRez
jOPqM6DN+t52HMSnqHFxsy6cqOfqOSAsitZT2LkBWVDj3TxkENnw04hPUS4ip48jMB0szuajEMmK
qs5/uGY9EyQ3bHlDDWQxu/DULZJOcsZPX67mcOTLfXOXFnyW/gOGbvCgitlimm7xrDHmVWvB4AE7
XPK7ogjGmG1qEq7vnYOcgj93DGizi+QkmVMCJwpGYjCCBzEwggYZoAMCAQICCBjdh64fS7Z7MA0G
CSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMg
YW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMTN0hlbGxl
bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEwHhcNMTUw
NzI4MDcxMDQ4WhcNMjMwNzI2MDcxMDQ4WjCBjzELMAkGA1UEBhMCR1IxRDBCBgNVBAoTO0hlbGxl
bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9yaXR5MTow
OAYDVQQDEzFBdGhlbnMgVW5pdmVyc2l0eSBvZiBFY29ub21pY3MgYW5kIEJ1c2luZXNzIENBIFIy
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjTO6hsbRRbmkpEjRUM1K7/Mn2XgBgh/T
p6AbDXt5rS/oFBc/GJ5bCJFc7P1d1LHMSM1VT0advzlwE2xdnR0X9ThYKIm67gOAs1RUHxLqSYcr
g2qkGdm1LadSwfn8KTDAxXynmVHhduU5jOTWS/LbX18EkZQ0tWiTEHxN+Uj7RFGzPrrEC6C3x+W/
jZ9uZEfjLOxC0FHkYGndlHWh2SnoJyKvcWXE1F3DEdsGhm7gK/wxRG70U1ryihV3upd43YNdxEzB
BEP2RIR8UDPLt4UpdfmmTk9uVJR6waYYtpnF10PSpuMRXNqV2dtlXCz8OEuoWFSlJbUF7VmwiZID
g5P7INZ9bRWercaBquvOdDk0hBcuUfadx7TfPQHRhhUAP9UGvGcJsX7gP/3R0eUMGC6QH+Ly5LKd
fHpubVABNQnXcKXgVQtjJWGObSGsnz/X3PmhF+MYlQRtrT7852Paf0xnQ1klXaLpd04jRK/EoVrJ
s9jZWggPatQsX9aWuXR7xWGqOR3kT7aetAwk3FgT896eUj5V1C5eJZy9b21SJm5ux2WtmrcpCtDc
YSafDaJ/0toGUPnZZnDMyyKYbuQvNu7AVYcT5uFTu84JKTqjl8jrXb4PITFN7rjKPOb0geJm+RtT
De9Shan4d0vty9xWUDvMV5utJPIkreaRdGDbbNJQkP0CAwEAAaOCAocwggKDMA8GA1UdEwEB/wQF
MAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR3YFnHGSeSQFC8gpltjz5J0BD0KjBGBgNV
HR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEuaGFyaWNhLmdyL0hhcmljYVJvb3RDQTIwMTEvY3Js
djEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9E2FKI54IpCnl2BMEI+5BJTBuBggrBgEFBQcBAQRi
MGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLmhhcmljYS5ncjA7BggrBgEFBQcwAoYvaHR0cDov
L3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhUm9vdENBMjAxMS5jcnQwggE3BgNVHSAEggEuMIIB
KjCCASYGBFUdIAAwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5nci9kb2N1bWVu
dHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2Vh
cmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoGJVGhpcyBjZXJ0
aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91ciBDUFMuIFRoaXMgQ2VydGlm
aWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBlZHVjYXRp
b25hbCBwdXJwb3Nlcy4wLQYDVR0eBCYwJKAiMAmCB2F1ZWIuZ3IwCYEHYXVlYi5ncjAKgQguYXVl
Yi5ncjANBgkqhkiG9w0BAQsFAAOCAQEAhSXJoQDbTRBYH549pfk9+3CjT+HnAcFajp60aV8UYR63
DZflolPCDagaRxADLd3SpbOuGlRGNw+MgYpAp/d6i5BfVpjMVIhp5E7zr6TDJgVIwt2UxuLejfow
umCNkRJD+RrdUcLKHzcPOfSD40MRHprehXT1bvyuka26ogF6U0T2uEDoOIaObV/RS9wgGx9y63/Q
Ic/tsZNQ3pzcAbTecnax6ITfSvnnfeMol6IcS+rKxPwKjPPFQq93qT8w61qe+zEx54vRwJXi241e
dkTmBTJddM5Cdhxxy98xYX+eYNnf5x96vVDQ1qc2wcecMHADZBrfVV/tx0Ev6hTlYBhOmzGCBEUw
ggRBAgEBMIGkMIGPMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5k
IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBV
bml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MgQ0EgUjICEEAHdoZP4jlrbMlX2Q9x
tRkwDQYJYIZIAWUDBAIBBQCgggJxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTIwMTEyMTAyMzAxNlowLwYJKoZIhvcNAQkEMSIEIAEXQlwPojpyfBC+9+fBRCGEvxT+
swhyQ+LT6qpUXSuzMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMIG1BgkrBgEE
AYI3EAQxgacwgaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBh
bmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5z
IFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZ
D3G1GTCBtwYLKoZIhvcNAQkQAgsxgaeggaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxs
ZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6
MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBS
MgIQQAd2hk/iOWtsyVfZD3G1GTANBgkqhkiG9w0BAQEFAASCAQAJD6LtTTCJolLMmmFFIlT0ZQdg
HhmmQT4s6F2/svS3+wSRMbAsLSPLqZuTa/Lov79j275cbQbv4ElrVGEfTYjqmkYEuy4b/pnrii+C
Z/HpoPiilgcucn4e2zNt9juGNjPHbwGpZELHkWP/laKXVui5LrujWCHtPgLDExYl7UUhUgw3Fyfk
QB2NVHUOrt2/0erN0CLse8XBoWE/ryQSOPQ0naGRmR5R/FWHTlXv/RnJpmC9euXEp95LIhHF3ZCr
losrt6hQBW1RZv4UJsNxkp0eq8Mvmd4QtQongbX5D46ljVa32xqI0c9pGtydZsO2cqyYXwAtlcvd
SjOzrPGD2e5LAAAAAAAA

------=_NextPart_000_016B_01D6BFBF.0343C4C0--


From nobody Mon Nov 23 03:51:53 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D633A0972 for ; Mon, 23 Nov 2020 03:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.019
X-Spam-Level: 
X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rj5aI3-YNfu for ; Mon, 23 Nov 2020 03:51:49 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6D23A0969 for ; Mon, 23 Nov 2020 03:51:48 -0800 (PST)
Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0ANBpgjU009435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Nov 2020 06:51:43 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Justin Richer 
In-Reply-To: <016f01d6bfae$407e6bd0$c17b4370$@aueb.gr>
Date: Mon, 23 Nov 2020 06:51:42 -0500
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0352818D-4793-44E2-832B-3FD7B7BF7507@mit.edu>
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu> <016f01d6bfae$407e6bd0$c17b4370$@aueb.gr>
To: Nikos Fotiou 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 23 Nov 2020 11:51:51 -0000

Correct, but the choice of using different keys is entirely in the hands =
of the client, as the AS accepts whatever key the client presents in its =
initial DPoP proof to bind to the token. If it=E2=80=99s on the client =
to prevent this kind of thing, we should at least mention it in the =
security considerations. If it=E2=80=99s something we want to prevent =
wholesale, we should expand the signature coverage to the access token, =
or at least a hash of the token.

 =E2=80=94 Justin

> On Nov 20, 2020, at 9:30 PM, Nikos Fotiou  wrote:
>=20
> Hi,
> The token is granted to a client based on the authorization grant and =
not the client's key. Therefore, a client may use a different key per =
token. At least this is an approach we are following.=20
>=20
> Best,
> Nikos
>=20
> -----Original Message-----
> From: OAuth  On Behalf Of Justin Richer
> Sent: Friday, November 20, 2020 9:26 PM
> To: oauth 
> Subject: [OAUTH-WG] Token substitution in DPoP
>=20
> While working on an implementation of DPoP recently, I realized that =
the value of the access token itself is not covered by the DPoP =
signature at all. What I=E2=80=99m wondering is whether or not this =
constitutes an attack surface that we care about here. Here=E2=80=99s =
how it works:
>=20
>=20
> Let=E2=80=99s say that a client creates a DPoP key and uses that key =
to request two tokens, T1 and T2, for different users, Alice and Bob, =
respectively. Alice is malicious and wants to get Bob=E2=80=99s stuff. =
Alice manages to get a hold of Bob=E2=80=99s token value, T2, through =
some means. Normally DPoP wouldn=E2=80=99t let Alice create a new =
request using T2 since Alice doesn=E2=80=99t have the client=E2=80=99s =
key. However, if Alice gets the client to create a request for her using =
T1, she can copy the signature from that request onto a new request =
using T2. Since the signature doesn=E2=80=99t cover the token value and =
the key is the same, the RS should accept both requests, right?
>=20
> An important aspect is that the parts needed to make this attack work =
are a little weird: you=E2=80=99d need access to a valid signed request =
from the client with T1 as well as access to a valid T2 attached to the =
same key in order to make this substitution. However, this is =
effectively the same attack area that bearer tokens have in a lot of =
ways, since it doesn=E2=80=99t require the attacker gaining access to =
the singing key to generate or modify a signature, nor does it require =
the attacker to generate or modify an access token (merely obtain one).
>=20
>=20
> I=E2=80=99d like to understand if this is an actual attack against =
DPoP. If it isn=E2=80=99t, how is it countered by DPoP today? If it is, =
do we discuss in the DPoP draft? I didn=E2=80=99t see a mention of it =
there. If it=E2=80=99s not, should we discuss it there?
>=20
>=20
> The old OAuth PoP draft mitigates this attack by putting the access =
token itself inside the signature body instead of a second header. =
Another option would be to include a hash of the token value (such as =
OIDC=E2=80=99s =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in =
the DPoP payload. With either of these approaches, Alice having access =
to T1, T2, and a signed message for T1 does not allow her to use T2 =
effectively.
>=20
> =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Nov 23 05:03:20 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA5C3A0ADF for ; Mon, 23 Nov 2020 05:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.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 zWGR-IRh7nYx for ; Mon, 23 Nov 2020 05:03:16 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (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 8BDB73A0AC1 for ; Mon, 23 Nov 2020 05:03:15 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3FF411BE47E; Mon, 23 Nov 2020 08:03:14 -0500 (EST)
Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id A45F11BE0A4; Mon, 23 Nov 2020 08:03:13 -0500 (EST)
Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 9648680C79D; Mon, 23 Nov 2020 08:03:13 -0500 (EST)
Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4CfnQ94HWyz3D4CC; Mon, 23 Nov 2020 13:02:57 +0000 (UTC)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2102.outbound.protection.outlook.com [104.47.64.102]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4CfnPm17JFzmqC; Mon, 23 Nov 2020 13:02:52 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iBXj/9Q9o7xHIgkP9YJTwy+G3k8BDyR8uC4UuU5If1XMdlCZI+jGhzFh2rPgB90+41ZKyYpXzlaCHyk9V6de/wVbvcfyETgKmIkv2kSE5BpgvRZR8HbikImAlfaNY15rWFTX/G2cO/xgqsz9W6uWOBY096qzsHc6FpuYXKMCGaJ9qBVdLahlIXhLC7J/4aUd9Vv8xR8N9tWKG5luOn6ZFqj2V4p1jwJdbZDy+gYtSBqTvr3diIREe4xBta9oIVIl/M4WPvXwzwVXlewL93OIAfdWjYW5CwHlz7q+/vjMXMFUHsRsqAJwZGBqkMeVDfI65nJfiiDB1XZaH4BGO2Uhnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i/kiD+j8Tk6pxGHnwMZNDYW4fntfZBoyypYTBvANc2M=; b=YhFRpCIlotSDsBI9ERWCZPBZ98Xzho4CIapXmgImRJCcCiOmKgwQI54q15qs8+3bpGPSDlwwGnd+xk/d8CHK6hhxljZqDSaSS1VjOO3NCHp7KIWvXoZUuPgHiYn0Z/XM1STAbq2z+5bOl0sn4eLvSrVjr8PTjEj1gPEeEwfi4BgW2Bzx07PxnF53SoDyGTCPICwEfIY0l1OIlbdJncj3Ome9zafv6VLKfTLPa//16zh8FYtTU57I6nnUmFxC/I+k4Xydjje8LxAApgDuOh9oTdyjp1Io4vEGjDBVhM6INRlw1abHdc+ohw2b/6N90+UQgeg9/80mnsbxqL0ZomCMdw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none
Received: from MN2PR09MB5724.namprd09.prod.outlook.com (2603:10b6:208:213::14) by MN2PR09MB5161.namprd09.prod.outlook.com (2603:10b6:208:220::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 13:02:50 +0000
Received: from MN2PR09MB5724.namprd09.prod.outlook.com ([fe80::4879:b624:224a:644c]) by MN2PR09MB5724.namprd09.prod.outlook.com ([fe80::4879:b624:224a:644c%3]) with mapi id 15.20.3589.030; Mon, 23 Nov 2020 13:02:50 +0000
From: Michael A Peck 
To: Justin Richer , Nikos Fotiou 
CC: oauth 
Thread-Topic: [EXT] Re: [OAUTH-WG] Token substitution in DPoP
Thread-Index: AQHWwY8CzMQLqWr/LSN3K9lSN/t1H6nVWvUA
Date: Mon, 23 Nov 2020 13:02:50 +0000
Message-ID: <2B99664F-C236-422D-BBA1-BCF99485DBDC@mitre.org>
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu> <016f01d6bfae$407e6bd0$c17b4370$@aueb.gr> <15245_1606132326_5FBBA25D_15245_296_1_0352818D-4793-44E2-832B-3FD7B7BF7507@mit.edu>
In-Reply-To: <15245_1606132326_5FBBA25D_15245_296_1_0352818D-4793-44E2-832B-3FD7B7BF7507@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.42.20101102
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=mitre.org;
x-originating-ip: [192.80.55.89]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8dd72f1d-226f-4fbe-c57c-08d88fb01548
x-ms-traffictypediagnostic: MN2PR09MB5161:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rxKEfWVLC1KhCSW+Khqctw3eVPEXMNFGH5W769+5uil3/9oD7Ix5sPWSp0GzahG/U6/hF0LrJWMu4WhWfX83NhgxtphT3t6qahtqww8n0wtpy+JwP1DSCbRx8Q9kJKPPTeS8SZMZ0WZ9DZVy+hBRrZbIBsK89pvOAGWvsP87uQhtTRZzx75y479j63bi6g678d3ASNPWXK10luA2GaraSRfprOXCYVuIyHSzhi2WxJtohtyEQsQQgI2dK97nX7MixSwnUiBqxg9bPceLF4pRuKl56XUpLUpHpUL0YaI/hD576TI8cFJN2MPYMHIpZsJDntXP4OFni+iD8H1hbDlpND4Ixoihn+OCyfxy2rP6S5FGtsEkCV3M8oCQ7WA1BxXDIftMyNOLeH4p1v/2NWPBMQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR09MB5724.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(136003)(396003)(346002)(366004)(39850400004)(376002)(83380400001)(26005)(6512007)(186003)(86362001)(4326008)(2616005)(36756003)(66476007)(8676002)(53546011)(110136005)(966005)(6506007)(316002)(6486002)(71200400001)(33656002)(2906002)(5660300002)(76116006)(8936002)(66946007)(478600001)(64756008)(66446008)(66556008); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: FJR5JUUmQJfjwPbY14TOYfEZiYfcdWpLpeh/wu3TTjdzD9YKJkYBFzHc2KDNNvS+0EzEtasnYIBlJ1yo37iBhe51ZicIV2bNaS3EI526hgHRGlQUN1ipmEu5/XYzKknHoIldADCTEdRkUis/E5pwfdiShQ2XxA43PByLvYz50dNXj22qug109lx74YaIUXQv61ya3+PNIK9T3P8BlhFVQrJFrLwOe6zOnv09jg1ybmisaHTEciZjbX4/0gQPLCXfnrBQCTi+Zq9VlX+5mUGaFsYEBb99y2IbR5soh50+ySQpCt3j8Ao0pzR0WC14F0eCku+Bts67PVk0EacXOTSuOvbjBU1Z0WrfJofG8Zo14/HWsoG6w47NBLByVEOqmKaIEBsnb4Yfsa5FtWIC375b4VKb0sI55/plJCh1MVamCocZtZ4JDvg9IyGlf1goN0+qZ9wayt9bUYar9yQr6nkjBpigQfYmygCSivx1V6BP9KWBXs/7asS67/Rg5BgzcwFSb67GyL1omQ2npmf88xHnUpdz36sS0JQIhBLVVt3D8E4CoQR2xE4h9AgRN2vapChFidIk6cbz4CzPBeBK2v/3Bz4R59WsjEvI6df4XbQTZox0MaTK1zkgtZUFp4eMIsvj4b2Ax3e2WjJvcO0jUlgHclJGtUPO3oDIEYtJks+Ibjh4n9OyZKF36tf1zp8aIZtJMRDtVL/qR+Na/eFUDUlUB3kkDLQjeJfeLyVgtG9c1PKDeas1vxhOAKREnfDFM4GhIvLYZhAKrGYX9KkabXzeqLeEy1xB2/gkukRhW15E8xJz4czm5/wpZQ0aX7qNI65Ov28bBUOIBWZNTU+gYfIYZaAbMAdslRXKUhntOqMOvIzzqw28KDmumckphGU8SBjVPN4EktV+IMcpQySuemAGTg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: mitre.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5724.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8dd72f1d-226f-4fbe-c57c-08d88fb01548
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 13:02:50.5697 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: n7JMctnTt8NGwXwdxxbD4EPLb6Dh6IA1fOkoBh3/z7k4TQ24K3B3KnejeIsuvJHh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5161
X-MITRE: 8GQsMWxq66rxk57w
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:content-id:content-transfer-encoding:mime-version; s=selector1; bh=i/kiD+j8Tk6pxGHnwMZNDYW4fntfZBoyypYTBvANc2M=; b=kxhXkcY5jW/nSImDWptilU2jDYSPCp/lKgxSSfh/xfFRTANJkCfnUyRIq61/l6DLDrtZRC6TU01nkQA6gelUVpF+Xk1xoSTmzlY5TzwmLKaU/rtq2RUJHKjS+QBhY1CfkHWr+kTstoPUM2II9Uo3kE2kp94sFVB6S+QdpE+WV3E=
Archived-At: 
Subject: Re: [OAUTH-WG] [EXT] Re:  Token substitution in DPoP
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, 23 Nov 2020 13:03:19 -0000

SSBhZ3JlZSB3aXRoIGhhdmluZyB0aGUgRFBvUCBwcm9vZiBjb3ZlciB0aGUgYWNjZXNzIHRva2Vu
ICh1bmxlc3MgdGhlcmUncyBzb21lIGJ1cmRlbiBvbiB0aGUgY2xpZW50cyBkb2luZyBzbyB0aGF0
IEknbSB1bmF3YXJlIG9mKS4NCg0KVGhhdCB3b3VsZCBhbHNvIGxpbWl0IHRoZSBhYmlsaXR5IHRv
IHByZS1jb21wdXRlIERQb1AgcHJvb2ZzIHdpdGggZnV0dXJlIHRpbWVzdGFtcHMgKEkgc2VudCBh
biBlbWFpbCB0byB0aGUgbGlzdCBhYm91dCB0aGlzIG9uIDEgQXByaWwpIGlmIGFuIGF0dGFja2Vy
IGNhbiBwZXJmb3JtIHNvbWUga2luZCBvZiBhdHRhY2sgKFhTUz8pIHRoYXQgdGVtcG9yYXJpbHkg
YWxsb3dzIGV4ZWN1dGluZyBjb2RlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBjbGllbnQgLSBhcyBp
dCB3b3VsZCBwcmV2ZW50IGdlbmVyYXRpbmcgRFBvUCBwcm9vZnMgZm9yIGFjY2VzcyB0b2tlbnMg
dGhhdCBoYXZlIG5vdCB5ZXQgYmVlbiBpc3N1ZWQuDQoNCkRQb1Aga2V5IHJvdGF0aW9uIChlLmcu
ICJnZW5lcmF0aW5nIGFuZCB1c2luZyBhIG5ldyBEUG9QIGtleSBmb3IgZWFjaCBuZXcgYXV0aG9y
aXphdGlvbiBjb2RlIGdyYW50IiBhcyBzdWdnZXN0ZWQgaW4gc2VjdGlvbiAyIG9mIHRoZSBEUG9Q
IGRyYWZ0KSBpcyBhIGdvb2QgaWRlYSBidXQgYXMgSnVzdGluIHNheXMgZGVwZW5kcyBvbiB0aGUg
Y2xpZW50cyBhY3R1YWxseSBkb2luZyBpdCwgd2l0aCBubyByZWFsIGVuZm9yY2VtZW50IG1lY2hh
bmlzbS4NCg0KTWlrZQ0KDQrvu79PbiAxMS8yMy8yMCwgNjo1MiBBTSwgIk9BdXRoIG9uIGJlaGFs
ZiBvZiBKdXN0aW4gUmljaGVyIiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg
anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCg0KICAgIENvcnJlY3QsIGJ1dCB0aGUgY2hvaWNlIG9m
IHVzaW5nIGRpZmZlcmVudCBrZXlzIGlzIGVudGlyZWx5IGluIHRoZSBoYW5kcyBvZiB0aGUgY2xp
ZW50LCBhcyB0aGUgQVMgYWNjZXB0cyB3aGF0ZXZlciBrZXkgdGhlIGNsaWVudCBwcmVzZW50cyBp
biBpdHMgaW5pdGlhbCBEUG9QIHByb29mIHRvIGJpbmQgdG8gdGhlIHRva2VuLiBJZiBpdOKAmXMg
b24gdGhlIGNsaWVudCB0byBwcmV2ZW50IHRoaXMga2luZCBvZiB0aGluZywgd2Ugc2hvdWxkIGF0
IGxlYXN0IG1lbnRpb24gaXQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiBJZiBpdOKA
mXMgc29tZXRoaW5nIHdlIHdhbnQgdG8gcHJldmVudCB3aG9sZXNhbGUsIHdlIHNob3VsZCBleHBh
bmQgdGhlIHNpZ25hdHVyZSBjb3ZlcmFnZSB0byB0aGUgYWNjZXNzIHRva2VuLCBvciBhdCBsZWFz
dCBhIGhhc2ggb2YgdGhlIHRva2VuLg0KDQogICAgIOKAlCBKdXN0aW4NCg0KICAgID4gT24gTm92
IDIwLCAyMDIwLCBhdCA5OjMwIFBNLCBOaWtvcyBGb3Rpb3UgPGZvdGlvdUBhdWViLmdyPiB3cm90
ZToNCiAgICA+IA0KICAgID4gSGksDQogICAgPiBUaGUgdG9rZW4gaXMgZ3JhbnRlZCB0byBhIGNs
aWVudCBiYXNlZCBvbiB0aGUgYXV0aG9yaXphdGlvbiBncmFudCBhbmQgbm90IHRoZSBjbGllbnQn
cyBrZXkuIFRoZXJlZm9yZSwgYSBjbGllbnQgbWF5IHVzZSBhIGRpZmZlcmVudCBrZXkgcGVyIHRv
a2VuLiBBdCBsZWFzdCB0aGlzIGlzIGFuIGFwcHJvYWNoIHdlIGFyZSBmb2xsb3dpbmcuIA0KICAg
ID4gDQogICAgPiBCZXN0LA0KICAgID4gTmlrb3MNCiAgICA+IA0KICAgID4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn
PiBPbiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KICAgID4gU2VudDogRnJpZGF5LCBOb3ZlbWJl
ciAyMCwgMjAyMCA5OjI2IFBNDQogICAgPiBUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KICAg
ID4gU3ViamVjdDogW09BVVRILVdHXSBUb2tlbiBzdWJzdGl0dXRpb24gaW4gRFBvUA0KICAgID4g
DQogICAgPiBXaGlsZSB3b3JraW5nIG9uIGFuIGltcGxlbWVudGF0aW9uIG9mIERQb1AgcmVjZW50
bHksIEkgcmVhbGl6ZWQgdGhhdCB0aGUgdmFsdWUgb2YgdGhlIGFjY2VzcyB0b2tlbiBpdHNlbGYg
aXMgbm90IGNvdmVyZWQgYnkgdGhlIERQb1Agc2lnbmF0dXJlIGF0IGFsbC4gV2hhdCBJ4oCZbSB3
b25kZXJpbmcgaXMgd2hldGhlciBvciBub3QgdGhpcyBjb25zdGl0dXRlcyBhbiBhdHRhY2sgc3Vy
ZmFjZSB0aGF0IHdlIGNhcmUgYWJvdXQgaGVyZS4gSGVyZeKAmXMgaG93IGl0IHdvcmtzOg0KICAg
ID4gDQogICAgPiANCiAgICA+IExldOKAmXMgc2F5IHRoYXQgYSBjbGllbnQgY3JlYXRlcyBhIERQ
b1Aga2V5IGFuZCB1c2VzIHRoYXQga2V5IHRvIHJlcXVlc3QgdHdvIHRva2VucywgVDEgYW5kIFQy
LCBmb3IgZGlmZmVyZW50IHVzZXJzLCBBbGljZSBhbmQgQm9iLCByZXNwZWN0aXZlbHkuIEFsaWNl
IGlzIG1hbGljaW91cyBhbmQgd2FudHMgdG8gZ2V0IEJvYuKAmXMgc3R1ZmYuIEFsaWNlIG1hbmFn
ZXMgdG8gZ2V0IGEgaG9sZCBvZiBCb2LigJlzIHRva2VuIHZhbHVlLCBUMiwgdGhyb3VnaCBzb21l
IG1lYW5zLiBOb3JtYWxseSBEUG9QIHdvdWxkbuKAmXQgbGV0IEFsaWNlIGNyZWF0ZSBhIG5ldyBy
ZXF1ZXN0IHVzaW5nIFQyIHNpbmNlIEFsaWNlIGRvZXNu4oCZdCBoYXZlIHRoZSBjbGllbnTigJlz
IGtleS4gSG93ZXZlciwgaWYgQWxpY2UgZ2V0cyB0aGUgY2xpZW50IHRvIGNyZWF0ZSBhIHJlcXVl
c3QgZm9yIGhlciB1c2luZyBUMSwgc2hlIGNhbiBjb3B5IHRoZSBzaWduYXR1cmUgZnJvbSB0aGF0
IHJlcXVlc3Qgb250byBhIG5ldyByZXF1ZXN0IHVzaW5nIFQyLiBTaW5jZSB0aGUgc2lnbmF0dXJl
IGRvZXNu4oCZdCBjb3ZlciB0aGUgdG9rZW4gdmFsdWUgYW5kIHRoZSBrZXkgaXMgdGhlIHNhbWUs
IHRoZSBSUyBzaG91bGQgYWNjZXB0IGJvdGggcmVxdWVzdHMsIHJpZ2h0Pw0KICAgID4gDQogICAg
PiBBbiBpbXBvcnRhbnQgYXNwZWN0IGlzIHRoYXQgdGhlIHBhcnRzIG5lZWRlZCB0byBtYWtlIHRo
aXMgYXR0YWNrIHdvcmsgYXJlIGEgbGl0dGxlIHdlaXJkOiB5b3XigJlkIG5lZWQgYWNjZXNzIHRv
IGEgdmFsaWQgc2lnbmVkIHJlcXVlc3QgZnJvbSB0aGUgY2xpZW50IHdpdGggVDEgYXMgd2VsbCBh
cyBhY2Nlc3MgdG8gYSB2YWxpZCBUMiBhdHRhY2hlZCB0byB0aGUgc2FtZSBrZXkgaW4gb3JkZXIg
dG8gbWFrZSB0aGlzIHN1YnN0aXR1dGlvbi4gSG93ZXZlciwgdGhpcyBpcyBlZmZlY3RpdmVseSB0
aGUgc2FtZSBhdHRhY2sgYXJlYSB0aGF0IGJlYXJlciB0b2tlbnMgaGF2ZSBpbiBhIGxvdCBvZiB3
YXlzLCBzaW5jZSBpdCBkb2VzbuKAmXQgcmVxdWlyZSB0aGUgYXR0YWNrZXIgZ2FpbmluZyBhY2Nl
c3MgdG8gdGhlIHNpbmdpbmcga2V5IHRvIGdlbmVyYXRlIG9yIG1vZGlmeSBhIHNpZ25hdHVyZSwg
bm9yIGRvZXMgaXQgcmVxdWlyZSB0aGUgYXR0YWNrZXIgdG8gZ2VuZXJhdGUgb3IgbW9kaWZ5IGFu
IGFjY2VzcyB0b2tlbiAobWVyZWx5IG9idGFpbiBvbmUpLg0KICAgID4gDQogICAgPiANCiAgICA+
IEnigJlkIGxpa2UgdG8gdW5kZXJzdGFuZCBpZiB0aGlzIGlzIGFuIGFjdHVhbCBhdHRhY2sgYWdh
aW5zdCBEUG9QLiBJZiBpdCBpc27igJl0LCBob3cgaXMgaXQgY291bnRlcmVkIGJ5IERQb1AgdG9k
YXk/IElmIGl0IGlzLCBkbyB3ZSBkaXNjdXNzIGluIHRoZSBEUG9QIGRyYWZ0PyBJIGRpZG7igJl0
IHNlZSBhIG1lbnRpb24gb2YgaXQgdGhlcmUuIElmIGl04oCZcyBub3QsIHNob3VsZCB3ZSBkaXNj
dXNzIGl0IHRoZXJlPw0KICAgID4gDQogICAgPiANCiAgICA+IFRoZSBvbGQgT0F1dGggUG9QIGRy
YWZ0IG1pdGlnYXRlcyB0aGlzIGF0dGFjayBieSBwdXR0aW5nIHRoZSBhY2Nlc3MgdG9rZW4gaXRz
ZWxmIGluc2lkZSB0aGUgc2lnbmF0dXJlIGJvZHkgaW5zdGVhZCBvZiBhIHNlY29uZCBoZWFkZXIu
IEFub3RoZXIgb3B0aW9uIHdvdWxkIGJlIHRvIGluY2x1ZGUgYSBoYXNoIG9mIHRoZSB0b2tlbiB2
YWx1ZSAoc3VjaCBhcyBPSURD4oCZcyDigJxhdF9oYXNo4oCdIG1ldGhvZCB1c2VkIGluIElEIFRv
a2VucykgaW4gdGhlIERQb1AgcGF5bG9hZC4gV2l0aCBlaXRoZXIgb2YgdGhlc2UgYXBwcm9hY2hl
cywgQWxpY2UgaGF2aW5nIGFjY2VzcyB0byBUMSwgVDIsIGFuZCBhIHNpZ25lZCBtZXNzYWdlIGZv
ciBUMSBkb2VzIG5vdCBhbGxvdyBoZXIgdG8gdXNlIFQyIGVmZmVjdGl2ZWx5Lg0KICAgID4gDQog
ICAgPiDigJQgSnVzdGluDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KICAgID4gT0F1dGggbWFpbGluZyBsaXN0DQogICAgPiBPQXV0aEBpZXRm
Lm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K
DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg
ICBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICBPQXV0aEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K


From nobody Mon Nov 23 08:47:07 2020
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B48893A0A73; Mon, 23 Nov 2020 08:47:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160615002564.5031.4169453764480011254@ietfa.amsl.com>
Date: Mon, 23 Nov 2020 08:47:05 -0800
Archived-At: 
Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-12-07
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, 23 Nov 2020 16:47:06 -0000

The Web Authorization Protocol (oauth) WG will hold
a virtual interim meeting on 2020-12-07 from 12:00 to 13:00 America/Toronto (17:00 to 18:00 UTC).

Agenda:
This meeting is to discuss the OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response document:
https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01

Regards,
 Rifaat & Hannes

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=mb02e9742d3d655d8686ff7ae6f850c72


From nobody Mon Nov 23 08:52:50 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0BC3A0AAF for ; Mon, 23 Nov 2020 08:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHiUxZFYBh6R for ; Mon, 23 Nov 2020 08:52:48 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55D63A0AA7 for ; Mon, 23 Nov 2020 08:52:47 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id f18so775361ljg.9 for ; Mon, 23 Nov 2020 08:52:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=U6QOcFztd5G+7lzZ9GR7J0TB5aeg4ICj+tMERXCFHeY=; b=gDmx8vJ250KGsxFwDLAjYs1wUgiek46+YyO+O5IkO8JilAGRml1LD9lI0UASVepVKA q8HcjdYlyFqlVayen8+XZx0BWdlVoZBbyNpdvSPtp5IbYdTy5i9s1h6BlfrQVJVNlRwF uIksIoBv2M9+Xz6Iq0kMKmmg6cPb8kVhIJSOVOZjtza89sXBDZ55EoWmZv/D9HvZKpYj 81x5woBwOzRAWviwYDq4kdB93b7wgIhB+nk9THRGVPp1kDFdEDL8VS4mF5MMrImIs9Ah d8bvu4YbBrt7fs4JA+f4qTmEi25zEDMrqJuWBSqKjzoBqFw/AyS2FLDLe3nM4KVonOzx /aRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=U6QOcFztd5G+7lzZ9GR7J0TB5aeg4ICj+tMERXCFHeY=; b=jH6N89+CQbyir3H68SDoH4HItGemhkDfdL6rCJkoOkG9NlGRZi7F8CBGh/I6GqpH4W 5gvjR8FdIW9wG0Qn3d9fAjelZHp5QA2940Y/SGZ/72XGtOERJ6Ucs7Xm8AzqAIvrDrOg ZGWCBSq5S9I7d2u+uXjnRoTWKfWKRaCJpoq3ylmAISEXo2AcX8U3KM9w2iijqmpIPIn2 BEAm2Ygqv+olzJvGrt6hNBQ17QgktjYLZWCDKnr9YQVGwbj2zyL3jjnJu4zt611oMlr7 2DcweLgchtpOS4H52DJy/mPT/kmDm6iUjPdJ089MQvIhwxYDo9YFnmbQ7uhEW/icGjNr Szsg==
X-Gm-Message-State: AOAM531cJx8guChSOrmgM7sE540EGdScnksy7XL+LF9KO709mWPLEwXt ka5Fihz1yi4/npycY7FGVQPPpyGWfD+q7dAeA3lpkQij
X-Google-Smtp-Source: ABdhPJwC9JOCAFmusuquqos9yAxZXQua/I+zwBUuQjwmFfKYDeqjZlmw780xUWhxl2BgfWgLS7MbdLLCjDXK+6kQaNo=
X-Received: by 2002:a05:651c:545:: with SMTP id q5mr126749ljp.124.1606150364864;  Mon, 23 Nov 2020 08:52:44 -0800 (PST)
MIME-Version: 1.0
References: <1365969095.9443331606149594974.JavaMail.nobody@rva2rmd101.webex.com>
In-Reply-To: <1365969095.9443331606149594974.JavaMail.nobody@rva2rmd101.webex.com>
From: Rifaat Shekh-Yusef 
Date: Mon, 23 Nov 2020 11:52:33 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/mixed; boundary="000000000000f4448905b4c9055c"
Archived-At: 
Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Interim - AS Issuer Identifier in Authorization 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: Mon, 23 Nov 2020 16:52:50 -0000

--000000000000f4448905b4c9055c
Content-Type: multipart/alternative; boundary="000000000000f4448705b4c9055a"

--000000000000f4448705b4c9055a
Content-Type: text/plain; charset="UTF-8"

---------- Forwarded message ---------
From: Web Authorization Protocol Working Group 
Date: Mon, Nov 23, 2020 at 11:39 AM
Subject: (Forward to others) Webex meeting invitation: OAuth WG Interim -
AS Issuer Identifier in Authorization Response
To: 



You can forward this invitation to others.
Web Authorization Protocol Working Group invites you to join this Webex
meeting.

Meeting number (access code): 178 473 9389
Meeting password: d3tYccTfm77

Monday, December 7, 2020
12:00 pm  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr

Join meeting


*Tap to join from a mobile device (attendees only)*
+1-650-479-3208,,1784739389## <%2B1-650-479-3208,,*01*1784739389%23%23*01*>
Call-in toll number (US/Canada)

*Join by phone*
1-650-479-3208 Call-in toll number (US/Canada)
Global call-in numbers


*Join from a video system or application*
Dial 1784739389@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

*Join using Microsoft Lync or Microsoft Skype for Business*
Dial 1784739389.ietf@lync.webex.com


Need help? Go to http://help.webex.com

--000000000000f4448705b4c9055a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro=
up <m=
essenger@webex.com>
Date: Mon, Nov 23, 2020 at 11:39 AMSubject: (Forward to others) Webex meeting invitation: OAuth WG Interim - =
AS Issuer Identifier in Authorization Response
To:  <oauth-chairs@ietf.org>






	
=C2=A0

	

		
		=09


You can forward this invitation to others. 




       

           
                Web Authorization Protocol Working Group invites you to joi=
n this Webex meeting.
                	           
      






=C2=
=A0


    

        

            
                Meeting number (access code): 178 473 9389
            
        

    

    

        

            Meeting password: d3tYccTfm77
        

    


=C2=
=A0


    

        

            Monday, December 7, 2020
            
        

        

            12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05:00) East=
ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
            
        

    


 

   =20

			
=C2=A0

			
Join meeting

			
=
=C2=A0



	
Tap to join from a mobile device =
(attendees only)
+1-650-4=
79-3208,,1784739389## Call-in toll number (US/Canada)
=C2=A0
<=
tr style=3D"margin:0px">=

Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
Global call-in numbers
=C2=A0

	
Join from a video system or appli=
cation
Dial 1784739389@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu=
mber.
=C2=A0

    
Join using Microsoft Lync or Microsoft Skype for Business
Dial 1784739389.ietf@lync.webex.com


	
=C2=
=A0

=09

			

                
=C2=A0

				

					Need help? Go to http://help.webe=
x.com
					
				

                
=C2=A0

			

				
	






--000000000000f4448705b4c9055a
Content-Type: text/calendar; charset="UTF-8"; method=REQUEST
Content-Transfer-Encoding: quoted-printable

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20201123T163954Z
ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI=
PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org
ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai=
rs@ietf.org
DTSTART;TZID=3DAmerica/New_York:20201207T120000
DTEND;TZID=3DAmerica/New_York:20201207T130000
LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dmb02e9742d3d655d8686ff7ae=
6f850c72
TRANSP:OPAQUE
SEQUENCE:1606149594
UID:a356a2ef-086f-4e07-b634-f0e536f06b4b
DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M=
TID=3Dmb02e9742d3d655d8686ff7ae6f850c72\nMeeting number (access code): 178 =
473 9389\n\nMeeting password: d3tYccTfm77\n\n\n\nTAP TO JOIN FROM A MOBILE =
DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1784739389## tel:%2B1-650-479-320=
8,,*01*1784739389%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PH=
ONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbe=
rs\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dmb27f3910196e796554=
d5a75d3ceede42\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:17847=
39389@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting=
 number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDi=
al sip:1784739389.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nh=
ttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIMPORTANT NOTI=
CE: Please note that this Webex service allows audio and other information =
sent during the session to be recorded, which may be discoverable in a lega=
l matter. By joining this session, you automatically consent to such record=
ings. If you do not consent to being recorded, discuss your concerns with t=
he host or do not join the session.\n
X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n	\n	\n		\n	\n
 
\n			\n\n\n\n\n\n	=
		\n				\n					\n				\n				\n					\n				\n			
\n						When it's time, join the Webex meeting here.\n					\n				
 
\n						Meeting number (access code): 178 473 9389\n		=
			
\n			
Meeting password:d3tYccTfm77
\n=
\n        \n        	\n			\n				\n			\n		
 
\n					\n						\n=
							\n					
Join meeting<=
/td>\n						
\n				
\n\n \n 
 
\n\n  
=
Tap to join from a mobile device (attendees only)   
+1-650-479-3208,,178=
4739389## Call-in toll number (US/Canada)  

J=
oin by phone   
1-650-479-3208 Call-in toll number (US/Canada)   
Global call-in numbe=
rs  


\n\n
 
\n\nJoin from a v=
ideo system or application
Dial 1784739389@ietf.webex.com  
You can also=
 dial 173.243.2.68 and enter your meeting number.   
=
  
\n\n
Join using Microsoft Lync or Microsoft Skype for Busine=
ss
Dial 1784739389.ietf@lync.webex.com
\n\n	
 
\n=
	\n\n			\n     =
           \n				\n					=
\n				\n                \n			
 
Need help? Go to http://help.webex.com\n	=
				
 =

\n		
\n
SUMMARY:OAuth WG Interim - AS Issuer Identifier in Authorization Response
PRIORITY:5
CLASS:PUBLIC
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR

--000000000000f4448705b4c9055a--

--000000000000f4448905b4c9055c
Content-Type: application/ics; name="Webex_Meeting.ics"
Content-Disposition: attachment; filename="Webex_Meeting.ics"
Content-Transfer-Encoding: base64
Content-ID: <175f6054c65c1ce7aee1>
X-Attachment-Id: 175f6054c65c1ce7aee1

QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r
IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ
TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u
ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l
d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w
NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS
TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP
RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5
NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO
RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAxMTIz
VDE2Mzk1NFoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n
IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly
c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr
aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l
cmljYS9OZXdfWW9yazoyMDIwMTIwN1QxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y
azoyMDIwMTIwN1QxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q
LnBocD9NVElEPW1iMDJlOTc0MmQzZDY1NWQ4Njg2ZmY3YWU2Zjg1MGM3Mg0KVFJBTlNQOk9QQVFV
RQ0KU0VRVUVOQ0U6MTYwNjE0OTU5NA0KVUlEOmEzNTZhMmVmLTA4NmYtNGUwNy1iNjM0LWYwZTUz
NmYwNmI0Yg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v
aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1iMDJlOTc0MmQzZDY1NWQ4Njg2ZmY3YWU2
Zjg1MGM3MlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMTc4IDQ3MyA5Mzg5XG5cbk1l
ZXRpbmcgcGFzc3dvcmQ6IGQzdFljY1RmbTc3XG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9C
SUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDE3ODQ3MzkzODkj
IyB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoxNzg0NzM5Mzg5JTIzJTIzKjAxKiBDYWxsLWlu
IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMy
MDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1pbiBudW1i
ZXJzXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW1i
MjdmMzkxMDE5NmU3OTY1NTRkNWE3NWQzY2VlZGU0MlxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZ
U1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6MTc4NDczOTM4OUBpZXRmLndlYmV4LmNvbVxu
WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVt
YmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv
ciBCdXNpbmVzc1xuRGlhbCBzaXA6MTc4NDczOTM4OS5pZXRmQGx5bmMud2ViZXguY29tXG5cblxu
XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAu
Y2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxl
YXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp
bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2gg
bWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNl
c3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5
b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJu
cyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVND
O0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9y
ZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNw
YWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9u
dC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6
IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7
XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRo
OiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1l
ZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJ
Zm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAh
aW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJ
d2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1c
bgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFp
bXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5
bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWdu
PSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5c
bgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu
OiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4
OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIg
YWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2Vu
dGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs
ZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8
Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1l
LCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwv
dHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0
OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U
IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFj
Y2VzcyBjb2RlKTogMTc4IDQ3MyA5Mzg5PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J
CQk8L3RhYmxlPlxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2
NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBT
SVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5kM3RZY2NUZm03NzwvRk9OVD48
L3RkPjwvdHI+PC90YWJsZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9
ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48
L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4J
CQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5
bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNB
OTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdp
ZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi
ZXguY29tL2lldGYvai5waHA/TVRJRD1tYjAyZTk3NDJkM2Q2NTVkODY4NmZmN2FlNmY4NTBjNzIi
IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v
bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4J
CQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0i
I0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9
IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxC
Uj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2
NjYiIEZBQ0U9ImFyaWFsIj5UYXAgdG8gam9pbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5k
ZWVzIG9ubHkpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2
IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTc4NDcz
OTM4OSUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5v
bmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7
Jz4rMS02NTAtNDc5LTMyMDgsLDE3ODQ3MzkzODkjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAo
VVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB
TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBo
b25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF
PSJhcmlhbCI+MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwv
Rk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp
YWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw
P01USUQ9bWIyN2YzOTEwMTk2ZTc5NjU1NGQ1YTc1ZDNjZWVkZTQyIiBzdHlsZT0idGV4dC1kZWNv
cmF0aW9uOm5vbmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4g
bnVtYmVyczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0eWxl
PSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+
PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i
MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0g
b3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG
QUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjE3ODQ3MzkzODlAaWV0Zi53ZWJl
eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+MTc4NDcz
OTM4OUBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD
T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42
OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U
PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0
cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6
ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1
c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv
dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7
IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi
PkRpYWwgPGEgaHJlZj0iIHNpcDoxNzg0NzM5Mzg5LmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5
bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3ODQ3MzkzODkuaWV0ZkBs
eW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCTx0YWJsZT48dHIgc3R5bGU9
ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv
dHI+PC90YWJsZT5cbglcblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWduPSJs
ZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcy
cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9ImhlaWdo
dDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6IDE0
cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRwOi8v
aGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9u
ZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAg
ICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry
PlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpPQXV0
aCBXRyBJbnRlcmltIC0gQVMgSXNzdWVyIElkZW50aWZpZXIgaW4gQXV0aG9yaXphdGlvbiBSZXNw
b25zZQ0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBU
NU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5E
OlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K
--000000000000f4448905b4c9055c--


From nobody Mon Nov 23 10:04:19 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C753A0C73 for ; Mon, 23 Nov 2020 10:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsnPuALU3iTX for ; Mon, 23 Nov 2020 10:04:00 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883693A0C52 for ; Mon, 23 Nov 2020 10:04:00 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id r18so4240874ljc.2 for ; Mon, 23 Nov 2020 10:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P+xA0P8Hw72AvrsnfXnwuwCKvJUg48ZqltdDpcQ2QJ8=; b=Eurxz8aS+geHauIu/hhwbfREvpXoJ4Vx22C4fakl2cYNDD7uPZ73ksz4xuETSl0IR4 LFnsK+nk1w2RGFNh373EKo6C3AEupqiM1TAr1zKuGGFHw38WZ6XzzMKdzR6z341SfMzM glQcJqxNuoFprh4nlKbiFDv5E4GkJ/C4oncxJTMkYasfVBxX5v4950G+Y20gMDNrt+JH PV2++TNmVJcGaEXurHJkyiiOPWUNp+zlJ01fKbqzKZ3NaR040BVuk2HmCtnDLxaqcsqF Ycvw77nMp22Zyy95UtFeS37k2DP9H+zuIObL1F50zHGdwZF+ZHJwpsNCkew54md1PJRx t75Q==
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=P+xA0P8Hw72AvrsnfXnwuwCKvJUg48ZqltdDpcQ2QJ8=; b=K3nQBb8206SfvpfQ8fnvVzSNOgMmAvU6barGABu2VgmVk6qb6i6FUOLHA9dmAPqME2 DL9zfwuMWP567HVRx/0RyGgtHkfNU83a/AfjXdgopzxCuguJFx9+grFOVbbvaVrMf4XT /K7eP55ms5vVspwBB5oGF8aelL8jQPk1YNjTPwUgAUtn1c2my9/oasLommKehTZi2uEh 78BeemswvEKinyDnlSjy5HhS281u5r0oidtStfL90nvzUlZJSt0HecLdLDivpD+5mn9p YeDhqS6aJPZYe1X7Jf49efyL4TWPqkIzElj5Lc/EPDHySb671zopJl/Jlk6x/srbbYgu myZQ==
X-Gm-Message-State: AOAM533Jlwy60lWqGMCNQUncdo1Rj8lfKLPU7V46dC6uCW5WgC/Zjh+w nxYti98TpPNBU69wKC85bxFdkhtDdEx4MdJtsGZ8jbtL5JrMq2UJOmV7C5iN+xKFQy7zcqpxRBe iKpJs5PQgJmRlQQ==
X-Google-Smtp-Source: ABdhPJx7tBwfTZVTFH415ulVQOErnP7+SMVie9Xuy5CRfG4t2WRAuqvUJZGR4aqLn+MV0CwKp3UwFKKooKu5+THT7KE=
X-Received: by 2002:a2e:2419:: with SMTP id k25mr234784ljk.422.1606154638512;  Mon, 23 Nov 2020 10:03:58 -0800 (PST)
MIME-Version: 1.0
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
In-Reply-To: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
From: Brian Campbell 
Date: Mon, 23 Nov 2020 11:03:32 -0700
Message-ID: 
To: Justin Richer 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000aef37405b4ca04b8"
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 23 Nov 2020 18:04:10 -0000

--000000000000aef37405b4ca04b8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The extent of the weirdness needed leads me to feel that it's not a threat
that's in scope. To copy the proof signature from a request with T1 onto a
new request using T2, Alice would need access to the first request, which
is made directly from client to RS. That's not possible for a web server
client so the client would need to be running on Alice's machine/device.
Such on device clients aren't typically going to be acting on behalf of
multiple users. Or if they are, will need to do a lot more to securely
segment the user execution environments from each other. Most of which is
outside what can be done at this protocol application level.



On Fri, Nov 20, 2020 at 12:26 PM Justin Richer  wrote:

> While working on an implementation of DPoP recently, I realized that the
> value of the access token itself is not covered by the DPoP signature at
> all. What I=E2=80=99m wondering is whether or not this constitutes an att=
ack
> surface that we care about here. Here=E2=80=99s how it works:
>
>
> Let=E2=80=99s say that a client creates a DPoP key and uses that key to r=
equest
> two tokens, T1 and T2, for different users, Alice and Bob, respectively.
> Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice manages to=
 get a
> hold of Bob=E2=80=99s token value, T2, through some means. Normally DPoP =
wouldn=E2=80=99t
> let Alice create a new request using T2 since Alice doesn=E2=80=99t have =
the
> client=E2=80=99s key. However, if Alice gets the client to create a reque=
st for her
> using T1, she can copy the signature from that request onto a new request
> using T2. Since the signature doesn=E2=80=99t cover the token value and t=
he key is
> the same, the RS should accept both requests, right?
>
> An important aspect is that the parts needed to make this attack work are
> a little weird: you=E2=80=99d need access to a valid signed request from =
the client
> with T1 as well as access to a valid T2 attached to the same key in order
> to make this substitution. However, this is effectively the same attack
> area that bearer tokens have in a lot of ways, since it doesn=E2=80=99t r=
equire the
> attacker gaining access to the singing key to generate or modify a
> signature, nor does it require the attacker to generate or modify an acce=
ss
> token (merely obtain one).
>
>
> I=E2=80=99d like to understand if this is an actual attack against DPoP. =
If it
> isn=E2=80=99t, how is it countered by DPoP today? If it is, do we discuss=
 in the
> DPoP draft? I didn=E2=80=99t see a mention of it there. If it=E2=80=99s n=
ot, should we
> discuss it there?
>
>
> The old OAuth PoP draft mitigates this attack by putting the access token
> itself inside the signature body instead of a second header. Another opti=
on
> would be to include a hash of the token value (such as OIDC=E2=80=99s =E2=
=80=9Cat_hash=E2=80=9D
> method used in ID Tokens) in the DPoP payload. With either of these
> approaches, Alice having access to T1, T2, and a signed message for T1 do=
es
> not allow her to use T2 effectively.
>
>  =E2=80=94 Justin
> _______________________________________________
> 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._

--000000000000aef37405b4ca04b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The extent of the weirdness needed leads me to feel t=
hat it's not a threat that's in scope. To copy the proof signature =
from a request with T1 onto a new request using T2, Alice would need access=
 to the first request, which is made directly from client to RS. That's=
 not possible for a web server client so the client would need to be runnin=
g on Alice's machine/device. Such on device clients aren't typicall=
y going to be acting on behalf of multiple users. Or if they are, will need=
 to do a lot more to securely segment the user execution environments from =
each other. Most of which is outside what can be done at this protocol appl=
ication level.=C2=A0 



On Fri, Nov 20=
, 2020 at 12:26 PM Justin Richer <jricher@mit.edu> wrote:
While working on an implementation of DPoP re=
cently, I realized that the value of the access token itself is not covered=
 by the DPoP signature at all. What I=E2=80=99m wondering is whether or not=
 this constitutes an attack surface that we care about here. Here=E2=80=99s=
 how it works:





Let=E2=80=99s say that a client creates a DPoP key and uses that key to req=
uest two tokens, T1 and T2, for different users, Alice and Bob, respectivel=
y. Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice manages t=
o get a hold of Bob=E2=80=99s token value, T2, through some means. Normally=
 DPoP wouldn=E2=80=99t let Alice create a new request using T2 since Alice =
doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets the c=
lient to create a request for her using T1, she can copy the signature from=
 that request onto a new request using T2. Since the signature doesn=E2=80=
=99t cover the token value and the key is the same, the RS should accept bo=
th requests, right?



An important aspect is that the parts needed to make this attack work are a=
 little weird: you=E2=80=99d need access to a valid signed request from the=
 client with T1 as well as access to a valid T2 attached to the same key in=
 order to make this substitution. However, this is effectively the same att=
ack area that bearer tokens have in a lot of ways, since it doesn=E2=80=99t=
 require the attacker gaining access to the singing key to generate or modi=
fy a signature, nor does it require the attacker to generate or modify an a=
ccess token (merely obtain one).





I=E2=80=99d like to understand if this is an actual attack against DPoP. If=
 it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we discu=
ss in the DPoP draft? I didn=E2=80=99t see a mention of it there. If it=E2=
=80=99s not, should we discuss it there?





The old OAuth PoP draft mitigates this attack by putting the access token i=
tself inside the signature body instead of a second header. Another option =
would be to include a hash of the token value (such as OIDC=E2=80=99s =E2=
=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. With =
either of these approaches, Alice having access to T1, T2, and a signed mes=
sage for T1 does not allow her to use T2 effectively.



=C2=A0=E2=80=94 Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000aef37405b4ca04b8--


From nobody Mon Nov 23 10:50:54 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F8C3A048B for ; Mon, 23 Nov 2020 10:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28H3yzbKVnid for ; Mon, 23 Nov 2020 10:50:50 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399343A0418 for ; Mon, 23 Nov 2020 10:50:50 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id l11so25305938lfg.0 for ; Mon, 23 Nov 2020 10:50:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b1TCMx74n3Lq89NrMnW/wxQl6D/dkWraUyFvcnTqyrI=; b=Ujnv3c+1/xDk2MsiyyJ7hC6IQ0Sc/tT3pP4BC9V/HpAYshyEngJbrLOs6rSFqC5eI2 p3xMPmXzn3ThIYYuPHHy1vqAGvJz9DuKGo4n4bOy+/yOtmnm2FUAnLwZ9LC/56PQO7yy 3iC/Yb+k/Gdg0QOVlfcF0nO1XEydjBPmKqf3kaajAbhOFEE6sXlGG2qxfa5j644lsmGq I05PjJA2BVEvSpAMJlM6aSNnnhNFJ5g2sIqIfHjtHdKoRfqpksb+yv+ag/J8CycmIsqO UnB7E5qbXvtq6IdYwsRmEpxSXNZAtWLLLA3tKme3b+qqgbc8a9JNSf/v2V845jBrjcWH vzZg==
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=b1TCMx74n3Lq89NrMnW/wxQl6D/dkWraUyFvcnTqyrI=; b=fP3jUHuv4x0da3E5GjuDR5EvhQTe4WcJhvmRSUKqr5/r87c89n3Ofvo2QVJdoRWXiP xL/66mC0qP58DOeF900l0rN6/ezgsiKBFCVJWBvEnclqI1c4Rdi5iLq7pubNGJFEda0q iqXYzrTbOGk54hTAlTe+BNuf5Q3NSVnzR0px5ws5p7aSYyEU+OIxrVQ3Ky5pirSeKcwG STYGFGlrqOjUMxIQ+7vAJOq2s+O35pQaLJKbSbZej5GS0GI4CbgEPsSLI/r9kwSv/3X5 15/DsH96LqJEAhgxJSJ+abLz0npBG6aZTZa20kwM3omatfBEwuGShnWnHB8+JLu8i3Ja 9BvQ==
X-Gm-Message-State: AOAM530geMF5a+XbZMK9qLeGfXMSroAFA7hIivZ/vjGeAg6WhCnW4Qsn i9NYfGCd2KMrpiflcFEQrkzha7Bj4Fa5acCajqFGCKhYRG7jTpZoZquYXyCcyBw3/33vRZMSBLC AgKJihYku9MPQYw==
X-Google-Smtp-Source: ABdhPJylU3kyg8hHnCPYqJFtn1Cry0fdQZPwIOTdMLhpPp0vBI/UCTW5JEYATEgWwhvXmKEnwzWSzFsawvtVSTjrFIg=
X-Received: by 2002:a19:c658:: with SMTP id w85mr201083lff.560.1606157448085;  Mon, 23 Nov 2020 10:50:48 -0800 (PST)
MIME-Version: 1.0
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu> <016f01d6bfae$407e6bd0$c17b4370$@aueb.gr> <15245_1606132326_5FBBA25D_15245_296_1_0352818D-4793-44E2-832B-3FD7B7BF7507@mit.edu> <2B99664F-C236-422D-BBA1-BCF99485DBDC@mitre.org>
In-Reply-To: <2B99664F-C236-422D-BBA1-BCF99485DBDC@mitre.org>
From: Brian Campbell 
Date: Mon, 23 Nov 2020 11:50:21 -0700
Message-ID: 
To: Michael A Peck 
Cc: Justin Richer , Nikos Fotiou , oauth 
Content-Type: multipart/alternative; boundary="00000000000025a56a05b4caac59"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXT] Re: Token substitution in DPoP
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, 23 Nov 2020 18:50:53 -0000

--00000000000025a56a05b4caac59
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It's not a huge burden but does add some non-zero complexity to the
protocol as well as size to the proof. And in my mind anyway, doing so
would sort of beg the question as to having some similar treatment for
authz codes and refresh tokens. Which can, of course, also be done. But
adds more complexity. And then there are other grant types to consider
(even not doing anything with them demands some consideration of them). I
question if the benefit is sufficient to account for the cost in added
complexity etc.. But anyway, with all that rambling said, I do plan to have
this as a general item for discussion in the upcoming interim meeting.
Which I hope will be an easier forum to better hash it out.

On Mon, Nov 23, 2020 at 6:03 AM Michael A Peck  wrote:

> I agree with having the DPoP proof cover the access token (unless there's
> some burden on the clients doing so that I'm unaware of).
>
> That would also limit the ability to pre-compute DPoP proofs with future
> timestamps (I sent an email to the list about this on 1 April) if an
> attacker can perform some kind of attack (XSS?) that temporarily allows
> executing code in the context of the client - as it would prevent
> generating DPoP proofs for access tokens that have not yet been issued.
>
> DPoP key rotation (e.g. "generating and using a new DPoP key for each new
> authorization code grant" as suggested in section 2 of the DPoP draft) is=
 a
> good idea but as Justin says depends on the clients actually doing it, wi=
th
> no real enforcement mechanism.
>
> Mike
>
> =EF=BB=BFOn 11/23/20, 6:52 AM, "OAuth on behalf of Justin Richer" <
> oauth-bounces@ietf.org on behalf of jricher@mit.edu> wrote:
>
>     Correct, but the choice of using different keys is entirely in the
> hands of the client, as the AS accepts whatever key the client presents i=
n
> its initial DPoP proof to bind to the token. If it=E2=80=99s on the clien=
t to
> prevent this kind of thing, we should at least mention it in the security
> considerations. If it=E2=80=99s something we want to prevent wholesale, w=
e should
> expand the signature coverage to the access token, or at least a hash of
> the token.
>
>      =E2=80=94 Justin
>
>     > On Nov 20, 2020, at 9:30 PM, Nikos Fotiou  wrote:
>     >
>     > Hi,
>     > The token is granted to a client based on the authorization grant
> and not the client's key. Therefore, a client may use a different key per
> token. At least this is an approach we are following.
>     >
>     > Best,
>     > Nikos
>     >
>     > -----Original Message-----
>     > From: OAuth  On Behalf Of Justin Richer
>     > Sent: Friday, November 20, 2020 9:26 PM
>     > To: oauth 
>     > Subject: [OAUTH-WG] Token substitution in DPoP
>     >
>     > While working on an implementation of DPoP recently, I realized tha=
t
> the value of the access token itself is not covered by the DPoP signature
> at all. What I=E2=80=99m wondering is whether or not this constitutes an =
attack
> surface that we care about here. Here=E2=80=99s how it works:
>     >
>     >
>     > Let=E2=80=99s say that a client creates a DPoP key and uses that ke=
y to
> request two tokens, T1 and T2, for different users, Alice and Bob,
> respectively. Alice is malicious and wants to get Bob=E2=80=99s stuff. Al=
ice
> manages to get a hold of Bob=E2=80=99s token value, T2, through some mean=
s.
> Normally DPoP wouldn=E2=80=99t let Alice create a new request using T2 si=
nce Alice
> doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets the=
 client to create
> a request for her using T1, she can copy the signature from that request
> onto a new request using T2. Since the signature doesn=E2=80=99t cover th=
e token
> value and the key is the same, the RS should accept both requests, right?
>     >
>     > An important aspect is that the parts needed to make this attack
> work are a little weird: you=E2=80=99d need access to a valid signed requ=
est from
> the client with T1 as well as access to a valid T2 attached to the same k=
ey
> in order to make this substitution. However, this is effectively the same
> attack area that bearer tokens have in a lot of ways, since it doesn=E2=
=80=99t
> require the attacker gaining access to the singing key to generate or
> modify a signature, nor does it require the attacker to generate or modif=
y
> an access token (merely obtain one).
>     >
>     >
>     > I=E2=80=99d like to understand if this is an actual attack against =
DPoP. If
> it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we disc=
uss in the
> DPoP draft? I didn=E2=80=99t see a mention of it there. If it=E2=80=99s n=
ot, should we
> discuss it there?
>     >
>     >
>     > The old OAuth PoP draft mitigates this attack by putting the access
> token itself inside the signature body instead of a second header. Anothe=
r
> option would be to include a hash of the token value (such as OIDC=E2=80=
=99s
> =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. =
With either of
> these approaches, Alice having access to T1, T2, and a signed message for
> T1 does not allow her to use T2 effectively.
>     >
>     > =E2=80=94 Justin
>     > _______________________________________________
>     > 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
_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._

--00000000000025a56a05b4caac59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It's not a huge burden but does add some non-zero=
 complexity to the protocol as well as size to the proof. And in my mind an=
yway, doing so would sort of beg the question as to having some similar tre=
atment for authz codes and refresh tokens. Which can, of course, also be do=
ne. But adds more complexity. And then there are other grant types to consi=
der (even not doing anything with them demands some consideration of them).=
 I question if the benefit is sufficient to account for the cost in added c=
omplexity etc.. But anyway, with all that rambling said, I do plan to have =
this as a general item for discussion in the upcoming interim meeting. Whic=
h I hope will be an easier forum to better hash it out.
 
On Mon, N=
ov 23, 2020 at 6:03 AM Michael A Peck <mpeck@mitre.org> wrote:
I agree with having the DPoP proof cover the access token =
(unless there's some burden on the clients doing so that I'm unawar=
e of).



That would also limit the ability to pre-compute DPoP proofs with future ti=
mestamps (I sent an email to the list about this on 1 April) if an attacker=
 can perform some kind of attack (XSS?) that temporarily allows executing c=
ode in the context of the client - as it would prevent generating DPoP proo=
fs for access tokens that have not yet been issued.



DPoP key rotation (e.g. "generating and using a new DPoP key for each =
new authorization code grant" as suggested in section 2 of the DPoP dr=
aft) is a good idea but as Justin says depends on the clients actually doin=
g it, with no real enforcement mechanism.



Mike



=EF=BB=BFOn 11/23/20, 6:52 AM, "OAuth on behalf of Justin Richer"=
 <oauth-boun=
ces@ietf.org on behalf of jricher@mit.edu> wrote:



=C2=A0 =C2=A0 Correct, but the choice of using different keys is entirely i=
n the hands of the client, as the AS accepts whatever key the client presen=
ts in its initial DPoP proof to bind to the token. If it=E2=80=99s on the c=
lient to prevent this kind of thing, we should at least mention it in the s=
ecurity considerations. If it=E2=80=99s something we want to prevent wholes=
ale, we should expand the signature coverage to the access token, or at lea=
st a hash of the token.



=C2=A0 =C2=A0 =C2=A0=E2=80=94 Justin



=C2=A0 =C2=A0 > On Nov 20, 2020, at 9:30 PM, Nikos Fotiou <fotiou@aueb.gr> wrote:

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Hi,

=C2=A0 =C2=A0 > The token is granted to a client based on the authorizat=
ion grant and not the client's key. Therefore, a client may use a diffe=
rent key per token. At least this is an approach we are following. 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Best,

=C2=A0 =C2=A0 > Nikos

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > -----Original Message-----

=C2=A0 =C2=A0 > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Justin Rich=
er

=C2=A0 =C2=A0 > Sent: Friday, November 20, 2020 9:26 PM

=C2=A0 =C2=A0 > To: oauth <oauth@ietf.org>

=C2=A0 =C2=A0 > Subject: [OAUTH-WG] Token substitution in DPoP

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > While working on an implementation of DPoP recently, I r=
ealized that the value of the access token itself is not covered by the DPo=
P signature at all. What I=E2=80=99m wondering is whether or not this const=
itutes an attack surface that we care about here. Here=E2=80=99s how it wor=
ks:

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Let=E2=80=99s say that a client creates a DPoP key and u=
ses that key to request two tokens, T1 and T2, for different users, Alice a=
nd Bob, respectively. Alice is malicious and wants to get Bob=E2=80=99s stu=
ff. Alice manages to get a hold of Bob=E2=80=99s token value, T2, through s=
ome means. Normally DPoP wouldn=E2=80=99t let Alice create a new request us=
ing T2 since Alice doesn=E2=80=99t have the client=E2=80=99s key. However, =
if Alice gets the client to create a request for her using T1, she can copy=
 the signature from that request onto a new request using T2. Since the sig=
nature doesn=E2=80=99t cover the token value and the key is the same, the R=
S should accept both requests, right?

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > An important aspect is that the parts needed to make thi=
s attack work are a little weird: you=E2=80=99d need access to a valid sign=
ed request from the client with T1 as well as access to a valid T2 attached=
 to the same key in order to make this substitution. However, this is effec=
tively the same attack area that bearer tokens have in a lot of ways, since=
 it doesn=E2=80=99t require the attacker gaining access to the singing key =
to generate or modify a signature, nor does it require the attacker to gene=
rate or modify an access token (merely obtain one).

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > I=E2=80=99d like to understand if this is an actual atta=
ck against DPoP. If it isn=E2=80=99t, how is it countered by DPoP today? If=
 it is, do we discuss in the DPoP draft? I didn=E2=80=99t see a mention of =
it there. If it=E2=80=99s not, should we discuss it there?

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > The old OAuth PoP draft mitigates this attack by putting=
 the access token itself inside the signature body instead of a second head=
er. Another option would be to include a hash of the token value (such as O=
IDC=E2=80=99s =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DP=
oP payload. With either of these approaches, Alice having access to T1, T2,=
 and a signed message for T1 does not allow her to use T2 effectively.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > =E2=80=94 Justin

=C2=A0 =C2=A0 > _______________________________________________

=C2=A0 =C2=A0 > OAuth mailing list

=C2=A0 =C2=A0 > OAut=
h@ietf.org

=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/=
oauth



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 OAuth mailing list

=C2=A0 =C2=A0 OAuth@iet=
f.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oau=
th



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000025a56a05b4caac59--


From nobody Tue Nov 24 01:38:45 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A503A1994 for ; Tue, 24 Nov 2020 01:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level: 
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l6AO5rd6wSt for ; Tue, 24 Nov 2020 01:38:42 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F3D3A125F for ; Tue, 24 Nov 2020 01:38:41 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 238871686C for ; Tue, 24 Nov 2020 09:38:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1606210718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p81AZza8k32y0PooYZSs2068Qu0F0TGY8Ow7r6e1u5k=; b=nvXvb8+luqw3ag2MPyTWN+m9HBOJhBLTEiX+CYbHuClnfwxOFidVEO8omiiKXFftK1FYQX WizT/LkfqOLcclxsHFFOru5Kgopc8MNoHN92r6lNUQCUjq+EZEc/pIbGKFmbTVqzoso9Vc 9DC7/65/OGBucv1QhxoczWuPFYo4+LQ=
To: oauth@ietf.org
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
From: Daniel Fett 
Message-ID: 
Date: Tue, 24 Nov 2020 10:38:37 +0100
MIME-Version: 1.0
In-Reply-To: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
Content-Type: multipart/alternative; boundary="------------801F6AA7668F40588572128A"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1606210718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p81AZza8k32y0PooYZSs2068Qu0F0TGY8Ow7r6e1u5k=; b=Le2qKPFkzYo8/HU5pl8Fv+zxux9WmsjOeOokjIuHsMJIkN+ICcJfAsgQQxIiUoxKt6wKzl 4E2FNC1tZDyctM58iCP2icd8MuFUhJ0hb7uOMDGiJxeUusW6F3cV7E5hxjPz1pHTKv5flO G9uGWUZ+TN7G1ABGbVyNTC0Ez6mh7j0=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1606210718; a=rsa-sha256; cv=none; b=mvN/nvawJda9CHUXFX4H8VuRgsB/HIiESXpIBp20wgXW953dEPgdkzunVP9OqqxKGzI93R rABnmk8vKM00+Y6jOF1YYaVKrOC1VnI+ixzaCCj04fB/cgIfbINNrEewhgq+AZWtyhq5cQ UcRGiv6LsEboNIQQsPEaZzZaabX00/o=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 24 Nov 2020 09:38:44 -0000

This is a multi-part message in MIME format.
--------------801F6AA7668F40588572128A
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Thanks Justin for bringing this to our attention.

Right now, I don't think that this is a big problem and I wasn't able to
come up with a way to improve the attack. I hope that it doesn't come
back to haunt us when somebody does a more in-depth analysis...

That said, the lack of binding to the access token makes it easier to
precompute proofs if somebody has a limited code execution opportunity
in the client. We have this paragraph in the spec:

   Malicious XSS code executed in the context of the browser-based
   client application is also in a position to create DPoP proofs with
   timestamp values in the future and exfiltrate them in conjunction
   with a token.  These stolen artifacts can later be used together
   independent of the client application to access protected resources.
   The impact of such precomputed DPoP proofs can be limited somewhat by
   a browser-based client generating and using a new DPoP key for each
   new authorization code grant.

The recommendation could be to use a fresh key pair for each token request.

-Daniel


Am 20.11.20 um 20:26 schrieb Justin Richer:
> While working on an implementation of DPoP recently, I realized that the value of the access token itself is not covered by the DPoP signature at all. What I’m wondering is whether or not this constitutes an attack surface that we care about here. Here’s how it works:
>
>
> Let’s say that a client creates a DPoP key and uses that key to request two tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s token value, T2, through some means. Normally DPoP wouldn’t let Alice create a new request using T2 since Alice doesn’t have the client’s key. However, if Alice gets the client to create a request for her using T1, she can copy the signature from that request onto a new request using T2. Since the signature doesn’t cover the token value and the key is the same, the RS should accept both requests, right?
>
> An important aspect is that the parts needed to make this attack work are a little weird: you’d need access to a valid signed request from the client with T1 as well as access to a valid T2 attached to the same key in order to make this substitution. However, this is effectively the same attack area that bearer tokens have in a lot of ways, since it doesn’t require the attacker gaining access to the singing key to generate or modify a signature, nor does it require the attacker to generate or modify an access token (merely obtain one).
>
>
> I’d like to understand if this is an actual attack against DPoP. If it isn’t, how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? I didn’t see a mention of it there. If it’s not, should we discuss it there?
>
>
> The old OAuth PoP draft mitigates this attack by putting the access token itself inside the signature body instead of a second header. Another option would be to include a hash of the token value (such as OIDC’s “at_hash” method used in ID Tokens) in the DPoP payload. With either of these approaches, Alice having access to T1, T2, and a signed message for T1 does not allow her to use T2 effectively.
>
>  — Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de


--------------801F6AA7668F40588572128A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Justin for bringing this to our
      attention.

    


    

    
Right now, I don't think that this is a
      big problem and I wasn't able to come up with a way to improve the
      attack. I hope that it doesn't come back to haunt us when somebody
      does a more in-depth analysis...

    


    

    
That said, the lack of binding to the
      access token makes it easier to precompute proofs if somebody has
      a limited code execution opportunity in the client. We have this
      paragraph in the spec:

    


    

    
   Malicious XSS code executed in the
      context of the browser-based

         client application is also in a position to create DPoP proofs
      with

         timestamp values in the future and exfiltrate them in
      conjunction

         with a token.  These stolen artifacts can later be used
      together

         independent of the client application to access protected
      resources.

         The impact of such precomputed DPoP proofs can be limited
      somewhat by

         a browser-based client generating and using a new DPoP key for
      each

         new authorization code grant.

    


    

    
The recommendation could be to use a
      fresh key pair for each token request.

    


    

    
-Daniel

    


    

    


    

    
Am 20.11.20 um 20:26 schrieb Justin
      Richer:

    

    

      
While working on an implementation of DPoP recently, I realized that the value of the access token itself is not covered by the DPoP signature at all. What I’m wondering is whether or not this constitutes an attack surface that we care about here. Here’s how it works:


Let’s say that a client creates a DPoP key and uses that key to request two tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s token value, T2, through some means. Normally DPoP wouldn’t let Alice create a new request using T2 since Alice doesn’t have the client’s key. However, if Alice gets the client to create a request for her using T1, she can copy the signature from that request onto a new request using T2. Since the signature doesn’t cover the token value and the key is the same, the RS should accept both requests, right?

An important aspect is that the parts needed to make this attack work are a little weird: you’d need access to a valid signed request from the client with T1 as well as access to a valid T2 attached to the same key in order to make this substitution. However, this is effectively the same attack area that bearer tokens have in a lot of ways, since it doesn’t require the attacker gaining access to the singing key to generate or modify a signature, nor does it require the attacker to generate or modify an access token (merely obtain one).


I’d like to understand if this is an actual attack against DPoP. If it isn’t, how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? I didn’t see a mention of it there. If it’s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access token itself inside the signature body instead of a second header. Another option would be to include a hash of the token value (such as OIDC’s “at_hash” method used in ID Tokens) in the DPoP payload. With either of these approaches, Alice having access to T1, T2, and a signed message for T1 does not allow her to use T2 effectively.

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


    

    


    

    
-- 
https://danielfett.de

  


--------------801F6AA7668F40588572128A--


From nobody Tue Nov 24 03:03:01 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1323B3A03FA for ; Tue, 24 Nov 2020 03:03:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4umliGTAisT for ; Tue, 24 Nov 2020 03:02:57 -0800 (PST)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC92C3A03F8 for ; Tue, 24 Nov 2020 03:02:55 -0800 (PST)
Received: by mail-ej1-x634.google.com with SMTP id f23so27880923ejk.2 for ; Tue, 24 Nov 2020 03:02:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=7dainsuyIqHPus+ChICt2sff+y5SPpu7mrvhWu7xODU=; b=BfCSNCgiXXSjpd9dUcPs1hQ7zlM4rVdOaJkeX+Q+tpV1cvxj96Q/AZu+tznWQflct3 NoB7Tny7RQLJwroFtFASnyrVyPCMqc8kVbKK/OHX9AWstSPON68PSFNKfMWmfm7uPXcu Ht+jr7Aw5PT59P8EJr8MTlZvBPSyD9Xo5/UyM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=7dainsuyIqHPus+ChICt2sff+y5SPpu7mrvhWu7xODU=; b=lgcEca78CJuG8qY2UIaJwpCfU830X/0WPw4g9PHPP2ezeYoQ6kxyxXLtfeAknn0fFZ At8x1AR5gr0am6OkXS1Q1jNKSOAkn+oKQg0uxpbhW9WVDtdzgXJGf6PplG8PENTME9sq cULK3o9OnfL3ZVxj9aQkQOwzMzZTlkcwzNWsE8uDlv6FAAo78VpY66GS63B53L3oyRKC MpoYdB1c0qfMszryGCtFZI/NmvTnoy5CbdITsAhzZCZBlDPm7rbq/DBxip8mkMigyAX7 S5Hd+cKmR/DW1odbC5I0ue0iCy7HtidbvFDWs5ePGVXC05OEyv5qyF259NAD7TLs4vnO uTMQ==
X-Gm-Message-State: AOAM531g+8HNnog7KAimpWkuVRqnRRZ0Wzb/9/SxfUjMq6siYXoV5GK5 Z74h5LueKFQBWNVF8mCyWQFqetm26mUdm882DVLqFMwHoLGmw+2hr/913I96l/86T0usjmSaIN9 fI7RHnbuC
X-Google-Smtp-Source: ABdhPJw7eMoewRaDoWMv1MAWJ/iTPyIGIi6WdjEhuGFyZ+dqbviUvw2jWzIQ4y7sc3SCToSAZ9p6Jg==
X-Received: by 2002:a17:906:1db1:: with SMTP id u17mr2693129ejh.359.1606215774366;  Tue, 24 Nov 2020 03:02:54 -0800 (PST)
Received: from [10.0.0.17] ([213.31.218.193]) by smtp.gmail.com with ESMTPSA id t10sm6601530eji.61.2020.11.24.03.02.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 03:02:53 -0800 (PST)
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Tue, 24 Nov 2020 11:02:52 +0000
Message-Id: <22D724F4-BF92-481F-A70C-E82B08D2017F@forgerock.com>
References: 
Cc: oauth@ietf.org
In-Reply-To: 
To: Daniel Fett 
X-Mailer: iPhone Mail (18A8395)
Content-Type: multipart/alternative; boundary=Apple-Mail-4FA33979-B5F8-4764-B602-BD44E3FF5ADF
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 24 Nov 2020 11:03:00 -0000

--Apple-Mail-4FA33979-B5F8-4764-B602-BD44E3FF5ADF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with Daniel that I=E2=80=99d be a bit wary of assuming that this co=
uld never be exploited. For example, a server-side web app that signs DPoP =
proofs on behalf of client-side Javascript (to keep the key safe on the ser=
ver) and reuses the key for different users could be a risk.=20

IMO this is another symptom of the general issue of using signatures for au=
thentication - they are too strong for the job. The fact that a signature i=
s equally valid to all parties and at all times means you have to be very c=
areful to include enough context in the signature calculation to ensure all=
 these kinds of attacks are eliminated. And you have to ensure that all RSe=
s check the context.=20

Contrast that to my suggestion to use ECDH [1], which was already immune to=
 such attacks by including the access token in the key derivation step. (An=
d in such a way that requires no additional data on the wire and is almost =
impossible for the RS not to verify). Even without including the access tok=
en in the KDF, the attack could only happen if the client reused its key an=
d the RS reused a challenge key pair.=20

Macaroon access tokens [2] are also immune to this attack, as in that case =
the constraints that go in the DPoP proof are directly attached to the acce=
ss token itself so there is no way to reuse them separately. (Interestingly=
, macaroons have a more direct analogue of DPoP in the form of discharge ma=
caroons. Such discharge macaroons are required to be =E2=80=9Cprepared=E2=
=80=9D before use, which cryptographically binds them to the equivalent of =
the access token - so this kind of attack was also considered and addressed=
 there).=20

[1]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9=
s/
[2]: https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-ma=
caroon-access-tokens-in-am-7-0/

=E2=80=94 Neil

> On 24 Nov 2020, at 09:38, Daniel Fett  wrote:
>=20
> =EF=BB=BF
> Thanks Justin for bringing this to our attention.
>=20
> Right now, I don't think that this is a big problem and I wasn't able to =
come up with a way to improve the attack. I hope that it doesn't come back =
to haunt us when somebody does a more in-depth analysis...
>=20
> That said, the lack of binding to the access token makes it easier to pre=
compute proofs if somebody has a limited code execution opportunity in the =
client. We have this paragraph in the spec:
>=20
>    Malicious XSS code executed in the context of the browser-based
>    client application is also in a position to create DPoP proofs with
>    timestamp values in the future and exfiltrate them in conjunction
>    with a token.  These stolen artifacts can later be used together
>    independent of the client application to access protected resources.
>    The impact of such precomputed DPoP proofs can be limited somewhat by
>    a browser-based client generating and using a new DPoP key for each
>    new authorization code grant.
>=20
> The recommendation could be to use a fresh key pair for each token reques=
t.
>=20
> -Daniel
>=20
>=20
> Am 20.11.20 um 20:26 schrieb Justin Richer:
>> While working on an implementation of DPoP recently, I realized that the=
 value of the access token itself is not covered by the DPoP signature at a=
ll. What I=E2=80=99m wondering is whether or not this constitutes an attack=
 surface that we care about here. Here=E2=80=99s how it works:
>>=20
>>=20
>> Let=E2=80=99s say that a client creates a DPoP key and uses that key to =
request two tokens, T1 and T2, for different users, Alice and Bob, respecti=
vely. Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice manage=
s to get a hold of Bob=E2=80=99s token value, T2, through some means. Norma=
lly DPoP wouldn=E2=80=99t let Alice create a new request using T2 since Ali=
ce doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets th=
e client to create a request for her using T1, she can copy the signature f=
rom that request onto a new request using T2. Since the signature doesn=E2=
=80=99t cover the token value and the key is the same, the RS should accept=
 both requests, right?
>>=20
>> An important aspect is that the parts needed to make this attack work ar=
e a little weird: you=E2=80=99d need access to a valid signed request from =
the client with T1 as well as access to a valid T2 attached to the same key=
 in order to make this substitution. However, this is effectively the same =
attack area that bearer tokens have in a lot of ways, since it doesn=E2=80=
=99t require the attacker gaining access to the singing key to generate or =
modify a signature, nor does it require the attacker to generate or modify =
an access token (merely obtain one).
>>=20
>>=20
>> I=E2=80=99d like to understand if this is an actual attack against DPoP.=
 If it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we di=
scuss in the DPoP draft? I didn=E2=80=99t see a mention of it there. If it=
=E2=80=99s not, should we discuss it there?
>>=20
>>=20
>> The old OAuth PoP draft mitigates this attack by putting the access toke=
n itself inside the signature body instead of a second header. Another opti=
on would be to include a hash of the token value (such as OIDC=E2=80=99s =
=E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. Wi=
th either of these approaches, Alice having access to T1, T2, and a signed =
message for T1 does not allow her to use T2 effectively.
>>=20
>>  =E2=80=94 Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> --=20
> https://danielfett.de
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
ForgeRock values your Privacy 

--Apple-Mail-4FA33979-B5F8-4764-B602-BD44E3FF5ADF
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree with Daniel th=
at I=E2=80=99d be a bit wary of assuming that this could never be exploited=
. For example, a server-side web app that signs DPoP proofs on behalf of cl=
ient-side Javascript (to keep the key safe on the server) and reuses the ke=
y for different users could be a risk. 

IMO this is another symptom of the general issue of usin=
g signatures for authentication - they are too strong for the job. The fact=
 that a signature is equally valid to all parties and at all times means yo=
u have to be very careful to include enough context in the signature calcul=
ation to ensure all these kinds of attacks are eliminated. And you have to =
ensure that all RSes check the context. 

Contrast that to my suggestion to use ECDH [1], which w=
as already immune to such attacks by including the access token in the key =
derivation step. (And in such a way that requires no additional data on the=
 wire and is almost impossible for the RS not to verify). Even without incl=
uding the access token in the KDF, the attack could only happen if the clie=
nt reused its key and the RS reused a challenge key pair. 

Macaroon access tokens [2] are also i=
mmune to this attack, as in that case the constraints that go in the DPoP p=
roof are directly attached to the access token itself so there is no way to=
 reuse them separately. (Interestingly, macaroons have a more direct analog=
ue of DPoP in the form of discharge macaroons. Such discharge macaroons are=
 required to be =E2=80=9Cprepared=E2=80=9D before use, which cryptographica=
lly binds them to the equivalent of the access token - so this kind of atta=
ck was also considered and addressed there). 
[2]:&n=
bsp;https://neilmadden.blog/2020/07/=
29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/

=E2=80=94 Neil

On 24 Nov 2020, at 09:38, Daniel Fe=
tt <fett@danielfett.de> wrote:

=EF=BB=BF
 =20
    
 =20
 =20
    
Thanks Justin for bringing this to our
      attention.

    


    

    
Right now, I don't think that this is a
      big problem and I wasn't able to come up with a way to improve the
      attack. I hope that it doesn't come back to haunt us when somebody
      does a more in-depth analysis...

    


    

    
That said, the lack of binding to the
      access token makes it easier to precompute proofs if somebody has
      a limited code execution opportunity in the client. We have this
      paragraph in the spec:

    


    

    
   Malicious XSS code executed=
 in the
      context of the browser-based

         client application is also in a position to create DPoP =
proofs
      with

         timestamp values in the future and exfiltrate them in
      conjunction

         with a token.  These stolen artifacts can later be =
used
      together

         independent of the client application to access protecte=
d
      resources.

         The impact of such precomputed DPoP proofs can be limite=
d
      somewhat by

         a browser-based client generating and using a new DPoP k=
ey for
      each

         new authorization code grant.

    


    

    
The recommendation could be to use a
      fresh key pair for each token request.

    


    

    
-Daniel

    


    

    


    

    
Am 20.11.20 um 20:26 schrieb Justin
      Richer:

    

    

      
While working on an implementa=
tion of DPoP recently, I realized that the value of the access token itself=
 is not covered by the DPoP signature at all. What I=E2=80=99m wondering is=
 whether or not this constitutes an attack surface that we care about here.=
 Here=E2=80=99s how it works:


Let=E2=80=99s say that a client creates a DPoP key and uses that key to req=
uest two tokens, T1 and T2, for different users, Alice and Bob, respectivel=
y. Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice manages t=
o get a hold of Bob=E2=80=99s token value, T2, through some means. Normally=
 DPoP wouldn=E2=80=99t let Alice create a new request using T2 since Alice =
doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets the c=
lient to create a request for her using T1, she can copy the signature from=
 that request onto a new request using T2. Since the signature doesn=E2=80=
=99t cover the token value and the key is the same, the RS should accept bo=
th requests, right?

An important aspect is that the parts needed to make this attack work are a=
 little weird: you=E2=80=99d need access to a valid signed request from the=
 client with T1 as well as access to a valid T2 attached to the same key in=
 order to make this substitution. However, this is effectively the same att=
ack area that bearer tokens have in a lot of ways, since it doesn=E2=80=99t=
 require the attacker gaining access to the singing key to generate or modi=
fy a signature, nor does it require the attacker to generate or modify an a=
ccess token (merely obtain one).


I=E2=80=99d like to understand if this is an actual attack against DPoP. If=
 it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we discu=
ss in the DPoP draft? I didn=E2=80=99t see a mention of it there. If it=E2=
=80=99s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access token i=
tself inside the signature body instead of a second header. Another option =
would be to include a hash of the token value (such as OIDC=E2=80=99s =E2=
=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. With =
either of these approaches, Alice having access to T1, T2, and a signed mes=
sage for T1 does not allow her to use T2 effectively.

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


    

    


    

    
--=20
https://d=
anielfett.de

 =20

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



ForgeRock values your Privacy
--Apple-Mail-4FA33979-B5F8-4764-B602-BD44E3FF5ADF--


From nobody Tue Nov 24 10:00:12 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82D73A1276 for ; Tue, 24 Nov 2020 10:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCF3HNymEYd5 for ; Tue, 24 Nov 2020 10:00:09 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8356A3A1274 for ; Tue, 24 Nov 2020 10:00:09 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id s30so30163777lfc.4 for ; Tue, 24 Nov 2020 10:00:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TH3FaRJtu/jQFyH58pv3TvwM+9uPCoEmSkHrqiCB+Ts=; b=a9NYXGOqw6zvS+LKBP85ak3Ngeum1Rg3WVe8oX1BmOqtUgwkj985vM3go5JlJb1lAU +T+jgpNZ/eG1BF1DOQ3YnhDHJ6ezlvL3y2pXieFVW9fg7mNxns30lErM2L/RjeWg743y hNJlDDhiKDAzHLXQ8DnxEHs92PYlvKBMWVgR08yaNEukW0HMdQabs6ZEFpYKbhyf6XFb nvRzEfRZHfcMR0Hkug0wQp0w5r80+sk8DKn1Qub4e9tCXhzawpS7dMsjEaT1WTX3JCUS 63qJmZ4xjCRNRF6pgwWD7ikLSty3MTWqbsBjlg4VWLNPvTjBuXhDurj9jvjaRnumd8k9 ptQw==
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=TH3FaRJtu/jQFyH58pv3TvwM+9uPCoEmSkHrqiCB+Ts=; b=oK0O0B/5NtAoPrTTUruiEBjmmw7y9NSjCrw1q+G6ojhwwVjZSLieEuoaMitlgPAk+n WZel54fJGcC8lUduEs+bcVaXbzkLnXeF6WdBlvBKDyTNkra0bP9d602e4RYB41xRjelk pftXNEMD5JY1WGSh6JGqYY0cZDyZ5l5O8py6X6k7OExqwKcCupR9zirkXcrcuAXCV3tY 4OMi5HYZWdBDUg/3HkKBcVjTNlwsk+4zJCmr2B5iAclKanrcWNIAT+mHg5MMUpd1q3fc Pc3JNVWyzeT5ie4tW29KBCe1hHO633nPt6gmN/hG98K16sIjPLVBvvvshQ6Yx3lbLYaF uBTQ==
X-Gm-Message-State: AOAM530AEXLvB95H47a7NoUx0KNOgnB/SEt9//FBi5ZxVMABG9SPjVUl +rW/GABz+U0p9Yqmj1lHOnYsayysUgnYjIhnqsCsWoxZBoXI1qDs+sDM5xAyxy0Ki2HoQSceZy2 1dWnIQsBE3CUE4w==
X-Google-Smtp-Source: ABdhPJyRtMHUKSi2Wzz+tBVZVh+A6AOIylK8Tdj++uiUGDKMNqXsYYkOBEz+dOBdcrLVmvVMrr4jY4w5wgHtg39QdSk=
X-Received: by 2002:ac2:58e6:: with SMTP id v6mr2062914lfo.407.1606240807364;  Tue, 24 Nov 2020 10:00:07 -0800 (PST)
MIME-Version: 1.0
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu> 
In-Reply-To: 
From: Brian Campbell 
Date: Tue, 24 Nov 2020 10:59:41 -0700
Message-ID: 
To: Daniel Fett 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000bf4f2305b4de1414"
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 24 Nov 2020 18:00:11 -0000

--000000000000bf4f2305b4de1414
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 24, 2020 at 2:39 AM Daniel Fett  wrote:

>
> The recommendation could be to use a fresh key pair for each token reques=
t.
>
>
 Public clients will have RTs bound so need to use the same key.

--=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._

--000000000000bf4f2305b4de1414
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 24, 2020 at 2:39 AM Danie=
l Fett <fett@danielfett.de>=
 wrote:

 =20
   =20
 =20
  

    

    
The recommendation could be to use a
      fresh key pair for each token request.


=C2=A0Public clients will have RTs bound so need to use t=
he same key. 




<=
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.
--000000000000bf4f2305b4de1414--


From nobody Tue Nov 24 13:18:40 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754133A0BD9 for ; Tue, 24 Nov 2020 13:18:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVIS_IohXFoV for ; Tue, 24 Nov 2020 13:18:35 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 A79AA3A0BE2 for ; Tue, 24 Nov 2020 13:18:34 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id s27so107162lfp.5 for ; Tue, 24 Nov 2020 13:18:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nZ9mrCHvzuAfkExbUXyZJ3K18jgXbN3G8p7p9x3fv7Y=; b=RM+XZq5l0LOdZRnA4io5O6jeqdnpdcF4Ez9rHCsskAYtOOrnrYGLJhwJ293SAghAYH 2vS5aMEFhGVOqVMwfHf1qjKKleHl2eAp84x3GVruUMb5X01L9Msu5crrhePtxtK2LdZC 4+aBJbV3DgMTRzPRWvfp0E2vAoyT0kPZXhz9Xw7LMsbwlrQJQDV3EN1J11weHE/EtoR8 W/+HOs/aLjC0YRMF/oLLqhsuFG/ZhN5ZyTVgdAwxeEt88K3Tqo4pMuiD/7Qm3qvqeCdt qZwrDaSqLmex01fzyd/Y3uGdwjkU6k3daxjluiHkxJGVcqkw17JUNk39bMC8eFSPt6Lx I2EA==
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=nZ9mrCHvzuAfkExbUXyZJ3K18jgXbN3G8p7p9x3fv7Y=; b=Fnq8Mk8lwsNcU/nJdCh+KfyRjlkFRDnrb2vScQs4A8Dsm8K2x05FltxTW+tZOVmcA3 6/3XpynqaEFtsQXX44N8k4lBih/yvCO5Pnl8em50yVPC7LfMz6SDbbI/uXW3xuJPudiP Y7F8Gl7ZS/LI4R8ZPOsgK399yIYT1fll/eSM3mhxgyRTZjM3f/MVqsPYFiDRy/2AKJol ROB/e1z6wfcz1SccCbkodrUxQPTc6kszuRjQ36XY9twIcLRGZyqhL3MzmEV3lIZlfkA7 cNy+/FICR3voAi6P5iA3qMjHCJTic8KvAAf6mjhPRNa+HqvjWp2WbgeNtmFXU4gkO5OF TflA==
X-Gm-Message-State: AOAM532uwEnbWUKdyRis2rCi0Xni5A2izWp384rN1rm01W8P9G/XIaTW NH+g6VfRiexS4tOBGKJ94qorBmlvDLgqu/+HPd0Qk3TwfyfsAlht5wKBGKqsfQmnCub719hegIN y3qZPF/lPeUtxsg==
X-Google-Smtp-Source: ABdhPJw+2nJOIbI9D2sKy4jqhpBd0MM2pSNN5ihFtbrc/PUo0UY8364w5x1/nY545MNaBW85ADDUL3i4WNmiFmvLxEA=
X-Received: by 2002:ac2:4349:: with SMTP id o9mr34214lfl.194.1606252710099; Tue, 24 Nov 2020 13:18:30 -0800 (PST)
MIME-Version: 1.0
References:  <22D724F4-BF92-481F-A70C-E82B08D2017F@forgerock.com>
In-Reply-To: <22D724F4-BF92-481F-A70C-E82B08D2017F@forgerock.com>
From: Brian Campbell 
Date: Tue, 24 Nov 2020 14:18:03 -0700
Message-ID: 
To: Neil Madden 
Cc: Daniel Fett , oauth 
Content-Type: multipart/alternative; boundary="00000000000034a4ab05b4e0dabe"
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 24 Nov 2020 21:18:39 -0000

--00000000000034a4ab05b4e0dabe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It took me some time to warm to the ECDH based idea but I do think it has a
lot of merit. For whatever it's worth, I put the idea forth as one
potential path forward during the general PoP interim meeting back in March
(
https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides=
-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf
slide 8) but the WG consensus was to pursue a signature style PoP for the
current efforts, which was followed not long after by WG adoption of DPoP.
I could potentially see an ECDH-style-POP effort making a resurgence in the
future. But it's fundamentally pretty different.




On Tue, Nov 24, 2020 at 4:03 AM Neil Madden 
wrote:

> I agree with Daniel that I=E2=80=99d be a bit wary of assuming that this =
could
> never be exploited. For example, a server-side web app that signs DPoP
> proofs on behalf of client-side Javascript (to keep the key safe on the
> server) and reuses the key for different users could be a risk.
>
> IMO this is another symptom of the general issue of using signatures for
> authentication - they are too strong for the job. The fact that a signatu=
re
> is equally valid to all parties and at all times means you have to be ver=
y
> careful to include enough context in the signature calculation to ensure
> all these kinds of attacks are eliminated. And you have to ensure that al=
l
> RSes check the context.
>
> Contrast that to my suggestion to use ECDH [1], which was already immune
> to such attacks by including the access token in the key derivation step.
> (And in such a way that requires no additional data on the wire and is
> almost impossible for the RS not to verify). Even without including the
> access token in the KDF, the attack could only happen if the client reuse=
d
> its key and the RS reused a challenge key pair.
>
> Macaroon access tokens [2] are also immune to this attack, as in that cas=
e
> the constraints that go in the DPoP proof are directly attached to the
> access token itself so there is no way to reuse them separately.
> (Interestingly, macaroons have a more direct analogue of DPoP in the form
> of discharge macaroons. Such discharge macaroons are required to be
> =E2=80=9Cprepared=E2=80=9D before use, which cryptographically binds them=
 to the equivalent
> of the access token - so this kind of attack was also considered and
> addressed there).
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/
> [2]:
> https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macar=
oon-access-tokens-in-am-7-0/
>
> =E2=80=94 Neil
>
> On 24 Nov 2020, at 09:38, Daniel Fett  wrote:
>
> =EF=BB=BF
> Thanks Justin for bringing this to our attention.
>
> Right now, I don't think that this is a big problem and I wasn't able to
> come up with a way to improve the attack. I hope that it doesn't come bac=
k
> to haunt us when somebody does a more in-depth analysis...
>
> That said, the lack of binding to the access token makes it easier to
> precompute proofs if somebody has a limited code execution opportunity in
> the client. We have this paragraph in the spec:
>
>    Malicious XSS code executed in the context of the browser-based
>    client application is also in a position to create DPoP proofs with
>    timestamp values in the future and exfiltrate them in conjunction
>    with a token.  These stolen artifacts can later be used together
>    independent of the client application to access protected resources.
>    The impact of such precomputed DPoP proofs can be limited somewhat by
>    a browser-based client generating and using a new DPoP key for each
>    new authorization code grant.
>
> The recommendation could be to use a fresh key pair for each token reques=
t.
>
> -Daniel
>
>
> Am 20.11.20 um 20:26 schrieb Justin Richer:
>
> While working on an implementation of DPoP recently, I realized that the =
value of the access token itself is not covered by the DPoP signature at al=
l. What I=E2=80=99m wondering is whether or not this constitutes an attack =
surface that we care about here. Here=E2=80=99s how it works:
>
>
> Let=E2=80=99s say that a client creates a DPoP key and uses that key to r=
equest two tokens, T1 and T2, for different users, Alice and Bob, respectiv=
ely. Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice manages=
 to get a hold of Bob=E2=80=99s token value, T2, through some means. Normal=
ly DPoP wouldn=E2=80=99t let Alice create a new request using T2 since Alic=
e doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets the=
 client to create a request for her using T1, she can copy the signature fr=
om that request onto a new request using T2. Since the signature doesn=E2=
=80=99t cover the token value and the key is the same, the RS should accept=
 both requests, right?
>
> An important aspect is that the parts needed to make this attack work are=
 a little weird: you=E2=80=99d need access to a valid signed request from t=
he client with T1 as well as access to a valid T2 attached to the same key =
in order to make this substitution. However, this is effectively the same a=
ttack area that bearer tokens have in a lot of ways, since it doesn=E2=80=
=99t require the attacker gaining access to the singing key to generate or =
modify a signature, nor does it require the attacker to generate or modify =
an access token (merely obtain one).
>
>
> I=E2=80=99d like to understand if this is an actual attack against DPoP. =
If it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we dis=
cuss in the DPoP draft? I didn=E2=80=99t see a mention of it there. If it=
=E2=80=99s not, should we discuss it there?
>
>
> The old OAuth PoP draft mitigates this attack by putting the access token=
 itself inside the signature body instead of a second header. Another optio=
n would be to include a hash of the token value (such as OIDC=E2=80=99s =E2=
=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. With =
either of these approaches, Alice having access to T1, T2, and a signed mes=
sage for T1 does not allow her to use T2 effectively.
>
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> -- https://danielfett.de
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ForgeRock values your Privacy 
> _______________________________________________
> 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._

--00000000000034a4ab05b4e0dabe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It took me some time to warm to the ECDH based idea b=
ut I do think it has a lot of merit. For whatever it's worth, I put the=
 idea forth as one potential path forward during the general PoP interim me=
eting back in March (https://datatracker.ietf.org/meeti=
ng/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth=
-20-proof-of-possession-00.pdf slide 8) but the WG consensus was to pur=
sue a  signature style PoP for the current efforts, which was followed not =
long after by WG adoption of DPoP. I could potentially see an ECDH-style-PO=
P effort making a resurgence in the future. But it's fundamentally pret=
ty different.=C2=A0 



=


=
On Tue, Nov 24, 2020 at 4:03 AM Neil Madden <neil.madden@forgerock.com> wrote=
:
I agree with Daniel that I=E2=80=99d be a bit wary of =
assuming that this could never be exploited. For example, a server-side web=
 app that signs DPoP proofs on behalf of client-side Javascript (to keep th=
e key safe on the server) and reuses the key for different users could be a=
 risk.=C2=A0

IMO this is a=
nother symptom of the general issue of using signatures for authentication =
- they are too strong for the job. The fact that a signature is equally val=
id to all parties and at all times means you have to be very careful to inc=
lude enough context in the signature calculation to ensure all these kinds =
of attacks are eliminated. And you have to ensure that all RSes check the c=
ontext.=C2=A0

Contrast tha=
t to my suggestion to use ECDH [1], which was already immune to such attack=
s by including the access token in the key derivation step. (And in such a =
way that requires no additional data on the wire and is almost impossible f=
or the RS not to verify). Even without including the access token in the KD=
F, the attack could only happen if the client reused its key and the RS reu=
sed a challenge key pair.=C2=A0

Macaroon access tokens [2] are also immune to this attack, as in that=
 case the constraints that go in the DPoP proof are directly attached to th=
e access token itself so there is no way to reuse them separately. (Interes=
tingly, macaroons have a more direct analogue of DPoP in the form of discha=
rge macaroons. Such discharge macaroons are required to be =E2=80=9Cprepare=
d=E2=80=9D before use, which cryptographically binds them to the equivalent=
 of the access token - so this kind of attack was also considered and addre=
ssed there).=C2=A0



On 24 Nov 2020, at 09:38, Danie=
l Fett <fett@dan=
ielfett.de> wrote:

=EF=BB=BF
 =20
   =20
 =20
 =20
    
Thanks Justin for bringing this to our
      attention.

    


    

    
Right now, I don't think that this is a
      big problem and I wasn't able to come up with a way to improve th=
e
      attack. I hope that it doesn't come back to haunt us when somebod=
y
      does a more in-depth analysis...

    


    

    
That said, the lack of binding to the
      access token makes it easier to precompute proofs if somebody has
      a limited code execution opportunity in the client. We have this
      paragraph in the spec:

    


    

    
=C2=A0=C2=A0 Malicious XSS code executed in the
      context of the browser-based

      =C2=A0=C2=A0 client application is also in a position to create DPoP =
proofs
      with

      =C2=A0=C2=A0 timestamp values in the future and exfiltrate them in
      conjunction

      =C2=A0=C2=A0 with a token.=C2=A0 These stolen artifacts can later be =
used
      together

      =C2=A0=C2=A0 independent of the client application to access protecte=
d
      resources.

      =C2=A0=C2=A0 The impact of such precomputed DPoP proofs can be limite=
d
      somewhat by

      =C2=A0=C2=A0 a browser-based client generating and using a new DPoP k=
ey for
      each

      =C2=A0=C2=A0 new authorization code grant.

    


    

    
The recommendation could be to use a
      fresh key pair for each token request.

    


    

    
-Daniel

    


    

    


    

    
Am 20.11.20 um 20:26 schrieb Justin
      Richer:

    

    

      
While working on an implementation of DPoP recently, I realized =
that the value of the access token itself is not covered by the DPoP signat=
ure at all. What I=E2=80=99m wondering is whether or not this constitutes a=
n attack surface that we care about here. Here=E2=80=99s how it works:


Let=E2=80=99s say that a client creates a DPoP key and uses that key to req=
uest two tokens, T1 and T2, for different users, Alice and Bob, respectivel=
y. Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice manages t=
o get a hold of Bob=E2=80=99s token value, T2, through some means. Normally=
 DPoP wouldn=E2=80=99t let Alice create a new request using T2 since Alice =
doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets the c=
lient to create a request for her using T1, she can copy the signature from=
 that request onto a new request using T2. Since the signature doesn=E2=80=
=99t cover the token value and the key is the same, the RS should accept bo=
th requests, right?

An important aspect is that the parts needed to make this attack work are a=
 little weird: you=E2=80=99d need access to a valid signed request from the=
 client with T1 as well as access to a valid T2 attached to the same key in=
 order to make this substitution. However, this is effectively the same att=
ack area that bearer tokens have in a lot of ways, since it doesn=E2=80=99t=
 require the attacker gaining access to the singing key to generate or modi=
fy a signature, nor does it require the attacker to generate or modify an a=
ccess token (merely obtain one).


I=E2=80=99d like to understand if this is an actual attack against DPoP. If=
 it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we discu=
ss in the DPoP draft? I didn=E2=80=99t see a mention of it there. If it=E2=
=80=99s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access token i=
tself inside the signature body instead of a second header. Another option =
would be to include a hash of the token value (such as OIDC=E2=80=99s =E2=
=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. With =
either of these approaches, Alice having access to T1, T2, and a signed mes=
sage for T1 does not allow her to use T2 effectively.

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


    

    


    

    
--=20
https://danielfett.de

 =20

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



ForgeRock values your Privacy__=
_____________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000034a4ab05b4e0dabe--


From nobody Tue Nov 24 15:32:15 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917553A0773 for ; Tue, 24 Nov 2020 15:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrkTv6dxI1YW for ; Tue, 24 Nov 2020 15:32:11 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93973A0762 for ; Tue, 24 Nov 2020 15:32:10 -0800 (PST)
Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AONW7fK028620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Nov 2020 18:32:07 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_96BBA268-8DDB-4AC0-90AF-04659D929707"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 24 Nov 2020 18:32:06 -0500
In-Reply-To: 
Cc: Neil Madden , oauth 
To: Brian Campbell 
References:  <22D724F4-BF92-481F-A70C-E82B08D2017F@forgerock.com> 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 24 Nov 2020 23:32:14 -0000

--Apple-Mail=_96BBA268-8DDB-4AC0-90AF-04659D929707
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

With the renewed work on HTTP Message Signatures[1] in the HTTP WG[2], I =
think we might have a good avenue for this ECDH-with-KDF flavor of =
message signature in that arena instead of trying to twist it into DPoP. =
I think that this signing mechanism will be a better base for a general =
PoP effort in OAuth, and I still believe that this could live alongside =
DPoP=E2=80=99s more specific focus and intentional limitations.=20

 =E2=80=94 Justin

[1] =
https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.html =


[2] https://github.com/httpwg/http-extensions/ =



> On Nov 24, 2020, at 4:18 PM, Brian Campbell =
 wrote:
>=20
> It took me some time to warm to the ECDH based idea but I do think it =
has a lot of merit. For whatever it's worth, I put the idea forth as one =
potential path forward during the general PoP interim meeting back in =
March =
(https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slid=
es-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf =
 =
slide 8) but the WG consensus was to pursue a signature style PoP for =
the current efforts, which was followed not long after by WG adoption of =
DPoP. I could potentially see an ECDH-style-POP effort making a =
resurgence in the future. But it's fundamentally pretty different. =20
>=20
>=20
>=20
>=20
> On Tue, Nov 24, 2020 at 4:03 AM Neil Madden > wrote:
> I agree with Daniel that I=E2=80=99d be a bit wary of assuming that =
this could never be exploited. For example, a server-side web app that =
signs DPoP proofs on behalf of client-side Javascript (to keep the key =
safe on the server) and reuses the key for different users could be a =
risk.=20
>=20
> IMO this is another symptom of the general issue of using signatures =
for authentication - they are too strong for the job. The fact that a =
signature is equally valid to all parties and at all times means you =
have to be very careful to include enough context in the signature =
calculation to ensure all these kinds of attacks are eliminated. And you =
have to ensure that all RSes check the context.=20
>=20
> Contrast that to my suggestion to use ECDH [1], which was already =
immune to such attacks by including the access token in the key =
derivation step. (And in such a way that requires no additional data on =
the wire and is almost impossible for the RS not to verify). Even =
without including the access token in the KDF, the attack could only =
happen if the client reused its key and the RS reused a challenge key =
pair.=20
>=20
> Macaroon access tokens [2] are also immune to this attack, as in that =
case the constraints that go in the DPoP proof are directly attached to =
the access token itself so there is no way to reuse them separately. =
(Interestingly, macaroons have a more direct analogue of DPoP in the =
form of discharge macaroons. Such discharge macaroons are required to be =
=E2=80=9Cprepared=E2=80=9D before use, which cryptographically binds =
them to the equivalent of the access token - so this kind of attack was =
also considered and addressed there).=20
>=20
> [1]: =
https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/ =
=

> [2]: =
https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaro=
on-access-tokens-in-am-7-0/ =

>=20
> =E2=80=94 Neil
>=20
>> On 24 Nov 2020, at 09:38, Daniel Fett > wrote:
>>=20
>> =EF=BB=BF
>> Thanks Justin for bringing this to our attention.
>>=20
>> Right now, I don't think that this is a big problem and I wasn't able =
to come up with a way to improve the attack. I hope that it doesn't come =
back to haunt us when somebody does a more in-depth analysis...
>>=20
>> That said, the lack of binding to the access token makes it easier to =
precompute proofs if somebody has a limited code execution opportunity =
in the client. We have this paragraph in the spec:
>>=20
>>    Malicious XSS code executed in the context of the browser-based
>>    client application is also in a position to create DPoP proofs =
with
>>    timestamp values in the future and exfiltrate them in conjunction
>>    with a token.  These stolen artifacts can later be used together
>>    independent of the client application to access protected =
resources.
>>    The impact of such precomputed DPoP proofs can be limited somewhat =
by
>>    a browser-based client generating and using a new DPoP key for =
each
>>    new authorization code grant.
>>=20
>> The recommendation could be to use a fresh key pair for each token =
request.
>>=20
>> -Daniel
>>=20
>>=20
>> Am 20.11.20 um 20:26 schrieb Justin Richer:
>>> While working on an implementation of DPoP recently, I realized that =
the value of the access token itself is not covered by the DPoP =
signature at all. What I=E2=80=99m wondering is whether or not this =
constitutes an attack surface that we care about here. Here=E2=80=99s =
how it works:
>>>=20
>>>=20
>>> Let=E2=80=99s say that a client creates a DPoP key and uses that key =
to request two tokens, T1 and T2, for different users, Alice and Bob, =
respectively. Alice is malicious and wants to get Bob=E2=80=99s stuff. =
Alice manages to get a hold of Bob=E2=80=99s token value, T2, through =
some means. Normally DPoP wouldn=E2=80=99t let Alice create a new =
request using T2 since Alice doesn=E2=80=99t have the client=E2=80=99s =
key. However, if Alice gets the client to create a request for her using =
T1, she can copy the signature from that request onto a new request =
using T2. Since the signature doesn=E2=80=99t cover the token value and =
the key is the same, the RS should accept both requests, right?
>>>=20
>>> An important aspect is that the parts needed to make this attack =
work are a little weird: you=E2=80=99d need access to a valid signed =
request from the client with T1 as well as access to a valid T2 attached =
to the same key in order to make this substitution. However, this is =
effectively the same attack area that bearer tokens have in a lot of =
ways, since it doesn=E2=80=99t require the attacker gaining access to =
the singing key to generate or modify a signature, nor does it require =
the attacker to generate or modify an access token (merely obtain one).
>>>=20
>>>=20
>>> I=E2=80=99d like to understand if this is an actual attack against =
DPoP. If it isn=E2=80=99t, how is it countered by DPoP today? If it is, =
do we discuss in the DPoP draft? I didn=E2=80=99t see a mention of it =
there. If it=E2=80=99s not, should we discuss it there?
>>>=20
>>>=20
>>> The old OAuth PoP draft mitigates this attack by putting the access =
token itself inside the signature body instead of a second header. =
Another option would be to include a hash of the token value (such as =
OIDC=E2=80=99s =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in =
the DPoP payload. With either of these approaches, Alice having access =
to T1, T2, and a signed message for T1 does not allow her to use T2 =
effectively.
>>>=20
>>>  =E2=80=94 Justin
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>>=20
>> --=20
>> https://danielfett.de =
_______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> ForgeRock values your Privacy =
__________________________________=
_____________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_96BBA268-8DDB-4AC0-90AF-04659D929707
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

With =
the renewed work on HTTP Message Signatures[1] in the HTTP WG[2], I =
think we might have a good avenue for this ECDH-with-KDF flavor of =
message signature in that arena instead of trying to twist it into DPoP. =
I think that this signing mechanism will be a better base for a general =
PoP effort in OAuth, and I still believe that this could live alongside =
DPoP=E2=80=99s more specific focus and intentional =
limitations. 

 =E2=80=94 Justin

[1] https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures=
-01.html

[2] https://github.com/httpwg/http-extensions/


On Nov 24, 2020, at 4:18 PM, =
Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> =
wrote:

It took me some =
time to warm to the ECDH based idea but I do think it has a lot of =
merit. For whatever it's worth, I put the idea forth as one potential =
path forward during the general PoP interim meeting back in March (https://datatracker.ietf.org/meeting/interim-2020-oauth-02/mate=
rials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.p=
df slide 8) but the WG consensus was to pursue a  signature style =
PoP for the current efforts, which was followed not long after by WG =
adoption of DPoP. I could potentially see an ECDH-style-POP effort =
making a resurgence in the future. But it's fundamentally pretty =
different.  




On Tue, Nov 24, 2020 at 4:03 AM Neil =
Madden <neil.madden@forgerock.com> wrote:
I agree with Daniel that I=E2=80=99d be a bit =
wary of assuming that this could never be exploited. For example, a =
server-side web app that signs DPoP proofs on behalf of client-side =
Javascript (to keep the key safe on the server) and reuses the key for =
different users could be a risk. 

IMO this is =
another symptom of the general issue of using signatures for =
authentication - they are too strong for the job. The fact that a =
signature is equally valid to all parties and at all times means you =
have to be very careful to include enough context in the signature =
calculation to ensure all these kinds of attacks are eliminated. And you =
have to ensure that all RSes check the context. 

Contrast that to my suggestion to use ECDH [1], which was =
already immune to such attacks by including the access token in the key =
derivation step. (And in such a way that requires no additional data on =
the wire and is almost impossible for the RS not to verify). Even =
without including the access token in the KDF, the attack could only =
happen if the client reused its key and the RS reused a challenge key =
pair. 

Macaroon access tokens [2] are also immune to =
this attack, as in that case the constraints that go in the DPoP proof =
are directly attached to the access token itself so there is no way to =
reuse them separately. (Interestingly, macaroons have a more direct =
analogue of DPoP in the form of discharge macaroons. Such discharge =
macaroons are required to be =E2=80=9Cprepared=E2=80=9D before use, =
which cryptographically binds them to the equivalent of the access token =
- so this kind of attack was also considered and addressed =
there). 

[1]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmho=
KLbavu9s/
[2]: https://neilmadden.blog/2020/07/29/least-privilege-with-less-ef=
fort-macaroon-access-tokens-in-am-7-0/

=E2=80=94 =
Neil

On 24 Nov 2020, at 09:38, Daniel Fett <fett@danielfett.de> wrote:

=EF=BB=BF
 =20
   =20
 =20
 =20
    
Thanks Justin for bringing this to our
      attention.

    


    

    
Right now, I don't think that this is a
      big problem and I wasn't able to come up with a way to improve the
      attack. I hope that it doesn't come back to haunt us when somebody
      does a more in-depth analysis...

    


    

    
That said, the lack of binding to the
      access token makes it easier to precompute proofs if somebody has
      a limited code execution opportunity in the client. We have this
      paragraph in the spec:

    


    

    
   Malicious XSS code executed in the
      context of the browser-based

         client application is also in a position to create =
DPoP proofs
      with

         timestamp values in the future and exfiltrate them in
      conjunction

         with a token.  These stolen artifacts can later =
be used
      together

         independent of the client application to access =
protected
      resources.

         The impact of such precomputed DPoP proofs can be =
limited
      somewhat by

         a browser-based client generating and using a new =
DPoP key for
      each

         new authorization code grant.

    


    

    
The recommendation could be to use a
      fresh key pair for each token request.

    


    

    
-Daniel

    


    

    


    

    
Am 20.11.20 um 20:26 schrieb Justin
      Richer:

    

    

      
While working on an implementation of DPoP =
recently, I realized that the value of the access token itself is not =
covered by the DPoP signature at all. What I=E2=80=99m wondering is =
whether or not this constitutes an attack surface that we care about =
here. Here=E2=80=99s how it works:


Let=E2=80=99s say that a client creates a DPoP key and uses that key to =
request two tokens, T1 and T2, for different users, Alice and Bob, =
respectively. Alice is malicious and wants to get Bob=E2=80=99s stuff. =
Alice manages to get a hold of Bob=E2=80=99s token value, T2, through =
some means. Normally DPoP wouldn=E2=80=99t let Alice create a new =
request using T2 since Alice doesn=E2=80=99t have the client=E2=80=99s =
key. However, if Alice gets the client to create a request for her using =
T1, she can copy the signature from that request onto a new request =
using T2. Since the signature doesn=E2=80=99t cover the token value and =
the key is the same, the RS should accept both requests, right?

An important aspect is that the parts needed to make this attack work =
are a little weird: you=E2=80=99d need access to a valid signed request =
from the client with T1 as well as access to a valid T2 attached to the =
same key in order to make this substitution. However, this is =
effectively the same attack area that bearer tokens have in a lot of =
ways, since it doesn=E2=80=99t require the attacker gaining access to =
the singing key to generate or modify a signature, nor does it require =
the attacker to generate or modify an access token (merely obtain one).


I=E2=80=99d like to understand if this is an actual attack against DPoP. =
If it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we =
discuss in the DPoP draft? I didn=E2=80=99t see a mention of it there. =
If it=E2=80=99s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access =
token itself inside the signature body instead of a second header. =
Another option would be to include a hash of the token value (such as =
OIDC=E2=80=99s =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in =
the DPoP payload. With either of these approaches, Alice having access =
to T1, T2, and a signed message for T1 does not allow her to use T2 =
effectively.

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


    


    

    
--=20
https://danielfett.de

 =20

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



ForgeRock values your Privacy______________________________________=
_________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






CONFIDENTIALITY NOTICE: This email may contain confidential =
and privileged material for the sole use of the intended recipient(s). =
Any review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, =
please notify the sender immediately by e-mail and delete the message =
and any file attachments from your computer. Thank =
you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_96BBA268-8DDB-4AC0-90AF-04659D929707--


From nobody Tue Nov 24 18:12:35 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BE43A0C40 for ; Tue, 24 Nov 2020 18:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wesefNV-eT8s for ; Tue, 24 Nov 2020 18:12:27 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D040B3A0C15 for ; Tue, 24 Nov 2020 18:12:26 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id c198so684633wmd.0 for ; Tue, 24 Nov 2020 18:12:26 -0800 (PST)
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=y1bogaKxoItp8Trh31UwX0ui50Y4C6IKP6G6lKGPLco=; b=oKEjrQdDv+K0RA4aOtvljSxtvulKDrRHCupG8l9aYwoP3t0NRb/otTPcAdBL1bG5e+ GRWwd7L8F0WI6d/GBYYLMGk8UgQCOCRfx1AANLLXDOe5pWB/Gvu9In/rHtJO5MHQubij VtS1ybUpGig1p3jozyXGit8/gvtdmpyStBDEt7co+9MFyP4+vPFTO+7mpEYw/IQv6vkY gsyGfxV02FmZ9M/Nh8oatLjGOVqKQsBkXsfFIqU1BUZBoC1XLhUvIz6R2CYkWmTPyvWl R477klrXTiQIvwwiYz+PU5fr6QetagaCDZ+Fb1nwxxSJ+lrq+UyE6YfcKF0Zded7ijEj N1RQ==
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=y1bogaKxoItp8Trh31UwX0ui50Y4C6IKP6G6lKGPLco=; b=KXsWF1ANJMfb93Ptk1pu3G113Gl7DwHgvEb/OcTvkhr1lz8wf5IRz5AWMS0zuOZ0tu SJ7415cuCucKCk+zoP8yzL9La9dqzs1bqtimbDtW3tWQyfykQbcugkNQV51HPQuUy0GH wC6Z+zvtfT8ERX3xabFw9yj8Du75qF0ZPsDyuALTRni8dYNkfOUHv7SlcXvgDaAyIsDW qwSk/y/iMoqNxjU14FNx5ipdhwYONQURmID2+jMheynMeYQRr3EsQUoJOJwnpx6HGoPg 0bk2qScKpKqKP+yPR1weQVGWboqKscVZEA4cMe3NRA32SwNa0p7gf8DdJCJYQScQ/cn7 5LuA==
X-Gm-Message-State: AOAM530Ra+6tsc/bdPIhNiCqX90+L6XTREd1xX2SeZXqJcdz5/R8K2gD JI+BEjynhKJatP0hpA7XMQbUBxFjsNAddvRcg47mfA==
X-Google-Smtp-Source: ABdhPJxCdTjvgChzSAHF8uReTquPcLZ1Ry48XrFKkJwMf4vQiS6+nepur+0J6vZwrcwgr2McRkHWH9R8lCO08/rDRd8=
X-Received: by 2002:a1c:2b05:: with SMTP id r5mr1185296wmr.179.1606270344688;  Tue, 24 Nov 2020 18:12:24 -0800 (PST)
MIME-Version: 1.0
References: <160561332226.11634.7029583323888283532@ietfa.amsl.com> <4b0a35e1-523f-d631-7bfe-7a81c1337f92@hackmanit.de>
In-Reply-To: <4b0a35e1-523f-d631-7bfe-7a81c1337f92@hackmanit.de>
From: Takahiko Kawasaki 
Date: Wed, 25 Nov 2020 11:12:13 +0900
Message-ID: 
To: Karsten Meyer zu Selhausen 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000004f0fd005b4e4f52f"
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Nov 2020 02:12:32 -0000

--0000000000004f0fd005b4e4f52f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Karsten,

I read draft-meyerzuselhausen-oauth-iss-auth-resp-02. I think it is good
enough for authorization server implementers to implement the specification=
.

Best Regards,
Taka

On Tue, Nov 17, 2020 at 8:48 PM Karsten Meyer zu Selhausen <
karsten.meyerzuselhausen@hackmanit.de> wrote:

> Hi all,
>
> thank you for your valuable feedback on the last draft version. Daniel an=
d
> I tried to address all comments in the new version.
>
> Changes in -02:
>
>    - Incorporated WG feedback
>    - Clarifications for unique issuer identifier
>    - Clarifications when multiple issuer identifier could be present
>    - Added note that iss parameter MUST NOT be used with JARM
>    - Added note on error responses and example for error response
>    - Editorial changes
>
>
> We would like to ask you for further feedback and comments on the new
> draft version.
>
> Best regards,
> Karsten
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
> Date: Tue, 17 Nov 2020 03:42:02 -0800
> From: internet-drafts@ietf.org
> To: Karsten zu Selhausen 
> , Daniel Fett 
> , Karsten Meyer zu Selhausen
> 
> 
>
>
> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
> has been successfully submitted by Karsten Meyer zu Selhausen and posted
> to the
> IETF repository.
>
> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
> Revision: 02
> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization
> Response
> Document date: 2020-11-17
> Group: Individual Submission
> Pages: 10
> URL:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-re=
sp/
> Html:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res=
p-02.html
> Htmlized:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth=
-resp-02
>
> Abstract:
> This document specifies a new parameter "iss" that is used to
> explicitly include the issuer identifier of the authorization server
> in the authorization response of an OAuth authorization flow. If
> implemented correctly, the "iss" parameter serves as an effective
> countermeasure to "mix-up attacks".
>
>
>
> 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
>
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:	+49 (0)234 / 54456499
> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, =
Security Training
>
> Nehmen Sie an unserer n=C3=A4chsten Live Online-Schulung zur Sicherheit v=
on OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:https://www.hackmani=
t.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth=
-openid-connect-am-27-01-28-01-2021
>
> Hackmanit GmbH
> Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000004f0fd005b4e4f52f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Karsten,

I read=C2=A0draft-meyerzuse=
lhausen-oauth-iss-auth-resp-02. I think it is good enough for authorization=
 server implementers to implement the specification.

Best Regards,
Taka

<=
div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 17, 2020 at 8:48 PM Karste=
n Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> wrote:

 =20

   =20
 =20
  

    
Hi all,

    
thank you for your valuable
        feedback on the last draft version. Daniel and I tried to
        address all comments in the new version.

      

    
Changes in -02:

    
    
      
  • Incorporated WG
            feedback
    • 
      
  • Clarifications for
            unique issuer identifier
    • 
      
  • Clarifications when
            multiple issuer identifier could be present
    • 
      
  • Added note that iss
            parameter MUST NOT be used with JARM
    • 
      
  • Added note on error
            responses and example for error response
    • 
      
  • Editorial changes
    • 
    

    


      We would like to ask you for further
            feedback and comments on the new draft version.

          

    


      

    
Best regards,

    
Karsten

    


      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
          

          

            Date: 
            Tue, 17 Nov 2020 03:42:02 -0800
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Karsten zu Selhausen
              <karsten.meyerzuselhausen@hackmanit.de>, Daniel Fet=
t
              <m=
ail@danielfett.de>, Karsten Meyer zu Selhausen
              <karsten.meyerzuselhausen@hackmanit.de>
          

        
      

      

      

      

      A new version of I-D,
      draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt

      has been successfully submitted by Karsten Meyer zu Selhausen and
      posted to the

      IETF repository.

      

      Name: draft-meyerzuselhausen-oauth-iss-auth-resp

      Revision: 02

      Title: OAuth 2.0 Authorization Server Issuer Identifier in
      Authorization Response

      Document date: 2020-11-17

      Group: Individual Submission

      Pages: 10

      URL:
https://www.ietf.org/archive/id/draft-=
meyerzuselhausen-oauth-iss-auth-resp-02.txt

      Status:
https://datatracker.ietf.org/doc/draft-meye=
rzuselhausen-oauth-iss-auth-resp/

      Html:
https://www.ietf.org/archive/id/draft=
-meyerzuselhausen-oauth-iss-auth-resp-02.html

      Htmlized:
https://tools.ietf.org/html/draft-meyerzuselha=
usen-oauth-iss-auth-resp-02

      Diff:
https://www.ietf.org/rfcdiff?url2=3Ddr=
aft-meyerzuselhausen-oauth-iss-auth-resp-02

      

      Abstract:

      This document specifies a new parameter "iss" that is used =
to

      explicitly include the issuer identifier of the authorization
      server

      in the authorization response of an OAuth authorization flow. If

      implemented correctly, the "iss" parameter serves as an eff=
ective

      countermeasure to "mix-up attacks".

      

      

      

      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

      

      

    

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

Nehmen Sie an unserer n=C3=A4chsten Live Online-Schulung zur Sicherheit von=
 OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:
https://www.hackmanit.de/de/schulungen/127-live-online-schulung=
-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth



--0000000000004f0fd005b4e4f52f--


From nobody Wed Nov 25 03:09:03 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EA13A0E01 for ; Wed, 25 Nov 2020 03:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRd2FysnMdL3 for ; Wed, 25 Nov 2020 03:08:58 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF3B3A0DF3 for ; Wed, 25 Nov 2020 03:08:57 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id q16so2081369edv.10 for ; Wed, 25 Nov 2020 03:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=f2Y4Yy7Z/jhueajlmV4CShti4TsRpW1+BNNr2C3euxQ=; b=ONQqD7/zI6w1PU4PfastEe1lHuyRRGz6HRrABRW7p1tt3j9z0r6oPmQKTrPMvyZiM+ 5l1iF2+4YiLfdo3Q65F8gZq441ZnfUPH8+2Mo42aHDjAZFeChB5DlYwhW2h7eWXck1tT oMiGl6t564v9Im0fb7AJlVkIQFvtHhkt3v9Vw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=f2Y4Yy7Z/jhueajlmV4CShti4TsRpW1+BNNr2C3euxQ=; b=aKhaqZkiD4g2LgBDvom48ss53JM8bXukvxW6DwZNRrmSoCg4rheFd9+iLWPQyBQVJ5 JroyRK2LMc7lHVS4M6FlHJl2kHlriu1vIvypaqpF3QWO9VcIYZhVjf20yhkKbhy8nHyZ tDNcDUYv6eaRlIGLW/ey/aj9BOVuxQ/SW00pnsRKACOYaaYv+PgGPAUY9+EQfBaVxjpV jEKHbynQf0uzJfcBc1x6DT+6FI967DRqJQaCY96WMIWz04L4F7W4telq4YQjbGVnxhSz Qe8oi/GoFmtV0UNa1bG2Dd/nWz/wbZpIiyibUHZzd/dW7KMIViA+jnOLMnb5NTuOaPO1 Xb3A==
X-Gm-Message-State: AOAM531nsze9kHBj5veRGpTkTHfO6CCH7FtyH0ZrIV0vtRjzJdCSrS51 Y3NMJ5gqmsXA021lOz2INnHlnXxMt9GeWR+dBsipIWYFPrY9hwSJCDnwcIW45ghOZ3dghpBdmQ= =
X-Google-Smtp-Source: ABdhPJzxW+l/V1Vej4QmAyjPtGIOav4WgQg1F800peIgPBe8+MDsOhOjmb8V94ZGzulLCJuBxwYPZg==
X-Received: by 2002:a50:99c3:: with SMTP id n3mr2871681edb.213.1606302535565;  Wed, 25 Nov 2020 03:08:55 -0800 (PST)
Received: from [10.0.0.17] ([213.31.218.193]) by smtp.gmail.com with ESMTPSA id bd21sm1025818edb.79.2020.11.25.03.08.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 03:08:54 -0800 (PST)
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Wed, 25 Nov 2020 11:08:53 +0000
Message-Id: <77EA0CD3-187A-4AF6-A34E-48F5DC0653EC@forgerock.com>
References: 
Cc: Brian Campbell , oauth 
In-Reply-To: 
To: Justin Richer 
X-Mailer: iPhone Mail (18A8395)
Content-Type: multipart/alternative; boundary=Apple-Mail-C4798F38-3AE5-40BD-BF16-8368FD465AA7
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Token substitution in DPoP
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, 25 Nov 2020 11:09:03 -0000

--Apple-Mail-C4798F38-3AE5-40BD-BF16-8368FD465AA7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I=E2=80=99d be interested in hearing why people think digital signatures ar=
e a good choice for PoP. As far as I can tell that choice has not been clea=
rly motivated.=20

I have no interest in canonicalised HTTP message signing. I don=E2=80=99t t=
hink it=E2=80=99s a good idea.=20

=E2=80=94 Neil

> On 24 Nov 2020, at 23:32, Justin Richer  wrote:
>=20
> =EF=BB=BFWith the renewed work on HTTP Message Signatures[1] in the HTTP =
WG[2], I think we might have a good avenue for this ECDH-with-KDF flavor of=
 message signature in that arena instead of trying to twist it into DPoP. I=
 think that this signing mechanism will be a better base for a general PoP =
effort in OAuth, and I still believe that this could live alongside DPoP=E2=
=80=99s more specific focus and intentional limitations.=20
>=20
>  =E2=80=94 Justin
>=20
> [1] https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.ht=
ml
>=20
> [2] https://github.com/httpwg/http-extensions/
>=20
>=20
>> On Nov 24, 2020, at 4:18 PM, Brian Campbell  wrote:
>>=20
>> It took me some time to warm to the ECDH based idea but I do think it ha=
s a lot of merit. For whatever it's worth, I put the idea forth as one pote=
ntial path forward during the general PoP interim meeting back in March (ht=
tps://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-i=
nterim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf slide 8) but=
 the WG consensus was to pursue a signature style PoP for the current effor=
ts, which was followed not long after by WG adoption of DPoP. I could poten=
tially see an ECDH-style-POP effort making a resurgence in the future. But =
it's fundamentally pretty different. =20
>>=20
>>=20
>>=20
>>=20
>> On Tue, Nov 24, 2020 at 4:03 AM Neil Madden  =
wrote:
>>> I agree with Daniel that I=E2=80=99d be a bit wary of assuming that thi=
s could never be exploited. For example, a server-side web app that signs D=
PoP proofs on behalf of client-side Javascript (to keep the key safe on the=
 server) and reuses the key for different users could be a risk.=20
>>>=20
>>> IMO this is another symptom of the general issue of using signatures fo=
r authentication - they are too strong for the job. The fact that a signatu=
re is equally valid to all parties and at all times means you have to be ve=
ry careful to include enough context in the signature calculation to ensure=
 all these kinds of attacks are eliminated. And you have to ensure that all=
 RSes check the context.=20
>>>=20
>>> Contrast that to my suggestion to use ECDH [1], which was already immun=
e to such attacks by including the access token in the key derivation step.=
 (And in such a way that requires no additional data on the wire and is alm=
ost impossible for the RS not to verify). Even without including the access=
 token in the KDF, the attack could only happen if the client reused its ke=
y and the RS reused a challenge key pair.=20
>>>=20
>>> Macaroon access tokens [2] are also immune to this attack, as in that c=
ase the constraints that go in the DPoP proof are directly attached to the =
access token itself so there is no way to reuse them separately. (Interesti=
ngly, macaroons have a more direct analogue of DPoP in the form of discharg=
e macaroons. Such discharge macaroons are required to be =E2=80=9Cprepared=
=E2=80=9D before use, which cryptographically binds them to the equivalent =
of the access token - so this kind of attack was also considered and addres=
sed there).=20
>>>=20
>>> [1]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLb=
avu9s/
>>> [2]: https://neilmadden.blog/2020/07/29/least-privilege-with-less-effor=
t-macaroon-access-tokens-in-am-7-0/
>>>=20
>>> =E2=80=94 Neil
>>>=20
>>>> On 24 Nov 2020, at 09:38, Daniel Fett  wrote:
>>>>=20
>>>> =EF=BB=BF
>>>> Thanks Justin for bringing this to our attention.
>>>>=20
>>>> Right now, I don't think that this is a big problem and I wasn't able =
to come up with a way to improve the attack. I hope that it doesn't come ba=
ck to haunt us when somebody does a more in-depth analysis...
>>>>=20
>>>> That said, the lack of binding to the access token makes it easier to =
precompute proofs if somebody has a limited code execution opportunity in t=
he client. We have this paragraph in the spec:
>>>>=20
>>>>    Malicious XSS code executed in the context of the browser-based
>>>>    client application is also in a position to create DPoP proofs with
>>>>    timestamp values in the future and exfiltrate them in conjunction
>>>>    with a token.  These stolen artifacts can later be used together
>>>>    independent of the client application to access protected resources=
.
>>>>    The impact of such precomputed DPoP proofs can be limited somewhat =
by
>>>>    a browser-based client generating and using a new DPoP key for each
>>>>    new authorization code grant.
>>>>=20
>>>> The recommendation could be to use a fresh key pair for each token req=
uest.
>>>>=20
>>>> -Daniel
>>>>=20
>>>>=20
>>>> Am 20.11.20 um 20:26 schrieb Justin Richer:
>>>>> While working on an implementation of DPoP recently, I realized that =
the value of the access token itself is not covered by the DPoP signature a=
t all. What I=E2=80=99m wondering is whether or not this constitutes an att=
ack surface that we care about here. Here=E2=80=99s how it works:
>>>>>=20
>>>>>=20
>>>>> Let=E2=80=99s say that a client creates a DPoP key and uses that key =
to request two tokens, T1 and T2, for different users, Alice and Bob, respe=
ctively. Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice man=
ages to get a hold of Bob=E2=80=99s token value, T2, through some means. No=
rmally DPoP wouldn=E2=80=99t let Alice create a new request using T2 since =
Alice doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets=
 the client to create a request for her using T1, she can copy the signatur=
e from that request onto a new request using T2. Since the signature doesn=
=E2=80=99t cover the token value and the key is the same, the RS should acc=
ept both requests, right?
>>>>>=20
>>>>> An important aspect is that the parts needed to make this attack work=
 are a little weird: you=E2=80=99d need access to a valid signed request fr=
om the client with T1 as well as access to a valid T2 attached to the same =
key in order to make this substitution. However, this is effectively the sa=
me attack area that bearer tokens have in a lot of ways, since it doesn=E2=
=80=99t require the attacker gaining access to the singing key to generate =
or modify a signature, nor does it require the attacker to generate or modi=
fy an access token (merely obtain one).
>>>>>=20
>>>>>=20
>>>>> I=E2=80=99d like to understand if this is an actual attack against DP=
oP. If it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we=
 discuss in the DPoP draft? I didn=E2=80=99t see a mention of it there. If =
it=E2=80=99s not, should we discuss it there?
>>>>>=20
>>>>>=20
>>>>> The old OAuth PoP draft mitigates this attack by putting the access t=
oken itself inside the signature body instead of a second header. Another o=
ption would be to include a hash of the token value (such as OIDC=E2=80=99s=
 =E2=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. W=
ith either of these approaches, Alice having access to T1, T2, and a signed=
 message for T1 does not allow her to use T2 effectively.
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> --=20
>>>> https://danielfett.de
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> ForgeRock values your Privacy__________________________________________=
_____
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg=
ed material for the sole use of the intended recipient(s). Any review, use,=
 distribution or disclosure by others is strictly prohibited.  If you have =
received this communication in error, please notify the sender immediately =
by e-mail and delete the message and any file attachments from your compute=
r. Thank you._______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--=20
ForgeRock values your Privacy 

--Apple-Mail-C4798F38-3AE5-40BD-BF16-8368FD465AA7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I=E2=80=99d be interes=
ted in hearing why people think digital signatures are a good choice for Po=
P. As far as I can tell that choice has not been clearly motivated. 

I have no interest in canon=
icalised HTTP message signing. I don=E2=80=99t think it=E2=80=99s a good id=
ea. 

=E2=80=94 Neil

On 24 Nov 2020, at 23:32=
, Justin Richer <jricher@mit.edu> wrote:

=EF=BB=BFWith the renewed work on HT=
TP Message Signatures[1] in the HTTP WG[2], I think we might have a good av=
enue for this ECDH-with-KDF flavor of message signature in that arena inste=
ad of trying to twist it into DPoP. I think that this signing mechanism wil=
l be a better base for a general PoP effort in OAuth, and I still believe t=
hat this could live alongside DPoP=E2=80=99s more specific focus and intent=
ional limitations. 

 =E2=80=94 Justin


<=
/div>
[2] https://github.com/httpwg/http-extensions/


On Nov 24, 2020, at 4:18 PM, Bri=
an Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrot=
e:

It took me some time to warm to t=
he ECDH based idea but I do think it has a lot of merit. For whatever it's =
worth, I put the idea forth as one potential path forward during the genera=
l PoP interim meeting back in March (https:/=
/datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interi=
m-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf slide 8) but =
the WG consensus was to pursue a  signature style PoP for the current effor=
ts, which was followed not long after by WG adoption of DPoP. I could poten=
tially see an ECDH-style-POP effort making a resurgence in the future. But =
it's fundamentally pretty different.  




=

On Tue, Nov 24, 2020 at 4:03 AM Neil =
Madden <neil.madden@forgerock.com> wrote:
=

I agree with Daniel that I=E2=80=99d be a bit w=
ary of assuming that this could never be exploited. For example, a server-s=
ide web app that signs DPoP proofs on behalf of client-side Javascript (to =
keep the key safe on the server) and reuses the key for different users cou=
ld be a risk. 

<=
div dir=3D"ltr" class=3D"">IMO this is another symptom of the general issue=
 of using signatures for authentication - they are too strong for the job. =
The fact that a signature is equally valid to all parties and at all times =
means you have to be very careful to include enough context in the signatur=
e calculation to ensure all these kinds of attacks are eliminated. And you =
have to ensure that all RSes check the context. 

Contrast that =
to my suggestion to use ECDH [1], which was already immune to such attacks =
by including the access token in the key derivation step. (And in such a wa=
y that requires no additional data on the wire and is almost impossible for=
 the RS not to verify). Even without including the access token in the KDF,=
 the attack could only happen if the client reused its key and the RS reuse=
d a challenge key pair. 

Macaroon access tokens [2] are also im=
mune to this attack, as in that case the constraints that go in the DPoP pr=
oof are directly attached to the access token itself so there is no way to =
reuse them separately. (Interestingly, macaroons have a more direct analogu=
e of DPoP in the form of discharge macaroons. Such discharge macaroons are =
required to be =E2=80=9Cprepared=E2=80=9D before use, which cryptographical=
ly binds them to the equivalent of the access token - so this kind of attac=
k was also considered and addressed there). 

[1]: https://mailarchive.ietf.org/arch/msg/oauth=
/1Zltt75p5taPw0DRmhoKLbavu9s/
[2]:&nbs=
p;https=
://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-acc=
ess-tokens-in-am-7-0/

<=
/div>
=E2=80=94 Neil

On 24 Nov 2020, a=
t 09:38, Daniel Fett <fett@danielfett.de> wrote:

=EF=BB=BF
 =20
   =20
 =20
 =20
    
Thanks Justin for bringing this to our
      attention.

    


    

    
Right now, I don't think that this is a
      big problem and I wasn't able to come up with a way to improve the
      attack. I hope that it doesn't come back to haunt us when somebody
      does a more in-depth analysis...

    


    

    
That said, the lack of binding to the
      access token makes it easier to precompute proofs if somebody has
      a limited code execution opportunity in the client. We have this
      paragraph in the spec:

    


    

    
   Malicious XSS code executed in the
      context of the browser-based

         client application is also in a position to create DPoP =
proofs
      with

         timestamp values in the future and exfiltrate them in
      conjunction

         with a token.  These stolen artifacts can later be =
used
      together

         independent of the client application to access protecte=
d
      resources.

         The impact of such precomputed DPoP proofs can be limite=
d
      somewhat by

         a browser-based client generating and using a new DPoP k=
ey for
      each

         new authorization code grant.

    


    

    
The recommendation could be to use a
      fresh key pair for each token request.

    


    

    
-Daniel

    


    

    


    

    
Am 20.11.20 um 20:26 schrieb Justin
      Richer:

    

    

      
While working on an implementation of DPoP recently, =
I realized that the value of the access token itself is not covered by the =
DPoP signature at all. What I=E2=80=99m wondering is whether or not this co=
nstitutes an attack surface that we care about here. Here=E2=80=99s how it =
works:


Let=E2=80=99s say that a client creates a DPoP key and uses that key to req=
uest two tokens, T1 and T2, for different users, Alice and Bob, respectivel=
y. Alice is malicious and wants to get Bob=E2=80=99s stuff. Alice manages t=
o get a hold of Bob=E2=80=99s token value, T2, through some means. Normally=
 DPoP wouldn=E2=80=99t let Alice create a new request using T2 since Alice =
doesn=E2=80=99t have the client=E2=80=99s key. However, if Alice gets the c=
lient to create a request for her using T1, she can copy the signature from=
 that request onto a new request using T2. Since the signature doesn=E2=80=
=99t cover the token value and the key is the same, the RS should accept bo=
th requests, right?

An important aspect is that the parts needed to make this attack work are a=
 little weird: you=E2=80=99d need access to a valid signed request from the=
 client with T1 as well as access to a valid T2 attached to the same key in=
 order to make this substitution. However, this is effectively the same att=
ack area that bearer tokens have in a lot of ways, since it doesn=E2=80=99t=
 require the attacker gaining access to the singing key to generate or modi=
fy a signature, nor does it require the attacker to generate or modify an a=
ccess token (merely obtain one).


I=E2=80=99d like to understand if this is an actual attack against DPoP. If=
 it isn=E2=80=99t, how is it countered by DPoP today? If it is, do we discu=
ss in the DPoP draft? I didn=E2=80=99t see a mention of it there. If it=E2=
=80=99s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access token i=
tself inside the signature body instead of a second header. Another option =
would be to include a hash of the token value (such as OIDC=E2=80=99s =E2=
=80=9Cat_hash=E2=80=9D method used in ID Tokens) in the DPoP payload. With =
either of these approaches, Alice having access to T1, T2, and a signed mes=
sage for T1 does not allow her to use T2 effectively.

 =E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/oauth


    


    

    
--=20
https://dan=
ielfett.de

 =20

_______________________________________________
OAuth mailing list
OA=
uth@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/oauth



ForgeRock values your=
 Privacy____________________________________________=
___

OAuth mailing list

OAuth@ietf.o=
rg

https://www.ietf.org/mailman/listinfo/oauth






CONFIDENTIALITY NOTICE: =
This email may contain confidential and privileged material for the sole us=
e of the intended recipient(s). Any review, use, distribution or disclosure=
 by others is strictly prohibited.  If you have received this communic=
ation in error, please notify the sender immediately by e-mail and delete t=
he message and any file attachments from your computer. Thank you._______________________________________________
OAut=
h mailing list
O=
Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=





ForgeRock values your Privacy
--Apple-Mail-C4798F38-3AE5-40BD-BF16-8368FD465AA7--


From nobody Fri Nov 27 10:54:17 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38883A0D95 for ; Fri, 27 Nov 2020 10:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKrEh39aday4 for ; Fri, 27 Nov 2020 10:54:14 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26F53A0D89 for ; Fri, 27 Nov 2020 10:54:13 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id t6so8299768lfl.13 for ; Fri, 27 Nov 2020 10:54:13 -0800 (PST)
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=OhgGzJpEPdA7cox5JSZVDyijWB0C0CfIYbhgmjtIg0M=; b=jb2DUWPbqTmPcKgsKbY3ZO3JqXjSBv76HxzXMRnDg4JJS28c1CDPnD5ZUlZq130NVq 5ANxOrb+iH0/gBUA7/2FHR118/vMhs2pn3iRgn4zqrRY6TE21robvlSQaG3QRtZHmqGf RF7dujcoeL5DuF7fZ+ZsJpxIkvR1jnI/vbPPaqKRulQJ/FKvr8XhtA3cNXkZeWHLo244 DUYFPbXXwg6laEjiX3LB+k/prBTQ2M/znS5kc6m3rfvYtzS9TJJ2de8WPmMcbTDDFEVs SKnKambsk9SN7m3ZNt2u1HvuVR+DXYkQtQkddiacGi+5s6/3dKvVgY3+iXRbL3fGYkJ7 1lpQ==
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=OhgGzJpEPdA7cox5JSZVDyijWB0C0CfIYbhgmjtIg0M=; b=OmGdAiLHcIIvdXkqa2lHBD5cazmYLhZDHMequPNEP0niwlonzq2KVSvbfCTTkHsTj4 xN0ZArJvEJ1KeKJff/Xa1E5GVLsJebCC4Sm7SMD2kou25kOI8ZmIGjCMy4ltWEv6FRRS YGMVjDZ8npVQHe4ZiCtRz2e8t4hHwsujQTdXA17IHOED6sP492iu38Ks0kgyqclJqAIr dvrQlTFlUBDbgQnTlpXwYa/3ar7hxKUWoZRIST3Aq12h5ABkdy4Yzh6UNAW+WArCL84W 1rS1lsZe/DRO5dquDsxrCxOuP5tlxn47mHF0Il9OOFTkzuEhYtAfZiRfGG+Ad1fOBZKm dw4g==
X-Gm-Message-State: AOAM530BBne84fftA0kWWQeXvMrvHCXcVZU2qVayXAO2oeyy5QYNTiKa JcVQXLFxMvJzh/MtM1g0TQHdgSFW7VWL4Hdy7QLnBhZptDo=
X-Google-Smtp-Source: ABdhPJyqLUw8c3MhuagmpoA1HtzqWomVBYQMMQaJvriVUCxNgL/LGTdVCz/wtKCW6r3DahdWeMd4M7MhB5FofeQtqnc=
X-Received: by 2002:a19:8405:: with SMTP id g5mr4125931lfd.360.1606503251337;  Fri, 27 Nov 2020 10:54:11 -0800 (PST)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Fri, 27 Nov 2020 13:54:00 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000a064b005b51b2fac"
Archived-At: 
Subject: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
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, 27 Nov 2020 18:54:16 -0000

--000000000000a064b005b51b2fac
Content-Type: text/plain; charset="UTF-8"

All,

This is a reminder that we have an Interim meeting this Monday, Nov 30th @
12:00pm ET, to discuss the latest with the *DPoP *document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

You can find the details of the meeting and the slides here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth

Regards,
 Rifaat & Hannes

--000000000000a064b005b51b2fac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

This is a reminder that we have an=
 Interim meeting=C2=A0this Monday, Nov 30th @ 12:00pm ET, to discuss the la=
test with the DPoP document:

You can find the detai=
ls of the meeting and the slides here:
=

Regards,
=C2=A0Rifaat & Hannes

<=
/div>


--000000000000a064b005b51b2fac--


From nobody Mon Nov 30 07:45:25 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD803A0E03 for ; Mon, 30 Nov 2020 07:45:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6sjN6Pr8T05 for ; Mon, 30 Nov 2020 07:45:21 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBC53A0DFC for ; Mon, 30 Nov 2020 07:45:21 -0800 (PST)
Received: from [192.168.1.11] ([90.91.135.71]) by mwinf5d62 with ME id yflG2300M1Ybo4i03flHfV; Mon, 30 Nov 2020 16:45:17 +0100
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 30 Nov 2020 16:45:17 +0100
X-ME-IP: 90.91.135.71
To: oauth 
References: 
From: Denis 
Message-ID: <1b584adf-14f9-ba2e-657d-f22b57d87675@free.fr>
Date: Mon, 30 Nov 2020 16:45:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4F16CC642ECEB2D669A0A5A0"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
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, 30 Nov 2020 15:45:24 -0000

This is a multi-part message in MIME format.
--------------4F16CC642ECEB2D669A0A5A0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

One comment on slide 5 about the /time window/.

At the bottom, on the left, it is written: "Only valid for a limited 
/time window/ relative to creation time".

While the creation time is defined by "iat", the /time window/ is 
currently left at the discretion of each RS.

It would be preferable to mandate the inclusion in the JWT of the exp 
(Expiration Time) Claim.
In this way, the /time window /would be defined by the AS using both the 
"iat" and the "exp" claims.

This would have the following advantages:

  * The client will know whether a token is still usable and is unlikely
    to get a rejection of the token
    because of an unknown time window defined by a RS.

  * The RS is able to manage better the "jti" claim values, because it
    will be able to discard "jti" claim values
    as soon as they are outside the time window defined by the AS in a JWT.

Denis


> All,
>
> This is a reminder that we have an Interim meeting this Monday, Nov 
> 30th @ 12:00pm ET, to discuss the latest with the *DPoP *document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ 
> 
>
> You can find the details of the meeting and the slides here:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth 
> 
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------4F16CC642ECEB2D669A0A5A0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

      
One comment on slide 5 about the time
            window.

          

          At the bottom, on the left, it is written: "Only valid for a
          limited time
            window relative to creation time".

          

          While the creation time is defined by "iat", the time
            window
          is currently left at the discretion of each
          RS.

          

          It would be preferable to mandate the inclusion in the JWT of
          the exp (Expiration Time) Claim. 

          In this way, the time window would be defined by the
          AS using both the "iat"
          and the "exp" claims.

          

          This would have the following advantages: 

        

      
    
        
  • 
            The client will know whether a token is still usable and is
            unlikely to get
            a rejection of the token 
    
            because of an unknown time window defined by a RS.
    • 
      

      
    
        
  • 
            The RS is able to manage better the "jti" claim values,
            because it will
            be able to discard "jti" claim values 
    
            as soon as they are outside the
            time window defined by the AS in a JWT.
    • 
      

      

          Denis

      

    

    

    

      
      
All,
        


        

        
This is a reminder that we have an Interim meeting this
          Monday, Nov 30th @ 12:00pm ET, to discuss the latest with the
          DPoP document:

        
        


        

        
You can find the details of the meeting and the slides
          here:

        
        


        

        
Regards,

        
 Rifaat & Hannes

        


        

      

      

      

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


    

    


    

  


--------------4F16CC642ECEB2D669A0A5A0--


From nobody Mon Nov 30 08:29:28 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B4D3A0E31 for ; Mon, 30 Nov 2020 08:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niTsbyZjy-wI for ; Mon, 30 Nov 2020 08:29:24 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4203A0E24 for ; Mon, 30 Nov 2020 08:29:24 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id r18so18860885ljc.2 for ; Mon, 30 Nov 2020 08:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=lry4zoq5cRrZ/Fqeg/Ue2Eww/wqQR65STcu5kMZ1XpQ=; b=mRSEZvyQXPvacAY5VqcvVB4otqtL04EsiIOVmp1Ejtxe5LuJdSuLsS0H8ARjRlrBZO fsa+SVCMY8vxQdGaWOFsXgtmTP8/REVzfqKE4xvMqKfTOLbdzJfbFSqZpeBcNdHof0O+ +3W/HWfSH+mzfsBHNEkzJClluNhtwVFFknBOzdxbXY8hn8e25D7ju/oZN0l7WpAA6hJL 3emPOMGZAXHdMneVs1pPvFRJbE655mmA1BHeibkRYRXK5/g4zZMII2KAR1iYGu8TvGq9 XWBANGJafDA/NxTZHxChkL7qjquDst6JGB2heuC24FVSmib53XBmooJX2X4sVO4fuTi5 rTvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lry4zoq5cRrZ/Fqeg/Ue2Eww/wqQR65STcu5kMZ1XpQ=; b=VOJanzpptgLQfuMZt8sP2+9CT1VwfO6sQ19wXSqkyJLLQNZwczDitj4Cgyzbs+ELWH JTzqMuGeeUhV/yncaeFFkZUpwoZfn+Bb+5KovauWh1qmfVqRAd4tQwBCCinrh5ZkUCN7 AAmwr5p8xzyTfjmhIPyTnDLXmS8WrAbjkFKU74gp+orz/+iP9T+UkdHYSKmJnlXeSRQj +tXX78vRZwD2JyZQIU8oFuw6qo5D8xrYNgicjzpVqIMxtEvRJvs2WxDZDB4C7bRKwcPc yD5/Rj31sFdLAOAjjMioCg6fOS1eUyXHk53yGw9yn3oQS3e1LgA0/jCRoM7XmDHe7oKg 2FKg==
X-Gm-Message-State: AOAM532ZLx/9argXPu5ZpPhDkP9OpdqZoErqOhRKOTuMm41vQnfxcfPU L+LqG3z1kS4p5BMl/RZStQqyS6HdI3uHJ0k7cNR22ALBPDU=
X-Google-Smtp-Source: ABdhPJyN1ZAzuWKT5YNgsL/dgLymm43Zzozrz57p9JIyd1kbw6P+NN+pqezYmWQWiIv2xluKn+CpZq9ibo/BYyrN8NM=
X-Received: by 2002:a2e:9793:: with SMTP id y19mr9998402lji.437.1606753761865;  Mon, 30 Nov 2020 08:29:21 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 30 Nov 2020 08:28:45 -0800
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000037bc7305b55583d0"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP Binding JWT proposal
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, 30 Nov 2020 16:29:27 -0000

--00000000000037bc7305b55583d0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Pushing this to the top of the stack in case there is interest in
separating the binding mechanism from the RT / AT so that existing RTs /
ATs can be used.
=E1=90=A7

On Fri, Nov 6, 2020 at 2:12 PM Dick Hardt  wrote:

> Hello
>
> After reviewing the DPoP spec, and reflecting on implementations I have
> worked with, I wanted to see if there was interest in a DPoP Binding JWT.
>
> The use case is to enable existing deployments to add support for DPoP
> without having to replace their existing refresh token and access tokens,
> and the processing of them as the DPoP Binding JWT processing can be adde=
d
> as an independent software layer.
>
> The processing overhead is minimized as the DPoP Binding JWT
> verification can be cached for an access token,
> adding only one JWT verification for the lifetime of the access token.
>
> DPoP Binding JWTs using asymmetric cryptographic algorithms, provide the
> increased security of public / private key for existing deployments using
> access tokens signed with shared secrets such as HMAC.
>
> /Dick
>
>
> *X. DPoP Binding JWT*
>     Deployments that do not want to modify their existing access tokens o=
r
> resource tokens to contain
>     the DPoP thumbprint can include DPoP Binding JWTs in the response fro=
m
> the AS and present them in
>     calls to the RS. A DPoP Binding JWT contains the DPoP thumbprint and =
a
> hash of the access token
>     or refresh token, and is signed by the AS.
>
>     The use of DPoP Binding JWTs enables existing deployments to add
> proof-of-possession assurance to
>     existing deployments by adding a middle layer service or software
> without modifying the processing
>     of refresh tokens or access tokens.
>
>
>
> *X.1 DPoP Binding JWT Syntax*
>     * "typ": type header, value "dpop-binding+jwt"
>
>     * "jti": unique id
>     * "iat": time created
>     * "jkt": JWK SHA-256 Thumbprint of the DPoP public key
>
>     If binding an access token
>         * "ath": SHA-256 hash of the access token
>
>     If binding an refresh token
>         * "rth": SHA-256 hash of the refresh token
>
>     Example DPoP Binding JWT for an access token:
>
>     {
>         "typ":"dpop-binding+jwt",
>         "alg":"ES256",
>         "jwk": {
>         "kty":"EC",
>         "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
>         "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
>         "crv":"P-256"
>         }
>     }.{
>         "jti":"-BwC3ESc6acc2lTc",
>         "iat":1562262616,
>         "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I",
>         "ath":"N0d2HglBV3uiguA4I0ZcOCORZNYy-DWpqq30jZyJGHT"
>     }
>
>
>
> *X.2 Checking DPoP Bindings*
>     Check the DPoP Binding JWT is valid
>     Check the DPoP Binding JWT "jkt" value matches the thumbprint of the
> DPoP public key
>     Check the DPoP Binding JWT "ath" value matches the SHA-256 hash of th=
e
> access token
>       or
>     Check the DPoP Binding JWT "rth" value matches the SHA-256 hash of th=
e
> refresh token
>
>
> *X.3 Token Response*
>     The AS sets the "token_type" parameter to "DPoP-Binding".
>     The AS returns the DPoP Binding JWT for the access token in the
> "access_token_binding" parameter,
>     and the DPoP Binding JWT for the refresh token in the
> "refresh_token_binding" parameter.
>
>      HTTP/1.1 200 OK
>      Content-Type: application/json;charset=3DUTF-8
>      Cache-Control: no-store
>      Pragma: no-cache
>
>      {
>        "access_token":"2YotnFZFEjr1zCsicMWpAA",
>        "access_token_binding":"eyJ0eXAiOiJkcG9w....",
>        "token_type":"DPoP-Binding",
>        "expires_in":3600,
>        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
>        "refresh_token_binding":"eyJ0eXAiOiJkcG9w....."
>        "example_parameter":"example_value"
>      }
>
>
> *X.4 Resource access*
>     The client presents the access token DPoP Binding JWT in the
> "DPoP-Binding" HTTP header.
>
>     GET /protectedresource HTTP/1.1
>     Host: resource.example.org
>     Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6IkJlQUxrYiJ9.eyJzdWI
>         iOiJzb21lb25lQGV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhh=
bX
>         BsZS5jb20iLCJhdWQiOiJodHRwczovL3Jlc291cmNlLmV4YW1wbGUub3JnIiwibmJ=
mI
>         joxNTYyMjYyNjExLCJleHAiOjE1NjIyNjYyMTYsImNuZiI6eyJqa3QiOiIwWmNPQ0=
9S
>         Wk5ZeS1EV3BxcTMwalp5SkdIVE4wZDJIZ2xCVjN1aWd1QTRJIn19.vsFiVqHCyIkB=
Yu
>         50c69bmPJsj8qYlsXfuC6nZcLl8YYRNOhqMuRXu6oSZHe2dGZY0ODNaGg1cg-kVig=
zY
>         hF1MQ
>     DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
>         VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVd=
CR
>         nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1=
JE
>         QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRt=
Ij
>         oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN=
0Z
>         WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCi=
GB
>         NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4UCbQ
>     DPoP-Binding: eyJ_an_example_DPoP_binding_JWT_0eXAiOiJkcG9wK2p3dCIsI
>         VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVd=
CR
>         nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1=
JE
>         QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRt=
Ij
>         oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN=
0Z
>         WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWCi=
GB
>         NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4AUg1JSskfWIyo4UCbQ
>
>
>
> =E1=90=A7
>

--00000000000037bc7305b55583d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Pushing this to the top of the stack in case there is inte=
rest in separating the binding mechanism from the RT / AT so that existing =
RTs / ATs can be used.
3D""=E1=90=A7

On Fri, Nov 6, 2020 =
at 2:12 PM Dick Hardt <dick.hard=
t@gmail.com> wrote:
Hello

After revie=
wing the DPoP spec, and reflecting on implementations I have worked with, I=
 wanted to see if there was interest in a=C2=A0DPoP Binding JWT.
=

The use case is to enable existing deployments to add suppor=
t for DPoP without having to replace their existing refresh token and acces=
s tokens, and the processing of them as the DPoP Binding JWT processing can=
 be added as an independent=C2=A0software layer.=C2=A0

=

The processing overhead is minimized as the DPoP Binding JWT verificat=
ion=C2=A0can be cached for an access token,=C2=A0
adding only one=
 JWT verification for the lifetime of the access token.

DPoP Binding JWTs using asymmetric cryptographic algorithms, provide =
the increased security of public / private key for existing deployments usi=
ng access tokens signed with shared secrets such as HMAC.

/Dick

X. DPoP Binding JWT

=
=C2=A0 =C2=A0 Deployments that do not want to modify their existing access =
tokens or resource tokens to contain 
=C2=A0 =C2=A0 the DPoP thumbprint =
can include DPoP Binding JWTs in the response from the AS and present them =
in 
=C2=A0 =C2=A0 calls to the RS. A DPoP Binding JWT contains the DPoP =
thumbprint and a hash of the access token
=C2=A0 =C2=A0 or refresh token=
, and is signed by the AS. 

=C2=A0 =C2=A0 The use of DPoP Binding JW=
Ts enables existing deployments to add proof-of-possession assurance to =C2=A0 =C2=A0 existing deployments by adding a middle layer service or sof=
tware without modifying the processing
=C2=A0 =C2=A0 of refresh tokens o=
r access tokens.


X.1 DPoP Binding JWT Syntax

=C2=
=A0 =C2=A0 * "typ": type header, value "dpop-binding+jwt&quo=
t; 

=C2=A0 =C2=A0 * "jti": unique id
=C2=A0 =C2=A0 * &q=
uot;iat": time created
=C2=A0 =C2=A0 * "jkt": JWK SHA-256=
 Thumbprint of the DPoP public key 

=C2=A0 =C2=A0 If binding an acce=
ss token
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * "ath": SHA-256 hash of =
the access token

=C2=A0 =C2=A0 If binding an refresh token
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 * "rth": SHA-256 hash of the refresh token<=
br>
=C2=A0 =C2=A0 Example DPoP Binding=C2=A0JWT for an access token:
=

=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "typ":"dp=
op-binding+jwt",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "alg":"=
ES256",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "jwk": {
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "kty":"EC",
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs&=
quot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "y":"9VE4jf_Ok_o64zbTT=
lcuNJajHmt6v9TDVrU0CdvGRDA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "crv&=
quot;:"P-256"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }=
.{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "jti":"-BwC3ESc6acc2lTc&qu=
ot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "iat":1562262616,
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2Hg=
lBV3uiguA4I",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ath":"N0d=
2HglBV3uiguA4I0ZcOCORZNYy-DWpqq30jZyJGHT"
=C2=A0 =C2=A0 }

X.2 Checking DPoP Bindings

=C2=A0 =C2=A0 Check the DPoP Bin=
ding JWT is valid
=C2=A0 =C2=A0 Check the DPoP Binding JWT "jkt&quo=
t; value matches the thumbprint of the DPoP public key
=C2=A0 =C2=A0 Che=
ck the DPoP Binding JWT "ath" value matches the SHA-256 hash of t=
he access token
=C2=A0 =C2=A0 =C2=A0 or
=C2=A0 =C2=
=A0 Check the DPoP Binding JWT "rth" value matches the SHA-256 ha=
sh of the refresh token

X.3 Token Response
=C2=A0 =C2=A0 The AS sets the "token_type" parameter to "D=
PoP-Binding". 
=C2=A0 =C2=A0 The AS returns the DPoP Binding JWT fo=
r the access token in the "access_token_binding" parameter, 
=
=C2=A0 =C2=A0 and the DPoP Binding JWT for the refresh token in the "r=
efresh_token_binding" parameter.

=C2=A0 =C2=A0 =C2=A0HTTP/1.1 2=
00 OK
=C2=A0 =C2=A0 =C2=A0Content-Type: application/json;charset=3DUTF-8=

=C2=A0 =C2=A0 =C2=A0Cache-Control: no-store
=C2=A0 =C2=A0 =C2=A0Prag=
ma: no-cache

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0&qu=
ot;access_token":"2YotnFZFEjr1zCsicMWpAA",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0"access_token_binding":"eyJ0eXAiOiJkcG9w....&qu=
ot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0"token_type":"DPoP-Bindin=
g",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"expires_in":3600,
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0"refresh_token":"tGzv3JOkF0XG5Qx2TlK=
WIA"
=C2=A0 =C2=A0 =C2=A0 =C2=A0"refresh_token_binding":&=
quot;eyJ0eXAiOiJkcG9w....."
=C2=A0 =C2=A0 =C2=A0 =C2=A0"exampl=
e_parameter":"example_value"
=C2=A0 =C2=A0 =C2=A0}
X.4 Resource access

=C2=A0 =C2=A0 The client presents the ac=
cess token DPoP Binding JWT in the "DPoP-Binding" HTTP header.
=C2=A0 =C2=A0 GET /protectedresource HTTP/1.1
=C2=A0 =C2=A0 Host: <=
a href=3D"http://resource.example.org" target=3D"_blank">resource.example.o=
rg
=C2=A0 =C2=A0 Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6IkJ=
lQUxrYiJ9.eyJzdWI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 iOiJzb21lb25lQGV4YW1wbGUuY=
29tIiwiaXNzIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbX
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bs=
ZS5jb20iLCJhdWQiOiJodHRwczovL3Jlc291cmNlLmV4YW1wbGUub3JnIiwibmJmI
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 joxNTYyMjYyNjExLCJleHAiOjE1NjIyNjYyMTYsImNuZiI6eyJqa3=
QiOiIwWmNPQ09S
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Wk5ZeS1EV3BxcTMwalp5SkdIVE4wZ=
DJIZ2xCVjN1aWd1QTRJIn19.vsFiVqHCyIkBYu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 50c69=
bmPJsj8qYlsXfuC6nZcLl8YYRNOhqMuRXu6oSZHe2dGZY0ODNaGg1cg-kVigzY
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 hF1MQ
=C2=A0 =C2=A0 DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsI=
mFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VDIiwi=
eCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWcl=
UwQ2R2R1JE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QSIsImNydiI6IlAtMjU2In19.eyJqdGki=
OiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oiR0VUIiw=
iaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E7=
4kWCiGB
=C2=A0 =C2=A0 =C2=A0 =C2=A0 NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-u=
yUI4AUg1JSskfWIyo4UCbQ
=C2=A0 =C2=A0 DPoP-Binding: eyJ_an_example_DPoP_b=
inding_JWT_0eXAiOiJkcG9wK2p3dCIsI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VDIiwieCI6=
Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2=
R2R1JE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJl=
MWozVl9iS2ljOC1MQUVCIiwiaHRtIj
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oiR0VUIiwiaHR=
1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOH0.lNhmpAX1WwmpBvwhok4E74kWC=
iGB
=C2=A0 =C2=A0 =C2=A0 =C2=A0 NdavjLAeevGy32H3dbF0Jbri69Nm2ukkwb-uyUI4=
AUg1JSskfWIyo4UCbQ



3D""=E1=90=A7




--00000000000037bc7305b55583d0--


From nobody Mon Nov 30 08:49:56 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C663A0E99 for ; Mon, 30 Nov 2020 08:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whNFbexLS1Mp for ; Mon, 30 Nov 2020 08:49:53 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 CA1123A0EBF for ; Mon, 30 Nov 2020 08:49:52 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id v14so22919845lfo.3 for ; Mon, 30 Nov 2020 08:49:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NY2m/7r+rTNMp5dI1Lvy/NglcupZGJDrbveZGcRXsoo=; b=b/61fmNUBmUhW4MVBUrvpxelLSnYs7rFcSBY+49E2ysSZ052PPJ3f/whBExZ9PRv0N Cp0L97H+jw5axqZlkBR3FBrvStw2kiCZP4EH6ZCFZMl12siEPyBohFOh6pGc267e2ok9 zh202a9h1aEZHuO4Tr/j/Gq78igiwXg1NN3ZxdlasIEZnIr2FR8pS8q0mdLYfTDmfNnK z83mbJiN2TAp+Tpxa2gLQ//VPvJeBb0gzDgdCdpstOfW1Heq1t/EsuwfYGG+5hqVSthD AK6nlXPqXl7i8D4GIK2o+7kIjg+vlZm2SrgVRK09zjhnXgacwSqVbFxNorCf63WqViOI aqug==
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=NY2m/7r+rTNMp5dI1Lvy/NglcupZGJDrbveZGcRXsoo=; b=Zlzg2Rgho3xvtNTnxLXpHhrvRnXtk1pVGnqGvGaOM7snu2Ymug43ubXnEcU1Spt0b/ K2qVsCNmZLZgbPDLUCTiQQ01sB+e/FbAgc6eVI8F3LzkD5CXQddNsF7C3F4Qucd3kYr5 /bKye5R2/xCKXCLMIaXQ+GKg5a2ChcpAMKNsH1vSqru6FvGgd8VU1BWZymya/IkuC1Z2 vCtk96NKeYYEuQZx9uuPc96dSvaDuWTx+rDcAa2m9BcHMlRTNlUdsyYPUATSyAG1/Fpi 0a459e4VYl11KGC1ydLPm71MptCOTzjqqKgQo4lprr5HlfbzzmAYyR+ditIKdrsa5Y5A iJRA==
X-Gm-Message-State: AOAM533uyiCZFdoL4YfFwPZ6mxVXjZempWlw0QwP2Hiogvi9OBbofyZJ j4l0/6w80n7vBD00cIRoOebatbq4ZE1H3eauztdhUIfl6Sq7RzOVLiSDTLFSU9TGvYxt1+UEEEB vLrZAPbPhZbHGag==
X-Google-Smtp-Source: ABdhPJxlXtuB9+RNuU6kxqJl6Z2aJ7gpbTH6ADsTkW3hlVQVu2PTTQexg3EW8HuYw8vntzhDih7/WdO/4rkj1wyhbJs=
X-Received: by 2002:a19:5215:: with SMTP id m21mr7291908lfb.407.1606754990983;  Mon, 30 Nov 2020 08:49:50 -0800 (PST)
MIME-Version: 1.0
References:  <1b584adf-14f9-ba2e-657d-f22b57d87675@free.fr>
In-Reply-To: <1b584adf-14f9-ba2e-657d-f22b57d87675@free.fr>
From: Brian Campbell 
Date: Mon, 30 Nov 2020 09:49:24 -0700
Message-ID: 
To: Denis 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000007ab25f05b555ccf4"
Archived-At: 
Subject: Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
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, 30 Nov 2020 16:49:55 -0000

--0000000000007ab25f05b555ccf4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

The choice to use "iat" vs. "exp" was made in the summer of last year. You
can see some of the discussion from then in
https://github.com/danielfett/draft-dpop/issues/38. I believe it pretty
well has consensus at this point and thus unlikely to be changed.

While I do believe there are reasonable arguments that can be made on both
sides of using either of "iat" or "exp", it's difficult (and honestly time
consuming and very frustrating) to try and have such discussions or even
respond in a coherent way when fundamental aspects of the draft are
misrepresented or misunderstood. For example, the DPoP proof JWT is created
by the client not the AS so the advantages you put forward are nonsensical
in the context of the actual workings of the draft.





On Mon, Nov 30, 2020 at 8:45 AM Denis  wrote:

> One comment on slide 5 about the *time window*.
>
> At the bottom, on the left, it is written: "Only valid for a limited *tim=
e
> window* relative to creation time".
>
> While the creation time is defined by "iat", the *time window* is
> currently left at the discretion of each RS.
>
> It would be preferable to mandate the inclusion in the JWT of the exp
> (Expiration Time) Claim.
> In this way, the *time window *would be defined by the AS using both the
> "iat" and the "exp" claims.
>
> This would have the following advantages:
>
>    - The client will know whether a token is still usable and is unlikely
>    to get a rejection of the token
>    because of an unknown time window defined by a RS.
>
>
>    - The RS is able to manage better the "jti" claim values, because it
>    will be able to discard "jti" claim values
>    as soon as they are outside the time window defined by the AS in a JWT=
.
>
> Denis
>
> All,
>
> This is a reminder that we have an Interim meeting this Monday, Nov 30th =
@
> 12:00pm ET, to discuss the latest with the *DPoP *document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
> You can find the details of the meeting and the slides here:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> _______________________________________________
> 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._

--0000000000007ab25f05b555ccf4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


Hi Denis, 

The choice to=
 use "iat" vs.  "exp" was made in the summer of last ye=
ar. You can see some of the discussion from then in https://github.co=
m/danielfett/draft-dpop/issues/38. I believe it pretty well has consens=
us at this point and thus unlikely to be changed. 

=

While I do believe there are reasonable arguments that can be made on =
both sides of using either of "iat" or  "exp", it's=
 difficult (and honestly time consuming and very frustrating) to try and ha=
ve such discussions or even respond in a coherent way when fundamental aspe=
cts of the draft are misrepresented or misunderstood. For example, the DPoP=
 proof JWT is created by the client not the AS so the advantages you put forward are nonsensical in t=
he context of the actual workings of the draft. 

<=
/div>




On Mon, Nov 30, 2020 at 8=
:45 AM Denis <de=
nis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    

    

      
One comment on slide 5 about the time
            window.

          

          At the bottom, on the left, it is written: "Only valid for a
          limited time
            window relative to creation time".

          

          While the creation time is defined by "iat", the tim=
e
            window
          is currently left at the discretion of each
          RS.

          

          It would be preferable to mandate the inclusion in the JWT of
          the exp (Expiration Time) Claim. 

          In this way, the time window would be defined by the
          AS using both the "iat"
          and the "exp" claims.

          

          This would have the following advantages: 

        

      
    
        
  • 
            The client will know whether a token is still usable and is
            unlikely to get
            a rejection of the token 
    
            because of an unknown time window defined by a RS.
    • 
      

      
    
        
  • 
            The RS is able to manage better the "jti" claim value=
s,
            because it will
            be able to discard "jti" claim values 
    
            as soon as they are outside the
            time window defined by the AS in a JWT.
    • 
      

      

          Denis

      

    

    

    

     =20
      
All,
        


        

        
This is a reminder that we have an Interim meeting=C2=A0this
          Monday, Nov 30th @ 12:00pm ET, to discuss the latest with the
          DPoP document:

        
        


        

        
You can find the details of the meeting and the slides
          here:

        
        


        

        
Regards,

        
=C2=A0Rifaat & Hannes

        


        

      

      

      

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


    

    


    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000007ab25f05b555ccf4--


From nobody Mon Nov 30 15:14:48 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480963A1257 for ; Mon, 30 Nov 2020 15:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc4bXcsxoI-m for ; Mon, 30 Nov 2020 15:14:44 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4792E3A1254 for ; Mon, 30 Nov 2020 15:14:44 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id o24so20820036ljj.6 for ; Mon, 30 Nov 2020 15:14:44 -0800 (PST)
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=+c3IdqTzZUxJYDxA29jXBE8+HmHRPTssAgiE/Xv7wP0=; b=dRbQFcEBdf1I3lHZNsNlExN06tT4qziMiT5XlQh2ht5wbnfXD00b2s/Jl8cblYQoZk 9H0MarLcXF7xs4SEEgyvzFVQ6ROE5o7JBGoc67mY4dcwtIp0PAm+PVFfol6Zv5wSgZ7Z 0FbY7B8Blx/hKUmsT6jyFeRlX2jzY0Jfzof7OrT54ILDjLZSwexCn/r29ojPujBYesx/ 4DgZgYhwSDqw51/2Ao5ZfhnvEQRF46Kr72RmHov9iW3USJTmQhzjIGDUg+MhDZGEA+PT a8ubcFI+WUMYcqON8lPhcrCf2GemFnyxrLUVSldJM5yE7xdoUuAbUaOMxDY8umPQofP4 KNDA==
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=+c3IdqTzZUxJYDxA29jXBE8+HmHRPTssAgiE/Xv7wP0=; b=ihQi03y+mvJOurNgNY1jM8qCv+x6AqilZ87m2AqEJ7xrk3pIwlBuhm3ZtP92tqUsnb 4kCWm4ofgpta9zamTSnlMTMUH2on0M4xnbkl2xBoAbM+aBN1yUTK1mOUSufN5I4krMW4 1W2KE0ReYapRZgM3qMXMjA1NCdXuMrFxrQntmVebNjPNb78ch5j8EjGlTKEyfQ4ciYnD e2pyQQfdwh8dFFXsvGuHLBoALHdV6/w3Ax4z035ziZAzxE/3JU+hzq944U4gR7K9HNeO 9DVowMgu4glya+WXwA57j/bPLJ1HYqEuqmc9NNpDTwdeb+uZjYGMKq2u7lsgAk/Erj2L 1mpg==
X-Gm-Message-State: AOAM530Sxsm6zKRjyWddb8unMmz7loKP5gLifoPoezcTEC8O+P5J55zc A7wuS6u7zcezSAfnuV0V0ktmROvUUz08TUClqfenRP2gmUo=
X-Google-Smtp-Source: ABdhPJz8iIXBdRmLJaNYFRmtXyZUJK+tse408lefp03TuSPzClKYeUva+wTzCvY6pB7+/MDAszRwHLX9yYp2SzeSwok=
X-Received: by 2002:a2e:86c8:: with SMTP id n8mr12177911ljj.258.1606778082141;  Mon, 30 Nov 2020 15:14:42 -0800 (PST)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 30 Nov 2020 18:14:31 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000d1a98205b55b2c51"
Archived-At: 
Subject: [OAUTH-WG] DPoP Interim Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Nov 2020 23:14:46 -0000

--000000000000d1a98205b55b2c51
Content-Type: text/plain; charset="UTF-8"

All,

You can find the minutes of the *DPoP* meeting here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/minutes-interim-2020-oauth-16-202011301200-01
and here:
https://codimd.ietf.org/notes-ietf-interim-2020-oauth-16-oauth?view

Thanks to *Dick Hardt* for taking these notes.

Regards,
 Rifaat & Hannes

--000000000000d1a98205b55b2c51
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

You can find the minutes of the DPoP meeting here:
and he=
re:

Thanks to Dick Hardt fo=
r taking these notes.

Regards,
=C2=A0Rif=
aat & Hannes


--000000000000d1a98205b55b2c51--


From nobody Mon Nov 30 18:10:50 2020
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440F23A03F2 for ; Mon, 30 Nov 2020 18:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.54
X-Spam-Level: 
X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV5UgKvaiZVq for ; Mon, 30 Nov 2020 18:10:48 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6093A03F1 for ; Mon, 30 Nov 2020 18:10:47 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id y7so106628lji.8 for ; Mon, 30 Nov 2020 18:10:47 -0800 (PST)
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=+Lo9QUWMsYAtpfLxj+cpgNbRpU1Wl6qce5UjHVwvr3c=; b=JsWIcD3QWusnoHmThpaWVnJ/S2qj6lhyA3ZUXAoY2Y/4NiVXwlUsXLbP0UiiWARa7l a9IDK2wNJDOIwcCtUQQ2D4zUXKRWcjazEmzO1aWLdRZxxHizBis8Bu1lAVk3dhPCX/f8 F3YMlpGP79GLhhxEjNtjyRq5RMlDFGmnu9J/pI2uv1cM9Sp/6qg0Fvrgdg9sCw0+qE/s zFQK30VlXEdcP2X92SVIbvuxQwSozaqrymeId3Yyd+66F+QnrZP0dYD2vEYgxh4Ubt9y gzo9QM0R0aAKPWFADEnYrSWBWaIFCt+AXrR0tPMyOX5wLxYq6eTe7E/x/BuNP4UVCliD rdOQ==
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=+Lo9QUWMsYAtpfLxj+cpgNbRpU1Wl6qce5UjHVwvr3c=; b=seUdca890CSTYBwOSD0d7r0S5mCWSExA5Zes2bzTxGjSJm0USakisFrUYJiqo3yjOs UHM3QfAn9Kyl8EJLlTwdEy/SIrsE9V6HNy90jVWlIylBDAK/AKlhrRf9x+9HfkQQ8ud+ rGOmTPO5Dm9j6KWQ3KIb6Ws8Q+tixYE+ywtNuqDcHH7CVjfYElqGQlGvtU8Z92x8n+p3 R81l+TVkb4Uf/RCghfWnq9AmiQxvZhQTocJrN3Ly6R+kzYePKtxjtiQpJGGyJIiE1e3J kdH0Vj90ObZTRc0ZU7GOKNKAYLEIeXINYVP6MgvZfwRN+ffKOcRCj516j4NaHwk1UHa5 s7tQ==
X-Gm-Message-State: AOAM533yKWoOKheEAhgbDzLtHGDbMGyVzUUASzG/70m4Lr3fL1o/fA+q XtB1nxWU32JEy/d7YNmyhSjBSgivnETLhmm6e2o=
X-Google-Smtp-Source: ABdhPJzF0T35wOj/59CTRUwAo7oyXxb5NLECwSpewOYeMmMKF6zo0cO02WSwV7VjOEDYcgRiLuxkbP7I6g6WFbCWjXQ=
X-Received: by 2002:a2e:b4d1:: with SMTP id r17mr239013ljm.246.1606788645675;  Mon, 30 Nov 2020 18:10:45 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 30 Nov 2020 18:10:09 -0800
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000007466cc05b55da243"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP Interim Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Dec 2020 02:10:49 -0000

--0000000000007466cc05b55da243
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks to those addressing the points I missed during the meeting!
=E1=90=A7

On Mon, Nov 30, 2020 at 3:15 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> You can find the minutes of the *DPoP* meeting here:
>
> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/minu=
tes-interim-2020-oauth-16-202011301200-01
> and here:
> https://codimd.ietf.org/notes-ietf-interim-2020-oauth-16-oauth?view
>
> Thanks to *Dick Hardt* for taking these notes.
>
> Regards,
>  Rifaat & Hannes
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000007466cc05b55da243
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks to those addressing the points I missed during the =
meeting!
3D""=E1=90=A7

On Mon, Nov 30, 2020 at 3:15 PM Rif=
aat Shekh-Yusef <rifaat.s.iet=
f@gmail.com> wrote:
Thanks to Dick Hardt for taking these notes.
<=
div>
Regards,
=C2=A0Rifaat & Hannes


--0000000000007466cc05b55da243--