From nobody Thu Nov 1 00:04:58 2018 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 51AEE1276D0; Thu, 1 Nov 2018 00:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 o5twtCPWMJ6K; Thu, 1 Nov 2018 00:04:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297B0124D68; Thu, 1 Nov 2018 00:04:52 -0700 (PDT) Received: from Jude (218.148.84.253) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 1 Nov 2018 00:00:00 -0700 From: Jim Schaad To: 'Mike Jones' , CC: 'oauth' References: <04d301d4712f$08bf8dc0$1a3ea940$@augustcellars.com> In-Reply-To: Date: Thu, 1 Nov 2018 16:04:42 +0900 Message-ID: <04e401d471b1$2c1bb370$84531a50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E5_01D471FC.9C050920" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG+Jyd7cNHtotn1TdAHg2LX3dwhKAHw+6ukpVeI3RA= Content-Language: en-us X-Originating-IP: [218.148.84.253] Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 07:04:57 -0000 ------=_NextPart_000_04E5_01D471FC.9C050920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ok - I'll ask the questions explicitly. What additional features do you get from the claims that are already defined for a JWT. How do these features relate to the original problem statement of needing encryption and origination? Why are these not features that should be in the base OAuth design and thus part of the OAuth registry? Jim From: Mike Jones Sent: Wednesday, October 31, 2018 9:18 AM To: Jim Schaad ; draft-ietf-oauth-jwsreq@ietf.org Cc: 'oauth' Subject: RE: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq JWT defines a number of standard claims that are used in this application, including "iss" (issuer), "aud" (audience), etc. Making the requests a JWT allows code reuse, rather than having an application-specific signed request representation that has many of the semantics and fields of a JWT anyway. It's also worth noting that this practice has been a standard since 2014. OpenID Connect Core standardized the OAuth signed request format in https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests. The draft-ietf-oauth-jwsreq spec is the OAuth-only version of this already standard and deployed practice. (There's other precedents for OAuth subsetting standard OpenID Connect functionality. For instance, RFC 8414 is the OAuth-specific subset of the metadata format defined by OpenID Connect Discovery .) -- Mike -----Original Message----- From: OAuth > On Behalf Of Jim Schaad Sent: Wednesday, October 31, 2018 8:33 AM To: draft-ietf-oauth-jwsreq@ietf.org Cc: 'oauth' > Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq As part of looking at the issues of using CWTs for this purpose I did some more reading of the document. I am having a problem with the understanding the reasons for using JWT as opposed to just saying that you are going to use JWS and JWE. There is nothing in this section that I can see that points to a reason to be using JWTs as the carrier. What am I missing? Jim _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_04E5_01D471FC.9C050920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok – I’ll ask the questions = explicitly.

 

What additional features do you get from the claims = that are already defined for a JWT. 

 

How do these = features relate to the original problem statement of needing encryption = and origination?

 

Why are = these not features that should be in the base OAuth design and thus part = of the OAuth registry?

 

Jim

 

 

From: Mike = Jones <Michael.Jones@microsoft.com>
Sent: Wednesday, = October 31, 2018 9:18 AM
To: Jim Schaad = <ietf@augustcellars.com>; = draft-ietf-oauth-jwsreq@ietf.org
Cc: 'oauth' = <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Mail regarding = draft-ietf-oauth-jwsreq

 

JWT = defines a number of standard claims that are used in this application, = including "iss" (issuer), "aud" (audience), = etc.  Making the requests a JWT allows code reuse, rather than = having an application-specific signed request representation that has = many of the semantics and fields of a JWT anyway.

 

It's = also worth noting that this practice has been a standard since 2014. =  OpenID Connect Core standardized the OAuth signed request format = in https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests.&= nbsp; The draft-iet= f-oauth-jwsreq spec is the OAuth-only version of this already = standard and deployed practice.  (There's other precedents for = OAuth subsetting standard OpenID Connect functionality.  For = instance, RFC 8414 = is the OAuth-specific subset of the metadata format defined by OpenI= D Connect Discovery.)

 

        &nbs= p;            = ;            =             &= nbsp;         -- = Mike

 

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On = Behalf Of Jim Schaad
Sent: Wednesday, October 31, 2018 8:33 AM
To: = draft-ietf-oauth-jwsreq@= ietf.org
Cc: 'oauth' <oauth@ietf.org>
Subject: = [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq

 

As = part of looking at the issues of using CWTs for this purpose I did some = more reading of the document.  I am having a problem with the = understanding the reasons for using JWT as opposed to just saying that = you are going to use JWS and JWE.  There is nothing in this section = that I can see that points to a reason to be using JWTs as the = carrier.  What am I missing?

 

Jim

 

 

_______________________________________________=

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oaut= h

------=_NextPart_000_04E5_01D471FC.9C050920-- From nobody Thu Nov 1 05:45:47 2018 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 0FDBD126DBF for ; Thu, 1 Nov 2018 05:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 r2FhW4wIfA38 for ; Thu, 1 Nov 2018 05:45:41 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 DBD8212D4F1 for ; Thu, 1 Nov 2018 05:45:40 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id d10-v6so19964239wrs.5 for ; Thu, 01 Nov 2018 05:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N60qlvLy+4YQTSZZrmlX9x6K+ed+YRyyjCzmTn/odIg=; b=ONebYo6epv8oayOoq1vq/WfvGX8eeupq6dSvS/iuafq7E3AT7Mvyew9L22KtwaNbwn kJW9rulukcjrkRt48uLlenwWREUF5SaV9s3HoFv+2ZhjUwhlGXGq6QH0B/S7L4S+ziLQ MYJZKHDWbQIIgtfkzkW/+lq6BlTn8PQkaaETiz8LLb0l5TCcfDBa5jp/072MjWB5WAWn N60MMw/LhRvomz/F1N0yetzCUEe2mjGpSoJyOYhJtZOH0UEcZ3Zdhi8/kMOE0wUeu6nC nLxx+23EsJuZ58TNknvg6Ayb1IzI//nbkiiIwXAUxHzi6RaGxgt0w8BCLj3t7FtSln9r 5hyA== 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=N60qlvLy+4YQTSZZrmlX9x6K+ed+YRyyjCzmTn/odIg=; b=gOCLXRf3TPRmgAOGuY+hKOmgTB1QU/bAIkpeHa6lgjyhTNGs6yU011TOZT/AKiawN/ tjOgoJMAdc5tv00+LhSvTodgPVKkpnQYYIiG63itLy3xpAZaQVLbXpfugmEhkjeklve0 ASX+waVVxmcVZdVUQLZecbeGhCdJ6dVAaPBhL9gWhJcp9U2g5g3p/pSZ45cjJSzp6byb PTJgd1jsCyNlC2owElYIKJDvLmucMudr4aQrnB8I28t70iBdzcb7iutYraV742fwdYhW D21BKIDRqyC1/XdgaY6nxPLuUxjog+aDIUQBG1W6PZiJ/5a5CFOOaWm0j0RP39PdMu0k 6VAg== X-Gm-Message-State: AGRZ1gJ9NGDEYm51TZprPs3NFIczq+0vsY4yNjNGjGsxeg0fLe9DcseW d07eNH/oCcEUGoCVaQAgm49QRlphXAKOFxY+y3Em/g== X-Google-Smtp-Source: AJdET5frSWiEFSLWp15lHo7a0eXMoXdN6WINfPUpVCdevCdoAKnlZTDgc2rtTuNEAbuFSyODjkjT4qQTe5den+5wKgI= X-Received: by 2002:adf:ce06:: with SMTP id p6-v6mr6877552wrn.324.1541076338383; Thu, 01 Nov 2018 05:45:38 -0700 (PDT) MIME-Version: 1.0 References: <04d301d4712f$08bf8dc0$1a3ea940$@augustcellars.com> <04e401d471b1$2c1bb370$84531a50$@augustcellars.com> In-Reply-To: <04e401d471b1$2c1bb370$84531a50$@augustcellars.com> From: John Bradley Date: Thu, 1 Nov 2018 09:45:23 -0300 Message-ID: To: Jim Schaad Cc: Michael Jones , draft-ietf-oauth-jwsreq@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000b8bb4c057999cba2" Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 12:45:44 -0000 --000000000000b8bb4c057999cba2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The JWT was done by the OAuth WG. Some wanted it to be core to OAuth and others wanted it to be entirely optional so that people would not feel obligated to use it for access tokens. JWT is used in a number of OAuth specs now and provides consistency for some common elements like issuer , audience, and expiery. Yes we could have started from JWS and redefined those elements but would then need another IANA registry. Perhaps I am not understanding what you are getting at. John B. On Thu, Nov 1, 2018, 4:04 AM Jim Schaad Ok =E2=80=93 I=E2=80=99ll ask the questions explicitly. > > > > What additional features do you get from the claims that are already > defined for a JWT. > > > > How do these features relate to the original problem statement of needing > encryption and origination? > > > > Why are these not features that should be in the base OAuth design and > thus part of the OAuth registry? > > > > Jim > > > > > > *From:* Mike Jones > *Sent:* Wednesday, October 31, 2018 9:18 AM > *To:* Jim Schaad ; > draft-ietf-oauth-jwsreq@ietf.org > *Cc:* 'oauth' > *Subject:* RE: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq > > > > JWT defines a number of standard claims that are used in this application= , > including "iss" (issuer), "aud" (audience), etc. Making the requests a J= WT > allows code reuse, rather than having an application-specific signed > request representation that has many of the semantics and fields of a JWT > anyway. > > > > It's also worth noting that this practice has been a standard since 2014. > OpenID Connect Core standardized the OAuth signed request format in > https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests. The > draft-ietf-oauth-jwsreq > spec is the > OAuth-only version of this already standard and deployed practice. > (There's other precedents for OAuth subsetting standard OpenID Connect > functionality. For instance, RFC 8414 > is the OAuth-specific subset of the > metadata format defined by OpenID Connect Discovery > .) > > > > -- Mike > > > > -----Original Message----- > From: OAuth On Behalf Of Jim Schaad > Sent: Wednesday, October 31, 2018 8:33 AM > To: draft-ietf-oauth-jwsreq@ietf.org > Cc: 'oauth' > Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq > > > > As part of looking at the issues of using CWTs for this purpose I did som= e > more reading of the document. I am having a problem with the understandi= ng > the reasons for using JWT as opposed to just saying that you are going to > use JWS and JWE. There is nothing in this section that I can see that > points to a reason to be using JWTs as the carrier. What am I missing? > > > > Jim > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b8bb4c057999cba2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The JWT was done by the OAuth WG.

Some wanted it to be core to OAuth and oth= ers wanted it to be entirely optional so that people would not feel obligat= ed to use it for access tokens.=C2=A0=C2=A0

JWT is used in a number of OAuth specs now and provides= consistency for some common elements like issuer , audience, and expiery.<= /div>

Yes we could have starte= d from JWS and redefined those elements but would then need another IANA re= gistry.=C2=A0=C2=A0

Perh= aps I am not understanding what you are getting at.=C2=A0

John B.=C2=A0

=
On Thu, Nov 1,= 2018, 4:04 AM Jim Schaad <iet= f@augustcellars.com wrote:

Ok =E2=80=93 I=E2=80=99ll = ask the questions explicitly.

=C2=A0

What additional features do you g= et from the claims that are already defined for a JWT.=C2=A0 =

=C2=A0

H= ow do these features relate to the original problem statement of needing en= cryption and origination?

= =C2=A0

Why are these not features that sho= uld be in the base OAuth design and thus part of the OAuth registry?=

=C2=A0

Jim

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

From: Mike Jones <Michael.Jones@microsoft= .com>
Sent: Wednesday, October 31, 2018 9:18 AM
To:= Jim Schaad <ietf@augustcellars.com>; draft= -ietf-oauth-jwsreq@ietf.org
Cc: 'oauth' <oauth@ietf.= org>
Subject: RE: [OAUTH-WG] Mail regarding draft-ietf-oau= th-jwsreq

=C2=A0=

JWT defines a nu= mber of standard claims that are used in this application, including "= iss" (issuer), "aud" (audience), etc.=C2=A0 Making the reque= sts a JWT allows code reuse, rather than having an application-specific sig= ned request representation that has many of the semantics and fields of a J= WT anyway.

=C2=A0

It= 's also worth noting that this practice has been a standard since 2014.= =C2=A0 OpenID Connect Core standardized the OAuth signed request format in = https://openid.net/specs/openid-con= nect-core-1_0.html#JWTRequests.=C2=A0 The = draft-ietf-oauth-jwsreq spec is the OAuth-only version of this already = standard and deployed practice.=C2=A0 (There's other precedents for OAu= th subsetting standard OpenID Connect functionality.=C2=A0 For instance, RFC 8414 is the OAuth-specific subset of the metadata format de= fined by OpenID Connect Discovery.)=

=C2= =A0

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 -- Mike

=C2=A0

-----Original Message-----
From: OAuth <oauth-bounces@iet= f.org> On Behalf Of Jim Schaad
Sent: Wednesday, October 31, 2018 = 8:33 AM
To: draft-ietf-oauth-jwsreq@ietf.org
Cc: = 'oauth' <oauth@ietf.org>
Subject: [OAUTH-WG] Mail regardin= g draft-ietf-oauth-jwsreq

=C2=A0

As part of looking at the issues of using CWTs for this purpos= e I did some more reading of the document.=C2=A0 I am having a problem with= the understanding the reasons for using JWT as opposed to just saying that= you are going to use JWS and JWE.=C2=A0 There is nothing in this section t= hat I can see that points to a reason to be using JWTs as the carrier.=C2= =A0 What am I missing?

=C2=A0

Jim

=C2=A0

=C2=A0

__= _____________________________________________

OAuth mailing list

OAuth@ietf.org

h= ttps://www.ietf.org/mailman/listinfo/oauth

--000000000000b8bb4c057999cba2-- From nobody Thu Nov 1 07:37:41 2018 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 95DC4124D68 for ; Thu, 1 Nov 2018 07:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 mPybyksxmiWG for ; Thu, 1 Nov 2018 07:37:38 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0: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 B07D9124BAA for ; Thu, 1 Nov 2018 07:37:38 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id p64-v6so2313519itp.0 for ; Thu, 01 Nov 2018 07:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ARUglijxYIeRcO6Qq5XAc0+Hbj5ZmaSNNwOQMEnxuI4=; b=iPMpljGb/3c1kcJBrn5YBFt4s3gpw8VkkO/YLV6PQ/9x0His+7EnQo9nRcSE2QzlFE juLhUiR+/yG4vlcOh+mAtAC17IDg/W6ca7vYIsnTMO90cTUjy0x0XGOx4c4dnmeZNSpB 7F25xHAcA6mFU9yMMzD4V+xM+eji3uOA/rKUU= 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=ARUglijxYIeRcO6Qq5XAc0+Hbj5ZmaSNNwOQMEnxuI4=; b=P6nSLuDoHeiqA/Yy/4eMElDhcAwzZagzGSDUJoW0ovcAproLrNyAU0vF4MEKsj+hjL fdkT+zfNeBDa3Ntfyv1PUpdLJC3WXG76AJA6kV4HmYq/oqXInxh/z5YqlLTYaUqcGwZD OcSFgcEGPqsnrl277O1zuNpihS3XMuwwH6gKG8xQ5bTricM+7U5YqQv0wZ3ImWJKIK3c NAHG1peuFeqvJ/K9vOlVT8+ouksVr7r9+eSg3JaLfgxVcNAu3QZ6ogxCdqvF6A7hgb1A 0J/likY9CT9B8blQ4th4p4yOnRdC2Z4fMRvsFsCKlEqreC5invko089bEGjZgG14k388 VTZw== X-Gm-Message-State: AGRZ1gKuj/wtHLlI+FG52AOGoPIN3CuOQ4hk0xGrH55KD3P54o9ZwTGF Y1imF9Ng1FF1Q5rO8Z+yHqvNxPOLrzU92cWH8GbksqhOTh7QH2UveJhvsTHTBwaK2VnDc4C5B0k mSIPcf/ixiwoUp/uP1U8= X-Google-Smtp-Source: AJdET5f0W6K2vRYfRZByBQ4zndZcAuwY/noPAU8+HBLOyhf0J3nM8VvQI5vYW916jXWFRKecJrEcZmaf6OUCnO4JXbY= X-Received: by 2002:a24:bcc1:: with SMTP id n184-v6mr5710433ite.174.1541083057889; Thu, 01 Nov 2018 07:37:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Thu, 1 Nov 2018 08:37:11 -0600 Message-ID: To: jmg+oauth@newcontext.com Cc: oauth Content-Type: multipart/alternative; boundary="0000000000003c629d05799b5c4b" Archived-At: Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 14:37:41 -0000 --0000000000003c629d05799b5c4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To be honest, I thought that was a relatively well known aspect of TLS 1.2 (and prior) and a noted difference of the new features in TLS 1.3. Also, I'd note that we're well past WGCL for this document. But, with that said, I suppose adding some privacy considerations text on the subject is worthwhile. Would you propose some text for the WG to consider, John-Mark? Bearing in mind that the implications of a certificate presented by, and representing, an OAuth client are somewhat different than for an end-user doing client cert authentication. On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney wrote: > I would suggest that the security considerations section of > draft-ietf-oauth-mtls-12 be expanded to include the privacy > implications of using this on versions of TLS before 1.3. On all > versions of TLS before 1.3, the client cert is not encrypted and can > be used by third parties to monitor and track users. I recently > posted a blog entry about this: > https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.ht= ml > > Thanks. > > John-Mark Gurney > > _______________________________________________ > 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._ --0000000000003c629d05799b5c4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be honest, I thought that was a r= elatively well known aspect of TLS 1.2 (and prior) and a noted difference o= f the new features in TLS 1.3. Also, I'd note that we're well past = WGCL for this document. But, with that said, I suppose adding some privacy = considerations text on the subject is worthwhile. Would you propose some te= xt for the WG to consider, John-Mark? Bearing in mind that the implications= of a certificate presented by, and representing, an OAuth client are somew= hat different than for an end-user doing client cert authentication.
<= /div>




On Wed, Oct 31, 2018 at 4:12 PM John-Ma= rk Gurney <jmg+oauth@newco= ntext.com> wrote:
I would = suggest that the security considerations section of
draft-ietf-oauth-mtls-12 be expanded to include the privacy
implications of using this on versions of TLS before 1.3.=C2=A0 On all
versions of TLS before 1.3, the client cert is not encrypted and can
be used by third parties to monitor and track users.=C2=A0 I recently
posted a blog entry about this:
https://blog.funkthat.com= /2018/10/tls-client-authentication-leaks-user.html

Thanks.

John-Mark Gurney

_______________________________________________
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. --0000000000003c629d05799b5c4b-- From nobody Thu Nov 1 07:55:31 2018 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 272DB12777C for ; Thu, 1 Nov 2018 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 IBMECzZu0Xtj for ; Thu, 1 Nov 2018 07:55:26 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E10124BAA for ; Thu, 1 Nov 2018 07:55:26 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id u1-v6so20399033wrn.0 for ; Thu, 01 Nov 2018 07:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NFFOMn4GWiNc0QfnHz86IZCwpz6i+00ioJ/+Nh/yvmk=; b=jtLaEIWqwzzt9W67jE+Sq1mPuUyPeZbpVCavqfYlQAsvcn5f7zutjyqUrHqj2LmWgc 8yyVd4RLmSMGgaRa3h6QaBmB5NleeQzeVGMcLEG4dz8Oe3cDs3V93sHvBJXohGiPw5ER hyuRR161OxY4t2Fi/xY/y69MXEZkv1QnujiQ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NFFOMn4GWiNc0QfnHz86IZCwpz6i+00ioJ/+Nh/yvmk=; b=LiEl8lmpa661Gz79WgcQyLCMvdPASWFxyiy3pSC2mC6sGp5SymBng9xbneR0K+KN5q a12z+tYOETS8ihzS2N6vZuct1rB6pfhFhwDq/RmHURF5pmHezqxjpykaksjgH0et9uII 5ylPnmNrpGYspzp4akrTzX9LVV5I44gmlUjoQ9NXuSsI8KrOiwrB0xhfqWLI2B7XjiSs 6udJNJE88T81T+/wCMw590NANMa15DXmELPdmuHyUytupWPKRS7ZpK7aSlNGN8FTbBHQ VSQX7PiaXVKSBmEz3T/SDhsSLnYQaM//ebP4+Q6NrM8Zw8b1nif1MKa9ijWxZd4D5qd2 nFdg== X-Gm-Message-State: AGRZ1gJjaxXt9PCF4dKUQffy73XtECUyIlTFTeLGkommhHPEUhxzSQeI x0Q8xxMfI4GziYbhFCWLGSjiuQ== X-Google-Smtp-Source: AJdET5fTN4kB/biZivm+aAtJFe8tSAO29tqrmk6kKD8RGlO3hqQk0kXM5cyRQ0NIih8f6OmqqdL89g== X-Received: by 2002:adf:bd0f:: with SMTP id j15-v6mr6494303wrh.267.1541084124502; Thu, 01 Nov 2018 07:55:24 -0700 (PDT) Received: from guest2s-mbp.lan (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id y21-v6sm10206981wma.36.2018.11.01.07.55.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 07:55:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Neil Madden In-Reply-To: Date: Thu, 1 Nov 2018 14:55:22 +0000 Cc: jmg+oauth@newcontext.com, oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 14:55:30 -0000 I believe the standard approach to this is to only prompt for a client = certificate in a renegotiation handshake rather than in the initial = handshake. Renegotiations are encrypted under the existing TLS session. =E2=80=94 Neil > On 1 Nov 2018, at 14:37, Brian Campbell = wrote: >=20 > To be honest, I thought that was a relatively well known aspect of TLS = 1.2 (and prior) and a noted difference of the new features in TLS 1.3. = Also, I'd note that we're well past WGCL for this document. But, with = that said, I suppose adding some privacy considerations text on the = subject is worthwhile. Would you propose some text for the WG to = consider, John-Mark? Bearing in mind that the implications of a = certificate presented by, and representing, an OAuth client are somewhat = different than for an end-user doing client cert authentication.=20 >=20 >=20 >=20 >=20 > On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney = wrote: > I would suggest that the security considerations section of > draft-ietf-oauth-mtls-12 be expanded to include the privacy > implications of using this on versions of TLS before 1.3. On all > versions of TLS before 1.3, the client cert is not encrypted and can > be used by third parties to monitor and track users. I recently > posted a blog entry about this: > = https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.htm= l >=20 > Thanks. >=20 > John-Mark Gurney >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Nov 1 08:21:45 2018 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 E9D111298C5 for ; Thu, 1 Nov 2018 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w0340uBMLzJ for ; Thu, 1 Nov 2018 08:21:41 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DE412872C for ; Thu, 1 Nov 2018 08:21:41 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id b203-v6so1644391wme.5 for ; Thu, 01 Nov 2018 08:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tVXb4QmU6vZWcSCXZnFbZgXQScRP5pqPmaXkue4J+L8=; b=M06OkuZCNJlkFcd0jSNYIBjF5GQ9fbBPPeGpfpQRVGF9jozhDIOPbVAhMtDb0QKT0I x7I1SplpdzBIAdD4FZQLdKqxj3gO1e3n05Gxm8p4yxuTfwcy0Tdbhm9CrCiojqx2WFhG RYANxJzBiu6fb3qzIcCMiX8O3QmN+S6GkFRD3AGYerL4zN1ItzOduzYHVS0nABbf2DZn yi+C6Xgcs+DDyx2NYGJduToi4v7brQJZWZ4PEWSrTJMrBkxxf6WH8ngB4Js25u31kvxE yvPYSvf6Hwbnt9m8ivPy8SiZKmMzuR1DPfzOsveaykZ5V2LBX2cmKif5cwYdfRVVmZVJ aPDw== 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=tVXb4QmU6vZWcSCXZnFbZgXQScRP5pqPmaXkue4J+L8=; b=LZNuLIzbYEcIxEQuZDUEeykhRstFYggaryyPKF4RHD4hUS4eBCsynH9yFPRrhIHyOZ aE3WoZL0RUS0IJFwOYK1cgAkAKkjcKUkIX54LlW1L6SsMn8xoqrjSeJDEH3CdHKqqkQU 6fanznTYHVCs1CZ6cAaB6sBKt/+slXwXlGNdHp8WpO8ZBusKbMaDoxiZkaEemP3w7td8 RnqwwCqgLHJ3lA9Yh+GEAsEggPyJJHw2cKn/fALevsjh5Avdd77MfALQ0FSTIjKBBf9A pmEhPWO81yPer4IGMXGp1EZAGTgm9YduuQqkyIsu6fyxhdU54F7Ozm5FoA08yx8rqPU/ SF3A== X-Gm-Message-State: AGRZ1gJKs4yZ4iR5l9QP2TWwYorWt8sk3IbBsrqM7fsZgu/N84BooKnT BYi/WXw4oIXsnnJgdhrvX8y7gB27vRE0/+Fr8pc= X-Google-Smtp-Source: AJdET5eqRfksjS32TJKaQEs056NQ8DXse/kHqpIzuV3lc66YrrAFOMI6JcSloyxn7eUpNHGByAPuoBCb/z3BACFkVMo= X-Received: by 2002:a1c:1984:: with SMTP id 126-v6mr5827855wmz.7.1541085699141; Thu, 01 Nov 2018 08:21:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Fri, 2 Nov 2018 00:21:26 +0900 Message-ID: To: neil.madden@forgerock.com Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="000000000000aa79c505799bf9ae" Archived-At: Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 15:21:44 -0000 --000000000000aa79c505799bf9ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adding to it, in OAuth MTLS setting, the client cert is that of the OAuth client, which is typically a web server and not of a natural person. The content of the certs should be well publicized so that the natural person and the OAuth Authorization Server involved should become aware of what this client is, so I am not sure if there is much privacy impact in this setting. Yes, if the client is a dedicated client for the natural person, then there is going to be additional privacy impact, but for something like that, we were talking of token binding instead. On Thu, Nov 1, 2018 at 11:55 PM Neil Madden wrote: > I believe the standard approach to this is to only prompt for a client > certificate in a renegotiation handshake rather than in the initial > handshake. Renegotiations are encrypted under the existing TLS session. > > =E2=80=94 Neil > > > On 1 Nov 2018, at 14:37, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > > > To be honest, I thought that was a relatively well known aspect of TLS > 1.2 (and prior) and a noted difference of the new features in TLS 1.3. > Also, I'd note that we're well past WGCL for this document. But, with tha= t > said, I suppose adding some privacy considerations text on the subject is > worthwhile. Would you propose some text for the WG to consider, John-Mark= ? > Bearing in mind that the implications of a certificate presented by, and > representing, an OAuth client are somewhat different than for an end-user > doing client cert authentication. > > > > > > > > > > On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney < > jmg+oauth@newcontext.com> wrote: > > I would suggest that the security considerations section of > > draft-ietf-oauth-mtls-12 be expanded to include the privacy > > implications of using this on versions of TLS before 1.3. On all > > versions of TLS before 1.3, the client cert is not encrypted and can > > be used by third parties to monitor and track users. I recently > > posted a blog entry about this: > > > https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.ht= ml > > > > Thanks. > > > > John-Mark Gurney > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000000000000aa79c505799bf9ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding to it, in OAuth MTLS setting, the client cert is th= at of the OAuth client, which is typically a web server and not of a natura= l person. The content of the certs should be well publicized so that the na= tural person and the OAuth Authorization Server involved should become awar= e of what this client is, so I am not sure if there is much privacy impact = in this setting. Yes, if the client is a dedicated client for the natural p= erson, then there is going to be additional privacy impact, but for somethi= ng like that, we were talking of token binding instead.=C2=A0

On Thu, Nov 1, 2018 at 11:55 PM Nei= l Madden <neil.madden@forge= rock.com> wrote:
I believe t= he standard approach to this is to only prompt for a client certificate in = a renegotiation handshake rather than in the initial handshake. Renegotiati= ons are encrypted under the existing TLS session.

=E2=80=94 Neil

> On 1 Nov 2018, at 14:37, Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org> wrote:
>
> To be honest, I thought that was a relatively well known aspect of TLS= 1.2 (and prior) and a noted difference of the new features in TLS 1.3. Als= o, I'd note that we're well past WGCL for this document. But, with = that said, I suppose adding some privacy considerations text on the subject= is worthwhile. Would you propose some text for the WG to consider, John-Ma= rk? Bearing in mind that the implications of a certificate presented by, an= d representing, an OAuth client are somewhat different than for an end-user= doing client cert authentication.
>
>
>
>
> On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney <jmg+oauth@newcontext.com= > wrote:
> I would suggest that the security considerations section of
> draft-ietf-oauth-mtls-12 be expanded to include the privacy
> implications of using this on versions of TLS before 1.3.=C2=A0 On all=
> versions of TLS before 1.3, the client cert is not encrypted and can > be used by third parties to monitor and track users.=C2=A0 I recently<= br> > posted a blog entry about this:
> https://blog.funktha= t.com/2018/10/tls-client-authentication-leaks-user.html
>
> Thanks.
>
> John-Mark Gurney
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y= ou have received this communication in error, please notify the sender imme= diately by e-mail and delete the message and any file attachments from your= computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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


--
Nat Sakimura = (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--000000000000aa79c505799bf9ae-- From nobody Thu Nov 1 14:01:48 2018 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 EA077129AB8 for ; Thu, 1 Nov 2018 14:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=newcontext.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 Rgbaa479LHkd for ; Thu, 1 Nov 2018 14:01:45 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0: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 1BEBD127B92 for ; Thu, 1 Nov 2018 14:01:45 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id j13-v6so6427289pff.11 for ; Thu, 01 Nov 2018 14:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newcontext.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dyVHKtN/89vofzodDI1ZVUMu/KEXJ3K7BizUJAdd484=; b=DBpGCjB8QV+lXvCS3SDwdihLXTRtPf1IB/snpIZJwggFz6SL2IPdc/vp28uphVEfFN wPORZQxgDvLP+8tvvApLe9TDRNO3MvncOIHydWPKH4x4BBEarqpO7ONtTrWofNU6nXcz NAsSJdaNk3s9H0hEU7x+RmWBOExrYoa+RuBavTm2gMX1q+7A1DaVg2vni32w3g9tvBby 6e6FN9TziEXQp7RWgd5/wX1INKaR0AG+YkoDbdAgTJNuODZBKo/N70BrERnHfgZVkP2Y TYYSDGk+5loJbbhCoPiqWzf8Pdw5QutSaW/l5OhpP8FunFgmUkxtcepmHc02benNqywg Vagg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dyVHKtN/89vofzodDI1ZVUMu/KEXJ3K7BizUJAdd484=; b=IlTNqJm+mO4lxd6vPFzv+92wOvo2DxbpZ60lWgYzHvlqqAl1whiErD7LmWen9yJ2AE yrb2zrYAnnB5DL+IO1O1G3LxyuDy4pfp45H45gMDdZvQJTTTErQNl0zyRAuuE9S/JNzw zyIr22+HQKn97P2B2jdSR5jc0/RohSdMkmxatHTNboezJGmwJ9J33MPYbf8jkurh+2/9 c3BTHDYL/m9u8wP0b97xORQGhaRCbebUq8scB3OmChQYKpQiEPbD9tg788XplSePzapl hX1RVIvUFnr48eZAn/dkO1DPpAdlPPpH9k9NsCjTAZmz/AT2l49WasWAnz16Pv8Ok2h7 Buvg== X-Gm-Message-State: AGRZ1gKsYJ9/G5WamQVfbUqHtwVc+TK7g2HXrTieuWSVCdgbsSi4u2IG U0DxsjDD2tJWbQcU/zqZyRPPKCmL4NQvs7prrfzGhw== X-Google-Smtp-Source: AJdET5cdTpPYelbxEkhtfIW5vFEsrKIZb3lsNH+bAoZPAs8+yaYUz8qwQNrOkAOC5uQS2jbnHmGaw0ZxzHaoB11jiOo= X-Received: by 2002:a63:1520:: with SMTP id v32-v6mr8609986pgl.150.1541106104642; Thu, 01 Nov 2018 14:01:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John-Mark Gurney Date: Thu, 1 Nov 2018 14:01:33 -0700 Message-ID: To: bcampbell@pingidentity.com Cc: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 21:01:47 -0000 I do not have a good enough understanding of OAuth nor how it is used in this draft to be able to write a proper security considerations section about it. You mention that the OAuth certification is different than one for client cert authentication, but as I don't know the standard well enough, I do not know the implications of it. Even if the paragraph reads something like: Though client certs are public in TLS versions 1.2 and before, they are not a privacy concern because of x, y and z. This would allow people who are reviewing it to understand why it is not a privacy issue. I only briefly reviewed this document because a coworker asked about it, but I raised this concern because it was not mentioned in the security considerations section. On Thu, Nov 1, 2018 at 7:37 AM Brian Campbell wrote: > > To be honest, I thought that was a relatively well known aspect of TLS 1.= 2 (and prior) and a noted difference of the new features in TLS 1.3. Also, = I'd note that we're well past WGCL for this document. But, with that said, = I suppose adding some privacy considerations text on the subject is worthwh= ile. Would you propose some text for the WG to consider, John-Mark? Bearing= in mind that the implications of a certificate presented by, and represent= ing, an OAuth client are somewhat different than for an end-user doing clie= nt cert authentication. > > > > > On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney wrote: >> >> I would suggest that the security considerations section of >> draft-ietf-oauth-mtls-12 be expanded to include the privacy >> implications of using this on versions of TLS before 1.3. On all >> versions of TLS before 1.3, the client cert is not encrypted and can >> be used by third parties to monitor and track users. I recently >> posted a blog entry about this: >> https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.h= tml >> >> Thanks. >> >> John-Mark Gurney >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. From nobody Thu Nov 1 14:02:25 2018 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 5D59912D4E8 for ; Thu, 1 Nov 2018 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=newcontext.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 KyUP8uv2Td_X for ; Thu, 1 Nov 2018 14:02:22 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A5C127B92 for ; Thu, 1 Nov 2018 14:02:22 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id b9-v6so9512521pls.7 for ; Thu, 01 Nov 2018 14:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newcontext.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bNr0ZW6Ysno3grMsPFYjLyZEGmZ8KxS0htjTXNajJBk=; b=Owl9SxxOtJgBSpYF4rQLNpYV6TkNPTaIfq0K+SdMv23TNODOKVagJCYrmVahh5H875 I02zj+/EUP0/Xvg3SHiEhobTecdKI65FdnlcF2HNbm8yQ4WRyky4WKRp8Oq7R9gjPSzv L65x37pdNV2gnm5Iw9OxkqLOQeRNxCS1SYd1/r4szMAYQyJCvKhaIGMk1op0AIAQhm8M O6xVfRKgicV8O3bNOVNE/ClyFEBMts9C5vMR03DV0Lml+M2Fk36gdkwjAgKr3jH92FeF VZ/EpKG0H441+qf6bay53ruW6rKRKlv8+7P23VVauQ/twywUgqmf7CkyK0sVWj7WpNHK 0C9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bNr0ZW6Ysno3grMsPFYjLyZEGmZ8KxS0htjTXNajJBk=; b=Na4ZKiPUWNXEDCnf5UYl+0U8nnB0UfIi1FoVQYocTaX7vE3YLd9jssuRjYWSmCrlie Td69GsaYhLRauqtU3RfE7CByhmxVUmbOo1of+Ah3Q8+/a7/cVQrZbUUc1exVx9Udidq3 QCAlL6zJW58uoEVmEOqlJuPYadxdamssLHI0il8fcvvcTnMT/DppF0zl+EVbMUMEYsLm AX0Fm/v6bTT56jLyxrVzGXdPGaKVQo4sq1Pd0PBl9NHUhiZ/ZzW3rugfg1FI5Mk0Ah7c RHxoNlr9xIhGvR7i6eVUFWHtYg9vUJWOIddArRoWiafZXeTYkVCMiJ2hSRqTVhRYfaB/ h67g== X-Gm-Message-State: AGRZ1gLgGPnAVqNUPRCXn7KzXp3Ryt6di/z6rA/Ymeq6nBdi0lEZi8Qj PrEOkGacQkq+JPqGCUJ+20hV2uCeTHLgVKPIUejgfw== X-Google-Smtp-Source: AJdET5eT/wqZKojv+bhmVl0e8HwAFN7L9RGXq8D3IwxP5jCNmwm1MBdlinqxO9+AuRjYq0Fr/N5M28wSGSsZGn3rhzo= X-Received: by 2002:a17:902:3041:: with SMTP id u59-v6mr8658878plb.279.1541106141466; Thu, 01 Nov 2018 14:02:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John-Mark Gurney Date: Thu, 1 Nov 2018 14:02:10 -0700 Message-ID: To: sakimura@gmail.com Cc: neil.madden@forgerock.com, bcampbell=40pingidentity.com@dmarc.ietf.org, oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 21:02:24 -0000 This sounds like a great thing to add. That this draft should only be used by clients that have many (in the hundreds, if not thousands) "natural persons" associated with it, and if not, then you should use X instead. On Thu, Nov 1, 2018 at 8:21 AM Nat Sakimura wrote: > > Adding to it, in OAuth MTLS setting, the client cert is that of the OAuth= client, which is typically a web server and not of a natural person. The c= ontent of the certs should be well publicized so that the natural person an= d the OAuth Authorization Server involved should become aware of what this = client is, so I am not sure if there is much privacy impact in this setting= . Yes, if the client is a dedicated client for the natural person, then the= re is going to be additional privacy impact, but for something like that, w= e were talking of token binding instead. > > On Thu, Nov 1, 2018 at 11:55 PM Neil Madden w= rote: >> >> I believe the standard approach to this is to only prompt for a client c= ertificate in a renegotiation handshake rather than in the initial handshak= e. Renegotiations are encrypted under the existing TLS session. >> >> =E2=80=94 Neil >> >> > On 1 Nov 2018, at 14:37, Brian Campbell wrote: >> > >> > To be honest, I thought that was a relatively well known aspect of TLS= 1.2 (and prior) and a noted difference of the new features in TLS 1.3. Als= o, I'd note that we're well past WGCL for this document. But, with that sai= d, I suppose adding some privacy considerations text on the subject is wort= hwhile. Would you propose some text for the WG to consider, John-Mark? Bear= ing in mind that the implications of a certificate presented by, and repres= enting, an OAuth client are somewhat different than for an end-user doing c= lient cert authentication. >> > >> > >> > >> > >> > On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney wrote: >> > I would suggest that the security considerations section of >> > draft-ietf-oauth-mtls-12 be expanded to include the privacy >> > implications of using this on versions of TLS before 1.3. On all >> > versions of TLS before 1.3, the client cert is not encrypted and can >> > be used by third parties to monitor and track users. I recently >> > posted a blog entry about this: >> > https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user= .html >> > >> > Thanks. >> > >> > John-Mark Gurney >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.. If you ha= ve received this communication in error, please notify the sender immediate= ly by e-mail and delete the message and any file attachments from your comp= uter. Thank you._______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 John-Mark Gurney Principal Security Architect From nobody Fri Nov 2 16:41:36 2018 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 97FAF127333 for ; Fri, 2 Nov 2018 16:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=carlsue-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 Cx6XO_rXvL95 for ; Fri, 2 Nov 2018 16:41:32 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8770126BED for ; Fri, 2 Nov 2018 16:41:31 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id f8-v6so3018315edt.13 for ; Fri, 02 Nov 2018 16:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=carlsue-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=B1KpbqCJh6HWYxQuYqIDoD1GX7b3Vy0OwzM+W6dUjYQ=; b=QsnwlIK6SWnJ93n3uk5e6skgNssQyKb1Gf8EED/AH2xqcGRSN0HUlz3pwNu6cNRsAp 5ZlwoCjGIBUQ2fHJwY7rZx+G7uO3fy87r4SjpnzkEoT10jss9AkA3qYefyH3mx56emim 4anzf6BvVr3ptKK36ZcAyv0cOc6N9i24F7CGRRoIIbwU1PzUZtCg3yJ2u26APd1xlKfo cg0jh9jnfiqnJpYIsyJPkq6SdVYpVqydQKwIaDMX1WHLj8VC11LXoRTB3mFWu4KmVxmS pVoQV/JirreNdJ8CAyZCpGe2jLYdv/rNbkphpDgtG2IkqKUM/4XZ2Ceh/nmIgsMKDrkr utWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=B1KpbqCJh6HWYxQuYqIDoD1GX7b3Vy0OwzM+W6dUjYQ=; b=saoYdJQN0g6P98HbnBN/Qpozuef1mQNpzkGIDvfTBQl2/9eV0Mo3TPLGm1pGMuMX4f +KPBGES1Y77eoRe83Rlv33ELyFBfhd6eq9WFucUJx82TvyQvUxdAE4XCWO1CjeifZJVz zcFEr6k95rj57AvkPiIHCunxFNtKEkL2LMqAfGkmTIgZVCWBWsXIfnWnIpA+x0jXwXeu DsTAuIW2RW6pGCa70DqVLTz45DOJhkjJhUCxVVGr4Rudb/BKknyabGIeegntdtEbhtpr BUp+iUVsfaZG6+q+IHMoML2bm8HTepXh4ELAUw/bUZa9420LZaqDNxV4m9/6oLGc/LC3 3Hqw== X-Gm-Message-State: AGRZ1gI5Vc8fIm1vGxUszUGKZYQTR91pQ1atuMgzZDg4b8p2Hl3F7lTF rqoQ0TLhKkUdVTfEU75yjMhdrQ== X-Google-Smtp-Source: AJdET5cxdNALCuWku/Ye7RIEc2tVv/mHHYIigXk0NnbWJlBN43um6OK1EPkPl7VZBqWzjngJxrSl9g== X-Received: by 2002:a50:fc17:: with SMTP id i23-v6mr1958295edr.153.1541202090147; Fri, 02 Nov 2018 16:41:30 -0700 (PDT) Received: from LNXP265MB0203.GBRP265.PROD.OUTLOOK.COM ([40.100.174.109]) by smtp.gmail.com with ESMTPSA id o10-v6sm6060057ejc.18.2018.11.02.16.41.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 16:41:29 -0700 (PDT) From: Nomad On Walkabout To: John-Mark Gurney , "bcampbell@pingidentity.com" CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 Thread-Index: AVFTOGE5+Qcq0LkzstDLCUif3cxEqGdYaFpWd1dVcTX/Shx0mg== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 2 Nov 2018 23:41:28 +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] security considerations for draft-ietf-oauth-mtls-12 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, 02 Nov 2018 23:41:35 -0000 SGkgSm9obiwNCg0KSSBzdWdnZXN0IHlvdSByZWFkIHRoZSBmaXJzdCBmZXcgc2VjdGlvbnMgb2Yg dGhlIE9BdXRoIHNwZWMgYXMgaXQgbWF5IGV4cGxhaW4gYmV0dGVyIHRoZSB1c2Ugb2YgdGVybXMg aW4gT0F1dGggYXMgdGhleSBhcmUgYSBsaXR0bGUgZGlmZmVyZW50IGR1ZSB0byBpbXBsZW1lbnRh dGlvbi4gSW4gdGhpcyBjYXNlIEkgYmVsaWV2ZSB5b3UgbWVhbiAiUmVzb3VyY2UgT3duZXIiIGFz IHRoZSAiQ2xpZW50IidzIGNlcnRpZmljYXRlIGlzIG5vdCBnb2luZyB0byBiZSBhIHByaXZhY3kg aXNzdWUgdW5sZXNzIGFzIHN0YXRlZCBiZWZvcmUgdGhlICJjbGllbnQiIGlzIGEgdGhpcmQgcGFy dHkgZW50aXR5IGFuZCBpcyBsaWtlbHkgbm90IGdvaW5nIHRvIGJlIGVmZmVjdGVkIGJ5IHByaXZh Y3kgY29uY2VybnMgYXMgSSB1bmRlcnN0YW5kIHRoZSBpbiB0aGlzIGNhc2UuIEFsc28gaW4gdGhl IGZpcnN0IGZldyBzZWN0aW9ucyBvZiB0aGUgT0F1dGggUkZDLCBzZWN1cml0eSAoYW5kIHByaXZh Y3kpIGNvbmNlcm5zIGFyZSBhZGRyZXNzZWQgc3RhdGluZyB0aGF0IHRoZSBsYXRlc3QgdmVyc2lv biBvZiBTU0wvVExTIHBvc3NpYmxlIHNob3VsZCBiZSBpbiB1c2UuIChBdCB0aGUgdGltZSBvZiB3 cml0aW5nIFRMU3YxLjIgd2FzIHRoZSBsYXRlc3QpDQoNCkNoZWVycywNCkNhcmwNCmNhcmxAY2Fy bHN1ZS5jb20NCg0K77u/T24gMTEvMS8xOCwgOTowMSBQTSwgIk9BdXRoIG9uIGJlaGFsZiBvZiBK b2huLU1hcmsgR3VybmV5IiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam1n K29hdXRoQG5ld2NvbnRleHQuY29tPiB3cm90ZToNCg0KICAgIEkgZG8gbm90IGhhdmUgYSBnb29k IGVub3VnaCB1bmRlcnN0YW5kaW5nIG9mIE9BdXRoIG5vciBob3cgaXQgaXMgdXNlZA0KICAgIGlu IHRoaXMgZHJhZnQgdG8gYmUgYWJsZSB0byB3cml0ZSBhIHByb3BlciBzZWN1cml0eSBjb25zaWRl cmF0aW9ucw0KICAgIHNlY3Rpb24gYWJvdXQgaXQuICBZb3UgbWVudGlvbiB0aGF0IHRoZSBPQXV0 aCBjZXJ0aWZpY2F0aW9uIGlzDQogICAgZGlmZmVyZW50IHRoYW4gb25lIGZvciBjbGllbnQgY2Vy dCBhdXRoZW50aWNhdGlvbiwgYnV0IGFzIEkgZG9uJ3Qga25vdw0KICAgIHRoZSBzdGFuZGFyZCB3 ZWxsIGVub3VnaCwgSSBkbyBub3Qga25vdyB0aGUgaW1wbGljYXRpb25zIG9mIGl0Lg0KICAgIA0K ICAgIEV2ZW4gaWYgdGhlIHBhcmFncmFwaCByZWFkcyBzb21ldGhpbmcgbGlrZTogVGhvdWdoIGNs aWVudCBjZXJ0cyBhcmUNCiAgICBwdWJsaWMgaW4gVExTIHZlcnNpb25zIDEuMiBhbmQgYmVmb3Jl LCB0aGV5IGFyZSBub3QgYSBwcml2YWN5IGNvbmNlcm4NCiAgICBiZWNhdXNlIG9mIHgsIHkgYW5k IHouICBUaGlzIHdvdWxkIGFsbG93IHBlb3BsZSB3aG8gYXJlIHJldmlld2luZyBpdA0KICAgIHRv IHVuZGVyc3RhbmQgd2h5IGl0IGlzIG5vdCBhIHByaXZhY3kgaXNzdWUuDQogICAgDQogICAgSSBv bmx5IGJyaWVmbHkgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBiZWNhdXNlIGEgY293b3JrZXIgYXNr ZWQgYWJvdXQNCiAgICBpdCwgYnV0IEkgcmFpc2VkIHRoaXMgY29uY2VybiBiZWNhdXNlIGl0IHdh cyBub3QgbWVudGlvbmVkIGluIHRoZQ0KICAgIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rp b24uDQogICAgT24gVGh1LCBOb3YgMSwgMjAxOCBhdCA3OjM3IEFNIEJyaWFuIENhbXBiZWxsDQog ICAgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiB3cm90ZToNCiAgICA+DQogICAgPiBUbyBi ZSBob25lc3QsIEkgdGhvdWdodCB0aGF0IHdhcyBhIHJlbGF0aXZlbHkgd2VsbCBrbm93biBhc3Bl Y3Qgb2YgVExTIDEuMiAoYW5kIHByaW9yKSBhbmQgYSBub3RlZCBkaWZmZXJlbmNlIG9mIHRoZSBu ZXcgZmVhdHVyZXMgaW4gVExTIDEuMy4gQWxzbywgSSdkIG5vdGUgdGhhdCB3ZSdyZSB3ZWxsIHBh c3QgV0dDTCBmb3IgdGhpcyBkb2N1bWVudC4gQnV0LCB3aXRoIHRoYXQgc2FpZCwgSSBzdXBwb3Nl IGFkZGluZyBzb21lIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgdGV4dCBvbiB0aGUgc3ViamVjdCBp cyB3b3J0aHdoaWxlLiBXb3VsZCB5b3UgcHJvcG9zZSBzb21lIHRleHQgZm9yIHRoZSBXRyB0byBj b25zaWRlciwgSm9obi1NYXJrPyBCZWFyaW5nIGluIG1pbmQgdGhhdCB0aGUgaW1wbGljYXRpb25z IG9mIGEgY2VydGlmaWNhdGUgcHJlc2VudGVkIGJ5LCBhbmQgcmVwcmVzZW50aW5nLCBhbiBPQXV0 aCBjbGllbnQgYXJlIHNvbWV3aGF0IGRpZmZlcmVudCB0aGFuIGZvciBhbiBlbmQtdXNlciBkb2lu ZyBjbGllbnQgY2VydCBhdXRoZW50aWNhdGlvbi4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+ DQogICAgPiBPbiBXZWQsIE9jdCAzMSwgMjAxOCBhdCA0OjEyIFBNIEpvaG4tTWFyayBHdXJuZXkg PGptZytvYXV0aEBuZXdjb250ZXh0LmNvbT4gd3JvdGU6DQogICAgPj4NCiAgICA+PiBJIHdvdWxk IHN1Z2dlc3QgdGhhdCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZg0KICAg ID4+IGRyYWZ0LWlldGYtb2F1dGgtbXRscy0xMiBiZSBleHBhbmRlZCB0byBpbmNsdWRlIHRoZSBw cml2YWN5DQogICAgPj4gaW1wbGljYXRpb25zIG9mIHVzaW5nIHRoaXMgb24gdmVyc2lvbnMgb2Yg VExTIGJlZm9yZSAxLjMuICBPbiBhbGwNCiAgICA+PiB2ZXJzaW9ucyBvZiBUTFMgYmVmb3JlIDEu MywgdGhlIGNsaWVudCBjZXJ0IGlzIG5vdCBlbmNyeXB0ZWQgYW5kIGNhbg0KICAgID4+IGJlIHVz ZWQgYnkgdGhpcmQgcGFydGllcyB0byBtb25pdG9yIGFuZCB0cmFjayB1c2Vycy4gIEkgcmVjZW50 bHkNCiAgICA+PiBwb3N0ZWQgYSBibG9nIGVudHJ5IGFib3V0IHRoaXM6DQogICAgPj4gaHR0cHM6 Ly9ibG9nLmZ1bmt0aGF0LmNvbS8yMDE4LzEwL3Rscy1jbGllbnQtYXV0aGVudGljYXRpb24tbGVh a3MtdXNlci5odG1sDQogICAgPj4NCiAgICA+PiBUaGFua3MuDQogICAgPj4NCiAgICA+PiBKb2hu LU1hcmsgR3VybmV5DQogICAgPj4NCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgID4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4+IE9B dXRoQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KICAgID4NCiAgICA+DQogICAgPiBDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcs IHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICBPQXV0aEBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAg ICANCg== From nobody Sat Nov 3 17:13:27 2018 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 19535128CF2 for ; Sat, 3 Nov 2018 17:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 KGpizhIgAFgr for ; Sat, 3 Nov 2018 17:13:23 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 AA6E612896A for ; Sat, 3 Nov 2018 17:13:23 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id o19-v6so3998417iod.3 for ; Sat, 03 Nov 2018 17:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GNRMwpV//Tb13dbJi2OFiZ8eJLWTNLpKL9EBCo+4BIc=; b=NtMcrD4XkkpGi39cYpqbZ+Da75usioryzHeSAhgFtXdj6fOYJxr6yL1YXU4yC2rcfO a50ctrNN6fSaWqU09yy4qq8aJ9XqtHMIIp7y5olq4WTAdDQWohIml+dGstVQkCvNFuHL dZ2fknLi/OLE652dHt43lT1dk+3J5gtHX10yc= 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=GNRMwpV//Tb13dbJi2OFiZ8eJLWTNLpKL9EBCo+4BIc=; b=DReqVBezCz4OPYYimHLcbWSJYtVwdjiOwYRy+yNwiW2g/DF87aIRo9ZEhGwch6pw3H 4sWVdhvPvvk3rq3Lr9gfwi3lxi381S5rIW2SJG6fUyJ1X0A0vdB6vsMU8AsO8ip2jjc5 yvb9Nk9Xjtzb8aJkzEy8cNhgAbGlup1KgBNbPwszdpQyiyMd5q7uq2XFAnP3ua1x6ECg SqO6RE1do6yII5GX/qB1rI1TB9SzpWRJU0BzgqYOSNNgFB5m6g7TgikwL89GZxx9v5Ub WPfWZDNYP1+wHeyoa/9jseU1rBYBJqcpYuIwHkVpHBXMPQskIb3qf7BipUVtYDKltK9d M9qA== X-Gm-Message-State: AGRZ1gJtRvRR7uBUAaYfhAd+HliXV/doHJrZTKCZtnVlrDqIV6/jWsSl fi3oS6mjnlupY0Jk8yR1rSMb/0CJcjb5hgLC9AaWHrXpWntxJR7htI32yjFaiuHeuBYyUISwK0w zUEA1faD4aC4hHw== X-Google-Smtp-Source: AJdET5eSK3WzV9SWa8cFOF9HZlg1/pSeqz5J775eXQoUFZoeyiuwxS2o67Z0K9NT1vKE8MeTGekpWLn0JzJh+SykPOM= X-Received: by 2002:a6b:b750:: with SMTP id h77-v6mr13466410iof.59.1541290402851; Sat, 03 Nov 2018 17:13:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Sun, 4 Nov 2018 08:13:10 +0800 Message-ID: To: John-Mark Gurney Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f545bc0579cba267" Archived-At: Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12 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, 04 Nov 2018 00:13:26 -0000 --000000000000f545bc0579cba267 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's fair. I'll see if maybe I can piece together some reasonable text about it and/or will also try to discuss it with the WG this week in Bangkok. On Fri, Nov 2, 2018, 3:18 AM John-Mark Gurney I do not have a good enough understanding of OAuth nor how it is used > in this draft to be able to write a proper security considerations > section about it. You mention that the OAuth certification is > different than one for client cert authentication, but as I don't know > the standard well enough, I do not know the implications of it. > > Even if the paragraph reads something like: Though client certs are > public in TLS versions 1.2 and before, they are not a privacy concern > because of x, y and z. This would allow people who are reviewing it > to understand why it is not a privacy issue. > > I only briefly reviewed this document because a coworker asked about > it, but I raised this concern because it was not mentioned in the > security considerations section. > > On Thu, Nov 1, 2018 at 7:37 AM Brian Campbell > wrote: > > > > To be honest, I thought that was a relatively well known aspect of TLS > 1.2 (and prior) and a noted difference of the new features in TLS 1.3. > Also, I'd note that we're well past WGCL for this document. But, with tha= t > said, I suppose adding some privacy considerations text on the subject is > worthwhile. Would you propose some text for the WG to consider, John-Mark= ? > Bearing in mind that the implications of a certificate presented by, and > representing, an OAuth client are somewhat different than for an end-user > doing client cert authentication. > > > > > > > > > > On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney < > jmg+oauth@newcontext.com> wrote: > >> > >> I would suggest that the security considerations section of > >> draft-ietf-oauth-mtls-12 be expanded to include the privacy > >> implications of using this on versions of TLS before 1.3. On all > >> versions of TLS before 1.3, the client cert is not encrypted and can > >> be used by third parties to monitor and track users. I recently > >> posted a blog entry about this: > >> > https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.ht= ml > >> > >> Thanks. > >> > >> John-Mark Gurney > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > > > -- > John-Mark Gurney > Principal Security Architect > --=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._ --000000000000f545bc0579cba267 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's fair. I'll see if maybe I can piece t= ogether some reasonable text about it and/or will also try to discuss it wi= th the WG this week in Bangkok.

On Fri, Nov 2, 2018, 3:18 AM John-Mark Gurney <jmg@newcontext.com wrote:
I do not have a good enough understanding of OAuth nor how= it is used
in this draft to be able to write a proper security considerations
section about it.=C2=A0 You mention that the OAuth certification is
different than one for client cert authentication, but as I don't know<= br> the standard well enough, I do not know the implications of it.

Even if the paragraph reads something like: Though client certs are
public in TLS versions 1.2 and before, they are not a privacy concern
because of x, y and z.=C2=A0 This would allow people who are reviewing it to understand why it is not a privacy issue.

I only briefly reviewed this document because a coworker asked about
it, but I raised this concern because it was not mentioned in the
security considerations section.

On Thu, Nov 1, 2018 at 7:37 AM Brian Campbell
<bcampbell@pingidentity.com> wrote:
>
> To be honest, I thought that was a relatively well known aspect of TLS= 1.2 (and prior) and a noted difference of the new features in TLS 1.3. Als= o, I'd note that we're well past WGCL for this document. But, with = that said, I suppose adding some privacy considerations text on the subject= is worthwhile. Would you propose some text for the WG to consider, John-Ma= rk? Bearing in mind that the implications of a certificate presented by, an= d representing, an OAuth client are somewhat different than for an end-user= doing client cert authentication.
>
>
>
>
> On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney <jmg+oauth= @newcontext.com> wrote:
>>
>> I would suggest that the security considerations section of
>> draft-ietf-oauth-mtls-12 be expanded to include the privacy
>> implications of using this on versions of TLS before 1.3.=C2=A0 On= all
>> versions of TLS before 1.3, the client cert is not encrypted and c= an
>> be used by third parties to monitor and track users.=C2=A0 I recen= tly
>> posted a blog entry about this:
>> https= ://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.html<= br> >>
>> Thanks.
>>
>> John-Mark Gurney
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo= /oauth
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.



--
John-Mark Gurney
Principal Security Architect

<= 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. --000000000000f545bc0579cba267-- From nobody Sun Nov 4 19:54:23 2018 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 2A602126BED for ; Sun, 4 Nov 2018 19:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-1rwLY78sZM for ; Sun, 4 Nov 2018 19:54:19 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0: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 4F494128CF2 for ; Sun, 4 Nov 2018 19:54:19 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id w3-v6so3558469pgs.11 for ; Sun, 04 Nov 2018 19:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=2GUTrw0yjrCbdaJcTC+4GnSAdO6afo4spV0aGbHzifo=; b=BrhXmwEM4okls3N4i/4oy1lW/8ecpcFAGaD6uGV2g1CTQCBfOKlYfnH3x1CvHuc5x/ a1FArBhg1v7i/iUfFqpZCczwfld0G4MQNSTA62vOoHzYRlowgv7x1q4XNuHeNbEOBnwH N33Dfajugtn9Ct8zROMxBvD0W6sNpXfzx7HM/roBARZqf3FJwX7R/Cqe+Fs+AMT4mGaA 2SlYK1EByrQWPKS3FArR/P8hxc0TU+IfcDVe1mk8QIaXnZQPVqEqhXtm0ETkhCnhkLIz mxgU3RYeOjjQXXY5aPhcffyflUJ1SIi6+CfQRf7P3s25Myc5Yr4KgAMmIEYtiDp2Vei4 q+YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=2GUTrw0yjrCbdaJcTC+4GnSAdO6afo4spV0aGbHzifo=; b=XBgdnnxWMASHFjiQFJ9UB+l5BxZrbTKDYODwS2TIg68rldFp59ht54MIvVAZT7KI/a TQNTIQK10mmIeUIepJJsGoZUUlM6lPG9aLrsfqWkJPC9tbbliV8yUAmqV1STWUAkDxvd mfgocnfN6LFotdLDo9k8zqTlF/4ZMhlqPq0P7V4k7TP9Qulyb5pwVzxf9ibXTy1RjDsD KZcsKmwntTWY79dOAsjUWZSpW0N4VLgnm52ybkwRq/9Ty42QVsSNT/eybyH18zBfBDUA RSLhd2rWj4uOD/JHmxTIa57/9SBTiv/qrdGvJGfOI6kXQh84vrfhVNjRxUIXKv9f4F9L CMAg== X-Gm-Message-State: AGRZ1gIqsl3I0t2JM2rRqIspE1AGJCllTPF2S+JISnPWSEp+9Dj2chEB ux4SPfvQx+DkFrACCzjUFgVFrnzqy+sX9g== X-Google-Smtp-Source: AJdET5egv5fIAH2P6clyhdCVCE63RHSFt8G7i3ucpvbeu/ETsP54fhNSSEKXHb+0qUn/APiibqIWXw== X-Received: by 2002:a62:31c2:: with SMTP id x185-v6mr2562001pfx.39.1541390058492; Sun, 04 Nov 2018 19:54:18 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:7552:df46:2884:33b5? ([2001:67c:1232:144:7552:df46:2884:33b5]) by smtp.gmail.com with ESMTPSA id q145-v6sm13003206pfq.143.2018.11.04.19.54.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 19:54:17 -0800 (PST) Sender: Matthew Miller To: oauth@ietf.org From: "Matthew A. Miller" Message-ID: Date: Mon, 5 Nov 2018 10:54:16 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] For Tuesday's Session: OAuth2 for Browser-based Apps 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, 05 Nov 2018 03:54:21 -0000 All, Here is the draft that was foreshadowed for tomorrow's discuss: https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00 -- - m&m Matthew A. Miller From nobody Sun Nov 4 22:32:50 2018 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 40855128B14 for ; Sun, 4 Nov 2018 22:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xt9pF3ZpfKbk for ; Sun, 4 Nov 2018 22:32:45 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) (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 3925012EB11 for ; Sun, 4 Nov 2018 22:32:44 -0800 (PST) Received: from [31.133.150.222] (helo=dhcp-96de.meeting.ietf.org) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gJYRF-0007BU-VL for oauth@ietf.org; Mon, 05 Nov 2018 07:32:42 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_7D2483FC-C157-450A-B2E4-E21DB3E8E10A"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Message-Id: Date: Mon, 5 Nov 2018 13:32:38 +0700 To: oauth X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01 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, 05 Nov 2018 06:32:48 -0000 --Apple-Mail=_7D2483FC-C157-450A-B2E4-E21DB3E8E10A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 as mentioned during the presentation this morning, I would like to get a = feeling what the working groups thinks about generalizing = draft-ietf-oauth-jwt-introspection-response-01 to a mechanism supporting = requesting and providing JWT responses from the different OAuth = endpoints, such as token, revocation, client registration, and = introspection.=20 Please share your thoughts on the list.=20 Thanks in advance, Torsten.=20= --Apple-Mail=_7D2483FC-C157-450A-B2E4-E21DB3E8E10A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMDUwNjMyMzlaMC8GCSqGSIb3DQEJBDEiBCDL tLlW1YMURSdqzyd8cAK3gMoe+2Y/eeGyj5gtRb79yTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAVVszKQvbgq4a3cHeK5Ev0td1 Dk8DvVz9XDndCk9HjxYcDiUt/INTN89JH4vY2ylLoD5tQU+wIyqRl24iB0cxzKpX0+Z2r6X4ftyq ZKWL6wJuYly8fjg9lybGbn403zy/XODLGsxpKRUsDjiOSQF9JbH+gg+BXq5tJfFCM5gIS4eJBG3A e3JP6QQyScFC3uXCWAIXWSdiD7kc7dSTSp51yRRhORJBq3CUepdjBI3dSMjEUF414VvY3NwyYsDJ HQL/hGejdKm831hLlY2nOg58pI4wkO1UtCg1bjhPM2Mt8Y/9QDQj09ChyaqZ3PDhZqNuxetdIEpE uZBtGGKHd9xr3gAAAAAAAA== --Apple-Mail=_7D2483FC-C157-450A-B2E4-E21DB3E8E10A-- From nobody Sun Nov 4 22:38:56 2018 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 39983130E5D for ; Sun, 4 Nov 2018 22:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 MeBtxVyRxPmT for ; Sun, 4 Nov 2018 22:38:51 -0800 (PST) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.111]) (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 A48B1130EA9 for ; Sun, 4 Nov 2018 22:38:51 -0800 (PST) Received: from [31.133.150.222] (helo=dhcp-96de.meeting.ietf.org) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gJYXA-0002dD-R0; Mon, 05 Nov 2018 07:38:49 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_9740C433-1955-4EFC-8A7F-54AE20CED852"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Message-Id: Date: Mon, 5 Nov 2018 13:38:45 +0700 To: oauth X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) 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, 05 Nov 2018 06:38:56 -0000 --Apple-Mail=_9740C433-1955-4EFC-8A7F-54AE20CED852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 the Financial-grade API WG at the OpenID Foundation has published a = mechanism for signing and encrypting OAuth authorization responses that = I would like to bring to your attention.=20 The draft https://openid.net//specs/openid-financial-api-jarm-wd-01.html = went already through Implementations Draft voting.=20 I presented the draft in the session today at IETF-103 and perceived = positive feedback on making this draft usable in a broader OAuth = context. For the time being we would like the draft to stay in the FAPI = WG. If you want to give feedback, please do so either here or at the = FAPI mailing list = (http://lists.openid.net/mailman/listinfo/openid-specs-fapi). kind regards, Torsten.=20= --Apple-Mail=_9740C433-1955-4EFC-8A7F-54AE20CED852 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMDUwNjM4NDVaMC8GCSqGSIb3DQEJBDEiBCD5 hnc/diKHFJW3JUyvsEusF992PR+/jjda1RK2a3HMQTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAsQShMnMvxK6JCm3js5v5Zf5V SX2V8aXFNvDYQd7gFFhwCpsbHetn8+LdIWhb2TFifSW1cwAOJQz1RhJr+v8Wh0OE/U+cGXE4tSoH rbNjynrJSkXVM8IBlsYoxVexnhiaEvsZez+GKDjU2f6nn08r2UqvZyJD+bsQ8AIiotX0pveaOOnP rwYRvSToJ7Aw2W3AKU+R4OOgHZL0vrvVgAihS6xupiIELqry3o9g5r2uFs+hHZCsU4J/FWnEajZT 7IY9eEPCrv57Qg7E4puap+Ez5/AUiSHxNEAJ1qIoFwQSFqGIMccTG+2go+oAvCZOcxVpEiJ0oKLz AngzkhcmMyF2tAAAAAAAAA== --Apple-Mail=_9740C433-1955-4EFC-8A7F-54AE20CED852-- From nobody Sun Nov 4 22:39:50 2018 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 0A06F12EB11 for ; Sun, 4 Nov 2018 22:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFkzmJwapVFV for ; Sun, 4 Nov 2018 22:39:45 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393D7128B14 for ; Sun, 4 Nov 2018 22:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FdbXD/RQ/UmI89JzZ0n3xF6oxjb5X4SDo/bdRkiYJu8=; b=IvMRYyRWBZBmaBNAvVRIytpPFkq49LszqoIWmlQ04QOAjGurFliUZe3iPfhyU2XthNxjl5VVLBsed0p2qbTeeoPrNSDrrFJZxr8SgRkbtdvDTV/SpJt3V4/N0+RHyyj0IBvL135Arc69dYaA8DYQZbEAoo2jSTp0yvGuyUeiDwc= Received: from SN6PR00MB0304.namprd00.prod.outlook.com (52.132.117.158) by SN6PR00MB0416.namprd00.prod.outlook.com (52.132.118.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1351.0; Mon, 5 Nov 2018 06:39:41 +0000 Received: from SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::7049:34d6:bb27:76a4]) by SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::7049:34d6:bb27:76a4%4]) with mapi id 15.20.1350.000; Mon, 5 Nov 2018 06:39:41 +0000 From: Mike Jones To: Torsten Lodderstedt , oauth Thread-Topic: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01 Thread-Index: AQHUdNFn6HIT3bT5CE+WhUFo4eQ7gaVAughQ Date: Mon, 5 Nov 2018 06:39:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0416; 6:xlhGYr8f4Hg2/IG9uEudTNYPlsWwimSSOGq3w7/6XJ+ThDs7fo/oUdJjZdlzwb+Eq1HETCkvHmDY5fp/VWmkj2B9uFr0mdMoCkBOqf47tDjv40i8E6kaXSiMLZctGxhRVed4jCHiS7jPQ/zFbdK9DKqVT+eujvpRUgEHNiOV7JFgQpzFwhxdPN4okwYRPgTrVfTxduejv5pCcSNO19IK1dRYS4z+7KugsJv0I3KPqPjBFfZesexq0ziU0sw5Vv5ZRs6RzCG8Sx1ZojipHdwHyIz9NvzJZ1iSQbgZKZ/lHhK8zR5mC3TsHB8DFrAVXoEbL94CBDp8lDCVLh1PdP+EWaxHTQnZvbDq9KAEbDzUwTVOWlEHQOo4DExDH+gCe0xXIQka3VEsBI+SxZ2x5cFjIMP0lhWjFkYW22AJvJAj50miaKuRsL8mi/gya3avy0Oh5ijjCsU8GQw8xoA+Bpuzdg==; 5:ZVa/0n1l55QiODgyai+ARmito4D1bwCh+9KNpQH0PsmQlahPdnKiVkUnzIAUBMYDTzVRpvbQlYfGdQoraIar6RKJd0UbF2FurPK9IqvseHsT9tmh/3it9UwrJElZJD0fWA85HrVqoLVXU8+TdCWYueuOmVjM5YTGdjJCaIgtCDk=; 7:gAuI2Bqz3wx9QmlMyytkBMUXlfAnb4owwVmzrXVIy/ObW0IwxIZEwAg+ECL6veya/rOmMKmhjpoXknb3JMkEZWYgCtK1jAIH6hejmVx5UPib58t9ZOzh/r03X2UUpv42KF3NNZUlu5mljpo7zH6Uqw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 81a53e91-dc2f-4f7a-8f41-08d642e97742 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:SN6PR00MB0416; x-ms-traffictypediagnostic: SN6PR00MB0416: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3231382)(944501410)(52105102)(2018427008)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201703061421075)(201703161042150)(6042181)(201708071742011)(7699051)(76991095); SRVR:SN6PR00MB0416; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0416; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(13464003)(51874003)(199004)(189003)(53754006)(8936002)(76176011)(7736002)(26005)(186003)(5660300001)(106356001)(99286004)(305945005)(2906002)(2900100001)(7696005)(8990500004)(86612001)(9686003)(53936002)(10090500001)(6506007)(6436002)(81166006)(81156014)(74316002)(55016002)(102836004)(53546011)(8676002)(105586002)(6246003)(25786009)(11346002)(256004)(476003)(66066001)(33656002)(71200400001)(71190400001)(110136005)(446003)(22452003)(97736004)(229853002)(486006)(68736007)(72206003)(86362001)(14454004)(3846002)(10290500003)(498600001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0416; H:SN6PR00MB0304.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ngcu3kVGUGweB/baj7KwvtDsWit8Yx3AimXIb5SCKmAU42PTsXTNJOT1mqzHXCSTtBcMgbkao1L6eNucTvv4qjH2YileYIoI2IQIRHIAOrkkKDRTHEkRO/3LMpxXdtFShiFX4sZJd5LKN2RBqbBnFag060mHqxvQ9iJYqQrczKZifvWOVDrH2LZy5SqGFqa815vxyi/1InqmfHLj/qqX1RU7xk7BFx3YQ3EmMhXe9fWldbxQ/LIJXL/F3MW70UzgbEvuepeUthtgeB8XUR8QOv5C4kkW6nGYfPttxaZGd9vSfmPor2U33qWWtzH8G4iQfRL3gLu/VbuOpk91N40z3l+pQOYlNovisiFzSvV6ymk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81a53e91-dc2f-4f7a-8f41-08d642e97742 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 06:39:41.3746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0416 Archived-At: Subject: Re: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01 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, 05 Nov 2018 06:39:48 -0000 As discussed during the working group meeting, I agree with the people who = spoke up saying that they believe that trying to over-generalize the JWT in= trospection response mechanism to cover all OAuth interactions would be rea= ching too far. There are differences in the characteristics of the differe= nt OAuth endpoints (authorization, token, introspection, AS metadata, dynam= ic registration, etc.) that would have to be accounted for, including the l= ikelihood that different keys and algorithms would be appropriate in the di= fferent contexts, different client authentication methods would be needed, = etc. Let's do one thing well. Not create something that's extra-complicated wit= hout any clear use cases for doing so. -- Mike -----Original Message----- From: OAuth On Behalf Of Torsten Lodderstedt Sent: Monday, November 5, 2018 1:33 PM To: oauth Subject: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-respons= e-01 Hi all,=20 as mentioned during the presentation this morning, I would like to get a fe= eling what the working groups thinks about generalizing draft-ietf-oauth-jw= t-introspection-response-01 to a mechanism supporting requesting and provid= ing JWT responses from the different OAuth endpoints, such as token, revoca= tion, client registration, and introspection.=20 Please share your thoughts on the list.=20 Thanks in advance, Torsten.=20 From nobody Mon Nov 5 00:39:36 2018 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 51926128CFD for ; Mon, 5 Nov 2018 00:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JzeJyESti9Gb for ; Mon, 5 Nov 2018 00:39:31 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640134.outbound.protection.outlook.com [40.107.64.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E172B12D4EB for ; Mon, 5 Nov 2018 00:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ssfDhdHYgPUC1cV3b/nb6MT2AspSC4GjZGQJRHMgvTo=; b=KTjqmgUBtSmVdIK/mXm0grHiW7jtnPzKnrHSiZqVpLQC9alNHhEdF7iqy9zGWX46mdMq6Xh6z6THhpZGasZdEmql7B/EHYUU4ES1jPlbAxXEpG8rVBa/UftNUyWcczQJvyZAyqabwcm3gy9K9w5crfBuwglOvp2bkUyFGZwHblQ= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0317.namprd00.prod.outlook.com (52.132.117.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1349.0; Mon, 5 Nov 2018 08:39:28 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::a519:cc84:ebe4:5f51]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::a519:cc84:ebe4:5f51%10]) with mapi id 15.20.1351.000; Mon, 5 Nov 2018 08:39:28 +0000 From: Mike Jones To: Eric Rescorla , oauth CC: Yaron Sheffer Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp Thread-Index: AQHUPYBLZ8Pf3pDy70ieP7DpSsramaVBSSJg Date: Mon, 5 Nov 2018 08:39:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.129.171] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0317; 6:k8crRTOjOtrj0A8ZW8C1v5iN7UjyOzf6p6xcyF9rggjGwBcUIwKRodmuDXWPxW8hXNftqIhBUnp7ogOOrG3cWa5kOmhxOWnu1GX+gsOy9FPjY9ASmYNqb6n5Vk+nH1zEskzpGlsrS+L6BT45yNACQlQof41vOzp1gwSNsLcxyKtMVwXHI60Hs8IMjLF9PSwyJr5l5OeTApzgdLpbY9rWVJIx0WJNNknfwzS7aTKOxreVydJAsYd6k9ZWO/XmKlUTthIHZwSxpe/0XGkVM/tnrWOKIavT3Vf6zBi4MEGmDQDw5ktteRuxxO0tGKt9XWI+PzwKagav2VV8FQEPuly2Xg07dmU4UcbCVc4g4HRaQ/kh851QSenmQZ64HuNreWrxGKxIoML2xj9xwWp4mKL9gSXQL0XfIQWpMLz36J3J/N5vHLu5yp93XqCmVboedPAcqkFNE1BmvnCKSCWxZd4VKw==; 5:0cudjJaJR1ZLS8c4buUNGamfY2yXvofCRE1hBAwWd9vDulJzF76KuWaIFKjzVTrLyApNWI4KksXmRE2+oRI71G/ljPxC09h7GueeJIlM0ePjgLEY/J5wIJRvvJRmIbGilOPIS9aCAa+m/59hczM0Z1PNxpLMk3TKJsKKPw4hXGU=; 7:VQ0CgaZgM9Ewdtc8ZpKwh7VY89ssXbYWrztVx7G8i+LqBirLIyI6NqPG+sVpmI60g7gnpLyfXd9H3CBjTTrzO6Acn7xnXOh6Ib4THzYuJ3ZzaITfedkkZ0u48cfEcGk6rJh8P4V+0DPchMEdy0aJhg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d68414e0-f156-4289-2a03-08d642fa3337 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR00MB0317; x-ms-traffictypediagnostic: SN6PR00MB0317: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(3231382)(944501410)(52105102)(2018427008)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:SN6PR00MB0317; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0317; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(396003)(346002)(136003)(189003)(199004)(102836004)(6246003)(6436002)(39060400002)(2900100001)(11346002)(71200400001)(71190400001)(446003)(476003)(76176011)(74316002)(55016002)(99286004)(110136005)(86362001)(22452003)(66066001)(68736007)(10090500001)(486006)(14444005)(316002)(86612001)(256004)(606006)(81166006)(81156014)(5660300001)(8676002)(551544002)(14454004)(26005)(6506007)(53546011)(8936002)(33656002)(186003)(8990500004)(4326008)(72206003)(966005)(3846002)(790700001)(6116002)(7696005)(6306002)(54896002)(9686003)(53936002)(478600001)(236005)(97736004)(25786009)(229853002)(2906002)(106356001)(10290500003)(105586002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0317; H:SN6PR00MB0301.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RbZK0R+z9PCANt/kl3bu6ze/JmYoY8pipz6St4zkMpRznpsRe3sLoj/RuPjJmdbIU4CkoCPAynJIWZUmBYAdpAwg8Fs5pMeWtWExyVppiJKp8AppsmSY8PkVwVKOaYY3eyEk7rwPgp4WwqpWsXYU35LnAJVuBkkPW3OKx72XlKlR9p3J/LowkwpIOTmDcGI8Xo1iRl9D19tkmSgeirpNaxI3jfZ4Z7upfB02A2FnwpBhlwRVOdETwVcmVqtzCcNkUKXqUo3pD+kYig6wrcssk2CmHYbvq/EQIs0Jmsc+GcNQ/0MJkH4bwfhsWwjFgWU0LOg7LYSb+aTtL265lpCsdImUN1QbJyBPcsTtvVCjcK4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0301C6909630591B0BAB27DDF5CA0SN6PR00MB0301namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d68414e0-f156-4289-2a03-08d642fa3337 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 08:39:28.6343 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0317 Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp 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, 05 Nov 2018 08:39:36 -0000 --_000_SN6PR00MB0301C6909630591B0BAB27DDF5CA0SN6PR00MB0301namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYy4gIFRoYW5rcyBhZ2FpbiBmb3IgeW91ciByZXZpZXcuICBodHRwczovL2dpdGh1Yi5j b20veWFyb25mL0ktRC9wdWxsLzI0IGlzIGludGVuZGVkIHRvIGFkZHJlc3MgeW91ciByZXZpZXcg Y29tbWVudHMuICBUZXh0IGNoYW5nZXMgbWFkZSB0byBhZGRyZXNzIGVhY2ggb2YgeW91ciBjb21t ZW50cyBhcmUgbGlzdGVkIGJlbG93Lg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IE1vbmRheSwgQXVndXN0IDI3 LCAyMDE4IDQ6MDMgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FV VEgtV0ddIEFEIFJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3ANCg0KUmljaCB2ZXJz aW9uIG9mIHRoaXMgcmV2aWV3IGF0Og0KaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1v emF3cy5uZXQvRDQ2NDkNCg0KDQpDT01NRU5UUw0KUyAxLjIuDQo+ICAgMS4yLiAgQ29udmVudGlv bnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50DQo+DQo+ICAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KPiAgICAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kDQo+ICAgICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4NCj4gICAgICBbUkZDMjExOV0uDQoNCllvdSB3aWxs IHdhbnQgdG8gY2l0ZSA4MTc0IGhlcmUuDQoNCjwgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNU IE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwNCjwgIlNI T1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAi T1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlDQo8IGludGVycHJldGVkIGFzIGRl c2NyaWJlZCBpbiB7e1JGQzIxMTl9fS4NCi0tLQ0KPiBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMDQo+IE5PVCIsICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLA0KPiAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMN Cj4gZGVzY3JpYmVkIGluIEJDUCAxNCB7e1JGQzIxMTl9fSB7e1JGQzgxNzR9fSB3aGVuLCBhbmQg b25seSB3aGVuLCB0aGV5DQo+IGFwcGVhciBpbiBhbGwgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUu DQoNClMgMi42Lg0KPg0KPiAgIDIuNi4gIFN1YnN0aXR1dGlvbiBBdHRhY2tzDQo+DQo+ICAgICAg VGhlcmUgYXJlIGF0dGFja3MgaW4gd2hpY2ggb25lIHJlY2lwaWVudCB3aWxsIGhhdmUgYSBKV1Qg aW50ZW5kZWQgZm9yDQo+ICAgICAgaXQgYW5kIGF0dGVtcHQgdG8gdXNlIGl0IGF0IGEgZGlmZmVy ZW50IHJlY2lwaWVudCB0aGF0IGl0IHdhcyBub3QNCj4gICAgICBpbnRlbmRlZCBmb3IuICBJZiBu b3QgY2F1Z2h0LCB0aGVzZSBhdHRhY2tzIGNhbiByZXN1bHQgaW4gdGhlDQoNCkkgZG9uJ3QgdW5k ZXJzdGFuZCB0aGlzIGF0dGFjay4gQ2FuIHlvdSBnbyBpbnRvIG1vcmUgZGV0YWlsPw0KDQo+IEZv ciBpbnN0YW5jZSwgaWYgYW4gT0F1dGggMi4wIHt7UkZDNjc0OX19IGFjY2VzcyB0b2tlbiBpcyBw cmVzZW50ZWQgdG8gYW4gT0F1dGggMi4wIHByb3RlY3RlZCByZXNvdXJjZQ0KPiB0aGF0IGl0IGlz IGludGVuZGVkIGZvciwgdGhhdCBwcm90ZWN0ZWQgcmVzb3VyY2UgbWlnaHQgYXR0ZW1wdCB0byBn YWluIGFjY2VzcyB0byBhIGRpZmZlcmVudA0KPiBwcm90ZWN0ZWQgcmVzb3VyY2UgYnkgcHJlc2Vu dGluZyB0aGF0IHNhbWUgYWNjZXNzIHRva2VuIHRvIHRoZSBkaWZmZXJlbnQgcHJvdGVjdGVkIHJl c291cmNlLA0KPiB3aGljaCB0aGUgYWNjZXNzIHRva2VuIGlzIG5vdCBpbnRlbmRlZCBmb3IuDQoN ClMgMy4yLg0KPiAgICAgIFRoZXJlZm9yZSwgYXBwbGljYXRpb25zIE1VU1Qgb25seSBhbGxvdyB0 aGUgdXNlIG9mIGNyeXB0b2dyYXBoaWNhbGx5DQo+ICAgICAgY3VycmVudCBhbGdvcml0aG1zIHRo YXQgbWVldCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZQ0KPiAgICAgIGFwcGxpY2F0 aW9uLi4gIFRoaXMgc2V0IHdpbGwgdmFyeSBvdmVyIHRpbWUgYXMgbmV3IGFsZ29yaXRobXMgYXJl DQo+ICAgICAgaW50cm9kdWNlZCBhbmQgZXhpc3RpbmcgYWxnb3JpdGhtcyBhcmUgZGVwcmVjYXRl ZCBkdWUgdG8gZGlzY292ZXJlZA0KPiAgICAgIGNyeXB0b2dyYXBoaWMgd2Vha25lc3Nlcy4gIEFw cGxpY2F0aW9ucyBtdXN0IHRoZXJlZm9yZSBiZSBkZXNpZ25lZCB0bw0KPiAgICAgIGVuYWJsZSBj cnlwdG9ncmFwaGljIGFnaWxpdHkuDQoNCklzIHRoaXMgbXVzdCBub3JtYXRpdmU/DQoNCjwgQXBw bGljYXRpb25zIG11c3QgdGhlcmVmb3JlIGJlIGRlc2lnbmVkIHRvIGVuYWJsZSBjcnlwdG9ncmFw aGljIGFnaWxpdHkuDQotLS0NCj4gQXBwbGljYXRpb25zIE1VU1QgdGhlcmVmb3JlIGJlIGRlc2ln bmVkIHRvIGVuYWJsZSBjcnlwdG9ncmFwaGljIGFnaWxpdHkuDQoNClMgMy4yLg0KPiAgICAgIG1h eSBiZSBubyBuZWVkIHRvIGFwcGx5IGFub3RoZXIgbGF5ZXIgb2YgY3J5cHRvZ3JhcGhpYyBwcm90 ZWN0aW9ucyB0bw0KPiAgICAgIHRoZSBKV1QuICBJbiBzdWNoIGNhc2VzLCB0aGUgdXNlIG9mIHRo ZSAibm9uZSIgYWxnb3JpdGhtIGNhbiBiZQ0KPiAgICAgIHBlcmZlY3RseSBhY2NlcHRhYmxlLiAg SldUcyB1c2luZyAibm9uZSIgYXJlIG9mdGVuIHVzZWQgaW4NCj4gICAgICBhcHBsaWNhdGlvbiBj b250ZXh0cyBpbiB3aGljaCB0aGUgY29udGVudCBpcyBvcHRpb25hbGx5IHNpZ25lZDsgdGhlbg0K PiAgICAgIHRoZSBVUkwtc2FmZSBjbGFpbXMgcmVwcmVzZW50YXRpb24gYW5kIHByb2Nlc3Npbmcg Y2FuIGJlIHRoZSBzYW1lIGluDQo+ICAgICAgYm90aCB0aGUgc2lnbmVkIGFuZCB1bnNpZ25lZCBj YXNlcy4NCg0KSSB0aGluayB5b3UgcHJvYmFibHkgbmVlZCB0byBoYXZlIGEgY2xlYXJlciAiZG9u J3QgdXNlIG5vbmUgYnkNCmRlZmF1bHQiIHN0YXRlbWVudCBoZXJlLg0KDQo+IFRoZSAibm9uZSIg YWxnb3JpdGhtIHNob3VsZCBvbmx5IGJlIHVzZWQgd2hlbiB0aGUgSldUIGlzIGNyeXB0b2dyYXBo aWNhbGx5IHByb3RlY3RlZCBieSBvdGhlciBtZWFucy4NCg0KUyAzLjQuDQo+ICAgICAgRUNESC1F UyBlcGhlbWVyYWwgcHVibGljIGtleSAoZXBrKSBpbnB1dHMgc2hvdWxkIGJlIHZhbGlkYXRlZA0K PiAgICAgIGFjY29yZGluZyB0byB0aGUgcmVjaXBpZW50J3MgY2hvc2VuIGVsbGlwdGljIGN1cnZl LiAgRm9yIHRoZSBOSVNUDQo+ICAgICAgcHJpbWUtb3JkZXIgY3VydmVzIFAtMjU2LCBQLTM4NCBh bmQgUC01MjEsIHZhbGlkYXRpb24gTVVTVCBiZQ0KPiAgICAgIHBlcmZvcm1lZCBhY2NvcmRpbmcg dG8gU2VjdGlvbiA1LjYuMi4zLjQgIkVDQyBQYXJ0aWFsIFB1YmxpYy1LZXkNCj4gICAgICBWYWxp ZGF0aW9uIFJvdXRpbmUiIG9mIE5JU1QgU3BlY2lhbCBQdWJsaWNhdGlvbiA4MDAtNTZBIHJldmlz aW9uIDMNCj4gICAgICBbbmlzdC1zcC04MDAtNTZhLXIzXS4NCg0KSXMgdGhlcmUgYW4gWDI1NTE5 IHNwZWNpZmljYXRpb24gZm9yIEpXRT8gSWYgc28sIHlvdSBzaG91bGQgcHJvYmFibHkNCnNwZWNp ZnkgdGhlIGFwcHJvcHJpYXRlIGNoZWNrcy4NCg0KPiBMaWtld2lzZSwgaWYgdGhlICJYMjU1MTki IG9yICJYNDQ4IiB7e1JGQzgwMzd9fSBhbGdvcml0aG1zIGFyZSB1c2VkLA0KPiB0aGVuIHRoZSB2 YWx1ZXMgTVVTVCBiZSB2YWxpZGF0ZWQgYWNjb3JkaW5nIHt7UkZDNzc0OH19Lg0KDQpTIDMuNS4N Cj4gICAzLjUuICBFbnN1cmUgQ3J5cHRvZ3JhcGhpYyBLZXlzIGhhdmUgU3VmZmljaWVudCBFbnRy b3B5DQo+DQo+ICAgICAgVGhlIEtleSBFbnRyb3B5IGFuZCBSYW5kb20gVmFsdWVzIGFkdmljZSBp biBTZWN0aW9uIDEwLjEgb2YgW1JGQzc1MTVdDQo+ICAgICAgYW5kIHRoZSBQYXNzd29yZCBDb25z aWRlcmF0aW9ucyBpbiBTZWN0aW9uIDguOCBvZiBbUkZDNzUxOF0gTVVTVCBiZQ0KPiAgICAgIGZv bGxvd2VkLiAgSW4gcGFydGljdWxhciwgaHVtYW4tbWVtb3JpemFibGUgcGFzc3dvcmRzIE1VU1Qg Tk9UIGJlDQo+ICAgICAgZGlyZWN0bHkgdXNlZCBhcyB0aGUga2V5IHRvIGEga2V5ZWQtTUFDIGFs Z29yaXRobSBzdWNoIGFzICJIUzI1NiIuDQoNCklmIHlvdSBjYW4ndCB1c2UgdGhlbSAiZGlyZWN0 bHkiIHRoYW4gaG93IHNob3VsZCB5b3UgdXNlIHRoZW0/IERvIHlvdQ0Kd2FudCB0byBzYXkgYW55 dGhpbmcgYWJvdXQgcGFzc3dvcmQgaGFzaGluZyAoYXJnb24sIGV0Yy4pPw0KDQo+IFJhdGhlciwg dGhlIHByaW5jaXBsZXMgZnJvbSB7e1JGQzI4OTh9fSBTSE9VTEQgYmUgdXNlZA0KPiB0byBkZXJp dmUgY3J5cHRvZ3JhcGhpYyBrZXlzIGZyb20gdXNlci1zdXBwbGllZCBwYXNzd29yZHMuDQoNClMg My4xMi4NCj4gICAgICAgICBvZiBKV1RzLg0KPg0KPiAgICAgIEdpdmVuIHRoZSBicm9hZCBkaXZl cnNpdHkgb2YgSldUIHVzYWdlIGFuZCBhcHBsaWNhdGlvbnMsIHRoZSBiZXN0DQo+ICAgICAgY29t YmluYXRpb24gb2YgdHlwZXMsIHJlcXVpcmVkIGNsYWltcywgdmFsdWVzLCBoZWFkZXIgcGFyYW1l dGVycywga2V5DQo+ICAgICAgdXNhZ2VzLCBhbmQgaXNzdWVycyB0byBkaWZmZXJlbnRpYXRlIGFt b25nIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzDQo+ICAgICAgd2lsbCwgaW4gZ2VuZXJhbCwgYmUg YXBwbGljYXRpb24gc3BlY2lmaWMuDQoNCkkgZ2V0IHRoYXQgdGhpcyBpcyB0aGUgc3RhdGUgd2Ug ZmluZCBvdXJzZWx2ZXMgaW4sIGJ1dCBpdCBzZWVtcyBsaWtlDQppdCdzIHVuZm9ydHVuYXRlLiBU aGlzIG1pZ2h0IGJlIGEgZ29vZCB0aW1lIHRvIHJlLWVtcGhhc2l6ZSB0aGUNCnJlY29tbWVuZGF0 aW9uIGZvciBleHBsaWNpdCB0eXBlcyBpbiAzLjExLg0KDQo+IEZvciBuZXcgSldUIGFwcGxpY2F0 aW9ucywgdGhlIHVzZSBvZiBleHBsaWNpdCB0eXBpbmcgaXMgUkVDT01NRU5ERUQuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3Mg YWdhaW4sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQo= --_000_SN6PR00MB0301C6909630591B0BAB27DDF5CA0SN6PR00MB0301namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SGkgRXJpYy4mbmJzcDsgVGhhbmtzIGFnYWluIGZvciB5 b3VyIHJldmlldy4mbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS95YXJvbmYvSS1E L3B1bGwvMjQiPmh0dHBzOi8vZ2l0aHViLmNvbS95YXJvbmYvSS1EL3B1bGwvMjQ8L2E+IGlzIGlu dGVuZGVkIHRvIGFkZHJlc3MgeW91ciByZXZpZXcgY29tbWVudHMuJm5ic3A7IFRleHQgY2hhbmdl cyBtYWRlIHRvIGFkZHJlc3MgZWFjaCBvZiB5b3VyIGNvbW1lbnRzIGFyZSBsaXN0ZWQgYmVsb3cu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZn dDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBBdWd1c3QgMjcsIDIwMTggNDowMyBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGggJmx0 O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIEFEIFJl dmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3A8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJpY2ggdmVyc2lvbiBvZiB0aGlzIHJldmlldyBhdDo8YnI+DQo8YSBocmVmPSJodHRw czovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9ENDY0OSI+aHR0cHM6Ly9tb3pw aGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQ2NDk8L2E+PGJyPg0KPGJyPg0KPGJyPg0K Q09NTUVOVFM8YnI+DQpTIDEuMi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IDEuMi4mbmJzcDsgQ29u dmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyA8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBrZXkgd29yZHMgJnF1b3Q7 TVVTVCZxdW90OywgJnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1b3Q7LCAm cXVvdDtTSEFMTCZxdW90OywgJnF1b3Q7U0hBTEwgTk9UJnF1b3Q7LDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7U0hPVUxEJnF1b3Q7LCAmcXVvdDtTSE9VTEQg Tk9UJnF1b3Q7LCAmcXVvdDtSRUNPTU1FTkRFRCZxdW90OywgJnF1b3Q7Tk9UIFJFQ09NTUVOREVE JnF1b3Q7LCAmcXVvdDtNQVkmcXVvdDssIGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7T1BUSU9OQUwmcXVvdDsgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8g YmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBbUkZDMjExOV0uPGJyPg0KPGJyPg0KWW91IHdpbGwgd2FudCB0byBjaXRl IDgxNzQgaGVyZS48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jmx0OyBU aGUga2V5IHdvcmRzICZxdW90O01VU1QmcXVvdDssICZxdW90O01VU1QgTk9UJnF1b3Q7LCAmcXVv dDtSRVFVSVJFRCZxdW90OywgJnF1b3Q7U0hBTEwmcXVvdDssICZxdW90O1NIQUxMIE5PVCZxdW90 OywgJnF1b3Q7U0hPVUxEJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbHQ7ICZxdW90O1NIT1VMRCBO T1QmcXVvdDssICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LCAmcXVvdDtOT1QgUkVDT01NRU5ERUQm cXVvdDssICZxdW90O01BWSZxdW90OywgYW5kICZxdW90O09QVElPTkFMJnF1b3Q7IGluIHRoaXMg ZG9jdW1lbnQgYXJlIHRvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZsdDsgaW50ZXJwcmV0ZWQgYXMgZGVz Y3JpYmVkIGluIHt7UkZDMjExOX19LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ Jmd0OyBUaGUga2V5IHdvcmRzICZxdW90O01VU1QmcXVvdDssICZxdW90O01VU1QgTk9UJnF1b3Q7 LCAmcXVvdDtSRVFVSVJFRCZxdW90OywgJnF1b3Q7U0hBTEwmcXVvdDssICZxdW90O1NIQUxMPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZndDsgTk9UJnF1b3Q7LCAmcXVvdDtTSE9VTEQmcXVvdDssICZxdW90O1NI T1VMRCBOT1QmcXVvdDssICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LCAmcXVvdDtOT1QgUkVDT01N RU5ERUQmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZndDsgJnF1b3Q7TUFZJnF1b3Q7LCBhbmQgJnF1 b3Q7T1BUSU9OQUwmcXVvdDsgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jmd0OyBkZXNjcmliZWQgaW4gQkNQIDE0IHt7UkZDMjExOX19IHt7 UkZDODE3NH19IHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jmd0OyBh cHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClMgMi42Ljxicj4NCiZndDsmbmJzcDsmbmJz cDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyAyLjYuJm5ic3A7IFN1YnN0aXR1dGlvbiBBdHRhY2tz PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoZXJlIGFyZSBhdHRhY2tzIGluIHdoaWNoIG9uZSByZWNpcGllbnQgd2lsbCBoYXZl IGEgSldUIGludGVuZGVkIGZvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaXQgYW5kIGF0dGVtcHQgdG8gdXNlIGl0IGF0IGEgZGlmZmVyZW50IHJlY2lwaWVudCB0aGF0 IGl0IHdhcyBub3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVu ZGVkIGZvci4mbmJzcDsgSWYgbm90IGNhdWdodCwgdGhlc2UgYXR0YWNrcyBjYW4gcmVzdWx0IGlu IHRoZTxicj4NCjxicj4NCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGF0dGFjay4gQ2FuIHlvdSBn byBpbnRvIG1vcmUgZGV0YWlsPzxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jmd0OyBGb3IgaW5zdGFuY2UsIGlmIGFuIE9BdXRoIDIuMCB7e1JG QzY3NDl9fSBhY2Nlc3MgdG9rZW4gaXMgcHJlc2VudGVkIHRvIGFuIE9BdXRoIDIuMCBwcm90ZWN0 ZWQgcmVzb3VyY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jmd0OyB0aGF0IGl0IGlzIGludGVuZGVkIGZvciwg dGhhdCBwcm90ZWN0ZWQgcmVzb3VyY2UgbWlnaHQgYXR0ZW1wdCB0byBnYWluIGFjY2VzcyB0byBh IGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mZ3Q7IHByb3RlY3RlZCByZXNvdXJjZSBieSBwcmVz ZW50aW5nIHRoYXQgc2FtZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGRpZmZlcmVudCBwcm90ZWN0ZWQg cmVzb3VyY2UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZndDsgd2hpY2ggdGhlIGFjY2VzcyB0b2tlbiBpcyBu b3QgaW50ZW5kZWQgZm9yLjxicj4NCjwvc3Bhbj48YnI+DQpTIDMuMi48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlZm9yZSwgYXBwbGljYXRpb25zIE1VU1Qgb25s eSBhbGxvdyB0aGUgdXNlIG9mIGNyeXB0b2dyYXBoaWNhbGx5PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBjdXJyZW50IGFsZ29yaXRobXMgdGhhdCBtZWV0IHRoZSBzZWN1 cml0eSByZXF1aXJlbWVudHMgb2YgdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhcHBsaWNhdGlvbi4uJm5ic3A7IFRoaXMgc2V0IHdpbGwgdmFyeSBvdmVyIHRpbWUg YXMgbmV3IGFsZ29yaXRobXMgYXJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBpbnRyb2R1Y2VkIGFuZCBleGlzdGluZyBhbGdvcml0aG1zIGFyZSBkZXByZWNhdGVkIGR1 ZSB0byBkaXNjb3ZlcmVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBj cnlwdG9ncmFwaGljIHdlYWtuZXNzZXMuJm5ic3A7IEFwcGxpY2F0aW9ucyBtdXN0IHRoZXJlZm9y ZSBiZSBkZXNpZ25lZCB0bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZW5hYmxlIGNyeXB0b2dyYXBoaWMgYWdpbGl0eS48YnI+DQo8YnI+DQpJcyB0aGlzIG11c3Qgbm9y bWF0aXZlPzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48YnI+DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZsdDsgQXBwbGljYXRpb25zIG11c3QgdGhlcmVmb3Jl IGJlIGRlc2lnbmVkIHRvIGVuYWJsZSBjcnlwdG9ncmFwaGljIGFnaWxpdHkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mZ3Q7IEFwcGxpY2F0aW9ucyBNVVNUIHRoZXJlZm9yZSBi ZSBkZXNpZ25lZCB0byBlbmFibGUgY3J5cHRvZ3JhcGhpYyBhZ2lsaXR5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij48YnI+DQo8L3NwYW4+UyAzLjIuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBtYXkgYmUgbm8gbmVlZCB0byBhcHBseSBhbm90aGVyIGxheWVyIG9mIGNyeXB0b2dyYXBo aWMgcHJvdGVjdGlvbnMgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRoZSBKV1QuJm5ic3A7IEluIHN1Y2ggY2FzZXMsIHRoZSB1c2Ugb2YgdGhlICZxdW90O25vbmUm cXVvdDsgYWxnb3JpdGhtIGNhbiBiZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcGVyZmVjdGx5IGFjY2VwdGFibGUuJm5ic3A7IEpXVHMgdXNpbmcgJnF1b3Q7bm9uZSZx dW90OyBhcmUgb2Z0ZW4gdXNlZCBpbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYXBwbGljYXRpb24gY29udGV4dHMgaW4gd2hpY2ggdGhlIGNvbnRlbnQgaXMgb3B0aW9u YWxseSBzaWduZWQ7IHRoZW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRoZSBVUkwtc2FmZSBjbGFpbXMgcmVwcmVzZW50YXRpb24gYW5kIHByb2Nlc3NpbmcgY2FuIGJl IHRoZSBzYW1lIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib3Ro IHRoZSBzaWduZWQgYW5kIHVuc2lnbmVkIGNhc2VzLjxicj4NCjxicj4NCkkgdGhpbmsgeW91IHBy b2JhYmx5IG5lZWQgdG8gaGF2ZSBhIGNsZWFyZXIgJnF1b3Q7ZG9uJ3QgdXNlIG5vbmUgYnk8YnI+ DQpkZWZhdWx0JnF1b3Q7IHN0YXRlbWVudCBoZXJlLjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jmd0OyBUaGUgJnF1b3Q7bm9uZSZxdW90OyBh bGdvcml0aG0gc2hvdWxkIG9ubHkgYmUgdXNlZCB3aGVuIHRoZSBKV1QgaXMgY3J5cHRvZ3JhcGhp Y2FsbHkgcHJvdGVjdGVkIGJ5IG90aGVyIG1lYW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClMgMy40Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRUNESC1FUyBlcGhlbWVyYWwgcHVibGljIGtleSAoZXBrKSBpbnB1dHMg c2hvdWxkIGJlIHZhbGlkYXRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYWNjb3JkaW5nIHRvIHRoZSByZWNpcGllbnQncyBjaG9zZW4gZWxsaXB0aWMgY3VydmUuJm5i c3A7IEZvciB0aGUgTklTVDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg cHJpbWUtb3JkZXIgY3VydmVzIFAtMjU2LCBQLTM4NCBhbmQgUC01MjEsIHZhbGlkYXRpb24gTVVT VCBiZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVyZm9ybWVkIGFj Y29yZGluZyB0byBTZWN0aW9uIDUuNi4yLjMuNCAmcXVvdDtFQ0MgUGFydGlhbCBQdWJsaWMtS2V5 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWYWxpZGF0aW9uIFJvdXRp bmUmcXVvdDsgb2YgTklTVCBTcGVjaWFsIFB1YmxpY2F0aW9uIDgwMC01NkEgcmV2aXNpb24gMzxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW25pc3Qtc3AtODAwLTU2YS1y M10uPGJyPg0KPGJyPg0KSXMgdGhlcmUgYW4gWDI1NTE5IHNwZWNpZmljYXRpb24gZm9yIEpXRT8g SWYgc28sIHlvdSBzaG91bGQgcHJvYmFibHk8YnI+DQpzcGVjaWZ5IHRoZSBhcHByb3ByaWF0ZSBj aGVja3MuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mZ3Q7IExpa2V3aXNlLCBpZiB0aGUgJnF1b3Q7WDI1NTE5JnF1b3Q7IG9yICZxdW90O1g0 NDgmcXVvdDsge3tSRkM4MDM3fX0gYWxnb3JpdGhtcyBhcmUgdXNlZCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ Jmd0OyB0aGVuIHRoZSB2YWx1ZXMgTVVTVCBiZSB2YWxpZGF0ZWQgYWNjb3JkaW5nIHt7UkZDNzc0 OH19Ljxicj4NCjxicj4NCjwvc3Bhbj5TIDMuNS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IDMuNS4m bmJzcDsgRW5zdXJlIENyeXB0b2dyYXBoaWMgS2V5cyBoYXZlIFN1ZmZpY2llbnQgRW50cm9weTxi cj4NCiZndDsmbmJzcDsmbmJzcDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGUgS2V5IEVudHJvcHkgYW5kIFJhbmRvbSBWYWx1ZXMgYWR2aWNlIGluIFNlY3Rpb24g MTAuMSBvZiBbUkZDNzUxNV08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFuZCB0aGUgUGFzc3dvcmQgQ29uc2lkZXJhdGlvbnMgaW4gU2VjdGlvbiA4Ljggb2YgW1JGQzc1 MThdIE1VU1QgYmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvbGxv d2VkLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBodW1hbi1tZW1vcml6YWJsZSBwYXNzd29yZHMgTVVT VCBOT1QgYmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpcmVjdGx5 IHVzZWQgYXMgdGhlIGtleSB0byBhIGtleWVkLU1BQyBhbGdvcml0aG0gc3VjaCBhcyAmcXVvdDtI UzI1NiZxdW90Oy48YnI+DQo8YnI+DQpJZiB5b3UgY2FuJ3QgdXNlIHRoZW0gJnF1b3Q7ZGlyZWN0 bHkmcXVvdDsgdGhhbiBob3cgc2hvdWxkIHlvdSB1c2UgdGhlbT8gRG8geW91PGJyPg0Kd2FudCB0 byBzYXkgYW55dGhpbmcgYWJvdXQgcGFzc3dvcmQgaGFzaGluZyAoYXJnb24sIGV0Yy4pPzxicj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48YnI+DQomZ3Q7IFJhdGhlciwgdGhlIHByaW5j aXBsZXMgZnJvbSB7e1JGQzI4OTh9fSBTSE9VTEQgYmUgdXNlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mZ3Q7 IHRvIGRlcml2ZSBjcnlwdG9ncmFwaGljIGtleXMgZnJvbSB1c2VyLXN1cHBsaWVkIHBhc3N3b3Jk cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PGJyPg0KPC9zcGFuPlMgMy4xMi48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIEpXVHMuPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdp dmVuIHRoZSBicm9hZCBkaXZlcnNpdHkgb2YgSldUIHVzYWdlIGFuZCBhcHBsaWNhdGlvbnMsIHRo ZSBiZXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21iaW5hdGlv biBvZiB0eXBlcywgcmVxdWlyZWQgY2xhaW1zLCB2YWx1ZXMsIGhlYWRlciBwYXJhbWV0ZXJzLCBr ZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzYWdlcywgYW5kIGlz c3VlcnMgdG8gZGlmZmVyZW50aWF0ZSBhbW9uZyBkaWZmZXJlbnQga2luZHMgb2YgSldUczxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2lsbCwgaW4gZ2VuZXJhbCwgYmUg YXBwbGljYXRpb24gc3BlY2lmaWMuPGJyPg0KPGJyPg0KSSBnZXQgdGhhdCB0aGlzIGlzIHRoZSBz dGF0ZSB3ZSBmaW5kIG91cnNlbHZlcyBpbiwgYnV0IGl0IHNlZW1zIGxpa2U8YnI+DQppdCdzIHVu Zm9ydHVuYXRlLiBUaGlzIG1pZ2h0IGJlIGEgZ29vZCB0aW1lIHRvIHJlLWVtcGhhc2l6ZSB0aGU8 YnI+DQpyZWNvbW1lbmRhdGlvbiBmb3IgZXhwbGljaXQgdHlwZXMgaW4gMy4xMS48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m Z3Q7IEZvciBuZXcgSldUIGFwcGxpY2F0aW9ucywgdGhlIHVzZSBvZiBleHBsaWNpdCB0eXBpbmcg aXMgUkVDT01NRU5ERUQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFnYWluLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN6PR00MB0301C6909630591B0BAB27DDF5CA0SN6PR00MB0301namp_-- From nobody Mon Nov 5 02:55:21 2018 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 7888512EB11 for ; Mon, 5 Nov 2018 02:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EpcUzSPjFv4s for ; Mon, 5 Nov 2018 02:55:17 -0800 (PST) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 CCC011274D0 for ; Mon, 5 Nov 2018 02:55:16 -0800 (PST) Received: from [31.133.150.222] (helo=dhcp-96de.meeting.ietf.org) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gJcXI-0007kW-T0 for oauth@ietf.org; Mon, 05 Nov 2018 11:55:13 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_A42725F3-E73A-42BF-A77D-816C96BBBFDB"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Message-Id: <2B48D704-9408-488C-9426-035F16366567@lodderstedt.net> Date: Mon, 5 Nov 2018 17:55:09 +0700 To: oauth X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] OAuth Security Workshop 2019 - Save the Date! 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, 05 Nov 2018 10:55:20 -0000 --Apple-Mail=_A42725F3-E73A-42BF-A77D-816C96BBBFDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 it has become a tradition to conduct an OAuth Security Workshop once a = year. This time it is taking place March 20=E2=80=9322, 2019 (just = before IETF-104 in Prague), in Stuttgart/Germany, and is hosted by the = Institute of Information Security (SEC) at the University of Stuttgart. And here is the workshop website: = https://sec.uni-stuttgart.de/events/osw2019 Stay tuned! kind regards, Torsten.=20= --Apple-Mail=_A42725F3-E73A-42BF-A77D-816C96BBBFDB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMDUxMDU1MTBaMC8GCSqGSIb3DQEJBDEiBCDX 0YOa4V32ru5j7u0SSdkX4Kf3t0YvusEZan1B96G4yjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAhw3oIapyplp/mxxH68PdmTpi 76nq9U5cXkRyoDRY31OUC80awb/7tAg9PqLLC0f7V8UKtfvrYRAfT4FjVJDlVklna5B5OywHXaZe WQLPI/DlhOIJ1NuEZ8sgDh1KvxDwZE0Ez6sODECtBjweroqfXsabdGTBBugUsPPQ/b0clTsBsbxN nN/pRIcptwSPXHYe7sa8Yla/pxw36CRpTCG7kZw+QSfS1Y/LrRbBqIBJjz9PauhHOZEVqGOIgDXf h01h5CAsr6hDBfmrvd5/BdfLYBDIojfdrfjAywCMt9lKAWxw77qQD0pQrMcdDsyTVc7AI8ocJEb2 seq5+zrxczo8LgAAAAAAAA== --Apple-Mail=_A42725F3-E73A-42BF-A77D-816C96BBBFDB-- From nobody Mon Nov 5 14:52:50 2018 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 8499A130EE5 for ; Mon, 5 Nov 2018 14:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCU8FyCPGy4z for ; Mon, 5 Nov 2018 14:52:41 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 DE927130DC0 for ; Mon, 5 Nov 2018 14:52:40 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id o89so17414387qko.0 for ; Mon, 05 Nov 2018 14:52:40 -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=6Fel55uaP+MyNcg9JtitajxQYqg69IqbTVXc1WOFZUg=; b=X89btyPcroi5LYHQzTJvfrIdLx8AHvnUk0yjPtbqwNWZceoIWFH/x7flTaqCznmBBT /8ab6duGubQ23IAdxDq3Zn47+nRDwR24nYFz7DXn2kR/soP38rsedBd3rzususgQjFbK DoCNToET6uadM7KHuWAabUTYGh4DHNUAQwWi3fy/Xr9lNSacLs/k/F4CgTUfVE9LkeY5 r3GIREXtineIwM6OI7qGV6P9nMiXvKc3oUk60NiKkdtLYzJMCQglhcdr7xblsryxeWQa V1Uf3eXBUvWp8ZzmigPmNJZ3xVN0R8QOkr+Sz0vdtc0nNg0gW87ksnvtHUaGqzOjmrRi CCPw== 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=6Fel55uaP+MyNcg9JtitajxQYqg69IqbTVXc1WOFZUg=; b=MZabk0Rm+b+vzSHQ+coN7k6fIjxRIQWaqdBibi4MGIy+/BLn7pOrj0Jpj4x4YomDMM heUfmr2DrV1TlJZmSGNbBu5lnssPY4fA3hdYIk7oUgTy/SijSJdZn23n4BcdwsDe35on rqrdTk077YjGXhXRVj3o+zx3qjlC7yA4Aq4Tl//9s6zD6WQTpbA5+sy2jZFzn6g+JxNC dcoeqA1WrbTxLkpwH1FxAJlqaKHb2s0rlTnp42qgI/zBi+ZSbUuGgLrpNZ0NlBfFpB37 Vxky3EqpzE7jcYeTQQet6s0VW+0xRXWtdm+64XurB1Wgkr0wlwKDiGQRDf41DFya+ht+ 5w/A== X-Gm-Message-State: AGRZ1gJQXtSCmLaZjabxqG8/LpD+XuJWHTQnIvm+jQU95aH4akTMsj5d /KxfBsECUHBRlc7LrEd7SI/uDrPxhsHh1q7+Fx00I3D8 X-Google-Smtp-Source: AJdET5fqiF/qEu2mLG0bdfdfq+tYDF/n8JYWvtIEVWqlKaWhDDlf1n6ujM2ISfvecZjIhgHGC7ezgi/c69GDdUfMQlI= X-Received: by 2002:a37:c12:: with SMTP id 18mr21898306qkm.317.1541458359440; Mon, 05 Nov 2018 14:52:39 -0800 (PST) MIME-Version: 1.0 From: Evan Gilman Date: Mon, 5 Nov 2018 14:52:28 -0800 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 22:52:49 -0000 Hello everyone. Very excited to see this draft. It helps tremendously in addressing use cases around oauth client management in machine-to-machine scenarios. Particularly, the PKI authentication method. In reviewing the document, I noticed that the only supported method for identifying a client using the PKI authentication method is by referencing its distinguished name. This caught me a bit by surprise - many newer projects aimed at automating X.509 issuance in the datacenter utilize SAN extensions rather than distinguished name in order to encode identity. I am further under the impression that the community is, in general, moving away from the subject extension altogether in favor of SAN-based identification. Full disclosure: I am one of the maintainers on a project called SPIFFE, which provides identity specifications for datacenter workload applications. For X.509, SPIFFE encodes identity into a URI SAN extension. A number of projects using SPIFFE do not configure the subject with identifying information (SPIRE and Google Istio being just a couple). I am also hearing of other X.509 automation projects which are moving away from subject/distinguished name (even if they are not using SPIFFE). While I think support for distinguished name is absolutely necessary, I worry that supporting it solely will render it incompatible with some of the more modern PKIX systems and not stand the test of time. I know that I am a little late to this, and for that I apologize... but I feel this is a significant point. I would like to open a discussion on supporting the most commonly used SAN extension types in addition to distinguished name. To accomplish this, amending section 2.1.2 `Client Registration Metadata` with additional parameters seems appropriate. In my experience, the most commonly used SAN extensions are: DNS name, IP address, URI, and email address. Are there significant drawbacks to extending the number of client registration metadata parameters? I would very much like to see this - without it, many existing projects will be unable to use the spec. I am happy to contribute time and text to this, assuming people feel that this is a beneficial addition. Sorry again for the timing -- evan From nobody Mon Nov 5 17:56:07 2018 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 2426412D4EA for ; Mon, 5 Nov 2018 17:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 p_Ja7rrgNVTs for ; Mon, 5 Nov 2018 17:56:03 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0: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 B3AC81294D0 for ; Mon, 5 Nov 2018 17:56:02 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id r12-v6so12985099ita.3 for ; Mon, 05 Nov 2018 17:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zrA8H9CfwBQ6vP93qLyFJkriax7nKpuIhMLzsQBxe5k=; b=OBXocpFvyExir8PqN3pnhYmaEUSPPV4oFn6QJucrO/bToNzyON3TFEG2tYWz9mLPTS 1f+xAUKNKqhe40lQwu3CkWzL68TZMx1YhkOJ0VJTvLaq8o9CVwjgTXYhhlpQSf98B+pm hex8eBXt1X7REp3Yi0OVI6ZPEV0sYQw+6X6+c= 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=zrA8H9CfwBQ6vP93qLyFJkriax7nKpuIhMLzsQBxe5k=; b=Bh6O5K1N6FKNOILU4WJlSpahmVXpFfB5SVsdU0Dz/1b3/jGUaRdAw+TF4BBHiI62jT cNYhbzeFsX1ePZzHJqDMc1r0Kc268oxW+YeGYGuI7LSigYv1qlAgKnEeZ+vHh/QLN2+K TmLdbOg1Wdpl4ggSzthBSlvyBYxfW95h/lD8XzHo/ouMax5tHlzz72W1g1T297DxTa9E bMJxmHmBaYOQkpAXjirj6chxKm11JJte8slHRc1ZM4161nRhrtCo+HZv8gRZFxOZqeA4 M+WC5TeECqNHQBKyEzXceyDdaAlzuE2vrPuaidk+Wce9T9/ui197cGpmzHiadtxevbnH BvUA== X-Gm-Message-State: AGRZ1gKHPm9DFAfKczlu50vbKAwbNpgrzga/r6HvlMkO9L6qnFRRD+MX erOXBlXfTTwIcOHUJD9ulQvfxieRe0YoDaLpBxkCQMQDm7v3Ph/xbXFYS0yx3YkmoIy5cVG8eXA S55dK4P+HA+z0Bw== X-Google-Smtp-Source: AJdET5d+RupMCRa50fCP2hLQg3z7Vjg4ay6H4VltwZ6o7IQzMtJCnRywnJ8Wb3X/loQLdRnGZEWIRPXWpgtgRsjBxGc= X-Received: by 2002:a02:128e:: with SMTP id 14-v6mr24325195jap.28.1541469361810; Mon, 05 Nov 2018 17:56:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Tue, 6 Nov 2018 08:55:34 +0700 Message-ID: To: Evan Gilman Cc: oauth Content-Type: multipart/alternative; boundary="000000000000be4b000579f54db4" Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 01:56:06 -0000 --000000000000be4b000579f54db4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Evan for bringing this to the WG's attention. More or less the same question/issue was raised yesterday in the area director's review of the document as well. I plan to bring this up as a discussion item in the meeting today. But my sense from some early discussions is that there is likely to be (rough) consensus to make some change in order to allow a SAN to be specified as the certificate subject identifier in the PKI client auth mode. We'll need to figure out the specifics of how that works. I don't think there are significant drawbacks to extending the number of client registration metadata parameters per se. I guess I've just been attracted to the idea of overloading the existing value because that felt like maybe a less invasive change. But perhaps that's shortsighted. And there's nothing inherently wrong with additional client metadata parameters. I don't know if we could get away with a single new parameter that could carry the value for any SAN type. Something like, { ... "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I feel like that'd probably be okay but in theory there's the potential for confusion of the value across different types. So probably there's a need to indicate the SAN type too. Either with more client metadata parameters like tls_client_auth_san_uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or maybe with a structured value of some sort like {... "tls_client_auth_san": {"type":"URI", "value":"spiffe://trust-domain/path"} ... }. And then deciding which types to support and if/how to allow for the extensible types. Anyway, those are just some thoughts on it. And it'll be discussed more today. Suggested/proposed text is always helpful though (even if it's not used directly it can help move the conversation forward and/or help editor(s) to have prospective wording). On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman wrote: > Hello everyone. > > Very excited to see this draft. It helps tremendously in addressing > use cases around oauth client management in machine-to-machine > scenarios. Particularly, the PKI authentication method. > > In reviewing the document, I noticed that the only supported method > for identifying a client using the PKI authentication method is by > referencing its distinguished name. This caught me a bit by surprise - > many newer projects aimed at automating X.509 issuance in the > datacenter utilize SAN extensions rather than distinguished name in > order to encode identity. I am further under the impression that the > community is, in general, moving away from the subject extension > altogether in favor of SAN-based identification. > > Full disclosure: I am one of the maintainers on a project called > SPIFFE, which provides identity specifications for datacenter workload > applications. For X.509, SPIFFE encodes identity into a URI SAN > extension. A number of projects using SPIFFE do not configure the > subject with identifying information (SPIRE and Google Istio being > just a couple). I am also hearing of other X.509 automation projects > which are moving away from subject/distinguished name (even if they > are not using SPIFFE). > > While I think support for distinguished name is absolutely necessary, > I worry that supporting it solely will render it incompatible with > some of the more modern PKIX systems and not stand the test of time. I > know that I am a little late to this, and for that I apologize... but > I feel this is a significant point. > > I would like to open a discussion on supporting the most commonly used > SAN extension types in addition to distinguished name. To accomplish > this, amending section 2.1.2 `Client Registration Metadata` with > additional parameters seems appropriate. In my experience, the most > commonly used SAN extensions are: DNS name, IP address, URI, and email > address. > > Are there significant drawbacks to extending the number of client > registration metadata parameters? I would very much like to see this - > without it, many existing projects will be unable to use the spec. I > am happy to contribute time and text to this, assuming people feel > that this is a beneficial addition. Sorry again for the timing > > -- > evan > > _______________________________________________ > 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._ --000000000000be4b000579f54db4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Evan for bringing this to the WG's attention. Mor= e or less the same question/issue was raised yesterday in the area director= 's review of the document as well. I plan to bring this up as a discuss= ion item in the meeting today. But my sense from some early discussions is = that there is likely to be (rough) consensus to make some change in order t= o allow a SAN to be specified as the certificate subject identifier in the = PKI client auth mode. We'll need to figure out the specifics of how tha= t works. I don't think there are significant drawbacks to extending the= number of client registration metadata parameters per se. I guess I've= just been attracted to the idea of overloading the existing value because = that felt like maybe a less invasive change. But perhaps that's shortsi= ghted. And there's nothing inherently wrong with additional client meta= data parameters.=C2=A0

I don't know if we coul= d get away with a single new parameter that could carry the value for any S= AN type. Something like, { ... "tls_client_auth_san": "spiff= e://trust-domain/path" ...}. In practice I feel like that'd probab= ly be okay but in theory there's the potential for confusion of the val= ue across different types. So probably there's a need to indicate the S= AN type too. Either with more client metadata parameters like tls_client_au= th_san_uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or mayb= e with a structured value of some sort like {... "tls_client_auth_san&= quot;: {"type":"URI", "value":"spiffe://= trust-domain/path"} ... }. And then deciding which types to support an= d if/how to allow for the extensible types.

A= nyway, those are just some thoughts on it. And it'll be discussed more = today. Suggested/proposed text is always helpful though (even if it's n= ot used directly it can help move the conversation forward and/or help edit= or(s) to have prospective wording).





On Tue, Nov 6, 2018 at 5:53 AM Evan Gilma= n <evan2645@gmai= l.com> wrote:
Hello everyone= .

Very excited to see this draft. It helps tremendously in addressing
use cases around oauth client management in machine-to-machine
scenarios. Particularly, the PKI authentication method.

In reviewing the document, I noticed that the only supported method
for identifying a client using the PKI authentication method is by
referencing its distinguished name. This caught me a bit by surprise -
many newer projects aimed at automating X.509 issuance in the
datacenter utilize SAN extensions rather than distinguished name in
order to encode identity. I am further under the impression that the
community is, in general, moving away from the subject extension
altogether in favor of SAN-based identification.

Full disclosure: I am one of the maintainers on a project called
SPIFFE, which provides identity specifications for datacenter workload
applications. For X.509, SPIFFE encodes identity into a URI SAN
extension. A number of projects using SPIFFE do not configure the
subject with identifying information (SPIRE and Google Istio being
just a couple). I am also hearing of other X.509 automation projects
which are moving away from subject/distinguished name (even if they
are not using SPIFFE).

While I think support for distinguished name is absolutely necessary,
I worry that supporting it solely will render it incompatible with
some of the more modern PKIX systems and not stand the test of time. I
know that I am a little late to this, and for that I apologize... but
I feel this is a significant point.

I would like to open a discussion on supporting the most commonly used
SAN extension types in addition to distinguished name. To accomplish
this, amending section 2.1.2 `Client Registration Metadata` with
additional parameters seems appropriate. In my experience, the most
commonly used SAN extensions are: DNS name, IP address, URI, and email
address.

Are there significant drawbacks to extending the number of client
registration metadata parameters? I would very much like to see this -
without it, many existing projects will be unable to use the spec. I
am happy to contribute time and text to this, assuming people feel
that this is a beneficial addition. Sorry again for the timing

--
evan

_______________________________________________
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. --000000000000be4b000579f54db4-- From nobody Mon Nov 5 21:19:30 2018 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 55DE8129619 for ; Mon, 5 Nov 2018 21:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Djbkg9woDHbD for ; Mon, 5 Nov 2018 21:19:27 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 712AF12D4F0 for ; Mon, 5 Nov 2018 21:19:27 -0800 (PST) X-AuditID: 1209190c-a6dff70000005694-ce-5be1245d570e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 63.D1.22164.D5421EB5; Tue, 6 Nov 2018 00:19:26 -0500 (EST) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wA65JLd7024747 for ; Tue, 6 Nov 2018 00:19:22 -0500 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id wA65JUxq016558 for ; Tue, 6 Nov 2018 00:19:30 -0500 Received: from OC11EXHUB11.exchange.mit.edu (18.9.3.25) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 6 Nov 2018 00:18:12 -0500 Received: from OC11EXPO25.exchange.mit.edu ([169.254.1.63]) by OC11EXHUB11.exchange.mit.edu ([18.9.3.25]) with mapi id 14.03.0352.000; Tue, 6 Nov 2018 00:19:19 -0500 From: Justin P Richer To: "oauth@ietf.org" Thread-Topic: AS Discovery in Distributed Draft Thread-Index: AQHUdZBEwtYfru+j+0SsQMl40PsGQg== Date: Tue, 6 Nov 2018 05:19:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.94] Content-Type: multipart/alternative; boundary="_000_CFFB07DAF9804B4795D9051BF660D736mitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBKsWRmVeSWpSXmKPExsUixG6nrhun8jDaYNdsLouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9XrS2wFE+Qrnv56wtbAOFmui5GTQ0LAROLOrN8sXYxcHEIC a5gkOk/fgHKuMEpcntrGBOHcZpT4M2k6I4SznVFi0re1zBDOSkaJ/nfX2UCGsQmoS2ybdocJ xBYRUJXYd/QKO4gtLKAl8XLpQhaIuL7ErL+9rBC2nkTfrfNgNSwCKhJ/V30Bi/MKWEn8Orsd bA6jgJjE91NrwGxmAXGJW0/mM0EcLiCxZM95ZghbVOLl43+sELasRMvnm6wQ9XESvye0skDM FJQ4OfMJywRGkVlIRs1CUjYLSdksRg6guKbE+l36ECWKElO6H7JD2BoSrXPmQtn2ElfPvGRH VrOAkWMVo2xKbpVubmJmTnFqsm5xcmJeXmqRrqFebmaJXmpK6SZGUMRxSvLsYDzzxusQowAH oxIPb0LRg2gh1sSy4srcQ4ySHExKorwdLA+jhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwKrEB lfOmJFZWpRblw6SkOViUxHkntCyOFhJITyxJzU5NLUgtgsnKcHAoSfDqKgMNFSxKTU+tSMvM KUFIM3FwggznARqeDVLDW1yQmFucmQ6RP8VoyfFoRscMZo53YPLKmc4ZzEIsefl5qVLivOwg DQIgDRmleXAzwQmUk1nwFaM40IvCvPNAqniAyRdu6iughUxAC+/JgnxTXJKIkJJqYNwz79ge 2a1+zQwTPtuJXb4rIrVL+QR7Ht/OuZE7P/bb/17BvtQhqKQ33s/WOoKT+ahXqH36Mfk+uawt LVczHu5u5Jwf66Wr+36lzR/2murTft+uiFkucZrAvGoz3412Nc0FB2Pjrte4CgYb6/HufOpT r/pra1VI5ISjLBVr5790dFKc8V1LU4mlOCPRUIu5qDgRAEsXwOh7AwAA Archived-At: Subject: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 05:19:29 -0000 --_000_CFFB07DAF9804B4795D9051BF660D736mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhlIG1lZXRpbmcgdG9uaWdodCBJIGJyb3VnaHQgdXAgYSByZXNwb25zZSB0byB0aGUgcXVl c3Rpb24gb2Ygd2hldGhlciB0byBoYXZlIGZ1bGwgVVJMIG9yIHBsYWluIGlzc3VlciBmb3IgdGhl IGF1dGggc2VydmVyIGluIHRoZSBSUyByZXNwb25zZeKAmXMgaGVhZGVyLiBNeSBzdWdnZXN0aW9u IHdhcyB0aGF0IHdlIGhhdmUgdHdvIGRpZmZlcmVudCBwYXJhbWV0ZXJzIHRvIHRoZSBoZWFkZXIg dG8gcmVwcmVzZW50IHRoZSBBUzogb25lIG9mIHRoZW0gYmVpbmcgdGhlIGZ1bGwgVVJMIChhc191 cmkpIGFuZCBvbmUgb2YgdGhlbSBiZWluZyB0aGUgaXNzdWVyIHRvIGJlIGNvbnN0cnVjdGVkIHNv bWVob3cgKGFzX2lzc3VlcikuIEkgcmFuIGludG8gYSBzaW1pbGFyIHByb2JsZW0gb24gYSBzeXN0 ZW0gdGhhdCBJIGJ1aWx0IGxhc3QgeWVhciB3aGVyZSBhbGwgb2Ygb3VyIHNlcnZlcnMgaGFkIGRp c2NvdmVyeSBkb2N1bWVudHMgYnV0IG5vdCBhbGwgb2YgdGhlbSB3ZXJlIGVhc2lseSBjb25zdHJ1 Y3RlZCBmcm9tIGFuIGlzc3VlciBzdHlsZSBVUkwgKHVzaW5nIE9JREMgcGF0dGVybnMgYW55d2F5 KS4gU28gd2Ugc29sdmVkIGl0IGJ5IGhhdmluZyB0d28gZGlmZmVyZW50IHZhcmlhYmxlcy4gSWYg dGhlIGZ1bGwgVVJMIHdhcyBzZXQsIHdlIHVzZWQgdGhhdDsgaWYgaXQgd2FzbuKAmXQsIHdlIHRy aWVkIHRoZSBpc3N1ZXI7IGlmIG5laXRoZXIgd2FzIHNldCB3ZSBkaWRu4oCZdCBkbyBhbnkgZGlz Y292ZXJ5Lg0KDQpJ4oCZbSBzZW5zaXRpdmUgdG8gVG9yc3RlbuKAmXMgY29uY2VybnMgYWJvdXQg Y29tcGxleGl0eSwgYnV0IEkgdGhpbmsgdGhpcyBpcyBhIHNpbXBsZSBhbmQgZGV0ZXJtaW5pc3Rp YyBzb2x1dGlvbiB0aGF0IHNpZGVzdGVwcyBtdWNoIG9mIHRoZSBpc3N1ZS4gTm8gcHVuIGludGVu ZGVkLg0KDQrigJQgSnVzdGluDQoNCg== --_000_CFFB07DAF9804B4795D9051BF660D736mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkluIHRoZSBtZWV0aW5nIHRvbmlnaHQgSSBicm91 Z2h0IHVwIGEgcmVzcG9uc2UgdG8gdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdG8gaGF2ZSBmdWxs IFVSTCBvciBwbGFpbiBpc3N1ZXIgZm9yIHRoZSBhdXRoIHNlcnZlciBpbiB0aGUgUlMgcmVzcG9u c2XigJlzIGhlYWRlci4gTXkgc3VnZ2VzdGlvbiB3YXMgdGhhdCB3ZSBoYXZlIHR3byBkaWZmZXJl bnQgcGFyYW1ldGVycyB0byB0aGUgaGVhZGVyIHRvIHJlcHJlc2VudCB0aGUgQVM6IG9uZSBvZiB0 aGVtDQogYmVpbmcgdGhlIGZ1bGwgVVJMIChhc191cmkpIGFuZCBvbmUgb2YgdGhlbSBiZWluZyB0 aGUgaXNzdWVyIHRvIGJlIGNvbnN0cnVjdGVkIHNvbWVob3cgKGFzX2lzc3VlcikuIEkgcmFuIGlu dG8gYSBzaW1pbGFyIHByb2JsZW0gb24gYSBzeXN0ZW0gdGhhdCBJIGJ1aWx0IGxhc3QgeWVhciB3 aGVyZSBhbGwgb2Ygb3VyIHNlcnZlcnMgaGFkIGRpc2NvdmVyeSBkb2N1bWVudHMgYnV0IG5vdCBh bGwgb2YgdGhlbSB3ZXJlIGVhc2lseSBjb25zdHJ1Y3RlZA0KIGZyb20gYW4gaXNzdWVyIHN0eWxl IFVSTCAodXNpbmcgT0lEQyBwYXR0ZXJucyBhbnl3YXkpLiBTbyB3ZSBzb2x2ZWQgaXQgYnkgaGF2 aW5nIHR3byBkaWZmZXJlbnQgdmFyaWFibGVzLiBJZiB0aGUgZnVsbCBVUkwgd2FzIHNldCwgd2Ug dXNlZCB0aGF0OyBpZiBpdCB3YXNu4oCZdCwgd2UgdHJpZWQgdGhlIGlzc3VlcjsgaWYgbmVpdGhl ciB3YXMgc2V0IHdlIGRpZG7igJl0IGRvIGFueSBkaXNjb3ZlcnkuDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBzZW5zaXRpdmUgdG8gVG9y c3RlbuKAmXMgY29uY2VybnMgYWJvdXQgY29tcGxleGl0eSwgYnV0IEkgdGhpbmsgdGhpcyBpcyBh IHNpbXBsZSBhbmQgZGV0ZXJtaW5pc3RpYyBzb2x1dGlvbiB0aGF0IHNpZGVzdGVwcyBtdWNoIG9m IHRoZSBpc3N1ZS4gTm8gcHVuIGludGVuZGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CFFB07DAF9804B4795D9051BF660D736mitedu_-- From nobody Mon Nov 5 21:35:44 2018 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 3B31E12D4F2 for ; Mon, 5 Nov 2018 21:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 AH9NKPhZ_REz for ; Mon, 5 Nov 2018 21:35:40 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E0129619 for ; Mon, 5 Nov 2018 21:35:40 -0800 (PST) Received: from [IPv6:2601:282:202:b210:24d2:4c99:bef7:cb04] (unknown [IPv6:2601:282:202:b210:24d2:4c99:bef7:cb04]) by alkaline-solutions.com (Postfix) with ESMTPSA id E09BC31682; Tue, 6 Nov 2018 05:35:39 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_19CD317F-5A61-456C-911A-7C70A8B650FE" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 5 Nov 2018 22:35:39 -0700 In-Reply-To: Cc: "oauth@ietf.org" To: Justin P Richer References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 05:35:42 -0000 --Apple-Mail=_19CD317F-5A61-456C-911A-7C70A8B650FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is there a need for a client to understand the identity of an = authorization server? This would seem to mean that the token or authorization endpoint would = need to be that identity, rather than the issuer (since now the metadata = might not be from an authoritative location) -DW > On Nov 5, 2018, at 10:19 PM, Justin P Richer wrote: >=20 > In the meeting tonight I brought up a response to the question of = whether to have full URL or plain issuer for the auth server in the RS = response=E2=80=99s header. My suggestion was that we have two different = parameters to the header to represent the AS: one of them being the full = URL (as_uri) and one of them being the issuer to be constructed somehow = (as_issuer). I ran into a similar problem on a system that I built last = year where all of our servers had discovery documents but not all of = them were easily constructed from an issuer style URL (using OIDC = patterns anyway). So we solved it by having two different variables. If = the full URL was set, we used that; if it wasn=E2=80=99t, we tried the = issuer; if neither was set we didn=E2=80=99t do any discovery. >=20 > I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, = but I think this is a simple and deterministic solution that sidesteps = much of the issue. No pun intended. >=20 > =E2=80=94 Justin >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_19CD317F-5A61-456C-911A-7C70A8B650FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Is there a need for a client to understand the identity of an = authorization server?

This would seem to mean that the token or authorization = endpoint would need to be that identity, rather than the issuer (since = now the metadata might not be from an authoritative location)

-DW

On Nov 5, 2018, at 10:19 PM, = Justin P Richer <jricher@mit.edu> wrote:

In the meeting tonight I brought up a response to the question of = whether to have full URL or plain issuer for the auth server in the RS = response=E2=80=99s header. My suggestion was that we have two different = parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be = constructed somehow (as_issuer). I ran into a similar problem on a = system that I built last year where all of our servers had discovery = documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it = by having two different variables. If the full URL was set, we used = that; if it wasn=E2=80=99t, we tried the issuer; if neither was set we = didn=E2=80=99t do any discovery.

I=E2=80=99m sensitive to Torsten=E2=80=99s concerns = about complexity, but I think this is a simple and deterministic = solution that sidesteps much of the issue. No pun intended.

=E2=80=94 Justin

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

= --Apple-Mail=_19CD317F-5A61-456C-911A-7C70A8B650FE-- From nobody Mon Nov 5 21:57:43 2018 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 16E69130DD2 for ; Mon, 5 Nov 2018 21:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 feAYZxNOCZPL for ; Mon, 5 Nov 2018 21:57:40 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E602C128CF2 for ; Mon, 5 Nov 2018 21:57:39 -0800 (PST) X-AuditID: 1209190f-77dff70000001f06-9d-5be12d52f943 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 31.12.07942.25D21EB5; Tue, 6 Nov 2018 00:57:38 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA65vaJG014309; Tue, 6 Nov 2018 00:57:37 -0500 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (W92EXEDGE5.EXCHANGE.MIT.EDU [18.7.73.22]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id wA65voLc014161; Tue, 6 Nov 2018 00:57:51 -0500 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 6 Nov 2018 00:56:46 -0500 Received: from OC11EXPO25.exchange.mit.edu ([169.254.1.63]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0352.000; Tue, 6 Nov 2018 00:57:34 -0500 From: Justin P Richer To: David Waite CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AS Discovery in Distributed Draft Thread-Index: AQHUdZBElSFnGdM690mDE7xRj+9jzqVCjcqAgAAGH4A= Date: Tue, 6 Nov 2018 05:57:33 +0000 Message-ID: <3426BA45-12CB-4C5E-BBB7-2F705998BAE7@mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.94] Content-Type: multipart/alternative; boundary="_000_3426BA4512CB4C5EBBB72F705998BAE7mitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGJsWRmVeSWpSXmKPExsUixCmqrBuk+zDaYNYaRYvF39+zWJx8+4rN gcnj/o7fTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4uuAHa8Ezp4prXXOYGhg/O3QxcnJICJhI tE6bydrFyMUhJLCGSWJv93w2CGc/o8TZbx3MEM5RRokvW88yQjjbGCXa/0+EclYySjy6OJ0V ZBibgLrEtml3mEBsEQE9iXfPbzCD2MwCqhLrV18EiwsLWEpMXf2GGaLGSuLE3YksMPbBj7fZ QGwWARWJDau/gNXwAsVbJmxnB7GFBKok/t87BlbPKeAlMXPKW7CZjAJiEt9PrWGC2CUucevJ fCaI5wQkluw5zwxhi0q8fPyPFcKWlWj5fJMVoj5O4sSV5VC7BCVOznzCMoFRfBaSUbOQlM1C UjaLkQMorimxfpc+RImixJTuh+wQtoZE65y5ULa9xL3XDezIahYwcqxilE3JrdLNTczMKU5N 1i1OTszLSy3SNdHLzSzRS00p3cQIjmZJ/h2Mcxq8DzEKcDAq8fByFDyIFmJNLCuuzD3EKMnB pCTK28HyMFqILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK8SG1A5b0piZVVqUT5MSpqDRUmcd0LL 4mghgfTEktTs1NSC1CKYrAwHh5IEb4gO0FDBotT01Iq0zJwShDQTByfIcB6g4TEgNbzFBYm5 xZnpEPlTjJYcj2Z0zGDmeAcmr5zpnMEsxJKXn5cqJc5bpw3UIADSkFGaBzcTnJzZPcVeMYoD vSjM2wsylgeY2OGmvgJayAS08J4syDfFJYkIKakGRjWtIyfT//1m+PSmqJVxwy7p60wcUdI1 m2wOzHpycNJfK59MzpO2k/4mVK+TlY/frlqa0JZ4cd7+xL/+dYpMm1q/nrjJFctevWL5U1Pf fQE3Mm6GlC2+/3+LtHtP7vXtZ++6tL+Z/vz+nvNfrvwRecGYdOPUBRmx0oaXaUmrX3I2vWbd cHxhWKMSS3FGoqEWc1FxIgDdPBipqQMAAA== Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 05:57:42 -0000 --_000_3426BA4512CB4C5EBBB72F705998BAE7mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG5lZWQgaXMgaW4gdGhlIGRpc3RyaWJ1dGVkIE9BdXRoIGRyYWZ0LCB3aGljaCBoYXMgbW9y ZSBkZXRhaWwgb2YgaXRzIHVzZSBjYXNlLiBUaGUgcHJvYmxlbSB3aXRoIHVzaW5nIGVpdGhlciB0 aGUgdG9rZW4gb3IgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyB0aGUgc29sZSBpZGVudGl0eSBv ZiB0aGUgYXV0aCBzZXJ2ZXIgaXMgdGhhdCBPYXV0aCBkb2VzbuKAmXQgc3RpY2sgdG8ganVzdCBv bmUgb2YgdGhlbSBhbmQgdGhlcmXigJlzIG5vIHNvbGlkIHdheSB0byB0aWUgdGhlbSB0b2dldGhl ciBhcGFydCBmcm9tIEFTIGRpc2NvdmVyeS4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBOb3YgNiwgMjAx OCwgYXQgMTI6MzUgQU0sIERhdmlkIFdhaXRlIDxkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29t PG1haWx0bzpkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29tPj4gd3JvdGU6DQoNCklzIHRoZXJl IGEgbmVlZCBmb3IgYSBjbGllbnQgdG8gdW5kZXJzdGFuZCB0aGUgaWRlbnRpdHkgb2YgYW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXI/DQoNClRoaXMgd291bGQgc2VlbSB0byBtZWFuIHRoYXQgdGhlIHRv a2VuIG9yIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgd291bGQgbmVlZCB0byBiZSB0aGF0IGlkZW50 aXR5LCByYXRoZXIgdGhhbiB0aGUgaXNzdWVyIChzaW5jZSBub3cgdGhlIG1ldGFkYXRhIG1pZ2h0 IG5vdCBiZSBmcm9tIGFuIGF1dGhvcml0YXRpdmUgbG9jYXRpb24pDQoNCi1EVw0KDQpPbiBOb3Yg NSwgMjAxOCwgYXQgMTA6MTkgUE0sIEp1c3RpbiBQIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1h aWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KSW4gdGhlIG1lZXRpbmcgdG9uaWdodCBJ IGJyb3VnaHQgdXAgYSByZXNwb25zZSB0byB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB0byBoYXZl IGZ1bGwgVVJMIG9yIHBsYWluIGlzc3VlciBmb3IgdGhlIGF1dGggc2VydmVyIGluIHRoZSBSUyBy ZXNwb25zZeKAmXMgaGVhZGVyLiBNeSBzdWdnZXN0aW9uIHdhcyB0aGF0IHdlIGhhdmUgdHdvIGRp ZmZlcmVudCBwYXJhbWV0ZXJzIHRvIHRoZSBoZWFkZXIgdG8gcmVwcmVzZW50IHRoZSBBUzogb25l IG9mIHRoZW0gYmVpbmcgdGhlIGZ1bGwgVVJMIChhc191cmkpIGFuZCBvbmUgb2YgdGhlbSBiZWlu ZyB0aGUgaXNzdWVyIHRvIGJlIGNvbnN0cnVjdGVkIHNvbWVob3cgKGFzX2lzc3VlcikuIEkgcmFu IGludG8gYSBzaW1pbGFyIHByb2JsZW0gb24gYSBzeXN0ZW0gdGhhdCBJIGJ1aWx0IGxhc3QgeWVh ciB3aGVyZSBhbGwgb2Ygb3VyIHNlcnZlcnMgaGFkIGRpc2NvdmVyeSBkb2N1bWVudHMgYnV0IG5v dCBhbGwgb2YgdGhlbSB3ZXJlIGVhc2lseSBjb25zdHJ1Y3RlZCBmcm9tIGFuIGlzc3VlciBzdHls ZSBVUkwgKHVzaW5nIE9JREMgcGF0dGVybnMgYW55d2F5KS4gU28gd2Ugc29sdmVkIGl0IGJ5IGhh dmluZyB0d28gZGlmZmVyZW50IHZhcmlhYmxlcy4gSWYgdGhlIGZ1bGwgVVJMIHdhcyBzZXQsIHdl IHVzZWQgdGhhdDsgaWYgaXQgd2FzbuKAmXQsIHdlIHRyaWVkIHRoZSBpc3N1ZXI7IGlmIG5laXRo ZXIgd2FzIHNldCB3ZSBkaWRu4oCZdCBkbyBhbnkgZGlzY292ZXJ5Lg0KDQpJ4oCZbSBzZW5zaXRp dmUgdG8gVG9yc3RlbuKAmXMgY29uY2VybnMgYWJvdXQgY29tcGxleGl0eSwgYnV0IEkgdGhpbmsg dGhpcyBpcyBhIHNpbXBsZSBhbmQgZGV0ZXJtaW5pc3RpYyBzb2x1dGlvbiB0aGF0IHNpZGVzdGVw cyBtdWNoIG9mIHRoZSBpc3N1ZS4gTm8gcHVuIGludGVuZGVkLg0KDQrigJQgSnVzdGluDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo= --_000_3426BA4512CB4C5EBBB72F705998BAE7mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <48EB94A10D61B043AD75B78B2FFAFB05@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoZSBuZWVkIGlzIGluIHRoZSBkaXN0cmlidXRl ZCBPQXV0aCBkcmFmdCwgd2hpY2ggaGFzIG1vcmUgZGV0YWlsIG9mIGl0cyB1c2UgY2FzZS4gVGhl IHByb2JsZW0gd2l0aCB1c2luZyBlaXRoZXIgdGhlIHRva2VuIG9yIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgYXMgdGhlIHNvbGUgaWRlbnRpdHkgb2YgdGhlIGF1dGggc2VydmVyIGlzIHRoYXQgT2F1 dGggZG9lc27igJl0IHN0aWNrIHRvIGp1c3Qgb25lIG9mIHRoZW0gYW5kIHRoZXJl4oCZcyBubyBz b2xpZA0KIHdheSB0byB0aWUgdGhlbSB0b2dldGhlciBhcGFydCBmcm9tIEFTIGRpc2NvdmVyeS4m bmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTm92IDYsIDIw MTgsIGF0IDEyOjM1IEFNLCBEYXZpZCBXYWl0ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkQGFs a2FsaW5lLXNvbHV0aW9ucy5jb20iIGNsYXNzPSIiPmRhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPklzIHRoZXJlIGEgbmVlZCBmb3IgYSBjbGllbnQg dG8gdW5kZXJzdGFuZCB0aGUgaWRlbnRpdHkgb2YgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXI/PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5U aGlzIHdvdWxkIHNlZW0gdG8gbWVhbiB0aGF0IHRoZSB0b2tlbiBvciBhdXRob3JpemF0aW9uIGVu ZHBvaW50IHdvdWxkIG5lZWQgdG8gYmUgdGhhdCBpZGVudGl0eSwgcmF0aGVyIHRoYW4gdGhlIGlz c3VlciAoc2luY2Ugbm93IHRoZSBtZXRhZGF0YSBtaWdodCBub3QgYmUgZnJvbSBhbiBhdXRob3Jp dGF0aXZlIGxvY2F0aW9uKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+LURXPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTm92IDUsIDIwMTgsIGF0IDEwOjE5 IFBNLCBKdXN0aW4gUCBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUi IGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkluIHRoZSBtZWV0aW5nIHRvbmln aHQgSSBicm91Z2h0IHVwIGEgcmVzcG9uc2UgdG8gdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdG8g aGF2ZSBmdWxsIFVSTCBvciBwbGFpbiBpc3N1ZXIgZm9yIHRoZSBhdXRoIHNlcnZlciBpbiB0aGUg UlMgcmVzcG9uc2XigJlzIGhlYWRlci4gTXkgc3VnZ2VzdGlvbiB3YXMgdGhhdCB3ZSBoYXZlIHR3 byBkaWZmZXJlbnQgcGFyYW1ldGVycyB0byB0aGUgaGVhZGVyIHRvIHJlcHJlc2VudCB0aGUgQVM6 IG9uZSBvZiB0aGVtDQogYmVpbmcgdGhlIGZ1bGwgVVJMIChhc191cmkpIGFuZCBvbmUgb2YgdGhl bSBiZWluZyB0aGUgaXNzdWVyIHRvIGJlIGNvbnN0cnVjdGVkIHNvbWVob3cgKGFzX2lzc3Vlciku IEkgcmFuIGludG8gYSBzaW1pbGFyIHByb2JsZW0gb24gYSBzeXN0ZW0gdGhhdCBJIGJ1aWx0IGxh c3QgeWVhciB3aGVyZSBhbGwgb2Ygb3VyIHNlcnZlcnMgaGFkIGRpc2NvdmVyeSBkb2N1bWVudHMg YnV0IG5vdCBhbGwgb2YgdGhlbSB3ZXJlIGVhc2lseSBjb25zdHJ1Y3RlZA0KIGZyb20gYW4gaXNz dWVyIHN0eWxlIFVSTCAodXNpbmcgT0lEQyBwYXR0ZXJucyBhbnl3YXkpLiBTbyB3ZSBzb2x2ZWQg aXQgYnkgaGF2aW5nIHR3byBkaWZmZXJlbnQgdmFyaWFibGVzLiBJZiB0aGUgZnVsbCBVUkwgd2Fz IHNldCwgd2UgdXNlZCB0aGF0OyBpZiBpdCB3YXNu4oCZdCwgd2UgdHJpZWQgdGhlIGlzc3Vlcjsg aWYgbmVpdGhlciB3YXMgc2V0IHdlIGRpZG7igJl0IGRvIGFueSBkaXNjb3ZlcnkuDQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBzZW5zaXRp dmUgdG8gVG9yc3RlbuKAmXMgY29uY2VybnMgYWJvdXQgY29tcGxleGl0eSwgYnV0IEkgdGhpbmsg dGhpcyBpcyBhIHNpbXBsZSBhbmQgZGV0ZXJtaW5pc3RpYyBzb2x1dGlvbiB0aGF0IHNpZGVzdGVw cyBtdWNoIG9mIHRoZSBpc3N1ZS4gTm8gcHVuIGludGVuZGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBj bGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_3426BA4512CB4C5EBBB72F705998BAE7mitedu_-- From nobody Mon Nov 5 23:53:35 2018 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 6CF9A130F35 for ; Mon, 5 Nov 2018 23:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ppELt5fTVsPN for ; Mon, 5 Nov 2018 23:53:18 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDD2130FBB for ; Mon, 5 Nov 2018 23:53:14 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id p2-v6so10410032wmc.2 for ; Mon, 05 Nov 2018 23:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FhZjmxq6GjyJ2ebyuQcTJ4i+3tn0a8Yq/tU2TN7IpsY=; b=Y/F9oF98QgLq+6dRZPIP7p38GXktmyh+cjH+2aqoijRxXkpHis2zoPouKzqzjMTOPl v8vfCrmkc/SrTLLkOb0fFJ7Q1Zmg0blOR39H3bXgCC4eO5pNWKG6OAbe0CDLhZhvjk4f ewLTE6PerBrRpE+QYMRjwcuFRgyAG9FjxWRSw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FhZjmxq6GjyJ2ebyuQcTJ4i+3tn0a8Yq/tU2TN7IpsY=; b=Gb1tcVGe0yA9Oek00dLZRflPEjjnJTGyAt8Zt+Rif3O9RSCjhFpEjWtPCBiQq/Kw6Y U/84OoJV4pQk20/5TRhh6NbRgbPRJ8/RvZsXSSm4xPfLapM+hQKaepk5YzhjTDp8qiME eN3ThCGDA2TgmHgpS3wj37g72nBQXsqtPErnQSVQmYhiQprCm5LqR/nzAoIyEVYlAxYB NZhAzPcLeSyF5JDm4NNaAhPI6N6WEyIdWB0HckF32sBtTJkFrxAeUK8Hqb2YkrZloKDp Kiy267bVdXKBaYXpsDxN12lQ4VNgGWY61VRddCIuK9lqbzxPMeq74lKrMMF7wWF4KGdu GI3w== X-Gm-Message-State: AGRZ1gKc6xC7i3gL6kyd0HeZlTM/m0ODC/vTKFYAzOU/LhtzUjceoaKF fXU4LQGVd4F1uy3F6nyuesiZ/w== X-Google-Smtp-Source: AJdET5d9FozE9gFqa/goS+LvF80tWrapKncvjddudblCoTr1XSsniS27pRmXUZY8huuTWjKn9wtBxQ== X-Received: by 2002:a1c:ab54:: with SMTP id u81-v6mr1039257wme.45.1541490792760; Mon, 05 Nov 2018 23:53:12 -0800 (PST) Received: from [192.168.1.65] (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id w18-v6sm15681232wrn.66.2018.11.05.23.53.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 23:53:11 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-203D89FA-74C0-4716-850A-FE88358386BD Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Tue, 6 Nov 2018 07:53:11 +0000 Cc: Evan Gilman , oauth Content-Transfer-Encoding: 7bit Message-Id: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> References: To: Brian Campbell Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 07:53:25 -0000 --Apple-Mail-203D89FA-74C0-4716-850A-FE88358386BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Is there an intention that any semantics are attached to the SAN being a URI= or DNS name or IP or ...? Or is it still intended to be an opaque identifie= r? > On 6 Nov 2018, at 01:55, Brian Campbell wrote: >=20 > Thanks Evan for bringing this to the WG's attention. More or less the same= question/issue was raised yesterday in the area director's review of the do= cument as well. I plan to bring this up as a discussion item in the meeting t= oday. But my sense from some early discussions is that there is likely to be= (rough) consensus to make some change in order to allow a SAN to be specifi= ed as the certificate subject identifier in the PKI client auth mode. We'll n= eed to figure out the specifics of how that works. I don't think there are s= ignificant drawbacks to extending the number of client registration metadata= parameters per se. I guess I've just been attracted to the idea of overload= ing the existing value because that felt like maybe a less invasive change. B= ut perhaps that's shortsighted. And there's nothing inherently wrong with ad= ditional client metadata parameters.=20 >=20 > I don't know if we could get away with a single new parameter that could c= arry the value for any SAN type. Something like, { ... "tls_client_auth_san"= : "spiffe://trust-domain/path" ...}. In practice I feel like that'd probably= be okay but in theory there's the potential for confusion of the value acro= ss different types. So probably there's a need to indicate the SAN type too.= Either with more client metadata parameters like tls_client_auth_san_uir, t= ls_client_auth_san_email, tls_client_auth_san_ip, etc. or maybe with a struc= tured value of some sort like {... "tls_client_auth_san": {"type":"URI", "va= lue":"spiffe://trust-domain/path"} ... }. And then deciding which types to s= upport and if/how to allow for the extensible types.=20 >=20 > Anyway, those are just some thoughts on it. And it'll be discussed more to= day. Suggested/proposed text is always helpful though (even if it's not used= directly it can help move the conversation forward and/or help editor(s) to= have prospective wording).=20 >=20 >=20 >=20 >=20 >=20 >> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman wrote: >> Hello everyone.. >>=20 >> Very excited to see this draft. It helps tremendously in addressing >> use cases around oauth client management in machine-to-machine >> scenarios. Particularly, the PKI authentication method. >>=20 >> In reviewing the document, I noticed that the only supported method >> for identifying a client using the PKI authentication method is by >> referencing its distinguished name. This caught me a bit by surprise - >> many newer projects aimed at automating X.509 issuance in the >> datacenter utilize SAN extensions rather than distinguished name in >> order to encode identity. I am further under the impression that the >> community is, in general, moving away from the subject extension >> altogether in favor of SAN-based identification. >>=20 >> Full disclosure: I am one of the maintainers on a project called >> SPIFFE, which provides identity specifications for datacenter workload >> applications. For X.509, SPIFFE encodes identity into a URI SAN >> extension. A number of projects using SPIFFE do not configure the >> subject with identifying information (SPIRE and Google Istio being >> just a couple). I am also hearing of other X.509 automation projects >> which are moving away from subject/distinguished name (even if they >> are not using SPIFFE). >>=20 >> While I think support for distinguished name is absolutely necessary, >> I worry that supporting it solely will render it incompatible with >> some of the more modern PKIX systems and not stand the test of time. I >> know that I am a little late to this, and for that I apologize... but >> I feel this is a significant point. >>=20 >> I would like to open a discussion on supporting the most commonly used >> SAN extension types in addition to distinguished name. To accomplish >> this, amending section 2.1.2 `Client Registration Metadata` with >> additional parameters seems appropriate. In my experience, the most >> commonly used SAN extensions are: DNS name, IP address, URI, and email >> address. >>=20 >> Are there significant drawbacks to extending the number of client >> registration metadata parameters? I would very much like to see this - >> without it, many existing projects will be unable to use the spec. I >> am happy to contribute time and text to this, assuming people feel >> that this is a beneficial addition. Sorry again for the timing >>=20 >> --=20 >> evan >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-203D89FA-74C0-4716-850A-FE88358386BD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is t= here an intention that any semantics are attached to the SAN being a URI or D= NS name or IP or ...? Or is it still intended to be an opaque identifier?

On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell=3D40pingide= ntity.com@dmarc.ietf.org> wrote:

Thanks Evan for bringing this to the WG's a= ttention. More or less the same question/issue was raised yesterday in the a= rea director's review of the document as well. I plan to bring this up as a d= iscussion item in the meeting today. But my sense from some early discussion= s is that there is likely to be (rough) consensus to make some change in ord= er to allow a SAN to be specified as the certificate subject identifier in t= he PKI client auth mode. We'll need to figure out the specifics of how that w= orks. I don't think there are significant drawbacks to extending the number o= f client registration metadata parameters per se. I guess I've just been att= racted to the idea of overloading the existing value because that felt like m= aybe a less invasive change. But perhaps that's shortsighted. And there's no= thing inherently wrong with additional client metadata parameters. 

I don't know if we could get away with a single new pa= rameter that could carry the value for any SAN type. Something like, { ... "= tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I feel l= ike that'd probably be okay but in theory there's the potential for confusio= n of the value across different types. So probably there's a need to indicat= e the SAN type too. Either with more client metadata parameters like tls_cli= ent_auth_san_uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or= maybe with a structured value of some sort like {... "tls_client_auth_san":= {"type":"URI", "value":"spiffe://trust-domain/path"} ... }. And then decidi= ng which types to support and if/how to allow for the extensible types.
=

Anyway, those are just some thoughts on it. And it= 'll be discussed more today. Suggested/proposed text is always helpful thoug= h (even if it's not used directly it can help move the conversation forward a= nd/or help editor(s) to have prospective wording).

=



<= br>
On Tue, Nov 6, 2018 at 5:53 A= M Evan Gilman <ev= an2645@gmail.com> wrote:
Hello= everyone..

Very excited to see this draft. It helps tremendously in addressing
use cases around oauth client management in machine-to-machine
scenarios. Particularly, the PKI authentication method.

In reviewing the document, I noticed that the only supported method
for identifying a client using the PKI authentication method is by
referencing its distinguished name. This caught me a bit by surprise -
many newer projects aimed at automating X.509 issuance in the
datacenter utilize SAN extensions rather than distinguished name in
order to encode identity. I am further under the impression that the
community is, in general, moving away from the subject extension
altogether in favor of SAN-based identification.

Full disclosure: I am one of the maintainers on a project called
SPIFFE, which provides identity specifications for datacenter workload
applications. For X.509, SPIFFE encodes identity into a URI SAN
extension. A number of projects using SPIFFE do not configure the
subject with identifying information (SPIRE and Google Istio being
just a couple). I am also hearing of other X.509 automation projects
which are moving away from subject/distinguished name (even if they
are not using SPIFFE).

While I think support for distinguished name is absolutely necessary,
I worry that supporting it solely will render it incompatible with
some of the more modern PKIX systems and not stand the test of time. I
know that I am a little late to this, and for that I apologize... but
I feel this is a significant point.

I would like to open a discussion on supporting the most commonly used
SAN extension types in addition to distinguished name. To accomplish
this, amending section 2.1.2 `Client Registration Metadata` with
additional parameters seems appropriate. In my experience, the most
commonly used SAN extensions are: DNS name, IP address, URI, and email
address.

Are there significant drawbacks to extending the number of client
registration metadata parameters? I would very much like to see this -
without it, many existing projects will be unable to use the spec. I
am happy to contribute time and text to this, assuming people feel
that this is a beneficial addition. Sorry again for the timing

--
evan

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

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately 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-203D89FA-74C0-4716-850A-FE88358386BD-- From nobody Tue Nov 6 01:55:28 2018 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 A5CBF130EB1 for ; Tue, 6 Nov 2018 01:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5sr0Ystj5Qz for ; Tue, 6 Nov 2018 01:55:23 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8508130FB4 for ; Tue, 6 Nov 2018 01:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vYBVK6A0Vhq20ONCKiBvgHCNIE7hhwsTKq1SfPiVokA=; b=h1oKooIKlbnFL0CNanthDJx4mHGwm5eeFkBJhVWIGiJK/2j9uXmaOBhNhrlRIPDrCzzPBJ70aSVn3MdwwK1p3zXag3VCxNSElsjKVEc/cNNW8WNPSIoLFU0q+9hg8bn0tb3ysEZDcUzmPmHFj+Z1nPIhgTxBv9MQj11FNogKejQ= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1325.eurprd08.prod.outlook.com (10.167.197.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.28; Tue, 6 Nov 2018 09:55:15 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c%2]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 09:55:15 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: draft-parecki-oauth-browser-based-apps-00 Thread-Index: AdR1tZqXsuKHZhdYRhq5sgoVL0Z8eg== Date: Tue, 6 Nov 2018 09:55:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [2001:67c:370:128:655d:cd4f:e8ef:67c2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1325; 6:j1PF+J3nVZc1u4EJzrTjEIM8gQ/mjl3JXIYTjCEdBZc7C7y/xsckz9viXd6gQat6l9/ermHRiQfhWGiEruJIsEt7TtJnTTA1IIf3aKDFSp4ASCzZ2CJD07V92Z2NYjTHW4+6zWoLQZRA2r7J22gd4xJDnG3IO3uBmb/7JfE36BkZRcf6werBhiIe2d1L93Z9fblx64KTVYeY5QAGo22f0VULP+gPIZi19avLt6Ui4vJ8VoKXEmoR1ADpGPMpDnfUkLfHC5atuPUxQD3zgMBrpwdsVLyvxRbCcBrmvnb9k0r5lNsVaytc77TjuCR/VPvWQT4HR2dYQzgAEIQklpkIvpk5F+1kyBWlTHKmmoz17MldtXBLMlGLEcxbTQPmwhtzlYL6trQZVOu2QqEWrJJr3o1rQeBcmauzrsF+Tsv+QjTIh2YJAHq7I+xvkl/qwZHwmjWwaseXgoAFMAWTFt5FMQ==; 5:qTChR/kExZoBhHa5gnnqutKB4R5O5vIvc+h3p2xveyXD3H/6fm2EDnYUVgiFmXVSvU7+dj1xc/OUx2sPHSfUE657/VRNRDM/9mq6OXEBvrtVhcG4Sj+67CEEFgYCs9NshYjO1aCPxFXbeyOHWjR0FUhgrJ4uLMdr4f5wvPwIrHQ=; 7:TE3t3LSgaIMXy3LUz/OUql4J0/NRvNtWsY7T897UEyDIt8O5KS9B6IsZa3wdF4OZUAKCJG1PdRHNcdlSa5r9wfET9EPnVynig5Idv1AfLkOpwWql5Y6/Xv5PmMAAxmO8EhnI7cNfRBnoSJ0c8wpw9w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fa8bb22c-e872-4ff3-baf8-08d643cdf393 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1325; x-ms-traffictypediagnostic: VI1PR0801MB1325: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1325; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1325; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(346002)(39860400002)(396003)(189003)(199004)(40434004)(53754006)(105586002)(66574009)(72206003)(102836004)(71200400001)(99286004)(5660300001)(81166006)(81156014)(25786009)(8676002)(97736004)(6506007)(7696005)(71190400001)(186003)(305945005)(7736002)(106356001)(74316002)(2900100001)(68736007)(33656002)(8936002)(2906002)(6116002)(86362001)(256004)(46003)(966005)(5024004)(6306002)(9686003)(478600001)(53936002)(316002)(476003)(486006)(14454004)(14444005)(6916009)(55016002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1325; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: f0gsC2bDcGYvxXftL/kRpx/KyKJTErLYc/RIdCT4s4VUOxeZkdi0GcTbAoVN90av1YyJ63EKfbKat4/38szJCVBhdaq1C7dU5xUmynMB8YHuJai7315eiwCxVSTtueCMhWDIWqnRvdg2nM2Dv6AvE2yH6GU7Tb5DdgzyECheQsvW9y0JJKFjiQpQE5WAUphAYB8D3nuSwR+k1RODWE34lXag+BFLWMXC9td07UHzhvf01BvJtFqYHlSWR8DsyIPnnYA7R7PU4VS/iICNiV0fzjxZuofTmvJfyw02tXBJapWcvZFJkT3KYrbJY7/KnL5/rTyNXVPWxfowmDe428jrFPu+JGJOCbQrL3A9uu1DyP0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa8bb22c-e872-4ff3-baf8-08d643cdf393 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 09:55:15.1834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1325 Archived-At: Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 06 Nov 2018 09:55:27 -0000 Hi all, Today we were not able to talk about draft-parecki-oauth-browser-based-apps= -00, which describes "OAuth 2.0 for Browser-Based Apps". Aaron put a few slides together, which can be found here: https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-o= auth-2-for-browser-based-apps-00.pdf Your review of this new draft is highly appreciated. 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. From nobody Tue Nov 6 02:13:58 2018 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 8B99D129AB8 for ; Tue, 6 Nov 2018 02:13:56 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsCmwXAL4Jb2 for ; Tue, 6 Nov 2018 02:13:53 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6A61277C8 for ; Tue, 6 Nov 2018 02:13:53 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id t190-v6so11316815itb.2 for ; Tue, 06 Nov 2018 02:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=altIvsF40ov2SwdS24KfwKV7NmpzS3xH9/hzhKsjsJ0=; b=sHjMbegIlWpMrtqB/uem7xMRW4/eBSUqKxSZmJwmkC0VzmE8bTOLe+624+K5og7aT4 r/bC7tNxpv0auquJRHkpi+Us8Ev0y+q5YK7VWXmsoQ/794d07CFer7LdFlsJbtf2pwYP +6CRbZuPr3r0GonxGCTJEDgntAugUEd6Q6HBqRHib+0A/udkwUcNseYzUURk3QvHYTOj OL4lmjl1Zu/vwziwcTy8GUUQoa80CkVyGexvfWlukgbY9xCFNb4zZhWCRpDvCb428Dfl waHaL7wLuOEk58rbT4TRnL0pUbZy9li55g4tTBPrJ7nYhtkWtw35BJIHWCo6vp9pWUSo h/ZQ== 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=altIvsF40ov2SwdS24KfwKV7NmpzS3xH9/hzhKsjsJ0=; b=D4isIwDLVJM/gCsWKHtB5l/vEuNS6j/6SEKAhMQ1/s/hIuS4W2npTBA/ZOlp2lBLHi Ej0uTfb1l6tixWnyMavDW/lZhWTLjbIIDho/fItBDeM5agDhBDFmTfAGJn0FUZ+sQ+J2 PyDvWhKIfhqUSX0ngSXOvn9pHh6tlp7zGfZ39UoacjZtWsGg5TheE1j1mY1MZ2qbKQsl qza3MNlvdyLbJTZ+FSZEgAT42u/BVAGqJDzQevE1FlUpsDwGgfJoyhQoa4y6psabsqoN 8+uWy3f+roZYsHO955tVEMf8FCVN8vdGPATaYeFI02Zmh8eDbSgmK//ZrnH3YqA0znK1 ajBg== X-Gm-Message-State: AGRZ1gJrAspl6cQzRaALEjUmSbLit0hf+NeU48awPTMpwaZQgvdy0hiT MTV09MN7zuZGV4x+FZrUxiH/7+69gIOHsQ== X-Google-Smtp-Source: AJdET5dDZeYNU5smM3pSz1VMwtXJeKK9Rzo9hPpIUdTKDU+N/X6u75EMbo0zve1SB36Zh9qMaiVwNg== X-Received: by 2002:a24:d93:: with SMTP id 141-v6mr1442157itx.163.1541499232261; Tue, 06 Nov 2018 02:13:52 -0800 (PST) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id w127-v6sm738368ita.38.2018.11.06.02.13.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 02:13:51 -0800 (PST) Received: by mail-io1-f53.google.com with SMTP id t81-v6so8784601iod.10 for ; Tue, 06 Nov 2018 02:13:51 -0800 (PST) X-Received: by 2002:a6b:153:: with SMTP id 80-v6mr21807909iob.290.1541499230917; Tue, 06 Nov 2018 02:13:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 6 Nov 2018 11:13:37 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="00000000000014a4180579fc429a" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 06 Nov 2018 10:13:56 -0000 --00000000000014a4180579fc429a Content-Type: text/plain; charset="UTF-8" Thanks Hannes, Since I wasn't able to give an intro during the meeting today, I'd like to share a little more context about this here as well. At the Internet Identity Workshop in Mountain View last week, I led a session to collect feedback on recommendations for OAuth for browser based apps. During the session, we came up with a list of several points based on the collective experience of the attendees. I then tried to address all those points in this draft. The goal of this is not to specify any new behavior, but rather to limit the possibilities that the existing OAuth specs provide, to ensure a secure implementation in browser based apps. Thanks in advance for your review and feedback! Aaron Parecki aaronpk.com On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig wrote: > Hi all, > > Today we were not able to talk about > draft-parecki-oauth-browser-based-apps-00, which describes "OAuth 2.0 for > Browser-Based Apps". > > Aaron put a few slides together, which can be found here: > > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf > > Your review of this new draft is highly appreciated. > > Ciao > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please 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. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ---- Aaron Parecki aaronparecki.com @aaronpk --00000000000014a4180579fc429a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Hannes,

Since I wasn't able to give an intro during the mee= ting today, I'd like to share a little more context about this here as = well.

At the Internet Id= entity Workshop in Mountain View last week, I led a session to collect feed= back on recommendations for OAuth for browser based apps. During the sessio= n, we came up with a list of several points based on the collective experie= nce of the attendees. I then tried to address all those points in this draf= t.

The goal of this is n= ot to specify any new behavior, but rather to limit the possibilities that = the existing OAuth specs provide, to ensure a secure implementation in brow= ser based apps.

Thanks i= n advance for your review and feedback!

Aaron Parecki



On Tue, Nov= 6, 2018 at 10:55 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi all,

Today we were not able to talk about draft-parecki-oauth-browser-based-apps= -00, which describes=C2=A0 "OAuth 2.0 for Browser-Based Apps".
Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-o= auth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

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.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--00000000000014a4180579fc429a-- From nobody Tue Nov 6 12:53:03 2018 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 E94F8130E08 for ; Tue, 6 Nov 2018 12:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWhepwPMW3Qa for ; Tue, 6 Nov 2018 12:52:58 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 B9BAA130DED for ; Tue, 6 Nov 2018 12:52:58 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id l9-v6so4297582qtj.12 for ; Tue, 06 Nov 2018 12:52:58 -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:content-transfer-encoding; bh=GOikaVRYGXPLZLMhiAfXxERxA+MqmntiCWClbIK3oOw=; b=js6j6G5+/eEB9ofHFwWhY2W2iKUxk9HqdOFowhLUPSSoWHy9gDQ0n3B6pOkMQfJZ3v yOAPU4kqoA1R+aDvs0GjlgZ+jaAd9sG/1rRSByXv0gSaCL+ddZOhEZIOZIumvmQ9MMml T/Yd1Ws5aS1tpkTbvewsZ8vSS85gdA0W1Du3j5CQJbya1LJIqe/R7blY88B2QS93ngRF dUZ4ynnkTk2hVyBKHpmo+fXtOllimaVVnkDcsWdPpsa7aSa3PKsMcdemhEx0D9H5QN8C eZbY61FoX7jC6vfRyTPRNdlKCZV+QKiExtwHLpCsC33E9QHE1TkpIJaCAq0dZKABC8b1 HcFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GOikaVRYGXPLZLMhiAfXxERxA+MqmntiCWClbIK3oOw=; b=R3xFI/G/crjuoPZhO6syE5KjFj1iGUQR3yoOuLyVJaT5PZak5ZL7UP7haN+DMac8St v8awpd4Vm3EPNOhDIWmON4raVplOXGTsEHyqIoNzWWalBcLqFBkdYfwWf3pDqJKL+Yl5 59vWnVkdtGJ1Q4YrL2b19zM+BYFqd16mIBWECrXedk+MTU4Eyp3vPbcZbB5qyFxrO7PD vl5Zr6iLapMMu9txlF3j9ajvbh9edDS0MF6kJnrtCCruNiLziI9ahILQHRv6T4uS5pdq pUAZaVRRegyD0lFhXyvSkN9Oug8HX3vXiyROy3ETo9v+qAaqotXni9yGfmRVEKAIOfSz 7ACw== X-Gm-Message-State: AGRZ1gJgYGTjAxk/MgUVLSP6hcC1r7SGFMSL6/1CoYVuKX4LH4gE+hMZ wKS4qCGN7Sdlwmr2ebKq5afS3lTE6CbosY6+VzZPu4kB X-Google-Smtp-Source: AJdET5f0fQmLUO7xQC3Lo/4R8tYmT7IKluXvZp/1Qz+0/y67WNud90WPQp2Lv0T1DhEyjthVNg2AFGuB5jq3RRZ2Pcg= X-Received: by 2002:ac8:25f6:: with SMTP id f51mr10357561qtf.129.1541537577587; Tue, 06 Nov 2018 12:52:57 -0800 (PST) MIME-Version: 1.0 References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> In-Reply-To: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> From: Evan Gilman Date: Tue, 6 Nov 2018 12:52:45 -0800 Message-ID: To: neil.madden@forgerock.com Cc: bcampbell=40pingidentity.com@dmarc.ietf.org, oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 20:53:01 -0000 Response(s) inline On Mon, Nov 5, 2018 at 11:53 PM Neil Madden wro= te: > > Is there an intention that any semantics are attached to the SAN being a = URI or DNS name or IP or ...? Or is it still intended to be an opaque ident= ifier? There are some extra things we could do if we attached type-specific semantics to the matching (e.g. DNS wildcarding etc), however I think that continuing to use the values as opaque identifiers would get us most of what we need while keeping things simple. > On 6 Nov 2018, at 01:55, Brian Campbell wrote: > > Thanks Evan for bringing this to the WG's attention. More or less the sam= e question/issue was raised yesterday in the area director's review of the = document as well. I plan to bring this up as a discussion item in the meeti= ng today. But my sense from some early discussions is that there is likely = to be (rough) consensus to make some change in order to allow a SAN to be s= pecified as the certificate subject identifier in the PKI client auth mode.= We'll need to figure out the specifics of how that works. I don't think th= ere are significant drawbacks to extending the number of client registratio= n metadata parameters per se. I guess I've just been attracted to the idea = of overloading the existing value because that felt like maybe a less invas= ive change. But perhaps that's shortsighted. And there's nothing inherently= wrong with additional client metadata parameters. > > I don't know if we could get away with a single new parameter that could = carry the value for any SAN type. Something like, { ... "tls_client_auth_sa= n": "spiffe://trust-domain/path" ...}. In practice I feel like that'd proba= bly be okay but in theory there's the potential for confusion of the value = across different types. So probably there's a need to indicate the SAN type= too. Either with more client metadata parameters like tls_client_auth_san_= uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or maybe with = a structured value of some sort like {... "tls_client_auth_san": {"type":"U= RI", "value":"spiffe://trust-domain/path"} ... }. And then deciding which t= ypes to support and if/how to allow for the extensible types. I am far from an authority here, but it is my understanding that one of the primary drivers in supporting SAN over Subject is that the values are strongly typed. While some of the advantages gained from this may be less useful in our own context, I feel that it make sense to keep the values separate and not overload a single value. Whether that means dedicated metadata parameters or a structured parameter value, I am not sure what the tradeoffs would be, but both options sound suitable to me. > Anyway, those are just some thoughts on it. And it'll be discussed more t= oday. Suggested/proposed text is always helpful though (even if it's not us= ed directly it can help move the conversation forward and/or help editor(s)= to have prospective wording). Great. I will work on some sample text since it sounds like that would be generally helpful > On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman wrote: >> >> Hello everyone.. >> >> Very excited to see this draft. It helps tremendously in addressing >> use cases around oauth client management in machine-to-machine >> scenarios. Particularly, the PKI authentication method. >> >> In reviewing the document, I noticed that the only supported method >> for identifying a client using the PKI authentication method is by >> referencing its distinguished name. This caught me a bit by surprise - >> many newer projects aimed at automating X.509 issuance in the >> datacenter utilize SAN extensions rather than distinguished name in >> order to encode identity. I am further under the impression that the >> community is, in general, moving away from the subject extension >> altogether in favor of SAN-based identification. >> >> Full disclosure: I am one of the maintainers on a project called >> SPIFFE, which provides identity specifications for datacenter workload >> applications. For X.509, SPIFFE encodes identity into a URI SAN >> extension. A number of projects using SPIFFE do not configure the >> subject with identifying information (SPIRE and Google Istio being >> just a couple). I am also hearing of other X.509 automation projects >> which are moving away from subject/distinguished name (even if they >> are not using SPIFFE). >> >> While I think support for distinguished name is absolutely necessary, >> I worry that supporting it solely will render it incompatible with >> some of the more modern PKIX systems and not stand the test of time. I >> know that I am a little late to this, and for that I apologize... but >> I feel this is a significant point. >> >> I would like to open a discussion on supporting the most commonly used >> SAN extension types in addition to distinguished name. To accomplish >> this, amending section 2.1.2 `Client Registration Metadata` with >> additional parameters seems appropriate. In my experience, the most >> commonly used SAN extensions are: DNS name, IP address, URI, and email >> address. >> >> Are there significant drawbacks to extending the number of client >> registration metadata parameters? I would very much like to see this - >> without it, many existing projects will be unable to use the spec. I >> am happy to contribute time and text to this, assuming people feel >> that this is a beneficial addition. Sorry again for the timing >> >> -- >> evan >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d 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 evan From nobody Tue Nov 6 13:03:33 2018 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 91EAB130E0C for ; Tue, 6 Nov 2018 13:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0a7Wc1597JRR for ; Tue, 6 Nov 2018 13:03:28 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0: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 C85E01277D2 for ; Tue, 6 Nov 2018 13:03:27 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id h13so19970654itl.1 for ; Tue, 06 Nov 2018 13:03:27 -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=sD36WHIEQgIdY2bWR/ISsLIgF1QQyq1kQYHhfdf2dMI=; b=JG6gaU8nJ9Q2r331in75OXZ4HgDFDPxDtbzkWFyMDMS6xv3ayHMaOyBBweIrdpQalk SrhztlmAoUeoqfZ0rZP+soPtLf+rRLR2xOqlCOov+PV3Vyji8D8EYnFVLqcqjH1/OFf2 k0rF2+cy8kkPlAXP0Hc5unjHSGfTPRXvvvPCa+Uj+/Yr3wbtkfD2bP7mizfpqhz687f+ jvYLZ5b5CAVkMjqXauOikzUbrvsxTLjp7W7xjCjfn+wuhpxAREJy6gRjLdCvHUfvK3DC A4ZMhY+47rG5piHXQ5XkXTfYUh3leBeBVD3IsNbiPk4OdZ+bNaqZ2iiitRsCR3pzwUKQ VzZA== 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=sD36WHIEQgIdY2bWR/ISsLIgF1QQyq1kQYHhfdf2dMI=; b=mhH90n9yfxidVYJHJxsl2UVxZqWPS5InOFSfKDAPbzJmXOuLrOpxvlyhWfjcfZFYG8 OamrjXJzLtXU1d+B+iLkZ4lEY08G2dqAFo7newfGlK2vPRts0Cd1Zhxp7tkBT6uaYbb+ G7W0CxgrrB/p8C2TFG89Q0hzQvY6J2n7rVKL+mcv7joXplQL/nPqWulF1MIUF9s8spPx q9I5aPGCQWhWZSiPlTOYaNW/52vg8TiGwbtquC1pnspO8HXlfVH0y8Kmp7gb3CwW/qSD PEefXGLhVUAB2foQZXigb5VF98n55JztIFr414+HXpgGUExIlivnzS150K3pScQWkWTE Farg== X-Gm-Message-State: AGRZ1gLMYx7KvZklmF2ci9tWZPqoeOxTBL70KxHf30OkX8aAxHemHZqp k7M4uktmc9hetfz9uBhANAJZ7Wbtjr0aiog7xhA= X-Google-Smtp-Source: AJdET5ftmipbG/Qslk7JdWRSVQIKdgYERIkdg1BdoieTrp9AN3swZOhGkb1Dz3SHEu0/Jo7dDv+r/ocPo3h24CKrBRw= X-Received: by 2002:a05:660c:247:: with SMTP id t7mr3767188itk.107.1541538207065; Tue, 06 Nov 2018 13:03:27 -0800 (PST) MIME-Version: 1.0 References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 6 Nov 2018 16:03:09 -0500 Message-ID: To: evan2645@gmail.com Cc: neil.madden@forgerock.com, bcampbell=40pingidentity.com@dmarc.ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000003d6bd1057a055572" Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 21:03:31 -0000 --0000000000003d6bd1057a055572 Content-Type: text/plain; charset="UTF-8" You might want to look at RFC6125 which covers this topic and provides recommendations for representing application in certificates: https://tools.ietf.org/html/rfc6125 Regards, Rifaat On Tue, Nov 6, 2018 at 3:53 PM Evan Gilman wrote: > Response(s) inline > > On Mon, Nov 5, 2018 at 11:53 PM Neil Madden > wrote: > > > > Is there an intention that any semantics are attached to the SAN being a > URI or DNS name or IP or ...? Or is it still intended to be an opaque > identifier? > > There are some extra things we could do if we attached type-specific > semantics to the matching (e.g. DNS wildcarding etc), however I think > that continuing to use the values as opaque identifiers would get us > most of what we need while keeping things simple. > > > On 6 Nov 2018, at 01:55, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > > > Thanks Evan for bringing this to the WG's attention. More or less the > same question/issue was raised yesterday in the area director's review of > the document as well. I plan to bring this up as a discussion item in the > meeting today. But my sense from some early discussions is that there is > likely to be (rough) consensus to make some change in order to allow a SAN > to be specified as the certificate subject identifier in the PKI client > auth mode. We'll need to figure out the specifics of how that works. I > don't think there are significant drawbacks to extending the number of > client registration metadata parameters per se. I guess I've just been > attracted to the idea of overloading the existing value because that felt > like maybe a less invasive change. But perhaps that's shortsighted. And > there's nothing inherently wrong with additional client metadata parameters. > > > > I don't know if we could get away with a single new parameter that could > carry the value for any SAN type. Something like, { ... > "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I > feel like that'd probably be okay but in theory there's the potential for > confusion of the value across different types. So probably there's a need > to indicate the SAN type too. Either with more client metadata parameters > like tls_client_auth_san_uir, tls_client_auth_san_email, > tls_client_auth_san_ip, etc. or maybe with a structured value of some sort > like {... "tls_client_auth_san": {"type":"URI", > "value":"spiffe://trust-domain/path"} ... }. And then deciding which types > to support and if/how to allow for the extensible types. > > I am far from an authority here, but it is my understanding that one > of the primary drivers in supporting SAN over Subject is that the > values are strongly typed. While some of the advantages gained from > this may be less useful in our own context, I feel that it make sense > to keep the values separate and not overload a single value. Whether > that means dedicated metadata parameters or a structured parameter > value, I am not sure what the tradeoffs would be, but both options > sound suitable to me. > > > Anyway, those are just some thoughts on it. And it'll be discussed more > today. Suggested/proposed text is always helpful though (even if it's not > used directly it can help move the conversation forward and/or help > editor(s) to have prospective wording). > > Great. I will work on some sample text since it sounds like that would > be generally helpful > > > On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman wrote: > >> > >> Hello everyone.. > >> > >> Very excited to see this draft. It helps tremendously in addressing > >> use cases around oauth client management in machine-to-machine > >> scenarios. Particularly, the PKI authentication method. > >> > >> In reviewing the document, I noticed that the only supported method > >> for identifying a client using the PKI authentication method is by > >> referencing its distinguished name. This caught me a bit by surprise - > >> many newer projects aimed at automating X.509 issuance in the > >> datacenter utilize SAN extensions rather than distinguished name in > >> order to encode identity. I am further under the impression that the > >> community is, in general, moving away from the subject extension > >> altogether in favor of SAN-based identification. > >> > >> Full disclosure: I am one of the maintainers on a project called > >> SPIFFE, which provides identity specifications for datacenter workload > >> applications. For X.509, SPIFFE encodes identity into a URI SAN > >> extension. A number of projects using SPIFFE do not configure the > >> subject with identifying information (SPIRE and Google Istio being > >> just a couple). I am also hearing of other X.509 automation projects > >> which are moving away from subject/distinguished name (even if they > >> are not using SPIFFE). > >> > >> While I think support for distinguished name is absolutely necessary, > >> I worry that supporting it solely will render it incompatible with > >> some of the more modern PKIX systems and not stand the test of time. I > >> know that I am a little late to this, and for that I apologize... but > >> I feel this is a significant point. > >> > >> I would like to open a discussion on supporting the most commonly used > >> SAN extension types in addition to distinguished name. To accomplish > >> this, amending section 2.1.2 `Client Registration Metadata` with > >> additional parameters seems appropriate. In my experience, the most > >> commonly used SAN extensions are: DNS name, IP address, URI, and email > >> address. > >> > >> Are there significant drawbacks to extending the number of client > >> registration metadata parameters? I would very much like to see this - > >> without it, many existing projects will be unable to use the spec. I > >> am happy to contribute time and text to this, assuming people feel > >> that this is a beneficial addition. Sorry again for the timing > >> > >> -- > >> evan > >> > >> _______________________________________________ > >> 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 > > > > -- > evan > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003d6bd1057a055572 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You might want to look at RFC6125 wh= ich covers this topic and provides recommendations for representing applica= tion in certificates:

R= egards,
=C2=A0Rifaat


On Tue, Nov 6, 2018 at 3:53 PM Evan Gil= man <evan2645@gmail.com> wr= ote:
Response(s) inline

On Mon, Nov 5, 2018 at 11:53 PM Neil Madden <neil.madden@forgerock.com> wrote= :
>
> Is there an intention that any semantics are attached to the SAN being= a URI or DNS name or IP or ...? Or is it still intended to be an opaque id= entifier?

There are some extra things we could do if we attached type-specific
semantics to the matching (e.g. DNS wildcarding etc), however I think
that continuing to use the values as opaque identifiers would get us
most of what we need while keeping things simple.

> On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org> wrote:
>
> Thanks Evan for bringing this to the WG's attention. More or less = the same question/issue was raised yesterday in the area director's rev= iew of the document as well. I plan to bring this up as a discussion item i= n the meeting today. But my sense from some early discussions is that there= is likely to be (rough) consensus to make some change in order to allow a = SAN to be specified as the certificate subject identifier in the PKI client= auth mode. We'll need to figure out the specifics of how that works. I= don't think there are significant drawbacks to extending the number of= client registration metadata parameters per se. I guess I've just been= attracted to the idea of overloading the existing value because that felt = like maybe a less invasive change. But perhaps that's shortsighted. And= there's nothing inherently wrong with additional client metadata param= eters.
>
> I don't know if we could get away with a single new parameter that= could carry the value for any SAN type. Something like, { ... "tls_cl= ient_auth_san": "spiffe://trust-domain/path" ...}. In practi= ce I feel like that'd probably be okay but in theory there's the po= tential for confusion of the value across different types. So probably ther= e's a need to indicate the SAN type too. Either with more client metada= ta parameters like tls_client_auth_san_uir, tls_client_auth_san_email, tls_= client_auth_san_ip, etc. or maybe with a structured value of some sort like= {... "tls_client_auth_san": {"type":"URI", &= quot;value":"spiffe://trust-domain/path"} ... }. And then de= ciding which types to support and if/how to allow for the extensible types.=

I am far from an authority here, but it is my understanding that one
of the primary drivers in supporting SAN over Subject is that the
values are strongly typed. While some of the advantages gained from
this may be less useful in our own context, I feel that it make sense
to keep the values separate and not overload a single value. Whether
that means dedicated metadata parameters or a structured parameter
value, I am not sure what the tradeoffs would be, but both options
sound suitable to me.

> Anyway, those are just some thoughts on it. And it'll be discussed= more today. Suggested/proposed text is always helpful though (even if it&#= 39;s not used directly it can help move the conversation forward and/or hel= p editor(s) to have prospective wording).

Great. I will work on some sample text since it sounds like that would
be generally helpful

> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman <evan2645@gmail.com> wrote:
>>
>> Hello everyone..
>>
>> Very excited to see this draft. It helps tremendously in addressin= g
>> use cases around oauth client management in machine-to-machine
>> scenarios. Particularly, the PKI authentication method.
>>
>> In reviewing the document, I noticed that the only supported metho= d
>> for identifying a client using the PKI authentication method is by=
>> referencing its distinguished name. This caught me a bit by surpri= se -
>> many newer projects aimed at automating X.509 issuance in the
>> datacenter utilize SAN extensions rather than distinguished name i= n
>> order to encode identity. I am further under the impression that t= he
>> community is, in general, moving away from the subject extension >> altogether in favor of SAN-based identification.
>>
>> Full disclosure: I am one of the maintainers on a project called >> SPIFFE, which provides identity specifications for datacenter work= load
>> applications. For X.509, SPIFFE encodes identity into a URI SAN >> extension. A number of projects using SPIFFE do not configure the<= br> >> subject with identifying information (SPIRE and Google Istio being=
>> just a couple). I am also hearing of other X.509 automation projec= ts
>> which are moving away from subject/distinguished name (even if the= y
>> are not using SPIFFE).
>>
>> While I think support for distinguished name is absolutely necessa= ry,
>> I worry that supporting it solely will render it incompatible with=
>> some of the more modern PKIX systems and not stand the test of tim= e. I
>> know that I am a little late to this, and for that I apologize... = but
>> I feel this is a significant point.
>>
>> I would like to open a discussion on supporting the most commonly = used
>> SAN extension types in addition to distinguished name. To accompli= sh
>> this, amending section 2.1.2 `Client Registration Metadata` with >> additional parameters seems appropriate. In my experience, the mos= t
>> commonly used SAN extensions are: DNS name, IP address, URI, and e= mail
>> address.
>>
>> Are there significant drawbacks to extending the number of client<= br> >> registration metadata parameters? I would very much like to see th= is -
>> without it, many existing projects will be unable to use the spec.= I
>> am happy to contribute time and text to this, assuming people feel=
>> that this is a beneficial addition. Sorry again for the timing
>>
>> --
>> evan
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y= ou have received this communication in error, please notify the sender imme= diately 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



--
evan

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003d6bd1057a055572-- From nobody Tue Nov 6 17:11:22 2018 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 8C9FA12870E for ; Tue, 6 Nov 2018 17:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 pXy_Cq2UrULn for ; Tue, 6 Nov 2018 17:11:17 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 BAA561277BB for ; Tue, 6 Nov 2018 17:11:16 -0800 (PST) X-AuditID: 12074422-326849e00000220e-53-5be23bb2f787 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 38.A6.08718.2BB32EB5; Tue, 6 Nov 2018 20:11:14 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA71B6Cs030845; Tue, 6 Nov 2018 20:11:12 -0500 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id wA71BEBZ018402; Tue, 6 Nov 2018 20:11:23 -0500 Received: from W92EXHUB16.exchange.mit.edu (18.7.73.27) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 6 Nov 2018 20:10:35 -0500 Received: from OC11EXPO25.exchange.mit.edu ([169.254.1.63]) by W92EXHUB16.exchange.mit.edu ([18.7.73.27]) with mapi id 14.03.0352.000; Tue, 6 Nov 2018 20:10:59 -0500 From: Justin P Richer To: Evan Gilman CC: "neil.madden@forgerock.com" , "bcampbell=40pingidentity.com@dmarc.ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls Thread-Index: AQHUdVpVz+ichRFcu0C4sSKaIlwlp6VCULkAgABj6oCAANnPgIAASCeA Date: Wed, 7 Nov 2018 01:10:59 +0000 Message-ID: <129B91F9-E471-4AE4-98D3-F534D6BF09C1@mit.edu> References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.81] Content-Type: multipart/alternative; boundary="_000_129B91F9E4714AE498D3F534D6BF09C1mitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01TWUwTURTNmxmmU8KYoVD6rO2HI4mCYBU1qbhg3FL5UT+VRB3t2Da2hcwU pSQmUHc0LnErlU2ouGEIRNlcMBUSqUYwkggUURCjFiWiJu7UmU4Rfl7Ovefcc3Lz3iNQRROu Jix2B8vZGSuNR2MKuXJWav3Soaz5bX3J+rpAOa7v9BXJ9CVlv3B9x6cgvhIzPKrujjL0HKoA hmbPS5nB6/2JbMS2RC8zslbLHpbTrdgeba7oHMRyXGVonut5EC0AF8+gRUBOQGoRHBnz40Ug mlBQNQi81V+HSEUrgC2/PwGpaAfwa6AwImsEsCt4FZOKawD63/fiohlOzYYN5/sREcdTibD5 XSg8jlLPACz5+BQTiThqGRz4djUiWg6bL97BJbwO3vgRCPcxYdg1XCgTMUmlw4aHQ5Hocwjc X1cJREJObYINL9rCpoBKgN/9NeFhlFLBvuFyRFqPgt67nZFVlfDDm/EoCWthxV9RTwj6rfDy 8SQpKxZ2FA9jp4DKM8XJM6nyTFFJ7SRY26KT1DPh2WODMgnPgQdLSiM4A7beD6JTNRWAuA60 Rlt+qo2xWHl2Zyq/k7HbWS518TybxTGPNebWA/HyZWvoJnB6PNMHKALQMWTX7cEsRRSzh3fa fGA6gdBK0lQttKbtyDY6zQxv3sblWlneByCB0vHk4xsCRxoZZz7LZU9QMwiMVpGnD1RlKSgT 42B3s2wOy02wGoKgIZmRPpSliOVYE5u3y2J1TNIIIRfNYwRzlagh+RzGxltMEu8Ha4kjl0IX UGLIfcSNEqPhs/vJUeH8WPrDjSowe7adVatIWhymxGFzrv2/f/jBy9ZTQaAS1o0jG0RVjPAd /icEhXBECB/QvhbDHcwkpS4AmlFtX2tMgml15Zmgz3gz1BRqTFk9mng94eu6tC+1tOkeq/Qb 3B/SrriSVurUYGx+e5Ny3/RV6NslZsWr/A7ZHVvQcq+35/DCXYnx1Ser5MXVGvt4mW7vU/NI njZh0Z8LB+syXQHjXK+m9255coo3Iz39VPMcX8+GB5WfT5Q6N9MYb2YWJKMcz/wDOPS/gMsD AAA= Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 01:11:20 -0000 --_000_129B91F9E4714AE498D3F534D6BF09C1mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V291bGQgaXQgbWFrZSBzZW5zZSBmb3IgdGhlc2UgdG8gYmUgYSBkaWZmZXJlbnQgY2xpZW50X2F1 dGhfbWV0aG9kIGVudGlyZWx5PyBNdWNoIHRoZSBzYW1lIHdheSB0aGF0IHdlIGhhdmUgcHJpdmF0 ZV9rZXlfand0IGFuZCBjbGllbnRfc2VjcmV0X2p3dCB0b2RheSwgYm90aCBvZiB3aGljaCB1c2Ug dGhlIEpXVCBhc3NlcnRpb24gZnJhbWV3b3JrIGJ1dCBoYXZlIHZlcnkgZGlmZmVyZW50IGtleWlu ZyBhbmQgc2VjdXJpdHkgYXNzdW1wdGlvbnMuIEluIHRoZSBzYW1lIHdheSwgaGVyZSB5b3XigJly ZSBzdGlsbCB2YWxpZGF0aW5nIHRoZSBjZXJ0IGJ1dCB0aGUgbWVhbnMgYnkgd2hpY2ggaXTigJlz IHZhbGlkYXRlZCBpcyBkaWZmZXJlbnQsIHNvIHRoZSBhdXRoIG1ldGhvZCBpcyBhcmd1YWJseSBu b3QgZ29pbmcgdG8gYmVuZWZpdCBmcm9tIGJlaW5nIG92ZXJsb2FkZWQuIENhdmVhdCwgSeKAmXZl IG5vdCBidWlsdCBvdXQgYSBzeXN0ZW0gdXNpbmcgU0FOcyBpbiBhbnkgbWVhbmluZ2Z1bCB3YXku DQoNCklmIHdlIHdlcmUgdG8gZG8gdGhhdCwgdGhpcyBkcmFmdCBjb3VsZCBnbyBmb3J3YXJkIGFz LWlzIChzaW5jZSBpdOKAmXMgZmFpcmx5IGRvbmUgaW4gbXkgb3BpbmlvbikgYW5kIGEgbmV3IGRv Y3VtZW50IGNvdWxkIGJldHRlciBkZWZpbmUgdGhlIHNlbWFudGljcyBmb3IgdGhlIHZhcmlvdXMg U0FOIHR5cGVzLCBidXQgd2hpbGUgYnVpbGRpbmcgb24gdGhlIGZyYW1ld29yayBhbmQgY29uY2Vw dHMgbGlzdGVkIGluIGhlcmUuDQoNCuKAlCBKdXN0aW4NCg0KT24gTm92IDYsIDIwMTgsIGF0IDM6 NTIgUE0sIEV2YW4gR2lsbWFuIDxldmFuMjY0NUBnbWFpbC5jb208bWFpbHRvOmV2YW4yNjQ1QGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpSZXNwb25zZShzKSBpbmxpbmUNCg0KT24gTW9uLCBOb3YgNSwg MjAxOCBhdCAxMTo1MyBQTSBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTxt YWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4+IHdyb3RlOg0KDQpJcyB0aGVyZSBhbiBp bnRlbnRpb24gdGhhdCBhbnkgc2VtYW50aWNzIGFyZSBhdHRhY2hlZCB0byB0aGUgU0FOIGJlaW5n IGEgVVJJIG9yIEROUyBuYW1lIG9yIElQIG9yIC4uLj8gT3IgaXMgaXQgc3RpbGwgaW50ZW5kZWQg dG8gYmUgYW4gb3BhcXVlIGlkZW50aWZpZXI/DQoNClRoZXJlIGFyZSBzb21lIGV4dHJhIHRoaW5n cyB3ZSBjb3VsZCBkbyBpZiB3ZSBhdHRhY2hlZCB0eXBlLXNwZWNpZmljDQpzZW1hbnRpY3MgdG8g dGhlIG1hdGNoaW5nIChlLmcuIEROUyB3aWxkY2FyZGluZyBldGMpLCBob3dldmVyIEkgdGhpbmsN CnRoYXQgY29udGludWluZyB0byB1c2UgdGhlIHZhbHVlcyBhcyBvcGFxdWUgaWRlbnRpZmllcnMg d291bGQgZ2V0IHVzDQptb3N0IG9mIHdoYXQgd2UgbmVlZCB3aGlsZSBrZWVwaW5nIHRoaW5ncyBz aW1wbGUuDQoNCk9uIDYgTm92IDIwMTgsIGF0IDAxOjU1LCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBi ZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86YmNhbXBiZWxsPTQw cGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpUaGFua3MgRXZhbiBm b3IgYnJpbmdpbmcgdGhpcyB0byB0aGUgV0cncyBhdHRlbnRpb24uIE1vcmUgb3IgbGVzcyB0aGUg c2FtZSBxdWVzdGlvbi9pc3N1ZSB3YXMgcmFpc2VkIHllc3RlcmRheSBpbiB0aGUgYXJlYSBkaXJl Y3RvcidzIHJldmlldyBvZiB0aGUgZG9jdW1lbnQgYXMgd2VsbC4gSSBwbGFuIHRvIGJyaW5nIHRo aXMgdXAgYXMgYSBkaXNjdXNzaW9uIGl0ZW0gaW4gdGhlIG1lZXRpbmcgdG9kYXkuIEJ1dCBteSBz ZW5zZSBmcm9tIHNvbWUgZWFybHkgZGlzY3Vzc2lvbnMgaXMgdGhhdCB0aGVyZSBpcyBsaWtlbHkg dG8gYmUgKHJvdWdoKSBjb25zZW5zdXMgdG8gbWFrZSBzb21lIGNoYW5nZSBpbiBvcmRlciB0byBh bGxvdyBhIFNBTiB0byBiZSBzcGVjaWZpZWQgYXMgdGhlIGNlcnRpZmljYXRlIHN1YmplY3QgaWRl bnRpZmllciBpbiB0aGUgUEtJIGNsaWVudCBhdXRoIG1vZGUuIFdlJ2xsIG5lZWQgdG8gZmlndXJl IG91dCB0aGUgc3BlY2lmaWNzIG9mIGhvdyB0aGF0IHdvcmtzLiBJIGRvbid0IHRoaW5rIHRoZXJl IGFyZSBzaWduaWZpY2FudCBkcmF3YmFja3MgdG8gZXh0ZW5kaW5nIHRoZSBudW1iZXIgb2YgY2xp ZW50IHJlZ2lzdHJhdGlvbiBtZXRhZGF0YSBwYXJhbWV0ZXJzIHBlciBzZS4gSSBndWVzcyBJJ3Zl IGp1c3QgYmVlbiBhdHRyYWN0ZWQgdG8gdGhlIGlkZWEgb2Ygb3ZlcmxvYWRpbmcgdGhlIGV4aXN0 aW5nIHZhbHVlIGJlY2F1c2UgdGhhdCBmZWx0IGxpa2UgbWF5YmUgYSBsZXNzIGludmFzaXZlIGNo YW5nZS4gQnV0IHBlcmhhcHMgdGhhdCdzIHNob3J0c2lnaHRlZC4gQW5kIHRoZXJlJ3Mgbm90aGlu ZyBpbmhlcmVudGx5IHdyb25nIHdpdGggYWRkaXRpb25hbCBjbGllbnQgbWV0YWRhdGEgcGFyYW1l dGVycy4NCg0KSSBkb24ndCBrbm93IGlmIHdlIGNvdWxkIGdldCBhd2F5IHdpdGggYSBzaW5nbGUg bmV3IHBhcmFtZXRlciB0aGF0IGNvdWxkIGNhcnJ5IHRoZSB2YWx1ZSBmb3IgYW55IFNBTiB0eXBl LiBTb21ldGhpbmcgbGlrZSwgeyAuLi4gInRsc19jbGllbnRfYXV0aF9zYW4iOiAic3BpZmZlOi8v dHJ1c3QtZG9tYWluL3BhdGgiIC4uLn0uIEluIHByYWN0aWNlIEkgZmVlbCBsaWtlIHRoYXQnZCBw cm9iYWJseSBiZSBva2F5IGJ1dCBpbiB0aGVvcnkgdGhlcmUncyB0aGUgcG90ZW50aWFsIGZvciBj b25mdXNpb24gb2YgdGhlIHZhbHVlIGFjcm9zcyBkaWZmZXJlbnQgdHlwZXMuIFNvIHByb2JhYmx5 IHRoZXJlJ3MgYSBuZWVkIHRvIGluZGljYXRlIHRoZSBTQU4gdHlwZSB0b28uIEVpdGhlciB3aXRo IG1vcmUgY2xpZW50IG1ldGFkYXRhIHBhcmFtZXRlcnMgbGlrZSB0bHNfY2xpZW50X2F1dGhfc2Fu X3VpciwgdGxzX2NsaWVudF9hdXRoX3Nhbl9lbWFpbCwgdGxzX2NsaWVudF9hdXRoX3Nhbl9pcCwg ZXRjLiBvciBtYXliZSB3aXRoIGEgc3RydWN0dXJlZCB2YWx1ZSBvZiBzb21lIHNvcnQgbGlrZSB7 Li4uICJ0bHNfY2xpZW50X2F1dGhfc2FuIjogeyJ0eXBlIjoiVVJJIiwgInZhbHVlIjoic3BpZmZl Oi8vdHJ1c3QtZG9tYWluL3BhdGgifSAuLi4gfS4gQW5kIHRoZW4gZGVjaWRpbmcgd2hpY2ggdHlw ZXMgdG8gc3VwcG9ydCBhbmQgaWYvaG93IHRvIGFsbG93IGZvciB0aGUgZXh0ZW5zaWJsZSB0eXBl cy4NCg0KSSBhbSBmYXIgZnJvbSBhbiBhdXRob3JpdHkgaGVyZSwgYnV0IGl0IGlzIG15IHVuZGVy c3RhbmRpbmcgdGhhdCBvbmUNCm9mIHRoZSBwcmltYXJ5IGRyaXZlcnMgaW4gc3VwcG9ydGluZyBT QU4gb3ZlciBTdWJqZWN0IGlzIHRoYXQgdGhlDQp2YWx1ZXMgYXJlIHN0cm9uZ2x5IHR5cGVkLiBX aGlsZSBzb21lIG9mIHRoZSBhZHZhbnRhZ2VzIGdhaW5lZCBmcm9tDQp0aGlzIG1heSBiZSBsZXNz IHVzZWZ1bCBpbiBvdXIgb3duIGNvbnRleHQsIEkgZmVlbCB0aGF0IGl0IG1ha2Ugc2Vuc2UNCnRv IGtlZXAgdGhlIHZhbHVlcyBzZXBhcmF0ZSBhbmQgbm90IG92ZXJsb2FkIGEgc2luZ2xlIHZhbHVl LiBXaGV0aGVyDQp0aGF0IG1lYW5zIGRlZGljYXRlZCBtZXRhZGF0YSBwYXJhbWV0ZXJzIG9yIGEg c3RydWN0dXJlZCBwYXJhbWV0ZXINCnZhbHVlLCBJIGFtIG5vdCBzdXJlIHdoYXQgdGhlIHRyYWRl b2ZmcyB3b3VsZCBiZSwgYnV0IGJvdGggb3B0aW9ucw0Kc291bmQgc3VpdGFibGUgdG8gbWUuDQoN CkFueXdheSwgdGhvc2UgYXJlIGp1c3Qgc29tZSB0aG91Z2h0cyBvbiBpdC4gQW5kIGl0J2xsIGJl IGRpc2N1c3NlZCBtb3JlIHRvZGF5LiBTdWdnZXN0ZWQvcHJvcG9zZWQgdGV4dCBpcyBhbHdheXMg aGVscGZ1bCB0aG91Z2ggKGV2ZW4gaWYgaXQncyBub3QgdXNlZCBkaXJlY3RseSBpdCBjYW4gaGVs cCBtb3ZlIHRoZSBjb252ZXJzYXRpb24gZm9yd2FyZCBhbmQvb3IgaGVscCBlZGl0b3IocykgdG8g aGF2ZSBwcm9zcGVjdGl2ZSB3b3JkaW5nKS4NCg0KR3JlYXQuIEkgd2lsbCB3b3JrIG9uIHNvbWUg c2FtcGxlIHRleHQgc2luY2UgaXQgc291bmRzIGxpa2UgdGhhdCB3b3VsZA0KYmUgZ2VuZXJhbGx5 IGhlbHBmdWwNCg0KT24gVHVlLCBOb3YgNiwgMjAxOCBhdCA1OjUzIEFNIEV2YW4gR2lsbWFuIDxl dmFuMjY0NUBnbWFpbC5jb208bWFpbHRvOmV2YW4yNjQ1QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpI ZWxsbyBldmVyeW9uZS4uDQoNClZlcnkgZXhjaXRlZCB0byBzZWUgdGhpcyBkcmFmdC4gSXQgaGVs cHMgdHJlbWVuZG91c2x5IGluIGFkZHJlc3NpbmcNCnVzZSBjYXNlcyBhcm91bmQgb2F1dGggY2xp ZW50IG1hbmFnZW1lbnQgaW4gbWFjaGluZS10by1tYWNoaW5lDQpzY2VuYXJpb3MuIFBhcnRpY3Vs YXJseSwgdGhlIFBLSSBhdXRoZW50aWNhdGlvbiBtZXRob2QuDQoNCkluIHJldmlld2luZyB0aGUg ZG9jdW1lbnQsIEkgbm90aWNlZCB0aGF0IHRoZSBvbmx5IHN1cHBvcnRlZCBtZXRob2QNCmZvciBp ZGVudGlmeWluZyBhIGNsaWVudCB1c2luZyB0aGUgUEtJIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBp cyBieQ0KcmVmZXJlbmNpbmcgaXRzIGRpc3Rpbmd1aXNoZWQgbmFtZS4gVGhpcyBjYXVnaHQgbWUg YSBiaXQgYnkgc3VycHJpc2UgLQ0KbWFueSBuZXdlciBwcm9qZWN0cyBhaW1lZCBhdCBhdXRvbWF0 aW5nIFguNTA5IGlzc3VhbmNlIGluIHRoZQ0KZGF0YWNlbnRlciB1dGlsaXplIFNBTiBleHRlbnNp b25zIHJhdGhlciB0aGFuIGRpc3Rpbmd1aXNoZWQgbmFtZSBpbg0Kb3JkZXIgdG8gZW5jb2RlIGlk ZW50aXR5LiBJIGFtIGZ1cnRoZXIgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUNCmNvbW11 bml0eSBpcywgaW4gZ2VuZXJhbCwgbW92aW5nIGF3YXkgZnJvbSB0aGUgc3ViamVjdCBleHRlbnNp b24NCmFsdG9nZXRoZXIgaW4gZmF2b3Igb2YgU0FOLWJhc2VkIGlkZW50aWZpY2F0aW9uLg0KDQpG dWxsIGRpc2Nsb3N1cmU6IEkgYW0gb25lIG9mIHRoZSBtYWludGFpbmVycyBvbiBhIHByb2plY3Qg Y2FsbGVkDQpTUElGRkUsIHdoaWNoIHByb3ZpZGVzIGlkZW50aXR5IHNwZWNpZmljYXRpb25zIGZv ciBkYXRhY2VudGVyIHdvcmtsb2FkDQphcHBsaWNhdGlvbnMuIEZvciBYLjUwOSwgU1BJRkZFIGVu Y29kZXMgaWRlbnRpdHkgaW50byBhIFVSSSBTQU4NCmV4dGVuc2lvbi4gQSBudW1iZXIgb2YgcHJv amVjdHMgdXNpbmcgU1BJRkZFIGRvIG5vdCBjb25maWd1cmUgdGhlDQpzdWJqZWN0IHdpdGggaWRl bnRpZnlpbmcgaW5mb3JtYXRpb24gKFNQSVJFIGFuZCBHb29nbGUgSXN0aW8gYmVpbmcNCmp1c3Qg YSBjb3VwbGUpLiBJIGFtIGFsc28gaGVhcmluZyBvZiBvdGhlciBYLjUwOSBhdXRvbWF0aW9uIHBy b2plY3RzDQp3aGljaCBhcmUgbW92aW5nIGF3YXkgZnJvbSBzdWJqZWN0L2Rpc3Rpbmd1aXNoZWQg bmFtZSAoZXZlbiBpZiB0aGV5DQphcmUgbm90IHVzaW5nIFNQSUZGRSkuDQoNCldoaWxlIEkgdGhp bmsgc3VwcG9ydCBmb3IgZGlzdGluZ3Vpc2hlZCBuYW1lIGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5 LA0KSSB3b3JyeSB0aGF0IHN1cHBvcnRpbmcgaXQgc29sZWx5IHdpbGwgcmVuZGVyIGl0IGluY29t cGF0aWJsZSB3aXRoDQpzb21lIG9mIHRoZSBtb3JlIG1vZGVybiBQS0lYIHN5c3RlbXMgYW5kIG5v dCBzdGFuZCB0aGUgdGVzdCBvZiB0aW1lLiBJDQprbm93IHRoYXQgSSBhbSBhIGxpdHRsZSBsYXRl IHRvIHRoaXMsIGFuZCBmb3IgdGhhdCBJIGFwb2xvZ2l6ZS4uLiBidXQNCkkgZmVlbCB0aGlzIGlz IGEgc2lnbmlmaWNhbnQgcG9pbnQuDQoNCkkgd291bGQgbGlrZSB0byBvcGVuIGEgZGlzY3Vzc2lv biBvbiBzdXBwb3J0aW5nIHRoZSBtb3N0IGNvbW1vbmx5IHVzZWQNClNBTiBleHRlbnNpb24gdHlw ZXMgaW4gYWRkaXRpb24gdG8gZGlzdGluZ3Vpc2hlZCBuYW1lLiBUbyBhY2NvbXBsaXNoDQp0aGlz LCBhbWVuZGluZyBzZWN0aW9uIDIuMS4yIGBDbGllbnQgUmVnaXN0cmF0aW9uIE1ldGFkYXRhYCB3 aXRoDQphZGRpdGlvbmFsIHBhcmFtZXRlcnMgc2VlbXMgYXBwcm9wcmlhdGUuIEluIG15IGV4cGVy aWVuY2UsIHRoZSBtb3N0DQpjb21tb25seSB1c2VkIFNBTiBleHRlbnNpb25zIGFyZTogRE5TIG5h bWUsIElQIGFkZHJlc3MsIFVSSSwgYW5kIGVtYWlsDQphZGRyZXNzLg0KDQpBcmUgdGhlcmUgc2ln bmlmaWNhbnQgZHJhd2JhY2tzIHRvIGV4dGVuZGluZyB0aGUgbnVtYmVyIG9mIGNsaWVudA0KcmVn aXN0cmF0aW9uIG1ldGFkYXRhIHBhcmFtZXRlcnM/IEkgd291bGQgdmVyeSBtdWNoIGxpa2UgdG8g c2VlIHRoaXMgLQ0Kd2l0aG91dCBpdCwgbWFueSBleGlzdGluZyBwcm9qZWN0cyB3aWxsIGJlIHVu YWJsZSB0byB1c2UgdGhlIHNwZWMuIEkNCmFtIGhhcHB5IHRvIGNvbnRyaWJ1dGUgdGltZSBhbmQg dGV4dCB0byB0aGlzLCBhc3N1bWluZyBwZW9wbGUgZmVlbA0KdGhhdCB0aGlzIGlzIGEgYmVuZWZp Y2lhbCBhZGRpdGlvbi4gU29ycnkgYWdhaW4gZm9yIHRoZSB0aW1pbmcNCg0KLS0NCmV2YW4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi eSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMg ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpldmFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0K --_000_129B91F9E4714AE498D3F534D6BF09C1mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldvdWxkIGl0IG1ha2Ugc2Vuc2UgZm9yIHRoZXNl IHRvIGJlIGEgZGlmZmVyZW50IGNsaWVudF9hdXRoX21ldGhvZCBlbnRpcmVseT8gTXVjaCB0aGUg c2FtZSB3YXkgdGhhdCB3ZSBoYXZlIHByaXZhdGVfa2V5X2p3dCBhbmQgY2xpZW50X3NlY3JldF9q d3QgdG9kYXksIGJvdGggb2Ygd2hpY2ggdXNlIHRoZSBKV1QgYXNzZXJ0aW9uIGZyYW1ld29yayBi dXQgaGF2ZSB2ZXJ5IGRpZmZlcmVudCBrZXlpbmcgYW5kIHNlY3VyaXR5IGFzc3VtcHRpb25zLiBJ bg0KIHRoZSBzYW1lIHdheSwgaGVyZSB5b3XigJlyZSBzdGlsbCB2YWxpZGF0aW5nIHRoZSBjZXJ0 IGJ1dCB0aGUgbWVhbnMgYnkgd2hpY2ggaXTigJlzIHZhbGlkYXRlZCBpcyBkaWZmZXJlbnQsIHNv IHRoZSBhdXRoIG1ldGhvZCBpcyBhcmd1YWJseSBub3QgZ29pbmcgdG8gYmVuZWZpdCBmcm9tIGJl aW5nIG92ZXJsb2FkZWQuIENhdmVhdCwgSeKAmXZlIG5vdCBidWlsdCBvdXQgYSBzeXN0ZW0gdXNp bmcgU0FOcyBpbiBhbnkgbWVhbmluZ2Z1bCB3YXkuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiB3ZSB3ZXJlIHRvIGRvIHRoYXQsIHRo aXMgZHJhZnQgY291bGQgZ28gZm9yd2FyZCBhcy1pcyAoc2luY2UgaXTigJlzIGZhaXJseSBkb25l IGluIG15IG9waW5pb24pIGFuZCBhIG5ldyBkb2N1bWVudCBjb3VsZCBiZXR0ZXIgZGVmaW5lIHRo ZSBzZW1hbnRpY3MgZm9yIHRoZSB2YXJpb3VzIFNBTiB0eXBlcywgYnV0IHdoaWxlIGJ1aWxkaW5n IG9uIHRoZSBmcmFtZXdvcmsgYW5kIGNvbmNlcHRzIGxpc3RlZCBpbiBoZXJlLiZuYnNwOzxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTm92IDYs IDIwMTgsIGF0IDM6NTIgUE0sIEV2YW4gR2lsbWFuICZsdDs8YSBocmVmPSJtYWlsdG86ZXZhbjI2 NDVAZ21haWwuY29tIiBjbGFzcz0iIj5ldmFuMjY0NUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlJlc3BvbnNlKHMpDQogaW5s aW5lPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T24NCiBNb24sIE5vdiA1LCAyMDE4 IGF0IDExOjUzIFBNIE5laWwgTWFkZGVuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5laWwu bWFkZGVuQGZvcmdlcm9jay5jb20iIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPm5laWwubWFkZGVuQGZvcmdlcm9jay5jb208L2E+PHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48YnIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklzIHRo ZXJlIGFuIGludGVudGlvbiB0aGF0IGFueSBzZW1hbnRpY3MgYXJlIGF0dGFjaGVkIHRvIHRoZSBT QU4gYmVpbmcgYSBVUkkgb3IgRE5TIG5hbWUgb3IgSVAgb3IgLi4uPyBPciBpcyBpdCBzdGlsbCBp bnRlbmRlZCB0byBiZSBhbiBvcGFxdWUgaWRlbnRpZmllcj88YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+VGhlcmUNCiBhcmUgc29tZSBl eHRyYSB0aGluZ3Mgd2UgY291bGQgZG8gaWYgd2UgYXR0YWNoZWQgdHlwZS1zcGVjaWZpYzwvc3Bh bj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3Bs YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+c2VtYW50aWNzDQogdG8gdGhlIG1hdGNo aW5nIChlLmcuIEROUyB3aWxkY2FyZGluZyBldGMpLCBob3dldmVyIEkgdGhpbms8L3NwYW4+PGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnRoYXQNCiBjb250aW51aW5nIHRvIHVzZSB0aGUg dmFsdWVzIGFzIG9wYXF1ZSBpZGVudGlmaWVycyB3b3VsZCBnZXQgdXM8L3NwYW4+PGJyIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPm1vc3QNCiBvZiB3aGF0IHdlIG5lZWQgd2hpbGUga2VlcGlu ZyB0aGluZ3Mgc2ltcGxlLjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQpPbiA2IE5vdiAyMDE4LCBhdCAwMTo1NSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9 Im1haWx0bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnIiBjbGFz cz0iIj5iY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzIEV2YW4gZm9yIGJyaW5n aW5nIHRoaXMgdG8gdGhlIFdHJ3MgYXR0ZW50aW9uLiBNb3JlIG9yIGxlc3MgdGhlIHNhbWUgcXVl c3Rpb24vaXNzdWUgd2FzIHJhaXNlZCB5ZXN0ZXJkYXkgaW4gdGhlIGFyZWEgZGlyZWN0b3IncyBy ZXZpZXcgb2YgdGhlIGRvY3VtZW50IGFzIHdlbGwuIEkgcGxhbiB0byBicmluZyB0aGlzIHVwIGFz IGEgZGlzY3Vzc2lvbiBpdGVtIGluIHRoZSBtZWV0aW5nIHRvZGF5LiBCdXQgbXkgc2Vuc2UgZnJv bSBzb21lIGVhcmx5DQogZGlzY3Vzc2lvbnMgaXMgdGhhdCB0aGVyZSBpcyBsaWtlbHkgdG8gYmUg KHJvdWdoKSBjb25zZW5zdXMgdG8gbWFrZSBzb21lIGNoYW5nZSBpbiBvcmRlciB0byBhbGxvdyBh IFNBTiB0byBiZSBzcGVjaWZpZWQgYXMgdGhlIGNlcnRpZmljYXRlIHN1YmplY3QgaWRlbnRpZmll ciBpbiB0aGUgUEtJIGNsaWVudCBhdXRoIG1vZGUuIFdlJ2xsIG5lZWQgdG8gZmlndXJlIG91dCB0 aGUgc3BlY2lmaWNzIG9mIGhvdyB0aGF0IHdvcmtzLiBJIGRvbid0IHRoaW5rDQogdGhlcmUgYXJl IHNpZ25pZmljYW50IGRyYXdiYWNrcyB0byBleHRlbmRpbmcgdGhlIG51bWJlciBvZiBjbGllbnQg cmVnaXN0cmF0aW9uIG1ldGFkYXRhIHBhcmFtZXRlcnMgcGVyIHNlLiBJIGd1ZXNzIEkndmUganVz dCBiZWVuIGF0dHJhY3RlZCB0byB0aGUgaWRlYSBvZiBvdmVybG9hZGluZyB0aGUgZXhpc3Rpbmcg dmFsdWUgYmVjYXVzZSB0aGF0IGZlbHQgbGlrZSBtYXliZSBhIGxlc3MgaW52YXNpdmUgY2hhbmdl LiBCdXQgcGVyaGFwcyB0aGF0J3MNCiBzaG9ydHNpZ2h0ZWQuIEFuZCB0aGVyZSdzIG5vdGhpbmcg aW5oZXJlbnRseSB3cm9uZyB3aXRoIGFkZGl0aW9uYWwgY2xpZW50IG1ldGFkYXRhIHBhcmFtZXRl cnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBkb24ndCBrbm93IGlmIHdlIGNvdWxk IGdldCBhd2F5IHdpdGggYSBzaW5nbGUgbmV3IHBhcmFtZXRlciB0aGF0IGNvdWxkIGNhcnJ5IHRo ZSB2YWx1ZSBmb3IgYW55IFNBTiB0eXBlLiBTb21ldGhpbmcgbGlrZSwgeyAuLi4gJnF1b3Q7dGxz X2NsaWVudF9hdXRoX3NhbiZxdW90OzogJnF1b3Q7PGEgaHJlZj0ic3BpZmZlOi8vdHJ1c3QtZG9t YWluL3BhdGgiIGNsYXNzPSIiPnNwaWZmZTovL3RydXN0LWRvbWFpbi9wYXRoPC9hPiZxdW90OyAu Li59LiBJbiBwcmFjdGljZSBJIGZlZWwgbGlrZQ0KIHRoYXQnZCBwcm9iYWJseSBiZSBva2F5IGJ1 dCBpbiB0aGVvcnkgdGhlcmUncyB0aGUgcG90ZW50aWFsIGZvciBjb25mdXNpb24gb2YgdGhlIHZh bHVlIGFjcm9zcyBkaWZmZXJlbnQgdHlwZXMuIFNvIHByb2JhYmx5IHRoZXJlJ3MgYSBuZWVkIHRv IGluZGljYXRlIHRoZSBTQU4gdHlwZSB0b28uIEVpdGhlciB3aXRoIG1vcmUgY2xpZW50IG1ldGFk YXRhIHBhcmFtZXRlcnMgbGlrZSB0bHNfY2xpZW50X2F1dGhfc2FuX3VpciwgdGxzX2NsaWVudF9h dXRoX3Nhbl9lbWFpbCwNCiB0bHNfY2xpZW50X2F1dGhfc2FuX2lwLCBldGMuIG9yIG1heWJlIHdp dGggYSBzdHJ1Y3R1cmVkIHZhbHVlIG9mIHNvbWUgc29ydCBsaWtlIHsuLi4gJnF1b3Q7dGxzX2Ns aWVudF9hdXRoX3NhbiZxdW90OzogeyZxdW90O3R5cGUmcXVvdDs6JnF1b3Q7VVJJJnF1b3Q7LCAm cXVvdDt2YWx1ZSZxdW90OzomcXVvdDs8YSBocmVmPSJzcGlmZmU6Ly90cnVzdC1kb21haW4vcGF0 aCIgY2xhc3M9IiI+c3BpZmZlOi8vdHJ1c3QtZG9tYWluL3BhdGg8L2E+JnF1b3Q7fSAuLi4gfS4g QW5kIHRoZW4gZGVjaWRpbmcgd2hpY2ggdHlwZXMgdG8gc3VwcG9ydA0KIGFuZCBpZi9ob3cgdG8g YWxsb3cgZm9yIHRoZSBleHRlbnNpYmxlIHR5cGVzLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogYW0gZmFyIGZyb20gYW4gYXV0 aG9yaXR5IGhlcmUsIGJ1dCBpdCBpcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgb25lPC9zcGFuPjxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5vZg0KIHRoZSBwcmltYXJ5IGRyaXZlcnMgaW4g c3VwcG9ydGluZyBTQU4gb3ZlciBTdWJqZWN0IGlzIHRoYXQgdGhlPC9zcGFuPjxiciBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj52YWx1ZXMNCiBhcmUgc3Ryb25nbHkgdHlwZWQuIFdoaWxlIHNv bWUgb2YgdGhlIGFkdmFudGFnZXMgZ2FpbmVkIGZyb208L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPnRoaXMNCiBtYXkgYmUgbGVzcyB1c2VmdWwgaW4gb3VyIG93biBjb250ZXh0 LCBJIGZlZWwgdGhhdCBpdCBtYWtlIHNlbnNlPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj50bw0KIGtlZXAgdGhlIHZhbHVlcyBzZXBhcmF0ZSBhbmQgbm90IG92ZXJsb2FkIGEg c2luZ2xlIHZhbHVlLiBXaGV0aGVyPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij50aGF0DQogbWVhbnMgZGVkaWNhdGVkIG1ldGFkYXRhIHBhcmFtZXRlcnMgb3IgYSBzdHJ1Y3R1 cmVkIHBhcmFtZXRlcjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsg ZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+dmFsdWUs DQogSSBhbSBub3Qgc3VyZSB3aGF0IHRoZSB0cmFkZW9mZnMgd291bGQgYmUsIGJ1dCBib3RoIG9w dGlvbnM8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnNvdW5kDQogc3VpdGFi bGUgdG8gbWUuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIg Y2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCkFu eXdheSwgdGhvc2UgYXJlIGp1c3Qgc29tZSB0aG91Z2h0cyBvbiBpdC4gQW5kIGl0J2xsIGJlIGRp c2N1c3NlZCBtb3JlIHRvZGF5LiBTdWdnZXN0ZWQvcHJvcG9zZWQgdGV4dCBpcyBhbHdheXMgaGVs cGZ1bCB0aG91Z2ggKGV2ZW4gaWYgaXQncyBub3QgdXNlZCBkaXJlY3RseSBpdCBjYW4gaGVscCBt b3ZlIHRoZSBjb252ZXJzYXRpb24gZm9yd2FyZCBhbmQvb3IgaGVscCBlZGl0b3IocykgdG8gaGF2 ZSBwcm9zcGVjdGl2ZSB3b3JkaW5nKS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+R3JlYXQuDQogSSB3aWxsIHdvcmsgb24gc29tZSBz YW1wbGUgdGV4dCBzaW5jZSBpdCBzb3VuZHMgbGlrZSB0aGF0IHdvdWxkPC9zcGFuPjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5iZQ0KIGdlbmVyYWxseSBoZWxwZnVsPC9zcGFuPjxiciBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCk9uIFR1ZSwgTm92IDYsIDIwMTggYXQg NTo1MyBBTSBFdmFuIEdpbG1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2YW4yNjQ1QGdtYWlsLmNv bSIgY2xhc3M9IiI+ZXZhbjI2NDVAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KSGVsbG8g ZXZlcnlvbmUuLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClZlcnkgZXhjaXRlZCB0byBz ZWUgdGhpcyBkcmFmdC4gSXQgaGVscHMgdHJlbWVuZG91c2x5IGluIGFkZHJlc3Npbmc8YnIgY2xh c3M9IiI+DQp1c2UgY2FzZXMgYXJvdW5kIG9hdXRoIGNsaWVudCBtYW5hZ2VtZW50IGluIG1hY2hp bmUtdG8tbWFjaGluZTxiciBjbGFzcz0iIj4NCnNjZW5hcmlvcy4gUGFydGljdWxhcmx5LCB0aGUg UEtJIGF1dGhlbnRpY2F0aW9uIG1ldGhvZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJ biByZXZpZXdpbmcgdGhlIGRvY3VtZW50LCBJIG5vdGljZWQgdGhhdCB0aGUgb25seSBzdXBwb3J0 ZWQgbWV0aG9kPGJyIGNsYXNzPSIiPg0KZm9yIGlkZW50aWZ5aW5nIGEgY2xpZW50IHVzaW5nIHRo ZSBQS0kgYXV0aGVudGljYXRpb24gbWV0aG9kIGlzIGJ5PGJyIGNsYXNzPSIiPg0KcmVmZXJlbmNp bmcgaXRzIGRpc3Rpbmd1aXNoZWQgbmFtZS4gVGhpcyBjYXVnaHQgbWUgYSBiaXQgYnkgc3VycHJp c2UgLTxiciBjbGFzcz0iIj4NCm1hbnkgbmV3ZXIgcHJvamVjdHMgYWltZWQgYXQgYXV0b21hdGlu ZyBYLjUwOSBpc3N1YW5jZSBpbiB0aGU8YnIgY2xhc3M9IiI+DQpkYXRhY2VudGVyIHV0aWxpemUg U0FOIGV4dGVuc2lvbnMgcmF0aGVyIHRoYW4gZGlzdGluZ3Vpc2hlZCBuYW1lIGluPGJyIGNsYXNz PSIiPg0Kb3JkZXIgdG8gZW5jb2RlIGlkZW50aXR5LiBJIGFtIGZ1cnRoZXIgdW5kZXIgdGhlIGlt cHJlc3Npb24gdGhhdCB0aGU8YnIgY2xhc3M9IiI+DQpjb21tdW5pdHkgaXMsIGluIGdlbmVyYWws IG1vdmluZyBhd2F5IGZyb20gdGhlIHN1YmplY3QgZXh0ZW5zaW9uPGJyIGNsYXNzPSIiPg0KYWx0 b2dldGhlciBpbiBmYXZvciBvZiBTQU4tYmFzZWQgaWRlbnRpZmljYXRpb24uPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KRnVsbCBkaXNjbG9zdXJlOiBJIGFtIG9uZSBvZiB0aGUgbWFpbnRh aW5lcnMgb24gYSBwcm9qZWN0IGNhbGxlZDxiciBjbGFzcz0iIj4NClNQSUZGRSwgd2hpY2ggcHJv dmlkZXMgaWRlbnRpdHkgc3BlY2lmaWNhdGlvbnMgZm9yIGRhdGFjZW50ZXIgd29ya2xvYWQ8YnIg Y2xhc3M9IiI+DQphcHBsaWNhdGlvbnMuIEZvciBYLjUwOSwgU1BJRkZFIGVuY29kZXMgaWRlbnRp dHkgaW50byBhIFVSSSBTQU48YnIgY2xhc3M9IiI+DQpleHRlbnNpb24uIEEgbnVtYmVyIG9mIHBy b2plY3RzIHVzaW5nIFNQSUZGRSBkbyBub3QgY29uZmlndXJlIHRoZTxiciBjbGFzcz0iIj4NCnN1 YmplY3Qgd2l0aCBpZGVudGlmeWluZyBpbmZvcm1hdGlvbiAoU1BJUkUgYW5kIEdvb2dsZSBJc3Rp byBiZWluZzxiciBjbGFzcz0iIj4NCmp1c3QgYSBjb3VwbGUpLiBJIGFtIGFsc28gaGVhcmluZyBv ZiBvdGhlciBYLjUwOSBhdXRvbWF0aW9uIHByb2plY3RzPGJyIGNsYXNzPSIiPg0Kd2hpY2ggYXJl IG1vdmluZyBhd2F5IGZyb20gc3ViamVjdC9kaXN0aW5ndWlzaGVkIG5hbWUgKGV2ZW4gaWYgdGhl eTxiciBjbGFzcz0iIj4NCmFyZSBub3QgdXNpbmcgU1BJRkZFKS48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpXaGlsZSBJIHRoaW5rIHN1cHBvcnQgZm9yIGRpc3Rpbmd1aXNoZWQgbmFtZSBp cyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSw8YnIgY2xhc3M9IiI+DQpJIHdvcnJ5IHRoYXQgc3VwcG9y dGluZyBpdCBzb2xlbHkgd2lsbCByZW5kZXIgaXQgaW5jb21wYXRpYmxlIHdpdGg8YnIgY2xhc3M9 IiI+DQpzb21lIG9mIHRoZSBtb3JlIG1vZGVybiBQS0lYIHN5c3RlbXMgYW5kIG5vdCBzdGFuZCB0 aGUgdGVzdCBvZiB0aW1lLiBJPGJyIGNsYXNzPSIiPg0Ka25vdyB0aGF0IEkgYW0gYSBsaXR0bGUg bGF0ZSB0byB0aGlzLCBhbmQgZm9yIHRoYXQgSSBhcG9sb2dpemUuLi4gYnV0PGJyIGNsYXNzPSIi Pg0KSSBmZWVsIHRoaXMgaXMgYSBzaWduaWZpY2FudCBwb2ludC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJIHdvdWxkIGxpa2UgdG8gb3BlbiBhIGRpc2N1c3Npb24gb24gc3VwcG9ydGlu ZyB0aGUgbW9zdCBjb21tb25seSB1c2VkPGJyIGNsYXNzPSIiPg0KU0FOIGV4dGVuc2lvbiB0eXBl cyBpbiBhZGRpdGlvbiB0byBkaXN0aW5ndWlzaGVkIG5hbWUuIFRvIGFjY29tcGxpc2g8YnIgY2xh c3M9IiI+DQp0aGlzLCBhbWVuZGluZyBzZWN0aW9uIDIuMS4yIGBDbGllbnQgUmVnaXN0cmF0aW9u IE1ldGFkYXRhYCB3aXRoPGJyIGNsYXNzPSIiPg0KYWRkaXRpb25hbCBwYXJhbWV0ZXJzIHNlZW1z IGFwcHJvcHJpYXRlLiBJbiBteSBleHBlcmllbmNlLCB0aGUgbW9zdDxiciBjbGFzcz0iIj4NCmNv bW1vbmx5IHVzZWQgU0FOIGV4dGVuc2lvbnMgYXJlOiBETlMgbmFtZSwgSVAgYWRkcmVzcywgVVJJ LCBhbmQgZW1haWw8YnIgY2xhc3M9IiI+DQphZGRyZXNzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkFyZSB0aGVyZSBzaWduaWZpY2FudCBkcmF3YmFja3MgdG8gZXh0ZW5kaW5nIHRoZSBu dW1iZXIgb2YgY2xpZW50PGJyIGNsYXNzPSIiPg0KcmVnaXN0cmF0aW9uIG1ldGFkYXRhIHBhcmFt ZXRlcnM/IEkgd291bGQgdmVyeSBtdWNoIGxpa2UgdG8gc2VlIHRoaXMgLTxiciBjbGFzcz0iIj4N CndpdGhvdXQgaXQsIG1hbnkgZXhpc3RpbmcgcHJvamVjdHMgd2lsbCBiZSB1bmFibGUgdG8gdXNl IHRoZSBzcGVjLiBJPGJyIGNsYXNzPSIiPg0KYW0gaGFwcHkgdG8gY29udHJpYnV0ZSB0aW1lIGFu ZCB0ZXh0IHRvIHRoaXMsIGFzc3VtaW5nIHBlb3BsZSBmZWVsPGJyIGNsYXNzPSIiPg0KdGhhdCB0 aGlzIGlzIGEgYmVuZWZpY2lhbCBhZGRpdGlvbi4gU29ycnkgYWdhaW4gZm9yIHRoZSB0aW1pbmc8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLTxiciBjbGFzcz0iIj4NCmV2YW48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24g b3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICZuYnNwO0lm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwNCiBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1l c3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsg eW91LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5P QXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+LS08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5ldmFuPC9zcGFuPjxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9BdXRo DQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPk9BdXRoQGll dGYub3JnPC9hPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_129B91F9E4714AE498D3F534D6BF09C1mitedu_-- From nobody Tue Nov 6 17:16:13 2018 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 392671292AD for ; Tue, 6 Nov 2018 17:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 Hlgg2AmDp8dk for ; Tue, 6 Nov 2018 17:16:10 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF901277BB for ; Tue, 6 Nov 2018 17:16:09 -0800 (PST) X-AuditID: 1209190e-471ff70000000ceb-09-5be23cd85f2c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id CC.47.03307.8DC32EB5; Tue, 6 Nov 2018 20:16:08 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wA71G7eJ003411; Tue, 6 Nov 2018 20:16:07 -0500 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id wA71GFpN020103; Tue, 6 Nov 2018 20:16:18 -0500 Received: from OC11EXHUB8.exchange.mit.edu (18.9.3.20) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 6 Nov 2018 20:15:33 -0500 Received: from OC11EXPO25.exchange.mit.edu ([169.254.1.63]) by OC11EXHUB8.exchange.mit.edu ([18.9.3.20]) with mapi id 14.03.0352.000; Tue, 6 Nov 2018 20:16:04 -0500 From: Justin P Richer To: Torsten Lodderstedt CC: oauth Thread-Topic: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01 Thread-Index: AQHUdNFuzDsL/mmYCkuj+Od+5p+LBaVD2RQA Date: Wed, 7 Nov 2018 01:16:03 +0000 Message-ID: <08ECF78A-74CB-483A-90BE-CC3194E68762@mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.81] Content-Type: multipart/alternative; boundary="_000_08ECF78A74CB483A90BECC3194E68762mitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBJsWRmVeSWpSXmKPExsUixCmqrXvD5lG0QccTdYuTb1+xWbw69pTF gcljyZKfTB7HevpZA5iiuGxSUnMyy1KL9O0SuDJ2bvcoOGNSsfTTPOYGxnbjLkZODgkBE4kN lz+wdjFycQgJrGGS2DNtORuEs59R4kTLR0YI5xijxJJ7LSwQzlZGiV/frkOVrWCUePpiCxPI MDYBdYlt0+6A2SIChhLtExcyg9jMAlISj1pOsYDYwgKhEvP+nASKcwDVhEns6i+DKDeSWLRk MTtImEVARWLSUbAwr4CVxPpZ/ewgtpCAk8TK05vBSjgFnCU+fcwBCTMKiEl8P7WGCWKRuMSt J/OZID4TkFiy5zwzhC0q8fLxP1YIW1ZiwV+Y+jiJM0tfMEKsEpQ4OfMJywRG8VlIRs1CUjYL SdksoCuYBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zF8q2l/g54RALspoFjByrGGVTcqt0cxMzc4pT k3WLkxPz8lKLdI31cjNL9FJTSjcxgqNYkm8H46QG70OMAhyMSjy8GjseRguxJpYVV+YeYpTk YFIS5U1fBhTiS8pPqcxILM6ILyrNSS0+xCjBwawkwnt6NVCONyWxsiq1KB8mJc3BoiTOO6Fl cbSQQHpiSWp2ampBahFMVoaDQ0mCVwiYrIQEi1LTUyvSMnNKENJMHJwgw3mAhn+1BqrhLS5I zC3OTIfIn2K053g0o2MGM8cLMPkOTF450zmDWYglLz8vVUqc9x5ImwBIW0ZpHtxkSIJmFn3F KA70qDDvE5AqHmByh5v9CmgtE9Dae7IPQNaWJCKkpBoYlyxXPfJsdl4n776YQB0m+zrWwL6v xxmPnr1p53fB6F7w20Mvfb91SU16usjhrsmK9rQgZmOTrQtfJG/6fE1t+jQLo5lsO8LjYuK8 bppFlq1vv3L9zZ6nhvx/tzqtEjjz7b92PNss99nL526P0/5vmix/9apf/9wP5jKnxG3nzjnb wPnDwWDXLCWW4oxEQy3mouJEALnAeBCrAwAA Archived-At: Subject: Re: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01 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, 07 Nov 2018 01:16:12 -0000 --_000_08ECF78A74CB483A90BECC3194E68762mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgSSBicm91Z2h0IHRoaXMgdXAgaW5pdGlhbGx5LCBJIHdhbnQgdG8gcmUtdm9pY2UgbXkg c3VwcG9ydCBmb3IgYSBnZW5lcmFsIG1lY2hhbmlzbS4gSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0 byBoYXZlIHNvbWV0aGluZyB0aGF0IGFsbCBvZiB0aGUgT0F1dGggSlNPTi1zcG91dGluZyBlbmRw b2ludHMgKGludHJvc3BlY3Rpb24sIHRva2VuLCByZXZvY2F0aW9uLCByZWdpc3RyYXRpb24sIGRp c2NvdmVyeSkgY2FuIHVzZSB0byB1bml2ZXJzYWxseSBwdXQgb3V0IHNpZ25lZCBhbmQvb3IgZW5j cnlwdGVkIEpXVHMgaW5zdGVhZCB1c2luZyB0aGUgc2FtZSBtZWNoYW5pc20uDQoNCktleWluZyBm b3IgZWFjaCBvZiB0aGVzZSBzaG91bGQgYmUgZmFpcmx5IGNsZWFyIGFuZCBiYXNlZCBvbiB0aGUg bmF0dXJlIG9mIHRoZSByZXF1ZXN0ZXIuIERpc2NvdmVyeSB3b3VsZCBiZSBzaWduZWQgYnkgdGhl IHNlcnZlciBrZXksIHRva2VuIGNvdWxkIGJlIGVuY3JweXRlZCB0byB0aGUgY2xpZW504oCZcyBr ZXkgb3Igc2VjcmV0LCBpbnRyb3NwZWN0aW9uIHRpZWQgdG8gdGhlIHJlc291cmNl4oCZcyBrZXks IGV0Yy4gSSBkb27igJl0IHNlZSBhIGxvdCBvZiBwb3NzaWJpbGl0eSBmb3IgY29uZnVzaW9uIGJ1 dCBpbnN0ZWFkIHNlZSBhIGNoYW5jZSB0byBtYWtlIGdvb2QgcmUtdXNlIG9mIGEgZ2VuZXJhbCBt ZWNoYW5pc20gYWxsIG92ZXIgdGhlIHBsYWNlLg0KDQpUaGUgYXV0aG9yaXphdGlvbiBlbmRwb2lu dCBkb2VzbuKAmXQgY29tZSBpbnRvIHBsYXkgYXQgYWxsIGJlY2F1c2UgaXQgZG9lc27igJl0IHJl dHVybiBKU09OLCBhbmQgaW5zdGVhZCBpcyBhIGZyb250LWNoYW5uZWwgcmVkaXJlY3QgZW5kcG9p bnQuIEFzIHN1Y2ggaXTigJlzIGEgZHJhc3RpY2FsbHkgZGlmZmVyZW50IHNwYWNlIGFuZCB0aGVy ZWZvcmUgdGhpcyBzcGVjIHdvdWxkbuKAmXQgYXBwbHkuIEluIGZhY3QsIHRoYXTigJlzIHdoZXJl IEpBUk0gd291bGQgY29tZSBpbnRvIHBsYXkuDQoNCuKAlCBKdXN0aW4NCg0KT24gTm92IDUsIDIw MTgsIGF0IDE6MzIgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KDQpIaSBhbGwsDQoN CmFzIG1lbnRpb25lZCBkdXJpbmcgdGhlIHByZXNlbnRhdGlvbiB0aGlzIG1vcm5pbmcsIEkgd291 bGQgbGlrZSB0byBnZXQgYSBmZWVsaW5nIHdoYXQgdGhlIHdvcmtpbmcgZ3JvdXBzIHRoaW5rcyBh Ym91dCBnZW5lcmFsaXppbmcgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNw b25zZS0wMSB0byBhIG1lY2hhbmlzbSBzdXBwb3J0aW5nIHJlcXVlc3RpbmcgYW5kIHByb3ZpZGlu ZyBKV1QgcmVzcG9uc2VzIGZyb20gdGhlIGRpZmZlcmVudCBPQXV0aCBlbmRwb2ludHMsIHN1Y2gg YXMgdG9rZW4sIHJldm9jYXRpb24sIGNsaWVudCByZWdpc3RyYXRpb24sIGFuZCBpbnRyb3NwZWN0 aW9uLg0KDQpQbGVhc2Ugc2hhcmUgeW91ciB0aG91Z2h0cyBvbiB0aGUgbGlzdC4NCg0KVGhhbmtz IGluIGFkdmFuY2UsDQpUb3JzdGVuLiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCg== --_000_08ECF78A74CB483A90BECC3194E68762mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <2E77B0552C6CCB4BAB4B3CDA8FB7DDA5@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClNpbmNlIEkgYnJvdWdodCB0aGlzIHVwIGluaXRp YWxseSwgSSB3YW50IHRvIHJlLXZvaWNlIG15IHN1cHBvcnQgZm9yIGEgZ2VuZXJhbCBtZWNoYW5p c20uIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBzb21ldGhpbmcgdGhhdCBhbGwgb2Yg dGhlIE9BdXRoIEpTT04tc3BvdXRpbmcgZW5kcG9pbnRzIChpbnRyb3NwZWN0aW9uLCB0b2tlbiwg cmV2b2NhdGlvbiwgcmVnaXN0cmF0aW9uLCBkaXNjb3ZlcnkpIGNhbiB1c2UgdG8gdW5pdmVyc2Fs bHkNCiBwdXQgb3V0IHNpZ25lZCBhbmQvb3IgZW5jcnlwdGVkIEpXVHMgaW5zdGVhZCB1c2luZyB0 aGUgc2FtZSBtZWNoYW5pc20uJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5LZXlpbmcgZm9yIGVhY2ggb2YgdGhlc2Ugc2hvdWxkIGJlIGZh aXJseSBjbGVhciBhbmQgYmFzZWQgb24gdGhlIG5hdHVyZSBvZiB0aGUgcmVxdWVzdGVyLiBEaXNj b3Zlcnkgd291bGQgYmUgc2lnbmVkIGJ5IHRoZSBzZXJ2ZXIga2V5LCB0b2tlbiBjb3VsZCBiZSBl bmNycHl0ZWQgdG8gdGhlIGNsaWVudOKAmXMga2V5IG9yIHNlY3JldCwgaW50cm9zcGVjdGlvbiB0 aWVkIHRvIHRoZSByZXNvdXJjZeKAmXMga2V5LCBldGMuIEkgZG9u4oCZdA0KIHNlZSBhIGxvdCBv ZiBwb3NzaWJpbGl0eSBmb3IgY29uZnVzaW9uIGJ1dCBpbnN0ZWFkIHNlZSBhIGNoYW5jZSB0byBt YWtlIGdvb2QgcmUtdXNlIG9mIGEgZ2VuZXJhbCBtZWNoYW5pc20gYWxsIG92ZXIgdGhlIHBsYWNl LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgZG9lc27igJl0IGNvbWUgaW50byBwbGF5IGF0 IGFsbCBiZWNhdXNlIGl0IGRvZXNu4oCZdCByZXR1cm4gSlNPTiwgYW5kIGluc3RlYWQgaXMgYSBm cm9udC1jaGFubmVsIHJlZGlyZWN0IGVuZHBvaW50LiBBcyBzdWNoIGl04oCZcyBhIGRyYXN0aWNh bGx5IGRpZmZlcmVudCBzcGFjZSBhbmQgdGhlcmVmb3JlIHRoaXMgc3BlYyB3b3VsZG7igJl0IGFw cGx5LiBJbiBmYWN0LCB0aGF04oCZcyB3aGVyZQ0KIEpBUk0gd291bGQgY29tZSBpbnRvIHBsYXku PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE5vdiA1LCAy MDE4LCBhdCAxOjMyIEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIGNsYXNzPSIiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGkgYWxsLCA8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQphcyBtZW50aW9uZWQgZHVyaW5nIHRoZSBwcmVzZW50YXRpb24gdGhp cyBtb3JuaW5nLCBJIHdvdWxkIGxpa2UgdG8gZ2V0IGEgZmVlbGluZyB3aGF0IHRoZSB3b3JraW5n IGdyb3VwcyB0aGlua3MgYWJvdXQgZ2VuZXJhbGl6aW5nIGRyYWZ0LWlldGYtb2F1dGgtand0LWlu dHJvc3BlY3Rpb24tcmVzcG9uc2UtMDEgdG8gYSBtZWNoYW5pc20gc3VwcG9ydGluZyByZXF1ZXN0 aW5nIGFuZCBwcm92aWRpbmcgSldUIHJlc3BvbnNlcyBmcm9tIHRoZSBkaWZmZXJlbnQNCiBPQXV0 aCBlbmRwb2ludHMsIHN1Y2ggYXMgdG9rZW4sIHJldm9jYXRpb24sIGNsaWVudCByZWdpc3RyYXRp b24sIGFuZCBpbnRyb3NwZWN0aW9uLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxl YXNlIHNoYXJlIHlvdXIgdGhvdWdodHMgb24gdGhlIGxpc3QuIDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClRoYW5rcyBpbiBhZHZhbmNlLDxiciBjbGFzcz0iIj4NClRvcnN0ZW4uIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_08ECF78A74CB483A90BECC3194E68762mitedu_-- From nobody Tue Nov 6 18:50:25 2018 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 E3030127332 for ; Tue, 6 Nov 2018 18:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OitREvA249p2 for ; Tue, 6 Nov 2018 18:50:17 -0800 (PST) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 6A80D1293FB for ; Tue, 6 Nov 2018 18:50:15 -0800 (PST) Received: from [31.133.129.111] (helo=dhcp-816f.meeting.ietf.org) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gKDuz-0002rk-FQ; Wed, 07 Nov 2018 03:50:10 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_80502670-3315-4ACE-9A80-2BD7EB2AD759"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 7 Nov 2018 09:50:04 +0700 In-Reply-To: Cc: evan2645@gmail.com, bcampbell=40pingidentity.com@dmarc.ietf.org, oauth To: Rifaat Shekh-Yusef References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 02:50:21 -0000 --Apple-Mail=_80502670-3315-4ACE-9A80-2BD7EB2AD759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for referring us to this spec. How I read it, every way to = represent an application identity may require specific verification = rules (including typ specific syntactical rules).=20 In my interpretation this means we must explicitly manage expected type = and value of the identifier used to match the client identity. It could = also require the AS to apply type specific matching rules. =20 Comments? > Am 07.11.2018 um 04:03 schrieb Rifaat Shekh-Yusef = : >=20 > You might want to look at RFC6125 which covers this topic and provides = recommendations for representing application in certificates: > https://tools.ietf.org/html/rfc6125 >=20 > Regards, > Rifaat >=20 >=20 > On Tue, Nov 6, 2018 at 3:53 PM Evan Gilman wrote: > Response(s) inline >=20 > On Mon, Nov 5, 2018 at 11:53 PM Neil Madden = wrote: > > > > Is there an intention that any semantics are attached to the SAN = being a URI or DNS name or IP or ...? Or is it still intended to be an = opaque identifier? >=20 > There are some extra things we could do if we attached type-specific > semantics to the matching (e.g. DNS wildcarding etc), however I think > that continuing to use the values as opaque identifiers would get us > most of what we need while keeping things simple. >=20 > > On 6 Nov 2018, at 01:55, Brian Campbell = wrote: > > > > Thanks Evan for bringing this to the WG's attention. More or less = the same question/issue was raised yesterday in the area director's = review of the document as well. I plan to bring this up as a discussion = item in the meeting today. But my sense from some early discussions is = that there is likely to be (rough) consensus to make some change in = order to allow a SAN to be specified as the certificate subject = identifier in the PKI client auth mode. We'll need to figure out the = specifics of how that works. I don't think there are significant = drawbacks to extending the number of client registration metadata = parameters per se. I guess I've just been attracted to the idea of = overloading the existing value because that felt like maybe a less = invasive change. But perhaps that's shortsighted. And there's nothing = inherently wrong with additional client metadata parameters. > > > > I don't know if we could get away with a single new parameter that = could carry the value for any SAN type. Something like, { ... = "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I = feel like that'd probably be okay but in theory there's the potential = for confusion of the value across different types. So probably there's a = need to indicate the SAN type too. Either with more client metadata = parameters like tls_client_auth_san_uir, tls_client_auth_san_email, = tls_client_auth_san_ip, etc. or maybe with a structured value of some = sort like {... "tls_client_auth_san": {"type":"URI", = "value":"spiffe://trust-domain/path"} ... }. And then deciding which = types to support and if/how to allow for the extensible types. >=20 > I am far from an authority here, but it is my understanding that one > of the primary drivers in supporting SAN over Subject is that the > values are strongly typed. While some of the advantages gained from > this may be less useful in our own context, I feel that it make sense > to keep the values separate and not overload a single value. Whether > that means dedicated metadata parameters or a structured parameter > value, I am not sure what the tradeoffs would be, but both options > sound suitable to me. >=20 > > Anyway, those are just some thoughts on it. And it'll be discussed = more today. Suggested/proposed text is always helpful though (even if = it's not used directly it can help move the conversation forward and/or = help editor(s) to have prospective wording). >=20 > Great. I will work on some sample text since it sounds like that would > be generally helpful >=20 > > On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman = wrote: > >> > >> Hello everyone.. > >> > >> Very excited to see this draft. It helps tremendously in addressing > >> use cases around oauth client management in machine-to-machine > >> scenarios. Particularly, the PKI authentication method. > >> > >> In reviewing the document, I noticed that the only supported method > >> for identifying a client using the PKI authentication method is by > >> referencing its distinguished name. This caught me a bit by = surprise - > >> many newer projects aimed at automating X.509 issuance in the > >> datacenter utilize SAN extensions rather than distinguished name in > >> order to encode identity. I am further under the impression that = the > >> community is, in general, moving away from the subject extension > >> altogether in favor of SAN-based identification. > >> > >> Full disclosure: I am one of the maintainers on a project called > >> SPIFFE, which provides identity specifications for datacenter = workload > >> applications. For X.509, SPIFFE encodes identity into a URI SAN > >> extension. A number of projects using SPIFFE do not configure the > >> subject with identifying information (SPIRE and Google Istio being > >> just a couple). I am also hearing of other X.509 automation = projects > >> which are moving away from subject/distinguished name (even if they > >> are not using SPIFFE). > >> > >> While I think support for distinguished name is absolutely = necessary, > >> I worry that supporting it solely will render it incompatible with > >> some of the more modern PKIX systems and not stand the test of = time. I > >> know that I am a little late to this, and for that I apologize... = but > >> I feel this is a significant point. > >> > >> I would like to open a discussion on supporting the most commonly = used > >> SAN extension types in addition to distinguished name. To = accomplish > >> this, amending section 2.1.2 `Client Registration Metadata` with > >> additional parameters seems appropriate. In my experience, the most > >> commonly used SAN extensions are: DNS name, IP address, URI, and = email > >> address. > >> > >> Are there significant drawbacks to extending the number of client > >> registration metadata parameters? I would very much like to see = this - > >> without it, many existing projects will be unable to use the spec. = I > >> am happy to contribute time and text to this, assuming people feel > >> that this is a beneficial addition. Sorry again for the timing > >> > >> -- > >> evan > >> > >> _______________________________________________ > >> 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 >=20 >=20 >=20 > --=20 > evan >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_80502670-3315-4ACE-9A80-2BD7EB2AD759 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMDcwMjUwMDVaMC8GCSqGSIb3DQEJBDEiBCAs 0tYUwPX0flWccynDM0HYNK3SpAqEerHwSt2syBGcJjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAvzpn2TPKpbVGgMryIYY8+7Ri jdoN+eQa3wYtxUFPImls2wg9/dLNFh6+I1Hzq7u5kzsQoiN8aUqLwoaEOGeCGXX+7YYKrzaOFDh9 NLYtVX9g7crKTBeMqpPDur1ITsHamw/1k0/GbjMUDwZC4bYgpmVhEetO039p1KAdEtqzHSaewJlJ ffIisWUiz9tfhlTbsTID2OXeiuJqH+Ll3jmM1kfDtvTJAcuUKJnOVYQKnaTLVTSQZLgw289xl9rg ueWUzKkDfSNnNHV/wPCL1oaOTVDNtKRPSKKN8WZ2UkTMxHGluf5iIX17QnM9IMVOSFe1iqrrn7mJ 62+YSIy4AOzgkgAAAAAAAA== --Apple-Mail=_80502670-3315-4ACE-9A80-2BD7EB2AD759-- From nobody Wed Nov 7 00:46:39 2018 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 BA4741286D9 for ; Wed, 7 Nov 2018 00:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6pHLARCudNbx for ; Wed, 7 Nov 2018 00:46:35 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0: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 E6CAB12007C for ; Wed, 7 Nov 2018 00:46:34 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id t190-v6so16082198itb.2 for ; Wed, 07 Nov 2018 00:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z6zXAa7BCEeqIntJvkyj72vdH3wY6aShclEhoNkLdCU=; b=HxyOcrZxUDMDqsqTjcVfezxWZ0v+QmCgSd4HhvrQM1A5ukRW+AO/fCD/e4He5GJDAV RK/WcHkjdUdOJD7hCJT4MQVsCXqfleH8d+41RzhNDmllTolVk25poLenl8MJbpryB52k TMgpRPeup0Bb+Yc3+AziU/43PooL+0Fk0JWWw= 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=Z6zXAa7BCEeqIntJvkyj72vdH3wY6aShclEhoNkLdCU=; b=mmyzs2SE5HNS/0cVc1m2cvEHjAcbWHkXE/1REIzh58pNICqBt1hfGWn8W6ITXTXwxj Y+qIeroGAcSXWO7SGcPGruqVpPAH9389GQP0e75SsvKZRHmeuFkeiM/+fwyAqF4rnGiE oopVYRBxrRaZVLiR8sK//7OyyyC6oz1JRp6QIrDckdEfXG26OQxY/yX3znZf94bdPR/m +WvbHe8oFOPMW73j9q2edJxOCShzTcLjHUdMt1UeXqwTt2GI6SsTPtsEjg2gb+0JZzpX p5tpEt11rmqt9CwPdPvLuEuD2hAlHZHC7uW/9P5uFIUZzR4kfBBbo83+Jk4RAgCpSqTg UmAQ== X-Gm-Message-State: AGRZ1gJcKHPqNvSiw6i1c3hpw6LjV4v2rbnaZUmWc1D6xV1feLWjxPVv ZKUcJ11JYo7gZmBMSbUZwU7iMyg20JmKF7Xso4oKlS40h0RmeNmpiNTFQ/j9hXHrqFa0IB3Len1 HsqPJtXr1qUT60A== X-Google-Smtp-Source: AJdET5chyrLROcBLMrflgfqiRIxUXA1bmBvK+6BDukfiuO9RwneK4uSpxQN4SezksloHjguKj/6yGKZfB81Y+oeWCh0= X-Received: by 2002:a24:f60b:: with SMTP id u11-v6mr1030257ith.45.1541580394084; Wed, 07 Nov 2018 00:46:34 -0800 (PST) MIME-Version: 1.0 References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> In-Reply-To: From: Brian Campbell Date: Wed, 7 Nov 2018 00:46:07 -0800 Message-ID: To: Evan Gilman Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000c86757057a0f279d" Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 08:46:37 -0000 --000000000000c86757057a0f279d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable inline below On Tue, Nov 6, 2018 at 12:53 PM Evan Gilman wrote: > There are some extra things we could do if we attached type-specific > semantics to the matching (e.g. DNS wildcarding etc), however I think > that continuing to use the values as opaque identifiers would get us > most of what we need while keeping things simple. > Agreed. I am far from an authority here, but it is my understanding that one > of the primary drivers in supporting SAN over Subject is that the > values are strongly typed. While some of the advantages gained from > this may be less useful in our own context, I feel that it make sense > to keep the values separate and not overload a single value. I'm likewise no authority but have a similar understanding. Because the advantages of a typed name are less clear in this context is why I've been wanting to simplify with an overloaded parameter. But that's probably ultimately a bad idea. So yeah, I'm agreeing that separating the types is the way to go. Whether > that means dedicated metadata parameters or a structured parameter > value, I am not sure what the tradeoffs would be, but both options > sound suitable to me. > Seems like it's largely an esthetic thing but perhaps the benefits or drawbacks of one over the other will become more apparent as we dig into it more. Great. I will work on some sample text since it sounds like that would > be generally helpful > I think it would, yes. Thank you! --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000c86757057a0f279d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
inline below

On Tue, Nov 6, 2018 at 12:53 PM Evan Gilman <evan2645@gmail.com> wrote:<= br>
There are some extra things we could do if we attached type-specific
semantics to the matching (e.g. DNS wildcarding etc), however I think
that continuing to use the values as opaque identifiers would get us
most of what we need while keeping things simple.

=
Agreed.
=C2=A0

I am far from an authority here, but it is my understanding that one
of the primary drivers in supporting SAN over Subject is that the
values are strongly typed. While some of the advantages gained from
this may be less useful in our own context, I feel that it make sense
to keep the values separate and not overload a single value.

I'm likewise no authority but have a similar understa= nding. Because the advantages of a typed name are less clear in this contex= t is why I've been wanting to simplify with an overloaded parameter. Bu= t that's probably ultimately a bad idea. So yeah, I'm agreeing that= separating the types is the way to go.=C2=A0
=C2=A0
<= br>
Whether
that means dedicated metadata parameters or a structured parameter
value, I am not sure what the tradeoffs would be, but both options
sound suitable to me.

Seems like it'= ;s largely an esthetic thing but perhaps the benefits or drawbacks of one o= ver the other will become more apparent as we dig into it more.
<= br>
Great. I will work on some sample text since it sounds like that would
be generally helpful

I think it would, = yes. Thank you!

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000c86757057a0f279d-- From nobody Wed Nov 7 00:51:32 2018 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 3D30F128CB7 for ; Wed, 7 Nov 2018 00:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6SECZ_vyf4M3 for ; Wed, 7 Nov 2018 00:51:27 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1699D1286D9 for ; Wed, 7 Nov 2018 00:51:26 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id k141-v6so19877952itk.3 for ; Wed, 07 Nov 2018 00:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WwyTP1n69sHt/qA5y4xXDYl4/yodIq8gYehzgQJPdkE=; b=UpjF3Oj3MrRgOgZyYHvbCB+Oj6l8jxa1Fr0DEKUTNQEiT810dea+ZpwI++TVxqPx3h Gjfp0zXk7I+jfKBn7x8QlktzfcbmrXC+4owz6yEv3XeMyb9LiElFO4jws5HtSY9jThx4 OOQwt1ytQse4rn8a6T64b9wSyAdCq3UIHHPC0= 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=WwyTP1n69sHt/qA5y4xXDYl4/yodIq8gYehzgQJPdkE=; b=n1JryOBVFNclmzlhon5DVl//yWzshFAqWULdawBa7Ov8RTwO0Sr9oyWrkJS9cZ2I7u RZTRLSTS9N6yQjkk4MI3AddfWOo3S4J9Ou2+SQnnZ2VyYQEKyOFqFSp5pW9xarr1W+cp 6Vs/XdK9brW09OYSTsGfyDQ0ic1x4uKOcdgVRKi+0M49eGjWySqYZcuhJBkEpXcY1Wrf LHfhFzLbEg1FsA0/bUGlOvgm1/58qGWjEAayPDF+6cwOC+KY162RLYKq4pu4Fr6oPTDr DE27V3ylDTLGkQoy+1NYyBeHirzm3hJ1+A2ayzRHfmhiEkm/LIwopy6+zCSBh7e9BGiA D2GQ== X-Gm-Message-State: AGRZ1gKRKKhl8sgiGgSAvBFWW4XdiTyyL6dkGPe+Ox+pounEIphEZwl7 95tEWqPhAyDz0cf6iM/lwnnEsz8vH/O28/JubBGky1FwCGQZW22dKK1lPrxLOIb9EFnQkN89VTq GTm8ti4iBfxWrsQ== X-Google-Smtp-Source: AJdET5cWB1/Fh/CeDRjfgh6o9r+jHh3jKTkWJ3P+MOB3LAvDaV/sMN97OUlKA9t8HkdDI4R6m3hRp4vYfotDfpQTXd0= X-Received: by 2002:a24:bcc1:: with SMTP id n184-v6mr1074445ite.174.1541580686072; Wed, 07 Nov 2018 00:51:26 -0800 (PST) MIME-Version: 1.0 References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> <129B91F9-E471-4AE4-98D3-F534D6BF09C1@mit.edu> In-Reply-To: <129B91F9-E471-4AE4-98D3-F534D6BF09C1@mit.edu> From: Brian Campbell Date: Wed, 7 Nov 2018 00:50:59 -0800 Message-ID: To: Justin Richer Cc: Evan Gilman , Neil Madden , oauth Content-Type: multipart/alternative; boundary="0000000000002fc1f3057a0f396f" Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 08:51:30 -0000 --0000000000002fc1f3057a0f396f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, I think they could be treated as different different client_auth_methods. But there is a lot more commonality than differences to the point where I think it makes sense to keep it all in a single document and under a single client auth method with just the variation on which name is being used. On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer wrote: > Would it make sense for these to be a different client_auth_method > entirely? Much the same way that we have private_key_jwt and > client_secret_jwt today, both of which use the JWT assertion framework bu= t > have very different keying and security assumptions. In the same way, her= e > you=E2=80=99re still validating the cert but the means by which it=E2=80= =99s validated is > different, so the auth method is arguably not going to benefit from being > overloaded. Caveat, I=E2=80=99ve not built out a system using SANs in any > meaningful way. > > If we were to do that, this draft could go forward as-is (since it=E2=80= =99s > fairly done in my opinion) and a new document could better define the > semantics for the various SAN types, but while building on the framework > and concepts listed in here. > > =E2=80=94 Justin > > On Nov 6, 2018, at 3:52 PM, Evan Gilman wrote: > > Response(s) inline > > On Mon, Nov 5, 2018 at 11:53 PM Neil Madden > wrote: > > > Is there an intention that any semantics are attached to the SAN being a > URI or DNS name or IP or ...? Or is it still intended to be an opaque > identifier? > > > There are some extra things we could do if we attached type-specific > semantics to the matching (e.g. DNS wildcarding etc), however I think > that continuing to use the values as opaque identifiers would get us > most of what we need while keeping things simple. > > On 6 Nov 2018, at 01:55, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > Thanks Evan for bringing this to the WG's attention. More or less the sam= e > question/issue was raised yesterday in the area director's review of the > document as well. I plan to bring this up as a discussion item in the > meeting today. But my sense from some early discussions is that there is > likely to be (rough) consensus to make some change in order to allow a SA= N > to be specified as the certificate subject identifier in the PKI client > auth mode. We'll need to figure out the specifics of how that works. I > don't think there are significant drawbacks to extending the number of > client registration metadata parameters per se. I guess I've just been > attracted to the idea of overloading the existing value because that felt > like maybe a less invasive change. But perhaps that's shortsighted. And > there's nothing inherently wrong with additional client metadata paramete= rs. > > I don't know if we could get away with a single new parameter that could > carry the value for any SAN type. Something like, { ... > "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I > feel like that'd probably be okay but in theory there's the potential for > confusion of the value across different types. So probably there's a need > to indicate the SAN type too. Either with more client metadata parameters > like tls_client_auth_san_uir, tls_client_auth_san_email, > tls_client_auth_san_ip, etc. or maybe with a structured value of some sor= t > like {... "tls_client_auth_san": {"type":"URI", "value":" > spiffe://trust-domain/path"} ... }. And then deciding which types to > support and if/how to allow for the extensible types. > > > I am far from an authority here, but it is my understanding that one > of the primary drivers in supporting SAN over Subject is that the > values are strongly typed. While some of the advantages gained from > this may be less useful in our own context, I feel that it make sense > to keep the values separate and not overload a single value. Whether > that means dedicated metadata parameters or a structured parameter > value, I am not sure what the tradeoffs would be, but both options > sound suitable to me. > > Anyway, those are just some thoughts on it. And it'll be discussed more > today. Suggested/proposed text is always helpful though (even if it's not > used directly it can help move the conversation forward and/or help > editor(s) to have prospective wording). > > > Great. I will work on some sample text since it sounds like that would > be generally helpful > > On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman wrote: > > > Hello everyone.. > > Very excited to see this draft. It helps tremendously in addressing > use cases around oauth client management in machine-to-machine > scenarios. Particularly, the PKI authentication method. > > In reviewing the document, I noticed that the only supported method > for identifying a client using the PKI authentication method is by > referencing its distinguished name. This caught me a bit by surprise - > many newer projects aimed at automating X.509 issuance in the > datacenter utilize SAN extensions rather than distinguished name in > order to encode identity. I am further under the impression that the > community is, in general, moving away from the subject extension > altogether in favor of SAN-based identification. > > Full disclosure: I am one of the maintainers on a project called > SPIFFE, which provides identity specifications for datacenter workload > applications. For X.509, SPIFFE encodes identity into a URI SAN > extension. A number of projects using SPIFFE do not configure the > subject with identifying information (SPIRE and Google Istio being > just a couple). I am also hearing of other X.509 automation projects > which are moving away from subject/distinguished name (even if they > are not using SPIFFE). > > While I think support for distinguished name is absolutely necessary, > I worry that supporting it solely will render it incompatible with > some of the more modern PKIX systems and not stand the test of time. I > know that I am a little late to this, and for that I apologize... but > I feel this is a significant point. > > I would like to open a discussion on supporting the most commonly used > SAN extension types in addition to distinguished name. To accomplish > this, amending section 2.1.2 `Client Registration Metadata` with > additional parameters seems appropriate. In my experience, the most > commonly used SAN extensions are: DNS name, IP address, URI, and email > address. > > Are there significant drawbacks to extending the number of client > registration metadata parameters? I would very much like to see this - > without it, many existing projects will be unable to use the spec. I > am happy to contribute time and text to this, assuming people feel > that this is a beneficial addition. Sorry again for the timing > > -- > evan > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.. If you hav= e > received this communication in error, please notify the sender immediatel= y > 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 > > > > > -- > evan > > _______________________________________________ > 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._ --0000000000002fc1f3057a0f396f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, I think they could be treated as different different= client_auth_methods. But there is a lot more commonality than differences = to the point where I think it makes sense to keep it all in a single docume= nt and under a single client auth method with just the variation on which n= ame is being used. =C2=A0

On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer <jricher@mit.edu> wrote:
Would it make sense for these to be a different client_auth_method entirely= ? Much the same way that we have private_key_jwt and client_secret_jwt toda= y, both of which use the JWT assertion framework but have very different ke= ying and security assumptions. In the same way, here you=E2=80=99re still validating the cert but the means = by which it=E2=80=99s validated is different, so the auth method is arguabl= y not going to benefit from being overloaded. Caveat, I=E2=80=99ve not buil= t out a system using SANs in any meaningful way.=C2=A0

If we were to do that, this draft could go forward as-is (since it=E2= =80=99s fairly done in my opinion) and a new document could better define t= he semantics for the various SAN types, but while building on the framework= and concepts listed in here.=C2=A0

=E2=80=94 Justin

On Nov 6, 2018, at 3:52 PM, Evan Gilman <evan2645@gmail.com> wrote:

Response(s) inline

On Mon, Nov 5, 2018 at 11:53 PM Neil Madden <neil.madden@forgerock.com> wrote:

Is there an intention that any semantics are attached to the SAN being a UR= I or DNS name or IP or ...? Or is it still intended to be an opaque identif= ier?

There are some extra things we could do if we attached type-specific
semantics to the matching (e.g. DNS wildcarding etc), however I think
that continuing to use the values as opaque identifiers would get us
most of what we need while keeping things simple.

On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:

Thanks Evan for bringing this to the WG's attention. More or less the s= ame question/issue was raised yesterday in the area director's review o= f the document as well. I plan to bring this up as a discussion item in the= meeting today. But my sense from some early discussions is that there is likely to be (rough) consensus to make some c= hange in order to allow a SAN to be specified as the certificate subject id= entifier in the PKI client auth mode. We'll need to figure out the spec= ifics of how that works. I don't think there are significant drawbacks to extending the number of client registra= tion metadata parameters per se. I guess I've just been attracted to th= e idea of overloading the existing value because that felt like maybe a les= s invasive change. But perhaps that's shortsighted. And there's nothing inherently wrong with additional cli= ent metadata parameters.

I don't know if we could get away with a single new parameter that coul= d carry the value for any SAN type. Something like, { ... "tls_client_= auth_san": "spiffe://trust-domain/path" ...}. In prac= tice I feel like that'd probably be okay but in theory there's the potential for co= nfusion of the value across different types. So probably there's a need= to indicate the SAN type too. Either with more client metadata parameters = like tls_client_auth_san_uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or maybe with a structured value of some sort= like {... "tls_client_auth_san": {"type":"URI&quo= t;, "value":"spiffe://trust-domain/path"} ... }.= And then deciding which types to support and if/how to allow for the extensible types.

I am far from an authority here, but it is my understanding that one<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;tex= t-decoration:none"> of the primary drivers in supporting SAN over Subject is that the
values are strongly typed. While some of the advantages gained from
this may be less useful in our own context, I feel that it make sense to keep the values separate and not overload a single value. Whether that means dedicated metadata parameters or a structured parameter
value, I am not sure what the tradeoffs would be, but both options
sound suitable to me.

Anyway, those are just some thoughts on it. And it'll be discussed more= today. Suggested/proposed text is always helpful though (even if it's = not used directly it can help move the conversation forward and/or help edi= tor(s) to have prospective wording).

Great. I will work on some sample text since it sounds like that would
be generally helpful

On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman <evan2645@gmail.com> wrote:

Hello everyone..

Very excited to see this draft. It helps tremendously in addressing
use cases around oauth client management in machine-to-machine
scenarios. Particularly, the PKI authentication method.

In reviewing the document, I noticed that the only supported method
for identifying a client using the PKI authentication method is by
referencing its distinguished name. This caught me a bit by surprise -
many newer projects aimed at automating X.509 issuance in the
datacenter utilize SAN extensions rather than distinguished name in
order to encode identity. I am further under the impression that the
community is, in general, moving away from the subject extension
altogether in favor of SAN-based identification.

Full disclosure: I am one of the maintainers on a project called
SPIFFE, which provides identity specifications for datacenter workload
applications. For X.509, SPIFFE encodes identity into a URI SAN
extension. A number of projects using SPIFFE do not configure the
subject with identifying information (SPIRE and Google Istio being
just a couple). I am also hearing of other X.509 automation projects
which are moving away from subject/distinguished name (even if they
are not using SPIFFE).

While I think support for distinguished name is absolutely necessary,
I worry that supporting it solely will render it incompatible with
some of the more modern PKIX systems and not stand the test of time. I
know that I am a little late to this, and for that I apologize... but
I feel this is a significant point.

I would like to open a discussion on supporting the most commonly used
SAN extension types in addition to distinguished name. To accomplish
this, amending section 2.1.2 `Client Registration Metadata` with
additional parameters seems appropriate. In my experience, the most
commonly used SAN extensions are: DNS name, IP address, URI, and email
address.

Are there significant drawbacks to extending the number of client
registration metadata parameters? I would very much like to see this -
without it, many existing projects will be unable to use the spec. I
am happy to contribute time and text to this, assuming people feel
that this is a beneficial addition. Sorry again for the timing

--
evan

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://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, di= stribution or disclosure by others is strictly prohibited..=C2=A0 If you ha= ve 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
h= ttps://www.ietf.org/mailman/listinfo/oauth



--=C2=A0
evan

_________________= ______________________________
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. --0000000000002fc1f3057a0f396f-- From nobody Wed Nov 7 07:20:23 2018 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 09436130DC8 for ; Wed, 7 Nov 2018 07:20:22 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 4sf-UAt0ZwU7 for ; Wed, 7 Nov 2018 07:20:19 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E0712F295 for ; Wed, 7 Nov 2018 07:20:19 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id z16-v6so17833535wrv.2 for ; Wed, 07 Nov 2018 07:20:19 -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=+vFlKtTzfHTCyXDQUh48ACc92U1igigyXDbyOD8Jt/Y=; b=V9kXMpZ4mHS0N9GPUlcjtvwVl4n8r5zvD63lOv6pt1JbsgjjyMUAMTb8LelL/ferM9 qTbGHKivoxk9+OZ92QT/C8Cf5a+MhTZVOVPN4slNkZG2P5Kd+739jaaqzao9vU4m91da 5hA+xySDEzs3dzI6JpEmmPQknnNv8Hu8o9DnaMulK2hmPu5+1nHDsjQ11FXMYFJJuXe7 9/+ynr+MS+qidRQIGE+PJSJAcAbCTYzh4CiVpIRRtpCdIiCJYeHKDZsEaKdNPocmqGTc f08oU/w4nFvLso6vgqMwyZFOplFFZuCCQQGlApDbkKaeBV650eQ/BQHZM48EoyArJrIs RztQ== 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=+vFlKtTzfHTCyXDQUh48ACc92U1igigyXDbyOD8Jt/Y=; b=NjoR8oKL1zl9khxQctkoagEPzkFKIN3pdBPz6FibNuhKDpLK9DvLN5F1UlwMlBJPX5 uCia5z0hOgdf8ufOG09GcxvBMdS5HrCyU500zN6/yetjWbJ39kiOyvw21hTPT6FXtSGe 4+2cLo1p9QnivKQ91yiZmV2PuYyfwiX51cYgPoj0NHl3bUkMuS77yYX8mTMiVz8eJdS8 FWKLs+e6qjsv3IMvfX7pFxaFSNlnnNMvw22QneVtPX40DFVLMSOgVWMpLv2BazKGT7dt SixJXIIdebhKMAcLWiS5T+u76uSjM62poQoA7x/XG/detW0q5QBTj435tY/uT/Gqyg54 5/wA== X-Gm-Message-State: AGRZ1gI9NHiEzWlTuWmoGjxYch9AtHupUmBjEzX3wKcqb4/2WBzGagPq L5lxWgRTRhN1xOp/Swh9ze+r/yQsE+U= X-Google-Smtp-Source: AJdET5dQILWIXJvLiQ6ZijZZGJGl+opzGJKKUCLtWgmZPwYZvmTZ0mfFTTcY5MzrkEdKuZ+AiZv2vQ== X-Received: by 2002:adf:e808:: with SMTP id o8-v6mr632233wrm.112.1541604017588; Wed, 07 Nov 2018 07:20:17 -0800 (PST) Received: from [10.32.3.105] ([194.168.45.114]) by smtp.gmail.com with ESMTPSA id v9-v6sm1649617wmh.32.2018.11.07.07.20.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 07:20:16 -0800 (PST) From: Joseph Heenan Message-Id: <894C1893-8722-4005-8A33-AECADFD18024@authlete.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E2018F02-2B33-46FF-9742-7230D559A120" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 7 Nov 2018 15:20:14 +0000 In-Reply-To: Cc: oauth To: Aaron Parecki References: X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 07 Nov 2018 15:20:22 -0000 --Apple-Mail=_E2018F02-2B33-46FF-9742-7230D559A120 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Aaron, Thanks for putting this document together, I think this kind of guidance = is invaluable. It may be worth slightly rewording 7.2 as it may encourage a growing = misconception that all native apps must be public clients. With many = devices now having embedded HSMs, we=E2=80=99ve seen increasing interest = in mobile apps being dynamically (per-install) registered oauth2 private = clients, and that model has a lot of advantages. (I=E2=80=99m not sure = if we might see a similar model evolving for web apps.)=20 The BCP for native apps does allow = this:https://tools.ietf.org/html/rfc8252#section-8.4 Cheers, Joseph > On 6 Nov 2018, at 10:13, Aaron Parecki wrote: >=20 > Thanks Hannes, >=20 > Since I wasn't able to give an intro during the meeting today, I'd = like to share a little more context about this here as well. >=20 > At the Internet Identity Workshop in Mountain View last week, I led a = session to collect feedback on recommendations for OAuth for browser = based apps. During the session, we came up with a list of several points = based on the collective experience of the attendees. I then tried to = address all those points in this draft. >=20 > The goal of this is not to specify any new behavior, but rather to = limit the possibilities that the existing OAuth specs provide, to ensure = a secure implementation in browser based apps. >=20 > Thanks in advance for your review and feedback! >=20 > Aaron Parecki > aaronpk.com >=20 >=20 >=20 > On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig = > wrote: > Hi all, >=20 > Today we were not able to talk about = draft-parecki-oauth-browser-based-apps-00, which describes "OAuth 2.0 = for Browser-Based Apps". >=20 > Aaron put a few slides together, which can be found here: > = https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-= oauth-2-for-browser-based-apps-00.pdf = >=20 > Your review of this new draft is highly appreciated. >=20 > Ciao > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > --=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_E2018F02-2B33-46FF-9742-7230D559A120 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Aaron,

Thanks for = putting this document together, I think this kind of guidance is = invaluable.

It = may be worth slightly rewording 7.2 as it may encourage a growing = misconception that all native apps must be public clients. With many = devices now having embedded HSMs, we=E2=80=99ve seen increasing interest = in mobile apps being dynamically (per-install) registered oauth2 private = clients, and that model has a lot of advantages. (I=E2=80=99m not sure = if we might see a similar model evolving for web apps.) 

The BCP for native apps = does allow this:https://tools.ietf.org/html/rfc8252#section-8.4

Cheers,

Joseph





On 6 Nov = 2018, at 10:13, Aaron Parecki <aaron@parecki.com> wrote:

Thanks Hannes,

Since I = wasn't able to give an intro during the meeting today, I'd like to share = a little more context about this here as well.

At the = Internet Identity Workshop in Mountain View last week, I led a session = to collect feedback on recommendations for OAuth for browser based apps. = During the session, we came up with a list of several points based on = the collective experience of the attendees. I then tried to address all = those points in this draft.

The goal of this is not to = specify any new behavior, but rather to limit the possibilities that the = existing OAuth specs provide, to ensure a secure implementation in = browser based apps.

Thanks in advance for your = review and feedback!

Aaron Parecki
aaronpk.com



On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi all,

Today we were not able to talk about = draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth = 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-o= auth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com
@aaronpk

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

= --Apple-Mail=_E2018F02-2B33-46FF-9742-7230D559A120-- From nobody Wed Nov 7 08:09:09 2018 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 8B9DE1274D0 for ; Wed, 7 Nov 2018 08:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 pcSikfb1IBPf for ; Wed, 7 Nov 2018 08:09:03 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 4BC9E130DCA for ; Wed, 7 Nov 2018 08:09:03 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id f10-v6so2442444wme.3 for ; Wed, 07 Nov 2018 08:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=749W3u7yIsL5zB9kA/k9+a3nNdzDUoWMHvmSUFCwxiE=; b=S3PjoHEc0Egnq0OP2CW3IWBUcdZTcFnLDcDWa2INrFhd4lgXft5zcVg4AIMUoa27Fi TpEVSi3PHwmFFn07+rn4B4h1SxNjHBZstdUfv9CGDkHHF2n5KPsKkJsOBC+B5vxGSECt YW6kSAY39rorFBvEMMp2EfeJCOI/RvzbjHuhY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=749W3u7yIsL5zB9kA/k9+a3nNdzDUoWMHvmSUFCwxiE=; b=dk6rM5RlsifVhTtP13GCRij3ZomwlEIrTa+VH0EDNUYsiDi6ddk9pyqneuwYzjKG8d pB1NGdhsd3nByqxeY1recCrWiZprtVL6exnqORAv2FK33dOTKbVQcnQkOP/CzLyd2G8Q opZmBAYj+QSyTS4gapQwxdxLNgTMewBcTzgyOuaxNlzE3gYB2y+LHiMlbduSyriTU7Xr vlqA2x/DXaWCQ/Btd91tVz5pjDn1YmrgA4z110wb2JjbS13UnHM84bTXj5rV/RVkBJaX 9E3bpzqAbzbho0D6xzV5KwdHeHEI/W8kynDsyI+Bqo3hWBDatzI9u5p8eCDDHc4RG2I6 6wCw== X-Gm-Message-State: AGRZ1gIgPteURrbmoFfxqcxQWtRO0ppTAp/HeVNVC51bDGBRGRhdFY+G YCnvbzdppHkKjyEaNd3Yg2kRuTCV3YvOGeBqkdVgLv7KMOb/8nckln/ySnn3l68OGVj7bvzESgO qCgWt8CikMMB+Ow6F8qcdasdNqIFNB6cvSU+Z47EbQMM7x6UZYYFjk+EuRj+t79Tqjg== X-Google-Smtp-Source: AJdET5fcxD6gTQhZsyY/N+YxCdyamcpf03UgZ0stvVNo3/oMb74w6SLU+ieoB98B3vkS43khNDw29Q== X-Received: by 2002:a1c:c50f:: with SMTP id v15-v6mr742299wmf.22.1541606940962; Wed, 07 Nov 2018 08:09:00 -0800 (PST) Received: from [192.168.1.140] (host31-51-173-216.range31-51.btcentralplus.com. [31.51.173.216]) by smtp.gmail.com with ESMTPSA id x139-v6sm8551072wme.3.2018.11.07.08.08.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 08:09:00 -0800 (PST) To: Joseph Heenan , Aaron Parecki Cc: oauth References: <894C1893-8722-4005-8A33-AECADFD18024@authlete.com> From: Simon Moffatt Openpgp: preference=signencrypt Autocrypt: addr=simon.moffatt@forgerock.com; prefer-encrypt=mutual; keydata= xsFNBFpM/n8BEADaxItKbVxF35pwLIskzqD/KnZPVk3B5bUijuHNNCntemEq5QEfHh1b9Ogx As2hw/ZVND6Q97V7NOMithmrP0N4du+66yK+Ejyqfa8yWQPtx1q7OuscIA9YkrO9NJlKgPQL LTDoMP2hpiu+dAcMs1QxJadXjyGGFzCrLzPgOzzyV6NOGpqdSPDYf819XO2fNgcJD5uQ8D9j ULMufQ+J/+kFPTlYqRai1NTO3QxLk3woFkF8TTqslKjcKmwV7jGtSJFCIKA6CRSZjw9WIq9D 5MtDXwsdh9gUJB+KtwnzTLtOp7en+0YH14KgV/RQyy/dkXzhm8YqhufnP2e4JhFK4TmDLoZU otWid8Hkc8tNn1HwTmBxjDgU7kqvkj06RH9SyZFo8Os8ttcQYtWVahclpnJzogJ8qqL1g2VE hTEjaHdAKi8PC5JK7FEXs041fs+bymnRTczej+ZqU0oFrE/kB4n4X6tq/iWg44YAmcEfiGNN aewcI3oNuOm8qgb+0Z9HldVGSpK9W1eHDVGzNsVfLXSI2h15b0aTurfA/MEtIB5AntZLMgJA R7VQmgzlqT/ujEGMRZZIHxOTxOWisyN267NYIHRZ6ODNiGfM9NMt7srTh9vk1IguhynxdEWN S6MwnrbkdKJf3VlAMcOyckn0lXLbBKgoCXsB0zpOeKTmmi3wgwARAQABzStTaW1vbiBNb2Zm YXR0IDxzaW1vbi5tb2ZmYXR0QGZvcmdlcm9jay5jb20+wsF9BBMBCAAnBQJaTP5/AhsjBQkJ ZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJECJvtLWEryhHkJAQALoR//eJenZoE1SL MNsM0VthhVp7am/5YfcGzkE02h8n96n5R3hJzQaBp9BDdMt2FFWbwEkWaHDujut4rONcWXxh hyfN4uoxzXzqBmcMlemNCaI9IGefGKx6rGEY5PkxAEtCYX2umLbFQGF3ggNOZeIytlK++9Z/ RgYIzKy6yYelxfChAKOd9w9UkuuJ2EfzXcmrFE6DttBBAYIM8qeWe4pVvNqpX1b0cHqkRvYP s+xcbd7qcgMGFOZU3iuBeThJ3Pcy0FncbA+Txr6TZoWChOgqKntlfbDcRbrW7eLig1JFwmm8 Mdt/SbhA4Ry+TyQ7XogsZLNYd4uxF4GVJS4AvYT0cCsDWeUUFonMyvdjJ0b5PlH1NmqKekV0 ey/67RPzGg78ZXdC9R1r+KhDNzd68yb3RCeQ/9eYYHhQ33ShZqhZ8pFOWqy3iuY3MY30kfsg 51ZUBiEZw35GSNBgFmg1sqg37ZSUJLwz89hT1UuwrktHVMxPbBvePr95AY38X+w2JQJvDpli TYu9U4AunxQBdoUMjg2bnIpPxThssTSt6uxMtARi8tItYMVx7hOmJldQQuCELcqkpvqW2uSa Yf3D9tXuEDuBA2b2lQuu2nNgxZe/5biZUoAyBYOKz6ABmZkVFfLh8N5T33UTiAEk9XMclmOd RK97tm+7Zptrv/jNpq3SzsFNBFpM/n8BEAC0WEJPdG15JFgQCZtsacXgltd49ybCqb+Az64f JyqardhHVX1YBbzWFrToKq/MORA67KhG1iAr8qvd8z1DM9K3bfm0pSGtziXAhUV7/+XEes5U ZRtYhkezBmAYZjOUmBPISInM/vSBEHzwUTbpJncUfMmZEJEUXTTSh5xoD2YXuTznY8LccpUV BrGP36BH2aBCyzqcRxXov6Tt9e8Y3QT8sbIM/luBDubL8pPcBDw6dul4g77GKUhjTIdlmF9C wq/Ow9EhT5M+U/msTjyIrInPEDAC+uNGMuMtJFAWU1ZollOqu56GXQU/iPvwmYPwcqjkcNxU hgE0+KK7JF3CwI8loilrYiOmTpaKNti00pFj3EEb2M7Im12L56yJqHjAlSXFaXvGca4LOzm/ H1iO4IcHUgj9tj3hI1DFsdimfyzxuLW67uSwoAKHg3lUMR5di34xfg6dclYH7gMI2o31tkpw CAtDFKDCIKQ118Jph/5aQHOw8nAyZodJZ3ZJGP1TBhlitf6R5vYneQchD7JBueMGHwUZzP0Q ByUN8y78M4+pfasEk4TrEOtR41dFSWD/qm5HG1qNay9gqfn4lfCOQUeYK2qplwgYtwdIdITk BRLfKLdhyJHW2C9e8p0C3lmnmgw7SEA22h3bNx6lL5BABfqQDu1H8HXYcTFS8FUTpxku4wAR AQABwsFlBBgBCAAPBQJaTP5/AhsMBQkJZgGAAAoJECJvtLWEryhHf0AP/3Ms+rqgkONi88Sa FSus/EQ1jCv3jOBe+wrBX+vhNr5fEuOD9InxzlCy9VqfTI7wwqFVXSedyE/9h+Lb1FhJBT6a q7iYtzxkMGq0dBd+8V0oZc4BPClGobxTZ5G0CmcheHcqJrCMoj3x2Fs0lN6Tit98Fip4rhxh y1pTam76ejTCTFOWECFHPDy4ez9lHUZjHGZyBIVAAk0joCrb8zRWk2EFqm5/pu7q803cx8mU 6eNljkdXOVpFxneOJe6Mds1livs/1kmjii8Ffls2VkAlydCjpSVrTUjj9UOy2vlRET1UEqB8 qqzcRLqOSEFYwwzBIDYWCL2Mh+Cr5uIHR3qvgbU8+5DZZRLNPaG5prw0vIlBzcVMKAEpK3Hb oZdajUdCov1ZaZJHsbQg5lnY0lAn62kKxC8FeP/qX6O8baa+GTKCAXdfmIU5dP8yZ9ROxqxR vz7OwioE/vFOzffoUQ/Y/4o6K2dzdP/GzwZ6t9ZV0iTio83pZEE2BlkYP+/TRhEpPdDaBmMs 23Q74rw1nXpWEKuQLPFKSciQHqHxSdSVo+sLZwCrTD5sVaTvRfqQpgl+3PK7jdMO+hMBM24I jgA6Iz9gM2S3HQgsJ44Xt5sfy/X+8g4ycLurxO92YuxKaCg9JbPBUictMBqttOFcPbAbdzhf lzTn1OR1F1ZcV9br/vdY Message-ID: <5d754635-836d-07b6-4f6e-a2fa2ebbeaca@forgerock.com> Date: Wed, 7 Nov 2018 16:08:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <894C1893-8722-4005-8A33-AECADFD18024@authlete.com> Content-Type: multipart/alternative; boundary="------------C26569D63D337176A00C42F7" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 07 Nov 2018 16:09:06 -0000 This is a multi-part message in MIME format. --------------C26569D63D337176A00C42F7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It's an interesting topic.=C2=A0 I think there is a definitely a set of options and considerations for this.=C2=A0 Namely operational.=C2=A0 For = example, hugely popular mobile apps (multi-million downloads across different OS's) using dynamic reg with per-instance private creds requires the AS to be able to store and index those client profiles easily.=C2=A0 Smaller= scale custom built authorization servers are not necessarily going to be able to handle that - hence the popularity of assuming everything is generic and public coupled with PKCE. On the other hand, if a less popular first-party app used internally for employees for example, might well go for secure element integration on the appropriate mobile OS. So, I guess options are needed and best practice for a few subtly different scenarios. Regards Simon On 07/11/18 15:20, Joseph Heenan wrote: > Hi Aaron, > > Thanks for putting this document together, I think this kind of > guidance is invaluable. > > It may be worth slightly rewording 7.2 as it may encourage a growing > misconception that all native apps must be public clients. With many > devices now having embedded HSMs, we=E2=80=99ve seen increasing interes= t in > mobile apps being dynamically (per-install) registered oauth2 private > clients, and that model has a lot of advantages. (I=E2=80=99m not sure = if we > might see a similar model evolving for web apps.)=C2=A0 > > The BCP for native apps does allow > this:https://tools.ietf.org/html/rfc8252#section-8.4 > > Cheers, > > Joseph > > > > > >> On 6 Nov 2018, at 10:13, Aaron Parecki > > wrote: >> >> Thanks Hannes, >> >> Since I wasn't able to give an intro during the meeting today, I'd >> like to share a little more context about this here as well. >> >> At the Internet Identity Workshop in Mountain View last week, I led a >> session to collect feedback on recommendations for OAuth for browser >> based apps. During the session, we came up with a list of several >> points based on the collective experience of the attendees. I then >> tried to address all those points in this draft. >> >> The goal of this is not to specify any new behavior, but rather to >> limit the possibilities that the existing OAuth specs provide, to >> ensure a secure implementation in browser based apps. >> >> Thanks in advance for your review and feedback! >> >> Aaron Parecki >> aaronpk.com >> >> >> >> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig >> > wrote: >> >> Hi all, >> >> Today we were not able to talk about >> draft-parecki-oauth-browser-based-apps-00, which describes=C2=A0 >> "OAuth 2.0 for Browser-Based Apps". >> >> Aaron put a few slides together, which can be found here: >> https://datatracker.ietf.org/meeting/103/materials/slides-103-oaut= h-sessa-oauth-2-for-browser-based-apps-00.pdf >> >> Your review of this new draft is highly appreciated. >> >> Ciao >> Hannes >> IMPORTANT NOTICE: The contents of this email and any attachments >> are confidential and may also be privileged. If you are not the >> intended recipient, please 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= =2E >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> _______________________________________________ >> 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 ForgeRock *Simon Moffatt* Technical Director Product Management =C2=A0|=C2=A0 ForgeRock *t* (44) 7903 347 240 =C2=A0|=C2=A0 *e* simon.moffatt@forgerock.com *twitter* @simonmoffatt =C2=A0|=C2=A0 *web* www.forgerock.com NOTICE: This message, including any attachments, may contain confidential information. If you are not the intended recipient, please advise the sender immediately and destroy all copies of this message and any attachments. ForgeRock Ltd may monitor email traffic data and also the content of email transmitted over its network for security purposes. No employee or agent is authorized to conclude any binding agreement on behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd is a limited company registered in England and Wales; its registered address is 60 Queen Square, Bristol, BS1 4JZ; and its registration number is 7227664. --------------C26569D63D337176A00C42F7 Content-Type: multipart/related; boundary="------------CF2BDD45B6184047CF015AC4" --------------CF2BDD45B6184047CF015AC4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It's an interesting topic.  I think there is a definitely a set of options and considerations for this.  Namely operational.  For example, hugely popular mobile apps (multi-million downloads across different OS's) using dynamic reg with per-instance private creds requires the AS to be able to store and index those client profiles easily.  Smaller scale custom built authorization servers are not necessarily going to be able to handle that - hence the popularity of assuming everything is generic and public coupled with PKCE.

On the other hand, if a less popular first-party app used internally for employees for example, might well go for secure element integration on the appropriate mobile OS.

So, I guess options are needed and best practice for a few subtly different scenarios.

Regards

Simon



On 07/11/18 15:20, Joseph Heenan wrote:
Hi Aaron,

Thanks for putting this document together, I think this kind of guidance is invaluable.

It may be worth slightly rewording 7.2 as it may encourage a growing misconception that all native apps must be public clients. With many devices now having embedded HSMs, we’ve seen increasing interest in mobile apps being dynamically (per-install) registered oauth2 private clients, and that model has a lot of advantages. (I’m not sure if we might see a similar model evolving for web apps.) 

The BCP for native apps does allow this:https://tools.ietf.org/html/rfc8252#section-8.4

Cheers,

Joseph





On 6 Nov 2018, at 10:13, Aaron Parecki <aaron@parecki.com> wrote:

Thanks Hannes,

Since I wasn't able to give an intro during the meeting today, I'd like to share a little more context about this here as well.

At the Internet Identity Workshop in Mountain View last week, I led a session to collect feedback on recommendations for OAuth for browser based apps. During the session, we came up with a list of several points based on the collective experience of the attendees. I then tried to address all those points in this draft.

The goal of this is not to specify any new behavior, but rather to limit the possibilities that the existing OAuth specs provide, to ensure a secure implementation in browser based apps.

Thanks in advance for your review and feedback!

Aaron Parecki



On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi all,

Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.

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

_______________________________________________
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

--
ForgeRock Simon Moffatt
Technical Director Product Management  |  ForgeRock
t (44) 7903 347 240  |  e simon.moffatt@forgerock.com
twitter @simonmoffatt  |  web www.forgerock.com


NOTICE: This message, including any attachments, may contain confidential information. If you are not the intended recipient, please advise the sender immediately and destroy all copies of this message and any attachments. ForgeRock Ltd may monitor email traffic data and also the content of email transmitted over its network for security purposes. No employee or agent is authorized to conclude any binding agreement on behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd is a limited company registered in England and Wales; its registered address is 60 Queen Square, Bristol, BS1 4JZ; and its registration number is 7227664.
--------------CF2BDD45B6184047CF015AC4 Content-Type: image/png; name="ForgeRock_retina_email_bw_logo.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ForgeRock_retina_email_bw_logo.png" iVBORw0KGgoAAAANSUhEUgAAAXIAAACMCAYAAABhyyLUAAAACXBIWXMAAAsTAAALEwEAmpwY AAAFFmlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPD94cGFja2V0IGJlZ2luPSLvu78iIGlk PSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9i ZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42LWMxNDAgNzkuMTYwNDUx LCAyMDE3LzA1LzA2LTAxOjA4OjIxICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0 dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2Ny aXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIgeG1s bnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4bWxu czp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZUV2ZW50IyIgeG1w OkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ0MgKE1hY2ludG9zaCkiIHhtcDpDcmVh dGVEYXRlPSIyMDE3LTEyLTIwVDIzOjQ5OjQwKzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAx Ny0xMi0yMFQyMzo1MDoxMyswMTowMCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxNy0xMi0yMFQy Mzo1MDoxMyswMTowMCIgZGM6Zm9ybWF0PSJpbWFnZS9wbmciIHBob3Rvc2hvcDpDb2xvck1v ZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgeG1wTU06 SW5zdGFuY2VJRD0ieG1wLmlpZDpkZWU5ZDJhMS01OGMwLTQ1NGYtYTNhMS1jZDI0ODY1OTA5 ZDciIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6ZGVlOWQyYTEtNThjMC00NTRmLWEzYTEt Y2QyNDg2NTkwOWQ3IiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6ZGVlOWQy YTEtNThjMC00NTRmLWEzYTEtY2QyNDg2NTkwOWQ3Ij4gPHhtcE1NOkhpc3Rvcnk+IDxyZGY6 U2VxPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0iY3JlYXRlZCIgc3RFdnQ6aW5zdGFuY2VJRD0i eG1wLmlpZDpkZWU5ZDJhMS01OGMwLTQ1NGYtYTNhMS1jZDI0ODY1OTA5ZDciIHN0RXZ0Ondo ZW49IjIwMTctMTItMjBUMjM6NDk6NDArMDE6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFk b2JlIFBob3Rvc2hvcCBDQyAoTWFjaW50b3NoKSIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlz dG9yeT4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBh Y2tldCBlbmQ9InIiPz6hHcrKAAATNElEQVR4nO2d/3HjOBKFn682AIbAieC4ESwngtNGsHQE J0dgOgLNRCBtBOONQNoIxIvAvAjMi0D3B6WyRhbRDRAgCOl9Vaj5QQDdIKXHFtgAHw6HA1Lh 4eEhtgskfXIACwB/APgLQB3RFzJjktLGpJylkBM3cnyId3H8vxbAlyjekCRISRt/ie0AIYHI 8Vm8z3ma0BdCgsKInNwSBXrhXqAX8iF2AL4G94YkTVLamJSzFHLymQI68T7nVwBNEG/IzZCS NnJqhaRIAXvxPrEBRZzcGIzISSoUcBfvEx36B5ydB3/IjZOSNjIiJ3OmwHjxPuc7ZBHPFHUI mRWMyMkcWcGfeJ9oIacbLtELee3RLkmUpLQxKWcp5PdABWAdoN9H9PPjQ2QA3o5/fkEv/OSO SUkb/xHbAULOyNBH477ZwSziAPB8tI9APhASDAo5mRNLfIipT16E4/nR9okFgDKAH4QEgUJO 5kIO4N8B+t2gj8hNXJvKYVROkoFCTubC+dSGLzrI0XiJ69F3gX6+npDZQyEnc6BEGNH8Dvmh penBaoibCyHeoZCTOfAcoM8WwDehTgVzimOOn+fOCZklTD8ksakQP93QRId+b5Z2vEskJVLS RkbkJCYZwkTjO8jphkvopk0yhPGREH8cDodkCrk5agCHAKUU7OYB+iQ3Rmy9symMyEkscsRL N3RJLWRUTmYLhZzEIma64cKh7xJMRyQzhQ87SQwKAPsA/b5A3vBqj+uvftPQgu/5vBtS0kZG 5CQGIVZNdtClGxYjbOTgzohkhjAiJ1OzAPAjQL++0g0lWjAqvwtS0kZG5GRqQkTjDfylG0p8 99AHIV5hRE6mpEaY7I+vMGeq5Oij8bG0YDR+N6SkjYzIyVRkCJNu+Iow6YbXePTUDyFeoZCT qVghzAZUT8LxEm7phpfsIN8wCIkCp1bIFOTwM7VxSeh0w3P4+rc7IyVtZEROpiDEplgdwqcb ntiAIk5mDCNyEpoSwDZAv5p0wz3M29Rq6NBH493IfkhipKSNjMhJaEJE4w106Ya5B1vfIYt4 6cEOIe7E3rWLux/eNEvE293w3YMdzbx+eaybK+qShIitd1baGNsBCvnNksGPmF4WzTTN2pOt hcLW1sIvkhCx9Y5CTubACmGi8VywW3qyoxHmxUWbUtGGJEJsvaOQk9jkCCPiK4XtU4Q8tpQK W28Xbd4UbUgixNY7CjmJzQ/4F/F3yAuKKk+21oox1gNtl4q2JAFi6x2FnMSkRJhofCnYzfA5 Qna9YeQKW++G9pnQniRAbL2zKUw/JL7RTH/Y0kJe/LOEv3TDVqizwrBYZ2BUTqYm9p2EEflN USFMNF4KdnP4SzfMBFuFsq9c6IfMnNh6Z6WNsR2gkN8MGdJPN6wUtrbKvn4o+iIzJrbeUchJ DGqEicZzwW7pyY7mhmFrq1T0SWZKbL2jkJOpyRFGxFcK29oI2Yfovln2uVf0SWZKbL2jkJOp +QH/Iv6O6dINfyjGuHTsu1L0TWZIbL2jkJMpKREmGq8Vtm0j5KGSC3YyuM//a25IZIbE1jub wvRDMpbnAH22kIW8hp/MkBfI6YbPcBfjDExHJKGJfSdhRJ40FcJE4wvBbgY/GTKaaDn3ZCcX 7JCZEVvvrLQxtgMU8mTJ4G9q47xsFbbXnmxVCltbT7bWCltkRsTWOwo5mYIaYaLxQrBbeLLz phhj6XlspcImmQmx9Y5CTkKTI8ziH03U6itCLhW29p7Ht1XYJDMhtt5RyElo1vAv4u+Q56sX nmxpBLUKMMYDmI6YDLH1jkJOQlIijMDVCttvnmzlgp0MYX5xHKDbz4XMgNh6Z1N+iX2ySHLs ADxEsFvDT+bHN8jphkuEE9v82H8dqH9yhzykFOk+PMTQDzIDMviJZDsAX45/DpEj/Jt+NH6Q yKSkjVwQRFJgBT8R8gtk8Xz2YEciQ5h928mdwoiczJ0cfiLkFn0UbKLEtJklvwJoJrRHLEhJ GxmRk7nTwc8UxJOizhTR+DndxPbIjUIhJ3OnQz8lMoYdgFehToVpF+x8g/zQlRAVnFohqfAG 96wVaQojQ7/4x7V/WzrwYefsSUkbGZGTVHh0bLeBPA+9xLSbWn0HRZz4JHYiOxcEJccCYRbK LBS2t5Z9vkO3u2GoxT9DC4JIAsTWO5vCiJzY8op+ztk3mnQ8zQPLczSR7zOmXWlpOwZCZGLf SRiRJ0mBeMv018q+NAuIQo1jqGwV4yMzIbbeWWljbAco5MmiFVTfUyEZdFMhlWIM2wBjMJVC 4ROZCbH1jkJOpiBDvK1sa6EPTeS7COD72HGRGRFb7yjkZCpqxItc3wzty5HtfZd3cMfD5Iit dzaFDzvJGGqEWdSyUtQZWiS0gfwwtgbTDcktEftOwog8eSqEiWJLhe0tPke+udAmA9MNiYLY eseInEzJBmHSETVzypdR+XfIvxBWYLohuTVi30kYkd8EJcJEs0uF7TX089B5ID+HylbhP5kp sfXOShtjO0AhvxlOguqzaMX5HfNMNywVPpGZElvvKOQkBjnCzD2vFLYXijplAN9MZa3wicyY 2HpnU7j7IfFJjTB7en/B+OyYN0y7u+Gv4Da1SZOSNvJhJ/HJN4RJsxsb3S4xfbphO6E9cucw Iie+qRBmWuEr3LJjMvh5cbOWFn003k1kjwQiJW1kRE58s0GY91C63hyeMW26oeYFz4R4hRE5 CUGJMKl3j+hvFFpyTLsgZ4f+lwO5AVLSRkbkJAQ7yO/IdGEFu+hak/Hik7HvFiXECQo5CUWI FY0ZdIuEgP5XwSKAD0NsEGaFKyEinFohIakRLx3xB6YVch8pkmRGpKSNjMhJSL4hzIM/zZTJ XwHsDvECijiJCCNyEpolwsxVa9IR9wj/Vp4OfTTeBbZDJiYpbUzKWQp5qoRYVdmgz9c2USL8 xlW2mTQkEVLSRk6tkCl4DNBnAXmjrB3CZM+caEARJzOAETmZii387wbYQZ7WyBEul9x1tSlJ gJS0kRE5mYoQUXkGOR2xRf/Q1TevoIiTmcCInEzJGrp9w23oIO80mMH/fitMN7xxUtJGRuRk Sp7gP7sjg5yr3qHfkdAXTDcks4IROZmaGmEWCWnmq31kz3RguuFdkJI2MiInU1MjTDSruTn4 2AuFuxuS2cGInMRggX4JvW80Od1jsmda9NE4uQOS0saknKWQ3xIh0hFbyC91KOG+SIjphndE UtqYlLMU8lsiR5jXrzWQpz4KuGWw7BzakERJShuTcpZCTgiZiJS0kQ87CSEkcSjkhBCSOBRy QghJHAo5IYQkDoWcEEISh0JOCCGJQyEnhJDEoZATQkjiUMgJISRxKOSEEJI4FHJCCEkcCjkh hCQOhZwQQhKHQk4IIYlDISeEkMT5JbYDN0KB6y8q2E3qRXwKXD8PDfiey1Bk6M/7JS3CvBvV RIb5+HJXpCbkFYA/Avb/VVkvB/Bv9K8NK4S6DXpB//P4d1sqjBvz38c/d/B/Y8nRv3/zX5Bf 29Yd7f8F4BV2wr6CfJ5daQA8ebbZAfgPevFq4HbdTVQAfkN/7jPBjx3czrmWBT6ufy7UPfel HahTwfx5135HAd01/BMf73mt0Y+lQT8WG1txORwOyRT0J/oQsEgU6N/36Nq/y3sqfY75HcAa 41+xlh/7GeOLjR9jzrnmmoS2+Yb+OmbK8Q5Ro7+Grtfehw8nlujH5fv610I7LZrP5zs+hD5H f83fj+Nax9Y7K22M7UBCQr7yaGcN/Rcq1JhXSvuXLOEuJte+SJXC5tbz2M/LdkKb7+gjWFsK APvIPoTypbrovxbaaFgrbRdnbUr8fKPMY+sdhdy9XCODvw/uedlDJ+Yhx6z14YTmC+JScsHu NuA52EawWQvjPaeCvxvneVla+BDSl3f8/BmshfoaHzU2i4t2Gfrvw4+jD/vYemdTmLViJkP/ hS4C9F0c+84C9G3jw1pZdw1d9GzLBvf3IOwZunNZwe7Xmw0r2Il5KF+e4G/uvoLu8/yEz88t OgCPx7//hn4uPx1i30lmHpGvA9s7oI8CTIQe8wHyT+1QPkhjP7ENOPZtBJsHfI5ELykQJhK3 vfYhfVlfsVULbYaolDYrxXgBILre2ZTUslZMdPCbHbCAXQTa4iOyzKF/kFeg//DWFrZOdJDH XCr6eUafSXCN4nhcS4OfI6wh+x38ZAW0GBfRNwFs5pCvf4Y+Iq4Hjq9hF/3uzv5eWrRbH9t2 Qh1XX4qBtg2uZwu5UEEXiT/iI0Pltoh9J/EYkQ9FVq68GWydR1U1rn9pc+izDEzRWW1opxlz jn7eT/Lh2hgAXWRqOg/AxxTO+bkoFb5rfKgt+rFhrM0S8rOVt4G2ldDu/PovBvpYCGM4LyvD OHz4UuDn6/+O4enKWrDj6l9lGONVYuudlTbGdmCmQl4Z7JzKHrqoO4NOSOuB9rWhjc2YJR+q K21Khd/a8wB8nIulhd9AmkIO9OM9iddQya60exPaHKA/hwuFD0N+aH2plL5kkJ+11IKtcwro xrZS+vcTsfWOQj6evcHOSbwyyz4lIX0baFcb2tiMuRDs11farBU+ZxY+uJKqkANy2mp5Ub8Q 6tsIp02fS8d2tr5I1IK9c980Ir52dSS23tkUZq18JoOcpfII+yftUptcYXcMjUObhXDc5Tzc G7bZD38Ix19hP8/bAHgR6vzLwZeNgy8+KKDL+NrgIxPlpqGQf6YUjm/gJoodgO8jbU9JAfMX ZYf720vGhcyyfiEcd31AWMN80y2v/F8h9CndHEJQgCL+iVsS8hLyzyzNz+RCsPPnCB83wvF/ juhbYiEc7y7+nQv1TefBNC0hlVKwe8nzBDbG8JtwvL34d2mo21ypb8NGOF5c/Ls01G0QJ/9f I+KvuCMRB25LyKdiN6JtCzltLQQZ5BTC3cW/C6F+4+bKXVHAPIfcwU4Md86e9PxHOJ5Z9BVr wUymqNMF9mF2UMg/I0VQY2kD93/JAvLq1Bb2wmxb/57I0Au4FD2+Wvb7PydvPmgt6mYjbcWk wrj9ZJLjlhYE3SMFhjNXCui/jGOmi+6RPzB8wy8t+pGemRB31og3/TM5FPLP/I2wc6i5x74y jPe1AfDNoV2B+43Kc4y/jt8w/fnLLOp2gXyYigy9mKezp/gIOLViTzmibQ6zALQj+nahw3AK YSO0Lfy6clc0cMv4uJYiaIM0bdh57GsOlHDb5TE5bknIdwAeHEp90U8j2JFya01UwvH/jujb lgZ9tNIMHG+F9iZR+Yrh8/1N4ZcNLwZbQ2VnacMnr+jPTzdwfGdoW2DcL4FKON5c/HtnqFsi 3MN5LR3kz8sKdxB03JKQ+2InHK/g9gHO0L8ezsSrQ78uNDCL+KlOZzi+gNuvE1ObTrCZOt8A /A7zGBuhj5Wj7RryuoBLGqFPKRMqJB36z7AmzdB5dWcqUMg/00H+AP+A/VP9tdCmVdj1RQHd zehVOL6C3XkoYY6OdhZ9pUgJ+XxJD54XcFuiL4nutXRCKcWwcvDFBx0+ApEG8jRVAfcbYBrE 3iNgpnutVAY7p7KHTsQyhNs0a49eHK6VtQf/S4Xfe+huCgXkvTGqgbamBUa1wrYLJptrDJ/3 vaHdATpBeRP6OEA/91tiPptmAf31MtWvBVvvuB4MSOf9AMtfkLH1zkobYzswUyEHxm9jm0H/ fst3+N/GNlOMQSMqJkG7PA/XxpBBfx6utZd8qBVjcMHVZmFodyoLwXal6ON0/Yf6KqB/Mcra ky/lQB/ZsZ/T5/Ed7tvYVgPtCoWPpu/ZJ2LrnU15OApkEjw8PNQY/om4g99UowX6SFpLi48H hBnsHrC8wByRu465hHyD+x3mKRRNH+c00L1Y4pINhuc7TSKxQ58y6kqL60vXTTZN1wswXzOg Pz9fYJ4r38PuM7Q7+3sBvWD59qXDz1OE2UDbBtcf+tYwn7sHwzGpLdB/1n8X6gAAUtLG6HeS GUfkgG5KZGzZCz7UhraaMa8E+5ooRepjbJF82Aa0PXQOTTZrg68n9o52TxTgq96uFRMZPE4F xdY7m8KHnWYeEfYBZIvwCxZeYB5DBvmXxxPCbld6i9vhStkUJczz3A38vQptiBfoMqUahPGl gt+HpR10WSwrxE+d9AqF3EwHOU3PlQbmfGJfdBgvKkC49x0+Yrq0yylpIGdTrGCestgg3C5+ 0vTQJRuE8WUFv/u67CCvVchgN206eyjkMh2AX+G2jH2IV/Qi3nrs00SD8aIC9F9klxWJpv42 HvubGzXkIGANs5Bt0H/+Wg/+AP3n+Xe4PSQO4csT/AczL5B9LBDuQfn0xJ7bmfkc+SUlxs3X bmG/iKYW+rNBmrfdQxcd5dBnRAz5XVj4Peaca3yxtVlb+F4ofFgp+6rhPlf9Dr/R7xhfDug/ P/lAv6Z2WkqlH8VQB7H1zqaktmlWi+FFI80E9nfHUqBfql9Ct2/3Dv1Cj8bBZgt/Y36ELBq5 ot8WH9H5Av1y/VLR5hVu58G2vo++TTZby/6fYN7SoFD2VeMjD/t0zjOhzSv6hT2v8Bv5uviy O/OlHajTws/CsB36z+dvQr0CN7D52/8BhY+9JyJF0ywAAAAASUVORK5CYII= --------------CF2BDD45B6184047CF015AC4-- --------------C26569D63D337176A00C42F7-- From nobody Wed Nov 7 11:30:39 2018 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 6D529127B92 for ; Wed, 7 Nov 2018 11:30:37 -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, HTML_MESSAGE=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 zEzt0O-YhoF2 for ; Wed, 7 Nov 2018 11:30:35 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id B654B1200D7 for ; Wed, 7 Nov 2018 11:30:35 -0800 (PST) Received: from [IPv6:2601:282:202:b210:bdbe:87c1:197b:4c88] (unknown [IPv6:2601:282:202:b210:bdbe:87c1:197b:4c88]) by alkaline-solutions.com (Postfix) with ESMTPSA id 0ABD631689; Wed, 7 Nov 2018 19:30:33 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8D3084AF-F09D-4CE0-9160-BC5FD0B1B2D2" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 7 Nov 2018 12:30:33 -0700 In-Reply-To: <5d754635-836d-07b6-4f6e-a2fa2ebbeaca@forgerock.com> Cc: Joseph Heenan , Aaron Parecki , oauth To: Simon Moffatt References: <894C1893-8722-4005-8A33-AECADFD18024@authlete.com> <5d754635-836d-07b6-4f6e-a2fa2ebbeaca@forgerock.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 07 Nov 2018 19:30:37 -0000 --Apple-Mail=_8D3084AF-F09D-4CE0-9160-BC5FD0B1B2D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 7, 2018, at 9:08 AM, Simon Moffatt = wrote: >=20 > It's an interesting topic. I think there is a definitely a set of = options and considerations for this. Namely operational. For example, = hugely popular mobile apps (multi-million downloads across different = OS's) using dynamic reg with per-instance private creds requires the AS = to be able to store and index those client profiles easily. Smaller = scale custom built authorization servers are not necessarily going to be = able to handle that - hence the popularity of assuming everything is = generic and public coupled with PKCE. >=20 Having unique client identifiers does provide some niceties. As = examples: it gives a user a chance to administer/revoke those clients, = and it gives the AS an opportunity to do behavioral analysis with a = per-client rather than per-user granularity. It also allows you to track user-granted consent per client. There are = very limited options (really, just id_token_hint from OIDC) to indicate = when hitting the authorization endpoint that you have prior consent. In any case, the ability to work with public clients or the need to do = dynamic client registration is AS policy, not something clients = typically have the power to decide. -DW= --Apple-Mail=_8D3084AF-F09D-4CE0-9160-BC5FD0B1B2D2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Nov 7, 2018, at 9:08 AM, Simon Moffatt <simon.moffatt@forgerock.com> wrote:

It's an interesting topic.  I think there is a definitely a set of options and considerations for this.  Namely operational.  For example, hugely popular mobile apps (multi-million downloads across different OS's) using dynamic reg with per-instance private creds requires the AS to be able to store and index those client profiles easily.  Smaller scale custom built authorization servers are not necessarily going to be able to handle that - hence the popularity of assuming everything is generic and public coupled with PKCE.

Having unique client identifiers does provide some niceties. As examples: it gives a user a chance to administer/revoke those clients, and it gives the AS an opportunity to do behavioral analysis with a per-client rather than per-user granularity.

It also allows you to track user-granted consent per client. There are very limited options (really, just id_token_hint from OIDC) to indicate when hitting the authorization endpoint that you have prior consent.

In any case, the ability to work with public clients or the need to do dynamic client registration is AS policy, not something clients typically have the power to decide.

-DW
--Apple-Mail=_8D3084AF-F09D-4CE0-9160-BC5FD0B1B2D2-- From nobody Wed Nov 7 12:13:04 2018 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 A441E130DCA for ; Wed, 7 Nov 2018 12:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mN-Iqg-D1oiv for ; Wed, 7 Nov 2018 12:13:00 -0800 (PST) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 337EB127B92 for ; Wed, 7 Nov 2018 12:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1541621579; bh=ErZtekA236gdCqZXc47WBoR5N6MlozgO2/LtFwBoAPg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=O4fj2anEdw5doL3RdK0MFW6DzFRKWJjoKI35dH/Oj6yUnTQifBXvQUA/bb2MNn5H33qCtLIgky4bjQSz0cOla5gpTdG4DXKIa3O2+BHN9cNtj6ATRgBtebrJdITRo7PKiZlS9Yb4jRSyGhAepgDByJ6tvcN3+/DLcD6Xl6XCUnX3KVm5f5qZ08doKowAaBK/VcvRd3NDadQ96bgXa0vYqJxiIRvOIGU3Z1wisW4k0drE7T7IhWuUI5fK9Ijb7P+v11yAbGLPWEMBoxLtdkW4hi+jyYrsbrZWIOHYp6aXuH9Zc9gibOFIpngSbI6zsREMp06UmJNXzYNkYxgA54MzVg== X-YMail-OSG: 030Xnp0VM1kd6g3FpW_uw75Nslk31C15owrGR.DLM0CtoGxCYQZlPjV7c525W0n KzAkxTsb.rekB6aZUySuc7zf3am1ZVSxzIWBxRzbNvWhn8aouJVfxbkYpcU97CpWdSPYHz8kJQFZ UbSQWgtU_gcfRII2Kn_Zwf3aSwAs5s.jssW254xSm_t7MSZexKaU.BW_dMKwZksRZeHiIsuuW0ZJ U08hjva9W24tIhhYMgdPAarUFHu4HxDyCukzJy7fZHvoTB9r3EWPyNdktc5BA2vKS26.SesP3sGI LvczXAB6zDUf0PjYc.qT3OdPKTifVUa9kCnatF8u.F9ilMFqeuIXTjE_KSr.0m.n.W9y.BpnvmS. 6_FvtDiADAIVBXAlDkxPsYSsZq4chw0gk7.5M5h7.fCbYf83hsIRk44NxOjxT2.0Ldfe.N6aqV0F Y6.4aqPOpI1evFRed7P98U9LiIEoItKv7i70dKiXNBpoxW7Mfq2hhPAVGBiC9Wznz.Ya1ZtLw1oj xUeAoQCNqWpsgNSTaYl5cRZWVwg260hgb_ESko_iW8sZ2odqCQPLp51JP_cCoihFUGrN615FhVtG yW34dpNIo9vujcnpP_61kAcOnkceOkDr_11SsarKYhRaybNg5dRmlL.WOiG7fD1B5qRgWWPKCFG9 bgSc0hX4QYkFMwmwBmg335ad58giXSHenv_K8piAB.tr.5f9W.EyCmZMCUOuwym3vRd_QhXDRw99 fBLSUzlJPo1dnCJSDsx1Eb62xcoh2fZ6T6lRCCciXxz_TdHKzXhiUNMmOBYwq2kD9peDlw3Ffcc8 rbRjPVK8huOxCW6D8ecjFltFJIICJW5xbwBWd3XtfyAFWXb08aXW1SwW0ZX2.3pURiyQ_8PxU.II Se2Mp39wkYF6qrHowSFo64H7.vV43bRPPIqmYoBxEURHvvf6mYpkwy1ixtnaAmJjVhw.gb4u004P VF.kgahbEUgWHHt34AJTJRtv2Ekg1TXd20Jqgy6Kpg5AIgMw58oLJlCekBUhwMSBuwelYPlajC9O p4UizO2JMiUm7my0keul_UoAf_FXx.IdpUohePg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 7 Nov 2018 20:12:59 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9ea03decb8758aa4a6bea6df730ee5b5; Wed, 07 Nov 2018 20:12:57 +0000 (UTC) To: oauth@ietf.org References: <153998365568.6513.8592147530039175488@ietfa.amsl.com> Cc: Hannes Tschofenig , William Denniss , John Bradley , Mike Jones , hongchen@oath.com From: George Fletcher Organization: AOL LLC Message-ID: <31dd448d-a001-ab6f-bc3c-d7316296631c@aol.com> Date: Wed, 7 Nov 2018 15:12:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153998365568.6513.8592147530039175488@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------03888BF67200AC6A1CB5D95D" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-13.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, 07 Nov 2018 20:13:04 -0000 This is a multi-part message in MIME format. --------------03888BF67200AC6A1CB5D95D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Have we considered replacing the device_code logic with PKCE now that PKCE exists? At the time we started this spec I'm not sure PKCE was around, but now that it exists and is required (practically speaking) for mobile apps, should we look at using it instead of device_code to protect this flow? I'm assuming that most of these devices can not protect secrets and hence are effectively "public" clients. If this has already been considered and I missed it, I'm sorry for the noise :) Thanks, George On 10/19/18 5:14 PM, internet-drafts@ietf.org wrote: > 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 Device Flow for Browserless and Input Constrained Devices > Authors : William Denniss > John Bradley > Michael B. Jones > Hannes Tschofenig > Filename : draft-ietf-oauth-device-flow-13.txt > Pages : 21 > Date : 2018-10-19 > > Abstract: > This OAuth 2.0 authorization flow is designed for devices that either > lack a browser to perform a user-agent based OAuth flow, or are > input-constrained to the extent that requiring the user to input a > lot of text (like their credentials to authenticate with the > authorization server) is impractical. It enables OAuth clients on > such devices (like smart TVs, media consoles, digital picture frames, > and printers) to obtain user authorization to access protected > resources without using an on-device user-agent, provided that they > have an Internet connection. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-13 > > > 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/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------03888BF67200AC6A1CB5D95D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Have we considered replacing the device_code logic with PKCE now that PKCE exists? At the time we started this spec I'm not sure PKCE was around, but now that it exists and is required (practically speaking) for mobile apps, should we look at using it instead of device_code to protect this flow?

I'm assuming that most of these devices can not protect secrets and hence are effectively "public" clients.

If this has already been considered and I missed it, I'm sorry for the noise :)

Thanks,
George

On 10/19/18 5:14 PM, internet-drafts@ietf.org wrote:
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 Device Flow for Browserless and Input Constrained Devices
        Authors         : William Denniss
                          John Bradley
                          Michael B. Jones
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-device-flow-13.txt
	Pages           : 21
	Date            : 2018-10-19

Abstract:
   This OAuth 2.0 authorization flow is designed for devices that either
   lack a browser to perform a user-agent based OAuth flow, or are
   input-constrained to the extent that requiring the user to input a
   lot of text (like their credentials to authenticate with the
   authorization server) is impractical.  It enables OAuth clients on
   such devices (like smart TVs, media consoles, digital picture frames,
   and printers) to obtain user authorization to access protected
   resources without using an on-device user-agent, provided that they
   have an Internet connection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-13


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/

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

--------------03888BF67200AC6A1CB5D95D-- From nobody Wed Nov 7 13:08:34 2018 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 2F6FC12F1AB for ; Wed, 7 Nov 2018 13:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 O3t1saSNm3kc for ; Wed, 7 Nov 2018 13:08:30 -0800 (PST) Received: from sonic305-4.consmr.mail.bf2.yahoo.com (sonic305-4.consmr.mail.bf2.yahoo.com [74.6.133.43]) (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 26898124408 for ; Wed, 7 Nov 2018 13:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1541624909; bh=hm2bHjm03nkVcD5aTJ8aq8vMuSCUqsKvtX4zv3EyNWI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=EDS1eOVa+cuuGcH7oP4xTSkG8N3OVc7S0PATBIuwaKPp33ebOt5/768KDIegetDz0NcdulwfdKGTLmb7HJ+wJAm7rmY/TcPz9i4E7TznpN/NwyORoK556bvr93AvFCMaHNJY66gOPJrYVicV15cvh8b5IXjrpvV2z1YGTK+5zX3oT0MP98qXXLjdd8EKISrQgKxwvXSrQMW59Pra0qL17vQgoYnpLcrydJzoF2mnSPbdSCdQoj+tOuu/7KQBTt1GomtfkA4ZGqrNgfSkVzzvaR2wMMzQ88o6GNAbZ+zOmENa7FXAFKLQ+T+OLtSImseCbPPoCTmOg1qc1/8TNs3cLw== X-YMail-OSG: qp9TosIVM1ktbTX8OMx5X4DYxJEVnvV6o65Hy1_zMoTx0UWAtvRn9JzDZdAevpG xwRqBbeN1kTtE1gDtYVLD0bmw6QWy5EWk76M0fVI0dBNdLrH.yNOP4hHPFNzaGfZJVOJuweFPxRy OJomdEgfu01.9ToS3iWz08MunLwjyWY1zpqBLOpaN1PE7ZKSbI5UnMg5C11GvdPq6aZwmiQjbuSc EWf6HrF__YvHx9OLJpjDub7GeLqqlQgfMZn6SlKZnSR25DqwKtpkrg6dh9T3VoSAMPtOZKKHVuaD TW8Zj1oDSFWwYq6Ea64k_6.2xSd_2AAMrKHP6UP1pbWbnDQgPQRUcVOiCDHz.hEkyaB4fFvXTaC9 D.j9yhqjKLbgB.QEgvhOwUfy9Nu0R7i0VnKQ37Cou17xCljDDwTILtpt67tlpq9EyvQxnfcbx2AE SqJww.1iRiYUTYJWIMpaqaQkafy4jE.ldquZOtBTFGt_YzJkpfYcGudEnIXvscCIDCbhtymE6Eff IwPeS9QL.y2SYXMpaNdMlBo9_9IFoi28ABZyHQnN71okTvG4o0n5iw3yy_yejMaddw836XJAs9e_ E_I1PNSKZjkxZ8RKEWMwDGZPk4QO0YecBmV64sO2QLK4JIgm1XfXGp4yNwKge2BEazGB_C44Wgzh BEDomDQX5AZOaDeJVz6_kTSOFvOV.cPXgUaSpFxtVcJrMEZ.4wiuTgZ1lJmwdtLZO8rQS8PRO6yp 57fi12W2HK_NDCmW5uEEXEdUiwghDH6BsIL99sTQ0I8CSAh7IPhoD8srxoZKgEcvJsLSwF8n1Vjn kmjzsm3wcLocxF5w49YlPbmDt9lX_FECLDdJNgPHaxMcKiEvy4T3.kgwdSx1MYR8XQKSGICgRUHS rbHbQDg9KRyQWU7UU2VoK1.x5P9hfGvgikCw.hHihmmoZBdBAOPchQgMMo1zsdno6Cj6soMQoZQA LFlOBeqisETiMa8fRJYsEz8BVa_Gcj8zT3rtlHoxOJNETygODNi57EmdnyR4UDpOWy9V0363WWF8 UVUqScX0gVIP4dQeSDRbYFZE00E7uOTbN29tQ Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Wed, 7 Nov 2018 21:08:29 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e6b74e00208e42387023a5368450ea43; Wed, 07 Nov 2018 21:08:25 +0000 (UTC) To: Justin P Richer , "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: Date: Wed, 7 Nov 2018 16:08:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------19E146D5F57A536923697384" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 21:08:33 -0000 This is a multi-part message in MIME format. --------------19E146D5F57A536923697384 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Related to this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use... WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", error="invalid_token", rs_uri="https://api.example.com/resource", as_uri="https://as1.example.com,https://as2.example.com" Thanks, George On 11/6/18 12:19 AM, Justin P Richer wrote: > In the meeting tonight I brought up a response to the question of > whether to have full URL or plain issuer for the auth server in the RS > response’s header. My suggestion was that we have two different > parameters to the header to represent the AS: one of them being the > full URL (as_uri) and one of them being the issuer to be constructed > somehow (as_issuer). I ran into a similar problem on a system that I > built last year where all of our servers had discovery documents but > not all of them were easily constructed from an issuer style URL > (using OIDC patterns anyway). So we solved it by having two different > variables. If the full URL was set, we used that; if it wasn’t, we > tried the issuer; if neither was set we didn’t do any discovery. > > I’m sensitive to Torsten’s concerns about complexity, but I think this > is a simple and deterministic solution that sidesteps much of the > issue. No pun intended. > > — Justin > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------19E146D5F57A536923697384 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Related to this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", error="invalid_token", rs_uri="https://api.example.com/resource", as_uri="https://as1.example.com,https://as2.example.com"

Thanks,
George
On 11/6/18 12:19 AM, Justin P Richer wrote:
In the meeting tonight I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response’s header. My suggestion was that we have two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn’t, we tried the issuer; if neither was set we didn’t do any discovery.

I’m sensitive to Torsten’s concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun intended.

— Justin



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

--------------19E146D5F57A536923697384-- From nobody Wed Nov 7 13:28:15 2018 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 D63F1130D7A for ; Wed, 7 Nov 2018 13:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWG11Ebl_CSI for ; Wed, 7 Nov 2018 13:28:11 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 C4CA1124BE5 for ; Wed, 7 Nov 2018 13:28:11 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA7LJCjg080674; Wed, 7 Nov 2018 21:28:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=A9kaomAQflg4l19jqrfxWdwoqGZLQKeydxH6MXeaqXk=; b=W0XmvKeo+udmaSNciok6Rz0xgv8p4qHBDI9pSilk0DSM0K1V3/Goxpp2kiLapytTSk92 c1XNQOFRBl2VhCV180ka5R0iljTREewP7JGXLYlmoxLBDvGG/1+0Op7RCMCUSgyukhWm 9M65YO+WiTd0+6zxfoXB+OvgZr2orjQ1Ek15pSTBrEfyrZpea9h3yCDxObc9zyI2Bx48 Y4kLr42+J0d20QQYX0CWlIzr9wkOfV+o6aErNm6/bkYsscQb3aonQ4Yd882ZEMfQKMFc QO/LU602KE5AjajEIiaIhkX7/rARkibaHNaCM3/wyGYbJw5kSB6lvRHjTcjQgs22TFL3 IQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2nh3mpx2x3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Nov 2018 21:28:06 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA7LS5f0016499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Nov 2018 21:28:05 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA7LS44S011736; Wed, 7 Nov 2018 21:28:05 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Nov 2018 13:28:04 -0800 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9294C060-EF83-4E30-AABB-B4065C6DC37F" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 7 Nov 2018 13:28:03 -0800 In-Reply-To: Cc: Justin P Richer , "oauth@ietf.org" To: George Fletcher References: X-Mailer: Apple Mail (2.3445.101.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9070 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811070190 Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 21:28:14 -0000 --Apple-Mail=_9294C060-EF83-4E30-AABB-B4065C6DC37F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m seeing broader need for discovery of OAuth infrastructure = for APIs in general now that APIs are being deployed by many parties: * based on a standard (e.g. SCIM, IMAP, SMTP) * Implemented in open source and deployed by many (e.g. K8S and its = various components). * Services like streaming (Kakfa)=20 * Serverless/microservices APIs I agree, that having some process where the RS can indicate to a client = where to go do discovery would be helpful. The issue is somewhat = complex and we have talked about some of this before. For example, an RS = may have multiple AS=E2=80=99s it accepts tokens from. Does the RS = indicate many or specific discovery endpoint that may or may not involve = registration (in order to determine the appropriate AS)? How is the = metadata secured? How do we ensure we haven=E2=80=99t opened up an = automated attack point (e.g. a MITM=E2=80=99d RS gives a client false = discovery information). Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Nov 7, 2018, at 1:08 PM, George Fletcher = wrote: >=20 > Related to this discussion of AS discovery... what is the value of = using the Link response header over just returning the variables in the = WWW-Authenticate header? Could we not use... >=20 > WWW-Authenticate: OAuth realm=3D"example_realm", = scope=3D"example_scope", error=3D"invalid_token", = rs_uri=3D"https://api.example.com/resource" = , = as_uri=3D"https://as1.example.com,https://as2.example.com" = >=20 > Thanks, > George >=20 > On 11/6/18 12:19 AM, Justin P Richer wrote: >> In the meeting tonight I brought up a response to the question of = whether to have full URL or plain issuer for the auth server in the RS = response=E2=80=99s header. My suggestion was that we have two different = parameters to the header to represent the AS: one of them being the full = URL (as_uri) and one of them being the issuer to be constructed somehow = (as_issuer). I ran into a similar problem on a system that I built last = year where all of our servers had discovery documents but not all of = them were easily constructed from an issuer style URL (using OIDC = patterns anyway). So we solved it by having two different variables. If = the full URL was set, we used that; if it wasn=E2=80=99t, we tried the = issuer; if neither was set we didn=E2=80=99t do any discovery. >>=20 >> I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, = but I think this is a simple and deterministic solution that sidesteps = much of the issue. No pun intended. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9294C060-EF83-4E30-AABB-B4065C6DC37F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m seeing broader need for discovery of OAuth infrastructure for APIs = in general now that APIs are being deployed by many parties:
* based on a standard (e.g. SCIM, IMAP, SMTP)
* Implemented in open source and deployed by many (e.g. K8S = and its various components).
* Services like = streaming (Kakfa) 
* Serverless/microservices = APIs

I agree, that having some process where the RS can indicate = to a client where to go do discovery would be helpful.  The issue = is somewhat complex and we have talked about some of this before. For = example, an RS may have multiple AS=E2=80=99s it accepts tokens from. = Does the RS indicate many or specific discovery endpoint that may or may = not involve registration (in order to determine the appropriate AS)? =  How is the metadata secured?  How do we ensure we haven=E2=80=99= t opened up an automated attack point (e.g. a MITM=E2=80=99d RS gives a = client false discovery information).

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Nov 7, 2018, at 1:08 PM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20
Related to = this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"example_scope", error=3D"invalid_token", rs_uri=3D"https://api.example.com/resourc= e", as_uri=3D"https://as1.examp= le.com,https://as2.example.com"

Thanks,
George
On 11/6/18 12:19 AM, Justin P Richer wrote:
In the meeting tonight I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response=E2=80=99s header. My suggestion was that we have = two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn=E2=80=99t, we tried the issuer; = if neither was set we didn=E2=80=99t do any discovery.

I=E2=80=99m sensitive to Torsten=E2=80=99s = concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun = intended.

=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

= --Apple-Mail=_9294C060-EF83-4E30-AABB-B4065C6DC37F-- From nobody Thu Nov 8 02:13:55 2018 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 36B5E130DEA for ; Thu, 8 Nov 2018 02:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTOP-8OIh9av for ; Thu, 8 Nov 2018 02:13:51 -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 330B912D4F2 for ; Thu, 8 Nov 2018 02:13:48 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id n18so13742345lfh.6 for ; Thu, 08 Nov 2018 02:13:48 -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=mg1XP+sl4a9IXg5kb2wTuzShdwYat4itIhTt2w9o4+o=; b=Qq9q7bPfiqUxK02ipBXarFYURgIDwaBl4AYd3j8ZsHd28rHzcgW6mDgdnYhG+9ZRRH 9jdm/d53ypS02StAPDShirINz4eJX7wpRywYgPyWKSypNsz7YWfuQnubQRHMC5XHLHvk RZo8JWOw0v0jh2Pn84FhyRj5FSX/N8TmKsXdZudL7uCeGFBliIWWrAY95lxsamLGKqOW 4+ISQVnfya0xqRXkyoyOFUKb3lyx8/AEOZRya4BMPZoFThhHlkkr3ysW1nM6ozBHMYRV DfuTjBRm9SLZkt6Ze3rwjFJgtPwqV1bNRyC4hHaZYHQE+QIKG/v1ADxbg1uCTlwjogF8 WLrg== 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=mg1XP+sl4a9IXg5kb2wTuzShdwYat4itIhTt2w9o4+o=; b=mKiW8erczE79ZTHTkSE9hbbqI/u9dlAudsETGaWUBLvPAdcj9PmS3I8aR3LlNvBcZ1 8MPYcqWM/oKrbLUPwuV6WVjSLHT3bLOldPbUwcs2SS8L3DTeKY4pT7/4Y/eSg1d45Em7 4jHabDBjZTUPYpzHReAlD5n2FsjAdw2nsg4WYY+X4wgzk04GkmR7PSy1m22/q8Xbl5bX Qnu/YtR8Esw4cyKnAOJjrMbwnuLFppa4OAYYjomJQ2O5A/QZdHVFrz4JSbQLJWKlLqrQ k/9o/QiSYjOU1/pzMXJuEYmNVZFhyn6S2YgFegLDLqNQA09HBo7Y0DrzAZP4eeINqXuM /FNw== X-Gm-Message-State: AGRZ1gI5v0de0IhwcQNa1sUU6l016gnDXj5oqZa2+nEXYM0N2E6Oz012 yd2ffPBqJ3+o953iXqBJ/UmQ/OE6w/5NdsLTUjU= X-Google-Smtp-Source: AJdET5f0nJtbwkW49N5jENGfXtTddRDALJjgZFYllte/G+Uk98J65ATJdeeWE2BV0tb+diwPOhdATGc0hx9GHKPJERQ= X-Received: by 2002:a19:d857:: with SMTP id p84mr2282370lfg.44.1541672026108; Thu, 08 Nov 2018 02:13:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 8 Nov 2018 17:13:35 +0700 Message-ID: To: Phil Hunt Cc: gffletch=40aol.com@dmarc.ietf.org, oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000079fa5b057a247d84" Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 10:13:53 -0000 --00000000000079fa5b057a247d84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Phil, would you clarify what you are suggesting? I'm unclear if you are disagreeing with George or not. On Thu, Nov 8, 2018 at 4:28 AM Phil Hunt wrote: > I=E2=80=99m seeing broader need for discovery of OAuth infrastructure for= APIs in > general now that APIs are being deployed by many parties: > * based on a standard (e.g. SCIM, IMAP, SMTP) > * Implemented in open source and deployed by many (e.g. K8S and its > various components). > * Services like streaming (Kakfa) > * Serverless/microservices APIs > > I agree, that having some process where the RS can indicate to a client > where to go do discovery would be helpful. The issue is somewhat complex > and we have talked about some of this before. For example, an RS may have > multiple AS=E2=80=99s it accepts tokens from. Does the RS indicate many o= r specific > discovery endpoint that may or may not involve registration (in order to > determine the appropriate AS)? How is the metadata secured? How do we > ensure we haven=E2=80=99t opened up an automated attack point (e.g. a MIT= M=E2=80=99d RS > gives a client false discovery information). > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Nov 7, 2018, at 1:08 PM, George Fletcher < > gffletch=3D40aol.com@dmarc.ietf.org> wrote: > > Related to this discussion of AS discovery... what is the value of using > the Link response header over just returning the variables in the > WWW-Authenticate header? Could we not use... > > WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"example_scope", > error=3D"invalid_token", rs_uri=3D"https://api.example.com/resource" > , as_uri=3D > "https://as1.example.com,https://as2.example.com" > > > Thanks, > George > > On 11/6/18 12:19 AM, Justin P Richer wrote: > > In the meeting tonight I brought up a response to the question of whether > to have full URL or plain issuer for the auth server in the RS response= =E2=80=99s > header. My suggestion was that we have two different parameters to the > header to represent the AS: one of them being the full URL (as_uri) and o= ne > of them being the issuer to be constructed somehow (as_issuer). I ran int= o > a similar problem on a system that I built last year where all of our > servers had discovery documents but not all of them were easily construct= ed > from an issuer style URL (using OIDC patterns anyway). So we solved it by > having two different variables. If the full URL was set, we used that; if > it wasn=E2=80=99t, we tried the issuer; if neither was set we didn=E2=80= =99t do any > discovery. > > I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, but= I think this is > a simple and deterministic solution that sidesteps much of the issue. No > pun intended. > > =E2=80=94 Justin > > > > _______________________________________________ > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000079fa5b057a247d84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Phil, would you clarify what you are suggesting? I'm u= nclear if you are disagreeing with George or not.

On Thu, Nov 8, 2018 at 4:28 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I=E2=80=99m seeing broader need for discovery = of OAuth infrastructure for APIs in general now that APIs are being deploye= d by many parties:
* based on a standard (e.g. SCIM, IMAP, SMTP)
<= div>* Implemented in open source and deployed by many (e.g. K8S and its var= ious components).
* Services like streaming (Kakfa)=C2=A0
* Serverless/microservices APIs

I agree, t= hat having some process where the RS can indicate to a client where to go d= o discovery would be helpful.=C2=A0 The issue is somewhat complex and we ha= ve talked about some of this before. For example, an RS may have multiple A= S=E2=80=99s it accepts tokens from. Does the RS indicate many or specific d= iscovery endpoint that may or may not involve registration (in order to det= ermine the appropriate AS)?=C2=A0 How is the metadata secured?=C2=A0 How do= we ensure we haven=E2=80=99t opened up an automated attack point (e.g. a M= ITM=E2=80=99d RS gives a client false discovery information).

Phil

Oracle Corporation, Clou= d Security and Identity Architect
@independentid
phil.hunt@oracle.com

On Nov 7, 2018, at 1:08 PM, George = Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20 =20
Related to this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"example_scope", error=3D"invalid_token", rs_uri=3D"https://api.e= xample.com/resource", as_uri=3D"= ;https://as1.example.com,https://as2.example.com"

Thanks,
George
On 11/6/18 12:19 AM= , Justin P Richer wrote:
=20 In the meeting tonight I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response=E2=80=99s header. My suggestion was that we have two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn=E2=80=99t, we tried the issuer; if neither was set we didn=E2=80=99t do any discovery.

I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun intended.

=E2=80=94 Justin



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/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
--00000000000079fa5b057a247d84-- From nobody Thu Nov 8 02:16:31 2018 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 943CD130FD0 for ; Thu, 8 Nov 2018 02:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sSb2cASEgnJK for ; Thu, 8 Nov 2018 02:16:17 -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 41021130F78 for ; Thu, 8 Nov 2018 02:16:14 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id g26-v6so17458326lja.10 for ; Thu, 08 Nov 2018 02:16:14 -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=Jiu57+wanRHhDKx9exo4bGO5ftiz8tK5kpxT9olGXGk=; b=SIVoc0gBdb6K0dcwYuXMzF/LPzP8wkvPhQarp9pW6Rw/pOtYwEvMyns26cj9aC8WX9 QuJoSRaX8tBy3MT/f6TbtwYN7AlmSqzkA7YRfPBlorZ8bESxr5DI8z7cICmFPwy3g6Vl plWU6fNKvlIG92mCZUnBfTYJ/Y0czeYmMqyuDJciH49anSNlKTy35X0wCwdJhzALx/KZ j9XieZ1RXz4+EAWcbV88OUwpu0lqBrXvZKDntcu/6vk5jD9H7W+T79e0JGvf7ERncY2a B8Im/ltxIDn1ofE1tDsuDRhz97rxOChgx/VUHLD0RB8o3MAZMegLtSO4x0y5tM31eiYj 1z2g== 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=Jiu57+wanRHhDKx9exo4bGO5ftiz8tK5kpxT9olGXGk=; b=GYVFFDri7GNrtfaKToDF9aHaqMtBX7N7Fg0GnYXaWYyYJ6EM+bvU8skiiQ18s/xsSw bS48DyEvpckJoTCaH87pB+2O//K53axGC1fAYnRNj17Ummo8+V6/5eUUxshZgo8Z8iJ6 5hFnkVd0/rjfNOge3QVX3dJtW4s23w/ukvr4+rJ3rP6tFkad2A16crwI8phNXBqQfoZ2 8sof8FrOVq0eZSbwuwFduzH4n8G0wrEGNW7i8XMVZiWTny/4sl49TtRmESqsXEfd6VLw VIsCZo9qOqJKJDger346TOep3bwx0k9grdXJg20nAhJ47DS0pSxQgWo27OsB+VO4aPUY 1C9w== X-Gm-Message-State: AGRZ1gKm6YnkrDSHRYWFrOT31OhiMgLAxh4wTMhFrNfgE1cJoONJmGBD Idz1UGY0k/cslcQ+zKZoI+FmeVUt9/9VmAz+ShM= X-Google-Smtp-Source: AJdET5c6p7wTVtOIewxrIPXnfJyQ61wao+Mk0CS5bl0voihPZ3IEZE9Gxes7SW2JxPi82v0+WWwKhrZBACA0zxwJYc8= X-Received: by 2002:a2e:9ec5:: with SMTP id h5-v6mr2412327ljk.40.1541672172117; Thu, 08 Nov 2018 02:16:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 8 Nov 2018 17:16:00 +0700 Message-ID: To: gffletch=40aol.com@dmarc.ietf.org Cc: Justin Richer , oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002de60d057a248688" Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 10:16:27 -0000 --0000000000002de60d057a248688 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable George: in the WG meeting we discussed this topic of where to put the discovery information. No one at the meeting advocated for using Link response (Nat was the one who was advocating for this). Many others preferred using the www-authenticate header similar to how you propose. On Thu, Nov 8, 2018 at 4:08 AM George Fletcher wrote: > Related to this discussion of AS discovery... what is the value of using > the Link response header over just returning the variables in the > WWW-Authenticate header? Could we not use... > > WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"example_scope", > error=3D"invalid_token", rs_uri=3D"https://api.example.com/resource" > , as_uri=3D > "https://as1.example.com,https://as2.example.com" > > > Thanks, > George > > On 11/6/18 12:19 AM, Justin P Richer wrote: > > In the meeting tonight I brought up a response to the question of whether > to have full URL or plain issuer for the auth server in the RS response= =E2=80=99s > header. My suggestion was that we have two different parameters to the > header to represent the AS: one of them being the full URL (as_uri) and o= ne > of them being the issuer to be constructed somehow (as_issuer). I ran int= o > a similar problem on a system that I built last year where all of our > servers had discovery documents but not all of them were easily construct= ed > from an issuer style URL (using OIDC patterns anyway). So we solved it by > having two different variables. If the full URL was set, we used that; if > it wasn=E2=80=99t, we tried the issuer; if neither was set we didn=E2=80= =99t do any > discovery. > > I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, but= I think this is > a simple and deterministic solution that sidesteps much of the issue. No > pun intended. > > =E2=80=94 Justin > > > > _______________________________________________ > 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 > --0000000000002de60d057a248688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
George: in the WG meeting we discussed this topic of where= to put the discovery information. No one at the meeting advocated for usin= g Link response (Nat was the one who was advocating for this). Many others = preferred using the www-authenticate header similar to how you propose.
On Thu, Nov 8, 2018 at 4:= 08 AM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
Related to this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"example_scope", error=3D"invalid_token", rs_uri=3D"https://api.= example.com/resource", as_uri=3D&qu= ot;https://as1.example.com,https://as2.example.com"

Thanks,
George
On 11/6/18 12:19 A= M, Justin P Richer wrote:
=20 In the meeting tonight I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response=E2=80=99s header. My suggestion was that we have two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn=E2=80=99t, we tried the issuer; if neither was set we didn=E2=80=99t do any discovery.

I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun intended.

=E2=80=94 Justin



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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002de60d057a248688-- From nobody Thu Nov 8 02:17:52 2018 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 0F86F128D68 for ; Thu, 8 Nov 2018 02:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2dsFe3_hLjkw for ; Thu, 8 Nov 2018 02:17:48 -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 4310212870E for ; Thu, 8 Nov 2018 02:17:48 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id s15-v6so17471995lji.3 for ; Thu, 08 Nov 2018 02:17:48 -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=jqUGJc+mWVk5trvME5pr9rp8kzoHzvpdNV4ccGP5ySA=; b=FKPwfw0B5TDVQr1ib482AZLaKDYy2zIpSlOaE4HOblphCmSlqlk2IXH/yoKz+77Nvv HyaogKzbyTwtpOg/8sbgJaPq+iTPnivnQyRKUn5CyMA6jlSxegiKqYq+NhHH4nlFVM25 zv0Hj7J0UoO1FFm4zd6df0sMx3kMPzRzPfl5yX7SJpPb/If2hnkOVKnRy1QhP6lWhryV kUyWiLakWt8nIHhhIVduD0NmeKFsMip6LGqjEgB1kLEWtRbqjgVQjvIMKvncshGC+YJt 13OROgO8KQ+dVx8p+sX0FWdYW3bUmxPN8LU4ArJ/iEwMz81YCYvV/eX52JbutSxka6mr 4lLQ== 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=jqUGJc+mWVk5trvME5pr9rp8kzoHzvpdNV4ccGP5ySA=; b=WlY/ZRh1RoC/HnBZq8x913a6mzAhYHGNqEsvUfNP+994VlWFuNZrtDPHHDC/zfbyZM O9ikE1MmA74kGm1x5AVU2qGdO2HxawgolVaO7P7azaPJeXPIQyjvXOa0D4YwXR2BSH3H ueMUcrEvE2R7Cr9D7C71ZQVtkKNbWf4XIVaIc0K/uWsQq/jHBAgNW53UnvC3/6ShC9PA 6v/03QQBQul4y9gMGJd1QmAvx01pTEDPY/PAvCNHqyXORi0NKZFn4X4KOqunrxuu8xPt lNeX17APZAidzLGM1M45IASuETOv7bKHbdPEFY1VjETKAg77FA6ZAfrfI0mXK+R0CYa3 5Xyw== X-Gm-Message-State: AGRZ1gJi9Wyw7mpmcJcEAst9L6aamUf+T9lBhc1do9JywyA49FqVv8Ov MqE/tkSz79xWpXtSj0MjojImeY1c9FzN0oapE0TrKZlU X-Google-Smtp-Source: AJdET5e13S33b8UtCWi1/fPUi2I8fO/RlHBgAfirbfea9q7LO/4qJnRAK/twhO8Pjv/ojvG9s/WBJR9oWhZ7Y4CQz4E= X-Received: by 2002:a2e:1510:: with SMTP id s16-v6mr2427552ljd.4.1541672266282; Thu, 08 Nov 2018 02:17:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 8 Nov 2018 17:17:35 +0700 Message-ID: To: David Waite Cc: Justin Richer , oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000cabafb057a248b43" Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 10:17:51 -0000 --000000000000cabafb057a248b43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is a requirement in Distributed OAuth for the client to locate one or more AS metadata files for a given resource. On Tue, Nov 6, 2018 at 12:35 PM David Waite wrote: > Is there a need for a client to understand the identity of an > authorization server? > > This would seem to mean that the token or authorization endpoint would > need to be that identity, rather than the issuer (since now the metadata > might not be from an authoritative location) > > -DW > > On Nov 5, 2018, at 10:19 PM, Justin P Richer wrote: > > In the meeting tonight I brought up a response to the question of whether > to have full URL or plain issuer for the auth server in the RS response= =E2=80=99s > header. My suggestion was that we have two different parameters to the > header to represent the AS: one of them being the full URL (as_uri) and o= ne > of them being the issuer to be constructed somehow (as_issuer). I ran int= o > a similar problem on a system that I built last year where all of our > servers had discovery documents but not all of them were easily construct= ed > from an issuer style URL (using OIDC patterns anyway). So we solved it by > having two different variables. If the full URL was set, we used that; if > it wasn=E2=80=99t, we tried the issuer; if neither was set we didn=E2=80= =99t do any > discovery. > > I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, but= I think this is > a simple and deterministic solution that sidesteps much of the issue. No > pun intended. > > =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 > --000000000000cabafb057a248b43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a requirement in Distributed OAuth for the client= to locate one or more AS metadata files for a given resource.=C2=A0
<= br>
On Tue, Nov 6, 2018 at 12:35= PM David Waite <david@a= lkaline-solutions.com> wrote:
Is = there a need for a client to understand the identity of an authorization se= rver?

This would seem to mean that the token or au= thorization endpoint would need to be that identity, rather than the issuer= (since now the metadata might not be from an authoritative location)
=

-DW

On Nov 5, 2018, at 10:19 PM, Justin P Richer <jricher@mit.edu> wrote:
In the meeting tonight I brought up a response to the question of whether t= o have full URL or plain issuer for the auth server in the RS response=E2= =80=99s header. My suggestion was that we have two different parameters to = the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constru= cted somehow (as_issuer). I ran into a similar problem on a system that I b= uilt last year where all of our servers had discovery documents but not all= of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by = having two different variables. If the full URL was set, we used that; if i= t wasn=E2=80=99t, we tried the issuer; if neither was set we didn=E2=80=99t= do any discovery.

I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, = but I think this is a simple and deterministic solution that sidesteps much= of the issue. No pun intended.

=E2=80=94 Justin

_______________________________________________
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
--000000000000cabafb057a248b43-- From nobody Thu Nov 8 02:42:50 2018 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 40DE3130FCE for ; Thu, 8 Nov 2018 02:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0N0gVf3lVokR for ; Thu, 8 Nov 2018 02:42:42 -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 8BBB1128CB7 for ; Thu, 8 Nov 2018 02:42:42 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id f3-v6so17532032ljk.9 for ; Thu, 08 Nov 2018 02:42:42 -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:cc; bh=NdyoiIDnjx+xRHg/jvEUbYxprH5SUnqixQAY6P68oTw=; b=Cl76luAWzF4uUrqOLqT08aUoEtZ+VGo2vx/33IrgjxDI/zQS7O2DMxjUzVaWEDV+fg VTdAcLqwnJHGWcVnQS3pzV9OnfPEW9i12PajpqAa2+eTNfjsqWR0RNRozDFF/R2qxE95 Ss9JuOvNmkeI+ETiktvt8sJqR74Y3iXqWePdIfGzhPctgiBkARuol4bIbd9dXTdtPEJb mAQRGqq0Aqzj6MvTnT3NFd2hvjRt719lzKmMSckX7bCUnJPp3ogrEj2iRf6PPg9GL+vl lugaRXHQW6mVvHy6kzrWu1Q98rtJhHpWGFS0e+8kuv2PELenSJ3oZZtCtSUTUGJGFAUi LobQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NdyoiIDnjx+xRHg/jvEUbYxprH5SUnqixQAY6P68oTw=; b=gkcft9T6HXMHfl+62HBOJ81h+q2vJwLDwOF3V49WczoZ0SYb2Qog6bk5zl3UlpQohM 5DDlVVQtiGeiDeuwRYe2h9cghvZb+5K3HQvsOUn8W6rziDovqa8LrFnqT0M+HubWKvqC 9+QJ+nRlLGiUVYYvJop96gzKw04fbS9/PoG5IJE7M2HyBjch/gNIXUJ5BDVCJ7d/0lkz q8HHi7biomgpHUGjvazDcqhYVyIhAjxfPBKWC5zWmlObtDZJIH9FGuYnHPfqSEFlKQjA YgvYKVMNLphJVBD0aRpqt1A6WDfeCnusd3ch2kfR9WtnVlAiyF4qEzpJ8Q8+dyLL5s3n uaYQ== X-Gm-Message-State: AGRZ1gJr8ruacRsRCtYVqZqgGUdaWKYezUhlPSlhzf2ZvpfAX6MjPt1H o/CiuBq5PDXU7EHtDPk0CpDV0hPr836sq7BKAxc= X-Google-Smtp-Source: AJdET5etEXeaFKbf748sC+m3RZU7BWoOUei6bph9J1uPMaRi1QeV0U5xQf3Bn0/RXOGgDjxb4GTuQMjc+P0DOvqCtUE= X-Received: by 2002:a2e:9059:: with SMTP id n25-v6mr2535912ljg.155.1541673760585; Thu, 08 Nov 2018 02:42:40 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Thu, 8 Nov 2018 17:42:28 +0700 Message-ID: To: omerlh@gmail.com Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000dbffc3057a24e4b4" Archived-At: Subject: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant 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, 08 Nov 2018 10:42:48 -0000 --000000000000dbffc3057a24e4b4 Content-Type: text/plain; charset="UTF-8" Omar As promised, I have reviewed the ID[1] you posted. I'm confused in the Motivation by the references to authentication, as OAuth is about authorization. Perhaps you can post to the list the use case you are trying to solve for? I can infer aspects, but don't fully understand it. >From what I can understand though, there is software running in a trusted device that would like to get an access token, and an OTP is part of how the device is authenticating to the AS. This seems like a 2 legged OAuth flow as there is no user involved directly, and it seems you have a means for the client to authenticate to the AS using an OTP. Am I guessing correctly? /Dick [1] https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 --000000000000dbffc3057a24e4b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Omar

As promised, I have reviewed the ID[1] you posted. I'm con= fused in the Motivation by the references to authentication, as OAuth is ab= out authorization.

Perhaps= you can post to the list the use case you are trying to solve for? I can i= nfer aspects, but don't fully understand it.=C2=A0

From what I can understand though, there is so= ftware running in a trusted device that would like to get an access token, = and an OTP is part of how the device is authenticating to the AS. This seem= s like a 2 legged OAuth flow as there is no user involved directly, and it = seems you have a means for the client to authenticate to the AS using an OT= P. Am I guessing correctly?

--000000000000dbffc3057a24e4b4-- From nobody Thu Nov 8 03:19:20 2018 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 4E5F6130E08 for ; Thu, 8 Nov 2018 03:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 yS554QQqKeq3 for ; Thu, 8 Nov 2018 03:19:16 -0800 (PST) Received: from sonic304-21.consmr.mail.ne1.yahoo.com (sonic304-21.consmr.mail.ne1.yahoo.com [66.163.191.147]) (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 387FA128CF3 for ; Thu, 8 Nov 2018 03:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1541675955; bh=/KOIWB8m7BUfEoF4KJiBFr/DuK+4FJ24tNn2EtPDCxY=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=eNWnOn2s7rUtGDLHv8R+U5SuSjtnGsQ1a97ghUsDUoDWANALfIfCFr3J4HQp5TaR/TAqZ2VKQspBVSxLDNxMEilA4BnrRWSgF5xEW9z2zj3/jKZaFr9+G8ZBZHVVbeT1YT1XvYzbpIFjysDn4K9WsDl/FBHE7IKUF0/NtAHHOH+cJ8eJbMnIZ4M2gBtjDmNjKCsFhkQ4c8IWSvMVEhUkI66LNN1yhAAO/1iP+boBmu6SypDyriMe/Q+0bU8PSSLIcCQgcZyp2/o36fiVRTraKLLEMuWEJ/x6jwetRVXIEbncDK2/A2qm+v3mj9KS2BzV4ge1zi9kB9NVk5liL/gUdQ== X-YMail-OSG: fEk1_joVM1lD0KZ1i7lUqDEvPddh71K7Y9nXphQyrWT2QuhAtVyqbj_Y49NFWrs vfDmId99qRgUqRMBh5OTQAA0lhBhtbsqKjdGXbweukortfMNGn3k7Y1RAFsBU3pd4QFl1AApoujR mcUystasevtZnTvmqXFnvSvZ_IAsOZvAo0GlUShKR72.fdYZqGFgwrMk6WhVU3krDUwXyaPevLhn 4fuClz9539CBy_mxKodnh8d6cOkeqf_l_.LO0.ZTD7kVLW2qPI7uc60vZ1HB3_sWQv9rnHG.x9aB WL_LJeSDwtimGx7M5GS7Eh.JGEY5YN0SFCYIjrhQA.Kyxj0hL2z1oPC8GYZ1CcPKw5WmF87C9SAq e74w.HJYo8Ys5QH_YWy0zRyiTYBOS37cxgeOA7nPN4VVepVGrCqJ.j1oZwNqd78zD2v_s4DkNs6H 7PwW4xfBPqlmN8bcFCwYnguko3RPefbW4JTyZC8lv4yIzWyEG6YocJ2VpaJZqIUoCiPzy9K6r_h7 DGosnLVrLypOMehiKdLZ5.gCa2a_J4k1mrHhuwgoEWivK3m0QiVr_0fJY2BUJcsFQnMEaci.Wm9. Rlv3cyY7QpE0EsxL6f.M5cnEmQO3dtJlWLqV5mrysuKnks9SVc1VBRaj7oJMCc_rWDO1eXL4uDsQ PK8L1JWyQyKn0rppHxVCrW1ZOnb8K7z.8kUdcKrJAKAInt9Fj8F27VtF_GEvFkzozoODkr6yhBnK Su6R3oVelVIQFfnozsF5WrEYU6ufgmCkvuPAKOyyfcBiGajMvx.JELxLzh6kc6rxJuDJYxf6CALd TsLc.u3GszARQCN9HHnngW9sRZFthseXGoSa_EoJ1SkIhr.m_EeGGEFs2ECknk2L22VtqMy2.7SC 2DiXljnagZNWb7gUR7Rcvd1fpXm0Cl4qYi.0STh.NeZyaZkiwLLM2pUWFYZtxiasSrGTDQxxz7O0 CYgO5D06KrNvBFpy1kRGrRHG5dxGt8W9_JRMCJbxsWMh62YorB9cFnUQbn_37ObwLEs2MIe1pBwA - Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Thu, 8 Nov 2018 11:19:15 +0000 Date: Thu, 8 Nov 2018 11:19:14 +0000 (UTC) From: Tomek Stojecki To: oauth , Hannes Tschofenig Message-ID: <710899611.302780.1541675954453@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.12721 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 08 Nov 2018 11:19:18 -0000 Thanks for putting this together Aaron.=C2=A0 Having read through the document, I am not as convinced that there is enoug= h of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs. In section 7.8. the document outlines the Implicit flow disadvantages as fo= llowing: "- OAuth 2.0 provides no mechanism for a client to verify that an access to= ken was issued to it, which could lead to misuse and possible impersonation= attacks if a malicious party hands off an access token it retrieved throug= h some other means to the client." If you use Code + PKCE with no client secret (public client) as it is being= advocated, you can't verify the client either. PKCE is not for authenticat= ing the client, it is there to provide a mechanism to verify inter-app comm= unication, which occurs between a browser and a native app. There is no int= er-app communication in implicit (everything stays in the browser), so no n= eed for PKCE. "-=C2=A0Supporting the implicit flow requires additional code, more upkeep = and understanding of the related security considerations, while limiting th= e authorization server to just the authorization code flow simplifies the i= mplementation." This is subjective and can be easily argued the other way. I think one of t= he main selling points behind implicit was its simplicity. It is hard to ar= gue (putting libraries aside) that making one redirect (implicit) requires = more code, work, etc.. than making a redirect and at least two additional c= alls in order to get AT (plus CORS on AS side). Further, in the beginning paragraph of 7.8, you mention that implicit gets = the AT through the front-channel. Exchanging code for AT will also happen i= n the browser , where instead of a url you will have an xhr (and again, now= we have cors) Finally, how is the AT going to be refreshed? Are we allowing for long live= d RT in the browser? I see that the document mentions CSP in 7.7, but doesn= 't the same apply to securing AT with Implicit? Regrads, Tomek Stojecki On Tuesday, November 6, 2018, 10:55:40 AM GMT+1, Hannes Tschofenig wrote:=20 Hi all, Today we were not able to talk about draft-parecki-oauth-browser-based-apps= -00, which describes=C2=A0 "OAuth 2.0 for Browser-Based Apps". Aaron put a few slides together, which can be found here: https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-o= auth-2-for-browser-based-apps-00.pdf Your review of this new draft is highly appreciated. 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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Nov 8 04:56:54 2018 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 8ABE9129619; Thu, 8 Nov 2018 04:56:52 -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: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154168181252.31289.10256085593572115838@ietfa.amsl.com> Date: Thu, 08 Nov 2018 04:56:52 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 12:56:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JSON Web Token Best Current Practices Authors : Yaron Sheffer Dick Hardt Michael B. Jones Filename : draft-ietf-oauth-jwt-bcp-04.txt Pages : 15 Date : 2018-11-08 Abstract: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 8 07:11:40 2018 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 EAB6D128D68 for ; Thu, 8 Nov 2018 07:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ua4Ai9NQYpih for ; Thu, 8 Nov 2018 07:11:37 -0800 (PST) Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (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 00DFB128CF3 for ; Thu, 8 Nov 2018 07:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1541689895; bh=c56EnW3YqY8t90DIiWPwI+LQ1bI807l8ZYxEMngxY4E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=UA/sqr8aXYm1gfVa13hh7QEM8NjpjF0QP7Fjg+B5XP9zoJ5upzFd417EpaURC6iYqmsNAuczOa/c4rk1I5zvEhlgPoZHVjFOfBqvHSMmD74mdxcQqYU//zCHGZJqLbq1F0s/qXldOJr27ud/vqzUaehDoBCCXeQGPxfucw7bhceXiHd3F2a4M53Ihqd+GCkp5aATmeCnwQ8DfJgRz5Bkl3WCGDFXT7HZL6kRy+FSZb/RChzlT5Dm7YnozhuahnTpCIZJyvcYOEU+X87aHeLGmNGBK/EEcIk1HUINiLCEFOo2GblImjDaBIQDHxBHpEXvJUOm8S2CLjQNkGDsMdj9/w== X-YMail-OSG: 8o3LJ08VM1loBs4WGNa4zPxbs3tSyUaViNwjMqmZ4oYf.i3SwGa4_zw3xoN8cN8 wP.qJtlah4qigfpYyPdxO1KjE1OmoIN2.HQBBjd82gQhrAQ9Lqm1AUgqwDbfpCcdwXYU6tCQ.0IR f.oEnz5pdpx4EcgL1KjqwKZM3PaHKwckVxWFWGuSRt2GBsn3.r01FSQFA8bNyWk2UdPkmBQP2xbL MhEQqgGzpaA.gshNhoDBtoynh5mNXyV4g0qD3sv7mYubmXg4WAXLcIqHU1fnOjyta3cBXEoRxaNN OtWX3ixHzZOdmaIafhf14OWH23aZeDyCYIa.APj4YLEacfj35b.scdU4KENk.3.DpAXl3Ers06vE KSrusGgO07kEEpv5mxYMOHZ4UsVDNVWMkFvy9gnHlTKSDxVACR9JWwhXOYyNdl.YUUxyQW4y0hwZ G.IgqnH.IRr0zq0_.YH0wkBSdrJsRl5POcsqaIKb4.hCBatKv3acGMfgqtVooY48LxUq2dSodTwU hTVfQaFMORq43w_6AW5cP9sVCVaZhbbCqcnxQbwguY7GJjUP8UGdNVKES7UuUDI8Kqzsc60XyrHI HgBR3P5wWmzVocYXKZlcwIBfaDHikEjfp1dvlDaQ7BwyYk03vHqezsMnQSlG1RW9cADPWYRZnpu0 XMZPAXb657UVR28rqmNhQHJKty940lVpG_a1BpfjmjWdB7iUHt8oa8GfmZdWLZ7C4lLcvwWj.9HZ y_4WKaEWmcx_KR1fnJQf9nmy0W0Spm0hdFbj3vJgh2xsWxxoMDPqU5mPBHjlPb_2aTXaLmteIebp 1vH_XqGbrmTgrCXtjYA.sJCWMQjglFtEeY5p4_uRGHnAD20HjNuyt5a_xrJ7LpWaM6Y1Y_FvwMJt JFoBOHtp2Q8q9w3jaup1EyXOcLuvb8Hg5pYwhTJdSJizjwY2keSoYQUaw7MpPH8SPKeyU31J2VjK A5bQ49RmjzlxachP2w9HQ60LkCGF7S32pADOw6LcfxJqx0cqhm8dZvvW8cFShEzpRiyEBNzzAVUP uDAE85UQtZe6DF1U5rr1_YubC9NZ0pLYpX5bSBgE2vKO9.2hx Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Thu, 8 Nov 2018 15:11:35 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2c3273ef0482181bb8dbac8f133b786c; Thu, 08 Nov 2018 15:11:31 +0000 (UTC) To: Dick Hardt , gffletch=40aol.com@dmarc.ietf.org Cc: oauth@ietf.org References: From: George Fletcher Organization: AOL LLC Message-ID: <10bd2f07-d867-9db9-dfd7-9300617ec41b@aol.com> Date: Thu, 8 Nov 2018 10:11:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D58F2AF0E71755D093BA44C3" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 15:11:39 -0000 This is a multi-part message in MIME format. --------------D58F2AF0E71755D093BA44C3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cool! Sorry I couldn't make the meeting. One benefit of using WWW-Authenticate is that UMA has basically the same discovery logic (from RS to AS) and uses the WWW-Authenticate header. Keeping this discovery method the same (since UMA is just a profile of OAuth anyway) will help all developers. On 11/8/18 5:16 AM, Dick Hardt wrote: > George: in the WG meeting we discussed this topic of where to put the > discovery information. No one at the meeting advocated for using Link > response (Nat was the one who was advocating for this). Many others > preferred using the www-authenticate header similar to how you propose. > > On Thu, Nov 8, 2018 at 4:08 AM George Fletcher > > > wrote: > > Related to this discussion of AS discovery... what is the value of > using the Link response header over just returning the variables > in the WWW-Authenticate header? Could we not use... > > WWW-Authenticate: OAuth realm="example_realm", > scope="example_scope", error="invalid_token", > rs_uri="https://api.example.com/resource" > , > as_uri="https://as1.example.com,https://as2.example.com" > > > Thanks, > George > > On 11/6/18 12:19 AM, Justin P Richer wrote: >> In the meeting tonight I brought up a response to the question of >> whether to have full URL or plain issuer for the auth server in >> the RS response’s header. My suggestion was that we have two >> different parameters to the header to represent the AS: one of >> them being the full URL (as_uri) and one of them being the issuer >> to be constructed somehow (as_issuer). I ran into a similar >> problem on a system that I built last year where all of our >> servers had discovery documents but not all of them were easily >> constructed from an issuer style URL (using OIDC patterns >> anyway). So we solved it by having two different variables. If >> the full URL was set, we used that; if it wasn’t, we tried the >> issuer; if neither was set we didn’t do any discovery. >> >> I’m sensitive to Torsten’s concerns about complexity, but I think >> this is a simple and deterministic solution that sidesteps much >> of the issue. No pun intended. >> >> — 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 --------------D58F2AF0E71755D093BA44C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Cool! Sorry I couldn't make the meeting. One benefit of using WWW-Authenticate is that UMA has basically the same discovery logic (from RS to AS) and uses the WWW-Authenticate header. Keeping this discovery method the same (since UMA is just a profile of OAuth anyway) will help all developers.

On 11/8/18 5:16 AM, Dick Hardt wrote:
George: in the WG meeting we discussed this topic of where to put the discovery information. No one at the meeting advocated for using Link response (Nat was the one who was advocating for this). Many others preferred using the www-authenticate header similar to how you propose.

On Thu, Nov 8, 2018 at 4:08 AM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:
Related to this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", error="invalid_token", rs_uri="https://api.example.com/resource", as_uri="https://as1.example.com,https://as2.example.com"

Thanks,
George
On 11/6/18 12:19 AM, Justin P Richer wrote:
In the meeting tonight I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response’s header. My suggestion was that we have two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn’t, we tried the issuer; if neither was set we didn’t do any discovery.

I’m sensitive to Torsten’s concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun intended.

— 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

--------------D58F2AF0E71755D093BA44C3-- From nobody Thu Nov 8 08:42:33 2018 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 2D99A12D4E6 for ; Thu, 8 Nov 2018 08:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=yes.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 n5weKveXxXPx for ; Thu, 8 Nov 2018 08:42:27 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22ED0128BCC for ; Thu, 8 Nov 2018 08:42:27 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id k15-v6so18990796wre.12 for ; Thu, 08 Nov 2018 08:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=lZuifhLpZYTJ39QWIdJlgIsPx1jGCt3eiY4nzXglEhI=; b=VuVj3hWF5dtFL5i23LrI5cckFMaS/f4vxNojO0Pt88d0IToCAwb72LEQX86BlgJiIc O5A93kGbt850ZvR4o05CRCHJpbMKKFoin6BD84+SUOfgjvoaMLs4/O4qyObsY2sMzp9P EckS4UlxP9dToLmJNck454mlwjIEiA5mFMOVRbJzcGw6V8dr4ecel+szBDked2i4wzZN /Yoc4VT6n5uvhiku+AkPBUjU61V5fgllqx/IW8IomZysqtyWl5em36qzncdcSC7xl/ZQ xi8CAYisc1veQ6lRQvmkG5IIV8Ey0AqWusgZFUEmYElr2aHHAcy0Mr9yOBmIvBgAcghd 78/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lZuifhLpZYTJ39QWIdJlgIsPx1jGCt3eiY4nzXglEhI=; b=WBig6gTK2Ib1NLqq6vVVClOhf27sKq2RJuEvYrzX0rD8SHvPWg2EWXPIXY+6flhVUi qYcSazB7sZkH8JqfadpDh0mxNu5bBrR6dJbe24ZSZwgqlHtnhFmhvRa2Lt3ZxkqTEeJb 7mHGk2dmqq8O+dyLKMsXg7+GTS3COHwqxYyGMFX0XS7IlYZ8OxmJghPx12iJPvnI5cYI YuOdLmst+ubv9ULvHx1qnJnry+TUmQED/Gewpso7i4NIhlH4XKVBCC/4gobQj5A9B0v5 Y4tHA8ulRG/eElC8+SY8LQ30OBf8T4fRR9clEOruLmGfVfyUfQ4xzayMgUIMGDXExyq0 EqqA== X-Gm-Message-State: AGRZ1gIkRj+1qsv4MEKeWswFNCAybmJON+NrTpzJ1RXu0MWx2/unq+GZ 21gfMzf2hgHw44gm27TWZe2aHt005OY= X-Google-Smtp-Source: AJdET5d+HBMb/jfjj4b8DnYQSoYl7RyWhF96toBB7BGjYQdu/cqSFVyEMiD7HIdyVctUeW3cczprkg== X-Received: by 2002:adf:eb0b:: with SMTP id s11-v6mr4698735wrn.102.1541695345307; Thu, 08 Nov 2018 08:42:25 -0800 (PST) Received: from ?IPv6:2003:c1:4f35:9400:c81c:1386:f2dd:279e? (p200300C14F359400C81C1386F2DD279E.dip0.t-ipconnect.de. [2003:c1:4f35:9400:c81c:1386:f2dd:279e]) by smtp.gmail.com with ESMTPSA id w2-v6sm4043742wre.57.2018.11.08.08.42.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 08:42:24 -0800 (PST) From: Daniel Fett To: oauth@ietf.org References: Message-ID: <178f104d-0b3d-d2e9-8013-ff57adb9be4b@yes.com> Date: Thu, 8 Nov 2018 17:42:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------54F40EE5F6C70D4D88933447" Content-Language: de-DE Archived-At: Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 08 Nov 2018 16:42:31 -0000 This is a multi-part message in MIME format. --------------54F40EE5F6C70D4D88933447 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Aaron, Thanks for writing up clear guidelines for SPAs. I reviewed the draft and would like to offer some feedback: One important aspect I am missing is a brief discussion on how, in general, SPAs should be implemented; in particular, whether the browser-app exchanges the code for an access token or whether the server does that. In Section 7.6 it becomes clear that you propose to use the first solution (do everything in the browser, as would be expected from a true in-browser app). Other remarks: 6.1.: "The PKCE extension prevents an attack where the authorization code is intercepted and exchanged for an access token by a malicious client" I guess what you want to say here is that PKCE prevents the injection of an *authorization code* by a *malicious user*, right? 6.2.: "If an authorization server wishes to provide some flexibility in redirect URI usage to clients, it MAY require that only the hostname component of the redirect URI match the hostname of the URL the application is served from." At the bare minimum, the whole origin should be an exact match (otherwise a network attacker can intercept the auth code in the authz response when he uses the redirect URI http://correct-hostname.example ). This is also further discussed here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08#section-3.1 We there recommend exact redirect URI matching only. And finally some nitpicking: 5. "For example, an web email client" (an -> a) "or use the OAuth Password grant" -> should be the "Resource Owner Password Credentials Grant" to stick to the RFC6749 terminology - Daniel Am 06.11.18 um 11:13 schrieb Aaron Parecki: > Thanks Hannes, > > Since I wasn't able to give an intro during the meeting today, I'd > like to share a little more context about this here as well. > > At the Internet Identity Workshop in Mountain View last week, I led a > session to collect feedback on recommendations for OAuth for browser > based apps. During the session, we came up with a list of several > points based on the collective experience of the attendees. I then > tried to address all those points in this draft. > > The goal of this is not to specify any new behavior, but rather to > limit the possibilities that the existing OAuth specs provide, to > ensure a secure implementation in browser based apps. > > Thanks in advance for your review and feedback! > > Aaron Parecki > aaronpk.com > > > > On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig > > wrote: > > Hi all, > > Today we were not able to talk about > draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth > 2.0 for Browser-Based Apps". > > Aaron put a few slides together, which can be found here: > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf > > Your review of this new draft is highly appreciated. > > Ciao > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments > are confidential and may also be privileged. If you are not the > intended recipient, please 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. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------54F40EE5F6C70D4D88933447 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Aaron,

Thanks for writing up clear guidelines for SPAs. I reviewed the draft and would like to offer some feedback:

One important aspect I am missing is a brief discussion on how, in general, SPAs should be implemented; in particular, whether the browser-app exchanges the code for an access token or whether the server does that. In Section 7.6 it becomes clear that you propose to use the first solution (do everything in the browser, as would be expected from a true in-browser app).

Other remarks:

6.1.:
"The PKCE extension prevents an attack where the authorization code is intercepted and exchanged for an access token by a malicious client"
I guess what you want to say here is that PKCE prevents the injection of an *authorization code* by a *malicious user*, right?

6.2.:
"If an authorization server wishes to provide some flexibility in redirect URI usage to clients, it MAY require that only the hostname component of the redirect URI match the hostname of the URL the application is served from."
At the bare minimum, the whole origin should be an exact match (otherwise a network attacker can intercept the auth code in the authz response when he uses the redirect URI http://correct-hostname.example ).

This is also further discussed here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08#section-3.1
We there recommend exact redirect URI matching only.

And finally some nitpicking:

5.
"For example, an web email client" (an -> a)

"or use the OAuth Password grant" -> should be the "Resource Owner Password Credentials Grant" to stick to the RFC6749 terminology


- Daniel



Am 06.11.18 um 11:13 schrieb Aaron Parecki:
Thanks Hannes,

Since I wasn't able to give an intro during the meeting today, I'd like to share a little more context about this here as well.

At the Internet Identity Workshop in Mountain View last week, I led a session to collect feedback on recommendations for OAuth for browser based apps. During the session, we came up with a list of several points based on the collective experience of the attendees. I then tried to address all those points in this draft.

The goal of this is not to specify any new behavior, but rather to limit the possibilities that the existing OAuth specs provide, to ensure a secure implementation in browser based apps.

Thanks in advance for your review and feedback!

Aaron Parecki



On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi all,

Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.

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


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


--------------54F40EE5F6C70D4D88933447-- From nobody Thu Nov 8 08:43:55 2018 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 7A1DC130DC5 for ; Thu, 8 Nov 2018 08:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 oZ7cGTXe9i1i for ; Thu, 8 Nov 2018 08:43:43 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 52D9012D4EE for ; Thu, 8 Nov 2018 08:43:43 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id d10-v6so21972612wrs.5 for ; Thu, 08 Nov 2018 08:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=y+kD1SwySdTj2pwpehzYO4f+qEzeiR/P+3Ey/2k2Pks=; b=Rx/ihEmR33se9ar5/0bnoikjomZnxLul0xv3/fnWwgDXWEJ1qLXW69iDQvVVxUmzFk x4yexqjlgNnQDctTN3YAdFGgPTueLXNU9wuTvBpnOQr/4XiCFetmtsD1LwV65R5Y93Yi 2DFlOWeAOmLH1/aNLFxMuCe4OsoudSiC4rkOSBHsN3W2lXk4IAFnciC9TxM0Rae0RyRW SchaLjCqqc+XMTkqyPv/1tuLrtFCzYwuThVEJLk56U5f9a++nSEBzH/2C+HIa6Mh4Xel fiEuqavox/3nhQhOQhIND1PNGwEQFEHQyOv+LyOPnU3HFe+/9ZVRhmjQ/CDI+s8Xk1FD CL1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=y+kD1SwySdTj2pwpehzYO4f+qEzeiR/P+3Ey/2k2Pks=; b=l/2tLkOshPOJ/YMC3E04vTiuMHaJ5OComtLhKPB70KBPRIqZ2jyvz13GYa4DBrF0Nw 32wx4N9ZHgCFU8pCqAb6xm9lJDqufj/Fm1jOOYOIps0zhf0od/UaigHykYukHLiC+oF6 u92KOWvyvxt82o9W+EedLclOdIxAa3ETF1eaiCB6rPXJhuLXybx4s+2mZY20vHCbmt7Z nFiXl81bQNYpMTOzkdm1EMddfAfv1cM0jp5meajLRfr2lVRJccuFA+UajKDqMWcDa6rT w4KOmWrRzjxlRXpYsRB1ZDbnkOTgWGpIosG9EhUxZW6QV4d4dDQZ0or+fQZqYw4BJjdD mpyQ== X-Gm-Message-State: AGRZ1gLy5QbAnTsZn6+dhLYPMQWu1mJK1BPOMK1ZTzXBGGm2jHyljc2t tc+NiVQHaZlcFhkUWVfIZnlZTI/rDdM= X-Google-Smtp-Source: AJdET5e8HxrbLKtDEN3RWYu9DZxgbdWLIo8yfEpX6zgHU6aWtUOhBNgUcKlo9KZHQJPxyFdp4bzyMA== X-Received: by 2002:adf:80c8:: with SMTP id 66-v6mr4766031wrl.57.1541695421382; Thu, 08 Nov 2018 08:43:41 -0800 (PST) Received: from ?IPv6:2003:c1:4f35:9400:c81c:1386:f2dd:279e? (p200300C14F359400C81C1386F2DD279E.dip0.t-ipconnect.de. [2003:c1:4f35:9400:c81c:1386:f2dd:279e]) by smtp.gmail.com with ESMTPSA id z8-v6sm4816004wrr.94.2018.11.08.08.43.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 08:43:40 -0800 (PST) From: Daniel Fett To: oauth@ietf.org References: <710899611.302780.1541675954453@mail.yahoo.com> Message-ID: Date: Thu, 8 Nov 2018 17:43:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <710899611.302780.1541675954453@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------D28C4B34CAD45317707B79A1" Content-Language: de-DE Archived-At: Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 08 Nov 2018 16:43:46 -0000 This is a multi-part message in MIME format. --------------D28C4B34CAD45317707B79A1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Tomek, Am 08.11.18 um 12:19 schrieb Tomek Stojecki: > Thanks for putting this together Aaron.  > > Having read through the document, I am not as convinced that there is enough of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs. > > In section 7.8. the document outlines the Implicit flow disadvantages as following: > > "- OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client." > > If you use Code + PKCE with no client secret (public client) as it is being advocated, you can't verify the client either. PKCE is not for authenticating the client, it is there to provide a mechanism to verify inter-app communication, which occurs between a browser and a native app. There is no inter-app communication in implicit (everything stays in the browser), so no need for PKCE. PKCE can protect the auth code also in SPAs: The assumption is that the authz response can leak - it is just a URL after all. It can appear in log files, leak through mix-up, and many other attacks. (Browser-to-native app communication is just one case where the authz response can leak.) When using PKCE, an attacker cannot redeem a leaked auth code for a token at the token endpoint, since he does not know the pkce verifier.  That is the extra protection that PKCE provides. - Daniel --------------D28C4B34CAD45317707B79A1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Tomek,

Am 08.11.18 um 12:19 schrieb Tomek Stojecki:
Thanks for putting this together Aaron. 

Having read through the document, I am not as convinced that there is enough of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.

In section 7.8. the document outlines the Implicit flow disadvantages as following:

"- OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client."

If you use Code + PKCE with no client secret (public client) as it is being advocated, you can't verify the client either. PKCE is not for authenticating the client, it is there to provide a mechanism to verify inter-app communication, which occurs between a browser and a native app. There is no inter-app communication in implicit (everything stays in the browser), so no need for PKCE.

PKCE can protect the auth code also in SPAs:

The assumption is that the authz response can leak - it is just a URL after all. It can appear in log files, leak through mix-up, and many other attacks. (Browser-to-native app communication is just one case where the authz response can leak.)

When using PKCE, an attacker cannot redeem a leaked auth code for a token at the token endpoint, since he does not know the pkce verifier. 

That is the extra protection that PKCE provides.

- Daniel

--------------D28C4B34CAD45317707B79A1-- From nobody Thu Nov 8 09:08:32 2018 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 1574E128BCC for ; Thu, 8 Nov 2018 09:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qM1TPRaV__f for ; Thu, 8 Nov 2018 09:08:29 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 2F6421293FB for ; Thu, 8 Nov 2018 09:08:28 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA8GxIKh006542; Thu, 8 Nov 2018 17:08:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=FPHNzKAMTM6Rr9NZDhMpv0EVFqjKMKyu3eIA69EnK4Q=; b=qBk+81sQpk8MD7o8h893BkUbPEKiIKghWoII+Cb33OLvuIa/rGuySf4LmIa+vnFIte1/ bs9+RwNT4RtmmA7b2pWkYQbuVy4JweFiD9gnOeDN8jWOXUUBMJZiHudnJTYEEeQkNTio vOurFAcpT2M99lASLNY66FEfx+eFio5OcZY8GA1/yWfgsCvwz2YDRRlXpMEOlRM00cLX ih2p+XId8aYOAYIA87Jlg4BM+zva8C8Hh9hIU7h4J6jKyOcXLQZDJ2EKBMqheiUtwjUm AsFr1kbPAMvPIg4XVdtUCq4eMfw92XaicnY0KCz93HznMel2eBVE93PqwLeuCNrmyH/G dw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2nh3mq2qn1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 08 Nov 2018 17:08:25 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wA8H8NKi016827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Nov 2018 17:08:24 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wA8H8NNS011465; Thu, 8 Nov 2018 17:08:23 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Nov 2018 09:08:23 -0800 From: Phil Hunt Message-Id: <014B02F0-5CD7-487E-B374-1419BF2877DB@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5565CE63-9623-4C4B-B786-28A4947007C2" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Thu, 8 Nov 2018 09:08:20 -0800 In-Reply-To: <10bd2f07-d867-9db9-dfd7-9300617ec41b@aol.com> Cc: Dick Hardt , oauth@ietf.org To: George Fletcher References: <10bd2f07-d867-9db9-dfd7-9300617ec41b@aol.com> X-Mailer: Apple Mail (2.3445.101.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9071 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811080144 Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 17:08:31 -0000 --Apple-Mail=_5565CE63-9623-4C4B-B786-28A4947007C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dick,=20 I was generally agreeing with George and stating I think we have an = emerging *general* OAuth2 discovery problem emerging. Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Nov 8, 2018, at 7:11 AM, George Fletcher = wrote: >=20 > Cool! Sorry I couldn't make the meeting. One benefit of using = WWW-Authenticate is that UMA has basically the same discovery logic = (from RS to AS) and uses the WWW-Authenticate header. Keeping this = discovery method the same (since UMA is just a profile of OAuth anyway) = will help all developers. >=20 > On 11/8/18 5:16 AM, Dick Hardt wrote: >> George: in the WG meeting we discussed this topic of where to put the = discovery information. No one at the meeting advocated for using Link = response (Nat was the one who was advocating for this). Many others = preferred using the www-authenticate header similar to how you propose. >>=20 >> On Thu, Nov 8, 2018 at 4:08 AM George Fletcher = > = wrote: >> Related to this discussion of AS discovery... what is the value of = using the Link response header over just returning the variables in the = WWW-Authenticate header? Could we not use... >>=20 >> WWW-Authenticate: OAuth realm=3D"example_realm", = scope=3D"example_scope", error=3D"invalid_token", = rs_uri=3D"https://api.example.com/resource" = , = as_uri=3D"https://as1.example.com,https://as2.example.com" = >>=20 >> Thanks, >> George >>=20 >> On 11/6/18 12:19 AM, Justin P Richer wrote: >>> In the meeting tonight I brought up a response to the question of = whether to have full URL or plain issuer for the auth server in the RS = response=E2=80=99s header. My suggestion was that we have two different = parameters to the header to represent the AS: one of them being the full = URL (as_uri) and one of them being the issuer to be constructed somehow = (as_issuer). I ran into a similar problem on a system that I built last = year where all of our servers had discovery documents but not all of = them were easily constructed from an issuer style URL (using OIDC = patterns anyway). So we solved it by having two different variables. If = the full URL was set, we used that; if it wasn=E2=80=99t, we tried the = issuer; if neither was set we didn=E2=80=99t do any discovery. >>>=20 >>> I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about = complexity, but I think this is a simple and deterministic solution that = sidesteps much of the issue. No pun intended. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5565CE63-9623-4C4B-B786-28A4947007C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dick, 

I was generally agreeing with George and stating I think we = have an emerging *general* OAuth2 discovery problem emerging.

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Nov 8, 2018, at 7:11 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20
Cool! Sorry I = couldn't make the meeting. One benefit of using WWW-Authenticate is that = UMA has basically the same discovery logic (from RS to AS) and uses the WWW-Authenticate header. Keeping this discovery method the same (since UMA is just a profile of OAuth anyway) will help all developers.

On 11/8/18 5:16 AM, Dick Hardt = wrote:
George: in the WG meeting we discussed = this topic of where to put the discovery information. No one at the meeting advocated for using Link response (Nat was the one who was advocating for this). Many others preferred using the www-authenticate header similar to how you propose.

On Thu, Nov 8, 2018 at 4:08 AM = George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
Related to this discussion = of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"example_scope", error=3D"invalid_token", = rs_uri=3D"https://api.example.com/resource", as_uri=3D"https://as1.example.com,https://as2.example.com"=

Thanks,
George
On 11/6/18 12:19 AM, Justin P Richer wrote:
In the meeting tonight = I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response=E2=80=99= s header. My suggestion was that we have two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn=E2=80=99t, we tried the issuer; if = neither was set we didn=E2=80=99t do any discovery.

I=E2=80=99m sensitive to Torsten=E2=80=99s = concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun intended.

=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

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

= --Apple-Mail=_5565CE63-9623-4C4B-B786-28A4947007C2-- From nobody Thu Nov 8 11:04:20 2018 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 C6E3812D4EA for ; Thu, 8 Nov 2018 11:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sCM41W55OvFj for ; Thu, 8 Nov 2018 11:04:17 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6DF12D4E7 for ; Thu, 8 Nov 2018 11:04:16 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id u130-v6so17867157oie.7 for ; Thu, 08 Nov 2018 11:04:16 -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=TlofzruOrubdaiVOb5fVB5BNyd8jDsWbbQ4Hah2qKx8=; b=nFSNSMwhZ0zKMFhcxI47cFh/O+TepPtWXSSpjwbUnene9LiiZnvUuhqXJbdI/XmKjS 9auoPK5H+7cROdTgu39TL59HLpJopuRnMDktPdF14SuSyzMlocS7/TUHii/ySP8mjIYr qWMdbxOD0WHCSbpZK5nVlm4jG4Q0gvX5yvRKK6hq/EEUDWDB1Yybkwc6fbTd7Te+zTnx 2YWzho/vt7IOUUpSNAjqtmWnwyav1myAwzfxf9LLD+4VPoqdyitOjEr8U0Dh0JJ02yY6 nRNlWCqaRfn0FRicl8lZXUDe+jGjg7qq1DJ6b8QYuIbvczGzupD3uSQhWKb8F+CkbS+n TVAQ== 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=TlofzruOrubdaiVOb5fVB5BNyd8jDsWbbQ4Hah2qKx8=; b=DzwZD754NjeEcGMXLAmADm1312VhJfRof56kzUwvjHyfglrahUlSRZ8VjtHXv520VI D1yRW3xOgUwZ2dDMnmttCQAzKXo+F5Ibe9dAhBo1AuzMtg0UAdt6KGkukyDsIQQUM60d fxCn1cqIztUX6ws+cQ4pBmPZEfPPs5c8c0N3tGByUAxKqEAMtlQQ3xNNGejTMrdgkKWh uBqVAM7cpMyV9kQn1qyWdKoOc7USVrXCb+7dy9UDlUU2gB3LIYFbjr4E9xDbRE3Lz3+9 I3pNQMWbe2No1/oEjZoomfo6Y3iqBKVXq9iDv3TZLF3rZAr0ANceYco9CeoVm4e8KuwO gbpQ== X-Gm-Message-State: AGRZ1gKwPDtGCMOzl6XH67UG10Ye9ILAxzVpHJylIngGfrVTQ/RoypvT psEzDfMtletvP/Ns/YmXiXR4956JjKmrxLO83+E= X-Google-Smtp-Source: AJdET5fuP6mwuVUjjjrD1LQkWEp6FMipwBPKBsG8v8IDWxW1S2q8B35YRdgp/qDWHEQnCz0Gt5MSK3gLGHeUSaGr9kk= X-Received: by 2002:aca:6a4e:: with SMTP id f75-v6mr3515401oic.260.1541703856047; Thu, 08 Nov 2018 11:04:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Omer Levi Hevroni Date: Thu, 8 Nov 2018 21:04:04 +0200 Message-ID: To: dick.hardt@gmail.com Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b04c64057a2be649" Archived-At: Subject: Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant 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, 08 Nov 2018 19:04:19 -0000 --000000000000b04c64057a2be649 Content-Type: text/plain; charset="UTF-8" Yes, that is correct. I'm sorry the confusion, I think this confusion is built into oauth framework itself. You understood well the scenario - I have an application running on an untrusted device in an untrusted network. I looked for a way to authenticate the requests from the device to AS. Does it make more sense now? On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt wrote: > Omar > > As promised, I have reviewed the ID[1] you posted. I'm confused in the > Motivation by the references to authentication, as OAuth is about > authorization. > > Perhaps you can post to the list the use case you are trying to solve for? > I can infer aspects, but don't fully understand it. > > From what I can understand though, there is software running in a trusted > device that would like to get an access token, and an OTP is part of how > the device is authenticating to the AS. This seems like a 2 legged OAuth > flow as there is no user involved directly, and it seems you have a means > for the client to authenticate to the AS using an OTP. Am I guessing > correctly? > > /Dick > > [1] > https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 > > > --000000000000b04c64057a2be649 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, that is correct.=C2=A0
I'm sorry the conf= usion, I think this confusion is built into oauth=C2=A0framework itself.
You understood well the scenario - I have an application running on= an untrusted device in an untrusted network. I looked for a way to authent= icate the requests from the device to AS.
Does it make more sense= now?

On Thu, No= v 8, 2018 at 12:42 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Omar

<= div dir=3D"ltr">As promised, I have reviewed the ID[1] you posted. I'm = confused in the Motivation by the references to authentication, as OAuth is= about authorization.

Perh= aps you can post to the list the use case you are trying to solve for? I ca= n infer aspects, but don't fully understand it.=C2=A0

From what I can understand though, there is= software running in a trusted device that would like to get an access toke= n, and an OTP is part of how the device is authenticating to the AS. This s= eems like a 2 legged OAuth flow as there is no user involved directly, and = it seems you have a means for the client to authenticate to the AS using an= OTP. Am I guessing correctly?

--000000000000b04c64057a2be649-- From nobody Thu Nov 8 13:59:21 2018 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 79713130934 for ; Thu, 8 Nov 2018 13:59:20 -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, 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 MzEsa-tsCprR for ; Thu, 8 Nov 2018 13:59:18 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9D72912D4E8 for ; Thu, 8 Nov 2018 13:59:18 -0800 (PST) Received: from [IPv6:2601:282:202:b210:3cb7:7c78:650b:98d] (unknown [IPv6:2601:282:202:b210:3cb7:7c78:650b:98d]) by alkaline-solutions.com (Postfix) with ESMTPSA id ED63C31689; Thu, 8 Nov 2018 21:59:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: David Waite In-Reply-To: <710899611.302780.1541675954453@mail.yahoo.com> Date: Thu, 8 Nov 2018 14:59:16 -0700 Cc: oauth , Hannes Tschofenig Content-Transfer-Encoding: quoted-printable Message-Id: <9829E15A-416C-489E-A48D-58B771F6FFDA@alkaline-solutions.com> References: <710899611.302780.1541675954453@mail.yahoo.com> To: Tomek Stojecki X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 08 Nov 2018 21:59:20 -0000 > On Nov 8, 2018, at 4:19 AM, Tomek Stojecki = wrote: >=20 > Thanks for putting this together Aaron.=20 >=20 > Having read through the document, I am not as convinced that there is = enough of a benefit of Authorization Code + PKCE vs Implict Flow for = SPAs. >=20 > In section 7.8. the document outlines the Implicit flow disadvantages = as following: >=20 > "- OAuth 2.0 provides no mechanism for a client to verify that an = access token was issued to it, which could lead to misuse and possible = impersonation attacks if a malicious party hands off an access token it = retrieved through some other means to the client." >=20 > If you use Code + PKCE with no client secret (public client) as it is = being advocated, you can't verify the client either. PKCE is not for = authenticating the client, it is there to provide a mechanism to verify = inter-app communication, which occurs between a browser and a native = app. There is no inter-app communication in implicit (everything stays = in the browser), so no need for PKCE. Use of a fixed set of uniquely resolvable redirect URIs (e.g. not = localhost, not arbitrarily registrable custom URI schemes) does provide = an addressable channel to the public client for codes and implicit = tokens. I should not be able to make a client that can reuses the public = identifier as a third party, because I cannot catch the response URL = from the authorization endpoint. The difference is with implicit, the first party client cannot verify = the tokens were meant for the client (or really even that they came from = the AS). With code, you are contacting the AS and doing an exchange = based on the code and your public client identifier. In the sense of pure OAuth, where no authentication or additional = authorization decisions are made based on the access token, the issuer = and audience client could be checked via an introspection endpoint - but = if you are using pure OAuth and not relying on things like CORS = restrictions for your security model, it shouldn=E2=80=99t matter. For OpenID Connect and cases where you are going beyond a pure = authorization model (perhaps by having API access restricted by CORS), = this sort of check is important. You could trust clients to explicitly = check by looking in an id_token (when available) or calling an = introspection endpoint, or you could have this check happen as part of = normal flow by using code flow. PCKE does not resolve any known code injection attacks for SPA public = clients. Recommending administrators require PKCE does allow them to = start to make a single coherent policy for public clients. A consistent policy also helps in SPA/native app crossover cases. For = examples, a javascript app could be published as a native app via = wrapping in a Cordova-style toolset, or by sharing a significant amount = of code using a React-native style toolset. Both the SPA and native app = could then share handling links depending on native app installation due = to universal/app link features of the operating systems. For this = reason, there was a definite effort to propose best practices that = overlapped with the native app BCP. It is also worth noting that since the SPA and native app could share = the same client identifier and redirect handling (via universal links), = you *could* have code injection, but it would be between multiple = first-party apps. > "- Supporting the implicit flow requires additional code, more upkeep = and understanding of the related security considerations, while limiting = the authorization server to just the authorization code flow simplifies = the implementation." >=20 > This is subjective and can be easily argued the other way. I think one = of the main selling points behind implicit was its simplicity. It is = hard to argue (putting libraries aside) that making one redirect = (implicit) requires more code, work, etc.. than making a redirect and at = least two additional calls in order to get AT (plus CORS on AS side). The implicit flow is only simpler for clients until they have to get a = new access token. Typically then you need a different set of OAuth code = to request a new token in the background via a hidden iframe, failing = back to temporarily leaving the app via top-level redirect. There are = also cases where the safari browser detects this cross-domain iframe = bouncing as a tracker and segments any AS cookies/storage per client = site. It is more work for the AS to support both. You may also wind up having = different security models for the two different public client flows. In = particular, you may find yourself as an AS policy setter wanting to have = longer lived sessions for implicit clients which do not have refresh = tokens to extend access token validity in the background. For this = reason, you may also decide implicit clients cannot get access to the = same scopes that a code client can.=20 There are also gotchas people are not used to in implicit, such as = fragment identifiers being preserved on redirects. For OpenID Connect, getting the id_token on a back-end call means that = there is still transport-level security of the value if clients ignore = the signature. Again, you could trust your clients to explicitly add = signature verification code for id_tokens and access token hashes, as = well as verify the token issuer and audience - or you could have a = baseline level of security by using the code flow. > Further, in the beginning paragraph of 7.8, you mention that implicit = gets the AT through the front-channel. Exchanging code for AT will also = happen in the browser , where instead of a url you will have an xhr (and = again, now we have cors) >=20 > Finally, how is the AT going to be refreshed? Are we allowing for long = lived RT in the browser? I see that the document mentions CSP in 7.7, = but doesn't the same apply to securing AT with Implicit? Refresh tokens are used for two different purposes, and this might be = worth clarifying for those setting their security policy: 1. refresh tokens for =E2=80=9Coffline=E2=80=9D access, meaning that the = client may perform actions on the user=E2=80=99s behalf while the user = isn=E2=80=99t around. Typically, this means the refresh token lasts = until the user or AS revokes it, so authorization thus also remains = until revoked. 2. refresh tokens as a signaling method for re-authentication. In this = case, the idea is that tokens are being used =E2=80=9Conline=E2=80=9D as = part of user interaction, with the application being forced to send the = user to the AS to re-authenticate when the access token can no longer be = refreshed. If the AS can track consent to the client (by a unique client = identifier or via a mechanism like id_token_hint), this = re-authentication may still require no user interaction. For public clients, I see us using the second =E2=80=9Conline=E2=80=9D = refresh tokens. Whether they are long-lived or not really depends on the = AS policy for re-authentication. If the client is being run on a device = falling under corporate management, the AS might decide to make those = particular refresh tokens last indefinitely. -DW From nobody Thu Nov 8 15:55:01 2018 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 9E1FD127B92 for ; Thu, 8 Nov 2018 15:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3toCbB5qC4vU for ; Thu, 8 Nov 2018 15:54:57 -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 3470A126CC7 for ; Thu, 8 Nov 2018 15:54:57 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id s5-v6so33308ljd.12 for ; Thu, 08 Nov 2018 15:54:57 -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=7UojKXRulZ/orIN9B38eXz7jYFZnLBR/vEyTd15Vz3Q=; b=ugv4lNmpMZvm7yklIXBpjVlBHWtAo7QC5pOuWpqSjtvNJ05jYPS5O5pV2k6nVIwZWf 99ZrQKkQqLj3kU1TrpVmyWcaKJVLPXR+8sVvg9tViTrkIxsfL+a0sGe7IMz3lamxPSEq tLoE6KkU57BeJWZsxNj122CV1169EvfvkIchGonyoQooGKzCTeeOnrrozCXFHUihbnrk A7zjDjgNLIcJk/h2d3MB7dtraXy/nJjv64670ZAohjWoM7Je0uHnhy6Vyyyz0kCg07lD YxkncYvxZP4Xf4vsRVZkEjxYVHzUxls2Bd5G2XO1pQfcXc6W/LFNvEE2JzGlnLQ1YR3b zRVw== 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=7UojKXRulZ/orIN9B38eXz7jYFZnLBR/vEyTd15Vz3Q=; b=pb4ZY4PMxGIS3pACDAhUjKA+hyekdL4uG0fFwCHpk0pFZCvTfNmFnRnhMV/HXpoC0n 8YFqOROehYQlKnDdTFE4wnyjivUtHNQKh24MW+vDkYUEbRcDnf60gFDIUOcpuu+aG7lU U02K2YNoZrz1ftvQsQUKYTeDbomEqFD6ze+bB4opuhMmfVzUQ+ayXBpIfS8NeJr7AX7B TbvZdvikqyYLCqTsc8OtT4wUYMOgFFOR9+lD7rb7LVtQty4OD+1HzHVOnZKP3Jw47SuP gMvxsPGuvMc/aXXYsDCOymfmlBMdvExOz6AZIZ6w592CL4OuTORSTS+72LjJ+ecEDRQ0 Upxw== X-Gm-Message-State: AGRZ1gJFzHeB7IqReSxk7iqUUdwhNkfKuJJbhTqFcYpXg+Ly+nKxrtEX LgaY3mMG4erRjQ54NBnF27baFlGnGUTrcuHIkp4= X-Google-Smtp-Source: AJdET5fjhMjtPi5VFz6hi8Nv3LzkOCoR/GF/BB7iw/dOQ5GvNt5vu2Gflt+o/WuMpsjMgUBWWJdkvwg8qzbvIIihKJo= X-Received: by 2002:a2e:1510:: with SMTP id s16-v6mr4089588ljd.4.1541721295182; Thu, 08 Nov 2018 15:54:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 9 Nov 2018 06:54:42 +0700 Message-ID: To: Omer Levi Hevroni Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000024631e057a2ff6e4" Archived-At: Subject: Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant 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, 08 Nov 2018 23:55:00 -0000 --00000000000024631e057a2ff6e4 Content-Type: text/plain; charset="UTF-8" More detail on the scenario would help. On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni wrote: > Yes, that is correct. > I'm sorry the confusion, I think this confusion is built into > oauth framework itself. > You understood well the scenario - I have an application running on an > untrusted device in an untrusted network. I looked for a way to > authenticate the requests from the device to AS. > Does it make more sense now? > > On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt wrote: > >> Omar >> >> As promised, I have reviewed the ID[1] you posted. I'm confused in the >> Motivation by the references to authentication, as OAuth is about >> authorization. >> >> Perhaps you can post to the list the use case you are trying to solve >> for? I can infer aspects, but don't fully understand it. >> >> From what I can understand though, there is software running in a trusted >> device that would like to get an access token, and an OTP is part of how >> the device is authenticating to the AS. This seems like a 2 legged OAuth >> flow as there is no user involved directly, and it seems you have a means >> for the client to authenticate to the AS using an OTP. Am I guessing >> correctly? >> >> /Dick >> >> [1] >> https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 >> >> >> --00000000000024631e057a2ff6e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
More detail on the scenario would help.
<= div>
On Fri, Nov 9, 2018 at = 2:04 AM Omer Levi Hevroni <omerlh@gm= ail.com> wrote:
Yes, that is correct.=C2=A0
I'm sorry the confusion, I thi= nk this confusion is built into oauth=C2=A0framework itself.
You = understood well the scenario - I have an application running on an untruste= d device in an untrusted network. I looked for a way to authenticate the re= quests from the device to AS.
Does it make more sense now?
<= /div>
On Thu, Nov 8, 2018 at= 12:42 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Omar

<= /div>
As promised, I have reviewed the ID[1] you posted. I&= #39;m confused in the Motivation by the references to authentication, as OA= uth is about authorization.

Perhaps you can post to the list the use case you are trying to solve for= ? I can infer aspects, but don't fully understand it.=C2=A0

From what I can understand though, th= ere is software running in a trusted device that would like to get an acces= s token, and an OTP is part of how the device is authenticating to the AS. = This seems like a 2 legged OAuth flow as there is no user involved directly= , and it seems you have a means for the client to authenticate to the AS us= ing an OTP. Am I guessing correctly?

--00000000000024631e057a2ff6e4-- From nobody Thu Nov 8 22:53:53 2018 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 05356130DF7 for ; Thu, 8 Nov 2018 22:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cV2EZlXo6iY1 for ; Thu, 8 Nov 2018 22:53:35 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0121.outbound.protection.outlook.com [104.47.53.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBE8130DE9 for ; Thu, 8 Nov 2018 22:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=85kQGGIUgM13pdadpV3lXVdO8mzLd8nHWj4ruERcaTA=; b=F0rOf+FXoJFBSlPbbIKc0QE8Urvt40Rj9cYfZlpBcmW84SYMCGwX2csLDuVeKEY6fq9F7IRjBDuRnKsrAM231gZUHUwUUtbCMyVI/hlPTmEJtH6GGq8cUV0oJA6zxyo+BjmH/utRvqQZ2U+PZBVnTpIK0xl4OI5oJAdvlUVoEGc= Received: from MW2PR00MB0300.namprd00.prod.outlook.com (52.132.148.31) by MW2PR00MB0442.namprd00.prod.outlook.com (52.132.149.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1362.0; Fri, 9 Nov 2018 06:53:31 +0000 Received: from MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::701e:fb23:db7b:2fec]) by MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::701e:fb23:db7b:2fec%6]) with mapi id 15.20.1361.000; Fri, 9 Nov 2018 06:53:31 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JWT BCP updates addressing Area Director review comments Thread-Index: AdR38+0WloFKUaMkSI2c2rtrZ9tvfA== Date: Fri, 9 Nov 2018 06:53:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0442; 6:PVhhe/58rIWWEv3p2EyKsUyOykq9dZLl3nqUog9Ue5w1WcwkE1Wcvst8SCF0XR2m2y1YrJPg3N7/lZX0PyRkHDmtUCxiTNFWNlkR1wKVT0JgzHOwsfRB8wX0fyB3MVW/2CYbhhHMpr/fXjOTKXyK1jTLC2LM1DklymYJhdyowsgRfxCPD4YUu11ubdYajCVUr+Sym6krNlNIJggAgbXjyDtEKqLjTyZQdYwlsKW/7z8+fMcdzAOVfqn3AkVOq3A/HKx2oUb5gJ3AP0PRt91SCXSoi6EUBAaujCQxugCtWe4i2kXy4tSYDn0OoIH0S8Scffl/AfAiHFyOd/QijUnzlqhDNaxu77bnPX47xYp54HbqD9+44QqIDQzZc4up1YZ9W78YDKXI7yXqh1b15OidAFXE+3M/BpS2pAEqtijCl2NTGFOhy0+PEDFMpQ9JQjO+L/wbL1Q0tK/B3KJpR1bi/g==; 5:kMDsIUg2M9i9Z/y6R6nep09WwjoCXtIWkoaPZ9GkMgX/PdOLTH4wLVzpOeK3KlvKpww3OTJuYHeQQ5CihjltRGny31qezOXubAORCXVv4bscRxcWcFMN4Xgb6gmk+Joz026MuOC1yrOFujXXu3CdnbhIRd5UCLA/Edbhv5Gyz9I=; 7:PJvwAd9xY4o/dTF8MGu4Y2E2YsacjSJA4nDSXrdhex2bU8Cei1I7QHZk2pv3irdD9M339ooXTQApNlkN6AG2JMrzkPEILlNIrog7apOJG9agN6UVislfwjooQwFQ9LqxbxuXqWWU1KwuvvrHzH/p8g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4a936af9-f2bf-4bc8-72dc-08d646100f91 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MW2PR00MB0442; x-ms-traffictypediagnostic: MW2PR00MB0442: x-ms-exchange-purlcount: 9 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231390)(944501410)(4982022)(2018427008)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:MW2PR00MB0442; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0442; x-forefront-prvs: 08512C5403 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(366004)(39860400002)(136003)(396003)(346002)(209900001)(199004)(189003)(6116002)(106356001)(6916009)(2906002)(105586002)(54896002)(9686003)(966005)(6436002)(55016002)(6306002)(2900100001)(7110500001)(7696005)(22452003)(2420400007)(606006)(316002)(2501003)(68736007)(217873002)(72206003)(790700001)(14454004)(486006)(86612001)(476003)(86362001)(21615005)(26005)(66066001)(99286004)(53376002)(186003)(74316002)(25786009)(3846002)(71190400001)(5660300001)(6506007)(10090500001)(53936002)(81166006)(5640700003)(236005)(8676002)(14444005)(7736002)(8990500004)(33656002)(8936002)(256004)(10290500003)(97736004)(478600001)(102836004)(81156014)(15650500001)(2351001)(1730700003)(71200400001)(6606295002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0442; H:MW2PR00MB0300.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: hMdQuiAiZHH3uy18aSKN7ClT4X7DjfXrKqNtdF6mLeYBsmqhO7VZy/E+JWcICucXtKmtm66f7Scoi3a173liEeQ7Ife03sZ14yQzITczXOQ4azNCXV+GGyPjJma5icAe5zpMWk/miQIgDX5T/Q6tA2CKb75u/Vxp/gtUvc/HEqnS2jkx6wj4hGfeIDKLop7G+Tm1bXOKDfMtL3rzjpiu25a6nea3Gvxe3dCliyTWGauzPY7vRBv5bduSzRWFbA002xq0COP8BoowStM4051rlKwrf0236uiivfets6iCYuDsCIkthF1k8SNSJLc5B2O3cTUEy3CkggKlX62/Jb5zcf5VSE15CCNFyzQ/P468Ac0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB030055B76E01749F2AEE42C2F5C60MW2PR00MB0300namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a936af9-f2bf-4bc8-72dc-08d646100f91 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2018 06:53:31.3354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0442 Archived-At: Subject: [OAUTH-WG] JWT BCP updates addressing Area Director review comments 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, 09 Nov 2018 06:53:40 -0000 --_000_MW2PR00MB030055B76E01749F2AEE42C2F5C60MW2PR00MB0300namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The JSON Web Token (JWT) Best Current Practices (BCP) specification has bee= n updated to address the review comments from Security Area Director (AD) E= ric Rescorla. Thanks to Eric for the review and to Yaron Sheffer for worki= ng on the responses with me. Note that IETF publication has already been requested. The next step is fo= r the shepherd review to be submitted and responded to. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-04 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-jwt-bcp-04.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1936 and = as @selfissued. --_000_MW2PR00MB030055B76E01749F2AEE42C2F5C60MW2PR00MB0300namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The JSON Web Token (JWT) Best Current Practices (BCP= ) specification has been updated to address the review comments from Securi= ty Area Director (AD) Eric Rescorla.  Thanks to Eric for the review an= d to Yaron Sheffer for working on the responses with me.

 

Note that IETF publication has already been requeste= d.  The next step is for the shepherd review to be submitted and respo= nded to.

 

The specification is available at:

--_000_MW2PR00MB030055B76E01749F2AEE42C2F5C60MW2PR00MB0300namp_-- From nobody Fri Nov 9 00:33:13 2018 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 611AE124D68; Fri, 9 Nov 2018 00:32:56 -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: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154175237636.14370.2795740097592534192@ietfa.amsl.com> Date: Fri, 09 Nov 2018 00:32:56 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 08:32:57 -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 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Daniel Fett Filename : draft-ietf-oauth-security-topics-09.txt Pages : 35 Date : 2018-11-09 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 9 00:57:05 2018 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 B73D5127332 for ; Fri, 9 Nov 2018 00:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AgAPfA75VWHN for ; Fri, 9 Nov 2018 00:57:00 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0129.outbound.protection.outlook.com [104.47.53.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF60124408 for ; Fri, 9 Nov 2018 00:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gqzPQ2WIPSC7dstqT2O4vudr5Iwzi9+r4iysL2fxaow=; b=MGG74L2SjgjZ8l8YeUErjI1ytqhxETBRJp4t0OA0fqFqEdfWAXNaVO8TGPaPLdfauDWlN7jFSBz2RFT4TGKl2uS7nzL/EMKSgJj3lJa3ITbZnaXoDpb9OeAu+7YMApwi6gsqzJWIGS6Jkq88Iu/r03i2Qraqyrojz1c5QqtCsyw= Received: from MW2PR00MB0300.namprd00.prod.outlook.com (52.132.148.31) by MW2PR00MB0444.namprd00.prod.outlook.com (52.132.149.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1360.0; Fri, 9 Nov 2018 08:56:53 +0000 Received: from MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::701e:fb23:db7b:2fec]) by MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::701e:fb23:db7b:2fec%6]) with mapi id 15.20.1361.000; Fri, 9 Nov 2018 08:56:53 +0000 From: Mike Jones To: Eric Rescorla CC: oauth Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp Thread-Index: AQHUPYBLZ8Pf3pDy70ieP7DpSsramaVHeJmA Date: Fri, 9 Nov 2018 08:56:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.191.113] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0444; 6:3QI9TVcAF3ZhTg+maXd6u6L68omQhuxIyEX3MGRODrVvo/MwTwbw6Tza42wFocznWYGoQmZhPhWPOzJLJOr8ExvYxlWOUJ+SXQ2Sj08qH0eL7MOblxuPEzVUp3swQ3zLJu1hS7NvU3ahnKk8gqC4MfIpgExS08lj8Y/qCVaeCpnbdl8cBCSLk+EuZkOvwqaGobdBm4SeRuBPDg2Smx6Ko9P9VlHJH3HSxLoT2UP1gZ7EtVjzo1akAWVg+htsnELEU4zv4o/LtkLAhNeDtn4GNa4beHkomenL7ijCupirSKd8CtLkTRMfRUE89l4HKY2IlZ7hy3WKjcDzSr7OER/mDw7usT4nsvfG+02d6xM/rXF7NrIMF4mk0anH959smpIDSEZwPS6FZS/TQvAsa4aUvrwLXVS2voSVbUHjDA1qBQ/Jo5KyuL8mVxqx2hPy68JSzvlMFldH19FZ9ORKInn5xg==; 5:oIeOPrkcoTwH5z6B4IvkqraFjZbBHn9qm6V5klWFuvSIyi25aMeYe3JOtn8c3ofIGhq2fyizAOcaTgAOXPCuH+9XWA0dtGAlcHDjHJpJ7ktVgsbOUut3yqlBtgfx/uFfISanm3h2MQoAlqmMES2lPDtMaBQdazkNzJFnpUKOE3M=; 7:cjMzV8pXTsy4AzrjkaHNYAigMCTREmP9AdIqcJMA1cPToJQ1xfqUfhWwMXYmCqdcjwM+fK32PfeqeQaR8l/rCWn31zgobnQE8UGsYm5fTVL9QpYvVoMM2M22fsZEizeVSiwijNutITO9zfET3eSITg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b6cf84b1-00b8-42cf-8f95-08d646214b5c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR00MB0444; x-ms-traffictypediagnostic: MW2PR00MB0444: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231390)(944501410)(2018427008)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:MW2PR00MB0444; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0444; x-forefront-prvs: 08512C5403 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(346002)(396003)(376002)(199004)(189003)(5660300001)(81156014)(4326008)(74316002)(8936002)(106356001)(6916009)(8676002)(81166006)(26005)(7736002)(86612001)(2906002)(86362001)(551544002)(33656002)(6116002)(14454004)(25786009)(105586002)(478600001)(446003)(3846002)(790700001)(72206003)(6436002)(229853002)(22452003)(316002)(966005)(10290500003)(55016002)(97736004)(68736007)(6246003)(8990500004)(2900100001)(9686003)(236005)(54896002)(10090500001)(606006)(53936002)(7696005)(102836004)(76176011)(71200400001)(486006)(99286004)(71190400001)(66066001)(476003)(186003)(14444005)(11346002)(256004)(53546011)(6506007)(6346003)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0444; H:MW2PR00MB0300.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: Ummts2+J18VblclL/5SnwcNxAw9ADa+SLIS6LyNGJkAZzVwKLzxz8YWPbOPpirL8MdzVExtLbUE8N0D/Lfjp5nRCreTmaPf6524Qb/JXgJHXRqWiA8YKwI8cBRSl2cZ5G3bCTSuh4ecrOCNUtUyJfLixp51ZYgsSCt9OOMjugyQ/Ud4nrVayUw1OgdMZwo9ohAWbf2144wo3ccdNOw4DQPizBQBYv+3aUBr2l51GYQ4Kiqbn4+bT7ZigAph/8bjJKFV6eybPofOybuZF38nBBaNuaoVWRs813hTVmnhgjXYY5EBx1qt5Y0Z6iwWrRhPnoVtsgFKHEFr6ijIz3z7VQhPnILh9VjwkdsRBQleBoLM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB030055D02E7E6C55A28533D4F5C60MW2PR00MB0300namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6cf84b1-00b8-42cf-8f95-08d646214b5c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2018 08:56:52.9964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0444 Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp 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, 09 Nov 2018 08:57:04 -0000 --_000_MW2PR00MB030055D02E7E6C55A28533D4F5C60MW2PR00MB0300namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFnYWluIGZvciB0aGUgcmV2aWV3LCBFcmljLiAgVGhlIHJlc29sdXRpb25zIHB1Ymxp c2hlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3Qt YmNwLTA0IGFyZSBhcyBmb2xsb3dzLi4uDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogTW9uZGF5LCBBdWd1c3Qg MjcsIDIwMTggNDowMyBBTQ0KVG86IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtP QVVUSC1XR10gQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtand0LWJjcA0KDQpSaWNoIHZl cnNpb24gb2YgdGhpcyByZXZpZXcgYXQ6DQpodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYu bW96YXdzLm5ldC9ENDY0OQ0KDQpDT01NRU5UUw0KUyAxLjIuDQo+ICAgMS4yLiAgQ29udmVudGlv bnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50DQo+DQo+ICAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KPiAgICAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kDQo+ICAgICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4NCj4gICAgICBbUkZDMjExOV0uDQoNCllvdSB3aWxs IHdhbnQgdG8gY2l0ZSA4MTc0IGhlcmUuDQoNCk1pa2U+IERvbmUuDQoNClMgMi42Lg0KPg0KPiAg IDIuNi4gIFN1YnN0aXR1dGlvbiBBdHRhY2tzDQo+DQo+ICAgICAgVGhlcmUgYXJlIGF0dGFja3Mg aW4gd2hpY2ggb25lIHJlY2lwaWVudCB3aWxsIGhhdmUgYSBKV1QgaW50ZW5kZWQgZm9yDQo+ICAg ICAgaXQgYW5kIGF0dGVtcHQgdG8gdXNlIGl0IGF0IGEgZGlmZmVyZW50IHJlY2lwaWVudCB0aGF0 IGl0IHdhcyBub3QNCj4gICAgICBpbnRlbmRlZCBmb3IuICBJZiBub3QgY2F1Z2h0LCB0aGVzZSBh dHRhY2tzIGNhbiByZXN1bHQgaW4gdGhlDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGF0dGFj ay4gQ2FuIHlvdSBnbyBpbnRvIG1vcmUgZGV0YWlsPw0KDQpNaWtlPiBBZGRlZCBhbiBleGFtcGxl IHN0YXJ0aW5nIHdpdGgg4oCcRm9yIGluc3RhbmNlLCBpZiBhbiBPQXV0aCAyLjAgYWNjZXNzIHRv a2Vu4oCm4oCdIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgYXR0YWNrIGNsZWFyZXIuDQoNClMgMy4y Lg0KPiAgICAgIFRoZXJlZm9yZSwgYXBwbGljYXRpb25zIE1VU1Qgb25seSBhbGxvdyB0aGUgdXNl IG9mIGNyeXB0b2dyYXBoaWNhbGx5DQo+ICAgICAgY3VycmVudCBhbGdvcml0aG1zIHRoYXQgbWVl dCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZQ0KPiAgICAgIGFwcGxpY2F0aW9uLi4g IFRoaXMgc2V0IHdpbGwgdmFyeSBvdmVyIHRpbWUgYXMgbmV3IGFsZ29yaXRobXMgYXJlDQo+ICAg ICAgaW50cm9kdWNlZCBhbmQgZXhpc3RpbmcgYWxnb3JpdGhtcyBhcmUgZGVwcmVjYXRlZCBkdWUg dG8gZGlzY292ZXJlZA0KPiAgICAgIGNyeXB0b2dyYXBoaWMgd2Vha25lc3Nlcy4gIEFwcGxpY2F0 aW9ucyBtdXN0IHRoZXJlZm9yZSBiZSBkZXNpZ25lZCB0bw0KPiAgICAgIGVuYWJsZSBjcnlwdG9n cmFwaGljIGFnaWxpdHkuDQoNCklzIHRoaXMgbXVzdCBub3JtYXRpdmU/DQoNCk1pa2U+IE5vdyBp dOKAmXMgYSDigJxNVVNU4oCdLg0KDQpTIDMuMi4NCj4gICAgICBtYXkgYmUgbm8gbmVlZCB0byBh cHBseSBhbm90aGVyIGxheWVyIG9mIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbnMgdG8NCj4gICAg ICB0aGUgSldULiAgSW4gc3VjaCBjYXNlcywgdGhlIHVzZSBvZiB0aGUgIm5vbmUiIGFsZ29yaXRo bSBjYW4gYmUNCj4gICAgICBwZXJmZWN0bHkgYWNjZXB0YWJsZS4gIEpXVHMgdXNpbmcgIm5vbmUi IGFyZSBvZnRlbiB1c2VkIGluDQo+ICAgICAgYXBwbGljYXRpb24gY29udGV4dHMgaW4gd2hpY2gg dGhlIGNvbnRlbnQgaXMgb3B0aW9uYWxseSBzaWduZWQ7IHRoZW4NCj4gICAgICB0aGUgVVJMLXNh ZmUgY2xhaW1zIHJlcHJlc2VudGF0aW9uIGFuZCBwcm9jZXNzaW5nIGNhbiBiZSB0aGUgc2FtZSBp bg0KPiAgICAgIGJvdGggdGhlIHNpZ25lZCBhbmQgdW5zaWduZWQgY2FzZXMuDQoNCkkgdGhpbmsg eW91IHByb2JhYmx5IG5lZWQgdG8gaGF2ZSBhIGNsZWFyZXIgImRvbid0IHVzZSBub25lIGJ5DQpk ZWZhdWx0IiBzdGF0ZW1lbnQgaGVyZS4NCg0KTWlrZT4gQWRkZWQgdHdvIHNlbnRlbmNlcyB0byB0 aGlzIGVmZmVjdCDigJMgb25lIGFib3V0IGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiBvZiB0aGUg SldUIGFuZCBvbmUgYWJvdXQg4oCcbm9uZeKAnSBub3QgYmVpbmcgYSBsaWJyYXJ5IGRlZmF1bHQu DQoNClMgMy40Lg0KPiAgICAgIEVDREgtRVMgZXBoZW1lcmFsIHB1YmxpYyBrZXkgKGVwaykgaW5w dXRzIHNob3VsZCBiZSB2YWxpZGF0ZWQNCj4gICAgICBhY2NvcmRpbmcgdG8gdGhlIHJlY2lwaWVu dCdzIGNob3NlbiBlbGxpcHRpYyBjdXJ2ZS4gIEZvciB0aGUgTklTVA0KPiAgICAgIHByaW1lLW9y ZGVyIGN1cnZlcyBQLTI1NiwgUC0zODQgYW5kIFAtNTIxLCB2YWxpZGF0aW9uIE1VU1QgYmUNCj4g ICAgICBwZXJmb3JtZWQgYWNjb3JkaW5nIHRvIFNlY3Rpb24gNS42LjIuMy40ICJFQ0MgUGFydGlh bCBQdWJsaWMtS2V5DQo+ICAgICAgVmFsaWRhdGlvbiBSb3V0aW5lIiBvZiBOSVNUIFNwZWNpYWwg UHVibGljYXRpb24gODAwLTU2QSByZXZpc2lvbiAzDQo+ICAgICAgW25pc3Qtc3AtODAwLTU2YS1y M10uDQoNCklzIHRoZXJlIGFuIFgyNTUxOSBzcGVjaWZpY2F0aW9uIGZvciBKV0U/IElmIHNvLCB5 b3Ugc2hvdWxkIHByb2JhYmx5DQpzcGVjaWZ5IHRoZSBhcHByb3ByaWF0ZSBjaGVja3MuDQoNCk1p a2U+IENpdGVkIFtSRkM4MDM3XSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgWDI1NTE5IGFu ZCBYNDQ4Lg0KDQpTIDMuNS4NCj4gICAzLjUuICBFbnN1cmUgQ3J5cHRvZ3JhcGhpYyBLZXlzIGhh dmUgU3VmZmljaWVudCBFbnRyb3B5DQo+DQo+ICAgICAgVGhlIEtleSBFbnRyb3B5IGFuZCBSYW5k b20gVmFsdWVzIGFkdmljZSBpbiBTZWN0aW9uIDEwLjEgb2YgW1JGQzc1MTVdDQo+ICAgICAgYW5k IHRoZSBQYXNzd29yZCBDb25zaWRlcmF0aW9ucyBpbiBTZWN0aW9uIDguOCBvZiBbUkZDNzUxOF0g TVVTVCBiZQ0KPiAgICAgIGZvbGxvd2VkLiAgSW4gcGFydGljdWxhciwgaHVtYW4tbWVtb3JpemFi bGUgcGFzc3dvcmRzIE1VU1QgTk9UIGJlDQo+ICAgICAgZGlyZWN0bHkgdXNlZCBhcyB0aGUga2V5 IHRvIGEga2V5ZWQtTUFDIGFsZ29yaXRobSBzdWNoIGFzICJIUzI1NiIuDQoNCklmIHlvdSBjYW4n dCB1c2UgdGhlbSAiZGlyZWN0bHkiIHRoYW4gaG93IHNob3VsZCB5b3UgdXNlIHRoZW0/IERvIHlv dQ0Kd2FudCB0byBzYXkgYW55dGhpbmcgYWJvdXQgcGFzc3dvcmQgaGFzaGluZyAoYXJnb24sIGV0 Yy4pPw0KDQpNaWtlPiBBZGRlZCBhIHNlbnRlbmNlIGFib3V0IG9ubHkgdXNpbmcgcGFzc3dvcmQt YmFzZWQgZW5jcnlwdGlvbiBmb3Iga2V5IGVuY3J5cHRpb24sIHJhdGhlciB0aGFuIGNvbnRlbnQg ZW5jcnlwdGlvbi4gIEFsc28gYWRkZWQgYSBzZW50ZW5jZSBhYm91dCBicnV0ZSBmb3JjZSBhdHRh Y2tzLg0KDQpTIDMuMTIuDQo+ICAgICAgICAgb2YgSldUcy4NCj4NCj4gICAgICBHaXZlbiB0aGUg YnJvYWQgZGl2ZXJzaXR5IG9mIEpXVCB1c2FnZSBhbmQgYXBwbGljYXRpb25zLCB0aGUgYmVzdA0K PiAgICAgIGNvbWJpbmF0aW9uIG9mIHR5cGVzLCByZXF1aXJlZCBjbGFpbXMsIHZhbHVlcywgaGVh ZGVyIHBhcmFtZXRlcnMsIGtleQ0KPiAgICAgIHVzYWdlcywgYW5kIGlzc3VlcnMgdG8gZGlmZmVy ZW50aWF0ZSBhbW9uZyBkaWZmZXJlbnQga2luZHMgb2YgSldUcw0KPiAgICAgIHdpbGwsIGluIGdl bmVyYWwsIGJlIGFwcGxpY2F0aW9uIHNwZWNpZmljLg0KDQpJIGdldCB0aGF0IHRoaXMgaXMgdGhl IHN0YXRlIHdlIGZpbmQgb3Vyc2VsdmVzIGluLCBidXQgaXQgc2VlbXMgbGlrZQ0KaXQncyB1bmZv cnR1bmF0ZS4gVGhpcyBtaWdodCBiZSBhIGdvb2QgdGltZSB0byByZS1lbXBoYXNpemUgdGhlDQpy ZWNvbW1lbmRhdGlvbiBmb3IgZXhwbGljaXQgdHlwZXMgaW4gMy4xMS4NCg0KV2Ugbm93IGV4cGxp Y2l0bHkgc2F5IHRoYXQgZXhwbGljaXQgdHlwaW5nIGlzIFJFQ09NTUVOREVEIGZvciBuZXcgSldU IGFwcGxpY2F0aW9ucy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo= --_000_MW2PR00MB030055D02E7E6C55A28533D4F5C60MW2PR00MB0300namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhbmtzIGFnYWluIGZvciB0aGUgcmV2aWV3LCBFcmlj LiZuYnNwOyBUaGUgcmVzb2x1dGlvbnMgcHVibGlzaGVkIGluDQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLTA0Ij5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLTA0PC9hPiBhcmUgYXMg Zm9sbG93cy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNA aWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpFcmljIFJlc2NvcmxhPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDI3LCAyMDE4IDQ6MDMgQU08YnI+DQo8Yj5Ubzo8L2I+ IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRI LVdHXSBBRCBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SaWNoIHZlcnNpb24gb2YgdGhpcyByZXZpZXcgYXQ6PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQ2NDkiPmh0 dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0NjQ5PC9hPjxicj4NCjxi cj4NCkNPTU1FTlRTPGJyPg0KUyAxLjIuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyAxLjIuJm5ic3A7 IENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudDxicj4NCiZndDsmbmJzcDsmbmJzcDsg PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUga2V5IHdvcmRzICZx dW90O01VU1QmcXVvdDssICZxdW90O01VU1QgTk9UJnF1b3Q7LCAmcXVvdDtSRVFVSVJFRCZxdW90 OywgJnF1b3Q7U0hBTEwmcXVvdDssICZxdW90O1NIQUxMIE5PVCZxdW90Oyw8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hP VUxEIE5PVCZxdW90OywgJnF1b3Q7UkVDT01NRU5ERUQmcXVvdDssICZxdW90O05PVCBSRUNPTU1F TkRFRCZxdW90OywgJnF1b3Q7TUFZJnF1b3Q7LCBhbmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O09QVElPTkFMJnF1b3Q7IGluIHRoaXMgZG9jdW1lbnQgYXJl IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgW1JGQzIxMTldLjxicj4NCjxicj4NCllvdSB3aWxsIHdhbnQgdG8g Y2l0ZSA4MTc0IGhlcmUuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5NaWtlJmd0OyBEb25lLjwvc3Bhbj48YnI+DQo8YnI+DQpTIDIuNi48YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsgMi42LiZuYnNwOyBTdWJz dGl0dXRpb24gQXR0YWNrczxicj4NCiZndDsmbmJzcDsmbmJzcDsgPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGVyZSBhcmUgYXR0YWNrcyBpbiB3aGljaCBvbmUgcmVj aXBpZW50IHdpbGwgaGF2ZSBhIEpXVCBpbnRlbmRlZCBmb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IGFuZCBhdHRlbXB0IHRvIHVzZSBpdCBhdCBhIGRpZmZlcmVu dCByZWNpcGllbnQgdGhhdCBpdCB3YXMgbm90PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBpbnRlbmRlZCBmb3IuJm5ic3A7IElmIG5vdCBjYXVnaHQsIHRoZXNlIGF0dGFj a3MgY2FuIHJlc3VsdCBpbiB0aGU8YnI+DQo8YnI+DQpJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBh dHRhY2suIENhbiB5b3UgZ28gaW50byBtb3JlIGRldGFpbD88YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1pa2UmZ3Q7IEFkZGVkIGFuIGV4YW1w bGUgc3RhcnRpbmcgd2l0aCDigJxGb3IgaW5zdGFuY2UsIGlmIGFuIE9BdXRoIDIuMCBhY2Nlc3Mg dG9rZW7igKbigJ0gdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBhdHRhY2sgY2xlYXJlci48L3NwYW4+ PGJyPg0KPGJyPg0KUyAzLjIuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGVyZWZvcmUsIGFwcGxpY2F0aW9ucyBNVVNUIG9ubHkgYWxsb3cgdGhlIHVzZSBvZiBjcnlw dG9ncmFwaGljYWxseTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3Vy cmVudCBhbGdvcml0aG1zIHRoYXQgbWVldCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRo ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGljYXRpb24uLiZu YnNwOyBUaGlzIHNldCB3aWxsIHZhcnkgb3ZlciB0aW1lIGFzIG5ldyBhbGdvcml0aG1zIGFyZTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50cm9kdWNlZCBhbmQgZXhp c3RpbmcgYWxnb3JpdGhtcyBhcmUgZGVwcmVjYXRlZCBkdWUgdG8gZGlzY292ZXJlZDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3J5cHRvZ3JhcGhpYyB3ZWFrbmVzc2Vz LiZuYnNwOyBBcHBsaWNhdGlvbnMgbXVzdCB0aGVyZWZvcmUgYmUgZGVzaWduZWQgdG88YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuYWJsZSBjcnlwdG9ncmFwaGljIGFn aWxpdHkuPGJyPg0KPGJyPg0KSXMgdGhpcyBtdXN0IG5vcm1hdGl2ZT88YnI+DQo8YnI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1pa2UmZ3Q7IE5vdyBpdOKA mXMgYSDigJxNVVNU4oCdLjwvc3Bhbj48YnI+DQo8YnI+DQpTIDMuMi48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1heSBiZSBubyBuZWVkIHRvIGFwcGx5IGFub3RoZXIg bGF5ZXIgb2YgY3J5cHRvZ3JhcGhpYyBwcm90ZWN0aW9ucyB0bzxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIEpXVC4mbmJzcDsgSW4gc3VjaCBjYXNlcywgdGhlIHVz ZSBvZiB0aGUgJnF1b3Q7bm9uZSZxdW90OyBhbGdvcml0aG0gY2FuIGJlPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJmZWN0bHkgYWNjZXB0YWJsZS4mbmJzcDsgSldU cyB1c2luZyAmcXVvdDtub25lJnF1b3Q7IGFyZSBvZnRlbiB1c2VkIGluPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbiBjb250ZXh0cyBpbiB3aGljaCB0 aGUgY29udGVudCBpcyBvcHRpb25hbGx5IHNpZ25lZDsgdGhlbjxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIFVSTC1zYWZlIGNsYWltcyByZXByZXNlbnRhdGlvbiBh bmQgcHJvY2Vzc2luZyBjYW4gYmUgdGhlIHNhbWUgaW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGJvdGggdGhlIHNpZ25lZCBhbmQgdW5zaWduZWQgY2FzZXMuPGJyPg0K PGJyPg0KSSB0aGluayB5b3UgcHJvYmFibHkgbmVlZCB0byBoYXZlIGEgY2xlYXJlciAmcXVvdDtk b24ndCB1c2Ugbm9uZSBieTxicj4NCmRlZmF1bHQmcXVvdDsgc3RhdGVtZW50IGhlcmUuPGJyPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NaWtlJmd0 OyBBZGRlZCB0d28gc2VudGVuY2VzIHRvIHRoaXMgZWZmZWN0IOKAkyBvbmUgYWJvdXQgY3J5cHRv Z3JhcGhpYyBwcm90ZWN0aW9uIG9mIHRoZSBKV1QgYW5kIG9uZSBhYm91dCDigJxub25l4oCdIG5v dCBiZWluZyBhIGxpYnJhcnkgZGVmYXVsdC48L3NwYW4+PGJyPg0KPGJyPg0KUyAzLjQuPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFQ0RILUVTIGVwaGVtZXJhbCBwdWJs aWMga2V5IChlcGspIGlucHV0cyBzaG91bGQgYmUgdmFsaWRhdGVkPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2NvcmRpbmcgdG8gdGhlIHJlY2lwaWVudCdzIGNob3Nl biBlbGxpcHRpYyBjdXJ2ZS4mbmJzcDsgRm9yIHRoZSBOSVNUPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBwcmltZS1vcmRlciBjdXJ2ZXMgUC0yNTYsIFAtMzg0IGFuZCBQ LTUyMSwgdmFsaWRhdGlvbiBNVVNUIGJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBwZXJmb3JtZWQgYWNjb3JkaW5nIHRvIFNlY3Rpb24gNS42LjIuMy40ICZxdW90O0VD QyBQYXJ0aWFsIFB1YmxpYy1LZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFZhbGlkYXRpb24gUm91dGluZSZxdW90OyBvZiBOSVNUIFNwZWNpYWwgUHVibGljYXRpb24g ODAwLTU2QSByZXZpc2lvbiAzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBbbmlzdC1zcC04MDAtNTZhLXIzXS48YnI+DQo8YnI+DQpJcyB0aGVyZSBhbiBYMjU1MTkgc3Bl Y2lmaWNhdGlvbiBmb3IgSldFPyBJZiBzbywgeW91IHNob3VsZCBwcm9iYWJseTxicj4NCnNwZWNp ZnkgdGhlIGFwcHJvcHJpYXRlIGNoZWNrcy48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1pa2UmZ3Q7IENpdGVkIFtSRkM4MDM3XSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBmb3IgWDI1NTE5IGFuZCBYNDQ4Ljwvc3Bhbj48YnI+DQo8YnI+DQpT IDMuNS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IDMuNS4mbmJzcDsgRW5zdXJlIENyeXB0b2dyYXBo aWMgS2V5cyBoYXZlIFN1ZmZpY2llbnQgRW50cm9weTxicj4NCiZndDsmbmJzcDsmbmJzcDsgPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgS2V5IEVudHJvcHkgYW5k IFJhbmRvbSBWYWx1ZXMgYWR2aWNlIGluIFNlY3Rpb24gMTAuMSBvZiBbUkZDNzUxNV08YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCB0aGUgUGFzc3dvcmQgQ29uc2lk ZXJhdGlvbnMgaW4gU2VjdGlvbiA4Ljggb2YgW1JGQzc1MThdIE1VU1QgYmU8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvbGxvd2VkLiZuYnNwOyBJbiBwYXJ0aWN1bGFy LCBodW1hbi1tZW1vcml6YWJsZSBwYXNzd29yZHMgTVVTVCBOT1QgYmU8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpcmVjdGx5IHVzZWQgYXMgdGhlIGtleSB0byBhIGtl eWVkLU1BQyBhbGdvcml0aG0gc3VjaCBhcyAmcXVvdDtIUzI1NiZxdW90Oy48YnI+DQo8YnI+DQpJ ZiB5b3UgY2FuJ3QgdXNlIHRoZW0gJnF1b3Q7ZGlyZWN0bHkmcXVvdDsgdGhhbiBob3cgc2hvdWxk IHlvdSB1c2UgdGhlbT8gRG8geW91PGJyPg0Kd2FudCB0byBzYXkgYW55dGhpbmcgYWJvdXQgcGFz c3dvcmQgaGFzaGluZyAoYXJnb24sIGV0Yy4pPzxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWlrZSZndDsgQWRkZWQgYSBzZW50ZW5jZSBhYm91 dCBvbmx5IHVzaW5nIHBhc3N3b3JkLWJhc2VkIGVuY3J5cHRpb24gZm9yIGtleSBlbmNyeXB0aW9u LCByYXRoZXIgdGhhbiBjb250ZW50IGVuY3J5cHRpb24uJm5ic3A7IEFsc28gYWRkZWQgYSBzZW50 ZW5jZSBhYm91dCBicnV0ZSBmb3JjZSBhdHRhY2tzLjwvc3Bhbj48YnI+DQo8YnI+DQpTIDMuMTIu PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBvZiBKV1RzLjxicj4NCiZndDsmbmJzcDsmbmJzcDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBHaXZlbiB0aGUgYnJvYWQgZGl2ZXJzaXR5IG9mIEpXVCB1c2FnZSBh bmQgYXBwbGljYXRpb25zLCB0aGUgYmVzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgY29tYmluYXRpb24gb2YgdHlwZXMsIHJlcXVpcmVkIGNsYWltcywgdmFsdWVzLCBo ZWFkZXIgcGFyYW1ldGVycywga2V5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB1c2FnZXMsIGFuZCBpc3N1ZXJzIHRvIGRpZmZlcmVudGlhdGUgYW1vbmcgZGlmZmVyZW50 IGtpbmRzIG9mIEpXVHM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdp bGwsIGluIGdlbmVyYWwsIGJlIGFwcGxpY2F0aW9uIHNwZWNpZmljLjxicj4NCjxicj4NCkkgZ2V0 IHRoYXQgdGhpcyBpcyB0aGUgc3RhdGUgd2UgZmluZCBvdXJzZWx2ZXMgaW4sIGJ1dCBpdCBzZWVt cyBsaWtlPGJyPg0KaXQncyB1bmZvcnR1bmF0ZS4gVGhpcyBtaWdodCBiZSBhIGdvb2QgdGltZSB0 byByZS1lbXBoYXNpemUgdGhlPGJyPg0KcmVjb21tZW5kYXRpb24gZm9yIGV4cGxpY2l0IHR5cGVz IGluIDMuMTEuPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+V2Ugbm93IGV4cGxpY2l0bHkgc2F5IHRoYXQgZXhwbGljaXQgdHlw aW5nIGlzIFJFQ09NTUVOREVEIGZvciBuZXcgSldUIGFwcGxpY2F0aW9ucy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaGFua3MgYWdhaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW2PR00MB030055D02E7E6C55A28533D4F5C60MW2PR00MB0300namp_-- From nobody Fri Nov 9 01:42:31 2018 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 D665C128DFD; Fri, 9 Nov 2018 01:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 HXlaR1SN_AD5; Fri, 9 Nov 2018 01:42:26 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) (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 C783F12777C; Fri, 9 Nov 2018 01:42:25 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gL3J1-0001XC-9B; Fri, 09 Nov 2018 10:42:23 +0100 From: Torsten Lodderstedt Message-Id: <399248B5-A485-456E-B57C-FCD91FE77AC2@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_56FBE047-8C50-4B68-BDCB-0655C6C00116"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Fri, 9 Nov 2018 10:42:19 +0100 In-Reply-To: <154175237636.14370.2795740097592534192@ietfa.amsl.com> Cc: i-d-announce@ietf.org To: oauth References: <154175237636.14370.2795740097592534192@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.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, 09 Nov 2018 09:42:29 -0000 --Apple-Mail=_56FBE047-8C50-4B68-BDCB-0655C6C00116 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 the new revision incorporates the recommendation to use more secure = grant types instead of implicit we agreed to add during the WG session = on Monday. It also has more text around justifications for our = recommendation. Especially, there is a new section 3.6 on access token = injection.=20 I also posted about this topic on LinkedIn = (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-g= rant-torsten-lodderstedt/) and Medium = (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oau= th-implicit-grant-2436ced1c926) kind regards, Torsten.=20 > Am 09.11.2018 um 09:32 schrieb internet-drafts@ietf.org: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-09.txt > Pages : 35 > Date : 2018-11-09 >=20 > Abstract: > This document describes best current security practice for OAuth = 2.0. > It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and covers new threats relevant due to the broader > application of OAuth 2.0. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_56FBE047-8C50-4B68-BDCB-0655C6C00116 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMDkwOTQyMjBaMC8GCSqGSIb3DQEJBDEiBCCB amr1IbS5UN7ehYRKr6BES/9FsQHsbsO8zG6KXjwVcDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAXc8QIlF3ZWqYbWgXk9cP5tMw v1ymDO8SaVfhiur7ttKphuyn09qLG3TzmlcoHt7XfMPxi4gFjKE2G2GBdqaaJqaG9h3DktxX5dZ9 iqekZ+NiQ/+6jlUMTYDQl/PBQ9zWaJ+xeviXNnY1dclqZEEruLvmuXXaN8n1LdxaOT9JDFIyQFMh QezFCsOBmC5nvd7K/2D+riUNNTLi3c0SUwok+/pXXs6pCznEqbzgtA7ILRPBnMpG7JLAncBcH4J9 xfch327aF4tEnZrtpaVHtX4nhN7Dz31XJ/kI5fwcelMzVEhTFGSvdd4oJ+KYMTpVU/0y5l/VqXqr WRQYrPx2ZFX8rAAAAAAAAA== --Apple-Mail=_56FBE047-8C50-4B68-BDCB-0655C6C00116-- From nobody Fri Nov 9 09:14:47 2018 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 294AB12EB11 for ; Fri, 9 Nov 2018 09:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 Takbrt3HEKmH for ; Fri, 9 Nov 2018 09:14:42 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) (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 D060F128766 for ; Fri, 9 Nov 2018 09:14:41 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gLAMg-0005VM-Cz; Fri, 09 Nov 2018 18:14:38 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EF8C645F-B559-475C-BAEB-AFD3565E3F5F"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Fri, 9 Nov 2018 18:14:37 +0100 In-Reply-To: <9829E15A-416C-489E-A48D-58B771F6FFDA@alkaline-solutions.com> Cc: Tomek Stojecki , oauth To: David Waite References: <710899611.302780.1541675954453@mail.yahoo.com> <9829E15A-416C-489E-A48D-58B771F6FFDA@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 09 Nov 2018 17:14:45 -0000 --Apple-Mail=_EF8C645F-B559-475C-BAEB-AFD3565E3F5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 08.11.2018 um 22:59 schrieb David Waite = : >=20 > PCKE does not resolve any known code injection attacks for SPA public = clients. It can be utilized to detect code injection at the redirect between AS = and client. The PKCE verifier is bound to user agent that initiated the = corresponding request. The AS binds the code to the respective PCKE = challenge. If a code is stolen and injected at a different user agent, = the PKCE verifier check will fail at the AS (because the client will use = the wrong PKCE verifier). =20 = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.= 5 --Apple-Mail=_EF8C645F-B559-475C-BAEB-AFD3565E3F5F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMDkxNzE0MzdaMC8GCSqGSIb3DQEJBDEiBCB4 jlcAIXl/4CFzAhl94Sr0XYIUIScxqRbDoB3K3T6qOzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAntI6wxhDoOR1kbvj963zVi2O N2W9uFNaCsRvdIvkRZi7o3ovFmq2BUrkQ5+mgsKtyXjVVGfus7RqJrpmsM+Irt6cL+CjRdE7SmAs UbwTGHNLcHwFlX1xGwlflhrmAqyHv9ZTXvoxVSS6jNvMeVDiTZ8e7kzk9OHM0h9xTEupy4dPnnzd RFzPeb0LJS3+EfaUsLBbY7LMIE51vkWtSYrVW8UJhzer1JM9ktQxuKNL8Dkb9VB4b5Pczmy12BL1 sDkMkxPkPxHLfgxmALqMVKnEbY7jyaKio1TZ8OsmLUe+qPQvH7cxBpdEUlaHF3/Hflw56N0OB2Aj 4KiQr7ru4fNKigAAAAAAAA== --Apple-Mail=_EF8C645F-B559-475C-BAEB-AFD3565E3F5F-- From nobody Fri Nov 9 09:27:21 2018 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 EE8A9130DC0 for ; Fri, 9 Nov 2018 09:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 mzfADJflL5HJ for ; Fri, 9 Nov 2018 09:27:18 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 988D0128766 for ; Fri, 9 Nov 2018 09:27:18 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id r11-v6so2737175wmb.2 for ; Fri, 09 Nov 2018 09:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CR1H+zqYpOU707gqnmoZyWSh3jkFUAI12BtJVWGcquE=; b=Icqsenv+R9AnuZGHvmkps/YrVoI4XLAe+xNKo0kyP8iO8pWS2q5XDw2zHc6NDW8x4m Jv2PoR+H0GYx49bG0ho6D6+vhbKsaATULYqqhst+WqCGkdtzIT5X/fw4EnGCVuu5WAQb TUt86AsXc1e/HV1f7A0QZGSiBIFfkSEfYxnGlB7Y5bzjfkttr8lznK39Z/4m2DWijDEa RtD0NQ18V2yPfVa2OJ4peo73s9k1Cwljem63L0H5DpxIwwBmriDQn7tewHBmuGJj5K9r xKw/lVlB/wLszYjHcyeQQvGUQ229puhcA7Usq83iw6yfgltLhV2EYV1QzBbhcpDZ4hYE AvUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CR1H+zqYpOU707gqnmoZyWSh3jkFUAI12BtJVWGcquE=; b=KLX1FKtG2M1shv3E2pTsd1sOAJNtGuy6EU7LLiJtCaOJpLuJ63fpKD02YK//+CiUCq UzUo/TEAh/S3FpM6OIag13xQhHcL38lWi4HNObqxO5LDiV9vDlRcJu6CFywG8ACSgjez SsTYZnlQSYoK5vnLBwBe5jLA0prLltzYHPIFjOgx6gznESUjlBjvihInJAMvaLA+ux+D 1J1jpnFRYNzqjslXpopmAwXjT34xORcniyqYu/2RALyMW11nE1j9Je5p/N/G6TpbrUL8 /HW6izhJP8SrTrAyRcxtCnMsw531Kt/38TGa4djiyDPq+cBQZlzN72YROZuaQKylpW0/ L16g== X-Gm-Message-State: AGRZ1gI3ZOetp8HTzxGzadZb+FOehz06srO+ao1J9IdXRjEpw+0hqrpQ uoIiLmUTErcpa3cEA0SxbtA2Gw== X-Google-Smtp-Source: AJdET5fb1NZdCNuIy4CNvWW7cbrHVUW+tt6O9gSplif54q+R4yjxhCyKmjVq7zqTNugP1tbXOt6ycQ== X-Received: by 2002:a1c:58c5:: with SMTP id m188-v6mr183580wmb.85.1541784436817; Fri, 09 Nov 2018 09:27:16 -0800 (PST) Received: from [192.168.78.139] (glasgow.emobix.co.uk. [87.117.93.88]) by smtp.gmail.com with ESMTPSA id h189-v6sm4861442wma.10.2018.11.09.09.27.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 09:27:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Joseph Heenan In-Reply-To: <399248B5-A485-456E-B57C-FCD91FE77AC2@lodderstedt.net> Date: Fri, 9 Nov 2018 17:27:14 +0000 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <062837A8-2737-482E-A304-9B7065D73BCD@authlete.com> References: <154175237636.14370.2795740097592534192@ietfa.amsl.com> <399248B5-A485-456E-B57C-FCD91FE77AC2@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.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, 09 Nov 2018 17:27:21 -0000 Hi Torsten, A few comments having just read this afresh: 2.1: 'Clients SHALL avoid=E2=80=99 - is that normatively different to = =E2=80=99SHOULD=E2=80=99 given it appears to be permitted? I find it a little hard to understand exactly what "avoid any redirects = or forwards which can be parameterized by URI query parameters=E2=80=9D = means (particularly as it comes directly after a paragraph on the = redirect_uri and I initially thought it was talking about that. Perhaps = something along the lines of =E2=80=9Cavoid forwarding the user=E2=80=99s = browser to a value from a uri query parameter=E2=80=9D might be clearer. " Clients SHALL ensure to only process =E2=80=9C could just be written = =E2=80=98Client SHALL only process=E2=80=9D I think. 2.1.1: "Authorization servers SHALL consider the=E2=80=9D - is =E2=80=99SHALL = consider=E2=80=99 different to =E2=80=99SHOULD=E2=80=99? Or does it mean = something like =E2=80=9CSHALL implement at least one countermeasure from = <=E2=80=A6>=E2=80=9D. 3.2.4: This says "Authorization codes SHOULD be invalidated by the AS after = their first use at the token endpoint=E2=80=9D. https://tools.ietf.org/html/rfc6749#section-10.5 says: "Authorization codes MUST be short lived and single-use.=E2=80=9D. Does this "MUST be single-use=E2=80=9D not effectively already require = the code is invalidated after first use? If so why downgrade this to a = =E2=80=9CSHOULD=E2=80=9D? Cheers, Joseph > On 9 Nov 2018, at 09:42, Torsten Lodderstedt = wrote: >=20 > Hi all,=20 >=20 > the new revision incorporates the recommendation to use more secure = grant types instead of implicit we agreed to add during the WG session = on Monday. It also has more text around justifications for our = recommendation. Especially, there is a new section 3.6 on access token = injection.=20 >=20 > I also posted about this topic on LinkedIn = (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-g= rant-torsten-lodderstedt/) and Medium = (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oau= th-implicit-grant-2436ced1c926) >=20 > kind regards, > Torsten.=20 >=20 >> Am 09.11.2018 um 09:32 schrieb internet-drafts@ietf.org: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol WG of the = IETF. >>=20 >> Title : OAuth 2.0 Security Best Current Practice >> Authors : Torsten Lodderstedt >> John Bradley >> Andrey Labunets >> Daniel Fett >> Filename : draft-ietf-oauth-security-topics-09.txt >> Pages : 35 >> Date : 2018-11-09 >>=20 >> Abstract: >> This document describes best current security practice for OAuth = 2.0. >> It updates and extends the OAuth 2.0 Security Threat Model to >> incorporate practical experiences gathered since OAuth 2.0 was >> published and covers new threats relevant due to the broader >> application of OAuth 2.0. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09 >> = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-09= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Nov 9 10:44:27 2018 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 2298E12D4EE for ; Fri, 9 Nov 2018 10: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, HTML_MESSAGE=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 tucWttZ1sIuB for ; Fri, 9 Nov 2018 10:44:24 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id F3C20128CF3 for ; Fri, 9 Nov 2018 10:44:23 -0800 (PST) Received: from [IPv6:2601:282:202:b210:31f6:1925:965a:44cc] (unknown [IPv6:2601:282:202:b210:31f6:1925:965a:44cc]) by alkaline-solutions.com (Postfix) with ESMTPSA id 18B5D31689; Fri, 9 Nov 2018 18:44:23 +0000 (UTC) From: David Waite Message-Id: <14BB75BB-F650-408D-8359-B25FA4E66DC9@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1FAE800-51DB-4D16-8BDF-8420562A3596" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 9 Nov 2018 11:44:22 -0700 In-Reply-To: Cc: Aaron Parecki , oauth To: Hans Zandbelt References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 09 Nov 2018 18:44:26 -0000 --Apple-Mail=_A1FAE800-51DB-4D16-8BDF-8420562A3596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Hans, I hope it is acceptable to reply to your message on-list. Others could correct me if I am wrong, but I believe the purpose of this = document is to recommend uses of other OAuth/OIDC specifications, not to = include its own technologies. In terms of being another spec to be referenced, I think it would be = useful but I wonder hypothetically how to best write that specification. = This method seems to be relying on standards-defined tokens and = converting them to an application server session, which isn=E2=80=99t = defined by behavior other than HTTP cookies. The session info hook then = lets you use those proprietary session tokens to retrieve the access/id = token. As such, it is closer to an architecture for implementing a client - as = a confidential client backend with an associated SPA frontend that needs = to make OAuth-protected calls. It is not describing the communication = between existing OAuth roles, such as between the client and AS. There=E2=80=99s obvious value here, and it's one of several = architectures for browser-based apps using a confidential client rather = than a public one (another example being a reverse proxy which maps = remote OAuth endpoints into local, session-token-protected ones). I = personally am just not sure how you would define the communication = between back-end and front-end portions of the client in these = architectures as a standard within OAuth. -DW > On Nov 6, 2018, at 3:03 AM, Hans Zandbelt = wrote: >=20 > Hi Aaron, DW, >=20 > About draft-parecki-oauth-browser-based-apps: > would you consider including a recommendation about and the = standardization of a "session info" endpoint (I'm open for better naming = ;-)) as described in: > = https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-pa= ge-applications/ = >=20 > this approach is not just something that I cooked up; it is based on = real world requests & deployments at Netflix and OAth. >=20 > Let me know what you think, >=20 > Hans. >=20 > On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig = > wrote: > Hi all, >=20 > Today we were not able to talk about = draft-parecki-oauth-browser-based-apps-00, which describes "OAuth 2.0 = for Browser-Based Apps". >=20 > Aaron put a few slides together, which can be found here: > = https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-= oauth-2-for-browser-based-apps-00.pdf = >=20 > Your review of this new draft is highly appreciated. >=20 > Ciao > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > --=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu --Apple-Mail=_A1FAE800-51DB-4D16-8BDF-8420562A3596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Hans, I hope it is acceptable to reply to your message on-list.

Others could correct me = if I am wrong, but I believe the purpose of this document is to = recommend uses of other OAuth/OIDC specifications, not to include its = own technologies.

In terms of being another spec to be referenced, I think it = would be useful but I wonder hypothetically how to best write that = specification. This method seems to be relying on standards-defined = tokens and converting them to an application server session, which = isn=E2=80=99t defined by behavior other than HTTP cookies. The session = info hook then lets you use those proprietary session tokens to retrieve = the access/id token.

As such, it is closer to an architecture for implementing a = client - as a confidential client backend with an associated SPA = frontend that needs to make OAuth-protected calls. It is not describing = the communication between existing OAuth roles, such as between the = client and AS.

There=E2=80=99s obvious value here, and it's one of several = architectures for browser-based apps using a confidential client rather = than a public one (another example being a reverse proxy which maps = remote OAuth endpoints into local, session-token-protected ones). I = personally am just not sure how you would define the communication = between back-end and front-end portions of the client in these = architectures as a standard within OAuth.

-DW

On Nov = 6, 2018, at 3:03 AM, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:

Hi = Aaron, DW,

About draft-parecki-oauth-browser-based-apps:
would you consider including a recommendation about and the = standardization of a "session info" endpoint (I'm open for better naming = ;-)) as described in:
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-fo= r-single-page-applications/

this approach is not just something = that I cooked up; it is based on real world requests & deployments = at Netflix and OAth.

Let me know what you think,

Hans.

On = Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi all,

Today we were not able to talk about = draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth = 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-o= auth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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.

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


--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

= --Apple-Mail=_A1FAE800-51DB-4D16-8BDF-8420562A3596-- From nobody Fri Nov 9 12:22:21 2018 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 70DF7127148 for ; Fri, 9 Nov 2018 12:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 qJyVIMf9pO0k for ; Fri, 9 Nov 2018 12:22:16 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7161293FB for ; Fri, 9 Nov 2018 12:22:15 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id o125so3889185qkf.3 for ; Fri, 09 Nov 2018 12:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=GL49slKQXmlZBEVguORDHr7bbrFic3yXjs1faydjMEY=; b=VrQkkpeP9/uhyqz5Gv6aATRRqjMCG6VdhYCx3e8zds7Ahgwz+02yFC23MqE5KLDI8q sh6BE+XyQU3gSRlSPjy6qQ71uh6yomZPsGU20tMkKgdeNRV0NR+3MR430S3zjOcrdkcS A677CX0IVQhg6DpCQZPe8hfxDPZg85U4nfZ8yJbQJMvGWfLydlwvgkFiKunN1UtevdyK Nu1rzHI7L9Qti5vvsqZVyqLAWL8yMQg/TEYc+GV2o07g/K88Y7kvhIXaOJ89Eily6ZMm Zsl/oiU+/MDgkKHDkQLWrQRKzbTU9EdwX7RNZkRBNDcTmdG/iAwmJq3BThECS+PLChzi oHlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=GL49slKQXmlZBEVguORDHr7bbrFic3yXjs1faydjMEY=; b=r7Slv9spGnC9sOzyN6uQ3UqxYCC+vlUgBXVujeMt5MLLrRutqAKA7HW1sjC2JQxLsD hIbnN0AFx6wMtPho6GAQGQaqT/Ib/SdSO7Md0C0w3K9S85reWhPsyv8h5i3PnuQrbWeV 1eumkMX2sXi+u6tfJrkplYsUPRcs0CNKgFiV3hZoMg+eRt9u2skyF3kRwEim4QVb5FIC XOUTQOuHD8fDXXSlvyzDuHOmvAFicApy5NYvuNhAb/Ln+pdSD412Ejrwx1Z4oOhr7Leq DZ0ld4f0Hg5u2XYOl90EBpw7gkH8Sw12Ox2RN8QM3Y4dgTKrqoDuw8vDtr1EtYrz7XHY heYw== X-Gm-Message-State: AGRZ1gIjpRswgrDjJnTyneePfB3FwjSH7p3Ml6Nxhf7v9TsSnU4uxWDh ggEejLq9yy31ruweW68CL6Q= X-Google-Smtp-Source: AJdET5creIQ7CM6bIrKcyImfWCZQwdIrNnaa6ahOo5P26DuImMv5CaU6YsvZeVsFdeUjfXK+NV5ZVA== X-Received: by 2002:a0c:9359:: with SMTP id e25mr10214616qve.203.1541794934653; Fri, 09 Nov 2018 12:22:14 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id o42sm5022227qtc.90.2018.11.09.12.22.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 12:22:13 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_23549239.598800389680" MIME-Version: 1.0 Date: Fri, 09 Nov 2018 15:22:11 -0500 Message-ID: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> From: "Brock Allen" To: "Aaron Parecki" , "Hannes Tschofenig" Cc: "" In-Reply-To: References: User-Agent: Mailbird/2.5.23.0 X-Mailbird-ID: 9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 09 Nov 2018 20:22:20 -0000 ------=_NextPart_23549239.598800389680 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello all -- I also have some thoughts/feedback on this document. Personally I agree with some of the conclusions, but as it stands I think t= he document's main conclusion that code flow is the real solution is not su= fficiently convincing. I would like to see a brief summary of the current concerns (much like RFC8= 252 does) so we have context before the document just jumps to what a best = practice is. The reason I bring this up is that generally the concept of "b= est practice" is meaningless without context. I think stating that code flo= w is best practice without motivation seems somewhat "cart before the horse= ". I think just a short blurb about the desire to eliminate the access token f= rom being delivered in the URL, and the current attacks against doing so wo= uld be helpful (showing attacks is super important in making this "real"). = I guess this would make the most sense in section "4. Overview" prior to th= e list of "best practice" conclusions. Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into= specifics, but many of the points seem confused (or at least confuse me) a= nd/or the conclusion that code flow is the only approach seems misleading. = For example: "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required= according to Section 6), so clients and authorization servers MUST NOT use= the Implicit Flow for browser-based apps." This is specious. The threat is the token is in the URL, not that implicit = clients can't use PKCE. So perhaps the document should explain the variety = of mitigations, not just one? While code flow is one, using CSP and the bro= wser history API to remove the token from the URL is another. Elsewhere in = the document the use of CSP is a "SHOULD". That's great, but using CSP can = be and is used today, and doesn't necessitate code flow. "OAuth 2.0 provides no mechanism for a client to verify that an access toke= n was issued to it, which could lead to misuse and possible impersonation a= ttacks if a malicious party hands off an access token it retrieved through = some other means to the client." Sure, but OIDC does provide a mitigation for this (even with implicit). So = perhaps it should be offered as a suggestion as well? I did see the point t= hat with code flow id_token validation could instead rely upon the token en= dpoint, but the client still has other work to do (namely around PKCE). Tha= t's just trading one bit of work for another, not a clear cut reason to use= one flow over another. "Supporting the implicit flow requires additional code, more upkeep and und= erstanding of the related security considerations, while limiting the autho= rization server to just the authorization code flow simplifies the implemen= tation." As offered by someone else already, this is opinion and not objective. IMO,= this diminishes the potential of this document. "If the JavaScript application gets wrapped into a native app, then [RFC825= 2] also requires the use of the authorization code flow." Given how many browser dependencies SPA apps tend to have, is this really c= ommon? In all my years building both, I've never seen it. "Historically, the Implicit flow provided an advantage to single-page apps = since JavaScript could always arbitrarily read and manipulate the fragment = portion of the URL without triggering a page reload. Now with the Session H= istory API (described in "Session history and navigation" of [HTML]), brows= ers have a mechanism to modify the path component of the URL without trigge= ring a page reload, so this overloaded use of the fragment portion is no lo= nger needed." While this section is intended to indicate the existence of the history API= is a reason to move away from implicit, it's also what can be used to prot= ect token exposure in the URL, which I think weakens its point. As a sectio= n, to me, it seems unnecessary. The push to a single flow (for consistency) is a marginal motivation, and I= agree with that theme in the document. Much of the other guidance in this document is already covered elsewhere (e= .g. RFC6819). I don't know if the goal of the document is to reproduce thos= e existing recommendations (as a contrast RFC8252 does not and mainly focus= es on what's unique to the native scenario). I can't quite tell the real motivation for this "best practice" document. I= f it's trying to give guidance for browser-based JS apps, then perhaps it s= hould be enhanced to give guidance for the existing implicit flow, as well = as suggesting code flow? But if the real motivation is just to kill off imp= licit flow then more needs to be done, IMO. Finally, my last real concern (which is why I'm pushing back so much on cod= e flow), is that this implies refresh tokens in the browser. My sense is th= at given the danger of this, the original OAuth2 RFC (via the implicit flow= ) was designed to limit the client's ability to obtain new access tokens ba= sed on the user's authentication session at the AS (via a cookie). Allowing= refresh tokens now means that a successful attacker has unfettered ability= to do this (beyond just an access token's lifetime). And yes, CSP is menti= oned as a mitigation to protect the refresh token, but it was already neces= sary to protect the access token, so CSP is not the only mitigation. What's= missing is strong guidance for token servers to provide mechanisms to limi= t the lifetime of refresh tokens for these high risk client scenarios. I ha= ve a suspicion that many existing token servers do not have such features, = and this would imply more features mandated for the token servers (beyond P= KCE for example). Having said all of these things, I am all for using code flow. I just would= like there to be more clear rationale. My comments above were the various = counter arguments I was thinking while reading this document, and given how= many of these I came up with I was left feeling unconvinced (as I already = mentioned). Thanks for reading this far, and thanks for putting forth the document. -Brock On 11/6/2018 5:14:05 AM, Aaron Parecki wrote: Thanks Hannes, Since I wasn't able to give an intro during the meeting today, I'd like to = share a little more context about this here as well. At the Internet Identity Workshop in Mountain View last week, I led a sessi= on to collect feedback on recommendations for OAuth for browser based apps.= During the session, we came up with a list of several points based on the = collective experience of the attendees. I then tried to address all those p= oints in this draft. The goal of this is not to specify any new behavior, but rather to limit th= e possibilities that the existing OAuth specs provide, to ensure a secure i= mplementation in browser based apps. Thanks in advance for your review and feedback! Aaron Parecki aaronpk.com [http://aaronpk.com] On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig wrote: Hi all, Today we were not able to talk about draft-parecki-oauth-browser-based-apps= -00, which describes=C2=A0 "OAuth 2.0 for Browser-Based Apps". Aaron put a few slides together, which can be found here: https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-o= auth-2-for-browser-based-apps-00.pdf [https://datatracker.ietf.org/meeting/= 103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf] Your review of this new draft is highly appreciated. 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. _______________________________________________ OAuth mailing list OAuth@ietf.org [mailto:OAuth@ietf.org] https://www.ietf.org/mailman/listinfo/oauth [https://www.ietf.org/mailman/l= istinfo/oauth] -- ---- Aaron Parecki aaronparecki.com [http://aaronparecki.com] @aaronpk [http://twitter.com/aaronpk] _______________________________________________ OAuth mailing list OAuth@ie= tf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_23549239.598800389680 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A Hello all --

I also have some thoughts/feedback on this document.

Personal= ly I agree with some of the conclusions, but as it stands I think the docum= ent's main conclusion that code flow is the real solution is not sufficient= ly convincing.

I would like to see a brief summary of the current co= ncerns (much like RFC8252 does) so we have context before the document just= jumps to what a best practice is. The reason I bring this up is that gener= ally the concept of "best practice" is meaningless without context. I think= stating that code flow is best practice without motivation seems somewhat = "cart before the horse".

I think just a short blurb about the desire= to eliminate the access token from being delivered in the URL, and the cur= rent attacks against doing so would be helpful (showing attacks is super im= portant in making this "real"). I guess this would make the most sense in s= ection "4. Overview" prior to the list of "best practice" conclusions.
<= br>Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get i= nto specifics, but many of the points seem confused (or at least confuse me= ) and/or the conclusion that code flow is the only approach seems misleadin= g. For example:

"The Implicit Flow cannot be protected by PKCE [RFC7= 636] (which is required according to Section 6), so clients and authorizati= on servers MUST NOT use the Implicit Flow for browser-based apps."

T= his is specious. The threat is the token is in the URL, not that implicit c= lients can't use PKCE. So perhaps the document should explain the variety o= f mitigations, not just one? While code flow is one, using CSP and the brow= ser history API to remove the token from the URL is another. Elsewhere in t= he document the use of CSP is a "SHOULD". That's great, but using CSP can b= e and is used today, and doesn't necessitate code flow.

"OAuth 2.0 p= rovides no mechanism for a client to verify that an access token was issued= to it, which could lead to misuse and possible impersonation attacks if a = malicious party hands off an access token it retrieved through some other m= eans to the client."

Sure, but OIDC does provide a mitigation for th= is (even with implicit). So perhaps it should be offered as a suggestion as= well? I did see the point that with code flow id_token validation could in= stead rely upon the token endpoint, but the client still has other work to = do (namely around PKCE). That's just trading one bit of work for another, n= ot a clear cut reason to use one flow over another.

"Supporting the = implicit flow requires additional code, more upkeep and understanding of th= e related security considerations, while limiting the authorization server = to just the authorization code flow simplifies the implementation."

= As offered by someone else already, this is opinion and not objective. IMO,= this diminishes the potential of this document.

"If the JavaScript = application gets wrapped into a native app, then [RFC8252] also requires th= e use of the authorization code flow."

Given how many browser depend= encies SPA apps tend to have, is this really common? In all my years buildi= ng both, I've never seen it.

"Historically, the Implicit flow provid= ed an advantage to single-page apps since JavaScript could always arbitrari= ly read and manipulate the fragment portion of the URL without triggering a= page reload. Now with the Session History API (described in "Session histo= ry and navigation" of [HTML]), browsers have a mechanism to modify the path= component of the URL without triggering a page reload, so this overloaded = use of the fragment portion is no longer needed."

While this section= is intended to indicate the existence of the history API is a reason to mo= ve away from implicit, it's also what can be used to protect token exposure= in the URL, which I think weakens its point. As a section, to me, it seems= unnecessary.

The push to a single flow (for consistency) is a margi= nal motivation, and I agree with that theme in the document.

Much of= the other guidance in this document is already covered elsewhere (e.g. RFC= 6819). I don't know if the goal of the document is to reproduce those exist= ing recommendations (as a contrast RFC8252 does not and mainly focuses on w= hat's unique to the native scenario).

I can't quite tell the real mo= tivation for this "best practice" document. If it's trying to give guidance= for browser-based JS apps, then perhaps it should be enhanced to give guid= ance for the existing implicit flow, as well as suggesting code flow? But i= f the real motivation is just to kill off implicit flow then more needs to = be done, IMO.

Finally, my last real concern (which is why I'm pushin= g back so much on code flow), is that this implies refresh tokens in the br= owser. My sense is that given the danger of this, the original OAuth2 RFC (= via the implicit flow) was designed to limit the client's ability to obtain= new access tokens based on the user's authentication session at the AS (vi= a a cookie). Allowing refresh tokens now means that a successful attacker h= as unfettered ability to do this (beyond just an access token's lifetime). = And yes, CSP is mentioned as a mitigation to protect the refresh token, but= it was already necessary to protect the access token, so CSP is not the on= ly mitigation. What's missing is strong guidance for token servers to provi= de mechanisms to limit the lifetime of refresh tokens for these high risk c= lient scenarios. I have a suspicion that many existing token servers do not= have such features, and this would imply more features mandated for the to= ken servers (beyond PKCE for example).

Having said all of these thin= gs, I am all for using code flow. I just would like there to be more clear = rationale. My comments above were the various counter arguments I was think= ing while reading this document, and given how many of these I came up with= I was left feeling unconvinced (as I already mentioned).

Thanks for= reading this far, and thanks for putting forth the document.

-Brock

=0A

On 11/6/2018 5:14:05 AM, Aaron Parecki <= ;aaron@parecki.com> wrote:

Thanks Hannes,

Since I wasn't able to give an intro during= the meeting today, I'd like to share a little more context about this here= as well.

At the Interne= t Identity Workshop in Mountain View last week, I led a session to collect = feedback on recommendations for OAuth for browser based apps. During the se= ssion, we came up with a list of several points based on the collective exp= erience of the attendees. I then tried to address all those points in this = draft.

The goal of this = is not to specify any new behavior, but rather to limit the possibilities t= hat the existing OAuth specs provide, to ensure a secure implementation in = browser based apps.

Than= ks in advance for your review and feedback!

Aaron Parecki



On Tue,= Nov 6, 2018 at 10:55 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi all,
=0A
=0AToday we were not able to talk = about draft-parecki-oauth-browser-based-apps-00, which describes  "OAu= th 2.0 for Browser-Based Apps".
=0A
=0AAaron put a few slides togethe= r, which can be found here:
=0Ahttps://datatracker.ietf.org/m= eeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-= 00.pdf
=0A
=0AYour review of this new draft is highly appreciated= .
=0A
=0ACiao
=0AHannes
=0AIMPORTANT NOTICE: The contents of th= is email and any attachments are confidential and may also be privileged. I= f you are not the intended recipient, please notify the sender immediately = and do not disclose the contents to any other person, use it for any purpos= e, or store or copy the information in any medium. Thank you.
=0A
=0A= _______________________________________________
=0AOAuth mailing list=0AOAuth@ietf.org<= br>=0Ahttps://www.ietf.org/mailman/listinfo/oauth
= =0A
--
----
=0A__________________________________= _____________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/= mailman/listinfo/oauth=0A
=0A = =0A
------=_NextPart_23549239.598800389680-- From nobody Fri Nov 9 14:07:40 2018 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 A1CAB1276D0 for ; Fri, 9 Nov 2018 14:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 gnt9CvbwU1Fr for ; Fri, 9 Nov 2018 14:07:36 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEC21200D7 for ; Fri, 9 Nov 2018 14:07:35 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id r71so4368654qkr.10 for ; Fri, 09 Nov 2018 14:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=OZ+1w184oKEMgpErshFk5zgFHYiSphSKseFSs+ahiqQ=; b=d/5DH70RS/LZ+TgdQ1eBimpMnBwq0L8Z1kc/ygxxTHwzoouFTSTMO/nc4LvLJ58UAU 5YEp8NMs9HbIQdq8DidbJ1O9SLkXD2kWfA0aaPXvZAc3WPVyQ9iUHt5kEPfNpXNn1Cio 0Q0T4Ztid78z8SoeeH2IkDol0uRWearbE/BzLzb0qwAaMdfP99YL9zn1/EMc58QbYK3P tSV0EHCEd3Ba6pmAb4ZUXvoyheTrvPkaxQaitmDiVil0MzSidwxgN1XWv5Q0ebY2/CFA F7aJdJ7zBTMAmMPHI74uh+CWcE+EA3saAim8gghM8JKTTDZ8n47c3OwtTq2hPCVOhbak IwYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=OZ+1w184oKEMgpErshFk5zgFHYiSphSKseFSs+ahiqQ=; b=WEN+skUvqc6svkV6cp1bt+hy3XnguYTuI8sd/YaAAZbTg3Ocntt/puLAcRFfiW893x EYIINuo6b2D7iTZgYqEpPTD/+2IsJgCNmBMW9diCJvlfwqdhfZCwPVQZZGSBdrRwc5X5 vFFOr4eBxuygmRdvBpC5klttz1NiaJpiulCAy81J7VuX5pBcTbkO/TkiZyBZ14jMegJL hbztfxxemiY2mP1cgP+iNS9ovuiIoiu51FauiQX/4vI2zDsSYaBxK9yELLHkAW5jM0VD 8u3GeuTsdIerPeg/jwuXxY+cHJ27fSHv3wLjylhfza/QSsu5WZc4G3PRT3x9bcDIyJuO PQZQ== X-Gm-Message-State: AGRZ1gJ/ZxemSX2BqhVy0I7KyGqv8xU7ii+lfbIATSZTaAz1nde37ScK pbqEWc5LDlvTlbqadBcu3rU= X-Google-Smtp-Source: AJdET5eRmCN8yaDC7WAcLb1Ma8I9ncaEUWOgw7Q6WMc+t7Cv8w5R+3C8u8UmOcH+Egyuw/lUZGtwqA== X-Received: by 2002:a37:aa0c:: with SMTP id t12mr9849805qke.358.1541801254796; Fri, 09 Nov 2018 14:07:34 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id m61-v6sm4716175qte.30.2018.11.09.14.07.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 14:07:33 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_41506485.559191625583" MIME-Version: 1.0 Date: Fri, 09 Nov 2018 17:07:31 -0500 Message-ID: <6339eebc-fcdc-4cd5-a129-1d950f4d7e45@getmailbird.com> From: "Brock Allen" To: "Aaron Parecki" , "Hannes Tschofenig" Cc: "" In-Reply-To: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> User-Agent: Mailbird/2.5.23.0 X-Mailbird-ID: 6339eebc-fcdc-4cd5-a129-1d950f4d7e45@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 09 Nov 2018 22:07:39 -0000 ------=_NextPart_41506485.559191625583 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0Finally, my last real concern (which is why I'm pushing back so much= on code flow), is that this implies refresh tokens in the browser. My sens= e is that given the danger of this, the original OAuth2 RFC (via the implic= it flow) was designed to limit the client's ability to obtain new access to= kens based on the user's authentication session at the AS (via a cookie). A= llowing refresh tokens now means that a successful attacker has unfettered = ability to do this (beyond just an access token's lifetime). And yes, CSP i= s mentioned as a mitigation to protect the refresh token, but it was alread= y necessary to protect the access token, so CSP is not the only mitigation.= What's missing is strong guidance for token servers to provide mechanisms = to limit the lifetime of refresh tokens for these high risk client scenario= s. I have a suspicion that many existing token servers do not have such fea= tures, and this would imply more features mandated for the token servers (b= eyond PKCE for example). And to expand upon this serious concern -- CSP only protects the current pa= ge from things like XSS. It does not protect every other page under your do= main. IOW, your app using/storing refresh tokens (and access tokens) is tru= sting every other page on the domain to also be protected from XSS. At leas= t an access token compromised this way has an expiration, whereas unbounded= refresh tokens won't necessarily. This is why I am pushing for strong guid= ance around refresh token expirations, and this requires the token servers = to implement and enforce this.=C2=A0 So this sort of threat should possibly be used in the document to reinforce= and motivate such guidance. -Brock ------=_NextPart_41506485.559191625583 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;Finally, my last real concern (which is wh= y I'm pushing back so much on code flow), is that this implies refresh toke= ns in the browser. My sense is that given the danger of this, the original = OAuth2 RFC (via the implicit flow) was designed to limit the client's abili= ty to obtain new access tokens based on the user's authentication session a= t the AS (via a cookie). Allowing refresh tokens now means that a successfu= l attacker has unfettered ability to do this (beyond just an access token's= lifetime). And yes, CSP is mentioned as a mitigation to protect the refres= h token, but it was already necessary to protect the access token, so CSP i= s not the only mitigation. What's missing is strong guidance for token serv= ers to provide mechanisms to limit the lifetime of refresh tokens for these= high risk client scenarios. I have a suspicion that many existing token se= rvers do not have such features, and this would imply more features mandate= d for the token servers (beyond PKCE for example).

And to expand upon this serious concern -- CSP only protects the curr= ent page from things like XSS. It does not protect every other page under y= our domain. IOW, your app using/storing refresh tokens (and access tokens) = is trusting every other page on the domain to also be protected from XSS. A= t least an access token compromised this way has an expiration, whereas unb= ounded refresh tokens won't necessarily. This is why I am pushing for stron= g guidance around refresh token expirations, and this requires the token se= rvers to implement and enforce this. 

So this= sort of threat should possibly be used in the document to reinforce and mo= tivate such guidance.

-Brock

=
=0A =0A =
=0A = =0A
------=_NextPart_41506485.559191625583-- From nobody Sun Nov 11 12:08:27 2018 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 D584F12426A for ; Sun, 11 Nov 2018 12:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Lnam92rdtsoc for ; Sun, 11 Nov 2018 12:08:23 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EFB124BAA for ; Sun, 11 Nov 2018 12:08:23 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id a11so2505322otr.10 for ; Sun, 11 Nov 2018 12:08:23 -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=4p1kzpkT6sIGf0/QcRV3Ei4ad6pr11MYIfnQ0dvsN9s=; b=H/y40CHXCv6awNgRFsU5OqVY6E1ofpqHCWMlLFf4fajMPu5ZqC/moWxQ8/y31+ELFJ WL/wQSd75YIjQO98IpVI8JKLHktQMC8Mu1HLYFid45H5jttjCBCb+APnlvHPuQOk8ONh ose7ASuWPyPAd+8XD7Qdo5ql19Nne2mv3KcgblScgc1v3SO54Vw06iqPsLyntrS4BONM QF5wOhXLR0y43p3BSo6BmP6l4LdgigpNQHn2yXdEwXZvSHX5d7vFentMdnEeQojHfOTx +vUWVT2jfi29os4dSRHegGRsDZ1U5amrGttP9Fq7JCA8oO7S3UR0WCzI9JgTZIP3WGlT WLMw== 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=4p1kzpkT6sIGf0/QcRV3Ei4ad6pr11MYIfnQ0dvsN9s=; b=HzZI8QvbpCvxI+jsYd2vtmfWAwdVsSiwHDCQJ8pTIqYBoKQTyNiAz0+BykWkBIRT9e og1fd4NSH9ngwIzddr0VOJldUqscArQnk83FU41FfDxiG3whFHDxSOibGKq3eOJSQFC5 U2SO16USfwB6xpKXK5m459meNFlMcx2LmbwEzPHQ2rOEY1Kq4aOMB03NdAT1yUVb47P7 2sWtPdZ5M/1SLVvlDpVcuZ7NfNJHx4dgY+Uwe6qu/X1wjrEE5udH9FihTa8HxDmLNVUX JMxKtqO5nGiD7zLTO4xurR2iT+LhnXgf3eb/E8fCgCv1F4kyyzIAjx7G8v2Wjb/PitQP HYUg== X-Gm-Message-State: AGRZ1gKmdvBXPk65avkQsG7NxeknHWIPq2zsNCHR/MymXmWSqKxB9p7v jq5j6fwwt032X6ATUoEHxioVuuttPY/gmwKiBrI= X-Google-Smtp-Source: AJdET5eosjlSmarFhiXWJn8hlxChQwKxFHiArjwHE8G3M1cS4SVy+r4y9FsLoWy8wo3hKWtl61hpRSWQAC17YAK5ruk= X-Received: by 2002:a9d:44d0:: with SMTP id p16mr9948603otg.235.1541966902801; Sun, 11 Nov 2018 12:08:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Omer Levi Hevroni Date: Sun, 11 Nov 2018 22:08:11 +0200 Message-ID: To: Dick Hardt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f39d4057a6925e8" Archived-At: Subject: Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant 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, 11 Nov 2018 20:08:26 -0000 --0000000000007f39d4057a6925e8 Content-Type: text/plain; charset="UTF-8" Ok, let me try. At the company where I work, we have an app that is used by our users. We want to have a way to authenticate the requests from the application, without requiring the user to perform any interactive login flow. I described it more in-depth in the blog post - https://blog.solutotlv.com/userless-mobile-authentication/ Does this help? Also, thank you for your time and feedback. I appreciate it! On Fri, Nov 9, 2018 at 1:54 AM Dick Hardt wrote: > More detail on the scenario would help. > > On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni wrote: > >> Yes, that is correct. >> I'm sorry the confusion, I think this confusion is built into >> oauth framework itself. >> You understood well the scenario - I have an application running on an >> untrusted device in an untrusted network. I looked for a way to >> authenticate the requests from the device to AS. >> Does it make more sense now? >> >> On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt wrote: >> >>> Omar >>> >>> As promised, I have reviewed the ID[1] you posted. I'm confused in the >>> Motivation by the references to authentication, as OAuth is about >>> authorization. >>> >>> Perhaps you can post to the list the use case you are trying to solve >>> for? I can infer aspects, but don't fully understand it. >>> >>> From what I can understand though, there is software running in a >>> trusted device that would like to get an access token, and an OTP is part >>> of how the device is authenticating to the AS. This seems like a 2 legged >>> OAuth flow as there is no user involved directly, and it seems you have a >>> means for the client to authenticate to the AS using an OTP. Am I guessing >>> correctly? >>> >>> /Dick >>> >>> [1] >>> https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 >>> >>> >>> --0000000000007f39d4057a6925e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, let me try.

At the= company where I work, we have an app that is used by our users. We want to= have a way to authenticate the requests from the application, without requ= iring the user to perform any interactive login flow. I described it more i= n-depth in the blog post -=C2=A0https://blog.solutotlv.com/userless-mobile-auth= entication/

Does=C2=A0this help?
Also, thank you for your time and feedback. I appreciate it!

On Fri, Nov = 9, 2018 at 1:54 AM Dick Hardt <d= ick.hardt@gmail.com> wrote:
=
More detail on the scenario would help.
<= div>
On Fri, Nov 9, 2018 at = 2:04 AM Omer Levi Hevroni <omerlh@gmail.com> wrote:
Yes, that is correct.=C2=A0
I'm sorry th= e confusion, I think this confusion is built into oauth=C2=A0framework itse= lf.
You understood well the scenario - I have an application runn= ing on an untrusted device in an untrusted network. I looked for a way to a= uthenticate the requests from the device to AS.
Does it make more= sense now?

On T= hu, Nov 8, 2018 at 12:42 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Omar

As promised, I have reviewed the ID= [1] you posted. I'm confused in the Motivation by the references to aut= hentication, as OAuth is about authorization.

Perhaps you can post to the list the use case you are t= rying to solve for? I can infer aspects, but don't fully understand it.= =C2=A0

From what I can und= erstand though, there is software running in a trusted device that would li= ke to get an access token, and an OTP is part of how the device is authenti= cating to the AS. This seems like a 2 legged OAuth flow as there is no user= involved directly, and it seems you have a means for the client to authent= icate to the AS using an OTP. Am I guessing correctly?

--0000000000007f39d4057a6925e8-- From nobody Mon Nov 12 05:19:07 2018 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 EC0F1130E2D for ; Mon, 12 Nov 2018 05:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4EpbSSzA2LVR for ; Mon, 12 Nov 2018 05:19:03 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2553F130E26 for ; Mon, 12 Nov 2018 05:19:03 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id e26so4357232lfc.2 for ; Mon, 12 Nov 2018 05:19: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=knrTIjhdwO89z+NtATlDqiWN/dvCYSSh0k+D9Qggm2U=; b=Kn/Ff4052cZROU4w+sSllI0KVoNJszBb+AWvw2G36FHN8adYmY7BKpEeTtA4kO5n7A DM4V4LM/ikqZSlGfO3mMcRTBKgm46/nxJ2ieNSMozKQ8wOX/IVo6UE8ojjxOCLkG6c7m Rs4Z9KLt9vO/d/OxdEq/hCeDmXliiv3iWFcWoq7UJUgqZGwGWqSFRpNyEZdqc0kxX1NK 0xNluHCNsuCQZe0ryk5IT9V8glBFfI4risrjYA5Z8is7hwnnIn0nPa/BzZe5OdN5A68P 3LLG9kL9LwozUClJ36kcUe8kyyBpgCiEst2eN32RUghCoMB5dD3+uDtM7mCCg7vbiJ9K +vbg== 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=knrTIjhdwO89z+NtATlDqiWN/dvCYSSh0k+D9Qggm2U=; b=BrVz1kaHeyfOT9YnjvKybL+O+0D2bYnZw+2CHKGuzRHgmbzIUmjNls0Ek+pqI9LfCk Mt/zwe42j1FcBvxCz6/MadIAmMPbEkWjshWX0PA6kOs4+nkj8Y4mtPN4kMcvz7627JAc gxG4XwFrqpTSF4ykll1czuoEiSqPsJBSNjBafi3O3nOEl0ofJuCNgji1Z54HKVYGwbHk PK/JQt6d6fWHo4jLKVItVsf7c9oYUjiVre//NJ4oCUBanvPyQ+9aKn+WeBgpwlOF+xH+ TCmNHJU0KTLLsGf+NWTBVMIiAcElDb963HvyLgpiwQO3GCHXj4idVMv9Rg7yCbQZGdDJ 4iOw== X-Gm-Message-State: AGRZ1gKOZSsZ5EomZ+oyOVpaSD0WZ0SJqEMV45bH0QTHSMBfmsQNxNcF JiWOBxjJcCAioeyzaJ5rhkPW72Db7ZGwMyAtbXA= X-Google-Smtp-Source: AJdET5cDyKjKtVNi2hTgSlOtEH61x5/bcRBRnpUiTukL8oAsoMgcXWclhj6e8Eq0TYg5glsJvmH1bY7n5msGbHJuie8= X-Received: by 2002:a19:6806:: with SMTP id d6mr604204lfc.48.1542028741129; Mon, 12 Nov 2018 05:19:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 12 Nov 2018 20:19:04 +0700 Message-ID: To: Omer Levi Hevroni Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000594ea7057a778b8b" Archived-At: Subject: Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant 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, 12 Nov 2018 13:19:06 -0000 --000000000000594ea7057a778b8b Content-Type: text/plain; charset="UTF-8" I understand better, thanks! >From an OAuth perspective, this is a client credentials grant. You have added some other checks that may or may not help the security profile, but at the core, you have a private key on the device that is the primary credential, and is device oriented. FWIW: there are a number of usability challenges with your approach. The user can't use more than one device. If they change devices, they lose all their data. Also, IMHO, I don't think the private key protections you have in place are a net positive. On Mon, Nov 12, 2018 at 3:08 AM Omer Levi Hevroni wrote: > Ok, let me try. > > At the company where I work, we have an app that is used by our users. We > want to have a way to authenticate the requests from the application, > without requiring the user to perform any interactive login flow. I > described it more in-depth in the blog post - > https://blog.solutotlv.com/userless-mobile-authentication/ > > Does this help? > > Also, thank you for your time and feedback. I appreciate it! > > On Fri, Nov 9, 2018 at 1:54 AM Dick Hardt wrote: > >> More detail on the scenario would help. >> >> On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni >> wrote: >> >>> Yes, that is correct. >>> I'm sorry the confusion, I think this confusion is built into >>> oauth framework itself. >>> You understood well the scenario - I have an application running on an >>> untrusted device in an untrusted network. I looked for a way to >>> authenticate the requests from the device to AS. >>> Does it make more sense now? >>> >>> On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt wrote: >>> >>>> Omar >>>> >>>> As promised, I have reviewed the ID[1] you posted. I'm confused in the >>>> Motivation by the references to authentication, as OAuth is about >>>> authorization. >>>> >>>> Perhaps you can post to the list the use case you are trying to solve >>>> for? I can infer aspects, but don't fully understand it. >>>> >>>> From what I can understand though, there is software running in a >>>> trusted device that would like to get an access token, and an OTP is part >>>> of how the device is authenticating to the AS. This seems like a 2 legged >>>> OAuth flow as there is no user involved directly, and it seems you have a >>>> means for the client to authenticate to the AS using an OTP. Am I guessing >>>> correctly? >>>> >>>> /Dick >>>> >>>> [1] >>>> https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 >>>> >>>> >>>> --000000000000594ea7057a778b8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand better, thanks!

From an OA= uth perspective, this is a client credentials grant. You have added some ot= her checks that may or may not help the security profile, but at the core, = you have a private key on the device that is the primary credential, and is= device oriented.=C2=A0

FWIW: there are a number o= f usability challenges with your approach. The user can't use more than= one device. If they change devices, they lose all their data. Also, IMHO,= =C2=A0 I don't think the private key protections you have in place are = a net positive.



On Mon, Nov 12, 2018 at 3:08 A= M Omer Levi Hevroni <omerlh@gmail.co= m> wrote:
<= div dir=3D"ltr">Ok, let me try.

At the company where I w= ork, we have an app that is used by our users. We want to have a way to aut= henticate the requests from the application, without requiring the user to = perform any interactive login flow. I described it more in-depth in the blo= g post -=C2=A0https://blog.solutotlv.com/userless-mobile-auth= entication/

Does=C2=A0this help?
Also, thank you for your time and feedback. I appreciate it!

On Fri, Nov = 9, 2018 at 1:54 AM Dick Hardt <dick.hardt@gmail.com> wrote:
More detail on the scenario would = help.

On Fr= i, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni <omerlh@gmail.com> wrote:
Yes, that is correct.=C2=A0
I'm sorry the confusion, I think this confusion is built into oauth= =C2=A0framework itself.
You understood well the scenario - I have= an application running on an untrusted device in an untrusted network. I l= ooked for a way to authenticate the requests from the device to AS.
Does it make more sense now?

<= div dir=3D"ltr">On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt <dick.hardt@gmail.com> = wrote:
Omar

As promised, I = have reviewed the ID[1] you posted. I'm confused in the Motivation by t= he references to authentication, as OAuth is about authorization.

Perhaps you can post to the list th= e use case you are trying to solve for? I can infer aspects, but don't = fully understand it.=C2=A0

From what I can understand though, there is software running in a trusted = device that would like to get an access token, and an OTP is part of how th= e device is authenticating to the AS. This seems like a 2 legged OAuth flow= as there is no user involved directly, and it seems you have a means for t= he client to authenticate to the AS using an OTP. Am I guessing correctly?<= /div>

=

--000000000000594ea7057a778b8b-- From nobody Mon Nov 12 15:59:38 2018 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 BD92F130DC2 for ; Mon, 12 Nov 2018 15:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh_4fzGeIpWZ for ; Mon, 12 Nov 2018 15:59:33 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 1C1E0128CE4 for ; Mon, 12 Nov 2018 15:59:33 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id o89so16567620qko.0 for ; Mon, 12 Nov 2018 15:59: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 :cc:content-transfer-encoding; bh=SNfen3buLpO6TC8qH29iHI5/GE8o1lZHOafrIDORN2I=; b=SSrcuXQxMbzqBR8i9P3V258g+EowlsW/LzXCWQnkP6nenef6+5iL6ugtxpr1zJdXo5 PIpEoUz3gdzyUugKZNdUOBDegiUeEKLakou6OMkBRYNzhddYtPs9WPHvW0F6IqXrpjdh qnFQ7BGg8yHqUryZWoo4VlSivBn9PkMYIlAk2HPNrKFcqHpOr2Y+gOvR+hcE6fWNfZfV xh3wUV13gwZaf+X410K+pwBb1Bq50f8uzutabJKivutMJNnjiQag8FFF7YU+6E2f9qOM YSxdzAokuL6/zmVszt/whXevSGoUYLTmTrt/uUKZ7Ubihhwgxg677nS3O1j0i2x33u06 cYsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SNfen3buLpO6TC8qH29iHI5/GE8o1lZHOafrIDORN2I=; b=MD+Ijl6ZTHR9L0uGXvqVImjqTLchDFr6kQyiJc8a+r250woDVL3XbP/bQfJPRvAhku yhgCLxd69OmqTrqSIXIP2SXaWPtWV2MMO0+xVELHgcUDxGCDJFjs9Nc2roH2DpEB+E5n rN7G+JIlilaKr3l/AU6uHBZFEVSGvhlekRC4Rovt4JfA5C3zabmILvLJGBu+0PjWwT7W Fc4eMf5qATyqAHbxX1D0Lbunk48uOs/UpcKFybmXrIjomKTthIPIoeMBS0nL4k+hIj0R zhg9P+m9E+OKG9cfccrUveWxsRVhSTdnEhFqtpk2IW3a84Kkq3MiNP+wfMtyf4pbQwNO FaAA== X-Gm-Message-State: AGRZ1gI9GolRFjxluh/y5pSF8cW9trFoiIF8lERdDPDgpOhq5wOWTNq6 wm9PbDpBFl+Mj0U96d6GCi9REGogUvNcKlDJQn8= X-Google-Smtp-Source: AJdET5fUf5U3rrclWeRwFypvY+1FQaWbxlBhsKA9jsilIEwP4NWYN+ivY8QeRSmiuDSaf91lj8/xxtwfjaIxiyd0bzM= X-Received: by 2002:a0c:ad16:: with SMTP id u22mr3088709qvc.240.1542067171838; Mon, 12 Nov 2018 15:59:31 -0800 (PST) MIME-Version: 1.0 References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> <129B91F9-E471-4AE4-98D3-F534D6BF09C1@mit.edu> In-Reply-To: From: Evan Gilman Date: Mon, 12 Nov 2018 15:59:20 -0800 Message-ID: To: Brian Campbell Cc: jricher@mit.edu, Neil Madden , oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 23:59:36 -0000 Thank you everyone for the feedback. I am currently working on the sample text, and should be complete in the next couple days. Apologies for the delay. On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell wrote: > > Sure, I think they could be treated as different different client_auth_me= thods. But there is a lot more commonality than differences to the point wh= ere I think it makes sense to keep it all in a single document and under a = single client auth method with just the variation on which name is being us= ed. > > On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer wrote: >> >> Would it make sense for these to be a different client_auth_method entir= ely? Much the same way that we have private_key_jwt and client_secret_jwt t= oday, both of which use the JWT assertion framework but have very different= keying and security assumptions. In the same way, here you=E2=80=99re stil= l validating the cert but the means by which it=E2=80=99s validated is diff= erent, so the auth method is arguably not going to benefit from being overl= oaded. Caveat, I=E2=80=99ve not built out a system using SANs in any meanin= gful way. >> >> If we were to do that, this draft could go forward as-is (since it=E2=80= =99s fairly done in my opinion) and a new document could better define the = semantics for the various SAN types, but while building on the framework an= d concepts listed in here. >> >> =E2=80=94 Justin >> >> On Nov 6, 2018, at 3:52 PM, Evan Gilman wrote: >> >> Response(s) inline >> >> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden = wrote: >> >> >> Is there an intention that any semantics are attached to the SAN being a= URI or DNS name or IP or ...? Or is it still intended to be an opaque iden= tifier? >> >> >> There are some extra things we could do if we attached type-specific >> semantics to the matching (e.g. DNS wildcarding etc), however I think >> that continuing to use the values as opaque identifiers would get us >> most of what we need while keeping things simple. >> >> On 6 Nov 2018, at 01:55, Brian Campbell wrote: >> >> Thanks Evan for bringing this to the WG's attention. More or less the sa= me question/issue was raised yesterday in the area director's review of the= document as well. I plan to bring this up as a discussion item in the meet= ing today. But my sense from some early discussions is that there is likely= to be (rough) consensus to make some change in order to allow a SAN to be = specified as the certificate subject identifier in the PKI client auth mode= . We'll need to figure out the specifics of how that works. I don't think t= here are significant drawbacks to extending the number of client registrati= on metadata parameters per se. I guess I've just been attracted to the idea= of overloading the existing value because that felt like maybe a less inva= sive change. But perhaps that's shortsighted. And there's nothing inherentl= y wrong with additional client metadata parameters. >> >> I don't know if we could get away with a single new parameter that could= carry the value for any SAN type. Something like, { ... "tls_client_auth_s= an": "spiffe://trust-domain/path" ...}. In practice I feel like that'd prob= ably be okay but in theory there's the potential for confusion of the value= across different types. So probably there's a need to indicate the SAN typ= e too. Either with more client metadata parameters like tls_client_auth_san= _uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or maybe with= a structured value of some sort like {... "tls_client_auth_san": {"type":"= URI", "value":"spiffe://trust-domain/path"} ... }. And then deciding which = types to support and if/how to allow for the extensible types. >> >> >> I am far from an authority here, but it is my understanding that one >> of the primary drivers in supporting SAN over Subject is that the >> values are strongly typed. While some of the advantages gained from >> this may be less useful in our own context, I feel that it make sense >> to keep the values separate and not overload a single value. Whether >> that means dedicated metadata parameters or a structured parameter >> value, I am not sure what the tradeoffs would be, but both options >> sound suitable to me. >> >> Anyway, those are just some thoughts on it. And it'll be discussed more = today. Suggested/proposed text is always helpful though (even if it's not u= sed directly it can help move the conversation forward and/or help editor(s= ) to have prospective wording). >> >> >> Great. I will work on some sample text since it sounds like that would >> be generally helpful >> >> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman wrote: >> >> >> Hello everyone.. >> >> Very excited to see this draft. It helps tremendously in addressing >> use cases around oauth client management in machine-to-machine >> scenarios. Particularly, the PKI authentication method. >> >> In reviewing the document, I noticed that the only supported method >> for identifying a client using the PKI authentication method is by >> referencing its distinguished name. This caught me a bit by surprise - >> many newer projects aimed at automating X.509 issuance in the >> datacenter utilize SAN extensions rather than distinguished name in >> order to encode identity. I am further under the impression that the >> community is, in general, moving away from the subject extension >> altogether in favor of SAN-based identification. >> >> Full disclosure: I am one of the maintainers on a project called >> SPIFFE, which provides identity specifications for datacenter workload >> applications. For X.509, SPIFFE encodes identity into a URI SAN >> extension. A number of projects using SPIFFE do not configure the >> subject with identifying information (SPIRE and Google Istio being >> just a couple). I am also hearing of other X.509 automation projects >> which are moving away from subject/distinguished name (even if they >> are not using SPIFFE). >> >> While I think support for distinguished name is absolutely necessary, >> I worry that supporting it solely will render it incompatible with >> some of the more modern PKIX systems and not stand the test of time. I >> know that I am a little late to this, and for that I apologize... but >> I feel this is a significant point. >> >> I would like to open a discussion on supporting the most commonly used >> SAN extension types in addition to distinguished name. To accomplish >> this, amending section 2.1.2 `Client Registration Metadata` with >> additional parameters seems appropriate. In my experience, the most >> commonly used SAN extensions are: DNS name, IP address, URI, and email >> address. >> >> Are there significant drawbacks to extending the number of client >> registration metadata parameters? I would very much like to see this - >> without it, many existing projects will be unable to use the spec. I >> am happy to contribute time and text to this, assuming people feel >> that this is a beneficial addition. Sorry again for the timing >> >> -- >> evan >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> 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 comput= er. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> evan >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. --=20 evan From nobody Tue Nov 13 01:08:11 2018 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 6952F128BCC for ; Tue, 13 Nov 2018 01:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xEDqX1mxSPzw for ; Tue, 13 Nov 2018 01:08:05 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A53124BE5 for ; Tue, 13 Nov 2018 01:08:05 -0800 (PST) Received: from [80.187.113.183] (helo=[172.20.10.2]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gMUfw-0002MJ-RQ; Tue, 13 Nov 2018 10:08:00 +0100 From: Torsten Lodderstedt Message-Id: <1F60828E-B714-487F-A812-3C68FF54385F@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_F7B6187B-C75A-4FF2-A259-E4108676314F"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 13 Nov 2018 10:07:58 +0100 In-Reply-To: <062837A8-2737-482E-A304-9B7065D73BCD@authlete.com> Cc: oauth To: Joseph Heenan References: <154175237636.14370.2795740097592534192@ietfa.amsl.com> <399248B5-A485-456E-B57C-FCD91FE77AC2@lodderstedt.net> <062837A8-2737-482E-A304-9B7065D73BCD@authlete.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.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, 13 Nov 2018 09:08:09 -0000 --Apple-Mail=_F7B6187B-C75A-4FF2-A259-E4108676314F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joseph,=20 > Am 09.11.2018 um 18:27 schrieb Joseph Heenan : >=20 > Hi Torsten, >=20 > A few comments having just read this afresh: >=20 > 2.1: 'Clients SHALL avoid=E2=80=99 - is that normatively different to = =E2=80=99SHOULD=E2=80=99 given it appears to be permitted? SHALL is equivalent to MUST, changed it into SHOULD for the reason you = gave.=20 I also changed other occurrences of SHALL to MUST as it seems people are = more familiar with this term.=20 >=20 > I find it a little hard to understand exactly what "avoid any = redirects or forwards which can be parameterized by URI query = parameters=E2=80=9D means (particularly as it comes directly after a = paragraph on the redirect_uri and I initially thought it was talking = about that. Perhaps something along the lines of =E2=80=9Cavoid = forwarding the user=E2=80=99s browser to a value from a uri query = parameter=E2=80=9D might be clearer. Incorporated your text. >=20 > " Clients SHALL ensure to only process =E2=80=9C could just be written = =E2=80=98Client SHALL only process=E2=80=9D I think. That=E2=80=99s indeed simpler :-) >=20 >=20 > 2.1.1: >=20 > "Authorization servers SHALL consider the=E2=80=9D - is =E2=80=99SHALL = consider=E2=80=99 different to =E2=80=99SHOULD=E2=80=99? Or does it mean = something like =E2=80=9CSHALL implement at least one countermeasure from = <=E2=80=A6>=E2=80=9D. That wouldn't work since the text in RFC6819 gives implementors multiple = mostly complementary measures. But the direction of your proposal makes = sense, so I added the requirement for the AS to bind every code to a = client (already stated in RFC6749) and to authenticate the client. = Thanks to Dynamic Registration and PKCE this is now feasible and it = seems to be the most effective mitigation to me. I also made the = reference to RFC 6819 a SHOULD. >=20 > 3.2.4: >=20 > This says "Authorization codes SHOULD be invalidated by the AS after = their first use at the token endpoint=E2=80=9D. >=20 > https://tools.ietf.org/html/rfc6749#section-10.5 says: >=20 > "Authorization codes MUST be short lived and single-use.=E2=80=9D. >=20 Thanks for pointing this out!=20 > Does this "MUST be single-use=E2=80=9D not effectively already require = the code is invalidated after first use? If so why downgrade this to a = =E2=80=9CSHOULD=E2=80=9D? You are right. My feeling is single use can turn out to be a really hard = to implement requirement. That=E2=80=99s why I would like to relax it. = Given we now have a stronger requirement on client authentication that = should be fine.=20 Question to the list: what is your implementation experience regarding = one time use authorization codes? Thanks for your feedback! kind regards, Torsten.=20 >=20 >=20 > Cheers, >=20 > Joseph >=20 >=20 >> On 9 Nov 2018, at 09:42, Torsten Lodderstedt = wrote: >>=20 >> Hi all,=20 >>=20 >> the new revision incorporates the recommendation to use more secure = grant types instead of implicit we agreed to add during the WG session = on Monday. It also has more text around justifications for our = recommendation. Especially, there is a new section 3.6 on access token = injection.=20 >>=20 >> I also posted about this topic on LinkedIn = (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-g= rant-torsten-lodderstedt/) and Medium = (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oau= th-implicit-grant-2436ced1c926) >>=20 >> kind regards, >> Torsten.=20 >>=20 >>> Am 09.11.2018 um 09:32 schrieb internet-drafts@ietf.org: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Web Authorization Protocol WG of = the IETF. >>>=20 >>> Title : OAuth 2.0 Security Best Current Practice >>> Authors : Torsten Lodderstedt >>> John Bradley >>> Andrey Labunets >>> Daniel Fett >>> Filename : draft-ietf-oauth-security-topics-09.txt >>> Pages : 35 >>> Date : 2018-11-09 >>>=20 >>> Abstract: >>> This document describes best current security practice for OAuth = 2.0. >>> It updates and extends the OAuth 2.0 Security Threat Model to >>> incorporate practical experiences gathered since OAuth 2.0 was >>> published and covers new threats relevant due to the broader >>> application of OAuth 2.0. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09 >>> = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09 >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-09 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_F7B6187B-C75A-4FF2-A259-E4108676314F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTMwOTA3NTlaMC8GCSqGSIb3DQEJBDEiBCCD s3BBXX9nwHi8zBfmv9B8HRBf9FFm/a6Or5OQhB6GRTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAiY+opPzFFWaG2ogv4S3XHQ41 pgpr89sfMiDdYJXTz08JyxJOeuitmwZTT4XCbfW7+eByXLR/ZFL96rg4PqoDitFjrU7wULZnBcRJ JkG3gSNugq3apYqueZ37qKYscCdC5NFDfa3bryxaJBarjC3JXE/TyF0Ts6DXi1/hkGee5WYcrlnV OuGtC7Uyk/NUROmpdj0qV0DSJdVYbMfxE2m99fSJVfutLlDVfB5Ifg/e2MDkxSzeu0oD967bVXoM Xl49Tj0+yd/oa7C4TGUppBvjvS+xhYuLakMu4JKvGK5yd0zqozQUFE1aIur2IIHfxEGbESqR3bGR kDVRtutiPY4ynQAAAAAAAA== --Apple-Mail=_F7B6187B-C75A-4FF2-A259-E4108676314F-- From nobody Tue Nov 13 06:24:59 2018 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 3B30C12D4EE for ; Tue, 13 Nov 2018 06:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 VS2Yf4JXwMHv for ; Tue, 13 Nov 2018 06:24:55 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (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 AC475127332 for ; Tue, 13 Nov 2018 06:24:54 -0800 (PST) Received: from [80.155.34.3] (helo=[10.3.12.54]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gMZcZ-0007lw-Em; Tue, 13 Nov 2018 15:24:51 +0100 From: Torsten Lodderstedt Message-Id: <1AEDD443-72AD-4F46-9005-D64794C055AA@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_E72F23BF-50E7-49DD-A1A6-788E816C9FA7"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 13 Nov 2018 15:24:50 +0100 In-Reply-To: Cc: Brian Campbell , oauth@ietf.org To: Evan Gilman References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> <129B91F9-E471-4AE4-98D3-F534D6BF09C1@mit.edu> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 14:24:58 -0000 --Apple-Mail=_E72F23BF-50E7-49DD-A1A6-788E816C9FA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Evan,=20 I scanned through the SPIFFE docs but didn=E2=80=99t any mentioning of = OAuth (just plain X.509). What=E2=80=99s your plan for introducing OAuth = and mtls? kind regards, Torsten.=20 > Am 13.11.2018 um 00:59 schrieb Evan Gilman : >=20 > Thank you everyone for the feedback. >=20 > I am currently working on the sample text, and should be complete in > the next couple days. Apologies for the delay. > On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell > wrote: >>=20 >> Sure, I think they could be treated as different different = client_auth_methods. But there is a lot more commonality than = differences to the point where I think it makes sense to keep it all in = a single document and under a single client auth method with just the = variation on which name is being used. >>=20 >> On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer = wrote: >>>=20 >>> Would it make sense for these to be a different client_auth_method = entirely? Much the same way that we have private_key_jwt and = client_secret_jwt today, both of which use the JWT assertion framework = but have very different keying and security assumptions. In the same = way, here you=E2=80=99re still validating the cert but the means by = which it=E2=80=99s validated is different, so the auth method is = arguably not going to benefit from being overloaded. Caveat, I=E2=80=99ve = not built out a system using SANs in any meaningful way. >>>=20 >>> If we were to do that, this draft could go forward as-is (since = it=E2=80=99s fairly done in my opinion) and a new document could better = define the semantics for the various SAN types, but while building on = the framework and concepts listed in here. >>>=20 >>> =E2=80=94 Justin >>>=20 >>> On Nov 6, 2018, at 3:52 PM, Evan Gilman wrote: >>>=20 >>> Response(s) inline >>>=20 >>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden = wrote: >>>=20 >>>=20 >>> Is there an intention that any semantics are attached to the SAN = being a URI or DNS name or IP or ...? Or is it still intended to be an = opaque identifier? >>>=20 >>>=20 >>> There are some extra things we could do if we attached type-specific >>> semantics to the matching (e.g. DNS wildcarding etc), however I = think >>> that continuing to use the values as opaque identifiers would get us >>> most of what we need while keeping things simple. >>>=20 >>> On 6 Nov 2018, at 01:55, Brian Campbell = wrote: >>>=20 >>> Thanks Evan for bringing this to the WG's attention. More or less = the same question/issue was raised yesterday in the area director's = review of the document as well. I plan to bring this up as a discussion = item in the meeting today. But my sense from some early discussions is = that there is likely to be (rough) consensus to make some change in = order to allow a SAN to be specified as the certificate subject = identifier in the PKI client auth mode. We'll need to figure out the = specifics of how that works. I don't think there are significant = drawbacks to extending the number of client registration metadata = parameters per se. I guess I've just been attracted to the idea of = overloading the existing value because that felt like maybe a less = invasive change. But perhaps that's shortsighted. And there's nothing = inherently wrong with additional client metadata parameters. >>>=20 >>> I don't know if we could get away with a single new parameter that = could carry the value for any SAN type. Something like, { ... = "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I = feel like that'd probably be okay but in theory there's the potential = for confusion of the value across different types. So probably there's a = need to indicate the SAN type too. Either with more client metadata = parameters like tls_client_auth_san_uir, tls_client_auth_san_email, = tls_client_auth_san_ip, etc. or maybe with a structured value of some = sort like {... "tls_client_auth_san": {"type":"URI", = "value":"spiffe://trust-domain/path"} ... }. And then deciding which = types to support and if/how to allow for the extensible types. >>>=20 >>>=20 >>> I am far from an authority here, but it is my understanding that one >>> of the primary drivers in supporting SAN over Subject is that the >>> values are strongly typed. While some of the advantages gained from >>> this may be less useful in our own context, I feel that it make = sense >>> to keep the values separate and not overload a single value. Whether >>> that means dedicated metadata parameters or a structured parameter >>> value, I am not sure what the tradeoffs would be, but both options >>> sound suitable to me. >>>=20 >>> Anyway, those are just some thoughts on it. And it'll be discussed = more today. Suggested/proposed text is always helpful though (even if = it's not used directly it can help move the conversation forward and/or = help editor(s) to have prospective wording). >>>=20 >>>=20 >>> Great. I will work on some sample text since it sounds like that = would >>> be generally helpful >>>=20 >>> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman = wrote: >>>=20 >>>=20 >>> Hello everyone.. >>>=20 >>> Very excited to see this draft. It helps tremendously in addressing >>> use cases around oauth client management in machine-to-machine >>> scenarios. Particularly, the PKI authentication method. >>>=20 >>> In reviewing the document, I noticed that the only supported method >>> for identifying a client using the PKI authentication method is by >>> referencing its distinguished name. This caught me a bit by surprise = - >>> many newer projects aimed at automating X.509 issuance in the >>> datacenter utilize SAN extensions rather than distinguished name in >>> order to encode identity. I am further under the impression that the >>> community is, in general, moving away from the subject extension >>> altogether in favor of SAN-based identification. >>>=20 >>> Full disclosure: I am one of the maintainers on a project called >>> SPIFFE, which provides identity specifications for datacenter = workload >>> applications. For X.509, SPIFFE encodes identity into a URI SAN >>> extension. A number of projects using SPIFFE do not configure the >>> subject with identifying information (SPIRE and Google Istio being >>> just a couple). I am also hearing of other X.509 automation projects >>> which are moving away from subject/distinguished name (even if they >>> are not using SPIFFE). >>>=20 >>> While I think support for distinguished name is absolutely = necessary, >>> I worry that supporting it solely will render it incompatible with >>> some of the more modern PKIX systems and not stand the test of time. = I >>> know that I am a little late to this, and for that I apologize... = but >>> I feel this is a significant point. >>>=20 >>> I would like to open a discussion on supporting the most commonly = used >>> SAN extension types in addition to distinguished name. To accomplish >>> this, amending section 2.1.2 `Client Registration Metadata` with >>> additional parameters seems appropriate. In my experience, the most >>> commonly used SAN extensions are: DNS name, IP address, URI, and = email >>> address. >>>=20 >>> Are there significant drawbacks to extending the number of client >>> registration metadata parameters? I would very much like to see this = - >>> without it, many existing projects will be unable to use the spec. I >>> am happy to contribute time and text to this, assuming people feel >>> that this is a beneficial addition. Sorry again for the timing >>>=20 >>> -- >>> evan >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> evan >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 >=20 >=20 > --=20 > evan >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_E72F23BF-50E7-49DD-A1A6-788E816C9FA7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTMxNDI0NTFaMC8GCSqGSIb3DQEJBDEiBCCX 8X24/aYX/5NhYSCmULwmtb9L73iqDHFySoAUAWJlMzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEABtwyJH64kl370QxFHiTS1lYi eD4Fjzz/FfB7RKOg6jy0BV1GcJD/MCbx+G9J5m4+3DQRQTFwZM+pDDaJq050FA17K3m6o5Zd3Iyt Q5bezgPLbWzMY5lyOc/rATqSRchVs06yXsABlPb+DN2kcAz1j6jIfzC/qr4OTAvJmVK6+BknlCDL w3xjnIRQXTPwYi3/Vj0Kgwgw9ULi6qWLxwTToYdgeHk+qzop1cz3DRvyi79sCBOBYnBvo/GniKyA SlPLVbrS7FiM1tPHfseZ/HRLPkv/yVJ7iSxV/SvBkqo9X9rGfEs+o1a4HZeDgUddgwBikoDfd4oP 4nQ2wOn9oildIAAAAAAAAA== --Apple-Mail=_E72F23BF-50E7-49DD-A1A6-788E816C9FA7-- From nobody Tue Nov 13 08:29:50 2018 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 E4D7D1294D7 for ; Tue, 13 Nov 2018 08:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 P74DOCAcnokl for ; Tue, 13 Nov 2018 08:29:45 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0: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 8F957128A6E for ; Tue, 13 Nov 2018 08:29:45 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id v11so19351347itj.0 for ; Tue, 13 Nov 2018 08:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zoge2bATsKdjY1GkPLuNSBzGhOwL6HcI6ukXvPEI31Y=; b=MN1h0ZrLxQBoQScOhbzsyP0FdcQoQplNAAGpYVe+c/erWEFUD2cDu733Nb340MONxg 7fAYF5xS23W6cF8ybeMx2d6XCewMx1xnQ7kbtGK4dE4CvPdW0ojWUJPg1TBFnKXN64Jk Vc08PAUswNFPFKrJe3R/H1mlGEUVvPsz+z6o8= 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=Zoge2bATsKdjY1GkPLuNSBzGhOwL6HcI6ukXvPEI31Y=; b=JnMsO7M0RDBmiJts0D4TFP18SC4BDtQ3jP84SYTLZRnY1mCqDlbxd2plzF79HtfZ6J 4iqOdG0OBGiuXMyEK4COT0wigQMn22bcTObywVc3uF98toy27VR6Fob/eWnXC5aVYNzd FMUUmhJtRnkI+fspsh8g6rb8WAol4UuW4IcmeU3G/CQQQeyRlNur3UmbgcHc85KdTN3u 39Tzo1SFKF2U0KBEjPwszKXnQZ6pV9V/5h/6DCNNofZUbD0yE6wimPHX9VfT5nFFZ/RO dLgE48QdyxsQ2jFR7aU+cnHgflOpXMM45uReBaLLkqg/CBnLX81oETqCGAwFwaNvSAWo zhMg== X-Gm-Message-State: AGRZ1gJjeiTCXlxsnhenC1pDf4EnqQxZ6yhhJ4G+VViDvpvmMk8R6FQt T9LAoL4SOFYkaUW/FnDo/cf9XDokNjDjnCMvwWCgiJy647AA5yijKXmGX6a9PDHIPSZznxAozJh mNalFTqQrkliwdg== X-Google-Smtp-Source: AJdET5eJr/8Ud47llhX4VpWk6lFU+cnZdp4A15G+yWXDx+TlnUGa3Z3dZ0AcY7CdgzF14r0ECDh6n8Lqsb9zv3L+IYE= X-Received: by 2002:a24:bcc1:: with SMTP id n184-v6mr4154457ite.174.1542126584657; Tue, 13 Nov 2018 08:29:44 -0800 (PST) MIME-Version: 1.0 References: <154175237636.14370.2795740097592534192@ietfa.amsl.com> <399248B5-A485-456E-B57C-FCD91FE77AC2@lodderstedt.net> <062837A8-2737-482E-A304-9B7065D73BCD@authlete.com> <1F60828E-B714-487F-A812-3C68FF54385F@lodderstedt.net> In-Reply-To: <1F60828E-B714-487F-A812-3C68FF54385F@lodderstedt.net> From: Brian Campbell Date: Tue, 13 Nov 2018 08:29:18 -0800 Message-ID: To: Torsten Lodderstedt Cc: Joseph Heenan , oauth Content-Type: multipart/alternative; boundary="00000000000047502c057a8e530d" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.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, 13 Nov 2018 16:29:48 -0000 --00000000000047502c057a8e530d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Does this "MUST be single-use=E2=80=9D not effectively already require = the code > is invalidated after first use? If so why downgrade this to a =E2=80=9CSH= OULD=E2=80=9D? > > You are right. My feeling is single use can turn out to be a really hard > to implement requirement. That=E2=80=99s why I would like to relax it. Gi= ven we now > have a stronger requirement on client authentication that should be fine. > > Question to the list: what is your implementation experience regarding on= e > time use authorization codes? > There's a bit of discussion about this on this ticket in the Connect WG: https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-= single-use FWIW. I do think that in some systems or architectures it can be difficult to strictly guarantee that a code can only be used once. And it'd be better for specs to come to terms with that rather than being unrealistically strict about it. We have an AS implementation that does do strict one-time use of the code. But it comes at a cost including some difficulties with resiliency for any particular code. Not to mention some troubleshooting and support issues/questions about it. We haven't gotten to the point of changing anything but have, from time to time, considered changing the implementation approach for code to something that would appear to behave the same but might not 100% guarantee a code could only be used once. --=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._ --00000000000047502c057a8e530d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Does this "MUST be single-use=E2=80=9D not effectively already re= quire the code is invalidated after first use? If so why downgrade this to = a =E2=80=9CSHOULD=E2=80=9D?

You are right. My feeling is single use can turn out to be a really hard to= implement requirement. That=E2=80=99s why I would like to relax it. Given = we now have a stronger requirement on client authentication that should be = fine.

Question to the list: what is your implementation experience regarding one = time use authorization codes?

There'= ;s a bit of discussion about this on this ticket in the Connect WG: https://bitbucket.org/openid/connect/issu= es/1057/oidcc-appears-to-override-single-use FWIW.

=
I do think that in some systems or architectures it can be difficult t= o strictly guarantee that a code can only be used once. And it'd be bet= ter for specs to come to terms with that rather than being unrealistically = strict about it.

We have an AS implementation that= does do strict one-time use of the code. But it comes at a cost including = some difficulties with resiliency for any particular code. Not to mention s= ome troubleshooting and support issues/questions about it. We haven't g= otten to the point of changing anything but have, from time to time, consid= ered changing the implementation approach for code to something that would = appear to behave the same but might not 100% guarantee a code could only be= used once.

=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. --00000000000047502c057a8e530d-- From nobody Tue Nov 13 10:06:47 2018 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 0964F128B14 for ; Tue, 13 Nov 2018 10:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 IcvN2UAZw9Br for ; Tue, 13 Nov 2018 10:06:43 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0: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 D60D412777C for ; Tue, 13 Nov 2018 10:06:42 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id u130-v6so11151253oie.7 for ; Tue, 13 Nov 2018 10:06:42 -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=ouy4egYvL9T3CIJlmPXCBOHiBKmWFZt6n1mpHAYKRho=; b=VNwloMFtQEyeen4gO4j9Ms4WP2DfXDjGJCDUrefCMlnbfsNqduQbtThgMODZaHWHWz 0a0zbYaoTdYtyiU1LOrJvGx7/XVga2y44qxAB2Az6Y9ax4oW5TvwEtczkRSrGBaRCO3g vAoipwivtPUBNRHKVxR7ZBWZk30XxxJQE5Ghz/Rto/aAbh92Zty9gybT5vW6XGcluM9A 5AVnnQb2e1JpunpGJsjfjn4FpLjdLoj4fE+z4vrWbj74w5nk61nmAB1T0WPXiJsWUz8I aR2IQb1utL5qVyeHoMjmzB5CJT/AwC6IiloYysA5xPi2HYJv2eFlz5IgpT+PoQaqircn cDAQ== 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=ouy4egYvL9T3CIJlmPXCBOHiBKmWFZt6n1mpHAYKRho=; b=iDXyDbW72sS5C5PASdEgc7b7oVIL0rC2QkMxWyfCcZPMmUkmRvrNWZ6CVGFSD5/dyj 4JhIPJ/dXWxV1xxZNsuwIgzVrDaIzwyTGxSzGxn9brJ97ccP4I7qkGauQSsMWt1FgEmM XsIlEqnbO4f/wJ4svtIQHUMNcUQqCNjIjAg5qr/hulxXL6qb6S4F2PezC6BIi1+67bdh k0FG4MgdP7s4fPiuwZnJhvNEGyQnamq4VBjECEQK+HDX6XGLXFcZVZEns/oSgR+b3I3I r3YJ2jk6ZqM0mwCtI2BWpl5wAfREpMAshofNghi8S5zOx7ziX/Us65zxA+eijLT9WHF3 f8fw== X-Gm-Message-State: AGRZ1gI3xLWNKzWAWvUQ9bABETpR6XzeDv3Fn1ZwUr11N2WSTVaV3RHI ZR3otQ+X6ebi+tX4lCMckDgLQdF+QV4L1rDolD4= X-Google-Smtp-Source: AJdET5e+5p5LoEnInKzB7JjQhvLS8xrc7j9v1kC6MzUPnOg/2FcMLFLfyvnQltbIBqSOq0A1zVUFuGMrF5/BoBt2Th8= X-Received: by 2002:aca:6a4e:: with SMTP id f75-v6mr3762142oic.260.1542132402167; Tue, 13 Nov 2018 10:06:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Omer Levi Hevroni Date: Tue, 13 Nov 2018 20:06:30 +0200 Message-ID: To: Dick Hardt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000072399057a8fae64" Archived-At: Subject: Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant 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, 13 Nov 2018 18:06:45 -0000 --000000000000072399057a8fae64 Content-Type: text/plain; charset="UTF-8" Ok, thanks for the clarification. Your point about a user with multiple devices is correct - but it is by design. The goal of this protocol is to allow device authentication - there is no information about the user. Therefore, there is also no way to associate devices to a user. It creates challenges, but it also opens new opportunities - for cases when there is no need in user entity, only strong authentication solution. Could you elaborate more about why do you think that "the private key protections you have in place are a net positive"? Finally, yes, it's just a small change to JWT client assertion, that make it more usable on physical devices. On Mon, Nov 12, 2018 at 3:19 PM Dick Hardt wrote: > I understand better, thanks! > > From an OAuth perspective, this is a client credentials grant. You have > added some other checks that may or may not help the security profile, but > at the core, you have a private key on the device that is the primary > credential, and is device oriented. > > FWIW: there are a number of usability challenges with your approach. The > user can't use more than one device. If they change devices, they lose all > their data. Also, IMHO, I don't think the private key protections you have > in place are a net positive. > > > > > On Mon, Nov 12, 2018 at 3:08 AM Omer Levi Hevroni > wrote: > >> Ok, let me try. >> >> At the company where I work, we have an app that is used by our users. We >> want to have a way to authenticate the requests from the application, >> without requiring the user to perform any interactive login flow. I >> described it more in-depth in the blog post - >> https://blog.solutotlv.com/userless-mobile-authentication/ >> >> Does this help? >> >> Also, thank you for your time and feedback. I appreciate it! >> >> On Fri, Nov 9, 2018 at 1:54 AM Dick Hardt wrote: >> >>> More detail on the scenario would help. >>> >>> On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni >>> wrote: >>> >>>> Yes, that is correct. >>>> I'm sorry the confusion, I think this confusion is built into >>>> oauth framework itself. >>>> You understood well the scenario - I have an application running on an >>>> untrusted device in an untrusted network. I looked for a way to >>>> authenticate the requests from the device to AS. >>>> Does it make more sense now? >>>> >>>> On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt >>>> wrote: >>>> >>>>> Omar >>>>> >>>>> As promised, I have reviewed the ID[1] you posted. I'm confused in the >>>>> Motivation by the references to authentication, as OAuth is about >>>>> authorization. >>>>> >>>>> Perhaps you can post to the list the use case you are trying to solve >>>>> for? I can infer aspects, but don't fully understand it. >>>>> >>>>> From what I can understand though, there is software running in a >>>>> trusted device that would like to get an access token, and an OTP is part >>>>> of how the device is authenticating to the AS. This seems like a 2 legged >>>>> OAuth flow as there is no user involved directly, and it seems you have a >>>>> means for the client to authenticate to the AS using an OTP. Am I guessing >>>>> correctly? >>>>> >>>>> /Dick >>>>> >>>>> [1] >>>>> https://datatracker.ietf.org/doc/draft-hevroni-oauth-seamless-flow/?include_text=1 >>>>> >>>>> >>>>> --000000000000072399057a8fae64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, thanks for the clarification.=C2=A0
Your point abo= ut a user with multiple devices is correct - but it is by design. The goal = of this protocol is to allow device authentication - there is no informatio= n about the user. Therefore, there is also no way to associate devices to a= user. It creates challenges, but it also opens new opportunities=C2=A0- fo= r cases when there is no need in user entity, only strong authentication so= lution.
Could you elaborate more about why do you think that &quo= t;the private key protections you have in place are a net positive"?

Finally, yes, it's just a small change to=C2=A0= JWT client assertion, that make it more usable on physical devices.

On Mon, Nov 12, 2018 at= 3:19 PM Dick Hardt <dick.hardt@= gmail.com> wrote:
I understand better, thanks!

From an OAuth pers= pective, this is a client credentials grant. You have added some other chec= ks that may or may not help the security profile, but at the core, you have= a private key on the device that is the primary credential, and is device = oriented.=C2=A0

FWIW: there are a number of usabil= ity challenges with your approach. The user can't use more than one dev= ice. If they change devices, they lose all their data. Also, IMHO,=C2=A0 I = don't think the private key protections you have in place are a net pos= itive.




On Mon, Nov 12, 2018 at 3:08 AM Omer Le= vi Hevroni <omerlh= @gmail.com> wrote:
Ok, let me try.

At the company= where I work, we have an app that is used by our users. We want to have a = way to authenticate the requests from the application, without requiring th= e user to perform any interactive login flow. I described it more in-depth = in the blog post -=C2=A0https://blog.solutotlv.com/userless-m= obile-authentication/

Does=C2=A0this help?

Also, thank you for your time and feedback. I appreci= ate it!

On= Fri, Nov 9, 2018 at 1:54 AM Dick Hardt <dick.hardt@gmail.com> wrote:
More detail on the scena= rio would help.

On Fri, Nov 9, 2018 at 2:04 AM Omer Levi Hevroni <omerlh@gmail.com> wrote:
Yes, that is correct.=C2= =A0
I'm sorry the confusion, I think this confusion is built in= to oauth=C2=A0framework itself.
You understood well the scenario = - I have an application running on an untrusted device in an untrusted netw= ork. I looked for a way to authenticate the requests from the device to AS.=
Does it make more sense now?

On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt <dick.hardt@gmail.com<= /a>> wrote:

--000000000000072399057a8fae64-- From nobody Tue Nov 13 11:08:10 2018 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 EDF90128B14 for ; Tue, 13 Nov 2018 11:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 Zi3sdy52uN2h for ; Tue, 13 Nov 2018 11:08:04 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (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 58F4E128CB7 for ; Tue, 13 Nov 2018 11:08:03 -0800 (PST) Received: from [194.140.108.146] (helo=[10.5.51.163]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gMe2a-00079q-3R; Tue, 13 Nov 2018 20:08:00 +0100 From: Torsten Lodderstedt Message-Id: <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_5312C576-D17E-4C9D-B7BA-CC6F00F2F6A4"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 13 Nov 2018 20:07:58 +0100 In-Reply-To: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> Cc: Aaron Parecki , Hannes Tschofenig , oauth@ietf.org To: Brock Allen References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 13 Nov 2018 19:08:09 -0000 --Apple-Mail=_5312C576-D17E-4C9D-B7BA-CC6F00F2F6A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brock, > Am 09.11.2018 um 21:22 schrieb Brock Allen : >=20 > Hello all -- >=20 > I also have some thoughts/feedback on this document. >=20 > Personally I agree with some of the conclusions, but as it stands I = think the document's main conclusion that code flow is the real solution = is not sufficiently convincing. >=20 > I would like to see a brief summary of the current concerns (much like = RFC8252 does) so we have context before the document just jumps to what = a best practice is. The reason I bring this up is that generally the = concept of "best practice" is meaningless without context. I think = stating that code flow is best practice without motivation seems = somewhat "cart before the horse". >=20 > I think just a short blurb about the desire to eliminate the access = token from being delivered in the URL, and the current attacks against = doing so would be helpful (showing attacks is super important in making = this "real"). I guess this would make the most sense in section "4. = Overview" prior to the list of "best practice" conclusions. >=20 I agree, justifications are needed. As = draft-ietf-oauth-security-topics-09 provides those justifications, I = suggest to add suitable references here.=20 > Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get = into specifics, but many of the points seem confused (or at least = confuse me) and/or the conclusion that code flow is the only approach = seems misleading. For example: >=20 > "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is = required according to Section 6), so clients and authorization servers = MUST NOT use the Implicit Flow for browser-based apps.=E2=80=9C Don=E2=80=99t understand the wording either. The text should state that = the implicit cannot detect token injection. >=20 > This is specious. The threat is the token is in the URL, not that = implicit clients can't use PKCE. So perhaps the document should explain = the variety of mitigations, not just one? While code flow is one, using = CSP and the browser history API to remove the token from the URL is = another. Helps to prevent leakage, not injection in the authorization response.=20= > Elsewhere in the document the use of CSP is a "SHOULD". That's great, = but using CSP can be and is used today, and doesn't necessitate code = flow. >=20 > "OAuth 2.0 provides no mechanism for a client to verify that an access = token was issued to it, which could lead to misuse and possible = impersonation attacks if a malicious party hands off an access token it = retrieved through some other means to the client." >=20 > Sure, but OIDC does provide a mitigation for this (even with = implicit). This is about token replay detection at the RS. What mitigation does = OIDC provide here?=20 > So perhaps it should be offered as a suggestion as well? I did see the = point that with code flow id_token validation could instead rely upon = the token endpoint, but the client still has other work to do (namely = around PKCE). That's just trading one bit of work for another, not a = clear cut reason to use one flow over another. >=20 > "Supporting the implicit flow requires additional code, more upkeep = and understanding of the related security considerations, while limiting = the authorization server to just the authorization code flow simplifies = the implementation." >=20 > As offered by someone else already, this is opinion and not objective. = IMO, this diminishes the potential of this document. >=20 > "If the JavaScript application gets wrapped into a native app, then = [RFC8252] also requires the use of the authorization code flow." >=20 > Given how many browser dependencies SPA apps tend to have, is this = really common? In all my years building both, I've never seen it. >=20 > "Historically, the Implicit flow provided an advantage to single-page = apps since JavaScript could always arbitrarily read and manipulate the = fragment portion of the URL without triggering a page reload. Now with = the Session History API (described in "Session history and navigation" = of [HTML]), browsers have a mechanism to modify the path component of = the URL without triggering a page reload, so this overloaded use of the = fragment portion is no longer needed." >=20 > While this section is intended to indicate the existence of the = history API is a reason to move away from implicit, it's also what can = be used to protect token exposure in the URL, which I think weakens its = point. As a section, to me, it seems unnecessary. >=20 > The push to a single flow (for consistency) is a marginal motivation, = and I agree with that theme in the document. >=20 > Much of the other guidance in this document is already covered = elsewhere (e.g. RFC6819). I don't know if the goal of the document is to = reproduce those existing recommendations (as a contrast RFC8252 does not = and mainly focuses on what's unique to the native scenario). >=20 > I can't quite tell the real motivation for this "best practice" = document. If it's trying to give guidance for browser-based JS apps, = then perhaps it should be enhanced to give guidance for the existing = implicit flow, as well as suggesting code flow? But if the real = motivation is just to kill off implicit flow then more needs to be done, = IMO. >=20 > Finally, my last real concern (which is why I'm pushing back so much = on code flow), is that this implies refresh tokens in the browser. My = sense is that given the danger of this, the original OAuth2 RFC (via the = implicit flow) was designed to limit the client's ability to obtain new = access tokens based on the user's authentication session at the AS (via = a cookie). The implicit grant was not equipped with the ability to issue refresh = tokens simply because the working group didn=E2=80=99t want them to end = up in the browser history, leak through open redirectors etc. This is = different with code since tokens travel directly through a TLS protected = connection. =20 > Allowing refresh tokens now means that a successful attacker has = unfettered ability to do this (beyond just an access token's lifetime). First of all the AS decides whether it issues refresh tokens or not. = Having the ability does not mean the AS must do it. If you feel it=E2=80=99= s safer to not do it. Fine. It=E2=80=99s still possible to refresh your = access tokens the way you mentioned above by sending another = authorization request to the AS.=20 But let=E2=80=99s assume for a moment the AS, based on its risk = assessment, decides to issue refresh tokens. Can you please explain how = an attacker will get access to this tokens? Especially what the expected = strength of the attacker would need to be?=20 I would also like to understand how a refresh token is any different = from a long living cookie in the browser and what you think is the big = difference to mobile apps when it comes to refresh token handling.=20 > And yes, CSP is mentioned as a mitigation to protect the refresh = token, but it was already necessary to protect the access token, so CSP = is not the only mitigation. What's missing is strong guidance for token = servers to provide mechanisms to limit the lifetime of refresh tokens = for these high risk client scenarios. I have a suspicion that many = existing token servers do not have such features, and this would imply = more features mandated for the token servers (beyond PKCE for example). Good point! I will add text on refresh protection to the Security BCP. = Limiting the refresh tokens lifetime, rotating them on every refresh = (allowing the AS to detect replay), binding refresh tokens to certs etc.=20= >=20 > Having said all of these things, I am all for using code flow. I just = would like there to be more clear rationale. My comments above were the = various counter arguments I was thinking while reading this document, = and given how many of these I came up with I was left feeling = unconvinced (as I already mentioned). >=20 > Thanks for reading this far, and thanks for putting forth the = document. Thanks for your feedback.=20 kind regards,=20 Torsten, >=20 > -Brock >=20 >> On 11/6/2018 5:14:05 AM, Aaron Parecki wrote: >>=20 >> Thanks Hannes, >>=20 >> Since I wasn't able to give an intro during the meeting today, I'd = like to share a little more context about this here as well. >>=20 >> At the Internet Identity Workshop in Mountain View last week, I led a = session to collect feedback on recommendations for OAuth for browser = based apps. During the session, we came up with a list of several points = based on the collective experience of the attendees. I then tried to = address all those points in this draft. >>=20 >> The goal of this is not to specify any new behavior, but rather to = limit the possibilities that the existing OAuth specs provide, to ensure = a secure implementation in browser based apps. >>=20 >> Thanks in advance for your review and feedback! >>=20 >> Aaron Parecki >> aaronpk.com >>=20 >>=20 >>=20 >> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig = wrote: >> Hi all, >>=20 >> Today we were not able to talk about = draft-parecki-oauth-browser-based-apps-00, which describes "OAuth 2.0 = for Browser-Based Apps". >>=20 >> Aaron put a few slides together, which can be found here: >> = https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-= oauth-2-for-browser-based-apps-00.pdf >>=20 >> Your review of this new draft is highly appreciated.. >>=20 >> Ciao >> Hannes >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> --=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >> _______________________________________________ OAuth mailing list = OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5312C576-D17E-4C9D-B7BA-CC6F00F2F6A4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTMxOTA3NThaMC8GCSqGSIb3DQEJBDEiBCCx PbrxYod7HB6zuBRsui9hjnLJGiDEJIkK7CveO0AZ3jCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAH/5NKI/CpW3i7T39yvsTiE5W atH8aUbr9BJ191jNr8AsEFUHBQ1Gvdgqx/jz/qj3uV1BbCOw6iKBY/x6bNhOhbBWyZbNZ7vkQT48 FclBRimrL3faezWwwq+S77wtYS+RoZ6BiSezfny4BuGUwIfOLE9e7I1XoQ5g5oa4VhSsxlNT4ySt LRs5cEpes7Pc/u8iJXM1JIcLKSVHHzEDRHCRqg7NQG5gZ+i6loQbRg/1RLL/w9Zu0+5BIxxM4tcE yg9KBoz6UVES6L5xAo+q7bZMkUP8Uv/ZtjsVbOiAxzcvQ6GXMaukLlnkmx2pH1LVlwAjWnuNlzVO x5b8tdwv/5N+PQAAAAAAAA== --Apple-Mail=_5312C576-D17E-4C9D-B7BA-CC6F00F2F6A4-- From nobody Wed Nov 14 00:26:40 2018 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 5F1FA128CF3 for ; Wed, 14 Nov 2018 00:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=yes.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 LpYYQ5QT9X0G for ; Wed, 14 Nov 2018 00:26:35 -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 4C1CA130DCF for ; Wed, 14 Nov 2018 00:26:35 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id y3-v6so16201721wrh.10 for ; Wed, 14 Nov 2018 00:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=bTaUiNAxtbzl41iszrdNWtSxXKWVHknIIuuwqCJVYE4=; b=qMcuWIi3UPzxy3auxi7sj0DwwQoZpte78seLdqJIA50fxH31WQP/X8Dk143y5AfHEX ZioY3+kIvowKp93QMAK6jE62n0gUGwB8KdtxQA7KA8zxVJ+O8PZS0rngitPJxTPWtlTZ QGwvkqckUny/5RMIEPuV91utq+fYSP88vJT22Rsc9Q54l/IM+rNucKJHyPyZqHj2ijlG pVHNWy/ahc3Y13Rt2hdv8MaP9ZvyvHvor+zKXljldhk2jOt6+wQWOGgxeexklF+cIjSD V81a0b9yBDr8nDsCd5cHfSiZino6ouJ9PcGlN9npbWyS/DX724rYoB+eE0d+UgbL12V7 H+kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=bTaUiNAxtbzl41iszrdNWtSxXKWVHknIIuuwqCJVYE4=; b=lVnm3zmXYDCTVf3fQvxNEUyfy6Dzoq2Za655q8y9hLhByGWX0q4s3wX3t8nFQmrK19 63zzWWusedReEpGR3YC/33zw4hhICJTQ+jIeiuMpN7nsz7fEEK17WJnwyFwBW2r4Tqhj oo9/bVfD6DDEy1Sx17NP12KX31rN0DCCain5w5aFsiX6gk5QVtYx9yZ7NWO2A4vNf/Uv 7zDoh+ASyZ70LRtVFsUupNfgt+y1yr+VmQlQ4RGn1c4QkaQZVppUUlbTC4ieJWJBDtLn vozndU/Ihny5d1VuI32mC/G+xBvm+H5BU5j7aUyNAxgIECori62ObA90Jr14vS4IQtXf UicA== X-Gm-Message-State: AGRZ1gLDFjmktCfASUDNbB832cgTzbqeIHWH5Eb0IiGWVcU0N7k2f5hR W3xRrlqHrvEbrdP8m+xfYEb01czRfM0= X-Google-Smtp-Source: AJdET5d6qG/dWmXu19lIaPCPvl5CeEohv+DqrJ99QUHtvPChsMhAAfiNGmMyonL8h4ijRTaG79LOOg== X-Received: by 2002:adf:dd07:: with SMTP id a7-v6mr881463wrm.2.1542183993480; Wed, 14 Nov 2018 00:26:33 -0800 (PST) Received: from ?IPv6:2003:c1:4f3a:ca00:cc33:a3af:4584:e7de? (p200300C14F3ACA00CC33A3AF4584E7DE.dip0.t-ipconnect.de. [2003:c1:4f3a:ca00:cc33:a3af:4584:e7de]) by smtp.gmail.com with ESMTPSA id s66sm574919wmf.34.2018.11.14.00.26.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Nov 2018 00:26:32 -0800 (PST) To: oauth@ietf.org References: <154175237636.14370.2795740097592534192@ietfa.amsl.com> <399248B5-A485-456E-B57C-FCD91FE77AC2@lodderstedt.net> <062837A8-2737-482E-A304-9B7065D73BCD@authlete.com> <1F60828E-B714-487F-A812-3C68FF54385F@lodderstedt.net> From: Daniel Fett Message-ID: Date: Wed, 14 Nov 2018 09:26:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------22D1FB4A1A320CEA8BBE9563" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.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, 14 Nov 2018 08:26:39 -0000 This is a multi-part message in MIME format. --------------22D1FB4A1A320CEA8BBE9563 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 13.11.18 um 17:29 schrieb Brian Campbell: > > > Does this "MUST be single-use†not effectively already require > the code is invalidated after first use? If so why downgrade this > to a “SHOULD� > > You are right. My feeling is single use can turn out to be a > really hard to implement requirement. That’s why I would like to > relax it. Given we now have a stronger requirement on client > authentication that should be fine. > > Question to the list: what is your implementation experience > regarding one time use authorization codes? > > > There's a bit of discussion about this on this ticket in the Connect > WG: > https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-single-use > FWIW. > > I do think that in some systems or architectures it can be difficult > to strictly guarantee that a code can only be used once. And it'd be > better for specs to come to terms with that rather than being > unrealistically strict about it. > > We have an AS implementation that does do strict one-time use of the > code. But it comes at a cost including some difficulties with > resiliency for any particular code. Not to mention some > troubleshooting and support issues/questions about it. We haven't > gotten to the point of changing anything but have, from time to time, > considered changing the implementation approach for code to something > that would appear to behave the same but might not 100% guarantee a > code could only be used once. >From a security point of view: What do we want to achieve? I assume that the original text in 6749 tried to ensure that even if an authz code leaks to an attacker, the attacker (or a client on behalf of the attacker) cannot obtain an access token using this code. To capture this in a (very strong) security property, we could say: Even if the whole authz response leaks to an attacker, including all browser cookies, the attacker must not be able to obtain a token (or make the client obtain a token) with it (after the legitimate user used the code). With the current state of the draft, we can achieve this: We have client authentication and injection prevention (read: PKCE) to prevent any direct use of the code or use of the code in a new session with the client. We further require that each authz response is accepted only once by a client, in particular, we suggest to use a single-use "state" for this purpose. TL;DR: With single-use state and client authentication we do not gain security from single-use codes. I would be fine with relaxing the requirement on single-use codes in 6749. -Daniel --------------22D1FB4A1A320CEA8BBE9563 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 13.11.18 um 17:29 schrieb Brian Campbell:

> Does this "MUST be single-use†not effectively already require the code is invalidated after first use? If so why downgrade this to a “SHOULD�

You are right. My feeling is single use can turn out to be a really hard to implement requirement. That’s why I would like to relax it. Given we now have a stronger requirement on client authentication that should be fine.

Question to the list: what is your implementation experience regarding one time use authorization codes?

There's a bit of discussion about this on this ticket in the Connect WG: https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-single-use FWIW.

I do think that in some systems or architectures it can be difficult to strictly guarantee that a code can only be used once. And it'd be better for specs to come to terms with that rather than being unrealistically strict about it.

We have an AS implementation that does do strict one-time use of the code. But it comes at a cost including some difficulties with resiliency for any particular code. Not to mention some troubleshooting and support issues/questions about it. We haven't gotten to the point of changing anything but have, from time to time, considered changing the implementation approach for code to something that would appear to behave the same but might not 100% guarantee a code could only be used once.

From a security point of view: What do we want to achieve?

I assume that the original text in 6749 tried to ensure that even if an authz code leaks to an attacker, the attacker (or a client on behalf of the attacker) cannot obtain an access token using this code.

To capture this in a (very strong) security property, we could say: Even if the whole authz response leaks to an attacker, including all browser cookies, the attacker must not be able to obtain a token (or make the client obtain a token) with it (after the legitimate user used the code).

With the current state of the draft, we can achieve this: We have client authentication and injection prevention (read: PKCE) to prevent any direct use of the code or use of the code in a new session with the client. We further require that each authz response is accepted only once by a client, in particular, we suggest to use a single-use "state" for this purpose.

TL;DR: With single-use state and client authentication we do not gain security from single-use codes.

I would be fine with relaxing the requirement on single-use codes in 6749.

-Daniel


--------------22D1FB4A1A320CEA8BBE9563-- From nobody Thu Nov 15 01:48:42 2018 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 E3D3E1252B7 for ; Thu, 15 Nov 2018 01:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 xAzqhqTvTHyv for ; Thu, 15 Nov 2018 01:48:37 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 6E9DB12D4ED for ; Thu, 15 Nov 2018 01:48:36 -0800 (PST) Received: from [88.128.80.129] (helo=[172.29.250.147]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gNEGH-0001Ee-Hk; Thu, 15 Nov 2018 10:48:33 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_00C839F0-5B78-457C-9187-759A5F0055FD"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Thu, 15 Nov 2018 10:48:32 +0100 In-Reply-To: To: oauth References: <154175237636.14370.2795740097592534192@ietfa.amsl.com> <399248B5-A485-456E-B57C-FCD91FE77AC2@lodderstedt.net> <062837A8-2737-482E-A304-9B7065D73BCD@authlete.com> <1F60828E-B714-487F-A812-3C68FF54385F@lodderstedt.net> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.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: Thu, 15 Nov 2018 09:48:41 -0000 --Apple-Mail=_00C839F0-5B78-457C-9187-759A5F0055FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, here is the respective text proposal for section 2.1. (Note: we also = refactored the text in order to disentangle CSRF/replay and mix-up = detection). ---- Clients MUST prevent CSRF and ensure that each authorization response is = only accepted once. One-time use CSRF tokens carried in the state = parameter, which are securely bound to the user agent, SHOULD be used = for that purpose. In order to prevent mix-up attacks, clients MUST only process redirect = responses of the OAuth authorization server they send the respective = request to and from the same user agent this authorization request was = initiated with. Clients MUST memorize which authorization server they = sent an authorization request to and bind this information to the user = agent and ensure any sub-sequent messages are sent to the same = authorization server. Clients SHOULD use AS-specific redirect URIs as a = means to identify the AS a particular response came from. ---- kind regards, Torsten.=20 > Am 14.11.2018 um 09:26 schrieb Daniel Fett : >=20 > Am 13.11.18 um 17:29 schrieb Brian Campbell: >>=20 >> > Does this "MUST be single-use=E2=80=9D not effectively already = require the code is invalidated after first use? If so why downgrade = this to a =E2=80=9CSHOULD=E2=80=9D? >>=20 >> You are right. My feeling is single use can turn out to be a really = hard to implement requirement. That=E2=80=99s why I would like to relax = it. Given we now have a stronger requirement on client authentication = that should be fine.=20 >>=20 >> Question to the list: what is your implementation experience = regarding one time use authorization codes? >>=20 >> There's a bit of discussion about this on this ticket in the Connect = WG: = https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override= -single-use FWIW. >>=20 >> I do think that in some systems or architectures it can be difficult = to strictly guarantee that a code can only be used once. And it'd be = better for specs to come to terms with that rather than being = unrealistically strict about it. >>=20 >> We have an AS implementation that does do strict one-time use of the = code. But it comes at a cost including some difficulties with resiliency = for any particular code. Not to mention some troubleshooting and support = issues/questions about it. We haven't gotten to the point of changing = anything but have, from time to time, considered changing the = implementation approach for code to something that would appear to = behave the same but might not 100% guarantee a code could only be used = once.=20 > =46rom a security point of view: What do we want to achieve? >=20 > I assume that the original text in 6749 tried to ensure that even if = an authz code leaks to an attacker, the attacker (or a client on behalf = of the attacker) cannot obtain an access token using this code. >=20 > To capture this in a (very strong) security property, we could say: = Even if the whole authz response leaks to an attacker, including all = browser cookies, the attacker must not be able to obtain a token (or = make the client obtain a token) with it (after the legitimate user used = the code). >=20 > With the current state of the draft, we can achieve this: We have = client authentication and injection prevention (read: PKCE) to prevent = any direct use of the code or use of the code in a new session with the = client. We further require that each authz response is accepted only = once by a client, in particular, we suggest to use a single-use "state" = for this purpose. >=20 > TL;DR: With single-use state and client authentication we do not gain = security from single-use codes. >=20 > I would be fine with relaxing the requirement on single-use codes in = 6749.=20 >=20 > -Daniel >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_00C839F0-5B78-457C-9187-759A5F0055FD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTUwOTQ4MzJaMC8GCSqGSIb3DQEJBDEiBCAP KRB5QM3gIP769VGlB+OuGQNFMXXvp7ZAcPDYH2WaCDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEADdak6hJlGiR2g5AWLsj4SH9F X7r7ooO4HIldHpNfcSbCkh/QAdYWFQH5FROCl3STCrL3FV287o0WycmhhaZ80403KD7QNexDxLkF 9uNduzchejJIUJM+Fs0VaXpP5g7nEurSvW8zYl4CwgFDVB9K+CUNsWhpI1VuA2VI4yr1q3Rts5VV Kgk+91sFgap1FcmLqp2q6vAcgMxzuBQeqjautMEz9DSWcNDLE3fchDSXZ6BdlyyvW1ZmOFsWLYES aLubE0kpACJ/BzsSN/armNbngG4PtM0VVD7F8YERW/rpMzaYDJjTEeF4PmEtXtFfEqG3oRHHHEzL zRColsbAJjUfrgAAAAAAAA== --Apple-Mail=_00C839F0-5B78-457C-9187-759A5F0055FD-- From nobody Thu Nov 15 06:01:36 2018 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 5C564129385 for ; Thu, 15 Nov 2018 06:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 q9GhqVch-NiH for ; Thu, 15 Nov 2018 06:01:32 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C0571128CFD for ; Thu, 15 Nov 2018 06:01:31 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id q70so14341428qkh.6 for ; Thu, 15 Nov 2018 06:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=1Hs9kuE9LvrFXk0Ph6ngcV65SqDewFUpUHAHa4dqcHg=; b=H5hxFPAwOW/3MBgMBOo6Q2cVGDWublBZ/nLZO1VeoxKLrYZ13/qUphGuFddI+rwJIC F569AkS2JAYGbzcZhdTIdO85zPG9XkbJwygBLpFuBtMicWZthhpmePo2zCu8Vs/yNAjY GNq2VtKo7Nsz7LERPxyqkjijL7cf9nmMO1+N82UVyVPdPdgrEX3tscO651zWQP5FTKRF MoNkyGLI97/J75K6nn+KNtKB+uGozZLWjdemOHgFFMT/Wa8ZsVg3NZD10OYp1wmvC/4N tGLG67Pmhp7PJacfPxwyAOKvpjctv84ekEibtiVtG3lTknzmSFX/iXyJiKfy5mlRleGt KtKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=1Hs9kuE9LvrFXk0Ph6ngcV65SqDewFUpUHAHa4dqcHg=; b=J7a+y8rOC7DLS+Oc/58ZTpyeuZIMG0M4PTOYVfRJKzw0Fr3zTH0EMnjE1kp0yBKBL+ nmot34fNBBdMGsYRHf5si1z3DSvRm8gVFBUEN3GXh0cBRY7VCG6916IMTgLtSTKX61a+ pC+ClhTmGRV6/2anjj9V/5zQnOfbZ6eYRVQwM6GmgX+SGnlv/T+dCNXv4f/60ulLW1fn 5xw1BmWGNYzWnnhf2VcbfM0JdWwBVddhjdQGDDF89e+a2a5gfEicofgeFKOX1dOR6ygo w2UOxp8MhLo/mMac2gJwi/8dwdtlI/ED3qvb2Jynz97m0x2IyClEJhNyLga/WuIeW7sC KkIg== X-Gm-Message-State: AGRZ1gLDcbL+umaYhapx36xjK2p9NeZuA+3qK2WNxLjBvTdd5nn5nZJb D+/lCiEio2c5h8w9ERpp5sF5OxKC X-Google-Smtp-Source: AJdET5fiYpzxCpknhoyS+enefxgpWJMy4CvuQ4m4OAB3gXxTIGpRggwPnQKS+DxDj46T6bLr3q6C6g== X-Received: by 2002:ac8:44d3:: with SMTP id b19mr6211639qto.107.1542290490675; Thu, 15 Nov 2018 06:01:30 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id q5sm17390756qtq.20.2018.11.15.06.01.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 06:01:30 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_51060598.470372800206" MIME-Version: 1.0 Date: Thu, 15 Nov 2018 09:01:27 -0500 Message-ID: <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> From: "Brock Allen" To: "Torsten Lodderstedt" Cc: "Aaron Parecki" , "Hannes Tschofenig" , "" In-Reply-To: <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> User-Agent: Mailbird/2.5.23.0 X-Mailbird-ID: 27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 15 Nov 2018 14:01:35 -0000 ------=_NextPart_51060598.470372800206 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0Helps to prevent leakage, not injection in the authorization respons= e. So then wording and its motivation could get updated to correctly reflect t= hat. >> "OAuth 2.0 provides no mechanism for a client to verify that an access t= oken was issued to it, which could lead to misuse and possible impersonatio= n attacks if a malicious party hands off an access token it retrieved throu= gh some other means to the client." >>=C2=A0 >> Sure, but OIDC does provide a mitigation for this (even with implicit). > >This is about token replay detection at the RS. What mitigation does OIDC = provide here?=C2=A0 The wording doesn't go with that, then. My point about OIDC is that with th= e at_hash in the id_token provides a mitigation so the client can verify th= at the access token was issued to it. >=C2=A0The implicit grant was not equipped with the ability to issue refres= h tokens simply because the working group didn=E2=80=99t want them to end u= p in the browser history, leak through open redirectors etc. This is differ= ent with code since tokens travel directly through a TLS protected connecti= on. Well, if limiting the access token renewal to the user's session lifetime w= asn't a=C2=A0conscious=C2=A0design goal, it's a very interesting side=C2=A0= effect which does limit the potential of an attacker. >=C2=A0First of all the AS decides whether it issues refresh tokens or not.= Having the ability does not mean the AS must do it. If you feel it=E2=80= =99s safer to not do it. Fine.=C2=A0 Sure, and this should be mentioned then somewhere (either in the threats do= c or in this proposed best practice doc). Not all end developers using thes= e protocols fully understand the ramifications.=C2=A0 > It=E2=80=99s still possible to refresh your access tokens the way you men= tioned above by sending another authorization request to the AS.=C2=A0 This also could be added as a proposal for an alternative to renewing token= s. It provides more awareness to folks, and aids in a potential best practi= ce depending on the requirements of the consuming app. >=C2=A0But let=E2=80=99s assume for a moment the AS, based on its risk asse= ssment, decides to issue refresh tokens. Can you please explain how an atta= cker will get access to this tokens? Especially what the expected strength = of the attacker would need to be? I don't have a profile of an attack. But I'm assuming it's no different tha= n anything in the past we've been trying to defend against when we consider= ed the potential for an access token to be exfiltrated. So my point is that= an access token will expire so an attacker would then have to go back and = re-attack the app to get a new access token to continue to have access to t= he user's resource. But now with refresh tokens in the picture, the attacke= r would have both and then not need to go back to the app to continue to ha= ve access to the user's resource.=C2=A0 >=C2=A0I would also like to understand how a refresh token is any different= from a long living cookie in the browser and what you think is the big dif= ference to mobile apps when it comes to refresh token handling.=C2=A0 To use the cookie, the app must be active, and the attacker must be attacki= ng the app itself. Maybe a different way to say it is that an attacker must only compromise th= e app once to have long lived access, whereas without refresh tokens the at= tacker can attack the app once, but the once the=C2=A0comprised=C2=A0access= token is expired they would have to re-attack the app to get another acces= s token.=C2=A0Refresh tokens means they only have to get in once to the app= , then they no longer have to go back to the source. Maybe there's a better= way to convey what I'm trying to say... Also, I guess my question/comment about providing guidance for existing imp= licit flow clients is not up for discussion? Again, my reasoning is that it= 's a hard sell to always say there's exactly one right way to do something.= And since so many clients have been built based on implicit flow that migh= t not be able to change quickly to a new flow, perhaps there are "baby step= s" that can be suggested to help them improve their security. -Brock ------=_NextPart_51060598.470372800206 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
> = ;Helps to prevent l= eakage, not injection in the authorization response.

So then wording and its motivation = could get updated to correctly reflect that.
=0A = =0A =0A = =0A = =0A =0A =

>> "OAuth 2.0 provides no mechanism for= a client to verify that an access token was issued to it, which could lead= to misuse and possible impersonation attacks if a malicious party hands of= f an access token it retrieved through some other means to the client."
= >> 
>> Sure, but OIDC does provide a mitigation for thi= s (even with implicit).
>
>This is about token replay detection= at the RS. What mitigation does OIDC provide here? 

The wording doesn't go with that, then. My point about OIDC is tha= t with the at_hash in the id_token provides a mitigation so the client can = verify that the access token was issued to it.

>= ; The implicit grant = was not equipped with the ability to issue refresh tokens simply because th= e working group didn=E2=80=99t want them to end up in the browser history, = leak through open redirectors etc. This is different with code since tokens= travel directly through a TLS protected connection.

Well, if limiting the access token = renewal to the user's session lifetime wasn't a conscious design goal, it's a very i= nteresting side effect which does limit the potential of an attacker.<= /span>

> F= irst of all the AS decides whether it issues refresh tokens or not. Having = the ability does not mean the AS must do it. If you feel it=E2=80=99s safer= to not do it. Fine. 

Sure, and this shoul= d be mentioned then somewhere (either in the threats doc or in this propose= d best practice doc). Not all end developers using these protocols fully un= derstand the ramifications. 

> It=E2=80= =99s still possible to refresh your access tokens the way you mentioned abo= ve by sending another authorization request to the AS. 

This also could be added as a proposal for an alternative t= o renewing tokens. It provides more awareness to folks, and aids in a poten= tial best practice depending on the requirements of the consuming app.

> But let=E2=80=99s assume for a moment the AS, based on its risk assess= ment, decides to issue refresh tokens. Can you please explain how an attack= er will get access to this tokens? Especially what the expected strength of= the attacker would need to be?

I don't have a profile of an attack. But I'm assuming it= 's no different than anything in the past we've been trying to defend again= st when we considered the potential for an access token to be exfiltrated. = So my point is that an access token will expire so an attacker would then h= ave to go back and re-attack the app to get a new access token to continue = to have access to the user's resource. But now with refresh tokens in the p= icture, the attacker would have both and then not need to go back to the ap= p to continue to have access to the user's resource. 

> I would also like to understand how a= refresh token is any different from a long living cookie in the browser an= d what you think is the big difference to mobile apps when it comes to refr= esh token handling. 

To use the cookie, the app must be active, and the attacker mu= st be attacking the app itself.

Maybe a different way to say it is that an attacker must= only compromise the app once to have long lived access, whereas without re= fresh tokens the attacker can attack the app once, but the once the comprised access token is exp= ired they would have to re-attack the app to get another access token. = ;Refresh tokens mea= ns they only have to get in once to the app, then they no longer have to go= back to the source. Maybe there's a better way to convey what I'm trying t= o say...

Also, I guess my question/comment = about providing guidance for existing implicit flow clients is not up for d= iscussion? Again, my reasoning is that it's a hard sell to always say there= 's exactly one right way to do something. And since so many clients have be= en built based on implicit flow that might not be able to change quickly to= a new flow, perhaps there are "baby steps" that can be suggested to help t= hem improve their security.

-Brock

=0A = =0A =
------=_NextPart_51060598.470372800206-- From nobody Thu Nov 15 06:28:42 2018 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 3CD6012D4E7 for ; Thu, 15 Nov 2018 06:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 dE84ZmFF7Jrp for ; Thu, 15 Nov 2018 06:28:37 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) (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 68A1712785F for ; Thu, 15 Nov 2018 06:28:37 -0800 (PST) Received: from [80.187.102.148] (helo=[10.202.3.155]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gNIdG-00026s-AP for oauth@ietf.org; Thu, 15 Nov 2018 15:28:34 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary=Apple-Mail-A9A195D7-2950-42E8-B976-A0BD0F12D3BC; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Thu, 15 Nov 2018 15:28:32 +0100 Message-Id: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net> To: oauth@ietf.org X-Mailer: iPhone Mail (16B92) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Refresh Token Expiration 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, 15 Nov 2018 14:28:40 -0000 --Apple-Mail-A9A195D7-2950-42E8-B976-A0BD0F12D3BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I=E2=80=98m preparing a new section on Refresh Token best practices for the S= ecurity BCP. I=E2=80=98m wondering whether anyone has implemented a binding o= f the refresh token=E2=80=98s expiration/revocation with the state of the se= ssion the refresh token was issued in/for. So do you revoke refresh tokens w= hen the user logs out from the AS or the session terminated for other reason= s? kinds regards, Torsten.= --Apple-Mail-A9A195D7-2950-42E8-B976-A0BD0F12D3BC Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTE1MTQyODMzWjAvBgkqhkiG 9w0BCQQxIgQgdVQi6KghXXVJP/n2w7m9i9OoX+WitifJdkgHN5T6BT8wgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAKu/ 4UlVokuo7DNOoqOLQahDxqJwIJ2Md98ElSLx1RRTKw5TIv94L3nikXcSwZU5gONanzKr+1fYaLGQ qr4CjGQmQl+6YOIz4ZnmqLJAe8RxlTVYANTI7uWNRBO45wkPw5raCAAmPnTpepvwiDp1Y0SRc9XE pxUM6mALNeLZtXU4PS0t6R81hM5fhHd+HD7NmiDjJcfpVJQi9/KZsyqUZ5vjMC4bMqI7X+eaU+xP wNG9Wf1TuMzdT6NTHEbMF2dLzxHlLyaWFpL0tEmLY9wprU28TL0/4gq8VMZINCVvR1ZOKZOzV04/ 4/L2A1SEfXr2WBR48ydgZzXRW4D9GI0J+7oAAAAAAAA= --Apple-Mail-A9A195D7-2950-42E8-B976-A0BD0F12D3BC-- From nobody Thu Nov 15 07:36:26 2018 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 A3F9E130DD9 for ; Thu, 15 Nov 2018 07:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EYZdx_f55w4G for ; Thu, 15 Nov 2018 07:36:22 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0: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 6B832130DD3 for ; Thu, 15 Nov 2018 07:36:22 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id v6so4757850oif.2 for ; Thu, 15 Nov 2018 07:36: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=tFjY82khXOKZTlau4FEtSshW+/Rze8Gi4OD6t35cz34=; b=pqvLMBGWcFlJlJR9u9VEQC9+SVH03r/heftg4ou8AEXoY4cpwEMkdJB1no6Xxtm5I6 aCHYJ7jLwTmdxrPaNr7vutMTOERZlkEpOE4mREbinv9YJxv5Y8TUfBn2bahORb+zMYFD DpDWq5EMy6+rSYHRIVTZKXxQY5VookoZeyZeDHgWK/BKa0g329iKO1LaYiFk9xdUdZ92 C+30hRL/hn1uRyLKz8KfS9ICgbxVovA6eoHThkxH8FgrFERRdYpklSSTxmKf9DxyEJzR pH6S7qH4nK7Q2UhlBI53lskhcq6Sy18n77hfhewuvzeFPfe12cwl3RbZcEoh86Y1OVX0 W6Bg== 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=tFjY82khXOKZTlau4FEtSshW+/Rze8Gi4OD6t35cz34=; b=THAmOT0v5kGaJTOOFBZJKgRSu3QiKsYCazOu9uOqbb2HYZnuj7SynuDM/slkrpAFwa lMC8kTZzGjnlx4W5lSP+3fK/6dMMFu7mOkLw4y6y9+Pn/RQvTulHRsyW5xJSmHe2UP07 QwysMpzNqmbHFhpnftzHDwIkSzCXaD5tzx2dzNrhJeaLVG1O6jbT1EuCssMbVHRG2RcB gHdsc2OsJ+Qtagiyp9/2OR3WwU219MRfKe7yUfmtQVF1s242AnqD2p/x7Nid13cEqAva wnnlUgHOJ/Nm0EHSK+fPSG6Q0I5nLs1Ozpny2qr15jk63AVz735PI+EkhLQ0k34dEkEV mpIg== X-Gm-Message-State: AGRZ1gJ1mtXAmIjlDyDmS6lhrriLA25641RymP08CAYUvZMumiuuFspb mUSIQQ7bbFJO0+Lhf9aRHY17iml3TPlFd1kgs58w1Q== X-Google-Smtp-Source: AJdET5cL+1pj7wSsUBcPNgJxTf6G/sKPigKMK0nJZlGxchj6Gf9QxF6hWAwYN2txEiH2VW3xw2EKH9x70bA/swkWcJk= X-Received: by 2002:aca:abcd:: with SMTP id u196mr3978371oie.29.1542296181602; Thu, 15 Nov 2018 07:36:21 -0800 (PST) MIME-Version: 1.0 References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net> In-Reply-To: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net> From: Thomas Broyer Date: Thu, 15 Nov 2018 16:36:10 +0100 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000b241b057ab5d05e" Archived-At: Subject: Re: [OAUTH-WG] Refresh Token Expiration 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, 15 Nov 2018 15:36:25 -0000 --0000000000000b241b057ab5d05e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fwiw, this is something I thought about for Ozwillo but never ended up implementing (though that still could happen): always issuing a refresh token (vs. only when scope includes offline_access nowadays) but bind its lifetime to the session when not offline_access. I would then revoke the refresh token on logout (like I already do for access tokens), on session timeouts (this would mean, for me, extending the refresh tokens' expiry whenever I extend the session expiry), or whenever the session is terminated (e.g. password change). The reason I was contemplating this is that some clients/RPs find it hard to integrate their apps with OpenID Connect / OAuth because they need to redirect the users to "refresh" the access tokens, and this is not practical when processing a POST request (e.g. form submission). The reason I haven't done it yet is that it's been a while since I heard back from clients on that topic ;-) (though most of them actually simply use OpenID Connect, and don't make calls to protected resources afterwards). Others might be using Session Management (will have to check logs, though I doubt it), which means always having a valid access token as a side-effect. On Thu, Nov 15, 2018 at 3:28 PM Torsten Lodderstedt wrote: > Hi all, > > I=E2=80=98m preparing a new section on Refresh Token best practices for t= he > Security BCP. I=E2=80=98m wondering whether anyone has implemented a bind= ing of the > refresh token=E2=80=98s expiration/revocation with the state of the sessi= on the > refresh token was issued in/for. So do you revoke refresh tokens when the > user logs out from the AS or the session terminated for other reasons? > > kinds regards, > Torsten._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000000b241b057ab5d05e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fwiw, this is something I thought about for Ozwillo but ne= ver ended up implementing (though that still could happen): always issuing = a refresh token (vs. only when scope includes offline_access nowadays) but = bind its lifetime to the session when not offline_access. I would then revo= ke the refresh token on logout (like I already do for access tokens), on se= ssion timeouts (this would mean, for me, extending the refresh tokens' = expiry whenever I extend the session expiry), or whenever the session is te= rminated (e.g. password change).
The reason I was contemplating this is= that some clients/RPs find it hard to integrate their apps with OpenID Con= nect / OAuth because they need to redirect the users to "refresh"= the access tokens, and this is not practical when processing a POST reques= t (e.g. form submission).
The reason I haven't done it yet is= that it's been a while since I heard back from clients on that topic ;= -) (though most of them actually simply use OpenID Connect, and don't m= ake calls to protected resources afterwards). Others might be using Session= Management (will have to check logs, though I doubt it), which means alway= s having a valid access token as a side-effect.

On Thu, Nov 15, 2018 at 3:28 PM Torsten L= odderstedt <torsten@lodderste= dt.net> wrote:
Hi all,

I=E2=80=98m preparing a new section on Refresh Token best practices for the= Security BCP. I=E2=80=98m wondering whether anyone has implemented a bindi= ng of the refresh token=E2=80=98s expiration/revocation with the state of t= he session the refresh token was issued in/for. So do you revoke refresh to= kens when the user logs out from the AS or the session terminated for other= reasons?

kinds regards,
Torsten._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000000b241b057ab5d05e-- From nobody Thu Nov 15 12:58:28 2018 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 7EBB2130DE4 for ; Thu, 15 Nov 2018 12:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 7ylTbx1wtGZt for ; Thu, 15 Nov 2018 12:58:22 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 9248B130DD8 for ; Thu, 15 Nov 2018 12:58:22 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gNOiQ-00053y-Np; Thu, 15 Nov 2018 21:58:18 +0100 From: Torsten Lodderstedt Message-Id: <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_E820659C-4CDF-4324-AEE7-B99A956F3012"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Thu, 15 Nov 2018 20:27:07 +0100 In-Reply-To: <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> Cc: Aaron Parecki , Hannes Tschofenig , oauth@ietf.org To: Brock Allen References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 15 Nov 2018 20:58:27 -0000 --Apple-Mail=_E820659C-4CDF-4324-AEE7-B99A956F3012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brock,=20 > Am 15.11.2018 um 15:01 schrieb Brock Allen : >=20 > > Helps to prevent leakage, not injection in the authorization = response. >=20 > So then wording and its motivation could get updated to correctly = reflect that. >=20 > >> "OAuth 2.0 provides no mechanism for a client to verify that an = access token was issued to it, which could lead to misuse and possible = impersonation attacks if a malicious party hands off an access token it = retrieved through some other means to the client." > >>=20 > >> Sure, but OIDC does provide a mitigation for this (even with = implicit). > > > >This is about token replay detection at the RS. What mitigation does = OIDC provide here?=20 >=20 > The wording doesn't go with that, then. My point about OIDC is that = with the at_hash in the id_token provides a mitigation so the client can = verify that the access token was issued to it. Understand, you are referring to the token injection prevention provided = by =E2=80=9Etoken id_token=E2=80=9C or =E2=80=9Ecode token id_token=E2=80=9C= . It still lacks the ability to issue sender constraint access tokens. = So if you wanna take the risk associated with bearer tokens you can use = it. The Security BCP recommends to use sender constraint access tokens, = so we cannot recommend response types not supporting this pattern.=20 >=20 > > The implicit grant was not equipped with the ability to issue = refresh tokens simply because the working group didn=E2=80=99t want them = to end up in the browser history, leak through open redirectors etc. = This is different with code since tokens travel directly through a TLS = protected connection. >=20 > Well, if limiting the access token renewal to the user's session = lifetime wasn't a conscious design goal, it's a very interesting side = effect which does limit the potential of an attacker. That=E2=80=99s true. Note that the effectiveness of limitation depends = on the lifetime of the issued access tokens.=20 The AS can bind the lifetime of the refresh tokens to the session = lifetime, i.e. automatically revoke it on logout.=20 In my opinion, whether this is the most appropriate choice largely = depends on what the client uses the token for. If the client effectively = relies on the AS (OP) to login the user and obtain user data that makes = sense. If the client has an independent login and uses the tokens to = access resources (e.g. contacts), the session with the AS does not have = a real meaning with respect to this client. Potentially the client even = stores the refresh token in a backend with the user account.=20 >=20 > > First of all the AS decides whether it issues refresh tokens or not. = Having the ability does not mean the AS must do it. If you feel it=E2=80=99= s safer to not do it. Fine.=20 >=20 > Sure, and this should be mentioned then somewhere (either in the = threats doc or in this proposed best practice doc). Not all end = developers using these protocols fully understand the ramifications.=20 @Aaron: I suggest this goes to the SPA BCP since this is client = specific. >=20 > > It=E2=80=99s still possible to refresh your access tokens the way = you mentioned above by sending another authorization request to the AS.=20= >=20 > This also could be added as a proposal for an alternative to renewing = tokens. It provides more awareness to folks, and aids in a potential = best practice depending on the requirements of the consuming app. I agree.=20 >=20 > > But let=E2=80=99s assume for a moment the AS, based on its risk = assessment, decides to issue refresh tokens. Can you please explain how = an attacker will get access to this tokens? Especially what the expected = strength of the attacker would need to be? >=20 > I don't have a profile of an attack. But I'm assuming it's no = different than anything in the past we've been trying to defend against = when we considered the potential for an access token to be exfiltrated. = So my point is that an access token will expire so an attacker would = then have to go back and re-attack the app to get a new access token to = continue to have access to the user's resource. But now with refresh = tokens in the picture, the attacker would have both and then not need to = go back to the app to continue to have access to the user's resource.=20 Largely depends on the refresh token protection. I case of public = clients I would always recommend to rotation refresh tokens with every = refresh. This renders the old refresh tokens useless. If the attacker = happens to be at the lucky end and conducts the first refresh, the AS = should be able to detect the replay when the legit user tries to = refresh. It then shall revoke the active (in possession of the attacker) = refresh token as well.=20 I will add this to the Security BCP. >=20 > > I would also like to understand how a refresh token is any different = from a long living cookie in the browser and what you think is the big = difference to mobile apps when it comes to refresh token handling.=20 >=20 > To use the cookie, the app must be active, and the attacker must be = attacking the app itself. >=20 > Maybe a different way to say it is that an attacker must only = compromise the app once to have long lived access, whereas without = refresh tokens the attacker can attack the app once, but the once the = comprised access token is expired they would have to re-attack the app = to get another access token. Refresh tokens means they only have to get = in once to the app, then they no longer have to go back to the source. = Maybe there's a better way to convey what I'm trying to say=E2=80=A6 I think I understand. Refresh tokens can be used outside of the user = agent. Token rotation and expiration would be potential mitigations, = token binding too. >=20 > Also, I guess my question/comment about providing guidance for = existing implicit flow clients is not up for discussion? Again, my = reasoning is that it's a hard sell to always say there's exactly one = right way to do something. And since so many clients have been built = based on implicit flow that might not be able to change quickly to a new = flow, perhaps there are "baby steps" that can be suggested to help them = improve their security. The only potential =E2=80=9Ebaby step=E2=80=9C I would see is to move = towards =E2=80=9Etoken id_token=E2=80=9C. Since this requires = signature/at_hash checks etc. I doubt this is really easier than moving = to code and exchange the code for an access token. What=E2=80=99s your = opinion? kind regards, Torsten.=20 >=20 > -Brock >=20 --Apple-Mail=_E820659C-4CDF-4324-AEE7-B99A956F3012 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTUxOTI3MDhaMC8GCSqGSIb3DQEJBDEiBCAG t3FJa1GX8ss3iZ8Hu9hb5deOBGHeHoeEidxITKls5jCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEARBJnVQ/z+5v++KTu4KcU41ek z6AHbQqp2loSsORgUrNNjutatvlnlmgZ9XuBULXor76ZMiIfC5jx80gY3LhkqV1/Z1F/jzYleb9f rtUMGh/9jVbE5Vgng6808cMWQiVYN6QII6mDv+BbZr/KbSPeC1AT9Ug6VaDM4QO++7gjvgcT5uGd hH2TJ/jho+kwYOUqnxpH3+++9x7ztT8IfLD0TIuDJmtchyU51ffAfJuXPOX+825SWtCRpmNNfFX3 1cXhcxC3hb2al2q6Faf/u57M/q2/tkdwbUSJU7u9GE9RqfzkiE03ivJfEmFtH/+xJj2yuDWqqpSz S1qOI1qZSoMqOAAAAAAAAA== --Apple-Mail=_E820659C-4CDF-4324-AEE7-B99A956F3012-- From nobody Thu Nov 15 14:01:19 2018 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 B1996130ECA for ; Thu, 15 Nov 2018 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 7ya7P1LElJfC for ; Thu, 15 Nov 2018 14:01:16 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB00F130EC7 for ; Thu, 15 Nov 2018 14:01:15 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id q70so16838781qkh.6 for ; Thu, 15 Nov 2018 14:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=Yavoz46N2Cy976B8I49QXfIsjtZVT/GTXabpB+lRICg=; b=ldBoF3r7+iohz0pvRHSUjaSTvv3PHRMvccbc1merh+kD8P54whjEcsSgI/XuIZb5WB LKP5lBlDl2y6GhaBkwULtU4UidLwR0eNyW3yEGOZNkgR6Kp8/BFyfetYcfbm3XGMuoFG lUKL/aa2jS4U4uiWtp/bmjrQiM5ndKOJNOzgdkm0c1yQZBKL5CsLYANXoF0/Rdsmpnm9 pfnPxNTQZnQolJYTL7DHUO5vYLIiOwFOYibQdEc7BOQlGOl34fKCqZe3vv8HsizcOvLM uIzOZnbf3r9qmvZNZFM1GM1AjKSAH1L1cwnWkmslyGQ7oBFtCtfxdxZ7wgozZZUO2Txv lmlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=Yavoz46N2Cy976B8I49QXfIsjtZVT/GTXabpB+lRICg=; b=ptA51hB0Sc8+2xNLDIwPqsnJmy00Srtw0lj7eao/BdHasfz+9TJj5EJaayDD/teztw 9bm0dWslEZf6jhkEqFSpIFPq1A0wV5DhNe8nFJ8SQSPxRcVAiGdIqnOk67/Dtlbgv1yZ zsJeXuUqGE+Prn3tBpkIncTwY9nBEMFncQh2L/LC1MAPeAdSVE9z67RT7/qos3uFPCuL Tdiumk6uNW2+2XIU1O2wTiaqjZSyml07Nyen7XWRQBzb/gxUdNm9aSYFF1l4HJclSlkA m7il09w2MPHP+ALybXkPaYT5UGFWlX4yq3SFepxnnAEFimd+aEWMduehogTQy/Mzb1F2 gpow== X-Gm-Message-State: AGRZ1gJ9hXYXULdZ7MhM0akdXgCtQdjFfp+ltjskneK78RxXxX/ELK+c TDI/aLpmhA6YLHaZ8z5CPvapdb75 X-Google-Smtp-Source: AJdET5dYPwWrdOo2XxTsCYuIRgBWk6G/2ROZh9jxCyGYwQEaj+XRxwcrxCHbGPJYBa5gIPikWk69BA== X-Received: by 2002:a0c:f0c2:: with SMTP id d2mr7901175qvl.123.1542319274760; Thu, 15 Nov 2018 14:01:14 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id k6sm6572598qkk.60.2018.11.15.14.01.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 14:01:13 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_49816796.133433135323" MIME-Version: 1.0 Date: Thu, 15 Nov 2018 17:01:10 -0500 Message-ID: <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> From: "Brock Allen" To: "Torsten Lodderstedt" Cc: "Aaron Parecki" , "Hannes Tschofenig" , "" In-Reply-To: <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> User-Agent: Mailbird/2.5.23.0 X-Mailbird-ID: 64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 15 Nov 2018 22:01:18 -0000 ------=_NextPart_49816796.133433135323 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0It still lacks the ability to issue sender constraint access tokens. So you mean at the resource server ensuring the token was really issued to = the client? Isn't that an inherent limitation of all bearer tokens (modulo = HTTP token binding, which is still some time off)? Resource servers don't k= now the flow the clients might use, especially if/when they have many clien= ts. >=C2=A0The AS can bind the lifetime of the refresh tokens to the session li= fetime, i.e. automatically revoke it on logout. Yea, I saw your other email asking about refresh token revocation relating = to session management. Obviously for certain clients, this won't make sense= , but for implicit/browser-based ones it's a nice feature to have. The alternative, as you mentioned, is to not issue refresh tokens and do to= ken renewal the "same old way" via iframe with prompt=3Dnone, while still u= sing code flow. >=C2=A0The only potential =E2=80=9Ebaby step=E2=80=9C I would see is to mov= e towards =E2=80=9Etoken id_token=E2=80=9C. Since this requires signature/a= t_hash checks etc. I doubt this is really easier than moving to code and ex= change the code for an access token. What=E2=80=99s your opinion? Even since OIDC arrived, this is the only flow I use for JS/browser-based c= lients (anything less has always seemed so obviously inferior). So for me a= nd my customers, all browser-based clients I am involved in are already the= re. Perhaps this is the reason for all of my questions/comments about the r= ecent BCP doc. Given "id_token token", CSP, and using the browser history A= PI to wipe the access token from browser history, we already have a decent = set of tools to mitigate attacks. As I already conceded, the only remaining= issue (IMO) is the short window of time the access token is in the URL. Given that it seems to me that OIDC and OAuth2 are typically used together= =C2=A0(at least when a user is involved with authentication), I always wond= er=C2=A0why the OAuth and OIDC WGs are separate. Given that so much effort = of the two sets of specs overlap, it seems odd to keep adding onto the OAut= h specs and ignoring the added features that OIDC provides. I don't mean to= derail this thread, or step on any political toes, so apologies in advance. -Brock ------=_NextPart_49816796.133433135323 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;It still lacks the ability to issue sender= constraint access tokens.

So you mean at the res= ource server ensuring the token was really issued to the client? Isn't that= an inherent limitation of all bearer tokens (modulo HTTP token binding, wh= ich is still some time off)? Resource servers don't know the flow the clien= ts might use, especially if/when they have many clients.

> The AS can bind the lifeti= me of the refresh tokens to the session lifetime, i.e. automatically revoke= it on logout.

Yea, I saw your other email a= sking about refresh token revocation relating to session management. Obviou= sly for certain clients, this won't make sense, but for implicit/browser-ba= sed ones it's a nice feature to have.

The alternat= ive, as you mentioned, is to not issue refresh tokens and do token renewal = the "same old way" via iframe with prompt=3Dnone, while still using code fl= ow.

> The on= ly potential =E2=80=9Ebaby step=E2=80=9C I would see is to move towards =E2= =80=9Etoken id_token=E2=80=9C. Since this requires signature/at_hash checks= etc. I doubt this is really easier than moving to code and exchange the co= de for an access token. What=E2=80=99s your opinion?

Even since OIDC arrived, this is th= e only flow I use for JS/browser-based clients (anything less has always se= emed so obviously inferior). So for me and my customers, all browser-based = clients I am involved in are already there. Perhaps this is the reason for = all of my questions/comments about the recent BCP doc. Given "id_token toke= n", CSP, and using the browser history API to wipe the access token from br= owser history, we already have a decent set of tools to mitigate attacks. A= s I already conceded, the only remaining issue (IMO) is the short window of= time the access token is in the URL.

Given that it seems to me that OIDC and OAuth2 are= typically used together (at least when a user is involved with authentication), I always wonder = why the OAuth and O= IDC WGs are separate. Given that so much effort of the two sets of specs ov= erlap, it seems odd to keep adding onto the OAuth specs and ignoring the ad= ded features that OIDC provides. I don't mean to derail this thread, or ste= p on any political toes, so apologies in advance.


-Brock

=0A = =0A
------=_NextPart_49816796.133433135323-- From nobody Thu Nov 15 16:41:45 2018 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 3DD56130E08 for ; Thu, 15 Nov 2018 16:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ivqoCkZCzdr for ; Thu, 15 Nov 2018 16:41:41 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 56A8B128B14 for ; Thu, 15 Nov 2018 16:41:41 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id 189so34901064qkj.8 for ; Thu, 15 Nov 2018 16:41:41 -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:content-transfer-encoding; bh=KRvtt9AgsCChro1qgMQb+k+PLTTcWeWXpsLeu5pSJfY=; b=LzGVtAWVbqtBBy5rkksZ6GHKyCJHS2m9wnJuQ+H4MKtvySuxk1gfEg9o5BTnlRsxeG RWG6o5SaEbpbGYegQbeGXSXkxwA/+lmZ7mcCt2KvFekzifxE2LfQsI78/qo7anjwfF2s vWdYcupTvMZV/8e6kSqqSKsiA7vCmGdp9BALOgsqJ0o3exdUwy0YioGhGfp4be69RGDs 267CB9CfZZ+w3ZCTM/jAId6w7P0tALgYI2Lbb0dgSGPEnXLIzF+msWIImokgeIknGsOu +Da2+yB3bbNCDj8S6pMaKBKnFzUZ3J8z49hdmd5jFXSXipSa8i9CZdgYGh8MVZeGhW4J 8LZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KRvtt9AgsCChro1qgMQb+k+PLTTcWeWXpsLeu5pSJfY=; b=t9lK/f974uMIKSA01EcNOc27OolIQwFCkb62CBcrU3qqRlbhg7KZLTZsAPzThxhrK8 WzQ1WYW5Mtg78lJ3T2Mo9rkwgVueZSk1H8OJcAMPxiMKZQw1SjBtggFTarvoDS81AgJF BDEwn5c9qt4+QIBZWWUegMLEuP2gW9bCp7y+jrgTr+dBvMr/ZpQ45Nwf/1F5b/eQQ1gz y45qZ8nzhViAgZFJ5IftEwWYSbDuoquR33b9WLJVE0wXyOA3bFsXPYSUICHyLKpKhc8g n7P/9AAJfdncRZ4nD+Y0lBuGWUmTh73I431Bb2R0H4RWRszHze4g+WozUwfMmgCILOsb Ub+Q== X-Gm-Message-State: AGRZ1gKcMJ5fGwhC/Mb+Vp5uUv1vmg9qSf+ZlQxShnSxZfjDCMPTTzX7 mXYjkaJ9f5Pz4QGcQY/sOJ3a/L7qr//FWlx8N+8+7+mp X-Google-Smtp-Source: AJdET5dfFP5xXB7weBS96kQ3ijRkB7Ywvz/3SFD9m/nTS1uURDdJNs+WJ8zWwobwEVyr+rY608ttntrQTcXdJYQ/Gg4= X-Received: by 2002:a37:2a81:: with SMTP id q1mr8388143qkq.252.1542328900035; Thu, 15 Nov 2018 16:41:40 -0800 (PST) MIME-Version: 1.0 References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> <129B91F9-E471-4AE4-98D3-F534D6BF09C1@mit.edu> <1AEDD443-72AD-4F46-9005-D64794C055AA@lodderstedt.net> In-Reply-To: <1AEDD443-72AD-4F46-9005-D64794C055AA@lodderstedt.net> From: Evan Gilman Date: Thu, 15 Nov 2018 16:41:28 -0800 Message-ID: To: torsten@lodderstedt.net Cc: Brian Campbell , oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 00:41:43 -0000 I have taken a stab at some text that will open the door for SAN-based subject identity support. Some minor modifications in section 2.1, and additional metadata parameters in section 2.1.2. Please find that text below. > I scanned through the SPIFFE docs but didn=E2=80=99t any mentioning of OA= uth (just plain X.509). What=E2=80=99s your plan for introducing OAuth and = mtls? That is correct - SPIFFE does not currently involve any OAuth works... the use case for this change was brought to my attention a couple of weeks ago: use SPIFFE identities in "cloud native" environments to authenticate to an OAuth server in order to receive an access token for authentication with on-prem infrastructure which is OAuth-enabled. Doing so relieves a good deal of pressure around OAuth client (and secret) management. That said, I think the proposed change here is beneficial on all counts, and not just an accommodation for SPIFFE authentication. As I mentioned previously, there are several other projects that are relying on SAN rather than DN for subject identity and the number is growing. I tried to think through what the text would look like to support a structured value for a parameter named `tls_client_auth_san`, but ran into a couple sticking points... the first is that it is certainly more complex and would require more text, and feels more error prone than simply introducing additional metadata parameters. Second, we would need to strictly define supported values for `type`, and it wasn't immediately clear if this is something that would need to be centrally registered. I am curious to hear thoughts on the structured value approach versus that which I took below. 2.1. PKI Mutual TLS OAuth Client Authentication Method The PKI (public key infrastructure) method of mutual TLS OAuth client authentication uses a subject name (DN or SAN) and validated certificate chain to identify the client. The TLS handshake is utilized to validate the client's possession of the private key corresponding to the public key in the certificate and to validate the corresponding certificate chain. The client is successfully authenticated if the subject information in the certificate matches the expected subject configured or registered for that particular client (note that a predictable treatment of DN values, such as the distinguishedNameMatch rule from [RFC4517], is needed in comparing the certificate's subject DN to the client's registered DN). If and how to check a certificate's revocation status is a deployment decision at the discretion of the authorization server. The PKI method facilitates the way X.509 certificates are traditionally being used for authentication. It also allows the client to rotate its X.509 certificates without the need to modify its respective authentication data at the authorization server by obtaining a new certificate with the same subject from a trusted certificate authority (CA). and 2.1.2. Client Registration Metadata The following metadata parameters are introduced for the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] in support of the PKI method of binding a certificate to a client: tls_client_auth_subject_dn An [RFC4514] string representation of the expected subject distinguished name of the certificate, which the OAuth client will use in mutual TLS authentication. tls_client_auth_san_dns A string containing the value of an expected dNSName SAN entry in the certificate, which the OAuth client will use in mutual TLS authentication. tls_client_auth_san_uri A string containing the value of an expected uniformResourceIdentifier SAN entry in the certificate, which the OAuth client will use in mutual TLS authentication. tls_client_auth_san_ip A string representation of an IP address in either dotted decimal notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as defined in [RFC4291] section 2.2) that is expected to be present as an iPAddress SAN entry in the certificate, which the OAuth client will use in mutual TLS authentication. tls_client_auth_san_email A string containing the value of an expected rfc822Name SAN entry in the certificate, which the OAuth client will use in mutual TLS authentication. On Tue, Nov 13, 2018 at 6:24 AM Torsten Lodderstedt wrote: > > Hi Evan, > > I scanned through the SPIFFE docs but didn=E2=80=99t any mentioning of OA= uth (just plain X.509). What=E2=80=99s your plan for introducing OAuth and = mtls? > > kind regards, > Torsten. > > > Am 13.11.2018 um 00:59 schrieb Evan Gilman : > > > > Thank you everyone for the feedback. > > > > I am currently working on the sample text, and should be complete in > > the next couple days. Apologies for the delay. > > On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell > > wrote: > >> > >> Sure, I think they could be treated as different different client_auth= _methods. But there is a lot more commonality than differences to the point= where I think it makes sense to keep it all in a single document and under= a single client auth method with just the variation on which name is being= used. > >> > >> On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer wrote= : > >>> > >>> Would it make sense for these to be a different client_auth_method en= tirely? Much the same way that we have private_key_jwt and client_secret_jw= t today, both of which use the JWT assertion framework but have very differ= ent keying and security assumptions. In the same way, here you=E2=80=99re s= till validating the cert but the means by which it=E2=80=99s validated is d= ifferent, so the auth method is arguably not going to benefit from being ov= erloaded. Caveat, I=E2=80=99ve not built out a system using SANs in any mea= ningful way. > >>> > >>> If we were to do that, this draft could go forward as-is (since it=E2= =80=99s fairly done in my opinion) and a new document could better define t= he semantics for the various SAN types, but while building on the framework= and concepts listed in here. > >>> > >>> =E2=80=94 Justin > >>> > >>> On Nov 6, 2018, at 3:52 PM, Evan Gilman wrote: > >>> > >>> Response(s) inline > >>> > >>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden wrote: > >>> > >>> > >>> Is there an intention that any semantics are attached to the SAN bein= g a URI or DNS name or IP or ...? Or is it still intended to be an opaque i= dentifier? > >>> > >>> > >>> There are some extra things we could do if we attached type-specific > >>> semantics to the matching (e.g. DNS wildcarding etc), however I think > >>> that continuing to use the values as opaque identifiers would get us > >>> most of what we need while keeping things simple. > >>> > >>> On 6 Nov 2018, at 01:55, Brian Campbell wrote: > >>> > >>> Thanks Evan for bringing this to the WG's attention. More or less the= same question/issue was raised yesterday in the area director's review of = the document as well. I plan to bring this up as a discussion item in the m= eeting today. But my sense from some early discussions is that there is lik= ely to be (rough) consensus to make some change in order to allow a SAN to = be specified as the certificate subject identifier in the PKI client auth m= ode. We'll need to figure out the specifics of how that works. I don't thin= k there are significant drawbacks to extending the number of client registr= ation metadata parameters per se. I guess I've just been attracted to the i= dea of overloading the existing value because that felt like maybe a less i= nvasive change. But perhaps that's shortsighted. And there's nothing inhere= ntly wrong with additional client metadata parameters. > >>> > >>> I don't know if we could get away with a single new parameter that co= uld carry the value for any SAN type. Something like, { ... "tls_client_aut= h_san": "spiffe://trust-domain/path" ...}. In practice I feel like that'd p= robably be okay but in theory there's the potential for confusion of the va= lue across different types. So probably there's a need to indicate the SAN = type too. Either with more client metadata parameters like tls_client_auth_= san_uir, tls_client_auth_san_email, tls_client_auth_san_ip, etc. or maybe w= ith a structured value of some sort like {... "tls_client_auth_san": {"type= ":"URI", "value":"spiffe://trust-domain/path"} ... }. And then deciding whi= ch types to support and if/how to allow for the extensible types. > >>> > >>> > >>> I am far from an authority here, but it is my understanding that one > >>> of the primary drivers in supporting SAN over Subject is that the > >>> values are strongly typed. While some of the advantages gained from > >>> this may be less useful in our own context, I feel that it make sense > >>> to keep the values separate and not overload a single value. Whether > >>> that means dedicated metadata parameters or a structured parameter > >>> value, I am not sure what the tradeoffs would be, but both options > >>> sound suitable to me. > >>> > >>> Anyway, those are just some thoughts on it. And it'll be discussed mo= re today. Suggested/proposed text is always helpful though (even if it's no= t used directly it can help move the conversation forward and/or help edito= r(s) to have prospective wording). > >>> > >>> > >>> Great. I will work on some sample text since it sounds like that woul= d > >>> be generally helpful > >>> > >>> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman wrote= : > >>> > >>> > >>> Hello everyone.. > >>> > >>> Very excited to see this draft. It helps tremendously in addressing > >>> use cases around oauth client management in machine-to-machine > >>> scenarios. Particularly, the PKI authentication method. > >>> > >>> In reviewing the document, I noticed that the only supported method > >>> for identifying a client using the PKI authentication method is by > >>> referencing its distinguished name. This caught me a bit by surprise = - > >>> many newer projects aimed at automating X.509 issuance in the > >>> datacenter utilize SAN extensions rather than distinguished name in > >>> order to encode identity. I am further under the impression that the > >>> community is, in general, moving away from the subject extension > >>> altogether in favor of SAN-based identification. > >>> > >>> Full disclosure: I am one of the maintainers on a project called > >>> SPIFFE, which provides identity specifications for datacenter workloa= d > >>> applications. For X.509, SPIFFE encodes identity into a URI SAN > >>> extension. A number of projects using SPIFFE do not configure the > >>> subject with identifying information (SPIRE and Google Istio being > >>> just a couple). I am also hearing of other X.509 automation projects > >>> which are moving away from subject/distinguished name (even if they > >>> are not using SPIFFE). > >>> > >>> While I think support for distinguished name is absolutely necessary, > >>> I worry that supporting it solely will render it incompatible with > >>> some of the more modern PKIX systems and not stand the test of time. = I > >>> know that I am a little late to this, and for that I apologize... but > >>> I feel this is a significant point. > >>> > >>> I would like to open a discussion on supporting the most commonly use= d > >>> SAN extension types in addition to distinguished name. To accomplish > >>> this, amending section 2.1.2 `Client Registration Metadata` with > >>> additional parameters seems appropriate. In my experience, the most > >>> commonly used SAN extensions are: DNS name, IP address, URI, and emai= l > >>> address. > >>> > >>> Are there significant drawbacks to extending the number of client > >>> registration metadata parameters? I would very much like to see this = - > >>> without it, many existing projects will be unable to use the spec. I > >>> am happy to contribute time and text to this, assuming people feel > >>> that this is a beneficial addition. Sorry again for the timing > >>> > >>> -- > >>> evan > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.. If you h= ave received this communication in error, please notify the sender immediat= ely by e-mail and delete the message and any file attachments from your com= puter. Thank you. > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >>> > >>> -- > >>> evan > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited. If you hav= e received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your compu= ter. Thank you. > > > > > > > > -- > > evan > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --=20 evan From nobody Thu Nov 15 23:27:33 2018 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 2BB03127133 for ; Thu, 15 Nov 2018 23:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82s5vB4bVN-4 for ; Thu, 15 Nov 2018 23:27:29 -0800 (PST) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7D3124D68 for ; Thu, 15 Nov 2018 23:27:28 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id AF8B1472EE1; Fri, 16 Nov 2018 16:27:27 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 641114E0046; Fri, 16 Nov 2018 16:27:27 +0900 (JST) Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wAG7OfT4005859; Fri, 16 Nov 2018 16:27:27 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp with ESMTP id wAG7RQC2008417; Fri, 16 Nov 2018 16:27:27 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAG7RQla006041; Fri, 16 Nov 2018 16:27:26 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wAG7RQin006039; Fri, 16 Nov 2018 16:27:26 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAG7RQBF006036; Fri, 16 Nov 2018 16:27:26 +0900 Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM07PA.cu.nri.co.jp (172.159.253.49) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 16 Nov 2018 16:27:25 +0900 Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.176) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 16 Nov 2018 16:27:25 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DdR06bRrNr2Ww3JU8gGwgM0mU6E2EC7ALXw57J35U2o=; b=lnVmAD7vgXHYjkfbB5p0ubrA6/zCBM7WDj0WnEJNaiK+GMlt6keoa7pVuupcytWM9W612iLbf/Cgl7JUBdnlbcKH4Zy8QZVBYFzqnzEdfGudf4e0nmMz9T4ZSuHTj9Yw/W55U/Ln2QmI1nT8gtrzHoOE6i8l4yJD1b7mpcaTi1A= Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB2774.jpnprd01.prod.outlook.com (52.134.252.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.23; Fri, 16 Nov 2018 07:27:24 +0000 Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Fri, 16 Nov 2018 07:27:24 +0000 From: n-sakimura To: George Fletcher , Dick Hardt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AS Discovery in Distributed Draft Thread-Index: AQHUdZBEwtYfru+j+0SsQMl40PsGQqVE0OkAgADcDgCAAFKPAIAMEGWw Date: Fri, 16 Nov 2018 07:27:24 +0000 Message-ID: References: <10bd2f07-d867-9db9-dfd7-9300617ec41b@aol.com> In-Reply-To: <10bd2f07-d867-9db9-dfd7-9300617ec41b@aol.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.250.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; OSBPR01MB2774; 6:OsRWut6E5rTk43Ihyh6OmThaSAK5kHbVaGz72dion/J91m3LjKFtoLNO/3KkQGBZxHpVuBalrBnndAmpTJxZLdDCIIRt3Poi8aX/wxpDItcYeOokT2/vxcQPtqGJhanD4bZWoecAmnNTDguusS3/5rVwCvuzujKM8AyZUbduCsXB34NN/iv6oAVuas3JgjICbQ6VdoxDYCyVEX1lpvwElPSYWBujptdYegI+yaSgiLwmmSM56ntz2JVbONovci9Ao9W06mWNbj50JzpCDjm8kcJOqGhPxj6iIDCxF7vxLvXeY7VZc929W+LkC8pmOvaokgGugLplCLvx7X0Y/JaxuIpaPxTKDeO1/7LBRkF4PxrOqVc1+M+tfAOAYOG8SQM/ciNVnyDe/mb6ovNLx1rMJvQwhPZ+O0s7zT38MmtKcFU6FNny+/1kPx3ukj5kguWiSGGKZ5tScxdpNbq8rY5Vvw==; 5:P8j1E2HgQ2fhqhjxNBl/pW0foNgXo5J+zRL4naksE1YEaUD+02o50Uzauiys0OPO4pEDfV/18GgbLbtFm/LDRwijl5Eq6MBYY/chEJ/BO/8UI3sxc70yoeU+HszlgYYU1CVO/OBvLNuPfUJp3mfDy3U9U5fZ06XZjJ1SZbGJE4E=; 7:vdCVVdH51X95WeR5s/Hsnbvk5UpVdBNnUY7X994wVEeuILNopNIZm33sZlG//P8kxt2pEMYmzleDZ28B6V0504S/4HtBjtFXf4X6xaKlmAPyTcYCqtc2vvgiO5kpmrIo03qHD0w/AX7edB6Yh/UEsQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b46117bd-fc43-4f92-2ac0-08d64b94f45c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB2774; x-ms-traffictypediagnostic: OSBPR01MB2774: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231415)(944501410)(52105112)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB2774; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB2774; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(136003)(396003)(39840400004)(189003)(199004)(256004)(39060400002)(9686003)(71200400001)(236005)(6306002)(86362001)(71190400001)(478600001)(8676002)(54896002)(81156014)(68736007)(6436002)(186003)(81166006)(790700001)(55016002)(4326008)(6116002)(446003)(3846002)(11346002)(476003)(486006)(606006)(99286004)(33656002)(2900100001)(7736002)(14454004)(229853002)(97736004)(93886005)(74482002)(66066001)(7696005)(966005)(8936002)(6506007)(102836004)(53936002)(53546011)(76176011)(105586002)(316002)(6246003)(110136005)(106356001)(2906002)(5660300001)(26005)(14444005)(25786009)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB2774; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: ojf6b1lv5+dSkwDMQbFlBLt75AgKvCHbTVHwZNJ9/CYYcm3BjBw04jVNjuWILEGl7fNu/6imH5shnHByCL0ngNzcKFOn+0sj4V0/NqOvPMl5Zwg2n9K/MYIcw2L/qKWsixWKN+ns2TJVVSJcC8KVhxi+tQPYMz+kzFJfJqBHW2yvdJ0tFttAccj3ERbhykXDGgqvf0lHt4qdaq6dPHQVDWbvj1m/VU7Dex6vAWKZmuDQfrkX+hw5dk2mqrCyrhcYl7cIsC2KW5wMy0DfW9A63UYcbDYKwvUmrWZPP6YgbzWC1A4jIsC5L9Dkj5MmSZcndsViWskGX5bM3c0ksC2wz5vCJzpF5MaxDbpmx+xw7N8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_OSBPR01MB28691D315889CA0D7696ECCEF9DD0OSBPR01MB2869jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b46117bd-fc43-4f92-2ac0-08d64b94f45c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2018 07:27:24.5307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2774 X-OrganizationHeadersPreserved: OSBPR01MB2774.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 07:27:32 -0000 --_000_OSBPR01MB28691D315889CA0D7696ECCEF9DD0OSBPR01MB2869jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG1tbS4gQnV0IHRoZSBMaW5rLWhlYWRlciBpcyB0aGUgZ2VuZXJhbGl6ZWQgZGlzY292ZXJ5IG1l dGhvZCB3aGljaCBpcyBwcmV0dHkgd2lkZWx5IHVzZWQgb3V0c2lkZSBvZiBPQXV0aCBjb21tdW5p dHkgd2l0aCB0aGUgYWRkZWQgYmVuZWZpdCBvZiBiZWluZyBhYmxlIHRvIGZpbmQgdGhpbmdzIHdp dGhvdXQgbGlua2luZyB0byBhdXRoZW50aWNhdGlvbi4NCg0KRnJvbTogT0F1dGggPG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBHZW9yZ2UgRmxldGNoZXINClNlbnQ6IEZyaWRh eSwgTm92ZW1iZXIgMDksIDIwMTggMTI6MTIgQU0NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0 QGdtYWlsLmNvbT47IGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZw0KQ2M6IG9hdXRo QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBUyBEaXNjb3ZlcnkgaW4gRGlzdHJp YnV0ZWQgRHJhZnQNCg0KQ29vbCEgU29ycnkgSSBjb3VsZG4ndCBtYWtlIHRoZSBtZWV0aW5nLiBP bmUgYmVuZWZpdCBvZiB1c2luZyBXV1ctQXV0aGVudGljYXRlIGlzIHRoYXQgVU1BIGhhcyBiYXNp Y2FsbHkgdGhlIHNhbWUgZGlzY292ZXJ5IGxvZ2ljIChmcm9tIFJTIHRvIEFTKSBhbmQgdXNlcyB0 aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIuIEtlZXBpbmcgdGhpcyBkaXNjb3ZlcnkgbWV0aG9k IHRoZSBzYW1lIChzaW5jZSBVTUEgaXMganVzdCBhIHByb2ZpbGUgb2YgT0F1dGggYW55d2F5KSB3 aWxsIGhlbHAgYWxsIGRldmVsb3BlcnMuDQpPbiAxMS84LzE4IDU6MTYgQU0sIERpY2sgSGFyZHQg d3JvdGU6DQpHZW9yZ2U6IGluIHRoZSBXRyBtZWV0aW5nIHdlIGRpc2N1c3NlZCB0aGlzIHRvcGlj IG9mIHdoZXJlIHRvIHB1dCB0aGUgZGlzY292ZXJ5IGluZm9ybWF0aW9uLiBObyBvbmUgYXQgdGhl IG1lZXRpbmcgYWR2b2NhdGVkIGZvciB1c2luZyBMaW5rIHJlc3BvbnNlIChOYXQgd2FzIHRoZSBv bmUgd2hvIHdhcyBhZHZvY2F0aW5nIGZvciB0aGlzKS4gTWFueSBvdGhlcnMgcHJlZmVycmVkIHVz aW5nIHRoZSB3d3ctYXV0aGVudGljYXRlIGhlYWRlciBzaW1pbGFyIHRvIGhvdyB5b3UgcHJvcG9z ZS4NCg0KT24gVGh1LCBOb3YgOCwgMjAxOCBhdCA0OjA4IEFNIEdlb3JnZSBGbGV0Y2hlciA8Z2Zm bGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0 Zi4ub3JnPj4gd3JvdGU6DQpSZWxhdGVkIHRvIHRoaXMgZGlzY3Vzc2lvbiBvZiBBUyBkaXNjb3Zl cnkuLi4gd2hhdCBpcyB0aGUgdmFsdWUgb2YgdXNpbmcgdGhlIExpbmsgcmVzcG9uc2UgaGVhZGVy IG92ZXIganVzdCByZXR1cm5pbmcgdGhlIHZhcmlhYmxlcyBpbiB0aGUgV1dXLUF1dGhlbnRpY2F0 ZSBoZWFkZXI/IENvdWxkIHdlIG5vdCB1c2UuLi4NCg0KV1dXLUF1dGhlbnRpY2F0ZTogT0F1dGgg cmVhbG09ImV4YW1wbGVfcmVhbG0iLCBzY29wZT0iZXhhbXBsZV9zY29wZSIsIGVycm9yPSJpbnZh bGlkX3Rva2VuIiwgcnNfdXJpPSJodHRwczovL2FwaS5leGFtcGxlLmNvbS9yZXNvdXJjZSI8aHR0 cHM6Ly9hcGkuZXhhbXBsZS5jb20vcmVzb3VyY2U+LCBhc191cmk9Imh0dHBzOi8vYXMxLmV4YW1w bGUuY29tLGh0dHBzOi8vYXMyLmV4YW1wbGUuY29tIjxodHRwczovL2FzMS5leGFtcGxlLmNvbSxo dHRwczovYXMyLmV4YW1wbGUuY29tPg0KDQpUaGFua3MsDQpHZW9yZ2UNCk9uIDExLzYvMTggMTI6 MTkgQU0sIEp1c3RpbiBQIFJpY2hlciB3cm90ZToNCkluIHRoZSBtZWV0aW5nIHRvbmlnaHQgSSBi cm91Z2h0IHVwIGEgcmVzcG9uc2UgdG8gdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdG8gaGF2ZSBm dWxsIFVSTCBvciBwbGFpbiBpc3N1ZXIgZm9yIHRoZSBhdXRoIHNlcnZlciBpbiB0aGUgUlMgcmVz cG9uc2XigJlzIGhlYWRlci4gTXkgc3VnZ2VzdGlvbiB3YXMgdGhhdCB3ZSBoYXZlIHR3byBkaWZm ZXJlbnQgcGFyYW1ldGVycyB0byB0aGUgaGVhZGVyIHRvIHJlcHJlc2VudCB0aGUgQVM6IG9uZSBv ZiB0aGVtIGJlaW5nIHRoZSBmdWxsIFVSTCAoYXNfdXJpKSBhbmQgb25lIG9mIHRoZW0gYmVpbmcg dGhlIGlzc3VlciB0byBiZSBjb25zdHJ1Y3RlZCBzb21laG93IChhc19pc3N1ZXIpLiBJIHJhbiBp bnRvIGEgc2ltaWxhciBwcm9ibGVtIG9uIGEgc3lzdGVtIHRoYXQgSSBidWlsdCBsYXN0IHllYXIg d2hlcmUgYWxsIG9mIG91ciBzZXJ2ZXJzIGhhZCBkaXNjb3ZlcnkgZG9jdW1lbnRzIGJ1dCBub3Qg YWxsIG9mIHRoZW0gd2VyZSBlYXNpbHkgY29uc3RydWN0ZWQgZnJvbSBhbiBpc3N1ZXIgc3R5bGUg VVJMICh1c2luZyBPSURDIHBhdHRlcm5zIGFueXdheSkuIFNvIHdlIHNvbHZlZCBpdCBieSBoYXZp bmcgdHdvIGRpZmZlcmVudCB2YXJpYWJsZXMuIElmIHRoZSBmdWxsIFVSTCB3YXMgc2V0LCB3ZSB1 c2VkIHRoYXQ7IGlmIGl0IHdhc27igJl0LCB3ZSB0cmllZCB0aGUgaXNzdWVyOyBpZiBuZWl0aGVy IHdhcyBzZXQgd2UgZGlkbuKAmXQgZG8gYW55IGRpc2NvdmVyeS4NCg0KSeKAmW0gc2Vuc2l0aXZl IHRvIFRvcnN0ZW7igJlzIGNvbmNlcm5zIGFib3V0IGNvbXBsZXhpdHksIGJ1dCBJIHRoaW5rIHRo aXMgaXMgYSBzaW1wbGUgYW5kIGRldGVybWluaXN0aWMgc29sdXRpb24gdGhhdCBzaWRlc3RlcHMg bXVjaCBvZiB0aGUgaXNzdWUuIE5vIHB1biBpbnRlbmRlZC4NCg0K4oCUIEp1c3Rpbg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_OSBPR01MB28691D315889CA0D7696ECCEF9DD0OSBPR01MB2869jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5 IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7 DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEDvvK3vvLMg44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDEx IDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCDmm7jlvI/ku5jjgY0gXCjmloflrZdcKSI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOabuOW8j+S7mOOBjSBcKOaWh+Wtl1wpIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg5pu45byP5LuY44GNIjsN Cglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLjIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo5OS4yNXB0IDMuMGNtIDMuMGNtIDMuMGNt O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5IbW1tLiBCdXQgdGhlIExpbmstaGVhZGVyIGlzIHRoZSBnZW5lcmFsaXpl ZCBkaXNjb3ZlcnkgbWV0aG9kIHdoaWNoIGlzIHByZXR0eSB3aWRlbHkgdXNlZCBvdXRzaWRlIG9m IE9BdXRoIGNvbW11bml0eSB3aXRoIHRoZSBhZGRlZCBiZW5lZml0IG9mIGJlaW5nIGFibGUgdG8g ZmluZCB0aGluZ3Mgd2l0aG91dA0KIGxpbmtpbmcgdG8gYXV0aGVudGljYXRpb24uIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gT0F1dGggJmx0 O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdlb3JnZSBG bGV0Y2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDA5LCAyMDE4IDEyOjEy IEFNPGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZn dDs7IGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gb2F1 dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gQVMgRGlzY292 ZXJ5IGluIERpc3RyaWJ1dGVkIERyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNvb2whIFNvcnJ5 IEkgY291bGRuJ3QgbWFrZSB0aGUgbWVldGluZy4gT25lIGJlbmVmaXQgb2YgdXNpbmcgV1dXLUF1 dGhlbnRpY2F0ZSBpcyB0aGF0IFVNQSBoYXMgYmFzaWNhbGx5IHRoZSBzYW1lIGRpc2NvdmVyeSBs b2dpYyAoZnJvbSBSUyB0byBBUykgYW5kIHVzZXMgdGhlDQogV1dXLUF1dGhlbnRpY2F0ZSBoZWFk ZXIuIEtlZXBpbmcgdGhpcyBkaXNjb3ZlcnkgbWV0aG9kIHRoZSBzYW1lIChzaW5jZSBVTUEgaXMg anVzdCBhIHByb2ZpbGUgb2YgT0F1dGggYW55d2F5KSB3aWxsIGhlbHAgYWxsIGRldmVsb3BlcnMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEx LzgvMTggNToxNiBBTSwgRGljayBIYXJkdCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VvcmdlOiBpbiB0aGUgV0cgbWVldGluZyB3 ZSBkaXNjdXNzZWQgdGhpcyB0b3BpYyBvZiB3aGVyZSB0byBwdXQgdGhlIGRpc2NvdmVyeSBpbmZv cm1hdGlvbi4gTm8gb25lIGF0IHRoZSBtZWV0aW5nIGFkdm9jYXRlZCBmb3IgdXNpbmcgTGluayBy ZXNwb25zZSAoTmF0IHdhcyB0aGUgb25lIHdobyB3YXMgYWR2b2NhdGluZyBmb3IgdGhpcykuIE1h bnkgb3RoZXJzIHByZWZlcnJlZCB1c2luZyB0aGUgd3d3LWF1dGhlbnRpY2F0ZQ0KIGhlYWRlciBz aW1pbGFyIHRvIGhvdyB5b3UgcHJvcG9zZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTm92IDgsIDIwMTggYXQgNDowOCBBTSBHZW9yZ2UgRmxl dGNoZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi4u b3JnIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UmVsYXRlZCB0byB0aGlzIGRpc2N1c3Npb24gb2Yg QVMgZGlzY292ZXJ5Li4uIHdoYXQgaXMgdGhlIHZhbHVlIG9mIHVzaW5nIHRoZSBMaW5rIHJlc3Bv bnNlIGhlYWRlciBvdmVyIGp1c3QgcmV0dXJuaW5nIHRoZSB2YXJpYWJsZXMgaW4gdGhlIFdXVy1B dXRoZW50aWNhdGUgaGVhZGVyPw0KIENvdWxkIHdlIG5vdCB1c2UuLi48YnI+DQo8YnI+DQpXV1ct QXV0aGVudGljYXRlOiBPQXV0aCByZWFsbT0mcXVvdDtleGFtcGxlX3JlYWxtJnF1b3Q7LCBzY29w ZT0mcXVvdDtleGFtcGxlX3Njb3BlJnF1b3Q7LCBlcnJvcj0mcXVvdDtpbnZhbGlkX3Rva2VuJnF1 b3Q7LCByc191cmk9PGEgaHJlZj0iaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vcmVzb3VyY2UiIHRh cmdldD0iX2JsYW5rIj4mcXVvdDtodHRwczovL2FwaS5leGFtcGxlLmNvbS9yZXNvdXJjZSZxdW90 OzwvYT4sIGFzX3VyaT08YSBocmVmPSJodHRwczovL2FzMS5leGFtcGxlLmNvbSxodHRwczovYXMy LmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+JnF1b3Q7aHR0cHM6Ly9hczEuZXhhbXBsZS5j b20saHR0cHM6Ly9hczIuZXhhbXBsZS5jb20mcXVvdDs8L2E+PGJyPg0KPGJyPg0KVGhhbmtzLDxi cj4NCkdlb3JnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAxMS82LzE4IDEyOjE5IEFNLCBKdXN0aW4gUCBSaWNoZXIgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIG1lZXRpbmcgdG9u aWdodCBJIGJyb3VnaHQgdXAgYSByZXNwb25zZSB0byB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB0 byBoYXZlIGZ1bGwgVVJMIG9yIHBsYWluIGlzc3VlciBmb3IgdGhlIGF1dGggc2VydmVyIGluIHRo ZSBSUyByZXNwb25zZeKAmXMgaGVhZGVyLiBNeSBzdWdnZXN0aW9uIHdhcyB0aGF0IHdlIGhhdmUg dHdvIGRpZmZlcmVudCBwYXJhbWV0ZXJzIHRvIHRoZSBoZWFkZXIgdG8gcmVwcmVzZW50DQogdGhl IEFTOiBvbmUgb2YgdGhlbSBiZWluZyB0aGUgZnVsbCBVUkwgKGFzX3VyaSkgYW5kIG9uZSBvZiB0 aGVtIGJlaW5nIHRoZSBpc3N1ZXIgdG8gYmUgY29uc3RydWN0ZWQgc29tZWhvdyAoYXNfaXNzdWVy KS4gSSByYW4gaW50byBhIHNpbWlsYXIgcHJvYmxlbSBvbiBhIHN5c3RlbSB0aGF0IEkgYnVpbHQg bGFzdCB5ZWFyIHdoZXJlIGFsbCBvZiBvdXIgc2VydmVycyBoYWQgZGlzY292ZXJ5IGRvY3VtZW50 cyBidXQgbm90IGFsbCBvZiB0aGVtIHdlcmUNCiBlYXNpbHkgY29uc3RydWN0ZWQgZnJvbSBhbiBp c3N1ZXIgc3R5bGUgVVJMICh1c2luZyBPSURDIHBhdHRlcm5zIGFueXdheSkuIFNvIHdlIHNvbHZl ZCBpdCBieSBoYXZpbmcgdHdvIGRpZmZlcmVudCB2YXJpYWJsZXMuIElmIHRoZSBmdWxsIFVSTCB3 YXMgc2V0LCB3ZSB1c2VkIHRoYXQ7IGlmIGl0IHdhc27igJl0LCB3ZSB0cmllZCB0aGUgaXNzdWVy OyBpZiBuZWl0aGVyIHdhcyBzZXQgd2UgZGlkbuKAmXQgZG8gYW55IGRpc2NvdmVyeS4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gc2Vuc2l0aXZl IHRvIFRvcnN0ZW7igJlzIGNvbmNlcm5zIGFib3V0IGNvbXBsZXhpdHksIGJ1dCBJIHRoaW5rIHRo aXMgaXMgYSBzaW1wbGUgYW5kIGRldGVybWluaXN0aWMgc29sdXRpb24gdGhhdCBzaWRlc3RlcHMg bXVjaCBvZiB0aGUgaXNzdWUuIE5vIHB1biBpbnRlbmRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj7igJQgSnVz dGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_OSBPR01MB28691D315889CA0D7696ECCEF9DD0OSBPR01MB2869jpnp_-- From nobody Thu Nov 15 23:58:03 2018 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 798BC127133 for ; Thu, 15 Nov 2018 23:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 DYWDnIDe1HdJ for ; Thu, 15 Nov 2018 23:57:58 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C91124D68 for ; Thu, 15 Nov 2018 23:57:58 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id 96so6955738wrb.2 for ; Thu, 15 Nov 2018 23:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=z6XOXFswh/nzN4frwBcVzVDzFmObUIACkFXco/BtmDc=; b=ldI4LKcZvbHL15L12AeO6BlEO/YyHm/wJhiCKZDI0+Ufk/sciiXuZP0g/W+UIYFYvh VQnp/9SikuCqh/Evxh97jWhx9r5j49lcRmVsd2jfIc2pn0jOtBb0sACyH1uF5DnX5Jsl mlZXN9a0Jyi609LSghN+H86sgj6gdZc13A5b7S12kds8ZS/08Mh9mfg6nBrEhr21ycjd gozIOmcwMSRQkxvZXVjg6iydlxjYt4Cc5HavTZzODKbJ4lVlnDT7Lm09dcL1GnjzNKir 5j1RseoaGDYCUIt7BEjCgSWrmSOSt7fvlun9ipNELK6M+R6B6DzM94HtfUxFiqd2FTK/ dLcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=z6XOXFswh/nzN4frwBcVzVDzFmObUIACkFXco/BtmDc=; b=av6xrt4aEs/bU3C8QMV4sRSl3qjsxHxZsptazpo645mgalN2wAQkV/XVLkHjQWuMEn 95xCnEbeinE3fIDINMZ1OHT7Vmn5JxvI1ElwxN/lNaEO3H8zYudDi2ON8ortwLZusoas yxY/aGVA2mR6WV/Z5HaGNx58NC3GvXOyPRPy62Vqoi1L+eZyOZ0w0eFk5m3Ww4JKhk+N 3sGJpEVWmwLHa2+lTzGGgwmaaAj4p+BO/D2aJxprPkXxWreilqz9ELnLepQt0YC8cfkO t8QTQrLdU5q30uBWjOgurshMRQnJX3ri2BX4BOAkZ3fSUo6sHR9iPwKTnqQpDT64dGtK +47g== X-Gm-Message-State: AGRZ1gKQceuUgFee5k4jdoYYWyluv1yrB+eG+d13RpBeQwaEZIp16gXz rjVlyRJyKDwpNBzMv2XgluCDoPaH/4w= X-Google-Smtp-Source: AJdET5eP2MexezOahqB2Eco+GgqnIruD5nPf8A91BoSorcylKmZoeywmSeg0Mcxn1xUiQWdjC9VnjQ== X-Received: by 2002:adf:db86:: with SMTP id u6-v6mr8608638wri.165.1542355076002; Thu, 15 Nov 2018 23:57:56 -0800 (PST) Received: from ?IPv6:2003:c1:4f2e:1600:cc33:a3af:4584:e7de? (p200300C14F2E1600CC33A3AF4584E7DE.dip0.t-ipconnect.de. [2003:c1:4f2e:1600:cc33:a3af:4584:e7de]) by smtp.gmail.com with ESMTPSA id t5sm2915745wmd.15.2018.11.15.23.57.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 23:57:55 -0800 (PST) To: oauth@ietf.org References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> From: Daniel Fett Message-ID: Date: Fri, 16 Nov 2018 08:57:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> Content-Type: multipart/alternative; boundary="------------0A5D8A178C11EA86A997216D" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 16 Nov 2018 07:58:01 -0000 This is a multi-part message in MIME format. --------------0A5D8A178C11EA86A997216D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, Am 09.11.18 um 21:22 schrieb Brock Allen: > > Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get > into specifics, but many of the points seem confused (or at least > confuse me) and/or the conclusion that code flow is the only approach > seems misleading. For example: > > "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is > required according to Section 6), so clients and authorization servers > MUST NOT use the Implicit Flow for browser-based apps." > > This is specious. The threat is the token is in the URL, not that > implicit clients can't use PKCE. So perhaps the document should > explain the variety of mitigations, not just one? While code flow is > one, using CSP and the browser history API to remove the token from > the URL is another. Elsewhere in the document the use of CSP is a > "SHOULD". That's great, but using CSP can be and is used today, and > doesn't necessitate code flow. Could you please expand on what you are achieving with replacing the URL using the history API? Removing the token from the browser's history, or any protection beyond that? > > "Supporting the implicit flow requires additional code, more upkeep > and understanding of the related security considerations, while > limiting the authorization server to just the authorization code flow > simplifies the implementation." > > As offered by someone else already, this is opinion and not objective. > IMO, this diminishes the potential of this document. Another aspect is that removing implicit as an option greatly simplifies security analysis and formal proofs of security (of which I hope we will see more instances in the future). If you look at it this way, it is much more than an opinion and it is definitely objective. - Daniel --------------0A5D8A178C11EA86A997216D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi all,

Am 09.11.18 um 21:22 schrieb Brock Allen:

Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into specifics, but many of the points seem confused (or at least confuse me) and/or the conclusion that code flow is the only approach seems misleading. For example:

"The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required according to Section 6), so clients and authorization servers MUST NOT use the Implicit Flow for browser-based apps."

This is specious. The threat is the token is in the URL, not that implicit clients can't use PKCE. So perhaps the document should explain the variety of mitigations, not just one? While code flow is one, using CSP and the browser history API to remove the token from the URL is another. Elsewhere in the document the use of CSP is a "SHOULD". That's great, but using CSP can be and is used today, and doesn't necessitate code flow.

Could you please expand on what you are achieving with replacing the URL using the history API? Removing the token from the browser's history, or any protection beyond that?



"Supporting the implicit flow requires additional code, more upkeep and understanding of the related security considerations, while limiting the authorization server to just the authorization code flow simplifies the implementation."

As offered by someone else already, this is opinion and not objective. IMO, this diminishes the potential of this document.

Another aspect is that removing implicit as an option greatly simplifies security analysis and formal proofs of security (of which I hope we will see more instances in the future). If you look at it this way, it is much more than an opinion and it is definitely objective.

- Daniel
--------------0A5D8A178C11EA86A997216D-- From nobody Fri Nov 16 01:12:20 2018 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 B028A130EC2 for ; Fri, 16 Nov 2018 01:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl8-BPYBssPs for ; Fri, 16 Nov 2018 01:12:17 -0800 (PST) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874D4124D68 for ; Fri, 16 Nov 2018 01:12:16 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id 883E377EFB; Fri, 16 Nov 2018 18:12:15 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 323284E0046; Fri, 16 Nov 2018 18:12:15 +0900 (JST) Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wAG9CFo5006485; Fri, 16 Nov 2018 18:12:15 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp with ESMTP id wAG9CExK006480; Fri, 16 Nov 2018 18:12:15 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAG9CEhp061146; Fri, 16 Nov 2018 18:12:14 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wAG9CEqb061145; Fri, 16 Nov 2018 18:12:14 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAG9CEui061142; Fri, 16 Nov 2018 18:12:14 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM02SA.cu.nri.co.jp (172.59.253.44) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 16 Nov 2018 18:12:12 +0900 Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.183) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 16 Nov 2018 18:12:11 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dXJ4htByQakF72OwxYssW++d8+IKJm0qyY0OBFxFgwo=; b=sTD6aDksPT6J4jLfWL6jxfFi8PdIHJff4eziJKVM7o7BSqBWLn0sTU0fqbqpCs0AI12q+k3hzyJKaLO7DRETS8BSTV0N9QXZ/teGqbLLTs97x0OHmy9skp1n0vKIdegRBI19/07wqn5YuCdHoH63EXhMADHixcjKVrhH3sXToK4= Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB2885.jpnprd01.prod.outlook.com (52.134.253.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Fri, 16 Nov 2018 09:12:11 +0000 Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Fri, 16 Nov 2018 09:12:11 +0000 From: n-sakimura To: Brock Allen , Torsten Lodderstedt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 Thread-Index: AdR1tZqXsuKHZhdYRhq5sgoVL0Z8egAA8cqAAKwg0oAAxpLdAABZ4LyAAAtfsIAABWFQAAAXI//g Date: Fri, 16 Nov 2018 09:12:11 +0000 Message-ID: References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> In-Reply-To: <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.250.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; OSBPR01MB2885; 6:wUAsRFdazgIsP7MCrSc66k1ySvO8bLjNBB4xaow+wb0at1d28gc2A4+kQ+PoLSP5bpDdgkDXJEr5515fLlHvrwHMEnSofVRpZkQun7ETjm5fNIyghRWQz8pbBvYpUFo1unRvVAnnZBtMCPztp8lEaRQccGz9P8qDWZiHdwWoBfTgF0ujvuB49fcnEoccXYMonik3JoMzy/zq6K3XoQhfPExWMnMo62UkEczV0Uu2mEzylR6HRWAcMPgnUwTqZwf/yQ0RmK36AdQHkLD+4bwBeA8V8Tt2CTK8CRZv4j+lAQQ8tYYmKdbg23WlbGgsTTCJxvUUTXXoZN0KhpwWTAXPxR2lyi4qmPt4bVmsNe5PMxCa90hY9MKfZglGTkkHtzBV3rg50J4P2fzbdQT+b9mycF5gn5VRA6lhJYsOKoSY6xlGwNUX/MgwdNA3jYrs5KE6aNlWfIYyuj1Wfaz5yFciFg==; 5:3jWEHBFetqljUGjmsS6mKmz1Hc5z2CsCL7aXDA/pQ5h+IwkKuVBufSPpgXCm8V5TBQLl5Sczn5PmSU0M1n0VGd+Zwy5LXiqWPOwx0KNG6lGB+WBg0OvT9j4UF6Q5U2yOMdhhkk0n+AjXJK+ZHf+jWHV1IL7urdYzie2BJcaYB88=; 7:3N88UX3GvS/u5wbPXXFXOrxYcq9MaZM4M9D2f4F1/8hyzEb/kMwZ5VAfRm5aSSr5dLmW9BaWE4pF78VaA1Qf1sOFnIaspKZXAdUTTbJ+4ezio59NlCYEdAwkw9EsQ9DY/lCSJU9M5w3NNXiQWb2Fjw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4f015e24-b2a0-4dc4-84c7-08d64ba39793 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB2885; x-ms-traffictypediagnostic: OSBPR01MB2885: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193)(265634631926514)(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231415)(944501410)(4982022)(52105112)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB2885; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB2885; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(39840400004)(396003)(136003)(199004)(189003)(7736002)(105586002)(14444005)(486006)(256004)(446003)(11346002)(476003)(6246003)(9686003)(86362001)(110136005)(2900100001)(53936002)(55016002)(74316002)(26005)(186003)(106356001)(54896002)(93886005)(14454004)(6306002)(8676002)(790700001)(4326008)(8936002)(76176011)(5660300001)(53546011)(33656002)(102836004)(81166006)(71190400001)(81156014)(7696005)(99286004)(6506007)(68736007)(66574009)(6436002)(25786009)(74482002)(316002)(66066001)(6116002)(71200400001)(39060400002)(229853002)(3846002)(2906002)(478600001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB2885; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: pFMd0I5CkvGAScg9eoPuOug2u94DSRlB9Ea/YZEvT1sAkoozAxAaqQMOce+tnQki031cC6Aj6VRhDH0bpnW2zluaiZ6l3edP62QTokAhHXmRDUs0qE9ovhS1X4n/4gq7Lv9IobnTLl9psS51mRsrxfT9ZMBQDH2WeeMBb/r/w1Z/ttl/BxeSzqYMr/SrqoHfFQTywitqSL3Rw1olrAvVPLbHiW4EkzBor9/TOgtQvU+OmKYNEDi27bKclHHMoXm7Zww1fHpgd0AGmJPXZlReifufo9fEsvU5yBA4CD9FKxI4ztBDTAD08MTRF0/0tVLCRk8GDgEn49ZMbaQist6tcLJ8zC/nNh8FbSdyR48PNZg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_OSBPR01MB28699EE24930C1B23C131316F9DD0OSBPR01MB2869jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f015e24-b2a0-4dc4-84c7-08d64ba39793 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2018 09:12:11.3132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2885 X-OrganizationHeadersPreserved: OSBPR01MB2885.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 16 Nov 2018 09:12:19 -0000 --_000_OSBPR01MB28699EE24930C1B23C131316F9DD0OSBPR01MB2869jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludHMuDQoNCkFsc28sIHdoaWxlIGl0IG1heSBiZSBvZmYtdG9waWMsIEkgZG8gc2Vl IHZhbHVlcyBpbiBpbXBsaWNpdCBmbG93cy4gSW4gc29tZSBjYXNlcywgc3VjaCBhcyB3aGVuIHRo ZSBBUyBpcyBpbnNpZGUgdGhlIGZpcmV3YWxsIG9yIG9uIGEgbG9jYWxob3N0IChlLmcuLCBzbWFy dHBob25lKSwg4oCcY29kZSBmbG934oCdIGlzIG5vdCBwb3NzaWJsZSBhcyB0aGUgY2xpZW50IGNh bm5vdCByZWFjaCB0aGUgQVMgZGlyZWN0bHkuIEJhbm5pbmcgaW1wbGljaXQgKGFuZCB0aHVzIOKA nHRva2VuIGlkX3Rva2Vu4oCdIGFzIHdlbGwpIGhhcyB0aGlzIHJlcGVyY3Vzc2lvbiBhbmQgSSB3 b3VsZCBub3QgYWdyZWUgdG8gaXQuDQoNCkJlc3QsDQoNCk5hdCBTYWtpbXVyYQ0KDQpGcm9tOiBP QXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyb2NrIEFsbGVuDQpT ZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDE4IDc6MDEgQU0NClRvOiBUb3JzdGVuIExvZGRl cnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gZHJhZnQtcGFyZWNraS1vYXV0aC1icm93c2VyLWJhc2VkLWFw cHMtMDANCg0KPiBJdCBzdGlsbCBsYWNrcyB0aGUgYWJpbGl0eSB0byBpc3N1ZSBzZW5kZXIgY29u c3RyYWludCBhY2Nlc3MgdG9rZW5zLg0KDQpTbyB5b3UgbWVhbiBhdCB0aGUgcmVzb3VyY2Ugc2Vy dmVyIGVuc3VyaW5nIHRoZSB0b2tlbiB3YXMgcmVhbGx5IGlzc3VlZCB0byB0aGUgY2xpZW50PyBJ c24ndCB0aGF0IGFuIGluaGVyZW50IGxpbWl0YXRpb24gb2YgYWxsIGJlYXJlciB0b2tlbnMgKG1v ZHVsbyBIVFRQIHRva2VuIGJpbmRpbmcsIHdoaWNoIGlzIHN0aWxsIHNvbWUgdGltZSBvZmYpPyBS ZXNvdXJjZSBzZXJ2ZXJzIGRvbid0IGtub3cgdGhlIGZsb3cgdGhlIGNsaWVudHMgbWlnaHQgdXNl LCBlc3BlY2lhbGx5IGlmL3doZW4gdGhleSBoYXZlIG1hbnkgY2xpZW50cy4NCg0KPiBUaGUgQVMg Y2FuIGJpbmQgdGhlIGxpZmV0aW1lIG9mIHRoZSByZWZyZXNoIHRva2VucyB0byB0aGUgc2Vzc2lv biBsaWZldGltZSwgaS5lLiBhdXRvbWF0aWNhbGx5IHJldm9rZSBpdCBvbiBsb2dvdXQuDQoNClll YSwgSSBzYXcgeW91ciBvdGhlciBlbWFpbCBhc2tpbmcgYWJvdXQgcmVmcmVzaCB0b2tlbiByZXZv Y2F0aW9uIHJlbGF0aW5nIHRvIHNlc3Npb24gbWFuYWdlbWVudC4gT2J2aW91c2x5IGZvciBjZXJ0 YWluIGNsaWVudHMsIHRoaXMgd29uJ3QgbWFrZSBzZW5zZSwgYnV0IGZvciBpbXBsaWNpdC9icm93 c2VyLWJhc2VkIG9uZXMgaXQncyBhIG5pY2UgZmVhdHVyZSB0byBoYXZlLg0KDQpUaGUgYWx0ZXJu YXRpdmUsIGFzIHlvdSBtZW50aW9uZWQsIGlzIHRvIG5vdCBpc3N1ZSByZWZyZXNoIHRva2VucyBh bmQgZG8gdG9rZW4gcmVuZXdhbCB0aGUgInNhbWUgb2xkIHdheSIgdmlhIGlmcmFtZSB3aXRoIHBy b21wdD1ub25lLCB3aGlsZSBzdGlsbCB1c2luZyBjb2RlIGZsb3cuDQoNCj4gVGhlIG9ubHkgcG90 ZW50aWFsIOKAnmJhYnkgc3RlcOKAnCBJIHdvdWxkIHNlZSBpcyB0byBtb3ZlIHRvd2FyZHMg4oCe dG9rZW4gaWRfdG9rZW7igJwuIFNpbmNlIHRoaXMgcmVxdWlyZXMgc2lnbmF0dXJlL2F0X2hhc2gg Y2hlY2tzIGV0Yy4gSSBkb3VidCB0aGlzIGlzIHJlYWxseSBlYXNpZXIgdGhhbiBtb3ZpbmcgdG8g Y29kZSBhbmQgZXhjaGFuZ2UgdGhlIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbi4gV2hhdOKAmXMg eW91ciBvcGluaW9uPw0KDQpFdmVuIHNpbmNlIE9JREMgYXJyaXZlZCwgdGhpcyBpcyB0aGUgb25s eSBmbG93IEkgdXNlIGZvciBKUy9icm93c2VyLWJhc2VkIGNsaWVudHMgKGFueXRoaW5nIGxlc3Mg aGFzIGFsd2F5cyBzZWVtZWQgc28gb2J2aW91c2x5IGluZmVyaW9yKS4gU28gZm9yIG1lIGFuZCBt eSBjdXN0b21lcnMsIGFsbCBicm93c2VyLWJhc2VkIGNsaWVudHMgSSBhbSBpbnZvbHZlZCBpbiBh cmUgYWxyZWFkeSB0aGVyZS4gUGVyaGFwcyB0aGlzIGlzIHRoZSByZWFzb24gZm9yIGFsbCBvZiBt eSBxdWVzdGlvbnMvY29tbWVudHMgYWJvdXQgdGhlIHJlY2VudCBCQ1AgZG9jLiBHaXZlbiAiaWRf dG9rZW4gdG9rZW4iLCBDU1AsIGFuZCB1c2luZyB0aGUgYnJvd3NlciBoaXN0b3J5IEFQSSB0byB3 aXBlIHRoZSBhY2Nlc3MgdG9rZW4gZnJvbSBicm93c2VyIGhpc3RvcnksIHdlIGFscmVhZHkgaGF2 ZSBhIGRlY2VudCBzZXQgb2YgdG9vbHMgdG8gbWl0aWdhdGUgYXR0YWNrcy4gQXMgSSBhbHJlYWR5 IGNvbmNlZGVkLCB0aGUgb25seSByZW1haW5pbmcgaXNzdWUgKElNTykgaXMgdGhlIHNob3J0IHdp bmRvdyBvZiB0aW1lIHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW4gdGhlIFVSTC4NCg0KR2l2ZW4gdGhh dCBpdCBzZWVtcyB0byBtZSB0aGF0IE9JREMgYW5kIE9BdXRoMiBhcmUgdHlwaWNhbGx5IHVzZWQg dG9nZXRoZXIgKGF0IGxlYXN0IHdoZW4gYSB1c2VyIGlzIGludm9sdmVkIHdpdGggYXV0aGVudGlj YXRpb24pLCBJIGFsd2F5cyB3b25kZXIgd2h5IHRoZSBPQXV0aCBhbmQgT0lEQyBXR3MgYXJlIHNl cGFyYXRlLiBHaXZlbiB0aGF0IHNvIG11Y2ggZWZmb3J0IG9mIHRoZSB0d28gc2V0cyBvZiBzcGVj cyBvdmVybGFwLCBpdCBzZWVtcyBvZGQgdG8ga2VlcCBhZGRpbmcgb250byB0aGUgT0F1dGggc3Bl Y3MgYW5kIGlnbm9yaW5nIHRoZSBhZGRlZCBmZWF0dXJlcyB0aGF0IE9JREMgcHJvdmlkZXMuIEkg ZG9uJ3QgbWVhbiB0byBkZXJhaWwgdGhpcyB0aHJlYWQsIG9yIHN0ZXAgb24gYW55IHBvbGl0aWNh bCB0b2VzLCBzbyBhcG9sb2dpZXMgaW4gYWR2YW5jZS4NCg0KDQotQnJvY2sNCg0K --_000_OSBPR01MB28699EE24930C1B23C131316F9DD0OSBPR01MB2869jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTHVjaWRhIENvbnNvbGUiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDQgNSA0IDIgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIOOCtOOCt+ODg+OCryI7DQoJcGFub3Nl LTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLjE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9u dC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46OTkuMjVwdCAzLjBjbSAzLjBjbSAzLjBjbTt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkdvb2QgcG9pbnRzLiA8bzpwPg0K PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QWxzbywgd2hpbGUgaXQgbWF5IGJlIG9mZi10 b3BpYywgSSBkbyBzZWUgdmFsdWVzIGluIGltcGxpY2l0IGZsb3dzLiBJbiBzb21lIGNhc2VzLCBz dWNoIGFzIHdoZW4gdGhlIEFTIGlzIGluc2lkZSB0aGUgZmlyZXdhbGwgb3Igb24gYSBsb2NhbGhv c3QgKGUuZy4sIHNtYXJ0cGhvbmUpLCDigJxjb2RlIGZsb3figJ0gaXMgbm90IHBvc3NpYmxlDQog YXMgdGhlIGNsaWVudCBjYW5ub3QgcmVhY2ggdGhlIEFTIGRpcmVjdGx5LiBCYW5uaW5nIGltcGxp Y2l0IChhbmQgdGh1cyDigJx0b2tlbiBpZF90b2tlbuKAnSBhcyB3ZWxsKSBoYXMgdGhpcyByZXBl cmN1c3Npb24gYW5kIEkgd291bGQgbm90IGFncmVlIHRvIGl0Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5CZXN0LCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pk5hdCBTYWtpbXVyYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBP ZiA8L2I+DQpCcm9jayBBbGxlbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDE2 LCAyMDE4IDc6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3Rv cnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gZHJhZnQtcGFyZWNraS1vYXV0aC1i cm93c2VyLWJhc2VkLWFwcHMtMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iX19NYWlsYmlyZFN0eWxlQ29udGVudCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyZuYnNw O0l0IHN0aWxsIGxhY2tzIHRoZSBhYmlsaXR5IHRvIGlzc3VlIHNlbmRlciBjb25zdHJhaW50IGFj Y2VzcyB0b2tlbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1 Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xv cjpibGFjayI+U28geW91IG1lYW4gYXQgdGhlIHJlc291cmNlIHNlcnZlciBlbnN1cmluZyB0aGUg dG9rZW4gd2FzIHJlYWxseSBpc3N1ZWQgdG8gdGhlIGNsaWVudD8gSXNuJ3QgdGhhdCBhbiBpbmhl cmVudCBsaW1pdGF0aW9uIG9mIGFsbCBiZWFyZXIgdG9rZW5zIChtb2R1bG8gSFRUUCB0b2tlbiBi aW5kaW5nLA0KIHdoaWNoIGlzIHN0aWxsIHNvbWUgdGltZSBvZmYpPyBSZXNvdXJjZSBzZXJ2ZXJz IGRvbid0IGtub3cgdGhlIGZsb3cgdGhlIGNsaWVudHMgbWlnaHQgdXNlLCBlc3BlY2lhbGx5IGlm L3doZW4gdGhleSBoYXZlIG1hbnkgY2xpZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtUaGUgQVMgY2FuIGJp bmQgdGhlIGxpZmV0aW1lIG9mIHRoZSByZWZyZXNoIHRva2VucyB0byB0aGUgc2Vzc2lvbiBsaWZl dGltZSwgaS5lLiBhdXRvbWF0aWNhbGx5IHJldm9rZSBpdCBvbiBsb2dvdXQuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj5ZZWEsIEkgc2F3IHlv dXIgb3RoZXIgZW1haWwgYXNraW5nIGFib3V0IHJlZnJlc2ggdG9rZW4gcmV2b2NhdGlvbiByZWxh dGluZyB0byBzZXNzaW9uIG1hbmFnZW1lbnQuIE9idmlvdXNseSBmb3IgY2VydGFpbiBjbGllbnRz LCB0aGlzIHdvbid0IG1ha2Ugc2Vuc2UsIGJ1dCBmb3IgaW1wbGljaXQvYnJvd3Nlci1iYXNlZA0K IG9uZXMgaXQncyBhIG5pY2UgZmVhdHVyZSB0byBoYXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+VGhlIGFsdGVybmF0aXZlLCBh cyB5b3UgbWVudGlvbmVkLCBpcyB0byBub3QgaXNzdWUgcmVmcmVzaCB0b2tlbnMgYW5kIGRvIHRv a2VuIHJlbmV3YWwgdGhlICZxdW90O3NhbWUgb2xkIHdheSZxdW90OyB2aWEgaWZyYW1lIHdpdGgg cHJvbXB0PW5vbmUsIHdoaWxlIHN0aWxsIHVzaW5nIGNvZGUgZmxvdy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtU aGUgb25seSBwb3RlbnRpYWwg4oCeYmFieSBzdGVw4oCcIEkgd291bGQgc2VlIGlzIHRvIG1vdmUg dG93YXJkcyDigJ50b2tlbiBpZF90b2tlbuKAnC4gU2luY2UgdGhpcyByZXF1aXJlcyBzaWduYXR1 cmUvYXRfaGFzaCBjaGVja3MgZXRjLiBJIGRvdWJ0IHRoaXMgaXMgcmVhbGx5IGVhc2llciB0aGFu DQogbW92aW5nIHRvIGNvZGUgYW5kIGV4Y2hhbmdlIHRoZSBjb2RlIGZvciBhbiBhY2Nlc3MgdG9r ZW4uIFdoYXTigJlzIHlvdXIgb3Bpbmlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVj aWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPkV2ZW4gc2luY2UgT0lEQyBhcnJpdmVkLCB0 aGlzIGlzIHRoZSBvbmx5IGZsb3cgSSB1c2UgZm9yIEpTL2Jyb3dzZXItYmFzZWQgY2xpZW50cyAo YW55dGhpbmcgbGVzcyBoYXMgYWx3YXlzIHNlZW1lZCBzbyBvYnZpb3VzbHkgaW5mZXJpb3IpLiBT byBmb3IgbWUgYW5kIG15IGN1c3RvbWVycywNCiBhbGwgYnJvd3Nlci1iYXNlZCBjbGllbnRzIEkg YW0gaW52b2x2ZWQgaW4gYXJlIGFscmVhZHkgdGhlcmUuIFBlcmhhcHMgdGhpcyBpcyB0aGUgcmVh c29uIGZvciBhbGwgb2YgbXkgcXVlc3Rpb25zL2NvbW1lbnRzIGFib3V0IHRoZSByZWNlbnQgQkNQ IGRvYy4gR2l2ZW4gJnF1b3Q7aWRfdG9rZW4gdG9rZW4mcXVvdDssIENTUCwgYW5kIHVzaW5nIHRo ZSBicm93c2VyIGhpc3RvcnkgQVBJIHRvIHdpcGUgdGhlIGFjY2VzcyB0b2tlbiBmcm9tIGJyb3dz ZXIgaGlzdG9yeSwNCiB3ZSBhbHJlYWR5IGhhdmUgYSBkZWNlbnQgc2V0IG9mIHRvb2xzIHRvIG1p dGlnYXRlIGF0dGFja3MuIEFzIEkgYWxyZWFkeSBjb25jZWRlZCwgdGhlIG9ubHkgcmVtYWluaW5n IGlzc3VlIChJTU8pIGlzIHRoZSBzaG9ydCB3aW5kb3cgb2YgdGltZSB0aGUgYWNjZXNzIHRva2Vu IGlzIGluIHRoZSBVUkwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xl JnF1b3Q7O2NvbG9yOmJsYWNrIj5HaXZlbiB0aGF0IGl0IHNlZW1zIHRvIG1lIHRoYXQgT0lEQyBh bmQgT0F1dGgyIGFyZSB0eXBpY2FsbHkgdXNlZCB0b2dldGhlciZuYnNwOyhhdCBsZWFzdCB3aGVu IGEgdXNlciBpcyBpbnZvbHZlZCB3aXRoIGF1dGhlbnRpY2F0aW9uKSwgSSBhbHdheXMgd29uZGVy Jm5ic3A7d2h5IHRoZSBPQXV0aCBhbmQNCiBPSURDIFdHcyBhcmUgc2VwYXJhdGUuIEdpdmVuIHRo YXQgc28gbXVjaCBlZmZvcnQgb2YgdGhlIHR3byBzZXRzIG9mIHNwZWNzIG92ZXJsYXAsIGl0IHNl ZW1zIG9kZCB0byBrZWVwIGFkZGluZyBvbnRvIHRoZSBPQXV0aCBzcGVjcyBhbmQgaWdub3Jpbmcg dGhlIGFkZGVkIGZlYXR1cmVzIHRoYXQgT0lEQyBwcm92aWRlcy4gSSBkb24ndCBtZWFuIHRvIGRl cmFpbCB0aGlzIHRocmVhZCwgb3Igc3RlcCBvbiBhbnkgcG9saXRpY2FsIHRvZXMsIHNvIGFwb2xv Z2llcw0KIGluIGFkdmFuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25z b2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+ LUJyb2NrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_OSBPR01MB28699EE24930C1B23C131316F9DD0OSBPR01MB2869jpnp_-- From nobody Fri Nov 16 04:59:58 2018 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 161B3126BED for ; Fri, 16 Nov 2018 04:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 ztlkBfki21Zf for ; Fri, 16 Nov 2018 04:59:54 -0800 (PST) Received: from sonic313-10.consmr.mail.ne1.yahoo.com (sonic313-10.consmr.mail.ne1.yahoo.com [66.163.185.33]) (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 F0BC7124408 for ; Fri, 16 Nov 2018 04:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542373192; bh=DG5EU6MBY4219Ly3JGFVisKxvYvKcv3siJPhq0qYVrk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=HmuO58JPPUpJtV2Yns9zyQyKVDABXY8cVP6AJx6aY2x4pOyP6ZIuhL+4LFIeAHpLfkgFzlnt2k5Fhs9UiLUZZFAqEnqJdG3/qKTjDh2UWUxGPbIaaHi+zh8DvQV2xlnz3nBPnoYhFLCss6Aty6nLadzMSI5JSd6bSMtfb4Zm2kjIaT/7gxXkeRicLv3RLXQZ0JPwn85sWidAwP8ogeWsNOFO3rE+IcqJbgRmtPtutBX4HQi1vShFHyttQMMkOM+r5/kv5bak9wX0yOa3c/9ZmznKjZpWfY6ywdKLWpo+s9QSJJ8RvjkEjXjPTqj0PUc05Yxql8yelQUps5UIys+gdg== X-YMail-OSG: w0ETXf8VM1k9RT2WPGvoprEECATyYXyRjwBm0c6D_mSEOIMi8aW2zEHYxGwOC31 lKkNsInarhV7uERVDCes2.PZ.EL4QYFMcSgF_mSCDjdC3bHukY2tF0W8GUedPdEPX3HA9aLIZRmm PK9ll5kauXIU2sFYNXKyfz2ruEMEfsKfbHZu9yQO4j6wbHpswMm.JkAZ9NQPNTOjDCyZatmNoCgC Uqxf6daJV7HT_4KR9yTVAkkdGBqX0j88vzRlOpWhaT_apyu2gByRhoMAwHU3b1Q5PvhhOwEqnB2F emzjz_2OywiR7y3Eb8fb1B9UOEc1Izaw4ih3HCO58D7Kgcy1R5QBgZSm4AIFOwr95euBoixqVOum sG4wnp937j.Dtiq88MPfWg46izf4dqYi6lqRu1vM8HkxMFIKPGl3K85ZE7W6_if4tLbGujPiIhge v2iwsFBInxfCEyGm.5ZBKMTRgpsMjrT6yZgYrwjLGQLFTipTb7UAKE.4XMXO0wlwozFZlldcqXPJ xgEVAzBxqENC8EJQ2bNmAp8y_97za34U5H5YNAoPDppZO3nr1W0KcrVywbjI8HG5.3xyinEUMYZV lmSVdSpwYRrue1JFnyDYO4kMLhTqdcQgtsM1zyMVEWoIWhj0lnr4DeOSI2iWAkNzks9xTjeKyjpV BdUA_YGLyEebzJ2qojKF_vjwbZl5n5GqAGlRh_V2YEqzbA7ToFm7S9hW7NckzDd_osweB8bui7tN WgFlyugFHinzV8oqM.rPQuXM99Y8BUizgkrcN9qi5i.no7PWIMegDe3wZbMNx3c5Txb0XZ95igW6 TSCy58VlfT3Zti4VTxvKExxpReDe9pERBkjfrufIfbHE_eXCGM_ahCTrqDnk7FHo_B5bXX91AHCJ YaJ5nxhI5T.Im8SQeIpkTVbL1s.amnqoPRQOplre7LkvIT0IluVbax7a3Hu5pAUBqSZvVWRtCuuo MTFYCohmR.e0uMp18KLLdv0b.XSk9gfOQOU7uzpSaSdspO.Ks4XK6V1cxqA6YeUdpITaK.d0BmCM b1sQOZ0k- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 12:59:52 +0000 Date: Fri, 16 Nov 2018 12:59:50 +0000 (UTC) From: Tomek Stojecki To: Torsten Lodderstedt , Brock Allen Cc: oauth@ietf.org Message-ID: <915498670.1574190.1542373190714@mail.yahoo.com> In-Reply-To: <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1574189_953558317.1542373190710" X-Mailer: WebService/1.1.12729 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 16 Nov 2018 12:59:57 -0000 ------=_Part_1574189_953558317.1542373190710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >>=C2=A0The AS can bind the lifetime of the refresh tokens to the session = lifetime, i.e. automatically revoke it on logout.=C2=A0 > Yea, I saw your other email asking about refresh token revocation relatin= g to session management. Obviously for certain clients, this won't make sen= se, but for implicit/browser-based ones it's a nice feature to have. I agree that this can be useful, however with where we are today, is this s= upported by auth servers such that it can distinguish offline from renewabl= e-online clients and only revoke the latter when logging out?=C2=A0 > The alternative, as you mentioned, is to not issue refresh tokens and do = token renewal the "same old way" via iframe with prompt=3Dnone, while still= using code flow. Going from Implicit to Code deals with the problem of sending RT in the URL= , which I agree is a plus. Is there anything else in a way of an improvemen= t?=C2=A0I still am not comfortable enough with the idea of releasing RTs to= the browser clients=C2=A0where it can't be encrypted, prone to xss, etc...= =C2=A0 -Tomek On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Brock Allen wrote: =20 =20 >=C2=A0It still lacks the ability to issue sender constraint access toke= ns. So you mean at the resource server ensuring the token was really issued to = the client? Isn't that an inherent limitation of all bearer tokens (modulo = HTTP token binding, which is still some time off)? Resource servers don't k= now the flow the clients might use, especially if/when they have many clien= ts. >=C2=A0The AS can bind the lifetime of the refresh tokens to the session li= fetime, i.e. automatically revoke it on logout.=20 Yea, I saw your other email asking about refresh token revocation relating = to session management. Obviously for certain clients, this won't make sense= , but for implicit/browser-based ones it's a nice feature to have. The alternative, as you mentioned, is to not issue refresh tokens and do to= ken renewal the "same old way" via iframe with prompt=3Dnone, while still u= sing code flow. >=C2=A0The only potential =E2=80=9Ebaby step=E2=80=9C I would see is to mov= e towards =E2=80=9Etoken id_token=E2=80=9C. Since this requires signature/a= t_hash checks etc. I doubt this is really easier than moving to code and ex= change the code for an access token. What=E2=80=99s your opinion? Even since OIDC arrived, this is the only flow I use for JS/browser-based c= lients (anything less has always seemed so obviously inferior). So for me a= nd my customers, all browser-based clients I am involved in are already the= re. Perhaps this is the reason for all of my questions/comments about the r= ecent BCP doc. Given "id_token token", CSP, and using the browser history A= PI to wipe the access token from browser history, we already have a decent = set of tools to mitigate attacks. As I already conceded, the only remaining= issue (IMO) is the short window of time the access token is in the URL. Given that it seems to me that OIDC and OAuth2 are typically used together= =C2=A0(at least when a user is involved with authentication), I always wond= er=C2=A0why the OAuth and OIDC WGs are separate. Given that so much effort = of the two sets of specs overlap, it seems odd to keep adding onto the OAut= h specs and ignoring the added features that OIDC provides. I don't mean to= derail this thread, or step on any political toes, so apologies in advance= . -Brock _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_1574189_953558317.1542373190710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>> The AS can bin= d the lifetime of the refresh tokens to the session lifetime, i.e. automati= cally revoke it on logout. 

> Yea, I saw your other email asking abo= ut refresh token revocation relating to session management. Obviously for c= ertain clients, this won't make sense, but for implicit/browser-based ones = it's a nice feature to have.

I agree that this can be useful, however with where we are today, i= s this supported by auth servers such that it can distinguish offline from = renewable-online clients and only revoke the latter when logging out? =

> The alternative, as you mentio= ned, is to not issue refresh tokens and do token renewal the "same old way"= via iframe with prompt=3Dnone, while still using code flow.

Going from Implicit to Code deals with the pro= blem of sending RT in the URL, which I agree is a plus. Is there anything e= lse in a way of an improvement? I still am not comf= ortable enough with the idea of releasing RTs to the browser clients=  where it can't be encrypted, prone to xss, etc... 
<= div style=3D"color: rgb(0, 0, 0); font-family: Lucida Console; font-size: 1= 3.3333px;">

-Tomek
<= /div>

=20
=20
On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Broc= k Allen <brockallen@gmail.com> wrote:


=20 =20 =20 =20 =20 > It still lacks the ability to issue sender constraint access tokens.=

So you mean at the resource serve= r ensuring the token was really issued to the client? Isn't that an inheren= t limitation of all bearer tokens (modulo HTTP token binding, which is stil= l some time off)? Resource servers don't know the flow the clients might us= e, especially if/when they have many clients.

=
> The AS can bind the li= fetime of the refresh tokens to the session lifetime, i.e. automatically re= voke it on logout.

=
Yea, I saw your other email asking about refresh token revocation rela= ting to session management. Obviously for certain clients, this won't make = sense, but for implicit/browser-based ones it's a nice feature to have.

The alternative, as you mentioned, is = to not issue refresh tokens and do token renewal the "same old way" via ifr= ame with prompt=3Dnone, while still using code flow.

> = ;The only potential = =E2=80=9Ebaby step=E2=80=9C I would see is to move towards =E2=80=9Etoken i= d_token=E2=80=9C. Since this requires signature/at_hash checks etc. I doubt= this is really easier than moving to code and exchange the code for an acc= ess token. What=E2=80=99s your opinion?

Even since OIDC arrived, this is th= e only flow I use for JS/browser-based clients (anything less has always se= emed so obviously inferior). So for me and my customers, all browser-based = clients I am involved in are already there. Perhaps this is the reason for = all of my questions/comments about the recent BCP doc. Given "id_token toke= n", CSP, and using the browser history API to wipe the access token from br= owser history, we already have a decent set of tools to mitigate attacks. A= s I already conceded, the only remaining issue (IMO) is the short window of= time the access token is in the URL.

Given that it seems to me that OIDC a= nd OAuth2 are typically used together (at least when a user is involved with authent= ication), I always w= onder why the O= Auth and OIDC WGs are separate. Given that so much effort of the two sets o= f specs overlap, it seems odd to keep adding onto the OAuth specs and ignor= ing the added features that OIDC provides. I don't mean to derail this thre= ad, or step on any political toes, so apologies in advance.


-Brock

=20
___________= ____________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------=_Part_1574189_953558317.1542373190710-- From nobody Fri Nov 16 07:11:25 2018 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 3F37812D4EB for ; Fri, 16 Nov 2018 07:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 oV1CByZJ-Rff for ; Fri, 16 Nov 2018 07:11:22 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 C26B012DD85 for ; Fri, 16 Nov 2018 07:11:22 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id o125so37857946qkf.3 for ; Fri, 16 Nov 2018 07:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:in-reply-to:references :user-agent; bh=l1+yt18WgPIT39cbub79GCxDaUAc0s9QTLQcn0O/H48=; b=r1a4+9ZBci31tVU7WOKYXxTlAi6Y6tt6Tpjq8j1J7Hn1pZ9+7cL6wzIBu5+5YDePDO hfHZo6jSf7cX+j21oy3PLJyCDoihXKR2OpjEbYDXv6ZNCxlfbMSaMxyth8NGHn4zuTwX 2tNIFgY01WifUEa3EqzpDTk1ce8b33q4N/B4bp5Du9BlDOi6A3ieIPzyZ3SaBAkDZtWT 8KjwmIkVpWQlTTI12IVN7M5IacnWm3bL4eTQ7HnTHqwkiHh7eyMurN/vJgeVtIQ4iNPc yln/E/kwKd3OQCVfbaQF1RfSXTeARtoicfsQ3J2LCI65M5tv3A58J88At2kqUdGOQPXn p9Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :in-reply-to:references:user-agent; bh=l1+yt18WgPIT39cbub79GCxDaUAc0s9QTLQcn0O/H48=; b=ct0sZ0x/fxTBj2OG6/VtYQtPsrcWSK9QtBtoWBV9TZ9L4sWthFHC+It3nXU+9sNucG hTjzdyv7NguriigDmZfMM4CTJ2S4gxNVwPXZBX4j2uvadFGj4hcSZy5cQXy1tWsDgDTM vakrssMHYK4LRZrXP78nCIdHs9RCiWA1krlm5NiJDrGGVtB+TpMlg0lbii5vj4lYDY0X VlVAtPAUb5+cLfeQ9ArU6zeVQTW+mXg+DgbCfd4fk9OsH/vgkJenUWZskzr2CzXhfEGX G3YGRwkeiJ2vMOBSteUhBA5OXz9IcqJ4+gEG7sewN4QpjY3DwZ8Qsv2TqsKgyo7uqB0s hutw== X-Gm-Message-State: AGRZ1gIUIUAQ43KSwRfYAMjmdyo8YJaaOr5E7ntvS6DZorRs3G/azyZL 1pWSDT8L6xPtelsRmKSDpoc= X-Google-Smtp-Source: AJdET5d8DrzVBMgdhTPaYgAM5Jv7/pRQsaprXyBRNWmHw4KQw6M9Q3GzGyrikNQ8AOjQC4hrj+Fw4Q== X-Received: by 2002:ac8:3790:: with SMTP id d16mr10644725qtc.20.1542381081689; Fri, 16 Nov 2018 07:11:21 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id a50sm16821535qtb.38.2018.11.16.07.11.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Nov 2018 07:11:20 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_32609194.201174770633" MIME-Version: 1.0 Date: Fri, 16 Nov 2018 10:11:17 -0500 Message-ID: <155c95ac-ac34-48fb-ad0e-7d8102c11530@getmailbird.com> From: "Brock Allen" To: "Daniel Fett" , "" In-Reply-To: References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> User-Agent: Mailbird/2.5.23.0 X-Mailbird-ID: 155c95ac-ac34-48fb-ad0e-7d8102c11530@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 16 Nov 2018 15:11:24 -0000 ------=_NextPart_32609194.201174770633 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0Could you please expand on what you are achieving with replacing the= URL using the history API? Removing the token from the browser's history, = or any protection beyond that? Just this block of code which would be run on the redirect_uri page loaded = in the client (after id_token/token validation is complete): https://github.com/IdentityServer/IdentityServer4.Samples/blob/release/Clie= nts/src/JsOidc/wwwroot/callback.js#L4-L6 -Brock ------=_NextPart_32609194.201174770633 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;Could you please expand on what you are ac= hieving with replacing the URL using the history API? Removing the token fr= om the browser's history, or any protection beyond that?

Just this b= lock of code which would be run on the redirect_uri page loaded in the clie= nt (after id_token/token validation is complete):

https://github.com/IdentitySer= ver/IdentityServer4.Samples/blob/release/Clients/src/JsOidc/wwwroot/callbac= k.js#L4-L6

-Brock

=0A =0A =
------=_NextPart_32609194.201174770633-- From nobody Fri Nov 16 08:01:28 2018 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 33E82130934 for ; Fri, 16 Nov 2018 08:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 qaAZ3q-dKNEX for ; Fri, 16 Nov 2018 08:01:24 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 F238C12D4E7 for ; Fri, 16 Nov 2018 08:01:23 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id a132so38173094qkg.1 for ; Fri, 16 Nov 2018 08:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=DlZQB1B5eO/fVL0RwfbQWXihujmBJ5IwMi9b0edgNLo=; b=uZyEMHv1cLLVzShIcyJSo4xcWVRRTTqs9TGgxrW44kRvVW2MiVhQDL9kKwoJQo3ZLt ptXHTUSirKJ/Z+mF3I4HUVNiOzIVIAWKusGDYqHTH5DzTCRIizmUwPjPLOcZja6Loket yIKVpL5Z+3o5tT7IGPJFYBH00Ll26GMmjRJCh8CNr9a0jIiPzEiaDs48RJiprswL7nFf 6n+1bk6LmwsJIhOtDwpDHjJwO+LhApgz5sKZwFsBmD5D8iZnOLRWnfaoEt7b9Wtd+4ON c5OdUhQXz7+no5N1Y4+wAhj/J+FAjg1jaK0bq94pOzxNS9mp2nmkBEe7aGiyEv+eI9zE SJ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=DlZQB1B5eO/fVL0RwfbQWXihujmBJ5IwMi9b0edgNLo=; b=PsxmJgnR3/kAw6wpDS/slYz7+IIG/msdkxBJip9SMPP/hg1ixDZ485gbujc1/1F5CK LEoFQWiwKxy5ZIzxXGTqEgGHr6d5fhUaErtQJARvo0gNvsDqwGYdQwqi/qnjvByLml91 JK3iQcKiQcXQsDkVGQh9H73NhSkIHml5FUQPZ0BvxzhFU4e75+m9dd9wqgXy3aWNe8IU 154HXPa35IFiW1LTZnuSt6bPQuqZs9NcwjktUSrB/LivRZyeSZ0CNb4Fo2HHwaPxRPCw 1Q+GZXGGZDWBzdo3xw1PbFnTcVfSOLHzu1cajMEZ2jElzQoyFGUgszNJnhtB562kdXA/ f/pA== X-Gm-Message-State: AGRZ1gKjMvkPHjEjvzTf8NN9CFRtrG/8oxT5mpUjWNFT1HPfwRTWFQxd XLDnRhaGHcDO4GftxUX4dcw= X-Google-Smtp-Source: AJdET5c26KZSyZvRI+ZwRqNqzmWMkKd94w7XdRtua3hBmKYnh4VsrRwqHt++ILubBqOnwk1bUuC+PA== X-Received: by 2002:a37:b842:: with SMTP id i63mr10815643qkf.69.1542384082977; Fri, 16 Nov 2018 08:01:22 -0800 (PST) Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id q72sm6400396qki.24.2018.11.16.08.01.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Nov 2018 08:01:22 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_66048979.739371682387" MIME-Version: 1.0 Date: Fri, 16 Nov 2018 11:01:19 -0500 Message-ID: <67e12564-f8c0-4c64-8fc1-ae6851a678bd@getmailbird.com> From: "Brock Allen" To: "Tomek Stojecki" , "Torsten Lodderstedt" Cc: "" In-Reply-To: <915498670.1574190.1542373190714@mail.yahoo.com> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> User-Agent: Mailbird/2.5.23.0 X-Mailbird-ID: 67e12564-f8c0-4c64-8fc1-ae6851a678bd@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 16 Nov 2018 16:01:26 -0000 ------=_NextPart_66048979.739371682387 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0Going from Implicit to Code deals with the problem of sending RT in = the URL, which I agree is a plus. Is there anything else in a way of an imp= rovement?=C2=A0 As far as I can tell, that's the only additional security feature (beyond w= hat we already use for mitigations today) that code flow adds. That's why I= was hoping for the proposed BCP to explicitly point this out, which means = all the other mitigations and guidance in the document are valid and useful= for implicit flow. -Brock ------=_NextPart_66048979.739371682387 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;Going from Implicit to Code deals with the= problem of sending RT in the URL, which I agree is a plus. Is there anythi= ng else in a way of an improvement? 

As far as I= can tell, that's the only additional security feature (beyond what we alre= ady use for mitigations today) that code flow adds. That's why I was hoping= for the proposed BCP to explicitly point this out, which means all the oth= er mitigations and guidance in the document are valid and useful for implic= it flow.

-Brock
<= span style=3D"font-family: Lucida Console">
=0A = =0A
------=_NextPart_66048979.739371682387-- From nobody Fri Nov 16 14:44:26 2018 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 5E4C8130E6E for ; Fri, 16 Nov 2018 14:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 RrVJo9M9JkgX for ; Fri, 16 Nov 2018 14:44:20 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54747130E39 for ; Fri, 16 Nov 2018 14:44:20 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id f6so15262598iob.1 for ; Fri, 16 Nov 2018 14:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mzoc3wNXdQiNTm3S5NQZ7v8SmRiZIsBCuSBjJUImGUU=; b=cunStdKu1Hk5IVrGIchmQ/uBLb0knMzt+hwgu3wPUu6o9hdyT5s568cyM3bYnUSH4I cvYJAZzv6L/xKFcJeis7dNBxiaS46EYig5l9/Ix0GOgh6FZnMNbp7uSeYcDQEQsA57ZB i1sAlTnBQJ2Qu1mHmXtMPdmt8qV0P7oXPCkL4= 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=Mzoc3wNXdQiNTm3S5NQZ7v8SmRiZIsBCuSBjJUImGUU=; b=oKvlTFuEjz09ewjytx2lJWu7strx/QDr3BDT31HIt7NrGXpsWg6t/PQhBqsLOmH8XN 0enwT4HaoV6Mop+bBGDM0De59x0wYP6uROjhAxTNC9bpS31RR0DkJ9ezxoZL4f0ObibV IMUqmi2ITgbMq3dL5Y8Ss/+//XFi62qwMEfgnC9jIf7Ap3pLrzczWag2A/c/04WRexYu /NEb5NE5OR78+Ue84DCJpBG2ULdKKeUU/1ZGPjTcBuScex2dxs4VEUJmrcku/qdhiftq MZft0o1aSRmYI4NXnuXbksCPirRaQmj74tiEqfi8xgeeYApaqzssfChXUW+RfnBH3vcD IDHA== X-Gm-Message-State: AA+aEWaEYLOLKJW4xUBx9A53T93G2Ptz2NriS9SCBCXBMPNZJJeu+wXo zFG3Vh5+ppd4xHHzDPG62dCF/ijycnDL9h8Pm1i242tK7LgAbZPfOHVYHeBS21ohF6f/+TF4FQ9 itPdcg/gD5okqGQ== X-Google-Smtp-Source: AFSGD/WpJSKSne+M46PZptHF8OZqmyMdzByDIq5jzaRGh9wrJqELGk10S4iOg4ZMAXwo6i/mBBl7z5qWzO9B1fPIGJM= X-Received: by 2002:a6b:710b:: with SMTP id q11mr8958997iog.138.1542408259304; Fri, 16 Nov 2018 14:44:19 -0800 (PST) MIME-Version: 1.0 References: <369D0056-3FC0-417A-ADF0-7550EBB9794E@forgerock.com> <129B91F9-E471-4AE4-98D3-F534D6BF09C1@mit.edu> <1AEDD443-72AD-4F46-9005-D64794C055AA@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Fri, 16 Nov 2018 15:43:52 -0700 Message-ID: To: Evan Gilman Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="0000000000006517a3057acfe8ca" Archived-At: Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 22:44:24 -0000 --0000000000006517a3057acfe8ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Evan. This seems like a good start and I'll plan to work to incorporate the proposal in some/similar form into the next revision of the document. Comments, clarifications, etc. from the WG are also always welcome too in the meantime. Or from the AD, who also suggested allowing for the use of SAN. But this seems to generally fit the bill to allow for SAN-based subject identification of the client in the certificate. Having thought a bit more about the structured vs. flat metadata, I think I've come to a similar conclusion as you have. On Thu, Nov 15, 2018 at 5:41 PM Evan Gilman wrote: > I have taken a stab at some text that will open the door for SAN-based > subject identity support. Some minor modifications in section 2.1, and > additional metadata parameters in section 2.1.2. Please find that text > below. > > > I scanned through the SPIFFE docs but didn=E2=80=99t any mentioning of = OAuth > (just plain X.509). What=E2=80=99s your plan for introducing OAuth and mt= ls? > > That is correct - SPIFFE does not currently involve any OAuth works... > the use case for this change was brought to my attention a couple of > weeks ago: use SPIFFE identities in "cloud native" environments to > authenticate to an OAuth server in order to receive an access token > for authentication with on-prem infrastructure which is OAuth-enabled. > Doing so relieves a good deal of pressure around OAuth client (and > secret) management. That said, I think the proposed change here is > beneficial on all counts, and not just an accommodation for SPIFFE > authentication. As I mentioned previously, there are several other > projects that are relying on SAN rather than DN for subject identity > and the number is growing. > > I tried to think through what the text would look like to support a > structured value for a parameter named `tls_client_auth_san`, but ran > into a couple sticking points... the first is that it is certainly > more complex and would require more text, and feels more error prone > than simply introducing additional metadata parameters. Second, we > would need to strictly define supported values for `type`, and it > wasn't immediately clear if this is something that would need to be > centrally registered. I am curious to hear thoughts on the structured > value approach versus that which I took below. > > 2.1. PKI Mutual TLS OAuth Client Authentication Method > > The PKI (public key infrastructure) method of mutual TLS OAuth client > authentication uses a subject name (DN or SAN) and validated > certificate chain to identify the client. The TLS handshake is > utilized to validate the client's possession of the private key > corresponding to the public key in the certificate and to validate > the corresponding certificate chain. The client is successfully > authenticated if the subject information in the certificate matches > the expected subject configured or registered for that particular > client (note that a predictable treatment of DN values, such as the > distinguishedNameMatch rule from [RFC4517], is needed in comparing > the certificate's subject DN to the client's registered DN). If and > how to check a certificate's revocation status is a deployment > decision at the discretion of the authorization server. The PKI > method facilitates the way X.509 certificates are traditionally being > used for authentication. It also allows the client to rotate its > X.509 certificates without the need to modify its respective > authentication data at the authorization server by obtaining a new > certificate with the same subject from a trusted certificate > authority (CA). > > and > > 2.1.2. Client Registration Metadata > > The following metadata parameters are introduced for the OAuth 2.0 > Dynamic Client Registration Protocol [RFC7591] in support of the PKI > method of binding a certificate to a client: > > tls_client_auth_subject_dn > An [RFC4514] string representation of the expected subject > distinguished name of the certificate, which the OAuth client will > use in mutual TLS authentication. > > tls_client_auth_san_dns > A string containing the value of an expected dNSName SAN entry > in the certificate, which the OAuth client will use in mutual TLS > authentication. > > tls_client_auth_san_uri > A string containing the value of an expected > uniformResourceIdentifier SAN entry in the certificate, which > the OAuth client will use in mutual TLS authentication. > > tls_client_auth_san_ip > A string representation of an IP address in either dotted decimal > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as > defined in [RFC4291] section 2.2) that is expected to be present > as an iPAddress SAN entry in the certificate, which the OAuth > client will use in mutual TLS authentication. > > tls_client_auth_san_email > A string containing the value of an expected rfc822Name SAN > entry in the certificate, which the OAuth client will use in > mutual TLS authentication. > > On Tue, Nov 13, 2018 at 6:24 AM Torsten Lodderstedt > wrote: > > > > Hi Evan, > > > > I scanned through the SPIFFE docs but didn=E2=80=99t any mentioning of = OAuth > (just plain X.509). What=E2=80=99s your plan for introducing OAuth and mt= ls? > > > > kind regards, > > Torsten. > > > > > Am 13.11.2018 um 00:59 schrieb Evan Gilman : > > > > > > Thank you everyone for the feedback. > > > > > > I am currently working on the sample text, and should be complete in > > > the next couple days. Apologies for the delay. > > > On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell > > > wrote: > > >> > > >> Sure, I think they could be treated as different different > client_auth_methods. But there is a lot more commonality than differences > to the point where I think it makes sense to keep it all in a single > document and under a single client auth method with just the variation on > which name is being used. > > >> > > >> On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer > wrote: > > >>> > > >>> Would it make sense for these to be a different client_auth_method > entirely? Much the same way that we have private_key_jwt and > client_secret_jwt today, both of which use the JWT assertion framework bu= t > have very different keying and security assumptions. In the same way, her= e > you=E2=80=99re still validating the cert but the means by which it=E2=80= =99s validated is > different, so the auth method is arguably not going to benefit from being > overloaded. Caveat, I=E2=80=99ve not built out a system using SANs in any > meaningful way. > > >>> > > >>> If we were to do that, this draft could go forward as-is (since it= =E2=80=99s > fairly done in my opinion) and a new document could better define the > semantics for the various SAN types, but while building on the framework > and concepts listed in here. > > >>> > > >>> =E2=80=94 Justin > > >>> > > >>> On Nov 6, 2018, at 3:52 PM, Evan Gilman wrote: > > >>> > > >>> Response(s) inline > > >>> > > >>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden < > neil.madden@forgerock.com> wrote: > > >>> > > >>> > > >>> Is there an intention that any semantics are attached to the SAN > being a URI or DNS name or IP or ...? Or is it still intended to be an > opaque identifier? > > >>> > > >>> > > >>> There are some extra things we could do if we attached type-specifi= c > > >>> semantics to the matching (e.g. DNS wildcarding etc), however I thi= nk > > >>> that continuing to use the values as opaque identifiers would get u= s > > >>> most of what we need while keeping things simple. > > >>> > > >>> On 6 Nov 2018, at 01:55, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > >>> > > >>> Thanks Evan for bringing this to the WG's attention. More or less > the same question/issue was raised yesterday in the area director's revie= w > of the document as well. I plan to bring this up as a discussion item in > the meeting today. But my sense from some early discussions is that there > is likely to be (rough) consensus to make some change in order to allow a > SAN to be specified as the certificate subject identifier in the PKI clie= nt > auth mode. We'll need to figure out the specifics of how that works. I > don't think there are significant drawbacks to extending the number of > client registration metadata parameters per se. I guess I've just been > attracted to the idea of overloading the existing value because that felt > like maybe a less invasive change. But perhaps that's shortsighted. And > there's nothing inherently wrong with additional client metadata paramete= rs. > > >>> > > >>> I don't know if we could get away with a single new parameter that > could carry the value for any SAN type. Something like, { ... > "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I > feel like that'd probably be okay but in theory there's the potential for > confusion of the value across different types. So probably there's a need > to indicate the SAN type too. Either with more client metadata parameters > like tls_client_auth_san_uir, tls_client_auth_san_email, > tls_client_auth_san_ip, etc. or maybe with a structured value of some sor= t > like {... "tls_client_auth_san": {"type":"URI", > "value":"spiffe://trust-domain/path"} ... }. And then deciding which type= s > to support and if/how to allow for the extensible types. > > >>> > > >>> > > >>> I am far from an authority here, but it is my understanding that on= e > > >>> of the primary drivers in supporting SAN over Subject is that the > > >>> values are strongly typed. While some of the advantages gained from > > >>> this may be less useful in our own context, I feel that it make sen= se > > >>> to keep the values separate and not overload a single value. Whethe= r > > >>> that means dedicated metadata parameters or a structured parameter > > >>> value, I am not sure what the tradeoffs would be, but both options > > >>> sound suitable to me. > > >>> > > >>> Anyway, those are just some thoughts on it. And it'll be discussed > more today. Suggested/proposed text is always helpful though (even if it'= s > not used directly it can help move the conversation forward and/or help > editor(s) to have prospective wording). > > >>> > > >>> > > >>> Great. I will work on some sample text since it sounds like that > would > > >>> be generally helpful > > >>> > > >>> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman > wrote: > > >>> > > >>> > > >>> Hello everyone.. > > >>> > > >>> Very excited to see this draft. It helps tremendously in addressing > > >>> use cases around oauth client management in machine-to-machine > > >>> scenarios. Particularly, the PKI authentication method. > > >>> > > >>> In reviewing the document, I noticed that the only supported method > > >>> for identifying a client using the PKI authentication method is by > > >>> referencing its distinguished name. This caught me a bit by surpris= e > - > > >>> many newer projects aimed at automating X.509 issuance in the > > >>> datacenter utilize SAN extensions rather than distinguished name in > > >>> order to encode identity. I am further under the impression that th= e > > >>> community is, in general, moving away from the subject extension > > >>> altogether in favor of SAN-based identification. > > >>> > > >>> Full disclosure: I am one of the maintainers on a project called > > >>> SPIFFE, which provides identity specifications for datacenter > workload > > >>> applications. For X.509, SPIFFE encodes identity into a URI SAN > > >>> extension. A number of projects using SPIFFE do not configure the > > >>> subject with identifying information (SPIRE and Google Istio being > > >>> just a couple). I am also hearing of other X.509 automation project= s > > >>> which are moving away from subject/distinguished name (even if they > > >>> are not using SPIFFE). > > >>> > > >>> While I think support for distinguished name is absolutely necessar= y, > > >>> I worry that supporting it solely will render it incompatible with > > >>> some of the more modern PKIX systems and not stand the test of time= . > I > > >>> know that I am a little late to this, and for that I apologize... b= ut > > >>> I feel this is a significant point. > > >>> > > >>> I would like to open a discussion on supporting the most commonly > used > > >>> SAN extension types in addition to distinguished name. To accomplis= h > > >>> this, amending section 2.1.2 `Client Registration Metadata` with > > >>> additional parameters seems appropriate. In my experience, the most > > >>> commonly used SAN extensions are: DNS name, IP address, URI, and > email > > >>> address. > > >>> > > >>> Are there significant drawbacks to extending the number of client > > >>> registration metadata parameters? I would very much like to see thi= s > - > > >>> without it, many existing projects will be unable to use the spec. = I > > >>> am happy to contribute time and text to this, assuming people feel > > >>> that this is a beneficial addition. Sorry again for the timing > > >>> > > >>> -- > > >>> evan > > >>> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>> > > >>> > > >>> > > >>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > >>> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> evan > > >>> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>> > > >>> > > >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > > > > > > > > > > > -- > > > evan > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > evan > --=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._ --0000000000006517a3057acfe8ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Evan.

This seems like a good start and I'll plan to w= ork to incorporate the proposal in some/similar form into the next revision= of the document. Comments, clarifications, etc. from the WG are also alway= s welcome too in the meantime. Or from the AD, who also suggested allowing = for the use of SAN. But this seems to generally fit the bill to allow for S= AN-based subject identification of the client in the certificate.

Having thought a bit more about the structured vs. fl= at metadata, I think I've come to a similar conclusion as you have.
=





=




On Thu, Nov 15, 2018 at 5:41 PM E= van Gilman <evan2645@gmail.com= > wrote:
I have taken a stab at = some text that will open the door for SAN-based
subject identity support. Some minor modifications in section 2.1, and
additional metadata parameters in section 2.1.2. Please find that text
below.

> I scanned through the SPIFFE docs but didn=E2=80=99t any mentioning of= OAuth (just plain X.509). What=E2=80=99s your plan for introducing OAuth a= nd mtls?

That is correct - SPIFFE does not currently involve any OAuth works...
the use case for this change was brought to my attention a couple of
weeks ago: use SPIFFE identities in "cloud native" environments t= o
authenticate to an OAuth server in order to receive an access token
for authentication with on-prem infrastructure which is OAuth-enabled.
Doing so relieves a good deal of pressure around OAuth client (and
secret) management. That said, I think the proposed change here is
beneficial on all counts, and not just an accommodation for SPIFFE
authentication. As I mentioned previously, there are several other
projects that are relying on SAN rather than DN for subject identity
and the number is growing.

I tried to think through what the text would look like to support a
structured value for a parameter named `tls_client_auth_san`, but ran
into a couple sticking points... the first is that it is certainly
more complex and would require more text, and feels more error prone
than simply introducing additional metadata parameters. Second, we
would need to strictly define supported values for `type`, and it
wasn't immediately clear if this is something that would need to be
centrally registered. I am curious to hear thoughts on the structured
value approach versus that which I took below.

2.1.=C2=A0 PKI Mutual TLS OAuth Client Authentication Method

=C2=A0 =C2=A0The PKI (public key infrastructure) method of mutual TLS OAuth= client
=C2=A0 =C2=A0authentication uses a subject name (DN or SAN) and validated =C2=A0 =C2=A0certificate chain to identify the client.=C2=A0 The TLS handsh= ake is
=C2=A0 =C2=A0utilized to validate the client's possession of the privat= e key
=C2=A0 =C2=A0corresponding to the public key in the certificate and to vali= date
=C2=A0 =C2=A0the corresponding certificate chain.=C2=A0 The client is succe= ssfully
=C2=A0 =C2=A0authenticated if the subject information in the certificate ma= tches
=C2=A0 =C2=A0the expected subject configured or registered for that particu= lar
=C2=A0 =C2=A0client (note that a predictable treatment of DN values, such a= s the
=C2=A0 =C2=A0distinguishedNameMatch rule from [RFC4517], is needed in compa= ring
=C2=A0 =C2=A0the certificate's subject DN to the client's registere= d DN).=C2=A0 If and
=C2=A0 =C2=A0how to check a certificate's revocation status is a deploy= ment
=C2=A0 =C2=A0decision at the discretion of the authorization server.=C2=A0 = The PKI
=C2=A0 =C2=A0method facilitates the way X.509 certificates are traditionall= y being
=C2=A0 =C2=A0used for authentication.=C2=A0 It also allows the client to ro= tate its
=C2=A0 =C2=A0X.509 certificates without the need to modify its respective =C2=A0 =C2=A0authentication data at the authorization server by obtaining a= new
=C2=A0 =C2=A0certificate with the same subject from a trusted certificate =C2=A0 =C2=A0authority (CA).

and

2.1.2.=C2=A0 Client Registration Metadata

=C2=A0 =C2=A0The following metadata parameters are introduced for the OAuth= 2.0
=C2=A0 =C2=A0Dynamic Client Registration Protocol [RFC7591] in support of t= he PKI
=C2=A0 =C2=A0method of binding a certificate to a client:

=C2=A0 =C2=A0tls_client_auth_subject_dn
=C2=A0 =C2=A0 =C2=A0 An [RFC4514] string representation of the expected sub= ject
=C2=A0 =C2=A0 =C2=A0 distinguished name of the certificate, which the OAuth= client will
=C2=A0 =C2=A0 =C2=A0 use in mutual TLS authentication.

=C2=A0 =C2=A0tls_client_auth_san_dns
=C2=A0 =C2=A0 =C2=A0 A string containing the value of an expected dNSName S= AN entry
=C2=A0 =C2=A0 =C2=A0 in the certificate, which the OAuth client will use in= mutual TLS
=C2=A0 =C2=A0 =C2=A0 authentication.

=C2=A0 =C2=A0tls_client_auth_san_uri
=C2=A0 =C2=A0 =C2=A0 A string containing the value of an expected
=C2=A0 =C2=A0 =C2=A0 uniformResourceIdentifier SAN entry in the certificate= , which
=C2=A0 =C2=A0 =C2=A0 the OAuth client will use in mutual TLS authentication= .

=C2=A0 =C2=A0tls_client_auth_san_ip
=C2=A0 =C2=A0 =C2=A0 A string representation of an IP address in either dot= ted decimal
=C2=A0 =C2=A0 =C2=A0 notation (for IPv4) or colon-delimited hexadecimal (fo= r IPv6, as
=C2=A0 =C2=A0 =C2=A0 defined in [RFC4291] section 2.2) that is expected to = be present
=C2=A0 =C2=A0 =C2=A0 as an iPAddress SAN entry in the certificate, which th= e OAuth
=C2=A0 =C2=A0 =C2=A0 client will use in mutual TLS authentication.

=C2=A0 =C2=A0tls_client_auth_san_email
=C2=A0 =C2=A0 =C2=A0 A string containing the value of an expected rfc822Nam= e SAN
=C2=A0 =C2=A0 =C2=A0 entry in the certificate, which the OAuth client will = use in
=C2=A0 =C2=A0 =C2=A0 mutual TLS authentication.

On Tue, Nov 13, 2018 at 6:24 AM Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:
>
> Hi Evan,
>
> I scanned through the SPIFFE docs but didn=E2=80=99t any mentioning of= OAuth (just plain X.509). What=E2=80=99s your plan for introducing OAuth a= nd mtls?
>
> kind regards,
> Torsten.
>
> > Am 13.11.2018 um 00:59 schrieb Evan Gilman <evan2645@gmail.com>:
> >
> > Thank you everyone for the feedback.
> >
> > I am currently working on the sample text, and should be complete= in
> > the next couple days. Apologies for the delay.
> > On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell
> > <bcampbell@pingidentity.com> wrote:
> >>
> >> Sure, I think they could be treated as different different cl= ient_auth_methods. But there is a lot more commonality than differences to = the point where I think it makes sense to keep it all in a single document = and under a single client auth method with just the variation on which name= is being used.
> >>
> >> On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer <jricher@mit.edu> wrote: > >>>
> >>> Would it make sense for these to be a different client_au= th_method entirely? Much the same way that we have private_key_jwt and clie= nt_secret_jwt today, both of which use the JWT assertion framework but have= very different keying and security assumptions. In the same way, here you= =E2=80=99re still validating the cert but the means by which it=E2=80=99s v= alidated is different, so the auth method is arguably not going to benefit = from being overloaded. Caveat, I=E2=80=99ve not built out a system using SA= Ns in any meaningful way.
> >>>
> >>> If we were to do that, this draft could go forward as-is = (since it=E2=80=99s fairly done in my opinion) and a new document could bet= ter define the semantics for the various SAN types, but while building on t= he framework and concepts listed in here.
> >>>
> >>> =E2=80=94 Justin
> >>>
> >>> On Nov 6, 2018, at 3:52 PM, Evan Gilman <evan2645@gmail.com> wrote= :
> >>>
> >>> Response(s) inline
> >>>
> >>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden <neil.madden@forgero= ck.com> wrote:
> >>>
> >>>
> >>> Is there an intention that any semantics are attached to = the SAN being a URI or DNS name or IP or ...? Or is it still intended to be= an opaque identifier?
> >>>
> >>>
> >>> There are some extra things we could do if we attached ty= pe-specific
> >>> semantics to the matching (e.g. DNS wildcarding etc), how= ever I think
> >>> that continuing to use the values as opaque identifiers w= ould get us
> >>> most of what we need while keeping things simple.
> >>>
> >>> On 6 Nov 2018, at 01:55, Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org> wrote:
> >>>
> >>> Thanks Evan for bringing this to the WG's attention. = More or less the same question/issue was raised yesterday in the area direc= tor's review of the document as well. I plan to bring this up as a disc= ussion item in the meeting today. But my sense from some early discussions = is that there is likely to be (rough) consensus to make some change in orde= r to allow a SAN to be specified as the certificate subject identifier in t= he PKI client auth mode. We'll need to figure out the specifics of how = that works. I don't think there are significant drawbacks to extending = the number of client registration metadata parameters per se. I guess I'= ;ve just been attracted to the idea of overloading the existing value becau= se that felt like maybe a less invasive change. But perhaps that's shor= tsighted. And there's nothing inherently wrong with additional client m= etadata parameters.
> >>>
> >>> I don't know if we could get away with a single new p= arameter that could carry the value for any SAN type. Something like, { ...= "tls_client_auth_san": "spiffe://trust-domain/path" ..= .}. In practice I feel like that'd probably be okay but in theory there= 's the potential for confusion of the value across different types. So = probably there's a need to indicate the SAN type too. Either with more = client metadata parameters like tls_client_auth_san_uir, tls_client_auth_sa= n_email, tls_client_auth_san_ip, etc. or maybe with a structured value of s= ome sort like {... "tls_client_auth_san": {"type":"= ;URI", "value":"spiffe://trust-domain/path"} ... }= . And then deciding which types to support and if/how to allow for the exte= nsible types.
> >>>
> >>>
> >>> I am far from an authority here, but it is my understandi= ng that one
> >>> of the primary drivers in supporting SAN over Subject is = that the
> >>> values are strongly typed. While some of the advantages g= ained from
> >>> this may be less useful in our own context, I feel that i= t make sense
> >>> to keep the values separate and not overload a single val= ue. Whether
> >>> that means dedicated metadata parameters or a structured = parameter
> >>> value, I am not sure what the tradeoffs would be, but bot= h options
> >>> sound suitable to me.
> >>>
> >>> Anyway, those are just some thoughts on it. And it'll= be discussed more today. Suggested/proposed text is always helpful though = (even if it's not used directly it can help move the conversation forwa= rd and/or help editor(s) to have prospective wording).
> >>>
> >>>
> >>> Great. I will work on some sample text since it sounds li= ke that would
> >>> be generally helpful
> >>>
> >>> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman <evan2645@gmail.com> wr= ote:
> >>>
> >>>
> >>> Hello everyone..
> >>>
> >>> Very excited to see this draft. It helps tremendously in = addressing
> >>> use cases around oauth client management in machine-to-ma= chine
> >>> scenarios. Particularly, the PKI authentication method. > >>>
> >>> In reviewing the document, I noticed that the only suppor= ted method
> >>> for identifying a client using the PKI authentication met= hod is by
> >>> referencing its distinguished name. This caught me a bit = by surprise -
> >>> many newer projects aimed at automating X.509 issuance in= the
> >>> datacenter utilize SAN extensions rather than distinguish= ed name in
> >>> order to encode identity. I am further under the impressi= on that the
> >>> community is, in general, moving away from the subject ex= tension
> >>> altogether in favor of SAN-based identification.
> >>>
> >>> Full disclosure: I am one of the maintainers on a project= called
> >>> SPIFFE, which provides identity specifications for datace= nter workload
> >>> applications. For X.509, SPIFFE encodes identity into a U= RI SAN
> >>> extension. A number of projects using SPIFFE do not confi= gure the
> >>> subject with identifying information (SPIRE and Google Is= tio being
> >>> just a couple). I am also hearing of other X.509 automati= on projects
> >>> which are moving away from subject/distinguished name (ev= en if they
> >>> are not using SPIFFE).
> >>>
> >>> While I think support for distinguished name is absolutel= y necessary,
> >>> I worry that supporting it solely will render it incompat= ible with
> >>> some of the more modern PKIX systems and not stand the te= st of time. I
> >>> know that I am a little late to this, and for that I apol= ogize... but
> >>> I feel this is a significant point.
> >>>
> >>> I would like to open a discussion on supporting the most = commonly used
> >>> SAN extension types in addition to distinguished name. To= accomplish
> >>> this, amending section 2.1.2 `Client Registration Metadat= a` with
> >>> additional parameters seems appropriate. In my experience= , the most
> >>> commonly used SAN extensions are: DNS name, IP address, U= RI, and email
> >>> address.
> >>>
> >>> Are there significant drawbacks to extending the number o= f client
> >>> registration metadata parameters? I would very much like = to see this -
> >>> without it, many existing projects will be unable to use = the spec. I
> >>> am happy to contribute time and text to this, assuming pe= ople feel
> >>> that this is a beneficial addition. Sorry again for the t= iming
> >>>
> >>> --
> >>> evan
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth= @ietf.org
> >>> https://www.ietf.org/mailman/listinfo/o= auth
> >>>
> >>>
> >>>
> >>> CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you.
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth= @ietf.org
> >>> https://www.ietf.org/mailman/listinfo/o= auth
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> evan
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth= @ietf.org
> >>> https://www.ietf.org/mailman/listinfo/o= auth
> >>>
> >>>
> >>
> >> CONFIDENTIALITY NOTICE: This email may contain confidential a= nd privileged material for the sole use of the intended recipient(s). Any r= eview, use, distribution or disclosure by others is strictly prohibited.=C2= =A0 If you have received this communication in error, please notify the sen= der immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you.
> >
> >
> >
> > --
> > evan
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>


--
evan

<= 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. --0000000000006517a3057acfe8ca-- From nobody Fri Nov 16 17:02:57 2018 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 B85AF130DE3 for ; Fri, 16 Nov 2018 17:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 35Imsxv1bf1P for ; Fri, 16 Nov 2018 17:02:53 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225ED126CB6 for ; Fri, 16 Nov 2018 17:02:53 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id k19-v6so21841912lji.11 for ; Fri, 16 Nov 2018 17:02:53 -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=Ja9qri60NFjZt8RrAy0+zGx/QemhGORnP5swrBQcCpA=; b=hrJZrO9OKJ7TskG0kHz4yfOQuRnlY+OxlTxI8PT/A3PxoFtCxKRX8VVE7Eznz+F7rY Ky594tzrH2lnoFouXJ3PGvIDUYoGIn65Gh90hyagXDyZ8Ql3cU9OMpFqYL769ct4qxOv V819ZBaRBJHQSk7ysbs2vmDOwfjHE9ExLfDkiS51dfmfkOFEh3wdsJhfHHJGCmnxlnbt U3D+zoOil4Q0FVTig/p0qGQ7azxsgJMLx0pI8yeLJTnAGJGYppyrC7ZyJtDqGn5++jx1 ZubPrClxWj1/jXfgsD/3FUYqTgbTe0A7YCttAsqQXAukfk1dpRLW6sfmy/8NfS/7lkTg GiMw== 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=Ja9qri60NFjZt8RrAy0+zGx/QemhGORnP5swrBQcCpA=; b=TB+xar5Eef1COCpndhOOVKdxts2JG4ljirsD5hw6XqziteGhzZ549nzc6X1rf067B6 F0UPEArVR75nMkUiARODNTyra70RmiEvAPnSmv6dYVVzo5W9d/h+m3ABDKPgkQUcZ8Qs Mn2DAoESJ9bJsE/bhcSVNVAE9almlxnfWY4SCAMF6PQoRD+2ShAH/uJga8BRVRfVuN6I lqPcxsVeArLhhM+PHSThXSrhsSB3Fb8h+ey2vAXWoBQlcYffKaM/wUlCAVCitEKlWsFx HEQfFrRqBO3jMZDV6NF9PF9Se/8v/aoRlMxkKOYJQ5i37hvsp+ZDlIeiBj/nMFkIpUWk xCMA== X-Gm-Message-State: AGRZ1gK6Oh5PaLi2mZ0FEdI0a1um6WQgG9cPFctSW5V0TwaHqonAKT5G a2dME32YdlRZ2GfUs/FBCrdZwqGnd34inK+IWoE= X-Google-Smtp-Source: AJdET5eKJJFN7zfVxwixemYeKIaoIYojjxAeZ+XqXrSDGp4ezUZEeOe0Eimny9OM8tnv6DyuqzdYV5b4MUxKV6oXSrc= X-Received: by 2002:a2e:9ec5:: with SMTP id h5-v6mr7241761ljk.40.1542416571087; Fri, 16 Nov 2018 17:02:51 -0800 (PST) MIME-Version: 1.0 References: <10bd2f07-d867-9db9-dfd7-9300617ec41b@aol.com> In-Reply-To: From: Dick Hardt Date: Fri, 16 Nov 2018 17:02:39 -0800 Message-ID: To: Nat Sakimura Cc: gffletch=40aol.com@dmarc.ietf.org, oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d0c173057ad1d766" Archived-At: Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2018 01:02:56 -0000 --000000000000d0c173057ad1d766 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nat Currently, you are the only one actively taking the position of Link-header. Perhaps you can educate the broader WG on the value of using Link-header over WWW-Authenticate? On Thu, Nov 15, 2018 at 11:27 PM n-sakimura wrote: > Hmmm. But the Link-header is the generalized discovery method which is > pretty widely used outside of OAuth community with the added benefit of > being able to find things without linking to authentication. > > > > *From:* OAuth *On Behalf Of *George Fletcher > *Sent:* Friday, November 09, 2018 12:12 AM > *To:* Dick Hardt ; gffletch=3D40aol.com@dmarc.ietf.= org > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AS Discovery in Distributed Draft > > > > Cool! Sorry I couldn't make the meeting. One benefit of using > WWW-Authenticate is that UMA has basically the same discovery logic (from > RS to AS) and uses the WWW-Authenticate header. Keeping this discovery > method the same (since UMA is just a profile of OAuth anyway) will help a= ll > developers. > > On 11/8/18 5:16 AM, Dick Hardt wrote: > > George: in the WG meeting we discussed this topic of where to put the > discovery information. No one at the meeting advocated for using Link > response (Nat was the one who was advocating for this). Many others > preferred using the www-authenticate header similar to how you propose. > > > > On Thu, Nov 8, 2018 at 4:08 AM George Fletcher 40aol.com@dmarc.ietf.org <40aol.com@dmarc.ietf..org>> wrote: > > Related to this discussion of AS discovery... what is the value of using > the Link response header over just returning the variables in the > WWW-Authenticate header? Could we not use... > > WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"example_scope", > error=3D"invalid_token", rs_uri=3D"https://api.example.com/resource" > , as_uri=3D > "https://as1.example.com,https://as2.example.com" > > > Thanks, > George > > On 11/6/18 12:19 AM, Justin P Richer wrote: > > In the meeting tonight I brought up a response to the question of whether > to have full URL or plain issuer for the auth server in the RS response= =E2=80=99s > header. My suggestion was that we have two different parameters to the > header to represent the AS: one of them being the full URL (as_uri) and o= ne > of them being the issuer to be constructed somehow (as_issuer). I ran int= o > a similar problem on a system that I built last year where all of our > servers had discovery documents but not all of them were easily construct= ed > from an issuer style URL (using OIDC patterns anyway). So we solved it by > having two different variables. If the full URL was set, we used that; if > it wasn=E2=80=99t, we tried the issuer; if neither was set we didn=E2=80= =99t do any > discovery. > > > > I=E2=80=99m sensitive to Torsten=E2=80=99s concerns about complexity, but= I think this is > a simple and deterministic solution that sidesteps much of the issue. No > pun intended. > > > > =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 > > > --000000000000d0c173057ad1d766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nat

Currently, you are the only one = actively taking the position of Link-header. Perhaps you can educate the br= oader WG on the value of using Link-header over WWW-Authenticate?

On Thu, Nov 15, 2018 at 1= 1:27 PM n-sakimura <n-sakimura@n= ri.co.jp> wrote:

Hmmm. But the Link-header is the generalized discover= y method which is pretty widely used outside of OAuth community with the ad= ded benefit of being able to find things without linking to authentication.

=C2=A0

From:= OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Friday, November 09, 2018 12:12 AM
To: Dick Hardt <dick.hardt@gmail.com>; gffletch=3D40aol.com@dmarc.ietf.org
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft<= /u>

=C2=A0

Cool! Sorry I couldn't make the= meeting. One benefit of using WWW-Authenticate is that UMA has basically t= he same discovery logic (from RS to AS) and uses the WWW-Authenticate header. Keeping this discovery method the same (since UMA= is just a profile of OAuth anyway) will help all developers.=

On 11/8/18 5:16 AM, Dick Hardt wrote:<= /p>

George: in the WG meeting we discussed this topic of= where to put the discovery information. No one at the meeting advocated fo= r using Link response (Nat was the one who was advocating for this). Many o= thers preferred using the www-authenticate header similar to how you propose.

=C2=A0

On Thu, Nov 8, 2018 at 4:08 AM George Fletcher <g= ffletch=3D40= aol.com@dmarc.ietf.org> wrote:

Related to this discussion of AS di= scovery... what is the value of using the Link response header over just re= turning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm=3D"example_realm", scope=3D"ex= ample_scope", error=3D"invalid_token", rs_uri=3D"https://api.exampl= e.com/resource", as_uri=3D"https://as1.example.com,https://= as2.example.com"

Thanks,
George

On 11/6/18 12:19 AM, Justin P Richer wrote:

In the meeting tonight I brought up a response to th= e question of whether to have full URL or plain issuer for the auth server = in the RS response=E2=80=99s header. My suggestion was that we have two dif= ferent parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the = issuer to be constructed somehow (as_issuer). I ran into a similar problem = on a system that I built last year where all of our servers had discovery d= ocuments but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). = So we solved it by having two different variables. If the full URL was set,= we used that; if it wasn=E2=80=99t, we tried the issuer; if neither was se= t we didn=E2=80=99t do any discovery.

=C2=A0

I=E2=80=99m sensitive to Torsten=E2=80=99s concerns = about complexity, but I think this is a simple and deterministic solution t= hat sidesteps much of the issue. No pun intended.

=C2=A0

=E2=80=94 Justin

=C2=A0



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

_______________________________________________
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

=C2=A0

--000000000000d0c173057ad1d766-- From nobody Sat Nov 17 03:07:10 2018 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 A4E48130DC7 for ; Sat, 17 Nov 2018 03:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 2RK9F9cTQSlV for ; Sat, 17 Nov 2018 03:07:05 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) (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 966DC129C6A for ; Sat, 17 Nov 2018 03:07:05 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gNyRJ-0003Ih-P8; Sat, 17 Nov 2018 12:07:01 +0100 From: Torsten Lodderstedt Message-Id: <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_BB40BACD-AC9D-4756-AC93-8FCE97AC09D9"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 17 Nov 2018 12:07:00 +0100 In-Reply-To: <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> Cc: Aaron Parecki , Hannes Tschofenig , oauth@ietf.org To: Brock Allen References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 17 Nov 2018 11:07:09 -0000 --Apple-Mail=_BB40BACD-AC9D-4756-AC93-8FCE97AC09D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brock, > Am 15.11.2018 um 23:01 schrieb Brock Allen : >=20 > > It still lacks the ability to issue sender constraint access tokens. >=20 > So you mean at the resource server ensuring the token was really = issued to the client? Isn't that an inherent limitation of all bearer = tokens (modulo HTTP token binding, which is still some time off)? Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based = methods for sender constraining access tokens = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= .2). Token Binding for OAuth = (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well = as Mutual TLS for OAuth = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options = available.=20 > Resource servers don't know the flow the clients might use, especially = if/when they have many clients. They don=E2=80=99t need to. All they need to know is how to determine = whether the sender of the token is the legit client. This is achieved by = comparing the hash of the token binding id or the cert of the client = conveyed in the access token with the respective data from the TLS = handshake.=20 >=20 > > The AS can bind the lifetime of the refresh tokens to the session = lifetime, i.e. automatically revoke it on logout.=20 >=20 > Yea, I saw your other email asking about refresh token revocation = relating to session management. Obviously for certain clients, this = won't make sense, but for implicit/browser-based ones it's a nice = feature to have. >=20 > The alternative, as you mentioned, is to not issue refresh tokens and = do token renewal the "same old way" via iframe with prompt=3Dnone, while = still using code flow. yes.=20 Have you ever experienced issues with the latter approach and the = browser=E2=80=99s 3rd party cookie policy? >=20 > > The only potential =E2=80=9Ebaby step=E2=80=9C I would see is to = move towards =E2=80=9Etoken id_token=E2=80=9C. Since this requires = signature/at_hash checks etc. I doubt this is really easier than moving = to code and exchange the code for an access token. What=E2=80=99s your = opinion? >=20 > Even since OIDC arrived, this is the only flow I use for = JS/browser-based clients (anything less has always seemed so obviously = inferior). So for me and my customers, all browser-based clients I am = involved in are already there. Perhaps this is the reason for all of my = questions/comments about the recent BCP doc. Given "id_token token", = CSP, and using the browser history API to wipe the access token from = browser history, we already have a decent set of tools to mitigate = attacks. As I already conceded, the only remaining issue (IMO) is the = short window of time the access token is in the URL. There are two angles to approach access token leakage and replay from = two angles, (a) preventing leakage (that=E2=80=99s what you can do with = the browser history API, TLS, ...) or (b) detecting replay (that=E2=80=99s= what one can do with sender constraint access tokens).=20 The focus of OAuth/OIDC was on (a) but experiences have shown this is of = limited effectivity, especially in dynamic/open scenarios, which we are = seeing increasingly due to open banking, eHealth, eID, =E2=80=A6. So = sealing the problem from both ends seems reasonable. =20 =20 >=20 > Given that it seems to me that OIDC and OAuth2 are typically used = together (at least when a user is involved with authentication), I = always wonder why the OAuth and OIDC WGs are separate. Given that so = much effort of the two sets of specs overlap, it seems odd to keep = adding onto the OAuth specs and ignoring the added features that OIDC = provides. I don't mean to derail this thread, or step on any political = toes, so apologies in advance. No problem. As already stated, OIDC, esp. FAPI, and OAuth need to be = aligned on that point.=20 Thanks for the insights you shared. We will be publishing another = revision of the OAuth Security BCP soon, which also adds recommendation = and justification based on our discussions.=20 kind regards,=20 Torsten.=20 >=20 >=20 > -Brock >=20 --Apple-Mail=_BB40BACD-AC9D-4756-AC93-8FCE97AC09D9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTcxMTA3MDFaMC8GCSqGSIb3DQEJBDEiBCB/ QcatwCXgNAIz3qcHnzj8zNbj8zlweeSfsdPjZyaT+zCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAILcbAZa1RuIJIXiqaqeZYzWJ f2dFcLFl85qsf2TEZYVG0TACiug9hyhY9h0k7jKDei8TC9comz9ZatgcNELiCzrpX7/ndpNUnIJv 3IdN0sqR6BsjUUWCPmCW2nnUd57iA9wZWbURScaAuhrnKQzaDO7ranBxCfAInJsB5DoOG9A0DwS3 C6H4bUZuIEaTQxRehN1v4ehBh0U3hgf8F7AtNDRULepvNfwZPHPlbFCqbhkNFrc6GlPkFK/1ROv2 3WdsaJOwJmp0xSLnyn9gdKS+RcDkUFCou3uYy7dKGoE7yFjiMpW3No9+2tYUnDxXONleRGyQTNYj f3lUW4QFvwt1xQAAAAAAAA== --Apple-Mail=_BB40BACD-AC9D-4756-AC93-8FCE97AC09D9-- From nobody Sat Nov 17 03:14:48 2018 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 13A96130DC6 for ; Sat, 17 Nov 2018 03:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 4BtYmNF76rzw for ; Sat, 17 Nov 2018 03:14:43 -0800 (PST) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.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 8F561129C6A for ; Sat, 17 Nov 2018 03:14:43 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gNyYg-00082g-UO; Sat, 17 Nov 2018 12:14:39 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_54842693-8EAA-4CBE-9232-5F6BBBD04897"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 17 Nov 2018 12:14:38 +0100 In-Reply-To: Cc: Brock Allen , "oauth@ietf.org" To: n-sakimura References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 17 Nov 2018 11:14:46 -0000 --Apple-Mail=_54842693-8EAA-4CBE-9232-5F6BBBD04897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nat,=20 > Am 16.11.2018 um 10:12 schrieb n-sakimura : >=20 > Good points. >=20 > =20 >=20 > Also, while it may be off-topic, I do see values in implicit flows. In = some cases, such as when the AS is inside the firewall or on a localhost = (e.g., smartphone), =E2=80=9Ccode flow=E2=80=9D is not possible as the = client cannot reach the AS directly. are you saying the browser can send the HTTP GET to the authorization = endpoint but the JS in the browser cannot send the HTTP POST to the = token endpoint?=20 > Banning implicit (and thus =E2=80=9Ctoken id_token=E2=80=9D as well) = has this repercussion First of all we are not banning anything. The OAuth WG does no longer = recommend to use the implicit for very good reasons, which can be found = here = https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi#rfc.section.2.1.2 I would appreciate your comments.=20 > and I would not agree to it. As you were always on the =E2=80=9Emake it secure=E2=80=9C side, I=E2=80=99= m a bit surprised.=20 kind regards, Torsten.=20 >=20 > =20 >=20 > Best, >=20 > =20 >=20 > Nat Sakimura >=20 > =20 >=20 > From: OAuth On Behalf Of Brock Allen > Sent: Friday, November 16, 2018 7:01 AM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >=20 > =20 >=20 > > It still lacks the ability to issue sender constraint access tokens. >=20 > =20 >=20 > So you mean at the resource server ensuring the token was really = issued to the client? Isn't that an inherent limitation of all bearer = tokens (modulo HTTP token binding, which is still some time off)? = Resource servers don't know the flow the clients might use, especially = if/when they have many clients. >=20 > =20 >=20 > > The AS can bind the lifetime of the refresh tokens to the session = lifetime, i.e. automatically revoke it on logout. >=20 > =20 >=20 > Yea, I saw your other email asking about refresh token revocation = relating to session management. Obviously for certain clients, this = won't make sense, but for implicit/browser-based ones it's a nice = feature to have. >=20 > =20 >=20 > The alternative, as you mentioned, is to not issue refresh tokens and = do token renewal the "same old way" via iframe with prompt=3Dnone, while = still using code flow. >=20 > =20 >=20 > > The only potential =E2=80=9Ebaby step=E2=80=9C I would see is to = move towards =E2=80=9Etoken id_token=E2=80=9C. Since this requires = signature/at_hash checks etc. I doubt this is really easier than moving = to code and exchange the code for an access token. What=E2=80=99s your = opinion? >=20 > =20 >=20 > Even since OIDC arrived, this is the only flow I use for = JS/browser-based clients (anything less has always seemed so obviously = inferior). So for me and my customers, all browser-based clients I am = involved in are already there. Perhaps this is the reason for all of my = questions/comments about the recent BCP doc. Given "id_token token", = CSP, and using the browser history API to wipe the access token from = browser history, we already have a decent set of tools to mitigate = attacks. As I already conceded, the only remaining issue (IMO) is the = short window of time the access token is in the URL. >=20 > =20 >=20 > Given that it seems to me that OIDC and OAuth2 are typically used = together (at least when a user is involved with authentication), I = always wonder why the OAuth and OIDC WGs are separate. Given that so = much effort of the two sets of specs overlap, it seems odd to keep = adding onto the OAuth specs and ignoring the added features that OIDC = provides. I don't mean to derail this thread, or step on any political = toes, so apologies in advance. >=20 > =20 >=20 > =20 >=20 > -Brock >=20 > =20 >=20 --Apple-Mail=_54842693-8EAA-4CBE-9232-5F6BBBD04897 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTcxMTE0MzhaMC8GCSqGSIb3DQEJBDEiBCAu TGst0c/bfgCLAXp8hC/oWQqPotKc8apJggLDhlAIezCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAjBjUxgXrMCIUSz9hxAqyoMtb raWwxd+QCZ3s/EW6GCO+jv6iX7ktJIBZdpJpAu9udnMeKTEIGj3Fbh5VvRePay7WPkLbrcKxU02u +e6kZkA0MIYw7B18FvLesJoM4B3lcBmsbp/PEkIE8OPqtmhR0X/DHeWQfKOxYy9BYJvy8p6cDesQ JjzTGeEvn8F5k4VHLa/is9gJOfbC7VJxD+Thw+R03AwUARpNTHYft2AWMZbEX4W2uEDMO7BumLaf r/11AMuhR1OwiH0gRoBSHiU/yOklHFr9+1BBIWSWd9hSi/jNK41MktJT9BSaexu0DDvTRn26HubA IbYYegLwj3LgowAAAAAAAA== --Apple-Mail=_54842693-8EAA-4CBE-9232-5F6BBBD04897-- From nobody Sat Nov 17 03:27:02 2018 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 EE708130DC7 for ; Sat, 17 Nov 2018 03:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 aCE42z7gbNu1 for ; Sat, 17 Nov 2018 03:27:00 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF87129C6A for ; Sat, 17 Nov 2018 03:26:59 -0800 (PST) Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gNyka-00054y-Vg; Sat, 17 Nov 2018 12:26:57 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D31A4D72-DAF5-41D3-BE46-D4D0C33CD1FB"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sat, 17 Nov 2018 12:26:56 +0100 In-Reply-To: <915498670.1574190.1542373190714@mail.yahoo.com> Cc: Brock Allen , oauth@ietf.org To: Tomek Stojecki References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 17 Nov 2018 11:27:02 -0000 --Apple-Mail=_D31A4D72-DAF5-41D3-BE46-D4D0C33CD1FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tomek, > Am 16.11.2018 um 13:59 schrieb Tomek Stojecki : >=20 > >> The AS can bind the lifetime of the refresh tokens to the session = lifetime, i.e. automatically revoke it on logout.=20 >=20 > > Yea, I saw your other email asking about refresh token revocation = relating to session management. Obviously for certain clients, this = won't make sense, but for implicit/browser-based ones it's a nice = feature to have. >=20 > I agree that this can be useful, however with where we are today, is = this supported by auth servers such that it can distinguish offline from = renewable-online clients and only revoke the latter when logging out?=20 See other thread on refresh token revocation on logout. There seems to = be some implementations. Basically, I don=E2=80=99t think the clients = needs to now because it always needs to be prepared to handle invalid = (invalidated) refresh tokens (see = https://tools.ietf.org/html/rfc6749#section-5.2).=20 >=20 > > The alternative, as you mentioned, is to not issue refresh tokens = and do token renewal the "same old way" via iframe with prompt=3Dnone, = while still using code flow. >=20 > Going from Implicit to Code deals with the problem of sending RT in = the URL, which I agree is a plus. Have you taken a look at = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.= 1.2? It gives all the justification.=20 > Is there anything else in a way of an improvement? I still am not = comfortable enough with the idea of releasing RTs to the browser clients = where it can't be encrypted, prone to xss, etc=E2=80=A6=20 As already stated. The AS is not required to issue refresh tokens. If the AS decides to issue refresh tokens, there are ways to protect the = refresh token from replay even for public clients.=20 To start with, the AS may use refresh token rotation in combination with = automatic revocation in case of detected replay attempts.=20 How does it work? The AS issues a new refresh token with every refresh = and invalidate the old one. This restricts the lifetime of a refresh = token. If someone (might be the legit client or an attacker) submits one = of the older, invalidated refresh token, the AS might interpret this as = a signal indicating token leakage and revoke the valid refresh token as = well. We used this technique at Deutsche Telekom since our first OAuth = 2.0 implementation back in 2012. An emerging alternative is to use Token Binding (in browser) or Mutual = TLS (other clients) to bind the refresh token to the client=E2=80=99s = key key pair. kind regards, Torsten.=20 >=20 >=20 > -Tomek >=20 > On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Brock Allen = wrote: >=20 >=20 > > It still lacks the ability to issue sender constraint access tokens. >=20 > So you mean at the resource server ensuring the token was really = issued to the client? Isn't that an inherent limitation of all bearer = tokens (modulo HTTP token binding, which is still some time off)? = Resource servers don't know the flow the clients might use, especially = if/when they have many clients. >=20 > > The AS can bind the lifetime of the refresh tokens to the session = lifetime, i.e. automatically revoke it on logout.=20 >=20 > Yea, I saw your other email asking about refresh token revocation = relating to session management. Obviously for certain clients, this = won't make sense, but for implicit/browser-based ones it's a nice = feature to have. >=20 > The alternative, as you mentioned, is to not issue refresh tokens and = do token renewal the "same old way" via iframe with prompt=3Dnone, while = still using code flow. >=20 > > The only potential =E2=80=9Ebaby step=E2=80=9C I would see is to = move towards =E2=80=9Etoken id_token=E2=80=9C. Since this requires = signature/at_hash checks etc. I doubt this is really easier than moving = to code and exchange the code for an access token. What=E2=80=99s your = opinion? >=20 > Even since OIDC arrived, this is the only flow I use for = JS/browser-based clients (anything less has always seemed so obviously = inferior). So for me and my customers, all browser-based clients I am = involved in are already there. Perhaps this is the reason for all of my = questions/comments about the recent BCP doc. Given "id_token token", = CSP, and using the browser history API to wipe the access token from = browser history, we already have a decent set of tools to mitigate = attacks. As I already conceded, the only remaining issue (IMO) is the = short window of time the access token is in the URL. >=20 > Given that it seems to me that OIDC and OAuth2 are typically used = together (at least when a user is involved with authentication), I = always wonder why the OAuth and OIDC WGs are separate. Given that so = much effort of the two sets of specs overlap, it seems odd to keep = adding onto the OAuth specs and ignoring the added features that OIDC = provides. I don't mean to derail this thread, or step on any political = toes, so apologies in advance. >=20 >=20 > -Brock >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D31A4D72-DAF5-41D3-BE46-D4D0C33CD1FB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTcxMTI2NTZaMC8GCSqGSIb3DQEJBDEiBCAC FpzJktM+f7tGGL6p8Sw/V4By8jtYZcXepIM/YREFlzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAJ3yN344JJ+zen56DPMVk7rc4 b7/ihLPW+X+LeDoX7k84IJOrXuMsCqwP6OZIYc6YVdvFZ7o03NGF4bb7qyPoMyMu1WCts7ANWNB4 VymxFUrMUKebIBszSiLsIZq1QZD0LPOgrzS1OiNQwvtGSocVHhrEGea9Gm5oNyl2VS1702tIFjFo gz+wvr1xJL0O4XGRRpF9WZQjYWymuIMMDmF2C97yVV60QIimAswfzCxQjv/Lu6gRHvElQeL5DFig MeoPcYGHeWoSClbmvEaC+wwveomkH1p1dOULUbXrrQxE8UxMdfi+b8i0qnDXHOYC/Jkf/9y6pt3d GLV0pDAr1K6DPgAAAAAAAA== --Apple-Mail=_D31A4D72-DAF5-41D3-BE46-D4D0C33CD1FB-- From nobody Sat Nov 17 14:08:33 2018 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 D04F912F1A2 for ; Sat, 17 Nov 2018 14:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 jikANPr67xcs for ; Sat, 17 Nov 2018 14:08:31 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 DE58B1294D7 for ; Sat, 17 Nov 2018 14:08:30 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id j18-v6so7628420iog.6 for ; Sat, 17 Nov 2018 14:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D2qF0vB97sXYYjKWO6DlrXHJOtESklIH0L8NBIkiBVc=; b=osodrG8fGXCWr4jqANY6jSHLHgCqf2k/wIlK51OL5WPw6thFCHNIuwaVC99Rhq6Uma WiGCG6/Qqubda5YBl/KnMTAGDerEKKCDmkO08egkWlJLUEgieYhWEF8Y0ESt1KQoSGDa XAl6N7JFJl9474QGSjiIbNRobaCGBVSuVGouY= 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=D2qF0vB97sXYYjKWO6DlrXHJOtESklIH0L8NBIkiBVc=; b=Z+xU6SqItE631zNEgIZafnrBKpaFcW9DQajTwhr2LHWvzfNC0/1SlTz9jzC5QIK6qG kJCSYoIkG3G0UuDtFb0YZxL/Lz+XiDSF64c1gxljBxFxQrRhHfO0A5JqwfpRCDMbE6Hu AB7pJa78V6DmIRFrVtpbzipnf4mIk1+cj3S1AmyMizzodsASFd3MIWuniKTFCYtnVBlU +BUxCYySrSkHa8ydyn7UxJKzweL+pOh6yMgKzEoJXfmpCT2DwqDoLWWUboGb6krYsEfi W1h8ehHFYgROr7tCEc8vz1zmXjGY/oOPIw+YulmEEeC5CtIVzgKstySfY54P6XjCmSqw HSjQ== X-Gm-Message-State: AA+aEWbOO8YQrN0/lb5QZ6pWU4i7dNJX+qz4UKx8o68vLUvj3KvoNMfr owhtZ7vlyHIUEA+pI4tDWiX4bgAq94L3mYLTlIAIQZk6nhT1AoorC3vFE/yNiXe4P7OHWU/1bSF 8EYRmUhThOVanhg== X-Google-Smtp-Source: AJdET5csJ452tXw3+YqhWnJ64htR75atlMNBR7fTYl20OaCnLR1hp1wwmho9zOXlYBAGEY4Ujwl/uzBsz3evKBNdFkI= X-Received: by 2002:a6b:b345:: with SMTP id c66mr13122031iof.59.1542492510006; Sat, 17 Nov 2018 14:08:30 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> In-Reply-To: <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> From: Brian Campbell Date: Sat, 17 Nov 2018 15:08:18 -0700 Message-ID: To: Torsten Lodderstedt Cc: Brock Allen , oauth Content-Type: multipart/alternative; boundary="00000000000020c098057ae38672" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 17 Nov 2018 22:08:33 -0000 --00000000000020c098057ae38672 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I might suggest that neither of those are really best current practice per se. Using key constrained tokens is more of an aspirational recommendation for what would be good security practice than it is something that's done much for real in practice today. On Sat, Nov 17, 2018, 4:07 AM Torsten Lodderstedt > > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > > So you mean at the resource server ensuring the token was really issued > to the client? Isn't that an inherent limitation of all bearer tokens > (modulo HTTP token binding, which is still some time off)? > > Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based met= hods for > sender constraining access tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2). > Token Binding for OAuth ( > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as > Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-1= 2) > are the options available. > > > > --=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._ --00000000000020c098057ae38672 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I might sugge= st that neither of those are really best current practice per se. Using key= constrained tokens is more of an aspirational recommendation for what woul= d be good security practice than it is something that's done much for r= eal in practice today.=C2=A0

On Sat, Nov 17, 2018, 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net wrote:
=

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
>
> So you mean at the resource server ensuring the token was really issue= d to the client? Isn't that an inherent limitation of all bearer tokens= (modulo HTTP token binding, which is still some time off)?

Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based metho= ds for sender constraining access tokens (ht= tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2<= /a>). Token Binding for OAuth (https://tools.ietf.org/html/= draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the optio= ns available.

=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. --00000000000020c098057ae38672-- From nobody Sun Nov 18 04:33:08 2018 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 2F66A130DCD for ; Sun, 18 Nov 2018 04:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 M5ff7XeiQ9z6 for ; Sun, 18 Nov 2018 04:33:04 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0: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 D932912007C for ; Sun, 18 Nov 2018 04:33:03 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id b5so3816079iti.2 for ; Sun, 18 Nov 2018 04:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=eKH+0GaU3eaZJNghelPFXk2ckVu4N2EIW0VyyLK7O10=; b=Dg5/2zaIXnVBRBEtJmsJ9lhwrqr7f7MW/2WNI/IWh3wcvFSL2HuetSHWR7bVq/rrqt j+tm5bSuLonhGc6SfOEpkdACOL4S8+YqOdQJMO1Of0+JVqk36ARcC6GK21yw47UjM1L1 IGEjHb5Gv7JfolpOyD82Av+oLGtuTQlOf8BV0= 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=eKH+0GaU3eaZJNghelPFXk2ckVu4N2EIW0VyyLK7O10=; b=Qb0vs3KPJYCaqoGp/3p6LVv8umrzbcaI3fIX9uz6Fz2KXFCNH7/wy4Rxk6mEfqJXXJ eauwQ9H7WEpPBYfV/KK2lA/wY9YfQeFh+3P9V90WweeqXu5gMByOsw0MUFdLF0OdL0Wj a+h+JnkcH8h7z1ikz4weq3xc/qByIg29hR2FNwOMbNt3/RJjYdqrmkxmxx6wKCU36EsN UNVip851Pqf3VylUFapHWT7SYGVj5CEwo9sWDV1ZbxPINhH/ukjtgCzFzcfMcR63J1qn cnvqapvAxIAYJ9CDukWR5QQepI8d0JKc5C7pnVKDwwO4M+7FNGxZC2iOm/Vs5DtaS+UX pXog== X-Gm-Message-State: AGRZ1gLC9q2Mkva8Czpw/bz/3LPd4m1l+Wi/mlJbsMCd2TXN8/SfyQvA Cpa082S9wYzge15stF/5US4Zcp3viM92t2VrNs2ru8ABk3pMX6lMDvzZRNFw0grHsUrPsGsNuJL hTfCbDcS2/7DCK6ZZaYY= X-Google-Smtp-Source: AJdET5cfiOGS0ZEatMFzV/RjQs15tsOevBs9JG/yiW+QYHA2jsdLE/lps2GyjWt1xpTqgMSXZGWvGW3ksl2Qa9YjJUw= X-Received: by 2002:a02:23c5:: with SMTP id u188-v6mr16562142jau.90.1542544382690; Sun, 18 Nov 2018 04:33:02 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Sun, 18 Nov 2018 05:32:35 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000fb2b67057aef99c9" Archived-At: Subject: [OAUTH-WG] Token Binding & implicit 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, 18 Nov 2018 12:33:06 -0000 --000000000000fb2b67057aef99c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable During the first OAuth session in Bangkok the question "what to do about token binding & implicit?" was raised. There was some discussion but session time was limited and we had to move on before any real consensus was reached. So I thought I'd bring the question to the WG list to generate some more discussion on the issue. It's also related, at least in part, to a couple of the other ongoing threads on the list about browser based apps and security practices. The slides from the session are linked below. Slides 5 & 6 try and explain the awkwardness of doing Token Binding with implicit. While slide 7 lays out some (not very good) options for how to proceed. https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d= raft-ietf-oauth-token-binding-00 --=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._ --000000000000fb2b67057aef99c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
During the first OA= uth session in Bangkok the question=C2=A0"what to do about token bindi= ng & implicit?" was raised. There was some discussion but session = time was limited and we had to move on before any real consensus was reache= d.

So I thought I'd bring the question to= the WG list to generate some more discussion on the issue. It's also r= elated, at least in part, to a couple of the other ongoing threads on the l= ist about browser based apps and security practices.

The slides from the session are linked below. Slides 5 & 6 try= and explain the awkwardness of doing Token Binding with implicit. While sl= ide 7 lays out some (not very good) options for how to proceed.

<= 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. --000000000000fb2b67057aef99c9-- From nobody Mon Nov 19 01:48:46 2018 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 005F212F1A5 for ; Mon, 19 Nov 2018 01:48:45 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 SYcRS1cqw5go for ; Mon, 19 Nov 2018 01:48:43 -0800 (PST) Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (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 4140B1286D9 for ; Mon, 19 Nov 2018 01:48:43 -0800 (PST) Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id OgAbgpPYz9c9oOgAbgk8dG; Mon, 19 Nov 2018 02:48:42 -0700 To: oauth@ietf.org References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <1435364f-ac8c-e751-d9b6-806ab893bbde@connect2id.com> Date: Mon, 19 Nov 2018 11:48:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060004000203040500020304" X-CMAE-Envelope: MS4wfDNoPJE9jvniVaoRuVzR7Jv6tcELLG7aSDzGQ1DSMIK6mRsd6ATfKumfr0XLYM60ssE06jTSRPn5A8z31TR0AhH1ytBPRYgJlMSYrO1D8Kf6c39t5wqB feuj18nY2kxWE0DU33WBnGmB1iXuPNPic6p4TJsytEMmubNAifgpevqN Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 19 Nov 2018 09:48:45 -0000 This is a cryptographically signed message in MIME format. --------------ms060004000203040500020304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi everyone, On 17/11/2018 13:07, Torsten Lodderstedt wrote: > >> The alternative, as you mentioned, is to not issue refresh tokens and = do token renewal the "same old way" via iframe with prompt=3Dnone, while = still using code flow. > yes.=20 > > Have you ever experienced issues with the latter approach and the brows= er=E2=80=99s 3rd party cookie policy? I expect that what's ultimately going to drive people away from "implicit" and to "code" is blocked 3rd party cookies in browsers breaking renewal for clients via an iframe. IMO this policy is only more likely to spread out in browsers than getting rolled back. Vladimir --------------ms060004000203040500020304 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 CygwggU6MIIEIqADAgECAhEA9DW+rlLUzYs+I90AKROPBDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDIyMDAw MDAwWhcNMTkwNDIyMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd2bGFkaW1pckBjb25uZWN0 MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRKqCbZFgc5UOwarPfT 8akjZDXcXbV32yOcBnd5Rw1Befh5shhtGy2IWb2DjNHfxNtTe+pRAxd3pMM0b9jV4Bj8St19 sU55RCc3IcE2ZX25sUssusaNFOt9Z9njLjL0mXG5mdZPNomCjYLcx2PGoBlTmkww/MRyOIUg ioYdwghyuCySnZ83natEBgwPosPbUBtgo2FPzzVTFwbAt7I/YBBLoJWcJ0c5TZxJJXjlCK5X HJN5HyTkLE9r1WC6csWg+ImS9Qu1BJrwQmjOADKtVrRnioSWPYXsVeycHHXP00N4qfGps/G4 PoBMebQiJa74m0TF0VoDbcMHXzkbAaFU59ECAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaAFIKv bIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQ/eBsPoW26G+gUAJoWNRvNGOghWzAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcw AoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tMA0GCSqGSIb3DQEB CwUAA4IBAQBc2qNY13iSWIXWU+x+FroixRnfU+aald2oOQ0PCnezrlqkT2Ty/83/S7o6a+uF 1tKlYOu/eSu8lW1vpMIpgsUWE9dTMlsuQ1pDtdss6Di+y5lFl/gZNTJN0itXjI/f5G6LRnUQ 6CLhUgB4GqnhpU5dKORQNvEmBmgyiTD4ZOENcPwalWdRziAYsAkmaINMRPSN+jCjSKS29EFx mremUQ2le6rjruidlSjGxToAj+vbayxXKTo1wifncGDrneuOjQd91HLsrjeUzjwysPXHaELk /sUWs587QWdaDgiuV6hhMNZkuDs5chFl76wdI/faW8o6aznG4gE7ZZWbt9OdonrTMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ4 MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQD0Nb6uUtTNiz4j3QApE48EMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTkwOTQ4NDBaMC8GCSqGSIb3DQEJ BDEiBCD9mQl/gpfNXDxHErNpyRtIBPdtLTnOY2xXciirCd+HUTBsBgkqhkiG9w0BCQ8xXzBd MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA 9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq hkiG9w0BAQEFAASCAQCUXGLtA3USBPxPKeXxkVCHpqNubivfZCQRye+7cF7HNatvNGv3z77h Dos84etn7BsLTg/Jw3hCp8417MiEpLYEZw43V4YIHSCOQ4RgD8Frx7o0YGs/n3TtNUPtdkFw YaUuGTC5CLyeQjhGuX9La69hxMwibMKOrKE99kTGI3imtwcfjOxXroaRXZI3qknHGgbs9oas ty1RwGRElkiZQTWwAPqnJOfGByrTN5dzAxFOMaP0eO+o9EF+BZiSyglEWROClgarDICnY+gz 2v9XVOsmNBiHWf016rifZnV60irIjoLUAKRkOC5+j5iZ9mN36xG3iikSOtwyM2+XGOOcOjal AAAAAAAA --------------ms060004000203040500020304-- From nobody Mon Nov 19 01:58:37 2018 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 25D27128A5C for ; Mon, 19 Nov 2018 01:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvkiPIY-VliF for ; Mon, 19 Nov 2018 01:58:34 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10071.outbound.protection.outlook.com [40.107.1.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74C61286D9 for ; Mon, 19 Nov 2018 01:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ERbbS+rGfvHuRWPObttEuISbvZxvabQvnIkHwclnvV8=; b=PCk33yV/TcGkmsnnR/WyfmQn7q0vZgtGAWhKeg5TLsaUwhYpvv+zrswzJKNcOzQ+qBEKXKhabsMalUWgqduAGOCmth6b9mujCwUUbRVCJQ8yHjL9c+WKlDmHmKA3VgBDBLoU0pZDJiwIfKY9JjUdHo/HtKmF+qWnxizWlCg8mic= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1278.eurprd08.prod.outlook.com (10.167.197.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.26; Mon, 19 Nov 2018 09:58:30 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%2]) with mapi id 15.20.1339.026; Mon, 19 Nov 2018 09:58:30 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Meeting Minutes (IETF#103) Thread-Index: AdR/7j1jXT+tvOEpSTuqZhc2nwCmHw== Date: Mon, 19 Nov 2018 09:58:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.218.228] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1278; 6:Q4JtvfvYkOC+2kH2N9s4iosc/29joFktOjFi42h4RH2sWrKCbybh1H69eN9u1g9Z2hFDENsTGlB8gJjNuEm00MXCeajWgGLXA5ORJbmrSyUI+QCUphpl3IizeJ+MaB/91MZpksgTWZEbSg1IICslgUl3Zl0YPIwnixC8pYL/J5G9eIYUG7hqBd+M0wWtmesGK9WLbXdVkLC2Q7ewIo5iDXSpkb6cfD452P1C0LcOYatt6fvJ81rACacUENdR+SD3CNw2Np6wH5SQeo+UwjqXezh5JORHyHXVN4OZnzSakz5K0Auq0Iwi+b8dkJln3E6kOU1qglxiWQD5aiF59A7NuvFaF08UGt2pGQR0cMoFbtZjxLDNn0STYIpKJC4eklLtfqd5ANB9EvtS2OZmo9KpcEZfiluRlw3ZqwTcMmNsC+XY9e73i//dKBvlxCcKYiWiagbVwjMMJN7cGzQhenBImA==; 5:pDyFQ38+C6mg2AfFFRV0SSzc0i4Ng4hGZS15VMCeJRUcOVNXYhtDpc7bSea2v3WStWZnEoOGP56ON1vcrmwJ84fk8kfEJ/wFHrhuF+eJvcksP7ywGDHTlTQUgPiUA7XqmubGlC+GbB458NZ9dhbnWIQUC2BJt2oK723Svgq14TY=; 7:UeJPd3mQk/Et8HdUm2P5vMHUUPx1J/StCbcT7e35dy953LMZjrN0D0xceanWFlfy19Zrx7kzjXpEBdtU5WrRMar3qzSjSs0CmZcH18g2oG9z/59bU9VE9v+XhLl49y5o6OIy9I77vyDspgxTJ8rnXg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c3c051de-625d-4261-de24-08d64e058f6e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1278; x-ms-traffictypediagnostic: VI1PR0801MB1278: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231415)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1278; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1278; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(366004)(136003)(40434004)(189003)(199004)(97736004)(81156014)(8936002)(81166006)(25786009)(8676002)(86362001)(606006)(55016002)(105586002)(236005)(476003)(106356001)(478600001)(9686003)(14454004)(66066001)(2906002)(6306002)(54896002)(966005)(72206003)(6436002)(6116002)(3846002)(790700001)(6506007)(74316002)(99286004)(5660300001)(102836004)(53936002)(68736007)(7736002)(486006)(7696005)(71200400001)(316002)(71190400001)(6916009)(2900100001)(26005)(5024004)(14444005)(256004)(186003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1278; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GExpcGTHD0/vG9+OLHsW3auoCiUkG11CoPa2SSpr2BBo+JCtEX0VGDYUgxeEQpdAJfWKeMVDMGA9XN0xXcvjsOzuTGdDFuy3NMV7EYLD4Wj6NUhGUGyON6EBNQj+tvwAgzsczaMtSoX6IhImb3teoJgoQe2FyCr3kRWoSbdpQc4zh7I1a0ffw8hafvd8hO9kEcxopxAHtonx/Th3HgT4/rPFlE3sIVXrMqxkGS04Fit/fdSYvRKLY/bNuawVI3t7dDirevtwvOyfFMBk1098ebUOKL4oxaCrsU4Z2FevihpyQnrmPwTnsfmIXoN/o7jEIXl9YsJbSLd5yAnbJLM4cTSJlzspeUMkxm9eMIwXClg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211213AFA77ED0364412C3B1FAD80VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3c051de-625d-4261-de24-08d64e058f6e X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 09:58:30.6933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1278 Archived-At: Subject: [OAUTH-WG] Meeting Minutes (IETF#103) 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, 19 Nov 2018 09:58:36 -0000 --_000_VI1PR0801MB211213AFA77ED0364412C3B1FAD80VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the meeting minutes from the last IETF OAuth WG meeting from IETF#= 103: https://datatracker.ietf.org/meeting/103/materials/minutes-103-oauth-00 Thanks to Chris & Mike for taking notes. If you have comments, please let me know. 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_VI1PR0801MB211213AFA77ED0364412C3B1FAD80VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are the meeting minutes from the last IETF OAut= h WG meeting from IETF#103:

https://datatracker.ietf.org/meeting/103/ma= terials/minutes-103-oauth-00

 

Thanks to Chris & Mike for taking notes.

 

If you have comments, please let me know.

 

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_VI1PR0801MB211213AFA77ED0364412C3B1FAD80VI1PR0801MB2112_-- From nobody Mon Nov 19 01:58:44 2018 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 60D11130DCB for ; Mon, 19 Nov 2018 01:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 nlQpXZzCj2Vc for ; Mon, 19 Nov 2018 01:58:37 -0800 (PST) Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.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 711E912F1A5 for ; Mon, 19 Nov 2018 01:58:37 -0800 (PST) Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id OgKBgzHROhoGHOgKCgpSow; Mon, 19 Nov 2018 02:58:37 -0700 To: oauth@ietf.org References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com> Date: Mon, 19 Nov 2018 11:58:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000603030203070309030106" X-CMAE-Envelope: MS4wfC+hvRsf4Ah22pVhWLH7+LEUDnmafx2vtt5eDLSyLvuvHy+b3hoZz5+EUHGpbqTdI4ggh2gabBf9J3LcVgEfwQezy9R6bKTG05NNDjjn5/dVbL63fvsm m7vUE9gDeyjebCxeMVK48+iABmC3YOE+S6x7ss5qvRFx+vxcRlfYYGww Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 19 Nov 2018 09:58:43 -0000 This is a cryptographically signed message in MIME format. --------------ms000603030203070309030106 Content-Type: multipart/alternative; boundary="------------AD29F1E1869EB401292F76B9" Content-Language: en-US This is a multi-part message in MIME format. --------------AD29F1E1869EB401292F76B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/11/2018 13:26, Torsten Lodderstedt wrote: > To start with, the AS may use refresh token rotation in combination wit= h automatic revocation in case of detected replay attempts.=20 > > How does it work? The AS issues a new refresh token with every refresh = and invalidate the old one. This restricts the lifetime of a refresh toke= n. If someone (might be the legit client or an attacker) submits one of t= he older, invalidated refresh token, the AS might interpret this as a sig= nal indicating token leakage and revoke the valid refresh token as well. = We used this technique at Deutsche Telekom since our first OAuth 2.0 impl= ementation back in 2012. This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections? We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP: * A valid refresh causing the session to be refreshed too * AS / OP logout or session expiration invalidating the refresh token Vladimir --------------AD29F1E1869EB401292F76B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 17/11/2018 13:26, Torsten Lodderstedt wrote:
To start with, the AS may us=
e refresh token rotation in combination with automatic revocation in case=
 of detected replay attempts.=20

How does it work? The AS issues a new refresh token with every refresh an=
d invalidate the old one. This restricts the lifetime of a refresh token.=
 If someone (might be the legit client or an attacker) submits one of the=
 older, invalidated refresh token, the AS might interpret this as a signa=
l indicating token leakage and revoke the valid refresh token as well. We=
 used this technique at Deutsche Telekom since our first OAuth 2.0 implem=
entation back in 2012.

This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections?

We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP:

  • A valid refresh causing the session to be refreshed too
  • AS / OP logout or session expiration invalidating the refresh token


Vladimir

--------------AD29F1E1869EB401292F76B9-- --------------ms000603030203070309030106 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 CygwggU6MIIEIqADAgECAhEA9DW+rlLUzYs+I90AKROPBDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDIyMDAw MDAwWhcNMTkwNDIyMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd2bGFkaW1pckBjb25uZWN0 MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRKqCbZFgc5UOwarPfT 8akjZDXcXbV32yOcBnd5Rw1Befh5shhtGy2IWb2DjNHfxNtTe+pRAxd3pMM0b9jV4Bj8St19 sU55RCc3IcE2ZX25sUssusaNFOt9Z9njLjL0mXG5mdZPNomCjYLcx2PGoBlTmkww/MRyOIUg ioYdwghyuCySnZ83natEBgwPosPbUBtgo2FPzzVTFwbAt7I/YBBLoJWcJ0c5TZxJJXjlCK5X HJN5HyTkLE9r1WC6csWg+ImS9Qu1BJrwQmjOADKtVrRnioSWPYXsVeycHHXP00N4qfGps/G4 PoBMebQiJa74m0TF0VoDbcMHXzkbAaFU59ECAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaAFIKv bIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQ/eBsPoW26G+gUAJoWNRvNGOghWzAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcw AoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tMA0GCSqGSIb3DQEB CwUAA4IBAQBc2qNY13iSWIXWU+x+FroixRnfU+aald2oOQ0PCnezrlqkT2Ty/83/S7o6a+uF 1tKlYOu/eSu8lW1vpMIpgsUWE9dTMlsuQ1pDtdss6Di+y5lFl/gZNTJN0itXjI/f5G6LRnUQ 6CLhUgB4GqnhpU5dKORQNvEmBmgyiTD4ZOENcPwalWdRziAYsAkmaINMRPSN+jCjSKS29EFx mremUQ2le6rjruidlSjGxToAj+vbayxXKTo1wifncGDrneuOjQd91HLsrjeUzjwysPXHaELk /sUWs587QWdaDgiuV6hhMNZkuDs5chFl76wdI/faW8o6aznG4gE7ZZWbt9OdonrTMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ4 MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQD0Nb6uUtTNiz4j3QApE48EMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMTkwOTU4MzVaMC8GCSqGSIb3DQEJ BDEiBCCzEBkwPXgtVscxNvlp9sTUOR3ZCJFFEsROyR8QwImdBzBsBgkqhkiG9w0BCQ8xXzBd MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA 9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq hkiG9w0BAQEFAASCAQAAOIksjVePGUjOtMmdAA/qqFmWhsrjJ8wSwUs2/dp1ZYcdYsu+6gOU zzuAMfHWkoDyDL3NJ6OouTpyQ0MgVcNI/vo7s/YVHIUshGh3M4NXVaU1WVdIsVyU9w2mvNqX JvForbTnCcoJD42A4vdaZYNBYLEzaLcRabGEKW6G6q9vrvBYe3z84ED9tXmVNlExzmAoXgmD wcmvq5jzVYo8mfIPSx26nqUe22ysqqvOtLuWFDfQzayhVMOBmIO99pt1cCxcNs/80oNQMc1S avNaC7iBScBszv5RGfSIJ+/67fCKPqprsjYdBCn0U1eDus/vWrl0/e3rNJMKQISrGhTjYInu AAAAAAAA --------------ms000603030203070309030106-- From nobody Mon Nov 19 02:03:20 2018 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 0714112F1A5 for ; Mon, 19 Nov 2018 02:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.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 CgZ9hBK24Omi for ; Mon, 19 Nov 2018 02:03:16 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 73ABD128A5C for ; Mon, 19 Nov 2018 02:03:16 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id r200so16277883iod.11 for ; Mon, 19 Nov 2018 02:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p3VpJoIfNOORQZP2Ky8vf7A8w/+2IIGdYxKewOSVffo=; b=eh2uHtyECbeI84XSi2NH3UFjfLrip0KXOGKKGh0pVY1k2kWZ0uC/zVVfGCbFoJVPmz M+jSn+Rns+uUxVRgtbZU4d4TGmnosz2TE+Z38+aoK/snBXJQR9/jg5TQ2T0M8tcw47Y7 XvjD0daZtoXa2s+OJ6cYwMZQn/ibIhAl81nxK6fXohzTzVRdjcvNrC6KGIEP8g8xeYJ8 NkzwFQvZy3mCF6RPoOv/tmGdBTBMTLeq3xB3PwN8O1gANYQXF9IBPe4kjeDHQSgBeS/O 9h1f2EP5R0mSHNqNnvrSbiX5rD68uMJvwC2HX0Ku5uBq0/2eYaw5HpF9vYPFlAVm+ftN EB9A== 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=p3VpJoIfNOORQZP2Ky8vf7A8w/+2IIGdYxKewOSVffo=; b=qyhgdFZgxy/hJakFZUh3oG6uB1Y+7pOu+xL8tDZ3oTpad+zL3y/4CqJszE+fzwnWCN GANuVpyMHz3qTupNxL3OoxBlLCYbam0RSASC+KVRrcE9UCrqSLsMftLuLcxPDgSLtead 2gJecc94aAc08UQo+M2EqxtaIKR0biuDPPIgBNx1AcCyNubEouBXtCsp5fB2sWTSEMpC JiEUIO6T+A4Pca5SvEsX+nTbapph7ggF0d2lVCtrltz6mM6TrBpR5LsW7vbW1KR65gGo I3Qq1Lo0kDNa0ZCJJxZNw43YYeGiCTkvQS6hV2ok5DO5JH62xeCTZKuPI+DaZm76Mn1C Mg5Q== X-Gm-Message-State: AGRZ1gJVS6iSTyTS1/oc80pmVURsUqhExrvwryOByt13b1w7A8u/M5VY osy3VkTqmPK+GiYUUFFmTtKCNHGuDeOeM09xxV8Qlk5nMHg= X-Google-Smtp-Source: AFSGD/WKY+Fdnbj+vkCCD8Mzkq+Xbe9z1F+k8rPDThNfK8tAXVPIngntGraY7Zjac/yxR3hWCPmk9JeOS1DV+59qQbM= X-Received: by 2002:a6b:5f14:: with SMTP id t20mr18046910iob.268.1542621795707; Mon, 19 Nov 2018 02:03:15 -0800 (PST) MIME-Version: 1.0 References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com> In-Reply-To: <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com> From: Hans Zandbelt Date: Mon, 19 Nov 2018 11:03:04 +0100 Message-ID: To: Vladimir Dzhuvinov Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002802a4057b01a0e0" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 19 Nov 2018 10:03:19 -0000 --0000000000002802a4057b01a0e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to the suggestions that Vladimir raises; I've seen a fair number of requests in the field for exactly that Hans. On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov wrote: > On 17/11/2018 13:26, Torsten Lodderstedt wrote: > > To start with, the AS may use refresh token rotation in combination with = automatic revocation in case of detected replay attempts. > > How does it work? The AS issues a new refresh token with every refresh an= d invalidate the old one. This restricts the lifetime of a refresh token. I= f someone (might be the legit client or an attacker) submits one of the old= er, invalidated refresh token, the AS might interpret this as a signal indi= cating token leakage and revoke the valid refresh token as well. We used th= is technique at Deutsche Telekom since our first OAuth 2.0 implementation b= ack in 2012. > > This is a clever solution. Did you experience any false positives, e.g. > due to HTTP response timeouts on slow / poor connections? > > We were also thinking of additionally binding the refresh token to the > end-user session at the AS / OP: > > - A valid refresh causing the session to be refreshed too > - AS / OP logout or session expiration invalidating the refresh token > > > Vladimir > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000002802a4057b01a0e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to the suggestions that Vladimir raises; I've seen = a fair number of requests=C2=A0=C2=A0in the field for exactly that

=
Hans.

On Mon,= Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20
On 17/11/2018 13:2= 6, Torsten Lodderstedt wrote:
To start with, the=
 AS may use refresh token rotation in combination with automatic revocation=
 in case of detected replay attempts.=20

How does it work? The AS issues a new refresh token with every refresh and =
invalidate the old one. This restricts the lifetime of a refresh token. If =
someone (might be the legit client or an attacker) submits one of the older=
, invalidated refresh token, the AS might interpret this as a signal indica=
ting token leakage and revoke the valid refresh token as well. We used this=
 technique at Deutsche Telekom since our first OAuth 2.0 implementation bac=
k in 2012.

This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections?

We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP:

  • A valid refresh causing the session to be refreshed too
  • AS / OP logout or session expiration invalidating the refresh token


Vladimir

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


--
<= a href=3D"mailto:hans.zandbelt@zmartzone.eu" target=3D"_blank">hans.zandbel= t@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
<= /div>
--0000000000002802a4057b01a0e0-- From nobody Mon Nov 19 02:33:34 2018 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 029AF1271FF for ; Mon, 19 Nov 2018 02:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpooL1h0TOCs for ; Mon, 19 Nov 2018 02:33:30 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897E5129C6B for ; Mon, 19 Nov 2018 02:33:30 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id z23so3158373plo.0 for ; Mon, 19 Nov 2018 02:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b9j5qQGOP8BfcU03MNYxdwBdaPjZVOBYAP3Aq29nrPI=; b=eAGmUeDy7Xll0YpWzq5a9rpOq7IljCtL9gpyKofVtGtGnbfe3D0l6dUqLELED8IZJE 2PKXCH+hLCMq3OJDyY7J9GGUu5/llWqfBnFX4RFcet5/KUH7+lI+cCcipymtitlt+Y8+ UP0qe8JT52rbMpLnavSBKQUru+IMhEKsC/mBFkK60JT1V+HQ+293XUQhprNk6BNTeK4c Xw2XFFo0+hRQXTzDm9pgtIrnWmFpSjLfxEwStXGMmjdnT9VUxGmJvZcyCJhFg1vMWoAo V5K3/Ecc+XA7DAGGoc/kw+v6rZelW/lMv3yLrGj/A0m5Hdjh7nu2h5TMFaPM7ixC2PVq ey7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b9j5qQGOP8BfcU03MNYxdwBdaPjZVOBYAP3Aq29nrPI=; b=Kxsp+B4p2H+PncV9e9tvjVzCVqpQZUQ5Uw0cgMcf2TDwMsv1dC4WChqWAN7A/3qpL0 kepaq0uS58JLCx3t6TVL3Bsmh69oQc34TOB8eoYtOzEJSMLqQQ4+Rs7E0jbrdRcLvX4r nDV4m3wcbNzXuQRyDRNaKylrYsWmUQBciGw9mbRMNZZv0kkf8Bq3HmalB3U2LQrmqAFE 51HJgnLTH++v1FaOPvIWILR/EhiwyaoW4hw3JaKQPTAYV5MPZ94aDridBh3D6eVBYgo1 o6zbcFBb/N/uWDBc34Od4zyGSCnYvR6pvfbE/z9r1+j7uBdb8sfyiKjSkMq4wjGxVZOs ZLaw== X-Gm-Message-State: AA+aEWbsFgUBCV97KAJEIxaYnJecIqNqcKA9jCS1eeQW+SqdUFPLpIFN cABXnRste8Krjy9LHo+S+mmfkQ== X-Google-Smtp-Source: AFSGD/Upkq2vjlsMUKau6RLm5+unF9zL11T91B5I1pBhjPXcRkkhRfPwm30aNida+jkjtTB+Y21ZdA== X-Received: by 2002:a17:902:7686:: with SMTP id m6mr7699266pll.179.1542623609786; Mon, 19 Nov 2018 02:33:29 -0800 (PST) Received: from [192.168.0.117] ([27.34.20.231]) by smtp.gmail.com with ESMTPSA id l187-v6sm44880066pfc.79.2018.11.19.02.33.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 02:33:28 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-1A6030BD-9192-43D9-A329-000A4D80C85A Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Mon, 19 Nov 2018 16:18:25 +0545 Cc: Vladimir Dzhuvinov , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com> To: Hans Zandbelt Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 19 Nov 2018 10:33:33 -0000 --Apple-Mail-1A6030BD-9192-43D9-A329-000A4D80C85A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I want to +1 this as well. This really got my attention as an impressive and= straightforward defense technique. Jim > On Nov 19, 2018, at 3:48 PM, Hans Zandbelt wr= ote: >=20 > +1 to the suggestions that Vladimir raises; I've seen a fair number of req= uests in the field for exactly that >=20 > Hans. >=20 >> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov wrote: >>> On 17/11/2018 13:26, Torsten Lodderstedt wrote: >>> To start with, the AS may use refresh token rotation in combination with= automatic revocation in case of detected replay attempts.=20 >>>=20 >>> How does it work? The AS issues a new refresh token with every refresh a= nd invalidate the old one. This restricts the lifetime of a refresh token. I= f someone (might be the legit client or an attacker) submits one of the olde= r, invalidated refresh token, the AS might interpret this as a signal indica= ting token leakage and revoke the valid refresh token as well. We used this t= echnique at Deutsche Telekom since our first OAuth 2.0 implementation back i= n 2012. >> This is a clever solution. Did you experience any false positives, e.g. d= ue to HTTP response timeouts on slow / poor connections? >>=20 >> We were also thinking of additionally binding the refresh token to the en= d-user session at the AS / OP: >>=20 >> A valid refresh causing the session to be refreshed too >> AS / OP logout or session expiration invalidating the refresh token >>=20 >>=20 >> Vladimir >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1A6030BD-9192-43D9-A329-000A4D80C85A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit I want to +1 this as well. This really got my attention as an impressive and straightforward defense technique.

Jim


On Nov 19, 2018, at 3:48 PM, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:

+1 to the suggestions that Vladimir raises; I've seen a fair number of requests  in the field for exactly that

Hans.

On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
On 17/11/2018 13:26, Torsten Lodderstedt wrote:
To start with, the AS may use refresh token rotation in combination with automatic revocation in case of detected replay attempts. 

How does it work? The AS issues a new refresh token with every refresh and invalidate the old one. This restricts the lifetime of a refresh token. If someone (might be the legit client or an attacker) submits one of the older, invalidated refresh token, the AS might interpret this as a signal indicating token leakage and revoke the valid refresh token as well. We used this technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 2012.

This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections?

We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP:

  • A valid refresh causing the session to be refreshed too
  • AS / OP logout or session expiration invalidating the refresh token


Vladimir

_______________________________________________
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-1A6030BD-9192-43D9-A329-000A4D80C85A-- From nobody Mon Nov 19 02:34:28 2018 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 ECDA1130DC3 for ; Mon, 19 Nov 2018 02:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbA_QGlfgT78 for ; Mon, 19 Nov 2018 02:34:25 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBA01271FF for ; Mon, 19 Nov 2018 02:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=My7k/dlDcklzvnebHJpcQVE4hDCFrOMG2DMXOlzBNhs=; b=M45LBVZYpHIoSPC9+zLTy3kLGBQocRLHaXztTnWE3dXiZILC2vgvZHj/vIhYJDhLRUoaepko3qqBY3fFRZ+QfTgRm0UeOldC+75UBY6rxn5vaNDybjwnq8DNQmEO5ph4XqrHYHUNIHAUrcE8CkhE9B9xW9cniNJ8lgRPa8q/W1U= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2013.eurprd08.prod.outlook.com (10.173.74.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.23; Mon, 19 Nov 2018 10:34:22 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%2]) with mapi id 15.20.1339.026; Mon, 19 Nov 2018 10:34:22 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbw== Date: Mon, 19 Nov 2018 10:34:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.218.228] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2013; 6:2ALz2coaG4UT0hVvFh6l3ks13IBep0HO/GIOz+Bg5Udv4XPCy1B3xJ7gDVLRJf9wuVaXwjXlgxTjNvq8snNxdZM3GR7rB9fw5oti7Hm6UIZ4EqqzbJXp5Oyek7EPDAwp4FUbLQ3J1Bu+7kK+ukPCt7XhAAVTYWg2H38rBXrM5DB+CAWfF4TZXqGYAm1s25eKlkhfr52LR8SGN5S9fBSb8HLfyOHpSIlcU4vCUowjfg3F9SprqUqKwSCX8DTzLftZLgMCmHSB75wa/vcnhzrz1Cy+VFEE3o5Y3O/uQdviPNaN1q235DNSqzI+8sY5sT9NnHMo6gd5yDAQ/zdQgA02EkDdFfGBAjF3PsGK0Td1r29dTAwMkoPNXV7V4KU6fKse7hfI+a9BbOUWs35MGMIJQHovfxVSMm+obwmHP2yCIr99m7Qmte1yzyl8E8vEknC6VXkgoAqwjDG5QqbseqOe/Q==; 5:4ODE1fh49maA8pmMsqeid86ahBoVblUHlM9BJVXjAwbeXzk8inOt90UAhWKWu62EXY/USnhqRr4qBP5B9frdtMemaXYT5xhidMxGNK1CQPH833Z/95UqDv65ruIuUAPI6WC8sihRcQiKk9eeTmMma8FynhuY2rqz2Bt7i6sYWMY=; 7:A9sbT/CokpgF5myq77ll7n4A7m/71NahK2LwmNCwzFyjCXPdY3m183mWNcrIx58iaZT59np3dEMBokSVFzaoH8hkUHCBj+3dhIIhfdmZsY6+EYbTW8mcuThXW6OaNya2n095cMZEHztRqobFp8Ymsg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 632bf08c-c06a-44d1-4d05-08d64e0a91be x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2013; x-ms-traffictypediagnostic: VI1PR0801MB2013: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231415)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB2013; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2013; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(376002)(346002)(189003)(199004)(40434004)(53754006)(97736004)(25786009)(7696005)(2900100001)(10710500007)(54896002)(236005)(6306002)(9686003)(2906002)(86362001)(6916009)(476003)(6436002)(55016002)(7110500001)(7736002)(105586002)(486006)(256004)(14444005)(5024004)(74316002)(5660300001)(71200400001)(71190400001)(66574009)(186003)(66066001)(106356001)(606006)(15650500001)(6116002)(3846002)(790700001)(26005)(14454004)(102836004)(2420400007)(53936002)(6506007)(478600001)(33656002)(68736007)(99286004)(8676002)(8936002)(316002)(72206003)(966005)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2013; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Q9WwIj6q0EbtzJECLiBSX56uc29ZbV0wylNgs0bHRwu1q6Sw+eCKO3yaahhRjHnCSQBRML5yl2c8EUIKvj0Cg0PKoIubLdy+lg4BcULHJ5kgttQE1Fh7xNQHBPiwpqobwZAsKRoDe526I7lHdw38iBewrGsoJ9VGw4k9SNu2bhPSLdpy5YN8iH/CphAiWG8rTn9EIh5PBDRrTvExmDmIQ76oiG/Jj3uoZO2mEWGhnBpJ6VKRLx/njmDn5RcuhPDsKte6K+/eJ5K8rNJm8RBv/SUPbaJmGOrS3bbaut6WmZ6PvJJcNG4bfJv4xvCZ7KUi4Rlvw5+Gfm+8XcEvsuP5ZQN60JaP+JDcUu7AgXyjAMw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211266BA6F6E06FFB3081425FAD80VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 632bf08c-c06a-44d1-4d05-08d64e0a91be X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 10:34:22.0217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2013 Archived-At: Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 19 Nov 2018 10:34:27 -0000 --_000_VI1PR0801MB211266BA6F6E06FFB3081425FAD80VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The authors of the OAuth Security Topics draft came to the conclusion that = it is not possible to adequately secure the implicit flow against token inj= ection since potential solutions like token binding or JARM are in an early= stage of adoption. For this reason, and since CORS allows browser-based ap= ps to send requests to the token endpoint, Torsten suggested to use the aut= horization code instead of the implicit grant in call cases in his presenta= tion (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oau= th-sessb-draft-ietf-oauth-security-topics-01). A hum in the room at IETF#103 concluded strong support for his recommendati= ons. We would like to confirm the discussion on the list. Please provide a response by December 3rd. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB211266BA6F6E06FFB3081425FAD80VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

The authors of the OAuth Security Topics draft ca= me to the conclusion that it is not possible to adequately secure the impli= cit flow against token injection since potential solutions like token bindi= ng or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to sen= d requests to the token endpoint, Torsten suggested to use the authorizatio= n code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d= raft-ietf-oauth-security-topics-01).

A hum in the room at IETF#103 concluded strong su= pport for his recommendations. We would like to confirm the discussion on t= he list.

Please provide a response by December 3rd.

Ciao

Hannes & Rifaat

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB211266BA6F6E06FFB3081425FAD80VI1PR0801MB2112_-- From nobody Mon Nov 19 05:50:43 2018 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 3F67F130DC8 for ; Mon, 19 Nov 2018 05:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bb1Wv4khDNBg for ; Mon, 19 Nov 2018 05:50:40 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0: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 6A3C412426A for ; Mon, 19 Nov 2018 05:50:40 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id h193so6928817ita.5 for ; Mon, 19 Nov 2018 05:50:40 -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=QXXzleJHudUmTuEjjyLZdO4XQL4+bsbv+jdc0c7b2FY=; b=Su0gYf7dTVPGqAdTU0vn/AlOfVuTpuFUa9ABTN4NbyuWRakO07ptHt8XSfyynvkMiN ByKSdFbtt0BnY6wz3x3xo5mFS9H1JJV9k3txgPk8tqkxTgcEd3Gf58/JR61PW0koglHQ CiuQ0DMN2frK24iMGGxG+UYDqONG3lZPeUgkR0we5tCmDwwIIPTp1CMBWXpdtkOvl8fC hefRCv/37K4xyP6i0woG0DXNi3OBxlCT0I2sxqBQ4X7JERFBFn4tvod3rglwNEHFfZBd QfNsF7tzaTrzCxlYIBgp6NTN4yV77AxX73pmfWFzKZMCc4kJ6Dpqw9qZmtXmnpoROq8c fOWw== 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=QXXzleJHudUmTuEjjyLZdO4XQL4+bsbv+jdc0c7b2FY=; b=L0Jd4SvIo/nqO+t1lIXXQ9c9aeroPU7Fjex+W8ykqL0LoqEndVL9IOS/YzmoxujWK4 Btv90xEOJppXufDrY7rDalRPu3E5j9DCK2xmYQADQxE0JaZglYm+ooElcjvobKx7X4sG ib/OSOCZqkNdVLVQ2LbEYZZ4Heu1UL4T8Iu9iM89vfkJwcrLYap2hKjISeZm8uptu8RQ 6A0Hd/zJMNv3B5kU2hPcvWGzdoicNS8cm4LMRzLjT9yvX8CcjWneuMh7sAp4l8AOY3D0 A1lTNL0v5avn8UlfsTd7ETOG18kHoV0M3YnuFJ/QGsW5Au3sRKFVGzOst0ZxR66AiUre G3GQ== X-Gm-Message-State: AGRZ1gIEI+oaUxmYpeqx1+17HSi6JMwnRYSji0VUcyPDyoa5AGYFQqA6 pa37nUDB1k8SMT9XbKHt/VrDtfseLMFs/06KUQJbX3UFDYc= X-Google-Smtp-Source: AJdET5c3EZ0gTWt+1uzu0tAszwbjdG4472vNFukhgnBBLWddyUti2/jVl0pbuiCVEp+M0bmy2VpA8xPReJjuNCzDJG0= X-Received: by 2002:a24:7690:: with SMTP id z138-v6mr7771561itb.165.1542635439608; Mon, 19 Nov 2018 05:50:39 -0800 (PST) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 19 Nov 2018 08:50:28 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000006558c2057b04cd89" Archived-At: Subject: [OAUTH-WG] WGLC: draft-ietf-oauth-resource-indicators-01 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, 19 Nov 2018 13:50:42 -0000 --0000000000006558c2057b04cd89 Content-Type: text/plain; charset="UTF-8" All, As discussed during the meeting in Bangkok, we are starting a WGLC on the Resource Indicators document: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 Please, review the document and provide feedback on any issues you see with the document. The WGLC will end on December 3rd, 2018. Regards, Rifaat and Hannes --0000000000006558c2057b04cd89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As dis= cussed during the meeting in Bangkok, we are starting a WGLC on the Resourc= e Indicators document:

Please, review = the document and provide feedback on any issues you see with the document.<= /div>

The WGLC will end on December 3rd, 2018.

Regards,
=C2=A0Rifaat and Hannes

--0000000000006558c2057b04cd89-- From nobody Mon Nov 19 07:37:07 2018 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 4EF23130DD3 for ; Mon, 19 Nov 2018 07:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 34lQw0hDPOd7 for ; Mon, 19 Nov 2018 07:37:03 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.29]) (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 2CB6C130DC8 for ; Mon, 19 Nov 2018 07:37:03 -0800 (PST) Received: from [80.187.80.89] (helo=[10.151.119.14]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gOlbf-0007gr-Ad; Mon, 19 Nov 2018 16:37:00 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-CB8EF993-E761-4728-947B-09D16A68B9B8; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Mon, 19 Nov 2018 16:36:57 +0100 Cc: Vladimir Dzhuvinov , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <37CEB045-9A1A-43E0-88F5-50D3F5D705C3@lodderstedt.net> References: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com> To: Hans Zandbelt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 19 Nov 2018 15:37:06 -0000 --Apple-Mail-CB8EF993-E761-4728-947B-09D16A68B9B8 Content-Type: multipart/alternative; boundary=Apple-Mail-EC24D8E3-B710-46C8-B387-521C77B58EA6 Content-Transfer-Encoding: 7bit --Apple-Mail-EC24D8E3-B710-46C8-B387-521C77B58EA6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You mean the binding between refresh tokens and sessions? > Am 19.11.2018 um 11:03 schrieb Hans Zandbelt := >=20 > +1 to the suggestions that Vladimir raises; I've seen a fair number of req= uests in the field for exactly that >=20 > Hans. >=20 >> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov wrote: >>> On 17/11/2018 13:26, Torsten Lodderstedt wrote: >>> To start with, the AS may use refresh token rotation in combination with= automatic revocation in case of detected replay attempts.=20 >>>=20 >>> How does it work? The AS issues a new refresh token with every refresh a= nd invalidate the old one. This restricts the lifetime of a refresh token. I= f someone (might be the legit client or an attacker) submits one of the olde= r, invalidated refresh token, the AS might interpret this as a signal indica= ting token leakage and revoke the valid refresh token as well. We used this t= echnique at Deutsche Telekom since our first OAuth 2.0 implementation back i= n 2012. >> This is a clever solution. Did you experience any false positives, e.g. d= ue to HTTP response timeouts on slow / poor connections? >>=20 >> We were also thinking of additionally binding the refresh token to the en= d-user session at the AS / OP: >>=20 >> A valid refresh causing the session to be refreshed too >> AS / OP logout or session expiration invalidating the refresh token >>=20 >>=20 >> Vladimir >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-EC24D8E3-B710-46C8-B387-521C77B58EA6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
You mean the binding between refresh tokens and sessions?

Am 19.11.2018 um 11:03 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu>:

+1 to the suggestions that Vladimir raises; I've seen a fair number of requests  in the field for exactly that

Hans.

On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
On 17/11/2018 13:26, Torsten Lodderstedt wrote:
To start with, the AS may use refresh token rotation in combination with automatic revocation in case of detected replay attempts. 

How does it work? The AS issues a new refresh token with every refresh and invalidate the old one. This restricts the lifetime of a refresh token. If someone (might be the legit client or an attacker) submits one of the older, invalidated refresh token, the AS might interpret this as a signal indicating token leakage and revoke the valid refresh token as well. We used this technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 2012.

This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections?

We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP:

  • A valid refresh causing the session to be refreshed too
  • AS / OP logout or session expiration invalidating the refresh token


Vladimir

_______________________________________________
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-EC24D8E3-B710-46C8-B387-521C77B58EA6-- --Apple-Mail-CB8EF993-E761-4728-947B-09D16A68B9B8 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTE5MTUzNjU3WjAvBgkqhkiG 9w0BCQQxIgQg0xIab/Zp8+B0nWhPmt5+pKqOppWsmfacPJt/qgWELT4wgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAEKL h4/tkob06oY8QdU7CN+Db+ywuNlT9Fxmp5h8n0bjHSt4nDaJJ/Tw9AwQlITWds6h5lU42ZCDIicR 1v9dM9vJ24/Q3OYMDNIv8BXNDG8k9UnnH956yKCR6eOht+cDGBLdxvq9rZ0tgh/csrDIGedFLCd2 jxpPKMXB0QN+70H4mSw7xOcVYDKN56CF6G4vaqb/bsuIDqdgdTwq0J6HCC6VPCSK+oZNYewHLBPt StNpk7AzVzHTooN9MMAB8bgJgVSOkmz3kHdCdPZX2CMQt+k1bFndPqFuSu1sEP6CNeJY/3ZMjWaH +OZzUlt5G0iFaxlyNDL4mXg87e0Auar4kmkAAAAAAAA= --Apple-Mail-CB8EF993-E761-4728-947B-09D16A68B9B8-- From nobody Mon Nov 19 14:13:36 2018 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 1656C130DEE for ; Mon, 19 Nov 2018 14:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 A2bYMjjGm-1C for ; Mon, 19 Nov 2018 14:13:32 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF76130DE5 for ; Mon, 19 Nov 2018 14:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DCi114Z92ieaiQL257Sa2TK+QFoC95w0HO9dRFeMlK4=; b=XPs34PjyiG6jIc+dPUPwY5G7ku3U3hm/veitDGON23g8uEjuIlS1G8VunoeAaGBJrilpHz6JpkGcgVz7zhL2d/Hw7QwZKuiV1qB7zD6LpB0P7X3VReEAptBXctQxOjQlFx6sT6n52RxKJSbWoTTFMknwH1vlXTWbIHcU+ygo4bw= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0402.namprd00.prod.outlook.com (52.132.20.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1395.0; Mon, 19 Nov 2018 22:13:30 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::a18d:49e5:f24f:5fbf]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::a18d:49e5:f24f:5fbf%5]) with mapi id 15.20.1396.000; Mon, 19 Nov 2018 22:13:30 +0000 From: Mike Jones To: Hannes Tschofenig , oauth Thread-Topic: OAuth Security Topics -- Recommend authorization code instead of implicit Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwAYRRbA Date: Mon, 19 Nov 2018 22:13:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-11-19T22:13:26.5349988Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:9:48d3:87f8:bb08:ae16] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0402; 6:uQJ2+i3z5sdADlJNh7J4dTLhrGpLMVZW0mRhQ4freUhBhk5O0OhsycNalS0ZDX4WEGvnRa4+6rTRAnZkQUPRgB/jLfymScG9k5PC7OWnA9HmzwxT6fTpSXr2MXKGLBBjiXfdlwCZWT/2DncCvIUiuGhu67m/kPirYnfRTfLjKguyavPOv87z7rUrAgazmmg3dAISM2nrJdYTJc3vLAezs4UYtsWSq3NcSg57JlP7lWEZ6EuKY5fa2IEx9+FE5LRqbeQvdS7H+SEmqwlr6yO80hDrBgDi3T36oPLM0ViM8snVoW6T3iL8n86bLGiqMy6O+DWx40OtRa0RpJ6xnhWFJYp+YhzluVBmsG/cg7V4k7TTE9e0uzA3AcB/fjlM5RUTItw4DE8b1RTNkEspQpHyF2B4uuZI4AoYFLqEhKrZZqyUIZ2SfcFYIiZNZMvL1O2GCRf/K0epxXIlJEyCfaE3lw==; 5:xW+BBDktCIJ1VGK+863LUkq1wHOHqqcryLuRNLbsP3ozi7wiMcKXB/g1GuWPvKWfCGovAHigTzVSzqpYcxxmCobZOWDYBvowtrkyWNPmEDBrgbUoQKfQQdr1f0cpohZ/Iq3Thj/JHuSnuDSBnuRgW7PYiQktM65SC2501AXl6Wg=; 7:OPnoHn++5EsKdkv2hDIs2J0NFi6YSxvdctZUHQ/QNeJ3JlLGdcWZlY84twMd29RaREu7m8SfoZ9QEis0xOPvKRQQZcFUhBbhu+C8Us391tpZMJdeY4/xs1SzrsgU373D67M5lLCKuFQ42JbOLo6L6g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ba0a1f88-5929-4d2d-1657-08d64e6c3cba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR00MB0402; x-ms-traffictypediagnostic: BL0PR00MB0402: x-ms-exchange-purlcount: 6 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3002001)(3231440)(944501410)(2018427008)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:BL0PR00MB0402; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0402; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39860400002)(136003)(346002)(53754006)(189003)(199004)(40434004)(478600001)(81166006)(81156014)(6436002)(72206003)(966005)(7110500001)(86612001)(8676002)(10090500001)(66574009)(6116002)(790700001)(10290500003)(8936002)(14454004)(8990500004)(229853002)(33656002)(106356001)(2900100001)(25786009)(2906002)(10710500007)(86362001)(71200400001)(71190400001)(5024004)(14444005)(97736004)(15650500001)(110136005)(54906003)(5660300001)(53546011)(6506007)(102836004)(316002)(2420400007)(186003)(606006)(55016002)(4326008)(105586002)(7736002)(7696005)(76176011)(74316002)(99286004)(46003)(39060400002)(54896002)(236005)(9686003)(68736007)(6306002)(22452003)(256004)(476003)(6246003)(446003)(11346002)(486006)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0402; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DeAETJKkaliPdvqF9sO5FeQYcO9/V50jzbM2ja84PYoyhOM8zKRUTtWDgVTM0iVYcHQF+X7QUQLf2vx42Wo8VQbAb/45oXvbQosus1a29ElLM11Vv4P2YAXuAOBVCGZSpGs+eC4vzOjWy54D0ykTLPTqG/4flPOD/ghIei6aMN/obQ0ayvHUnz3Vj6aHsDEq+btGOiDBaR2OHZWEJr0c1yBB4AwY9ZBM2+wuBo6aVzeHiVFlIFTp/8ItFKQhhQuGvHQGspBMpEZL/6JbqKW2Lt++sQTCN5+H1X/0EvVOvHkEBUECNa94J9wj88SZHT8AcQQ6qQvp67OLiAivSgGp2/lQvSgIDsx8F3LZB9J2DAo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB029244CACC634E2D2E923B77F5D80BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba0a1f88-5929-4d2d-1657-08d64e6c3cba X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 22:13:29.9778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0402 Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 19 Nov 2018 22:13:35 -0000 --_000_BL0PR00MB029244CACC634E2D2E923B77F5D80BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This description of the situation is an oversimplification. OpenID Connect= secures the implicit flow against token injection attacks by including the= at_hash (access token hash) in the ID Token, enabling the client to valida= te that the access token was created by the issuer in the ID Token (which i= s also the OAuth Issuer, as described in RFC 8414). (Note that this mitigation was described in draft-ietf-oauth= -mix-up-mitigation.) Given the prevalence of this known-good solution for securing the implicit = flow, I would request that the draft be updated to describe this mitigation= . At the same time, I'm fine with the draft recommending the code flow ove= r the implicit flow when this mitigation is not used. Thank you, -- Mike From: OAuth On Behalf Of Hannes Tschofenig Sent: Monday, November 19, 2018 2:34 AM To: oauth Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code i= nstead of implicit Hi all, The authors of the OAuth Security Topics draft came to the conclusion that = it is not possible to adequately secure the implicit flow against token inj= ection since potential solutions like token binding or JARM are in an early= stage of adoption. For this reason, and since CORS allows browser-based ap= ps to send requests to the token endpoint, Torsten suggested to use the aut= horization code instead of the implicit grant in call cases in his presenta= tion (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oau= th-sessb-draft-ietf-oauth-security-topics-01). A hum in the room at IETF#103 concluded strong support for his recommendati= ons. We would like to confirm the discussion on the list. Please provide a response by December 3rd. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_BL0PR00MB029244CACC634E2D2E923B77F5D80BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This description of th= e situation is an oversimplification.  OpenID Connect secures the impl= icit flow against token injection attacks by including the at_hash (access = token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the = ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note = that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)

 

Given the prevalence o= f this known-good solution for securing the implicit flow, I would request = that the draft be updated to describe this mitigation.  At the same ti= me, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thank you,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization= code instead of implicit

 

Hi all,

 

The authors of the OAuth Sec= urity Topics draft came to the conclusion that it is not possible to adequa= tely secure the implicit flow against token injection since potential solut= ions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows brow= ser-based apps to send requests to the token endpoint, Torsten suggested to= use the authorization code instead of the implicit grant in call cases in = his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d= raft-ietf-oauth-security-topics-01).

 

A hum in the room at IETF#10= 3 concluded strong support for his recommendations. We would like to confir= m the discussion on the list.

 

Please provide a response by= December 3rd.

 

Ciao

Hannes & Rifaat

 

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

--_000_BL0PR00MB029244CACC634E2D2E923B77F5D80BL0PR00MB0292namp_-- From nobody Mon Nov 19 15:49:33 2018 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 D46E3130DE4 for ; Mon, 19 Nov 2018 15:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCcdrvCrd6Aa for ; Mon, 19 Nov 2018 15:49:30 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C74128C65 for ; Mon, 19 Nov 2018 15:49:30 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id x6so45721ioa.9 for ; Mon, 19 Nov 2018 15:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h9f+pbMQuBEbLBXyWa3qdFp/cbiTaolz1HOB4T7Q2Jg=; b=GIufu3UjM9Dl8xoZyA0L4v38JQYO3Oa3adZ3mFrqI2boEwMmndpf8bVFsWbRgo/jbY 4GSPa2ZXi5DgaRtX309uYpt4i1XTh6GoehtEekwjV1LjpKCwthGShFBuk6cpRmW1z65c etbYJtBS4FNK7PsF/746AjsDicjXP8CledjAFJxKLRD3KdY9uGWcAeGRnsBueGi5RYMj 434ghpHF0VujSwg7COu7A4MkueQSHCg/eS0Q5mVyxr6jDyfECroMgzPG/ybNmmUWSME8 GkdyZxZxOUNviqayPzbAFZ2Rqrb+N69c4HSq23tmTU51DMXs0FImwFBhXinOdR9iUwYE 2tow== 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=h9f+pbMQuBEbLBXyWa3qdFp/cbiTaolz1HOB4T7Q2Jg=; b=PfnYzKKHNrkZAPKmniVl5eg+rAuyiWGoxN6+SnJ3Uz9Q7rH0wfAUFDMHgn53UmhKL7 nbBQsjivH27u7eksg08E9ljD2Q+Nzv5q29FNejTAyCxdOp2DK3CJlFUbffszvXUlBg3P fgIP1XOw8mpBICXQOfC4AYckvFiVQCCv2LJ/bTxrOMyGn6kvcchheoaMmh5jH/OURDyv NWzohfTuS7sdzLmTsqOOhNe2vc1eqzhuJwVidNYsveJ9Q0wCea6wH2Ewr9h9rroQ5Yix FgwRdvbW1nU9SUfOFijAlifNyp+x1qgm6ACUdKu2TJhp2Txfc9GASl/Usz2mJ1eDbdJK psdw== X-Gm-Message-State: AA+aEWZ46nu/FWjVrvNQKcf0gbY8NarP9BZGdGaz4Svb8ENfGBwwzycx skXfeN1DIBrmMDCPYLCZKQY0RZdkBsM= X-Google-Smtp-Source: AFSGD/XHOm7zjCemwceGVE+Cnj0Gj6CRcwUz2AfNpA6IqA3zEo/bm6Tn75h4iiZgttEFEj3LuJyoLg== X-Received: by 2002:a6b:4f14:: with SMTP id d20-v6mr20394953iob.68.1542671369738; Mon, 19 Nov 2018 15:49:29 -0800 (PST) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id e64-v6sm10904098iof.12.2018.11.19.15.49.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 15:49:29 -0800 (PST) Received: by mail-io1-f52.google.com with SMTP id m19so66786ioh.3 for ; Mon, 19 Nov 2018 15:49:28 -0800 (PST) X-Received: by 2002:a6b:8d8a:: with SMTP id p132mr20036543iod.290.1542671368409; Mon, 19 Nov 2018 15:49:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Mon, 19 Nov 2018 15:49:17 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Cc: Hannes Tschofenig , Michael.Jones=40microsoft.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="000000000000eb5bb3057b0d2aa4" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 19 Nov 2018 23:49:33 -0000 --000000000000eb5bb3057b0d2aa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My understanding was that the scope of the discussion was limited to OAuth, and does not cover OpenID Connect ID Tokens. With that in mind, I support the recommendation to use the authorization code instead of the implicit flow. ---- Aaron Parecki aaronparecki.com @aaronpk On Mon, Nov 19, 2018 at 2:13 PM Mike Jones wrote: > This description of the situation is an oversimplification. OpenID > Connect secures the implicit flow against token injection attacks by > including the at_hash (access token hash) in the ID Token, enabling the > client to validate that the access token was created by the issuer in the > ID Token (which is also the OAuth Issuer, as described in RFC 8414 > ). (Note that this mitigation was > described in draft-ietf-oauth-mix-up-mitigation > .) > > > > Given the prevalence of this known-good solution for securing the implici= t > flow, I would request that the draft be updated to describe this > mitigation. At the same time, I=E2=80=99m fine with the draft recommendi= ng the > code flow over the implicit flow when this mitigation is not used. > > > > Thank you= , > > -- Mike > > > > *From:* OAuth *On Behalf Of * Hannes Tschofenig > *Sent:* Monday, November 19, 2018 2:34 AM > *To:* oauth > *Subject:* [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > > > > Hi all, > > > > The authors of the OAuth Security Topics draft came to the conclusion tha= t > it is not possible to adequately secure the implicit flow against token > injection since potential solutions like token binding or JARM are in an > early stage of adoption. For this reason, and since CORS allows > browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (see > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb= -draft-ietf-oauth-security-topics-01 > ). > > > > A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. > > > > Please provide a response by December 3rd. > > > > Ciao > > Hannes & Rifaat > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000eb5bb3057b0d2aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My understanding was that the scope of the discussion was = limited to OAuth, and does not cover OpenID Connect ID Tokens. With that in= mind, I support the recommendation to use the authorization code instead o= f the implicit flow.

----
Aaro= n Parecki


On Mon, Nov 19, 2018 at 2:13 = PM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

This description of th= e situation is an oversimplification.=C2=A0 OpenID Connect secures the impl= icit flow against token injection attacks by including the at_hash (access = token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the = ID Token (which is also the OAuth Issuer, as described in RFC 8414<= /a>).=C2=A0 (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)=

=C2=A0

Given the prevalence o= f this known-good solution for securing the implicit flow, I would request = that the draft be updated to describe this mitigation.=C2=A0 At the same ti= me, I=E2=80=99m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank you,=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization= code instead of implicit

=C2=A0

Hi all,=

= =C2=A0

The aut= hors of the OAuth Security Topics draft came to the conclusion that it is n= ot possible to adequately secure the implicit flow against token injection = since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows brow= ser-based apps to send requests to the token endpoint, Torsten suggested to= use the authorization code instead of the implicit grant in call cases in = his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d= raft-ietf-oauth-security-topics-01).

= =C2=A0

A hum i= n the room at IETF#103 concluded strong support for his recommendations. We= would like to confirm the discussion on the list.

= =C2=A0

Please = provide a response by December 3rd.

= =C2=A0

Ciao=

Hannes = & Rifaat

=C2=A0

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000eb5bb3057b0d2aa4-- From nobody Mon Nov 19 18:09:22 2018 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 7D7A6127333 for ; Mon, 19 Nov 2018 18:09:21 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En4vIDK7YNJy for ; Mon, 19 Nov 2018 18:09:18 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6850124BE5 for ; Mon, 19 Nov 2018 18:09:18 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id m1-v6so220881ioc.13 for ; Mon, 19 Nov 2018 18:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tRW99u+zGR7hNS6WFRX/qtdbi8Je5LaO2itau+Aqqtw=; b=YUUHr4/luiV0CQeTMeNvtueYtcHGA1HQMvSf2nRkmRt4QGfRsAvXfulgIRydouHuG+ FN1U/3VfQM0b0qfvaHQYFgpQMFUoPDTAJSRBnNSF8+SZ3dhszsVEC12f5E/uaRCpUTvS 4y0JmyW8VeUpunAKm++dJdZUy8+Jng+iVVCQNzVEC2mQaMzQXzz+V7ORdDT4yjWMr43H 0YoGrXuq+nvqkXK/12ZKPNl1afy73AkJPpIUcISQ8pZtZSCVZ2sHyUf89hHc02TOkoss nA6QAG89IiboT7EoSCEhgS29HLFyolQieFuTOFYi7odDttgsXil5Me9RSqAaDh238JJ6 WdjQ== 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=tRW99u+zGR7hNS6WFRX/qtdbi8Je5LaO2itau+Aqqtw=; b=p9Oe804If6dKgsgeMJx8oZsVcAeRn5EEM3WGC8b6zxjx6yeFmckzA5f2hSc399Kqew KqL0epPVHg/aDzMj3577cJZrch6NYbWui2FkQDJxZUKXhbBRya4LEwmr99xUIu0COvoZ 0f/ENRse7yRsrbPnk7RuaJ4g1vlqsgeQ2TTvmSjnUErEPkLfL4anZu0zWlLJLOM3gnGs fxFmv/gTjnSnFPShTDxqZfGdA7VwUPSp9++35Ce+qxtD+oXyxPwaPCpxLpT4fk4+RL1k rN+Ns6+05KkZn0SaKv3YABL+dUWBdTt491vX3KN8JcemTcY5gQiIAdNM4s6dcvqh0X03 D1JA== X-Gm-Message-State: AA+aEWZhZjgcKhTDlnQM9njmifSRcmeV/1lyOb1YkN0dsIHnUj4ONWF4 4GN3GcKXli7vna00tgnr8NswJ+ZA3/o= X-Google-Smtp-Source: AFSGD/U6HWMIvauWieIbCNe/pl1IXbe7GYRyNiMfZTYR9qG5TWfp1y/YLw0mSTeQAcA+T25yYH9O0Q== X-Received: by 2002:a6b:5116:: with SMTP id f22mr126054iob.28.1542679757760; Mon, 19 Nov 2018 18:09:17 -0800 (PST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com. [209.85.166.43]) by smtp.gmail.com with ESMTPSA id 186-v6sm14921750itf.11.2018.11.19.18.09.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 18:09:16 -0800 (PST) Received: by mail-io1-f43.google.com with SMTP id w7so225712iom.12 for ; Mon, 19 Nov 2018 18:09:16 -0800 (PST) X-Received: by 2002:a6b:8d8a:: with SMTP id p132mr105456iod.290.1542679755825; Mon, 19 Nov 2018 18:09:15 -0800 (PST) MIME-Version: 1.0 References: <894C1893-8722-4005-8A33-AECADFD18024@authlete.com> In-Reply-To: <894C1893-8722-4005-8A33-AECADFD18024@authlete.com> From: Aaron Parecki Date: Mon, 19 Nov 2018 18:09:03 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000d92b97057b0f1e6c" Archived-At: Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 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, 20 Nov 2018 02:09:21 -0000 --000000000000d92b97057b0f1e6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan wrote: > It may be worth slightly rewording 7.2 as it may encourage a growing > misconception that all native apps must be public clients. With many > devices now having embedded HSMs, we=E2=80=99ve seen increasing interest = in mobile > apps being dynamically (per-install) registered oauth2 private clients, a= nd > that model has a lot of advantages. (I=E2=80=99m not sure if we might see= a similar > model evolving for web apps.) > That's a great point, thanks. I've removed the reference to native apps being public clients since it doesn't really add anything to this spec if I have to caveat the description. On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > > First of all the AS decides whether it issues refresh tokens or not. > Having the ability does not mean the AS must do it. If you feel it=E2=80= =99s safer > to not do it. Fine. > > Sure, and this should be mentioned then somewhere (either in the threat= s > doc or in this proposed best practice doc). Not all end developers using > these protocols fully understand the ramifications. > @Aaron: I suggest this goes to the SPA BCP since this is client specific. Thanks, I agree that this document should include some recommendations around refresh token handling. Looking at the discussion in this thread, it seems there are a few different strategies folks are taking. Since it seems like there isn't a strong consensus, it sounds like this would be better suited for the "Security Considerations" section, and to not make MUST/SHOULD recommendations, but rather just point out the issues. Any thoughts on that before I take a stab at writing something? I've incorporated some of the other feedback here and published an updated version: https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01 Thanks for the feedback so far. --- Aaron Parecki https://aaronparecki.com --000000000000d92b97057b0f1e6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 7, 2018 at 7:20 AM Joseph = Heenan <joseph@= authlete.com> wrote:
=C2=A0
It may be worth slightly rewording 7= .2 as it may encourage a growing misconception that all native apps must be= public clients. With many devices now having embedded HSMs, we=E2=80=99ve = seen increasing interest in mobile apps being dynamically (per-install) reg= istered oauth2 private clients, and that model has a lot of advantages. (I= =E2=80=99m not sure if we might see a similar model evolving for web apps.)= =C2=A0

That's a great point= , thanks. I've removed the reference to native apps being public client= s since it doesn't really add anything to this spec if I have to caveat= the description.

On Thu, Nov 15, 2018 at 12:58 PM= Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=
> > First of a= ll the AS decides whether it issues refresh tokens or not. Having the abili= ty does not mean the AS must do it. If you feel it=E2=80=99s safer to not d= o it. Fine.=C2=A0
> Sure, and this should be mentioned then somewhere= (either in the threats doc or in this proposed best practice doc). Not all= end developers using these protocols fully understand the ramifications.= =C2=A0
@Aaron: I suggest this goes to the SPA BCP since this is client s= pecific.

Thanks, I agree that this do= cument should include some recommendations around refresh token handling. L= ooking at the discussion in this thread, it seems there are a few different= strategies folks are taking. Since it seems like there isn't a strong = consensus, it sounds like this would be better suited for the "Securit= y Considerations" section, and to not make MUST/SHOULD recommendations= , but rather just point out the issues. Any thoughts on that before I take = a stab at writing something?

I've incorporated= some of the other feedback here and published an updated version:


Thanks for the feedback= so far.

---
Aaron Parecki
<= /div>
--000000000000d92b97057b0f1e6c-- From nobody Mon Nov 19 23:36:28 2018 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 55C781277D2 for ; Mon, 19 Nov 2018 23:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fjNwHW9suGaC for ; Mon, 19 Nov 2018 23:36:23 -0800 (PST) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.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 A55D512870E for ; Mon, 19 Nov 2018 23:36:23 -0800 (PST) Received: from [46.183.103.17] (helo=[172.18.243.21]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gP0Zx-0005PO-4R; Tue, 20 Nov 2018 08:36:19 +0100 From: Torsten Lodderstedt Message-Id: <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_877B6901-5F4B-46AE-8217-8439AF1A2BDE"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 20 Nov 2018 08:35:17 +0100 In-Reply-To: Cc: Hannes Tschofenig , oauth To: Mike Jones References: X-Mailer: Apple Mail (2.3445.101.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 20 Nov 2018 07:36:27 -0000 --Apple-Mail=_877B6901-5F4B-46AE-8217-8439AF1A2BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike,=20 I agree that OIDC hybrid flows offer additional security over the OAuth = implicit grant and are used in the wild. On my slides and in the initial = version of the new section, we had included the hybrid OIDC flows = because of their known token injection countermeasures. I nevertheless feel very uncomfortable to recommend those flows and any = flow issuing access tokens in the front channel. In the course of the = detailed review of the new text we realized two issues:=20 1) Since the access token is exposed in the URL, such flows possess a = significantly higher risk to leak the access token (e.g. through browser = history, open redirection and even referrer headers) than the code = grant. 2) There is no viable way to sender constrain access tokens issued in = the front channel. Given the WG decided to recommend use of sender = constraint tokens = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= .2), it seems contradictory to recommend response types not supporting = such an approach.=20 kind regards, Torsten.=20 > Am 19.11.2018 um 23:13 schrieb Mike Jones = : >=20 > This description of the situation is an oversimplification. OpenID = Connect secures the implicit flow against token injection attacks by = including the at_hash (access token hash) in the ID Token, enabling the = client to validate that the access token was created by the issuer in = the ID Token (which is also the OAuth Issuer, as described in RFC 8414). = (Note that this mitigation was described in = draft-ietf-oauth-mix-up-mitigation.) > =20 > Given the prevalence of this known-good solution for securing the = implicit flow, I would request that the draft be updated to describe = this mitigation. At the same time, I=E2=80=99m fine with the draft = recommending the code flow over the implicit flow when this mitigation = is not used. > =20 > Thank = you, > -- = Mike > =20 > From: OAuth On Behalf Of Hannes Tschofenig > Sent: Monday, November 19, 2018 2:34 AM > To: oauth > Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization = code instead of implicit > =20 > Hi all, > =20 > The authors of the OAuth Security Topics draft came to the conclusion = that it is not possible to adequately secure the implicit flow against = token injection since potential solutions like token binding or JARM are = in an early stage of adoption. For this reason, and since CORS allows = browser-based apps to send requests to the token endpoint, Torsten = suggested to use the authorization code instead of the implicit grant in = call cases in his presentation = (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-se= ssb-draft-ietf-oauth-security-topics-01). > =20 > A hum in the room at IETF#103 concluded strong support for his = recommendations. We would like to confirm the discussion on the list. > =20 > Please provide a response by December 3rd. > =20 > Ciao > Hannes & Rifaat > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_877B6901-5F4B-46AE-8217-8439AF1A2BDE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU 50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5 6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3 ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+ IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7 BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjAwNzM1MTdaMC8GCSqGSIb3DQEJBDEiBCD6 tBPBEfcu528DYhyizW0Rw4Tyus/GzQWhuQHagtXI3DCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAt07dNedkSTwcaWyYL8UcEN/c ag9Gk1yFpmXr7iiQbYVAjhEocC51Qza8iG7+uCpzQbTt91NlfGEtwIg8bm59dJA98PX3N9/RDfU4 KlSlObPDIU1M6VYVzcBZ8IBDUYb3q2mmXTJhuDX08wn9QhvIfWzOws44zt5za2yZOH6ixFSjZ4q0 Po6wt66OR/BP2Zb2DCz0R1F8uyMpPmy9DS1ig11anMNK0zkZ6egGh//0+N095i9+vffN9PifTaRY pNsqulFgywc/XJrCCxKM8Sg7KGrvfRR0eKhiL7pOgsVMD2LfOKQvQk1Otgu89cUDqs871iI5OG3E hNMtGTdLm4+oqQAAAAAAAA== --Apple-Mail=_877B6901-5F4B-46AE-8217-8439AF1A2BDE-- From nobody Tue Nov 20 03:45:15 2018 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 2F0FB130DF9 for ; Tue, 20 Nov 2018 03:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 daB64kJgkMqY for ; Tue, 20 Nov 2018 03:45:03 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AF3130DF1 for ; Tue, 20 Nov 2018 03:45:03 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id 32so1344579ota.12 for ; Tue, 20 Nov 2018 03:45:03 -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=6e8plJ3BOd3vfFp/Tn9N2+e3Tq/KHmRt/36FzxzF6pA=; b=IEnuEsAPRow8CdSHylQrb2wL8RPcTNrwK+6tQpOvb4DBvt7rMuAHsX3J8PQOwMa5sl 0LddGKIgy5HpdCE7ABXERV9rBIcfDXrT8nKDxeVoyAaKBs4sZUB7Xosu31V0I7J6N/i7 i6/fgnpiKgjim2NY9KZzkEi8+mvV3se+6IXiwSBHrOAuEJ7ZBV6rm5dYN6ORtQngAQyB hrtjr2WOePtpHtOuLTdHxHpbwevvMzTosYxVLKwShUvy6J/m/cqFPW58AYaqmM+Mi2Qp HO9ofmcbJkHXdMaSB918vRt/jdsIT9z/Ux29EBn+4APDFF1hp8rRsf5Zj2qSlXeBxOdL c4PA== 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=6e8plJ3BOd3vfFp/Tn9N2+e3Tq/KHmRt/36FzxzF6pA=; b=POxagXom2BTDj09LYlne0IeAAtYK3+oYiNS8vRgXTqXT9zOWCuwULaO6r7Lo9Aae8M fB/m64hiwokw91HKKIe3laMwoP8wFz59uTKqGll3P2KeWpZ8gTb7R93W4BnkW7d9crta 1xY5nZApzIBhHcrXwrCmrjf8h3GjZ3Ldm+EZCy3J056LH4IignwGJdAAc2SNFLUTRI5U GInfOb9U8oYrgydvx3b1rxTD3Up/FOc6AZvM6bNparqKL1MAhviceACSxXFsb1OMH5QP irk8dOOaj1RbLoNCzGIwBxIc9vquQ8vKHE9lRvO4UKZdG12ku5Z/k8q+NSFRdD7/8Q2I 8+bw== X-Gm-Message-State: AA+aEWbsiTYQVxji7dOorgOXmAJUKjXQDPiS2XBe1s/UHZTLVsac8CXS 7k2GVdet6yVR2Fujl3M3tLIxuFj8cAkr2A8nsjZtlYk= X-Google-Smtp-Source: AFSGD/VyHkY9loxL+DE3mMYgyTXEHgGqWPbWBmGYRO8+V6WSfJLs7vVLPZQ8f+GiZbUyrf4+iBs0OT79Maz4z/wfe/8= X-Received: by 2002:a9d:927:: with SMTP id 36mr1025240otp.263.1542714301981; Tue, 20 Nov 2018 03:45:01 -0800 (PST) MIME-Version: 1.0 From: Filip Skokan Date: Tue, 20 Nov 2018 12:44:50 +0100 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000f5a95e057b172960" Archived-At: Subject: [OAUTH-WG] Dynamic Client Registration - client_secret_expires_at 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, 20 Nov 2018 11:45:14 -0000 --000000000000f5a95e057b172960 Content-Type: text/plain; charset="UTF-8" Hi all, a recent query about expiring client credentials (secrets) got me thinking about client_secret_expires_at client metadata from RFC 7591 used also in 7592 as well as OpenID Connect Dynamic Client Registration 1.0 *What does expired client secret (in the sense of client_secret_expires_at with a non 0 value) mean beyond obviously not processing secret-based client authentication (basic, post and client_secret_jwt) after the given timestamp?* *Fingers Crossed* I'm hoping for your comments and experience from existing deployments on the topic to shed some light on this for me and maybe others too. Also that this doesn't get lost between the current BCP/implicit discussions. This is my best shot at an implementable policy when it comes to clients with expired client secrets: *"all operations requiring a secret will be rejected when an expired one is presented"* - it is not valid for client secret based endpoint auth (basic, post, client secret jwt), the AS will reject with 401 invalid_client in those cases - it will not be used for validating symmetrically signed request object (JAR), the AS will reject the authorization request with ...? - it will not be used by the AS to symmetrically sign id tokens, userinfo, introspection or authorization responses (JARM), the AS will reject the requests with ...? - anything else? I feel this is reasonable interpretation and if so, are there appropriate errors to return to clients (both front and back-channel) when an expired secret is encountered during one of the operations that need it? Thank you very much for your thoughts and comments. Best, Filip --000000000000f5a95e057b172960 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

a recent query about expiring client credentials (secrets) got me th= inking about client_secret_expires_at client metadata from=C2=A0RFC 7591 us= ed also in 7592 as well as=C2=A0OpenID Connect Dynamic Client Registration = 1.0

What does expired client secret (in the sen= se of client_secret_expires_at with a non 0 value) mean beyond obviously no= t processing secret-based client authentication (basic, post and client_sec= ret_jwt) after the given timestamp?=C2=A0*Fingers Crossed* I'm hopi= ng for your comments and experience from existing deployments on the topic = to shed some light on this for me and maybe others too. Also that this does= n't get lost between the current BCP/implicit discussions.
This is my best shot at an implementable policy when it comes = to clients with expired client secrets: "all operations requiring a= secret will be rejected when an expired one is presented"
  • it is not valid for client secret based endpoint auth (basic, po= st, client secret jwt), the AS will reject with 401 invalid_client in those= cases
  • it will not be used for validating symmetrically signed = request object (JAR), the AS will reject the authorization request with ...= ?
  • it will not be used by the AS to symmetrically sign id tokens= , userinfo, introspection or authorization responses (JARM), the AS will re= ject the requests with=C2=A0...?
  • anything else?
    I feel this is reasonable interpretation and if so, are there appro= priate errors to return to clients (both front and back-channel) when an ex= pired secret is encountered during one of the operations that need it?

    Thank you very much for your thoughts and commen= ts.

    Best,
    Filip
--000000000000f5a95e057b172960-- From nobody Tue Nov 20 04:25:24 2018 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 60380130E10 for ; Tue, 20 Nov 2018 04:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 N6C1SyCqAKpj for ; Tue, 20 Nov 2018 04:25:19 -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 7796F130DFA for ; Tue, 20 Nov 2018 04:25:19 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id 96so1775964wrb.2 for ; Tue, 20 Nov 2018 04:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nEfTORhgwc7fg6z+w1ijwOMbbjE5chIzDUAYgI5vgwM=; b=WLXPI91OvZzohrGBFrTi85iHqiBtjdHYEIGKKqy1f/qyR6ua0NnPJDZDI+Jpy4Xocb yvnEwAOK9/dir4Rq7v4M1MtGnrV+qwQxQJ/IR9xD0Szk1U6XqJg8Tta2WUTx4ASfqYs4 3ZqUOzoO0jiZm3hsSKUGdeCKcLbOwLG4+yQkI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nEfTORhgwc7fg6z+w1ijwOMbbjE5chIzDUAYgI5vgwM=; b=MTxIbhZUEgeN4dmXu5fEdqiVg6STqA8DDV/3ISweAlQt5S8JTVRiIdkQJWWEILJAO9 mco44aMg8rzpXTUwN3/K4nAHKtUOoXvZb3zpbkwWOBb0xheT28JKNHt+/PUXobpKGVyD XGx/Qz4l1WHUcm0MEwdZAQCghljBaqFLt3MU+F/TQGLSIoneoxoRw8uj95wLH1j6RPRk UBeT1CFwlfhZE0dNDPat2d+aUvQnHNIf6sgN1C0sVJ1e8zJMkiXw/evN8BvxSMMiLdyt 1BO++DOqmBgjPC1vr3WcUDmdxeJT7jXPl4/tkv9keooW1prFyB4HerE6EyImlJwMEO8O WJmg== X-Gm-Message-State: AA+aEWbYfWbgdTCaSVl/+5iCTqOK8tW/ucVvBdOC4FCPJ7icHOFQFrZB 6EpFk1ye7Z6l5h89LldfWydiEkisnt0= X-Google-Smtp-Source: AFSGD/VTQHOjUc+SR1dqZA8KTt19nCEYJI5uc1zg6HloI03nVEonQNNQXpPQxCKHZd2xK6SWJ0rbxw== X-Received: by 2002:a5d:63c3:: with SMTP id c3mr1748323wrw.215.1542716717743; Tue, 20 Nov 2018 04:25:17 -0800 (PST) Received: from ?IPv6:2a01:4c8:1a:2953:c800:a6d5:81ac:d199? ([2a01:4c8:1a:2953:c800:a6d5:81ac:d199]) by smtp.gmail.com with ESMTPSA id d4sm39195561wrp.89.2018.11.20.04.25.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 04:25:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Neil Madden In-Reply-To: <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> Date: Tue, 20 Nov 2018 12:24:55 +0000 Cc: Mike Jones , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> References: <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 20 Nov 2018 12:25:22 -0000 I think the draft should elaborate more on what it means by =E2=80=9Ctoken= replay=E2=80=9D in section 2.2 and how the proposal to use = sender-constrained tokens prevents it. As far as I can tell, of the 4 = methods presented in section 3.8.1.2, only jpop signed requests actually = includes any specific countermeasure for replay (in the form of = negotiated nonces).=20 If we are discussing this in the context of client-side web apps/SPAs, = then surely the threat model includes malicious 3rd party scripts - for = which neither token binding nor mTLS constrained tokens are very = effective as those scripts run in the same TLS context as the legitimate = client? =E2=80=94 Neil > On 20 Nov 2018, at 07:35, Torsten Lodderstedt = wrote: >=20 > Hi Mike,=20 >=20 > I agree that OIDC hybrid flows offer additional security over the = OAuth implicit grant and are used in the wild. On my slides and in the = initial version of the new section, we had included the hybrid OIDC = flows because of their known token injection countermeasures. >=20 > I nevertheless feel very uncomfortable to recommend those flows and = any flow issuing access tokens in the front channel. In the course of = the detailed review of the new text we realized two issues:=20 >=20 > 1) Since the access token is exposed in the URL, such flows possess a = significantly higher risk to leak the access token (e.g. through browser = history, open redirection and even referrer headers) than the code = grant. > 2) There is no viable way to sender constrain access tokens issued in = the front channel. Given the WG decided to recommend use of sender = constraint tokens = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= .2), it seems contradictory to recommend response types not supporting = such an approach.=20 >=20 > kind regards, > Torsten.=20 >=20 >> Am 19.11.2018 um 23:13 schrieb Mike Jones = : >>=20 >> This description of the situation is an oversimplification. OpenID = Connect secures the implicit flow against token injection attacks by = including the at_hash (access token hash) in the ID Token, enabling the = client to validate that the access token was created by the issuer in = the ID Token (which is also the OAuth Issuer, as described in RFC 8414). = (Note that this mitigation was described in = draft-ietf-oauth-mix-up-mitigation.) >>=20 >> Given the prevalence of this known-good solution for securing the = implicit flow, I would request that the draft be updated to describe = this mitigation. At the same time, I=E2=80=99m fine with the draft = recommending the code flow over the implicit flow when this mitigation = is not used. >>=20 >> Thank = you, >> -- = Mike >>=20 >> From: OAuth On Behalf Of Hannes Tschofenig >> Sent: Monday, November 19, 2018 2:34 AM >> To: oauth >> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization = code instead of implicit >>=20 >> Hi all, >>=20 >> The authors of the OAuth Security Topics draft came to the conclusion = that it is not possible to adequately secure the implicit flow against = token injection since potential solutions like token binding or JARM are = in an early stage of adoption. For this reason, and since CORS allows = browser-based apps to send requests to the token endpoint, Torsten = suggested to use the authorization code instead of the implicit grant in = call cases in his presentation = (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-se= ssb-draft-ietf-oauth-security-topics-01). >>=20 >> A hum in the room at IETF#103 concluded strong support for his = recommendations. We would like to confirm the discussion on the list. >>=20 >> Please provide a response by December 3rd. >>=20 >> Ciao >> Hannes & Rifaat >>=20 >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Nov 20 04:30:10 2018 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 A7E07130DFE for ; Tue, 20 Nov 2018 04:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Kh8jN_i7pgC0 for ; Tue, 20 Nov 2018 04:30:04 -0800 (PST) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 03C3C130DFA for ; Tue, 20 Nov 2018 04:30:04 -0800 (PST) Received: by mail-ot1-x343.google.com with SMTP id u3so1477053ota.5 for ; Tue, 20 Nov 2018 04:30: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; bh=YBxSP9pWciq1cwYCk9Z8Rk5XHVy62mKGcxmymwlXvZ8=; b=vCJ3oA/T/pbgqdTvucZVeY3hoqTL24DcCrUe9GwtdYb30L9ZKorwwuBFZ+mFZEDqFs jLXM+9QiEUUgJJ8HGyNCUOJkRAk9tsD29FJnB/R5rYMNIXkz46wFolE56uQ04xcyyQ+Y 2boA8cSDGmLv0GLdesib4J0hgWNdBtPlzhYHjHm9IS5d+kQbh6YcGaC+nHgHUuHq8ozO KtBxzH+8+dXOjKgpD5sZEvB7LyfcYcVupwWrhjrN6vesl+Kvw5l0bFgEJ9wFE2OoLTwe Wny/w+NPe2lVt2+PI1jY1XLmQi7D0m50PPpPXQQ5J8f59gCO6RD3VolwwnCotFfqI+pi wSaQ== 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=YBxSP9pWciq1cwYCk9Z8Rk5XHVy62mKGcxmymwlXvZ8=; b=jNnj4hq9Xzdt3IwOpqtBDoXAGBfufJQmyEQ6UBIfcEmXQNthofV4QGrSXvMdB1+4F6 BzYnD3D5994tvleT2RSUejMoMLiTQp8UemOFbwHC7VLFG6tXhWhldTiyVhs50eNkiPER +q3rbnP0E6X75VmU8VSv9WG1UPk2WOq+XElKJN3wsEYylwKeOp4Ca7pMhzDdJLY68Zjc ZpWsTXQ62kODZU+wUQcohQL+maphv44bzJuAmN2pkWFEyiPbOc8xXJZxenujM2FkAnAo XPrS8oxJHXztAnRSeHaeGg1EhbnJwGYQ0Yf2Px+bOrYUtx/mWbMnfEbmKqT7+qhkTdaF DpJQ== X-Gm-Message-State: AA+aEWYtwMxglkRs3oEqSq61T/MIx8trOKne9ICQvbz+Kj/L6d4sWTg9 bj7Y7MAJ8Vmw/avv+eddJnOZNevucS1qZDMx43kgeecW X-Google-Smtp-Source: AFSGD/XRcYo3uezNLOjKO3/0B+Ingt38s08shEAXipx5F/pwk5i2O469b/D9dyNqCESUodqv4/Hs2WE2Q5YsZByPCUE= X-Received: by 2002:a9d:48b7:: with SMTP id d52mr1125466otf.354.1542717002567; Tue, 20 Nov 2018 04:30:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Adam Cashion Date: Tue, 20 Nov 2018 06:29:09 -0600 Message-ID: To: oauth , Adam Cashion Content-Type: multipart/alternative; boundary="000000000000ed569b057b17ca8d" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 121, Issue 43 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, 20 Nov 2018 12:30:09 -0000 --000000000000ed569b057b17ca8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2018, 6:25 AM Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: draft-parecki-oauth-browser-based-apps-00 (Aaron Parecki) > 2. Re: OAuth Security Topics -- Recommend authorization code > instead of implicit (Torsten Lodderstedt) > 3. Dynamic Client Registration - client_secret_expires_at > (Filip Skokan) > 4. Re: OAuth Security Topics -- Recommend authorization code > instead of implicit (Neil Madden) > > > > ---------- Forwarded message ---------- > From: Aaron Parecki > To: OAuth WG > Cc: > Bcc: > Date: Mon, 19 Nov 2018 18:09:03 -0800 > Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan wrote: > > >> It may be worth slightly rewording 7..2 as it may encourage a growing >> misconception that all native apps must be public clients. With many >> devices now having embedded HSMs, we=E2=80=99ve seen increasing interest= in mobile >> apps being dynamically (per-install) registered oauth2 private clients, = and >> that model has a lot of advantages. (I=E2=80=99m not sure if we might se= e a similar >> model evolving for web apps.) >> > > That's a great point, thanks. I've removed the reference to native apps > being public clients since it doesn't really add anything to this spec if= I > have to caveat the description. > > On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > First of all the AS decides whether it issues refresh tokens or not. >> Having the ability does not mean the AS must do it. If you feel it=E2=80= =99s safer >> to not do it. Fine. >> > Sure, and this should be mentioned then somewhere (either in the >> threats doc or in this proposed best practice doc). Not all end develope= rs >> using these protocols fully understand the ramifications. >> @Aaron: I suggest this goes to the SPA BCP since this is client specific= . > > > Thanks, I agree that this document should include some recommendations > around refresh token handling. Looking at the discussion in this thread, = it > seems there are a few different strategies folks are taking. Since it see= ms > like there isn't a strong consensus, it sounds like this would be better > suited for the "Security Considerations" section, and to not make > MUST/SHOULD recommendations, but rather just point out the issues. Any > thoughts on that before I take a stab at writing something? > > I've incorporated some of the other feedback here and published an update= d > version: > > https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01 > > Thanks for the feedback so far. > > --- > Aaron Parecki > https://aaronparecki.com > > > > ---------- Forwarded message ---------- > From: Torsten Lodderstedt > To: Mike Jones > Cc: Hannes Tschofenig , oauth > Bcc: > Date: Tue, 20 Nov 2018 08:35:17 +0100 > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > Hi Mike, > > I agree that OIDC hybrid flows offer additional security over the OAuth > implicit grant and are used in the wild. On my slides and in the initial > version of the new section, we had included the hybrid OIDC flows because > of their known token injection countermeasures. > > I nevertheless feel very uncomfortable to recommend those flows and any > flow issuing access tokens in the front channel. In the course of the > detailed review of the new text we realized two issues: > > 1) Since the access token is exposed in the URL, such flows possess a > significantly higher risk to leak the access token (e.g. through browser > history, open redirection and even referrer headers) than the code grant. > 2) There is no viable way to sender constrain access tokens issued in the > front channel. Given the WG decided to recommend use of sender constraint > tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2), > it seems contradictory to recommend response types not supporting such an > approach. > > kind regards, > Torsten. > > > Am 19.11.2018 um 23:13 schrieb Mike Jones 40microsoft.com@dmarc.ietf.org>: > > > > This description of the situation is an oversimplification. OpenID > Connect secures the implicit flow against token injection attacks by > including the at_hash (access token hash) in the ID Token, enabling the > client to validate that the access token was created by the issuer in the > ID Token (which is also the OAuth Issuer, as described in RFC 8414). (No= te > that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.= ) > > > > Given the prevalence of this known-good solution for securing the > implicit flow, I would request that the draft be updated to describe this > mitigation. At the same time, I=E2=80=99m fine with the draft recommendi= ng the > code flow over the implicit flow when this mitigation is not used. > > > > Thank > you, > > -- Mike > > > > From: OAuth On Behalf Of Hannes Tschofenig > > Sent: Monday, November 19, 2018 2:34 AM > > To: oauth > > Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > > > > Hi all, > > > > The authors of the OAuth Security Topics draft came to the conclusion > that it is not possible to adequately secure the implicit flow against > token injection since potential solutions like token binding or JARM are = in > an early stage of adoption. For this reason, and since CORS allows > browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (seehttps:// > datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-i= etf-oauth-security-topics-01 > ). > > > > A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. > > > > Please provide a response by December 3rd. > > > > Ciao > > Hannes & Rifaat > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > ---------- Forwarded message ---------- > From: Filip Skokan > To: oauth > Cc: > Bcc: > Date: Tue, 20 Nov 2018 12:44:50 +0100 > Subject: [OAUTH-WG] Dynamic Client Registration - client_secret_expires_a= t > Hi all, > > a recent query about expiring client credentials (secrets) got me thinkin= g > about client_secret_expires_at client metadata from RFC 7591 used also in > 7592 as well as OpenID Connect Dynamic Client Registration 1.0 > > *What does expired client secret (in the sense of client_secret_expires_a= t > with a non 0 value) mean beyond obviously not processing secret-based > client authentication (basic, post and client_secret_jwt) after the given > timestamp?* *Fingers Crossed* I'm hoping for your comments and experience > from existing deployments on the topic to shed some light on this for me > and maybe others too. Also that this doesn't get lost between the current > BCP/implicit discussions. > > This is my best shot at an implementable policy when it comes to clients > with expired client secrets: *"all operations requiring a secret will be > rejected when an expired one is presented"* > > - it is not valid for client secret based endpoint auth (basic, post, > client secret jwt), the AS will reject with 401 invalid_client in thos= e > cases > - it will not be used for validating symmetrically signed request > object (JAR), the AS will reject the authorization request with ...? > - it will not be used by the AS to symmetrically sign id tokens, > userinfo, introspection or authorization responses (JARM), the AS will > reject the requests with ...? > - anything else? > > > > I feel this is reasonable interpretation and if so, are there appropriate > errors to return to clients (both front and back-channel) when an expired > secret is encountered during one of the operations that need it? > > Thank you very much for your thoughts and comments. > > Best, > Filip > > > > ---------- Forwarded message ---------- > From: Neil Madden > To: Torsten Lodderstedt > Cc: Mike Jones , oauth < > oauth@ietf.org> > Bcc: > Date: Tue, 20 Nov 2018 12:24:55 +0000 > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > I think the draft should elaborate more on what it means by =E2=80=9Ctoke= n replay=E2=80=9D > in section 2.2 and how the proposal to use sender-constrained tokens > prevents it. As far as I can tell, of the 4 methods presented in section > 3.8.1.2, only jpop signed requests actually includes any specific > countermeasure for replay (in the form of negotiated nonces). > > If we are discussing this in the context of client-side web apps/SPAs, > then surely the threat model includes malicious 3rd party scripts - for > which neither token binding nor mTLS constrained tokens are very effectiv= e > as those scripts run in the same TLS context as the legitimate client? > > =E2=80=94 Neil > > > On 20 Nov 2018, at 07:35, Torsten Lodderstedt > wrote: > > > > Hi Mike, > > > > I agree that OIDC hybrid flows offer additional security over the OAuth > implicit grant and are used in the wild. On my slides and in the initial > version of the new section, we had included the hybrid OIDC flows because > of their known token injection countermeasures. > > > > I nevertheless feel very uncomfortable to recommend those flows and any > flow issuing access tokens in the front channel. In the course of the > detailed review of the new text we realized two issues: > > > > 1) Since the access token is exposed in the URL, such flows possess a > significantly higher risk to leak the access token (e.g. through browser > history, open redirection and even referrer headers) than the code grant. > > 2) There is no viable way to sender constrain access tokens issued in > the front channel. Given the WG decided to recommend use of sender > constraint tokens ( > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2= ..2), > it seems contradictory to recommend response types not supporting such an > approach. > > > > kind regards, > > Torsten. > > > >> Am 19.11.2018 um 23:13 schrieb Mike Jones 40microsoft.com@dmarc.ietf.org>: > >> > >> This description of the situation is an oversimplification. OpenID > Connect secures the implicit flow against token injection attacks by > including the at_hash (access token hash) in the ID Token, enabling the > client to validate that the access token was created by the issuer in the > ID Token (which is also the OAuth Issuer, as described in RFC 8414). (No= te > that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.= ) > >> > >> Given the prevalence of this known-good solution for securing the > implicit flow, I would request that the draft be updated to describe this > mitigation. At the same time, I=E2=80=99m fine with the draft recommendi= ng the > code flow over the implicit flow when this mitigation is not used. > >> > >> Thank > you, > >> -- Mike > >> > >> From: OAuth On Behalf Of Hannes Tschofenig > >> Sent: Monday, November 19, 2018 2:34 AM > >> To: oauth > >> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > >> > >> Hi all, > >> > >> The authors of the OAuth Security Topics draft came to the conclusion > that it is not possible to adequately secure the implicit flow against > token injection since potential solutions like token binding or JARM are = in > an early stage of adoption. For this reason, and since CORS allows > browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (seehttps:// > datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-i= etf-oauth-security-topics-01 > ). > >> > >> A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. > >> > >> Please provide a response by December 3rd. > >> > >> Ciao > >> Hannes & Rifaat > >> > >> IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ed569b057b17ca8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On = Tue, Nov 20, 2018, 6:25 AM <o= auth-request@ietf.org wrote:
Se= nd OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
Today's Topics:

=C2=A0 =C2=A01. Re: draft-parecki-oauth-browser-based-apps-00 (Aaron Pareck= i)
=C2=A0 =C2=A02. Re: OAuth Security Topics -- Recommend authorization code =C2=A0 =C2=A0 =C2=A0 instead of implicit (Torsten Lodderstedt)
=C2=A0 =C2=A03. Dynamic Client Registration - client_secret_expires_at
=C2=A0 =C2=A0 =C2=A0 (Filip Skokan)
=C2=A0 =C2=A04. Re: OAuth Security Topics -- Recommend authorization code =C2=A0 =C2=A0 =C2=A0 instead of implicit (Neil Madden)



---------- Forwarded message ----------
From:=C2=A0Aaron Par= ecki <aaron@parecki.com>
To:=C2=A0OAuth WG <oauth@ietf.org&g= t;
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Mon, 19 Nov 2018 18:09:03 -0800=
Subject:=C2=A0Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00<= br>
On Wed, Nov 7, 2018 at 7:20 AM Jose= ph Heenan <joseph@authlete.com> wrote:
=C2=A0
It may be wor= th slightly rewording 7..2 as it may encourage a growing misconception that= all native apps must be public clients. With many devices now having embed= ded HSMs, we=E2=80=99ve seen increasing interest in mobile apps being dynam= ically (per-install) registered oauth2 private clients, and that model has = a lot of advantages. (I=E2=80=99m not sure if we might see a similar model = evolving for web apps.)=C2=A0

T= hat's a great point, thanks. I've removed the reference to native a= pps being public clients since it doesn't really add anything to this s= pec if I have to caveat the description.

On Thu, N= ov 15, 2018 at 12:58 PM Torsten Lodderstedt <torsten@lodderstedt.ne= t> wrote:

> > First of all the AS decides whether it issue= s refresh tokens or not. Having the ability does not mean the AS must do it= . If you feel it=E2=80=99s safer to not do it. Fine.=C2=A0
> Sure, an= d this should be mentioned then somewhere (either in the threats doc or in = this proposed best practice doc). Not all end developers using these protoc= ols fully understand the ramifications.=C2=A0
@Aaron: I suggest this goe= s to the SPA BCP since this is client specific.

=
Thanks, I agree that this document should include some recommend= ations around refresh token handling. Looking at the discussion in this thr= ead, it seems there are a few different strategies folks are taking. Since = it seems like there isn't a strong consensus, it sounds like this would= be better suited for the "Security Considerations" section, and = to not make MUST/SHOULD recommendations, but rather just point out the issu= es. Any thoughts on that before I take a stab at writing something?

I've incorporated some of the other feedback here and= published an updated version:


Thanks for the feedbac= k so far.

---
Aaron Parecki
htt= ps://aaronparecki.com



---------- Forwarded message ----------
From:=C2=A0Torsten L= odderstedt <torsten@lodderstedt.net>
To:=C2=A0Mike Jones = <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
C= c:=C2=A0Hannes Tschofenig <Hannes.Tschofenig@arm.com>, oau= th <oauth@ietf.org>
Bcc:=C2=A0
Date:=C2=A0Tue, 20 Nov 2018 08:3= 5:17 +0100
Subject:=C2=A0Re: [OAUTH-WG] OAuth Security Topics -- Recomme= nd authorization code instead of implicit
Hi Mike,

I agree that OIDC hybrid flows offer additional security over the OAuth imp= licit grant and are used in the wild. On my slides and in the initial versi= on of the new section, we had included the hybrid OIDC flows because of the= ir known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any flo= w issuing access tokens in the front channel. In the course of the detailed= review of the new text we realized two issues:

1) Since the access token is exposed in the URL, such flows possess a signi= ficantly higher risk to leak the access token (e.g. through browser history= , open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the f= ront channel. Given the WG decided to recommend use of sender constraint to= kens (https:/= /tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2),= it seems contradictory to recommend response types not supporting such an = approach.

kind regards,
Torsten.

> Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:
>
> This description of the situation is an oversimplification.=C2=A0 Open= ID Connect secures the implicit flow against token injection attacks by inc= luding the at_hash (access token hash) in the ID Token, enabling the client= to validate that the access token was created by the issuer in the ID Toke= n (which is also the OAuth Issuer, as described in RFC 8414).=C2=A0 (Note t= hat this mitigation was described in draft-ietf-oauth-mix-up-mitigation.) >=C2=A0
> Given the prevalence of this known-good solution for securing the impl= icit flow, I would request that the draft be updated to describe this mitig= ation.=C2=A0 At the same time, I=E2=80=99m fine with the draft recommending= the code flow over the implicit flow when this mitigation is not used.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Thank you,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0-- Mike
>=C2=A0
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes= Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth <oauth@ietf.org>
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization c= ode instead of implicit
>=C2=A0
> Hi all,
>=C2=A0
> The authors of the OAuth Security Topics draft came to the conclusion = that it is not possible to adequately secure the implicit flow against toke= n injection since potential solutions like token binding or JARM are in an = early stage of adoption. For this reason, and since CORS allows browser-bas= ed apps to send requests to the token endpoint, Torsten suggested to use th= e authorization code instead of the implicit grant in call cases in his pre= sentation (seehttps://datatracker.ietf.org/meeting/103/m= aterials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01). >=C2=A0
> A hum in the room at IETF#103 concluded strong support for his recomme= ndations. We would like to confirm the discussion on the list.
>=C2=A0
> Please provide a response by December 3rd.
>=C2=A0
> Ciao
> Hannes & Rifaat
>=C2=A0
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oau= th




---------- Forwarded message ----------
From:=C2=A0Filip Sko= kan <panva.ip@gmail.com>
To:=C2=A0oauth <oauth@ietf.org>=
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Tue, 20 Nov 2018 12:44:50 +0100Subject:=C2=A0[OAUTH-WG] Dynamic Client Registration - client_secret_expi= res_at
Hi all,

a recent query about expiring client credentials (secrets)= got me thinking about client_secret_expires_at client metadata from=C2=A0R= FC 7591 used also in 7592 as well as=C2=A0OpenID Connect Dynamic Client Reg= istration 1.0

What does expired client secret (= in the sense of client_secret_expires_at with a non 0 value) mean beyond ob= viously not processing secret-based client authentication (basic, post and = client_secret_jwt) after the given timestamp?=C2=A0*Fingers Crossed* I&= #39;m hoping for your comments and experience from existing deployments on = the topic to shed some light on this for me and maybe others too. Also that= this doesn't get lost between the current BCP/implicit discussions.

This is my best shot at an implementable policy when= it comes to clients with expired client secrets: "all operations r= equiring a secret will be rejected when an expired one is presented"
  • it is not valid for client secret based endpoint auth = (basic, post, client secret jwt), the AS will reject with 401 invalid_clien= t in those cases
  • it will not be used for validating symmetrical= ly signed request object (JAR), the AS will reject the authorization reques= t with ...?
  • it will not be used by the AS to symmetrically sign= id tokens, userinfo, introspection or authorization responses (JARM), the = AS will reject the requests with=C2=A0...?
  • anything else?
    • <= /ul>
      I feel this is reasonable interpretation and if so, are t= here appropriate errors to return to clients (both front and back-channel) = when an expired secret is encountered during one of the operations that nee= d it?

    Thank you very much for your thoughts = and comments.

    Best,
    Filip



    ---------- Forwarded message ----------
    From:=C2=A0Neil Madd= en <neil.madden@forgerock.com>
    To:=C2=A0Torsten Lodde= rstedt <torsten@lodderstedt.net>
    Cc:=C2=A0Mike Jones <= Michael.Jones=3D40microsoft.com@dmarc.ietf.org>, oauth &= lt;o= auth@ietf.org>
    Bcc:=C2=A0
    Date:=C2=A0Tue, 20 Nov 2018 12:24:55= +0000
    Subject:=C2=A0Re: [OAUTH-WG] OAuth Security Topics -- Recommend a= uthorization code instead of implicit
    I think the draft should elaborate= more on what it means by =E2=80=9Ctoken replay=E2=80=9D in section 2.2 and= how the proposal to use sender-constrained tokens prevents it. As far as I= can tell, of the 4 methods presented in section 3.8.1.2, only jpop signed = requests actually includes any specific countermeasure for replay (in the f= orm of negotiated nonces).

    If we are discussing this in the context of client-side web apps/SPAs, then= surely the threat model includes malicious 3rd party scripts - for which n= either token binding nor mTLS constrained tokens are very effective as thos= e scripts run in the same TLS context as the legitimate client?

    =E2=80=94 Neil

    > On 20 Nov 2018, at 07:35, Torsten Lodderstedt <torsten@lodders= tedt.net> wrote:
    >
    > Hi Mike,
    >
    > I agree that OIDC hybrid flows offer additional security over the OAut= h implicit grant and are used in the wild. On my slides and in the initial = version of the new section, we had included the hybrid OIDC flows because o= f their known token injection countermeasures.
    >
    > I nevertheless feel very uncomfortable to recommend those flows and an= y flow issuing access tokens in the front channel. In the course of the det= ailed review of the new text we realized two issues:
    >
    > 1) Since the access token is exposed in the URL, such flows possess a = significantly higher risk to leak the access token (e.g. through browser hi= story, open redirection and even referrer headers) than the code grant.
    > 2) There is no viable way to sender constrain access tokens issued in = the front channel. Given the WG decided to recommend use of sender constrai= nt tokens (ht= tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2<= /a>), it seems contradictory to recommend response types not supporting suc= h an approach.
    >
    > kind regards,
    > Torsten.
    >
    >> Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=3D    40microsoft.com@dmarc.ietf.org>:
    >>
    >> This description of the situation is an oversimplification.=C2=A0 = OpenID Connect secures the implicit flow against token injection attacks by= including the at_hash (access token hash) in the ID Token, enabling the cl= ient to validate that the access token was created by the issuer in the ID = Token (which is also the OAuth Issuer, as described in RFC 8414).=C2=A0 (No= te that this mitigation was described in draft-ietf-oauth-mix-up-mitigation= .)
    >>
    >> Given the prevalence of this known-good solution for securing the = implicit flow, I would request that the draft be updated to describe this m= itigation.=C2=A0 At the same time, I=E2=80=99m fine with the draft recommen= ding the code flow over the implicit flow when this mitigation is not used.=
    >>
    >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Thank you,
    >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -- Mike
    >>
    >> From: OAuth <oauth-bounces@ietf.org> On Behalf Of = Hannes Tschofenig
    >> Sent: Monday, November 19, 2018 2:34 AM
    >> To: oauth <oauth@ietf.org>
    >> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorizati= on code instead of implicit
    >>
    >> Hi all,
    >>
    >> The authors of the OAuth Security Topics draft came to the conclus= ion that it is not possible to adequately secure the implicit flow against = token injection since potential solutions like token binding or JARM are in= an early stage of adoption. For this reason, and since CORS allows browser= -based apps to send requests to the token endpoint, Torsten suggested to us= e the authorization code instead of the implicit grant in call cases in his= presentation (seehttps://datatracker.ietf.org/meeting/1= 03/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01= ).
    >>
    >> A hum in the room at IETF#103 concluded strong support for his rec= ommendations. We would like to confirm the discussion on the list.
    >>
    >> Please provide a response by December 3rd.
    >>
    >> Ciao
    >> Hannes & Rifaat
    >>
    >> IMPORTANT NOTICE: The contents of this email and any attachments a= re confidential and may also be privileged. If you are not the intended rec= ipient, please notify the sender immediately and do not disclose the conten= ts to any other person, use it for any purpose, or store or copy the inform= ation in any medium. Thank you.
    >> _______________________________________________
    >> OAuth mailing list
    >> OAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo= /oauth
    >
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oau= th


    _______________________________________________
    OAuth mailing list
    OAut= h@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --000000000000ed569b057b17ca8d-- From nobody Tue Nov 20 07:47:35 2018 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 BAAC0129C6A for ; Tue, 20 Nov 2018 07:47:34 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 14jQoM1R9Ope for ; Tue, 20 Nov 2018 07:47:32 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 16A45123FFD for ; Tue, 20 Nov 2018 07:47:32 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id e5so469592qtr.12 for ; Tue, 20 Nov 2018 07:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Hi/VvKJnpGMFSvhKsK/171zRDV9+bfLPlbqxTjzq/MM=; b=TKlcjL03NN9VqAonqstN4zRXbZIxbj495X8ONU0ZvM02M7L0ok56yWD43QahUUzhMO FB/zYBtrs9ZNPkjqsHpPY8Hs/z3WoknACXtqNR1nvIDIo/89hIWlZSHJgJ21m52AJsNs 0FssNIEGGT11FU6VS6aDAF9jZcAPG6Iw4+3PBDrqBGT/bdyKkUp1DcOTWh6B3bWdq8vn 04t3r34ESZhDTy2mCjPm2qycUhSJpbIaVXhTWIAjtfJgVl61pU7QAsP/aKaNo2D8D5Jd 4CVNfes19dS8vSr6XCR7iX1aaHvPkHtc61X9NMGdWB5wZLrHnOWGtbQeyJgfXG1iEW3u vDXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Hi/VvKJnpGMFSvhKsK/171zRDV9+bfLPlbqxTjzq/MM=; b=kZdJMjnUfuf4+Rl71EZtzmgJjhlHv+dmP4GvIjcOx59IUKCDEcx46t5yp4Wp6zoN82 Cs7zOvnDWTQWUH/E8wmwnIK/yA8IeL7W0QOclqtkq7dDE808XllwKH2x4r8PsWQTZrIP tqvms2pLxeur07jg+lSfZ76yAJ8Xt8oHL+1C0mYqwDZYQB32XSkzGyjxMW+eGQkdKQ9f eaaYD248Ci4ZTUSRtJnK/nP0ZzR40NNif+nFaBI9esH44sl8XvG9hj/W5/d0TquSXi6U l2nz7FR53tIaBOKdipS6xRdvXS4Q7qpwdwWy7h99kzlzt18R2w/kHjHD4fIFVqJTw45M 1HpQ== X-Gm-Message-State: AA+aEWbmBdB5m5zq9gPLtMO8ySWNG4PmlyacZRmL6zN+raftA9tjT3c9 GIjgOCUh9zqVLnWaIMFfZMQYmFZAi4i7rxCc X-Google-Smtp-Source: AFSGD/XKcEoblglUlturmOBNa+1yQhHT0snc/Nsi+dvz11EgSODW3ghjKj4LBIQOl7sTOhapcwzIWQ== X-Received: by 2002:a0c:88a8:: with SMTP id 37mr2277925qvn.63.1542728850215; Tue, 20 Nov 2018 07:47:30 -0800 (PST) Received: from [192.168.86.49] ([191.115.150.242]) by smtp.gmail.com with ESMTPSA id 5sm20222641qkv.93.2018.11.20.07.47.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 07:47:29 -0800 (PST) From: John Bradley X-Google-Original-From: John Bradley To: oauth@ietf.org References: <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> Message-ID: <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com> Date: Tue, 20 Nov 2018 12:47:22 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------B63AEA4C87295795DF5DE00A" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit 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, 20 Nov 2018 15:47:35 -0000 This is a multi-part message in MIME format. --------------B63AEA4C87295795DF5DE00A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes the at_hash protects the client from accepting an injected AT. Unfortunately it doesn't do anything to protect against leakage in logs or redirects. So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice. John B. On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote: > Hi Mike, > > I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures. > > I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues: > > 1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant. > 2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach. > > kind regards, > Torsten. > >> Am 19.11.2018 um 23:13 schrieb Mike Jones : >> >> This description of the situation is an oversimplification. OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414). (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.) >> >> Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation. At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used. >> >> Thank you, >> -- Mike >> >> From: OAuth On Behalf Of Hannes Tschofenig >> Sent: Monday, November 19, 2018 2:34 AM >> To: oauth >> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit >> >> Hi all, >> >> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01). >> >> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list. >> >> Please provide a response by December 3rd. >> >> Ciao >> Hannes & Rifaat >> >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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. >> _______________________________________________ >> 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 --------------B63AEA4C87295795DF5DE00A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Yes the at_hash protects the client from accepting an injected AT. 

    Unfortunately it doesn't do anything to protect against leakage in logs or redirects.

    So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice.

    John B.

    On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
    Hi Mike, 

I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues: 

1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach. 

kind regards,
Torsten. 


    Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:

This description of the situation is an oversimplification.  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
 
Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
 
                                                                Thank you,
                                                                -- Mike
 
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
 
Hi all,
 
The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
 
A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
 
Please provide a response by December 3rd.
 
Ciao
Hannes & Rifaat
 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
_______________________________________________
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

    
    
    
  


--------------B63AEA4C87295795DF5DE00A--


From nobody Tue Nov 20 11:27:06 2018
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 3159E12785F; Tue, 20 Nov 2018 11:26:58 -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: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <154274201815.29841.1388851667499826707@ietfa.amsl.com>
Date: Tue, 20 Nov 2018 11:26:58 -0800
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2018 19:26:58 -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 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-10.txt
	Pages           : 38
	Date            : 2018-11-20

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10


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 Tue Nov 20 11:33:04 2018
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 A6BD8130E5B for ; Tue, 20 Nov 2018 11:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 mSH7RaSZFpC2 for ; Tue, 20 Nov 2018 11:32:53 -0800 (PST)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.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 A5F10130E8F for ; Tue, 20 Nov 2018 11:32:53 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gPBlT-0000Gy-48 for oauth@ietf.org; Tue, 20 Nov 2018 20:32:51 +0100
From: Torsten Lodderstedt 
Content-Type: multipart/signed; boundary="Apple-Mail=_48965DE1-D9D4-4E78-A4C5-44601E76ED70"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 20 Nov 2018 20:32:50 +0100
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>
To: oauth 
In-Reply-To: <154274201815.29841.1388851667499826707@ietfa.amsl.com>
Message-Id: 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 20 Nov 2018 19:33:03 -0000

--Apple-Mail=_48965DE1-D9D4-4E78-A4C5-44601E76ED70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,=20

the new revision contains the following changes:

* added section on refresh tokens=20
* additional justifications for recommendation for code
* refactored 2.1 in order to distinguish CSRF, authz response replay and =
mix-up (based on feedback by Joseph Heenan)
* added requirement to authenticate clients during code exchange (PKCE =
or client credential) to 2.1.1.
* changed occurrences of SHALL to MUST

As always: looking forward for your feedback.

kind regards,
Torsten.=20

> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Web Authorization Protocol WG of the =
IETF.
>=20
>        Title           : OAuth 2.0 Security Best Current Practice
>        Authors         : Torsten Lodderstedt
>                          John Bradley
>                          Andrey Labunets
>                          Daniel Fett
> 	Filename        : draft-ietf-oauth-security-topics-10.txt
> 	Pages           : 38
> 	Date            : 2018-11-20
>=20
> Abstract:
>   This document describes best current security practice for OAuth =
2.0.
>   It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and covers new threats relevant due to the broader
>   application of OAuth 2.0.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_48965DE1-D9D4-4E78-A4C5-44601E76ED70
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjAxOTMyNTBaMC8GCSqGSIb3DQEJBDEiBCBw
Yjr7vsLsOJf9LUAMOA1TVLdy038YIRqGqajAVWmmyjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEASs42ztvXBn+rXcGXk5VeKNJi
Ob4J/R6DVIcgH045RsvMlzn7yY3jeJaVH3LGd1Z0ZrUXNN02OipBE3dQtCdcwDDRTYs/TBKEi4q5
jV3YrF0R+bGV90fAtaOUI8LMuNH6ySBuzFUL+o5GD0pgAxcYQPBM+z5bChoUBPoVeaZc8JcFjf7i
tt2HEGeYohE452zT2xeHc4ywKQyGYBKctzbFQg8hXULDrakC18HUxHggErzxgc+6vG5sNhRTFa42
LfPnGRs1W4hzyyouAWOVu7sP0L08D2QWXY6wLj/GFpw4qZxw5TathfW0SqCKFpMoqD8Q6tJ5ZnU0
k6Yl9yH1KPRBXQAAAAAAAA==
--Apple-Mail=_48965DE1-D9D4-4E78-A4C5-44601E76ED70--


From nobody Tue Nov 20 11:36:47 2018
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 B6DA712F295 for ; Tue, 20 Nov 2018 11:36:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 57VAlzSl1PIV for ; Tue, 20 Nov 2018 11:36:43 -0800 (PST)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 919C812785F for ; Tue, 20 Nov 2018 11:36:43 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gPBpA-0006yR-O1; Tue, 20 Nov 2018 20:36:40 +0100
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_201B2D9F-435B-4EA0-BAC7-B08E54EE90FE"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 20 Nov 2018 20:36:39 +0100
In-Reply-To: 
Cc: oauth 
To: Brian Campbell 
References: 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Token Binding & implicit
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, 20 Nov 2018 19:36:46 -0000

--Apple-Mail=_201B2D9F-435B-4EA0-BAC7-B08E54EE90FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I opt for (4) - Remove support/description of binding of access tokens =
issued from the authorization endpoint=20

I think the potential solution we worked out (slide 6) is to complex and =
the security implications of the redirect via the resource servers are =
still unclear.

> Am 18.11.2018 um 13:32 schrieb Brian Campbell =
:
>=20
> During the first OAuth session in Bangkok the question "what to do =
about token binding & implicit?" was raised. There was some discussion =
but session time was limited and we had to move on before any real =
consensus was reached.=20
>=20
> So I thought I'd bring the question to the WG list to generate some =
more discussion on the issue. It's also related, at least in part, to a =
couple of the other ongoing threads on the list about browser based apps =
and security practices.=20
>=20
> The slides from the session are linked below. Slides 5 & 6 try and =
explain the awkwardness of doing Token Binding with implicit. While =
slide 7 lays out some (not very good) options for how to proceed.
> =
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-=
draft-ietf-oauth-token-binding-00
>=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=_201B2D9F-435B-4EA0-BAC7-B08E54EE90FE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjAxOTM2NDBaMC8GCSqGSIb3DQEJBDEiBCB1
p1wu3/Z5EQ12+ZV4nMDYDpDYYIdlPiWj0g7vqRhyXDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAgmBphWdCKOfDzMONxI8klJcY
cIa+KyAAheEaILuGvpfgKSkYOTgZZy7FcrCpZJBn8MOdeIEDGlO0XQYlU6hooGyVDNS9JFiuAOrD
0ocVm28Dzwr44Who2M+crWON0RAim/5QDcYwufQOX8N9t8fzqadCrk1JSmgi400eI3Jb9PrwsnLZ
He6Dcjng+n6NJzZTtLtqtCIaqaHAMNIs4QuyrXsj78chKDxFz5ToZY/054HhlQpYJVUF9OJm+m6z
Qic75GaTGmfJeEWGuX0CmPnbz1c0mSDYiWT35CGXvfTgj2x5p8gS1JEZ2xWUqfm3ZIjtiDiHQzc3
zKhHB3WVlCWrZQAAAAAAAA==
--Apple-Mail=_201B2D9F-435B-4EA0-BAC7-B08E54EE90FE--


From nobody Tue Nov 20 11:39:23 2018
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 488BD130DCF for ; Tue, 20 Nov 2018 11:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 jVwQTGMYImtP for ; Tue, 20 Nov 2018 11:39:20 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D4312D4E9 for ; Tue, 20 Nov 2018 11:39:19 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gPBrh-0005Fc-D0; Tue, 20 Nov 2018 20:39:17 +0100
From: Torsten Lodderstedt 
Message-Id: <2740EE7E-0290-400C-80DE-746C7BC1240C@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_262CA8AE-620A-4613-B079-E62645B1B011"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 20 Nov 2018 20:39:16 +0100
In-Reply-To: 
Cc: Hans Zandbelt , "oauth@ietf.org" 
To: Jim Manico 
References:   <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com>  <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com>  
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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, 20 Nov 2018 19:39:22 -0000

--Apple-Mail=_262CA8AE-620A-4613-B079-E62645B1B011
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,=20

please find some thoughts about refresh token protection in the new =
revision of the Security BCP =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.=
12

Feedback welcome!

kind regards,
Torsten.=20

> Am 19.11.2018 um 11:33 schrieb Jim Manico :
>=20
> I want to +1 this as well. This really got my attention as an =
impressive and straightforward defense technique.
>=20
> Jim
>=20
>=20
> On Nov 19, 2018, at 3:48 PM, Hans Zandbelt =
 wrote:
>=20
>> +1 to the suggestions that Vladimir raises; I've seen a fair number =
of requests  in the field for exactly that
>>=20
>> Hans.
>>=20
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov =
 wrote:
>> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>>> To start with, the AS may use refresh token rotation in combination =
with automatic revocation in case of detected replay attempts.=20
>>>=20
>>> How does it work? The AS issues a new refresh token with every =
refresh and invalidate the old one. This restricts the lifetime of a =
refresh token. If someone (might be the legit client or an attacker) =
submits one of the older, invalidated refresh token, the AS might =
interpret this as a signal indicating token leakage and revoke the valid =
refresh token as well. We used this technique at Deutsche Telekom since =
our first OAuth 2.0 implementation back in 2012.
>>>=20
>> This is a clever solution. Did you experience any false positives, =
e.g. due to HTTP response timeouts on slow / poor connections?
>>=20
>> We were also thinking of additionally binding the refresh token to =
the end-user session at the AS / OP:
>>=20
>> 	=E2=80=A2 A valid refresh causing the session to be refreshed =
too
>> 	=E2=80=A2 AS / OP logout or session expiration invalidating the =
refresh token
>>=20
>>=20
>> Vladimir
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> --=20
>> hans.zandbelt@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>> _______________________________________________
>> 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=_262CA8AE-620A-4613-B079-E62645B1B011
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjAxOTM5MTdaMC8GCSqGSIb3DQEJBDEiBCD1
RRRksvXzPVS9XI/Y8Xk7Qe+oH64p3ouAJli+6SiJOjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAdcRL4rUSZZtz7c7e1s1Oj5Fl
rRVBts7DH1zrRKACz8GLQ0+Awhad2UVOq+sP47rEQ+AAS0fnkwDvt8zn3RaXJUcjLS2PRnRBa9Ux
qUhG3Mz3fp3HiUxfpNCRf0/a9thw+y7RBcIvEfrVkjs7vUgFtABzihD29C+G3HmuYiW9dfQTAs6C
P2bA9N2wgfJENZS76XDRDMmYuPMnb+gC9k1QjcAexqY5Hg0+nrvgtRixzs7DmO+FwzhZluxmcPb5
15Y3JRl4GTdMmGnSqDFyoxiFRwkyBgmHOdeTVNKSAMQvaxEy+r+CpyiZtdi2om/6CwxQvzm612a6
R7eTG1/0xL6q8gAAAAAAAA==
--Apple-Mail=_262CA8AE-620A-4613-B079-E62645B1B011--


From nobody Tue Nov 20 11:50:52 2018
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 055F1130DCF; Tue, 20 Nov 2018 11:50:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper 
To: "The IESG" 
Cc: draft-ietf-oauth-token-exchange@ietf.org, Hannes Tschofenig , Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154274344398.29963.11727425335350408375.idtracker@ietfa.amsl.com>
Date: Tue, 20 Nov 2018 11:50:43 -0800
Archived-At: 
Subject: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2018 19:50:44 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 6: The requirements around confidentiality here are weaker than in both
RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?


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

Section 3:

If I understand this correctly:

"The distinction between an access token and a JWT is subtle."

I think it would be clearer if it said:

"The distinction between an access token type and a JWT token type is subtle."

Section 4.1:

What is the value of maintaining the whole delegation chain rather than
expressing just the most recent delegation? Doesn't it potentially expose
information about past exchanges unnecessarily?



From nobody Tue Nov 20 11:53:39 2018
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 16B5E130DCF; Tue, 20 Nov 2018 11:53:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=sAV5tjfy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Wh7CAxI4
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 ccSxXYlEzf0r; Tue, 20 Nov 2018 11:53:28 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A8C130DD2; Tue, 20 Nov 2018 11:53:25 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8A7DF24617; Tue, 20 Nov 2018 14:53:24 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 20 Nov 2018 14:53:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=0FTpxSnA6y63Iu6Snq4ein1 l6A0wxYlArzxrP7ARn9Y=; b=sAV5tjfy37C60DwZ3Dpn+XjpnbBqX+46dWE76bl JAecVPM5I+A3ZjPCduzKmGVPPqm+ZRCTrtQoXemiApBKX9qkf+4dMC/wXTuQwLj8 SY7q/rm9uQqD049dZw/IcbSvT6SKNu2GYFCQgiDfPVosGXR/arUs3LkADX5ujCUC dgKXd+XbJyndApmwwAOdMj5fsg8QskTbrm13JlRoDg3yYRce4AeaSzZrU+H/6qFw cJPagQ1UcwQUmu3SmBI1V/lmkb5TXqaHBwWnx5Fyzd1WzW+sWZ6l8WaYFiIU9Bdx PC5riBq6g8x8xX6M9jCd8DD4MU6hl+j2xzeUl3rGoX8WtCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0FTpxS nA6y63Iu6Snq4ein1l6A0wxYlArzxrP7ARn9Y=; b=Wh7CAxI47q3gK2JPK5AfQR WfYFRV/3tFilJvtnc4Ccv6VKhsj+MhVWYIAV6wloLUYdjNJ0TZXZgr0E+H4aNSio sLvekNrWcjmcQr5wMfcCEmfpLx95sORRt39cURGxDqg4xhhelrGWERNepCPF1yJr t43DHkfKHQPAF3tzTTopDNCl/MtnD8vie2o873AyijIoi6XmuBGUgI+7+hmssnzC yu7+lX//FuJ31ZoYUErnjEtTprAXSYW4mWr4zlhHSJO09jfLsiwBqMXdYex5gGxt 8J2+c0MkVuIj9oSohzLWDZq+BJPA1H472NRGQt86htu0DSpre2eewRy8lSQYi73w ==
X-ME-Sender: 
X-ME-Proxy:      
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 1F375102A0; Tue, 20 Nov 2018 14:53:23 -0500 (EST)
From: Alissa Cooper 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B02D3253-8711-49C6-BFE0-9FBBD5A2CACD"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 20 Nov 2018 14:53:21 -0500
In-Reply-To: 
Cc: General Area Review Team , draft-ietf-oauth-token-exchange.all@ietf.org, oauth 
To: Brian Campbell , Jari Arkko 
References: <153330418307.18499.9986651355808523631@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-token-exchange-14
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, 20 Nov 2018 19:53:30 -0000

--Apple-Mail=_B02D3253-8711-49C6-BFE0-9FBBD5A2CACD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Jari, thanks for your review. Brian, thanks for your response. I flagged =
the issue Jari raises below in my DISCUSS ballot =E2=80=94 it=E2=80=99s =
not clear to me why there aren=E2=80=99t normative requirements around =
confidentiality as there are in the JWT spec and the OAuth 2.0 spec.

Thanks,
Alissa

> On Aug 10, 2018, at 3:49 PM, Brian Campbell =
 wrote:
>=20
> Thanks for the review Jari,
>=20
> Regarding minimizing details, I'm thinking that incorporating some =
text along the lines of what's in the Privacy Considerations of RFC 7523 =
 might be a worthwhile =
addition. =20
>=20
>=20
> On Fri, Aug 3, 2018 at 7:49 AM Jari Arkko > wrote:
> Reviewer: Jari Arkko
> Review result: Ready
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>=20
> For more information, please see the FAQ at
>=20
> >.
>=20
> Document: draft-ietf-oauth-token-exchange-14
> Reviewer: Jari Arkko
> Review Date: 2018-08-03
> IETF LC End Date: 2018-08-06
> IESG Telechat date: Not scheduled for a telechat
>=20
> Summary:
>=20
> This specification describes a standardised protocol for requesting =
and
> receiving security tokens from an OAuth 2.0 authorisation service.
>=20
> I had no experience on OAuth previously, but the document was =
understandable
> and as far as I could determine, had no major issues.
>=20
> It was a bit more difficult to determine completeness.  Security and =
privacy
> considerations sections were quite short, for instance, and maybe =
that's
> justifiable given the ability to refer to prior RFCs on this subject. =
However,
> I suspect one could say more, e.g., Section 7 says "Tokens typically =
carry
> personal information and their usage in Token Exchange may  reveal =
details of
> the target services being accessed", but it does not offer any advice =
on how
> such details might be minimised. But perhaps that's already in another =
RFC as
> well.
>=20
> Major issues:
>=20
> Minor issues:
>=20
> Nits/editorial comments:
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


--Apple-Mail=_B02D3253-8711-49C6-BFE0-9FBBD5A2CACD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Jari,=
 thanks for your review. Brian, thanks for your response. I flagged the =
issue Jari raises below in my DISCUSS ballot =E2=80=94 it=E2=80=99s not =
clear to me why there aren=E2=80=99t normative requirements around =
confidentiality as there are in the JWT spec and the OAuth 2.0 spec.

    Thanks,
    Alissa

    On Aug 10, 2018, at 3:49 PM, =
Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> =
wrote:

    Thanks for the review =
Jari,

    Regarding =
minimizing details, I'm thinking that incorporating some text along the =
lines of what's in the Privacy =
Considerations of RFC 7523 might be a worthwhile addition.  


    On =
Fri, Aug 3, 2018 at 7:49 AM Jari Arkko <jari.arkko@piuha.net> wrote:
    Reviewer: Jari =
Arkko
    
Review result: Ready
    

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

    
For more information, please see the FAQ at
    

    
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
    

    
Document: draft-ietf-oauth-token-exchange-14
    
Reviewer: Jari Arkko
    
Review Date: 2018-08-03
    
IETF LC End Date: 2018-08-06
    
IESG Telechat date: Not scheduled for a telechat
    

    
Summary:
    

    
This specification describes a standardised protocol for requesting =
and
    
receiving security tokens from an OAuth 2.0 authorisation service.
    

    
I had no experience on OAuth previously, but the document was =
understandable
    
and as far as I could determine, had no major issues.
    

    
It was a bit more difficult to determine completeness.  Security =
and privacy
    
considerations sections were quite short, for instance, and maybe =
that's
    
justifiable given the ability to refer to prior RFCs on this subject. =
However,
    
I suspect one could say more, e.g., Section 7 says "Tokens typically =
carry
    
personal information and their usage in Token Exchange may  reveal =
details of
    
the target services being accessed", but it does not offer any advice on =
how
    
such details might be minimised. But perhaps that's already in another =
RFC as
    
well.
    

    
Major issues:
    

    
Minor issues:
    

    
Nits/editorial comments:
    

    

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

    =

--Apple-Mail=_B02D3253-8711-49C6-BFE0-9FBBD5A2CACD--


From nobody Tue Nov 20 12:02:55 2018
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 E6774130E6A for ; Tue, 20 Nov 2018 12:02:46 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOIKUtPgw_Eb for ; Tue, 20 Nov 2018 12:02:43 -0800 (PST)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0: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 D0373130EE1 for ; Tue, 20 Nov 2018 12:02:33 -0800 (PST)
Received: by mail-it1-x132.google.com with SMTP id a185so5323476itc.0 for ; Tue, 20 Nov 2018 12:02:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pmpsPUYvSNsxUFFmmhq4ScKBVKM4dLNA5HHB4DL8FI0=; b=T4UKucBWhc3FjzMxS1Dj6o63V5oSxiQBFKqehzLvroSYNZUdb+NpbHPmm44RHjxPXA zYK34190bUa7NoQI8KDwaTP7JlK6JpsRyaOwAQZGZcXIP8k+AUWbSw10HCEst2Cf9F+f HTBHSWpXQhPFt2FS4tM21dQxBtnUi7G1+LUDBAlEWq3SbpCqj1hR7o4xto5u7HraajJg 6HzXXKRlxFsZi4hrVJkl4LSRwt/vdmt4ZKzrrF00DJg6r1/ewHyWsJcIARPHMW1DXtDO k05sBs4ofaDtEMXg1Pgk4DiUWq78qq6IoiFzcyh4jPfb5S1U1lcKhXIC7rIgbtm7vaTs MyPw==
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=pmpsPUYvSNsxUFFmmhq4ScKBVKM4dLNA5HHB4DL8FI0=; b=oCAr9T+ALZYDx3QL3gY4r9GWVF+U0R+S/vHiPZdgtqFMfuGa1X2TsyN7KU/izSQTds SN5IXlOf/i6RKatZiPB4J3u9iB2ZptwAdOWRlZ30U8JhBGi5uALN6pW1mEPZDYCJYyA4 xBxd3GoxwOflgncpQMDVrRCnysGj4G5cDMOpuY92YzBPZ2dI4zjEs6cZFVMAXa5hZjJY 9jePvUONuGdGN9b6KHdiWEBxBP2z+jE6TnPlhUk7uOmBo4X/B+WdgeJvoTxdRwo9/bmL bMhSeinNlofUTl3kHjUt4fYkdznEsrba60MvZ/rdLzxvUaIwdSwgQnE8vTLd29CrrjaZ jKzg==
X-Gm-Message-State: AGRZ1gI2e3vwAbNGRgCMbGJmvS1w8/c1/NESMHc5l9HssK6PIlg7+Okh i4rXJRdPtd/BAPrLK86YIrZbjqO4QHQ=
X-Google-Smtp-Source: AFSGD/UTyTWf8mwdTQmw4aGuI5eXn1vbnheSRz8w2XWI3RS96eOO+ydTD8HBcjbzYOUwUgz3Ht7Pmw==
X-Received: by 2002:a24:250c:: with SMTP id g12-v6mr3524717itg.169.1542744152846;  Tue, 20 Nov 2018 12:02:32 -0800 (PST)
Received: from mail-it1-f170.google.com (mail-it1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id x191-v6sm16118505itb.3.2018.11.20.12.02.31 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 12:02:31 -0800 (PST)
Received: by mail-it1-f170.google.com with SMTP id o19so5275412itg.5 for ; Tue, 20 Nov 2018 12:02:31 -0800 (PST)
X-Received: by 2002:a24:658a:: with SMTP id u132mr3746617itb.25.1542744151475;  Tue, 20 Nov 2018 12:02:31 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Aaron Parecki 
Date: Tue, 20 Nov 2018 12:02:18 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000020e3b8057b1e1d43"
Archived-At: 
Subject: Re: [OAUTH-WG] Token Binding & implicit
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, 20 Nov 2018 20:02:54 -0000

--00000000000020e3b8057b1e1d43
Content-Type: text/plain; charset="UTF-8"

Agreed with 4. Since the security BCP is deprecating the implicit flow, it
seems like it's not worth the effort to try to come up with a solution for
this when the security implications of doing this aren't clear yet either.

----
Aaron Parecki
aaronparecki.com

On Tue, Nov 20, 2018 at 11:36 AM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> I opt for (4) - Remove support/description of binding of access tokens
> issued from the authorization endpoint
>
> I think the potential solution we worked out (slide 6) is to complex and
> the security implications of the redirect via the resource servers are
> still unclear.
>
> > Am 18.11.2018 um 13:32 schrieb Brian Campbell  40pingidentity.com@dmarc.ietf.org>:
> >
> > During the first OAuth session in Bangkok the question "what to do about
> token binding & implicit?" was raised. There was some discussion but
> session time was limited and we had to move on before any real consensus
> was reached.
> >
> > So I thought I'd bring the question to the WG list to generate some more
> discussion on the issue. It's also related, at least in part, to a couple
> of the other ongoing threads on the list about browser based apps and
> security practices.
> >
> > The slides from the session are linked below. Slides 5 & 6 try and
> explain the awkwardness of doing Token Binding with implicit. While slide 7
> lays out some (not very good) options for how to proceed.
> >
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    Agreed with 4. Since the security BCP is deprecating =
the implicit flow, it seems like it's not worth the effort to try to co=
me up with a solution for this when the security implications of doing this=
 aren't clear yet either.

    ----
    Aaron Parecki

    On Tue, Nov 20, 2018 at 11:36 AM Torsten Lod=
derstedt <torsten@lodderstedt=
.net> wrote:
    I opt for (4) -=
 Remove support/description of binding of access tokens issued from the aut=
horization endpoint 
    

    
I think the potential solution we worked out (slide 6) is to complex and th=
e security implications of the redirect via the resource servers are still =
unclear.
    

    
> Am 18.11.2018 um 13:32 schrieb Brian Campbell <bcampbell=3D40pingident=
ity.com@dmarc.ietf.org>:
    
> 
    
> During the first OAuth session in Bangkok the question "what to d=
o about token binding & implicit?" was raised. There was some disc=
ussion but session time was limited and we had to move on before any real c=
onsensus was reached. 
    
> 
    
> So I thought I'd bring the question to the WG list to generate som=
e more discussion on the issue. It's also related, at least in part, to=
 a couple of the other ongoing threads on the list about browser based apps=
 and security practices. 
    
> 
    
> The slides from the session are linked below. Slides 5 & 6 try and=
 explain the awkwardness of doing Token Binding with implicit. While slide =
7 lays out some (not very good) options for how to proceed.
    
> https://datatracker.ietf.org/meeting/103/materials/slides-103-o=
auth-sessb-draft-ietf-oauth-token-binding-00
    
> 
    
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil=
eged material for the sole use of the intended recipient(s). Any review, us=
e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y=
ou have received this communication in error, please notify the sender imme=
diately by e-mail and delete the message and any file attachments from your=
 computer. Thank you._______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org=

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

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

    

--00000000000020e3b8057b1e1d43--


From nobody Tue Nov 20 12:18:53 2018
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 1ED03130DCF for ; Tue, 20 Nov 2018 12:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDBzW5jqHNQK for ; Tue, 20 Nov 2018 12:18:51 -0800 (PST)
Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 31ACD12D4E9 for ; Tue, 20 Nov 2018 12:18:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542745129; bh=3MhTI76AdU4CWSJCh1vrGt4N7Z0YdTWr0Iuom+aq39c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=coUvIu50dN35CqAoJuHrcYGZs8bMNPnahvR2yaeJmz8zgOuHhSLB6RaH6BJ2Lma+Zlsj/jbhqlCrcLkaQDjdK3yYEBhX21zCgEEx6V5v3Y3jF9gO34aNw+OlMeO5LVl617H0XzGyHV23utjdw5ALHU+nSbr2yhxqLqe5WF8iERjIeamFIwYbIGDNdG79yb7FlDTDWltfiLdrLjZzqfdN7f38ik7k8hAHRUE9oC8GhIqJceaucfXtx4bGDcGZFaI9sgCM1KiwFGS1KP1ebS+M/p7+e+2tlAQ5eTdB9Uq86zWDCpcLVaGTHsjV7+p3NePSQdCyLk+FJDItQ1NRYxyr3g==
X-YMail-OSG: S1Og9IcVM1nlaN7b4vG4Bgao.F2iCl9JkVn400KwV60i8dxPzZ4NaFim3kHvM7s 2HyIhYY9QCX786Xu2TG4zRqlOa.JEEoJi8qcK7JuFWjJSLAneqpW0JcoaE.eoQmnq9zKS_ANiIOr 84t6hzQ4S6LzPjkoh2TrHZdTKTZu_UPgOBSzkQEb_EAKywxvusqO7HFjc3XR5ljYT3YbOkJNo9JT BiNALNd6qnYuE7C.nqTsmjzPEnCHhhoLZD7eiBnQyVlyg_51yiOm8vkSr8.cun5ZGvqlcakW2_Bo 3ZGadSnw1C5V8TQ0Aj9A.XJjthU10YJqifGaHombm3tYasRZNQfrwMuhuFy5oP4UbcY_v2maOxty PJBSV2vvfnbHWqhvKwJw6p2N9Q93EJhx95.I_8DgpH2ud5haJPU6eYuZcyAiReGxvcKuh9bPHMSz DgI1dJBx291moIM5jPOEENvIA1PoPdWXW09EdliWr6sDw3gkMGX05m_087Eq4FlKJBi2_ZFIYxBw 84ZY55zDmgceYzSZwSnsZw2RE4nojMT6T.NTdGJgXTNs_KU60_RfhfkEt28b0v7f43suJPttnMcT 8iFG.dIX4W0Xhvp5ni9sv.ixbMIbwJPVphNti95GhvDlcEClNKs2SKeCOjJ5SXNMqifO9vYO5_K5 n6fim2JZDfpxpZS8XZYbo1Ci5Tl8p6SILZMya3QHPmjbiykSfnRmN5z_mKs4NhFwQfacNNoEcf_c eVhT7rXsp7sgGI8fyMRl2jLZqCaTeXded9R3gdmZyKaWGOFCMN6xDjsf4Nkr7wYfTrE9DNpGiUVb vJYzGOPHvlVTLM6Wuuv3Gv.eaAg5gtzRI9H53Syeaemo_ClsQyI41B83E.si80hM2EQIsH09Hf6P XJyLrEaMQAoh9363JPy2ijghPejcH2raA0TW32LZOkNqgLetwp3ZNlgsY6oY17c2VQFMcZTG4AND Yq.mYdhy8eK_K.JrXzHhpf9ZP5q3fWJ1o5v3vw_aIKSdUeXWpwL03dEt5KCinZ4fFUbw5EGCOgeR rSjjaVKxgNU1.Y31Ec38IdKWs0cfVO4aZuyXUvINxxvtm6ylxYUlHcg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Tue, 20 Nov 2018 20:18:49 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.132.163]) ([184.165.8.99]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0baacfffed60db6c0c2dea4b49b11dfc;  Tue, 20 Nov 2018 20:08:43 +0000 (UTC)
To: Alissa Cooper , The IESG 
Cc: oauth@ietf.org, draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org
References: <154274344398.29963.11727425335350408375.idtracker@ietfa.amsl.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Tue, 20 Nov 2018 15:08:41 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <154274344398.29963.11727425335350408375.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2018 20:18:52 -0000

In regards to the comment on section 4.1, it depends on the 
authorization policy and the deployment architecture. I don't believe 
there is a single solution that will work with all deployments.

It may be worth calling out that exposure of the entire delegation chain 
can leak information and that care should be taken to ensure the entity 
receiving the token with this information is in fact authorized to 
receive it.

On 11/20/18 2:50 PM, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-oauth-token-exchange-16: Discuss
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 6: The requirements around confidentiality here are weaker than in both
> RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 3:
>
> If I understand this correctly:
>
> "The distinction between an access token and a JWT is subtle."
>
> I think it would be clearer if it said:
>
> "The distinction between an access token type and a JWT token type is subtle."
>
> Section 4.1:
>
> What is the value of maintaining the whole delegation chain rather than
> expressing just the most recent delegation? Doesn't it potentially expose
> information about past exchanges unnecessarily?
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Tue Nov 20 12:37:40 2018
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 3AFF112785F for ; Tue, 20 Nov 2018 12:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 StPeLVoIQc-P for ; Tue, 20 Nov 2018 12:37:34 -0800 (PST)
Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 7B25B12D4EF for ; Tue, 20 Nov 2018 12:37:34 -0800 (PST)
Received: by mail-oi1-x244.google.com with SMTP id y23so2664324oia.4 for ; Tue, 20 Nov 2018 12:37:34 -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=9uXMbqSVB03G6NltLxqCYWk/JrT2emEqlTEx+rPVAEI=; b=MHTX8atpNc/VTAyYWjllnmgGcmuRF4Zx24xuCIQekIRSt+xlnBF/cI0HNLIf9d+Syl NTYFHgkPSoTcXacEzh3K0VAMKv73PcGMSP65ptr4Rvv6BgwiKv4cVnn5Kk3msPcelL4J 4kgTND3xmuSfzWDBvoB/rzIZdHyMeV6QA/QCSvsPj6cQvcEhLfybaWHPJMvud3f2RaQv Bq5I9a7ViJK90mnAVIr1GzYx4AVwyyQM7fsK7mMjuE1OpwnaFTP7wnJWmZgLGo6TC1xO C/BmI0o+nD4eK3ZNaHvf+uIcgF0PUOo3DmPyCIID+ubVKMKHxqIGX0pkINO8nMekUOHO bY3g==
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=9uXMbqSVB03G6NltLxqCYWk/JrT2emEqlTEx+rPVAEI=; b=MORkinHYwYQYypTpluM4ljXWl2g1cyOADPKjNZmJRIWUnupOJCcWi1ruIifX4CYiy6 cgjYi+m993lxil31C8AGplk9EffXIVcJrLpWHUrkvrvTo4o3nGReGwM5SwppPp3uVmL0 ZfXpqIX+80oW4r6EtMqNqhDjhZi4imGa2E8BYouzBYsZSI8g7Ad3/J6JncfY7i4skyQs bibJINTYh5Yzp6lxM5SV7Mshj8P8f7tcAc0LFulwflPKvbm4U0+YB1cCviiHCrXJVtNm jgYMlkjHUVyzC4i9VWQOQ3ZnZiflLyYEKuJtNJhImbAqDcIy9bepyXbK5gIigMrXSY+Z AMBA==
X-Gm-Message-State: AGRZ1gIAl/tJPB5y7D3hSjknDUjFYzsKA19TLAseZ44W5s0NybeocIAu PdYWRWGzSeOsksQCgKWuyeU+u/JMPVpFmZW8k/vGftWc
X-Google-Smtp-Source: AJdET5fuXV3DdK1C3UQiqpqs9YEXnRSxXsStWyWb4jEjn4+/PzAktTauxISKhMmph3RA49qharv8plTUv2bAo0jxIKQ=
X-Received: by 2002:aca:53cd:: with SMTP id h196mr2086963oib.355.1542746253039;  Tue, 20 Nov 2018 12:37:33 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Adam Cashion 
Date: Tue, 20 Nov 2018 14:04:34 -0600
Message-ID: 
To: oauth , Adam Cashion 
Content-Type: multipart/alternative; boundary="000000000000641b79057b1e9a8b"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 121, Issue 45
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, 20 Nov 2018 20:37:38 -0000

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

email

On Tue, Nov 20, 2018, 1:37 PM  Send OAuth mailing list submissions to
>         oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         oauth-request@ietf.org
>
> You can reach the person managing the list at
>         oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (John Bradley)
>    2. I-D Action: draft-ietf-oauth-security-topics-10.txt
>       (internet-drafts@ietf.org)
>    3. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt
>       (Torsten Lodderstedt)
>    4. Re: Token Binding & implicit (Torsten Lodderstedt)
>
>
>
> ---------- Forwarded message ----------
> From: John Bradley 
> To: oauth@ietf.org
> Cc:
> Bcc:
> Date: Tue, 20 Nov 2018 12:47:22 -0300
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs o=
r
> redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say
> sending it in a redirect is a good security practice.
>
> John B.
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
> Hi Mike,
>
> I agree that OIDC hybrid flows offer additional security over the OAuth i=
mplicit grant and are used in the wild. On my slides and in the initial ver=
sion of the new section, we had included the hybrid OIDC flows because of t=
heir known token injection countermeasures.
>
> I nevertheless feel very uncomfortable to recommend those flows and any f=
low issuing access tokens in the front channel. In the course of the detail=
ed review of the new text we realized two issues:
>
> 1) Since the access token is exposed in the URL, such flows possess a sig=
nificantly higher risk to leak the access token (e.g. through browser histo=
ry, open redirection and even referrer headers) than the code grant.
> 2) There is no viable way to sender constrain access tokens issued in the=
 front channel. Given the WG decided to recommend use of sender constraint =
tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#sec=
tion-2..2), it seems contradictory to recommend response types not supporti=
ng such an approach.
>
> kind regards,
> Torsten.
>
>
> Am 19.11.2018 um 23:13 schrieb Mike Jones  :
>
> This description of the situation is an oversimplification.  OpenID Conne=
ct secures the implicit flow against token injection attacks by including t=
he at_hash (access token hash) in the ID Token, enabling the client to vali=
date that the access token was created by the issuer in the ID Token (which=
 is also the OAuth Issuer, as described in RFC 8414).  (Note that this miti=
gation was described in draft-ietf-oauth-mix-up-mitigation.)
>
> Given the prevalence of this known-good solution for securing the implici=
t flow, I would request that the draft be updated to describe this mitigati=
on.  At the same time, I=E2=80=99m fine with the draft recommending the cod=
e flow over the implicit flow when this mitigation is not used.
>
>                                                                 Thank you=
,
>                                                                 -- Mike
>
> From: OAuth   On Behalf O=
f Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth  
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code=
 instead of implicit
>
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion tha=
t it is not possible to adequately secure the implicit flow against token i=
njection since potential solutions like token binding or JARM are in an ear=
ly stage of adoption. For this reason, and since CORS allows browser-based =
apps to send requests to the token endpoint, Torsten suggested to use the a=
uthorization code instead of the implicit grant in call cases in his presen=
tation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oa=
uth-sessb-draft-ietf-oauth-security-topics-01).
>
> A hum in the room at IETF#103 concluded strong support for his recommenda=
tions. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are conf=
idential and may also be privileged. If you are not the intended recipient,=
 please notify the sender immediately and do not disclose the contents to a=
ny other person, use it for any purpose, or store or copy the information i=
n any medium. Thank you.
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
>
> ---------- Forwarded message ----------
> From: internet-drafts@ietf.org
> To: 
> Cc: oauth@ietf.org
> Bcc:
> Date: Tue, 20 Nov 2018 11:26:58 -0800
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IET=
F.
>
>         Title           : OAuth 2.0 Security Best Current Practice
>         Authors         : Torsten Lodderstedt
>                           John Bradley
>                           Andrey Labunets
>                           Daniel Fett
>         Filename        : draft-ietf-oauth-security-topics-10.txt
>         Pages           : 38
>         Date            : 2018-11-20
>
> Abstract:
>    This document describes best current security practice for OAuth 2.0.
>    It updates and extends the OAuth 2.0 Security Threat Model to
>    incorporate practical experiences gathered since OAuth 2.0 was
>    published and covers new threats relevant due to the broader
>    application of OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
>
>
> 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/
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Torsten Lodderstedt 
> To: oauth 
> Cc:
> Bcc:
> Date: Tue, 20 Nov 2018 20:32:50 +0100
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.t=
xt
> Hi all,
>
> the new revision contains the following changes:
>
> * added section on refresh tokens
> * additional justifications for recommendation for code
> * refactored 2.1 in order to distinguish CSRF, authz response replay and
> mix-up (based on feedback by Joseph Heenan)
> * added requirement to authenticate clients during code exchange (PKCE or
> client credential) to 2.1.1.
> * changed occurrences of SHALL to MUST
>
> As always: looking forward for your feedback.
>
> kind regards,
> Torsten.
>
> > Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
> >
> >
> > 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 Security Best Current Practice
> >        Authors         : Torsten Lodderstedt
> >                          John Bradley
> >                          Andrey Labunets
> >                          Daniel Fett
> >       Filename        : draft-ietf-oauth-security-topics-10.txt
> >       Pages           : 38
> >       Date            : 2018-11-20
> >
> > Abstract:
> >   This document describes best current security practice for OAuth 2.0.
> >   It updates and extends the OAuth 2.0 Security Threat Model to
> >   incorporate practical experiences gathered since OAuth 2.0 was
> >   published and covers new threats relevant due to the broader
> >   application of OAuth 2.0.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
> >
> >
> > 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/
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> ---------- Forwarded message ----------
> From: Torsten Lodderstedt 
> To: Brian Campbell 
> Cc: oauth 
> Bcc:
> Date: Tue, 20 Nov 2018 20:36:39 +0100
> Subject: Re: [OAUTH-WG] Token Binding & implicit
> I opt for (4) - Remove support/description of binding of access tokens
> issued from the authorization endpoint
>
> I think the potential solution we worked out (slide 6) is to complex and
> the security implications of the redirect via the resource servers are
> still unclear.
>
> > Am 18.11.2018 um 13:32 schrieb Brian Campbell  40pingidentity.com@dmarc.ietf.org>:
> >
> > During the first OAuth session in Bangkok the question "what to do abou=
t
> token binding & implicit?" was raised. There was some discussion but
> session time was limited and we had to move on before any real consensus
> was reached.
> >
> > So I thought I'd bring the question to the WG list to generate some mor=
e
> discussion on the issue. It's also related, at least in part, to a couple
> of the other ongoing threads on the list about browser based apps and
> security practices.
> >
> > The slides from the session are linked below. Slides 5 & 6 try and
> explain the awkwardness of doing Token Binding with implicit. While slide=
 7
> lays out some (not very good) options for how to proceed.
> >
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-token-binding-00
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you._______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    email

    On Tue, Nov 20, 2018, 1:37 PM  <oauth-request@ietf.org wrote:
    Send OAuth mailing list submissions to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org
    

    
To subscribe or unsubscribe via the World Wide Web, visit
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o=
rg/mailman/listinfo/oauth
    
or, via email, send a message with subject or body 'help' to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org
    

    
You can reach the person managing the list at
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org
    

    
When replying, please edit your Subject line so it is more specific
    
than "Re: Contents of OAuth digest..."
    
Today's Topics:
    

    
=C2=A0 =C2=A01. Re: OAuth Security Topics -- Recommend authorization code
=C2=A0 =C2=A0 =C2=A0 instead of implicit (John Bradley)
    
=C2=A0 =C2=A02. I-D Action: draft-ietf-oauth-security-topics-10.txt
    
=C2=A0 =C2=A0 =C2=A0 (internet-drafts@ietf.org)
    
=C2=A0 =C2=A03. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt
    
=C2=A0 =C2=A0 =C2=A0 (Torsten Lodderstedt)
    
=C2=A0 =C2=A04. Re: Token Binding & implicit (Torsten Lodderstedt)
    



    ---------- Forwarded message ----------
    From:=C2=A0John Brad=
ley <ve7jtb@ve7jtb.com>
    To:=C2=A0oauth@ietf.org
    Cc:=C2=A0Bcc:=C2=A0
    Date:=C2=A0Tue, 20 Nov 2018 12:47:22 -0300
    Subject:=C2=A0=
Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instea=
d of implicit
    
 =20
   =20
 =20
  
    
    
    Yes the at_hash protects the client from accepting an injected
      AT.=C2=A0 
    
    
    
    
    Unfortunately it doesn't do anything to protect against leakage
      in logs or redirects.
    
    
    
    
    So without the AT using some sort of POP mechanism it is hard to
      say sending it in a redirect is a good security practice.
    
    
    John B.
    
    
    
    
    On 11/20/2018 4:35 =
AM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi Mike,=20

I agree that OIDC hybrid flows offer additional security over the OAuth imp=
licit grant and are used in the wild. On my slides and in the initial versi=
on of the new section, we had included the hybrid OIDC flows because of the=
ir known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any flo=
w issuing access tokens in the front channel. In the course of the detailed=
 review of the new text we realized two issues:=20

1) Since the access token is exposed in the URL, such flows possess a signi=
ficantly higher risk to leak the access token (e.g. through browser history=
, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the f=
ront channel. Given the WG decided to recommend use of sender constraint to=
kens (https://tools.ietf.org/html/draft-ietf-o=
auth-security-topics-09#section-2..2), it seems contradictory to recomm=
end response types not supporting such an approach.=20

kind regards,
Torsten.=20


    
      
    
        
    Am 19.11.2018 um =
23:13 schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ie=
tf.org>:

This description of the situation is an oversimplification.  OpenID Connect=
 secures the implicit flow against token injection attacks by including the=
 at_hash (access token hash) in the ID Token, enabling the client to valida=
te that the access token was created by the issuer in the ID Token (which i=
s also the OAuth Issuer, as described in RFC 8414).  (Note that this mitiga=
tion was described in draft-ietf-oauth-mix-up-mitigation.)
=20
Given the prevalence of this known-good solution for securing the implicit =
flow, I would request that the draft be updated to describe this mitigation=
.  At the same time, I=E2=80=99m fine with the draft recommending the code =
flow over the implicit flow when this mitigation is not used.
=20
                                                                Thank you,
                                                                -- Mike
=20
From: OAuth <oa=
uth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <oauth@ietf.o=
rg>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code i=
nstead of implicit
=20
Hi all,
=20
The authors of the OAuth Security Topics draft came to the conclusion that =
it is not possible to adequately secure the implicit flow against token inj=
ection since potential solutions like token binding or JARM are in an early=
 stage of adoption. For this reason, and since CORS allows browser-based ap=
ps to send requests to the token endpoint, Torsten suggested to use the aut=
horization code instead of the implicit grant in call cases in his presenta=
tion (seehttps://datatracker.ietf.org/meeting/103/materials/slides-=
103-oauth-sessb-draft-ietf-oauth-security-topics-01).
=20
A hum in the room at IETF#103 concluded strong support for his recommendati=
ons. We would like to confirm the discussion on the list.
=20
Please provide a response by December 3rd.
=20
Ciao
Hannes & Rifaat
=20
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://www.ietf.org/mailman/listinfo/oauth

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

    
    
    
  
    




    ---------- Forwarded message ----------
    From:=C2=A0i=
nternet-drafts@ietf.org
    To:=C2=A0<i-d-announce@ietf.org>=
;
    Cc:=C2=A0oauth@ietf.org
    Bcc:=C2=A0
    Date:=C2=A0Tue, 20 Nov 2018 1=
1:26:58 -0800
    Subject:=C2=A0[OAUTH-WG] I-D Action: draft-ietf-oauth-secu=
rity-topics-10.txt

    
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 Security Best Current Practice
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tors=
ten Lodderstedt
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 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 Andrey Labunets
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Daniel Fett
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-security-topics-10.txt
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 38
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2018-11-20
    

    
Abstract:
    
=C2=A0 =C2=A0This document describes best current security practice for OAu=
th 2.0.
    
=C2=A0 =C2=A0It updates and extends the OAuth 2.0 Security Threat Model to<=
br>
=C2=A0 =C2=A0incorporate practical experiences gathered since OAuth 2.0 was=

    
=C2=A0 =C2=A0published and covers new threats relevant due to the broader
=C2=A0 =C2=A0application of OAuth 2.0.
    

    

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

    
There are also htmlized versions available at:
    
https://tools.ietf.org/htm=
l/draft-ietf-oauth-security-topics-10
    
https://datatrac=
ker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
    

    
A diff from the previous version is available at:
    
https://www.ietf.o=
rg/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
    

    

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

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

    

    



    ---------- Forwarded message ----------
    From:=C2=A0Torsten L=
odderstedt <torsten@lodderstedt.net>
    To:=C2=A0oauth <<=
a href=3D"mailto:oauth@ietf.org" target=3D"_blank" rel=3D"noreferrer">oauth=
@ietf.org>
    Cc:=C2=A0
    Bcc:=C2=A0
    Date:=C2=A0Tue, 20 Nov 2018=
 20:32:50 +0100
    Subject:=C2=A0Re: [OAUTH-WG] I-D Action: draft-ietf-oaut=
h-security-topics-10.txt
    Hi all, 
    

    
the new revision contains the following changes:
    

    
* added section on refresh tokens 
    
* additional justifications for recommendation for code
    
* refactored 2.1 in order to distinguish CSRF, authz response replay and mi=
x-up (based on feedback by Joseph Heenan)
    
* added requirement to authenticate clients during code exchange (PKCE or c=
lient credential) to 2.1.1.
    
* changed occurrences of SHALL to MUST
    

    
As always: looking forward for your feedback.
    

    
kind regards,
    
Torsten. 
    

    
> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
    
> 
    
> 
    
> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
    
> 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 Security Best Current Practice
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=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 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 Andrey Labunets
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Daniel Fett
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
ietf-oauth-security-topics-10.txt
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 38
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2018-11-20
    
> 
    
> Abstract:
    
>=C2=A0 =C2=A0This document describes best current security practice for=
 OAuth 2.0.
    
>=C2=A0 =C2=A0It updates and extends the OAuth 2.0 Security Threat Model=
 to
    
>=C2=A0 =C2=A0incorporate practical experiences gathered since OAuth 2.0=
 was
    
>=C2=A0 =C2=A0published and covers new threats relevant due to the broad=
er
    
>=C2=A0 =C2=A0application of OAuth 2.0.
    
> 
    
> 
    
> The IETF datatracker status page for this draft is:
    
> https://datatracke=
r.ietf.org/doc/draft-ietf-oauth-security-topics/
    
> 
    
> There are also htmlized versions available at:
    
> https://tools.ietf.or=
g/html/draft-ietf-oauth-security-topics-10
    
> https://dat=
atracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
    
> 
    
> A diff from the previous version is available at:
    
> https://www.i=
etf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
    
> 
    
> 
    
> Please note that it may take a couple of minutes from the time of subm=
ission
    
> 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/oau=
th
    

    



    ---------- Forwarded message ----------
    From:=C2=A0Torsten L=
odderstedt <torsten@lodderstedt.net>
    To:=C2=A0Brian Campb=
ell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
;
    Cc:=C2=A0oauth <oauth@ietf.org>
    Bcc:=C2=A0
    Date:=C2=A0Tue,=
 20 Nov 2018 20:36:39 +0100
    Subject:=C2=A0Re: [OAUTH-WG] Token Binding &=
amp; implicit
    I opt for (4) - Remove support/description of binding of a=
ccess tokens issued from the authorization endpoint 
    

    
I think the potential solution we worked out (slide 6) is to complex and th=
e security implications of the redirect via the resource servers are still =
unclear.
    

    
> Am 18.11.2018 um 13:32 schrieb Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>:
    
> 
    
> During the first OAuth session in Bangkok the question "what to d=
o about token binding & implicit?" was raised. There was some disc=
ussion but session time was limited and we had to move on before any real c=
onsensus was reached. 
    
> 
    
> So I thought I'd bring the question to the WG list to generate som=
e more discussion on the issue. It's also related, at least in part, to=
 a couple of the other ongoing threads on the list about browser based apps=
 and security practices. 
    
> 
    
> The slides from the session are linked below. Slides 5 & 6 try and=
 explain the awkwardness of doing Token Binding with implicit. While slide =
7 lays out some (not very good) options for how to proceed.
    
> https://datatracker.ietf.org/meeting/103/materials/s=
lides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
    
> 
    
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil=
eged material for the sole use of the intended recipient(s). Any review, us=
e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y=
ou have received this communication in error, please notify the sender imme=
diately 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/oau=
th
    

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

    

--000000000000641b79057b1e9a8b--


From nobody Tue Nov 20 12:37:59 2018
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 EB8CE130E4B for ; Tue, 20 Nov 2018 12:37:51 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRD4-qq1QKVB for ; Tue, 20 Nov 2018 12:37:48 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0: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 85E05130E6C for ; Tue, 20 Nov 2018 12:37:48 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id p11-v6so10966596itf.0 for ; Tue, 20 Nov 2018 12:37:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5jIC7cOUxEoSAoaHL99zOh1n13/o/NrKyQVsPLnY2q0=; b=FWY5niws/ZEkzXo5Db1XJ1Ksypd9h1LNIT83vd7vi0Maobw/YARKEFX4oUZN8dtUph oU40jhnpG69uFugQzEwXBm1uxasY5AsUN+xGLcmIDfrd9jurO1yc9aZVj05UCLUURZxS 9VET89Ete/oK2rBg9NbK+FkoFGJXEBsI/3IpDxr+JovFlea1t21+oYIA7FxgWRh9vFvn ls8SjmBA4QlgZ8mzT2A+wVyZTLuRer51+xS4Kubqq5rMBQ5LCCZ1ywPLEz1rtBPYDSrq /m9Yx+aa8jsOhD+F7MFQ6RND2MVrqsYJYrgdCchyXuAN+K/dsU35ViQ+35mlIWdlzH0W BG4A==
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=5jIC7cOUxEoSAoaHL99zOh1n13/o/NrKyQVsPLnY2q0=; b=rfAlZnk/7LE+h3txL52LtLaSaI9sLWx8Hx9ibTMrmSeV2lY8XcLwgslkicIUYLJI4V mbcc1OWiFD3X7Suxo/cUcNzA02y9aVQHPi4fshv9IC0jVZRNlu+dPk/80Ko3pW+FQPi5 Pm5MIHGwS5vQU1u7galkL92lPouZEMr4NOMmPyKQfD7hAGIhZK9VInYM7DwHyDNlk2/R RsKSIozsX/HypwmTeEZqgW1Gjxz6TylWY4SeOYzHJxDjXxF5BxsSsUaYq3SOBA7OHarn jOY9fM/+qBg29YvYTGb8ogCdeE6mLomXl6Zif1b+PJPLqW25ufhsdSLqGLC2C5M9Q379 K0HA==
X-Gm-Message-State: AA+aEWY8tMlSiQ1/1Ag6NUM7si2ESAZZi4pf+jcNFhMXpD+dJBgnVyhT Ih4faglLQbgC3yPq/G5v/sMQg/eUViw=
X-Google-Smtp-Source: AFSGD/W4wFz0Lw0Lso2+yOBzmq5WRay9MnfYi6UZrlQOp6w9Sab2hH9MXOhttLXi+Axl6iwKID/v7Q==
X-Received: by 2002:a24:2285:: with SMTP id o127-v6mr2966321ito.168.1542746267389;  Tue, 20 Nov 2018 12:37:47 -0800 (PST)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com. [209.85.166.42]) by smtp.gmail.com with ESMTPSA id m12sm8963318ioh.69.2018.11.20.12.37.46 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 12:37:46 -0800 (PST)
Received: by mail-io1-f42.google.com with SMTP id n9so2391958ioh.7 for ; Tue, 20 Nov 2018 12:37:46 -0800 (PST)
X-Received: by 2002:a6b:8d8a:: with SMTP id p132mr2806197iod.290.1542746266105;  Tue, 20 Nov 2018 12:37:46 -0800 (PST)
MIME-Version: 1.0
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com> 
In-Reply-To: 
From: Aaron Parecki 
Date: Tue, 20 Nov 2018 12:37:34 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Torsten Lodderstedt 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000002b80cb057b1e9bef"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 20 Nov 2018 20:37:58 -0000

--0000000000002b80cb057b1e9bef
Content-Type: text/plain; charset="UTF-8"

The new section on refresh tokens is great! I have a couple
questions/comments about some of the details.

Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o  logout at the authorization server


This doesn't sound like the desired behavior for mobile apps, where the
user's expectation of how long they are logged in to the mobile app is not
tied to their web session where they authorized the app. However this does
likely match a user's expectation when authorizing a browser-based app.
Should this be clarified that it should not apply to the mobile app case,
or only apply to browser-based apps?

Refresh tokens should expire if the client has been inactive for some time


This is a good suggestion, but I think it would benefit from a little more
clarity. Specifically pointing out that what counts as "activity" is use of
the access token and/or refresh token, if that's the intention. That will
help avoid confusion that "inactivity" may be referring to the user's
session at the authorization server.

Is this supposed to be a capital "SHOULD" or lowercase "should"?

It is also unclear whether this is meant to apply to public clients,
private clients, or both, as well as whether it should apply to mobile apps
or browser-based apps or both. I am curious what the intent is here, since
I feel like that can have some serious implications for the user experience
in some cases and is worth pointing out.

Lastly, minor nit, I see the comment about changing occurrences of "SHALL"
to "MUST", but the new refresh token section still has two uses of "SHALL".

Thanks! Overall I'm happy to see this guidance!

----
Aaron Parecki
aaronparecki.com



On Tue, Nov 20, 2018 at 11:33 AM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi all,
>
> the new revision contains the following changes:
>
> * added section on refresh tokens
> * additional justifications for recommendation for code
> * refactored 2.1 in order to distinguish CSRF, authz response replay and
> mix-up (based on feedback by Joseph Heenan)
> * added requirement to authenticate clients during code exchange (PKCE or
> client credential) to 2.1.1.
> * changed occurrences of SHALL to MUST
>
> As always: looking forward for your feedback.
>
> kind regards,
> Torsten.
>
> > Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
> >
> >
> > 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 Security Best Current Practice
> >        Authors         : Torsten Lodderstedt
> >                          John Bradley
> >                          Andrey Labunets
> >                          Daniel Fett
> >       Filename        : draft-ietf-oauth-security-topics-10.txt
> >       Pages           : 38
> >       Date            : 2018-11-20
> >
> > Abstract:
> >   This document describes best current security practice for OAuth 2.0.
> >   It updates and extends the OAuth 2.0 Security Threat Model to
> >   incorporate practical experiences gathered since OAuth 2.0 was
> >   published and covers new threats relevant due to the broader
> >   application of OAuth 2.0.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
> >
> >
> > 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/
> >
> > _______________________________________________
> > 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
>

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


    The new section on refresh tokens is great! I have a couple =
questions/comments about some of the details.

    Authorization servers may revoke refresh =
tokens automatically in case
    of a security event, such as:
    o=C2=A0 lo=
gout at the authorization server
    =C2=A0
    Th=
is doesn't sound like the desired behavior for mobile apps, where the u=
ser's expectation of how long they are logged in to the mobile app is n=
ot tied to their web session where they authorized the app. However this do=
es likely match a user's expectation when authorizing a browser-based a=
pp. Should this be clarified that it should not apply to the mobile app cas=
e, or only apply to browser-based apps?

    Refresh tokens should expire if the clie=
nt has been inactive for some time

    This is =
a good suggestion, but I think it would benefit from a little more clarity.=
 Specifically pointing out that=C2=A0what counts as "activity" is=
 use of the access token and/or refresh token, if that's the intention.=
 That will help avoid confusion that "inactivity" may be referrin=
g to the user's session at the authorization server.

    Hi all, 
    

    
the new revision contains the following changes:
    

    
* added section on refresh tokens 
    
* additional justifications for recommendation for code
    
* refactored 2.1 in order to distinguish CSRF, authz response replay and mi=
x-up (based on feedback by Joseph Heenan)
    
* added requirement to authenticate clients during code exchange (PKCE or c=
lient credential) to 2.1.1.
    
* changed occurrences of SHALL to MUST
    

    
As always: looking forward for your feedback.
    

    
kind regards,
    
Torsten. 
    

    
> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
    
> 
    
> 
    
> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
    
> 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 Security Best Current Practice
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=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 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 Andrey Labunets
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Daniel Fett
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
ietf-oauth-security-topics-10.txt
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 38
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2018-11-20
    
> 
    
> Abstract:
    
>=C2=A0 =C2=A0This document describes best current security practice for=
 OAuth 2.0.
    
>=C2=A0 =C2=A0It updates and extends the OAuth 2.0 Security Threat Model=
 to
    
>=C2=A0 =C2=A0incorporate practical experiences gathered since OAuth 2.0=
 was
    
>=C2=A0 =C2=A0published and covers new threats relevant due to the broad=
er
    
>=C2=A0 =C2=A0application of OAuth 2.0.
    
> 
    
> 
    
> The IETF datatracker status page for this draft is:
    
> https://datatracker.ietf.org/=
doc/draft-ietf-oauth-security-topics/
    
> 
    
> There are also htmlized versions available at:
    
> https://tools.ietf.org/html/draf=
t-ietf-oauth-security-topics-10
    
> https://datatracker.ie=
tf.org/doc/html/draft-ietf-oauth-security-topics-10
    
> 
    
> A diff from the previous version is available at:
    
> https://www.ietf.org/rfc=
diff?url2=3Ddraft-ietf-oauth-security-topics-10
    
> 
    
> 
    
> Please note that it may take a couple of minutes from the time of subm=
ission
    
> 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
    

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

    

--0000000000002b80cb057b1e9bef--


From nobody Tue Nov 20 12:38:09 2018
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 F0B7D130E7B for ; Tue, 20 Nov 2018 12:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YP83WukGYGvE for ; Tue, 20 Nov 2018 12:38:00 -0800 (PST)
Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 AEEA7130DE0 for ; Tue, 20 Nov 2018 12:38:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542746279; bh=atisI9sIpX8qIz1QJnsnY6WbYmrGzOUPPLmOnAuZw0I=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=dhQkad8laruckUWbNFPQuV7mjHt4Ii0g5dpshRMVCN1mGI04qQZcdMDMCsQHCPV6L30mZY0Z3D/iV5CB3DKK+QrzpBfaB7lny4NQzY/lno1OfhVZxCA95S1O/UVZ69rcz4xpgx+ff05oc39N6rl4bkE7EkaypYRAvTlkWXxZcb76GUA20zsOdmiVJ6bjqvkgZGPKt17SjPDLVOzUit0U/QzZMQGLm4/CK34s4Y3d4RVFkWNimh7nKhyRkOVLRkO7amG51Au0FjKhKU8oKdY7WOVcfieCH0zpK7/gLV4SZ8OR2ytFElF1JFnE+devYdGzd9s0xUPGpNAfAFEC7DvjnA==
X-YMail-OSG: pxHQWX4VM1lUIeBwkzxDEFjMQ6HtZ6.6Ba8WQvD2ZW7v_2orQse4TdsMWZH9kIo RVEUkIayCKPMarnwEMYg0NdgE_4fof1tNHT3pFD3lhrob8SQHyGD5bBGJH6tLObmAqf6y04WW3qb pmWIyeui910JN4FbcMj50SnU13m2bYcaO7LJmiiWX5vyTQqT6JKQhOOul8AU96OUNKhV8Lr4ICKG W5cRqzPYJVS_eM9BJ5OkxpP3Qo.lsujBlzWwUiNC7nJJLvi_7.XpYKPm6gjyfpHYcNA162yvYos. gaWYjq6vRkBg4A6Sonw40RIqRNEuY7LvmAAZnqm5PVFL0yNMWHOZk7J79DG1CdSvDebwxrtc1XUu nH2W6qc3dtww_pqsIjOOHKOOvp2BBI0txY3qfC.M6vL_sahcJprkRo.F2NKWeD2.EpOnE.KF2bqX zhNYG_NgOdyUW4obBJG6Vdf39bKQzlzKPxIBPItCjjrvnERH1ThwOED.fZw6MUW03xjlA9rYfTg_ f47JSXAfER16ALEnXvORhkydSUUIYeFkiGdcktrXqpDE9Uvf7vVTlvOpTG2wygU8j4HmY5ftjFbL chtIdeX5l4svkLhim5U47MUhdMnYATw7PGe8.gupr9O7jeLBvEXLRzPyoVndDp82XSkgQAgnqQz1 Tw_SH9QaVEXN9bbKC2gPeA5gvyvBKDw8kVI0LWIHtfjlxkaRq5FfUrCMn4aIdfrkIo6bMAkrwW1i GHuKEKLm2K6tnLr8UeMMDAPFH6tI6.0HZVQwC56Tyi5RD52gw.fM3A.iEQzqr7aNMPSTJDdwdDbe B0kpJZJ12SQJtwUIEukw_Y_GxJce2PEG.Pav7U._TlxUHM5N3FznbI0NADyfk_oKOXo_4j1PW0_l KlftTXs5DlGe0EZeGXCE7mLlEF3iB.whFBvxbkUO6XboobCiu.55PAc6zArXU4U42A2vphf.dd0M KUdRGvv0DF.dHNPhRCDaYqftS_OamoDSZPUDmwqsFspOnbrGtntef.dsGo4wYUNkV1XLmAR0pLnr Z3ftFYU.Aaq.COFXHLM7io5Hek42Nb7RsVCL5ZY2TKTfQ2w--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 20 Nov 2018 20:37:59 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.132.163]) ([184.165.8.99]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b3ab5efbcf239acc34b1f011e1fbe9d6;  Tue, 20 Nov 2018 20:37:58 +0000 (UTC)
To: Torsten Lodderstedt , oauth@ietf.org
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Tue, 20 Nov 2018 15:37:57 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------7D41E1D047608A398D1E5A2B"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 20 Nov 2018 20:38:08 -0000

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

Hi Torsten,

This is the module I much prefer. By default all refresh_tokens are 
bound to the user's authenticated session. When the authentication 
session is terminated, the refresh_tokens are invalidated. If a client 
wants to get a refresh_token that is NOT bound to an authentication 
session, then it much explicitly request the "offline_access" scope 
which then provides a consent interaction with the user which allows the 
user to know that this client wants to access their resources even when 
the user isn't logged in (present). This also provides the AS with the 
ability to control which clients are authorized to request 
"offline_access" and hence restrict that capability to know/approved 
clients.

We've implemented this module in two different Authorization Servers.

Thanks,
George

On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:
> Hi all,
>
> I‘m preparing a new section on Refresh Token best practices for the Security BCP. I‘m wondering whether anyone has implemented a binding of the refresh token‘s expiration/revocation with the state of the session the refresh token was issued in/for. So do you revoke refresh tokens when the user logs out from the AS or the session terminated for other reasons?
>
> kinds regards,
> Torsten.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Hi Torsten,
    
      
    
      This is the module I much prefer. By default all refresh_tokens
      are bound to the user's authenticated session. When the
      authentication session is terminated, the refresh_tokens are
      invalidated. If a client wants to get a refresh_token that is NOT
      bound to an authentication session, then it much explicitly
      request the "offline_access" scope which then provides a consent
      interaction with the user which allows the user to know that this
      client wants to access their resources even when the user isn't
      logged in (present). This also provides the AS with the ability to
      control which clients are authorized to request "offline_access"
      and hence restrict that capability to know/approved clients.
    
      
    
      We've implemented this module in two different Authorization
      Servers.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 11/15/18 9:28 AM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi all,

I‘m preparing a new section on Refresh Token best practices for the Security BCP. I‘m wondering whether anyone has implemented a binding of the refresh token‘s expiration/revocation with the state of the session the refresh token was issued in/for. So do you revoke refresh tokens when the user logs out from the AS or the session terminated for other reasons?

kinds regards,
Torsten.
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  


--------------7D41E1D047608A398D1E5A2B--


From nobody Tue Nov 20 12:56:39 2018
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 BCA43130DD4 for ; Tue, 20 Nov 2018 12:56:30 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.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 U1HI_gyT7OmR for ; Tue, 20 Nov 2018 12:56:27 -0800 (PST)
Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81822130E89 for ; Tue, 20 Nov 2018 12:56:27 -0800 (PST)
Received: by mail-it1-x12f.google.com with SMTP id a205-v6so5521851itd.4 for ; Tue, 20 Nov 2018 12:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DYI9XlQsvWBhMlDnYt31Va8mY/jIX+EUD0pgK2xeHJ0=; b=gP4f//6C2dhlDIGwQ9mO/lZBBj3VgjjsNcNlliZL+4gv4umpOciv8NA8a/jRGCSUPB iiz0eq97I5m7O3N0PPgLkmLd90LHAL18WRAxdahhFlT6usTaP1JvkJMiFQkBEk5NvUc4 ADgbD9lhQeU+zA8yTAmKvECO7L0MfJeZabVvBweDhrHrcrQj1FNGl8bqRH23SVyIMe0N xd9rTaVhjhjynhicMhXgL44EEhCyIzYIjbBgG3SPS4lU7WTfYEiwLNMy2gPKDCmPjiwT H2+4VG3heQyGPYNb6x8Gb7crcJ0Pep2RQLOMtmM1zbhhetOI7yPdNixzf5ypkXQFyybG SxTw==
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=DYI9XlQsvWBhMlDnYt31Va8mY/jIX+EUD0pgK2xeHJ0=; b=DHtGgt3G3XQe5TUHiIrtiZ3hp1qOSVJEJ0es7k0WCfq8iVeVILhet7Mj0IXW07OBQo OZK6DRvcAok9bCKm/ks4VkBZhSK3J8QjICweTX2XPleTHoGzWd0o9Uh9wWTVbzET9biX qXQjH9WNNjkitbaCq6sXP2Y7vUaprm650WosStZmGX10kplUYrAlt41u13aZMUGQkggl czYu6ItlQ4zROxsJDlBxx3+/6e6dXMnsREZGy7LY1r00TywNUnF9wBsl8tuRmGvyTLvI /+yhf/2wjP3+2NY7hDUCNBvc1AO8sYFWyikzJcFB7m4cplP2BjXAmwWjXMzMMwROsyG0 IK/g==
X-Gm-Message-State: AGRZ1gJCWXJIMBqxxD0XNOZWOh7bPGGCLgcAQP8xeRjyvvHIqbjGEidR NEFBoO4jXYRBxdMKIJwRHNHtS8x7Z9I=
X-Google-Smtp-Source: AJdET5fHKlG0alDmXQ6EJKg0RJyAYIHxQjXShwcJR9icgoxFUJ+RE6ZfLilHelOp/B1ldr9KfdN6XA==
X-Received: by 2002:a05:660c:ac1:: with SMTP id k1mr3605866itl.173.1542747386421;  Tue, 20 Nov 2018 12:56:26 -0800 (PST)
Received: from mail-it1-f171.google.com (mail-it1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id m81sm3378860itb.43.2018.11.20.12.56.25 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 12:56:25 -0800 (PST)
Received: by mail-it1-f171.google.com with SMTP id m15so5722900itl.4 for ; Tue, 20 Nov 2018 12:56:25 -0800 (PST)
X-Received: by 2002:a05:660c:944:: with SMTP id h4mr3753451itl.85.1542747385212;  Tue, 20 Nov 2018 12:56:25 -0800 (PST)
MIME-Version: 1.0
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net> 
In-Reply-To: 
From: Aaron Parecki 
Date: Tue, 20 Nov 2018 12:56:13 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: gffletch=40aol.com@dmarc.ietf.org
Cc: Torsten Lodderstedt , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000dfb6b8057b1edd1a"
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 20 Nov 2018 20:56:37 -0000

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

Hi George,

Reading this description, am I understanding correctly that you *always*
return a refresh token to every client? Are there any situations in which a
refresh token would not be returned? Specifically I'm wondering about how
this applies to browser-based apps using the authorization code flow and
refresh tokens.

----
Aaron Parecki
aaronparecki.com



On Tue, Nov 20, 2018 at 12:38 PM George Fletcher  wrote:

> Hi Torsten,
>
> This is the module I much prefer. By default all refresh_tokens are bound
> to the user's authenticated session. When the authentication session is
> terminated, the refresh_tokens are invalidated. If a client wants to get =
a
> refresh_token that is NOT bound to an authentication session, then it muc=
h
> explicitly request the "offline_access" scope which then provides a conse=
nt
> interaction with the user which allows the user to know that this client
> wants to access their resources even when the user isn't logged in
> (present). This also provides the AS with the ability to control which
> clients are authorized to request "offline_access" and hence restrict tha=
t
> capability to know/approved clients.
>
> We've implemented this module in two different Authorization Servers.
>
> Thanks,
> George
>
> On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:
>
> Hi all,
>
> I=E2=80=98m preparing a new section on Refresh Token best practices for t=
he Security BCP. I=E2=80=98m wondering whether anyone has implemented a bin=
ding of the refresh token=E2=80=98s expiration/revocation with the state of=
 the session the refresh token was issued in/for. So do you revoke refresh =
tokens when the user logs out from the AS or the session terminated for oth=
er reasons?
>
> kinds regards,
> Torsten.
>
>
>
> _______________________________________________
> 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
>

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


    Hi George,

    Reading this =
description, am I understanding correctly that you *always* return a refres=
h token to every client? Are there any situations in which a refresh token =
would not be returned? Specifically I'm wondering about how this applie=
s to browser-based apps using the authorization code flow and refresh token=
s.

    ----
    Aaron Parecki
    aaronparecki.com



    
 =20
   =20
 =20
  
    
    Hi Torsten,
    
      
    
      This is the module I much prefer. By default all refresh_tokens
      are bound to the user's authenticated session. When the
      authentication session is terminated, the refresh_tokens are
      invalidated. If a client wants to get a refresh_token that is NOT
      bound to an authentication session, then it much explicitly
      request the "offline_access" scope which then provides a co=
nsent
      interaction with the user which allows the user to know that this
      client wants to access their resources even when the user isn't
      logged in (present). This also provides the AS with the ability to
      control which clients are authorized to request "offline_access&=
quot;
      and hence restrict that capability to know/approved clients.
    
      
    
      We've implemented this module in two different Authorization
      Servers.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 11/15/18 9:28 A=
M, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi all,

I=E2=80=98m preparing a new section on Refresh Token best practices for the=
 Security BCP. I=E2=80=98m wondering whether anyone has implemented a bindi=
ng of the refresh token=E2=80=98s expiration/revocation with the state of t=
he session the refresh token was issued in/for. So do you revoke refresh to=
kens when the user logs out from the AS or the session terminated for other=
 reasons?

kinds regards,
Torsten.
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m=
ailman/listinfo/oauth

    
    
    
    
    
  
    

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

    

--000000000000dfb6b8057b1edd1a--


From nobody Tue Nov 20 13:00:42 2018
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 1BF26124D68 for ; Tue, 20 Nov 2018 13:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTXfditM9Arv for ; Tue, 20 Nov 2018 13:00:35 -0800 (PST)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490E812785F for ; Tue, 20 Nov 2018 13:00:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cuALutSp9DdrEzxoV0aHM3PH/AZo06jk9p+KKmEmzyQ=; b=mqDPZJrYuOmAfgrH196ykOR27CyTtqs7jBv2oJIobbvDVH9zBZEChxjQswWnCW+L8be3cL5AbJc/3z6TSwrcnvpQfkfUk06BWGi9qKrJBcpmcQhwlZe2flVZJG4eHLiTNwCa3loaLtgrz3BLUlue+bkmHVRihQSZpCmHx+Dh2aM=
Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0326.namprd00.prod.outlook.com (52.132.128.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1396.0; Tue, 20 Nov 2018 21:00:33 +0000
Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::957e:6cf1:bd05:6467]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::957e:6cf1:bd05:6467%3]) with mapi id 15.20.1399.000; Tue, 20 Nov 2018 21:00:33 +0000
From: Mike Jones 
To: John Bradley , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwAYRRbAABPdaIAAES+SAAAK3nrA
Date: Tue, 20 Nov 2018 21:00:32 +0000
Message-ID: 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>
In-Reply-To: <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:1:99c:fb4d:f44d:b4ba]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR00MB0326; 6:2HC3vkZVEx+qtgfWdvJ5yZ3IVP6bMFVxCpUX6P4S22Ka+q1mZMCc3aHg1x/5ReHv0nh40fBtnw0NWw2nifWOIV/FdEjZcjUtkIJDuxQvq6ALU4RqDRlO8icRSvyiZpkhJvwSug4avLeRG2F9gMLIF63iZDFHaQY6YJR0WXSdu5XeZCGpgKlk9RQutR+mRGYBHbbvHcD2O9v2fECyY+cipy2TqghWyNe2yYSeuuKWqTvLatsUO3B4iYUQICJNJLDipBch3ip/ZXV3TpviWNqHTIQO6aX1Yv5V3/9EEOtosfrUK5mI4KKNkNL3Td4i6FD9YDBUqhWRRaKEK1xF/7ykQv6UTqol+GoQrQHG/oMxmUvWHZHHPINx7cehVVPjfgoKLy0s+sUkTLotuCeMuaGuhe93oyJKDD17Nf4efkw/B0D48Oogdv1aaV56A0BbbYBKcChKmKBWhBc/gga2HGOWug==; 5:FN74FGCPd+4yZJGmUd50gATMu7YTlnMioAfdbGRBu4rghidoK46gRpVuHVTV6s1cwArjJrtqlQn1YpnijRSbb1bgyjHNXkA9wobSOSj5lhg4+l38qE1HFUyGcKqGCyNoQ68Yv4syl4PPduu/mn5cNvgf/iAhtuesIvvO2BeEbSM=; 7:CsFsvoEFCH5pHRJ8H/t2ouZGSYPD6GmhKy6BiMTAW0BGBJJR/jul1vsAKeQDZmNsqkVIOzA/eVQFnKEHKM+OtNtaCfxGlBoPUTI6TEMI9VScbX8Ryb3bKomVWstFdsILq0aBt5ffcOKocZTTXqvVFA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 655e8ffe-727b-4131-5411-08d64f2b3629
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR00MB0326; 
x-ms-traffictypediagnostic: DM5PR00MB0326:
x-ms-exchange-purlcount: 10
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3231442)(944501410)(2018427008)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM5PR00MB0326; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0326; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(346002)(39860400002)(396003)(53754006)(199004)(189003)(40434004)(6306002)(6436002)(25786009)(110136005)(8936002)(966005)(8990500004)(33656002)(72206003)(22452003)(86362001)(14454004)(21615005)(478600001)(71190400001)(71200400001)(316002)(93886005)(86612001)(81166006)(81156014)(99286004)(105586002)(7110500001)(68736007)(10290500003)(8676002)(9686003)(10710500007)(476003)(5660300001)(2501003)(54896002)(6506007)(236005)(2420400007)(229853002)(15650500001)(53936002)(446003)(66574009)(53546011)(74316002)(186003)(11346002)(46003)(97736004)(6246003)(2906002)(2900100001)(606006)(14444005)(256004)(5024004)(106356001)(790700001)(6116002)(10090500001)(102836004)(486006)(7736002)(7696005)(76176011)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0326; H:DM5PR00MB0293.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: lhyIe94z2sQlZlfHlKa7pcY0ubiOL7yh/2VLpPsEiq1J3SXMR0cCDzMrrxP2PQfnlbUb/wjtehN7vkMB+DwjaivmC8lrfitMBkDrTLoQ/wmrFf+AHiYCO0ayLUtaNGQPpxAyTh+To6UFR01qRie+BFcV+LcmKFZOvr1yGMIHi0u1oqs5npIxA2a16UlAJRzVc3A9L+rApJ09/0X9KNDRetDRGQ5gXuQ9DtGydwVe5qenNzpiRqg21z0LDI/pRfbQJPsor1u+L30Fp3IkUEVEUoVijjIUMXd3bichH4L+OlxAOv9ltJTkafzHzqUicnDbIJvmJCyiWKz4b60gzhzFMZ2iJ5nI28VZBeBwmMsqKYM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR00MB02937F639067DC15DC9D80D4F5D90DM5PR00MB0293namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 655e8ffe-727b-4131-5411-08d64f2b3629
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2018 21:00:32.8438 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0326
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 20 Nov 2018 21:00:40 -0000

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

TmV4dCBxdWVzdGlvbiDigJMgZG9lc27igJl0IHVzaW5nIHRoZSBGb3JtIFBvc3QgUmVzcG9uc2Ug
TW9kZSBodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItZm9ybS1wb3N0LXJlc3BvbnNl
LW1vZGUtMV8wLmh0bWwgbWl0aWdhdGUgdGhlIHRocmVhdHMgeW914oCZcmUgZGVzY3JpYmluZyBi
ZWxvdyBKb2huPyAgSWYgc28sIEkgYmVsaWV2ZSB0aGUgU2VjdXJpdHkgVG9waWNzIGRyYWZ0IHNo
b3VsZCBzYXkgdGhpcy4NCg0KSSBiZWxpZXZlIHdlIG93ZSBpdCB0byByZWFkZXJzIHRvIHByZXNl
bnQgdGhlIGNvbXBsZXRlIHBpY3R1cmUsIHdoaWNoIGlzIHdoeSBJIGJlbGlldmUgdGhhdCBkZXNj
cmliaW5nIHByb2ZpbGVzIHVzaW5nIElEIFRva2VucyBhbmQgdGhlIEZvcm0gUG9zdCBSZXNwb25z
ZSBNb2RlIGFyZSBpbiBzY29wZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFR1ZXNkYXksIE5v
dmVtYmVyIDIwLCAyMDE4IDc6NDcgQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0
aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KDQoNClllcyB0aGUgYXRfaGFzaCBwcm90ZWN0
cyB0aGUgY2xpZW50IGZyb20gYWNjZXB0aW5nIGFuIGluamVjdGVkIEFULg0KDQpVbmZvcnR1bmF0
ZWx5IGl0IGRvZXNuJ3QgZG8gYW55dGhpbmcgdG8gcHJvdGVjdCBhZ2FpbnN0IGxlYWthZ2UgaW4g
bG9ncyBvciByZWRpcmVjdHMuDQoNClNvIHdpdGhvdXQgdGhlIEFUIHVzaW5nIHNvbWUgc29ydCBv
ZiBQT1AgbWVjaGFuaXNtIGl0IGlzIGhhcmQgdG8gc2F5IHNlbmRpbmcgaXQgaW4gYSByZWRpcmVj
dCBpcyBhIGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2UuDQoNCkpvaG4gQi4NCk9uIDExLzIwLzIwMTgg
NDozNSBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZToNCg0KSGkgTWlrZSwNCg0KDQoNCkkg
YWdyZWUgdGhhdCBPSURDIGh5YnJpZCBmbG93cyBvZmZlciBhZGRpdGlvbmFsIHNlY3VyaXR5IG92
ZXIgdGhlIE9BdXRoIGltcGxpY2l0IGdyYW50IGFuZCBhcmUgdXNlZCBpbiB0aGUgd2lsZC4gT24g
bXkgc2xpZGVzIGFuZCBpbiB0aGUgaW5pdGlhbCB2ZXJzaW9uIG9mIHRoZSBuZXcgc2VjdGlvbiwg
d2UgaGFkIGluY2x1ZGVkIHRoZSBoeWJyaWQgT0lEQyBmbG93cyBiZWNhdXNlIG9mIHRoZWlyIGtu
b3duIHRva2VuIGluamVjdGlvbiBjb3VudGVybWVhc3VyZXMuDQoNCg0KDQpJIG5ldmVydGhlbGVz
cyBmZWVsIHZlcnkgdW5jb21mb3J0YWJsZSB0byByZWNvbW1lbmQgdGhvc2UgZmxvd3MgYW5kIGFu
eSBmbG93IGlzc3VpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gSW4gdGhl
IGNvdXJzZSBvZiB0aGUgZGV0YWlsZWQgcmV2aWV3IG9mIHRoZSBuZXcgdGV4dCB3ZSByZWFsaXpl
ZCB0d28gaXNzdWVzOg0KDQoNCg0KMSkgU2luY2UgdGhlIGFjY2VzcyB0b2tlbiBpcyBleHBvc2Vk
IGluIHRoZSBVUkwsIHN1Y2ggZmxvd3MgcG9zc2VzcyBhIHNpZ25pZmljYW50bHkgaGlnaGVyIHJp
c2sgdG8gbGVhayB0aGUgYWNjZXNzIHRva2VuIChlLmcuIHRocm91Z2ggYnJvd3NlciBoaXN0b3J5
LCBvcGVuIHJlZGlyZWN0aW9uIGFuZCBldmVuIHJlZmVycmVyIGhlYWRlcnMpIHRoYW4gdGhlIGNv
ZGUgZ3JhbnQuDQoNCjIpIFRoZXJlIGlzIG5vIHZpYWJsZSB3YXkgdG8gc2VuZGVyIGNvbnN0cmFp
biBhY2Nlc3MgdG9rZW5zIGlzc3VlZCBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gR2l2ZW4gdGhlIFdH
IGRlY2lkZWQgdG8gcmVjb21tZW5kIHVzZSBvZiBzZW5kZXIgY29uc3RyYWludCB0b2tlbnMgKGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGlj
cy0wOSNzZWN0aW9uLTIuLjIpLCBpdCBzZWVtcyBjb250cmFkaWN0b3J5IHRvIHJlY29tbWVuZCBy
ZXNwb25zZSB0eXBlcyBub3Qgc3VwcG9ydGluZyBzdWNoIGFuIGFwcHJvYWNoLg0KDQoNCg0Ka2lu
ZCByZWdhcmRzLA0KDQpUb3JzdGVuLg0KDQoNCg0KQW0gMTkuMTEuMjAxOCB1bSAyMzoxMyBzY2hy
aWViIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnPjxtYWlsdG86TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+
Og0KDQoNCg0KVGhpcyBkZXNjcmlwdGlvbiBvZiB0aGUgc2l0dWF0aW9uIGlzIGFuIG92ZXJzaW1w
bGlmaWNhdGlvbi4gIE9wZW5JRCBDb25uZWN0IHNlY3VyZXMgdGhlIGltcGxpY2l0IGZsb3cgYWdh
aW5zdCB0b2tlbiBpbmplY3Rpb24gYXR0YWNrcyBieSBpbmNsdWRpbmcgdGhlIGF0X2hhc2ggKGFj
Y2VzcyB0b2tlbiBoYXNoKSBpbiB0aGUgSUQgVG9rZW4sIGVuYWJsaW5nIHRoZSBjbGllbnQgdG8g
dmFsaWRhdGUgdGhhdCB0aGUgYWNjZXNzIHRva2VuIHdhcyBjcmVhdGVkIGJ5IHRoZSBpc3N1ZXIg
aW4gdGhlIElEIFRva2VuICh3aGljaCBpcyBhbHNvIHRoZSBPQXV0aCBJc3N1ZXIsIGFzIGRlc2Ny
aWJlZCBpbiBSRkMgODQxNCkuICAoTm90ZSB0aGF0IHRoaXMgbWl0aWdhdGlvbiB3YXMgZGVzY3Jp
YmVkIGluIGRyYWZ0LWlldGYtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24uKQ0KDQoNCg0KR2l2ZW4g
dGhlIHByZXZhbGVuY2Ugb2YgdGhpcyBrbm93bi1nb29kIHNvbHV0aW9uIGZvciBzZWN1cmluZyB0
aGUgaW1wbGljaXQgZmxvdywgSSB3b3VsZCByZXF1ZXN0IHRoYXQgdGhlIGRyYWZ0IGJlIHVwZGF0
ZWQgdG8gZGVzY3JpYmUgdGhpcyBtaXRpZ2F0aW9uLiAgQXQgdGhlIHNhbWUgdGltZSwgSeKAmW0g
ZmluZSB3aXRoIHRoZSBkcmFmdCByZWNvbW1lbmRpbmcgdGhlIGNvZGUgZmxvdyBvdmVyIHRoZSBp
bXBsaWNpdCBmbG93IHdoZW4gdGhpcyBtaXRpZ2F0aW9uIGlzIG5vdCB1c2VkLg0KDQoNCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFRoYW5rIHlvdSwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCkZyb206IE9BdXRoIDxvYXV0
aC1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo
YWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQoNClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTksIDIw
MTggMjozNCBBTQ0KDQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+DQoNClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJl
Y29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KDQoNCg0KSGkg
YWxsLA0KDQoNCg0KVGhlIGF1dGhvcnMgb2YgdGhlIE9BdXRoIFNlY3VyaXR5IFRvcGljcyBkcmFm
dCBjYW1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGFkZXF1
YXRlbHkgc2VjdXJlIHRoZSBpbXBsaWNpdCBmbG93IGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIHNp
bmNlIHBvdGVudGlhbCBzb2x1dGlvbnMgbGlrZSB0b2tlbiBiaW5kaW5nIG9yIEpBUk0gYXJlIGlu
IGFuIGVhcmx5IHN0YWdlIG9mIGFkb3B0aW9uLiBGb3IgdGhpcyByZWFzb24sIGFuZCBzaW5jZSBD
T1JTIGFsbG93cyBicm93c2VyLWJhc2VkIGFwcHMgdG8gc2VuZCByZXF1ZXN0cyB0byB0aGUgdG9r
ZW4gZW5kcG9pbnQsIFRvcnN0ZW4gc3VnZ2VzdGVkIHRvIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBj
b2RlIGluc3RlYWQgb2YgdGhlIGltcGxpY2l0IGdyYW50IGluIGNhbGwgY2FzZXMgaW4gaGlzIHBy
ZXNlbnRhdGlvbiAoc2VlaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9t
YXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5
LXRvcGljcy0wMSkuDQoNCg0KDQpBIGh1bSBpbiB0aGUgcm9vbSBhdCBJRVRGIzEwMyBjb25jbHVk
ZWQgc3Ryb25nIHN1cHBvcnQgZm9yIGhpcyByZWNvbW1lbmRhdGlvbnMuIFdlIHdvdWxkIGxpa2Ug
dG8gY29uZmlybSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4NCg0KDQoNClBsZWFzZSBwcm92
aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIgM3JkLg0KDQoNCg0KQ2lhbw0KDQpIYW5uZXMgJiBS
aWZhYXQNCg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls
IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp
dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl
bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3Jl
IG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFp
bGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxp
bmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt
aWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0
aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w
aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5OZXh0IHF1ZXN0aW9uIOKAkyBkb2VzbuKAmXQg
dXNpbmcgdGhlIEZvcm0gUG9zdCBSZXNwb25zZSBNb2RlDQo8YSBocmVmPSJodHRwczovL29wZW5p
ZC5uZXQvc3BlY3Mvb2F1dGgtdjItZm9ybS1wb3N0LXJlc3BvbnNlLW1vZGUtMV8wLmh0bWwiPmh0
dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1mb3JtLXBvc3QtcmVzcG9uc2UtbW9kZS0x
XzAuaHRtbDwvYT4gbWl0aWdhdGUgdGhlIHRocmVhdHMgeW914oCZcmUgZGVzY3JpYmluZyBiZWxv
dyBKb2huPyZuYnNwOyBJZiBzbywgSSBiZWxpZXZlIHRoZSBTZWN1cml0eSBUb3BpY3MgZHJhZnQg
c2hvdWxkIHNheSB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBi
ZWxpZXZlIHdlIG93ZSBpdCB0byByZWFkZXJzIHRvIHByZXNlbnQgdGhlIGNvbXBsZXRlIHBpY3R1
cmUsIHdoaWNoIGlzIHdoeSBJIGJlbGlldmUgdGhhdCBkZXNjcmliaW5nIHByb2ZpbGVzIHVzaW5n
IElEIFRva2VucyBhbmQgdGhlIEZvcm0gUG9zdCBSZXNwb25zZSBNb2RlIGFyZSBpbiBzY29wZS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5v
cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpKb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50Ojwv
Yj4gVHVlc2RheSwgTm92ZW1iZXIgMjAsIDIwMTggNzo0NyBBTTxicj4NCjxiPlRvOjwvYj4gb2F1
dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggU2Vj
dXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBp
bXBsaWNpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+WWVzIHRoZSBhdF9oYXNoIHByb3RlY3RzIHRo
ZSBjbGllbnQgZnJvbSBhY2NlcHRpbmcgYW4gaW5qZWN0ZWQgQVQuJm5ic3A7IDxvOnA+PC9vOnA+
PC9wPg0KPHA+VW5mb3J0dW5hdGVseSBpdCBkb2Vzbid0IGRvIGFueXRoaW5nIHRvIHByb3RlY3Qg
YWdhaW5zdCBsZWFrYWdlIGluIGxvZ3Mgb3IgcmVkaXJlY3RzLjxvOnA+PC9vOnA+PC9wPg0KPHA+
U28gd2l0aG91dCB0aGUgQVQgdXNpbmcgc29tZSBzb3J0IG9mIFBPUCBtZWNoYW5pc20gaXQgaXMg
aGFyZCB0byBzYXkgc2VuZGluZyBpdCBpbiBhIHJlZGlyZWN0IGlzIGEgZ29vZCBzZWN1cml0eSBw
cmFjdGljZS48bzpwPjwvbzpwPjwvcD4NCjxwPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMS8yMC8yMDE4IDQ6MzUgQU0sIFRvcnN0ZW4gTG9k
ZGVyc3RlZHQgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IaSBNaWtlLCA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIGFn
cmVlIHRoYXQgT0lEQyBoeWJyaWQgZmxvd3Mgb2ZmZXIgYWRkaXRpb25hbCBzZWN1cml0eSBvdmVy
IHRoZSBPQXV0aCBpbXBsaWNpdCBncmFudCBhbmQgYXJlIHVzZWQgaW4gdGhlIHdpbGQuIE9uIG15
IHNsaWRlcyBhbmQgaW4gdGhlIGluaXRpYWwgdmVyc2lvbiBvZiB0aGUgbmV3IHNlY3Rpb24sIHdl
IGhhZCBpbmNsdWRlZCB0aGUgaHlicmlkIE9JREMgZmxvd3MgYmVjYXVzZSBvZiB0aGVpciBrbm93
biB0b2tlbiBpbmplY3Rpb24gY291bnRlcm1lYXN1cmVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgbmV2ZXJ0aGVsZXNzIGZlZWwgdmVyeSB1
bmNvbWZvcnRhYmxlIHRvIHJlY29tbWVuZCB0aG9zZSBmbG93cyBhbmQgYW55IGZsb3cgaXNzdWlu
ZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBmcm9udCBjaGFubmVsLiBJbiB0aGUgY291cnNlIG9mIHRo
ZSBkZXRhaWxlZCByZXZpZXcgb2YgdGhlIG5ldyB0ZXh0IHdlIHJlYWxpemVkIHR3byBpc3N1ZXM6
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjEp
IFNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgZXhwb3NlZCBpbiB0aGUgVVJMLCBzdWNoIGZsb3dz
IHBvc3Nlc3MgYSBzaWduaWZpY2FudGx5IGhpZ2hlciByaXNrIHRvIGxlYWsgdGhlIGFjY2VzcyB0
b2tlbiAoZS5nLiB0aHJvdWdoIGJyb3dzZXIgaGlzdG9yeSwgb3BlbiByZWRpcmVjdGlvbiBhbmQg
ZXZlbiByZWZlcnJlciBoZWFkZXJzKSB0aGFuIHRoZSBjb2RlIGdyYW50LjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjIpIFRoZXJlIGlzIG5vIHZpYWJsZSB3YXkgdG8gc2VuZGVyIGNvbnN0cmFpbiBh
Y2Nlc3MgdG9rZW5zIGlzc3VlZCBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gR2l2ZW4gdGhlIFdHIGRl
Y2lkZWQgdG8gcmVjb21tZW5kIHVzZSBvZiBzZW5kZXIgY29uc3RyYWludCB0b2tlbnMgKDxhIGhy
ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5
LXRvcGljcy0wOSNzZWN0aW9uLTIuLjIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wOSNzZWN0aW9uLTIuLjI8L2E+KSwgaXQgc2Vl
bXMgY29udHJhZGljdG9yeSB0byByZWNvbW1lbmQgcmVzcG9uc2UgdHlwZXMgbm90IHN1cHBvcnRp
bmcgc3VjaCBhbiBhcHByb2FjaC4gPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+a2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRv
cnN0ZW4uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwcmU+QW0gMTkuMTEuMjAxOCB1bSAyMzoxMyBzY2hyaWViIE1pa2UgSm9uZXMgPGEgaHJlZj0i
bWFpbHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIj4mbHQ7
TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PC9hPjo8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGRl
c2NyaXB0aW9uIG9mIHRoZSBzaXR1YXRpb24gaXMgYW4gb3ZlcnNpbXBsaWZpY2F0aW9uLiZuYnNw
OyBPcGVuSUQgQ29ubmVjdCBzZWN1cmVzIHRoZSBpbXBsaWNpdCBmbG93IGFnYWluc3QgdG9rZW4g
aW5qZWN0aW9uIGF0dGFja3MgYnkgaW5jbHVkaW5nIHRoZSBhdF9oYXNoIChhY2Nlc3MgdG9rZW4g
aGFzaCkgaW4gdGhlIElEIFRva2VuLCBlbmFibGluZyB0aGUgY2xpZW50IHRvIHZhbGlkYXRlIHRo
YXQgdGhlIGFjY2VzcyB0b2tlbiB3YXMgY3JlYXRlZCBieSB0aGUgaXNzdWVyIGluIHRoZSBJRCBU
b2tlbiAod2hpY2ggaXMgYWxzbyB0aGUgT0F1dGggSXNzdWVyLCBhcyBkZXNjcmliZWQgaW4gUkZD
IDg0MTQpLiZuYnNwOyAoTm90ZSB0aGF0IHRoaXMgbWl0aWdhdGlvbiB3YXMgZGVzY3JpYmVkIGlu
IGRyYWZ0LWlldGYtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24uKTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5HaXZlbiB0aGUgcHJldmFsZW5jZSBvZiB0aGlz
IGtub3duLWdvb2Qgc29sdXRpb24gZm9yIHNlY3VyaW5nIHRoZSBpbXBsaWNpdCBmbG93LCBJIHdv
dWxkIHJlcXVlc3QgdGhhdCB0aGUgZHJhZnQgYmUgdXBkYXRlZCB0byBkZXNjcmliZSB0aGlzIG1p
dGlnYXRpb24uJm5ic3A7IEF0IHRoZSBzYW1lIHRpbWUsIEnigJltIGZpbmUgd2l0aCB0aGUgZHJh
ZnQgcmVjb21tZW5kaW5nIHRoZSBjb2RlIGZsb3cgb3ZlciB0aGUgaW1wbGljaXQgZmxvdyB3aGVu
IHRoaXMgbWl0aWdhdGlvbiBpcyBub3QgdXNlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IE9BdXRoIDxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnIj4mbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IE9uIEJlaGFs
ZiBPZiBIYW5uZXMgVHNjaG9mZW5pZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IE1vbmRh
eSwgTm92ZW1iZXIgMTksIDIwMTggMjozNCBBTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBv
YXV0aCA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZn
dDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogW09BVVRILVdHXSBPQXV0aCBT
ZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9m
IGltcGxpY2l0PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PkhpIGFsbCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+
VGhlIGF1dGhvcnMgb2YgdGhlIE9BdXRoIFNlY3VyaXR5IFRvcGljcyBkcmFmdCBjYW1lIHRvIHRo
ZSBjb25jbHVzaW9uIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGFkZXF1YXRlbHkgc2VjdXJl
IHRoZSBpbXBsaWNpdCBmbG93IGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIHNpbmNlIHBvdGVudGlh
bCBzb2x1dGlvbnMgbGlrZSB0b2tlbiBiaW5kaW5nIG9yIEpBUk0gYXJlIGluIGFuIGVhcmx5IHN0
YWdlIG9mIGFkb3B0aW9uLiBGb3IgdGhpcyByZWFzb24sIGFuZCBzaW5jZSBDT1JTIGFsbG93cyBi
cm93c2VyLWJhc2VkIGFwcHMgdG8gc2VuZCByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQs
IFRvcnN0ZW4gc3VnZ2VzdGVkIHRvIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQg
b2YgdGhlIGltcGxpY2l0IGdyYW50IGluIGNhbGwgY2FzZXMgaW4gaGlzIHByZXNlbnRhdGlvbiAo
c2VlaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xp
ZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMSku
PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkEgaHVtIGlu
IHRoZSByb29tIGF0IElFVEYjMTAzIGNvbmNsdWRlZCBzdHJvbmcgc3VwcG9ydCBmb3IgaGlzIHJl
Y29tbWVuZGF0aW9ucy4gV2Ugd291bGQgbGlrZSB0byBjb25maXJtIHRoZSBkaXNjdXNzaW9uIG9u
IHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5QbGVhc2UgcHJvdmlkZSBhIHJlc3BvbnNlIGJ5IERlY2VtYmVyIDNyZC48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Q2lhbzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPkhhbm5lcyAmYW1wOyBSaWZhYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48
L286cD48L3ByZT4NCjxwcmU+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg
ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi
ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg
Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig
c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Ljxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86
cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0
aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5n
IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v
cmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_DM5PR00MB02937F639067DC15DC9D80D4F5D90DM5PR00MB0293namp_--


From nobody Tue Nov 20 13:10:48 2018
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 9C00612F1AB for ; Tue, 20 Nov 2018 13:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lkQ8liCJthKp for ; Tue, 20 Nov 2018 13:10:42 -0800 (PST)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 D3E65128D0C for ; Tue, 20 Nov 2018 13:10:41 -0800 (PST)
Received: by mail-ot1-x331.google.com with SMTP id n46so2998707otb.9 for ; Tue, 20 Nov 2018 13:10:41 -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=BPUslztWFccLlks9u3t5iyEwj1cTa4SlLJI7eT9Txy8=; b=NirPR7ZQLi6Kb7UkiW3Pums0aXI3PxAk8+ihYmYZx4zA4qrpyrozUlFLLDIPdDnu/A nWTM8vCtCiCnZYwcLtPhaydHtCKfOMTnmicmRJUGkak33Twhqnhp3nSu+EuvJ1l28TgT 4Hspc3841U410ShVymyb2edCNBMyOYxfbY5FlBxQL69hbY40yBvSuTN4+HGn4SbL6/s7 5KXb8e50muc/bFXQtUudw+CKfqM3NjKi6dyknN+HIa0ScMZiGKo067phcPKOCG89AYVl H5XvMu+0RmZROiCRUN0PUdNmJERYWDoFU57+ySTA7/e/7Kt2s9sYIvxvihjmCklUpkYV b1mQ==
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=BPUslztWFccLlks9u3t5iyEwj1cTa4SlLJI7eT9Txy8=; b=ruq1/gaEhJNCn8Icsumc6/++tZOLTrlFQanAIRi1T71y1IqSF1kyC4HFqFi04T6w+x IVObjXU0JuSd07NQG/Zv3COH51Ges1DzMIgrctTvCJBCxlSnMsSUX8lzD5HpGts9e7p9 iTQDFFFZofLsPA+KdQcD2yUz78TBcp4AmSAf3vczMLP32vzDJjfaTgoCw/bWXLPTw3TF ktIkZt5eLB07qhw7X3eeSM18oUx33f2PK5Zsl8Q87pAYK22+TPK29ma1haZ/J33SWWGI faIgTNxgU3PfmjdfdW+vFWBsbYbs6zkgqtazu1XCBxcjTAGKdAZrQPHfPYZVTYHl9bxi kOvQ==
X-Gm-Message-State: AA+aEWbNSG0M/M2qQQqsCizZWco0i9T1BmM7JdhpQZn5xNmahknuyCsR xic7uqbJnt4hM1n93vSUFkyv6QR/nAwg7XN/vmgfSkQ0
X-Google-Smtp-Source: AFSGD/Vz09J6PLbKlcYk9jNIpRrepxpzoVJ6ayb+XEKiHhNt69Mj6fGckSlB5mwlWyGTIKn9jUvmqBfSCSB8396WQyw=
X-Received: by 2002:a9d:2ce7:: with SMTP id e36mr2242231otd.297.1542748240546;  Tue, 20 Nov 2018 13:10:40 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Adam Cashion 
Date: Tue, 20 Nov 2018 15:01:51 -0600
Message-ID: 
To: oauth , Adam Cashion 
Content-Type: multipart/alternative; boundary="000000000000db1307057b1f10a1"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 121, Issue 48
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, 20 Nov 2018 21:10:47 -0000

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

On Tue, Nov 20, 2018, 2:56 PM  Send OAuth mailing list submissions to
>         oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         oauth-request@ietf.org
>
> You can reach the person managing the list at
>         oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt
>       (Aaron Parecki)
>    2. Re: Refresh Token Expiration (George Fletcher)
>    3. Re: Refresh Token Expiration (Aaron Parecki)
>
>
>
> ---------- Forwarded message ----------
> From: Aaron Parecki 
> To: Torsten Lodderstedt 
> Cc: OAuth WG 
> Bcc:
> Date: Tue, 20 Nov 2018 12:37:34 -0800
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.t=
xt
> The new section on refresh tokens is great! I have a couple
> questions/comments about some of the details.
>
> Authorization servers may revoke refresh tokens automatically in case
>> of a security event, such as:
>> o  logout at the authorization server
>
>
> This doesn't sound like the desired behavior for mobile apps, where the
> user's expectation of how long they are logged in to the mobile app is no=
t
> tied to their web session where they authorized the app. However this doe=
s
> likely match a user's expectation when authorizing a browser-based app.
> Should this be clarified that it should not apply to the mobile app case,
> or only apply to browser-based apps?
>
> Refresh tokens should expire if the client has been inactive for some tim=
e
>
>
> This is a good suggestion, but I think it would benefit from a little mor=
e
> clarity. Specifically pointing out that what counts as "activity" is use =
of
> the access token and/or refresh token, if that's the intention. That will
> help avoid confusion that "inactivity" may be referring to the user's
> session at the authorization server.
>
> Is this supposed to be a capital "SHOULD" or lowercase "should"?
>
> It is also unclear whether this is meant to apply to public clients,
> private clients, or both, as well as whether it should apply to mobile ap=
ps
> or browser-based apps or both. I am curious what the intent is here, sinc=
e
> I feel like that can have some serious implications for the user experien=
ce
> in some cases and is worth pointing out.
>
> Lastly, minor nit, I see the comment about changing occurrences of "SHALL=
"
> to "MUST", but the new refresh token section still has two uses of "SHALL=
".
>
> Thanks! Overall I'm happy to see this guidance!
>
> ----
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Tue, Nov 20, 2018 at 11:33 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> the new revision contains the following changes:
>>
>> * added section on refresh tokens
>> * additional justifications for recommendation for code
>> * refactored 2.1 in order to distinguish CSRF, authz response replay and
>> mix-up (based on feedback by Joseph Heenan)
>> * added requirement to authenticate clients during code exchange (PKCE o=
r
>> client credential) to 2.1.1.
>> * changed occurrences of SHALL to MUST
>>
>> As always: looking forward for your feedback.
>>
>> kind regards,
>> Torsten.
>>
>> > Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
>> >
>> >
>> > 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 Security Best Current Practice
>> >        Authors         : Torsten Lodderstedt
>> >                          John Bradley
>> >                          Andrey Labunets
>> >                          Daniel Fett
>> >       Filename        : draft-ietf-oauth-security-topics-10.txt
>> >       Pages           : 38
>> >       Date            : 2018-11-20
>> >
>> > Abstract:
>> >   This document describes best current security practice for OAuth 2.0=
.
>> >   It updates and extends the OAuth 2.0 Security Threat Model to
>> >   incorporate practical experiences gathered since OAuth 2.0 was
>> >   published and covers new threats relevant due to the broader
>> >   application of OAuth 2.0.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>> >
>> > There are also htmlized versions available at:
>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>> >
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-1=
0
>> >
>> > A diff from the previous version is available at:
>> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-1=
0
>> >
>> >
>> > 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/
>> >
>> > _______________________________________________
>> > 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
>>
>
>
>
> ---------- Forwarded message ----------
> From: George Fletcher 
> To: Torsten Lodderstedt , oauth@ietf.org
> Cc:
> Bcc:
> Date: Tue, 20 Nov 2018 15:37:57 -0500
> Subject: Re: [OAUTH-WG] Refresh Token Expiration
> Hi Torsten,
>
> This is the module I much prefer. By default all refresh_tokens are bound
> to the user's authenticated session. When the authentication session is
> terminated, the refresh_tokens are invalidated. If a client wants to get =
a
> refresh_token that is NOT bound to an authentication session, then it muc=
h
> explicitly request the "offline_access" scope which then provides a conse=
nt
> interaction with the user which allows the user to know that this client
> wants to access their resources even when the user isn't logged in
> (present). This also provides the AS with the ability to control which
> clients are authorized to request "offline_access" and hence restrict tha=
t
> capability to know/approved clients.
>
> We've implemented this module in two different Authorization Servers.
>
> Thanks,
> George
>
> On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:
>
> Hi all,
>
> I=E2=80=98m preparing a new section on Refresh Token best practices for t=
he Security BCP. I=E2=80=98m wondering whether anyone has implemented a bin=
ding of the refresh token=E2=80=98s expiration/revocation with the state of=
 the session the refresh token was issued in/for. So do you revoke refresh =
tokens when the user logs out from the AS or the session terminated for oth=
er reasons?
>
> kinds regards,
> Torsten.
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Aaron Parecki 
> To: gffletch=3D40aol.com@dmarc.ietf.org
> Cc: Torsten Lodderstedt , OAuth WG <
> oauth@ietf.org>
> Bcc:
> Date: Tue, 20 Nov 2018 12:56:13 -0800
> Subject: Re: [OAUTH-WG] Refresh Token Expiration
> Hi George,
>
> Reading this description, am I understanding correctly that you *always*
> return a refresh token to every client? Are there any situations in which=
 a
> refresh token would not be returned? Specifically I'm wondering about how
> this applies to browser-based apps using the authorization code flow and
> refresh tokens.
>
> ----
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Tue, Nov 20, 2018 at 12:38 PM George Fletcher  40aol.com@dmarc.ietf.org> wrote:
>
>> Hi Torsten,
>>
>> This is the module I much prefer. By default all refresh_tokens are boun=
d
>> to the user's authenticated session. When the authentication session is
>> terminated, the refresh_tokens are invalidated. If a client wants to get=
 a
>> refresh_token that is NOT bound to an authentication session, then it mu=
ch
>> explicitly request the "offline_access" scope which then provides a cons=
ent
>> interaction with the user which allows the user to know that this client
>> wants to access their resources even when the user isn't logged in
>> (present). This also provides the AS with the ability to control which
>> clients are authorized to request "offline_access" and hence restrict th=
at
>> capability to know/approved clients.
>>
>> We've implemented this module in two different Authorization Servers.
>>
>> Thanks,
>> George
>>
>> On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:
>>
>> Hi all,
>>
>> I=E2=80=98m preparing a new section on Refresh Token best practices for =
the Security BCP. I=E2=80=98m wondering whether anyone has implemented a bi=
nding of the refresh token=E2=80=98s expiration/revocation with the state o=
f the session the refresh token was issued in/for. So do you revoke refresh=
 tokens when the user logs out from the AS or the session terminated for ot=
her reasons?
>>
>> kinds regards,
>> Torsten.
>>
>>
>>
>> _______________________________________________
>> 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
>

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



    On =
Tue, Nov 20, 2018, 2:56 PM  <o=
auth-request@ietf.org wrote:
    Se=
nd OAuth mailing list submissions to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org
    

    
To subscribe or unsubscribe via the World Wide Web, visit
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o=
rg/mailman/listinfo/oauth
    
or, via email, send a message with subject or body 'help' to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org
    

    
You can reach the person managing the list at
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org
    

    
When replying, please edit your Subject line so it is more specific
    
than "Re: Contents of OAuth digest..."
    
Today's Topics:
    

    
=C2=A0 =C2=A01. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt
    
=C2=A0 =C2=A0 =C2=A0 (Aaron Parecki)
    
=C2=A0 =C2=A02. Re: Refresh Token Expiration (George Fletcher)
    
=C2=A0 =C2=A03. Re: Refresh Token Expiration (Aaron Parecki)
    



    ---------- Forwarded message ----------
    From:=C2=A0Aaron Par=
ecki <aaron@parecki.com>
    To:=C2=A0Torsten Lodderstedt <=
torsten@lodderstedt.net>
    Cc:=C2=A0OAuth WG <oauth@ietf.org>=

    Bcc:=C2=A0
    Date:=C2=A0Tue, 20 Nov 2018 12:37:34 -0800
    Subject:=C2=
=A0Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
    The new section on refresh tokens is great! I have a couple q=
uestions/comments about some of the details.

    Authorization servers may revoke refresh t=
okens automatically in case
    of a security event, such as:
    o=C2=A0 log=
out at the authorization server
    =C2=A0
    Thi=
s doesn't sound like the desired behavior for mobile apps, where the us=
er's expectation of how long they are logged in to the mobile app is no=
t tied to their web session where they authorized the app. However this doe=
s likely match a user's expectation when authorizing a browser-based ap=
p. Should this be clarified that it should not apply to the mobile app case=
, or only apply to browser-based apps?

    Refresh tokens should expire if the clien=
t has been inactive for some time

    This is a=
 good suggestion, but I think it would benefit from a little more clarity. =
Specifically pointing out that=C2=A0what counts as "activity" is =
use of the access token and/or refresh token, if that's the intention. =
That will help avoid confusion that "inactivity" may be referring=
 to the user's session at the authorization server.

    Is this supposed to be a capital "SHOULD" or lowercase &quo=
t;should"?

    It is also unclear whether this is=
 meant to apply to public clients, private clients, or both, as well as whe=
ther it should apply to mobile apps or browser-based apps or both. I am cur=
ious what the intent is here, since I feel like that can have some serious =
implications for the user experience in some cases and is worth pointing ou=
t.

    Lastly, minor nit, I see the commen=
t about changing occurrences of "SHALL" to "MUST", but =
the new refresh token section still has two uses of "SHALL".

    Thanks! Overall I'm happy to see this guida=
nce!

    ----
    Aaron Parecki


    =


    On Tue, N=
ov 20, 2018 at 11:33 AM Torsten Lodderstedt <torsten@lodderstedt.ne=
t> wrote:
    Hi all, 
    

    
the new revision contains the following changes:
    

    
* added section on refresh tokens 
    
* additional justifications for recommendation for code
    
* refactored 2.1 in order to distinguish CSRF, authz response replay and mi=
x-up (based on feedback by Joseph Heenan)
    
* added requirement to authenticate clients during code exchange (PKCE or c=
lient credential) to 2.1.1.
    
* changed occurrences of SHALL to MUST
    

    
As always: looking forward for your feedback.
    

    
kind regards,
    
Torsten. 
    

    
> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
    
> 
    
> 
    
> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
    
> 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 Security Best Current Practice
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=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 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 Andrey Labunets
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Daniel Fett
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
ietf-oauth-security-topics-10.txt
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 38
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2018-11-20
    
> 
    
> Abstract:
    
>=C2=A0 =C2=A0This document describes best current security practice for=
 OAuth 2.0.
    
>=C2=A0 =C2=A0It updates and extends the OAuth 2.0 Security Threat Model=
 to
    
>=C2=A0 =C2=A0incorporate practical experiences gathered since OAuth 2.0=
 was
    
>=C2=A0 =C2=A0published and covers new threats relevant due to the broad=
er
    
>=C2=A0 =C2=A0application of OAuth 2.0.
    
> 
    
> 
    
> The IETF datatracker status page for this draft is:
    
> https://datatracke=
r.ietf.org/doc/draft-ietf-oauth-security-topics/
    
> 
    
> There are also htmlized versions available at:
    
> https://tools.ietf.or=
g/html/draft-ietf-oauth-security-topics-10
    
> https://dat=
atracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
    
> 
    
> A diff from the previous version is available at:
    
> https://www.i=
etf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
    
> 
    
> 
    
> Please note that it may take a couple of minutes from the time of subm=
ission
    
> 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/oau=
th
    

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

    



    ---------- Forwarded message ----------
    From:=C2=A0George Fl=
etcher <    gffletch@aol.com>
    To:=C2=A0Torsten Lodderstedt <=
torsten@lodderstedt.net>, oauth@ietf.org
    Cc:=C2=A0
    Bcc:=C2=
=A0
    Date:=C2=A0Tue, 20 Nov 2018 15:37:57 -0500
    Subject:=C2=A0Re: [OAU=
TH-WG] Refresh Token Expiration
    
 =20
   =20
 =20
  
    
    Hi Torsten,
    
      
    
      This is the module I much prefer. By default all refresh_tokens
      are bound to the user's authenticated session. When the
      authentication session is terminated, the refresh_tokens are
      invalidated. If a client wants to get a refresh_token that is NOT
      bound to an authentication session, then it much explicitly
      request the "offline_access" scope which then provides a co=
nsent
      interaction with the user which allows the user to know that this
      client wants to access their resources even when the user isn't
      logged in (present). This also provides the AS with the ability to
      control which clients are authorized to request "offline_access&=
quot;
      and hence restrict that capability to know/approved clients.
    
      
    
      We've implemented this module in two different Authorization
      Servers.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 11/15/18 9:28 AM=
, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi all,

I=E2=80=98m preparing a new section on Refresh Token best practices for the=
 Security BCP. I=E2=80=98m wondering whether anyone has implemented a bindi=
ng of the refresh token=E2=80=98s expiration/revocation with the state of t=
he session the refresh token was issued in/for. So do you revoke refresh to=
kens when the user logs out from the AS or the session terminated for other=
 reasons?

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

    
    
    
    
    
  
    




    ---------- Forwarded message ----------
    From:=C2=A0Aaron Par=
ecki <aaron@parecki.com>
    To:=C2=A0gffletch=3D40aol.com@dm=
arc.ietf.org
    Cc:=C2=A0Torsten Lodderstedt <torsten@lodderste=
dt.net>, OAuth WG <oauth@ietf.org>
    Bcc:=C2=A0
    Date:=C2=
=A0Tue, 20 Nov 2018 12:56:13 -0800
    Subject:=C2=A0Re: [OAUTH-WG] Refresh =
Token Expiration
    Hi George,

    Reading this description, am I understanding correctly that you *alw=
ays* return a refresh token to every client? Are there any situations in wh=
ich a refresh token would not be returned? Specifically I'm wondering a=
bout how this applies to browser-based apps using the authorization code fl=
ow and refresh tokens.

    ----
    Aaron Parecki
    =



    On Tue, Nov 20, 2018 at 12:38 PM George Fletcher <gffletch=3D=
40aol.com@dmarc.ietf.org> wrote:
    
 =20
   =20
 =20
  
    
    Hi Torsten,
    
      
    
      This is the module I much prefer. By default all refresh_tokens
      are bound to the user's authenticated session. When the
      authentication session is terminated, the refresh_tokens are
      invalidated. If a client wants to get a refresh_token that is NOT
      bound to an authentication session, then it much explicitly
      request the "offline_access" scope which then provides a co=
nsent
      interaction with the user which allows the user to know that this
      client wants to access their resources even when the user isn't
      logged in (present). This also provides the AS with the ability to
      control which clients are authorized to request "offline_access&=
quot;
      and hence restrict that capability to know/approved clients.
    
      
    
      We've implemented this module in two different Authorization
      Servers.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 11/15/18 9:28 AM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi all,

I=E2=80=98m preparing a new section on Refresh Token best practices for the=
 Security BCP. I=E2=80=98m wondering whether anyone has implemented a bindi=
ng of the refresh token=E2=80=98s expiration/revocation with the state of t=
he session the refresh token was issued in/for. So do you revoke refresh to=
kens when the user logs out from the AS or the session terminated for other=
 reasons?

kinds regards,
Torsten.
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
O=
Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  
    

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

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

    

--000000000000db1307057b1f10a1--


From nobody Tue Nov 20 13:15:33 2018
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 1AF7E126DBF for ; Tue, 20 Nov 2018 13:15:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jN1EBy8Zp1r4 for ; Tue, 20 Nov 2018 13:15:28 -0800 (PST)
Received: from sonic302-4.consmr.mail.bf2.yahoo.com (sonic302-4.consmr.mail.bf2.yahoo.com [74.6.135.43]) (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 9A6FE124D68 for ; Tue, 20 Nov 2018 13:15:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542748527; bh=EMZ69Mq4MXVLrjzL4pqdXx5Q7+vrcnQgOUKC2BCHc/E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=nYVqbDVLWADOdSr2syntnFVHg03cAfhY8mtKeiuYIXkow+kgtjcEhLCadlYXIpzLCA++kbxjUCWLiuKfZn83q091buezmDjm26SLiKrYyDjsEO6mKFPD3n22GqNbx2F1sI6QijxGsVZq/yDh9TJtC2wTjMgqT2W7QqykCpuDJM3Sn3WcLY/lL02B4bk6ECuADU2GbhfG7SHjEQ41E5w5VEmu/2AwXYKTeDGjrNyw9T/B5WIHpJ1LxCKbLPDBi5jEGSWMs6lxmyZYx4uA2B8xEH1RFgOzwZ/JzQ7pcQwQqysNfqEa15TDE/u+8EC5ZTG5D1rGTm77A7uLk39tWrMO2w==
X-YMail-OSG: bGE4DpAVM1mnapl0zBaAhaDzjJzzSxO94Fhy2CZFJIVNQGc9kmToc0MPvE3IL8i ZFSkeH4XN.AhO.2gNB4sAfbRIqJsYjqrEU5.xRfTmP1Dzg8L83Cc1JWWJQ8V3Si7GbpBI4BF8YM5 Zqh5X2Kjd63j36.FUZnye6ncoBN26UCowXWW2neMcQPg3l5OtUtu1vxj3pr5dAI4ZqBi4G8Gvp50 cuqT3kAM_pmRTBr5hh6O9NBGd2UlQT1ZcjMPRKFYnwCIpmCmiTckdeUdgCn1Oj54n4dGOyik16kh nOqWMaqAj.gpnZ.yK_OOXctDpm5SdKArc56mebXh9JkW_AmfOZZYxoNJ13VRzL2I0xz6y0Kw7EyP 1HNOvKC8rjmnZuiSFMBeRJBJfNbczZoR_h6tZdTQ6km_sZaTdHeSNiXmFJVUAOAC5pHNKFm9Rt7z .vuA7oYj2J2h33ECJjPCMYIfLd8ESDeJQkdwpXs4x_ja68wpC9VGG6FWWPw_P494E397JmMpyCLx t3xQ_0sQeAYKvd2IV8iQwEMBZjs_ddTYaevlMOwt0727l0BuVtWJfppjwdamxV7yyO7AS0bmKD4c htfGsPKo8NN5h1mplj.RBu21gZcZTBG8zkwadgjKlgG9e3HNkeNiY.Lm5dl3R5RF1BAHMYhVGiHX EUaiqxQkao6ECDGYScGOtcvZ86jo6PPxL2Zvbj3RqfdOdG38eXJCoxmK2U3m1l7we4hoXfAZ.wvS 699fpnMsPsHp_0fxN1lTarMgwbzkSDO_qTZCiT0_jvXT6.0Wst4LHTHa2Q1vG0Lo0Ye1i8JBkp4J 3K0dzgiVqr7arrr95_PIRbw25tUj1vOfSdbW_ZWs7LjbDVvVTAP0A2ObXJbW.tpjC37FCkLnNcSo 8HYK685vAekJzJEVpcjoi1IFO3Mgu0YeqEu80V5kco80qCPjyXe_a5q5.BYAncbCGY5RflZe_oiu dLDFsNoXZN6gjf2EkyYlXWbq.bPN1U7O3iC_x9MWLUdNgceuV7l5IPiGcWkursysbYAyWYD5t9wg 6lVb1ZengiUkrzMgHI2NFockZ2kpACvR3t0UKlqVQly68JwL_4m6p6LG654WY02EwpEBo
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Tue, 20 Nov 2018 21:15:27 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.132.163]) ([184.165.8.99]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0b547b0fb3839b3fe5131aba940e477c;  Tue, 20 Nov 2018 21:15:27 +0000 (UTC)
To: Aaron Parecki 
Cc: Torsten Lodderstedt , OAuth WG 
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com>
Date: Tue, 20 Nov 2018 16:15:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------5286C6278D1CDDF584E3EC39"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 20 Nov 2018 21:15:31 -0000

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

Hi Aaron,

We don't issue refresh_tokens for any implicit flow. So if a browser 
based app were to use the code flow, we would issue a refresh_token. 
Restricting which clients can receive refresh_tokens (or based on some 
other policy) is not a significant addition. However, for most browser 
apps, we have a module the relying party can deploy that handles all the 
code flow semantics on the server side and then the SPA can just request 
a new access_token from the server side module. The module also handles 
sessions management.

Personally, I'm not crazy about refresh_tokens being present in 
browsers. Browsers should just re-authorize if they can't use a 
server-side component for tokens management. OIDC provides a 
"prompt=none" mechanism that allows the browser app to request a new 
token in a hidden iframe. OAuth2 doesn't describe this flow. Note that 
full authentications of users should NOT happen in iframes due to 
click-jacking attacks.

Thanks,
George

On 11/20/18 3:56 PM, Aaron Parecki wrote:
> Hi George,
>
> Reading this description, am I understanding correctly that you 
> *always* return a refresh token to every client? Are there any 
> situations in which a refresh token would not be returned? 
> Specifically I'm wondering about how this applies to browser-based 
> apps using the authorization code flow and refresh tokens.
>
> ----
> Aaron Parecki
> aaronparecki.com 
>
>
>
> On Tue, Nov 20, 2018 at 12:38 PM George Fletcher 
> > 
> wrote:
>
>     Hi Torsten,
>
>     This is the model I much prefer. By default all refresh_tokens are
>     bound to the user's authenticated session. When the authentication
>     session is terminated, the refresh_tokens are invalidated. If a
>     client wants to get a refresh_token that is NOT bound to an
>     authentication session, then it much explicitly request the
>     "offline_access" scope which then provides a consent interaction
>     with the user which allows the user to know that this client wants
>     to access their resources even when the user isn't logged in
>     (present). This also provides the AS with the ability to control
>     which clients are authorized to request "offline_access" and hence
>     restrict that capability to know/approved clients.
>
>     We've implemented this module in two different Authorization Servers.
>
>     Thanks,
>     George
>
>     On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:
>>     Hi all,
>>
>>     I‘m preparing a new section on Refresh Token best practices for the Security BCP. I‘m wondering whether anyone has implemented a binding of the refresh token‘s expiration/revocation with the state of the session the refresh token was issued in/for. So do you revoke refresh tokens when the user logs out from the AS or the session terminated for other reasons?
>>
>>     kinds regards,
>>     Torsten.
>>
>>
>>     _______________________________________________
>>     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
>


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


  
    
  
  
    Hi Aaron,
    
      
    
      We don't issue refresh_tokens for any implicit flow. So if a
      browser based app were to use the code flow, we would issue a
      refresh_token. Restricting which clients can receive
      refresh_tokens      (or based on some other
        policy) is not a significant addition. However, for most
      browser apps, we have a module the relying party can deploy that
      handles all the code flow semantics on the server side and then
      the SPA can just request a new access_token from the server side
      module. The module also handles sessions management.
    
      
    
      Personally, I'm not crazy about refresh_tokens being present in
      browsers. Browsers should just re-authorize if they can't use a
      server-side component for tokens management. OIDC provides a
      "prompt=none" mechanism that allows the browser app to request a
      new token in a hidden iframe. OAuth2 doesn't describe this flow.
      Note that full authentications of users should NOT happen in
      iframes due to click-jacking attacks.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 11/20/18 3:56 PM, Aaron Parecki
      wrote:
    
    
    
    
    
      
      
      
    
      
    
        
    On Tue, Nov 20, 2018 at 12:38 PM George Fletcher
          <gffletch=40aol.com@dmarc.ietf.org>
          wrote:
    
        
    
        
    
          
     Hi Torsten,
    
              
    
              This is the model I much prefer. By default all
              refresh_tokens are bound to the user's authenticated
              session. When the authentication session is terminated,
              the refresh_tokens are invalidated. If a client wants to
              get a refresh_token that is NOT bound to an authentication
              session, then it much explicitly request the
              "offline_access" scope which then provides a consent
              interaction with the user which allows the user to know
              that this client wants to access their resources even when
              the user isn't logged in (present). This also provides the
              AS with the ability to control which clients are
              authorized to request "offline_access" and hence restrict
              that capability to know/approved clients.
    
              
    
              We've implemented this module in two different
              Authorization Servers.
    
              
    
              Thanks,
    
              George
    
            
    
            
    On
              11/15/18 9:28 AM, Torsten Lodderstedt wrote:
    
            
    
            
    
              
    Hi all,

I‘m preparing a new section on Refresh Token best practices for the Security BCP. I‘m wondering whether anyone has implemented a binding of the refresh token‘s expiration/revocation with the state of the session the refresh token was issued in/for. So do you revoke refresh tokens when the user logs out from the AS or the session terminated for other reasons?

kinds regards,
Torsten.
    
              
    
              
    
              
    
              
    _______________________________________________
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
    
        
    
      
    
    
    
    
    
  


--------------5286C6278D1CDDF584E3EC39--


From nobody Tue Nov 20 13:40:45 2018
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 6C761130DD6 for ; Tue, 20 Nov 2018 13:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Vphmc7-KKtWZ for ; Tue, 20 Nov 2018 13:40:41 -0800 (PST)
Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (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 2236F12F1AB for ; Tue, 20 Nov 2018 13:40:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542750039; bh=Rsvtzv6j8bRHXod3YLwgFL6ttGwJXlT5z5K/1NmjC9I=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=fSig4MdWdc7IS/GOOkP+Oixe7qVtxsq2srFnhJfP4PrxiB72lynfCSThAVBCLieExO4rOmyw2USxthNilTsfE3zlLerZ3nJffKSiH4A8C1/qclQeKtKS5hqZ6/3Ph50tzixXlu4918y730hTqVLh3Yz4VgOOfacFK99GOldGxXRirapiXDDiyCWJMkLOOqyGuZ5u+BZYju3Q7fVcYBaDVmK3zO/JvlGPeIRL5NBYGoW0UdGxd4RonEAXR2Qnv6nKGt7E6U7YCBBamGWwmWPqD9+eNCYKeu9+L6Gc1QFkDBnar/jCa5ZJTqpe4kJz9QdzfEGcJlBfAhWRy5tdYDFJ4Q==
X-YMail-OSG: 5zizSRAVM1ktp0qB4pFDNp2L8LScQxHV5YvAjD19xRD23w8Ze.CIrNmJh2q_A5r dmOLchNIAJjM7rykdbAxXpcNz2Vw1m5.7dK4_6mSjzWI3y8AOlrSf9ifBBUc07KiXDEluaPTfYLO uzwHk5BPC4xrN5d1jS3r37A6hjQ92VU1qPxr6wsp4bGhP2dCwaryQut316k7HDT7ywyy8h68H9qM SaGA.erMEpj.YJw8TqwGhJuRgKnIFy0MhJqKSB9u9UDcPp751BK7pMFZk_ODiXD_Tvjkh7RTrlBJ SItihHCG6Jtyr2eUaBFr_z6CwxoyWHzsZloweQIHH4ISnC19lNW76hU8.1VEwZ3nZIZjf1XzhRS. jvvWOMEn3f1xxVmXQYVJHfExCtwmiVmWTVHumOyEhTZk1NtufEbR6ms_Yx1_RowsA.SqVAyoSPsA YhzQqhjDubb9725xmV4SttJozuP.wJrzQicdpxbyAWpiCZJPK55XSNqliOMFRVVwBv3_VRqIsy_a f3nN5Syn5PlTmK0eUlUWtHAL56uUv4ojqmC_5v9aPmE3T7hDTKZGuqYAgiE1kMcwqZ1QAjrZovw5 uASce4RsVONeZj_66mdFxOxExDj9sCiLSTH1YQl4upYXRkV.qD3QU9D4vE3tFLTsFxvhEhld6qmw vy0muWyvY.fvp07ItgISoSfcE_GIXl8LGSMk7vbRVrbZpdgHLlPCCBeMcHH3rpMyLjFfAcbxgqgV Vs.rSz4qUCLWbafZjC4CWfuEvVkqFBAtXgclneiHT3tEx95LeVKvxyjb6D9QagFbpxpEAPuk1HkE BlBFIOUeF6D3jCsGqfma3keUI3jeHsCAhkUqJnj9LKyN8T4XcG9YzRl.XmHFnEPe5qKK8wzDtp3B qCK.xJDvVkLzBAEImz09fslzLBljzy202pD7LjT.QWW6dGBfhh8TqIwabkscQgQWmZ8Q1ZpvJ1CV GX6jj9vcx_dNE5nvq108F5Pbu4._0ZLmggn8OkyGI0Oq7biLvbgKKJ716vAZVmvu7CzSyOboYVZs lslRvJruXOdE6_uI2J8e4bEPtELPnX0MrpX9QBqhiI5Al4lM-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Tue, 20 Nov 2018 21:40:39 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.132.163]) ([184.165.8.99]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6be93cb21bc528b4a99271bbe5682c1f;  Tue, 20 Nov 2018 21:40:35 +0000 (UTC)
To: Mike Jones , John Bradley , "oauth@ietf.org" 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>
Date: Tue, 20 Nov 2018 16:40:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------607C51A3C9400054CB1DB458"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 20 Nov 2018 21:40:44 -0000

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

Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but 
it doesn't prevent the token from traversing through the browser. So a 
man-in-the-browser attack may be able to intercept the values. It should 
help with leakage in logs.

Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:
>
> Next question – doesn’t using the Form Post Response Mode 
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html 
> mitigate the threats you’re describing below John?  If so, I believe 
> the Security Topics draft should say this.
>
> I believe we owe it to readers to present the complete picture, which 
> is why I believe that describing profiles using ID Tokens and the Form 
> Post Response Mode are in scope.
>
> -- Mike
>
> *From:* OAuth  *On Behalf Of * John Bradley
> *Sent:* Tuesday, November 20, 2018 7:47 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend 
> authorization code instead of implicit
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in 
> logs or redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say 
> sending it in a redirect is a good security practice.
>
> John B.
>
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
>     Hi Mike,
>
>     I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.
>
>     I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues:
>
>     1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
>
>     2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach.
>
>     kind regards,
>
>     Torsten.
>
>         Am 19.11.2018 um 23:13 schrieb Mike Jones
>         :
>
>         This description of the situation is an oversimplification.  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>
>           
>
>         Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
>
>           
>
>                                                                          Thank you,
>
>                                                                          -- Mike
>
>           
>
>         From: OAuth   On Behalf Of Hannes Tschofenig
>
>         Sent: Monday, November 19, 2018 2:34 AM
>
>         To: oauth 
>
>         Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>
>           
>
>         Hi all,
>
>           
>
>         The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>
>           
>
>         A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
>
>           
>
>         Please provide a response by December 3rd.
>
>           
>
>         Ciao
>
>         Hannes & Rifaat
>
>           
>
>         IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
>
>         _______________________________________________
>
>         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


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


  
    
  
  
    Hi Mike,
    
      
    
      The Form Post Response Mode keeps the access_token out of the URL,
      but it doesn't prevent the token from traversing through the
      browser. So a man-in-the-browser attack may be able to intercept
      the values. It should help with leakage in logs.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 11/20/18 4:00 PM, Mike Jones wrote:
    
    
    
    
    
      
      
      
      
    
        
    Next question –
            doesn’t using the Form Post Response Mode
            https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
            mitigate the threats you’re describing below John?  If so, I
            believe the Security Topics draft should say this.
    
        
     
    
        
    I believe we
            owe it to readers to present the complete picture, which is
            why I believe that describing profiles using ID Tokens and
            the Form Post Response Mode are in scope.
    
        
     
    
        
                                                          
            -- Mike
    
        
     
    
        
    
          
    
            
    From: OAuth
              <oauth-bounces@ietf.org> On Behalf Of 
              John Bradley
    
              Sent: Tuesday, November 20, 2018 7:47 AM
    
              To: oauth@ietf.org
    
              Subject: Re: [OAUTH-WG] OAuth Security Topics --
              Recommend authorization code instead of implicit
    
          
    
        
    
        
     
    
        
    Yes the at_hash protects the client from accepting an
          injected AT.  
    
        
    Unfortunately it doesn't do anything to protect against
          leakage in logs or redirects.
    
        
    So without the AT using some sort of POP mechanism it is hard
          to say sending it in a redirect is a good security practice.
    
        
    John B.
    
        
    
          
    On 11/20/2018 4:35 AM, Torsten
            Lodderstedt wrote:
    
        
    
        
    
          
    Hi Mike, 
    
          
     
    
          
    I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.
    
          
     
    
          
    I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues: 
    
          
     
    
          
    1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
    
          
    2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach. 
    
          
     
    
          
    kind regards,
    
          
    Torsten. 
    
          
     
    
          
    
            
    Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:
    
            
     
    
            
    This description of the situation is an oversimplification.  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
    
            
     
    
            
    Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
    
            
     
    
            
                                                                    Thank you,
    
            
                                                                    -- Mike
    
            
     
    
            
    From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
    
            
    Sent: Monday, November 19, 2018 2:34 AM
    
            
    To: oauth <oauth@ietf.org>
    
            
    Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
    
            
     
    
            
    Hi all,
    
            
     
    
            
    The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
    
            
     
    
            
    A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
    
            
     
    
            
    Please provide a response by December 3rd.
    
            
     
    
            
    Ciao
    
            
    Hannes & Rifaat
    
            
     
    
            
    IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
    
            
    _______________________________________________
    
            
    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

    
    
    
    
    
  


--------------607C51A3C9400054CB1DB458--


From nobody Tue Nov 20 14:00:40 2018
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 D6DD4130E41 for ; Tue, 20 Nov 2018 14:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 i6lBYFuiuy2E for ; Tue, 20 Nov 2018 14:00:32 -0800 (PST)
Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (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 268A1130DF3 for ; Tue, 20 Nov 2018 14:00:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542751222; bh=RRHVp3RFuwnxsrWGhZ6N5RjzXvMNgX6fb3wao+kAo/E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=Kep4u9P8xLVo/najbaLbu8sjv+LpQ6BjfHeg1NS4iPef8/kpfMu5EzASdv3YYjyA4TiX/kjCg0weQaQEIXKJWhoagzdZ/8OEUhWLV44Sfs2NQnOSoe7FBVFajkEzLcct1SCaTSy9lV5hxW27A9IIcG4ImrzEEGYl1DyNid6DfBN/k2YVW3bqeMg7YQBdDmKGgvP+LSpkbIIOZRgwPW3ZTfiG7dRixtEkS5PbU2mhUeB5Wp/mxgH7ftDQnJtrRytJ3hwZB+88Z9ORmgerdI+aufhA6L0RdPqd6ZLlSlaggJvnuJcWz+JpUW+QTxrQbpvC0EJRgIEKR3QcqWCc8zl2ag==
X-YMail-OSG: QLfKa20VM1kAj4uPh0EIMnJvrc9CqCsgve1PZSVvMUXe09rc8cKQxHF3vfwotd2 .uqECDXGDfCWePHFFevlOZ0i.UZMxPEQpy_s5uvL1MQ0GucFOCiyrmedY0qW3xIYHsK_QyIKVAcb 5G0Aa6c653OlVCdM.iS9IsunL.YKAEXlLawSUq4H9UG92_bafXwMC9sEatYN5BTA3eC4QKrmigVk T0KjchW_UBHfimWgtD6Znj7MJiR1j_t2ARXUhjkWTpfvCHG6RZwyg4wt81OfNq6dmqnD_mUooYLW QWpRuyPorhaj4oE9tVUaDi7g83z74IdvTFkb9Bmofz5Db5MbSLETdICIxHZ_3b2BmqeA5iDGnjIn V1C7yVfJMgYTT_7j2PXYyZAoML7rSsmU1dI.sJNBRfhO7Genxs_ySPRbP5qZSNe1Lyng2S7cLBwS r.LvchOzut4T.2ijMu0r4XRV2aVz3P.WK7DLfXAO4dPGl7k7q71dtW2Z74.qtmzLQLK_nJOY7h9x G40fS4so2vex83N.zk5rO_LfAPz7.0Z5_SsQyVj1hV9k40AfdalUicpGNrxwk03dXMW_loGk2iaZ 90ymT2_JMDv7WxV1D0LgkkkDK2b6KNYlda6pb8Dd2pc6nuqQ0dX86ar9IY9bcnBz_W8VZGgTHuFD 6y1DeZBq0mbUYCTNN1nbNLBq8VBfKF.muQ_9x2WP8wI1ISeiSlKk5O4eB6hsXt1nlqnVcw1VwpoQ n6SqBklPQVeGRA3kERo1A3253kR77FyTI.RlmdXIYGY5TnelzNPtU9k7epp54cRligUNn9WYttBp wWzpzcXXwfys90JBpS9M2fuSyJ2lw6S4FST9zSA7X4LoHhpzQZsnsKISIWqK0aYPS0XjhksFnsmt tVLvUDC9olgmdBJToJe4mGM9ncvAtdLe7DjqOYc3QFoew43D4IszKN2ADU1xSAitAhWaScW6TQWo t_HSRQbmJR7AAYYpACl60OgdFd8oOvw67oU0_YfgIwgkU0hDJlQArhepCZCnXij1YO1rHng2RYHS YRoMOIs6c386sUZEaGAkj1u1trSMngIczS.jkTemnp0FFG53NSt8O_mGX
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 20 Nov 2018 22:00:22 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.132.163]) ([184.165.8.99]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e20dd9db169329cbd357893d9002dab8;  Tue, 20 Nov 2018 22:00:21 +0000 (UTC)
To: David Waite , Hans Zandbelt 
Cc: oauth 
References:   <14BB75BB-F650-408D-8359-B25FA4E66DC9@alkaline-solutions.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <1b451ff4-9de5-c3e2-acf3-f8b50b0212ff@aol.com>
Date: Tue, 20 Nov 2018 17:00:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <14BB75BB-F650-408D-8359-B25FA4E66DC9@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="------------BD60D0F8A17CDBF9F295ACD5"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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, 20 Nov 2018 22:00:35 -0000

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

+1

This model is useful and should be documented in its own right. Once 
documented it could possibly be referenced in the BCP.

On 11/9/18 1:44 PM, David Waite wrote:
> Hi Hans, I hope it is acceptable to reply to your message on-list.
>
> Others could correct me if I am wrong, but I believe the purpose of 
> this document is to recommend uses of other OAuth/OIDC specifications, 
> not to include its own technologies.
>
> In terms of being another spec to be referenced, I think it would be 
> useful but I wonder hypothetically how to best write that 
> specification. This method seems to be relying on standards-defined 
> tokens and converting them to an application server session, which 
> isn’t defined by behavior other than HTTP cookies. The session info 
> hook then lets you use those proprietary session tokens to retrieve 
> the access/id token.
>
> As such, it is closer to an architecture for implementing a client - 
> as a confidential client backend with an associated SPA frontend that 
> needs to make OAuth-protected calls. It is not describing the 
> communication between existing OAuth roles, such as between the client 
> and AS.
>
> There’s obvious value here, and it's one of several architectures for 
> browser-based apps using a confidential client rather than a public 
> one (another example being a reverse proxy which maps remote OAuth 
> endpoints into local, session-token-protected ones). I personally am 
> just not sure how you would define the communication between back-end 
> and front-end portions of the client in these architectures as a 
> standard within OAuth.
>
> -DW
>
>> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt > > wrote:
>>
>> Hi Aaron, DW,
>>
>> About draft-parecki-oauth-browser-based-apps:
>> would you consider including a recommendation about and the 
>> standardization of a "session info" endpoint (I'm open for better 
>> naming ;-)) as described in:
>> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
>>
>> this approach is not just something that I cooked up; it is based on 
>> real world requests & deployments at Netflix and OAth.
>>
>> Let me know what you think,
>>
>> Hans.
>>
>> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig 
>> > wrote:
>>
>>     Hi all,
>>
>>     Today we were not able to talk about
>>     draft-parecki-oauth-browser-based-apps-00, which describes 
>>     "OAuth 2.0 for Browser-Based Apps".
>>
>>     Aaron put a few slides together, which can be found here:
>>     https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>>
>>     Your review of this new draft is highly appreciated.
>>
>>     Ciao
>>     Hannes
>>     IMPORTANT NOTICE: The contents of this email and any attachments
>>     are confidential and may also be privileged. If you are not the
>>     intended recipient, please 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.
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> -- 
>> hans.zandbelt@zmartzone.eu 
>> ZmartZone IAM - www.zmartzone.eu 
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    +1
    
      
    
      This model is useful and should be documented in its own right.
      Once documented it could possibly be referenced in the BCP.
    
    
    
    
    On 11/9/18 1:44 PM, David Waite wrote:
    
    
    
    
    
      
      Hi Hans, I hope it is acceptable to reply to your message on-list.
      

    
      
    
      
    Others could correct me if I am wrong, but I believe
        the purpose of this document is to recommend uses of other
        OAuth/OIDC specifications, not to include its own technologies.
    
      

    
      
    
      
    In terms of being another spec to be referenced, I
        think it would be useful but I wonder hypothetically how to best
        write that specification. This method seems to be relying on
        standards-defined tokens and converting them to an application
        server session, which isn’t defined by behavior other than HTTP
        cookies. The session info hook then lets you use those
        proprietary session tokens to retrieve the access/id token.
    
      

    
      
    
      
    As such, it is closer to an architecture for
        implementing a client - as a confidential client backend with an
        associated SPA frontend that needs to make OAuth-protected
        calls. It is not describing the communication between existing
        OAuth roles, such as between the client and AS.
    
      

    
      
    
      
    There’s obvious value here, and it's one of several
        architectures for browser-based apps using a confidential client
        rather than a public one (another example being a reverse proxy
        which maps remote OAuth endpoints into local,
        session-token-protected ones). I personally am just not sure how
        you would define the communication between back-end and
        front-end portions of the client in these architectures as a
        standard within OAuth.
    
      

    
      
    
      
    -DW
    
        

    
          
    
            
    On Nov 6, 2018, at 3:03 AM, Hans Zandbelt <hans.zandbelt@zmartzone.eu>
              wrote:
    
            
    
            
    
              
    
                
    
                  
    Hi Aaron, DW,
                    

    
                    
    
                    
    About draft-parecki-oauth-browser-based-apps:
    
                    
    would you consider including a
                      recommendation about and the standardization of a
                      "session info" endpoint (I'm open for better
                      naming ;-)) as described in:
    
                    
                    

    
                    
    
                    
    this approach is not just something
                      that I cooked up; it is based on real world
                      requests & deployments at Netflix and OAth.
    
                    

    
                    
    
                    
    Let me know what you think,
    
                    

    
                    
    
                    
    Hans.
    
                  
    
                
    
              
    
              
    
              
    
                
    On Tue, Nov 6, 2018 at 10:55 AM
                  Hannes Tschofenig <Hannes.Tschofenig@arm.com>
                  wrote:
    
                
    
                
    Hi
                  all,
    
                  
    
                  Today we were not able to talk about
                  draft-parecki-oauth-browser-based-apps-00, which
                  describes  "OAuth 2.0 for Browser-Based Apps".
    
                  
    
                  Aaron put a few slides together, which can be found
                  here:
    
                  https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
    
                  
    
                  Your review of this new draft is highly appreciated.
    
                  
    
                  Ciao
    
                  Hannes
    
                  IMPORTANT NOTICE: The contents of this email and any
                  attachments are confidential and may also be
                  privileged. If you are not the intended recipient,
                  please 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.
    
                  
    
                  _______________________________________________
    
                  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

    
    
    
    
    
  


--------------BD60D0F8A17CDBF9F295ACD5--


From nobody Tue Nov 20 14:29:39 2018
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 0230B130E72 for ; Tue, 20 Nov 2018 14:29:36 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 t5c0Zi6_RHnB for ; Tue, 20 Nov 2018 14:29:31 -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 46E45130EA5 for ; Tue, 20 Nov 2018 14:29:31 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id x10so3624943wrs.8 for ; Tue, 20 Nov 2018 14:29:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pbmu9/CYHGstghmOKrCd/nsPzg7UdMrhN+hE4adDJJM=; b=miulnjWXbiwiEHOTXPPF3c8dcHEEj4eRKFdoSYy5ROQLvr0GMoS4oahVITTMMokjAs cAC7SxaMLUMJfgcyfOWH6wuZZeZ/W3bM0tq38v1BjqLp7K67ixWPtIR1l7hNnkTmVze3 0FJllPRHa1VuyjiWHCjgHl/VQ7c0ly2+MqcWTDKcgpyhl1dqgvfBRkSWG6KWctxcyIDn cTjNLlWUafW1NHaDBl0qzqGIh6d/GcQOapquB8UncTWR7Co8Hs51WwWckI/pGQNiJqbh UmvTREPnAG5Z+5Ca0j0lDRbOdjfAPiHqBXhSmlVHZzGkodeiGdwsKcL5mxZFvs9ip+rb 5v6g==
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=pbmu9/CYHGstghmOKrCd/nsPzg7UdMrhN+hE4adDJJM=; b=qhfu6X3+rtrspG+AlBXhbcfLLd3VeaMgbcM3/O6T7bX1duUrf+CaNKf1QgOQ7snGPi qmPfvgatnJYTxZ6giwAh4tQbuK4y0H57QoCEj8Z2jHWmJmZq+TRT248N9Wg+EqAcaYoQ RCf+6PuTFNxHpug4uojHRmR6hUcxzf5sYqCgYfrSbNYS/98IL7IXiu1ylujaRSkOKLnb qm6NX6QTM6rRCNE7/3TmwzlGEtgGk8dAbYwora3t7TmH4vLXkjEH2i+9SYiT4PCf3Pc9 PbLfhmtJ9Z9o1Kn1aWWbutAuTQlsevv6/B+IM6bwGCgqmM3HQwOx0RhSNSL5BMXC2uwM pdIw==
X-Gm-Message-State: AA+aEWY7dKznkyIW4iMghluVV/AiZBOURkw1wSvJ4QRAJi0q0JDM7Sba FwDYOsBw2+ulYNv3UAxucz1MuM0PRzN//Qa1oMHxfA==
X-Google-Smtp-Source: AFSGD/VUrADQb9NMyQy5xGow1FyMJ4gw9OHEsdd3L0phdEN7uV26sptbDwjEKRhdUKt1cJh5uo5itINlydb0bEM4bpQ=
X-Received: by 2002:adf:800b:: with SMTP id 11-v6mr3761653wrk.106.1542752969031;  Tue, 20 Nov 2018 14:29:29 -0800 (PST)
MIME-Version: 1.0
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>
In-Reply-To: <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>
From: John Bradley 
Date: Tue, 20 Nov 2018 19:29:15 -0300
Message-ID: 
To: George Fletcher 
Cc: Mike Jones ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b2163b057b202a1d"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 20 Nov 2018 22:29:38 -0000

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

Post response works OK for server based clients.  I don't think POST works
for single page applications.

Basically that would be something more like postmessage between two JS
apps.

Postmessage also has security issues passing a access token and leaking.

Perhaps someone more familiar with SPA can comment on POST.

John B.



On Tue, Nov 20, 2018, 6:40 PM George Fletcher  Hi Mike,
>
> The Form Post Response Mode keeps the access_token out of the URL, but it
> doesn't prevent the token from traversing through the browser. So a
> man-in-the-browser attack may be able to intercept the values. It should
> help with leakage in logs.
>
> Thanks,
> George
>
> On 11/20/18 4:00 PM, Mike Jones wrote:
>
> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Response Mode
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> mitigate the threats you=E2=80=99re describing below John?  If so, I beli=
eve the
> Security Topics draft should say this.
>
>
>
> I believe we owe it to readers to present the complete picture, which is
> why I believe that describing profiles using ID Tokens and the Form Post
> Response Mode are in scope.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth   *On
> Behalf Of * John Bradley
> *Sent:* Tuesday, November 20, 2018 7:47 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
>
>
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs o=
r
> redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say
> sending it in a redirect is a good security practice.
>
> John B.
>
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
> Hi Mike,
>
>
>
> I agree that OIDC hybrid flows offer additional security over the OAuth i=
mplicit grant and are used in the wild. On my slides and in the initial ver=
sion of the new section, we had included the hybrid OIDC flows because of t=
heir known token injection countermeasures.
>
>
>
> I nevertheless feel very uncomfortable to recommend those flows and any f=
low issuing access tokens in the front channel. In the course of the detail=
ed review of the new text we realized two issues:
>
>
>
> 1) Since the access token is exposed in the URL, such flows possess a sig=
nificantly higher risk to leak the access token (e.g. through browser histo=
ry, open redirection and even referrer headers) than the code grant.
>
> 2) There is no viable way to sender constrain access tokens issued in the=
 front channel. Given the WG decided to recommend use of sender constraint =
tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#sec=
tion-2..2), it seems contradictory to recommend response types not supporti=
ng such an approach.
>
>
>
> kind regards,
>
> Torsten.
>
>
>
> Am 19.11.2018 um 23:13 schrieb Mike Jones  :
>
>
>
> This description of the situation is an oversimplification.  OpenID Conne=
ct secures the implicit flow against token injection attacks by including t=
he at_hash (access token hash) in the ID Token, enabling the client to vali=
date that the access token was created by the issuer in the ID Token (which=
 is also the OAuth Issuer, as described in RFC 8414).  (Note that this miti=
gation was described in draft-ietf-oauth-mix-up-mitigation.)
>
>  Given the prevalence of this known-good solution for securing the implic=
it flow, I would request that the draft be updated to describe this mitigat=
ion.  At the same time, I=E2=80=99m fine with the draft recommending the co=
de flow over the implicit flow when this mitigation is not used.
>
>                                                                  Thank yo=
u,
>
>                                                                 -- Mike
>
>  From: OAuth   On Behalf =
Of Hannes Tschofenig
>
> Sent: Monday, November 19, 2018 2:34 AM
>
> To: oauth  
>
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code=
 instead of implicit
>
>  Hi all,
>
>  The authors of the OAuth Security Topics draft came to the conclusion th=
at it is not possible to adequately secure the implicit flow against token =
injection since potential solutions like token binding or JARM are in an ea=
rly stage of adoption. For this reason, and since CORS allows browser-based=
 apps to send requests to the token endpoint, Torsten suggested to use the =
authorization code instead of the implicit grant in call cases in his prese=
ntation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-o=
auth-sessb-draft-ietf-oauth-security-topics-01).
>
>  A hum in the room at IETF#103 concluded strong support for his recommend=
ations. We would like to confirm the discussion on the list.
>
>  Please provide a response by December 3rd.
>
>  Ciao
>
> Hannes & Rifaat
>
>  IMPORTANT NOTICE: The contents of this email and any attachments are con=
fidential and may also be privileged. If you are not the intended recipient=
, please 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.
>
> _______________________________________________
>
> 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
>
>
>

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


    Post response works OK for server based clients.=C2=A0 I =
don't think POST works for single page applications.=C2=A0=C2=A0

    Basically that would be something mo=
re like postmessage between two JS apps.=C2=A0=C2=A0

    Postmessage also has security issues passing a=
 access token and leaking.=C2=A0=C2=A0

    Perhaps someone more familiar with SPA can comment on POST.=
=C2=A0=C2=A0

    John B.=C2=
=A0



    =

    On Tue, Nov 20, 2018, 6:40 PM G=
eorge Fletcher <gffletch@aol.com=
 wrote:
    
 =20
   =20
 =20
  
    
    Hi Mike,
    
      
    
      The Form Post Response Mode keeps the access_token out of the URL,
      but it doesn't prevent the token from traversing through the
      browser. So a man-in-the-browser attack may be able to intercept
      the values. It should help with leakage in logs.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 11/20/18 4:00 PM=
, Mike Jones wrote:
    
    
    
    
    
     =20
     =20
     =20
      
    
        
    Next question =
=E2=80=93
            doesn=E2=80=99t using the Form Post Response Mode
            https://openid.net/spe=
cs/oauth-v2-form-post-response-mode-1_0.html
            mitigate the threats you=E2=80=99re describing below John?=C2=
=A0 If so, I
            believe the Security Topics draft should say this.
    
        
    =C2=A0<=
u>
    
        
    I believe we
            owe it to readers to present the complete picture, which is
            why I believe that describing profiles using ID Tokens and
            the Form Post Response Mode are in scope.<=
/p>
        
    =C2=A0<=
u>
    
        
    =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
            -- Mike
    
        
    =C2=A0<=
u>
    
        
    
          
    
            
    From: OAuth
              <=
;oauth-bounces@ietf.org> On Behalf Of 
              John Bradley
    
              Sent: Tuesday, November 20, 2018 7:47 AM
    
              To: oauth@ietf.org
    
              Subject: Re: [OAUTH-WG] OAuth Security Topics --
              Recommend authorization code instead of implicit
    
          
    
        
    
        
    =C2=A0
    
        
    Yes the at_hash protects the client from accepting an
          injected AT.=C2=A0 
    
        
    Unfortunately it doesn't do anything to protect against
          leakage in logs or redirects.
    
        
    So without the AT using some sort of POP mechanism it is hard
          to say sending it in a redirect is a good security practice.
    
        
    John B.
    
        
    
          
    On 11/20/2018 4:35 AM, Torsten
            Lodderstedt wrote:
    
        
    
        
    
          
    Hi Mike, 
    
          
    =C2=A0
    
          
    I agree that OIDC hybrid flows offer additional security ove=
r the OAuth implicit grant and are used in the wild. On my slides and in th=
e initial version of the new section, we had included the hybrid OIDC flows=
 because of their known token injection countermeasures.
          
    =C2=A0
    
          
    I nevertheless feel very uncomfortable to recommend those fl=
ows and any flow issuing access tokens in the front channel. In the course =
of the detailed review of the new text we realized two issues: 
    
          
    =C2=A0
    
          
    1) Since the access token is exposed in the URL, such flows =
possess a significantly higher risk to leak the access token (e.g. through =
browser history, open redirection and even referrer headers) than the code =
grant.
    
          
    2) There is no viable way to sender constrain access tokens =
issued in the front channel. Given the WG decided to recommend use of sende=
r constraint tokens (htt=
ps://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such=
 an approach. 
    
          
    =C2=A0
    
          
    kind regards,
    
          
    Torsten. 
    
          
    =C2=A0
    
          
    
            
    Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:<=
/u>
    
            
    =C2=A0
    
            
    This description of the situation is an oversimplification=
.=C2=A0 OpenID Connect secures the implicit flow against token injection at=
tacks by including the at_hash (access token hash) in the ID Token, enablin=
g the client to validate that the access token was created by the issuer in=
 the ID Token (which is also the OAuth Issuer, as described in RFC 8414).=
=C2=A0 (Note that this mitigation was described in draft-ietf-oauth-mix-up-=
mitigation.)
    
            
     
    
            
    Given the prevalence of this known-good solution for secur=
ing the implicit flow, I would request that the draft be updated to describ=
e this mitigation.=C2=A0 At the same time, I=E2=80=99m fine with the draft =
recommending the code flow over the implicit flow when this mitigation is n=
ot used.
    
            
     
    
            
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0Thank you,
    
            
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 -- Mike
    
            
     
    
            
    From: OAuth <oauth-bounces@ietf.org> On Beha=
lf Of Hannes Tschofenig
    
            
    Sent: Monday, November 19, 2018 2:34 AM
            
    To: oauth <oauth@ietf.org>
    
            
    Subject: [OAUTH-WG] OAuth Security Topics -- Recommend aut=
horization code instead of implicit
    
            
     
    
            
    Hi all,
    
            
     
    
            
    The authors of the OAuth Security Topics draft came to the=
 conclusion that it is not possible to adequately secure the implicit flow =
against token injection since potential solutions like token binding or JAR=
M are in an early stage of adoption. For this reason, and since CORS allows=
 browser-based apps to send requests to the token endpoint, Torsten suggest=
ed to use the authorization code instead of the implicit grant in call case=
s in his presentation (seehttps://datatracker.ietf.org/meeting/103/=
materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<=
u>
    
            
     
    
            
    A hum in the room at IETF#103 concluded strong support for=
 his recommendations. We would like to confirm the discussion on the list.<=
u>
    
            
     
    
            
    Please provide a response by December 3rd.
            
     
    
            
    Ciao
    
            
    Hannes & Rifaat
    
            
     
    
            
    IMPORTANT NOTICE: The contents of this email and any attac=
hments are confidential and may also be privileged. If you are not the inte=
nded recipient, please notify the sender immediately and do not disclose th=
e contents to any other person, use it for any purpose, or store or copy th=
e information in any medium. Thank you.
    
            
    _______________________________________________<=
/u>
    
            
    OAuth mailing list
    
            
    OAuth@ietf.org
    
            
    https://www.ietf.org/mailman/listinfo/oa=
uth
    
          
    
          
    =C2=A0
    
          

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

    
    
    
    
    
  
    


    

--000000000000b2163b057b202a1d--


From nobody Tue Nov 20 14:38:21 2018
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 0DD5E130E5D for ; Tue, 20 Nov 2018 14:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7XaorqX7dqod for ; Tue, 20 Nov 2018 14:38:17 -0800 (PST)
Received: from sonic308-3.consmr.mail.bf2.yahoo.com (sonic308-3.consmr.mail.bf2.yahoo.com [74.6.130.42]) (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 83B32130E5B for ; Tue, 20 Nov 2018 14:38:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542753496; bh=kAA5tZGnPCeiRibkak9KrEpd3W+icUaqbteUvkIVnFM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=KgGg2qODXTLNLqsn4VcUmE2NVPd1WSHBQLtm+tGyISQotdl9CznjP8oC+grGHcw8h68zJa6RaF6Zerez1iBiUaKCn+65e0BBml9r8jmBbYfBvAE/P4Cu+iTLOthRheIdyQdFm9poYGq8YdJ+9uMlOIPgLCuC1Aa1rOsd/LARc8jxaBF9czrveVn1udIaPF5CgwS1cRiMlRo1JDMRxF3RYJm1RUeIGrZ9SWtX+JaZupths2nWEcULm03bPR3TZ9HNHiItvp1J0nYLmg+Jy3KR39PLDLu2bny5wU54W3QXJVdAYYozq1oJcQDhuHKXpc7bJu2+izmCJmXm/oEj0ifADg==
X-YMail-OSG: D4hkLvsVM1nyVbegCBhTvsUzDXlKwbb.x8kQ5D9BbdS4g0USH.GrHLNJ_uZVWP_ mFkEVrxX7T9sqm3cN3TKCFiMoWxPgqYXsz2F3sOOswMFf7ntECqhcQISqxWPW9oOH5LMz21mxAeE 5ttr6wc7PN_luHgXGYG84ezvmKZQauxTI_JEO7Nq4lQrNp59CnuX6dQHnqA4INC5DKewWcYyQbyp Y.PcljzQkRh.02kCd4HFAsc33saeqyeeBO.1wSnb8CBQbzGetBwGkIc2r_GuuJR.L6tL7DRZaGpL ZMUQOOl0zMsU3Ax5ug60Vur8aKcDNaaKJEvaha7AbaRtou3_.3lJOV9EtupUE5DjKNhzJ79B4zi5 sFHESx2hDvD2xQmJ8jk7UPKkExEjeDtZr1bdkF026FFIhgWDgrimsjEfKog5UsmEGI3aH4aQOfSl tWjiPrtTWZMRi13bVAHVfwyAq6_qaBDhuvww_PIL6xmJHZ_YpHGNG3eZAS6WBF8b0INt.YMmTJPE 0fRRpedlPf4GChSOQ7hJWZnlL21FqvAIOff8.69a7.V1hXM6wRHRrt0I6aGfWWi90PT5U7ZBVs.G _MdLE0XAeQ0mp8_TLGzIEVn81Iqp73vbcrd8G74dyY23oY8vifus47UISyYyk1l6SPdYVzUufDx_ FdkTVTNPESu2J57OOZjYsKlzBazmxFaDzyEXElOMuS04uZQU39TiWMcUn5MyWPd97qxplRGordJi vcbyGNpYWyQQIkJ13JfQOcoeTUF_T9cQvBdEad6Ih.pdi54aRUpIgoJo4Utka5o9x.CMwoXH4Q4j CbEDM49nT0Mg_aUHo_V3EWsuhsqMHTX_EXNUmNlBD8uE95z8_cXzEaEA9HyUYSKpRt3SuPqvo0i7 CNG9a.eBaivKx8HRfHaT8UMDf5R0svPs3B1TSMG8.T8JG7CDCLYif6u2DdT4hK_PbHbF.oLSQqb_ bvwTR4zYScgW2fq4xKfs0KCtNXR.3bx2aqtOZCINFLRnisB3cZciIhX9e.eAzK31.t86xQ4Nzjgx Fv_Bj3c3BbDVPrZgT2Ca7Y4NPo.CGpfOuOXGcyciXnYQmIQ0-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Tue, 20 Nov 2018 22:38:16 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.132.163]) ([184.165.8.99]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8a5037703c78b58376ee6f26a0fef0f0;  Tue, 20 Nov 2018 22:38:15 +0000 (UTC)
To: Torsten Lodderstedt , oauth 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com>
Date: Tue, 20 Nov 2018 17:38:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------94BCF409CE6DBF867CBEA2A9"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 20 Nov 2018 22:38:20 -0000

This is a multi-part message in MIME format.
--------------94BCF409CE6DBF867CBEA2A9
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for the additional section on refresh_tokens. Some additional 
recommendations...

1. By default refresh_tokens are bound to the user's authenticated 
session. When the authenticated session expires or is terminated 
(whether by the user or for some other reason) the refresh_tokenis 
implicitly revoked.
2. Clients that need to obtain a refresh_token that exists beyond the 
lifetime of the user's authentication session MUST indicate this need by 
requesting the "offline_access" scope 
(https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). 
This provides for a user consent event making it clear to the user that 
the client is requesting access even when the user's authentication 
session expires. This then becomes the default for mobile apps as the 
refresh_token should not be tied to the web session used to authorize 
the app.
3. The AS MAY consider putting an upper bound on the lifetime of a 
refresh_token (e.g. 1 year). There is no real need to issue a 
refresh_token that is good indefinitely.

This is in addition to the other best practices described.

Thanks,
George

On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
> Hi all,
>
> the new revision contains the following changes:
>
> * added section on refresh tokens
> * additional justifications for recommendation for code
> * refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up (based on feedback by Joseph Heenan)
> * added requirement to authenticate clients during code exchange (PKCE or client credential) to 2.1.1.
> * changed occurrences of SHALL to MUST
>
> As always: looking forward for your feedback.
>
> kind regards,
> Torsten.
>
>> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
>>
>>
>> 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 Security Best Current Practice
>>         Authors         : Torsten Lodderstedt
>>                           John Bradley
>>                           Andrey Labunets
>>                           Daniel Fett
>> 	Filename        : draft-ietf-oauth-security-topics-10.txt
>> 	Pages           : 38
>> 	Date            : 2018-11-20
>>
>> Abstract:
>>    This document describes best current security practice for OAuth 2.0.
>>    It updates and extends the OAuth 2.0 Security Threat Model to
>>    incorporate practical experiences gathered since OAuth 2.0 was
>>    published and covers new threats relevant due to the broader
>>    application of OAuth 2.0.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
>>
>>
>> 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/
>>
>> _______________________________________________
>> 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


--------------94BCF409CE6DBF867CBEA2A9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Thanks for the additional
      section on refresh_tokens. Some additional recommendations...
    
      
    
      1. By default refresh_tokens are bound to the user's authenticated
      session. When the authenticated session expires or is terminated
      (whether by the user or for some other reason) the refresh_tokenis
      implicitly revoked.
    
      2. Clients that need to obtain a refresh_token that exists beyond
      the lifetime of the user's authentication session MUST indicate
      this need by requesting the "offline_access" scope (    https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess).
      This provides for a user consent event making it clear to the user
      that the client is requesting access even when the user's
      authentication session expires. This then becomes the default for
      mobile apps as the refresh_token should not be tied to the web
      session used to authorize the app.
    
      3. The AS MAY consider putting an upper bound on the lifetime of a
      refresh_token (e.g. 1 year). There is no real need to issue a
      refresh_token that is good indefinitely. 
    
      
    
      This is in addition to the other best practices described.
    
      
    
      Thanks,
    
      George
    
      
    
        
    
    On 11/20/18 2:32 PM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi all, 

the new revision contains the following changes:

* added section on refresh tokens 
* additional justifications for recommendation for code
* refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up (based on feedback by Joseph Heenan)
* added requirement to authenticate clients during code exchange (PKCE or client credential) to 2.1.1.
* changed occurrences of SHALL to MUST

As always: looking forward for your feedback.

kind regards,
Torsten. 


    
      
    
        
    Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:


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 Security Best Current Practice
       Authors         : Torsten Lodderstedt
                         John Bradley
                         Andrey Labunets
                         Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-10.txt
	Pages           : 38
	Date            : 2018-11-20

Abstract:
  This document describes best current security practice for OAuth 2.0.
  It updates and extends the OAuth 2.0 Security Threat Model to
  incorporate practical experiences gathered since OAuth 2.0 was
  published and covers new threats relevant due to the broader
  application of OAuth 2.0.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10


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/

_______________________________________________
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

    
    
    
    
    
  


--------------94BCF409CE6DBF867CBEA2A9--


From nobody Tue Nov 20 14:47:42 2018
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 9646012D7EA for ; Tue, 20 Nov 2018 14:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 VVRcDjmCurJP for ; Tue, 20 Nov 2018 14:47:40 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id C5E4412007C for ; Tue, 20 Nov 2018 14:47:39 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:9073:c2a4:dc29:37a0] (unknown [IPv6:2601:282:202:b210:9073:c2a4:dc29:37a0]) by alkaline-solutions.com (Postfix) with ESMTPSA id 14298315E9; Tue, 20 Nov 2018 22:47:38 +0000 (UTC)
From: David Waite 
Message-Id: <72896AA2-3E69-43A0-B583-04E33743D3C8@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8BE59DF0-8BF0-4B77-B6C6-781848416C38"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 20 Nov 2018 15:47:37 -0700
In-Reply-To: 
Cc: Torsten Lodderstedt , OAuth WG 
To: Aaron Parecki 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 20 Nov 2018 22:47:42 -0000

--Apple-Mail=_8BE59DF0-8BF0-4B77-B6C6-781848416C38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Nov 20, 2018, at 1:37 PM, Aaron Parecki  wrote:
>=20
> The new section on refresh tokens is great! I have a couple =
questions/comments about some of the details.
>=20
> Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o  logout at the authorization server
> =20
> This doesn't sound like the desired behavior for mobile apps, where =
the user's expectation of how long they are logged in to the mobile app =
is not tied to their web session where they authorized the app. However =
this does likely match a user's expectation when authorizing a =
browser-based app. Should this be clarified that it should not apply to =
the mobile app case, or only apply to browser-based apps?

There is also the model where web sessions are perpetual; where you are =
evaluating access against a confidence that it is the legitimate user =
against known threats. In that model, you require authentication =
(perhaps by invalidating a client=E2=80=99s access and refresh tokens) =
as needed to rebuild that confidence.

This still is considered an online model; the offline model would be =
distinguished by evaluating the confidence that a client is still =
trusted and acting in the user=E2=80=99s interests.

In terms of user-initiated logout - logout is an interesting action, =
with both broad and miscommunicated purpose. I=E2=80=99ve found three =
different verbalizations of why a user hits this button:

1. It must be here for some reason, so I think I=E2=80=99m supposed to =
hit it when I=E2=80=99m done (aka 'security hygiene')
2. I suspect I might not be the next person who interacts with this =
device, so you should ask me who I am before allowing future access (aka =
=E2=80=98is this still you=E2=80=99)
3. I want software on this device to stop being able to access my =
accounts, and to destroy any cached information (aka =E2=80=98kill =
switch=E2=80=99)

All could be expected to stop access by online clients, while someone =
operating under expectation #3 could extend even to stopping offline =
access.

Likewise, it could be said that users with expectation #2 would resume =
access with previous scopes after an authentication, while expectation =
#3 would imply a need to reestablish consent to resume.

-DW=

--Apple-Mail=_8BE59DF0-8BF0-4B77-B6C6-781848416C38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



    On Nov 20, 2018, at 1:37 PM, Aaron Parecki <aaron@parecki.com> =
wrote:

    The new section on refresh tokens is great! I have a couple =
questions/comments about some of the details.

    Authorization servers may =
revoke refresh tokens automatically in case
    of a security =
event, such as:
    o  logout at the authorization =
server
     
    This =
doesn't sound like the desired behavior for mobile apps, where the =
user's expectation of how long they are logged in to the mobile app is =
not tied to their web session where they authorized the app. However =
this does likely match a user's expectation when authorizing a =
browser-based app. Should this be clarified that it should not apply to =
the mobile app case, or only apply to browser-based =
apps?

    There is also the model where web sessions are =
perpetual; where you are evaluating access against a confidence that it =
is the legitimate user against known threats. In that model, you require =
authentication (perhaps by invalidating a client=E2=80=99s access and =
refresh tokens) as needed to rebuild that confidence.

    This still is considered an online model; the =
offline model would be distinguished by evaluating the confidence that a =
client is still trusted and acting in the user=E2=80=99s =
interests.

    In terms of =
user-initiated logout - logout is an interesting action, with both broad =
and miscommunicated purpose. I=E2=80=99ve found three different =
verbalizations of why a user hits this button:

    1. It must be here for some reason, so I think =
I=E2=80=99m supposed to hit it when I=E2=80=99m done (aka 'security =
hygiene')
    2. I suspect I might not be the next person who =
interacts with this device, so you should ask me who I am before =
allowing future access (aka =E2=80=98is this still you=E2=80=99)
    3. I want software on this device to stop being able to access my =
accounts, and to destroy any cached information (aka =E2=80=98kill =
switch=E2=80=99)

    All could be =
expected to stop access by online clients, while someone operating under =
expectation #3 could extend even to stopping offline =
access.

    Likewise, it could be said =
that users with expectation #2 would resume access with previous scopes =
after an authentication, while expectation #3 would imply a need to =
reestablish consent to resume.

    -DW
    =

--Apple-Mail=_8BE59DF0-8BF0-4B77-B6C6-781848416C38--


From nobody Tue Nov 20 15:07:37 2018
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 CFE9C130DEA for ; Tue, 20 Nov 2018 15:07:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vmOATW7BWCGe for ; Tue, 20 Nov 2018 15:07:34 -0800 (PST)
Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 D2A0012007C for ; Tue, 20 Nov 2018 15:07:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542755253; bh=CDv8AyELqiRyb85W1LMdyZ73OLX1ThhKCiAQ0Md2E8I=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=T9Y3m0foKo2+HkcGH1Mz9GQH0dXmyuHL0OgwDiLMGFm+2SzGSkAOcBFizVvgH+6Ev6nkmaeZShGlyBtxTQThs9Kpx9fzUppkYfgNoCedU51Ip4nECG9nJbSmBaJwGkPtOZMUJIZlQYLMOVFPK7BYfcAkd6dRuUFqaQnbDUTfbj2nPWazeHoa7747aMcFX+r4hNh4V+CBAZRq47aUO0g1y8khhfz3YSK6h6lcQSAmZqdZDC4XN+tgwGdFF4T63WClKZKVhZt+Pwo4hp6LiHPoB1OfJW7mM7VXS0egYsWpKSwZPM1xEmI2zvNUCak860rnH7QCGK1J81LOcS+vYqlBBw==
X-YMail-OSG: 0b2DoTgVM1nG_NjtfSsz9tPH6D0fF7dYw2_uuUKhascXhxHHRwuHYiBvpraLN4t S9XEvX0aOZmabkOLY_t2x9eyvbGIm3xttEF8hXjfK_ZOdu_V8ZdyuzKLUt4wdeSuUeIAzd2Ynzq8 JDv7l6lKI5NTzt3qqWQG6.qr4iWBPHSIyIQiSMaP5QE8vfExzFBxoIvPIpgHHDMkdkIuhZtk8qDb NI68ZdMNnEoPW9bCfpxkEa7jwpkerzT3HvlFI_Yx3Tz4TGfLVyj1oG4uNe5qNRzDj0VoMG9xrlkT UXZviBbSG8X0KmUmj.UncL6Xz0nkneHbKltJTjSCYBE7BZ8HjZMfP8msVweKRx.O.I8jYc_aCi8T GNdPOb30dKBOsP2CSzO2oOk1TrHV9u1.6tde0Z0MRF.0a1dBNLcUuTyy6wnu4Qje5vA01k2MfNYj gY0.RlSWQUhDYtZ_.kPui6fLazDMqhrS0i32JzBzdqWOOmUT0u_uElqfkLn_ABM0E8Ohtu9jdRT2 EsFZsekPEeNijKXyYvAoJkzZ7zGgGdn7v7oFI7NFLiJTWaYceu0FjnFXYNinl0WZJ91_1M9yxhFM BsMRx77mJ3F9IEBavo7xh54RT9v9_b30XiiBkgcUJ2BVbL4SQo4s8bgDaelJ1aSDSwGiJLcFpcRW w_9fYkYJYvrGKRNjcUMaGaqvzvwx_vijiq0Vi85yo62TY_f1zR5cYwytUWD1XPC6106e_DXFAvlD Y6FWCD.2T0x_X0EC3Pc_PROpCZo_pPWNDeUd9r0Ok6snvq7TpXrGjRRI_jZoWOwDBqBexP8d6cq4 yN6tZhem99_gZFflb8j2EBHdaMEeg5Iyt43q1TwKXWYsZ915KUpyujxHT2Oo9IRgjdq3Mv56EDS. zsWNKA1wVBh13UCIXX9CRmrcAaIcqNECsMSDdPEDf3QbJMQqXbpFnB2PJbW6llgGMgoM73QacLye _BG4L3YEac.KqHjeom4Cj.1a4DrhEwt2dK95WId18eCcMqzt8bUpX3PJmPjXSlf0NC8D.r8ajpjz KOq00brA77flPIMZqf3wWVcByaa4pzolfwlcnCducmiSKlR0NQB1qFA06
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Tue, 20 Nov 2018 23:07:33 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.132.163]) ([184.165.8.99]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a17544abddb04b7dd75ebe2b7adbfe75;  Tue, 20 Nov 2018 23:07:31 +0000 (UTC)
To: David Waite , Aaron Parecki 
Cc: OAuth WG 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>   <72896AA2-3E69-43A0-B583-04E33743D3C8@alkaline-solutions.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <1d517c85-dd81-b51a-dbb1-4390eebc35d3@aol.com>
Date: Tue, 20 Nov 2018 18:07:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <72896AA2-3E69-43A0-B583-04E33743D3C8@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="------------33962FFAD0E4EAD6A67E66F5"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 20 Nov 2018 23:07:36 -0000

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

All important points. I'm not sure it affects whether refresh_tokens 
should be bound to the authenticated session or not. If using a 
continuous authentication model, it just means that as long as the AS/OP 
believes the authentication session is valid, the refresh_token will 
also continue to be valid. When the authentication session is determined 
to be invalid, then the refresh_token is also revoked. In this 
"continuous authentication" model, it feels like forcing the user to 
re-authenticate would be a last resort. Instead other mechanisms would 
be used to increase the confidence that the identified user is correct.

On 11/20/18 5:47 PM, David Waite wrote:
>
>
>> On Nov 20, 2018, at 1:37 PM, Aaron Parecki > > wrote:
>>
>> The new section on refresh tokens is great! I have a couple 
>> questions/comments about some of the details.
>>
>>     Authorization servers may revoke refresh tokens automatically in case
>>     of a security event, such as:
>>     o  logout at the authorization server
>>
>> This doesn't sound like the desired behavior for mobile apps, where 
>> the user's expectation of how long they are logged in to the mobile 
>> app is not tied to their web session where they authorized the app. 
>> However this does likely match a user's expectation when authorizing 
>> a browser-based app. Should this be clarified that it should not 
>> apply to the mobile app case, or only apply to browser-based apps?
>
> There is also the model where web sessions are perpetual; where you 
> are evaluating access against a confidence that it is the legitimate 
> user against known threats. In that model, you require authentication 
> (perhaps by invalidating a client’s access and refresh tokens) as 
> needed to rebuild that confidence.
>
> This still is considered an online model; the offline model would be 
> distinguished by evaluating the confidence that a client is still 
> trusted and acting in the user’s interests.
>
> In terms of user-initiated logout - logout is an interesting action, 
> with both broad and miscommunicated purpose. I’ve found three 
> different verbalizations of why a user hits this button:
>
> 1. It must be here for some reason, so I think I’m supposed to hit it 
> when I’m done (aka 'security hygiene')
> 2. I suspect I might not be the next person who interacts with this 
> device, so you should ask me who I am before allowing future access 
> (aka ‘is this still you’)
> 3. I want software on this device to stop being able to access my 
> accounts, and to destroy any cached information (aka ‘kill switch’)
>
> All could be expected to stop access by online clients, while someone 
> operating under expectation #3 could extend even to stopping offline 
> access.
>
> Likewise, it could be said that users with expectation #2 would resume 
> access with previous scopes after an authentication, while expectation 
> #3 would imply a need to reestablish consent to resume.
>
> -DW
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    All important points. I'm
      not sure it affects whether refresh_tokens should be bound to the
      authenticated session or not. If using a continuous authentication
      model, it just means that as long as the AS/OP believes the
      authentication session is valid, the refresh_token will also
      continue to be valid. When the authentication session is
      determined to be invalid, then the refresh_token is also revoked.
      In this "continuous authentication" model, it feels like forcing the
      user to re-authenticate would be a last resort. Instead other
      mechanisms would be used to increase the confidence that the
      identified user is correct.
    
    
    
    
    On 11/20/18 5:47 PM, David Waite wrote:
    
    
    
    
    
      
      
    
      

    
        
    
          
    On Nov 20, 2018, at 1:37 PM, Aaron Parecki <aaron@parecki.com> wrote:
    
          
    
          
    
            
    
              
    
                
    
                  
    
                    
    
                      
    The new section on refresh tokens is
                        great! I have a couple questions/comments about
                        some of the details.
    
                      

    
                      
    
                      
    
                        
    Authorization
                          servers may revoke refresh tokens
                          automatically in case
    
                          of a security event, such as:
    
                          o  logout at the authorization server
    
                        
     
    
                      
    
                      
    This doesn't sound like the desired
                        behavior for mobile apps, where the user's
                        expectation of how long they are logged in to
                        the mobile app is not tied to their web session
                        where they authorized the app. However this does
                        likely match a user's expectation when
                        authorizing a browser-based app. Should this be
                        clarified that it should not apply to the mobile
                        app case, or only apply to browser-based apps?
    
                    
    
                  
    
                
    
              
    
            
    
          
    
        
    
        

    
        
    
        
    There is also the model where web sessions are perpetual;
          where you are evaluating access against a confidence that it
          is the legitimate user against known threats. In that model,
          you require authentication (perhaps by invalidating a client’s
          access and refresh tokens) as needed to rebuild that
          confidence.
    
        

    
        
    
        
    This still is considered an online model; the offline model
          would be distinguished by evaluating the confidence that a
          client is still trusted and acting in the user’s interests.
    
        

    
        
    
        
    In terms of user-initiated logout - logout is an
          interesting action, with both broad and miscommunicated
          purpose. I’ve found three different verbalizations of why a
          user hits this button:
    
      
    
      

    
      
    
      
    1. It must be here for some reason, so I think I’m supposed
        to hit it when I’m done (aka 'security hygiene')
    
      
    2. I suspect I might not be the next person who interacts
        with this device, so you should ask me who I am before allowing
        future access (aka ‘is this still you’)
    
      
    3. I want software on this device to stop being able to
        access my accounts, and to destroy any cached information (aka
        ‘kill switch’)
    
      

    
      
    
      
    All could be expected to stop access by online clients, while
        someone operating under expectation #3 could extend even to
        stopping offline access.
    
      

    
      
    
      
    Likewise, it could be said that users with expectation #2
        would resume access with previous scopes after an
        authentication, while expectation #3 would imply a need to
        reestablish consent to resume.
    
      

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

    
    
    
    
    
  


--------------33962FFAD0E4EAD6A67E66F5--


From nobody Tue Nov 20 15:39:44 2018
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 8769E1252B7; Tue, 20 Nov 2018 15:39:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-oauth-token-exchange@ietf.org, Hannes Tschofenig , Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154275717351.29758.7019772753190449469.idtracker@ietfa.amsl.com>
Date: Tue, 20 Nov 2018 15:39:33 -0800
Archived-At: 
Subject: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2018 23:39:34 -0000

Adam Roach has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who worked on this document. I have a blocking issue that
should be easy to resolve, and a handful of more minor issues.

§2.1:

>  The client makes a token exchange request to the token endpoint with
>  an extension grant type by including the following parameters using
>  the "application/x-www-form-urlencoded" format

This document needs a normative citation for this media type.

My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as this
appears to be the most recent stable description of how to encode this media
type. I'd love to hear rationale behind other citations being more appropriate,
since I'm not entirely happy with the one I suggest above (given that it's been
superseded by HTML 5.2); but every other plausible citation I can find is even
less palatable (with HTML 5.2 itself having the drawback of not actually
defining how to encode the media type, instead pointing to an unstable,
unversioned document).


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

Abstract:

>  This specification defines a protocol for an HTTP- and JSON- based

Nit: "...JSON-based..."

---------------------------------------------------------------------------

§1.1:

>  impersonates principal B, then in so far as any entity receiving such

Nit: "insofar"

---------------------------------------------------------------------------

§2.1:

>  The client makes a token exchange request to the token endpoint with
>  an extension grant type by including the following parameters using
>  the "application/x-www-form-urlencoded" format with a character
>  encoding of UTF-8 in the HTTP request entity-body:

I think there's an implication here that POST is used, but that probably needs
to be made explicit.

---------------------------------------------------------------------------

§2.2.1:

>  response using the "application/json" media type, as specified by
>  [RFC7159], and an HTTP 200 status code.  The parameters are

RFC 7159 has been replaced by RFC 8259.

---------------------------------------------------------------------------

§3:

>  urn:ietf:params:oauth:token-type:refresh_token
>     Indicates that the token is an OAuth 2.0 refreshe token issued by

nit: "refresh"



From nobody Tue Nov 20 23:08:26 2018
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 923AB130EDF for ; Tue, 20 Nov 2018 23:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.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 apLNdD50TlX5 for ; Tue, 20 Nov 2018 23:08:21 -0800 (PST)
Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0: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 4C57C127332 for ; Tue, 20 Nov 2018 23:08:21 -0800 (PST)
Received: by mail-it1-x133.google.com with SMTP id b5so7466597iti.2 for ; Tue, 20 Nov 2018 23:08:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7euNjT196GOL7XNDg4/hS4ovspmPG+dJn0GkfX/fic8=; b=FoTahU0ZmhdUkAEbLuGP5I7y+kXG16tsaIPp0+podRYuU9v3XQOz+KVNUbTthG42lC ilAEkJhQoE/aQB6lVzc7dCkxPkkz4QpLLlTuudXJvAstcB0SptRbnTcNJhHgf59kh6sS dDdcIIwuqh9JfJ0EG9sk0qt03ovKSSUQJLB/eEKLn1CIEwhLtdpLFXBYQW+TWZHDxU27 7j93pTIVnLSzMXqqTp08d3i8hkY0ageTJ9spup9PR0kRwUTPi2B0q1Xi+PBUEm6gnPqv dfEz/+v2ByGc9Eg3kH32vGYXkvHuVjrZZeIyp2buNBwkMk3LyS12u60dHiFrClJvwiCL 05zQ==
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=7euNjT196GOL7XNDg4/hS4ovspmPG+dJn0GkfX/fic8=; b=Raat5H6s5wI6MvfMT37NiDpqKak6WUXe+KEmKmfgRh/o5S8xrlkhngaxh34Y48EWqi HZJJBQ3h54PAz7Oj/feHKjZ1Zc5ZoMYkttb0AHnHjbK3pia7KUoSeZxt8M3OczPEmLhu zs57sT98sj4YcF/67QHYLUomeNep/jH/md3qeBheoMcKiVbE1Z1o9xNq7aqkM4O+snYK e1e2bSZWnYW7dyPedvc6SKm7aKLl8L+rK2Wj9zNluCVojalg/J9hyc5zcdRDmRMyODn4 ZMVevnqdPz9GF5+2sTFEIvjjiMUpuahB+/BFAhuhv78TRzIY15RPcbwtn4g+Bs1G/ZM9 qHrA==
X-Gm-Message-State: AA+aEWba0OOJ0jBEiz7pf5wbr+C6Z4aP/05tA4kAhi6qbktWrwGvo+sI I0YPBucIEEvhdgMr8graqo/2AnRuP2aInym7xCQlqg==
X-Google-Smtp-Source: AJdET5fmLH8LC9HYXOEL2PiI60M73sKDU1randnBuSaMz+VpIDemdigHjjJe/5Nf9SSPWJwghzSfLlBw+dAraIUKreU=
X-Received: by 2002:a02:89dd:: with SMTP id e29mr4689505jak.21.1542784100504;  Tue, 20 Nov 2018 23:08:20 -0800 (PST)
MIME-Version: 1.0
References:   <14BB75BB-F650-408D-8359-B25FA4E66DC9@alkaline-solutions.com> <1b451ff4-9de5-c3e2-acf3-f8b50b0212ff@aol.com>
In-Reply-To: <1b451ff4-9de5-c3e2-acf3-f8b50b0212ff@aol.com>
From: Hans Zandbelt 
Date: Wed, 21 Nov 2018 08:08:08 +0100
Message-ID: 
To: George Fletcher 
Cc: David Waite , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000046b31b057b276a1b"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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, 21 Nov 2018 07:08:25 -0000

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

I think of this as somewhat similar to:
a)  a grant type where a cookie grant is exchanged at an "RP token
endpoint" for an associated access and refresh token; the protocol between
SPA and the API to do so would benefit from standardization e.g. into SDKs
and server side frameworks
b) an "RP token introspection endpoint" where the cookie is introspected at
the RP and associated tokens are returned

if anyone comes up with a better name for this model and endpoint (and
probably less overloading of AS endpoint names...) and/or is willing to
help writing this down, please come forward and we'll pick it up on a new
thread/doc

Hans.

On Tue, Nov 20, 2018 at 11:00 PM George Fletcher  wrote:

> +1
>
> This model is useful and should be documented in its own right. Once
> documented it could possibly be referenced in the BCP.
>
> On 11/9/18 1:44 PM, David Waite wrote:
>
> Hi Hans, I hope it is acceptable to reply to your message on-list.
>
> Others could correct me if I am wrong, but I believe the purpose of this
> document is to recommend uses of other OAuth/OIDC specifications, not to
> include its own technologies.
>
> In terms of being another spec to be referenced, I think it would be
> useful but I wonder hypothetically how to best write that specification.
> This method seems to be relying on standards-defined tokens and convertin=
g
> them to an application server session, which isn=E2=80=99t defined by beh=
avior
> other than HTTP cookies. The session info hook then lets you use those
> proprietary session tokens to retrieve the access/id token.
>
> As such, it is closer to an architecture for implementing a client - as a
> confidential client backend with an associated SPA frontend that needs to
> make OAuth-protected calls. It is not describing the communication betwee=
n
> existing OAuth roles, such as between the client and AS.
>
> There=E2=80=99s obvious value here, and it's one of several architectures=
 for
> browser-based apps using a confidential client rather than a public one
> (another example being a reverse proxy which maps remote OAuth endpoints
> into local, session-token-protected ones). I personally am just not sure
> how you would define the communication between back-end and front-end
> portions of the client in these architectures as a standard within OAuth.
>
> -DW
>
> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt 
> wrote:
>
> Hi Aaron, DW,
>
> About draft-parecki-oauth-browser-based-apps:
> would you consider including a recommendation about and the
> standardization of a "session info" endpoint (I'm open for better naming
> ;-)) as described in:
>
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-p=
age-applications/
>
> this approach is not just something that I cooked up; it is based on real
> world requests & deployments at Netflix and OAth.
>
> Let me know what you think,
>
> Hans.
>
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
>
>> Hi all,
>>
>> Today we were not able to talk about
>> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 f=
or
>> Browser-Based Apps".
>>
>> Aaron put a few slides together, which can be found here:
>>
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sess=
a-oauth-2-for-browser-based-apps-00.pdf
>>
>> Your review of this new draft is highly appreciated.
>>
>> Ciao
>> Hannes
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy t=
he
>> information in any medium. Thank you.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>

--=20
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

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


    I think of this as somewhat similar to:
    a)=C2=A0 a gra=
nt type where a cookie grant is exchanged at an "RP token endpoint&quo=
t; for an associated access and refresh token; the protocol between SPA and=
 the API to do so would benefit from standardization e.g. into SDKs and ser=
ver side frameworks
    b) an "RP token introspection endpoint&q=
uot; where the cookie is introspected at the RP and associated tokens are r=
eturned

    if anyone comes up with a better name for =
this model and endpoint (and probably less overloading of AS endpoint names=
...) and/or is willing to help writing this down, please come forward and w=
e'll pick it up on a new thread/doc=C2=A0

    Hans=
.

    On Tue, Nov 20,=
 2018 at 11:00 PM George Fletcher <gffletch@aol.com> wrote:
    
 =20
   =20
 =20
  
    
    +1
    
      
    
      This model is useful and should be documented in its own right.
      Once documented it could possibly be referenced in the BCP.
    
    
    
    
    On 11/9/18 1:44 PM, David Waite wrote:
    
    
    
    
    
     =20
      Hi Hans, I hope it is acceptable to reply to your message on-list.
      

    
      
    
      
    Others could correct me if I am wrong, but I believe
        the purpose of this document is to recommend uses of other
        OAuth/OIDC specifications, not to include its own technologies.
      

    
      
    
      
    In terms of being another spec to be referenced, I
        think it would be useful but I wonder hypothetically how to best
        write that specification. This method seems to be relying on
        standards-defined tokens and converting them to an application
        server session, which isn=E2=80=99t defined by behavior other than =
HTTP
        cookies. The session info hook then lets you use those
        proprietary session tokens to retrieve the access/id token.
    
      

    
      
    
      
    As such, it is closer to an architecture for
        implementing a client - as a confidential client backend with an
        associated SPA frontend that needs to make OAuth-protected
        calls. It is not describing the communication between existing
        OAuth roles, such as between the client and AS.
    
      

    
      
    
      
    There=E2=80=99s obvious value here, and it's one of several
        architectures for browser-based apps using a confidential client
        rather than a public one (another example being a reverse proxy
        which maps remote OAuth endpoints into local,
        session-token-protected ones). I personally am just not sure how
        you would define the communication between back-end and
        front-end portions of the client in these architectures as a
        standard within OAuth.
    
      

    
      
    
      
    -DW
    
        

    
          
    
            
    On Nov 6, 2018, at 3:03 AM, Hans Zandbelt <hans.zandbelt@zmartzone=
.eu>
              wrote:
    
            
    
            
    
              
    
                
    
                  
    Hi Aaron, DW,
                    

    
                    
    
                    
    About=C2=A0draft-parecki-oauth-browser-based-apps:=

    
                    
    would you consider including a
                      recommendation about and the standardization of a
                      "session info" endpoint (I'm open for b=
etter
                      naming ;-)) as described in:
    
                    
                    

    
                    
    
                    
    this approach is not just something
                      that I cooked up; it is based on real world
                      requests & deployments at Netflix and OAth.
    
                    

    
                    
    
                    
    Let me know what you think,
    
                    

    
                    
    
                    
    Hans.
    
                  
    
                
    
              
    
              
    
              
    
                
    On Tue, Nov 6, 2018 at 10:55 AM
                  Hannes Tschofenig <Hannes.Tschofenig@arm.com>
                  wrote:
    
                
    
                
    Hi
                  all,
    
                  
    
                  Today we were not able to talk about
                  draft-parecki-oauth-browser-based-apps-00, which
                  describes=C2=A0 "OAuth 2.0 for Browser-Based Apps&qu=
ot;.
    
                  
    
                  Aaron put a few slides together, which can be found
                  here:
    
                  https://datatracker.ietf.org/meeting/103/mater=
ials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
    
                  
    
                  Your review of this new draft is highly appreciated.
    
                  
    
                  Ciao
    
                  Hannes
    
                  IMPORTANT NOTICE: The contents of this email and any
                  attachments are confidential and may also be
                  privileged. If you are not the intended recipient,
                  please 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.
    
                  
    
                  _______________________________________________
    
                  OAuth mailing list
    
                  OAuth=
@ietf.org
    
                  https://www.ietf.org/mailman/listinfo/o=
auth
    
                
    
              
    
              
    
              

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

    
    
    
    
    
  
    




    -- 
    

--00000000000046b31b057b276a1b--


From nobody Wed Nov 21 00:26:26 2018
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 D5623127332 for ; Wed, 21 Nov 2018 00:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 i0LQtDTI0zOM for ; Wed, 21 Nov 2018 00:26:23 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D862D124408 for ; Wed, 21 Nov 2018 00:26:22 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id f4so4140387edq.10 for ; Wed, 21 Nov 2018 00:26:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ClW9X5OuEA5dzn4GjznNQysJ2xKaHCHF97odegZ/h8g=; b=tGuP1bHRSeh9X5Y5MjI4bYw1S0UDbAZ6kjnmB/v2RrS2y/ZMTOlLOfHjmT6K/E/xB8 ycjMx47d8s+6Oo+QaS/X4v6F4N+unNfWR7vl97WKDKEhZjebDQQBiPpPfUZHXdBtNUZn zEJ9Tz6SHycFjHwzvgr/c2ju73++ZLJbkYQZsNP+1NZg665PoZ2OWnDi/z0uAqH6VXfk 3r3aZqGmAxHMYDnkob2qVtvqkszPEMVaIKxx5cUVxY6dQ+N/W0EWD8dVlayOcsqBqf/g aSSi0DKEZyHtDTrGKeGKD6+xPyshAsxgij+aXxBrbPbEEMC/ZVNoJIq5jfNMbtKafHX0 MhNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ClW9X5OuEA5dzn4GjznNQysJ2xKaHCHF97odegZ/h8g=; b=iWSu33w6xbw1/gCSdA28E9zHkHLY38EYnuWWGUHxuECqYgH2zcQgbQic8Qpxhyi+gg vAHkZu/TzG4nppnMgN6eMkad8XmXlybr0u1hJwKUHr8MkK3uw3HyQUcBkUzik8ypphv6 uROA5UtTqI5nPwuwCAkHy/Jn+5IBbH4wGfkP1b96SAsKw9geKzSPhMnHTh747Ty08Yp3 swno7V+YkD1ZqzVR/pZ3F4qen8Isqm8bxt4OFa/7J+Wq+BvV7cTz0fglotAh8PG4ZacR FWRc/uxpBeTG/YPvLcskRor19569mvYp73Z/Xd0wdyyb/tLWz6IX4/CHJFwoArRRTdN4 Gubw==
X-Gm-Message-State: AA+aEWZ3pBSGqYCnjdC5U5IDUyrvM+LBj26r4XsOIY10e35I6HmhhVqJ 02gqHts1YTISbp1ECCE0ktA35r7JK10=
X-Google-Smtp-Source: AFSGD/Wl/j9VD8N4R76vNkijTZ7jCIeqTgdy+I1lEjVHl6pTc7M2VugvZxAv8odLc2ScVAgjhMgxZw==
X-Received: by 2002:a50:d48a:: with SMTP id s10-v6mr4884523edi.127.1542788780625;  Wed, 21 Nov 2018 00:26:20 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id g13-v6sm6592637ejr.1.2018.11.21.00.26.19 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 00:26:19 -0800 (PST)
To: oauth@ietf.org
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com>
From: Daniel Fett 
Message-ID: <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com>
Date: Wed, 21 Nov 2018 09:26:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com>
Content-Type: multipart/alternative; boundary="------------6E0C84728C14BA5D8ECD270B"
Content-Language: de-DE
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 08:26:25 -0000

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

Am 20.11.18 um 13:24 schrieb Neil Madden:
> If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained tokens are very effective as those scripts run in the same TLS context as the legitimate client?

Please correct me if I'm wrong, but if a page/SPA/origin includes a
malicious third party script, the third party script can access all data
of that JavaScript. It can exfiltrate tokens and/or send requests on
behalf of that page/SPA/origin (using the page/SPA/origin's TLS context,
cookies, etc.).

So I doubt that there is any better solution than token binding or mTLS.

If we assume that an SPA includes a malicious third party script, it is
completely compromised.

-Daniel


--------------6E0C84728C14BA5D8ECD270B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    Am 20.11.18 um 13:24 schrieb Neil
      Madden:
    
    
    
    
    
      
    If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained tokens are very effective as those scripts run in the same TLS context as the legitimate client?

    
    
    
    
    Please correct me if I'm wrong, but if a page/SPA/origin includes
      a malicious third party script, the third party script can access
      all data of that JavaScript. It can exfiltrate tokens and/or send
      requests on behalf of that page/SPA/origin (using the
      page/SPA/origin's TLS context, cookies, etc.). 
    
    
    
    
    So I doubt that there is any better solution than token binding
      or mTLS.
    
    
    If we assume that an SPA includes a malicious third party script,
      it is completely compromised.
    
    
    
    
    -Daniel
    
    
    
  


--------------6E0C84728C14BA5D8ECD270B--


From nobody Wed Nov 21 00:35:02 2018
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 9E0C2127332 for ; Wed, 21 Nov 2018 00:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 FQQKB1D4KAsx for ; Wed, 21 Nov 2018 00:34:58 -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 38DD2124408 for ; Wed, 21 Nov 2018 00:34:58 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id z5so393055wrt.11 for ; Wed, 21 Nov 2018 00:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C7iQ0vTvJBMrtkwacP9JpRDXTndp3SkAwE9Piy5Ha3A=; b=JnjsSxVK6Urp9m6wJWBEZVSUzZE0Di/UKJt66fCq5Cr2SbRshNgXGp4p90IRCLCkKF JryZ2DCXUx6i+gTM7LuUKtzFgWSBehvuiIQCjjxLwNBDXg2K0tneWFtXk8Ffo8aRK9It zO9RDyFN2JfJIoGd1x8mnGfMfY5TqA/Jr5WkQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C7iQ0vTvJBMrtkwacP9JpRDXTndp3SkAwE9Piy5Ha3A=; b=s3ZaKaPlExZajI4Uri7DlLJufGT2eFeNHuOC43CU0TsZQnpZ/DSB+08qhMq4Wiuhy1 G5tMZb5ZhVUyguYXPFshTUkBn/vOAk4S3FiIqSmSGq89QphZMdVjTHpzoK667HkTDMpQ SFbImqpZPfevKFowvd/I7rjNS+tQJmVHCfdAmwbASKqeKRxJRgf/wDM0Jl5mfNzvryrT jWdVGFCgfCS8Qjy+bLeRjdzzp0GyQfZH2lp2QsrK6s6Gh5hhpSy+Pwvcyt7prsSh5l0V Y3n1Oh54I7n3ATB43ei+9IPMKZyqalq7HsIkZGJItB+OsnyqEUkKfgFMv4/Ej8Xnf0lj jwhA==
X-Gm-Message-State: AA+aEWYR1X5/J29FOKH0E7ZCX+Q36bIJAE0TfQiLzBm9RwnEirKtT4iY +H/nViH2VxJwzMxIeZN8Zm2uS9knPuA=
X-Google-Smtp-Source: AFSGD/XG4bkgoP0yg1+/ZieJe0ALuYvdLNq77yYEjQNHGHoqc0YAIUfQyk2PpsEV03d5sB6WOZJZ0A==
X-Received: by 2002:adf:82e4:: with SMTP id 91mr4991533wrc.131.1542789296558;  Wed, 21 Nov 2018 00:34:56 -0800 (PST)
Received: from ?IPv6:2a01:4c8:1a:2953:31f3:b6a:47c5:df61? ([2a01:4c8:1a:2953:31f3:b6a:47c5:df61]) by smtp.gmail.com with ESMTPSA id c188-v6sm167935wma.39.2018.11.21.00.34.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 00:34:55 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-64F51EED-EB24-4BCA-961F-A44C7E56DAD5
Mime-Version: 1.0 (1.0)
From: Neil Madden 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com>
Date: Wed, 21 Nov 2018 08:34:54 +0000
Cc: oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com>
To: Daniel Fett 
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 08:35:01 -0000

--Apple-Mail-64F51EED-EB24-4BCA-961F-A44C7E56DAD5
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

> On 21 Nov 2018, at 08:26, Daniel Fett  wrote:
>=20
>> Am 20.11.18 um 13:24 schrieb Neil Madden:
>> If we are discussing this in the context of client-side web apps/SPAs, th=
en surely the threat model includes malicious 3rd party scripts - for which n=
either token binding nor mTLS constrained tokens are very effective as those=
 scripts run in the same TLS context as the legitimate client?
> Please correct me if I'm wrong, but if a page/SPA/origin includes a malici=
ous third party script, the third party script can access all data of that J=
avaScript. It can exfiltrate tokens and/or send requests on behalf of that p=
age/SPA/origin (using the page/SPA/origin's TLS context, cookies, etc.).=20
>=20
> So I doubt that there is any better solution than token binding or mTLS.
>=20
> If we assume that an SPA includes a malicious third party script, it is co=
mpletely compromised.
>=20

No - same origin policy prevents those things. TLS doesn=E2=80=99t have thos=
e protections though because it acts at the transport layer and SOP is an ap=
plication-layer concept.=20

=E2=80=94 Neil=

--Apple-Mail-64F51EED-EB24-4BCA-961F-A44C7E56DAD5
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    On 2=
1 Nov 2018, at 08:26, Daniel Fett <danielf+oauth@yes.com> wrote:

    
 =20
    
 =20
 =20
    
    Am 20.11.18 um 13:24 schrieb Neil
      Madden:
    
    
    
    
    
      
    If we are discussing this in th=
e context of client-side web apps/SPAs, then surely the threat model include=
s malicious 3rd party scripts - for which neither token binding nor mTLS con=
strained tokens are very effective as those scripts run in the same TLS cont=
ext as the legitimate client?

    
    
    
    
    Please correct me if I'm wrong, but if a page/SPA/origin includes
      a malicious third party script, the third party script can access
      all data of that JavaScript. It can exfiltrate tokens and/or send
      requests on behalf of that page/SPA/origin (using the
      page/SPA/origin's TLS context, cookies, etc.). 
    
    
    
    
    So I doubt that there is any better solution than token binding
      or mTLS.
    
    
    If we assume that an SPA includes a malicious third party script,
      it is completely compromised.

    No - same=
 origin policy prevents those things. TLS doesn=E2=80=99t have those protect=
ions though because it acts at the transport layer and SOP is an application=
-layer concept. 

    =E2=80=94 Neil
    =

--Apple-Mail-64F51EED-EB24-4BCA-961F-A44C7E56DAD5--


From nobody Wed Nov 21 00:39:38 2018
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 7E286130EE9 for ; Wed, 21 Nov 2018 00:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 7C6EEB10nETZ for ; Wed, 21 Nov 2018 00:39:34 -0800 (PST)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BCB12870E for ; Wed, 21 Nov 2018 00:39:34 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id c126so4825687wmh.0 for ; Wed, 21 Nov 2018 00:39:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=FoVP0J9ghhatskfBTa5zuZaGbRQzmKOMzjd16yYG8dc=; b=AX5h7dw+YzOT7ftv8oljjus2hdtSbAXaYYdnfiKhRVpGLzlrmZyYkZkQ8vccuFRhEg idm701vppsIdW6TCqa36Z8i3V/IdgZOowJC7bq7TOoMklbj6zy0KnsE2a/ZVP5lwX/eU 6u6oGjZbknxTgjgFa+2GMbyvEHcWhLGG8Zzl4Px1ilqOO51RPO3621db4vWy/baCPYsJ eam+IjhAh07LpGTPUJ9munhiq7HXvsAcO+FCC9M+UiOiOho9RYccAbZNHGrEGe2K0/qc owJS0f0Ah66qDs7EAhmwpnP67PMnUTAlxYx84ZWaHrbVre2gJeveckftdDjpS20AnhEx RBwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=FoVP0J9ghhatskfBTa5zuZaGbRQzmKOMzjd16yYG8dc=; b=HNBMjFzQJVG6VH6mkDmAX/vUErRHgwNjI46A5fcYubIq8ORM7IAi0RU/F2gI5wiW9Y TKa6RqgeAzlz/mxQwmtksmK43DTFEx0nQ9bMyRwteP6j0Kn01PDChwEdmmwW47pkcShe 4A86KL4dIcN4XvdUlUj7MQSNvgDH4nNqiD2qKMWdTgHisvEPYhpDb+VWYrbAAz43FYUp lcCcC3HpaUWaup4PptM0Xr5rOV3vngBP8Rcpp43d+Fmrh5rUvqFw7I0Py0aEdvimy2gi XxZeqIq2HyulTshrIKkq4b+W2278Ubs99CqRU38kP28WU6N35tdExbXn7Px6hxrgzFXg 2ICA==
X-Gm-Message-State: AA+aEWb5XUHbsv+HKEtwI8MiRvCKNhQyYO0C5Ic9eBQPzDoGHu+5pzHA XzWXK2L6qT2GDviNsRMWogIaS/RTVdY=
X-Google-Smtp-Source: AJdET5eeioLIyF1BXXtHIIUzSglup0xdbCM3V7B6b9B8FRdbz/Lss+HEVq4q4nmx+c8xOfNNPWenzA==
X-Received: by 2002:a1c:9706:: with SMTP id z6mr5020672wmd.51.1542789572478; Wed, 21 Nov 2018 00:39:32 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id x142-v6sm641062wmd.20.2018.11.21.00.39.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 00:39:31 -0800 (PST)
To: Neil Madden 
Cc: oauth@ietf.org
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>
From: Daniel Fett 
Message-ID: 
Date: Wed, 21 Nov 2018 09:39:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>
Content-Type: multipart/alternative; boundary="------------60C8011629E8C2C221A62E1F"
Content-Language: de-DE
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 08:39:36 -0000

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

Am 21.11.18 um 09:34 schrieb Neil Madden:
> On 21 Nov 2018, at 08:26, Daniel Fett  > wrote:
>
>> Am 20.11.18 um 13:24 schrieb Neil Madden:
>>> If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained tokens are very effective as those scripts run in the same TLS context as the legitimate client?
>>
>> Please correct me if I'm wrong, but if a page/SPA/origin includes a
>> malicious third party script, the third party script can access all
>> data of that JavaScript. It can exfiltrate tokens and/or send
>> requests on behalf of that page/SPA/origin (using the
>> page/SPA/origin's TLS context, cookies, etc.).
>>
>> So I doubt that there is any better solution than token binding or mTLS.
>>
>> If we assume that an SPA includes a malicious third party script, it
>> is completely compromised.
>>
>
> No - same origin policy prevents those things. TLS doesn’t have those
> protections though because it acts at the transport layer and SOP is
> an application-layer concept.

If a page from origin A includes a third-party script from origin B,
that external script runs in origin A and has access to all cookies and
the JavaScript context of the page.

The SPA from origin A would be compromised. That is why we need things
such as Subresource Integrity.

-Daniel


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


  
    
  
  
    
    Am 21.11.18 um 09:34 schrieb Neil
      Madden:
    
    
    
    
    
      
      
    On 21 Nov 2018, at 08:26, Daniel Fett <danielf+oauth@yes.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
          
    Am 20.11.18 um 13:24 schrieb Neil
            Madden:
    
          
    
          
    
            
    If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained tokens are very effective as those scripts run in the same TLS context as the legitimate client?

    
          
    
          
    Please correct me if I'm wrong, but if a page/SPA/origin
            includes a malicious third party script, the third party
            script can access all data of that JavaScript. It can
            exfiltrate tokens and/or send requests on behalf of that
            page/SPA/origin (using the page/SPA/origin's TLS context,
            cookies, etc.). 
    
          
    
          
    So I doubt that there is any better solution than token
            binding or mTLS.
    
          
    If we assume that an SPA includes a malicious third party
            script, it is completely compromised.
    
        
    
      
    
      
    
      
    No - same origin policy prevents those things. TLS doesn’t
        have those protections though because it acts at the transport
        layer and SOP is an application-layer concept. 
    
      
    
    
    
    
    If a page from origin A includes a third-party script from origin
      B, that external script runs in origin A and has access to all
      cookies and the JavaScript context of the page.
    
    
    
    
    The SPA from origin A would be compromised. That is why we need
      things such as Subresource Integrity.
    
    
    -Daniel
    
    
    
  


--------------60C8011629E8C2C221A62E1F--


From nobody Wed Nov 21 00:48:03 2018
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 5644D130EE2 for ; Wed, 21 Nov 2018 00:48:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 bJCLs217dBaX for ; Wed, 21 Nov 2018 00:47:58 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C4E12870E for ; Wed, 21 Nov 2018 00:47:57 -0800 (PST)
Received: from [80.187.102.95] (helo=[172.20.10.2]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gPOAp-0000Ed-7m; Wed, 21 Nov 2018 09:47:51 +0100
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_50975194-AC6E-43D5-BBB5-441FEC9E376A"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 21 Nov 2018 09:47:49 +0100
In-Reply-To: 
Cc: George Fletcher , Mike Jones , "oauth@ietf.org" 
To: John Bradley 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com> 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 08:48:01 -0000

--Apple-Mail=_50975194-AC6E-43D5-BBB5-441FEC9E376A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

We had a discussion about this topic on Twitter =
https://twitter.com/Apl3b/status/1064854507606208513

Outcome is POST requires a backend to receive the request so it=E2=80=99s =
not a viable solution for SPAs.

> Am 20.11.2018 um 23:29 schrieb John Bradley :
>=20
> Post response works OK for server based clients.  I don't think POST =
works for single page applications. =20
>=20
> Basically that would be something more like postmessage between two JS =
apps. =20
>=20
> Postmessage also has security issues passing a access token and =
leaking. =20
>=20
> Perhaps someone more familiar with SPA can comment on POST. =20
>=20
> John B.=20
>=20
>=20
>=20
> On Tue, Nov 20, 2018, 6:40 PM George Fletcher  Hi Mike,
>=20
> The Form Post Response Mode keeps the access_token out of the URL, but =
it doesn't prevent the token from traversing through the browser. So a =
man-in-the-browser attack may be able to intercept the values. It should =
help with leakage in logs.
>=20
> Thanks,
> George
>=20
> On 11/20/18 4:00 PM, Mike Jones wrote:
>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Response =
Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html =
mitigate the threats you=E2=80=99re describing below John?  If so, I =
believe the Security Topics draft should say this.
>>=20
>> =20
>>=20
>> I believe we owe it to readers to present the complete picture, which =
is why I believe that describing profiles using ID Tokens and the Form =
Post Response Mode are in scope.
>>=20
>> =20
>>=20
>>                                                        -- Mike
>>=20
>> =20
>>=20
>> From: OAuth  On Behalf Of John Bradley
>> Sent: Tuesday, November 20, 2018 7:47 AM
>> To: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
>>=20
>> =20
>>=20
>> Yes the at_hash protects the client from accepting an injected AT.=20
>>=20
>> Unfortunately it doesn't do anything to protect against leakage in =
logs or redirects.
>>=20
>> So without the AT using some sort of POP mechanism it is hard to say =
sending it in a redirect is a good security practice.
>>=20
>> John B.
>>=20
>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>=20
>> Hi Mike,=20
>> =20
>> I agree that OIDC hybrid flows offer additional security over the =
OAuth implicit grant and are used in the wild. On my slides and in the =
initial version of the new section, we had included the hybrid OIDC =
flows because of their known token injection countermeasures.
>> =20
>> I nevertheless feel very uncomfortable to recommend those flows and =
any flow issuing access tokens in the front channel. In the course of =
the detailed review of the new text we realized two issues:=20
>> =20
>> 1) Since the access token is exposed in the URL, such flows possess a =
significantly higher risk to leak the access token (e.g. through browser =
history, open redirection and even referrer headers) than the code =
grant.
>> 2) There is no viable way to sender constrain access tokens issued in =
the front channel. Given the WG decided to recommend use of sender =
constraint tokens =
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2=
..2), it seems contradictory to recommend response types not supporting =
such an approach.=20
>> =20
>> kind regards,
>> Torsten.=20
>> =20
>> Am 19.11.2018 um 23:13 schrieb Mike Jones =
:
>> =20
>> This description of the situation is an oversimplification..  OpenID =
Connect secures the implicit flow against token injection attacks by =
including the at_hash (access token hash) in the ID Token, enabling the =
client to validate that the access token was created by the issuer in =
the ID Token (which is also the OAuth Issuer, as described in RFC 8414). =
 (Note that this mitigation was described in =
draft-ietf-oauth-mix-up-mitigation.)
>> =20
>> Given the prevalence of this known-good solution for securing the =
implicit flow, I would request that the draft be updated to describe =
this mitigation.  At the same time, I=E2=80=99m fine with the draft =
recommending the code flow over the implicit flow when this mitigation =
is not used.
>> =20
>>                                                                 Thank =
you,
>>                                                                 -- =
Mike
>> =20
>> From: OAuth  On Behalf Of Hannes Tschofenig
>> Sent: Monday, November 19, 2018 2:34 AM
>> To: oauth 
>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization =
code instead of implicit
>> =20
>> Hi all,
>> =20
>> The authors of the OAuth Security Topics draft came to the conclusion =
that it is not possible to adequately secure the implicit flow against =
token injection since potential solutions like token binding or JARM are =
in an early stage of adoption. For this reason, and since CORS allows =
browser-based apps to send requests to the token endpoint, Torsten =
suggested to use the authorization code instead of the implicit grant in =
call cases in his presentation =
(seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-se=
ssb-draft-ietf-oauth-security-topics-01).
>> =20
>> A hum in the room at IETF#103 concluded strong support for his =
recommendations. We would like to confirm the discussion on the list.
>> =20
>> Please provide a response by December 3rd.
>> =20
>> Ciao
>> Hannes & Rifaat
>> =20
>> IMPORTANT NOTICE: The contents of this email and any attachments are =
confidential and may also be privileged. If you are not the intended =
recipient, please 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.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>>=20
>> 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=_50975194-AC6E-43D5-BBB5-441FEC9E376A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjEwODQ3NTBaMC8GCSqGSIb3DQEJBDEiBCBn
1IrV0Mxgp6OHdR+wtFdn1gP9ccfrRLxF1b7qtJjJczCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAnjnjQVCOz6cE4drf8KZlh/0v
nUGdzo9t/lcswDFCyQlFZEg9+yLJuE4tOP9dtwdquj0+GMWnMlJy9o6HC78eNNb4MRn+OL+vZ8NS
eVR+1AEivAQ6ElHuA8je2GR+OWWgMl/KgcOsHkB6FglrRYEKwHqLIQNhJW6sSEAPyXxNGybn9AvY
QIIKy2szuqjrwfIoefC1vGpk0zYZQNFLNn8rsxAhlNKJ3nfuRajWJhF9ET/ckTLlAvQPLmeGfyLT
TF2F791n2Dk4IxloPE4Y0rQvfPBuk3hElH8Lx5gjlm+8oqKJQOIkj0c1CYOqNdLejk65zJBXYp/I
V2FGDgkMPV78qwAAAAAAAA==
--Apple-Mail=_50975194-AC6E-43D5-BBB5-441FEC9E376A--


From nobody Wed Nov 21 01:09:13 2018
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 0AEE3130EB4 for ; Wed, 21 Nov 2018 01:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 PGeq6hvX_aRx for ; Wed, 21 Nov 2018 01:09:09 -0800 (PST)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597D1130EF6 for ; Wed, 21 Nov 2018 01:09:07 -0800 (PST)
Received: by mail-wr1-x42d.google.com with SMTP id b13so4814743wrx.6 for ; Wed, 21 Nov 2018 01:09:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yr8FsjSJX0zv5+Fpcz0J5bNgsOVRdja95ZYFV/KhLp8=; b=g4S+8ysEjnkqsxc3or/yOxnNEhWIXeftTL6XS5PDudTURd3azoKVcMkwGMY5FfdkN3 r3sUeWZbtbCRVA5TWricKGf7j0EsP4/ZoZqgXH8TBcQiBexhA5e/DwI4WHp8IHzfwsNO oznzoD3l24WoboIip3G+Bb2Ve+VaA3vMqR8/Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yr8FsjSJX0zv5+Fpcz0J5bNgsOVRdja95ZYFV/KhLp8=; b=Far48kWiFvLyG8rdnDWYaGc0r6JUYDvSNj/5YR60GTqBSrDQ8RSSsE0FDDbvJoT7cB Qe+0+qE5wn2gNp0MVGcA7xOwq587Lm7WNkwdfWp8VfK1UmNhC8vbko1haORazBXd+NGv KmC3gfXGuSobI5Z+FSeE4l5GsgIjNK5hfL/T1W5XNfo76z0EQByILdrqPt6zvt5RfhNK jMEttg+vEEuf3RDHsXJAFrUVFxHlHvLED/D02zukROmM2kSKgZN3B9lPZtl1mBqxRLfX zx15ciI6wM+qsFNQrPWl/tGPoZWhKSKMpJGa6HVDgKl1Nv0hP7HDafLZxwZKoTEUlplv GJJw==
X-Gm-Message-State: AA+aEWYBDqngqFVX7+w7GUC+OwjAcr6K/bKDSbibwna3arvhTEQT7Inr sHEvSM+AQNQ5VjW6X46B9nY6IA==
X-Google-Smtp-Source: AFSGD/X/x2CzCNYR9hctvzxhqGdh6hx3ZlXb2JFWHnpubDMao8uF0KEujaHM24ZcyvKnOjknY3fH5Q==
X-Received: by 2002:a05:6000:1189:: with SMTP id g9mr5263526wrx.221.1542791345581;  Wed, 21 Nov 2018 01:09:05 -0800 (PST)
Received: from guest2s-mbp.lan (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id m80sm334506wmd.35.2018.11.21.01.09.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 01:09:04 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Neil Madden 
In-Reply-To: 
Date: Wed, 21 Nov 2018 09:09:03 +0000
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C8699BF-EE70-4299-91F2-87E8818E7464@forgerock.com>
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com> 
To: Daniel Fett 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 09:09:11 -0000

On 21 Nov 2018, at 08:39, Daniel Fett  wrote:
>=20
> Am 21.11.18 um 09:34 schrieb Neil Madden:
>> On 21 Nov 2018, at 08:26, Daniel Fett  wrote:
>>=20
>>> Am 20.11.18 um 13:24 schrieb Neil Madden:
>>>> If we are discussing this in the context of client-side web =
apps/SPAs, then surely the threat model includes malicious 3rd party =
scripts - for which neither token binding nor mTLS constrained tokens =
are very effective as those scripts run in the same TLS context as the =
legitimate client?
>>>>=20
>>> Please correct me if I'm wrong, but if a page/SPA/origin includes a =
malicious third party script, the third party script can access all data =
of that JavaScript. It can exfiltrate tokens and/or send requests on =
behalf of that page/SPA/origin (using the page/SPA/origin's TLS context, =
cookies, etc.).=20
>>>=20
>>> So I doubt that there is any better solution than token binding or =
mTLS.
>>>=20
>>> If we assume that an SPA includes a malicious third party script, it =
is completely compromised.
>>>=20
>>=20
>> No - same origin policy prevents those things. TLS doesn=E2=80=99t =
have those protections though because it acts at the transport layer and =
SOP is an application-layer concept.=20
> If a page from origin A includes a third-party script from origin B, =
that external script runs in origin A and has access to all cookies and =
the JavaScript context of the page.
>=20
> The SPA from origin A would be compromised. That is why we need things =
such as Subresource Integrity.

I think we=E2=80=99re talking about different things. I am talking about =
scripts from places like ad servers that are usually included via an =
iframe to enforce the SOP and sandbox them from other scripts. If they =
get access to an access token - e.g. via document.referrer or a redirect =
or some other leak, then they still act within the same TLS context as =
the legitimate client.

=E2=80=94 Neil=


From nobody Wed Nov 21 01:25:55 2018
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 2088C129AB8 for ; Wed, 21 Nov 2018 01:25:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 6c4e4i_BT4Fk for ; Wed, 21 Nov 2018 01:25:52 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEA812958B for ; Wed, 21 Nov 2018 01:25:52 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id y185so2796042wmd.1 for ; Wed, 21 Nov 2018 01:25:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=3ThQHNLIdUT38WnoGLcVDD5jcPvBnB0aO2ZydRtN7w0=; b=AaDRKRUasI+QDkpi57tbamEL4oqLpawdYF/KgHcJ20vMp5qiV/9dLyr15KSilAxwtH IWhR303CUqs3gNijFQp6GHFSadluOHJ/I0bnKSXiZyPOWtXYUTzEA50zrrjwiQRMpT1D aF5pQjq0K1Ef7/CxP+Dwpe7LluramiH8XtvIIPDUJwdtaPzrtoQ+11GyJshRl/5O9wPP sWVWER4IIHGvcdBAWxGmgXcHj54VecIJU2TAI23k1GU+3sbqhqTFvFrsR5DcbolUqTWu ApZc/0XMqUQlQ170D9CUZJ86jMXV4YNin38Bz/hn7DNWCeuG6c7EpC37XY2/3uYrtXmh zsVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=3ThQHNLIdUT38WnoGLcVDD5jcPvBnB0aO2ZydRtN7w0=; b=sBomnN0JoJEwsp+PHw07H070V9Lw9yltPCKK92PAPcWJp7lva91fHsyWI8ZDgTt9t1 uzvTbbKfqwLggLJvdCpc5J9OkcZWgId2W5SsOqVkGkkXAjI36Vz11PtuOAEPZUMJLWiV X6eAfTw+TZ5i1q+5A4bledi6Yk0TRr1w8dG8YFWhB+mHY1DrNSQBPtIDEyDsvcRwH46T poF57TG+VydFaWadOtGSxHhHk07lDKTGcCJXfSYVX8gO5dSZT3syGJpohs8WStnpAJHv YToVG3nqAigsdtj93cvRXyNGjQTVIG8WknMmaUG0+vvB7i30Esz7DRxDblvuilqDp9Ki Q0Cg==
X-Gm-Message-State: AA+aEWZnTKZ64hLZzFyHnCnx3+4YiqfJMXFE7V5KVE367ILXdMqzjivD gBDor/O6wZtZoC3x1ifRQXxeqH5aeD8=
X-Google-Smtp-Source: AFSGD/ULDw8qsw30MRpjZtNKWaOKV8Xc1OfdCZxgL+2y+x4lqmHgECz9qNDCwD4apIzjpvfRE+Vh+A==
X-Received: by 2002:a1c:2d57:: with SMTP id t84-v6mr5313549wmt.9.1542792350647;  Wed, 21 Nov 2018 01:25:50 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id 82-v6sm261430wms.17.2018.11.21.01.25.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 01:25:50 -0800 (PST)
To: Neil Madden 
Cc: oauth@ietf.org
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>  <3C8699BF-EE70-4299-91F2-87E8818E7464@forgerock.com>
From: Daniel Fett 
Message-ID: <83034de5-cde8-8cd9-ff11-7ce22b61fee6@yes.com>
Date: Wed, 21 Nov 2018 10:25:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <3C8699BF-EE70-4299-91F2-87E8818E7464@forgerock.com>
Content-Type: multipart/alternative; boundary="------------504311A378A3D3E1B1218C20"
Content-Language: de-DE
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 09:25:54 -0000

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

Am 21.11.18 um 10:09 schrieb Neil Madden:
>> If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.
>>
>> The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.
> I think we’re talking about different things. I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client.

Thanks for the clarification! I see that you highlight an important
point there.

The protection that would be required essentially boils down to
something similar to a CSRF protection for the resource server.

Luckily, CORS covers this: You can't set the Authorization header
cross-origin unless the appropriate CORS headers are set. So while the
third party origin would be able to send a request through the browser
using the TLS context, it would not be able to attach the access token.
(Unless, of course, that third party origin is whitelisted, or if the
bearer token is sent in a different way, e.g., as a URL parameter.)

As a side note, interestingly, this would leave an authorization code
unprotected, if the sender authentication would be mTLS or token
binding. PKCE on the other hand is fine.



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


  
    
  
  
    
    Am 21.11.18 um 10:09 schrieb Neil
      Madden:
    
    
    
    
      
    
        
    If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.

The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.

    
      
    
      
    I think we’re talking about different things. I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client.
    
    
    
    
    Thanks for the clarification! I see that you highlight an
      important point there.
    
    
    
    
    The protection that would be required essentially boils down to
      something similar to a CSRF protection for the resource server.
    
    
    Luckily, CORS covers this: You can't set the Authorization header
      cross-origin unless the appropriate CORS headers are set. So while
      the third party origin would be able to send a request through the
      browser using the TLS context, it would not be able to attach the
      access token. (Unless, of course, that third party origin is
      whitelisted, or if the bearer token is sent in a different way,
      e.g., as a URL parameter.)
    
    
    As a side note, interestingly, this would leave an authorization
      code unprotected, if the sender authentication would be mTLS or
      token binding. PKCE on the other hand is fine.
    
    
    
    

    
    
    
  


--------------504311A378A3D3E1B1218C20--


From nobody Wed Nov 21 02:01:57 2018
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 988F512D4EB for ; Wed, 21 Nov 2018 02:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 yiFBiGjKTvtv for ; Wed, 21 Nov 2018 02:01:53 -0800 (PST)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B42129AB8 for ; Wed, 21 Nov 2018 02:01:52 -0800 (PST)
Received: by mail-wr1-x434.google.com with SMTP id 96so4998655wrb.2 for ; Wed, 21 Nov 2018 02:01:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YS7gj/At/cdkb0NpU3qLGh7k8yDHGMQ3/15aIWy8/9o=; b=c/kqzY6sZd9H0eVh+r7QsAA4neU2YoyQGIOtmFkMGJJqcCyj28BvEeLIYwyuGl0ihq W3ORTPDTcXXK2DdCuVw0k+ndNUWba3XEyL7SQ6VJpmcZrcflK7BuxpoQZF8+dN1PBGZ8 v9+25R1dPzwhhBaM8pP2bLD98uWccmFp654Ho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YS7gj/At/cdkb0NpU3qLGh7k8yDHGMQ3/15aIWy8/9o=; b=TBOczW8/1pFbj2h3iWuL3O0unSTffgic84NNNP357VN9inVX52xrKVFytzuCxqntRF Mz/EeWgUuWRRO74+xjFy6EDU/e2JzG48hQloHgczxo0sUHLQhhpN92ZRMWJd1kdb9Lpl 3/+8572n3PdbqjEcg6uJ60x786luPL41GTy9C4ElNRYZkLJbEojv5XU/tYCfFSFtOAnY k/OI1I9OSxfEWrufmePE1QNftOQV0fwFMCsRJcHla+DJrwKcSdIoYx3aJJLAX911PhHd b03VA5bQ9paGYjmz0zoAU1eYaUf9X7HmwvvzTl4bTq/2kAUtF5jEyNwv+5FiJWkhPnS3 5aVg==
X-Gm-Message-State: AA+aEWYoQMOlp1knmxrM1eF1ngYK45SUeT4OM77OylL43eTMEkZSiYXZ HYpYXyOcrHvnAahtnN6g/jSpd6eYXx0=
X-Google-Smtp-Source: AFSGD/Xv0RrFxyI5jzWM4zjOTujL/UTda/4dJwh89WJBcWdVQxbfxFKOqXL8GhcTbYvArDEK8uxXeg==
X-Received: by 2002:adf:800b:: with SMTP id 11-v6mr5428242wrk.106.1542794511148;  Wed, 21 Nov 2018 02:01:51 -0800 (PST)
Received: from guest2s-mbp.lan (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id e8-v6sm275215wmf.22.2018.11.21.02.01.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 02:01:50 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Neil Madden 
In-Reply-To: <83034de5-cde8-8cd9-ff11-7ce22b61fee6@yes.com>
Date: Wed, 21 Nov 2018 10:01:49 +0000
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <70557E9F-8A8B-4BEB-80CC-07EFD74FFBF0@forgerock.com>
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>  <3C8699BF-EE70-4299-91F2-87E8818E7464@forgerock.com> <83034de5-cde8-8cd9-ff11-7ce22b61fee6@yes.com>
To: Daniel Fett 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 10:01:55 -0000

> On 21 Nov 2018, at 09:25, Daniel Fett  wrote:
>=20
> Am 21.11.18 um 10:09 schrieb Neil Madden:
>>> If a page from origin A includes a third-party script from origin B, =
that external script runs in origin A and has access to all cookies and =
the JavaScript context of the page.
>>>=20
>>> The SPA from origin A would be compromised. That is why we need =
things such as Subresource Integrity.
>>>=20
>> I think we=E2=80=99re talking about different things. I am talking =
about scripts from places like ad servers that are usually included via =
an iframe to enforce the SOP and sandbox them from other scripts. If =
they get access to an access token - e.g. via document.referrer or a =
redirect or some other leak, then they still act within the same TLS =
context as the legitimate client.
> Thanks for the clarification! I see that you highlight an important =
point there.
>=20
> The protection that would be required essentially boils down to =
something similar to a CSRF protection for the resource server.
>=20
> Luckily, CORS covers this: You can't set the Authorization header =
cross-origin unless the appropriate CORS headers are set. So while the =
third party origin would be able to send a request through the browser =
using the TLS context, it would not be able to attach the access token. =
(Unless, of course, that third party origin is whitelisted, or if the =
bearer token is sent in a different way, e.g., as a URL parameter.)

Right. But two points here:

Firstly, this assumes the access token is actually passed in an =
Authorization header and not just sent in a URL parameter or a CORS-safe =
form POST body (e.g. application/x-www-form-urlencoded). This should =
probably be its own security best practice recommendation, but I =
haven=E2=80=99t seen it anywhere. I think most REST APIs already do this =
following RFC 6750, but we should spell out that it has security =
benefits.

Secondly, this means that we are relying on something other than =
(TLS-based) sender-constrained access tokens to prevent this, so we =
should clarify that in the document.

>=20
> As a side note, interestingly, this would leave an authorization code =
unprotected, if the sender authentication would be mTLS or token =
binding. PKCE on the other hand is fine.

Right - that=E2=80=99s why I am glad to see the security topics draft =
recommending PKCE in all cases.

Why is PKCE so effective? In my opinion, you can view PKCE as a one-time =
PoP scheme for the auth code - you prove possession of the secret to the =
AS by simply giving it the secret along with the auth code. You could do =
something similar with the implicit flow, but I won=E2=80=99t share that =
scheme here as I am happy for the implicit flow to die ;-)

=E2=80=94 Neil=


From nobody Wed Nov 21 02:06:55 2018
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 D47381298C5 for ; Wed, 21 Nov 2018 02:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 VkW6XSGtAqvO for ; Wed, 21 Nov 2018 02:06:53 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 209EE128CFD for ; Wed, 21 Nov 2018 02:06:53 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id y56so4369164edd.11 for ; Wed, 21 Nov 2018 02:06:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xnAF523jTNVQs01VtbVRu6eHJmYrNM5Q85T/wN+cw0E=; b=B9O/lmyZeqkdGzUO9t1vSd5tvGFCJBAd6H0GdK24/H9z0iFoeUajZH1kVe1Hq5LahQ 7hXgjJXO59nHQHZ0WRWHK+6SCX1wmkfBMXLVEv8ViTALndVkyVNZ5QSpSqcncBXczIby 9Ri40+UqXAOljSqrni1PEw5hfYkkry13j8pYdSZI11sEKwESmoynYClj+e1pXkkNWAVt t5y7F7sRQUkc93srmILKpSuiBGL7nd8xzVpjgqyNor6AL34nQD+ufdsK/kaJlxR/cJx2 pPGtWvTjDhKIhIPmBTrzHBQnhGtY2Ivo2cnnAm2K27nNjuuCcLE7RN8W5zzruVQ6Hr1L XHmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xnAF523jTNVQs01VtbVRu6eHJmYrNM5Q85T/wN+cw0E=; b=A0foFgGnyGiSUSQOR+Y2kVRx6yeE54+o9mgrnc0gNpV0n8M24jiehqwxm17CkADMZM HYUZFzE6RRXA6AToC6MawrnJOUqOBmA07CIfb5Md1Enod91+MvN1uClUlxyRUj/fhJ2g u68l7EQhdyPU67+AQQexDBhJ0ZtFljYQAHu56v/R/CNG2Dqx5QG03iEAztedKYt/wCUe 1tuM7gkMyZdypXuW161qtkgDbIP0usw6bAcrnuZVdel9U3v1LNRp5QwBndtlq/c//HNq ZQm85NlEvbr2zHCfWgs1ssv1Kl9BI25E+SFyzwdk0ScjkS3o3i6R6pB6HpyWNgvrQnqE f8hg==
X-Gm-Message-State: AGRZ1gKBv6UpHegZ8JrVIwF+mH130/f694SbOmlQkB7c8NYNDEqt11Tn eXPe8EHiLvsC3JDZfDom94dMXhSJYCw=
X-Google-Smtp-Source: AJdET5eLGSlnEtNcjzp4hNQhn5a33EMQUdGpCArLRESyzTXPR397gYsRDLuQYvqFdr7qYQDMmppt2g==
X-Received: by 2002:a17:906:4003:: with SMTP id v3-v6mr4624602ejj.240.1542794811084;  Wed, 21 Nov 2018 02:06:51 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id k32sm5393898edb.42.2018.11.21.02.06.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 02:06:50 -0800 (PST)
To: Neil Madden 
Cc: oauth@ietf.org
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>  <3C8699BF-EE70-4299-91F2-87E8818E7464@forgerock.com> <83034de5-cde8-8cd9-ff11-7ce22b61fee6@yes.com> <70557E9F-8A8B-4BEB-80CC-07EFD74FFBF0@forgerock.com>
From: Daniel Fett 
Message-ID: <13ca2226-ce91-40f7-c040-dde3f7b3f611@yes.com>
Date: Wed, 21 Nov 2018 11:06:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <70557E9F-8A8B-4BEB-80CC-07EFD74FFBF0@forgerock.com>
Content-Type: multipart/alternative; boundary="------------7672D01F2067ABA885AF7A10"
Content-Language: de-DE
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 10:06:55 -0000

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

Am 21.11.18 um 11:01 schrieb Neil Madden:
>> On 21 Nov 2018, at 09:25, Daniel Fett  wrote:
>>
>> Am 21.11.18 um 10:09 schrieb Neil Madden:
>>>> If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.
>>>>
>>>> The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.
>>>>
>>> I think we’re talking about different things. I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client.
>> Thanks for the clarification! I see that you highlight an important point there.
>>
>> The protection that would be required essentially boils down to something similar to a CSRF protection for the resource server.
>>
>> Luckily, CORS covers this: You can't set the Authorization header cross-origin unless the appropriate CORS headers are set. So while the third party origin would be able to send a request through the browser using the TLS context, it would not be able to attach the access token. (Unless, of course, that third party origin is whitelisted, or if the bearer token is sent in a different way, e.g., as a URL parameter.)
> Right. But two points here:
>
> Firstly, this assumes the access token is actually passed in an Authorization header and not just sent in a URL parameter or a CORS-safe form POST body (e.g. application/x-www-form-urlencoded). This should probably be its own security best practice recommendation, but I haven’t seen it anywhere. I think most REST APIs already do this following RFC 6750, but we should spell out that it has security benefits.

Exactly what I thought. I will prepare a proposal for the security BCP.

-Daniel


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


  
    
  
  
    
    Am 21.11.18 um 11:01 schrieb Neil
      Madden:
    
    
    
    
    
      
    
        
    On 21 Nov 2018, at 09:25, Daniel Fett <danielf+oauth@yes.com> wrote:

Am 21.11.18 um 10:09 schrieb Neil Madden:

    
        
    
          
    
            
    If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.

The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.


    
          
    
          
    I think we’re talking about different things. I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client.

    
        
    
        
    Thanks for the clarification! I see that you highlight an important point there.

The protection that would be required essentially boils down to something similar to a CSRF protection for the resource server.

Luckily, CORS covers this: You can't set the Authorization header cross-origin unless the appropriate CORS headers are set. So while the third party origin would be able to send a request through the browser using the TLS context, it would not be able to attach the access token. (Unless, of course, that third party origin is whitelisted, or if the bearer token is sent in a different way, e.g., as a URL parameter.)

    
      
    
      
    Right. But two points here:

Firstly, this assumes the access token is actually passed in an Authorization header and not just sent in a URL parameter or a CORS-safe form POST body (e.g. application/x-www-form-urlencoded). This should probably be its own security best practice recommendation, but I haven’t seen it anywhere. I think most REST APIs already do this following RFC 6750, but we should spell out that it has security benefits.
    
    
    
    
    Exactly what I thought. I will prepare a proposal for the
      security BCP. 
    
    
    
    
    -Daniel
    
    
    
  


--------------7672D01F2067ABA885AF7A10--


From nobody Wed Nov 21 05:24:15 2018
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 6819B12F1A6 for ; Wed, 21 Nov 2018 05:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9UKrWbZxnvQC for ; Wed, 21 Nov 2018 05:24:10 -0800 (PST)
Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (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 D4BC01292AD for ; Wed, 21 Nov 2018 05:24:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542806648; bh=YLM2E64zcEDK3PiAKd2bvQsajEYPZXIIfJ7UDoWfjfo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=KY3ouQB5Rgo7reBaavptbdH1YEDABGgETbWwr/FRN17isiiMLOFKQe81fOJCo6cv2B9LbWCidZHARSb7bwbZfJP5rFxNnfgMAjsGqoUx9x1JbPiygsRkjg756PlmYPgZ8ctANFwYTWNFk0FO/PneB/NairSOBqG1aRwbzqyrESfde6YufLXmXAJpKwnOy0RQj30Uq3oVzqCROWXvp5bg7HFzoPIEbAbKSzx7Kn+1UpnuXbVd+ERYKA/NF5K/0VF67Iqh2zilerS2Z4p7/sVEtp8TmLxGpUDqjcTtMGWKdVTmKVwtfY2pQMZx1sXpQJdZfwSQ/adQyU0S8hbwLgCEog==
X-YMail-OSG: RouWv98VM1kgSqHNoSH73FS_srs8E_5jjlKI8dX2M2H1.d3G0i8TxHQJOt_r2nQ XKH0rtkjlUUWOPKEMqk_GaU3lXbOFrirCMNXD6vD.4T1PTKHHFl3TYrUeiIJK_FEDVxiaqPRpJ.A 0_50rmdyKpeUNuADYjYn.E_oUaVyQASnY7jZsmlojWSFAfA1u53JxEdPWPQo1nC2OTk5_ZFsBrjK ik58vnSz_kt0Hid04HxObK4HmRMMjSomKwVa0FS0Wthger27vOIsP27byw_01yZpp.FXEjGysLN0 klpwTCCrHS1nn_xBIgArZEtqD7CfaxjBH2noxvs.e3.GGsg4GDZqpBWZHlSSFnAhUBEoqynBDcOH cIZaVgr4jE05LJBSE_S1I7oG_BGN_p9U4IfJFr5vZmc7Tm3U8wrrINtnRMKvmlBaoqBFO6sezJwp n8A1Lvn5hLts.qmgwAyPFVUUzi2boFHjvoeUyI3qtQyTc6rnRHYeT9PQARMoOkFb3lPsjfHw4VWP SjLz009cxxypTHweGTfY_MgCyzS9eB9NoWpV7Xjuo7ZOUZ_B1sB8eMAmfF94_L5_WbEznuY4W7M0 NBu.xIYQ0xdCA5VARMqfC.lXf.1NyaaB3_232wu6be9Cr_wXjWls07W5O1ovgx3s21IS4.R5Q9gw raAZVEILUefC2opJDG5.JK19EeaPKs9McGbxksO.RPHPofHh2IVUh.cyALfMgHXXHh4GxGOmOtfr cS6Z9uq5SVXXSME.jSK.ivRRov0zJ0cP9G.bLU6BVCOi1Dpb2GSDZQH47.gtnQedRjxVWlPotejP Ylxiddm9vGitMjjXFL6a104DnKrTfIiH0BARNPzWeD5glywL68rZQ_Gv07N3ofCi.rTf2KzAQgAx LrurP3fCB8eXf_c8aku06Ra3nVnTcT8cev0GPEzV.R1NTVQNdJt7nKDhUQD7Ql5QyG1KvUZvndCK MOIy6VQTbV_SDgT0O5cG70F6HKQFpZMLL_X1OXiF6QtiK._dgNDq2oyiT6o18TTCPI7FQINx.Dd0 GDBN5RTSV_tJ9yoK7eJPMvIbnp2LnaunQS.2RlXb23jp9ZjzGbLDSRWz7DvHzuILgjJt.pg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 21 Nov 2018 13:24:08 +0000
Received: from 208.72.78.175 (EHLO [192.168.50.169]) ([208.72.78.175]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 59f8432fd83de41aea80b99aa3179896;  Wed, 21 Nov 2018 13:24:06 +0000 (UTC)
To: Torsten Lodderstedt , John Bradley 
Cc: Mike Jones , "oauth@ietf.org" 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>
Date: Wed, 21 Nov 2018 08:24:01 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------054D1221D1184DDF2F91EBF2"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 13:24:12 -0000

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

An SPA has a backend because it has to be loaded from somewhere :)

On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513
>
> Outcome is POST requires a backend to receive the request so it’s not a viable solution for SPAs.
>
>> Am 20.11.2018 um 23:29 schrieb John Bradley :
>>
>> Post response works OK for server based clients.  I don't think POST works for single page applications.
>>
>> Basically that would be something more like postmessage between two JS apps.
>>
>> Postmessage also has security issues passing a access token and leaking.
>>
>> Perhaps someone more familiar with SPA can comment on POST.
>>
>> John B.
>>
>>
>>
>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher > Hi Mike,
>>
>> The Form Post Response Mode keeps the access_token out of the URL, but it doesn't prevent the token from traversing through the browser. So a man-in-the-browser attack may be able to intercept the values. It should help with leakage in logs.
>>
>> Thanks,
>> George
>>
>> On 11/20/18 4:00 PM, Mike Jones wrote:
>>> Next question – doesn’t using the Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate the threats you’re describing below John?  If so, I believe the Security Topics draft should say this.
>>>
>>>   
>>>
>>> I believe we owe it to readers to present the complete picture, which is why I believe that describing profiles using ID Tokens and the Form Post Response Mode are in scope.
>>>
>>>   
>>>
>>>                                                         -- Mike
>>>
>>>   
>>>
>>> From: OAuth  On Behalf Of John Bradley
>>> Sent: Tuesday, November 20, 2018 7:47 AM
>>> To: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>>>
>>>   
>>>
>>> Yes the at_hash protects the client from accepting an injected AT.
>>>
>>> Unfortunately it doesn't do anything to protect against leakage in logs or redirects.
>>>
>>> So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice.
>>>
>>> John B.
>>>
>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>>
>>> Hi Mike,
>>>   
>>> I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.
>>>   
>>> I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues:
>>>   
>>> 1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
>>> 2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach.
>>>   
>>> kind regards,
>>> Torsten.
>>>   
>>> Am 19.11.2018 um 23:13 schrieb Mike Jones :
>>>   
>>> This description of the situation is an oversimplification..  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>>>   
>>> Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
>>>   
>>>                                                                  Thank you,
>>>                                                                  -- Mike
>>>   
>>> From: OAuth  On Behalf Of Hannes Tschofenig
>>> Sent: Monday, November 19, 2018 2:34 AM
>>> To: oauth 
>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>>>   
>>> Hi all,
>>>   
>>> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>>>   
>>> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
>>>   
>>> Please provide a response by December 3rd.
>>>   
>>> Ciao
>>> Hannes & Rifaat
>>>   
>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
>>> _______________________________________________
>>> 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


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


  
    
  
  
    An SPA has a backend
      because it has to be loaded from somewhere :)
    
    
    
    
    On 11/21/18 3:47 AM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513

Outcome is POST requires a backend to receive the request so it’s not a viable solution for SPAs.


    
      
    
        
    Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.com>:

Post response works OK for server based clients.  I don't think POST works for single page applications.  

Basically that would be something more like postmessage between two JS apps.  

Postmessage also has security issues passing a access token and leaking.  

Perhaps someone more familiar with SPA can comment on POST.  

John B. 



On Tue, Nov 20, 2018, 6:40 PM George Fletcher <gffletch@aol.com wrote:
Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but it doesn't prevent the token from traversing through the browser. So a man-in-the-browser attack may be able to intercept the values. It should help with leakage in logs.

Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:

    
        
    
          
    Next question – doesn’t using the Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate the threats you’re describing below John?  If so, I believe the Security Topics draft should say this.

 

I believe we owe it to readers to present the complete picture, which is why I believe that describing profiles using ID Tokens and the Form Post Response Mode are in scope.

 

                                                       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Tuesday, November 20, 2018 7:47 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

 

Yes the at_hash protects the client from accepting an injected AT. 

Unfortunately it doesn't do anything to protect against leakage in logs or redirects.

So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice.

John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike, 
 
I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.
 
I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues: 
 
1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach. 
 
kind regards,
Torsten. 
 
Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:
 
This description of the situation is an oversimplification..  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
 
Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
 
                                                                Thank you,
                                                                -- Mike
 
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
 
Hi all,
 
The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
 
A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
 
Please provide a response by December 3rd.
 
Ciao
Hannes & Rifaat
 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
_______________________________________________
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

    
      
    
      
    
    
    
    
    
  


--------------054D1221D1184DDF2F91EBF2--


From nobody Wed Nov 21 05:43:52 2018
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 AC40D127133; Wed, 21 Nov 2018 05:43:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 
To: "The IESG" 
Cc: draft-ietf-oauth-token-exchange@ietf.org, Hannes Tschofenig , Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com>
Date: Wed, 21 Nov 2018 05:43:43 -0800
Archived-At: 
Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Nov 2018 13:43:44 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It looks like allocations in the OAuth URIs registry are merely
"Specification Required", so we should not have the expectation of WG
exclusivity and thus are squatting on unallocated values here.
Process-wise, that's not great and the IESG shouldn't approve a document
that is squatting on codepoints.

why do we allow both client authentication (i.e., using an
actor token) and a distinct actor_token request parameter?  Is it
supposed to be the case that the actor_token parameter is only supplied
for delegation flows?  If so, that needs to be made explicit in the
document.

Are the privacy considerations (e.g., risk of a tailed per-request
error_uri) relating to the use of error_uri discussed in some other
document that we can refer to from this document's security
considerations?  (I say a bit more about this in my COMMENT.)

Section 2.1 has:
   audience
      OPTIONAL.  The logical name of the target service where the client
      intends to use the requested security token.  This serves a
      purpose similar to the "resource" parameter, but with the client
      providing a logical name rather than a location.  Interpretation
      of the name requires that the value be something that both the
      client and the authorization server understand.  An OAuth client
      identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an
      OpenID Connect Issuer Identifier [OpenID.Core], or a URI are
      examples of things that might be used as "audience" parameter
      values.  [...]

How does the STS know what type of identifier it is supposed
to interpret the provided audience value as?


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

The document could perhaps benefit from greater clarity as to whether
"security token"s refer to inputs, outputs, or both, of the token
endpoint (for the interactions defined in this specification).

Section 1

                                                            The OAuth
   2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens
   [RFC6750] have emerged as popular standards for authorizing third-
   party applications access to HTTP and RESTful resources.  [...]

nit: possessive "applications'"

Section 1.1

This section really jumps in quickly with no lead-in to why we would
care or transition from the introduction.  I suggest:

  One common use case for an STS (as alluded to in the previous section)
  is to allow a resource server A to make calls to a backend service C on
  behalf of the requesting user B.  Depending on the local site policy and
  authorization infrastructure, it may be desireable for A to use its own
  credentials to access C along with an annotation of some form that A is
  acting on behalf of B ("delegation"), or for A to be granted a limited access
  credential to C but that continues to identify B as the authorized
  entity ("imperesonation").  Delegation and impersonation can be useful
  concepts in other scenarios involving multiple participants as well.

Section 2.1

                                                  For example, [RFC7523]
   defines client authentication using JSON Web Tokens (JWTs) [JWT].

Please clarify that these are still bearer tokens.

   The supported methods of client authentication and whether or not to
   allow unauthenticated or unidentified clients are deployment
   decisions that are at the discretion of the authorization server.

It seems appropriate to note that omitting client authentication allows
for a compromised token to be leveraged via an STS into other tokens by
anyone possessing the compromised token, and thus that client
authentication allows for additional authorization checks as to which
entities are permitted to impersonate or receive delegations from other
entities.

   The client makes a token exchange request to the token endpoint with
   an extension grant type by including the following parameters using
   the "application/x-www-form-urlencoded" format with a character
   encoding of UTF-8 in the HTTP request entity-body:

Is there more to say than "just use UTF-8"; any normalization or
canonicalization issues to consider?

   subject_token
      REQUIRED.  A security token that represents the identity of the
      party on behalf of whom the request is being made.  Typically, the
      subject of this token will be the subject of the security token
      issued in response to this request.

nit: I think there's a subtle grammar mismatch here, where we start off
by talking about a/the request and end up with "this request".

   In processing the request, the authorization sever MUST validate the
   subject token as appropriate for the indicated token type and, if the
   actor token is present, also validate it according to its token type.

I misread this the first time around; I'd suggest something like
"perform the appropriate validation procedures for the indicated token
type" (as opposed to just verifying that the presented token is a
syntactically valid instance of the claimed type).

   In the absence of one-time-use or other semantics specific to the
   token type, the act of performing a token exchange has no impact on
   the validity of the subject token or actor token.  Furthermore, the
   validity of the subject token or actor token have no impact on the
   validity of the issued token after the exchange has occurred.

Do we really want this strong of a statement?  I suspect that in many
environments propagating, e.g., expiration time to the exchanged
credential may be desired.

Section 2.2.1

   token_type
[...]
      contents of the token itself.  Note that the meaning of this
      parameter is different from the meaning of the "issued_token_type"
      parameter, which declares the representation of the issued
      security token; the term "token type" is typically used with this
      meaning, as it is in all "*_token_type" parameters in this
      specification. [...]

Please disambiguate what "typically used with this meaning" means.
Perhaps it would be even more clear to change this field's name to
"token_access_token_type" to match the name of the registry?

Section 2.3

   The following example demonstrates a hypothetical token exchange in
   which an OAuth resource server assumes the role of the client during
   token exchange in order to trade an access token that it received in
   a protected resource request for a token that it will use to call to
   a backend service (extra line breaks and indentation in the examples
   are for display purposes only).

We could maybe add some commas or parentheses to help the reader group
the various clauses properly.  E.g., it is "(trade an access token (that
it received in a protected resource request)) for a token...", not
"trace an access token that it received (in a protected resource request
for a token)", where parentheses indicate logical grouping.

    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
    &resource=https%3A%2F%2Fbackend.example.com%2Fapi%20
    &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
    &subject_token_type=
     urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

                     Figure 2: Token Exchange Request
Is there really supposed to be a %20 in the resource query parameter's
value?

The token octets in Figures 3 and 4 do not match up, despite the prose
indicating that they are the same token.

Section 3

Would it be appropriate to note (here or elsewhere) that for non-JWT
token formats that are a binary format, the URI used for conveying them
needs to be associated with the semantics of base64 (or otherwise)
encoding them for usage with OAuth?

                                                Token Exchange can work
   with both tokens issued by other parties and tokens from the given
   authorization server.  [...]

Does "work with" mean "accept as input" or "produce as output" or both?
For input, as both subject_token and actor_token?

   The following token type identifiers are defined by this
   specification.  Other URIs MAY be used to indicate other token types.
I'd also link to the registry here.

Why is the text about "urn:ietf:params:oauth:token-type:jwt" formatted
differently than the other URIs listed?

Section 4.1

Do we want to consider a more self-describing subject identifier scheme,
akin to
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers ?

The example in Figure 5 appears to be using the "implicit issuer"
behavior wherein the "iss" of the actor's "sub" is assumed to be the
same value as in the containing structure.  I'm not a fan of this type
of behavior in general, but if it's going to be used, you need to
document the possibility in some fashion.

I might also consider some language about how "the nested "act" claims
serve as a history trail that connects the initial request and subject
through the various delegation steps undertaken before reaching the
current actor.  In this sense, the current actor is considered to
include the entire authorization/delegation history, leading naturally
to the nested structure described here".  (But see also the other ballot
comment about this potentially leaking information to unauthorized
parties; it seems a more careful adjustment of the text is in order
here.)

Section 4.2

Is this really the first time we're defining "scope" as a JWT claim?  I
would have thought that would be defined long ago...

Section 4.4

Just to double-check: this is "things that can act as me" (where "me" is
the subject of the token containing this field), right?  The
parenthetical "May Act For" doesn't really help me decide whether this
claim represents the source or target of a permitted delegation, so
maybe "Allowed Impersonators" or similar would be more clear.  Even "act
as" or "act on behalf of" instead of "act for" would help me, I think.
[This would have trickle-down effects to later parts of the document as
well, e.g., the IANA Considerations.]
(Not that I claim to be a representative population, of course!)

It would probably also help greatly to note that when a subject_token is
presented to the token endpoint in a token exchange request, the
"may_act" claim in the subject token can be used by the authorization
service to determine whether the client (or party identified in the
actor_token) is authorized to engage in the requested delegation [or
impersonation].

Section 6

Let me say a bit more here about my perception of the potential privacy
considerations involved in the use of an error_uri (so we can figure out
if they are already discussed in a relevant document that we can cite;
JWT itself doesn't seem to cover this topic).  By sending an error_uri
instead of an error string, the server is in effect causing the client
to make an outbound request to a URL of the server's choosing.  If there
is a proxy between the client and server, this could result in the
server (and/or a party controlled by the server) learning additional
information about the client's identity/location.  A malicious server
could also attempt to construct a URI that, when retrieved by the
client, performs some unwanted side effect.  Defenses against this
latter scenario are pretty well known in the web comunity, but we may
want to be sure that the need for them is mentioned in a discoverable
place.

Appendix A.1.1

   In the following token exchange request, a client is requesting a
   token with impersonation semantics. [...]

What part of the request indicates that impersonation semantics are
requested?

Is the use of the "jwt" subject_token_type appropriate, given the
previous discussion about id_token/access_token being generally
preferred (as conveying more meaning)?



From nobody Wed Nov 21 05:57:33 2018
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 9C112130F2D for ; Wed, 21 Nov 2018 05:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8SXR3zRdMhHc for ; Wed, 21 Nov 2018 05:57:21 -0800 (PST)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0: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 8FCE3130E31 for ; Wed, 21 Nov 2018 05:57:21 -0800 (PST)
Received: by mail-oi1-x234.google.com with SMTP id u18so4551829oie.10 for ; Wed, 21 Nov 2018 05:57:21 -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=bqELr89ng8xvqOpgKj8NfRdU653IxPH0YihTWqVxTh0=; b=mwz0+b1ahDjaAq28NcCQ6GB0toXJD0cX4gHiWvA/yemPWAybysp/ISEsuFxzwOjEuj cdCrOi0VAweIgx57SHvybGm1iMUM8SF3I8rg0ofqifNS+ajCPO5ls52v5cKENYKYLSsq /pkyDPuzHHeqt6G2Ohpwz446/ONz5mLUoSlBxe0tpHOMddWJhc1g+AdENfMoD9jLz4ar QT2f1sxug5KxNpzHegdURwgbhADumuz32epUo1mmQflaX4uRy9AgGeUegWppNapOiRfT RaBnF3eYIShT3RIRdTZiQ0UV0c/PaRSYyHwp8Nl+DYbv7oYl8Awi+w2u2YSjISSEFgP+ pbdQ==
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=bqELr89ng8xvqOpgKj8NfRdU653IxPH0YihTWqVxTh0=; b=B/wrVI6xgqkQ1dYfg/p72vgTU/fhgIJ6YPUc0ErvoB4gCmrOjIDwrf6CEUMlgYmJAg W8TkC1Ki+yNA4pVcdfKY6jyVBWOQ255E724AmFEKm34FXzt1/nDAC5SdS/rJLTs6WO2y iLphLCOUzObx/jA3HRlgT4WSnxElMqcz+MerlsUAPFMO1R1/zTDEf9SrNU36maq6uWUH 6Mr06BCAeL2vkQd0vtuW8/ZJJWILRayF4HlUHxb0fPoPkGzuBK0Pxn6fQSgTHVtf7KcW agsv7/9rxJuiTVkWj+UOli9742mbJrjfqMxMZZn7PHL/Wcs426HYBxiybBoqEHPTb8iT DiGw==
X-Gm-Message-State: AA+aEWYYUAfKQDt2tBAegYpmJqNhfHh1vTYrx4EXSFJ+EU6MSQmEtkPa K7j0zXnZUzFFuiqJ9cUa2+s7czaMQ0SHxDWYsWi2bw==
X-Google-Smtp-Source: AFSGD/VaVxMdZo0bHaeoxBgKCaSI7dyryzmw5lp79/joDnFtxpbUuubmgd4OSrl/rRbjGAvy6RYazmD6XaePBXUvmHE=
X-Received: by 2002:aca:e8c4:: with SMTP id f187mr3493791oih.267.1542808640093;  Wed, 21 Nov 2018 05:57:20 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Adam Cashion 
Date: Wed, 21 Nov 2018 07:30:49 -0600
Message-ID: 
To: oauth , Adam Cashion 
Content-Type: multipart/alternative; boundary="000000000000f301c9057b2d2040"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 121, Issue 55
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, 21 Nov 2018 13:57:32 -0000

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

email

On Wed, Nov 21, 2018, 7:24 AM  Send OAuth mailing list submissions to
>         oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         oauth-request@ietf.org
>
> You can reach the person managing the list at
>         oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Daniel Fett)
>    2. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Neil Madden)
>    3. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Daniel Fett)
>    4. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (George Fletcher)
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Fett 
> To: Neil Madden 
> Cc: oauth@ietf.org
> Bcc:
> Date: Wed, 21 Nov 2018 10:25:49 +0100
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> Am 21.11.18 um 10:09 schrieb Neil Madden:
>
> If a page from origin A includes a third-party script from origin B, that=
 external script runs in origin A and has access to all cookies and the Jav=
aScript context of the page.
>
> The SPA from origin A would be compromised. That is why we need things su=
ch as Subresource Integrity.
>
>
> I think we=E2=80=99re talking about different things. I am talking about =
scripts from places like ad servers that are usually included via an iframe=
 to enforce the SOP and sandbox them from other scripts. If they get access=
 to an access token - e.g. via document.referrer or a redirect or some othe=
r leak, then they still act within the same TLS context as the legitimate c=
lient.
>
> Thanks for the clarification! I see that you highlight an important point
> there.
>
> The protection that would be required essentially boils down to something
> similar to a CSRF protection for the resource server.
>
> Luckily, CORS covers this: You can't set the Authorization header
> cross-origin unless the appropriate CORS headers are set. So while the
> third party origin would be able to send a request through the browser
> using the TLS context, it would not be able to attach the access token.
> (Unless, of course, that third party origin is whitelisted, or if the
> bearer token is sent in a different way, e.g., as a URL parameter.)
>
> As a side note, interestingly, this would leave an authorization code
> unprotected, if the sender authentication would be mTLS or token binding.
> PKCE on the other hand is fine.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Neil Madden 
> To: Daniel Fett 
> Cc: oauth@ietf.org
> Bcc:
> Date: Wed, 21 Nov 2018 10:01:49 +0000
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> > On 21 Nov 2018, at 09:25, Daniel Fett  wrote:
> >
> > Am 21.11.18 um 10:09 schrieb Neil Madden:
> >>> If a page from origin A includes a third-party script from origin B,
> that external script runs in origin A and has access to all cookies and t=
he
> JavaScript context of the page.
> >>>
> >>> The SPA from origin A would be compromised. That is why we need thing=
s
> such as Subresource Integrity.
> >>>
> >> I think we=E2=80=99re talking about different things. I am talking abo=
ut
> scripts from places like ad servers that are usually included via an ifra=
me
> to enforce the SOP and sandbox them from other scripts. If they get acces=
s
> to an access token - e.g. via document.referrer or a redirect or some oth=
er
> leak, then they still act within the same TLS context as the legitimate
> client.
> > Thanks for the clarification! I see that you highlight an important
> point there.
> >
> > The protection that would be required essentially boils down to
> something similar to a CSRF protection for the resource server.
> >
> > Luckily, CORS covers this: You can't set the Authorization header
> cross-origin unless the appropriate CORS headers are set. So while the
> third party origin would be able to send a request through the browser
> using the TLS context, it would not be able to attach the access token.
> (Unless, of course, that third party origin is whitelisted, or if the
> bearer token is sent in a different way, e.g., as a URL parameter.)
>
> Right. But two points here:
>
> Firstly, this assumes the access token is actually passed in an
> Authorization header and not just sent in a URL parameter or a CORS-safe
> form POST body (e.g. application/x-www-form-urlencoded). This should
> probably be its own security best practice recommendation, but I haven=E2=
=80=99t
> seen it anywhere. I think most REST APIs already do this following RFC
> 6750, but we should spell out that it has security benefits.
>
> Secondly, this means that we are relying on something other than
> (TLS-based) sender-constrained access tokens to prevent this, so we shoul=
d
> clarify that in the document.
>
> >
> > As a side note, interestingly, this would leave an authorization code
> unprotected, if the sender authentication would be mTLS or token binding.
> PKCE on the other hand is fine.
>
> Right - that=E2=80=99s why I am glad to see the security topics draft rec=
ommending
> PKCE in all cases.
>
> Why is PKCE so effective? In my opinion, you can view PKCE as a one-time
> PoP scheme for the auth code - you prove possession of the secret to the =
AS
> by simply giving it the secret along with the auth code. You could do
> something similar with the implicit flow, but I won=E2=80=99t share that =
scheme
> here as I am happy for the implicit flow to die ;-)
>
> =E2=80=94 Neil
>
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Fett 
> To: Neil Madden 
> Cc: oauth@ietf.org
> Bcc:
> Date: Wed, 21 Nov 2018 11:06:49 +0100
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> Am 21.11.18 um 11:01 schrieb Neil Madden:
>
> On 21 Nov 2018, at 09:25, Daniel Fett   wrote:
>
> Am 21.11.18 um 10:09 schrieb Neil Madden:
>
> If a page from origin A includes a third-party script from origin B, that=
 external script runs in origin A and has access to all cookies and the Jav=
aScript context of the page.
>
> The SPA from origin A would be compromised. That is why we need things su=
ch as Subresource Integrity.
>
>
> I think we=E2=80=99re talking about different things. I am talking about =
scripts from places like ad servers that are usually included via an iframe=
 to enforce the SOP and sandbox them from other scripts. If they get access=
 to an access token - e.g. via document.referrer or a redirect or some othe=
r leak, then they still act within the same TLS context as the legitimate c=
lient.
>
> Thanks for the clarification! I see that you highlight an important point=
 there.
>
> The protection that would be required essentially boils down to something=
 similar to a CSRF protection for the resource server.
>
> Luckily, CORS covers this: You can't set the Authorization header cross-o=
rigin unless the appropriate CORS headers are set. So while the third party=
 origin would be able to send a request through the browser using the TLS c=
ontext, it would not be able to attach the access token. (Unless, of course=
, that third party origin is whitelisted, or if the bearer token is sent in=
 a different way, e.g., as a URL parameter.)
>
>
> Right. But two points here:
>
> Firstly, this assumes the access token is actually passed in an Authoriza=
tion header and not just sent in a URL parameter or a CORS-safe form POST b=
ody (e.g. application/x-www-form-urlencoded). This should probably be its o=
wn security best practice recommendation, but I haven=E2=80=99t seen it any=
where. I think most REST APIs already do this following RFC 6750, but we sh=
ould spell out that it has security benefits.
>
> Exactly what I thought. I will prepare a proposal for the security BCP.
>
> -Daniel
>
>
>
> ---------- Forwarded message ----------
> From: George Fletcher 
> To: Torsten Lodderstedt , John Bradley <
> ve7jtb@ve7jtb.com>
> Cc: Mike Jones , "
> oauth@ietf.org" 
> Bcc:
> Date: Wed, 21 Nov 2018 08:24:01 -0500
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> An SPA has a backend because it has to be loaded from somewhere :)
>
> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>
> We had a discussion about this topic on Twitter https://twitter.com/Apl3b=
/status/1064854507606208513
>
> Outcome is POST requires a backend to receive the request so it=E2=80=99s=
 not a viable solution for SPAs.
>
>
> Am 20.11.2018 um 23:29 schrieb John Bradley  :
>
> Post response works OK for server based clients.  I don't think POST work=
s for single page applications.
>
> Basically that would be something more like postmessage between two JS ap=
ps.
>
> Postmessage also has security issues passing a access token and leaking.
>
> Perhaps someone more familiar with SPA can comment on POST.
>
> John B.
>
>
>
> On Tue, Nov 20, 2018, 6:40 PM George Fletcher  Hi Mike,
>
> The Form Post Response Mode keeps the access_token out of the URL, but it=
 doesn't prevent the token from traversing through the browser. So a man-in=
-the-browser attack may be able to intercept the values. It should help wit=
h leakage in logs.
>
> Thanks,
> George
>
> On 11/20/18 4:00 PM, Mike Jones wrote:
>
> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Response Mode=
 https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigat=
e the threats you=E2=80=99re describing below John?  If so, I believe the S=
ecurity Topics draft should say this.
>
>
>
> I believe we owe it to readers to present the complete picture, which is =
why I believe that describing profiles using ID Tokens and the Form Post Re=
sponse Mode are in scope.
>
>
>
>                                                        -- Mike
>
>
>
> From: OAuth   On Behalf O=
f John Bradley
> Sent: Tuesday, November 20, 2018 7:47 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization =
code instead of implicit
>
>
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs o=
r redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say send=
ing it in a redirect is a good security practice.
>
> John B.
>
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
> Hi Mike,
>
> I agree that OIDC hybrid flows offer additional security over the OAuth i=
mplicit grant and are used in the wild. On my slides and in the initial ver=
sion of the new section, we had included the hybrid OIDC flows because of t=
heir known token injection countermeasures.
>
> I nevertheless feel very uncomfortable to recommend those flows and any f=
low issuing access tokens in the front channel. In the course of the detail=
ed review of the new text we realized two issues:
>
> 1) Since the access token is exposed in the URL, such flows possess a sig=
nificantly higher risk to leak the access token (e.g. through browser histo=
ry, open redirection and even referrer headers) than the code grant.
> 2) There is no viable way to sender constrain access tokens issued in the=
 front channel. Given the WG decided to recommend use of sender constraint =
tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#sec=
tion-2..2), it seems contradictory to recommend response types not supporti=
ng such an approach.
>
> kind regards,
> Torsten.
>
> Am 19.11.2018 um 23:13 schrieb Mike Jones  :
>
> This description of the situation is an oversimplification..  OpenID Conn=
ect secures the implicit flow against token injection attacks by including =
the at_hash (access token hash) in the ID Token, enabling the client to val=
idate that the access token was created by the issuer in the ID Token (whic=
h is also the OAuth Issuer, as described in RFC 8414).  (Note that this mit=
igation was described in draft-ietf-oauth-mix-up-mitigation.)
>
> Given the prevalence of this known-good solution for securing the implici=
t flow, I would request that the draft be updated to describe this mitigati=
on.  At the same time, I=E2=80=99m fine with the draft recommending the cod=
e flow over the implicit flow when this mitigation is not used.
>
>                                                                 Thank you=
,
>                                                                 -- Mike
>
> From: OAuth   On Behalf O=
f Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth  
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code=
 instead of implicit
>
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion tha=
t it is not possible to adequately secure the implicit flow against token i=
njection since potential solutions like token binding or JARM are in an ear=
ly stage of adoption. For this reason, and since CORS allows browser-based =
apps to send requests to the token endpoint, Torsten suggested to use the a=
uthorization code instead of the implicit grant in call cases in his presen=
tation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oa=
uth-sessb-draft-ietf-oauth-security-topics-01).
>
> A hum in the room at IETF#103 concluded strong support for his recommenda=
tions. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are conf=
idential and may also be privileged. If you are not the intended recipient,=
 please notify the sender immediately and do not disclose the contents to a=
ny other person, use it for any purpose, or store or copy the information i=
n any medium. Thank you.
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> 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
>

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


    email

    On Wed, Nov 21, 2018, 7:24 AM  <oauth-request@ietf.org wrote:
    Send OAuth mailing list submissions to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org
    

    
To subscribe or unsubscribe via the World Wide Web, visit
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o=
rg/mailman/listinfo/oauth
    
or, via email, send a message with subject or body 'help' to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org
    

    
You can reach the person managing the list at
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org
    

    
When replying, please edit your Subject line so it is more specific
    
than "Re: Contents of OAuth digest..."
    
Today's Topics:
    

    
=C2=A0 =C2=A01. Re: OAuth Security Topics -- Recommend authorization code
=C2=A0 =C2=A0 =C2=A0 instead of implicit (Daniel Fett)
    
=C2=A0 =C2=A02. Re: OAuth Security Topics -- Recommend authorization code
=C2=A0 =C2=A0 =C2=A0 instead of implicit (Neil Madden)
    
=C2=A0 =C2=A03. Re: OAuth Security Topics -- Recommend authorization code
=C2=A0 =C2=A0 =C2=A0 instead of implicit (Daniel Fett)
    
=C2=A0 =C2=A04. Re: OAuth Security Topics -- Recommend authorization code
=C2=A0 =C2=A0 =C2=A0 instead of implicit (George Fletcher)
    



    ---------- Forwarded message ----------
    From:=C2=A0Daniel Fe=
tt <danielf+oauth@yes.com>
    To:=C2=A0Neil Madden <neil.madden@forgerock.com>
    Cc:=C2=A0oauth@ietf.org
    Bcc:=C2=
=A0
    Date:=C2=A0Wed, 21 Nov 2018 10:25:49 +0100
    Subject:=C2=A0Re: [OAU=
TH-WG] OAuth Security Topics -- Recommend authorization code instead of imp=
licit
    
 =20
   =20
 =20
  
    
    
    Am 21.11.18 um 10:0=
9 schrieb Neil
      Madden:
    
    
    
    
      
    
        
    If a page from or=
igin A includes a third-party script from origin B, that external script ru=
ns in origin A and has access to all cookies and the JavaScript context of =
the page.

The SPA from origin A would be compromised. That is why we need things such=
 as Subresource Integrity.

    
      
    
      
    I think we=E2=80=99re talking about different things. I am talking about sc=
ripts from places like ad servers that are usually included via an iframe t=
o enforce the SOP and sandbox them from other scripts. If they get access t=
o an access token - e.g. via document.referrer or a redirect or some other =
leak, then they still act within the same TLS context as the legitimate cli=
ent.
    
    
    
    
    Thanks for the clarification! I see that you highlight an
      important point there.
    
    
    
    
    The protection that would be required essentially boils down to
      something similar to a CSRF protection for the resource server.
    
    
    Luckily, CORS covers this: You can't set the Authorization heade=
r
      cross-origin unless the appropriate CORS headers are set. So while
      the third party origin would be able to send a request through the
      browser using the TLS context, it would not be able to attach the
      access token. (Unless, of course, that third party origin is
      whitelisted, or if the bearer token is sent in a different way,
      e.g., as a URL parameter.)
    
    
    As a side note, interestingly, this would leave an authorization
      code unprotected, if the sender authentication would be mTLS or
      token binding. PKCE on the other hand is fine.
    
    
    
    

    
    
    
  
    




    ---------- Forwarded message ----------
    From:=C2=A0Neil Madd=
en <neil.madden@forgerock.com>
    To:=C2=A0Daniel Fett &=
lt;danielf+oauth@yes.com>
    Cc:=C2=A0oauth@ietf.org
    Bcc:=C2=
=A0
    Date:=C2=A0Wed, 21 Nov 2018 10:01:49 +0000
    Subject:=C2=A0Re: [OAU=
TH-WG] OAuth Security Topics -- Recommend authorization code instead of imp=
licit
    > On 21 Nov 2018, at 09:25, Daniel Fett <danielf+oauth@=
yes.com> wrote:
    
> 
    
> Am 21.11.18 um 10:09 schrieb Neil Madden:
    
>>> If a page from origin A includes a third-party script from ori=
gin B, that external script runs in origin A and has access to all cookies =
and the JavaScript context of the page.
    
>>> 
    
>>> The SPA from origin A would be compromised. That is why we nee=
d things such as Subresource Integrity.
    
>>> 
    
>> I think we=E2=80=99re talking about different things. I am talking=
 about scripts from places like ad servers that are usually included via an=
 iframe to enforce the SOP and sandbox them from other scripts. If they get=
 access to an access token - e.g. via document.referrer or a redirect or so=
me other leak, then they still act within the same TLS context as the legit=
imate client.
    
> Thanks for the clarification! I see that you highlight an important po=
int there.
    
> 
    
> The protection that would be required essentially boils down to someth=
ing similar to a CSRF protection for the resource server.
    
> 
    
> Luckily, CORS covers this: You can't set the Authorization header =
cross-origin unless the appropriate CORS headers are set. So while the thir=
d party origin would be able to send a request through the browser using th=
e TLS context, it would not be able to attach the access token. (Unless, of=
 course, that third party origin is whitelisted, or if the bearer token is =
sent in a different way, e.g., as a URL parameter.)
    

    
Right. But two points here:
    

    
Firstly, this assumes the access token is actually passed in an Authorizati=
on header and not just sent in a URL parameter or a CORS-safe form POST bod=
y (e.g. application/x-www-form-urlencoded). This should probably be its own=
 security best practice recommendation, but I haven=E2=80=99t seen it anywh=
ere. I think most REST APIs already do this following RFC 6750, but we shou=
ld spell out that it has security benefits.
    

    
Secondly, this means that we are relying on something other than (TLS-based=
) sender-constrained access tokens to prevent this, so we should clarify th=
at in the document.
    

    
> 
    
> As a side note, interestingly, this would leave an authorization code =
unprotected, if the sender authentication would be mTLS or token binding. P=
KCE on the other hand is fine.
    

    
Right - that=E2=80=99s why I am glad to see the security topics draft recom=
mending PKCE in all cases.
    

    
Why is PKCE so effective? In my opinion, you can view PKCE as a one-time Po=
P scheme for the auth code - you prove possession of the secret to the AS b=
y simply giving it the secret along with the auth code. You could do someth=
ing similar with the implicit flow, but I won=E2=80=99t share that scheme h=
ere as I am happy for the implicit flow to die ;-)
    

    
=E2=80=94 Neil
    

    



    ---------- Forwarded message ----------
    From:=C2=A0Daniel Fe=
tt <danielf+oauth@yes.com>
    To:=C2=A0Neil Madden <neil.madden@forgerock.com>
    Cc:=C2=A0oauth@ietf.org
    Bcc:=C2=
=A0
    Date:=C2=A0Wed, 21 Nov 2018 11:06:49 +0100
    Subject:=C2=A0Re: [OAU=
TH-WG] OAuth Security Topics -- Recommend authorization code instead of imp=
licit
    
 =20
   =20
 =20
  
    
    
    Am 21.11.18 um 11:0=
1 schrieb Neil
      Madden:
    
    
    
    
    
      
    
        
    On 21 Nov 2018, a=
t 09:25, Daniel Fett <danielf+oauth@yes.com> wrote:

Am 21.11.18 um 10:09 schrieb Neil Madden:

    
        
    
          
    
            
    If a page fro=
m origin A includes a third-party script from origin B, that external scrip=
t runs in origin A and has access to all cookies and the JavaScript context=
 of the page.

The SPA from origin A would be compromised. That is why we need things such=
 as Subresource Integrity.


    
          
    
          
    I think we=E2=
=80=99re talking about different things. I am talking about scripts from pl=
aces like ad servers that are usually included via an iframe to enforce the=
 SOP and sandbox them from other scripts. If they get access to an access t=
oken - e.g. via document.referrer or a redirect or some other leak, then th=
ey still act within the same TLS context as the legitimate client.

    
        
    
        
    Thanks for the cl=
arification! I see that you highlight an important point there.

The protection that would be required essentially boils down to something s=
imilar to a CSRF protection for the resource server.

Luckily, CORS covers this: You can't set the Authorization header cross=
-origin unless the appropriate CORS headers are set. So while the third par=
ty origin would be able to send a request through the browser using the TLS=
 context, it would not be able to attach the access token. (Unless, of cour=
se, that third party origin is whitelisted, or if the bearer token is sent =
in a different way, e.g., as a URL parameter.)

    
      
    
      
    Right. But two points here:

Firstly, this assumes the access token is actually passed in an Authorizati=
on header and not just sent in a URL parameter or a CORS-safe form POST bod=
y (e.g. application/x-www-form-urlencoded). This should probably be its own=
 security best practice recommendation, but I haven=E2=80=99t seen it anywh=
ere. I think most REST APIs already do this following RFC 6750, but we shou=
ld spell out that it has security benefits.
    
    
    
    
    Exactly what I thought. I will prepare a proposal for the
      security BCP. 
    
    
    
    
    -Daniel
    
    
    
  
    




    ---------- Forwarded message ----------
    From:=C2=A0George Fl=
etcher <gffletch@aol.com>
    To:=C2=A0Torsten Lodderstedt <=
torsten@lodderstedt.net>, John Bradley <ve7jtb@ve7jtb.com><=
br>Cc:=C2=A0Mike Jones <Michael.Jones=3D40microsoft.com@dmar=
c.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
    Bc=
c:=C2=A0
    Date:=C2=A0Wed, 21 Nov 2018 08:24:01 -0500
    Subject:=C2=A0Re:=
 [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead o=
f implicit
    
 =20
   =20
 =20
  
    
    An SPA has a backend
      because it has to be loaded from somewhere :)
    
    
    
    
    On 11/21/18 3:47 AM=
, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    We had a discussion about this topic on Twitter https://twi=
tter.com/Apl3b/status/1064854507606208513

Outcome is POST requires a backend to receive the request so it=E2=80=99s n=
ot a viable solution for SPAs.


    
      
    
        
    Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.com>:

Post response works OK for server based clients.  I don't think POST wo=
rks for single page applications. =20

Basically that would be something more like postmessage between two JS apps=
. =20

Postmessage also has security issues passing a access token and leaking. =
=20

Perhaps someone more familiar with SPA can comment on POST. =20

John B.=20



On Tue, Nov 20, 2018, 6:40 PM George Fletcher <gffletch@aol.com wrote:
Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but it d=
oesn't prevent the token from traversing through the browser. So a man-=
in-the-browser attack may be able to intercept the values. It should help w=
ith leakage in logs.

Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:

    
        
    
          
    Next question =E2=80=93 doesn=E2=80=99t using the Form Post =
Response Mode https://openid.net/specs/oauth-v2-form-po=
st-response-mode-1_0.html mitigate the threats you=E2=80=99re describin=
g below John?  If so, I believe the Security Topics draft should say this.

=20

I believe we owe it to readers to present the complete picture, which is wh=
y I believe that describing profiles using ID Tokens and the Form Post Resp=
onse Mode are in scope.

=20

                                                       -- Mike

=20

From: OAuth <oa=
uth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Tuesday, November 20, 2018 7:47 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization co=
de instead of implicit

=20

Yes the at_hash protects the client from accepting an injected AT.=20

Unfortunately it doesn't do anything to protect against leakage in logs=
 or redirects.

So without the AT using some sort of POP mechanism it is hard to say sendin=
g it in a redirect is a good security practice.

John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike,=20
=20
I agree that OIDC hybrid flows offer additional security over the OAuth imp=
licit grant and are used in the wild. On my slides and in the initial versi=
on of the new section, we had included the hybrid OIDC flows because of the=
ir known token injection countermeasures.
=20
I nevertheless feel very uncomfortable to recommend those flows and any flo=
w issuing access tokens in the front channel. In the course of the detailed=
 review of the new text we realized two issues:=20
=20
1) Since the access token is exposed in the URL, such flows possess a signi=
ficantly higher risk to leak the access token (e.g. through browser history=
, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the f=
ront channel. Given the WG decided to recommend use of sender constraint to=
kens (https://tools.ietf.org/html/draft-ietf-o=
auth-security-topics-09#section-2..2), it seems contradictory to recomm=
end response types not supporting such an approach.=20
=20
kind regards,
Torsten.=20
=20
Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=3D40micro=
soft.com@dmarc.ietf.org>:
=20
This description of the situation is an oversimplification..  OpenID Connec=
t secures the implicit flow against token injection attacks by including th=
e at_hash (access token hash) in the ID Token, enabling the client to valid=
ate that the access token was created by the issuer in the ID Token (which =
is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitig=
ation was described in draft-ietf-oauth-mix-up-mitigation.)
=20
Given the prevalence of this known-good solution for securing the implicit =
flow, I would request that the draft be updated to describe this mitigation=
.  At the same time, I=E2=80=99m fine with the draft recommending the code =
flow over the implicit flow when this mitigation is not used.
=20
                                                                Thank you,
                                                                -- Mike
=20
From: OAuth <oa=
uth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <oauth@ietf.o=
rg>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code i=
nstead of implicit
=20
Hi all,
=20
The authors of the OAuth Security Topics draft came to the conclusion that =
it is not possible to adequately secure the implicit flow against token inj=
ection since potential solutions like token binding or JARM are in an early=
 stage of adoption. For this reason, and since CORS allows browser-based ap=
ps to send requests to the token endpoint, Torsten suggested to use the aut=
horization code instead of the implicit grant in call cases in his presenta=
tion (seehttps://datatracker.ietf.org/meeting/103/materials/slides-=
103-oauth-sessb-draft-ietf-oauth-security-topics-01).
=20
A hum in the room at IETF#103 concluded strong support for his recommendati=
ons. We would like to confirm the discussion on the list.
=20
Please provide a response by December 3rd.
=20
Ciao
Hannes & Rifaat
=20
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://www.ietf.org/mailman/listinfo/oauth
=20



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

    
      
    
      
    
    
    
    
    
  
    

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

    

--000000000000f301c9057b2d2040--


From nobody Wed Nov 21 20:21:59 2018
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 0E42612D4ED for ; Wed, 21 Nov 2018 20:21:58 -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, 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 T7qyln8NuACl for ; Wed, 21 Nov 2018 20:21:56 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 79D95124BE5 for ; Wed, 21 Nov 2018 20:21:56 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:d540:185e:d973:299a] (unknown [IPv6:2601:282:202:b210:d540:185e:d973:299a]) by alkaline-solutions.com (Postfix) with ESMTPSA id D69EF315E9; Thu, 22 Nov 2018 04:21:54 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: David Waite 
In-Reply-To: 
Date: Wed, 21 Nov 2018 21:21:53 -0700
Cc: George Fletcher , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <14BB75BB-F650-408D-8359-B25FA4E66DC9@alkaline-solutions.com> <1b451ff4-9de5-c3e2-acf3-f8b50b0212ff@aol.com> 
To: Hans Zandbelt 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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, 22 Nov 2018 04:21:58 -0000

> On Nov 21, 2018, at 12:08 AM, Hans Zandbelt =
 wrote:
>=20
> I think of this as somewhat similar to:
> a)  a grant type where a cookie grant is exchanged at an "RP token =
endpoint" for an associated access and refresh token; the protocol =
between SPA and the API to do so would benefit from standardization e.g. =
into SDKs and server side frameworks
> b) an "RP token introspection endpoint" where the cookie is =
introspected at the RP and associated tokens are returned
>=20
> if anyone comes up with a better name for this model and endpoint (and =
probably less overloading of AS endpoint names...) and/or is willing to =
help writing this down, please come forward and we'll pick it up on a =
new thread/doc=20

Hand waving follows :-)

This sounds like the RP environment as two pieces, a javascript =
application and back-end infrastructure. The RP infrastructure maintains =
local tokens which it derives from remote tokens issued by a single =
upstream AS/IdP, which it interacts with as a confidential client.

This RP infrastructure separately manages authentication/authorization =
for a javascript application. In this use case, this infrastructure =
allows the javascript application to get the access token issued by the =
upstream AS, so that the javascript application may then act as the =
client to interact with protected resources associated with that AS. =
(For protected resources within the RP environment, a separate local =
token is used for authorization; possibly a non-OAuth token such as the =
cookie)

The first requirement of access token exposure sounds like a fit for =
token exchange, with the RP exposing its own authorization service token =
endpoint for this purpose, and the javascript acting as a public client =
to the RP and not to the upstream OAuth AS. The =E2=80=9Ccookie token=E2=80=
=9D would have a specific token type for this use case. Multiple =
exchanges would potentially return the same upstream access token, or =
could silently use the refresh token if needed to acquire and return a =
fresh access token.

In this scenario I would not expose the refresh token, as the javascript =
application should not have a direct relationship with the upstream AS, =
nor should it have credentials to perform the refresh.  Likewise, the =
id_token was addressed to the RP infrastructure and not the javascript =
application - I would expect authentication interactions to be between =
the RP infrastructure and the javascript application, indirectly based =
on the RP infrastructure=E2=80=99s relationship upstream service.

Once the javascript app has the access token, it should be able to use =
it to interact with a user info endpoint. This might be a RP user info =
endpoint, or the upstream user info endpoint, depending on RP =
requirements.

FWIW, if there are multiple upstream AS=E2=80=99s, I would expect the =
local RP environment to be a =E2=80=98full fledged=E2=80=99 AS issuing =
its own local access tokens, and to provide its own local protected =
resources which then may dispatch to the protected resources of the =
various upstream AS=E2=80=99s as needed. Everything above could be =
reused in this scenario, although you might just decide to have the =
local protected resources accept the cookie directly in addition to the =
local RP environment access tokens.

-DW=


From nobody Wed Nov 21 20:44:46 2018
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 40D46130E6F for ; Wed, 21 Nov 2018 20:44:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZYLq4ZqSGvS6 for ; Wed, 21 Nov 2018 20:44:39 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2577D130FAF for ; Wed, 21 Nov 2018 20:44:39 -0800 (PST)
Received: from [80.187.120.70] (helo=[10.149.176.184]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gPgqw-0007cS-FX; Thu, 22 Nov 2018 05:44:34 +0100
Content-Type: multipart/signed; boundary=Apple-Mail-1506B0D3-2B2E-44C1-AA58-C7AD3FE90156; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>
Date: Thu, 22 Nov 2018 05:44:23 +0100
Cc: John Bradley , Mike Jones , "oauth@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 22 Nov 2018 04:44:44 -0000

--Apple-Mail-1506B0D3-2B2E-44C1-AA58-C7AD3FE90156
Content-Type: multipart/alternative;
	boundary=Apple-Mail-78C90228-0674-4C17-9058-279BCBBEF30F
Content-Transfer-Encoding: 7bit


--Apple-Mail-78C90228-0674-4C17-9058-279BCBBEF30F
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

that=E2=80=99s certainly true, but that might by a web server with static co=
ntent only.

If the server is a real backend, there is even less reasons to use a implici=
t or hybrid. No even a performance gain in comparison to code.

> Am 21.11.2018 um 14:24 schrieb George Fletcher :
>=20
> An SPA has a backend because it has to be loaded from somewhere :)
>=20
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>> We had a discussion about this topic on Twitter https://twitter.com/Apl3b=
/status/1064854507606208513
>>=20
>> Outcome is POST requires a backend to receive the request so it=E2=80=99s=
 not a viable solution for SPAs.
>>=20
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley :
>>>>=20
>>>> Post response works OK for server based clients.  I don't think POST wo=
rks for single page applications. =20
>>>>=20
>>>> Basically that would be something more like postmessage between two JS a=
pps. =20
>>>>=20
>>>> Postmessage also has security issues passing a access token and leaking=
. =20
>>>>=20
>>>> Perhaps someone more familiar with SPA can comment on POST. =20
>>>>=20
>>>> John B.=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher >>> Hi Mike,
>>>>=20
>>>> The Form Post Response Mode keeps the access_token out of the URL, but i=
t doesn't prevent the token from traversing through the browser. So a man-in=
-the-browser attack may be able to intercept the values. It should help with=
 leakage in logs.
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Response Mo=
de https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitiga=
te the threats you=E2=80=99re describing below John?  If so, I believe the S=
ecurity Topics draft should say this.
>>>>=20
>>>> =20
>>>>=20
>>>> I believe we owe it to readers to present the complete picture, which i=
s why I believe that describing profiles using ID Tokens and the Form Post R=
esponse Mode are in scope.
>>>>=20
>>>> =20
>>>>=20
>>>>                                                        -- Mike
>>>>=20
>>>> =20
>>>>=20
>>>> From: OAuth  On Behalf Of John Bradley
>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>>>> To: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorizatio=
n code instead of implicit
>>>>=20
>>>> =20
>>>>=20
>>>> Yes the at_hash protects the client from accepting an injected AT.=20
>>>>=20
>>>> Unfortunately it doesn't do anything to protect against leakage in logs=
 or redirects.
>>>>=20
>>>> So without the AT using some sort of POP mechanism it is hard to say se=
nding it in a redirect is a good security practice.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>>>=20
>>>> Hi Mike,=20
>>>> =20
>>>> I agree that OIDC hybrid flows offer additional security over the OAuth=
 implicit grant and are used in the wild. On my slides and in the initial ve=
rsion of the new section, we had included the hybrid OIDC flows because of t=
heir known token injection countermeasures.
>>>> =20
>>>> I nevertheless feel very uncomfortable to recommend those flows and any=
 flow issuing access tokens in the front channel. In the course of the detai=
led review of the new text we realized two issues:=20
>>>> =20
>>>> 1) Since the access token is exposed in the URL, such flows possess a s=
ignificantly higher risk to leak the access token (e.g. through browser hist=
ory, open redirection and even referrer headers) than the code grant.
>>>> 2) There is no viable way to sender constrain access tokens issued in t=
he front channel. Given the WG decided to recommend use of sender constraint=
 tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#sec=
tion-2..2), it seems contradictory to recommend response types not supportin=
g such an approach.=20
>>>> =20
>>>> kind regards,
>>>> Torsten.=20
>>>> =20
>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones :
>>>> =20
>>>> This description of the situation is an oversimplification..  OpenID Co=
nnect secures the implicit flow against token injection attacks by including=
 the at_hash (access token hash) in the ID Token, enabling the client to val=
idate that the access token was created by the issuer in the ID Token (which=
 is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitig=
ation was described in draft-ietf-oauth-mix-up-mitigation.)
>>>> =20
>>>> Given the prevalence of this known-good solution for securing the impli=
cit flow, I would request that the draft be updated to describe this mitigat=
ion.  At the same time, I=E2=80=99m fine with the draft recommending the cod=
e flow over the implicit flow when this mitigation is not used.
>>>> =20
>>>>                                                                 Thank y=
ou,
>>>>                                                                 -- Mike=

>>>> =20
>>>> From: OAuth  On Behalf Of Hannes Tschofenig
>>>> Sent: Monday, November 19, 2018 2:34 AM
>>>> To: oauth 
>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization co=
de instead of implicit
>>>> =20
>>>> Hi all,
>>>> =20
>>>> The authors of the OAuth Security Topics draft came to the conclusion t=
hat it is not possible to adequately secure the implicit flow against token i=
njection since potential solutions like token binding or JARM are in an earl=
y stage of adoption. For this reason, and since CORS allows browser-based ap=
ps to send requests to the token endpoint, Torsten suggested to use the auth=
orization code instead of the implicit grant in call cases in his presentati=
on (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-s=
essb-draft-ietf-oauth-security-topics-01).
>>>> =20
>>>> A hum in the room at IETF#103 concluded strong support for his recommen=
dations. We would like to confirm the discussion on the list.
>>>> =20
>>>> Please provide a response by December 3rd.
>>>> =20
>>>> Ciao
>>>> Hannes & Rifaat
>>>> =20
>>>> IMPORTANT NOTICE: The contents of this email and any attachments are co=
nfidential and may also be privileged. If you are not the intended recipient=
, please notify the sender immediately and do not disclose the contents to a=
ny other person, use it for any purpose, or store or copy the information in=
 any medium. Thank you.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> =20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-78C90228-0674-4C17-9058-279BCBBEF30F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    tha=
t=E2=80=99s certainly true, but that might by a web server with static conte=
nt only.

    If the server is a=
 real backend, there is even less reasons to use a implicit or hybrid. No ev=
en a performance gain in comparison to code.
    
 =20
    
 =20
 =20
    An SPA has a backend
      because it has to be loaded from somewhere :)
    
    
    
    
    On 11/21/18 3:47 AM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513

Outcome is POST requires a backend to receive the request so it=E2=80=99s no=
t a viable solution for SPAs.


    
      
    
        
    Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.=
com>:

Post response works OK for server based clients.  I don't think POST works f=
or single page applications. =20

Basically that would be something more like postmessage between two JS apps.=
 =20

Postmessage also has security issues passing a access token and leaking. =20=


Perhaps someone more familiar with SPA can comment on POST. =20

John B.=20



On Tue, Nov 20, 2018, 6:40 PM George Fletcher <gffletch@aol.com wrote:
Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but it do=
esn't prevent the token from traversing through the browser. So a man-in-the=
-browser attack may be able to intercept the values. It should help with lea=
kage in logs.

Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:

    
        
    
          
    Next question =E2=80=93 doesn=E2=80=99t using the Fo=
rm Post Response Mode https://openid.net/=
specs/oauth-v2-form-post-response-mode-1_0.html mitigate the threats you=
=E2=80=99re describing below John?  If so, I believe the Security Topics dra=
ft should say this.

=20

I believe we owe it to readers to present the complete picture, which is why=
 I believe that describing profiles using ID Tokens and the Form Post Respon=
se Mode are in scope.

=20

                                                       -- Mike

=20

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Tuesday, November 20, 2018 7:47 AM
To: oau=
th@ietf.org
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization cod=
e instead of implicit

=20

Yes the at_hash protects the client from accepting an injected AT.=20

Unfortunately it doesn't do anything to protect against leakage in logs or r=
edirects.

So without the AT using some sort of POP mechanism it is hard to say sending=
 it in a redirect is a good security practice.

John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike,=20
=20
I agree that OIDC hybrid flows offer additional security over the OAuth impl=
icit grant and are used in the wild. On my slides and in the initial version=
 of the new section, we had included the hybrid OIDC flows because of their k=
nown token injection countermeasures.
=20
I nevertheless feel very uncomfortable to recommend those flows and any flow=
 issuing access tokens in the front channel. In the course of the detailed r=
eview of the new text we realized two issues:=20
=20
1) Since the access token is exposed in the URL, such flows possess a signif=
icantly higher risk to leak the access token (e.g. through browser history, o=
pen redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the fr=
ont channel. Given the WG decided to recommend use of sender constraint toke=
ns (https://tools.ietf.org/html=
/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradicto=
ry to recommend response types not supporting such an approach.=20
=20
kind regards,
Torsten.=20
=20
Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.=
Jones=3D40microsoft.com@dmarc.ietf.org>:
=20
This description of the situation is an oversimplification..  OpenID Connect=
 secures the implicit flow against token injection attacks by including the a=
t_hash (access token hash) in the ID Token, enabling the client to validate t=
hat the access token was created by the issuer in the ID Token (which is als=
o the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation w=
as described in draft-ietf-oauth-mix-up-mitigation.)
=20
Given the prevalence of this known-good solution for securing the implicit f=
low, I would request that the draft be updated to describe this mitigation. =
 At the same time, I=E2=80=99m fine with the draft recommending the code flo=
w over the implicit flow when this mitigation is not used.
=20
                                                                Thank you,
                                                                -- Mike
=20
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth =
<oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code in=
stead of implicit
=20
Hi all,
=20
The authors of the OAuth Security Topics draft came to the conclusion that i=
t is not possible to adequately secure the implicit flow against token injec=
tion since potential solutions like token binding or JARM are in an early st=
age of adoption. For this reason, and since CORS allows browser-based apps t=
o send requests to the token endpoint, Torsten suggested to use the authoriz=
ation code instead of the implicit grant in call cases in his presentation (=
seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01).
=20
A hum in the room at IETF#103 concluded strong support for his recommendatio=
ns. We would like to confirm the discussion on the list.
=20
Please provide a response by December 3rd.
=20
Ciao
Hannes & Rifaat
=20
IMPORTANT NOTICE: The contents of this email and any attachments are confide=
ntial and may also be privileged. If you are not the intended recipient, ple=
ase notify the sender immediately and do not disclose the contents to any ot=
her person, use it for any purpose, or store or copy the information in any m=
edium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth
=20



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


_______________________________________________
OAuth mailing list

OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

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

    
      
    
      
    
    
    
    
    
 =20


    =

--Apple-Mail-78C90228-0674-4C17-9058-279BCBBEF30F--

--Apple-Mail-1506B0D3-2B2E-44C1-AA58-C7AD3FE90156
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED
e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/
BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX
dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu
wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT
QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs
0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F
dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX
Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG
CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB
Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy
ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j
b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp
bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB
F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976
FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz
62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4
wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq
8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4
Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTIyMDQ0NDIzWjAvBgkqhkiG
9w0BCQQxIgQgdYnUF533W+QXGppkRsNBkvezrYUQwl8qoWpTOLOVcE4wgcEGCSsGAQQBgjcQBDGB
szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT
SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3
mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB
IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBACif
Tc71mOgQKsQ85ztCFfBsPDEdR14C4X+8H9gt7LMLxAOUaI5hvXoAFF084NmEMzltN9Icq5dsrwat
vrT3h8wJlKeSRHuBeIYVozLWop3pS/g9a+uDIytvbUXD8+XuB+N+m2UUa/FvG8HGjSG0zT5iROL5
s7qLnAVm4a+N5ECfYjr4ww4UYy2yu7KShZ4SZBSeKkEkXDoFV5CoExTjBiuIoZo1+KNxGEgHd1SD
mCIBoSfEtVcJpr2ZmvQaiDc6APD9zKSE8BGpbeu5jmMn3AgdaHpbloKwO5TvnDlPKl6eKj3/DaHr
ogmfWw9Axri3bSsmFu07ZZoY3iLsp45xU+0AAAAAAAA=

--Apple-Mail-1506B0D3-2B2E-44C1-AA58-C7AD3FE90156--


From nobody Wed Nov 21 20:50:26 2018
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 03452130FCD for ; Wed, 21 Nov 2018 20:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 o-AehDVCjY6A for ; Wed, 21 Nov 2018 20:50:24 -0800 (PST)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 2BFDC130FCB for ; Wed, 21 Nov 2018 20:50:24 -0800 (PST)
Received: from [80.187.120.70] (helo=[10.149.176.184]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gPgwV-00025L-Jf; Thu, 22 Nov 2018 05:50:19 +0100
Content-Type: multipart/signed; boundary=Apple-Mail-AA744B3A-964B-4C25-A8E0-94C325CEE440; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com>
Date: Thu, 22 Nov 2018 05:49:22 +0100
Cc: Aaron Parecki , OAuth WG 
Content-Transfer-Encoding: 7bit
Message-Id: <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net>
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 22 Nov 2018 04:50:26 -0000

--Apple-Mail-AA744B3A-964B-4C25-A8E0-94C325CEE440
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi George,

> Am 20.11.2018 um 22:15 schrieb George Fletcher :
>=20
> OIDC provides a "prompt=3Dnone" mechanism that allows the browser app to r=
equest a new token in a hidden iframe. OAuth2 doesn't describe this flow. No=
te that full authentications of users should NOT happen in iframes due to cl=
ick-jacking attacks.

Does this still work reliably given the limitations imposed by the browser=E2=
=80=98s 3rd party cookie policies?

kind regards,
Torsten.=

--Apple-Mail-AA744B3A-964B-4C25-A8E0-94C325CEE440
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED
e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/
BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX
dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu
wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT
QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs
0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F
dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX
Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG
CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB
Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy
ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j
b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp
bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB
F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976
FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz
62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4
wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq
8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4
Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTIyMDQ0OTIyWjAvBgkqhkiG
9w0BCQQxIgQgRgm/BMrMC0+8VHRSDICqLhKqx0RsEM3ztBb6nToMon0wgcEGCSsGAQQBgjcQBDGB
szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT
SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3
mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB
IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBADWr
rxLeHXdfj3a1e2OSAfMEW0cQx44AjvTlzHm8hRIvRk1WZyWEP1Fa/RBswSH925PWL2K3NxYauRWW
SbMCmk0bXu4CUbNhXe/pYN6OfkEdzYaugeLLVMou6io64LGJnFHRAil1Tcc3UbBXw61omvFDX/x0
aGQaS4OWBgw/NlbN+3r2KL2f0GEDQD9i5f2Y+BlpuzkK42HUXmXtew0R3UnaFXLaW1Em2qLSi6Qf
pbkgMr9s7sYsjH+la+KTWUm3DyCNrLx8YpvjBnYJtq9VO6gcWpGhTxfIqyC6ltCXoYbZXrhfcBXW
0/I1S0dvdDSBpOYnY2L2uQQcSeksaouv2IcAAAAAAAA=

--Apple-Mail-AA744B3A-964B-4C25-A8E0-94C325CEE440--


From nobody Thu Nov 22 06:42:13 2018
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 17188130ED9 for ; Thu, 22 Nov 2018 06:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 OFoK3gvi3hVt for ; Thu, 22 Nov 2018 06:42:10 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450: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 AEDCB130E46 for ; Thu, 22 Nov 2018 06:42:09 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id h15so7915825edb.4 for ; Thu, 22 Nov 2018 06:42:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=tlSP+0m7tl+9jxX5z8JUmAMjDpkPhGY98ofMF1tCBhc=; b=kDMo022cfVNZRtOJkQBmicrdpwHNVHDWcdsbNvtTd5aCJtkB26iSqIfMg0PT3hxJGF dYr+Qii8NkpJnJuzKcSKhtR+8flH82WQOEraDa0KyDsNYY1tuBJapdoHZk+5lczICdKT lcxz7WdfJ35DdQYPjKOLHEOWNzP4DY074kcCvfdtMWSXwIEjLOPFhYin87xLi8Qsh7+D M072HX40nEThbnE0WF4hy4vybD4HcDQDqxSLHd+OmhRW+Qnn8s9g26RKoMUo3uflNWYU vLkQq7QLR6ARpOZUEoMowi8+ZwL0Z5AfrsCDGUIOvCHlrMgwJibBJzT1NP4Vndcp33jA J29w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=tlSP+0m7tl+9jxX5z8JUmAMjDpkPhGY98ofMF1tCBhc=; b=ryT8NXHPrLl68DQGoyJnNb8tbvryugb2hXnwu9TVIJTNl4qxiqH3pOEKnQeC7mDJkl ro6Px9jXpvFz9dFQSbx3PVYosUz6zRDhZbTeGPiuDjQ3fp7gIM+JNI6XMTM1P12SYAGG pRpCdW+j/2mIVNO+/nuTxkvMIlKu+5kQFNM6MpX6XYHZtw8DgksRJ3O3p5OCACht5M5j Wlum39h5fB2y6lRW06r5yfYXgvJkZboqTUBWszD3xt7cpVxh0kQLLstM44x+snSxBLA5 AukQ31BGWHjL2Uyqh29TFcH9JHV0TR1c+06vi1sja9p2r7WZy382l0+lQqb9hCLRzDmh WLbA==
X-Gm-Message-State: AA+aEWbSp5/iEHiWMtUx70VKk34dfuhktU0+WXxkCVsKYHgsqAzCNmXh XPZeZEUn192XBmmt4NmDEnjpGXldLwc=
X-Google-Smtp-Source: AFSGD/UX2+xnzCBhw9hcfD06mKcxMUDEg6StCBqDMRGiF/eX5sCrZQ+gDaLIE8AaHlpBZ61Ei0Ja8Q==
X-Received: by 2002:a50:b36f:: with SMTP id r44mr6543092edd.284.1542897727875;  Thu, 22 Nov 2018 06:42:07 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id e35sm8482105eda.13.2018.11.22.06.42.06 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 06:42:07 -0800 (PST)
To: "oauth@ietf.org" 
From: Daniel Fett 
Message-ID: 
Date: Thu, 22 Nov 2018 15:42:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------476A46BFDA9420A85F39158D"
Content-Language: de-DE
Archived-At: 
Subject: [OAUTH-WG] Binding Access Tokens is not enough!
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, 22 Nov 2018 14:42:12 -0000

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

Hi all,

I would like to discuss a text proposal for the security BCP.

Background:

Yesterday, Neil pointed out the following problem with binding access
tokens using mTLS or token binding in SPAs:

"I am talking about scripts from places like ad servers that are usually
included via an iframe to enforce the SOP and sandbox them from other
scripts. If they get access to an access token - e.g. via
document.referrer or a redirect or some other leak, then they still act
within the same TLS context as the legitimate client."

The problem is that a browser's TLS stack will attach the proof of
possession no matter which origin started a request.

(This seems like a real downside of token binding - why does it not have
the "same site" option that cookies nowadays have?)

I prepared the following addition to the security BCP and would like to
hear your opinions:

"It is important to note that constraining the sender of a token to a
web browser (using a TLS-based method) does not constrain the origin of
the script that uses the token (lack of origin binding). In other words,
if access tokens are used in a browser (as in a single-page application,
SPA) and the access tokens are sender-constrained using a TLS-based
method, it must be ensured that origins other than the origin of the SPA
cannot misuse the TLS-based sender authentication.

The problem can be illustrated using an SPA on origin A that uses an
access token AT that is bound to the TLS connection between the browser
and the resource server R. If AT leaks to an attacker E, and there is,
for example, an iframe from E's origin loaded in the web browser, that
iframe can send a request to origin R using the access token AT. This
request will contain the proof-of-posession of the (mTLS or token
binding) key. The resource server R therefore cannot distinguish if a
request containing a valid access token originates from origin A or
origin E.

If the resource server only accepts the access token in an Authorization
header, then Cross-Origin Resource Sharing (CORS) will protect against
this attack by default. If the resource server accepts the access tokens
in other ways (e.g., as a URL parameter), or if the CORS policy of the
resource server permits requests by origin E, then the TLS-based token
binding only provides protection if the browser is offline."


The "summary" above this text reads as follows:

"If access tokens are sender-constrained to a web browser, the resource
server MUST ensure that the access token can only be used by the origin
to which the access token was issued (origin binding). One solution for
the resource server to accomplish this is to only accept the access
token in an Authorization header (as described in RFC 6750) and to
ensure that the active CORS policy prevents third parties from sending
Authorization headers. See  for details."

What do you think?

-Daniel


--------------476A46BFDA9420A85F39158D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    Hi all,
    
    
    I would like to discuss a text proposal for the security BCP.
    
    
    
    
    Background:
    
    
    Yesterday, Neil pointed out the following problem with binding
      access tokens using mTLS or token binding in SPAs:
    
    
    "I am talking about scripts from places like ad servers that are
      usually included via an iframe to enforce the SOP and sandbox them
      from other scripts. If they get access to an access token - e.g.
      via document.referrer or a redirect or some other leak, then they
      still act within the same TLS context as the legitimate client."
    
    
    The problem is that a browser's TLS stack will attach the proof
      of possession no matter which origin started a request.
    
    
    (This seems like a real downside of token binding - why does it
      not have the "same site" option that cookies nowadays have?)
    
    
    
    
    I prepared the following addition to the security BCP and would
      like to hear your opinions:
    
    "It is important to note that constraining the sender of a token to
    a web browser (using a TLS-based method) does not constrain the
    origin of the script that uses the token (lack of origin binding).
    In other words, if access tokens are used in a browser (as in a
    single-page application, SPA) and the access tokens are
    sender-constrained using a TLS-based method, it must be ensured that
    origins other than the origin of the SPA cannot misuse the TLS-based
    sender authentication.
    
    
    
    The problem can be illustrated using an SPA on origin A that uses an
    access token AT that is bound to the TLS connection between the
    browser and the resource server R. If AT leaks to an attacker E, and
    there is, for example, an iframe from E's origin loaded in the web
    browser, that iframe can send a request to origin R using the access
    token AT. This request will contain the proof-of-posession of the
    (mTLS or token binding) key. The resource server R therefore cannot
    distinguish if a request containing a valid access token originates
    from origin A or origin E.
    
    
    
    If the resource server only accepts the access token in an
    Authorization header, then Cross-Origin Resource Sharing (CORS) will
    protect against this attack by default. If the resource server
    accepts the access tokens in other ways (e.g., as a URL parameter),
    or if the CORS policy of the resource server permits requests by
    origin E, then the TLS-based token binding only provides protection
    if the browser is offline."
    

    
    
    
    
    The "summary" above this text reads as follows:
    
    
    "If access tokens are sender-constrained to a web browser, the
      resource server MUST ensure that the access token can only be used
      by the origin to which the access token was issued (origin
      binding). One solution for the resource server to accomplish this
      is to only accept the access token in an Authorization header (as
      described in RFC 6750) and to ensure that the active CORS policy
      prevents third parties from sending Authorization headers. See
      <xref target="pop_tokens"/> for details."
    
    
    What do you think?
    
    
    -Daniel
    
    
    
  


--------------476A46BFDA9420A85F39158D--


From nobody Thu Nov 22 07:48:11 2018
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 DC03D126C7E for ; Thu, 22 Nov 2018 07:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JAdtXjKNdJpE for ; Thu, 22 Nov 2018 07:48:07 -0800 (PST)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471AB12DF72 for ; Thu, 22 Nov 2018 07:48:07 -0800 (PST)
Received: by mail-ot1-x336.google.com with SMTP id a11so8380245otr.10 for ; Thu, 22 Nov 2018 07:48:07 -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=wesMBAHxDDpMgixHXhEKiVih4hRav+KgMnqWbch7k0g=; b=etGTSkvXhg1dcVjH/sYLBtrjKunQCIteungSk5c0eYo5x8iAL4p+2Lov3e8fNYCRQ9 BCgPWqsvTjljpoag/BUAWgxKWwHGYCo9+7+mgygcXqWW3GrniwzJ66gTGbmzaojKsBtB cZSjfw9JlDwLQ7JhNrcciUz/9N6FTZwh5hw+expZHWfSZvvuT9UAdRs5A53N3AbJaOu/ QhY1IqA/LW/voNBs9TdlrXMO0siJJqw2n6I+IUVPgkfghbz+eaD4EKq/CWyrjpKarrjf akSnAlWZhrrYdaHGu13GUke9zHUdxsd3OSrrP+pJryqPd0+GuGHAeltAdY3bwQWuaZb5 ctFw==
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=wesMBAHxDDpMgixHXhEKiVih4hRav+KgMnqWbch7k0g=; b=CGmpIAJVnvNr68apHWVtxpFgYqIoeJOuLqO+kwGrvmJRBkFx7qrXEol8+LRIDviGWs TOVckEqLyf7ojY5a9RVdsAEJ7v9YFP0Epkaax8BgcC3dkMxpIYSvJRoQdWcvZZEXSM5Y 7fLrtDCpRPuUD1Z1XphnxTh3a4cfe00nSiJ8tkbhp8oT4JsPbJo/pks9um3v5jF+fD7O NxXS3Ur8J9uMxQ9c3Lw+d+M6DlXwGSJWiUkJId5IBnNXPsHUTkvhgXdOOCF+tmlrcrE2 AbzcZ/mKyTDoP1HKafNTr6sOmOZToh2IFKSg1mK6VNrvb169JJXTHYoD7rKKdylTz/jF yyjQ==
X-Gm-Message-State: AA+aEWb47OB6Xpzn6yKvaevfB7uIUUhR8FRTcXDf3ojkMo/PhSnbvJkM slSTjbwWc/WHjIAmNThtQG/F4U56ONd+B9jbI3V4eg==
X-Google-Smtp-Source: AFSGD/U6JP4Zd5Zq6QzKoKjRSFOqlpaU8V3OwSUx+P4baY8EHe9AucJNLDsJ6VdV/iRrv04XKaoC53nQdmsf/XZainw=
X-Received: by 2002:a9d:582e:: with SMTP id r46mr6837266oth.238.1542901686526;  Thu, 22 Nov 2018 07:48:06 -0800 (PST)
MIME-Version: 1.0
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com> <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net>
In-Reply-To: <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net>
From: Thomas Broyer 
Date: Thu, 22 Nov 2018 16:47:55 +0100
Message-ID: 
To: Torsten Lodderstedt 
Cc: George Fletcher , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000f2e815057b42ca64"
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 22 Nov 2018 15:48:10 -0000

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

On Thu, Nov 22, 2018 at 5:50 AM Torsten Lodderstedt 
wrote:

> Hi George,
>
> > Am 20.11.2018 um 22:15 schrieb George Fletcher :
> >
> > OIDC provides a "prompt=3Dnone" mechanism that allows the browser app t=
o
> request a new token in a hidden iframe. OAuth2 doesn't describe this flow=
.
> Note that full authentications of users should NOT happen in iframes due =
to
> click-jacking attacks.
>
> Does this still work reliably given the limitations imposed by the
> browser=E2=80=98s 3rd party cookie policies?
>

Fwiw, I haven't had any problem (yet) with my OpenID Connect Session
Management implementation.

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




    On Thu=
, Nov 22, 2018 at 5:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi George,
    

    
> Am 20.11.2018 um 22:15 schrieb George Fletcher <gffletch@aol.com>:
    
> 
    
> OIDC provides a "prompt=3Dnone" mechanism that allows the br=
owser app to request a new token in a hidden iframe. OAuth2 doesn't des=
cribe this flow. Note that full authentications of users should NOT happen =
in iframes due to click-jacking attacks.
    

    
Does this still work reliably given the limitations imposed by the browser=
=E2=80=98s 3rd party cookie policies?

    F=
wiw, I haven't had any problem (yet) with my OpenID Connect Session Man=
agement implementation.
    

--000000000000f2e815057b42ca64--


From nobody Thu Nov 22 11:09:00 2018
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 AA399129A87 for ; Thu, 22 Nov 2018 11:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Fl4eG8CxnztB for ; Thu, 22 Nov 2018 11:08:56 -0800 (PST)
Received: from sonic302-21.consmr.mail.ir2.yahoo.com (sonic302-21.consmr.mail.ir2.yahoo.com [87.248.110.84]) (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 86460128AFB for ; Thu, 22 Nov 2018 11:08:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542913733; bh=LqOPLmGq0KNaaIj+ou8l1IoD/Y3XoV9nGSMkeAwix4w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=SrzXWnsBR1Lbq1OLp8qyhvTfNqUV2O8oR1XYJHH3RauHDnBkfaDNKBEsqyHp1L6xcT9NJe8K2oX5WOt8sLqE2hoJYIWShiyxubDHyLPPxO/IfZXOAH6eUPI30BFCmeCeEATBpNUI7CMTLkOPzjxAnahnjT+ePzAc8c66a+ubMPV+b9gVESb5jHbXwUw5dYY/8gMCe7Nk4GigJb9SWMrRAn/Cj4UTQgk6zDdl2tuT+ApsnykGgh5/v7ilYY8GdZ4aNwEIDgnUPGQ4SnsOPtpJWJWxwITkthokPb8jThpNinF5a93gq4oiVoqyH8GH44pBe2xpuR8Q4WoxBBLajwsaEA==
X-YMail-OSG: OU4H9pEVM1n5BwFvDUZbkRfkclQXwcJOsjpWits3z.3_heId4OrOb1oWWaX0ioc X_BhnODug2cU4RIvD4n3sNfSrHTBteh55jinHKpBK7mbOqtGtY.LSRb1_a0ztuse0ASh2t5v4bHD VYLTfYxclNM6xT47kbab7b2DOXVl25GVwM26F1Pbi5pmxJEop1ipuua4mqeQr8TzzAJkVad26vBw wdpIycrWQVBUs85m7ZCe8zqPuPpDsv529Jwdfff_cNXsU.wNjM__YHyoh8DNWvKSlb6Ut6c.0T4r tx2SXHNfTqr7ufV8Pq4nWYNq8OIcTdvLcXmIHWO88WYx2bOtZUbCLLzToTgvXwIc3tqfXKIFHuhi k1vae5z2xta9jGZsvH97heZs33ipM7pfkBB6fPAhTYR87QBQXgVApeuhKh_CGjL._V_.ZDHIy_tI lQeV_0xP4f0pTXryCi0Al30NulVZ3yOnIvXoYvmSI12UZNFGyBT.32ZT0qS4tPpWwfRbHrOi8mEP mea8jcg66WMBGBMXtY1vYEfhtkxb3_1oOTt21PsgNSPFzH0fIriu08yppOqLwEhIVf2rCTH9G7kX _uq9nU3AQVNET0pxr9ji.DzYHquuoWoCr7sKK54Q22Obsb5uHjFMKLnu.GnS8Gc5UWQikz5AKFmC MlNWLvdOtGD7EZZzu0Ld2GuM1CXFUyloF_IGd_YZelxSsn60WdHzasip0vNQHO4ESJQwZjPv6kd8 jAOIVTSwyg_lCkRKD8iRXQdJCIZ3gaDpUXrXeWoFF2AmYCpeX0fV6.HEb7ttYgrz7YKLTr_xZq.y c5RyJejdS3v7pb5rskTB3BRYzl_2hsU1EQhIJNA1BbRpTSIizfnucpLe0ApxT_tkczRt5z.V8yRp HijYSxH6l9yR_F96zYzZojdbF3OZ.RrJAyEirEppL7juyVD7F2QdP5Oz8F9f1lcO0P5QFrdw33kH v65nPmJ1IIbLl3n6oybXWAkpjQHkyYYt.rKjCSi7Vk0pRctgbXMzVGxQptbIuwjza6vZrnsUXtnA sN80IE0XXuT_wtC0qNeIZ9j5r5Ek7Ba6WsYFgYwhvuMfjDlpAkN4phb_Nag--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ir2.yahoo.com with HTTP; Thu, 22 Nov 2018 19:08:53 +0000
Received: from 208.72.78.175 (EHLO [192.168.50.169]) ([208.72.78.175]) by smtp407.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6498ac6d78f64fdeca1338471a6ae8d5;  Thu, 22 Nov 2018 19:08:50 +0000 (UTC)
To: Torsten Lodderstedt 
Cc: Aaron Parecki , OAuth WG 
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com> <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <45488c5d-54c8-a680-dc66-7fd5d4d41a7b@aol.com>
Date: Thu, 22 Nov 2018 14:08:47 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------3902CBC0BA549F6D80BF5B3E"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 22 Nov 2018 19:08:59 -0000

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

My understanding is that cookies are not blocked on redirects 
(IPT2/Safari) but I haven't done extensive testing. So from a full-page 
redirect perspective there should be no issues, from a hidden iframe I'm 
not sure... but I believe it will work.

On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
> Hi George,
>
>> Am 20.11.2018 um 22:15 schrieb George Fletcher :
>>
>> OIDC provides a "prompt=none" mechanism that allows the browser app to request a new token in a hidden iframe. OAuth2 doesn't describe this flow. Note that full authentications of users should NOT happen in iframes due to click-jacking attacks.
> Does this still work reliably given the limitations imposed by the browser‘s 3rd party cookie policies?
>
> kind regards,
> Torsten.


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


  
    
  
  
    My understanding is that
      cookies are not blocked on redirects (IPT2/Safari) but I haven't done
      extensive testing. So from a full-page redirect perspective there
      should be no issues, from a hidden iframe I'm not sure... but I
      believe it will work.
    
    
    
    
    On 11/21/18 11:49 PM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi George,


    
      
    
        
    Am 20.11.2018 um 22:15 schrieb George Fletcher <gffletch@aol.com>:

OIDC provides a "prompt=none" mechanism that allows the browser app to request a new token in a hidden iframe. OAuth2 doesn't describe this flow. Note that full authentications of users should NOT happen in iframes due to click-jacking attacks.

    
      
    
      
    Does this still work reliably given the limitations imposed by the browser‘s 3rd party cookie policies?

kind regards,
Torsten.
    
    
    
    
    
  


--------------3902CBC0BA549F6D80BF5B3E--


From nobody Fri Nov 23 05:34:46 2018
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 99634128CFD for ; Fri, 23 Nov 2018 05:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 r4ymKyNhIwt5 for ; Fri, 23 Nov 2018 05:34:42 -0800 (PST)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 8C3CB12D4EB for ; Fri, 23 Nov 2018 05:34:41 -0800 (PST)
Received: by mail-ot1-x331.google.com with SMTP id 32so10632443ota.12 for ; Fri, 23 Nov 2018 05:34:41 -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=qwWFIHe/BQa3sYdBwToMY2HusqIkyNQmDsZnuvShOIg=; b=PvCZJ3FxNw+etgeMDxwh5RYCIIPlxjVtEWGXjyh3JIixKPokOYiw18QfQy7fthjkgk 0Avcolo9uLoyPlozrl41EYhqzDD8mPW9OciJPpjB+++gikwQ3PvFpvyPpOVc/Sh7Cenf BaBtj+QPlH7UHh8lKhHyrxrBLxWpGGjUCQ9tvScF17aodNwREFLrOuzvUeMC0IcZ6mYo 7PCLIRMYahfmLMM/+QXIJtDXwpsP8bQ9nG7xL0YUNnajqGV4G9yJQT78vv6R/lcanqYk FCuNDE6O0148xsLXu2fe3qmui9cxoL1ROzEEVFzcc0yj9trOz9Bm70YStLYk4h6JyhnJ 5e6g==
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=qwWFIHe/BQa3sYdBwToMY2HusqIkyNQmDsZnuvShOIg=; b=SA8Z6aLhEtWyyXrszwkbsgQ8iRngjiHGvFfDkFW6xc8dlb60CNKM5RibvU2J8WCeo2 grTBx//+1toqfacJOUJOXUZj25A/JZxyOUfT9SxBgJGYnvCZmkyWEKgByTj02M92gOUZ wpdQb1MmaWAjOJPbi0i1cQHcIE+pDsWRiHrzz7DlL7SxndcXQL6NKJV9jop18dILCTan 0pgmT42TFOq1O4XfhJtbmm2zPmeXk023+WeezGBSgfbcPln4MdSgbcdDMEFDgjHbmjpg 65TemxfisoCjOnz7JYdpPaQOg7jQbH3LH8aYsRME57VE1zbHLw5I17nWGOcMEuAZSYJE hdVQ==
X-Gm-Message-State: AA+aEWbhlt2eLkHJ7QgXdZRJm1byjYpzqwvhEk+nRHGQwS0qhWmq//zF fz+ByDC+pjK1uNTmRp6JSv7TZKS8M7ik4CIz3fdPMg==
X-Google-Smtp-Source: AFSGD/UGpEDuoDmTXApjQsQ7u6TzLczYFYO7OOvZ6XXOKTtDs35iRmsnoBs3QLoGHNju20HZe60ubC38uAOxaTsAJRE=
X-Received: by 2002:a9d:582b:: with SMTP id r43mr9127181oth.323.1542980080847;  Fri, 23 Nov 2018 05:34:40 -0800 (PST)
MIME-Version: 1.0
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com> <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net> <45488c5d-54c8-a680-dc66-7fd5d4d41a7b@aol.com>
In-Reply-To: <45488c5d-54c8-a680-dc66-7fd5d4d41a7b@aol.com>
From: Thomas Broyer 
Date: Fri, 23 Nov 2018 14:34:28 +0100
Message-ID: 
To: George Fletcher 
Cc: Torsten Lodderstedt , OAuth WG 
Content-Type: multipart/alternative; boundary="0000000000009d51a2057b550bb8"
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 23 Nov 2018 13:34:45 -0000

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

Just tested my OpenID Connect Session Management implementation with Safari
12.0.1 and it works like a charm.

On Thu, Nov 22, 2018 at 8:09 PM George Fletcher  wrote:

> My understanding is that cookies are not blocked on redirects
> (IPT2/Safari) but I haven't done extensive testing. So from a full-page
> redirect perspective there should be no issues, from a hidden iframe I'm
> not sure... but I believe it will work.
>
>
> On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
>
> Hi George,
>
>
> Am 20.11.2018 um 22:15 schrieb George Fletcher  :
>
> OIDC provides a "prompt=3Dnone" mechanism that allows the browser app to =
request a new token in a hidden iframe. OAuth2 doesn't describe this flow. =
Note that full authentications of users should NOT happen in iframes due to=
 click-jacking attacks.
>
>
> Does this still work reliably given the limitations imposed by the browse=
r=E2=80=98s 3rd party cookie policies?
>
> kind regards,
> Torsten.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    Just tested my OpenID Connect Session Management implement=
ation with Safari 12.0.1 and it works like a charm.

    On Thu, Nov 22, 2018 at 8:09 PM George Fl=
etcher <gffletch=3D40aol.com=
@dmarc.ietf.org> wrote:
    
 =20
   =20
 =20
  
    
    My understanding is that
      cookies are not blocked on redirects (IPT2/Safari) but I haven't =
done
      extensive testing. So from a full-page redirect perspective there
      should be no issues, from a hidden iframe I'm not sure... but I
      believe it will work.

    
    
    
    
    On 11/21/18 11:49 P=
M, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi George,


    
      
    
        
    Am 20.11.2018 um 22:15 schrieb George Fletcher <gffletch@aol.com>:

OIDC provides a "prompt=3Dnone" mechanism that allows the browser=
 app to request a new token in a hidden iframe. OAuth2 doesn't describe=
 this flow. Note that full authentications of users should NOT happen in if=
rames due to click-jacking attacks.

    
      
    
      
    Does this still work reliably given the limitations imposed by the browser=
=E2=80=98s 3rd party cookie policies?

kind regards,
Torsten.
    
    
    
    
    
  
    

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

    

--0000000000009d51a2057b550bb8--


From nobody Fri Nov 23 05:54:10 2018
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 AB96D130E2B for ; Fri, 23 Nov 2018 05:54:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 vutVXGN024Sf for ; Fri, 23 Nov 2018 05:54:05 -0800 (PST)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510CB129AB8 for ; Fri, 23 Nov 2018 05:54:05 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id k198so12112865wmd.3 for ; Fri, 23 Nov 2018 05:54:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MRCGYdvULuG7HHJj2LYgoUwgNtLsNIGL5F1c+RvZSCA=; b=Lb18LcVjBTaUTFaZZBz8GgGTc19XHR10VLsCfVjhLTmbVO00RN5+nAQFS57Y79xH5z u9YNmjFlTcNXT97wpj5S26HdbNrBOcR7KsQJaY9CELbl/PSoieM7Daw1o3zqE/LlRCLr yNBcChmpVG8wz71RF+ITQdXNS+MwGZQ0NBoTQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MRCGYdvULuG7HHJj2LYgoUwgNtLsNIGL5F1c+RvZSCA=; b=W+OzKq9HlyOhTUrJgb38+b9di26oyNlcVl9J2fUh2qNU8mar7W5Dd9D1KN1GKOHGzJ PQHjcUmk2TziLyKlb/A0gsUfqRIQ/d+5ZQXohHpraPPNQ3Nv0f3WfzjnL3fq1uVnGSHn pS1sjQZ3QYFmCDLriWXiTtqTttlSZtG+AbsC3Npgv2f01u6bgX2Gx+iKHmY8/J5U1bcq mrMh+0BKIq9IjsowDh06jDLABi+kka92K3kAHvKRWErfH8H+FuaI574B9YXh9g1FNmYZ VYEBF9UduooSqXKjoCocWjh6WNLfdW91c2pO9jeH7tvxFzYXad2pqh4REElqN0LF5MwM l8jg==
X-Gm-Message-State: AGRZ1gJ1zRHKRbuBkFKGoM9rKMWXWsecWBYvHoJaHoeeLdyI/IazamYe XSBJ3Vs3nesaRjPRrOHiCNEpgg==
X-Google-Smtp-Source: AFSGD/Wfff9VOo22uOi2XxiHjo+Q00Q5CRMbttxslUtCoOqvJ7tdrpOU8Z6Fm4OORPojZc9zr8iM+Q==
X-Received: by 2002:a1c:9611:: with SMTP id y17-v6mr14370096wmd.36.1542981243640;  Fri, 23 Nov 2018 05:54:03 -0800 (PST)
Received: from guest2s-mbp.lan (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id w16sm9515946wrp.1.2018.11.23.05.54.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Nov 2018 05:54:02 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Neil Madden 
In-Reply-To: 
Date: Fri, 23 Nov 2018 13:54:00 +0000
Cc: "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Daniel Fett 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [OAUTH-WG] Binding Access Tokens is not enough!
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, 23 Nov 2018 13:54:09 -0000

Thanks for doing this Daniel, I think the proposed text is good.

=E2=80=94 Neil

> On 22 Nov 2018, at 14:42, Daniel Fett  wrote:
>=20
> Hi all,
>=20
> I would like to discuss a text proposal for the security BCP.
>=20
> Background:
>=20
> Yesterday, Neil pointed out the following problem with binding access =
tokens using mTLS or token binding in SPAs:
>=20
> "I am talking about scripts from places like ad servers that are =
usually included via an iframe to enforce the SOP and sandbox them from =
other scripts. If they get access to an access token - e.g. via =
document.referrer or a redirect or some other leak, then they still act =
within the same TLS context as the legitimate client."
>=20
> The problem is that a browser's TLS stack will attach the proof of =
possession no matter which origin started a request.
>=20
> (This seems like a real downside of token binding - why does it not =
have the "same site" option that cookies nowadays have?)
>=20
> I prepared the following addition to the security BCP and would like =
to hear your opinions:
>=20
> "It is important to note that constraining the sender of a token to a =
web browser (using a TLS-based method) does not constrain the origin of =
the script that uses the token (lack of origin binding). In other words, =
if access tokens are used in a browser (as in a single-page application, =
SPA) and the access tokens are sender-constrained using a TLS-based =
method, it must be ensured that origins other than the origin of the SPA =
cannot misuse the TLS-based sender authentication.
>=20
> The problem can be illustrated using an SPA on origin A that uses an =
access token AT that is bound to the TLS connection between the browser =
and the resource server R. If AT leaks to an attacker E, and there is, =
for example, an iframe from E's origin loaded in the web browser, that =
iframe can send a request to origin R using the access token AT. This =
request will contain the proof-of-posession of the (mTLS or token =
binding) key. The resource server R therefore cannot distinguish if a =
request containing a valid access token originates from origin A or =
origin E.
>=20
> If the resource server only accepts the access token in an =
Authorization header, then Cross-Origin Resource Sharing (CORS) will =
protect against this attack by default. If the resource server accepts =
the access tokens in other ways (e.g., as a URL parameter), or if the =
CORS policy of the resource server permits requests by origin E, then =
the TLS-based token binding only provides protection if the browser is =
offline."
>=20
>=20
> The "summary" above this text reads as follows:
>=20
> "If access tokens are sender-constrained to a web browser, the =
resource server MUST ensure that the access token can only be used by =
the origin to which the access token was issued (origin binding). One =
solution for the resource server to accomplish this is to only accept =
the access token in an Authorization header (as described in RFC 6750) =
and to ensure that the active CORS policy prevents third parties from =
sending Authorization headers. See  for =
details."
>=20
> What do you think?
>=20
> -Daniel
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Nov 23 09:16:56 2018
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 582321241F6 for ; Fri, 23 Nov 2018 09:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 MXGj4f9P3UhH for ; Fri, 23 Nov 2018 09:16:52 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 8E5F61292AD for ; Fri, 23 Nov 2018 09:16:52 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id n21so11142385qtl.6 for ; Fri, 23 Nov 2018 09:16:52 -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=Y2m6BoxSd8/d6w2Np2F8agcoSZA1iYPmfYxee+V4G/Q=; b=g7EfcMfIyeE3rF/6qe0wSAbV9bNDluzsZIwueLhKBstQgLox9Cco2PzzRWyEaVmnzj 3X13eK9zokrSmHTy0sZo8oHWfnRnUPu7Eu4+mc1z40irZokI7J97bQ6Mfw9F6TAUzN1u /2AUmq+XFOoOSXP4mhW0hZiJktNOgR/E8F3fy2z1rss/m5jBMw0y5HxGZnfYcZ7xDXPe 0kg3PkstGIaPx0sRBBVIkdB3R9Ncf0HvxUhjeTGaI6aBkRpJ5PxqpH8BE9Ctm96zjNd7 ya740Na0EpGYycHnalr7bcCIuE3joFCCPAzWzVa0WD4iPmHeHv6FFhJieDPjp4RbmW8m XdrQ==
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=Y2m6BoxSd8/d6w2Np2F8agcoSZA1iYPmfYxee+V4G/Q=; b=H3oBj8uLyYSlNIzp2MDE+A9a7NluTvX82B3SpEjuiDMQ2ZwsdrBRgRH8+cvP2tyHcO RLVqQfjwwiXlrNZrVaxuoUa4aeHAmJNEuT9Dh1zuh/DW1UHPBCe0hEfa0G7p88SAraGB PkZ3YqO6YmbAqzM1OrfZyWBL9dj9PlbLz45bt3z8SqwLBnFQOSgxn/wS6E2p8M33Yqvp 3bZpbV/glIaFP5/BSnauyN7jcqOWtLqWTzot/s2hOu9P+GoQgwcuPJvWQ1g40adW3ls5 FKvqhe+Ga7sgzz0hD4ybz+b48eP0QN5RcVpi0rAXpSMxYFz+6yLbYU9VJtoLf/QUcq6y SCwQ==
X-Gm-Message-State: AA+aEWbbbogLVcpLNdqtb4o6Jw9tKzeRTGB4bUgY+qGJtVXzd5I1MjsV I1OZL3weKseZMytW4IbhUwSVppySCYmM2PszZg==
X-Google-Smtp-Source: AFSGD/W+pUwgU/6aOrrIwIjSRXLv9nkKNybNfKILcwe0UDqSNOxDjQwsGIA3cNsqJnH9iYSTKmuinCBF/fwhRvxkJQM=
X-Received: by 2002:aed:2e86:: with SMTP id k6mr14676630qtd.292.1542993411693;  Fri, 23 Nov 2018 09:16:51 -0800 (PST)
MIME-Version: 1.0
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com> <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net> <45488c5d-54c8-a680-dc66-7fd5d4d41a7b@aol.com> 
In-Reply-To: 
From: Reman Child 
Date: Fri, 23 Nov 2018 09:16:40 -0800
Message-ID: 
To: t.broyer@gmail.com
Cc: gffletch=40aol.com@dmarc.ietf.org, oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000031e016057b582644"
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 23 Nov 2018 17:16:54 -0000

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

Thomas, did you test with ITP Debug Mode? If you haven't seen it, this is
how to set it up:
https://webkit.org/blog/8387/itp-debug-mode-in-safari-technology-preview-62=
/

When I tested a couple months ago, the iframe flows were the ones that were
most affected by ITP2 - the hidden iframe token refresh didn't work, and it
seemed like the session management flows would also break (although didn't
test them explicitly). If the domain is marked as a tracker and it's loaded
in an iframe, it will not have access to its first party cookies. This
differs from ITP 1.1, where there was a 1-day window where it would work
before the cookies were purged. Safari did add some new storage methods to
get access to these cookies, but they don't really help with these
non-interactive flows because by design they require user interaction.


On Fri, Nov 23, 2018 at 5:35 AM Thomas Broyer  wrote:

> Just tested my OpenID Connect Session Management implementation with
> Safari 12.0.1 and it works like a charm.
>
> On Thu, Nov 22, 2018 at 8:09 PM George Fletcher  40aol.com@dmarc.ietf.org> wrote:
>
>> My understanding is that cookies are not blocked on redirects
>> (IPT2/Safari) but I haven't done extensive testing. So from a full-page
>> redirect perspective there should be no issues, from a hidden iframe I'm
>> not sure... but I believe it will work.
>>
>>
>> On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
>>
>> Hi George,
>>
>>
>> Am 20.11.2018 um 22:15 schrieb George Fletcher  :
>>
>> OIDC provides a "prompt=3Dnone" mechanism that allows the browser app to=
 request a new token in a hidden iframe. OAuth2 doesn't describe this flow.=
 Note that full authentications of users should NOT happen in iframes due t=
o click-jacking attacks.
>>
>>
>> Does this still work reliably given the limitations imposed by the brows=
er=E2=80=98s 3rd party cookie policies?
>>
>> kind regards,
>> Torsten.
>>
>>
>> _______________________________________________
>> 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
>

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


    Thomas, did you test with ITP Debug =
Mode? If you haven't seen it, this is how to set it up:

    When I tested a couple months ago, =
the iframe flows were the ones that were most affected by ITP2 - the hidden=
 iframe token refresh didn't work, and it seemed like the session manag=
ement flows would also break (although didn't test them explicitly). If=
 the domain is marked as a tracker and it's loaded in an iframe, it wil=
l not have access to its first party cookies. This differs from ITP 1.1, wh=
ere there was a 1-day window where it would work before the cookies were pu=
rged. Safari did add some new storage methods to get access to these cookie=
s, but they don't really help with these non-interactive flows because =
by design they require user interaction.

    On Fri, Nov 23, 2018 at 5:35 =
AM Thomas Broyer <t.broyer@gmail.c=
om> wrote:
    =
Just tested my OpenID Connect Session Management implementation with Safari=
 12.0.1 and it works like a charm.

    =

    On Thu, Nov 22, 2018 at 8:09 PM George Fletcher <gfflet=
ch=3D40aol.co=
m@dmarc.ietf.org> wrote:
    
 =20
   =20
 =20
  
    
    My understanding is that
      cookies are not blocked on redirects (IPT2/Safari) but I haven't =
done
      extensive testing. So from a full-page redirect perspective there
      should be no issues, from a hidden iframe I'm not sure... but I
      believe it will work.

    
    
    
    
    On 11/21/18 11:49 PM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi George,


    
      
    
        
    Am 20.11.2018 um 22:15 schrieb George Fletcher <gffletch@aol.com>:

OIDC provides a "prompt=3Dnone" mechanism that allows the browser=
 app to request a new token in a hidden iframe. OAuth2 doesn't describe=
 this flow. Note that full authentications of users should NOT happen in if=
rames due to click-jacking attacks.

    
      
    
      
    Does this still work reliably given the limitations imposed by the browser=
=E2=80=98s 3rd party cookie policies?

kind regards,
Torsten.
    
    
    
    
    
  
    

_______________________________________________
    
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
    

    

--00000000000031e016057b582644--


From nobody Sun Nov 25 03:55:25 2018
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 086AE12D4F2 for ; Sun, 25 Nov 2018 03:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.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 O-CFXYN2uTJu for ; Sun, 25 Nov 2018 03:55:19 -0800 (PST)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 8BB63124408 for ; Sun, 25 Nov 2018 03:55:19 -0800 (PST)
Received: by mail-io1-xd34.google.com with SMTP id n9so11760495ioh.7 for ; Sun, 25 Nov 2018 03:55:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VVciY5KYAa5fYVpi4gyPfITQjrUT2Dex4GWWXYsZ/pc=; b=yVkdJPJCMFDYx6tyDJ1wZasFKHkxh/qe3gJ68VuphUnE4QFuMV4c7QrJy77o/PWAwd 2y1kb5pTLmviaXP8CvcqJb4QlLNeyDSH2Kl68fyYcdbWMI/Lpr8KobnIztxJKlgAiTZJ AqKCpMaTfC41SfIRidvoM3FAyBynW/Ejasbd9iOvQvIDKAbCuPqnzsbj0rUkD08FSELw U5NxnNI7Y9Q61nNb/iOyK/4PYsvb1mhZxpjJismlaRwSieq9/7CZ2H109GH88WqLUL+7 qAvtFkboOA4wc5XHnVxJfnDsx0lOL9Hl8pVDeUuOTQ8kqzdE3ncUb9S9JsaeP32aZedM WVpQ==
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=VVciY5KYAa5fYVpi4gyPfITQjrUT2Dex4GWWXYsZ/pc=; b=YSma+GGzsIauYKMB1D+1zYGRrWkry31zxmitk+YwMlzBUR8UYcXLOQpf8zAP1AqkYL dGugmraFas1enbbAHuLuZQZpebfYX/E+kJNDAnIHdUfoHMjLAJt1k5cPH7TjABp47YXF lsThvPsgc/IfPJBvAHsVnoHeoZfTgzlVq969G0s2oFwn4nDResSXi1pmG6f4Q1eGoZut RVuseJErpmHfZ+6F3ol1uFeiHQoev6nilbKCjeR/ZljX+RHxgbWkiHme5Hv+fIxQL/I3 uQvcNqL7rVf8CblKjeDnoz4UUFtm85m9Hb6U/NpSm0zuwgMmY8PLZtkImV/AC0Upw4Dx WfeQ==
X-Gm-Message-State: AA+aEWYyGFL0nHxwDjsqSAi88EEZy9I/Eqqe0lHqMS1Ue1zgtjMwa1FE 8hthn97u46W8din8plf6wttczuNqRGQDez+vzgWRWg==
X-Google-Smtp-Source: AFSGD/X3yQFsSNWLwRqRQIj/3nbmeNIlf29VLpjgUb/jyG1Bej7CZCITvJ1gHNZCxMgCTRWiZa4iPo3+DtysbEgsktE=
X-Received: by 2002:a6b:7019:: with SMTP id l25mr18083134ioc.145.1543146918503;  Sun, 25 Nov 2018 03:55:18 -0800 (PST)
MIME-Version: 1.0
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com> 
In-Reply-To: 
From: Hans Zandbelt 
Date: Sun, 25 Nov 2018 12:55:07 +0100
Message-ID: 
To: Torsten Lodderstedt 
Cc: George Fletcher , Michael.Jones=40microsoft.com@dmarc.ietf.org,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000e9fec3057b7be351"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 11:55:24 -0000

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

I strongly support the recommendation of using code instead of implicit. I
do so based on my own experience in the field [1] and stick to that also
after reading the comments and (what I would call) workarounds on this
thread.

Hans.

[1]
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-pag=
e-applications/

On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt 
wrote:

> that=E2=80=99s certainly true, but that might by a web server with static=
 content
> only.
>
> If the server is a real backend, there is even less reasons to use a
> implicit or hybrid. No even a performance gain in comparison to code.
>
> Am 21..11.2018 um 14:24 schrieb George Fletcher  >:
>
> An SPA has a backend because it has to be loaded from somewhere :)
>
> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>
> We had a discussion about this topic on Twitter https://twitter.com/Apl3b=
/status/1064854507606208513
>
> Outcome is POST requires a backend to receive the request so it=E2=80=99s=
 not a viable solution for SPAs.
>
>
> Am 20.11.2018 um 23:29 schrieb John Bradley  :
>
> Post response works OK for server based clients.  I don't think POST work=
s for single page applications.
>
> Basically that would be something more like postmessage between two JS ap=
ps.
>
> Postmessage also has security issues passing a access token and leaking.
>
> Perhaps someone more familiar with SPA can comment on POST.
>
> John B.
>
>
>
> On Tue, Nov 20, 2018, 6:40 PM George Fletcher  Hi Mike,
>
> The Form Post Response Mode keeps the access_token out of the URL, but it=
 doesn't prevent the token from traversing through the browser. So a man-in=
-the-browser attack may be able to intercept the values. It should help wit=
h leakage in logs.
>
> Thanks,
> George
>
> On 11/20/18 4:00 PM, Mike Jones wrote:
>
> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Response Mode=
 https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigat=
e the threats you=E2=80=99re describing below John?  If so, I believe the S=
ecurity Topics draft should say this.
>
>
>
> I believe we owe it to readers to present the complete picture, which is =
why I believe that describing profiles using ID Tokens and the Form Post Re=
sponse Mode are in scope.
>
>
>
>                                                        -- Mike
>
>
>
> From: OAuth   On Behalf O=
f John Bradley
> Sent: Tuesday, November 20, 2018 7:47 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization =
code instead of implicit
>
>
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs o=
r redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say send=
ing it in a redirect is a good security practice.
>
> John B.
>
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
> Hi Mike,
>
> I agree that OIDC hybrid flows offer additional security over the OAuth i=
mplicit grant and are used in the wild. On my slides and in the initial ver=
sion of the new section, we had included the hybrid OIDC flows because of t=
heir known token injection countermeasures.
>
> I nevertheless feel very uncomfortable to recommend those flows and any f=
low issuing access tokens in the front channel. In the course of the detail=
ed review of the new text we realized two issues:
>
> 1) Since the access token is exposed in the URL, such flows possess a sig=
nificantly higher risk to leak the access token (e.g. through browser histo=
ry, open redirection and even referrer headers) than the code grant.
> 2) There is no viable way to sender constrain access tokens issued in the=
 front channel. Given the WG decided to recommend use of sender constraint =
tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#sec=
tion-2..2), it seems contradictory to recommend response types not supporti=
ng such an approach.
>
> kind regards,
> Torsten.
>
> Am 19.11.2018 um 23:13 schrieb Mike Jones  :
>
> This description of the situation is an oversimplification..  OpenID Conn=
ect secures the implicit flow against token injection attacks by including =
the at_hash (access token hash) in the ID Token, enabling the client to val=
idate that the access token was created by the issuer in the ID Token (whic=
h is also the OAuth Issuer, as described in RFC 8414).  (Note that this mit=
igation was described in draft-ietf-oauth-mix-up-mitigation.)
>
> Given the prevalence of this known-good solution for securing the implici=
t flow, I would request that the draft be updated to describe this mitigati=
on.  At the same time, I=E2=80=99m fine with the draft recommending the cod=
e flow over the implicit flow when this mitigation is not used.
>
>                                                                 Thank you=
,
>                                                                 -- Mike
>
> From: OAuth   On Behalf O=
f Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth  
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code=
 instead of implicit
>
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion tha=
t it is not possible to adequately secure the implicit flow against token i=
njection since potential solutions like token binding or JARM are in an ear=
ly stage of adoption. For this reason, and since CORS allows browser-based =
apps to send requests to the token endpoint, Torsten suggested to use the a=
uthorization code instead of the implicit grant in call cases in his presen=
tation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oa=
uth-sessb-draft-ietf-oauth-security-topics-01).
>
> A hum in the room at IETF#103 concluded strong support for his recommenda=
tions. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are conf=
idential and may also be privileged. If you are not the intended recipient,=
 please notify the sender immediately and do not disclose the contents to a=
ny other person, use it for any purpose, or store or copy the information i=
n any medium. Thank you.
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> 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
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

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


    I strongly support the recommendation of =
using code instead of implicit. I do so based on my own experience in the f=
ield [1] and stick to that also after reading the comments and (what I woul=
d call) workarounds on this thread.

    Hans.


    On Thu, Nov 22, 2018 at 5:45 AM Torsten Loddersted=
t <torsten@lodderstedt.net> wrote:
    
 =20
   =20
 =20
 =20
    An SPA has a backend
      because it has to be loaded from somewhere :)
    
    
    
    
    On 11/21/18 3:47 AM=
, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    We had a discussion about this topic on Twitter https://twitter.com/Apl3b/stat=
us/1064854507606208513

Outcome is POST requires a backend to receive the request so it=E2=80=99s n=
ot a viable solution for SPAs.


    
      
    
        
    Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.com>:

Post response works OK for server based clients.  I don't think POST wo=
rks for single page applications. =20

Basically that would be something more like postmessage between two JS apps=
. =20

Postmessage also has security issues passing a access token and leaking. =
=20

Perhaps someone more familiar with SPA can comment on POST. =20

John B.=20



On Tue, Nov 20, 2018, 6:40 PM George Fletcher <gffletch@aol.com wrote:
Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but it d=
oesn't prevent the token from traversing through the browser. So a man-=
in-the-browser attack may be able to intercept the values. It should help w=
ith leakage in logs.

Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:

    
        
    
          
    Next question =E2=80=93 doesn=E2=80=99t using the Form Post =
Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_=
0.html mitigate the threats you=E2=80=99re describing below John?  If s=
o, I believe the Security Topics draft should say this.

=20

I believe we owe it to readers to present the complete picture, which is wh=
y I believe that describing profiles using ID Tokens and the Form Post Resp=
onse Mode are in scope.

=20

                                                       -- Mike

=20

From: OAuth <oauth-bounces@ietf.or=
g> On Behalf Of John Bradley
Sent: Tuesday, November 20, 2018 7:47 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization co=
de instead of implicit

=20

Yes the at_hash protects the client from accepting an injected AT.=20

Unfortunately it doesn't do anything to protect against leakage in logs=
 or redirects.

So without the AT using some sort of POP mechanism it is hard to say sendin=
g it in a redirect is a good security practice.

John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike,=20
=20
I agree that OIDC hybrid flows offer additional security over the OAuth imp=
licit grant and are used in the wild. On my slides and in the initial versi=
on of the new section, we had included the hybrid OIDC flows because of the=
ir known token injection countermeasures.
=20
I nevertheless feel very uncomfortable to recommend those flows and any flo=
w issuing access tokens in the front channel. In the course of the detailed=
 review of the new text we realized two issues:=20
=20
1) Since the access token is exposed in the URL, such flows possess a signi=
ficantly higher risk to leak the access token (e.g. through browser history=
, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the f=
ront channel. Given the WG decided to recommend use of sender constraint to=
kens (https://tools.ietf.org/html/draft-ietf-oauth-security-topic=
s-09#section-2..2), it seems contradictory to recommend response types =
not supporting such an approach.=20
=20
kind regards,
Torsten.=20
=20
Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf=
.org>:
=20
This description of the situation is an oversimplification..  OpenID Connec=
t secures the implicit flow against token injection attacks by including th=
e at_hash (access token hash) in the ID Token, enabling the client to valid=
ate that the access token was created by the issuer in the ID Token (which =
is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitig=
ation was described in draft-ietf-oauth-mix-up-mitigation.)
=20
Given the prevalence of this known-good solution for securing the implicit =
flow, I would request that the draft be updated to describe this mitigation=
.  At the same time, I=E2=80=99m fine with the draft recommending the code =
flow over the implicit flow when this mitigation is not used.
=20
                                                                Thank you,
                                                                -- Mike
=20
From: OAuth <oauth-bounces@ietf.or=
g> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code i=
nstead of implicit
=20
Hi all,
=20
The authors of the OAuth Security Topics draft came to the conclusion that =
it is not possible to adequately secure the implicit flow against token inj=
ection since potential solutions like token binding or JARM are in an early=
 stage of adoption. For this reason, and since CORS allows browser-based ap=
ps to send requests to the token endpoint, Torsten suggested to use the aut=
horization code instead of the implicit grant in call cases in his presenta=
tion (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-dra=
ft-ietf-oauth-security-topics-01).
=20
A hum in the room at IETF#103 concluded strong support for his recommendati=
ons. We would like to confirm the discussion on the list.
=20
Please provide a response by December 3rd.
=20
Ciao
Hannes & Rifaat
=20
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth
=20



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


_______________________________________________
OAuth mailing list

OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth

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

    
      
    
      
    
    
    
    
    
 =20


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



    -- 
    <=
a href=3D"mailto:hans.zandbelt@zmartzone.eu" target=3D"_blank">hans.zandbel=
t@zmartzone.eu
    ZmartZone IAM - www.zmartzone.eu
    <=
/div>
    

--000000000000e9fec3057b7be351--


From nobody Sun Nov 25 09:33:04 2018
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 2529F12EB11 for ; Sun, 25 Nov 2018 09:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 DhmIZhHPPJNA for ; Sun, 25 Nov 2018 09:32:58 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (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 D026B12896A for ; Sun, 25 Nov 2018 09:32:57 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gQyH8-00081x-8X for oauth@ietf.org; Sun, 25 Nov 2018 18:32:54 +0100
From: Torsten Lodderstedt 
Content-Type: multipart/signed; boundary="Apple-Mail=_3FED5829-2170-4DFD-BD70-2C61E36E8DEE"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Sun, 25 Nov 2018 18:32:53 +0100
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>  
To: "oauth@ietf.org" 
In-Reply-To: 
Message-Id: <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 17:33:02 -0000

--Apple-Mail=_3FED5829-2170-4DFD-BD70-2C61E36E8DEE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,=20

I would like to state again what the proposal of the authors of the =
Security BCP is:

Here is the respective text from the draft:

=E2=80=94=E2=80=94

2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2, Section =
3.3, and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.
=E2=80=94=E2=80=94

In my observation, discouraging implicit seems to be the less =
controversial issue.

=E2=80=9Eor any other response type causing the authorization server to =
issue an access token in the authorization response.=E2=80=9C in the 3rd =
paragraph caused discussions because it suggests to discourage =
developers from using ANY response type issuing access tokens in the =
authorization response. This includes OIDC=E2=80=99s response types =
=E2=80=9Etoken id_token=E2=80=9C, =E2=80=9Ecode token=E2=80=9C & =E2=80=9E=
code token id_token=E2=80=9C, where at least  =E2=80=9Etoken id_token=E2=80=
=9C is used in the wild to implement SPAs.

Why did we come up with this proposal given at least =E2=80=9Etoken =
id_token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect =
against injection?

Two reasons:=20

1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained =
tokens. Also use of refresh tokens to frequently issue new live-time and =
privilege restricted access tokens is not supported. =E2=80=9Ecode token =
id_token=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce=
 for achieving the same goal.

2) Protection against token leakage is rather thin and fragile. There is =
just a single line of defense (CSP, open redirection prevention, browser =
history manipulation) implemented by the client.=20

Daniel and I collected some more information and argument at =
https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that =
you might like to give a read.

My conclusion after 2 weeks of intensive discussions with SPA developers =
(mostly on twitter): code+pkce is the more secure, simpler, and more =
versatile approach to (also) implement SPAs. I prefer to approach =
developers with a clean and robust message instead of a lengthy =
description of what needs to go right in order to secure a SPA using =
OAuth. That=E2=80=99s why I think code+pkce should be the recommendation =
of our working group.

So please vote in favor of our proposal. I think that=E2=80=99s a huge =
improvement for OAuth.

kind regards,=20
Torsten.=20


> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt =
:
>=20
> I strongly support the recommendation of using code instead of =
implicit. I do so based on my own experience in the field [1] and stick =
to that also after reading the comments and (what I would call) =
workarounds on this thread.
>=20
> Hans.
>=20
> [1] =
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-pa=
ge-applications/
>=20
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt =
 wrote:
> that=E2=80=99s certainly true, but that might by a web server with =
static content only.
>=20
> If the server is a real backend, there is even less reasons to use a =
implicit or hybrid. No even a performance gain in comparison to code.
>=20
> Am 21..11.2018 um 14:24 schrieb George Fletcher :
>=20
>> An SPA has a backend because it has to be loaded from somewhere :)
>>=20
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>>> We had a discussion about this topic on Twitter =
https://twitter.com/Apl3b/status/1064854507606208513
>>>=20
>>>=20
>>> Outcome is POST requires a backend to receive the request so it=E2=80=99=
s not a viable solution for SPAs.
>>>=20
>>>=20
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
>>>> :
>>>>=20
>>>> Post response works OK for server based clients.  I don't think =
POST works for single page applications. =20
>>>>=20
>>>> Basically that would be something more like postmessage between two =
JS apps. =20
>>>>=20
>>>> Postmessage also has security issues passing a access token and =
leaking. =20
>>>>=20
>>>> Perhaps someone more familiar with SPA can comment on POST. =20
>>>>=20
>>>> John B.=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
>>>> gffletch@aol.com
>>>>  wrote:
>>>> Hi Mike,
>>>>=20
>>>> The Form Post Response Mode keeps the access_token out of the URL, =
but it doesn't prevent the token from traversing through the browser. So =
a man-in-the-browser attack may be able to intercept the values. It =
should help with leakage in logs.
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>>>>=20
>>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post =
Response Mode =
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>  mitigate the threats you=E2=80=99re describing below John?  If =
so, I believe the Security Topics draft should say this.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> I believe we owe it to readers to present the complete picture, =
which is why I believe that describing profiles using ID Tokens and the =
Form Post Response Mode are in scope.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>                                                        -- Mike
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> From: OAuth=20
>>>>> 
>>>>>  On Behalf Of John Bradley
>>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>>>>> To:=20
>>>>> oauth@ietf.org
>>>>>=20
>>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Yes the at_hash protects the client from accepting an injected AT.=20=

>>>>>=20
>>>>> Unfortunately it doesn't do anything to protect against leakage in =
logs or redirects.
>>>>>=20
>>>>> So without the AT using some sort of POP mechanism it is hard to =
say sending it in a redirect is a good security practice.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>>>>=20
>>>>> Hi Mike,=20
>>>>> =20
>>>>> I agree that OIDC hybrid flows offer additional security over the =
OAuth implicit grant and are used in the wild. On my slides and in the =
initial version of the new section, we had included the hybrid OIDC =
flows because of their known token injection countermeasures.
>>>>> =20
>>>>> I nevertheless feel very uncomfortable to recommend those flows =
and any flow issuing access tokens in the front channel. In the course =
of the detailed review of the new text we realized two issues:=20
>>>>> =20
>>>>> 1) Since the access token is exposed in the URL, such flows =
possess a significantly higher risk to leak the access token (e.g. =
through browser history, open redirection and even referrer headers) =
than the code grant.
>>>>> 2) There is no viable way to sender constrain access tokens issued =
in the front channel. Given the WG decided to recommend use of sender =
constraint tokens (
>>>>> =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.=
.2
>>>>> ), it seems contradictory to recommend response types not =
supporting such an approach.=20
>>>>> =20
>>>>> kind regards,
>>>>> Torsten.=20
>>>>> =20
>>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones=20
>>>>> 
>>>>> :
>>>>> =20
>>>>> This description of the situation is an oversimplification..  =
OpenID Connect secures the implicit flow against token injection attacks =
by including the at_hash (access token hash) in the ID Token, enabling =
the client to validate that the access token was created by the issuer =
in the ID Token (which is also the OAuth Issuer, as described in RFC =
8414).  (Note that this mitigation was described in =
draft-ietf-oauth-mix-up-mitigation.)
>>>>> =20
>>>>> Given the prevalence of this known-good solution for securing the =
implicit flow, I would request that the draft be updated to describe =
this mitigation.  At the same time, I=E2=80=99m fine with the draft =
recommending the code flow over the implicit flow when this mitigation =
is not used.
>>>>> =20
>>>>>                                                                 =
Thank you,
>>>>>                                                                 -- =
Mike
>>>>> =20
>>>>> From: OAuth=20
>>>>> 
>>>>>  On Behalf Of Hannes Tschofenig
>>>>> Sent: Monday, November 19, 2018 2:34 AM
>>>>> To: oauth=20
>>>>> 
>>>>>=20
>>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
>>>>> =20
>>>>> Hi all,
>>>>> =20
>>>>> The authors of the OAuth Security Topics draft came to the =
conclusion that it is not possible to adequately secure the implicit =
flow against token injection since potential solutions like token =
binding or JARM are in an early stage of adoption. For this reason, and =
since CORS allows browser-based apps to send requests to the token =
endpoint, Torsten suggested to use the authorization code instead of the =
implicit grant in call cases in his presentation (seehttps://
>>>>> =
datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ie=
tf-oauth-security-topics-01
>>>>> ).
>>>>> =20
>>>>> A hum in the room at IETF#103 concluded strong support for his =
recommendations. We would like to confirm the discussion on the list.
>>>>> =20
>>>>> Please provide a response by December 3rd.
>>>>> =20
>>>>> Ciao
>>>>> Hannes & Rifaat
>>>>> =20
>>>>> IMPORTANT NOTICE: The contents of this email and any attachments =
are confidential and may also be privileged. If you are not the intended =
recipient, please 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.
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> --=20
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu


--Apple-Mail=_3FED5829-2170-4DFD-BD70-2C61E36E8DEE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjUxNzMyNTNaMC8GCSqGSIb3DQEJBDEiBCA7
dKry+BYeG3L76WH/CxAUjUKVVJJrkWGyvF7G0Iq7JjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAWDqFW+bPvJAODy6UT3D060VT
edndqihM7WU683z7ySxyyM9GSQrfsZ8AH2QmbGmZ+oCpCdxZWwFKLZfhpUiftDxa0dsw4tRG/u5l
vS1IhxD84Bf10NBYENxXydZdYSwBSQW69NHx0zaPUshvHrFRGnubTzO8HRnSlZIPD7gG2hkzQ5we
7vDrFQsvYBaJEGPeVaAb2l5vffvSvnupYKosOZ23z3c00HqvUF4Ytd1c8760XH+WcjfLX0IEaFRw
Z+tG668saBbpXvSDs/47EigxEvq0093Gs0z5oPRCjQcKFKwVjqyc8leVrzysw3G5EBkI9L85A5VN
HScC8EML/rB0nAAAAAAAAA==
--Apple-Mail=_3FED5829-2170-4DFD-BD70-2C61E36E8DEE--


From nobody Sun Nov 25 10:23:00 2018
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 AE3501288EB for ; Sun, 25 Nov 2018 10:22:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cTW88zm8v0y for ; Sun, 25 Nov 2018 10:22:56 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0: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 5691412D84C for ; Sun, 25 Nov 2018 10:22:56 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id b5so24228484iti.2 for ; Sun, 25 Nov 2018 10:22:56 -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=VdWCRf+4iNUxg99UqU1EiJVplXPjcjWy35gIsVPjk/o=; b=u8ZZXVkp169ymTaESR7m3zizsh1PZg0Z1IsOYO3rZF9LdojtvazSB5UIuIb73yTNaF ucloTA3gvuKt9MDT0CybRyxqfTDItjWCWj6l265PVbtoBeH+ma/XeuYgzEbH3rTLJ4/R Fn2kCD5AIQw3AIrlvWBvjeF+Pni4Tvlrg7zMalxL2jGr9Ob0hKPX7ry1HKxC/xRVzS6X 1w7VVWX4hCIogOCG8xEDQ5Ur4pXvfFcwh044qQbytDev7uvS+Kruh7kLIdtiq1LyxuHo Zu3K12/X/4SLDSDKNnTZRem9WurwaV6idTxLY4etkH9QIg1DHzJGD1ZzR4xoC7SpS8yV GVkw==
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=VdWCRf+4iNUxg99UqU1EiJVplXPjcjWy35gIsVPjk/o=; b=abT4wW42QXGX5fGYxZnI7Z1QFtw00CCM2xNvYZPoH25k3FHbabAgPp7jMpa+aEsU1O HVrk5GFx1VoRRqiAKw5503McCQ6JjGj+tYm8+sWK8yxZ5Q9rbNuKRLd1ZOFyYgj9o7gP w281Kap+mt8ydC+IJIRtIJanO8zEUCEJR66pSE+JO7atdGewdik7m7DDRvVvYuLCWQY8 EEOF3E3ZDwNwT/yTgR1HOLi2Ha/3fOpHvCy/uLjxO6E/S/0/0ADNZHH7pBIky9Bz5tne 3MduldOhIfepexvJwAoq7S+EYbvVuseehIYyaYWuo36hMML4Q0suOUE+8ZTL8XOP6tuu I1Yg==
X-Gm-Message-State: AA+aEWY6ywLshmIZ3d9doEZxjxCb6X61Qs4f5gvEDGvCukM7okaj80j1 iN8tomNQGE0v/I8uUu1CEZUsqtS1UtPZSBjvkcL10Q==
X-Google-Smtp-Source: AFSGD/WpgWvA/Za50wLSkiIr+hN9g17MOsCv3+O3awfRbEJThBOlT4l9bUu5yabRtNGNv1AbyFWvrJw9XvMI2h29jB4=
X-Received: by 2002:a24:76d0:: with SMTP id z199mr8648034itb.165.1543170175508;  Sun, 25 Nov 2018 10:22:55 -0800 (PST)
MIME-Version: 1.0
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
In-Reply-To: <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
From: Rifaat Shekh-Yusef 
Date: Sun, 25 Nov 2018 13:22:44 -0500
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000023a94d057b814e96"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 18:23:00 -0000

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

Hi Torsten,

I am assuming that these recommendations are mainly for Public Clients, not
Confidential Clients; is that correct?

Regards,
 Rifaat


On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi all,
>
> I would like to state again what the proposal of the authors of the
> Security BCP is:
>
> Here is the respective text from the draft:
>
> =E2=80=94=E2=80=94
>
> 2.1.2.  Implicit Grant
>
>    The implicit grant (response type "token") and other response types
>    causing the authorization server to issue access tokens in the
>    authorization response are vulnerable to access token leakage and
>    access token replay as described in Section 3.1, Section 3.2, Section
> 3.3, and Section 3.6.
>
>    Moreover, no viable mechanism exists to cryptographically bind access
>    tokens issued in the authorization response to a certain client as it
>    is recommended in Section 2.2.  This makes replay detection for such
>    access tokens at resource servers impossible.
>
>    In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant or any other response type causing the authorization server to
>    issue an access token in the authorization response.
>
>    Clients SHOULD instead use the response type "code" (aka
>    authorization code grant type) as specified in Section 2.1.1 or any
>    other response type that causes the authorization server to issue
>    access tokens in the token response.  This allows the authorization
>    server to detect replay attempts and generally reduces the attack
>    surface since access tokens are not exposed in URLs.  It also allows
>    the authorization server to sender-constrain the issued tokens.
> =E2=80=94=E2=80=94
>
> In my observation, discouraging implicit seems to be the less
> controversial issue.
>
> =E2=80=9Eor any other response type causing the authorization server to i=
ssue an
> access token in the authorization response.=E2=80=9C in the 3rd paragraph=
 caused
> discussions because it suggests to discourage developers from using ANY
> response type issuing access tokens in the authorization response. This
> includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=9C, =
=E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token
> id_token=E2=80=9C, where at least  =E2=80=9Etoken id_token=E2=80=9C is us=
ed in the wild to
> implement SPAs.
>
> Why did we come up with this proposal given at least =E2=80=9Etoken id_to=
ken=E2=80=9C &
> =E2=80=9Ecode token id_token=E2=80=9C protect against injection?
>
> Two reasons:
>
> 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained t=
okens. Also use
> of refresh tokens to frequently issue new live-time and privilege
> restricted access tokens is not supported. =E2=80=9Ecode token id_token=
=E2=80=9C seems more
> complex than just =E2=80=9Ecode=E2=80=9C+pkce for achieving the same goal=
.
>
> 2) Protection against token leakage is rather thin and fragile. There is
> just a single line of defense (CSP, open redirection prevention, browser
> history manipulation) implemented by the client.
>
> Daniel and I collected some more information and argument at
> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you
> might like to give a read.
>
> My conclusion after 2 weeks of intensive discussions with SPA developers
> (mostly on twitter): code+pkce is the more secure, simpler, and more
> versatile approach to (also) implement SPAs. I prefer to approach
> developers with a clean and robust message instead of a lengthy descripti=
on
> of what needs to go right in order to secure a SPA using OAuth. That=E2=
=80=99s why
> I think code+pkce should be the recommendation of our working group.
>
> So please vote in favor of our proposal. I think that=E2=80=99s a huge im=
provement
> for OAuth.
>
> kind regards,
> Torsten.
>
>
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt  >:
> >
> > I strongly support the recommendation of using code instead of implicit=
.
> I do so based on my own experience in the field [1] and stick to that als=
o
> after reading the comments and (what I would call) workarounds on this
> thread.
> >
> > Hans.
> >
> > [1]
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-p=
age-applications/
> >
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> > that=E2=80=99s certainly true, but that might by a web server with stat=
ic
> content only.
> >
> > If the server is a real backend, there is even less reasons to use a
> implicit or hybrid. No even a performance gain in comparison to code.
> >
> > Am 21..11.2018 um 14:24 schrieb George Fletcher :
> >
> >> An SPA has a backend because it has to be loaded from somewhere :)
> >>
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
> >>> We had a discussion about this topic on Twitter
> https://twitter.com/Apl3b/status/1064854507606208513
> >>>
> >>>
> >>> Outcome is POST requires a backend to receive the request so it=E2=80=
=99s not
> a viable solution for SPAs.
> >>>
> >>>
> >>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
> >>>> :
> >>>>
> >>>> Post response works OK for server based clients.  I don't think POST
> works for single page applications.
> >>>>
> >>>> Basically that would be something more like postmessage between two
> JS apps.
> >>>>
> >>>> Postmessage also has security issues passing a access token and
> leaking.
> >>>>
> >>>> Perhaps someone more familiar with SPA can comment on POST.
> >>>>
> >>>> John B.
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
> >>>> gffletch@aol.com
> >>>>  wrote:
> >>>> Hi Mike,
> >>>>
> >>>> The Form Post Response Mode keeps the access_token out of the URL,
> but it doesn't prevent the token from traversing through the browser. So =
a
> man-in-the-browser attack may be able to intercept the values. It should
> help with leakage in logs.
> >>>>
> >>>> Thanks,
> >>>> George
> >>>>
> >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
> >>>>
> >>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Respons=
e Mode
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> >>>>>  mitigate the threats you=E2=80=99re describing below John?  If so,=
 I
> believe the Security Topics draft should say this.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I believe we owe it to readers to present the complete picture,
> which is why I believe that describing profiles using ID Tokens and the
> Form Post Response Mode are in scope.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                        -- Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: OAuth
> >>>>> 
> >>>>>  On Behalf Of John Bradley
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
> >>>>> To:
> >>>>> oauth@ietf.org
> >>>>>
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
> >>>>>
> >>>>>
> >>>>>
> >>>>> Yes the at_hash protects the client from accepting an injected AT.
> >>>>>
> >>>>> Unfortunately it doesn't do anything to protect against leakage in
> logs or redirects.
> >>>>>
> >>>>> So without the AT using some sort of POP mechanism it is hard to sa=
y
> sending it in a redirect is a good security practice.
> >>>>>
> >>>>> John B.
> >>>>>
> >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
> >>>>>
> >>>>> Hi Mike,
> >>>>>
> >>>>> I agree that OIDC hybrid flows offer additional security over the
> OAuth implicit grant and are used in the wild. On my slides and in the
> initial version of the new section, we had included the hybrid OIDC flows
> because of their known token injection countermeasures.
> >>>>>
> >>>>> I nevertheless feel very uncomfortable to recommend those flows and
> any flow issuing access tokens in the front channel. In the course of the
> detailed review of the new text we realized two issues:
> >>>>>
> >>>>> 1) Since the access token is exposed in the URL, such flows possess
> a significantly higher risk to leak the access token (e.g. through browse=
r
> history, open redirection and even referrer headers) than the code grant.
> >>>>> 2) There is no viable way to sender constrain access tokens issued
> in the front channel. Given the WG decided to recommend use of sender
> constraint tokens (
> >>>>>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2=
...2
> >>>>> ), it seems contradictory to recommend response types not supportin=
g
> such an approach.
> >>>>>
> >>>>> kind regards,
> >>>>> Torsten.
> >>>>>
> >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones
> >>>>> 
> >>>>> :
> >>>>>
> >>>>> This description of the situation is an oversimplification..  OpenI=
D
> Connect secures the implicit flow against token injection attacks by
> including the at_hash (access token hash) in the ID Token, enabling the
> client to validate that the access token was created by the issuer in the
> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (No=
te
> that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.=
)
> >>>>>
> >>>>> Given the prevalence of this known-good solution for securing the
> implicit flow, I would request that the draft be updated to describe this
> mitigation.  At the same time, I=E2=80=99m fine with the draft recommendi=
ng the
> code flow over the implicit flow when this mitigation is not used.
> >>>>>
> >>>>>
>  Thank you,
> >>>>>                                                                 --
> Mike
> >>>>>
> >>>>> From: OAuth
> >>>>> 
> >>>>>  On Behalf Of Hannes Tschofenig
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
> >>>>> To: oauth
> >>>>> 
> >>>>>
> >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorizatio=
n
> code instead of implicit
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> The authors of the OAuth Security Topics draft came to the
> conclusion that it is not possible to adequately secure the implicit flow
> against token injection since potential solutions like token binding or
> JARM are in an early stage of adoption. For this reason, and since CORS
> allows browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (seehttps://
> >>>>>
> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-i=
etf-oauth-security-topics-01
> >>>>> ).
> >>>>>
> >>>>> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> >>>>>
> >>>>> Please provide a response by December 3rd.
> >>>>>
> >>>>> Ciao
> >>>>> Hannes & Rifaat
> >>>>>
> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments ar=
e
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>>
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> 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
> >
> >
> > --
> > hans.zandbelt@zmartzone.eu
> > ZmartZone IAM - www.zmartzone.eu
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    Hi Torsten,

    I am assuming that these re=
commendations are mainly for Public Clients, not Confidential Clients; is t=
hat=C2=A0correct?

    Regards,
    =C2=A0Rifaat<=
/div>


    O=
n Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi all, 
    

    
I would like to state again what the proposal of the authors of the Securit=
y BCP is:
    

    
Here is the respective text from the draft:
    

    
=E2=80=94=E2=80=94
    

    
2.1.2.=C2=A0 Implicit Grant
    

    
=C2=A0 =C2=A0The implicit grant (response type "token") and other=
 response types
    
=C2=A0 =C2=A0causing the authorization server to issue access tokens in the=

    
=C2=A0 =C2=A0authorization response are vulnerable to access token leakage =
and
    
=C2=A0 =C2=A0access token replay as described in Section 3.1, Section 3.2, =
Section 3.3, and Section 3.6.
    

    
=C2=A0 =C2=A0Moreover, no viable mechanism exists to cryptographically bind=
 access
    
=C2=A0 =C2=A0tokens issued in the authorization response to a certain clien=
t as it
    
=C2=A0 =C2=A0is recommended in Section 2.2.=C2=A0 This makes replay detecti=
on for such
    
=C2=A0 =C2=A0access tokens at resource servers impossible.
    

    
=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the imp=
licit
    
=C2=A0 =C2=A0grant or any other response type causing the authorization ser=
ver to
    
=C2=A0 =C2=A0issue an access token in the authorization response.
    

    
=C2=A0 =C2=A0Clients SHOULD instead use the response type "code" =
(aka
    
=C2=A0 =C2=A0authorization code grant type) as specified in Section 2.1.1 o=
r any
    
=C2=A0 =C2=A0other response type that causes the authorization server to is=
sue
    
=C2=A0 =C2=A0access tokens in the token response.=C2=A0 This allows the aut=
horization
    
=C2=A0 =C2=A0server to detect replay attempts and generally reduces the att=
ack
    
=C2=A0 =C2=A0surface since access tokens are not exposed in URLs.=C2=A0 It =
also allows
    
=C2=A0 =C2=A0the authorization server to sender-constrain the issued tokens=
.
    
=E2=80=94=E2=80=94
    

    
In my observation, discouraging implicit seems to be the less controversial=
 issue.
    

    
=E2=80=9Eor any other response type causing the authorization server to iss=
ue an access token in the authorization response.=E2=80=9C in the 3rd parag=
raph caused discussions because it suggests to discourage developers from u=
sing ANY response type issuing access tokens in the authorization response.=
 This includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=
=9C, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=
=9C, where at least=C2=A0 =E2=80=9Etoken id_token=E2=80=9C is used in the w=
ild to implement SPAs.
    

    
Why did we come up with this proposal given at least =E2=80=9Etoken id_toke=
n=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against inje=
ction?
    

    
Two reasons: 
    

    
1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained tok=
ens. Also use of refresh tokens to frequently issue new live-time and privi=
lege restricted access tokens is not supported. =E2=80=9Ecode token id_toke=
n=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce for ach=
ieving the same goal.
    

    
2) Protection against token leakage is rather thin and fragile. There is ju=
st a single line of defense (CSP, open redirection prevention, browser hist=
ory manipulation) implemented by the client. 
    

    
Daniel and I collected some more information and argument at https://github.com/tlodderstedt/oauth2_spa/blob/ma=
ster/README.md that you might like to give a read.
    

    
My conclusion after 2 weeks of intensive discussions with SPA developers (m=
ostly on twitter): code+pkce is the more secure, simpler, and more versatil=
e approach to (also) implement SPAs. I prefer to approach developers with a=
 clean and robust message instead of a lengthy description of what needs to=
 go right in order to secure a SPA using OAuth. That=E2=80=99s why I think =
code+pkce should be the recommendation of our working group.
    

    
So please vote in favor of our proposal. I think that=E2=80=99s a huge impr=
ovement for OAuth.
    

    
kind regards, 
    
Torsten. 
    

    

    
> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu&g=
t;:
    
> 
    
> I strongly support the recommendation of using code instead of implici=
t. I do so based on my own experience in the field [1] and stick to that al=
so after reading the comments and (what I would call) workarounds on this t=
hread.
    
> 
    
> Hans.
    
> 
    
> [1] h=
ttps://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page=
-applications/
    
> 
    
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <torsten@lodderstedt.net&=
gt; wrote:
    
> that=E2=80=99s certainly true, but that might by a web server with sta=
tic content only.
    
> 
    
> If the server is a real backend, there is even less reasons to use a i=
mplicit or hybrid. No even a performance gain in comparison to code.
    
> 
    
> Am 21..11.2018 um 14:24 schrieb George Fletcher <gffletch@aol.com>:
    
> 
    
>> An SPA has a backend because it has to be loaded from somewhere :)=

    
>> 
    
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
    
>>> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513
    
>>> 
    
>>> 
    
>>> Outcome is POST requires a backend to receive the request so i=
t=E2=80=99s not a viable solution for SPAs.
    
>>> 
    
>>> 
    
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.com>
    
>>>> :
    
>>>> 
    
>>>> Post response works OK for server based clients.=C2=A0 I d=
on't think POST works for single page applications.=C2=A0 
    
>>>> 
    
>>>> Basically that would be something more like postmessage be=
tween two JS apps.=C2=A0 
    
>>>> 
    
>>>> Postmessage also has security issues passing a access toke=
n and leaking.=C2=A0 
    
>>>> 
    
>>>> Perhaps someone more familiar with SPA can comment on POST=
.=C2=A0 
    
>>>> 
    
>>>> John B. 
    
>>>> 
    
>>>> 
    
>>>> 
    
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
    
>>>> gffl=
etch@aol.com
    
>>>>=C2=A0 wrote:
    
>>>> Hi Mike,
    
>>>> 
    
>>>> The Form Post Response Mode keeps the access_token out of =
the URL, but it doesn't prevent the token from traversing through the b=
rowser. So a man-in-the-browser attack may be able to intercept the values.=
 It should help with leakage in logs.
    
>>>> 
    
>>>> Thanks,
    
>>>> George
    
>>>> 
    
>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
    
>>>> 
    
>>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form=
 Post Response Mode https://openid=
.net/specs/oauth-v2-form-post-response-mode-1_0.html
    
>>>>>=C2=A0 mitigate the threats you=E2=80=99re describing b=
elow John?=C2=A0 If so, I believe the Security Topics draft should say this=
.
    
>>>>> 
    
>>>>>=C2=A0 
    
>>>>> 
    
>>>>> I believe we owe it to readers to present the complete=
 picture, which is why I believe that describing profiles using ID Tokens a=
nd the Form Post Response Mode are in scope.
    
>>>>> 
    
>>>>>=C2=A0 
    
>>>>> 
    
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike<=
br>
>>>>> 
    
>>>>>=C2=A0 
    
>>>>> 
    
>>>>> From: OAuth 
    
>>>>> <oauth-bounces@ietf.org>
    
>>>>>=C2=A0 On Behalf Of John Bradley
    
>>>>> Sent: Tuesday, November 20, 2018 7:47 AM
    
>>>>> To: 
    
>>>>> oa=
uth@ietf.org
    
>>>>> 
    
>>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
>>>>> 
    
>>>>>=C2=A0 
    
>>>>> 
    
>>>>> Yes the at_hash protects the client from accepting an =
injected AT. 
    
>>>>> 
    
>>>>> Unfortunately it doesn't do anything to protect ag=
ainst leakage in logs or redirects.
    
>>>>> 
    
>>>>> So without the AT using some sort of POP mechanism it =
is hard to say sending it in a redirect is a good security practice.
    
>>>>> 
    
>>>>> John B.
    
>>>>> 
    
>>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
    
>>>>> 
    
>>>>> Hi Mike, 
    
>>>>>=C2=A0 
    
>>>>> I agree that OIDC hybrid flows offer additional securi=
ty over the OAuth implicit grant and are used in the wild. On my slides and=
 in the initial version of the new section, we had included the hybrid OIDC=
 flows because of their known token injection countermeasures.
    
>>>>>=C2=A0 
    
>>>>> I nevertheless feel very uncomfortable to recommend th=
ose flows and any flow issuing access tokens in the front channel. In the c=
ourse of the detailed review of the new text we realized two issues: 
    
>>>>>=C2=A0 
    
>>>>> 1) Since the access token is exposed in the URL, such =
flows possess a significantly higher risk to leak the access token (e.g. th=
rough browser history, open redirection and even referrer headers) than the=
 code grant.
    
>>>>> 2) There is no viable way to sender constrain access t=
okens issued in the front channel. Given the WG decided to recommend use of=
 sender constraint tokens (
    
>>>>> ht=
tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2=

    
>>>>> ), it seems contradictory to recommend response types =
not supporting such an approach. 
    
>>>>>=C2=A0 
    
>>>>> kind regards,
    
>>>>> Torsten. 
    
>>>>>=C2=A0 
    
>>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
    
>>>>> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>>>> :
    
>>>>>=C2=A0 
    
>>>>> This description of the situation is an oversimplifica=
tion..=C2=A0 OpenID Connect secures the implicit flow against token injecti=
on attacks by including the at_hash (access token hash) in the ID Token, en=
abling the client to validate that the access token was created by the issu=
er in the ID Token (which is also the OAuth Issuer, as described in RFC 841=
4).=C2=A0 (Note that this mitigation was described in draft-ietf-oauth-mix-=
up-mitigation.)
    
>>>>>=C2=A0 
    
>>>>> Given the prevalence of this known-good solution for s=
ecuring the implicit flow, I would request that the draft be updated to des=
cribe this mitigation.=C2=A0 At the same time, I=E2=80=99m fine with the dr=
aft recommending the code flow over the implicit flow when this mitigation =
is not used.
    
>>>>>=C2=A0 
    
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you,
    
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
    
>>>>>=C2=A0 
    
>>>>> From: OAuth 
    
>>>>> <oauth-bounces@ietf.org>
    
>>>>>=C2=A0 On Behalf Of Hannes Tschofenig
    
>>>>> Sent: Monday, November 19, 2018 2:34 AM
    
>>>>> To: oauth 
    
>>>>> <oauth@ietf.org>
    
>>>>> 
    
>>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend=
 authorization code instead of implicit
    
>>>>>=C2=A0 
    
>>>>> Hi all,
    
>>>>>=C2=A0 
    
>>>>> The authors of the OAuth Security Topics draft came to=
 the conclusion that it is not possible to adequately secure the implicit f=
low against token injection since potential solutions like token binding or=
 JARM are in an early stage of adoption. For this reason, and since CORS al=
lows browser-based apps to send requests to the token endpoint, Torsten sug=
gested to use the authorization code instead of the implicit grant in call =
cases in his presentation (seehttps://
    
>>>>> datatracker.ietf.org/meeting/103/materials/sli=
des-103-oauth-sessb-draft-ietf-oauth-security-topics-01
    
>>>>> ).
    
>>>>>=C2=A0 
    
>>>>> A hum in the room at IETF#103 concluded strong support=
 for his recommendations. We would like to confirm the discussion on the li=
st.
    
>>>>>=C2=A0 
    
>>>>> Please provide a response by December 3rd.
    
>>>>>=C2=A0 
    
>>>>> Ciao
    
>>>>> Hannes & Rifaat
    
>>>>>=C2=A0 
    
>>>>> IMPORTANT NOTICE: The contents of this email and any a=
ttachments are confidential and may also be privileged. If you are not the =
intended recipient, please notify the sender immediately and do not disclos=
e the contents to any other person, use it for any purpose, or store or cop=
y the information in any medium. Thank you.
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> OA=
uth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinf=
o/oauth
    
>>>>> 
    
>>>>>=C2=A0 
    
>>>>> 
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> OA=
uth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinf=
o/oauth
    
>>>>> 
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> 
    
>>>>> OA=
uth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinf=
o/oauth
    
>>>> _______________________________________________
    
>>>> OAuth mailing list
    
>>>> 
    
>>>> OAuth@=
ietf.org
    
>>>> https://www.ietf.org/mailman/listinfo/oa=
uth
    
>> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org=

    
> https://www.ietf.org/mailman/listinfo/oauth
    
> 
    
> 
    
> -- 
    
> hans.z=
andbelt@zmartzone.eu
    
> ZmartZone IAM - www.zmartzone.eu
    

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

    

--00000000000023a94d057b814e96--


From nobody Sun Nov 25 10:41:42 2018
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 B5CFD1288EB for ; Sun, 25 Nov 2018 10:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xVH_CoNFoBhC for ; Sun, 25 Nov 2018 10:41:37 -0800 (PST)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.103]) (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 C1F091200B3 for ; Sun, 25 Nov 2018 10:41:36 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gQzLZ-0001L6-Jp; Sun, 25 Nov 2018 19:41:33 +0100
From: Torsten Lodderstedt 
Message-Id: <465F5F67-E2FB-4A6B-B7AD-D1402FE7AD60@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_29399E1E-FDE1-4567-8BB0-FFE706C58B00"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Sun, 25 Nov 2018 19:41:31 +0100
In-Reply-To: 
Cc: oauth 
To: Rifaat Shekh-Yusef 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net> 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 18:41:41 -0000

--Apple-Mail=_29399E1E-FDE1-4567-8BB0-FFE706C58B00
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Rifaat,

this is a recommendation to anyone using implicit now. Implicit can only =
be used with public clients, so one could interpret it that way. I could =
also envision a SPA to use a backend, which in turn is a confidential =
client. There were some posts about this topic on the list recently.=20

Does this answer your question?

kind regards,
Torsten.=20

> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef =
:
>=20
> Hi Torsten,
>=20
> I am assuming that these recommendations are mainly for Public =
Clients, not Confidential Clients; is that correct?
>=20
> Regards,
>  Rifaat
>=20
>=20
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt =
 wrote:
> Hi all,=20
>=20
> I would like to state again what the proposal of the authors of the =
Security BCP is:
>=20
> Here is the respective text from the draft:
>=20
> =E2=80=94=E2=80=94
>=20
> 2.1.2.  Implicit Grant
>=20
>    The implicit grant (response type "token") and other response types
>    causing the authorization server to issue access tokens in the
>    authorization response are vulnerable to access token leakage and
>    access token replay as described in Section 3.1, Section 3.2, =
Section 3.3, and Section 3.6.
>=20
>    Moreover, no viable mechanism exists to cryptographically bind =
access
>    tokens issued in the authorization response to a certain client as =
it
>    is recommended in Section 2.2.  This makes replay detection for =
such
>    access tokens at resource servers impossible.
>=20
>    In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant or any other response type causing the authorization server =
to
>    issue an access token in the authorization response.
>=20
>    Clients SHOULD instead use the response type "code" (aka
>    authorization code grant type) as specified in Section 2.1.1 or any
>    other response type that causes the authorization server to issue
>    access tokens in the token response.  This allows the authorization
>    server to detect replay attempts and generally reduces the attack
>    surface since access tokens are not exposed in URLs.  It also =
allows
>    the authorization server to sender-constrain the issued tokens.
> =E2=80=94=E2=80=94
>=20
> In my observation, discouraging implicit seems to be the less =
controversial issue.
>=20
> =E2=80=9Eor any other response type causing the authorization server =
to issue an access token in the authorization response.=E2=80=9C in the =
3rd paragraph caused discussions because it suggests to discourage =
developers from using ANY response type issuing access tokens in the =
authorization response. This includes OIDC=E2=80=99s response types =
=E2=80=9Etoken id_token=E2=80=9C, =E2=80=9Ecode token=E2=80=9C & =E2=80=9E=
code token id_token=E2=80=9C, where at least  =E2=80=9Etoken id_token=E2=80=
=9C is used in the wild to implement SPAs.
>=20
> Why did we come up with this proposal given at least =E2=80=9Etoken =
id_token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect =
against injection?
>=20
> Two reasons:=20
>=20
> 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender =
constrained tokens. Also use of refresh tokens to frequently issue new =
live-time and privilege restricted access tokens is not supported. =
=E2=80=9Ecode token id_token=E2=80=9C seems more complex than just =
=E2=80=9Ecode=E2=80=9C+pkce for achieving the same goal.
>=20
> 2) Protection against token leakage is rather thin and fragile. There =
is just a single line of defense (CSP, open redirection prevention, =
browser history manipulation) implemented by the client.=20
>=20
> Daniel and I collected some more information and argument at =
https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that =
you might like to give a read.
>=20
> My conclusion after 2 weeks of intensive discussions with SPA =
developers (mostly on twitter): code+pkce is the more secure, simpler, =
and more versatile approach to (also) implement SPAs. I prefer to =
approach developers with a clean and robust message instead of a lengthy =
description of what needs to go right in order to secure a SPA using =
OAuth. That=E2=80=99s why I think code+pkce should be the recommendation =
of our working group.
>=20
> So please vote in favor of our proposal. I think that=E2=80=99s a huge =
improvement for OAuth.
>=20
> kind regards,=20
> Torsten.=20
>=20
>=20
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt =
:
> >=20
> > I strongly support the recommendation of using code instead of =
implicit. I do so based on my own experience in the field [1] and stick =
to that also after reading the comments and (what I would call) =
workarounds on this thread.
> >=20
> > Hans.
> >=20
> > [1] =
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-pa=
ge-applications/
> >=20
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt =
 wrote:
> > that=E2=80=99s certainly true, but that might by a web server with =
static content only.
> >=20
> > If the server is a real backend, there is even less reasons to use a =
implicit or hybrid. No even a performance gain in comparison to code.
> >=20
> > Am 21..11.2018 um 14:24 schrieb George Fletcher :
> >=20
> >> An SPA has a backend because it has to be loaded from somewhere :)
> >>=20
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
> >>> We had a discussion about this topic on Twitter =
https://twitter.com/Apl3b/status/1064854507606208513
> >>>=20
> >>>=20
> >>> Outcome is POST requires a backend to receive the request so =
it=E2=80=99s not a viable solution for SPAs.
> >>>=20
> >>>=20
> >>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
> >>>> :
> >>>>=20
> >>>> Post response works OK for server based clients.  I don't think =
POST works for single page applications. =20
> >>>>=20
> >>>> Basically that would be something more like postmessage between =
two JS apps. =20
> >>>>=20
> >>>> Postmessage also has security issues passing a access token and =
leaking. =20
> >>>>=20
> >>>> Perhaps someone more familiar with SPA can comment on POST. =20
> >>>>=20
> >>>> John B.=20
> >>>>=20
> >>>>=20
> >>>>=20
> >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
> >>>> gffletch@aol.com
> >>>>  wrote:
> >>>> Hi Mike,
> >>>>=20
> >>>> The Form Post Response Mode keeps the access_token out of the =
URL, but it doesn't prevent the token from traversing through the =
browser. So a man-in-the-browser attack may be able to intercept the =
values. It should help with leakage in logs.
> >>>>=20
> >>>> Thanks,
> >>>> George
> >>>>=20
> >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
> >>>>=20
> >>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post =
Response Mode =
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> >>>>>  mitigate the threats you=E2=80=99re describing below John?  If =
so, I believe the Security Topics draft should say this.
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>> I believe we owe it to readers to present the complete picture, =
which is why I believe that describing profiles using ID Tokens and the =
Form Post Response Mode are in scope.
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>>                                                        -- Mike
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>> From: OAuth=20
> >>>>> 
> >>>>>  On Behalf Of John Bradley
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
> >>>>> To:=20
> >>>>> oauth@ietf.org
> >>>>>=20
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>> Yes the at_hash protects the client from accepting an injected =
AT.=20
> >>>>>=20
> >>>>> Unfortunately it doesn't do anything to protect against leakage =
in logs or redirects.
> >>>>>=20
> >>>>> So without the AT using some sort of POP mechanism it is hard to =
say sending it in a redirect is a good security practice.
> >>>>>=20
> >>>>> John B.
> >>>>>=20
> >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
> >>>>>=20
> >>>>> Hi Mike,=20
> >>>>> =20
> >>>>> I agree that OIDC hybrid flows offer additional security over =
the OAuth implicit grant and are used in the wild. On my slides and in =
the initial version of the new section, we had included the hybrid OIDC =
flows because of their known token injection countermeasures.
> >>>>> =20
> >>>>> I nevertheless feel very uncomfortable to recommend those flows =
and any flow issuing access tokens in the front channel. In the course =
of the detailed review of the new text we realized two issues:=20
> >>>>> =20
> >>>>> 1) Since the access token is exposed in the URL, such flows =
possess a significantly higher risk to leak the access token (e.g. =
through browser history, open redirection and even referrer headers) =
than the code grant.
> >>>>> 2) There is no viable way to sender constrain access tokens =
issued in the front channel. Given the WG decided to recommend use of =
sender constraint tokens (
> >>>>> =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.=
..2
> >>>>> ), it seems contradictory to recommend response types not =
supporting such an approach.=20
> >>>>> =20
> >>>>> kind regards,
> >>>>> Torsten.=20
> >>>>> =20
> >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones=20
> >>>>> 
> >>>>> :
> >>>>> =20
> >>>>> This description of the situation is an oversimplification..  =
OpenID Connect secures the implicit flow against token injection attacks =
by including the at_hash (access token hash) in the ID Token, enabling =
the client to validate that the access token was created by the issuer =
in the ID Token (which is also the OAuth Issuer, as described in RFC =
8414).  (Note that this mitigation was described in =
draft-ietf-oauth-mix-up-mitigation.)
> >>>>> =20
> >>>>> Given the prevalence of this known-good solution for securing =
the implicit flow, I would request that the draft be updated to describe =
this mitigation.  At the same time, I=E2=80=99m fine with the draft =
recommending the code flow over the implicit flow when this mitigation =
is not used.
> >>>>> =20
> >>>>>                                                                 =
Thank you,
> >>>>>                                                                 =
-- Mike
> >>>>> =20
> >>>>> From: OAuth=20
> >>>>> 
> >>>>>  On Behalf Of Hannes Tschofenig
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
> >>>>> To: oauth=20
> >>>>> 
> >>>>>=20
> >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
> >>>>> =20
> >>>>> Hi all,
> >>>>> =20
> >>>>> The authors of the OAuth Security Topics draft came to the =
conclusion that it is not possible to adequately secure the implicit =
flow against token injection since potential solutions like token =
binding or JARM are in an early stage of adoption. For this reason, and =
since CORS allows browser-based apps to send requests to the token =
endpoint, Torsten suggested to use the authorization code instead of the =
implicit grant in call cases in his presentation (seehttps://
> >>>>> =
datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ie=
tf-oauth-security-topics-01
> >>>>> ).
> >>>>> =20
> >>>>> A hum in the room at IETF#103 concluded strong support for his =
recommendations. We would like to confirm the discussion on the list.
> >>>>> =20
> >>>>> Please provide a response by December 3rd.
> >>>>> =20
> >>>>> Ciao
> >>>>> Hannes & Rifaat
> >>>>> =20
> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments =
are confidential and may also be privileged. If you are not the intended =
recipient, please 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.
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>=20
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>=20
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>=20
> >>>>>=20
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>>=20
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>=20
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >=20
> >=20
> > --=20
> > hans.zandbelt@zmartzone.eu
> > ZmartZone IAM - www.zmartzone.eu
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_29399E1E-FDE1-4567-8BB0-FFE706C58B00
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjUxODQxMzJaMC8GCSqGSIb3DQEJBDEiBCAk
Z6f+0I4kFNVH5LoifCE3cMXedA7nQFMQI8LmSVQS8jCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAd9xFSogmdkXVHHzBu3klui2P
ffYo7rIhz+YVCA3L96QXVe2uUEL1xUtAIpaIamsT9qOB/fgA9wJKRwtxAvJb+ZRrwsNPeK1FVIEq
HL6ENID5QLSBFRrkggDdHOt4DzUXRM3CXzE7Ij59TB/TIiLOQdIqKJ0GMnPbPV1tGXA8BmKfHcDZ
UqN12+AKyry1tK7WJZrT0sJ5hlqa0VW3dkjkKarp/erzpPKVSxVTSCCXj+hJsIJorCiAzLtWqhcw
5N9bBMsNx7crtBKkhn44Hs4S2g9hSd45CCCkmBOgkWQrGy2UyqfDg4AlmplbI8e1C2jQc1XC4OkB
F3PlLD8DQArMEQAAAAAAAA==
--Apple-Mail=_29399E1E-FDE1-4567-8BB0-FFE706C58B00--


From nobody Sun Nov 25 10:46:34 2018
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 AF13D126CB6 for ; Sun, 25 Nov 2018 10:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 joL5l1_xH-o8 for ; Sun, 25 Nov 2018 10:46:30 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) (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 444111200B3 for ; Sun, 25 Nov 2018 10:46:30 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gQzQI-0006zx-OB; Sun, 25 Nov 2018 19:46:26 +0100
From: Torsten Lodderstedt 
Message-Id: <15ECD17C-C2E3-487B-B61D-E67E5A060DE4@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_90199A4F-8B99-4037-A516-BA0D58DF7A93"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Sun, 25 Nov 2018 19:46:25 +0100
In-Reply-To: 
Cc: Daniel Fett , "oauth@ietf.org" 
To: Neil Madden 
References:  
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Binding Access Tokens is not enough!
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, 25 Nov 2018 18:46:33 -0000

--Apple-Mail=_90199A4F-8B99-4037-A516-BA0D58DF7A93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Does this mean the RS effectively relies on the user agent to enforce =
the sender constraint (via CORS policy)?

> Am 23.11.2018 um 14:54 schrieb Neil Madden =
:
>=20
> Thanks for doing this Daniel, I think the proposed text is good.
>=20
> =E2=80=94 Neil
>=20
>> On 22 Nov 2018, at 14:42, Daniel Fett  wrote:
>>=20
>> Hi all,
>>=20
>> I would like to discuss a text proposal for the security BCP.
>>=20
>> Background:
>>=20
>> Yesterday, Neil pointed out the following problem with binding access =
tokens using mTLS or token binding in SPAs:
>>=20
>> "I am talking about scripts from places like ad servers that are =
usually included via an iframe to enforce the SOP and sandbox them from =
other scripts. If they get access to an access token - e.g. via =
document.referrer or a redirect or some other leak, then they still act =
within the same TLS context as the legitimate client."
>>=20
>> The problem is that a browser's TLS stack will attach the proof of =
possession no matter which origin started a request.
>>=20
>> (This seems like a real downside of token binding - why does it not =
have the "same site" option that cookies nowadays have?)
>>=20
>> I prepared the following addition to the security BCP and would like =
to hear your opinions:
>>=20
>> "It is important to note that constraining the sender of a token to a =
web browser (using a TLS-based method) does not constrain the origin of =
the script that uses the token (lack of origin binding). In other words, =
if access tokens are used in a browser (as in a single-page application, =
SPA) and the access tokens are sender-constrained using a TLS-based =
method, it must be ensured that origins other than the origin of the SPA =
cannot misuse the TLS-based sender authentication.
>>=20
>> The problem can be illustrated using an SPA on origin A that uses an =
access token AT that is bound to the TLS connection between the browser =
and the resource server R. If AT leaks to an attacker E, and there is, =
for example, an iframe from E's origin loaded in the web browser, that =
iframe can send a request to origin R using the access token AT. This =
request will contain the proof-of-posession of the (mTLS or token =
binding) key. The resource server R therefore cannot distinguish if a =
request containing a valid access token originates from origin A or =
origin E.
>>=20
>> If the resource server only accepts the access token in an =
Authorization header, then Cross-Origin Resource Sharing (CORS) will =
protect against this attack by default. If the resource server accepts =
the access tokens in other ways (e.g., as a URL parameter), or if the =
CORS policy of the resource server permits requests by origin E, then =
the TLS-based token binding only provides protection if the browser is =
offline."
>>=20
>>=20
>> The "summary" above this text reads as follows:
>>=20
>> "If access tokens are sender-constrained to a web browser, the =
resource server MUST ensure that the access token can only be used by =
the origin to which the access token was issued (origin binding). One =
solution for the resource server to accomplish this is to only accept =
the access token in an Authorization header (as described in RFC 6750) =
and to ensure that the active CORS policy prevents third parties from =
sending Authorization headers. See  for =
details."
>>=20
>> What do you think?
>>=20
>> -Daniel
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_90199A4F-8B99-4037-A516-BA0D58DF7A93
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjUxODQ2MjZaMC8GCSqGSIb3DQEJBDEiBCDF
/Fmwl/RCBb+6o5B9HWVvz/2yi7gbgYobmScRO6FCRTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEADDhb98UG0UnbriHM70VvbA+s
Fa9sp+MaIr266VQJhyJoByEfhHWac+cqaDmrMISQw02QW7gwsYDrucdiZIkbj7ZExQtWxbIvjF6J
FHo62EYE0VNI9dN1IaaqZ1MCb2nQvEzWINZPdg5mM5aD05O34ojolvD2jm6JVpGSdP95n3obDJj9
ZYL8S1ADNhwfn+Mlv9M5wcf1s6hC/WvD9NCeleQTayl1mb1J8b8aj6DZABkDNKaHU+83pv8AFXJz
9n8/ZiVyGd9I318OmVVnFfemyHrzXw0otBt8Z9+gswMY02IEvLwgM8MjW0L1SED5AjpX0YtZ6Ux9
0GfEHiF5ROYEQwAAAAAAAA==
--Apple-Mail=_90199A4F-8B99-4037-A516-BA0D58DF7A93--


From nobody Sun Nov 25 11:55:40 2018
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 57339124C04 for ; Sun, 25 Nov 2018 11:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jewX14K4tCBo for ; Sun, 25 Nov 2018 11:55:34 -0800 (PST)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0: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 DF4CF1286E3 for ; Sun, 25 Nov 2018 11:55:33 -0800 (PST)
Received: by mail-it1-x132.google.com with SMTP id m15so24411301itl.4 for ; Sun, 25 Nov 2018 11:55: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 :cc; bh=lmkBcC3yvbtMh9/4RBUBy6Py2dC4kkFtkbm8mvMwsuw=; b=rzbnFfeTyvAd1AparojDUcv57w3+TRJemwoUdHgQfzWOYug0VtJduyj/oLAZiLRO9v e8RX71Pq+1zNxsMxV7TKvyCdr4xE+YRIsNxvQiXkOAQXzlwOkQIt8u+Y6i9EePz3UWw+ 8Qv9AxabEbYckqkPtvuGIYH6h2nKPssmB4c6gnBVipj7cuC9Bu6JYU5+lwsr5CL+oyVN JvMQ9ooUdN436t2S1CYqzrfRxjaq8NXQLNPEOfN33wR9UOBgo1lDGmGWeBUiQhfHinRK T/CJbdtTIUAa255f9MTWvV35DS2sQ8VCwJA9j/djjVX4PeRE5bkhuv8M/2joNVSt3yTb 8+Aw==
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=lmkBcC3yvbtMh9/4RBUBy6Py2dC4kkFtkbm8mvMwsuw=; b=q3mK9r0qWX1nD77RGUkmrOSY46r7py6LE8ZyxjoQWKEtZ9zaeEx6ckg8eCOhuxw03C 0Iwb1wauRB/0PuAImLbK4suPW1JmSs7n8VvtWhyC/OM6W6TZoYhdDi/zfp0NXxTJ5s3/ dIqQCww7/RdEFIrcwgVNtsNWjRgJl7x+6oQnKBh9RAhho9YvOC8EfaotY2BNV1bvW9/2 CmLo6/KZL3IRLItuAe5ziVmwAa/avHIuAnLK4oSrVt9sUlG52dDTmGaCHEFdOhTi6qgg bVBfPUo+VgTWnk+LhAcPUPIT91Jw4xNCGiGfwrgkKSahwT77SOwzoR2k/c4RCDIVec9g Jd2Q==
X-Gm-Message-State: AA+aEWaOGq0HsJl27JncHjzY7kES3TYaPFyDp6vc4XyDOeLKvRXmVyXB Sj7jx99mc/JGNc0tGdG0RTZOBjJGUepbYgiQlv59GKq9
X-Google-Smtp-Source: AFSGD/UxA4RR6M/jzJnF32L/NUHAN2TKGb2mgNe4fRXzDrp6PKRl774nZReMo5DFDGIVFjLxpSisdkaRp3wLWtV3KGw=
X-Received: by 2002:a24:76d0:: with SMTP id z199mr8829955itb.165.1543175733032;  Sun, 25 Nov 2018 11:55:33 -0800 (PST)
MIME-Version: 1.0
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>  <465F5F67-E2FB-4A6B-B7AD-D1402FE7AD60@lodderstedt.net>
In-Reply-To: <465F5F67-E2FB-4A6B-B7AD-D1402FE7AD60@lodderstedt.net>
From: Rifaat Shekh-Yusef 
Date: Sun, 25 Nov 2018 14:55:21 -0500
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000064bbfb057b82991d"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 19:55:38 -0000

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

RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public
clients:

3.1.2.2 .
Registration Requirements

   The authorization server MUST require the following clients to

   register their redirection endpoint:

   o  Public clients.

*   o  Confidential clients utilizing the implicit grant type.*



I do not know if anybody is using Implicit with Confidential clients, but
just in case, you might want to make it clear that your recommendations are
specifically for public clients.

Regards,
 Rifaat




On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt 
wrote:

> Hi Rifaat,
>
> this is a recommendation to anyone using implicit now. Implicit can only
> be used with public clients, so one could interpret it that way. I could
> also envision a SPA to use a backend, which in turn is a confidential
> client. There were some posts about this topic on the list recently.
>
> Does this answer your question?
>
> kind regards,
> Torsten.
>
> > Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef  >:
> >
> > Hi Torsten,
> >
> > I am assuming that these recommendations are mainly for Public Clients,
> not Confidential Clients; is that correct?
> >
> > Regards,
> >  Rifaat
> >
> >
> > On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> > Hi all,
> >
> > I would like to state again what the proposal of the authors of the
> Security BCP is:
> >
> > Here is the respective text from the draft:
> >
> > =E2=80=94=E2=80=94
> >
> > 2.1.2.  Implicit Grant
> >
> >    The implicit grant (response type "token") and other response types
> >    causing the authorization server to issue access tokens in the
> >    authorization response are vulnerable to access token leakage and
> >    access token replay as described in Section 3.1, Section 3.2, Sectio=
n
> 3.3, and Section 3.6.
> >
> >    Moreover, no viable mechanism exists to cryptographically bind acces=
s
> >    tokens issued in the authorization response to a certain client as i=
t
> >    is recommended in Section 2.2.  This makes replay detection for such
> >    access tokens at resource servers impossible.
> >
> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server to
> >    issue an access token in the authorization response.
> >
> >    Clients SHOULD instead use the response type "code" (aka
> >    authorization code grant type) as specified in Section 2.1.1 or any
> >    other response type that causes the authorization server to issue
> >    access tokens in the token response.  This allows the authorization
> >    server to detect replay attempts and generally reduces the attack
> >    surface since access tokens are not exposed in URLs.  It also allows
> >    the authorization server to sender-constrain the issued tokens.
> > =E2=80=94=E2=80=94
> >
> > In my observation, discouraging implicit seems to be the less
> controversial issue.
> >
> > =E2=80=9Eor any other response type causing the authorization server to=
 issue an
> access token in the authorization response.=E2=80=9C in the 3rd paragraph=
 caused
> discussions because it suggests to discourage developers from using ANY
> response type issuing access tokens in the authorization response. This
> includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=9C, =
=E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token
> id_token=E2=80=9C, where at least  =E2=80=9Etoken id_token=E2=80=9C is us=
ed in the wild to
> implement SPAs.
> >
> > Why did we come up with this proposal given at least =E2=80=9Etoken id_=
token=E2=80=9C &
> =E2=80=9Ecode token id_token=E2=80=9C protect against injection?
> >
> > Two reasons:
> >
> > 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained=
 tokens. Also use
> of refresh tokens to frequently issue new live-time and privilege
> restricted access tokens is not supported. =E2=80=9Ecode token id_token=
=E2=80=9C seems more
> complex than just =E2=80=9Ecode=E2=80=9C+pkce for achieving the same goal=
.
> >
> > 2) Protection against token leakage is rather thin and fragile. There i=
s
> just a single line of defense (CSP, open redirection prevention, browser
> history manipulation) implemented by the client.
> >
> > Daniel and I collected some more information and argument at
> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you
> might like to give a read.
> >
> > My conclusion after 2 weeks of intensive discussions with SPA developer=
s
> (mostly on twitter): code+pkce is the more secure, simpler, and more
> versatile approach to (also) implement SPAs. I prefer to approach
> developers with a clean and robust message instead of a lengthy descripti=
on
> of what needs to go right in order to secure a SPA using OAuth. That=E2=
=80=99s why
> I think code+pkce should be the recommendation of our working group.
> >
> > So please vote in favor of our proposal. I think that=E2=80=99s a huge
> improvement for OAuth.
> >
> > kind regards,
> > Torsten.
> >
> >
> > > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <
> hans.zandbelt@zmartzone.eu>:
> > >
> > > I strongly support the recommendation of using code instead of
> implicit. I do so based on my own experience in the field [1] and stick t=
o
> that also after reading the comments and (what I would call) workarounds =
on
> this thread.
> > >
> > > Hans.
> > >
> > > [1]
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-p=
age-applications/
> > >
> > > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> > > that=E2=80=99s certainly true, but that might by a web server with st=
atic
> content only.
> > >
> > > If the server is a real backend, there is even less reasons to use a
> implicit or hybrid. No even a performance gain in comparison to code.
> > >
> > > Am 21..11.2018 um 14:24 schrieb George Fletcher :
> > >
> > >> An SPA has a backend because it has to be loaded from somewhere :)
> > >>
> > >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
> > >>> We had a discussion about this topic on Twitter
> https://twitter.com/Apl3b/status/1064854507606208513
> > >>>
> > >>>
> > >>> Outcome is POST requires a backend to receive the request so it=E2=
=80=99s
> not a viable solution for SPAs.
> > >>>
> > >>>
> > >>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
> > >>>> :
> > >>>>
> > >>>> Post response works OK for server based clients.  I don't think
> POST works for single page applications.
> > >>>>
> > >>>> Basically that would be something more like postmessage between tw=
o
> JS apps.
> > >>>>
> > >>>> Postmessage also has security issues passing a access token and
> leaking.
> > >>>>
> > >>>> Perhaps someone more familiar with SPA can comment on POST.
> > >>>>
> > >>>> John B.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
> > >>>> gffletch@aol.com
> > >>>>  wrote:
> > >>>> Hi Mike,
> > >>>>
> > >>>> The Form Post Response Mode keeps the access_token out of the URL,
> but it doesn't prevent the token from traversing through the browser. So =
a
> man-in-the-browser attack may be able to intercept the values. It should
> help with leakage in logs.
> > >>>>
> > >>>> Thanks,
> > >>>> George
> > >>>>
> > >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
> > >>>>
> > >>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Respo=
nse Mode
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> > >>>>>  mitigate the threats you=E2=80=99re describing below John?  If s=
o, I
> believe the Security Topics draft should say this.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> I believe we owe it to readers to present the complete picture,
> which is why I believe that describing profiles using ID Tokens and the
> Form Post Response Mode are in scope.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>                                                        -- Mike
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> From: OAuth
> > >>>>> 
> > >>>>>  On Behalf Of John Bradley
> > >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
> > >>>>> To:
> > >>>>> oauth@ietf.org
> > >>>>>
> > >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Yes the at_hash protects the client from accepting an injected AT=
.
> > >>>>>
> > >>>>> Unfortunately it doesn't do anything to protect against leakage i=
n
> logs or redirects.
> > >>>>>
> > >>>>> So without the AT using some sort of POP mechanism it is hard to
> say sending it in a redirect is a good security practice.
> > >>>>>
> > >>>>> John B.
> > >>>>>
> > >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
> > >>>>>
> > >>>>> Hi Mike,
> > >>>>>
> > >>>>> I agree that OIDC hybrid flows offer additional security over the
> OAuth implicit grant and are used in the wild. On my slides and in the
> initial version of the new section, we had included the hybrid OIDC flows
> because of their known token injection countermeasures.
> > >>>>>
> > >>>>> I nevertheless feel very uncomfortable to recommend those flows
> and any flow issuing access tokens in the front channel. In the course of
> the detailed review of the new text we realized two issues:
> > >>>>>
> > >>>>> 1) Since the access token is exposed in the URL, such flows
> possess a significantly higher risk to leak the access token (e.g. throug=
h
> browser history, open redirection and even referrer headers) than the cod=
e
> grant.
> > >>>>> 2) There is no viable way to sender constrain access tokens issue=
d
> in the front channel. Given the WG decided to recommend use of sender
> constraint tokens (
> > >>>>>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2=
...2
> > >>>>> ), it seems contradictory to recommend response types not
> supporting such an approach.
> > >>>>>
> > >>>>> kind regards,
> > >>>>> Torsten.
> > >>>>>
> > >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones
> > >>>>> 
> > >>>>> :
> > >>>>>
> > >>>>> This description of the situation is an oversimplification..
> OpenID Connect secures the implicit flow against token injection attacks =
by
> including the at_hash (access token hash) in the ID Token, enabling the
> client to validate that the access token was created by the issuer in the
> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (No=
te
> that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.=
)
> > >>>>>
> > >>>>> Given the prevalence of this known-good solution for securing the
> implicit flow, I would request that the draft be updated to describe this
> mitigation.  At the same time, I=E2=80=99m fine with the draft recommendi=
ng the
> code flow over the implicit flow when this mitigation is not used.
> > >>>>>
> > >>>>>
>  Thank you,
> > >>>>>                                                                 -=
-
> Mike
> > >>>>>
> > >>>>> From: OAuth
> > >>>>> 
> > >>>>>  On Behalf Of Hannes Tschofenig
> > >>>>> Sent: Monday, November 19, 2018 2:34 AM
> > >>>>> To: oauth
> > >>>>> 
> > >>>>>
> > >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
> > >>>>>
> > >>>>> Hi all,
> > >>>>>
> > >>>>> The authors of the OAuth Security Topics draft came to the
> conclusion that it is not possible to adequately secure the implicit flow
> against token injection since potential solutions like token binding or
> JARM are in an early stage of adoption. For this reason, and since CORS
> allows browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (seehttps://
> > >>>>>
> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-i=
etf-oauth-security-topics-01
> > >>>>> ).
> > >>>>>
> > >>>>> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> > >>>>>
> > >>>>> Please provide a response by December 3rd.
> > >>>>>
> > >>>>> Ciao
> > >>>>> Hannes & Rifaat
> > >>>>>
> > >>>>> IMPORTANT NOTICE: The contents of this email and any attachments
> are confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> > >>>>> _______________________________________________
> > >>>>> OAuth mailing list
> > >>>>>
> > >>>>> OAuth@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> OAuth mailing list
> > >>>>>
> > >>>>> OAuth@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> OAuth mailing list
> > >>>>>
> > >>>>>
> > >>>>> OAuth@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
> > >>>> _______________________________________________
> > >>>> 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
> > >
> > >
> > > --
> > > hans.zandbelt@zmartzone.eu
> > > ZmartZone IAM - www.zmartzone.eu
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>

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


    RFC6749, Section 3.1.2.2, implies that Implicit is not lim=
ited to public clients:

    3.1.2.2.  Registration Requirements
       The au=
thorization server MUST require the following clients to
       register their redirec=
tion endpoint:
       o  Confidential clients utilizing the implicit grant type=
.


    I do not know if anybody is using Implicit =
with Confidential clients, but just in case, you might want to make it clea=
r that your recommendations are specifically for public clients.
    =

    Regards,
    =C2=A0Rifaat



    On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Rifaat,
    

    
this is a recommendation to anyone using implicit now. Implicit can only be=
 used with public clients, so one could interpret it that way. I could also=
 envision a SPA to use a backend, which in turn is a confidential client. T=
here were some posts about this topic on the list recently. 
    

    
Does this answer your question?
    

    
kind regards,
    
Torsten. 
    

    
> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:
> 
    
> Hi Torsten,
    
> 
    
> I am assuming that these recommendations are mainly for Public Clients=
, not Confidential Clients; is that correct?
    
> 
    
> Regards,
    
>=C2=A0 Rifaat
    
> 
    
> 
    
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <torsten@lodderstedt.net=
> wrote:
    
> Hi all, 
    
> 
    
> I would like to state again what the proposal of the authors of the Se=
curity BCP is:
    
> 
    
> Here is the respective text from the draft:
    
> 
    
> =E2=80=94=E2=80=94
    
> 
    
> 2.1.2.=C2=A0 Implicit Grant
    
> 
    
>=C2=A0 =C2=A0 The implicit grant (response type "token") and =
other response types
    
>=C2=A0 =C2=A0 causing the authorization server to issue access tokens i=
n the
    
>=C2=A0 =C2=A0 authorization response are vulnerable to access token lea=
kage and
    
>=C2=A0 =C2=A0 access token replay as described in Section 3.1, Section =
3.2, Section 3.3, and Section 3.6.
    
> 
    
>=C2=A0 =C2=A0 Moreover, no viable mechanism exists to cryptographically=
 bind access
    
>=C2=A0 =C2=A0 tokens issued in the authorization response to a certain =
client as it
    
>=C2=A0 =C2=A0 is recommended in Section 2.2.=C2=A0 This makes replay de=
tection for such
    
>=C2=A0 =C2=A0 access tokens at resource servers impossible.
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant or any other response type causing the authorizatio=
n server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response.
    
> 
    
>=C2=A0 =C2=A0 Clients SHOULD instead use the response type "code&q=
uot; (aka
    
>=C2=A0 =C2=A0 authorization code grant type) as specified in Section 2.=
1.1 or any
    
>=C2=A0 =C2=A0 other response type that causes the authorization server =
to issue
    
>=C2=A0 =C2=A0 access tokens in the token response.=C2=A0 This allows th=
e authorization
    
>=C2=A0 =C2=A0 server to detect replay attempts and generally reduces th=
e attack
    
>=C2=A0 =C2=A0 surface since access tokens are not exposed in URLs.=C2=
=A0 It also allows
    
>=C2=A0 =C2=A0 the authorization server to sender-constrain the issued t=
okens.
    
> =E2=80=94=E2=80=94
    
> 
    
> In my observation, discouraging implicit seems to be the less controve=
rsial issue.
    
> 
    
> =E2=80=9Eor any other response type causing the authorization server t=
o issue an access token in the authorization response.=E2=80=9C in the 3rd =
paragraph caused discussions because it suggests to discourage developers f=
rom using ANY response type issuing access tokens in the authorization resp=
onse. This includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=
=E2=80=9C, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token id_token=
=E2=80=9C, where at least=C2=A0 =E2=80=9Etoken id_token=E2=80=9C is used in=
 the wild to implement SPAs.
    
> 
    
> Why did we come up with this proposal given at least =E2=80=9Etoken id=
_token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against=
 injection?
    
> 
    
> Two reasons: 
    
> 
    
> 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constraine=
d tokens. Also use of refresh tokens to frequently issue new live-time and =
privilege restricted access tokens is not supported. =E2=80=9Ecode token id=
_token=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce fo=
r achieving the same goal.
    
> 
    
> 2) Protection against token leakage is rather thin and fragile. There =
is just a single line of defense (CSP, open redirection prevention, browser=
 history manipulation) implemented by the client. 
    
> 
    
> Daniel and I collected some more information and argument at https://github.com/tlodderstedt/oauth2_sp=
a/blob/master/README.md that you might like to give a read.
    
> 
    
> My conclusion after 2 weeks of intensive discussions with SPA develope=
rs (mostly on twitter): code+pkce is the more secure, simpler, and more ver=
satile approach to (also) implement SPAs. I prefer to approach developers w=
ith a clean and robust message instead of a lengthy description of what nee=
ds to go right in order to secure a SPA using OAuth. That=E2=80=99s why I t=
hink code+pkce should be the recommendation of our working group.
    
> 
    
> So please vote in favor of our proposal. I think that=E2=80=99s a huge=
 improvement for OAuth.
    
> 
    
> kind regards, 
    
> Torsten. 
    
> 
    
> 
    
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu<=
/a>>:
    
> > 
    
> > I strongly support the recommendation of using code instead of im=
plicit. I do so based on my own experience in the field [1] and stick to th=
at also after reading the comments and (what I would call) workarounds on t=
his thread.
    
> > 
    
> > Hans.
    
> > 
    
> > [1]     https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single=
-page-applications/
    
> > 
    
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <torsten@lodderstedt.n=
et> wrote:
    
> > that=E2=80=99s certainly true, but that might by a web server wit=
h static content only.
    
> > 
    
> > If the server is a real backend, there is even less reasons to us=
e a implicit or hybrid. No even a performance gain in comparison to code.
> > 
    
> > Am 21..11.2018 um 14:24 schrieb George Fletcher <gffletch@aol.com>:
    
> > 
    
> >> An SPA has a backend because it has to be loaded from somewhe=
re :)
    
> >> 
    
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
    
> >>> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513
    
> >>> 
    
> >>> 
    
> >>> Outcome is POST requires a backend to receive the request=
 so it=E2=80=99s not a viable solution for SPAs.
    
> >>> 
    
> >>> 
    
> >>>> Am 20.11.2018 um 23:29 schrieb John Bradley <    ve7jtb@ve7jtb.com>=

    
> >>>> :
    
> >>>> 
    
> >>>> Post response works OK for server based clients.=C2=
=A0 I don't think POST works for single page applications.=C2=A0 
    
> >>>> 
    
> >>>> Basically that would be something more like postmessa=
ge between two JS apps.=C2=A0 
    
> >>>> 
    
> >>>> Postmessage also has security issues passing a access=
 token and leaking.=C2=A0 
    
> >>>> 
    
> >>>> Perhaps someone more familiar with SPA can comment on=
 POST.=C2=A0 
    
> >>>> 
    
> >>>> John B. 
    
> >>>> 
    
> >>>> 
    
> >>>> 
    
> >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
> >>>> gffletch@aol.com
    
> >>>>=C2=A0 wrote:
    
> >>>> Hi Mike,
    
> >>>> 
    
> >>>> The Form Post Response Mode keeps the access_token ou=
t of the URL, but it doesn't prevent the token from traversing through =
the browser. So a man-in-the-browser attack may be able to intercept the va=
lues. It should help with leakage in logs.
    
> >>>> 
    
> >>>> Thanks,
    
> >>>> George
    
> >>>> 
    
> >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
    
> >>>> 
    
> >>>>> Next question =E2=80=93 doesn=E2=80=99t using the=
 Form Post Response Mode https://o=
penid.net/specs/oauth-v2-form-post-response-mode-1_0.html
    
> >>>>>=C2=A0 mitigate the threats you=E2=80=99re describ=
ing below John?=C2=A0 If so, I believe the Security Topics draft should say=
 this.
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> I believe we owe it to readers to present the com=
plete picture, which is why I believe that describing profiles using ID Tok=
ens and the Form Post Response Mode are in scope.
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -=
- Mike
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>=C2=A0 On Behalf Of John Bradley
    
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
    
> >>>>> To: 
    
> >>>>> oauth@ietf.org
    
> >>>>> 
    
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- =
Recommend authorization code instead of implicit
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> Yes the at_hash protects the client from acceptin=
g an injected AT. 
    
> >>>>> 
    
> >>>>> Unfortunately it doesn't do anything to prote=
ct against leakage in logs or redirects.
    
> >>>>> 
    
> >>>>> So without the AT using some sort of POP mechanis=
m it is hard to say sending it in a redirect is a good security practice.
> >>>>> 
    
> >>>>> John B.
    
> >>>>> 
    
> >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:=

    
> >>>>> 
    
> >>>>> Hi Mike, 
    
> >>>>>=C2=A0 
    
> >>>>> I agree that OIDC hybrid flows offer additional s=
ecurity over the OAuth implicit grant and are used in the wild. On my slide=
s and in the initial version of the new section, we had included the hybrid=
 OIDC flows because of their known token injection countermeasures.
    
> >>>>>=C2=A0 
    
> >>>>> I nevertheless feel very uncomfortable to recomme=
nd those flows and any flow issuing access tokens in the front channel. In =
the course of the detailed review of the new text we realized two issues: <=
br>
> >>>>>=C2=A0 
    
> >>>>> 1) Since the access token is exposed in the URL, =
such flows possess a significantly higher risk to leak the access token (e.=
g. through browser history, open redirection and even referrer headers) tha=
n the code grant.
    
> >>>>> 2) There is no viable way to sender constrain acc=
ess tokens issued in the front channel. Given the WG decided to recommend u=
se of sender constraint tokens (
    
> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-=
2...2
    
> >>>>> ), it seems contradictory to recommend response t=
ypes not supporting such an approach. 
    
> >>>>>=C2=A0 
    
> >>>>> kind regards,
    
> >>>>> Torsten. 
    
> >>>>>=C2=A0 
    
> >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
    
> >>>>> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org&g=
t;
    
> >>>>> :
    
> >>>>>=C2=A0 
    
> >>>>> This description of the situation is an oversimpl=
ification..=C2=A0 OpenID Connect secures the implicit flow against token in=
jection attacks by including the at_hash (access token hash) in the ID Toke=
n, enabling the client to validate that the access token was created by the=
 issuer in the ID Token (which is also the OAuth Issuer, as described in RF=
C 8414).=C2=A0 (Note that this mitigation was described in draft-ietf-oauth=
-mix-up-mitigation.)
    
> >>>>>=C2=A0 
    
> >>>>> Given the prevalence of this known-good solution =
for securing the implicit flow, I would request that the draft be updated t=
o describe this mitigation.=C2=A0 At the same time, I=E2=80=99m fine with t=
he draft recommending the code flow over the implicit flow when this mitiga=
tion is not used.
    
> >>>>>=C2=A0 
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you,
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
    
> >>>>>=C2=A0 
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>=C2=A0 On Behalf Of Hannes Tschofenig
    
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
    
> >>>>> To: oauth 
    
> >>>>> <oauth@ietf.org>
    
> >>>>> 
    
> >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Reco=
mmend authorization code instead of implicit
    
> >>>>>=C2=A0 
    
> >>>>> Hi all,
    
> >>>>>=C2=A0 
    
> >>>>> The authors of the OAuth Security Topics draft ca=
me to the conclusion that it is not possible to adequately secure the impli=
cit flow against token injection since potential solutions like token bindi=
ng or JARM are in an early stage of adoption. For this reason, and since CO=
RS allows browser-based apps to send requests to the token endpoint, Torste=
n suggested to use the authorization code instead of the implicit grant in =
call cases in his presentation (seehttps://
    
> >>>>> datatracker.ietf.org/meeting/103/material=
s/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
    
> >>>>> ).
    
> >>>>>=C2=A0 
    
> >>>>> A hum in the room at IETF#103 concluded strong su=
pport for his recommendations. We would like to confirm the discussion on t=
he list.
    
> >>>>>=C2=A0 
    
> >>>>> Please provide a response by December 3rd.
    
> >>>>>=C2=A0 
    
> >>>>> Ciao
    
> >>>>> Hannes & Rifaat
    
> >>>>>=C2=A0 
    
> >>>>> IMPORTANT NOTICE: The contents of this email and =
any attachments are confidential and may also be privileged. If you are not=
 the intended recipient, please notify the sender immediately and do not di=
sclose the contents to any other person, use it for any purpose, or store o=
r copy the information in any medium. Thank you.
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org/mailman/li=
stinfo/oauth
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org/mailman/li=
stinfo/oauth
    
> >>>>> 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org/mailman/li=
stinfo/oauth
    
> >>>> _______________________________________________
    
> >>>> OAuth mailing list
    
> >>>> 
    
> >>>> O=
Auth@ietf.org
    
> >>>> https://www.ietf.org/mailman/listin=
fo/oauth
    
> >> 
    
> > _______________________________________________
    
> > OAuth mailing list
    
> > OAuth@ietf.or=
g
    
> > https://www.ietf.org/mailman/listinfo/oauth=

    
> > 
    
> > 
    
> > -- 
    
> > h=
ans.zandbelt@zmartzone.eu
    
> > ZmartZone IAM - www.zmartzone.eu
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org=

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

    

    

--00000000000064bbfb057b82991d--


From nobody Sun Nov 25 12:15:34 2018
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 56F40130DD5 for ; Sun, 25 Nov 2018 12:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 qFPyp06wmWAP for ; Sun, 25 Nov 2018 12:15:28 -0800 (PST)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.108]) (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 8A1011288EB for ; Sun, 25 Nov 2018 12:15:27 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.112]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gR0oL-0007Rr-4r; Sun, 25 Nov 2018 21:15:21 +0100
Content-Type: multipart/signed; boundary=Apple-Mail-5B0FAB10-7AB4-424D-BA14-0C0DAD0765CC; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: 
Date: Sun, 25 Nov 2018 21:15:20 +0100
Cc: oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <8DA53F7A-925F-49AB-B37C-0516E99E3061@lodderstedt.net>
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>  <465F5F67-E2FB-4A6B-B7AD-D1402FE7AD60@lodderstedt.net> 
To: Rifaat Shekh-Yusef 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 20:15:32 -0000

--Apple-Mail-5B0FAB10-7AB4-424D-BA14-0C0DAD0765CC
Content-Type: multipart/alternative;
	boundary=Apple-Mail-7571F183-485D-4982-B775-636F9AAF259D
Content-Transfer-Encoding: 7bit


--Apple-Mail-7571F183-485D-4982-B775-636F9AAF259D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

as I said, it=E2=80=99s a recommendation for anyone using the implicit now. I=
f there are confidential clients out there using implicit (I don=E2=80=99t t=
hink there are), it is applicable to them as well.=20

> Am 25.11.2018 um 20:55 schrieb Rifaat Shekh-Yusef :=

>=20
> RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public c=
lients:
>=20
> 3.1.2.2.  Registration Requirements
>    The authorization server MUST require the following clients to
>    register their redirection endpoint:
>    o  Public clients.
>    o  Confidential clients utilizing the implicit grant type.
>=20
>=20
> I do not know if anybody is using Implicit with Confidential clients, but j=
ust in case, you might want to make it clear that your recommendations are s=
pecifically for public clients.
>=20
> Regards,
>  Rifaat
>=20
>=20
>=20
>=20
>> On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt  wrote:
>> Hi Rifaat,
>>=20
>> this is a recommendation to anyone using implicit now. Implicit can only b=
e used with public clients, so one could interpret it that way. I could also=
 envision a SPA to use a backend, which in turn is a confidential client. Th=
ere were some posts about this topic on the list recently.=20
>>=20
>> Does this answer your question?
>>=20
>> kind regards,
>> Torsten.=20
>>=20
>> > Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef :
>> >=20
>> > Hi Torsten,
>> >=20
>> > I am assuming that these recommendations are mainly for Public Clients,=
 not Confidential Clients; is that correct?
>> >=20
>> > Regards,
>> >  Rifaat
>> >=20
>> >=20
>> > On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt  wrote:
>> > Hi all,=20
>> >=20
>> > I would like to state again what the proposal of the authors of the Sec=
urity BCP is:
>> >=20
>> > Here is the respective text from the draft:
>> >=20
>> > =E2=80=94=E2=80=94
>> >=20
>> > 2.1.2.  Implicit Grant
>> >=20
>> >    The implicit grant (response type "token") and other response types
>> >    causing the authorization server to issue access tokens in the
>> >    authorization response are vulnerable to access token leakage and
>> >    access token replay as described in Section 3.1, Section 3.2, Sectio=
n 3.3, and Section 3.6.
>> >=20
>> >    Moreover, no viable mechanism exists to cryptographically bind acces=
s
>> >    tokens issued in the authorization response to a certain client as i=
t
>> >    is recommended in Section 2.2.  This makes replay detection for such=

>> >    access tokens at resource servers impossible.
>> >=20
>> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
>> >    grant or any other response type causing the authorization server to=

>> >    issue an access token in the authorization response.
>> >=20
>> >    Clients SHOULD instead use the response type "code" (aka
>> >    authorization code grant type) as specified in Section 2.1.1 or any
>> >    other response type that causes the authorization server to issue
>> >    access tokens in the token response.  This allows the authorization
>> >    server to detect replay attempts and generally reduces the attack
>> >    surface since access tokens are not exposed in URLs.  It also allows=

>> >    the authorization server to sender-constrain the issued tokens.
>> > =E2=80=94=E2=80=94
>> >=20
>> > In my observation, discouraging implicit seems to be the less controver=
sial issue.
>> >=20
>> > =E2=80=9Eor any other response type causing the authorization server to=
 issue an access token in the authorization response.=E2=80=9C in the 3rd pa=
ragraph caused discussions because it suggests to discourage developers from=
 using ANY response type issuing access tokens in the authorization response=
. This includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=9C=
, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C, wher=
e at least  =E2=80=9Etoken id_token=E2=80=9C is used in the wild to implemen=
t SPAs.
>> >=20
>> > Why did we come up with this proposal given at least =E2=80=9Etoken id_=
token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against injec=
tion?
>> >=20
>> > Two reasons:=20
>> >=20
>> > 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained=
 tokens. Also use of refresh tokens to frequently issue new live-time and pr=
ivilege restricted access tokens is not supported. =E2=80=9Ecode token id_to=
ken=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce for ac=
hieving the same goal.
>> >=20
>> > 2) Protection against token leakage is rather thin and fragile. There i=
s just a single line of defense (CSP, open redirection prevention, browser h=
istory manipulation) implemented by the client.=20
>> >=20
>> > Daniel and I collected some more information and argument at https://gi=
thub.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might like t=
o give a read.
>> >=20
>> > My conclusion after 2 weeks of intensive discussions with SPA developer=
s (mostly on twitter): code+pkce is the more secure, simpler, and more versa=
tile approach to (also) implement SPAs. I prefer to approach developers with=
 a clean and robust message instead of a lengthy description of what needs t=
o go right in order to secure a SPA using OAuth. That=E2=80=99s why I think c=
ode+pkce should be the recommendation of our working group.
>> >=20
>> > So please vote in favor of our proposal. I think that=E2=80=99s a huge i=
mprovement for OAuth.
>> >=20
>> > kind regards,=20
>> > Torsten.=20
>> >=20
>> >=20
>> > > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt :
>> > >=20
>> > > I strongly support the recommendation of using code instead of implic=
it. I do so based on my own experience in the field [1] and stick to that al=
so after reading the comments and (what I would call) workarounds on this th=
read.
>> > >=20
>> > > Hans.
>> > >=20
>> > > [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-=
single-page-applications/
>> > >=20
>> > > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt  wrote:
>> > > that=E2=80=99s certainly true, but that might by a web server with st=
atic content only.
>> > >=20
>> > > If the server is a real backend, there is even less reasons to use a i=
mplicit or hybrid. No even a performance gain in comparison to code.
>> > >=20
>> > > Am 21..11.2018 um 14:24 schrieb George Fletcher :
>> > >=20
>> > >> An SPA has a backend because it has to be loaded from somewhere :)
>> > >>=20
>> > >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>> > >>> We had a discussion about this topic on Twitter https://twitter.com=
/Apl3b/status/1064854507606208513
>> > >>>=20
>> > >>>=20
>> > >>> Outcome is POST requires a backend to receive the request so it=E2=80=
=99s not a viable solution for SPAs.
>> > >>>=20
>> > >>>=20
>> > >>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
>> > >>>> :
>> > >>>>=20
>> > >>>> Post response works OK for server based clients.  I don't think PO=
ST works for single page applications. =20
>> > >>>>=20
>> > >>>> Basically that would be something more like postmessage between tw=
o JS apps. =20
>> > >>>>=20
>> > >>>> Postmessage also has security issues passing a access token and le=
aking. =20
>> > >>>>=20
>> > >>>> Perhaps someone more familiar with SPA can comment on POST. =20
>> > >>>>=20
>> > >>>> John B.=20
>> > >>>>=20
>> > >>>>=20
>> > >>>>=20
>> > >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
>> > >>>> gffletch@aol.com
>> > >>>>  wrote:
>> > >>>> Hi Mike,
>> > >>>>=20
>> > >>>> The Form Post Response Mode keeps the access_token out of the URL,=
 but it doesn't prevent the token from traversing through the browser. So a m=
an-in-the-browser attack may be able to intercept the values. It should help=
 with leakage in logs.
>> > >>>>=20
>> > >>>> Thanks,
>> > >>>> George
>> > >>>>=20
>> > >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>> > >>>>=20
>> > >>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Respo=
nse Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>> > >>>>>  mitigate the threats you=E2=80=99re describing below John?  If s=
o, I believe the Security Topics draft should say this.
>> > >>>>>=20
>> > >>>>> =20
>> > >>>>>=20
>> > >>>>> I believe we owe it to readers to present the complete picture, w=
hich is why I believe that describing profiles using ID Tokens and the Form P=
ost Response Mode are in scope.
>> > >>>>>=20
>> > >>>>> =20
>> > >>>>>=20
>> > >>>>>                                                        -- Mike
>> > >>>>>=20
>> > >>>>> =20
>> > >>>>>=20
>> > >>>>> From: OAuth=20
>> > >>>>> 
>> > >>>>>  On Behalf Of John Bradley
>> > >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>> > >>>>> To:=20
>> > >>>>> oauth@ietf.org
>> > >>>>>=20
>> > >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend author=
ization code instead of implicit
>> > >>>>>=20
>> > >>>>> =20
>> > >>>>>=20
>> > >>>>> Yes the at_hash protects the client from accepting an injected AT=
.=20
>> > >>>>>=20
>> > >>>>> Unfortunately it doesn't do anything to protect against leakage i=
n logs or redirects.
>> > >>>>>=20
>> > >>>>> So without the AT using some sort of POP mechanism it is hard to s=
ay sending it in a redirect is a good security practice.
>> > >>>>>=20
>> > >>>>> John B.
>> > >>>>>=20
>> > >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>> > >>>>>=20
>> > >>>>> Hi Mike,=20
>> > >>>>> =20
>> > >>>>> I agree that OIDC hybrid flows offer additional security over the=
 OAuth implicit grant and are used in the wild. On my slides and in the init=
ial version of the new section, we had included the hybrid OIDC flows becaus=
e of their known token injection countermeasures.
>> > >>>>> =20
>> > >>>>> I nevertheless feel very uncomfortable to recommend those flows a=
nd any flow issuing access tokens in the front channel. In the course of the=
 detailed review of the new text we realized two issues:=20
>> > >>>>> =20
>> > >>>>> 1) Since the access token is exposed in the URL, such flows posse=
ss a significantly higher risk to leak the access token (e.g. through browse=
r history, open redirection and even referrer headers) than the code grant.
>> > >>>>> 2) There is no viable way to sender constrain access tokens issue=
d in the front channel. Given the WG decided to recommend use of sender cons=
traint tokens (
>> > >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#s=
ection-2...2
>> > >>>>> ), it seems contradictory to recommend response types not support=
ing such an approach.=20
>> > >>>>> =20
>> > >>>>> kind regards,
>> > >>>>> Torsten.=20
>> > >>>>> =20
>> > >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones=20
>> > >>>>> 
>> > >>>>> :
>> > >>>>> =20
>> > >>>>> This description of the situation is an oversimplification..  Ope=
nID Connect secures the implicit flow against token injection attacks by inc=
luding the at_hash (access token hash) in the ID Token, enabling the client t=
o validate that the access token was created by the issuer in the ID Token (=
which is also the OAuth Issuer, as described in RFC 8414).  (Note that this m=
itigation was described in draft-ietf-oauth-mix-up-mitigation.)
>> > >>>>> =20
>> > >>>>> Given the prevalence of this known-good solution for securing the=
 implicit flow, I would request that the draft be updated to describe this m=
itigation.  At the same time, I=E2=80=99m fine with the draft recommending t=
he code flow over the implicit flow when this mitigation is not used.
>> > >>>>> =20
>> > >>>>>                                                                 T=
hank you,
>> > >>>>>                                                                 -=
- Mike
>> > >>>>> =20
>> > >>>>> From: OAuth=20
>> > >>>>> 
>> > >>>>>  On Behalf Of Hannes Tschofenig
>> > >>>>> Sent: Monday, November 19, 2018 2:34 AM
>> > >>>>> To: oauth=20
>> > >>>>> 
>> > >>>>>=20
>> > >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorizat=
ion code instead of implicit
>> > >>>>> =20
>> > >>>>> Hi all,
>> > >>>>> =20
>> > >>>>> The authors of the OAuth Security Topics draft came to the conclu=
sion that it is not possible to adequately secure the implicit flow against t=
oken injection since potential solutions like token binding or JARM are in a=
n early stage of adoption. For this reason, and since CORS allows browser-ba=
sed apps to send requests to the token endpoint, Torsten suggested to use th=
e authorization code instead of the implicit grant in call cases in his pres=
entation (seehttps://
>> > >>>>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
>> > >>>>> ).
>> > >>>>> =20
>> > >>>>> A hum in the room at IETF#103 concluded strong support for his re=
commendations. We would like to confirm the discussion on the list.
>> > >>>>> =20
>> > >>>>> Please provide a response by December 3rd.
>> > >>>>> =20
>> > >>>>> Ciao
>> > >>>>> Hannes & Rifaat
>> > >>>>> =20
>> > >>>>> IMPORTANT NOTICE: The contents of this email and any attachments a=
re confidential and may also be privileged. If you are not the intended reci=
pient, please notify the sender immediately and do not disclose the contents=
 to any other person, use it for any purpose, or store or copy the informati=
on in any medium. Thank you.
>> > >>>>> _______________________________________________
>> > >>>>> OAuth mailing list
>> > >>>>>=20
>> > >>>>> OAuth@ietf.org
>> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>>>>=20
>> > >>>>> =20
>> > >>>>>=20
>> > >>>>>=20
>> > >>>>>=20
>> > >>>>> _______________________________________________
>> > >>>>> OAuth mailing list
>> > >>>>>=20
>> > >>>>> OAuth@ietf.org
>> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>>>>=20
>> > >>>>>=20
>> > >>>>>=20
>> > >>>>> _______________________________________________
>> > >>>>> OAuth mailing list
>> > >>>>>=20
>> > >>>>>=20
>> > >>>>> OAuth@ietf.org
>> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>>> _______________________________________________
>> > >>>> OAuth mailing list
>> > >>>>=20
>> > >>>> OAuth@ietf.org
>> > >>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>=20
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > OAuth@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/oauth
>> > >=20
>> > >=20
>> > > --=20
>> > > hans.zandbelt@zmartzone.eu
>> > > ZmartZone IAM - www.zmartzone.eu
>> >=20
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>=20

--Apple-Mail-7571F183-485D-4982-B775-636F9AAF259D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    as I=
 said, it=E2=80=99s a recommendation for anyone using the implicit now. If t=
here are confidential clients out there using implicit (I don=E2=80=99t thin=
k there are), it is applicable to them as well. 
    =

    Am 25.11.2018 um 20:55 schrieb Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

    RFC6749, Section 3.1.2.2,=
 implies that Implicit is not limited to public clients:

    3.1.2.2.  Registratio=
n Requirements
       The authorization server MUST require the following clients to<=
/pre>
       regist=
er their redirection endpoint:
       o  Public clients.
       o  Confidential clients utilizing the implicit grant=
 type.


    I do not know if anybody is using Implic=
it with Confidential clients, but just in case, you might want to make it cl=
ear that your recommendations are specifically for public clients.

    Regards,
     Rifaat



    =
On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Rifaat,
    

    
this is a recommendation to anyone using implicit now. Implicit can only be u=
sed with public clients, so one could interpret it that way. I could also en=
vision a SPA to use a backend, which in turn is a confidential client. There=
 were some posts about this topic on the list recently. 
    

    
Does this answer your question?
    

    
kind regards,
    
Torsten. 
    

    
> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:
    =

> 
    
> Hi Torsten,
    
> 
    
> I am assuming that these recommendations are mainly for Public Clients,=
 not Confidential Clients; is that correct?
    
> 
    
> Regards,
    
>  Rifaat
    
> 
    
> 
    
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <torsten@lodderstedt.net&g=
t; wrote:
    
> Hi all, 
    
> 
    
> I would like to state again what the proposal of the authors of the Sec=
urity BCP is:
    
> 
    
> Here is the respective text from the draft:
    
> 
    
> =E2=80=94=E2=80=94
    
> 
    
> 2.1.2.  Implicit Grant
    
> 
    
>    The implicit grant (response type "token") and other respo=
nse types
    
>    causing the authorization server to issue access tokens in=
 the
    
>    authorization response are vulnerable to access token leak=
age and
    
>    access token replay as described in Section 3.1, Section 3=
.2, Section 3.3, and Section 3.6.
    
> 
    
>    Moreover, no viable mechanism exists to cryptographically b=
ind access
    
>    tokens issued in the authorization response to a certain c=
lient as it
    
>    is recommended in Section 2.2.  This makes replay det=
ection for such
    
>    access tokens at resource servers impossible.
    
> 
    
>    In order to avoid these issues, Clients SHOULD NOT use the=
 implicit
    
>    grant or any other response type causing the authorization=
 server to
    
>    issue an access token in the authorization response.
    
> 
    
>    Clients SHOULD instead use the response type "code" (aka
>    authorization code grant type) as specified in Section 2.1=
.1 or any
    
>    other response type that causes the authorization server t=
o issue
    
>    access tokens in the token response.  This allows the=
 authorization
    
>    server to detect replay attempts and generally reduces the=
 attack
    
>    surface since access tokens are not exposed in URLs. =
 It also allows
    
>    the authorization server to sender-constrain the issued to=
kens.
    
> =E2=80=94=E2=80=94
    
> 
    
> In my observation, discouraging implicit seems to be the less controver=
sial issue.
    
> 
    
> =E2=80=9Eor any other response type causing the authorization server to=
 issue an access token in the authorization response.=E2=80=9C in the 3rd pa=
ragraph caused discussions because it suggests to discourage developers from=
 using ANY response type issuing access tokens in the authorization response=
. This includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=9C=
, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C, w=
here at least  =E2=80=9Etoken id_token=E2=80=9C is used in the wild to i=
mplement SPAs.
    
> 
    
> Why did we come up with this proposal given at least =E2=80=9Etoken id_=
token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against i=
njection?
    
> 
    
> Two reasons: 
    
> 
    
> 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained=
 tokens. Also use of refresh tokens to frequently issue new live-time and pr=
ivilege restricted access tokens is not supported. =E2=80=9Ecode token id_to=
ken=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce for ac=
hieving the same goal.
    
> 
    
> 2) Protection against token leakage is rather thin and fragile. There i=
s just a single line of defense (CSP, open redirection prevention, browser h=
istory manipulation) implemented by the client. 
    
> 
    
> Daniel and I collected some more information and argument at https://github.com/tlodderstedt/oauth2_spa/blob/=
master/README.md that you might like to give a read.
    
> 
    
> My conclusion after 2 weeks of intensive discussions with SPA developer=
s (mostly on twitter): code+pkce is the more secure, simpler, and more versa=
tile approach to (also) implement SPAs. I prefer to approach developers with=
 a clean and robust message instead of a lengthy description of what needs t=
o go right in order to secure a SPA using OAuth. That=E2=80=99s why I think c=
ode+pkce should be the recommendation of our working group.
    
> 
    
> So please vote in favor of our proposal. I think that=E2=80=99s a huge i=
mprovement for OAuth.
    
> 
    
> kind regards, 
    
> Torsten. 
    
> 
    
> 
    
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu>:
    
> > 
    
> > I strongly support the recommendation of using code instead of imp=
licit. I do so based on my own experience in the field [1] and stick to that=
 also after reading the comments and (what I would call) workarounds on this=
 thread.
    
> > 
    
> > Hans.
    
> > 
    
> > [1]     https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-pa=
ge-applications/
    
> > 
    
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    
> > that=E2=80=99s certainly true, but that might by a web server with=
 static content only.
    
> > 
    
> > If the server is a real backend, there is even less reasons to use=
 a implicit or hybrid. No even a performance gain in comparison to code.
    =

> > 
    
> > Am 21..11.2018 um 14:24 schrieb George Fletcher <    gffletch@aol.com>:
    
> > 
    
> >> An SPA has a backend because it has to be loaded from somewher=
e :)
    
> >> 
    
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
    
> >>> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513
    =

> >>> 
    
> >>> 
    
> >>> Outcome is POST requires a backend to receive the request s=
o it=E2=80=99s not a viable solution for SPAs.
    
> >>> 
    
> >>> 
    
> >>>> Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.com>
> >>>> :
    
> >>>> 
    
> >>>> Post response works OK for server based clients. =
 I don't think POST works for single page applications.  
    
> >>>> 
    
> >>>> Basically that would be something more like postmessag=
e between two JS apps.  
    
> >>>> 
    
> >>>> Postmessage also has security issues passing a access t=
oken and leaking.  
    
> >>>> 
    
> >>>> Perhaps someone more familiar with SPA can comment on P=
OST.  
    
> >>>> 
    
> >>>> John B. 
    
> >>>> 
    
> >>>> 
    
> >>>> 
    
> >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
    =

> >>>> =
gffletch@aol.com
    
> >>>>  wrote:
    
> >>>> Hi Mike,
    
> >>>> 
    
> >>>> The Form Post Response Mode keeps the access_token out=
 of the URL, but it doesn't prevent the token from traversing through the br=
owser. So a man-in-the-browser attack may be able to intercept the values. I=
t should help with leakage in logs.
    
> >>>> 
    
> >>>> Thanks,
    
> >>>> George
    
> >>>> 
    
> >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
    
> >>>> 
    
> >>>>> Next question =E2=80=93 doesn=E2=80=99t using the =
Form Post Response Mode https://open=
id.net/specs/oauth-v2-form-post-response-mode-1_0.html
    
> >>>>>  mitigate the threats you=E2=80=99re describi=
ng below John?  If so, I believe the Security Topics draft should say t=
his.
    
> >>>>> 
    
> >>>>>  
    
> >>>>> 
    
> >>>>> I believe we owe it to readers to present the comp=
lete picture, which is why I believe that describing profiles using ID Token=
s and the Form Post Response Mode are in scope.
    
> >>>>> 
    
> >>>>>  
    
> >>>>> 
    
> >>>>>              &n=
bsp;                     &=
nbsp;                   -- Mike=

    
> >>>>> 
    
> >>>>>  
    
> >>>>> 
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>  On Behalf Of John Bradley
    
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
    
> >>>>> To: 
    
> >>>>> oauth@ietf.org
    
> >>>>> 
    
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>>>> 
    
> >>>>>  
    
> >>>>> 
    
> >>>>> Yes the at_hash protects the client from accepting=
 an injected AT. 
    
> >>>>> 
    
> >>>>> Unfortunately it doesn't do anything to protect ag=
ainst leakage in logs or redirects.
    
> >>>>> 
    
> >>>>> So without the AT using some sort of POP mechanism=
 it is hard to say sending it in a redirect is a good security practice.
    =

> >>>>> 
    
> >>>>> John B.
    
> >>>>> 
    
> >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:<=
br>
> >>>>> 
    
> >>>>> Hi Mike, 
    
> >>>>>  
    
> >>>>> I agree that OIDC hybrid flows offer additional se=
curity over the OAuth implicit grant and are used in the wild. On my slides a=
nd in the initial version of the new section, we had included the hybrid OID=
C flows because of their known token injection countermeasures.
    
> >>>>>  
    
> >>>>> I nevertheless feel very uncomfortable to recommen=
d those flows and any flow issuing access tokens in the front channel. In th=
e course of the detailed review of the new text we realized two issues: 
    =

> >>>>>  
    
> >>>>> 1) Since the access token is exposed in the URL, s=
uch flows possess a significantly higher risk to leak the access token (e.g.=
 through browser history, open redirection and even referrer headers) than t=
he code grant.
    
> >>>>> 2) There is no viable way to sender constrain acce=
ss tokens issued in the front channel. Given the WG decided to recommend use=
 of sender constraint tokens (
    
> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..=
.2
    
> >>>>> ), it seems contradictory to recommend response ty=
pes not supporting such an approach. 
    
> >>>>>  
    
> >>>>> kind regards,
    
> >>>>> Torsten. 
    
> >>>>>  
    
> >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
    
> >>>>> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>=

    
> >>>>> :
    
> >>>>>  
    
> >>>>> This description of the situation is an oversimpli=
fication..  OpenID Connect secures the implicit flow against token inje=
ction attacks by including the at_hash (access token hash) in the ID Token, e=
nabling the client to validate that the access token was created by the issu=
er in the ID Token (which is also the OAuth Issuer, as described in RFC 8414=
).  (Note that this mitigation was described in draft-ietf-oauth-mix-up=
-mitigation.)
    
> >>>>>  
    
> >>>>> Given the prevalence of this known-good solution f=
or securing the implicit flow, I would request that the draft be updated to d=
escribe this mitigation.  At the same time, I=E2=80=99m fine with the d=
raft recommending the code flow over the implicit flow when this mitigation i=
s not used.
    
> >>>>>  
    
> >>>>>              &n=
bsp;                     &=
nbsp;                     &=
nbsp;      Thank you,
    
> >>>>>              &n=
bsp;                     &=
nbsp;                     &=
nbsp;      -- Mike
    
> >>>>>  
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>  On Behalf Of Hannes Tschofenig
    
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
    
> >>>>> To: oauth 
    
> >>>>> <oauth@ietf.org>
    
> >>>>> 
    
> >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >>>>>  
    
> >>>>> Hi all,
    
> >>>>>  
    
> >>>>> The authors of the OAuth Security Topics draft cam=
e to the conclusion that it is not possible to adequately secure the implici=
t flow against token injection since potential solutions like token binding o=
r JARM are in an early stage of adoption. For this reason, and since CORS al=
lows browser-based apps to send requests to the token endpoint, Torsten sugg=
ested to use the authorization code instead of the implicit grant in call ca=
ses in his presentation (seehttps://
    
> >>>>> datatracker.ietf.org/meeting/103/materials/sl=
ides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
    
> >>>>> ).
    
> >>>>>  
    
> >>>>> A hum in the room at IETF#103 concluded strong sup=
port for his recommendations. We would like to confirm the discussion on the=
 list.
    
> >>>>>  
    
> >>>>> Please provide a response by December 3rd.
    
> >>>>>  
    
> >>>>> Ciao
    
> >>>>> Hannes & Rifaat
    
> >>>>>  
    
> >>>>> IMPORTANT NOTICE: The contents of this email and a=
ny attachments are confidential and may also be privileged. If you are not t=
he intended recipient, please notify the sender immediately and do not discl=
ose the contents to any other person, use it for any purpose, or store or co=
py the information in any medium. Thank you.
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org/mailman/list=
info/oauth
    
> >>>>> 
    
> >>>>>  
    
> >>>>> 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org/mailman/list=
info/oauth
    
> >>>>> 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org/mailman/list=
info/oauth
    
> >>>> _______________________________________________
    
> >>>> OAuth mailing list
    
> >>>> 
    
> >>>> OA=
uth@ietf.org
    
> >>>> https://www.ietf.org/mailman/listinfo=
/oauth
    
> >> 
    
> > _______________________________________________
    
> > OAuth mailing list
    
> > OAuth@ietf.org=

    
> > https://www.ietf.org/mailman/listinfo/oauth
> > 
    
> > 
    
> > -- 
    
> > ha=
ns.zandbelt@zmartzone.eu
    
> > ZmartZone IAM - www.zmartzone.eu
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org<=
br>
> https://www.ietf.org/mailman/listinfo/oauth
    

    

    

    =

--Apple-Mail-7571F183-485D-4982-B775-636F9AAF259D--

--Apple-Mail-5B0FAB10-7AB4-424D-BA14-0C0DAD0765CC
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED
e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/
BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX
dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu
wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT
QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs
0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F
dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX
Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG
CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB
Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy
ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j
b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp
bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB
F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976
FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz
62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4
wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq
8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4
Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTI1MjAxNTIwWjAvBgkqhkiG
9w0BCQQxIgQg0ts4c273v6/NHJiM5Vt+FejJILPmtUcOR13ewuLLy8MwgcEGCSsGAQQBgjcQBDGB
szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT
SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3
mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB
IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBALkN
Ama/ot7JeXhTNZW7K34Jw3MatXv9+zGlZqPClCET+SL10rjRp5bRklieYuvotNF5S7FWJ5Vg5z93
Uf2J4xMP9iEbQghMXb+B7GVkn+ZKMbybjoOI3d3DfU3RS5DkFsiEbTT+u1Xt66ubN69fwhO6n8NE
phz4DnE2SQO+fL6qTedUu9E/QLs3mOD5dgOOSiYNjtxb2aT1M3HwafEfjChNTKx2ilWbRL7AXGuS
To9wBUUsJUUUWOO3vxYVF7G43KJQgrDNdOl6KupxqUzU108+M68g8Kzioq/Q++ibR68Sjo+1Z3gV
wOWVfCYHZ712Kd6AckvZ51ZERShphJt91ugAAAAAAAA=

--Apple-Mail-5B0FAB10-7AB4-424D-BA14-0C0DAD0765CC--


From nobody Sun Nov 25 12:56:03 2018
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 0CBE2130DD5 for ; Sun, 25 Nov 2018 12:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 1T6vmeS88Yz9 for ; Sun, 25 Nov 2018 12:55:57 -0800 (PST)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 3C064129C6A for ; Sun, 25 Nov 2018 12:55:57 -0800 (PST)
Received: by mail-wm1-x32d.google.com with SMTP id r11-v6so16195698wmb.2 for ; Sun, 25 Nov 2018 12:55:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W6ZMK/xfxvyHY7HKoK2JA/d1OYqWYAn9GbFgW9lIY0A=; b=rGq7ko1QHwV8pa0XMPkL3b/DfljnVDVKf7cWMoa7I4chEH2rIgWX+z1CtZrWKKi/XN drVtrPI7nxlsqLaiIAYtaghtIax+k0Nafijhuo374acpirl8qLu8v1QKoS7gZBuaWKlO LvgBobYmiySfT63QWegsULPkBXPxCeB9eSNP+DZmNdkPFagUXheCzAWwvVBFSNhke67f CyO2wDiy/itLUzOb737fEZPZkwbcbiAZqpENd+Vyg661i3Cq4FblMVgsSlX+RLOJAIU1 EFvFu0/dfdTmvORB3bWcFX/+YgtplCmiLYcW99t31lTzghM2LEmXXaSdH02oxHT94bCL 8/vA==
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=W6ZMK/xfxvyHY7HKoK2JA/d1OYqWYAn9GbFgW9lIY0A=; b=HwJx5QrNPRe8Ii3n8x8PYUWFCO5TiIHF3941QrOG56WsrlW9bwKYDEObDAYWfNLzSC 8nG/yLcIsVUpWiTsdZDFrcjEXmB3l4LTFZcIsSZGsMao0WI9pO1JIohGX5eGAcRmNSJa /i9/WVkNjtTBrDUReZT1Z5xFCyGCD0qyyPqn5VXm/5vwK3IpWifupupdyu1p/5kyQbWC IUQ2E5F+fg8uP/ajRBiQkXeWVFFvar/9Z7J+gR81VDcxA3/CGiJXMhvIK8skADMhJuHk gbtgzCJEfpK46RJcJdZGB1Yt5vdyIjkCCxzFs1druz1mxpsuDvFanQNQTMnZed1WaeSl vzMQ==
X-Gm-Message-State: AA+aEWYmLgJQEJbhkhKb2UpbEdHm7fTWV/L0p7ZuiqG228HWm618q54j 4m6Gd+ZCNZTg6nUedm1tv7i9pZ+0o53TLotL78fiFQ==
X-Google-Smtp-Source: AJdET5eqmt3qHvT0cVcRw2aGEkEUGhBj3064OsrqMK8qnUkpZfzTSG5V0zxt7l7TPGYPAjk8DDcJdtXOdGFFOfYtg4E=
X-Received: by 2002:a1c:6783:: with SMTP id b125-v6mr21048821wmc.147.1543179354973;  Sun, 25 Nov 2018 12:55:54 -0800 (PST)
MIME-Version: 1.0
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>  <465F5F67-E2FB-4A6B-B7AD-D1402FE7AD60@lodderstedt.net> 
In-Reply-To: 
From: John Bradley 
Date: Sun, 25 Nov 2018 17:55:41 -0300
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: Torsten Lodderstedt , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000473f46057b8371ad"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 20:56:02 -0000

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

There is no such thing as a implicit confidential client.

Implicit clients are not authenticated, so are not confidential.

You could have a hybrid client using the "code token" response type that is
confidential for the code flow but i don't think anyone would consider the
token returned from the authorization endpoint as confidential.

That should have been hybrid rather than confidential I suspect.  Perhaps a
errata could be looked at.

John B.


On Sun, Nov 25, 2018, 4:55 PM Rifaat Shekh-Yusef  RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public
> clients:
>
> 3.1.2.2 .  Registrat=
ion Requirements
>
>    The authorization server MUST require the following clients to
>
>    register their redirection endpoint:
>
>    o  Public clients.
>
> *   o  Confidential clients utilizing the implicit grant type..*
>
>
>
> I do not know if anybody is using Implicit with Confidential clients, but
> just in case, you might want to make it clear that your recommendations a=
re
> specifically for public clients.
>
> Regards,
>  Rifaat
>
>
>
>
> On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi Rifaat,
>>
>> this is a recommendation to anyone using implicit now. Implicit can only
>> be used with public clients, so one could interpret it that way. I could
>> also envision a SPA to use a backend, which in turn is a confidential
>> client. There were some posts about this topic on the list recently.
>>
>> Does this answer your question?
>>
>> kind regards,
>> Torsten.
>>
>> > Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <
>> rifaat.ietf@gmail.com>:
>> >
>> > Hi Torsten,
>> >
>> > I am assuming that these recommendations are mainly for Public Clients=
,
>> not Confidential Clients; is that correct?
>> >
>> > Regards,
>> >  Rifaat
>> >
>> >
>> > On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>> > Hi all,
>> >
>> > I would like to state again what the proposal of the authors of the
>> Security BCP is:
>> >
>> > Here is the respective text from the draft:
>> >
>> > =E2=80=94=E2=80=94
>> >
>> > 2.1.2.  Implicit Grant
>> >
>> >    The implicit grant (response type "token") and other response types
>> >    causing the authorization server to issue access tokens in the
>> >    authorization response are vulnerable to access token leakage and
>> >    access token replay as described in Section 3.1, Section 3.2,
>> Section 3.3, and Section 3.6.
>> >
>> >    Moreover, no viable mechanism exists to cryptographically bind acce=
ss
>> >    tokens issued in the authorization response to a certain client as =
it
>> >    is recommended in Section 2.2.  This makes replay detection for suc=
h
>> >    access tokens at resource servers impossible.
>> >
>> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
>> >    grant or any other response type causing the authorization server t=
o
>> >    issue an access token in the authorization response.
>> >
>> >    Clients SHOULD instead use the response type "code" (aka
>> >    authorization code grant type) as specified in Section 2.1.1 or any
>> >    other response type that causes the authorization server to issue
>> >    access tokens in the token response.  This allows the authorization
>> >    server to detect replay attempts and generally reduces the attack
>> >    surface since access tokens are not exposed in URLs.  It also allow=
s
>> >    the authorization server to sender-constrain the issued tokens.
>> > =E2=80=94=E2=80=94
>> >
>> > In my observation, discouraging implicit seems to be the less
>> controversial issue.
>> >
>> > =E2=80=9Eor any other response type causing the authorization server t=
o issue
>> an access token in the authorization response.=E2=80=9C in the 3rd parag=
raph caused
>> discussions because it suggests to discourage developers from using ANY
>> response type issuing access tokens in the authorization response. This
>> includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=9C,=
 =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token
>> id_token=E2=80=9C, where at least  =E2=80=9Etoken id_token=E2=80=9C is u=
sed in the wild to
>> implement SPAs.
>> >
>> > Why did we come up with this proposal given at least =E2=80=9Etoken id=
_token=E2=80=9C &
>> =E2=80=9Ecode token id_token=E2=80=9C protect against injection?
>> >
>> > Two reasons:
>> >
>> > 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constraine=
d tokens. Also
>> use of refresh tokens to frequently issue new live-time and privilege
>> restricted access tokens is not supported. =E2=80=9Ecode token id_token=
=E2=80=9C seems more
>> complex than just =E2=80=9Ecode=E2=80=9C+pkce for achieving the same goa=
l.
>> >
>> > 2) Protection against token leakage is rather thin and fragile. There
>> is just a single line of defense (CSP, open redirection prevention, brow=
ser
>> history manipulation) implemented by the client.
>> >
>> > Daniel and I collected some more information and argument at
>> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that
>> you might like to give a read.
>> >
>> > My conclusion after 2 weeks of intensive discussions with SPA
>> developers (mostly on twitter): code+pkce is the more secure, simpler, a=
nd
>> more versatile approach to (also) implement SPAs. I prefer to approach
>> developers with a clean and robust message instead of a lengthy descript=
ion
>> of what needs to go right in order to secure a SPA using OAuth. That=E2=
=80=99s why
>> I think code+pkce should be the recommendation of our working group.
>> >
>> > So please vote in favor of our proposal. I think that=E2=80=99s a huge
>> improvement for OAuth.
>> >
>> > kind regards,
>> > Torsten.
>> >
>> >
>> > > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <
>> hans.zandbelt@zmartzone.eu>:
>> > >
>> > > I strongly support the recommendation of using code instead of
>> implicit. I do so based on my own experience in the field [1] and stick =
to
>> that also after reading the comments and (what I would call) workarounds=
 on
>> this thread.
>> > >
>> > > Hans.
>> > >
>> > > [1]
>> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-=
page-applications/
>> > >
>> > > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>> > > that=E2=80=99s certainly true, but that might by a web server with s=
tatic
>> content only.
>> > >
>> > > If the server is a real backend, there is even less reasons to use a
>> implicit or hybrid. No even a performance gain in comparison to code.
>> > >
>> > > Am 21..11.2018 um 14:24 schrieb George Fletcher :
>> > >
>> > >> An SPA has a backend because it has to be loaded from somewhere :)
>> > >>
>> > >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>> > >>> We had a discussion about this topic on Twitter
>> https://twitter.com/Apl3b/status/1064854507606208513
>> > >>>
>> > >>>
>> > >>> Outcome is POST requires a backend to receive the request so it=E2=
=80=99s
>> not a viable solution for SPAs.
>> > >>>
>> > >>>
>> > >>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
>> > >>>> :
>> > >>>>
>> > >>>> Post response works OK for server based clients.  I don't think
>> POST works for single page applications.
>> > >>>>
>> > >>>> Basically that would be something more like postmessage between
>> two JS apps.
>> > >>>>
>> > >>>> Postmessage also has security issues passing a access token and
>> leaking.
>> > >>>>
>> > >>>> Perhaps someone more familiar with SPA can comment on POST.
>> > >>>>
>> > >>>> John B.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
>> > >>>> gffletch@aol.com
>> > >>>>  wrote:
>> > >>>> Hi Mike,
>> > >>>>
>> > >>>> The Form Post Response Mode keeps the access_token out of the URL=
,
>> but it doesn't prevent the token from traversing through the browser. So=
 a
>> man-in-the-browser attack may be able to intercept the values. It should
>> help with leakage in logs.
>> > >>>>
>> > >>>> Thanks,
>> > >>>> George
>> > >>>>
>> > >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>> > >>>>
>> > >>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Resp=
onse Mode
>> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>> > >>>>>  mitigate the threats you=E2=80=99re describing below John?  If =
so, I
>> believe the Security Topics draft should say this.
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> I believe we owe it to readers to present the complete picture,
>> which is why I believe that describing profiles using ID Tokens and the
>> Form Post Response Mode are in scope.
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>                                                        -- Mike
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> From: OAuth
>> > >>>>> 
>> > >>>>>  On Behalf Of John Bradley
>> > >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>> > >>>>> To:
>> > >>>>> oauth@ietf.org
>> > >>>>>
>> > >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend
>> authorization code instead of implicit
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> Yes the at_hash protects the client from accepting an injected
>> AT.
>> > >>>>>
>> > >>>>> Unfortunately it doesn't do anything to protect against leakage
>> in logs or redirects.
>> > >>>>>
>> > >>>>> So without the AT using some sort of POP mechanism it is hard to
>> say sending it in a redirect is a good security practice.
>> > >>>>>
>> > >>>>> John B.
>> > >>>>>
>> > >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>> > >>>>>
>> > >>>>> Hi Mike,
>> > >>>>>
>> > >>>>> I agree that OIDC hybrid flows offer additional security over th=
e
>> OAuth implicit grant and are used in the wild. On my slides and in the
>> initial version of the new section, we had included the hybrid OIDC flow=
s
>> because of their known token injection countermeasures.
>> > >>>>>
>> > >>>>> I nevertheless feel very uncomfortable to recommend those flows
>> and any flow issuing access tokens in the front channel. In the course o=
f
>> the detailed review of the new text we realized two issues:
>> > >>>>>
>> > >>>>> 1) Since the access token is exposed in the URL, such flows
>> possess a significantly higher risk to leak the access token (e.g. throu=
gh
>> browser history, open redirection and even referrer headers) than the co=
de
>> grant.
>> > >>>>> 2) There is no viable way to sender constrain access tokens
>> issued in the front channel. Given the WG decided to recommend use of
>> sender constraint tokens (
>> > >>>>>
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-=
2...2
>> > >>>>> ), it seems contradictory to recommend response types not
>> supporting such an approach.
>> > >>>>>
>> > >>>>> kind regards,
>> > >>>>> Torsten.
>> > >>>>>
>> > >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones
>> > >>>>> > <40microsoft..com@dmarc.ietf.org>>
>> > >>>>> :
>> > >>>>>
>> > >>>>> This description of the situation is an oversimplification..
>> OpenID Connect secures the implicit flow against token injection attacks=
 by
>> including the at_hash (access token hash) in the ID Token, enabling the
>> client to validate that the access token was created by the issuer in th=
e
>> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (N=
ote
>> that this mitigation was described in draft-ietf-oauth-mix-up-mitigation=
.)
>> > >>>>>
>> > >>>>> Given the prevalence of this known-good solution for securing th=
e
>> implicit flow, I would request that the draft be updated to describe thi=
s
>> mitigation.  At the same time, I=E2=80=99m fine with the draft recommend=
ing the
>> code flow over the implicit flow when this mitigation is not used.
>> > >>>>>
>> > >>>>>
>>  Thank you,
>> > >>>>>
>>  -- Mike
>> > >>>>>
>> > >>>>> From: OAuth
>> > >>>>> 
>> > >>>>>  On Behalf Of Hannes Tschofenig
>> > >>>>> Sent: Monday, November 19, 2018 2:34 AM
>> > >>>>> To: oauth
>> > >>>>> 
>> > >>>>>
>> > >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend
>> authorization code instead of implicit
>> > >>>>>
>> > >>>>> Hi all,
>> > >>>>>
>> > >>>>> The authors of the OAuth Security Topics draft came to the
>> conclusion that it is not possible to adequately secure the implicit flo=
w
>> against token injection since potential solutions like token binding or
>> JARM are in an early stage of adoption. For this reason, and since CORS
>> allows browser-based apps to send requests to the token endpoint, Torste=
n
>> suggested to use the authorization code instead of the implicit grant in
>> call cases in his presentation (seehttps://
>> > >>>>>
>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-=
ietf-oauth-security-topics-01
>> > >>>>> ).
>> > >>>>>
>> > >>>>> A hum in the room at IETF#103 concluded strong support for his
>> recommendations. We would like to confirm the discussion on the list.
>> > >>>>>
>> > >>>>> Please provide a response by December 3rd.
>> > >>>>>
>> > >>>>> Ciao
>> > >>>>> Hannes & Rifaat
>> > >>>>>
>> > >>>>> IMPORTANT NOTICE: The contents of this email and any attachments
>> are confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy t=
he
>> information in any medium. Thank you.
>> > >>>>> _______________________________________________
>> > >>>>> OAuth mailing list
>> > >>>>>
>> > >>>>> OAuth@ietf.org
>> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> _______________________________________________
>> > >>>>> OAuth mailing list
>> > >>>>>
>> > >>>>> OAuth@ietf.org
>> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> _______________________________________________
>> > >>>>> OAuth mailing list
>> > >>>>>
>> > >>>>>
>> > >>>>> OAuth@ietf.org
>> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>>> _______________________________________________
>> > >>>> 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
>> > >
>> > >
>> > > --
>> > > hans.zandbelt@zmartzone.eu
>> > > ZmartZone IAM - www.zmartzone.eu
>> >
>> > _______________________________________________
>> > 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
>

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


    There is no such thing as a implicit confidential cl=
ient.=C2=A0=C2=A0

    Implicit cli=
ents are not authenticated, so are not confidential.=C2=A0

    You could have a hybrid client using the=
 "code token" response type that is confidential for the code flo=
w but i don't think anyone would consider the token returned from the a=
uthorization endpoint as confidential.=C2=A0

    That should have been hybrid rather than confidential =
I suspect.=C2=A0 Perhaps a errata could be looked at.=C2=A0=C2=A0

    John B.=C2=A0


    On Sun, Nov 25, 2018, 4:55 PM Rifaat =
Shekh-Yusef <rifaat.ietf@gmail.=
com wrote:
    RFC=
6749, Section 3.1.2.2, implies that Implicit is not limited to public clien=
ts:

    3.1.2.2.  Registr=
ation Requirements
       The authoriz=
ation server MUST require the following clients to
       registe=
r their redirection endpoint:
       o  Public clients.
    <=
pre class=3D"m_5896948099374498273gmail-newpage" style=3D"font-size:13.3333=
px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">
       o  Confidential clients utilizing the implicit grant type=
..


    I do not know if anyb=
ody is using Implicit with Confidential clients, but just in case, you migh=
t want to make it clear that your recommendations are specifically for publ=
ic clients.

    Regards,
    =C2=A0Rifaat
    <=
div>



    On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt =
<torsten@lodderstedt.net> wrote:
    Hi Rifaat,
    

    
this is a recommendation to anyone using implicit now. Implicit can only be=
 used with public clients, so one could interpret it that way. I could also=
 envision a SPA to use a backend, which in turn is a confidential client. T=
here were some posts about this topic on the list recently. 
    

    
Does this answer your question?
    

    
kind regards,
    
Torsten. 
    

    
> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <rifaat.ietf@g=
mail.com>:
    
> 
    
> Hi Torsten,
    
> 
    
> I am assuming that these recommendations are mainly for Public Clients=
, not Confidential Clients; is that correct?
    
> 
    
> Regards,
    
>=C2=A0 Rifaat
    
> 
    
> 
    
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <torsten@=
lodderstedt.net> wrote:
    
> Hi all, 
    
> 
    
> I would like to state again what the proposal of the authors of the Se=
curity BCP is:
    
> 
    
> Here is the respective text from the draft:
    
> 
    
> =E2=80=94=E2=80=94
    
> 
    
> 2.1.2.=C2=A0 Implicit Grant
    
> 
    
>=C2=A0 =C2=A0 The implicit grant (response type "token") and =
other response types
    
>=C2=A0 =C2=A0 causing the authorization server to issue access tokens i=
n the
    
>=C2=A0 =C2=A0 authorization response are vulnerable to access token lea=
kage and
    
>=C2=A0 =C2=A0 access token replay as described in Section 3.1, Section =
3.2, Section 3.3, and Section 3.6.
    
> 
    
>=C2=A0 =C2=A0 Moreover, no viable mechanism exists to cryptographically=
 bind access
    
>=C2=A0 =C2=A0 tokens issued in the authorization response to a certain =
client as it
    
>=C2=A0 =C2=A0 is recommended in Section 2.2.=C2=A0 This makes replay de=
tection for such
    
>=C2=A0 =C2=A0 access tokens at resource servers impossible.
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant or any other response type causing the authorizatio=
n server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response.
    
> 
    
>=C2=A0 =C2=A0 Clients SHOULD instead use the response type "code&q=
uot; (aka
    
>=C2=A0 =C2=A0 authorization code grant type) as specified in Section 2.=
1.1 or any
    
>=C2=A0 =C2=A0 other response type that causes the authorization server =
to issue
    
>=C2=A0 =C2=A0 access tokens in the token response.=C2=A0 This allows th=
e authorization
    
>=C2=A0 =C2=A0 server to detect replay attempts and generally reduces th=
e attack
    
>=C2=A0 =C2=A0 surface since access tokens are not exposed in URLs.=C2=
=A0 It also allows
    
>=C2=A0 =C2=A0 the authorization server to sender-constrain the issued t=
okens.
    
> =E2=80=94=E2=80=94
    
> 
    
> In my observation, discouraging implicit seems to be the less controve=
rsial issue.
    
> 
    
> =E2=80=9Eor any other response type causing the authorization server t=
o issue an access token in the authorization response.=E2=80=9C in the 3rd =
paragraph caused discussions because it suggests to discourage developers f=
rom using ANY response type issuing access tokens in the authorization resp=
onse. This includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=
=E2=80=9C, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token id_token=
=E2=80=9C, where at least=C2=A0 =E2=80=9Etoken id_token=E2=80=9C is used in=
 the wild to implement SPAs.
    
> 
    
> Why did we come up with this proposal given at least =E2=80=9Etoken id=
_token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against=
 injection?
    
> 
    
> Two reasons: 
    
> 
    
> 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constraine=
d tokens. Also use of refresh tokens to frequently issue new live-time and =
privilege restricted access tokens is not supported. =E2=80=9Ecode token id=
_token=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce fo=
r achieving the same goal.
    
> 
    
> 2) Protection against token leakage is rather thin and fragile. There =
is just a single line of defense (CSP, open redirection prevention, browser=
 history manipulation) implemented by the client. 
    
> 
    
> Daniel and I collected some more information and argument at https://github.com/tloddersted=
t/oauth2_spa/blob/master/README.md that you might like to give a read.<=
br>
> 
    
> My conclusion after 2 weeks of intensive discussions with SPA develope=
rs (mostly on twitter): code+pkce is the more secure, simpler, and more ver=
satile approach to (also) implement SPAs. I prefer to approach developers w=
ith a clean and robust message instead of a lengthy description of what nee=
ds to go right in order to secure a SPA using OAuth. That=E2=80=99s why I t=
hink code+pkce should be the recommendation of our working group.
    
> 
    
> So please vote in favor of our proposal. I think that=E2=80=99s a huge=
 improvement for OAuth.
    
> 
    
> kind regards, 
    
> Torsten. 
    
> 
    
> 
    
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zan=
dbelt@zmartzone.eu>:
    
> > 
    
> > I strongly support the recommendation of using code instead of im=
plicit. I do so based on my own experience in the field [1] and stick to th=
at also after reading the comments and (what I would call) workarounds on t=
his thread.
    
> > 
    
> > Hans.
    
> > 
    
> > [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect=
-for-single-page-applications/
    
> > 
    
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <to=
rsten@lodderstedt.net> wrote:
    
> > that=E2=80=99s certainly true, but that might by a web server wit=
h static content only.
    
> > 
    
> > If the server is a real backend, there is even less reasons to us=
e a implicit or hybrid. No even a performance gain in comparison to code.
> > 
    
> > Am 21..11.2018 um 14:24 schrieb George Fletcher <gffletch@aol.co=
m>:
    
> > 
    
> >> An SPA has a backend because it has to be loaded from somewhe=
re :)
    
> >> 
    
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
    
> >>> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/10648545076=
06208513
    
> >>> 
    
> >>> 
    
> >>> Outcome is POST requires a backend to receive the request=
 so it=E2=80=99s not a viable solution for SPAs.
    
> >>> 
    
> >>> 
    
> >>>> Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb=
@ve7jtb.com>
    
> >>>> :
    
> >>>> 
    
> >>>> Post response works OK for server based clients.=C2=
=A0 I don't think POST works for single page applications.=C2=A0 
    
> >>>> 
    
> >>>> Basically that would be something more like postmessa=
ge between two JS apps.=C2=A0 
    
> >>>> 
    
> >>>> Postmessage also has security issues passing a access=
 token and leaking.=C2=A0 
    
> >>>> 
    
> >>>> Perhaps someone more familiar with SPA can comment on=
 POST.=C2=A0 
    
> >>>> 
    
> >>>> John B. 
    
> >>>> 
    
> >>>> 
    
> >>>> 
    
> >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
> >>>> gffletch@aol.com
    
> >>>>=C2=A0 wrote:
    
> >>>> Hi Mike,
    
> >>>> 
    
> >>>> The Form Post Response Mode keeps the access_token ou=
t of the URL, but it doesn't prevent the token from traversing through =
the browser. So a man-in-the-browser attack may be able to intercept the va=
lues. It should help with leakage in logs.
    
> >>>> 
    
> >>>> Thanks,
    
> >>>> George
    
> >>>> 
    
> >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
    
> >>>> 
    
> >>>>> Next question =E2=80=93 doesn=E2=80=99t using the=
 Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> >>>>>=C2=A0 mitigate the threats you=E2=80=99re describ=
ing below John?=C2=A0 If so, I believe the Security Topics draft should say=
 this.
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> I believe we owe it to readers to present the com=
plete picture, which is why I believe that describing profiles using ID Tok=
ens and the Form Post Response Mode are in scope.
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -=
- Mike
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>=C2=A0 On Behalf Of John Bradley
    
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
    
> >>>>> To: 
    
> >>>>> oauth@ietf.org
    
> >>>>> 
    
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- =
Recommend authorization code instead of implicit
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> Yes the at_hash protects the client from acceptin=
g an injected AT. 
    
> >>>>> 
    
> >>>>> Unfortunately it doesn't do anything to prote=
ct against leakage in logs or redirects.
    
> >>>>> 
    
> >>>>> So without the AT using some sort of POP mechanis=
m it is hard to say sending it in a redirect is a good security practice.
> >>>>> 
    
> >>>>> John B.
    
> >>>>> 
    
> >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:=

    
> >>>>> 
    
> >>>>> Hi Mike, 
    
> >>>>>=C2=A0 
    
> >>>>> I agree that OIDC hybrid flows offer additional s=
ecurity over the OAuth implicit grant and are used in the wild. On my slide=
s and in the initial version of the new section, we had included the hybrid=
 OIDC flows because of their known token injection countermeasures.
    
> >>>>>=C2=A0 
    
> >>>>> I nevertheless feel very uncomfortable to recomme=
nd those flows and any flow issuing access tokens in the front channel. In =
the course of the detailed review of the new text we realized two issues: <=
br>
> >>>>>=C2=A0 
    
> >>>>> 1) Since the access token is exposed in the URL, =
such flows possess a significantly higher risk to leak the access token (e.=
g. through browser history, open redirection and even referrer headers) tha=
n the code grant.
    
> >>>>> 2) There is no viable way to sender constrain acc=
ess tokens issued in the front channel. Given the WG decided to recommend u=
se of sender constraint tokens (
    
> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-=
09#section-2...2
    
> >>>>> ), it seems contradictory to recommend response t=
ypes not supporting such an approach. 
    
> >>>>>=C2=A0 
    
> >>>>> kind regards,
    
> >>>>> Torsten. 
    
> >>>>>=C2=A0 
    
> >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
    
> >>>>> <Michael.Jones=3D40microsoft.com@=
dmarc.ietf.org>
    
> >>>>> :
    
> >>>>>=C2=A0 
    
> >>>>> This description of the situation is an oversimpl=
ification..=C2=A0 OpenID Connect secures the implicit flow against token in=
jection attacks by including the at_hash (access token hash) in the ID Toke=
n, enabling the client to validate that the access token was created by the=
 issuer in the ID Token (which is also the OAuth Issuer, as described in RF=
C 8414).=C2=A0 (Note that this mitigation was described in draft-ietf-oauth=
-mix-up-mitigation.)
    
> >>>>>=C2=A0 
    
> >>>>> Given the prevalence of this known-good solution =
for securing the implicit flow, I would request that the draft be updated t=
o describe this mitigation.=C2=A0 At the same time, I=E2=80=99m fine with t=
he draft recommending the code flow over the implicit flow when this mitiga=
tion is not used.
    
> >>>>>=C2=A0 
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you,
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
    
> >>>>>=C2=A0 
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>=C2=A0 On Behalf Of Hannes Tschofenig
    
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
    
> >>>>> To: oauth 
    
> >>>>> <oauth@ietf.org>
    
> >>>>> 
    
> >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Reco=
mmend authorization code instead of implicit
    
> >>>>>=C2=A0 
    
> >>>>> Hi all,
    
> >>>>>=C2=A0 
    
> >>>>> The authors of the OAuth Security Topics draft ca=
me to the conclusion that it is not possible to adequately secure the impli=
cit flow against token injection since potential solutions like token bindi=
ng or JARM are in an early stage of adoption. For this reason, and since CO=
RS allows browser-based apps to send requests to the token endpoint, Torste=
n suggested to use the authorization code instead of the implicit grant in =
call cases in his presentation (seehttps://
    
> >>>>> datatracker.ietf.org/meeting/1=
03/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01=

    
> >>>>> ).
    
> >>>>>=C2=A0 
    
> >>>>> A hum in the room at IETF#103 concluded strong su=
pport for his recommendations. We would like to confirm the discussion on t=
he list.
    
> >>>>>=C2=A0 
    
> >>>>> Please provide a response by December 3rd.
    
> >>>>>=C2=A0 
    
> >>>>> Ciao
    
> >>>>> Hannes & Rifaat
    
> >>>>>=C2=A0 
    
> >>>>> IMPORTANT NOTICE: The contents of this email and =
any attachments are confidential and may also be privileged. If you are not=
 the intended recipient, please notify the sender immediately and do not di=
sclose the contents to any other person, use it for any purpose, or store o=
r copy the information in any medium. Thank you.
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org=
/mailman/listinfo/oauth
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> _______________________________________________
> >>>>> 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/listinf=
o/oauth
    
> > 
    
> > 
    
> > -- 
    
> > hans.zandbelt@zmartzone.eu
    
> > ZmartZone IAM - www.zmartzone.eu
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org
    
> https://www.ietf.org/mailman/listinfo/oau=
th
    

    

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

    

--000000000000473f46057b8371ad--


From nobody Sun Nov 25 13:44:03 2018
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 3D9DF129C6A for ; Sun, 25 Nov 2018 13:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 2uQXljeiAW76 for ; Sun, 25 Nov 2018 13:43:57 -0800 (PST)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2EC12426E for ; Sun, 25 Nov 2018 13:43:56 -0800 (PST)
Received: by mail-it1-x134.google.com with SMTP id i7so25388885iti.2 for ; Sun, 25 Nov 2018 13:43:56 -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=rikJI+9JcZwe4Bms5DzHQjugN/YNdyfd6AD8jWyuKp4=; b=vcGY9FXIRt9ym1nVjiD7D9HrIndsrve10kEyup7eJJiC4j2HURmfebvXuWfV4zgC3K BJDDVT4VU4f5Gyz2CuvWrXbvey2Qq4/PiPmRyFrj5DWYhK7KaEmWfIn8ssaJRsqP39jV VjHpcPDeXgP4Nf4mSOvwmX2Nl8UfZKjLBPBC73kSEIKb9eGwFcevVwpsI82gAe76nEU0 P5xzBRPy5rGihLOEI4iWMbIAv1v6otI6TJoKljv6ar1nBQZsNH/2xylyUF8Uzum7VxV2 105P4PeJVyMPN8soqKm0qvPaWfAauvJ+ZrQheXdWD3brTRhjNlZhn09pwdtLKaBVxi+k xKqA==
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=rikJI+9JcZwe4Bms5DzHQjugN/YNdyfd6AD8jWyuKp4=; b=ce6G8b+3R2PG62BhCPuM2Cg5wzbzWcx5nkXqGiEEiCAx0Xra4puIBHgcWRTdHS3Z4h JSWnAgSG+00XplrAD03YNoPY67A+gWOWYUuTXDL+NpZGaVLkheHk68m6ZX6wKNhCa98S YTJj7X5fbPn2+lIkZynTG6kYjHm5ZvmULQ758PaGE6TyzueASv0NYmCcxsZmadAtXShm ziXlShv2tgLxnrNPacMqvF+WqqcWr88FtYTxf+7erftXmAwLiZwFkUN9SsenqyJlN0nm GRSIMmFNboYDexan/sTkcjC3SmSwU+bip5srpfMv5Fk6tGYzd7sVvD0kcOYRHdC/PMfp 00RA==
X-Gm-Message-State: AA+aEWZ0HmfQtvhPyBhkttBMiiOm4socljbzn5FFfPREbFmWewg/mDq8 pTzYXpUPnRz/W0l6n5UISecVwwZvEDBfPG6riGnqlw==
X-Google-Smtp-Source: AFSGD/U2K46LOQZH2zrankeGdSKmIBtXt+WyfgJoBwBPWiupvMQG/hJZpi7Mjd8iR4LxjIeQ1vIYaNaGKjf4q3vS9wA=
X-Received: by 2002:a24:76d0:: with SMTP id z199mr9066964itb.165.1543182235964;  Sun, 25 Nov 2018 13:43:55 -0800 (PST)
MIME-Version: 1.0
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>  <465F5F67-E2FB-4A6B-B7AD-D1402FE7AD60@lodderstedt.net>  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Sun, 25 Nov 2018 16:43:44 -0500
Message-ID: 
To: John Bradley 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="000000000000ff994c057b841cbf"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 25 Nov 2018 21:44:01 -0000

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

Thanks John!

Would you be able to create a new errata report about this?

Regards,
 Rifaat


On Sun, Nov 25, 2018 at 3:55 PM John Bradley  wrote:

> There is no such thing as a implicit confidential client.
>
> Implicit clients are not authenticated, so are not confidential.
>
> You could have a hybrid client using the "code token" response type that
> is confidential for the code flow but i don't think anyone would consider
> the token returned from the authorization endpoint as confidential.
>
> That should have been hybrid rather than confidential I suspect.  Perhaps
> a errata could be looked at.
>
> John B.
>
>
> On Sun, Nov 25, 2018, 4:55 PM Rifaat Shekh-Yusef  wrote:
>
>> RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public
>> clients:
>>
>> 3.1.2.2 .  Registra=
tion Requirements
>>
>>    The authorization server MUST require the following clients to
>>
>>    register their redirection endpoint:
>>
>>    o  Public clients.
>>
>> *   o  Confidential clients utilizing the implicit grant type..*
>>
>>
>>
>> I do not know if anybody is using Implicit with Confidential clients, bu=
t
>> just in case, you might want to make it clear that your recommendations =
are
>> specifically for public clients.
>>
>> Regards,
>>  Rifaat
>>
>>
>>
>>
>> On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>>
>>> Hi Rifaat,
>>>
>>> this is a recommendation to anyone using implicit now. Implicit can onl=
y
>>> be used with public clients, so one could interpret it that way. I coul=
d
>>> also envision a SPA to use a backend, which in turn is a confidential
>>> client. There were some posts about this topic on the list recently.
>>>
>>> Does this answer your question?
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> > Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <
>>> rifaat.ietf@gmail.com>:
>>> >
>>> > Hi Torsten,
>>> >
>>> > I am assuming that these recommendations are mainly for Public
>>> Clients, not Confidential Clients; is that correct?
>>> >
>>> > Regards,
>>> >  Rifaat
>>> >
>>> >
>>> > On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>> > Hi all,
>>> >
>>> > I would like to state again what the proposal of the authors of the
>>> Security BCP is:
>>> >
>>> > Here is the respective text from the draft:
>>> >
>>> > =E2=80=94=E2=80=94
>>> >
>>> > 2.1.2.  Implicit Grant
>>> >
>>> >    The implicit grant (response type "token") and other response type=
s
>>> >    causing the authorization server to issue access tokens in the
>>> >    authorization response are vulnerable to access token leakage and
>>> >    access token replay as described in Section 3.1, Section 3.2,
>>> Section 3.3, and Section 3.6.
>>> >
>>> >    Moreover, no viable mechanism exists to cryptographically bind
>>> access
>>> >    tokens issued in the authorization response to a certain client as
>>> it
>>> >    is recommended in Section 2.2.  This makes replay detection for su=
ch
>>> >    access tokens at resource servers impossible.
>>> >
>>> >    In order to avoid these issues, Clients SHOULD NOT use the implici=
t
>>> >    grant or any other response type causing the authorization server =
to
>>> >    issue an access token in the authorization response.
>>> >
>>> >    Clients SHOULD instead use the response type "code" (aka
>>> >    authorization code grant type) as specified in Section 2.1.1 or an=
y
>>> >    other response type that causes the authorization server to issue
>>> >    access tokens in the token response.  This allows the authorizatio=
n
>>> >    server to detect replay attempts and generally reduces the attack
>>> >    surface since access tokens are not exposed in URLs.  It also allo=
ws
>>> >    the authorization server to sender-constrain the issued tokens.
>>> > =E2=80=94=E2=80=94
>>> >
>>> > In my observation, discouraging implicit seems to be the less
>>> controversial issue.
>>> >
>>> > =E2=80=9Eor any other response type causing the authorization server =
to issue
>>> an access token in the authorization response.=E2=80=9C in the 3rd para=
graph caused
>>> discussions because it suggests to discourage developers from using ANY
>>> response type issuing access tokens in the authorization response. This
>>> includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=9C=
, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token
>>> id_token=E2=80=9C, where at least  =E2=80=9Etoken id_token=E2=80=9C is =
used in the wild to
>>> implement SPAs.
>>> >
>>> > Why did we come up with this proposal given at least =E2=80=9Etoken i=
d_token=E2=80=9C
>>> & =E2=80=9Ecode token id_token=E2=80=9C protect against injection?
>>> >
>>> > Two reasons:
>>> >
>>> > 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrain=
ed tokens. Also
>>> use of refresh tokens to frequently issue new live-time and privilege
>>> restricted access tokens is not supported. =E2=80=9Ecode token id_token=
=E2=80=9C seems more
>>> complex than just =E2=80=9Ecode=E2=80=9C+pkce for achieving the same go=
al.
>>> >
>>> > 2) Protection against token leakage is rather thin and fragile. There
>>> is just a single line of defense (CSP, open redirection prevention, bro=
wser
>>> history manipulation) implemented by the client.
>>> >
>>> > Daniel and I collected some more information and argument at
>>> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that
>>> you might like to give a read.
>>> >
>>> > My conclusion after 2 weeks of intensive discussions with SPA
>>> developers (mostly on twitter): code+pkce is the more secure, simpler, =
and
>>> more versatile approach to (also) implement SPAs. I prefer to approach
>>> developers with a clean and robust message instead of a lengthy descrip=
tion
>>> of what needs to go right in order to secure a SPA using OAuth. That=E2=
=80=99s why
>>> I think code+pkce should be the recommendation of our working group.
>>> >
>>> > So please vote in favor of our proposal. I think that=E2=80=99s a hug=
e
>>> improvement for OAuth.
>>> >
>>> > kind regards,
>>> > Torsten.
>>> >
>>> >
>>> > > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <
>>> hans.zandbelt@zmartzone.eu>:
>>> > >
>>> > > I strongly support the recommendation of using code instead of
>>> implicit. I do so based on my own experience in the field [1] and stick=
 to
>>> that also after reading the comments and (what I would call) workaround=
s on
>>> this thread.
>>> > >
>>> > > Hans.
>>> > >
>>> > > [1]
>>> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single=
-page-applications/
>>> > >
>>> > > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>> > > that=E2=80=99s certainly true, but that might by a web server with =
static
>>> content only.
>>> > >
>>> > > If the server is a real backend, there is even less reasons to use =
a
>>> implicit or hybrid. No even a performance gain in comparison to code.
>>> > >
>>> > > Am 21..11.2018 um 14:24 schrieb George Fletcher :
>>> > >
>>> > >> An SPA has a backend because it has to be loaded from somewhere :)
>>> > >>
>>> > >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>>> > >>> We had a discussion about this topic on Twitter
>>> https://twitter.com/Apl3b/status/1064854507606208513
>>> > >>>
>>> > >>>
>>> > >>> Outcome is POST requires a backend to receive the request so it=
=E2=80=99s
>>> not a viable solution for SPAs.
>>> > >>>
>>> > >>>
>>> > >>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
>>> > >>>> :
>>> > >>>>
>>> > >>>> Post response works OK for server based clients.  I don't think
>>> POST works for single page applications.
>>> > >>>>
>>> > >>>> Basically that would be something more like postmessage between
>>> two JS apps.
>>> > >>>>
>>> > >>>> Postmessage also has security issues passing a access token and
>>> leaking.
>>> > >>>>
>>> > >>>> Perhaps someone more familiar with SPA can comment on POST.
>>> > >>>>
>>> > >>>> John B.
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> > >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
>>> > >>>> gffletch@aol.com
>>> > >>>>  wrote:
>>> > >>>> Hi Mike,
>>> > >>>>
>>> > >>>> The Form Post Response Mode keeps the access_token out of the
>>> URL, but it doesn't prevent the token from traversing through the brows=
er.
>>> So a man-in-the-browser attack may be able to intercept the values. It
>>> should help with leakage in logs.
>>> > >>>>
>>> > >>>> Thanks,
>>> > >>>> George
>>> > >>>>
>>> > >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>>> > >>>>
>>> > >>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Res=
ponse Mode
>>> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>> > >>>>>  mitigate the threats you=E2=80=99re describing below John?  If=
 so, I
>>> believe the Security Topics draft should say this.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> I believe we owe it to readers to present the complete picture,
>>> which is why I believe that describing profiles using ID Tokens and the
>>> Form Post Response Mode are in scope.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>                                                        -- Mike
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> From: OAuth
>>> > >>>>> 
>>> > >>>>>  On Behalf Of John Bradley
>>> > >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>>> > >>>>> To:
>>> > >>>>> oauth@ietf.org
>>> > >>>>>
>>> > >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend
>>> authorization code instead of implicit
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Yes the at_hash protects the client from accepting an injected
>>> AT.
>>> > >>>>>
>>> > >>>>> Unfortunately it doesn't do anything to protect against leakage
>>> in logs or redirects.
>>> > >>>>>
>>> > >>>>> So without the AT using some sort of POP mechanism it is hard t=
o
>>> say sending it in a redirect is a good security practice.
>>> > >>>>>
>>> > >>>>> John B.
>>> > >>>>>
>>> > >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>> > >>>>>
>>> > >>>>> Hi Mike,
>>> > >>>>>
>>> > >>>>> I agree that OIDC hybrid flows offer additional security over
>>> the OAuth implicit grant and are used in the wild. On my slides and in =
the
>>> initial version of the new section, we had included the hybrid OIDC flo=
ws
>>> because of their known token injection countermeasures.
>>> > >>>>>
>>> > >>>>> I nevertheless feel very uncomfortable to recommend those flows
>>> and any flow issuing access tokens in the front channel. In the course =
of
>>> the detailed review of the new text we realized two issues:
>>> > >>>>>
>>> > >>>>> 1) Since the access token is exposed in the URL, such flows
>>> possess a significantly higher risk to leak the access token (e.g. thro=
ugh
>>> browser history, open redirection and even referrer headers) than the c=
ode
>>> grant.
>>> > >>>>> 2) There is no viable way to sender constrain access tokens
>>> issued in the front channel. Given the WG decided to recommend use of
>>> sender constraint tokens (
>>> > >>>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section=
-2...2
>>> > >>>>> ), it seems contradictory to recommend response types not
>>> supporting such an approach.
>>> > >>>>>
>>> > >>>>> kind regards,
>>> > >>>>> Torsten.
>>> > >>>>>
>>> > >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones
>>> > >>>>> >> <40microsoft..com@dmarc.ietf.org>>
>>> > >>>>> :
>>> > >>>>>
>>> > >>>>> This description of the situation is an oversimplification..
>>> OpenID Connect secures the implicit flow against token injection attack=
s by
>>> including the at_hash (access token hash) in the ID Token, enabling the
>>> client to validate that the access token was created by the issuer in t=
he
>>> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (=
Note
>>> that this mitigation was described in draft-ietf-oauth-mix-up-mitigatio=
n.)
>>> > >>>>>
>>> > >>>>> Given the prevalence of this known-good solution for securing
>>> the implicit flow, I would request that the draft be updated to describ=
e
>>> this mitigation.  At the same time, I=E2=80=99m fine with the draft rec=
ommending
>>> the code flow over the implicit flow when this mitigation is not used.
>>> > >>>>>
>>> > >>>>>
>>>  Thank you,
>>> > >>>>>
>>>  -- Mike
>>> > >>>>>
>>> > >>>>> From: OAuth
>>> > >>>>> 
>>> > >>>>>  On Behalf Of Hannes Tschofenig
>>> > >>>>> Sent: Monday, November 19, 2018 2:34 AM
>>> > >>>>> To: oauth
>>> > >>>>> 
>>> > >>>>>
>>> > >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend
>>> authorization code instead of implicit
>>> > >>>>>
>>> > >>>>> Hi all,
>>> > >>>>>
>>> > >>>>> The authors of the OAuth Security Topics draft came to the
>>> conclusion that it is not possible to adequately secure the implicit fl=
ow
>>> against token injection since potential solutions like token binding or
>>> JARM are in an early stage of adoption. For this reason, and since CORS
>>> allows browser-based apps to send requests to the token endpoint, Torst=
en
>>> suggested to use the authorization code instead of the implicit grant i=
n
>>> call cases in his presentation (seehttps://
>>> > >>>>>
>>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft=
-ietf-oauth-security-topics-01
>>> > >>>>> ).
>>> > >>>>>
>>> > >>>>> A hum in the room at IETF#103 concluded strong support for his
>>> recommendations. We would like to confirm the discussion on the list.
>>> > >>>>>
>>> > >>>>> Please provide a response by December 3rd.
>>> > >>>>>
>>> > >>>>> Ciao
>>> > >>>>> Hannes & Rifaat
>>> > >>>>>
>>> > >>>>> IMPORTANT NOTICE: The contents of this email and any attachment=
s
>>> are confidential and may also be privileged. If you are not the intende=
d
>>> recipient, please 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.
>>> > >>>>> _______________________________________________
>>> > >>>>> 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
>>> > >
>>> > >
>>> > > --
>>> > > hans.zandbelt@zmartzone.eu
>>> > > ZmartZone IAM - www.zmartzone.eu
>>> >
>>> > _______________________________________________
>>> > 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
>>
>

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


    Thanks John!

    Would you be able to creat=
e a new errata report about this?

    Regards,
    =C2=A0Rifaat


    There is no such thing a=
s a implicit confidential client.=C2=A0=C2=A0

    Implicit clients are not authenticated, so are not confiden=
tial.=C2=A0

    You could ha=
ve a hybrid client using the "code token" response type that is c=
onfidential for the code flow but i don't think anyone would consider t=
he token returned from the authorization endpoint as confidential.=C2=A0

    That should have been hybr=
id rather than confidential I suspect.=C2=A0 Perhaps a errata could be look=
ed at.=C2=A0=C2=A0

    John =
B.=C2=A0


    On Sun, N=
ov 25, 2018, 4:55 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com wrote:
    RFC6749, Section 3.1.2.2, implie=
s that Implicit is not limited to public clients:

    3.1.2.2.  Registration Requireme=
nts
       The authorization server MUST require the following client=
s to
       register their redirection endp=
oint:
       o  Public client=
s.
       o  Confidential clients utilizing the implicit grant type..


    I do not k=
now if anybody is using Implicit with Confidential clients, but just in cas=
e, you might want to make it clear that your recommendations are specifical=
ly for public clients.

    Regards,
    =C2=A0Ri=
faat




    On Sun, Nov 25, 2018 at 1:41 PM Torsten L=
odderstedt <torsten@lodderstedt.net> wrote:
    Hi Rifaat,
    

    
this is a recommendation to anyone using implicit now. Implicit can only be=
 used with public clients, so one could interpret it that way. I could also=
 envision a SPA to use a backend, which in turn is a confidential client. T=
here were some posts about this topic on the list recently. 
    

    
Does this answer your question?
    

    
kind regards,
    
Torsten. 
    

    
> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <rifaat.ietf@g=
mail.com>:
    
> 
    
> Hi Torsten,
    
> 
    
> I am assuming that these recommendations are mainly for Public Clients=
, not Confidential Clients; is that correct?
    
> 
    
> Regards,
    
>=C2=A0 Rifaat
    
> 
    
> 
    
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <torsten@=
lodderstedt.net> wrote:
    
> Hi all, 
    
> 
    
> I would like to state again what the proposal of the authors of the Se=
curity BCP is:
    
> 
    
> Here is the respective text from the draft:
    
> 
    
> =E2=80=94=E2=80=94
    
> 
    
> 2.1.2.=C2=A0 Implicit Grant
    
> 
    
>=C2=A0 =C2=A0 The implicit grant (response type "token") and =
other response types
    
>=C2=A0 =C2=A0 causing the authorization server to issue access tokens i=
n the
    
>=C2=A0 =C2=A0 authorization response are vulnerable to access token lea=
kage and
    
>=C2=A0 =C2=A0 access token replay as described in Section 3.1, Section =
3.2, Section 3.3, and Section 3.6.
    
> 
    
>=C2=A0 =C2=A0 Moreover, no viable mechanism exists to cryptographically=
 bind access
    
>=C2=A0 =C2=A0 tokens issued in the authorization response to a certain =
client as it
    
>=C2=A0 =C2=A0 is recommended in Section 2.2.=C2=A0 This makes replay de=
tection for such
    
>=C2=A0 =C2=A0 access tokens at resource servers impossible.
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant or any other response type causing the authorizatio=
n server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response.
    
> 
    
>=C2=A0 =C2=A0 Clients SHOULD instead use the response type "code&q=
uot; (aka
    
>=C2=A0 =C2=A0 authorization code grant type) as specified in Section 2.=
1.1 or any
    
>=C2=A0 =C2=A0 other response type that causes the authorization server =
to issue
    
>=C2=A0 =C2=A0 access tokens in the token response.=C2=A0 This allows th=
e authorization
    
>=C2=A0 =C2=A0 server to detect replay attempts and generally reduces th=
e attack
    
>=C2=A0 =C2=A0 surface since access tokens are not exposed in URLs.=C2=
=A0 It also allows
    
>=C2=A0 =C2=A0 the authorization server to sender-constrain the issued t=
okens.
    
> =E2=80=94=E2=80=94
    
> 
    
> In my observation, discouraging implicit seems to be the less controve=
rsial issue.
    
> 
    
> =E2=80=9Eor any other response type causing the authorization server t=
o issue an access token in the authorization response.=E2=80=9C in the 3rd =
paragraph caused discussions because it suggests to discourage developers f=
rom using ANY response type issuing access tokens in the authorization resp=
onse. This includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=
=E2=80=9C, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token id_token=
=E2=80=9C, where at least=C2=A0 =E2=80=9Etoken id_token=E2=80=9C is used in=
 the wild to implement SPAs.
    
> 
    
> Why did we come up with this proposal given at least =E2=80=9Etoken id=
_token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against=
 injection?
    
> 
    
> Two reasons: 
    
> 
    
> 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constraine=
d tokens. Also use of refresh tokens to frequently issue new live-time and =
privilege restricted access tokens is not supported. =E2=80=9Ecode token id=
_token=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce fo=
r achieving the same goal.
    
> 
    
> 2) Protection against token leakage is rather thin and fragile. There =
is just a single line of defense (CSP, open redirection prevention, browser=
 history manipulation) implemented by the client. 
    
> 
    
> Daniel and I collected some more information and argument at https://github.com/tloddersted=
t/oauth2_spa/blob/master/README.md that you might like to give a read.<=
br>
> 
    
> My conclusion after 2 weeks of intensive discussions with SPA develope=
rs (mostly on twitter): code+pkce is the more secure, simpler, and more ver=
satile approach to (also) implement SPAs. I prefer to approach developers w=
ith a clean and robust message instead of a lengthy description of what nee=
ds to go right in order to secure a SPA using OAuth. That=E2=80=99s why I t=
hink code+pkce should be the recommendation of our working group.
    
> 
    
> So please vote in favor of our proposal. I think that=E2=80=99s a huge=
 improvement for OAuth.
    
> 
    
> kind regards, 
    
> Torsten. 
    
> 
    
> 
    
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zan=
dbelt@zmartzone.eu>:
    
> > 
    
> > I strongly support the recommendation of using code instead of im=
plicit. I do so based on my own experience in the field [1] and stick to th=
at also after reading the comments and (what I would call) workarounds on t=
his thread.
    
> > 
    
> > Hans.
    
> > 
    
> > [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect=
-for-single-page-applications/
    
> > 
    
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <to=
rsten@lodderstedt.net> wrote:
    
> > that=E2=80=99s certainly true, but that might by a web server wit=
h static content only.
    
> > 
    
> > If the server is a real backend, there is even less reasons to us=
e a implicit or hybrid. No even a performance gain in comparison to code.
> > 
    
> > Am 21..11.2018 um 14:24 schrieb George Fletcher <gffletch@aol.co=
m>:
    
> > 
    
> >> An SPA has a backend because it has to be loaded from somewhe=
re :)
    
> >> 
    
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
    
> >>> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/10648545076=
06208513
    
> >>> 
    
> >>> 
    
> >>> Outcome is POST requires a backend to receive the request=
 so it=E2=80=99s not a viable solution for SPAs.
    
> >>> 
    
> >>> 
    
> >>>> Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb=
@ve7jtb.com>
    
> >>>> :
    
> >>>> 
    
> >>>> Post response works OK for server based clients.=C2=
=A0 I don't think POST works for single page applications.=C2=A0 
    
> >>>> 
    
> >>>> Basically that would be something more like postmessa=
ge between two JS apps.=C2=A0 
    
> >>>> 
    
> >>>> Postmessage also has security issues passing a access=
 token and leaking.=C2=A0 
    
> >>>> 
    
> >>>> Perhaps someone more familiar with SPA can comment on=
 POST.=C2=A0 
    
> >>>> 
    
> >>>> John B. 
    
> >>>> 
    
> >>>> 
    
> >>>> 
    
> >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
> >>>> gffletch@aol.com
    
> >>>>=C2=A0 wrote:
    
> >>>> Hi Mike,
    
> >>>> 
    
> >>>> The Form Post Response Mode keeps the access_token ou=
t of the URL, but it doesn't prevent the token from traversing through =
the browser. So a man-in-the-browser attack may be able to intercept the va=
lues. It should help with leakage in logs.
    
> >>>> 
    
> >>>> Thanks,
    
> >>>> George
    
> >>>> 
    
> >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
    
> >>>> 
    
> >>>>> Next question =E2=80=93 doesn=E2=80=99t using the=
 Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> >>>>>=C2=A0 mitigate the threats you=E2=80=99re describ=
ing below John?=C2=A0 If so, I believe the Security Topics draft should say=
 this.
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> I believe we owe it to readers to present the com=
plete picture, which is why I believe that describing profiles using ID Tok=
ens and the Form Post Response Mode are in scope.
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -=
- Mike
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>=C2=A0 On Behalf Of John Bradley
    
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
    
> >>>>> To: 
    
> >>>>> oauth@ietf.org
    
> >>>>> 
    
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- =
Recommend authorization code instead of implicit
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> Yes the at_hash protects the client from acceptin=
g an injected AT. 
    
> >>>>> 
    
> >>>>> Unfortunately it doesn't do anything to prote=
ct against leakage in logs or redirects.
    
> >>>>> 
    
> >>>>> So without the AT using some sort of POP mechanis=
m it is hard to say sending it in a redirect is a good security practice.
> >>>>> 
    
> >>>>> John B.
    
> >>>>> 
    
> >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:=

    
> >>>>> 
    
> >>>>> Hi Mike, 
    
> >>>>>=C2=A0 
    
> >>>>> I agree that OIDC hybrid flows offer additional s=
ecurity over the OAuth implicit grant and are used in the wild. On my slide=
s and in the initial version of the new section, we had included the hybrid=
 OIDC flows because of their known token injection countermeasures.
    
> >>>>>=C2=A0 
    
> >>>>> I nevertheless feel very uncomfortable to recomme=
nd those flows and any flow issuing access tokens in the front channel. In =
the course of the detailed review of the new text we realized two issues: <=
br>
> >>>>>=C2=A0 
    
> >>>>> 1) Since the access token is exposed in the URL, =
such flows possess a significantly higher risk to leak the access token (e.=
g. through browser history, open redirection and even referrer headers) tha=
n the code grant.
    
> >>>>> 2) There is no viable way to sender constrain acc=
ess tokens issued in the front channel. Given the WG decided to recommend u=
se of sender constraint tokens (
    
> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-=
09#section-2...2
    
> >>>>> ), it seems contradictory to recommend response t=
ypes not supporting such an approach. 
    
> >>>>>=C2=A0 
    
> >>>>> kind regards,
    
> >>>>> Torsten. 
    
> >>>>>=C2=A0 
    
> >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
    
> >>>>> <Michael.Jones=3D40microsoft.com@=
dmarc.ietf.org>
    
> >>>>> :
    
> >>>>>=C2=A0 
    
> >>>>> This description of the situation is an oversimpl=
ification..=C2=A0 OpenID Connect secures the implicit flow against token in=
jection attacks by including the at_hash (access token hash) in the ID Toke=
n, enabling the client to validate that the access token was created by the=
 issuer in the ID Token (which is also the OAuth Issuer, as described in RF=
C 8414).=C2=A0 (Note that this mitigation was described in draft-ietf-oauth=
-mix-up-mitigation.)
    
> >>>>>=C2=A0 
    
> >>>>> Given the prevalence of this known-good solution =
for securing the implicit flow, I would request that the draft be updated t=
o describe this mitigation.=C2=A0 At the same time, I=E2=80=99m fine with t=
he draft recommending the code flow over the implicit flow when this mitiga=
tion is not used.
    
> >>>>>=C2=A0 
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you,
    
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
    
> >>>>>=C2=A0 
    
> >>>>> From: OAuth 
    
> >>>>> <oauth-bounces@ietf.org>
    
> >>>>>=C2=A0 On Behalf Of Hannes Tschofenig
    
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
    
> >>>>> To: oauth 
    
> >>>>> <oauth@ietf.org>
    
> >>>>> 
    
> >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Reco=
mmend authorization code instead of implicit
    
> >>>>>=C2=A0 
    
> >>>>> Hi all,
    
> >>>>>=C2=A0 
    
> >>>>> The authors of the OAuth Security Topics draft ca=
me to the conclusion that it is not possible to adequately secure the impli=
cit flow against token injection since potential solutions like token bindi=
ng or JARM are in an early stage of adoption. For this reason, and since CO=
RS allows browser-based apps to send requests to the token endpoint, Torste=
n suggested to use the authorization code instead of the implicit grant in =
call cases in his presentation (seehttps://
    
> >>>>> datatracker.ietf.org/meeting/1=
03/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01=

    
> >>>>> ).
    
> >>>>>=C2=A0 
    
> >>>>> A hum in the room at IETF#103 concluded strong su=
pport for his recommendations. We would like to confirm the discussion on t=
he list.
    
> >>>>>=C2=A0 
    
> >>>>> Please provide a response by December 3rd.
    
> >>>>>=C2=A0 
    
> >>>>> Ciao
    
> >>>>> Hannes & Rifaat
    
> >>>>>=C2=A0 
    
> >>>>> IMPORTANT NOTICE: The contents of this email and =
any attachments are confidential and may also be privileged. If you are not=
 the intended recipient, please notify the sender immediately and do not di=
sclose the contents to any other person, use it for any purpose, or store o=
r copy the information in any medium. Thank you.
    
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
    
> >>>>> 
    
> >>>>> OAuth@ietf.org
    
> >>>>> https://www.ietf.org=
/mailman/listinfo/oauth
    
> >>>>> 
    
> >>>>>=C2=A0 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> 
    
> >>>>> _______________________________________________
> >>>>> 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/listinf=
o/oauth
    
> > 
    
> > 
    
> > -- 
    
> > hans.zandbelt@zmartzone.eu
    
> > ZmartZone IAM - www.zmartzone.eu
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org
    
> https://www.ietf.org/mailman/listinfo/oau=
th
    

    

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

    

    

--000000000000ff994c057b841cbf--


From nobody Mon Nov 26 00:18:27 2018
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 B6C60126DBF for ; Mon, 26 Nov 2018 00:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Level: 
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.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 CecKWcMWstnw for ; Mon, 26 Nov 2018 00:18:15 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810051.outbound.protection.outlook.com [40.107.81.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF00130DE2 for ; Mon, 26 Nov 2018 00:18:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eA9swASa6tUlzZidxLH+ILClXJDWZUqldN5WBr8aAzg=; b=C2fYX0OaqVC+x5e49UC4XYNqyP1MGy54I0VpGAuDKpUYckHvdnop1sCEmXs0uc/fQNszSCDhTgshs8/L/PPQ0vUI5W7a4D/l2j8srX8tamFMjjjjuPaG9LL8/oF2Ozzg9FbNUGpX2CmmiJXq0gfRaYfBXHB9j3IlriPENG/EQBM=
Received: from SN6PR02MB5311.namprd02.prod.outlook.com (52.135.104.21) by SN6PR02MB5038.namprd02.prod.outlook.com (52.135.99.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.26; Mon, 26 Nov 2018 08:18:11 +0000
Received: from SN6PR02MB5311.namprd02.prod.outlook.com ([fe80::7474:a69c:7624:d996]) by SN6PR02MB5311.namprd02.prod.outlook.com ([fe80::7474:a69c:7624:d996%6]) with mapi id 15.20.1361.019; Mon, 26 Nov 2018 08:18:11 +0000
From: Antonio Sanso 
To: Torsten Lodderstedt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwAYRRbAABPdaIAAES+SAAAK3nrAAAF3OoAAAbNqgAAVmmqAAAmlbIAAICS4gACl6t6AAAvL3oAAHtrZhA==
Date: Mon, 26 Nov 2018 08:18:11 +0000
Message-ID: 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>  , <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
In-Reply-To: <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; 
x-originating-ip: [192.147.117.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR02MB5038; 6:OQKTkhfe5sI//oclUFXt0RcBMex/kemt/FP82ut6BLxmADoSLQ0O0orMjhiy/2uRSXCUe5KjGzeyd/AlBPmg7zBCrAKfvmNrnHvpeB1OPRHlW7kel6BHXIcKH6kqR8EPiWc3RnjDVIjyhCjK2P+gYhU7N7CB4UuV8dnGb6sa0t6JS/H6nPwWSmDFjKcSj5TMXBYiM3o8rBhHz+o9OZ/9opoCg8CZb5CwEBvkLn5HpmKYSqhc5PTX/DmIcs2dC2hNu4Vx34tCnuKYiy3WwZzvHwu0CgdTsA2D3d1vJpSHBOLHE17uq4eYFWGqmWW006e8vVEXkwfV73ivwibStbNHL2V1q05nYHKS5O3AvJdOH7C4AmOplneZ4pQSBjafZXfqxlzy0o81Pu6jhVlj78rbPq2pSJunILhteTNOdPL+eqF1QKpwRfUM8MAr3VveN1YBOGJPiLQk1CfDriAr2P56Zw==; 5:YxqjBgQ3t8LD0r2P3g+fZTURCjthREZ7rY2CgzvZ6IdHBIVlw5gXOkWbmyPPASlpjyLMFY8HEbxFMbeMoMwc62tutvbkgb3lk9ZM9pIQjMX393eIKvYs1HUc0MzbV35jIs9AjP28KGfGmHhjRkngcPXUSaU5rVLLRBPzK++hl5w=; 7:LqUNF0ud/PRip9xw24zCi2/sISBpaRwduUGKw8N6XWPtoWVWBowIx7I/CTnvPgTylnOH+fd0kFJX7bs5DsRs2I+LjH+9foFshq9z0rNyJYbVyiyfN5xaTPUXknATbtPGaAmK/E6Hw11za0/HottN1Q==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: adb2d279-078a-4410-3417-08d65377b499
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:SN6PR02MB5038; 
x-ms-traffictypediagnostic: SN6PR02MB5038:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231443)(944501410)(52105112)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:SN6PR02MB5038; BCL:0; PCL:0; RULEID:; SRVR:SN6PR02MB5038; 
x-forefront-prvs: 086831DFB4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(39860400002)(396003)(53754006)(40434004)(51444003)(199004)(189003)(74316002)(81156014)(81166006)(7736002)(316002)(786003)(2420400007)(8676002)(68736007)(53546011)(6506007)(26005)(186003)(966005)(15650500001)(76176011)(99286004)(25786009)(102836004)(86362001)(2906002)(4744004)(6436002)(606006)(71200400001)(5024004)(14444005)(256004)(105586002)(106356001)(14454004)(110136005)(19627405001)(66066001)(71190400001)(66574009)(93886005)(486006)(33656002)(6306002)(54896002)(446003)(11346002)(9686003)(53936002)(236005)(53386004)(10090500001)(6116002)(3846002)(8990500004)(6606003)(6246003)(7110500001)(229853002)(2501003)(476003)(478600001)(1680700002)(5660300001)(7696005)(8936002)(21615005)(55016002)(561944003)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR02MB5038; H:SN6PR02MB5311.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: KulkLX42cAVUtNIEv+YyVg0klVX3lHo/zbB4QPoDKVzAbjnKTM/uQZIUxC3Hd4xXYek0pr5PoVsWnoRNHG7hrvdIAYWt1ndiOWJRuSxepRfY6y8eVrIhHRGpt0INcly7ZDuhST5a1JKnoCps5EwD/6NjfcrFxIRM48kmJuHOVx2I1hw0+idaEp9lygX6OLBxf5IlLIO6tXgL1801Yfn9+7p14ffGy9sfNESFGApSUJPuB5xGeffbLVQGwMNN/4HAGgC6AWP6yNz169cyjgKdsHtnQOT9QZt3l+Fyxja5bun6Xv3PgmRco93GmwJh2bTGiamyeeiC+MbUHJ0ed0s8xbH6h5S02ICb5YlxicozKrk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN6PR02MB531161515693ADDE8A36AA3CD9D70SN6PR02MB5311namp_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-Network-Message-Id: adb2d279-078a-4410-3417-08d65377b499
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2018 08:18:11.4355 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5038
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 26 Nov 2018 08:18:25 -0000

--_000_SN6PR02MB531161515693ADDE8A36AA3CD9D70SN6PR02MB5311namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Torsten,


nice one. FWIW I am reallly happy to see this happening.

Quick question though. What is the recommendation about dealing with the cl=
ient secret in this situation?


regards


antonio

________________________________
From: OAuth  on behalf of Torsten Lodderstedt 
Sent: Sunday, November 25, 2018 6:32:53 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization co=
de instead of implicit

Hi all,

I would like to state again what the proposal of the authors of the Securit=
y BCP is:

Here is the respective text from the draft:

=97=97

2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2, Section 3.=
3, and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.
=97=97

In my observation, discouraging implicit seems to be the less controversial=
 issue.

=84or any other response type causing the authorization server to issue an =
access token in the authorization response.=93 in the 3rd paragraph caused =
discussions because it suggests to discourage developers from using ANY res=
ponse type issuing access tokens in the authorization response. This includ=
es OIDC=92s response types =84token id_token=93, =84code token=93 & =84code=
 token id_token=93, where at least  =84token id_token=93 is used in the wil=
d to implement SPAs.

Why did we come up with this proposal given at least =84token id_token=93 &=
 =84code token id_token=93 protect against injection?

Two reasons:

1) =84token id_token=93 does not support sender constrained tokens. Also us=
e of refresh tokens to frequently issue new live-time and privilege restric=
ted access tokens is not supported. =84code token id_token=93 seems more co=
mplex than just =84code=93+pkce for achieving the same goal.

2) Protection against token leakage is rather thin and fragile. There is ju=
st a single line of defense (CSP, open redirection prevention, browser hist=
ory manipulation) implemented by the client.

Daniel and I collected some more information and argument at https://github=
.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might like to g=
ive a read.

My conclusion after 2 weeks of intensive discussions with SPA developers (m=
ostly on twitter): code+pkce is the more secure, simpler, and more versatil=
e approach to (also) implement SPAs. I prefer to approach developers with a=
 clean and robust message instead of a lengthy description of what needs to=
 go right in order to secure a SPA using OAuth. That=92s why I think code+p=
kce should be the recommendation of our working group.

So please vote in favor of our proposal. I think that=92s a huge improvemen=
t for OAuth.

kind regards,
Torsten.


> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt =
:
>
> I strongly support the recommendation of using code instead of implicit. =
I do so based on my own experience in the field [1] and stick to that also =
after reading the comments and (what I would call) workarounds on this thre=
ad.
>
> Hans.
>
> [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-sing=
le-page-applications/
>
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt  wrote:
> that=92s certainly true, but that might by a web server with static conte=
nt only.
>
> If the server is a real backend, there is even less reasons to use a impl=
icit or hybrid. No even a performance gain in comparison to code.
>
> Am 21..11.2018 um 14:24 schrieb George Fletcher :
>
>> An SPA has a backend because it has to be loaded from somewhere :)
>>
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>>> We had a discussion about this topic on Twitter https://twitter.com/Apl=
3b/status/1064854507606208513
>>>
>>>
>>> Outcome is POST requires a backend to receive the request so it=92s not=
 a viable solution for SPAs.
>>>
>>>
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
>>>> :
>>>>
>>>> Post response works OK for server based clients.  I don't think POST w=
orks for single page applications.
>>>>
>>>> Basically that would be something more like postmessage between two JS=
 apps.
>>>>
>>>> Postmessage also has security issues passing a access token and leakin=
g.
>>>>
>>>> Perhaps someone more familiar with SPA can comment on POST.
>>>>
>>>> John B.
>>>>
>>>>
>>>>
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
>>>> gffletch@aol.com
>>>>  wrote:
>>>> Hi Mike,
>>>>
>>>> The Form Post Response Mode keeps the access_token out of the URL, but=
 it doesn't prevent the token from traversing through the browser. So a man=
-in-the-browser attack may be able to intercept the values. It should help =
with leakage in logs.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>>>>
>>>>> Next question =96 doesn=92t using the Form Post Response Mode https:/=
/openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>  mitigate the threats you=92re describing below John?  If so, I belie=
ve the Security Topics draft should say this.
>>>>>
>>>>>
>>>>>
>>>>> I believe we owe it to readers to present the complete picture, which=
 is why I believe that describing profiles using ID Tokens and the Form Pos=
t Response Mode are in scope.
>>>>>
>>>>>
>>>>>
>>>>>                                                        -- Mike
>>>>>
>>>>>
>>>>>
>>>>> From: OAuth
>>>>> 
>>>>>  On Behalf Of John Bradley
>>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>>>>> To:
>>>>> oauth@ietf.org
>>>>>
>>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorizat=
ion code instead of implicit
>>>>>
>>>>>
>>>>>
>>>>> Yes the at_hash protects the client from accepting an injected AT.
>>>>>
>>>>> Unfortunately it doesn't do anything to protect against leakage in lo=
gs or redirects.
>>>>>
>>>>> So without the AT using some sort of POP mechanism it is hard to say =
sending it in a redirect is a good security practice.
>>>>>
>>>>> John B.
>>>>>
>>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> I agree that OIDC hybrid flows offer additional security over the OAu=
th implicit grant and are used in the wild. On my slides and in the initial=
 version of the new section, we had included the hybrid OIDC flows because =
of their known token injection countermeasures.
>>>>>
>>>>> I nevertheless feel very uncomfortable to recommend those flows and a=
ny flow issuing access tokens in the front channel. In the course of the de=
tailed review of the new text we realized two issues:
>>>>>
>>>>> 1) Since the access token is exposed in the URL, such flows possess a=
 significantly higher risk to leak the access token (e.g. through browser h=
istory, open redirection and even referrer headers) than the code grant.
>>>>> 2) There is no viable way to sender constrain access tokens issued in=
 the front channel. Given the WG decided to recommend use of sender constra=
int tokens (
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#secti=
on-2...2
>>>>> ), it seems contradictory to recommend response types not supporting =
such an approach.
>>>>>
>>>>> kind regards,
>>>>> Torsten.
>>>>>
>>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones
>>>>> 
>>>>> :
>>>>>
>>>>> This description of the situation is an oversimplification..  OpenID =
Connect secures the implicit flow against token injection attacks by includ=
ing the at_hash (access token hash) in the ID Token, enabling the client to=
 validate that the access token was created by the issuer in the ID Token (=
which is also the OAuth Issuer, as described in RFC 8414).  (Note that this=
 mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>>>>>
>>>>> Given the prevalence of this known-good solution for securing the imp=
licit flow, I would request that the draft be updated to describe this miti=
gation.  At the same time, I=92m fine with the draft recommending the code =
flow over the implicit flow when this mitigation is not used.
>>>>>
>>>>>                                                                 Thank=
 you,
>>>>>                                                                 -- Mi=
ke
>>>>>
>>>>> From: OAuth
>>>>> 
>>>>>  On Behalf Of Hannes Tschofenig
>>>>> Sent: Monday, November 19, 2018 2:34 AM
>>>>> To: oauth
>>>>> 
>>>>>
>>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization =
code instead of implicit
>>>>>
>>>>> Hi all,
>>>>>
>>>>> The authors of the OAuth Security Topics draft came to the conclusion=
 that it is not possible to adequately secure the implicit flow against tok=
en injection since potential solutions like token binding or JARM are in an=
 early stage of adoption. For this reason, and since CORS allows browser-ba=
sed apps to send requests to the token endpoint, Torsten suggested to use t=
he authorization code instead of the implicit grant in call cases in his pr=
esentation (seehttps://
>>>>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-dra=
ft-ietf-oauth-security-topics-01
>>>>> ).
>>>>>
>>>>> A hum in the room at IETF#103 concluded strong support for his recomm=
endations. We would like to confirm the discussion on the list.
>>>>>
>>>>> Please provide a response by December 3rd.
>>>>>
>>>>> Ciao
>>>>> Hannes & Rifaat
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are =
confidential and may also be privileged. If you are not the intended recipi=
ent, please notify the sender immediately and do not disclose the contents =
to any other person, use it for any purpose, or store or copy the informati=
on in any medium. Thank you.
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>
>>>>>
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> 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
>
>
> --
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu


--_000_SN6PR02MB531161515693ADDE8A36AA3CD9D70SN6PR02MB5311namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








    

    Hi Torsten,
    


    

    

    nice one. FWIW I am reallly happy=
 to see this happening.
    

    Quick question though. What is th=
e recommendation about dealing with the client secret in this situation?


    

    

    regards
    


    

    

    antonio
    

    

    

    

    From: OAuth <oauth-bounc=
es@ietf.org> on behalf of Torsten Lodderstedt <torsten@lodderstedt.ne=
t>
    
Sent: Sunday, November 25, 2018 6:32:53 PM
    
To: oauth@ietf.org
    
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza=
tion code instead of implicit    

     
    

    

    

    Hi all, 
    

    
I would like to state again what the proposal of the authors of the Securit=
y BCP is:
    

    
Here is the respective text from the draft:
    

    
=97=97
    

    
2.1.2.  Implicit Grant
    

    
   The implicit grant (response type "token") and other=
 response types
    
   causing the authorization server to issue access tokens in the=

    
   authorization response are vulnerable to access token leakage =
and
    
   access token replay as described in Section 3.1, Section 3.2, =
Section 3.3, and Section 3.6.
    

    
   Moreover, no viable mechanism exists to cryptographically bind=
 access
    
   tokens issued in the authorization response to a certain clien=
t as it
    
   is recommended in Section 2.2.  This makes replay detecti=
on for such
    
   access tokens at resource servers impossible.
    

    
   In order to avoid these issues, Clients SHOULD NOT use the imp=
licit
    
   grant or any other response type causing the authorization ser=
ver to
    
   issue an access token in the authorization response.
    

    
   Clients SHOULD instead use the response type "code" =
(aka
    
   authorization code grant type) as specified in Section 2.1.1 o=
r any
    
   other response type that causes the authorization server to is=
sue
    
   access tokens in the token response.  This allows the aut=
horization
    
   server to detect replay attempts and generally reduces the att=
ack
    
   surface since access tokens are not exposed in URLs.  It =
also allows
    
   the authorization server to sender-constrain the issued tokens=
.
    
=97=97
    

    
In my observation, discouraging implicit seems to be the less controversial=
 issue.
    

    
=84or any other response type causing the authorization server to issue an =
access token in the authorization response.=93 in the 3rd paragraph caused =
discussions because it suggests to discourage developers from using ANY res=
ponse type issuing access tokens in
 the authorization response. This includes OIDC=92s response types =84token=
 id_token=93, =84code token=93 & =84code token id_token=93, where at le=
ast  =84token id_token=93 is used in the wild to implement SPAs.
    

    
Why did we come up with this proposal given at least =84token id_token=93 &=
amp; =84code token id_token=93 protect against injection?
    

    
Two reasons: 
    

    
1) =84token id_token=93 does not support sender constrained tokens. Also us=
e of refresh tokens to frequently issue new live-time and privilege restric=
ted access tokens is not supported. =84code token id_token=93 seems more co=
mplex than just =84code=93+pkce for achieving
 the same goal.
    

    
2) Protection against token leakage is rather thin and fragile. There is ju=
st a single line of defense (CSP, open redirection prevention, browser hist=
ory manipulation) implemented by the client.

    

    
Daniel and I collected some more information and argument at     
https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that y=
ou might like to give a read.
    

    
My conclusion after 2 weeks of intensive discussions with SPA developers (m=
ostly on twitter): code+pkce is the more secure, simpler, and more vers=
atile approach to (also) implement SPAs. I prefer to approach developers wi=
th a clean and robust message instead
 of a lengthy description of what needs to go right in order to secure a SP=
A using OAuth. That=92s why I think code+pkce should be the recommendat=
ion of our working group.
    

    
So please vote in favor of our proposal. I think that=92s a huge improvemen=
t for OAuth.
    

    
kind regards, 
    
Torsten. 
    

    

    
> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zandbelt@zmartzo=
ne.eu>:
    
> 
    
> I strongly support the recommendation of using code instead of implici=
t. I do so based on my own experience in the field [1] and stick to that al=
so after reading the comments and (what I would call) workarounds on this t=
hread.
    
> 
    
> Hans.
    
> 
    
> [1] 
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-pag=
e-applications/
    
> 
    
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <torsten@lodder=
stedt.net> wrote:
    
> that=92s certainly true, but that might by a web server with static co=
ntent only.
    
> 
    
> If the server is a real backend, there is even less reasons to use a i=
mplicit or hybrid. No even a performance gain in comparison to code.
    
> 
    
> Am 21..11.2018 um 14:24 schrieb George Fletcher <gffletch@aol.com&g=
t;:
    
> 
    
>> An SPA has a backend because it has to be loaded from somewhere :)=

    
>> 
    
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
    
>>> We had a discussion about this topic on Twitter 
https://twitter.com/Apl3b/status/1064854507606208513
    
>>> 
    
>>> 
    
>>> Outcome is POST requires a backend to receive the request so i=
t=92s not a viable solution for SPAs.
    
>>> 
    
>>> 
    
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7=
jtb.com>
    
>>>> :
    
>>>> 
    
>>>> Post response works OK for server based clients.  I d=
on't think POST works for single page applications. 

    
>>>> 
    
>>>> Basically that would be something more like postmessage be=
tween two JS apps. 

    
>>>> 
    
>>>> Postmessage also has security issues passing a access toke=
n and leaking.  
    
>>>> 
    
>>>> Perhaps someone more familiar with SPA can comment on POST=
.  
    
>>>> 
    
>>>> John B. 
    
>>>> 
    
>>>> 
    
>>>> 
    
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
    
>>>> gffletch@aol.com
    
>>>>  wrote:
    
>>>> Hi Mike,
    
>>>> 
    
>>>> The Form Post Response Mode keeps the access_token out of =
the URL, but it doesn't prevent the token from traversing through the brows=
er. So a man-in-the-browser attack may be able to intercept the values. It =
should help with leakage in logs.
    
>>>> 
    
>>>> Thanks,
    
>>>> George
    
>>>> 
    
>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
    
>>>> 
    
>>>>> Next question =96 doesn=92t using the Form Post Respon=
se Mode 
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
    
>>>>>  mitigate the threats you=92re describing below J=
ohn?  If so, I believe the Security Topics draft should say this.
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> I believe we owe it to readers to present the complete=
 picture, which is why I believe that describing profiles using ID Tokens a=
nd the Form Post Response Mode are in scope.
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>>         &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;         -- Mike
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> From: OAuth 
    
>>>>> <oauth-bounces@ietf.org>
    
>>>>>  On Behalf Of John Bradley
    
>>>>> Sent: Tuesday, November 20, 2018 7:47 AM
    
>>>>> To: 
    
>>>>> oauth@ietf.org
    
>>>>> 
    
>>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> Yes the at_hash protects the client from accepting an =
injected AT. 
    
>>>>> 
    
>>>>> Unfortunately it doesn't do anything to protect agains=
t leakage in logs or redirects.
    
>>>>> 
    
>>>>> So without the AT using some sort of POP mechanism it =
is hard to say sending it in a redirect is a good security practice.
    
>>>>> 
    
>>>>> John B.
    
>>>>> 
    
>>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
    
>>>>> 
    
>>>>> Hi Mike, 
    
>>>>>  
    
>>>>> I agree that OIDC hybrid flows offer additional securi=
ty over the OAuth implicit grant and are used in the wild. On my slides and=
 in the initial version of the new section, we had included the hybrid OIDC=
 flows because of their known token injection countermeasures.
    
>>>>>  
    
>>>>> I nevertheless feel very uncomfortable to recommend th=
ose flows and any flow issuing access tokens in the front channel. In the c=
ourse of the detailed review of the new text we realized two issues:

    
>>>>>  
    
>>>>> 1) Since the access token is exposed in the URL, such =
flows possess a significantly higher risk to leak the access token (e.g. th=
rough browser history, open redirection and even referrer headers) than the=
 code grant.
    
>>>>> 2) There is no viable way to sender constrain access t=
okens issued in the front channel. Given the WG decided to recommend use of=
 sender constraint tokens (
    
>>>>> 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..=
.2
    
>>>>> ), it seems contradictory to recommend response types =
not supporting such an approach.

    
>>>>>  
    
>>>>> kind regards,
    
>>>>> Torsten. 
    
>>>>>  
    
>>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
    
>>>>> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>=

    
>>>>> :
    
>>>>>  
    
>>>>> This description of the situation is an oversimplifica=
tion..  OpenID Connect secures the implicit flow against token injecti=
on attacks by including the at_hash (access token hash) in the ID Token, en=
abling the client to validate that the access token
 was created by the issuer in the ID Token (which is also the OAuth Issuer,=
 as described in RFC 8414).  (Note that this mitigation was described =
in draft-ietf-oauth-mix-up-mitigation.)
    
>>>>>  
    
>>>>> Given the prevalence of this known-good solution for s=
ecuring the implicit flow, I would request that the draft be updated to des=
cribe this mitigation.  At the same time, I=92m fine with the draft re=
commending the code flow over the implicit flow when this
 mitigation is not used.
    
>>>>>  
    
>>>>>         &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     Thank you,
    
>>>>>         &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
    
>>>>>  
    
>>>>> From: OAuth 
    
>>>>> <oauth-bounces@ietf.org>
    
>>>>>  On Behalf Of Hannes Tschofenig
    
>>>>> Sent: Monday, November 19, 2018 2:34 AM
    
>>>>> To: oauth 
    
>>>>> <oauth@ietf.org>
    
>>>>> 
    
>>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend=
 authorization code instead of implicit
    
>>>>>  
    
>>>>> Hi all,
    
>>>>>  
    
>>>>> The authors of the OAuth Security Topics draft came to=
 the conclusion that it is not possible to adequately secure the implicit f=
low against token injection since potential solutions like token binding or=
 JARM are in an early stage of adoption. For this
 reason, and since CORS allows browser-based apps to send requests to the t=
oken endpoint, Torsten suggested to use the authorization code instead of t=
he implicit grant in call cases in his presentation (seehttps://
    
>>>>> datatracker.ietf.org/meeting/103/materials/slides-103-=
oauth-sessb-draft-ietf-oauth-security-topics-01
    
>>>>> ).
    
>>>>>  
    
>>>>> A hum in the room at IETF#103 concluded strong support=
 for his recommendations. We would like to confirm the discussion on the li=
st.
    
>>>>>  
    
>>>>> Please provide a response by December 3rd.
    
>>>>>  
    
>>>>> Ciao
    
>>>>> Hannes & Rifaat
    
>>>>>  
    
>>>>> IMPORTANT NOTICE: The contents of this email and any a=
ttachments are confidential and may also be privileged. If you are not the =
intended recipient, please notify the sender immediately and do not disclos=
e the contents to any other person, use it for
 any purpose, or store or copy the information in any medium. Thank you.
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> OAuth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinfo/oauth
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> OAuth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinfo/oauth
    
>>>>> 
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> 
    
>>>>> OAuth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinfo/oauth
    
>>>> _______________________________________________
    
>>>> OAuth mailing list
    
>>>> 
    
>>>> OAuth@ietf.org
    
>>>> ht=
tps://www.ietf.org/mailman/listinfo/oauth
    
>> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org
    
> https://www.ie=
tf.org/mailman/listinfo/oauth
    
> 
    
> 
    
> -- 
    
> hans.zandbelt@zmartzone.eu
    
> ZmartZone IAM - www.zmartzone.eu
    

    

    

    



--_000_SN6PR02MB531161515693ADDE8A36AA3CD9D70SN6PR02MB5311namp_--


From nobody Mon Nov 26 00:47:10 2018
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 49786130DE2 for ; Mon, 26 Nov 2018 00:47:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=yes.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 sT0y46Z_u_AL for ; Mon, 26 Nov 2018 00:47:06 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267251294D0 for ; Mon, 26 Nov 2018 00:47:06 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id y139so17201260wmc.5 for ; Mon, 26 Nov 2018 00:47:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Xq3xwTOYUH9B/F90ysiI8HeXB7Re8vqXHB9iQ/7h/mM=; b=K9xkjVDSAuf+Kow8P5s9Tn3MWzltt1YslLFVKZ1hSTmUDPyN53sFRrjXwoPlIPM0M0 8/huXYrfqhmhYSpVZcyjOPMKFoIQoXkFZw07pAKgcAU9NnrTpomttMfSQgtMBuQg3UvO rgeY1AoQ1vGMg7BG0HuDUn0Bky7mhZXrT8MyE0v/cQAokdN8wY68jQFqrVdjkfcV0+2m e7UwDHNOTg0xDrN1CjSz+bn9jrmfAnscLRdM0TzA4BNQoLknfJBs33CEd3O5EOI0tWa8 NMhE0rMdUSl2GPmvoY7VeaHEuJDcAFAn5mbPfLUWPYAhaSn2fXtAa6vRqZFzCpeNlHhb Rrkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Xq3xwTOYUH9B/F90ysiI8HeXB7Re8vqXHB9iQ/7h/mM=; b=j38YUqHA0H2YByfC3VI0eoO3O9PrV7LCLWRA7YeOwrRuS+lM+2XFaA7/o5hqq30SOP IxfSXs+OBpp++tYTkJWJWDxPdg7kl/2Io6CKPaIu/SbvYyIyBelFdlEUZnjy0sq+meHy pxx3gN/idmXqF4qBUwKT24ZseQgQoOjLufQwR3JAzvAWB8kJX68JBxl8MTsg9XjIskCr K+o7W92nhYffwPcuZ+lWMTOPiwCQcpl1AaMXxKPUIMQWvGnyuQ5mNIFpYdW9g4ptwpt+ jILTPa4YU0dNIL2JnUN1qZb+1jwz0gSj0rUGV6OQ7HfwUvVALJV+X3LYkvC/r+pByNSu E0ZA==
X-Gm-Message-State: AGRZ1gKy6MmD8w9x5z63sUeu6JnbNdlhFZJJNa/4Do+8eAlUWJhQXrho FPhjkXadrCcmAN8NGurbVbIzmJxoPkU=
X-Google-Smtp-Source: AJdET5ezbUHZFoiqA+fFUSOWmiK4rNGmqTn8jKkFIk4ynFrGONlsEJXf7qkCiPeVmr/9tsafI3902g==
X-Received: by 2002:a1c:4406:: with SMTP id r6mr22951280wma.151.1543222023979;  Mon, 26 Nov 2018 00:47:03 -0800 (PST)
Received: from ?IPv6:2001:41b8:83c:fb01:a510:9a05:e583:d6df? ([2001:41b8:83c:fb01:a510:9a05:e583:d6df]) by smtp.gmail.com with ESMTPSA id f2sm18119095wru.14.2018.11.26.00.47.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 00:47:03 -0800 (PST)
To: Torsten Lodderstedt , Neil Madden 
Cc: "oauth@ietf.org" 
References:   <15ECD17C-C2E3-487B-B61D-E67E5A060DE4@lodderstedt.net>
From: Daniel Fett 
Message-ID: 
Date: Mon, 26 Nov 2018 09:46:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <15ECD17C-C2E3-487B-B61D-E67E5A060DE4@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------BEB217F8494B7A7470DBCBBB"
Content-Language: de-DE
Archived-At: 
Subject: Re: [OAUTH-WG] Binding Access Tokens is not enough!
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, 26 Nov 2018 08:47:09 -0000

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

Yes. Token Binding enforces that only the right browser can send the
token; in this browser, CORS enforces that only the correct origin can
send the token.

Am 25.11.18 um 19:46 schrieb Torsten Lodderstedt:
> Does this mean the RS effectively relies on the user agent to enforce the sender constraint (via CORS policy)?
>
>> Am 23.11.2018 um 14:54 schrieb Neil Madden :
>>
>> Thanks for doing this Daniel, I think the proposed text is good.
>>
>> — Neil
>>
>>> On 22 Nov 2018, at 14:42, Daniel Fett  wrote:
>>>
>>> Hi all,
>>>
>>> I would like to discuss a text proposal for the security BCP.
>>>
>>> Background:
>>>
>>> Yesterday, Neil pointed out the following problem with binding access tokens using mTLS or token binding in SPAs:
>>>
>>> "I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client."
>>>
>>> The problem is that a browser's TLS stack will attach the proof of possession no matter which origin started a request.
>>>
>>> (This seems like a real downside of token binding - why does it not have the "same site" option that cookies nowadays have?)
>>>
>>> I prepared the following addition to the security BCP and would like to hear your opinions:
>>>
>>> "It is important to note that constraining the sender of a token to a web browser (using a TLS-based method) does not constrain the origin of the script that uses the token (lack of origin binding). In other words, if access tokens are used in a browser (as in a single-page application, SPA) and the access tokens are sender-constrained using a TLS-based method, it must be ensured that origins other than the origin of the SPA cannot misuse the TLS-based sender authentication.
>>>
>>> The problem can be illustrated using an SPA on origin A that uses an access token AT that is bound to the TLS connection between the browser and the resource server R. If AT leaks to an attacker E, and there is, for example, an iframe from E's origin loaded in the web browser, that iframe can send a request to origin R using the access token AT. This request will contain the proof-of-posession of the (mTLS or token binding) key. The resource server R therefore cannot distinguish if a request containing a valid access token originates from origin A or origin E.
>>>
>>> If the resource server only accepts the access token in an Authorization header, then Cross-Origin Resource Sharing (CORS) will protect against this attack by default. If the resource server accepts the access tokens in other ways (e.g., as a URL parameter), or if the CORS policy of the resource server permits requests by origin E, then the TLS-based token binding only provides protection if the browser is offline."
>>>
>>>
>>> The "summary" above this text reads as follows:
>>>
>>> "If access tokens are sender-constrained to a web browser, the resource server MUST ensure that the access token can only be used by the origin to which the access token was issued (origin binding). One solution for the resource server to accomplish this is to only accept the access token in an Authorization header (as described in RFC 6750) and to ensure that the active CORS policy prevents third parties from sending Authorization headers. See  for details."
>>>
>>> What do you think?
>>>
>>> -Daniel
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth



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


  
    
  
  
    
    Yes. Token Binding enforces that only
      the right browser can send the token; in this browser, CORS
      enforces that only the correct origin can send the token.
    
    
    
    

    
    
    
    
    Am 25.11.18 um 19:46 schrieb Torsten
      Lodderstedt:
    
    
    
    
    
      
    Does this mean the RS effectively relies on the user agent to enforce the sender constraint (via CORS policy)?


    
      
    
        
    Am 23.11.2018 um 14:54 schrieb Neil Madden <neil.madden@forgerock.com>:

Thanks for doing this Daniel, I think the proposed text is good.

— Neil


    
        
    
          
    On 22 Nov 2018, at 14:42, Daniel Fett <danielf+oauth@yes.com> wrote:

Hi all,

I would like to discuss a text proposal for the security BCP.

Background:

Yesterday, Neil pointed out the following problem with binding access tokens using mTLS or token binding in SPAs:

"I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client."

The problem is that a browser's TLS stack will attach the proof of possession no matter which origin started a request.

(This seems like a real downside of token binding - why does it not have the "same site" option that cookies nowadays have?)

I prepared the following addition to the security BCP and would like to hear your opinions:

"It is important to note that constraining the sender of a token to a web browser (using a TLS-based method) does not constrain the origin of the script that uses the token (lack of origin binding). In other words, if access tokens are used in a browser (as in a single-page application, SPA) and the access tokens are sender-constrained using a TLS-based method, it must be ensured that origins other than the origin of the SPA cannot misuse the TLS-based sender authentication.

The problem can be illustrated using an SPA on origin A that uses an access token AT that is bound to the TLS connection between the browser and the resource server R. If AT leaks to an attacker E, and there is, for example, an iframe from E's origin loaded in the web browser, that iframe can send a request to origin R using the access token AT. This request will contain the proof-of-posession of the (mTLS or token binding) key. The resource server R therefore cannot distinguish if a request containing a valid access token originates from origin A or origin E.

If the resource server only accepts the access token in an Authorization header, then Cross-Origin Resource Sharing (CORS) will protect against this attack by default. If the resource server accepts the access tokens in other ways (e.g., as a URL parameter), or if the CORS policy of the resource server permits requests by origin E, then the TLS-based token binding only provides protection if the browser is offline."


The "summary" above this text reads as follows:

"If access tokens are sender-constrained to a web browser, the resource server MUST ensure that the access token can only be used by the origin to which the access token was issued (origin binding). One solution for the resource server to accomplish this is to only accept the access token in an Authorization header (as described in RFC 6750) and to ensure that the active CORS policy prevents third parties from sending Authorization headers. See <xref target="pop_tokens"/> for details."

What do you think?

-Daniel

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

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

    
      
    
      
    
    
    
    

    
    
    
  


--------------BEB217F8494B7A7470DBCBBB--


From nobody Mon Nov 26 01:34:55 2018
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 B8B0F130DE5 for ; Mon, 26 Nov 2018 01:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level: 
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 vqeSFT4B9cS0 for ; Mon, 26 Nov 2018 01:34:49 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) (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 0904F12D4E7 for ; Mon, 26 Nov 2018 01:34:48 -0800 (PST)
Received: from [80.187.101.0] (helo=[10.76.251.61]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRDHu-0000SH-6A; Mon, 26 Nov 2018 10:34:42 +0100
Content-Type: multipart/signed; boundary=Apple-Mail-2F88AAEB-8479-4EAE-BD07-A5ED50A03B2D; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: 
Date: Mon, 26 Nov 2018 10:34:40 +0100
Cc: "oauth@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net> 
To: Antonio Sanso 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 26 Nov 2018 09:34:54 -0000

--Apple-Mail-2F88AAEB-8479-4EAE-BD07-A5ED50A03B2D
Content-Type: multipart/alternative;
	boundary=Apple-Mail-107E8539-84D8-4D8A-B5BE-B3D8FA878E4D
Content-Transfer-Encoding: 7bit


--Apple-Mail-107E8539-84D8-4D8A-B5BE-B3D8FA878E4D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Antonio,

good point. I would assume most SPAs will be public clients. Even if a singl=
e instance registers dynamically and obtains a secret, this secret can only b=
e used as kind of =E2=80=9Esame originator=E2=80=9C proof (much like PKCE). S=
PAs with a backend can also make the backend a confidential client. There wa=
s a thread about SPAs & backends on the list recently.

I would argue this is inline with RFC6749 security considerations. Do you se=
e a need to add this to the BCP?

kind regards,
Torsten.


> Am 26.11.2018 um 09:18 schrieb Antonio Sanso :
>=20
> Hi Torsten,
>=20
> nice one. FWIW I am reallly happy to see this happening.
> Quick question though. What is the recommendation about dealing with the c=
lient secret in this situation?
>=20
> regards
>=20
> antonio
> From: OAuth  on behalf of Torsten Lodderstedt 
> Sent: Sunday, November 25, 2018 6:32:53 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization c=
ode instead of implicit
> =20
> Hi all,=20
>=20
> I would like to state again what the proposal of the authors of the Securi=
ty BCP is:
>=20
> Here is the respective text from the draft:
>=20
> =E2=80=94=E2=80=94
>=20
> 2.1.2.  Implicit Grant
>=20
>    The implicit grant (response type "token") and other response types
>    causing the authorization server to issue access tokens in the
>    authorization response are vulnerable to access token leakage and
>    access token replay as described in Section 3.1, Section 3.2, Section 3=
.3, and Section 3.6.
>=20
>    Moreover, no viable mechanism exists to cryptographically bind access
>    tokens issued in the authorization response to a certain client as it
>    is recommended in Section 2.2.  This makes replay detection for such
>    access tokens at resource servers impossible.
>=20
>    In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant or any other response type causing the authorization server to
>    issue an access token in the authorization response.
>=20
>    Clients SHOULD instead use the response type "code" (aka
>    authorization code grant type) as specified in Section 2.1.1 or any
>    other response type that causes the authorization server to issue
>    access tokens in the token response.  This allows the authorization
>    server to detect replay attempts and generally reduces the attack
>    surface since access tokens are not exposed in URLs.  It also allows
>    the authorization server to sender-constrain the issued tokens.
> =E2=80=94=E2=80=94
>=20
> In my observation, discouraging implicit seems to be the less controversia=
l issue.
>=20
> =E2=80=9Eor any other response type causing the authorization server to is=
sue an access token in the authorization response.=E2=80=9C in the 3rd parag=
raph caused discussions because it suggests to discourage developers from us=
ing ANY response type issuing access tokens in the authorization response. T=
his includes OIDC=E2=80=99s response types =E2=80=9Etoken id_token=E2=80=9C,=
 =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C, where=
 at least  =E2=80=9Etoken id_token=E2=80=9C is used in the wild to implement=
 SPAs.
>=20
> Why did we come up with this proposal given at least =E2=80=9Etoken id_tok=
en=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against injectio=
n?
>=20
> Two reasons:=20
>=20
> 1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained to=
kens. Also use of refresh tokens to frequently issue new live-time and privi=
lege restricted access tokens is not supported. =E2=80=9Ecode token id_token=
=E2=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce for achie=
ving the same goal.
>=20
> 2) Protection against token leakage is rather thin and fragile. There is j=
ust a single line of defense (CSP, open redirection prevention, browser hist=
ory manipulation) implemented by the client.=20
>=20
> Daniel and I collected some more information and argument at https://githu=
b.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might like to g=
ive a read.
>=20
> My conclusion after 2 weeks of intensive discussions with SPA developers (=
mostly on twitter): code+pkce is the more secure, simpler, and more versatil=
e approach to (also) implement SPAs. I prefer to approach developers with a c=
lean and robust message instead of a lengthy description of what needs to go=
 right in order to secure a SPA using OAuth. That=E2=80=99s why I think code=
+pkce should be the recommendation of our working group.
>=20
> So please vote in favor of our proposal. I think that=E2=80=99s a huge imp=
rovement for OAuth.
>=20
> kind regards,=20
> Torsten.=20
>=20
>=20
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt :
> >=20
> > I strongly support the recommendation of using code instead of implicit.=
 I do so based on my own experience in the field [1] and stick to that also a=
fter reading the comments and (what I would call) workarounds on this thread=
.
> >=20
> > Hans.
> >=20
> > [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-sin=
gle-page-applications/
> >=20
> > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt  wrote:
> > that=E2=80=99s certainly true, but that might by a web server with stati=
c content only.
> >=20
> > If the server is a real backend, there is even less reasons to use a imp=
licit or hybrid. No even a performance gain in comparison to code.
> >=20
> > Am 21..11.2018 um 14:24 schrieb George Fletcher :
> >=20
> >> An SPA has a backend because it has to be loaded from somewhere :)
> >>=20
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
> >>> We had a discussion about this topic on Twitter https://twitter.com/Ap=
l3b/status/1064854507606208513
> >>>=20
> >>>=20
> >>> Outcome is POST requires a backend to receive the request so it=E2=80=99=
s not a viable solution for SPAs.
> >>>=20
> >>>=20
> >>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
> >>>> :
> >>>>=20
> >>>> Post response works OK for server based clients.  I don't think POST w=
orks for single page applications. =20
> >>>>=20
> >>>> Basically that would be something more like postmessage between two J=
S apps. =20
> >>>>=20
> >>>> Postmessage also has security issues passing a access token and leaki=
ng. =20
> >>>>=20
> >>>> Perhaps someone more familiar with SPA can comment on POST. =20
> >>>>=20
> >>>> John B.=20
> >>>>=20
> >>>>=20
> >>>>=20
> >>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
> >>>> gffletch@aol.com
> >>>>  wrote:
> >>>> Hi Mike,
> >>>>=20
> >>>> The Form Post Response Mode keeps the access_token out of the URL, bu=
t it doesn't prevent the token from traversing through the browser. So a man=
-in-the-browser attack may be able to intercept the values. It should help w=
ith leakage in logs.
> >>>>=20
> >>>> Thanks,
> >>>> George
> >>>>=20
> >>>> On 11/20/18 4:00 PM, Mike Jones wrote:
> >>>>=20
> >>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form Post Response=
 Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
> >>>>>  mitigate the threats you=E2=80=99re describing below John?  If so, I=
 believe the Security Topics draft should say this.
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>> I believe we owe it to readers to present the complete picture, whic=
h is why I believe that describing profiles using ID Tokens and the Form Pos=
t Response Mode are in scope.
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>>                                                        -- Mike
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>> From: OAuth=20
> >>>>> 
> >>>>>  On Behalf Of John Bradley
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
> >>>>> To:=20
> >>>>> oauth@ietf.org
> >>>>>=20
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza=
tion code instead of implicit
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>> Yes the at_hash protects the client from accepting an injected AT.=20=

> >>>>>=20
> >>>>> Unfortunately it doesn't do anything to protect against leakage in l=
ogs or redirects.
> >>>>>=20
> >>>>> So without the AT using some sort of POP mechanism it is hard to say=
 sending it in a redirect is a good security practice.
> >>>>>=20
> >>>>> John B.
> >>>>>=20
> >>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
> >>>>>=20
> >>>>> Hi Mike,=20
> >>>>> =20
> >>>>> I agree that OIDC hybrid flows offer additional security over the OA=
uth implicit grant and are used in the wild. On my slides and in the initial=
 version of the new section, we had included the hybrid OIDC flows because o=
f their known token injection countermeasures.
> >>>>> =20
> >>>>> I nevertheless feel very uncomfortable to recommend those flows and a=
ny flow issuing access tokens in the front channel. In the course of the det=
ailed review of the new text we realized two issues:=20
> >>>>> =20
> >>>>> 1) Since the access token is exposed in the URL, such flows possess a=
 significantly higher risk to leak the access token (e.g. through browser hi=
story, open redirection and even referrer headers) than the code grant.
> >>>>> 2) There is no viable way to sender constrain access tokens issued i=
n the front channel. Given the WG decided to recommend use of sender constra=
int tokens (
> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#sect=
ion-2...2
> >>>>> ), it seems contradictory to recommend response types not supporting=
 such an approach.=20
> >>>>> =20
> >>>>> kind regards,
> >>>>> Torsten.=20
> >>>>> =20
> >>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones=20
> >>>>> 
> >>>>> :
> >>>>> =20
> >>>>> This description of the situation is an oversimplification..  OpenID=
 Connect secures the implicit flow against token injection attacks by includ=
ing the at_hash (access token hash) in the ID Token, enabling the client to v=
alidate that the access token was created by the issuer in the ID Token (whi=
ch is also the OAuth Issuer, as described in RFC 8414).  (Note that this mit=
igation was described in draft-ietf-oauth-mix-up-mitigation.)
> >>>>> =20
> >>>>> Given the prevalence of this known-good solution for securing the im=
plicit flow, I would request that the draft be updated to describe this miti=
gation.  At the same time, I=E2=80=99m fine with the draft recommending the c=
ode flow over the implicit flow when this mitigation is not used.
> >>>>> =20
> >>>>>                                                                 Than=
k you,
> >>>>>                                                                 -- M=
ike
> >>>>> =20
> >>>>> From: OAuth=20
> >>>>> 
> >>>>>  On Behalf Of Hannes Tschofenig
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
> >>>>> To: oauth=20
> >>>>> 
> >>>>>=20
> >>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization=
 code instead of implicit
> >>>>> =20
> >>>>> Hi all,
> >>>>> =20
> >>>>> The authors of the OAuth Security Topics draft came to the conclusio=
n that it is not possible to adequately secure the implicit flow against tok=
en injection since potential solutions like token binding or JARM are in an e=
arly stage of adoption. For this reason, and since CORS allows browser-based=
 apps to send requests to the token endpoint, Torsten suggested to use the a=
uthorization code instead of the implicit grant in call cases in his present=
ation (seehttps://
> >>>>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-dr=
aft-ietf-oauth-security-topics-01
> >>>>> ).
> >>>>> =20
> >>>>> A hum in the room at IETF#103 concluded strong support for his recom=
mendations. We would like to confirm the discussion on the list.
> >>>>> =20
> >>>>> Please provide a response by December 3rd.
> >>>>> =20
> >>>>> Ciao
> >>>>> Hannes & Rifaat
> >>>>> =20
> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments are=
 confidential and may also be privileged. If you are not the intended recipi=
ent, please notify the sender immediately and do not disclose the contents t=
o any other person, use it for any purpose, or store or copy the information=
 in any medium. Thank you.
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>=20
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>=20
> >>>>> =20
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>=20
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>=20
> >>>>>=20
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>>=20
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>=20
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >=20
> >=20
> > --=20
> > hans.zandbelt@zmartzone.eu
> > ZmartZone IAM - www.zmartzone.eu
>=20

--Apple-Mail-107E8539-84D8-4D8A-B5BE-B3D8FA878E4D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Hi A=
ntonio,

    good point. I would=
 assume most SPAs will be public clients. Even if a single instance register=
s dynamically and obtains a secret, this secret can only be used as kind of =E2=
=80=9Esame originator=E2=80=9C proof (much like PKCE). SPAs with a backend c=
an also make the backend a confidential client. There was a thread about SPA=
s & backends on the list recently.

    I would argue this is inline with RFC6749 security considerations=
. Do you see a need to add this to the BCP?

    =

    kind regards,
    Torsten.


    Am 26.11.2018 um 09:18 schrieb Antonio S=
anso <asanso@adobe.com>:
    






    

    Hi Torsten,
    


    

    

    nice one. FWIW I am reallly happy t=
o see this happening.
    

    Quick question though. What is the=
 recommendation about dealing with the client secret in this situation?
    


    

    

    regards
    


    

    

    antonio
    

    

    

    

    From: OAuth <oauth-bounces@ietf.org> on behalf of Tor=
sten Lodderstedt <torsten@lodd=
erstedt.net>
    
Sent: Sunday, November 25, 2018 6:32:53 PM
    
To: oauth@ietf.org
    
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorizat=
ion code instead of implicit    

     
    

    

    

    Hi all, 
    

    
I would like to state again what the proposal of the authors of the Security=
 BCP is:
    

    
Here is the respective text from the draft:
    

    
=E2=80=94=E2=80=94
    

    
2.1.2.  Implicit Grant
    

    
   The implicit grant (response type "token") and other response t=
ypes
    
   causing the authorization server to issue access tokens in the<=
br>
   authorization response are vulnerable to access token leakage a=
nd
    
   access token replay as described in Section 3.1, Section 3.2, S=
ection 3.3, and Section 3.6.
    

    
   Moreover, no viable mechanism exists to cryptographically bind a=
ccess
    
   tokens issued in the authorization response to a certain client=
 as it
    
   is recommended in Section 2.2.  This makes replay detectio=
n for such
    
   access tokens at resource servers impossible.
    

    
   In order to avoid these issues, Clients SHOULD NOT use the impl=
icit
    
   grant or any other response type causing the authorization serv=
er to
    
   issue an access token in the authorization response.
    

    
   Clients SHOULD instead use the response type "code" (aka
    
   authorization code grant type) as specified in Section 2.1.1 or=
 any
    
   other response type that causes the authorization server to iss=
ue
    
   access tokens in the token response.  This allows the auth=
orization
    
   server to detect replay attempts and generally reduces the atta=
ck
    
   surface since access tokens are not exposed in URLs.  It a=
lso allows
    
   the authorization server to sender-constrain the issued tokens.=

    
=E2=80=94=E2=80=94
    

    
In my observation, discouraging implicit seems to be the less controversial i=
ssue.
    

    
=E2=80=9Eor any other response type causing the authorization server to issu=
e an access token in the authorization response.=E2=80=9C in the 3rd paragra=
ph caused discussions because it suggests to discourage developers from usin=
g ANY response type issuing access tokens in
 the authorization response. This includes OIDC=E2=80=99s response types =E2=
=80=9Etoken id_token=E2=80=9C, =E2=80=9Ecode token=E2=80=9C & =E2=80=9Ec=
ode token id_token=E2=80=9C, where at least  =E2=80=9Etoken id_token=E2=
=80=9C is used in the wild to implement SPAs.
    

    
Why did we come up with this proposal given at least =E2=80=9Etoken id_token=
=E2=80=9C & =E2=80=9Ecode token id_token=E2=80=9C protect against inject=
ion?
    

    
Two reasons: 
    

    
1) =E2=80=9Etoken id_token=E2=80=9C does not support sender constrained toke=
ns. Also use of refresh tokens to frequently issue new live-time and privile=
ge restricted access tokens is not supported. =E2=80=9Ecode token id_token=E2=
=80=9C seems more complex than just =E2=80=9Ecode=E2=80=9C+pkce for achievin=
g
 the same goal.
    

    
2) Protection against token leakage is rather thin and fragile. There is jus=
t a single line of defense (CSP, open redirection prevention, browser histor=
y manipulation) implemented by the client.

    

    
Daniel and I collected some more information and argument at 
https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that yo=
u might like to give a read.
    

    
My conclusion after 2 weeks of intensive discussions with SPA developers (mo=
stly on twitter): code+pkce is the more secure, simpler, and more versatile a=
pproach to (also) implement SPAs. I prefer to approach developers with a cle=
an and robust message instead
 of a lengthy description of what needs to go right in order to secure a SPA=
 using OAuth. That=E2=80=99s why I think code+pkce should be the recommendat=
ion of our working group.
    

    
So please vote in favor of our proposal. I think that=E2=80=99s a huge impro=
vement for OAuth.
    

    
kind regards, 
    
Torsten. 
    

    

    
> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu>:
    
> 
    
> I strongly support the recommendation of using code instead of implicit=
. I do so based on my own experience in the field [1] and stick to that also=
 after reading the comments and (what I would call) workarounds on this thre=
ad.
    
> 
    
> Hans.
    
> 
    
> [1] 
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page=
-applications/
    
> 
    
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    
> that=E2=80=99s certainly true, but that might by a web server with stat=
ic content only.
    
> 
    
> If the server is a real backend, there is even less reasons to use a im=
plicit or hybrid. No even a performance gain in comparison to code.
    
> 
    
> Am 21..11.2018 um 14:24 schrieb George Fletcher <gffletch@aol.com>:
    
> 
    
>> An SPA has a backend because it has to be loaded from somewhere :)<=
br>
>> 
    
>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
    
>>> We had a discussion about this topic on Twitter 
https://twitter.com/Apl3b/status/1064854507606208513
    
>>> 
    
>>> 
    
>>> Outcome is POST requires a backend to receive the request so it=
=E2=80=99s not a viable solution for SPAs.
    
>>> 
    
>>> 
    
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.com>
    
>>>> :
    
>>>> 
    
>>>> Post response works OK for server based clients.  I do=
n't think POST works for single page applications. 

    
>>>> 
    
>>>> Basically that would be something more like postmessage bet=
ween two JS apps. 

    
>>>> 
    
>>>> Postmessage also has security issues passing a access token=
 and leaking.  
    
>>>> 
    
>>>> Perhaps someone more familiar with SPA can comment on POST.=
  
    
>>>> 
    
>>>> John B. 
    
>>>> 
    
>>>> 
    
>>>> 
    
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
    
>>>> gffletch@aol.com
>>>>  wrote:
    
>>>> Hi Mike,
    
>>>> 
    
>>>> The Form Post Response Mode keeps the access_token out of t=
he URL, but it doesn't prevent the token from traversing through the browser=
. So a man-in-the-browser attack may be able to intercept the values. It sho=
uld help with leakage in logs.
    
>>>> 
    
>>>> Thanks,
    
>>>> George
    
>>>> 
    
>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
    
>>>> 
    
>>>>> Next question =E2=80=93 doesn=E2=80=99t using the Form P=
ost Response Mode 
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
    
>>>>>  mitigate the threats you=E2=80=99re describing be=
low John?  If so, I believe the Security Topics draft should say this.<=
br>
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> I believe we owe it to readers to present the complete p=
icture, which is why I believe that describing profiles using ID Tokens and t=
he Form Post Response Mode are in scope.
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>>         &n=
bsp;            =
            &nbs=
p;            &n=
bsp;        -- Mike
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> From: OAuth 
    
>>>>> <oauth-bou=
nces@ietf.org>
    
>>>>>  On Behalf Of John Bradley
    
>>>>> Sent: Tuesday, November 20, 2018 7:47 AM
    
>>>>> To: 
    
>>>>> oauth@ietf.org
>>>>> 
    
>>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recomm=
end authorization code instead of implicit
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> Yes the at_hash protects the client from accepting an i=
njected AT. 
    
>>>>> 
    
>>>>> Unfortunately it doesn't do anything to protect against=
 leakage in logs or redirects.
    
>>>>> 
    
>>>>> So without the AT using some sort of POP mechanism it i=
s hard to say sending it in a redirect is a good security practice.
    
>>>>> 
    
>>>>> John B.
    
>>>>> 
    
>>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
    
>>>>> 
    
>>>>> Hi Mike, 
    
>>>>>  
    
>>>>> I agree that OIDC hybrid flows offer additional securit=
y over the OAuth implicit grant and are used in the wild. On my slides and i=
n the initial version of the new section, we had included the hybrid OIDC fl=
ows because of their known token injection countermeasures.
    
>>>>>  
    
>>>>> I nevertheless feel very uncomfortable to recommend tho=
se flows and any flow issuing access tokens in the front channel. In the cou=
rse of the detailed review of the new text we realized two issues:

    
>>>>>  
    
>>>>> 1) Since the access token is exposed in the URL, such f=
lows possess a significantly higher risk to leak the access token (e.g. thro=
ugh browser history, open redirection and even referrer headers) than the co=
de grant.
    
>>>>> 2) There is no viable way to sender constrain access to=
kens issued in the front channel. Given the WG decided to recommend use of s=
ender constraint tokens (
    
>>>>> 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...=
2
    
>>>>> ), it seems contradictory to recommend response types n=
ot supporting such an approach.

    
>>>>>  
    
>>>>> kind regards,
    
>>>>> Torsten. 
    
>>>>>  
    
>>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
    
>>>>> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
    
>>>>> :
    
>>>>>  
    
>>>>> This description of the situation is an oversimplificat=
ion..  OpenID Connect secures the implicit flow against token injection=
 attacks by including the at_hash (access token hash) in the ID Token, enabl=
ing the client to validate that the access token
 was created by the issuer in the ID Token (which is also the OAuth Issuer, a=
s described in RFC 8414).  (Note that this mitigation was described in d=
raft-ietf-oauth-mix-up-mitigation.)
    
>>>>>  
    
>>>>> Given the prevalence of this known-good solution for se=
curing the implicit flow, I would request that the draft be updated to descr=
ibe this mitigation.  At the same time, I=E2=80=99m fine with the draft=
 recommending the code flow over the implicit flow when this
 mitigation is not used.
    
>>>>>  
    
>>>>>         &n=
bsp;            =
            &nbs=
p;            &n=
bsp;            =
     Thank you,
    
>>>>>         &n=
bsp;            =
            &nbs=
p;            &n=
bsp;            =
     -- Mike
    
>>>>>  
    
>>>>> From: OAuth 
    
>>>>> <oauth-bou=
nces@ietf.org>
    
>>>>>  On Behalf Of Hannes Tschofenig
    
>>>>> Sent: Monday, November 19, 2018 2:34 AM
    
>>>>> To: oauth 
    
>>>>> <oauth@ietf.org>
    
>>>>> 
    
>>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend a=
uthorization code instead of implicit
    
>>>>>  
    
>>>>> Hi all,
    
>>>>>  
    
>>>>> The authors of the OAuth Security Topics draft came to t=
he conclusion that it is not possible to adequately secure the implicit flow=
 against token injection since potential solutions like token binding or JAR=
M are in an early stage of adoption. For this
 reason, and since CORS allows browser-based apps to send requests to the to=
ken endpoint, Torsten suggested to use the authorization code instead of the=
 implicit grant in call cases in his presentation (seehttps://
    
>>>>>     datatracke=
r.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-sec=
urity-topics-01
    
>>>>> ).
    
>>>>>  
    
>>>>> A hum in the room at IETF#103 concluded strong support f=
or his recommendations. We would like to confirm the discussion on the list.=

    
>>>>>  
    
>>>>> Please provide a response by December 3rd.
    
>>>>>  
    
>>>>> Ciao
    
>>>>> Hannes & Rifaat
    
>>>>>  
    
>>>>> IMPORTANT NOTICE: The contents of this email and any at=
tachments are confidential and may also be privileged. If you are not the in=
tended recipient, please notify the sender immediately and do not disclose t=
he contents to any other person, use it for
 any purpose, or store or copy the information in any medium. Thank you.
    =

>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
    
>>>>> 
    
>>>>>  
    
>>>>> 
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
    
>>>>> 
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> 
    
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
    
>>>> _______________________________________________
    
>>>> OAuth mailing list
    
>>>> 
    
>>>> OAuth@ietf.org
    
>>>> htt=
ps://www.ietf.org/mailman/listinfo/oauth
    
>> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org
    
> https://www.iet=
f.org/mailman/listinfo/oauth
    
> 
    
> 
    
> -- 
    
> hans.zandbelt@zmartzone.e=
u
    
> ZmartZone IAM - www.zmartzone.eu
    

    

    

    



    =

--Apple-Mail-107E8539-84D8-4D8A-B5BE-B3D8FA878E4D--

--Apple-Mail-2F88AAEB-8479-4EAE-BD07-A5ED50A03B2D
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED
e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/
BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX
dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu
wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT
QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs
0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F
dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX
Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG
CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB
Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy
ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j
b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp
bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB
F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976
FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz
62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4
wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq
8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4
Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTI2MDkzNDQxWjAvBgkqhkiG
9w0BCQQxIgQgCklbBOMu65IGJNEBfstjhJYKVCvwM705aiFk7Ux4e7IwgcEGCSsGAQQBgjcQBDGB
szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT
SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3
mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB
IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAKUT
XkDHOvNDkDVJFZYvrZWE05H0fQoNHIzBrvFTV93Znsww38Eqb1A0H9h1Qc0V6OntXUmwKdf6S71s
T7tprUPc8Q5KmedJD623foIgttGxWIt3K18JsX3S13ZQZCL8EObIk8x8+F3GWvRnwd4aeidW2c+u
cAAhgZuXQlWmUHPXi1zorYCCSXKkAKC/jLpWZ4GAOoeJWgvmj3E0vr08AR/4v7ROUoqOnI1q4uk6
zErrLqRHTpp1k4QlfCo/bLhZcvCkf/yCtkQI3aOknlkLGzkh2m4G5SLkRK9S8TUQhosuWWxxw2s/
18NmJTx+/dphbndvvJwlyxmbS89WUe91k9IAAAAAAAA=

--Apple-Mail-2F88AAEB-8479-4EAE-BD07-A5ED50A03B2D--


From nobody Mon Nov 26 01:38:12 2018
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 DCF13130F08 for ; Mon, 26 Nov 2018 01:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Level: 
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.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 cF2DSx7FwzFR for ; Mon, 26 Nov 2018 01:38:07 -0800 (PST)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720055.outbound.protection.outlook.com [40.107.72.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA831128CF2 for ; Mon, 26 Nov 2018 01:38:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ThhVV3KOn/uBmZPOpA1Pa0GE0CfIJavX1Lxhm5Szllk=; b=MAfh5EcRQ5jVBX9EIIfR6eVM4eopcJQukBxvgZnvjAH39GTu56+iLJI9AYHeLP4sWpHbr97YQN1FePzkBM9y0uC2SUVgl6OzxJV+vNxTFdVsF8aKsvsysdQzCFjnI3mli6VgDMlG9dKTzZ4zUZ2/MUazDJ+NplkYvtZM6hBhNAk=
Received: from SN6PR02MB5311.namprd02.prod.outlook.com (52.135.104.21) by SN6PR02MB4141.namprd02.prod.outlook.com (52.135.70.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.19; Mon, 26 Nov 2018 09:38:02 +0000
Received: from SN6PR02MB5311.namprd02.prod.outlook.com ([fe80::7474:a69c:7624:d996]) by SN6PR02MB5311.namprd02.prod.outlook.com ([fe80::7474:a69c:7624:d996%6]) with mapi id 15.20.1361.019; Mon, 26 Nov 2018 09:38:02 +0000
From: Antonio Sanso 
To: Torsten Lodderstedt 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwAYRRbAABPdaIAAES+SAAAK3nrAAAF3OoAAAbNqgAAVmmqAAAmlbIAAICS4gACl6t6AAAvL3oAAHtrZhAACvCsAAAI2ZIA=
Date: Mon, 26 Nov 2018 09:38:02 +0000
Message-ID: <8EAA6268-62A4-4948-BAAF-43093E6FF5EF@adobe.com>
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.13.0.181109
authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; 
x-originating-ip: [192.147.117.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR02MB4141; 6:Q42Mzx/X+Ue9J1y5jlfOkWOhWmQb9gvzd9NTEQjN9z/O8UwKYCEADk4O7/x/ejM/E69vcZZshreL5GKt92U29eiSWg2ynXaTYsLWJodhJKlCEtwlWqigJnnRWC7Wn9C0ZuQz+iPpcLXptFf0K3J3B8RwqJ/p/TS56acbA2uemySK5FdW3vVML930AlS5SCWvvxiH0iJwPPLWynwWy6WvznRxJyv+kkFiVnR+hmnqCMCM2VrZy/TPoWxf7d39zxb2gskUJtmoa+71CzDl3zGSonwSgYbMdgLTZs1uyU4M3x2JAcev+KNp7C+FfqXK6Pi0gL1HbQqdTKlqZqPAF3JysZ5ztC9IIVf4kc99xBQBImbbqyRBk/S46ee+AsBaBkjDt/CALHE6MpHyK2OdqOXhXXmz5CVrOMNCY5uJjiOy2D0RYW8YQLITPjAWxAkmz8aG+d8rnU1DiwM5hpGdgp8z/A==; 5:HpNZvoOjKyZS5/dJBGmOje1nNxnVFC0sZFR5huySBeeQXWAOPj091CqbX09tpvR/38uTnqNzBo8Ycdc+fYXAtUI4oRbrQPzwMsFdWwzjpmSEPziAz4KwDIfZZynruLiPHLoMrKzzjgur81RucFIoUDr7MLXJZJxFgeuJd7yeS+s=; 7:zKupcNjOFPqXt+Aye+e6sbvw013p0tM+LcyaB8w9FUlhR+Sq6rkIDKFwXr9gWByAwwp+wDnJUNB/WHngm554fvuG4vXrPpV+s5Rsq4uGDLW11XUrip3ACD4i1Jw7dnsRzzdrW8h0Bmgm7HeORLkHqA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: edc1aaac-866e-4fac-4778-08d65382dc18
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:SN6PR02MB4141; 
x-ms-traffictypediagnostic: SN6PR02MB4141:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231443)(944501410)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:SN6PR02MB4141; BCL:0; PCL:0; RULEID:; SRVR:SN6PR02MB4141; 
x-forefront-prvs: 086831DFB4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(376002)(396003)(346002)(51444003)(189003)(199004)(53754006)(40434004)(8936002)(81156014)(6246003)(81166006)(106356001)(53386004)(105586002)(6306002)(2420400007)(14454004)(8676002)(53936002)(54896002)(6486002)(6436002)(102836004)(6506007)(99286004)(53546011)(76176011)(82746002)(6512007)(236005)(97736004)(256004)(14444005)(1680700002)(2906002)(486006)(229853002)(5024004)(68736007)(66066001)(476003)(4744004)(3846002)(83716004)(2616005)(6116002)(66574009)(11346002)(71200400001)(71190400001)(15650500001)(446003)(10090500001)(790700001)(21615005)(33656002)(478600001)(25786009)(5660300001)(186003)(966005)(93886005)(7736002)(786003)(316002)(36756003)(7110500001)(561944003)(26005)(606006)(58126008)(4326008)(6916009)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR02MB4141; H:SN6PR02MB5311.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: obJcFx1ZfsyUumD8+KfWJJJ8J4aiCw2/5ovdTP5FSsPIZ0PNfYXyRozb4ZnYN/NN3vmgEN4s+U9slqH/nVOXW0ltf+e62P8lq3lmUlgvcu6Kt3rbfmOUccviHCA+vOpxVN/JtHrSuHMUIqM70i9hdXWWgi6MtfbTGb0mmRkCYJn3ri0/kkPX+Ra4ypwC84wrgt831Ey79mCFQNU/f7pSorRcYrtXdWyz4sY3LraUC40QiKc6Q9VMULS2aE6+VQJhz9ysHrh8FT/W4Im3Mchnr4xHTOtElW7PbzsfFMcmD2tI+FadJexSKL6aUSVASYO33gK/Z5eCXJAVLP/+NxlBg4dWjpo57bJhEZyJ5B2tIQU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_8EAA626862A44948BAAF43093E6FF5EFadobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-Network-Message-Id: edc1aaac-866e-4fac-4778-08d65382dc18
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2018 09:38:02.2035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4141
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 26 Nov 2018 09:38:11 -0000

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

SGkgVG9yc3RlbiwgdGhhbmtzIGl0IG1ha2VzIHNlbnNlLg0KDQo+IERvIHlvdSBzZWUgYSBuZWVk
IHRvIGFkZCB0aGlzIHRvIHRoZSBCQ1A/DQoNCldlbGwsIHdoaWxlIHlvdSBhcmUgb24gaXQgdGhp
cyBtaWdodCBiZSBhIGdvb2QgY2hhbmNlIHRvIGluY2x1ZGUgdGhpcyBJTUhPLiBBdCBsZWFzdCBp
dCB3aWxsIGJlIGEgcG9pbnRlciBmb3IgYSBxdWVzdGlvbiB0aGF0IG1pZ2h0IHBvcCB1cCBxdWl0
ZSBvZnRlbi4NCg0KUmVnYXJkcw0KDQphbnRvbmlvDQoNCkZyb206IFRvcnN0ZW4gTG9kZGVyc3Rl
ZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KRGF0ZTogTW9uZGF5LCBOb3ZlbWJlciAyNiwg
MjAxOCBhdCAxMDozNCBBTQ0KVG86IEFudG9uaW8gU2Fuc28gPGFzYW5zb0BhZG9iZS5jb20+DQpD
YzogIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRI
LVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29k
ZSBpbnN0ZWFkIG9mIGltcGxpY2l0DQoNCkhpIEFudG9uaW8sDQoNCmdvb2QgcG9pbnQuIEkgd291
bGQgYXNzdW1lIG1vc3QgU1BBcyB3aWxsIGJlIHB1YmxpYyBjbGllbnRzLiBFdmVuIGlmIGEgc2lu
Z2xlIGluc3RhbmNlIHJlZ2lzdGVycyBkeW5hbWljYWxseSBhbmQgb2J0YWlucyBhIHNlY3JldCwg
dGhpcyBzZWNyZXQgY2FuIG9ubHkgYmUgdXNlZCBhcyBraW5kIG9mIOKAnnNhbWUgb3JpZ2luYXRv
cuKAnCBwcm9vZiAobXVjaCBsaWtlIFBLQ0UpLiBTUEFzIHdpdGggYSBiYWNrZW5kIGNhbiBhbHNv
IG1ha2UgdGhlIGJhY2tlbmQgYSBjb25maWRlbnRpYWwgY2xpZW50LiBUaGVyZSB3YXMgYSB0aHJl
YWQgYWJvdXQgU1BBcyAmIGJhY2tlbmRzIG9uIHRoZSBsaXN0IHJlY2VudGx5Lg0KDQpJIHdvdWxk
IGFyZ3VlIHRoaXMgaXMgaW5saW5lIHdpdGggUkZDNjc0OSBzZWN1cml0eSBjb25zaWRlcmF0aW9u
cy4gRG8geW91IHNlZSBhIG5lZWQgdG8gYWRkIHRoaXMgdG8gdGhlIEJDUD8NCg0Ka2luZCByZWdh
cmRzLA0KVG9yc3Rlbi4NCg0KDQpBbSAyNi4xMS4yMDE4IHVtIDA5OjE4IHNjaHJpZWIgQW50b25p
byBTYW5zbyA8YXNhbnNvQGFkb2JlLmNvbTxtYWlsdG86YXNhbnNvQGFkb2JlLmNvbT4+Og0KDQpI
aSBUb3JzdGVuLA0KDQoNCg0KbmljZSBvbmUuIEZXSVcgSSBhbSByZWFsbGx5IGhhcHB5IHRvIHNl
ZSB0aGlzIGhhcHBlbmluZy4NCg0KUXVpY2sgcXVlc3Rpb24gdGhvdWdoLiBXaGF0IGlzIHRoZSBy
ZWNvbW1lbmRhdGlvbiBhYm91dCBkZWFsaW5nIHdpdGggdGhlIGNsaWVudCBzZWNyZXQgaW4gdGhp
cyBzaXR1YXRpb24/DQoNCg0KDQpyZWdhcmRzDQoNCg0KDQphbnRvbmlvDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9y
ZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBUb3JzdGVuIExv
ZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJz
dGVkdC5uZXQ+Pg0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAyNSwgMjAxOCA2OjMyOjUzIFBNDQpU
bzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtP
QVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9u
IGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KDQpIaSBhbGwsDQoNCkkgd291bGQgbGlrZSB0byBz
dGF0ZSBhZ2FpbiB3aGF0IHRoZSBwcm9wb3NhbCBvZiB0aGUgYXV0aG9ycyBvZiB0aGUgU2VjdXJp
dHkgQkNQIGlzOg0KDQpIZXJlIGlzIHRoZSByZXNwZWN0aXZlIHRleHQgZnJvbSB0aGUgZHJhZnQ6
DQoNCuKAlOKAlA0KDQoyLjEuMi4gIEltcGxpY2l0IEdyYW50DQoNCiAgIFRoZSBpbXBsaWNpdCBn
cmFudCAocmVzcG9uc2UgdHlwZSAidG9rZW4iKSBhbmQgb3RoZXIgcmVzcG9uc2UgdHlwZXMNCiAg
IGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGlzc3VlIGFjY2VzcyB0b2tlbnMg
aW4gdGhlDQogICBhdXRob3JpemF0aW9uIHJlc3BvbnNlIGFyZSB2dWxuZXJhYmxlIHRvIGFjY2Vz
cyB0b2tlbiBsZWFrYWdlIGFuZA0KICAgYWNjZXNzIHRva2VuIHJlcGxheSBhcyBkZXNjcmliZWQg
aW4gU2VjdGlvbiAzLjEsIFNlY3Rpb24gMy4yLCBTZWN0aW9uIDMuMywgYW5kIFNlY3Rpb24gMy42
Lg0KDQogICBNb3Jlb3Zlciwgbm8gdmlhYmxlIG1lY2hhbmlzbSBleGlzdHMgdG8gY3J5cHRvZ3Jh
cGhpY2FsbHkgYmluZCBhY2Nlc3MNCiAgIHRva2VucyBpc3N1ZWQgaW4gdGhlIGF1dGhvcml6YXRp
b24gcmVzcG9uc2UgdG8gYSBjZXJ0YWluIGNsaWVudCBhcyBpdA0KICAgaXMgcmVjb21tZW5kZWQg
aW4gU2VjdGlvbiAyLjIuICBUaGlzIG1ha2VzIHJlcGxheSBkZXRlY3Rpb24gZm9yIHN1Y2gNCiAg
IGFjY2VzcyB0b2tlbnMgYXQgcmVzb3VyY2Ugc2VydmVycyBpbXBvc3NpYmxlLg0KDQogICBJbiBv
cmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGlt
cGxpY2l0DQogICBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBh
dXRob3JpemF0aW9uIHNlcnZlciB0bw0KICAgaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBh
dXRob3JpemF0aW9uIHJlc3BvbnNlLg0KDQogICBDbGllbnRzIFNIT1VMRCBpbnN0ZWFkIHVzZSB0
aGUgcmVzcG9uc2UgdHlwZSAiY29kZSIgKGFrYQ0KICAgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50
IHR5cGUpIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuMS4xIG9yIGFueQ0KICAgb3RoZXIgcmVz
cG9uc2UgdHlwZSB0aGF0IGNhdXNlcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gaXNzdWUN
CiAgIGFjY2VzcyB0b2tlbnMgaW4gdGhlIHRva2VuIHJlc3BvbnNlLiAgVGhpcyBhbGxvd3MgdGhl
IGF1dGhvcml6YXRpb24NCiAgIHNlcnZlciB0byBkZXRlY3QgcmVwbGF5IGF0dGVtcHRzIGFuZCBn
ZW5lcmFsbHkgcmVkdWNlcyB0aGUgYXR0YWNrDQogICBzdXJmYWNlIHNpbmNlIGFjY2VzcyB0b2tl
bnMgYXJlIG5vdCBleHBvc2VkIGluIFVSTHMuICBJdCBhbHNvIGFsbG93cw0KICAgdGhlIGF1dGhv
cml6YXRpb24gc2VydmVyIHRvIHNlbmRlci1jb25zdHJhaW4gdGhlIGlzc3VlZCB0b2tlbnMuDQri
gJTigJQNCg0KSW4gbXkgb2JzZXJ2YXRpb24sIGRpc2NvdXJhZ2luZyBpbXBsaWNpdCBzZWVtcyB0
byBiZSB0aGUgbGVzcyBjb250cm92ZXJzaWFsIGlzc3VlLg0KDQrigJ5vciBhbnkgb3RoZXIgcmVz
cG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBpc3N1ZSBhbiBh
Y2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2Uu4oCcIGluIHRoZSAzcmQg
cGFyYWdyYXBoIGNhdXNlZCBkaXNjdXNzaW9ucyBiZWNhdXNlIGl0IHN1Z2dlc3RzIHRvIGRpc2Nv
dXJhZ2UgZGV2ZWxvcGVycyBmcm9tIHVzaW5nIEFOWSByZXNwb25zZSB0eXBlIGlzc3VpbmcgYWNj
ZXNzIHRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS4gVGhpcyBpbmNsdWRlcyBP
SURD4oCZcyByZXNwb25zZSB0eXBlcyDigJ50b2tlbiBpZF90b2tlbuKAnCwg4oCeY29kZSB0b2tl
buKAnCAmIOKAnmNvZGUgdG9rZW4gaWRfdG9rZW7igJwsIHdoZXJlIGF0IGxlYXN0ICDigJ50b2tl
biBpZF90b2tlbuKAnCBpcyB1c2VkIGluIHRoZSB3aWxkIHRvIGltcGxlbWVudCBTUEFzLg0KDQpX
aHkgZGlkIHdlIGNvbWUgdXAgd2l0aCB0aGlzIHByb3Bvc2FsIGdpdmVuIGF0IGxlYXN0IOKAnnRv
a2VuIGlkX3Rva2Vu4oCcICYg4oCeY29kZSB0b2tlbiBpZF90b2tlbuKAnCBwcm90ZWN0IGFnYWlu
c3QgaW5qZWN0aW9uPw0KDQpUd28gcmVhc29uczoNCg0KMSkg4oCedG9rZW4gaWRfdG9rZW7igJwg
ZG9lcyBub3Qgc3VwcG9ydCBzZW5kZXIgY29uc3RyYWluZWQgdG9rZW5zLiBBbHNvIHVzZSBvZiBy
ZWZyZXNoIHRva2VucyB0byBmcmVxdWVudGx5IGlzc3VlIG5ldyBsaXZlLXRpbWUgYW5kIHByaXZp
bGVnZSByZXN0cmljdGVkIGFjY2VzcyB0b2tlbnMgaXMgbm90IHN1cHBvcnRlZC4g4oCeY29kZSB0
b2tlbiBpZF90b2tlbuKAnCBzZWVtcyBtb3JlIGNvbXBsZXggdGhhbiBqdXN0IOKAnmNvZGXigJwr
cGtjZSBmb3IgYWNoaWV2aW5nIHRoZSBzYW1lIGdvYWwuDQoNCjIpIFByb3RlY3Rpb24gYWdhaW5z
dCB0b2tlbiBsZWFrYWdlIGlzIHJhdGhlciB0aGluIGFuZCBmcmFnaWxlLiBUaGVyZSBpcyBqdXN0
IGEgc2luZ2xlIGxpbmUgb2YgZGVmZW5zZSAoQ1NQLCBvcGVuIHJlZGlyZWN0aW9uIHByZXZlbnRp
b24sIGJyb3dzZXIgaGlzdG9yeSBtYW5pcHVsYXRpb24pIGltcGxlbWVudGVkIGJ5IHRoZSBjbGll
bnQuDQoNCkRhbmllbCBhbmQgSSBjb2xsZWN0ZWQgc29tZSBtb3JlIGluZm9ybWF0aW9uIGFuZCBh
cmd1bWVudCBhdCBodHRwczovL2dpdGh1Yi5jb20vdGxvZGRlcnN0ZWR0L29hdXRoMl9zcGEvYmxv
Yi9tYXN0ZXIvUkVBRE1FLm1kIHRoYXQgeW91IG1pZ2h0IGxpa2UgdG8gZ2l2ZSBhIHJlYWQuDQoN
Ck15IGNvbmNsdXNpb24gYWZ0ZXIgMiB3ZWVrcyBvZiBpbnRlbnNpdmUgZGlzY3Vzc2lvbnMgd2l0
aCBTUEEgZGV2ZWxvcGVycyAobW9zdGx5IG9uIHR3aXR0ZXIpOiBjb2RlK3BrY2UgaXMgdGhlIG1v
cmUgc2VjdXJlLCBzaW1wbGVyLCBhbmQgbW9yZSB2ZXJzYXRpbGUgYXBwcm9hY2ggdG8gKGFsc28p
IGltcGxlbWVudCBTUEFzLiBJIHByZWZlciB0byBhcHByb2FjaCBkZXZlbG9wZXJzIHdpdGggYSBj
bGVhbiBhbmQgcm9idXN0IG1lc3NhZ2UgaW5zdGVhZCBvZiBhIGxlbmd0aHkgZGVzY3JpcHRpb24g
b2Ygd2hhdCBuZWVkcyB0byBnbyByaWdodCBpbiBvcmRlciB0byBzZWN1cmUgYSBTUEEgdXNpbmcg
T0F1dGguIFRoYXTigJlzIHdoeSBJIHRoaW5rIGNvZGUrcGtjZSBzaG91bGQgYmUgdGhlIHJlY29t
bWVuZGF0aW9uIG9mIG91ciB3b3JraW5nIGdyb3VwLg0KDQpTbyBwbGVhc2Ugdm90ZSBpbiBmYXZv
ciBvZiBvdXIgcHJvcG9zYWwuIEkgdGhpbmsgdGhhdOKAmXMgYSBodWdlIGltcHJvdmVtZW50IGZv
ciBPQXV0aC4NCg0Ka2luZCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQo+IEFtIDI1LjExLjIwMTgg
dW0gMTI6NTUgc2NocmllYiBIYW5zIFphbmRiZWx0IDxoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5l
dTxtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU+PjoNCj4NCj4gSSBzdHJvbmdseSBz
dXBwb3J0IHRoZSByZWNvbW1lbmRhdGlvbiBvZiB1c2luZyBjb2RlIGluc3RlYWQgb2YgaW1wbGlj
aXQuIEkgZG8gc28gYmFzZWQgb24gbXkgb3duIGV4cGVyaWVuY2UgaW4gdGhlIGZpZWxkIFsxXSBh
bmQgc3RpY2sgdG8gdGhhdCBhbHNvIGFmdGVyIHJlYWRpbmcgdGhlIGNvbW1lbnRzIGFuZCAod2hh
dCBJIHdvdWxkIGNhbGwpIHdvcmthcm91bmRzIG9uIHRoaXMgdGhyZWFkLg0KPg0KPiBIYW5zLg0K
Pg0KPiBbMV0gaHR0cHM6Ly9oYW5zemFuZGJlbHQud29yZHByZXNzLmNvbS8yMDE3LzAyLzI0L29w
ZW5pZC1jb25uZWN0LWZvci1zaW5nbGUtcGFnZS1hcHBsaWNhdGlvbnMvDQo+DQo+IE9uIFRodSwg
Tm92IDIyLCAyMDE4IGF0IDU6NDUgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2Rk
ZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQo+IHRo
YXTigJlzIGNlcnRhaW5seSB0cnVlLCBidXQgdGhhdCBtaWdodCBieSBhIHdlYiBzZXJ2ZXIgd2l0
aCBzdGF0aWMgY29udGVudCBvbmx5Lg0KPg0KPiBJZiB0aGUgc2VydmVyIGlzIGEgcmVhbCBiYWNr
ZW5kLCB0aGVyZSBpcyBldmVuIGxlc3MgcmVhc29ucyB0byB1c2UgYSBpbXBsaWNpdCBvciBoeWJy
aWQuIE5vIGV2ZW4gYSBwZXJmb3JtYW5jZSBnYWluIGluIGNvbXBhcmlzb24gdG8gY29kZS4NCj4N
Cj4gQW0gMjEuLjExLjIwMTggdW0gMTQ6MjQgc2NocmllYiBHZW9yZ2UgRmxldGNoZXIgPGdmZmxl
dGNoQGFvbC5jb208bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+PjoNCj4NCj4+IEFuIFNQQSBoYXMg
YSBiYWNrZW5kIGJlY2F1c2UgaXQgaGFzIHRvIGJlIGxvYWRlZCBmcm9tIHNvbWV3aGVyZSA6KQ0K
Pj4NCj4+IE9uIDExLzIxLzE4IDM6NDcgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgd3JvdGU6DQo+
Pj4gV2UgaGFkIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIHRvcGljIG9uIFR3aXR0ZXIgaHR0cHM6
Ly90d2l0dGVyLmNvbS9BcGwzYi9zdGF0dXMvMTA2NDg1NDUwNzYwNjIwODUxMw0KPj4+DQo+Pj4N
Cj4+PiBPdXRjb21lIGlzIFBPU1QgcmVxdWlyZXMgYSBiYWNrZW5kIHRvIHJlY2VpdmUgdGhlIHJl
cXVlc3Qgc28gaXTigJlzIG5vdCBhIHZpYWJsZSBzb2x1dGlvbiBmb3IgU1BBcy4NCj4+Pg0KPj4+
DQo+Pj4+IEFtIDIwLjExLjIwMTggdW0gMjM6Mjkgc2NocmllYiBKb2huIEJyYWRsZXkgPHZlN2p0
YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQo+Pj4+IDoNCj4+Pj4NCj4+
Pj4gUG9zdCByZXNwb25zZSB3b3JrcyBPSyBmb3Igc2VydmVyIGJhc2VkIGNsaWVudHMuICBJIGRv
bid0IHRoaW5rIFBPU1Qgd29ya3MgZm9yIHNpbmdsZSBwYWdlIGFwcGxpY2F0aW9ucy4NCj4+Pj4N
Cj4+Pj4gQmFzaWNhbGx5IHRoYXQgd291bGQgYmUgc29tZXRoaW5nIG1vcmUgbGlrZSBwb3N0bWVz
c2FnZSBiZXR3ZWVuIHR3byBKUyBhcHBzLg0KPj4+Pg0KPj4+PiBQb3N0bWVzc2FnZSBhbHNvIGhh
cyBzZWN1cml0eSBpc3N1ZXMgcGFzc2luZyBhIGFjY2VzcyB0b2tlbiBhbmQgbGVha2luZy4NCj4+
Pj4NCj4+Pj4gUGVyaGFwcyBzb21lb25lIG1vcmUgZmFtaWxpYXIgd2l0aCBTUEEgY2FuIGNvbW1l
bnQgb24gUE9TVC4NCj4+Pj4NCj4+Pj4gSm9obiBCLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBP
biBUdWUsIE5vdiAyMCwgMjAxOCwgNjo0MCBQTSBHZW9yZ2UgRmxldGNoZXIgPA0KPj4+PiBnZmZs
ZXRjaEBhb2wuY29tPG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPg0KPj4+PiAgd3JvdGU6DQo+Pj4+
IEhpIE1pa2UsDQo+Pj4+DQo+Pj4+IFRoZSBGb3JtIFBvc3QgUmVzcG9uc2UgTW9kZSBrZWVwcyB0
aGUgYWNjZXNzX3Rva2VuIG91dCBvZiB0aGUgVVJMLCBidXQgaXQgZG9lc24ndCBwcmV2ZW50IHRo
ZSB0b2tlbiBmcm9tIHRyYXZlcnNpbmcgdGhyb3VnaCB0aGUgYnJvd3Nlci4gU28gYSBtYW4taW4t
dGhlLWJyb3dzZXIgYXR0YWNrIG1heSBiZSBhYmxlIHRvIGludGVyY2VwdCB0aGUgdmFsdWVzLiBJ
dCBzaG91bGQgaGVscCB3aXRoIGxlYWthZ2UgaW4gbG9ncy4NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0K
Pj4+PiBHZW9yZ2UNCj4+Pj4NCj4+Pj4gT24gMTEvMjAvMTggNDowMCBQTSwgTWlrZSBKb25lcyB3
cm90ZToNCj4+Pj4NCj4+Pj4+IE5leHQgcXVlc3Rpb24g4oCTIGRvZXNu4oCZdCB1c2luZyB0aGUg
Rm9ybSBQb3N0IFJlc3BvbnNlIE1vZGUgaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29hdXRoLXYy
LWZvcm0tcG9zdC1yZXNwb25zZS1tb2RlLTFfMC5odG1sDQo+Pj4+PiAgbWl0aWdhdGUgdGhlIHRo
cmVhdHMgeW914oCZcmUgZGVzY3JpYmluZyBiZWxvdyBKb2huPyAgSWYgc28sIEkgYmVsaWV2ZSB0
aGUgU2VjdXJpdHkgVG9waWNzIGRyYWZ0IHNob3VsZCBzYXkgdGhpcy4NCj4+Pj4+DQo+Pj4+Pg0K
Pj4+Pj4NCj4+Pj4+IEkgYmVsaWV2ZSB3ZSBvd2UgaXQgdG8gcmVhZGVycyB0byBwcmVzZW50IHRo
ZSBjb21wbGV0ZSBwaWN0dXJlLCB3aGljaCBpcyB3aHkgSSBiZWxpZXZlIHRoYXQgZGVzY3JpYmlu
ZyBwcm9maWxlcyB1c2luZyBJRCBUb2tlbnMgYW5kIHRoZSBGb3JtIFBvc3QgUmVzcG9uc2UgTW9k
ZSBhcmUgaW4gc2NvcGUuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPj4+Pj4N
Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gRnJvbTogT0F1dGgNCj4+Pj4+IDxvYXV0aC1ib3VuY2VzQGll
dGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4NCj4+Pj4+ICBPbiBCZWhhbGYg
T2YgSm9obiBCcmFkbGV5DQo+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyMCwgMjAxOCA3
OjQ3IEFNDQo+Pj4+PiBUbzoNCj4+Pj4+IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz4NCj4+Pj4+DQo+Pj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0
eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxp
Y2l0DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBZZXMgdGhlIGF0X2hhc2ggcHJvdGVjdHMg
dGhlIGNsaWVudCBmcm9tIGFjY2VwdGluZyBhbiBpbmplY3RlZCBBVC4NCj4+Pj4+DQo+Pj4+PiBV
bmZvcnR1bmF0ZWx5IGl0IGRvZXNuJ3QgZG8gYW55dGhpbmcgdG8gcHJvdGVjdCBhZ2FpbnN0IGxl
YWthZ2UgaW4gbG9ncyBvciByZWRpcmVjdHMuDQo+Pj4+Pg0KPj4+Pj4gU28gd2l0aG91dCB0aGUg
QVQgdXNpbmcgc29tZSBzb3J0IG9mIFBPUCBtZWNoYW5pc20gaXQgaXMgaGFyZCB0byBzYXkgc2Vu
ZGluZyBpdCBpbiBhIHJlZGlyZWN0IGlzIGEgZ29vZCBzZWN1cml0eSBwcmFjdGljZS4NCj4+Pj4+
DQo+Pj4+PiBKb2huIEIuDQo+Pj4+Pg0KPj4+Pj4gT24gMTEvMjAvMjAxOCA0OjM1IEFNLCBUb3Jz
dGVuIExvZGRlcnN0ZWR0IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IEhpIE1pa2UsDQo+Pj4+Pg0KPj4+
Pj4gSSBhZ3JlZSB0aGF0IE9JREMgaHlicmlkIGZsb3dzIG9mZmVyIGFkZGl0aW9uYWwgc2VjdXJp
dHkgb3ZlciB0aGUgT0F1dGggaW1wbGljaXQgZ3JhbnQgYW5kIGFyZSB1c2VkIGluIHRoZSB3aWxk
LiBPbiBteSBzbGlkZXMgYW5kIGluIHRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhlIG5ldyBzZWN0
aW9uLCB3ZSBoYWQgaW5jbHVkZWQgdGhlIGh5YnJpZCBPSURDIGZsb3dzIGJlY2F1c2Ugb2YgdGhl
aXIga25vd24gdG9rZW4gaW5qZWN0aW9uIGNvdW50ZXJtZWFzdXJlcy4NCj4+Pj4+DQo+Pj4+PiBJ
IG5ldmVydGhlbGVzcyBmZWVsIHZlcnkgdW5jb21mb3J0YWJsZSB0byByZWNvbW1lbmQgdGhvc2Ug
Zmxvd3MgYW5kIGFueSBmbG93IGlzc3VpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgZnJvbnQgY2hh
bm5lbC4gSW4gdGhlIGNvdXJzZSBvZiB0aGUgZGV0YWlsZWQgcmV2aWV3IG9mIHRoZSBuZXcgdGV4
dCB3ZSByZWFsaXplZCB0d28gaXNzdWVzOg0KPj4+Pj4NCj4+Pj4+IDEpIFNpbmNlIHRoZSBhY2Nl
c3MgdG9rZW4gaXMgZXhwb3NlZCBpbiB0aGUgVVJMLCBzdWNoIGZsb3dzIHBvc3Nlc3MgYSBzaWdu
aWZpY2FudGx5IGhpZ2hlciByaXNrIHRvIGxlYWsgdGhlIGFjY2VzcyB0b2tlbiAoZS5nLiB0aHJv
dWdoIGJyb3dzZXIgaGlzdG9yeSwgb3BlbiByZWRpcmVjdGlvbiBhbmQgZXZlbiByZWZlcnJlciBo
ZWFkZXJzKSB0aGFuIHRoZSBjb2RlIGdyYW50Lg0KPj4+Pj4gMikgVGhlcmUgaXMgbm8gdmlhYmxl
IHdheSB0byBzZW5kZXIgY29uc3RyYWluIGFjY2VzcyB0b2tlbnMgaXNzdWVkIGluIHRoZSBmcm9u
dCBjaGFubmVsLiBHaXZlbiB0aGUgV0cgZGVjaWRlZCB0byByZWNvbW1lbmQgdXNlIG9mIHNlbmRl
ciBjb25zdHJhaW50IHRva2VucyAoDQo+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDkjc2VjdGlvbi0yLi4uMg0KPj4+Pj4g
KSwgaXQgc2VlbXMgY29udHJhZGljdG9yeSB0byByZWNvbW1lbmQgcmVzcG9uc2UgdHlwZXMgbm90
IHN1cHBvcnRpbmcgc3VjaCBhbiBhcHByb2FjaC4NCj4+Pj4+DQo+Pj4+PiBraW5kIHJlZ2FyZHMs
DQo+Pj4+PiBUb3JzdGVuLg0KPj4+Pj4NCj4+Pj4+IEFtIDE5LjExLjIwMTggdW0gMjM6MTMgc2No
cmllYiBNaWtlIEpvbmVzDQo+Pj4+PiA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1h
cmMuaWV0Zi5vcmc8bWFpbHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll
dGYub3JnPj4NCj4+Pj4+IDoNCj4+Pj4+DQo+Pj4+PiBUaGlzIGRlc2NyaXB0aW9uIG9mIHRoZSBz
aXR1YXRpb24gaXMgYW4gb3ZlcnNpbXBsaWZpY2F0aW9uLi4gIE9wZW5JRCBDb25uZWN0IHNlY3Vy
ZXMgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gYXR0YWNrcyBieSBp
bmNsdWRpbmcgdGhlIGF0X2hhc2ggKGFjY2VzcyB0b2tlbiBoYXNoKSBpbiB0aGUgSUQgVG9rZW4s
IGVuYWJsaW5nIHRoZSBjbGllbnQgdG8gdmFsaWRhdGUgdGhhdCB0aGUgYWNjZXNzIHRva2VuIHdh
cyBjcmVhdGVkIGJ5IHRoZSBpc3N1ZXIgaW4gdGhlIElEIFRva2VuICh3aGljaCBpcyBhbHNvIHRo
ZSBPQXV0aCBJc3N1ZXIsIGFzIGRlc2NyaWJlZCBpbiBSRkMgODQxNCkuICAoTm90ZSB0aGF0IHRo
aXMgbWl0aWdhdGlvbiB3YXMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtb2F1dGgtbWl4LXVwLW1p
dGlnYXRpb24uKQ0KPj4+Pj4NCj4+Pj4+IEdpdmVuIHRoZSBwcmV2YWxlbmNlIG9mIHRoaXMga25v
d24tZ29vZCBzb2x1dGlvbiBmb3Igc2VjdXJpbmcgdGhlIGltcGxpY2l0IGZsb3csIEkgd291bGQg
cmVxdWVzdCB0aGF0IHRoZSBkcmFmdCBiZSB1cGRhdGVkIHRvIGRlc2NyaWJlIHRoaXMgbWl0aWdh
dGlvbi4gIEF0IHRoZSBzYW1lIHRpbWUsIEnigJltIGZpbmUgd2l0aCB0aGUgZHJhZnQgcmVjb21t
ZW5kaW5nIHRoZSBjb2RlIGZsb3cgb3ZlciB0aGUgaW1wbGljaXQgZmxvdyB3aGVuIHRoaXMgbWl0
aWdhdGlvbiBpcyBub3QgdXNlZC4NCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmsgeW91LA0KPj4+
Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIC0tIE1pa2UNCj4+Pj4+DQo+Pj4+PiBGcm9tOiBPQXV0aA0KPj4+Pj4gPG9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPj4+Pj4g
IE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4+Pj4gU2VudDogTW9uZGF5LCBOb3Zl
bWJlciAxOSwgMjAxOCAyOjM0IEFNDQo+Pj4+PiBUbzogb2F1dGgNCj4+Pj4+IDxvYXV0aEBpZXRm
Lm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KPj4+Pj4NCj4+Pj4+IFN1YmplY3Q6IFtPQVVU
SC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNv
ZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KPj4+Pj4NCj4+Pj4+IEhpIGFsbCwNCj4+Pj4+DQo+Pj4+
PiBUaGUgYXV0aG9ycyBvZiB0aGUgT0F1dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNhbWUgdG8g
dGhlIGNvbmNsdXNpb24gdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVseSBzZWN1
cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2UgcG90ZW50
aWFsIHNvbHV0aW9ucyBsaWtlIHRva2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFybHkg
c3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzIHJlYXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dz
IGJyb3dzZXItYmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2lu
dCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVh
ZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9u
IChzZWVodHRwczovLw0KPj4+Pj4gZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0
ZXJpYWxzL3NsaWRlcy0xMDMtb2F1dGgtc2Vzc2ItZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10
b3BpY3MtMDE8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVyaWFs
cy9zbGlkZXMtMTAzLW9hdXRoLXNlc3NiLWRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNz
LTAxPg0KPj4+Pj4gKS4NCj4+Pj4+DQo+Pj4+PiBBIGh1bSBpbiB0aGUgcm9vbSBhdCBJRVRGIzEw
MyBjb25jbHVkZWQgc3Ryb25nIHN1cHBvcnQgZm9yIGhpcyByZWNvbW1lbmRhdGlvbnMuIFdlIHdv
dWxkIGxpa2UgdG8gY29uZmlybSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4NCj4+Pj4+DQo+
Pj4+PiBQbGVhc2UgcHJvdmlkZSBhIHJlc3BvbnNlIGJ5IERlY2VtYmVyIDNyZC4NCj4+Pj4+DQo+
Pj4+PiBDaWFvDQo+Pj4+PiBIYW5uZXMgJiBSaWZhYXQNCj4+Pj4+DQo+Pj4+PiBJTVBPUlRBTlQg
Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy
ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90
IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh
dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u
LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv
biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+
Pg0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+Pj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pj4NCj4+Pj4+DQo+
Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+Pg0KPj4+Pj4g
T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+Pj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+
IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBPQXV0aEBpZXRmLm9yZzxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pg0KPj4+PiBPQXV0aEBp
ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4gLS0NCj4gaGFucy56YW5kYmVsdEB6bWFydHpvbmUu
ZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KPiBabWFydFpvbmUgSUFNIC0g
d3d3LnptYXJ0em9uZS5ldTxodHRwOi8vd3d3LnptYXJ0em9uZS5ldT4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h
bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u
b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt
c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN
Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z
aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt
YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVG9yc3RlbiwgdGhhbmtzIGl0
IG1ha2VzIHNlbnNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IERvIHlvdSBzZWUgYSBu
ZWVkIHRvIGFkZCB0aGlzIHRvIHRoZSBCQ1A/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGws
IHdoaWxlIHlvdSBhcmUgb24gaXQgdGhpcyBtaWdodCBiZSBhIGdvb2QgY2hhbmNlIHRvIGluY2x1
ZGUgdGhpcyBJTUhPLiBBdCBsZWFzdCBpdCB3aWxsIGJlIGEgcG9pbnRlciBmb3IgYSBxdWVzdGlv
biB0aGF0IG1pZ2h0IHBvcCB1cCBxdWl0ZSBvZnRlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbnRvbmlvPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Ub3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBOb3ZlbWJlciAy
NiwgMjAxOCBhdCAxMDozNCBBTTxicj4NCjxiPlRvOiA8L2I+QW50b25pbyBTYW5zbyAmbHQ7YXNh
bnNvQGFkb2JlLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O29hdXRoQGlldGYub3JnJnF1
b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVU
SC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNv
ZGUgaW5zdGVhZCBvZiBpbXBsaWNpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQW50b25pbyw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z29vZCBwb2ludC4gSSB3b3VsZCBh
c3N1bWUgbW9zdCBTUEFzIHdpbGwgYmUgcHVibGljIGNsaWVudHMuIEV2ZW4gaWYgYSBzaW5nbGUg
aW5zdGFuY2UgcmVnaXN0ZXJzIGR5bmFtaWNhbGx5IGFuZCBvYnRhaW5zIGEgc2VjcmV0LCB0aGlz
IHNlY3JldCBjYW4gb25seSBiZSB1c2VkIGFzIGtpbmQgb2Yg4oCec2FtZSBvcmlnaW5hdG9y4oCc
IHByb29mIChtdWNoIGxpa2UgUEtDRSkuIFNQQXMgd2l0aCBhIGJhY2tlbmQgY2FuDQogYWxzbyBt
YWtlIHRoZSBiYWNrZW5kIGEgY29uZmlkZW50aWFsIGNsaWVudC4gVGhlcmUgd2FzIGEgdGhyZWFk
IGFib3V0IFNQQXMgJmFtcDsgYmFja2VuZHMgb24gdGhlIGxpc3QgcmVjZW50bHkuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYXJn
dWUgdGhpcyBpcyBpbmxpbmUgd2l0aCBSRkM2NzQ5IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiBE
byB5b3Ugc2VlIGEgbmVlZCB0byBhZGQgdGhpcyB0byB0aGUgQkNQPzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5raW5kIHJlZ2FyZHMsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub3JzdGVuLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkFtIDI2LjExLjIwMTggdW0gMDk6MTggc2No
cmllYiBBbnRvbmlvIFNhbnNvICZsdDs8YSBocmVmPSJtYWlsdG86YXNhbnNvQGFkb2JlLmNvbSI+
YXNhbnNvQGFkb2JlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt
YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y
OmJsYWNrIj5IaSBUb3JzdGVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn
aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt
YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Y29sb3I6YmxhY2siPm5pY2Ugb25lLiBGV0lXIEkgYW0gcmVhbGxseSBoYXBweSB0byBz
ZWUgdGhpcyBoYXBwZW5pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp
bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtjb2xvcjpibGFjayI+UXVpY2sgcXVlc3Rpb24gdGhvdWdoLiBXaGF0IGlzIHRoZSByZWNvbW1l
bmRhdGlvbiBhYm91dCBkZWFsaW5nIHdpdGggdGhlIGNsaWVudCBzZWNyZXQgaW4gdGhpcyBzaXR1
YXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj
ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy
Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi
bGFjayI+cmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu
O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s
b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46
MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Y29sb3I6YmxhY2siPmFudG9uaW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy
Ij4NCjxociBzaXplPSIwIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxk
aXYgaWQ9ImRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij4gT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0
aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFRvcnN0ZW4gTG9kZGVyc3Rl
ZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBs
b2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE5vdmVtYmVy
IDI1LCAyMDE4IDY6MzI6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0
aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
T0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlv
biBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQ8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+SGkgYWxsLCA8YnI+DQo8YnI+DQpJIHdvdWxkIGxpa2UgdG8gc3RhdGUgYWdh
aW4gd2hhdCB0aGUgcHJvcG9zYWwgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIFNlY3VyaXR5IEJDUCBp
czo8YnI+DQo8YnI+DQpIZXJlIGlzIHRoZSByZXNwZWN0aXZlIHRleHQgZnJvbSB0aGUgZHJhZnQ6
PGJyPg0KPGJyPg0K4oCU4oCUPGJyPg0KPGJyPg0KMi4xLjIuJm5ic3A7IEltcGxpY2l0IEdyYW50
PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFRoZSBpbXBsaWNpdCBncmFudCAocmVzcG9uc2UgdHlw
ZSAmcXVvdDt0b2tlbiZxdW90OykgYW5kIG90aGVyIHJlc3BvbnNlIHR5cGVzPGJyPg0KJm5ic3A7
Jm5ic3A7IGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGlzc3VlIGFjY2VzcyB0
b2tlbnMgaW4gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7IGF1dGhvcml6YXRpb24gcmVzcG9uc2UgYXJl
IHZ1bG5lcmFibGUgdG8gYWNjZXNzIHRva2VuIGxlYWthZ2UgYW5kPGJyPg0KJm5ic3A7Jm5ic3A7
IGFjY2VzcyB0b2tlbiByZXBsYXkgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLCBTZWN0aW9u
IDMuMiwgU2VjdGlvbiAzLjMsIGFuZCBTZWN0aW9uIDMuNi48YnI+DQo8YnI+DQombmJzcDsmbmJz
cDsgTW9yZW92ZXIsIG5vIHZpYWJsZSBtZWNoYW5pc20gZXhpc3RzIHRvIGNyeXB0b2dyYXBoaWNh
bGx5IGJpbmQgYWNjZXNzPGJyPg0KJm5ic3A7Jm5ic3A7IHRva2VucyBpc3N1ZWQgaW4gdGhlIGF1
dGhvcml6YXRpb24gcmVzcG9uc2UgdG8gYSBjZXJ0YWluIGNsaWVudCBhcyBpdDxicj4NCiZuYnNw
OyZuYnNwOyBpcyByZWNvbW1lbmRlZCBpbiBTZWN0aW9uIDIuMi4mbmJzcDsgVGhpcyBtYWtlcyBy
ZXBsYXkgZGV0ZWN0aW9uIGZvciBzdWNoPGJyPg0KJm5ic3A7Jm5ic3A7IGFjY2VzcyB0b2tlbnMg
YXQgcmVzb3VyY2Ugc2VydmVycyBpbXBvc3NpYmxlLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBJ
biBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhl
IGltcGxpY2l0PGJyPg0KJm5ic3A7Jm5ic3A7IGdyYW50IG9yIGFueSBvdGhlciByZXNwb25zZSB0
eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvPGJyPg0KJm5ic3A7Jm5ic3A7
IGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS48YnI+
DQo8YnI+DQombmJzcDsmbmJzcDsgQ2xpZW50cyBTSE9VTEQgaW5zdGVhZCB1c2UgdGhlIHJlc3Bv
bnNlIHR5cGUgJnF1b3Q7Y29kZSZxdW90OyAoYWthPGJyPg0KJm5ic3A7Jm5ic3A7IGF1dGhvcml6
YXRpb24gY29kZSBncmFudCB0eXBlKSBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjEuMSBvciBh
bnk8YnI+DQombmJzcDsmbmJzcDsgb3RoZXIgcmVzcG9uc2UgdHlwZSB0aGF0IGNhdXNlcyB0aGUg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gaXNzdWU8YnI+DQombmJzcDsmbmJzcDsgYWNjZXNzIHRv
a2VucyBpbiB0aGUgdG9rZW4gcmVzcG9uc2UuJm5ic3A7IFRoaXMgYWxsb3dzIHRoZSBhdXRob3Jp
emF0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7IHNlcnZlciB0byBkZXRlY3QgcmVwbGF5IGF0dGVtcHRz
IGFuZCBnZW5lcmFsbHkgcmVkdWNlcyB0aGUgYXR0YWNrPGJyPg0KJm5ic3A7Jm5ic3A7IHN1cmZh
Y2Ugc2luY2UgYWNjZXNzIHRva2VucyBhcmUgbm90IGV4cG9zZWQgaW4gVVJMcy4mbmJzcDsgSXQg
YWxzbyBhbGxvd3M8YnI+DQombmJzcDsmbmJzcDsgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRv
IHNlbmRlci1jb25zdHJhaW4gdGhlIGlzc3VlZCB0b2tlbnMuPGJyPg0K4oCU4oCUPGJyPg0KPGJy
Pg0KSW4gbXkgb2JzZXJ2YXRpb24sIGRpc2NvdXJhZ2luZyBpbXBsaWNpdCBzZWVtcyB0byBiZSB0
aGUgbGVzcyBjb250cm92ZXJzaWFsIGlzc3VlLjxicj4NCjxicj4NCuKAnm9yIGFueSBvdGhlciBy
ZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGlzc3VlIGFu
IGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS7igJwgaW4gdGhlIDNy
ZCBwYXJhZ3JhcGggY2F1c2VkIGRpc2N1c3Npb25zIGJlY2F1c2UgaXQgc3VnZ2VzdHMgdG8gZGlz
Y291cmFnZSBkZXZlbG9wZXJzIGZyb20gdXNpbmcgQU5ZIHJlc3BvbnNlIHR5cGUgaXNzdWluZyBh
Y2Nlc3MgdG9rZW5zIGluDQogdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UuIFRoaXMgaW5jbHVk
ZXMgT0lEQ+KAmXMgcmVzcG9uc2UgdHlwZXMg4oCedG9rZW4gaWRfdG9rZW7igJwsIOKAnmNvZGUg
dG9rZW7igJwgJmFtcDsg4oCeY29kZSB0b2tlbiBpZF90b2tlbuKAnCwgd2hlcmUgYXQgbGVhc3Qm
bmJzcDsg4oCedG9rZW4gaWRfdG9rZW7igJwgaXMgdXNlZCBpbiB0aGUgd2lsZCB0byBpbXBsZW1l
bnQgU1BBcy48YnI+DQo8YnI+DQpXaHkgZGlkIHdlIGNvbWUgdXAgd2l0aCB0aGlzIHByb3Bvc2Fs
IGdpdmVuIGF0IGxlYXN0IOKAnnRva2VuIGlkX3Rva2Vu4oCcICZhbXA7IOKAnmNvZGUgdG9rZW4g
aWRfdG9rZW7igJwgcHJvdGVjdCBhZ2FpbnN0IGluamVjdGlvbj88YnI+DQo8YnI+DQpUd28gcmVh
c29uczogPGJyPg0KPGJyPg0KMSkg4oCedG9rZW4gaWRfdG9rZW7igJwgZG9lcyBub3Qgc3VwcG9y
dCBzZW5kZXIgY29uc3RyYWluZWQgdG9rZW5zLiBBbHNvIHVzZSBvZiByZWZyZXNoIHRva2VucyB0
byBmcmVxdWVudGx5IGlzc3VlIG5ldyBsaXZlLXRpbWUgYW5kIHByaXZpbGVnZSByZXN0cmljdGVk
IGFjY2VzcyB0b2tlbnMgaXMgbm90IHN1cHBvcnRlZC4g4oCeY29kZSB0b2tlbiBpZF90b2tlbuKA
nCBzZWVtcyBtb3JlIGNvbXBsZXggdGhhbiBqdXN0IOKAnmNvZGXigJwmIzQzO3BrY2UgZm9yIGFj
aGlldmluZw0KIHRoZSBzYW1lIGdvYWwuPGJyPg0KPGJyPg0KMikgUHJvdGVjdGlvbiBhZ2FpbnN0
IHRva2VuIGxlYWthZ2UgaXMgcmF0aGVyIHRoaW4gYW5kIGZyYWdpbGUuIFRoZXJlIGlzIGp1c3Qg
YSBzaW5nbGUgbGluZSBvZiBkZWZlbnNlIChDU1AsIG9wZW4gcmVkaXJlY3Rpb24gcHJldmVudGlv
biwgYnJvd3NlciBoaXN0b3J5IG1hbmlwdWxhdGlvbikgaW1wbGVtZW50ZWQgYnkgdGhlIGNsaWVu
dC4NCjxicj4NCjxicj4NCkRhbmllbCBhbmQgSSBjb2xsZWN0ZWQgc29tZSBtb3JlIGluZm9ybWF0
aW9uIGFuZCBhcmd1bWVudCBhdCA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGxvZGRlcnN0
ZWR0L29hdXRoMl9zcGEvYmxvYi9tYXN0ZXIvUkVBRE1FLm1kIj4NCmh0dHBzOi8vZ2l0aHViLmNv
bS90bG9kZGVyc3RlZHQvb2F1dGgyX3NwYS9ibG9iL21hc3Rlci9SRUFETUUubWQ8L2E+IHRoYXQg
eW91IG1pZ2h0IGxpa2UgdG8gZ2l2ZSBhIHJlYWQuPGJyPg0KPGJyPg0KTXkgY29uY2x1c2lvbiBh
ZnRlciAyIHdlZWtzIG9mIGludGVuc2l2ZSBkaXNjdXNzaW9ucyB3aXRoIFNQQSBkZXZlbG9wZXJz
IChtb3N0bHkgb24gdHdpdHRlcik6IGNvZGUmIzQzO3BrY2UgaXMgdGhlIG1vcmUgc2VjdXJlLCBz
aW1wbGVyLCBhbmQgbW9yZSB2ZXJzYXRpbGUgYXBwcm9hY2ggdG8gKGFsc28pIGltcGxlbWVudCBT
UEFzLiBJIHByZWZlciB0byBhcHByb2FjaCBkZXZlbG9wZXJzIHdpdGggYSBjbGVhbiBhbmQgcm9i
dXN0IG1lc3NhZ2UgaW5zdGVhZA0KIG9mIGEgbGVuZ3RoeSBkZXNjcmlwdGlvbiBvZiB3aGF0IG5l
ZWRzIHRvIGdvIHJpZ2h0IGluIG9yZGVyIHRvIHNlY3VyZSBhIFNQQSB1c2luZyBPQXV0aC4gVGhh
dOKAmXMgd2h5IEkgdGhpbmsgY29kZSYjNDM7cGtjZSBzaG91bGQgYmUgdGhlIHJlY29tbWVuZGF0
aW9uIG9mIG91ciB3b3JraW5nIGdyb3VwLjxicj4NCjxicj4NClNvIHBsZWFzZSB2b3RlIGluIGZh
dm9yIG9mIG91ciBwcm9wb3NhbC4gSSB0aGluayB0aGF04oCZcyBhIGh1Z2UgaW1wcm92ZW1lbnQg
Zm9yIE9BdXRoLjxicj4NCjxicj4NCmtpbmQgcmVnYXJkcywgPGJyPg0KVG9yc3Rlbi4gPGJyPg0K
PGJyPg0KPGJyPg0KJmd0OyBBbSAyNS4xMS4yMDE4IHVtIDEyOjU1IHNjaHJpZWIgSGFucyBaYW5k
YmVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Ij5oYW5z
LnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT4mZ3Q7Ojxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHN0
cm9uZ2x5IHN1cHBvcnQgdGhlIHJlY29tbWVuZGF0aW9uIG9mIHVzaW5nIGNvZGUgaW5zdGVhZCBv
ZiBpbXBsaWNpdC4gSSBkbyBzbyBiYXNlZCBvbiBteSBvd24gZXhwZXJpZW5jZSBpbiB0aGUgZmll
bGQgWzFdIGFuZCBzdGljayB0byB0aGF0IGFsc28gYWZ0ZXIgcmVhZGluZyB0aGUgY29tbWVudHMg
YW5kICh3aGF0IEkgd291bGQgY2FsbCkgd29ya2Fyb3VuZHMgb24gdGhpcyB0aHJlYWQuPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IEhhbnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFsxXSA8YSBocmVmPSJo
dHRwczovL2hhbnN6YW5kYmVsdC53b3JkcHJlc3MuY29tLzIwMTcvMDIvMjQvb3BlbmlkLWNvbm5l
Y3QtZm9yLXNpbmdsZS1wYWdlLWFwcGxpY2F0aW9ucy8iPg0KaHR0cHM6Ly9oYW5zemFuZGJlbHQu
d29yZHByZXNzLmNvbS8yMDE3LzAyLzI0L29wZW5pZC1jb25uZWN0LWZvci1zaW5nbGUtcGFnZS1h
cHBsaWNhdGlvbnMvPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUaHUsIE5vdiAyMiwgMjAx
OCBhdCA1OjQ1IEFNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3Jz
dGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90
ZTo8YnI+DQomZ3Q7IHRoYXTigJlzIGNlcnRhaW5seSB0cnVlLCBidXQgdGhhdCBtaWdodCBieSBh
IHdlYiBzZXJ2ZXIgd2l0aCBzdGF0aWMgY29udGVudCBvbmx5Ljxicj4NCiZndDsgPGJyPg0KJmd0
OyBJZiB0aGUgc2VydmVyIGlzIGEgcmVhbCBiYWNrZW5kLCB0aGVyZSBpcyBldmVuIGxlc3MgcmVh
c29ucyB0byB1c2UgYSBpbXBsaWNpdCBvciBoeWJyaWQuIE5vIGV2ZW4gYSBwZXJmb3JtYW5jZSBn
YWluIGluIGNvbXBhcmlzb24gdG8gY29kZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgQW0gMjEuLjEx
LjIwMTggdW0gMTQ6MjQgc2NocmllYiBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0
bzpnZmZsZXRjaEBhb2wuY29tIj5nZmZsZXRjaEBhb2wuY29tPC9hPiZndDs6PGJyPg0KJmd0OyA8
YnI+DQomZ3Q7Jmd0OyBBbiBTUEEgaGFzIGEgYmFja2VuZCBiZWNhdXNlIGl0IGhhcyB0byBiZSBs
b2FkZWQgZnJvbSBzb21ld2hlcmUgOik8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiAx
MS8yMS8xOCAzOjQ3IEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IHdyb3RlOjxicj4NCiZndDsmZ3Q7
Jmd0OyBXZSBoYWQgYSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgdG9waWMgb24gVHdpdHRlciA8YSBo
cmVmPSJodHRwczovL3R3aXR0ZXIuY29tL0FwbDNiL3N0YXR1cy8xMDY0ODU0NTA3NjA2MjA4NTEz
Ij4NCmh0dHBzOi8vdHdpdHRlci5jb20vQXBsM2Ivc3RhdHVzLzEwNjQ4NTQ1MDc2MDYyMDg1MTM8
L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn
dDsgT3V0Y29tZSBpcyBQT1NUIHJlcXVpcmVzIGEgYmFja2VuZCB0byByZWNlaXZlIHRoZSByZXF1
ZXN0IHNvIGl04oCZcyBub3QgYSB2aWFibGUgc29sdXRpb24gZm9yIFNQQXMuPGJyPg0KJmd0OyZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEFtIDIwLjEx
LjIwMTggdW0gMjM6Mjkgc2NocmllYiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2
ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsgOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBQ
b3N0IHJlc3BvbnNlIHdvcmtzIE9LIGZvciBzZXJ2ZXIgYmFzZWQgY2xpZW50cy4mbmJzcDsgSSBk
b24ndCB0aGluayBQT1NUIHdvcmtzIGZvciBzaW5nbGUgcGFnZSBhcHBsaWNhdGlvbnMuJm5ic3A7
DQo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQmFzaWNhbGx5
IHRoYXQgd291bGQgYmUgc29tZXRoaW5nIG1vcmUgbGlrZSBwb3N0bWVzc2FnZSBiZXR3ZWVuIHR3
byBKUyBhcHBzLiZuYnNwOw0KPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7IFBvc3RtZXNzYWdlIGFsc28gaGFzIHNlY3VyaXR5IGlzc3VlcyBwYXNzaW5nIGEgYWNj
ZXNzIHRva2VuIGFuZCBsZWFraW5nLiZuYnNwOyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgUGVyaGFwcyBzb21lb25lIG1vcmUgZmFtaWxpYXIgd2l0aCBTUEEg
Y2FuIGNvbW1lbnQgb24gUE9TVC4mbmJzcDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7IEpvaG4gQi4gPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyBPbiBUdWUsIE5vdiAyMCwgMjAxOCwgNjo0MCBQTSBHZW9yZ2UgRmxldGNoZXIgJmx0Ozxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFvbC5jb20iPmdmZmxl
dGNoQGFvbC5jb208L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyB3cm90ZTo8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7IEhpIE1pa2UsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7IFRoZSBGb3JtIFBvc3QgUmVzcG9uc2UgTW9kZSBrZWVwcyB0aGUgYWNjZXNz
X3Rva2VuIG91dCBvZiB0aGUgVVJMLCBidXQgaXQgZG9lc24ndCBwcmV2ZW50IHRoZSB0b2tlbiBm
cm9tIHRyYXZlcnNpbmcgdGhyb3VnaCB0aGUgYnJvd3Nlci4gU28gYSBtYW4taW4tdGhlLWJyb3dz
ZXIgYXR0YWNrIG1heSBiZSBhYmxlIHRvIGludGVyY2VwdCB0aGUgdmFsdWVzLiBJdCBzaG91bGQg
aGVscCB3aXRoIGxlYWthZ2UgaW4gbG9ncy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgR2VvcmdlPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDExLzIwLzE4IDQ6MDAg
UE0sIE1pa2UgSm9uZXMgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyBOZXh0IHF1ZXN0aW9uIOKAkyBkb2VzbuKAmXQgdXNpbmcgdGhlIEZvcm0g
UG9zdCBSZXNwb25zZSBNb2RlIDxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0
aC12Mi1mb3JtLXBvc3QtcmVzcG9uc2UtbW9kZS0xXzAuaHRtbCI+DQpodHRwczovL29wZW5pZC5u
ZXQvc3BlY3Mvb2F1dGgtdjItZm9ybS1wb3N0LXJlc3BvbnNlLW1vZGUtMV8wLmh0bWw8L2E+PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgbWl0aWdhdGUgdGhlIHRocmVhdHMgeW914oCZ
cmUgZGVzY3JpYmluZyBiZWxvdyBKb2huPyZuYnNwOyBJZiBzbywgSSBiZWxpZXZlIHRoZSBTZWN1
cml0eSBUb3BpY3MgZHJhZnQgc2hvdWxkIHNheSB0aGlzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYmVsaWV2ZSB3ZSBvd2UgaXQgdG8g
cmVhZGVycyB0byBwcmVzZW50IHRoZSBjb21wbGV0ZSBwaWN0dXJlLCB3aGljaCBpcyB3aHkgSSBi
ZWxpZXZlIHRoYXQgZGVzY3JpYmluZyBwcm9maWxlcyB1c2luZyBJRCBUb2tlbnMgYW5kIHRoZSBG
b3JtIFBvc3QgUmVzcG9uc2UgTW9kZSBhcmUgaW4gc2NvcGUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IE9BdXRoIDxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+
b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
bmJzcDsgT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDIwLCAyMDE4IDc6NDcgQU08YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBUbzogPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv
Om9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBP
QXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0
ZWFkIG9mIGltcGxpY2l0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgWWVzIHRoZSBhdF9oYXNoIHByb3RlY3RzIHRoZSBjbGllbnQgZnJvbSBh
Y2NlcHRpbmcgYW4gaW5qZWN0ZWQgQVQuIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFVuZm9ydHVuYXRlbHkgaXQgZG9lc24ndCBkbyBhbnl0aGlu
ZyB0byBwcm90ZWN0IGFnYWluc3QgbGVha2FnZSBpbiBsb2dzIG9yIHJlZGlyZWN0cy48YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTbyB3aXRob3V0
IHRoZSBBVCB1c2luZyBzb21lIHNvcnQgb2YgUE9QIG1lY2hhbmlzbSBpdCBpcyBoYXJkIHRvIHNh
eSBzZW5kaW5nIGl0IGluIGEgcmVkaXJlY3QgaXMgYSBnb29kIHNlY3VyaXR5IHByYWN0aWNlLjxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEpvaG4g
Qi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBP
biAxMS8yMC8yMDE4IDQ6MzUgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgd3JvdGU6PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgTWlrZSwgPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
SSBhZ3JlZSB0aGF0IE9JREMgaHlicmlkIGZsb3dzIG9mZmVyIGFkZGl0aW9uYWwgc2VjdXJpdHkg
b3ZlciB0aGUgT0F1dGggaW1wbGljaXQgZ3JhbnQgYW5kIGFyZSB1c2VkIGluIHRoZSB3aWxkLiBP
biBteSBzbGlkZXMgYW5kIGluIHRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhlIG5ldyBzZWN0aW9u
LCB3ZSBoYWQgaW5jbHVkZWQgdGhlIGh5YnJpZCBPSURDIGZsb3dzIGJlY2F1c2Ugb2YgdGhlaXIg
a25vd24gdG9rZW4gaW5qZWN0aW9uIGNvdW50ZXJtZWFzdXJlcy48YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5ldmVydGhlbGVzcyBm
ZWVsIHZlcnkgdW5jb21mb3J0YWJsZSB0byByZWNvbW1lbmQgdGhvc2UgZmxvd3MgYW5kIGFueSBm
bG93IGlzc3VpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gSW4gdGhlIGNv
dXJzZSBvZiB0aGUgZGV0YWlsZWQgcmV2aWV3IG9mIHRoZSBuZXcgdGV4dCB3ZSByZWFsaXplZCB0
d28gaXNzdWVzOg0KPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgMSkgU2luY2UgdGhlIGFjY2VzcyB0b2tlbiBpcyBleHBvc2VkIGluIHRo
ZSBVUkwsIHN1Y2ggZmxvd3MgcG9zc2VzcyBhIHNpZ25pZmljYW50bHkgaGlnaGVyIHJpc2sgdG8g
bGVhayB0aGUgYWNjZXNzIHRva2VuIChlLmcuIHRocm91Z2ggYnJvd3NlciBoaXN0b3J5LCBvcGVu
IHJlZGlyZWN0aW9uIGFuZCBldmVuIHJlZmVycmVyIGhlYWRlcnMpIHRoYW4gdGhlIGNvZGUgZ3Jh
bnQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMikgVGhlcmUgaXMgbm8gdmlhYmxlIHdheSB0
byBzZW5kZXIgY29uc3RyYWluIGFjY2VzcyB0b2tlbnMgaXNzdWVkIGluIHRoZSBmcm9udCBjaGFu
bmVsLiBHaXZlbiB0aGUgV0cgZGVjaWRlZCB0byByZWNvbW1lbmQgdXNlIG9mIHNlbmRlciBjb25z
dHJhaW50IHRva2VucyAoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTA5
I3NlY3Rpb24tMi4uLjIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
b2F1dGgtc2VjdXJpdHktdG9waWNzLTA5I3NlY3Rpb24tMi4uLjI8L2E+PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgKSwgaXQgc2VlbXMgY29udHJhZGljdG9yeSB0byByZWNvbW1lbmQgcmVzcG9u
c2UgdHlwZXMgbm90IHN1cHBvcnRpbmcgc3VjaCBhbiBhcHByb2FjaC4NCjxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGtpbmQgcmVnYXJk
cyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUb3JzdGVuLiA8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBbSAxOS4xMS4yMDE4IHVt
IDIzOjEzIHNjaHJpZWIgTWlrZSBKb25lcyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnIj5NaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i
c3A7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgZGVzY3JpcHRpb24gb2YgdGhlIHNp
dHVhdGlvbiBpcyBhbiBvdmVyc2ltcGxpZmljYXRpb24uLiZuYnNwOyBPcGVuSUQgQ29ubmVjdCBz
ZWN1cmVzIHRoZSBpbXBsaWNpdCBmbG93IGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIGF0dGFja3Mg
YnkgaW5jbHVkaW5nIHRoZSBhdF9oYXNoIChhY2Nlc3MgdG9rZW4gaGFzaCkgaW4gdGhlIElEIFRv
a2VuLCBlbmFibGluZyB0aGUgY2xpZW50IHRvIHZhbGlkYXRlIHRoYXQgdGhlIGFjY2VzcyB0b2tl
bg0KIHdhcyBjcmVhdGVkIGJ5IHRoZSBpc3N1ZXIgaW4gdGhlIElEIFRva2VuICh3aGljaCBpcyBh
bHNvIHRoZSBPQXV0aCBJc3N1ZXIsIGFzIGRlc2NyaWJlZCBpbiBSRkMgODQxNCkuJm5ic3A7IChO
b3RlIHRoYXQgdGhpcyBtaXRpZ2F0aW9uIHdhcyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1vYXV0
aC1taXgtdXAtbWl0aWdhdGlvbi4pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgR2l2ZW4gdGhlIHByZXZhbGVuY2Ugb2YgdGhpcyBrbm93
bi1nb29kIHNvbHV0aW9uIGZvciBzZWN1cmluZyB0aGUgaW1wbGljaXQgZmxvdywgSSB3b3VsZCBy
ZXF1ZXN0IHRoYXQgdGhlIGRyYWZ0IGJlIHVwZGF0ZWQgdG8gZGVzY3JpYmUgdGhpcyBtaXRpZ2F0
aW9uLiZuYnNwOyBBdCB0aGUgc2FtZSB0aW1lLCBJ4oCZbSBmaW5lIHdpdGggdGhlIGRyYWZ0IHJl
Y29tbWVuZGluZyB0aGUgY29kZSBmbG93IG92ZXIgdGhlIGltcGxpY2l0IGZsb3cgd2hlbiB0aGlz
DQogbWl0aWdhdGlvbiBpcyBub3QgdXNlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw
OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBUaGFuayB5b3UsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IE9BdXRo
IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91
bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAxOCAyOjM0
IEFNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IG9hdXRoIDxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYu
b3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNv
bW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQ8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBhbGwsPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
VGhlIGF1dGhvcnMgb2YgdGhlIE9BdXRoIFNlY3VyaXR5IFRvcGljcyBkcmFmdCBjYW1lIHRvIHRo
ZSBjb25jbHVzaW9uIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGFkZXF1YXRlbHkgc2VjdXJl
IHRoZSBpbXBsaWNpdCBmbG93IGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIHNpbmNlIHBvdGVudGlh
bCBzb2x1dGlvbnMgbGlrZSB0b2tlbiBiaW5kaW5nIG9yIEpBUk0gYXJlIGluIGFuIGVhcmx5IHN0
YWdlIG9mIGFkb3B0aW9uLiBGb3IgdGhpcw0KIHJlYXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dz
IGJyb3dzZXItYmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2lu
dCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVh
ZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9u
IChzZWVodHRwczovLzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0
aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMSI+DQpkYXRhdHJhY2tl
ci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1k
cmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMTwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyApLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IEEgaHVtIGluIHRoZSByb29tIGF0IElFVEYjMTAzIGNvbmNsdWRlZCBzdHJv
bmcgc3VwcG9ydCBmb3IgaGlzIHJlY29tbWVuZGF0aW9ucy4gV2Ugd291bGQgbGlrZSB0byBjb25m
aXJtIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jm5ic3A7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBwcm92aWRlIGEgcmVzcG9u
c2UgYnkgRGVjZW1iZXIgM3JkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIYW5u
ZXMgJmFtcDsgUmlmYWF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg
ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi
ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg
Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvcg0KIGFueSBwdXJwb3NlLCBv
ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsmbmJzcDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBp
ZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4N
CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRo
QGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgLS0gPGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUu
ZXUiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPjxicj4NCiZndDsgWm1hcnRab25lIElB
TSAtIDxhIGhyZWY9Imh0dHA6Ly93d3cuem1hcnR6b25lLmV1Ij53d3cuem1hcnR6b25lLmV1PC9h
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_8EAA626862A44948BAAF43093E6FF5EFadobecom_--


From nobody Mon Nov 26 02:33:22 2018
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 76749130F12 for ; Mon, 26 Nov 2018 02:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 u2fUivAKXSPy for ; Mon, 26 Nov 2018 02:33:17 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFAF126CC7 for ; Mon, 26 Nov 2018 02:33:17 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id n133so999681wmd.4 for ; Mon, 26 Nov 2018 02:33:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ewfKtYh6NqU10BBtQmeZWqr5xIMZp1wGdzW6a1zUrQY=; b=WlKYsZNZTfuKzXILa03fHvQ5TIZo56OLr3xs9qmx8suBrQSsumpgS6AMKxQwus9Uuf jgX2UJbp816qzQF78eWx7D/1WJ7LMJMia2IkzHK7id40DCwTWG75g1MBnzdbdFFXr188 dylim12XdfKZ3eeVe9ctgk14ERLOjjteBjiq0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ewfKtYh6NqU10BBtQmeZWqr5xIMZp1wGdzW6a1zUrQY=; b=ni+tHERDHMI+z55xIz99+3AXt7KCisz0lE4lf5wI1jewfpdDpJYM/p0Yxp8hB3B9vU 7p03fG/1tH5VEKdD23FuNTZB5NUjAuERZLkO6RuwmCbZTcHrkDWqupLe43qeafUH9UZ3 CiTPsdMJC0lpz/7yQIu6JhDgv38x1+n5+8uW+pYy1MlnWe4jY4DsNgoNCJH8zOgFXTP9 wQXmT3K1ASiTovxDVeRp3OKf6J26ZG2RMBQuqQ2kfo0qrZn7SD9tJj0R18kcDe1A2hUN j3MLxYOEKkL3SqpP5SvjANgZegQJOpTGaXYR4OHjBueU18TfI1vFcV6AnhwkROUmoDgP L7uQ==
X-Gm-Message-State: AGRZ1gJPQjlV5WKBDtBGOVAgekJH8pVr3+o3FONTIlEvQUwZgVZeKiI7 D4KqUjlaeXodOBzEWaDM7vcAcg==
X-Google-Smtp-Source: AJdET5fkjYtmlDzT6yEPz+fYzVlLAj0C4fsc28bDSvmhow/VjnPPtoe0HLcR8svg3pLJUpvjmpiNBA==
X-Received: by 2002:a1c:7fc1:: with SMTP id a184mr22506198wmd.55.1543228395469;  Mon, 26 Nov 2018 02:33:15 -0800 (PST)
Received: from guest2s-mbp.lan (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id v133sm548058wmd.4.2018.11.26.02.33.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 02:33:14 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Neil Madden 
In-Reply-To: 
Date: Mon, 26 Nov 2018 10:33:13 +0000
Cc: Torsten Lodderstedt , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <584108B8-3293-48D4-9FD6-86DCF6CC34A3@forgerock.com>
References:   <15ECD17C-C2E3-487B-B61D-E67E5A060DE4@lodderstedt.net> 
To: Daniel Fett 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [OAUTH-WG] Binding Access Tokens is not enough!
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, 26 Nov 2018 10:33:20 -0000

I would perhaps clarify this a little, as it=E2=80=99s not really CORS =
that is doing the work here, but rather the same-origin policy (SOP) =E2=80=
=94 which is actually *relaxed* by CORS.=20

It is the fact that there is a non-safe header (Authorization) on the =
request that triggers the SOP protections - and it would do so even in =
an old pre-CORS browser. Otherwise CORS wouldn=E2=80=99t even be =
involved as the request would be considered =E2=80=9Csafe=E2=80=9D. For =
instance, if your (RS) API just requires an x-www-form-urlencoded POST =
body with the access token as one of the fields then I can always just =
create a form in a hidden iframe and submit it cross-origin with no =
problems, CORS or not. Adding the Authorization header prevents that - =
you can=E2=80=99t add a custom header to a form submission, and Ajax =
would not be allowed to make that request.

What CORS changes is that things that would previously be blocked =
outright now produce a CORS preflight to allow the destination origin to =
override the SOP and allow a request to go ahead anyway.

=E2=80=94 Neil

> On 26 Nov 2018, at 08:46, Daniel Fett  wrote:
>=20
> Yes. Token Binding enforces that only the right browser can send the =
token; in this browser, CORS enforces that only the correct origin can =
send the token.
>=20
> Am 25.11.18 um 19:46 schrieb Torsten Lodderstedt:
>> Does this mean the RS effectively relies on the user agent to enforce =
the sender constraint (via CORS policy)?
>>=20
>>=20
>>> Am 23.11.2018 um 14:54 schrieb Neil Madden =

>>> :
>>>=20
>>> Thanks for doing this Daniel, I think the proposed text is good.
>>>=20
>>> =E2=80=94 Neil
>>>=20
>>>=20
>>>> On 22 Nov 2018, at 14:42, Daniel Fett 
>>>>  wrote:
>>>>=20
>>>> Hi all,
>>>>=20
>>>> I would like to discuss a text proposal for the security BCP.
>>>>=20
>>>> Background:
>>>>=20
>>>> Yesterday, Neil pointed out the following problem with binding =
access tokens using mTLS or token binding in SPAs:
>>>>=20
>>>> "I am talking about scripts from places like ad servers that are =
usually included via an iframe to enforce the SOP and sandbox them from =
other scripts. If they get access to an access token - e.g. via =
document.referrer or a redirect or some other leak, then they still act =
within the same TLS context as the legitimate client."
>>>>=20
>>>> The problem is that a browser's TLS stack will attach the proof of =
possession no matter which origin started a request.
>>>>=20
>>>> (This seems like a real downside of token binding - why does it not =
have the "same site" option that cookies nowadays have?)
>>>>=20
>>>> I prepared the following addition to the security BCP and would =
like to hear your opinions:
>>>>=20
>>>> "It is important to note that constraining the sender of a token to =
a web browser (using a TLS-based method) does not constrain the origin =
of the script that uses the token (lack of origin binding). In other =
words, if access tokens are used in a browser (as in a single-page =
application, SPA) and the access tokens are sender-constrained using a =
TLS-based method, it must be ensured that origins other than the origin =
of the SPA cannot misuse the TLS-based sender authentication.
>>>>=20
>>>> The problem can be illustrated using an SPA on origin A that uses =
an access token AT that is bound to the TLS connection between the =
browser and the resource server R. If AT leaks to an attacker E, and =
there is, for example, an iframe from E's origin loaded in the web =
browser, that iframe can send a request to origin R using the access =
token AT. This request will contain the proof-of-posession of the (mTLS =
or token binding) key. The resource server R therefore cannot =
distinguish if a request containing a valid access token originates from =
origin A or origin E.
>>>>=20
>>>> If the resource server only accepts the access token in an =
Authorization header, then Cross-Origin Resource Sharing (CORS) will =
protect against this attack by default. If the resource server accepts =
the access tokens in other ways (e.g., as a URL parameter), or if the =
CORS policy of the resource server permits requests by origin E, then =
the TLS-based token binding only provides protection if the browser is =
offline."
>>>>=20
>>>>=20
>>>> The "summary" above this text reads as follows:
>>>>=20
>>>> "If access tokens are sender-constrained to a web browser, the =
resource server MUST ensure that the access token can only be used by =
the origin to which the access token was issued (origin binding). One =
solution for the resource server to accomplish this is to only accept =
the access token in an Authorization header (as described in RFC 6750) =
and to ensure that the active CORS policy prevents third parties from =
sending Authorization headers. See  for =
details."
>>>>=20
>>>> What do you think?
>>>>=20
>>>> -Daniel
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>>=20
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20


From nobody Mon Nov 26 06:08:36 2018
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 EA0C21277BB for ; Mon, 26 Nov 2018 06:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LzXzm0ea4rDF for ; Mon, 26 Nov 2018 06:08:29 -0800 (PST)
Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (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 68D1F130DE0 for ; Mon, 26 Nov 2018 06:08:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1543241308; bh=Py2mi+0uDW2nfzLayUy+rTS7DCUrWuS9RkqFv3+hgS0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=UCjZYSwp0FYTkQtTe85GyRYGEpJ7oPg5VIlHR6iesESp8SOUMrXlI3hi26C/7OJ1AYmWXLK/ItRaOFqbkgllhQz4uf7o8hb9w2Zg6gPanu9dB782PiFHyESPemF8RmeTdd0vuirbsDeA0NDkKq08/oa6cdDqU3xcxCAy+dsBkvaWF9tF99PJCOtyJjS5CvWQq6XJUjkce4e8nP2ozCl3gXPiubJ6so1k2+Mm/1eZLba+HZS1rEODwVXcpHVuXAvS4317grKTWlb01q0BLJ7GG6oFj845Cz12+WlI0Mwj8O29OIsBK9T4CmPET/L2loU6FLqOMVZHUz71m+ar6/Fa3A==
X-YMail-OSG: XDflGvoVM1kKZGEk8X73ws3hojfEhqKl5T3y7XAZtYtAJNOnMg5J0BQyUJ9W0Sm h0fUdGcJ6SFoE0BErNVqoOuHztIprgAfbWc1UxWxTbLWP9WjyIiC32gCM6TMj.FagUxwwPRQC1zM KQNEC3nu.lzVwHIIuHu5K.dN4ZfLQfKGxWdpmd2hRD_uvx2lJwS8y4WpPB8gZIj6C1IxCQvS.lcP .qV64Ws1ebj7SQedt_PCYux1Mufkx2cRRi4ofXESYvps2mUOm.1OcHh0ke_C0MjjptFFke7KIgOO eW.GrnwKwAxR7txdaQokt3AUWxd_E2yUHsDCCJfmKK8nx7g_FtEUECauu1Cc3EiYNVCIB.ELOMvv pdzz.cb20LG.ziK5siSj.7n7GYkiQinWqbPdvnEts.a5tBQv0l5wJ6cGbFgo50U4DPwO0FHN.3M1 ZrNBg6Se6It7gYCyphc.4rNel.mFYdtHbdf3X1EYVABq1maFCQ.AX2jnXQS9QD0X72zXK58qYocV C94Ikr7FETaZcB8ipFtHVij3hgzPtwrU7lx25ijSUiaYmpCtLaX7yx9GOsBP1MFDjvhsbI_ObNK_ kG.LJ5m8XoxK_WRY76xuCLat_HXPXyQ9hLJPwCJX2EtKdQrfXoKx8jcMDT.2S2E4iUhdodqjH4it ww3r1bqLNDSkTZ52YeyuFIGMjfKxEyBpMvqdyquguWsGYFoa2ZGU.ZAEjQLRBzQL_iz_aRJMTsds bcNKom0WIQcSgUeCCIK0aNJP5fGE7ERFZ.FICLpsMCLcR.iQ4wKoVQced6UM2sGStD2zn8AtGT2i FsrcP4cN5hqBgWHMu596Kn91Pqx31J6pmYpbr0puIGHqa6UiO3htDxkmunvBESBM3PqidC_E9Eza Ko1poKF2lz6vd2k3SRUemRENuvp3vqol2opZn8JH2BvaDhDfQlb7zL2kYkmxfn70v0tp.rNTVQ69 1mLt4dM2di3_pJdPPjJ6qQdxjfZ3NxH_1QDK8Rb9MYm7ZFDWaoeVsIY.9twDKU0CYxqAr23ve24K krt8Ub.PDUKBab5yttAaKScA6UhIYrQqUTVlvE0zulyB5lQD2q.9dLbSXYYUWo4jC0A--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Mon, 26 Nov 2018 14:08:28 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a2101c0e843296110c9aa760d61d794c;  Mon, 26 Nov 2018 14:08:27 +0000 (UTC)
To: Torsten Lodderstedt , "oauth@ietf.org" 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Mon, 26 Nov 2018 09:08:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------F056B5FBA875426DFA296B9B"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 26 Nov 2018 14:08:33 -0000

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

 > That’s why I think code+pkce should be the recommendation of our 
working group.

I am in favor of this recommendation for OAuth2 implementations.

On 11/25/18 12:32 PM, Torsten Lodderstedt wrote:
> Hi all,
>
> I would like to state again what the proposal of the authors of the Security BCP is:
>
> Here is the respective text from the draft:
>
> ——
>
> 2.1.2.  Implicit Grant
>
>     The implicit grant (response type "token") and other response types
>     causing the authorization server to issue access tokens in the
>     authorization response are vulnerable to access token leakage and
>     access token replay as described in Section 3.1, Section 3.2, Section 3.3, and Section 3.6.
>
>     Moreover, no viable mechanism exists to cryptographically bind access
>     tokens issued in the authorization response to a certain client as it
>     is recommended in Section 2.2.  This makes replay detection for such
>     access tokens at resource servers impossible.
>
>     In order to avoid these issues, Clients SHOULD NOT use the implicit
>     grant or any other response type causing the authorization server to
>     issue an access token in the authorization response.
>
>     Clients SHOULD instead use the response type "code" (aka
>     authorization code grant type) as specified in Section 2.1.1 or any
>     other response type that causes the authorization server to issue
>     access tokens in the token response.  This allows the authorization
>     server to detect replay attempts and generally reduces the attack
>     surface since access tokens are not exposed in URLs.  It also allows
>     the authorization server to sender-constrain the issued tokens.
> ——
>
> In my observation, discouraging implicit seems to be the less controversial issue.
>
> „or any other response type causing the authorization server to issue an access token in the authorization response.“ in the 3rd paragraph caused discussions because it suggests to discourage developers from using ANY response type issuing access tokens in the authorization response. This includes OIDC’s response types „token id_token“, „code token“ & „code token id_token“, where at least  „token id_token“ is used in the wild to implement SPAs.
>
> Why did we come up with this proposal given at least „token id_token“ & „code token id_token“ protect against injection?
>
> Two reasons:
>
> 1) „token id_token“ does not support sender constrained tokens. Also use of refresh tokens to frequently issue new live-time and privilege restricted access tokens is not supported. „code token id_token“ seems more complex than just „code“+pkce for achieving the same goal.
>
> 2) Protection against token leakage is rather thin and fragile. There is just a single line of defense (CSP, open redirection prevention, browser history manipulation) implemented by the client.
>
> Daniel and I collected some more information and argument at https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might like to give a read.
>
> My conclusion after 2 weeks of intensive discussions with SPA developers (mostly on twitter): code+pkce is the more secure, simpler, and more versatile approach to (also) implement SPAs. I prefer to approach developers with a clean and robust message instead of a lengthy description of what needs to go right in order to secure a SPA using OAuth. That’s why I think code+pkce should be the recommendation of our working group.
>
> So please vote in favor of our proposal. I think that’s a huge improvement for OAuth.
>
> kind regards,
> Torsten.
>
>
>> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt :
>>
>> I strongly support the recommendation of using code instead of implicit. I do so based on my own experience in the field [1] and stick to that also after reading the comments and (what I would call) workarounds on this thread.
>>
>> Hans.
>>
>> [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
>>
>> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt  wrote:
>> that’s certainly true, but that might by a web server with static content only.
>>
>> If the server is a real backend, there is even less reasons to use a implicit or hybrid. No even a performance gain in comparison to code.
>>
>> Am 21..11.2018 um 14:24 schrieb George Fletcher :
>>
>>> An SPA has a backend because it has to be loaded from somewhere :)
>>>
>>> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>>>> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513
>>>>
>>>>
>>>> Outcome is POST requires a backend to receive the request so it’s not a viable solution for SPAs.
>>>>
>>>>
>>>>> Am 20.11.2018 um 23:29 schrieb John Bradley 
>>>>> :
>>>>>
>>>>> Post response works OK for server based clients.  I don't think POST works for single page applications.
>>>>>
>>>>> Basically that would be something more like postmessage between two JS apps.
>>>>>
>>>>> Postmessage also has security issues passing a access token and leaking.
>>>>>
>>>>> Perhaps someone more familiar with SPA can comment on POST.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
>>>>> gffletch@aol.com
>>>>>   wrote:
>>>>> Hi Mike,
>>>>>
>>>>> The Form Post Response Mode keeps the access_token out of the URL, but it doesn't prevent the token from traversing through the browser. So a man-in-the-browser attack may be able to intercept the values. It should help with leakage in logs.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 11/20/18 4:00 PM, Mike Jones wrote:
>>>>>
>>>>>> Next question – doesn’t using the Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>>   mitigate the threats you’re describing below John?  If so, I believe the Security Topics draft should say this.
>>>>>>
>>>>>>   
>>>>>>
>>>>>> I believe we owe it to readers to present the complete picture, which is why I believe that describing profiles using ID Tokens and the Form Post Response Mode are in scope.
>>>>>>
>>>>>>   
>>>>>>
>>>>>>                                                         -- Mike
>>>>>>
>>>>>>   
>>>>>>
>>>>>> From: OAuth
>>>>>> 
>>>>>>   On Behalf Of John Bradley
>>>>>> Sent: Tuesday, November 20, 2018 7:47 AM
>>>>>> To:
>>>>>> oauth@ietf.org
>>>>>>
>>>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>>>>>>
>>>>>>   
>>>>>>
>>>>>> Yes the at_hash protects the client from accepting an injected AT.
>>>>>>
>>>>>> Unfortunately it doesn't do anything to protect against leakage in logs or redirects.
>>>>>>
>>>>>> So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>>>>>>
>>>>>> Hi Mike,
>>>>>>   
>>>>>> I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.
>>>>>>   
>>>>>> I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues:
>>>>>>   
>>>>>> 1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
>>>>>> 2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (
>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2
>>>>>> ), it seems contradictory to recommend response types not supporting such an approach.
>>>>>>   
>>>>>> kind regards,
>>>>>> Torsten.
>>>>>>   
>>>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones
>>>>>> 
>>>>>> :
>>>>>>   
>>>>>> This description of the situation is an oversimplification..  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>>>>>>   
>>>>>> Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
>>>>>>   
>>>>>>                                                                  Thank you,
>>>>>>                                                                  -- Mike
>>>>>>   
>>>>>> From: OAuth
>>>>>> 
>>>>>>   On Behalf Of Hannes Tschofenig
>>>>>> Sent: Monday, November 19, 2018 2:34 AM
>>>>>> To: oauth
>>>>>> 
>>>>>>
>>>>>> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>>>>>>   
>>>>>> Hi all,
>>>>>>   
>>>>>> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://
>>>>>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
>>>>>> ).
>>>>>>   
>>>>>> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
>>>>>>   
>>>>>> Please provide a response by December 3rd.
>>>>>>   
>>>>>> Ciao
>>>>>> Hannes & Rifaat
>>>>>>   
>>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
>>>>>> _______________________________________________
>>>>>> 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
>>
>>
>> -- 
>> hans.zandbelt@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    > That’s why I
    think code+pkce should be the recommendation of our working group.
    
    
    
    I am in favor of this recommendation for OAuth2 implementations.
    
    
    
    
    On 11/25/18 12:32 PM, Torsten
      Lodderstedt wrote:
    
    
    
    
    
      
    Hi all, 

I would like to state again what the proposal of the authors of the Security BCP is:

Here is the respective text from the draft:

——

2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2, Section 3.3, and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.
——

In my observation, discouraging implicit seems to be the less controversial issue.

„or any other response type causing the authorization server to issue an access token in the authorization response.“ in the 3rd paragraph caused discussions because it suggests to discourage developers from using ANY response type issuing access tokens in the authorization response. This includes OIDC’s response types „token id_token“, „code token“ & „code token id_token“, where at least  „token id_token“ is used in the wild to implement SPAs.

Why did we come up with this proposal given at least „token id_token“ & „code token id_token“ protect against injection?

Two reasons: 

1) „token id_token“ does not support sender constrained tokens. Also use of refresh tokens to frequently issue new live-time and privilege restricted access tokens is not supported. „code token id_token“ seems more complex than just „code“+pkce for achieving the same goal.

2) Protection against token leakage is rather thin and fragile. There is just a single line of defense (CSP, open redirection prevention, browser history manipulation) implemented by the client. 

Daniel and I collected some more information and argument at https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might like to give a read.

My conclusion after 2 weeks of intensive discussions with SPA developers (mostly on twitter): code+pkce is the more secure, simpler, and more versatile approach to (also) implement SPAs. I prefer to approach developers with a clean and robust message instead of a lengthy description of what needs to go right in order to secure a SPA using OAuth. That’s why I think code+pkce should be the recommendation of our working group.

So please vote in favor of our proposal. I think that’s a huge improvement for OAuth.

kind regards, 
Torsten. 



    
      
    
        
    Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu>:

I strongly support the recommendation of using code instead of implicit. I do so based on my own experience in the field [1] and stick to that also after reading the comments and (what I would call) workarounds on this thread.

Hans.

[1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/

On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
that’s certainly true, but that might by a web server with static content only.

If the server is a real backend, there is even less reasons to use a implicit or hybrid. No even a performance gain in comparison to code.

Am 21..11.2018 um 14:24 schrieb George Fletcher <gffletch@aol.com>:


    
        
    
          
    An SPA has a backend because it has to be loaded from somewhere :)

On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:

    
          
    
            
    We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513


Outcome is POST requires a backend to receive the request so it’s not a viable solution for SPAs.



    
            
    
              
    Am 20.11.2018 um 23:29 schrieb John Bradley <ve7jtb@ve7jtb.com>
:

Post response works OK for server based clients.  I don't think POST works for single page applications.  

Basically that would be something more like postmessage between two JS apps.  

Postmessage also has security issues passing a access token and leaking.  

Perhaps someone more familiar with SPA can comment on POST.  

John B. 



On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
gffletch@aol.com
 wrote:
Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but it doesn't prevent the token from traversing through the browser. So a man-in-the-browser attack may be able to intercept the values. It should help with leakage in logs.

Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:


    
              
    
                
    Next question – doesn’t using the Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
 mitigate the threats you’re describing below John?  If so, I believe the Security Topics draft should say this.

 

I believe we owe it to readers to present the complete picture, which is why I believe that describing profiles using ID Tokens and the Form Post Response Mode are in scope.

 

                                                       -- Mike

 

From: OAuth 
<oauth-bounces@ietf.org>
 On Behalf Of John Bradley
Sent: Tuesday, November 20, 2018 7:47 AM
To: 
oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

 

Yes the at_hash protects the client from accepting an injected AT. 

Unfortunately it doesn't do anything to protect against leakage in logs or redirects.

So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice.

John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:

Hi Mike, 
 
I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.
 
I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues: 
 
1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2
), it seems contradictory to recommend response types not supporting such an approach. 
 
kind regards,
Torsten. 
 
Am 19.11.2018 um 23:13 schrieb Mike Jones 
<Michael.Jones=40microsoft.com@dmarc.ietf.org>
:
 
This description of the situation is an oversimplification..  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
 
Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
 
                                                                Thank you,
                                                                -- Mike
 
From: OAuth 
<oauth-bounces@ietf.org>
 On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth 
<oauth@ietf.org>

Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
 
Hi all,
 
The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://
datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
).
 
A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
 
Please provide a response by December 3rd.
 
Ciao
Hannes & Rifaat
 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
_______________________________________________
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


-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

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

    
    
    
    
    
  


--------------F056B5FBA875426DFA296B9B--


From nobody Tue Nov 27 00:10:20 2018
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 4518E130E14 for ; Tue, 27 Nov 2018 00:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP4Y2fS0GcUr for ; Tue, 27 Nov 2018 00:10:14 -0800 (PST)
Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B35128CB7 for ; Tue, 27 Nov 2018 00:10:13 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id 625DB77EE6; Tue, 27 Nov 2018 17:10:12 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 14D794E0046; Tue, 27 Nov 2018 17:10:12 +0900 (JST)
Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wAR8ACx2012394; Tue, 27 Nov 2018 17:10:12 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp with ESMTP id wAR8ABJW012393; Tue, 27 Nov 2018 17:10:11 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAR8ABsS017481; Tue, 27 Nov 2018 17:10:11 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wAR8AB60017479; Tue, 27 Nov 2018 17:10:11 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAR8ABHv017475; Tue, 27 Nov 2018 17:10:11 +0900
Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM04PA.cu.nri.co.jp (172.159.253.24) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 27 Nov 2018 17:10:10 +0900
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.180) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 27 Nov 2018 17:10:10 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E0FGuC8cvo/sq2T13aVyxx5jBVd7lMBkW9eDZ+O9Acs=; b=yQHfVFGcL31uv+dHX6kWmUcxKztQfWLu9eW9Lgy12GxjWBeE+dzg2O+Q6B8d/b3rFhVqim6VVXT0DnwFt/3IukiRE6kFF9COyol7j1LWqjOjUKjTbimoJMvXhkRgpSr0e2xHhfyWj80bTTGgZ8Svuyi2KHxDEhTXSmf16mBoA9k=
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB1573.jpnprd01.prod.outlook.com (52.134.226.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Tue, 27 Nov 2018 08:10:09 +0000
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Tue, 27 Nov 2018 08:10:09 +0000
From: n-sakimura 
To: John Bradley , Rifaat Shekh-Yusef 
CC: IETF oauth WG 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwAYRRbAABPdaIAAES+SAAAK3nrAAAF3OoAAAbNqgAAVmmqAAAmlbIAAICS4gACl6t6AAAvL3oAAAb2yAAAAp/CAAAKUH4AAAhtsgABJqsog
Date: Tue, 27 Nov 2018 08:10:08 +0000
Message-ID: 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>  <465F5F67-E2FB-4A6B-B7AD-D1402FE7AD60@lodderstedt.net>  
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailadviser: 20170719
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [37.71.28.34]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; OSBPR01MB1573; 6:HdW/hAd7Hk816Kd7QPoiq3cN5rzlMBmGWSm75fE17q77FjlS3uVwEyG+NskeQKU/oB6JQLCx4CId/iYs/D+aDtmqoutBEoV2z0BSxZwt1pJO4kIzXPcIr0sS/F2gl22kuMEi0dqjisiLehgRecBePpprz8KzaOf6wCrgowRivv+skBMEtVsRvB5INgagaofXxAdnpf2fp/32ZFXj2Y0+aC3imvYhrJQ6S+taKLtFCLxogkQJWZPXcGxLJDuSDHiCB2U64Hh0CscvzvbK87tN+GHf/dISBerySjBtPXO2DVtJePNB26g1KRR9FmT8YSWva6SKcoAYJf7CWM3ijkdEJcaRYFBBsmfe93SYiAKXdCK66/Tu+HOzfJghuaQDlCb3qhFRB5v4cevRiZMO5LY3WkJBXvLF6B8pJ4ZRVhNBOjO71P+mguCGck4BjXYtctRA38GKHixYfUzuFLBikBTx/w==; 5:VUlbCkMCGuWo7d+ogRc5ivZmFBBPaiPIX/kma8A/kqAZlhJhvBffNAjDYUBJyu+cw8uam5xe6PCCviscYLSTsZErpB2ZgYNEUWloUPw4pHLrrKrOHoRW95wwEwso2L96dXA30nJIxxELg5Wm8wKfKdv8+YKCZsHmYn3zoqaSKuM=; 7:d2x1swWjVE6ucc1qKINuJ83vyQoC5qpnRJS0X8r4tiInCKMwqz7GPeBOdjPEqs83ZHSnyZWa7+nyTD4cVNE1GVefC/w5+n60cQ+Gyn2VGsdgo3OBrWfimJTaSeEgWyyCHEUD+q4BAmMxDYNT2m0yuA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2fef886a-ab5e-4ddb-45be-08d6543fbf6c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB1573; 
x-ms-traffictypediagnostic: OSBPR01MB1573:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(158342451672863)(85827821059158)(166708455590820)(111885846020525)(148322886591682)(47647156867600)(149059832740258)(31418570063057)(21532816269658);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231443)(944501410)(52105112)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB1573; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB1573; 
x-forefront-prvs: 086943A159
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39840400004)(346002)(376002)(136003)(366004)(51444003)(53754006)(40434004)(199004)(189003)(8676002)(71200400001)(256004)(97736004)(476003)(86362001)(74482002)(966005)(486006)(14454004)(102836004)(74316002)(105586002)(2906002)(110136005)(81156014)(39060400002)(229853002)(53546011)(14444005)(53386004)(71190400001)(6306002)(66066001)(9686003)(6436002)(66574009)(76176011)(316002)(26005)(106356001)(55016002)(7110500001)(15650500001)(5024004)(2420400007)(6116002)(4326008)(33656002)(6246003)(93886005)(186003)(790700001)(5660300001)(21615005)(7736002)(561944003)(11346002)(54896002)(606006)(4744004)(99286004)(25786009)(3846002)(53936002)(7696005)(236005)(508600001)(446003)(68736007)(6506007)(81166006)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB1573; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ckuDc6YsUn3rTRoKM+MyIb1Okn8nSR+mf6v6d0fApo4ETbYyDGO5FEjqEAs0pB6qNw8UeRibFzcdBS0THXFHPHL36JlapEPMkKWhFoSUr1sf5oUwKRDxBtCJ+ItPMJYqrOCyMQaLQFT9QfT95Nx057Wy8L5aThsvCBaLEED2WBULY9i7RHjf8QGp2sBrB9NPwOfy+L7H7vJ4oxegLeS/DSX+wSZHlXUm9xDJMFKdxeSh/YyK3viTtOGGiW7+aehkUc0L6VHU/EQjF7fbwEmEIxRh4IM+cAoSCIvvF2WtSBR5OEzYf0gwZhh5cTSW6nvXcC3Xrh11l49wwTk+YU56o/ex3y9BkbjmaXMAWFzkjVo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB2869CF11BB05CC93E092044AF9D00OSBPR01MB2869jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2fef886a-ab5e-4ddb-45be-08d6543fbf6c
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2018 08:10:08.9299 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB1573
X-OrganizationHeadersPreserved: OSBPR01MB1573.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 08:10:18 -0000

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

SSBhbSBub3Qgc3VyZSBhYm91dCBpdC4gVGhlcmUgYXJlIG5vIGNvbmZpZGVudGlhbCBpbXBsaWNp
dCBncmFudCBjbGllbnQgdGhhdCB1c2VzIGJlYXJlciB0b2tlbiBpcyBjb3JyZWN0LCBidXQgaWYg
dGhlIHRva2VuIGlzIHNlbmRlciBjb25zdHJhaW5lZCwgaXQgY2FuIGFjdCBhcyBhIGNvbmZpZGVu
dGlhbCBjbGllbnQuDQoNClRoaW5rIG9mIHRoZSBjYXNlIHdoZXJlIGFuIE9QIHRoYXQgaXMgdW5y
ZWFjaGVhYmxlIGRpcmVjdGx5IGZyb20gdGhlIGNsaWVudCBidXQgb25seSBpbmRpcmVjdGx5IHRo
cm91Z2ggdGhlIGJyb3dzZXIsIGUuZy4sIFNlbGYtSXNzdWVkIE9QIGFuZCBBUyB0aGF0IGFyZSBi
ZWhpbmQgdGhlIGNvcnBvcmF0ZSBmaXJld2FsbC4gVGhlbiwgc3VjaCBPUC9BUyBjYW4gcmV0dXJu
IGEgc2VuZGVyIGNvbnN0cmFpbmVkIHRva2VuIHRvIHRoZSBmdWxsIGNvbmZpZGVudGlhbCBjbGll
bnQgdGhhdCBjYW4gdXNlIGl0cyBrZXlzIHRvIGF1dGhlbnRpY2F0ZSBhZ2FpbnN0IHRoZSByZXNv
dXJjZSBzZXJ2ZXIgd2hlbiB1c2luZyB0aGUgc2VuZGVyIGNvbnN0cmFpbmVkIGFjY2VzcyB0b2tl
bi4gSSBjYXRlZ29yaXplIGl0IGFzIGEgY29uZmlkZW50aWFsIGNsaWVudC4NCg0KU28sIElNSE8s
IFJpZmFhdOKAmXMgcG9pbnQgaXMgY29ycmVjdC4NCg0KTmF0DQoNCkZyb206IE9BdXRoIDxvYXV0
aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBNb25k
YXksIE5vdmVtYmVyIDI2LCAyMDE4IDU6NTYgQU0NClRvOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJp
ZmFhdC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz4N
ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNvbW1l
bmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQNCg0KVGhlcmUgaXMgbm8g
c3VjaCB0aGluZyBhcyBhIGltcGxpY2l0IGNvbmZpZGVudGlhbCBjbGllbnQuDQoNCkltcGxpY2l0
IGNsaWVudHMgYXJlIG5vdCBhdXRoZW50aWNhdGVkLCBzbyBhcmUgbm90IGNvbmZpZGVudGlhbC4N
Cg0KWW91IGNvdWxkIGhhdmUgYSBoeWJyaWQgY2xpZW50IHVzaW5nIHRoZSAiY29kZSB0b2tlbiIg
cmVzcG9uc2UgdHlwZSB0aGF0IGlzIGNvbmZpZGVudGlhbCBmb3IgdGhlIGNvZGUgZmxvdyBidXQg
aSBkb24ndCB0aGluayBhbnlvbmUgd291bGQgY29uc2lkZXIgdGhlIHRva2VuIHJldHVybmVkIGZy
b20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXMgY29uZmlkZW50aWFsLg0KDQpUaGF0IHNo
b3VsZCBoYXZlIGJlZW4gaHlicmlkIHJhdGhlciB0aGFuIGNvbmZpZGVudGlhbCBJIHN1c3BlY3Qu
ICBQZXJoYXBzIGEgZXJyYXRhIGNvdWxkIGJlIGxvb2tlZCBhdC4NCg0KSm9obiBCLg0KDQpPbiBT
dW4sIE5vdiAyNSwgMjAxOCwgNDo1NSBQTSBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRm
QGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPiB3cm90ZToNClJGQzY3NDks
IFNlY3Rpb24gMy4xLjIuMiwgaW1wbGllcyB0aGF0IEltcGxpY2l0IGlzIG5vdCBsaW1pdGVkIHRv
IHB1YmxpYyBjbGllbnRzOg0KDQozLjEuMi4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y
ZmM2NzQ5I3NlY3Rpb24tMy4xLjIuMj4uICBSZWdpc3RyYXRpb24gUmVxdWlyZW1lbnRzDQoNCiAg
IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIGZvbGxvd2luZyBjbGll
bnRzIHRvDQoNCiAgIHJlZ2lzdGVyIHRoZWlyIHJlZGlyZWN0aW9uIGVuZHBvaW50Og0KDQogICBv
ICBQdWJsaWMgY2xpZW50cy4NCg0KICAgbyAgQ29uZmlkZW50aWFsIGNsaWVudHMgdXRpbGl6aW5n
IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlLi4uDQoNCg0KSSBkbyBub3Qga25vdyBpZiBhbnlib2R5
IGlzIHVzaW5nIEltcGxpY2l0IHdpdGggQ29uZmlkZW50aWFsIGNsaWVudHMsIGJ1dCBqdXN0IGlu
IGNhc2UsIHlvdSBtaWdodCB3YW50IHRvIG1ha2UgaXQgY2xlYXIgdGhhdCB5b3VyIHJlY29tbWVu
ZGF0aW9ucyBhcmUgc3BlY2lmaWNhbGx5IGZvciBwdWJsaWMgY2xpZW50cy4NCg0KUmVnYXJkcywN
CiBSaWZhYXQNCg0KDQoNCg0KT24gU3VuLCBOb3YgMjUsIDIwMTggYXQgMTo0MSBQTSBUb3JzdGVu
IExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2Rk
ZXJzdGVkdC5uZXQ+PiB3cm90ZToNCkhpIFJpZmFhdCwNCg0KdGhpcyBpcyBhIHJlY29tbWVuZGF0
aW9uIHRvIGFueW9uZSB1c2luZyBpbXBsaWNpdCBub3cuIEltcGxpY2l0IGNhbiBvbmx5IGJlIHVz
ZWQgd2l0aCBwdWJsaWMgY2xpZW50cywgc28gb25lIGNvdWxkIGludGVycHJldCBpdCB0aGF0IHdh
eS4gSSBjb3VsZCBhbHNvIGVudmlzaW9uIGEgU1BBIHRvIHVzZSBhIGJhY2tlbmQsIHdoaWNoIGlu
IHR1cm4gaXMgYSBjb25maWRlbnRpYWwgY2xpZW50LiBUaGVyZSB3ZXJlIHNvbWUgcG9zdHMgYWJv
dXQgdGhpcyB0b3BpYyBvbiB0aGUgbGlzdCByZWNlbnRseS4NCg0KRG9lcyB0aGlzIGFuc3dlciB5
b3VyIHF1ZXN0aW9uPw0KDQpraW5kIHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQo+IEFtIDI1LjExLjIw
MTggdW0gMTk6MjIgc2NocmllYiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWls
LmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj46DQo+DQo+IEhpIFRvcnN0ZW4sDQo+
DQo+IEkgYW0gYXNzdW1pbmcgdGhhdCB0aGVzZSByZWNvbW1lbmRhdGlvbnMgYXJlIG1haW5seSBm
b3IgUHVibGljIENsaWVudHMsIG5vdCBDb25maWRlbnRpYWwgQ2xpZW50czsgaXMgdGhhdCBjb3Jy
ZWN0Pw0KPg0KPiBSZWdhcmRzLA0KPiAgUmlmYWF0DQo+DQo+DQo+IE9uIFN1biwgTm92IDI1LCAy
MDE4IGF0IDEyOjMzIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQu
bmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KPiBIaSBhbGwsDQo+
DQo+IEkgd291bGQgbGlrZSB0byBzdGF0ZSBhZ2FpbiB3aGF0IHRoZSBwcm9wb3NhbCBvZiB0aGUg
YXV0aG9ycyBvZiB0aGUgU2VjdXJpdHkgQkNQIGlzOg0KPg0KPiBIZXJlIGlzIHRoZSByZXNwZWN0
aXZlIHRleHQgZnJvbSB0aGUgZHJhZnQ6DQo+DQo+IOKAlOKAlA0KPg0KPiAyLjEuMi4gIEltcGxp
Y2l0IEdyYW50DQo+DQo+ICAgIFRoZSBpbXBsaWNpdCBncmFudCAocmVzcG9uc2UgdHlwZSAidG9r
ZW4iKSBhbmQgb3RoZXIgcmVzcG9uc2UgdHlwZXMNCj4gICAgY2F1c2luZyB0aGUgYXV0aG9yaXph
dGlvbiBzZXJ2ZXIgdG8gaXNzdWUgYWNjZXNzIHRva2VucyBpbiB0aGUNCj4gICAgYXV0aG9yaXph
dGlvbiByZXNwb25zZSBhcmUgdnVsbmVyYWJsZSB0byBhY2Nlc3MgdG9rZW4gbGVha2FnZSBhbmQN
Cj4gICAgYWNjZXNzIHRva2VuIHJlcGxheSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEsIFNl
Y3Rpb24gMy4yLCBTZWN0aW9uIDMuMywgYW5kIFNlY3Rpb24gMy42Lg0KPg0KPiAgICBNb3Jlb3Zl
ciwgbm8gdmlhYmxlIG1lY2hhbmlzbSBleGlzdHMgdG8gY3J5cHRvZ3JhcGhpY2FsbHkgYmluZCBh
Y2Nlc3MNCj4gICAgdG9rZW5zIGlzc3VlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSB0
byBhIGNlcnRhaW4gY2xpZW50IGFzIGl0DQo+ICAgIGlzIHJlY29tbWVuZGVkIGluIFNlY3Rpb24g
Mi4yLiAgVGhpcyBtYWtlcyByZXBsYXkgZGV0ZWN0aW9uIGZvciBzdWNoDQo+ICAgIGFjY2VzcyB0
b2tlbnMgYXQgcmVzb3VyY2Ugc2VydmVycyBpbXBvc3NpYmxlLg0KPg0KPiAgICBJbiBvcmRlciB0
byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0
DQo+ICAgIGdyYW50IG9yIGFueSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhv
cml6YXRpb24gc2VydmVyIHRvDQo+ICAgIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0
aG9yaXphdGlvbiByZXNwb25zZS4NCj4NCj4gICAgQ2xpZW50cyBTSE9VTEQgaW5zdGVhZCB1c2Ug
dGhlIHJlc3BvbnNlIHR5cGUgImNvZGUiIChha2ENCj4gICAgYXV0aG9yaXphdGlvbiBjb2RlIGdy
YW50IHR5cGUpIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuMS4xIG9yIGFueQ0KPiAgICBvdGhl
ciByZXNwb25zZSB0eXBlIHRoYXQgY2F1c2VzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBp
c3N1ZQ0KPiAgICBhY2Nlc3MgdG9rZW5zIGluIHRoZSB0b2tlbiByZXNwb25zZS4gIFRoaXMgYWxs
b3dzIHRoZSBhdXRob3JpemF0aW9uDQo+ICAgIHNlcnZlciB0byBkZXRlY3QgcmVwbGF5IGF0dGVt
cHRzIGFuZCBnZW5lcmFsbHkgcmVkdWNlcyB0aGUgYXR0YWNrDQo+ICAgIHN1cmZhY2Ugc2luY2Ug
YWNjZXNzIHRva2VucyBhcmUgbm90IGV4cG9zZWQgaW4gVVJMcy4gIEl0IGFsc28gYWxsb3dzDQo+
ICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBzZW5kZXItY29uc3RyYWluIHRoZSBpc3N1
ZWQgdG9rZW5zLg0KPiDigJTigJQNCj4NCj4gSW4gbXkgb2JzZXJ2YXRpb24sIGRpc2NvdXJhZ2lu
ZyBpbXBsaWNpdCBzZWVtcyB0byBiZSB0aGUgbGVzcyBjb250cm92ZXJzaWFsIGlzc3VlLg0KPg0K
PiDigJ5vciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9u
IHNlcnZlciB0byBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVz
cG9uc2Uu4oCcIGluIHRoZSAzcmQgcGFyYWdyYXBoIGNhdXNlZCBkaXNjdXNzaW9ucyBiZWNhdXNl
IGl0IHN1Z2dlc3RzIHRvIGRpc2NvdXJhZ2UgZGV2ZWxvcGVycyBmcm9tIHVzaW5nIEFOWSByZXNw
b25zZSB0eXBlIGlzc3VpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNw
b25zZS4gVGhpcyBpbmNsdWRlcyBPSURD4oCZcyByZXNwb25zZSB0eXBlcyDigJ50b2tlbiBpZF90
b2tlbuKAnCwg4oCeY29kZSB0b2tlbuKAnCAmIOKAnmNvZGUgdG9rZW4gaWRfdG9rZW7igJwsIHdo
ZXJlIGF0IGxlYXN0ICDigJ50b2tlbiBpZF90b2tlbuKAnCBpcyB1c2VkIGluIHRoZSB3aWxkIHRv
IGltcGxlbWVudCBTUEFzLg0KPg0KPiBXaHkgZGlkIHdlIGNvbWUgdXAgd2l0aCB0aGlzIHByb3Bv
c2FsIGdpdmVuIGF0IGxlYXN0IOKAnnRva2VuIGlkX3Rva2Vu4oCcICYg4oCeY29kZSB0b2tlbiBp
ZF90b2tlbuKAnCBwcm90ZWN0IGFnYWluc3QgaW5qZWN0aW9uPw0KPg0KPiBUd28gcmVhc29uczoN
Cj4NCj4gMSkg4oCedG9rZW4gaWRfdG9rZW7igJwgZG9lcyBub3Qgc3VwcG9ydCBzZW5kZXIgY29u
c3RyYWluZWQgdG9rZW5zLiBBbHNvIHVzZSBvZiByZWZyZXNoIHRva2VucyB0byBmcmVxdWVudGx5
IGlzc3VlIG5ldyBsaXZlLXRpbWUgYW5kIHByaXZpbGVnZSByZXN0cmljdGVkIGFjY2VzcyB0b2tl
bnMgaXMgbm90IHN1cHBvcnRlZC4g4oCeY29kZSB0b2tlbiBpZF90b2tlbuKAnCBzZWVtcyBtb3Jl
IGNvbXBsZXggdGhhbiBqdXN0IOKAnmNvZGXigJwrcGtjZSBmb3IgYWNoaWV2aW5nIHRoZSBzYW1l
IGdvYWwuDQo+DQo+IDIpIFByb3RlY3Rpb24gYWdhaW5zdCB0b2tlbiBsZWFrYWdlIGlzIHJhdGhl
ciB0aGluIGFuZCBmcmFnaWxlLiBUaGVyZSBpcyBqdXN0IGEgc2luZ2xlIGxpbmUgb2YgZGVmZW5z
ZSAoQ1NQLCBvcGVuIHJlZGlyZWN0aW9uIHByZXZlbnRpb24sIGJyb3dzZXIgaGlzdG9yeSBtYW5p
cHVsYXRpb24pIGltcGxlbWVudGVkIGJ5IHRoZSBjbGllbnQuDQo+DQo+IERhbmllbCBhbmQgSSBj
b2xsZWN0ZWQgc29tZSBtb3JlIGluZm9ybWF0aW9uIGFuZCBhcmd1bWVudCBhdCBodHRwczovL2dp
dGh1Yi5jb20vdGxvZGRlcnN0ZWR0L29hdXRoMl9zcGEvYmxvYi9tYXN0ZXIvUkVBRE1FLm1kIHRo
YXQgeW91IG1pZ2h0IGxpa2UgdG8gZ2l2ZSBhIHJlYWQuDQo+DQo+IE15IGNvbmNsdXNpb24gYWZ0
ZXIgMiB3ZWVrcyBvZiBpbnRlbnNpdmUgZGlzY3Vzc2lvbnMgd2l0aCBTUEEgZGV2ZWxvcGVycyAo
bW9zdGx5IG9uIHR3aXR0ZXIpOiBjb2RlK3BrY2UgaXMgdGhlIG1vcmUgc2VjdXJlLCBzaW1wbGVy
LCBhbmQgbW9yZSB2ZXJzYXRpbGUgYXBwcm9hY2ggdG8gKGFsc28pIGltcGxlbWVudCBTUEFzLiBJ
IHByZWZlciB0byBhcHByb2FjaCBkZXZlbG9wZXJzIHdpdGggYSBjbGVhbiBhbmQgcm9idXN0IG1l
c3NhZ2UgaW5zdGVhZCBvZiBhIGxlbmd0aHkgZGVzY3JpcHRpb24gb2Ygd2hhdCBuZWVkcyB0byBn
byByaWdodCBpbiBvcmRlciB0byBzZWN1cmUgYSBTUEEgdXNpbmcgT0F1dGguIFRoYXTigJlzIHdo
eSBJIHRoaW5rIGNvZGUrcGtjZSBzaG91bGQgYmUgdGhlIHJlY29tbWVuZGF0aW9uIG9mIG91ciB3
b3JraW5nIGdyb3VwLg0KPg0KPiBTbyBwbGVhc2Ugdm90ZSBpbiBmYXZvciBvZiBvdXIgcHJvcG9z
YWwuIEkgdGhpbmsgdGhhdOKAmXMgYSBodWdlIGltcHJvdmVtZW50IGZvciBPQXV0aC4NCj4NCj4g
a2luZCByZWdhcmRzLA0KPiBUb3JzdGVuLg0KPg0KPg0KPiA+IEFtIDI1LjExLjIwMTggdW0gMTI6
NTUgc2NocmllYiBIYW5zIFphbmRiZWx0IDxoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWls
dG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU+PjoNCj4gPg0KPiA+IEkgc3Ryb25nbHkgc3Vw
cG9ydCB0aGUgcmVjb21tZW5kYXRpb24gb2YgdXNpbmcgY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0
LiBJIGRvIHNvIGJhc2VkIG9uIG15IG93biBleHBlcmllbmNlIGluIHRoZSBmaWVsZCBbMV0gYW5k
IHN0aWNrIHRvIHRoYXQgYWxzbyBhZnRlciByZWFkaW5nIHRoZSBjb21tZW50cyBhbmQgKHdoYXQg
SSB3b3VsZCBjYWxsKSB3b3JrYXJvdW5kcyBvbiB0aGlzIHRocmVhZC4NCj4gPg0KPiA+IEhhbnMu
DQo+ID4NCj4gPiBbMV0gaHR0cHM6Ly9oYW5zemFuZGJlbHQud29yZHByZXNzLmNvbS8yMDE3LzAy
LzI0L29wZW5pZC1jb25uZWN0LWZvci1zaW5nbGUtcGFnZS1hcHBsaWNhdGlvbnMvDQo+ID4NCj4g
PiBPbiBUaHUsIE5vdiAyMiwgMjAxOCBhdCA1OjQ1IEFNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRv
cnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdy
b3RlOg0KPiA+IHRoYXTigJlzIGNlcnRhaW5seSB0cnVlLCBidXQgdGhhdCBtaWdodCBieSBhIHdl
YiBzZXJ2ZXIgd2l0aCBzdGF0aWMgY29udGVudCBvbmx5Lg0KPiA+DQo+ID4gSWYgdGhlIHNlcnZl
ciBpcyBhIHJlYWwgYmFja2VuZCwgdGhlcmUgaXMgZXZlbiBsZXNzIHJlYXNvbnMgdG8gdXNlIGEg
aW1wbGljaXQgb3IgaHlicmlkLiBObyBldmVuIGEgcGVyZm9ybWFuY2UgZ2FpbiBpbiBjb21wYXJp
c29uIHRvIGNvZGUuDQo+ID4NCj4gPiBBbSAyMS4uMTEuMjAxOCB1bSAxNDoyNCBzY2hyaWViIEdl
b3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+
Og0KPiA+DQo+ID4+IEFuIFNQQSBoYXMgYSBiYWNrZW5kIGJlY2F1c2UgaXQgaGFzIHRvIGJlIGxv
YWRlZCBmcm9tIHNvbWV3aGVyZSA6KQ0KPiA+Pg0KPiA+PiBPbiAxMS8yMS8xOCAzOjQ3IEFNLCBU
b3JzdGVuIExvZGRlcnN0ZWR0IHdyb3RlOg0KPiA+Pj4gV2UgaGFkIGEgZGlzY3Vzc2lvbiBhYm91
dCB0aGlzIHRvcGljIG9uIFR3aXR0ZXIgaHR0cHM6Ly90d2l0dGVyLmNvbS9BcGwzYi9zdGF0dXMv
MTA2NDg1NDUwNzYwNjIwODUxMw0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBPdXRjb21lIGlzIFBPU1Qg
cmVxdWlyZXMgYSBiYWNrZW5kIHRvIHJlY2VpdmUgdGhlIHJlcXVlc3Qgc28gaXTigJlzIG5vdCBh
IHZpYWJsZSBzb2x1dGlvbiBmb3IgU1BBcy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IEFtIDIwLjEx
LjIwMTggdW0gMjM6Mjkgc2NocmllYiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1h
aWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQo+ID4+Pj4gOg0KPiA+Pj4+DQo+ID4+Pj4gUG9zdCBy
ZXNwb25zZSB3b3JrcyBPSyBmb3Igc2VydmVyIGJhc2VkIGNsaWVudHMuICBJIGRvbid0IHRoaW5r
IFBPU1Qgd29ya3MgZm9yIHNpbmdsZSBwYWdlIGFwcGxpY2F0aW9ucy4NCj4gPj4+Pg0KPiA+Pj4+
IEJhc2ljYWxseSB0aGF0IHdvdWxkIGJlIHNvbWV0aGluZyBtb3JlIGxpa2UgcG9zdG1lc3NhZ2Ug
YmV0d2VlbiB0d28gSlMgYXBwcy4NCj4gPj4+Pg0KPiA+Pj4+IFBvc3RtZXNzYWdlIGFsc28gaGFz
IHNlY3VyaXR5IGlzc3VlcyBwYXNzaW5nIGEgYWNjZXNzIHRva2VuIGFuZCBsZWFraW5nLg0KPiA+
Pj4+DQo+ID4+Pj4gUGVyaGFwcyBzb21lb25lIG1vcmUgZmFtaWxpYXIgd2l0aCBTUEEgY2FuIGNv
bW1lbnQgb24gUE9TVC4NCj4gPj4+Pg0KPiA+Pj4+IEpvaG4gQi4NCj4gPj4+Pg0KPiA+Pj4+DQo+
ID4+Pj4NCj4gPj4+PiBPbiBUdWUsIE5vdiAyMCwgMjAxOCwgNjo0MCBQTSBHZW9yZ2UgRmxldGNo
ZXIgPA0KPiA+Pj4+IGdmZmxldGNoQGFvbC5jb208bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+DQo+
ID4+Pj4gIHdyb3RlOg0KPiA+Pj4+IEhpIE1pa2UsDQo+ID4+Pj4NCj4gPj4+PiBUaGUgRm9ybSBQ
b3N0IFJlc3BvbnNlIE1vZGUga2VlcHMgdGhlIGFjY2Vzc190b2tlbiBvdXQgb2YgdGhlIFVSTCwg
YnV0IGl0IGRvZXNuJ3QgcHJldmVudCB0aGUgdG9rZW4gZnJvbSB0cmF2ZXJzaW5nIHRocm91Z2gg
dGhlIGJyb3dzZXIuIFNvIGEgbWFuLWluLXRoZS1icm93c2VyIGF0dGFjayBtYXkgYmUgYWJsZSB0
byBpbnRlcmNlcHQgdGhlIHZhbHVlcy4gSXQgc2hvdWxkIGhlbHAgd2l0aCBsZWFrYWdlIGluIGxv
Z3MuDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MsDQo+ID4+Pj4gR2VvcmdlDQo+ID4+Pj4NCj4gPj4+
PiBPbiAxMS8yMC8xOCA0OjAwIFBNLCBNaWtlIEpvbmVzIHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4+
IE5leHQgcXVlc3Rpb24g4oCTIGRvZXNu4oCZdCB1c2luZyB0aGUgRm9ybSBQb3N0IFJlc3BvbnNl
IE1vZGUgaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29hdXRoLXYyLWZvcm0tcG9zdC1yZXNwb25z
ZS1tb2RlLTFfMC5odG1sDQo+ID4+Pj4+ICBtaXRpZ2F0ZSB0aGUgdGhyZWF0cyB5b3XigJlyZSBk
ZXNjcmliaW5nIGJlbG93IEpvaG4/ICBJZiBzbywgSSBiZWxpZXZlIHRoZSBTZWN1cml0eSBUb3Bp
Y3MgZHJhZnQgc2hvdWxkIHNheSB0aGlzLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+
Pj4+PiBJIGJlbGlldmUgd2Ugb3dlIGl0IHRvIHJlYWRlcnMgdG8gcHJlc2VudCB0aGUgY29tcGxl
dGUgcGljdHVyZSwgd2hpY2ggaXMgd2h5IEkgYmVsaWV2ZSB0aGF0IGRlc2NyaWJpbmcgcHJvZmls
ZXMgdXNpbmcgSUQgVG9rZW5zIGFuZCB0aGUgRm9ybSBQb3N0IFJlc3BvbnNlIE1vZGUgYXJlIGlu
IHNjb3BlLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPiA+Pj4+
Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBGcm9tOiBPQXV0aA0KPiA+Pj4+PiA8b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+DQo+ID4+Pj4+
ICBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQo+ID4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVt
YmVyIDIwLCAyMDE4IDc6NDcgQU0NCj4gPj4+Pj4gVG86DQo+ID4+Pj4+IG9hdXRoQGlldGYub3Jn
PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4gPj4+Pj4NCj4gPj4+Pj4gU3ViamVjdDogUmU6IFtP
QVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9u
IGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+
Pj4+PiBZZXMgdGhlIGF0X2hhc2ggcHJvdGVjdHMgdGhlIGNsaWVudCBmcm9tIGFjY2VwdGluZyBh
biBpbmplY3RlZCBBVC4NCj4gPj4+Pj4NCj4gPj4+Pj4gVW5mb3J0dW5hdGVseSBpdCBkb2Vzbid0
IGRvIGFueXRoaW5nIHRvIHByb3RlY3QgYWdhaW5zdCBsZWFrYWdlIGluIGxvZ3Mgb3IgcmVkaXJl
Y3RzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTbyB3aXRob3V0IHRoZSBBVCB1c2luZyBzb21lIHNvcnQg
b2YgUE9QIG1lY2hhbmlzbSBpdCBpcyBoYXJkIHRvIHNheSBzZW5kaW5nIGl0IGluIGEgcmVkaXJl
Y3QgaXMgYSBnb29kIHNlY3VyaXR5IHByYWN0aWNlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBKb2huIEIu
DQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIDExLzIwLzIwMTggNDozNSBBTSwgVG9yc3RlbiBMb2RkZXJz
dGVkdCB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4gSGkgTWlrZSwNCj4gPj4+Pj4NCj4gPj4+Pj4g
SSBhZ3JlZSB0aGF0IE9JREMgaHlicmlkIGZsb3dzIG9mZmVyIGFkZGl0aW9uYWwgc2VjdXJpdHkg
b3ZlciB0aGUgT0F1dGggaW1wbGljaXQgZ3JhbnQgYW5kIGFyZSB1c2VkIGluIHRoZSB3aWxkLiBP
biBteSBzbGlkZXMgYW5kIGluIHRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhlIG5ldyBzZWN0aW9u
LCB3ZSBoYWQgaW5jbHVkZWQgdGhlIGh5YnJpZCBPSURDIGZsb3dzIGJlY2F1c2Ugb2YgdGhlaXIg
a25vd24gdG9rZW4gaW5qZWN0aW9uIGNvdW50ZXJtZWFzdXJlcy4NCj4gPj4+Pj4NCj4gPj4+Pj4g
SSBuZXZlcnRoZWxlc3MgZmVlbCB2ZXJ5IHVuY29tZm9ydGFibGUgdG8gcmVjb21tZW5kIHRob3Nl
IGZsb3dzIGFuZCBhbnkgZmxvdyBpc3N1aW5nIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGZyb250IGNo
YW5uZWwuIEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGRldGFpbGVkIHJldmlldyBvZiB0aGUgbmV3IHRl
eHQgd2UgcmVhbGl6ZWQgdHdvIGlzc3VlczoNCj4gPj4+Pj4NCj4gPj4+Pj4gMSkgU2luY2UgdGhl
IGFjY2VzcyB0b2tlbiBpcyBleHBvc2VkIGluIHRoZSBVUkwsIHN1Y2ggZmxvd3MgcG9zc2VzcyBh
IHNpZ25pZmljYW50bHkgaGlnaGVyIHJpc2sgdG8gbGVhayB0aGUgYWNjZXNzIHRva2VuIChlLmcu
IHRocm91Z2ggYnJvd3NlciBoaXN0b3J5LCBvcGVuIHJlZGlyZWN0aW9uIGFuZCBldmVuIHJlZmVy
cmVyIGhlYWRlcnMpIHRoYW4gdGhlIGNvZGUgZ3JhbnQuDQo+ID4+Pj4+IDIpIFRoZXJlIGlzIG5v
IHZpYWJsZSB3YXkgdG8gc2VuZGVyIGNvbnN0cmFpbiBhY2Nlc3MgdG9rZW5zIGlzc3VlZCBpbiB0
aGUgZnJvbnQgY2hhbm5lbC4gR2l2ZW4gdGhlIFdHIGRlY2lkZWQgdG8gcmVjb21tZW5kIHVzZSBv
ZiBzZW5kZXIgY29uc3RyYWludCB0b2tlbnMgKA0KPiA+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDkjc2VjdGlvbi0yLi4u
Mg0KPiA+Pj4+PiApLCBpdCBzZWVtcyBjb250cmFkaWN0b3J5IHRvIHJlY29tbWVuZCByZXNwb25z
ZSB0eXBlcyBub3Qgc3VwcG9ydGluZyBzdWNoIGFuIGFwcHJvYWNoLg0KPiA+Pj4+Pg0KPiA+Pj4+
PiBraW5kIHJlZ2FyZHMsDQo+ID4+Pj4+IFRvcnN0ZW4uDQo+ID4+Pj4+DQo+ID4+Pj4+IEFtIDE5
LjExLjIwMTggdW0gMjM6MTMgc2NocmllYiBNaWtlIEpvbmVzDQo+ID4+Pj4+IDxNaWNoYWVsLkpv
bmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuLi5j
b21AZG1hcmMuaWV0Zi5vcmc+Pg0KPiA+Pj4+PiA6DQo+ID4+Pj4+DQo+ID4+Pj4+IFRoaXMgZGVz
Y3JpcHRpb24gb2YgdGhlIHNpdHVhdGlvbiBpcyBhbiBvdmVyc2ltcGxpZmljYXRpb24uLiAgT3Bl
bklEIENvbm5lY3Qgc2VjdXJlcyB0aGUgaW1wbGljaXQgZmxvdyBhZ2FpbnN0IHRva2VuIGluamVj
dGlvbiBhdHRhY2tzIGJ5IGluY2x1ZGluZyB0aGUgYXRfaGFzaCAoYWNjZXNzIHRva2VuIGhhc2gp
IGluIHRoZSBJRCBUb2tlbiwgZW5hYmxpbmcgdGhlIGNsaWVudCB0byB2YWxpZGF0ZSB0aGF0IHRo
ZSBhY2Nlc3MgdG9rZW4gd2FzIGNyZWF0ZWQgYnkgdGhlIGlzc3VlciBpbiB0aGUgSUQgVG9rZW4g
KHdoaWNoIGlzIGFsc28gdGhlIE9BdXRoIElzc3VlciwgYXMgZGVzY3JpYmVkIGluIFJGQyA4NDE0
KS4gIChOb3RlIHRoYXQgdGhpcyBtaXRpZ2F0aW9uIHdhcyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0
Zi1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi4pDQo+ID4+Pj4+DQo+ID4+Pj4+IEdpdmVuIHRoZSBw
cmV2YWxlbmNlIG9mIHRoaXMga25vd24tZ29vZCBzb2x1dGlvbiBmb3Igc2VjdXJpbmcgdGhlIGlt
cGxpY2l0IGZsb3csIEkgd291bGQgcmVxdWVzdCB0aGF0IHRoZSBkcmFmdCBiZSB1cGRhdGVkIHRv
IGRlc2NyaWJlIHRoaXMgbWl0aWdhdGlvbi4gIEF0IHRoZSBzYW1lIHRpbWUsIEnigJltIGZpbmUg
d2l0aCB0aGUgZHJhZnQgcmVjb21tZW5kaW5nIHRoZSBjb2RlIGZsb3cgb3ZlciB0aGUgaW1wbGlj
aXQgZmxvdyB3aGVuIHRoaXMgbWl0aWdhdGlvbiBpcyBub3QgdXNlZC4NCj4gPj4+Pj4NCj4gPj4+
Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFRoYW5rIHlvdSwNCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4gPj4+Pj4NCj4g
Pj4+Pj4gRnJvbTogT0F1dGgNCj4gPj4+Pj4gPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiA+Pj4+PiAgT24gQmVoYWxmIE9mIEhhbm5lcyBU
c2Nob2ZlbmlnDQo+ID4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTggMjozNCBB
TQ0KPiA+Pj4+PiBUbzogb2F1dGgNCj4gPj4+Pj4gPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0
aEBpZXRmLm9yZz4+DQo+ID4+Pj4+DQo+ID4+Pj4+IFN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGgg
U2VjdXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBv
ZiBpbXBsaWNpdA0KPiA+Pj4+Pg0KPiA+Pj4+PiBIaSBhbGwsDQo+ID4+Pj4+DQo+ID4+Pj4+IFRo
ZSBhdXRob3JzIG9mIHRoZSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgZHJhZnQgY2FtZSB0byB0aGUg
Y29uY2x1c2lvbiB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBhZGVxdWF0ZWx5IHNlY3VyZSB0
aGUgaW1wbGljaXQgZmxvdyBhZ2FpbnN0IHRva2VuIGluamVjdGlvbiBzaW5jZSBwb3RlbnRpYWwg
c29sdXRpb25zIGxpa2UgdG9rZW4gYmluZGluZyBvciBKQVJNIGFyZSBpbiBhbiBlYXJseSBzdGFn
ZSBvZiBhZG9wdGlvbi4gRm9yIHRoaXMgcmVhc29uLCBhbmQgc2luY2UgQ09SUyBhbGxvd3MgYnJv
d3Nlci1iYXNlZCBhcHBzIHRvIHNlbmQgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LCBU
b3JzdGVuIHN1Z2dlc3RlZCB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9m
IHRoZSBpbXBsaWNpdCBncmFudCBpbiBjYWxsIGNhc2VzIGluIGhpcyBwcmVzZW50YXRpb24gKHNl
ZWh0dHBzOi8vDQo+ID4+Pj4+IGRhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVy
aWFscy9zbGlkZXMtMTAzLW9hdXRoLXNlc3NiLWRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9w
aWNzLTAxPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMv
c2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0w
MT4NCj4gPj4+Pj4gKS4NCj4gPj4+Pj4NCj4gPj4+Pj4gQSBodW0gaW4gdGhlIHJvb20gYXQgSUVU
RiMxMDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0IGZvciBoaXMgcmVjb21tZW5kYXRpb25zLiBX
ZSB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuDQo+ID4+
Pj4+DQo+ID4+Pj4+IFBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIgM3JkLg0K
PiA+Pj4+Pg0KPiA+Pj4+PiBDaWFvDQo+ID4+Pj4+IEhhbm5lcyAmIFJpZmFhdA0KPiA+Pj4+Pg0K
PiA+Pj4+PiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQg
YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn
ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg
dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0
byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBj
b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+ID4+Pj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IE9B
dXRoIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pg0KPiA+Pj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4N
Cj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4+Pj4+DQo+ID4+Pj4+IE9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+
PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4+
Pg0KPiA+Pj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPj4+PiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4+DQo+ID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBt
YWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+
ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+DQo+ID4N
Cj4gPiAtLQ0KPiA+IGhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRi
ZWx0QHptYXJ0em9uZS5ldT4NCj4gPiBabWFydFpvbmUgSUFNIC0gd3d3LnptYXJ0em9uZS5ldTxo
dHRwOi8vd3d3LnptYXJ0em9uZS5ldT4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEg
NiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0KaDUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6
Iuimi+WHuuOBlyA1IFwo5paH5a2XXCkiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h
cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl
ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl
ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDmm7jlvI/ku5jjgY0gXCjm
loflrZdcKSI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwg
bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs
Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MDQoJe21z
by1zdHlsZS1uYW1lOiJIVE1MIOabuOW8j+S7mOOBjSBcKOaWh+Wtl1wpIjsNCgltc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg5pu45byP5LuY44GNIjsNCglmb250
LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLm01ODk2OTQ4MDk5Mzc0NDk4MjczZ21haWwtaDUNCgl7
bXNvLXN0eWxlLW5hbWU6bV81ODk2OTQ4MDk5Mzc0NDk4MjczZ21haWwtaDU7fQ0Kc3Bhbi41DQoJ
e21zby1zdHlsZS1uYW1lOiLopovlh7rjgZcgNSBcKOaWh+Wtl1wpIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi6KaL5Ye644GXIDUiOw0KCWZvbnQtZmFtaWx5OiJB
cmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMkY1NDk2O30NCnNwYW4uMjINCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMt
c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo5OS4yNXB0IDMuMGNtIDMuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmIj5JIGFtIG5vdCBzdXJlIGFib3V0IGl0LiBUaGVyZSBhcmUgbm8gY29uZmlkZW50
aWFsIGltcGxpY2l0IGdyYW50IGNsaWVudCB0aGF0IHVzZXMgYmVhcmVyIHRva2VuIGlzIGNvcnJl
Y3QsIGJ1dCBpZiB0aGUgdG9rZW4gaXMgc2VuZGVyIGNvbnN0cmFpbmVkLCBpdCBjYW4gYWN0IGFz
IGEgY29uZmlkZW50aWFsIGNsaWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp
ZiI+VGhpbmsgb2YgdGhlIGNhc2Ugd2hlcmUgYW4gT1AgdGhhdCBpcyB1bnJlYWNoZWFibGUgZGly
ZWN0bHkgZnJvbSB0aGUgY2xpZW50IGJ1dCBvbmx5IGluZGlyZWN0bHkgdGhyb3VnaCB0aGUgYnJv
d3NlciwgZS5nLiwgU2VsZi1Jc3N1ZWQgT1AgYW5kIEFTIHRoYXQgYXJlIGJlaGluZCB0aGUgY29y
cG9yYXRlIGZpcmV3YWxsLiBUaGVuLA0KIHN1Y2ggT1AvQVMgY2FuIHJldHVybiBhIHNlbmRlciBj
b25zdHJhaW5lZCB0b2tlbiB0byB0aGUgZnVsbCBjb25maWRlbnRpYWwgY2xpZW50IHRoYXQgY2Fu
IHVzZSBpdHMga2V5cyB0byBhdXRoZW50aWNhdGUgYWdhaW5zdCB0aGUgcmVzb3VyY2Ugc2VydmVy
IHdoZW4gdXNpbmcgdGhlIHNlbmRlciBjb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW4uIEkgY2F0ZWdv
cml6ZSBpdCBhcyBhIGNvbmZpZGVudGlhbCBjbGllbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWYiPlNvLCBJTUhPLCBSaWZhYXTigJlzIHBvaW50IGlzIGNvcnJlY3QuDQo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk5hdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5v
cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpKb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50Ojwv
Yj4gTW9uZGF5LCBOb3ZlbWJlciAyNiwgMjAxOCA1OjU2IEFNPGJyPg0KPGI+VG86PC9iPiBSaWZh
YXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8
L2I+IElFVEYgb2F1dGggV0cgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1
dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhIGltcGxpY2l0IGNv
bmZpZGVudGlhbCBjbGllbnQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JbXBsaWNpdCBjbGllbnRzIGFyZSBub3QgYXV0aGVudGljYXRl
ZCwgc28gYXJlIG5vdCBjb25maWRlbnRpYWwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjb3VsZCBoYXZlIGEgaHlicmlkIGNs
aWVudCB1c2luZyB0aGUgJnF1b3Q7Y29kZSB0b2tlbiZxdW90OyByZXNwb25zZSB0eXBlIHRoYXQg
aXMgY29uZmlkZW50aWFsIGZvciB0aGUgY29kZSBmbG93IGJ1dCBpIGRvbid0IHRoaW5rIGFueW9u
ZSB3b3VsZCBjb25zaWRlciB0aGUgdG9rZW4gcmV0dXJuZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlv
biBlbmRwb2ludCBhcyBjb25maWRlbnRpYWwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc2hvdWxkIGhhdmUgYmVlbiBoeWJy
aWQgcmF0aGVyIHRoYW4gY29uZmlkZW50aWFsIEkgc3VzcGVjdC4mbmJzcDsgUGVyaGFwcyBhIGVy
cmF0YSBjb3VsZCBiZSBsb29rZWQgYXQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+T24gU3VuLCBOb3YgMjUsIDIwMTgsIDQ6NTUgUE0gUmlmYWF0IFNoZWtoLVl1c2Vm
ICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIj5yaWZhYXQuaWV0ZkBn
bWFpbC5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQzY3NDksIFNlY3Rpb24gMy4xLjIuMiwgaW1w
bGllcyB0aGF0IEltcGxpY2l0IGlzIG5vdCBsaW1pdGVkIHRvIHB1YmxpYyBjbGllbnRzOjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdp
bi1yaWdodDowY20iPg0KPGRpdj4NCjxoNSBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQi
PjxhIG5hbWU9Im1fNTg5Njk0ODA5OTM3NDQ5ODI3M19zZWN0aW9uLTMuMS4yLjIiPjwvYT48YSBo
cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMS4yLjIi
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O21fNTg5Njk0
ODA5OTM3NDQ5ODI3M19zZWN0aW9uLTNcLjFcLjJcLjImcXVvdDsiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+My4xLjIuMjwvc3Bh
bj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazomcXVvdDttXzU4OTY5NDgwOTkzNzQ0
OTgyNzNfc2VjdGlvbi0zXC4xXC4yXC4yJnF1b3Q7Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6JnF1b3Q7bV81ODk2OTQ4MDk5Mzc0NDk4MjczX3NlY3Rpb24tM1wuMVwuMlwu
MiZxdW90OyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjayI+LiZuYnNwOw0KIFJlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHM8
bzpwPjwvbzpwPjwvc3Bhbj48L2g1Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWst
YmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBh
dXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIGZvbGxvd2luZyBjbGllbnRzIHRv
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJicmVh
ay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVn
aXN0ZXIgdGhlaXIgcmVkaXJlY3Rpb24gZW5kcG9pbnQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+Jm5ic3A7Jm5i
c3A7IG8mbmJzcDsgUHVibGljIGNsaWVudHMuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRp
dj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IENvbmZpZGVudGlhbCBjbGllbnRzIHV0aWxpemlu
ZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZS4uLjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCBrbm93IGlmIGFueWJvZHkg
aXMgdXNpbmcgSW1wbGljaXQgd2l0aCBDb25maWRlbnRpYWwgY2xpZW50cywgYnV0IGp1c3QgaW4g
Y2FzZSwgeW91IG1pZ2h0IHdhbnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHlvdXIgcmVjb21tZW5k
YXRpb25zIGFyZSBzcGVjaWZpY2FsbHkgZm9yIHB1YmxpYyBjbGllbnRzLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIFN1biwgTm92IDI1LCAyMDE4IGF0IDE6NDEgUE0gVG9yc3RlbiBMb2RkZXJzdGVkdCAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFu
ayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+SGkgUmlmYWF0LDxicj4NCjxicj4NCnRoaXMgaXMgYSByZWNvbW1lbmRh
dGlvbiB0byBhbnlvbmUgdXNpbmcgaW1wbGljaXQgbm93LiBJbXBsaWNpdCBjYW4gb25seSBiZSB1
c2VkIHdpdGggcHVibGljIGNsaWVudHMsIHNvIG9uZSBjb3VsZCBpbnRlcnByZXQgaXQgdGhhdCB3
YXkuIEkgY291bGQgYWxzbyBlbnZpc2lvbiBhIFNQQSB0byB1c2UgYSBiYWNrZW5kLCB3aGljaCBp
biB0dXJuIGlzIGEgY29uZmlkZW50aWFsIGNsaWVudC4gVGhlcmUgd2VyZSBzb21lIHBvc3RzIGFi
b3V0IHRoaXMNCiB0b3BpYyBvbiB0aGUgbGlzdCByZWNlbnRseS4gPGJyPg0KPGJyPg0KRG9lcyB0
aGlzIGFuc3dlciB5b3VyIHF1ZXN0aW9uPzxicj4NCjxicj4NCmtpbmQgcmVnYXJkcyw8YnI+DQpU
b3JzdGVuLiA8YnI+DQo8YnI+DQomZ3Q7IEFtIDI1LjExLjIwMTggdW0gMTk6MjIgc2NocmllYiBS
aWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5j
b20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozo8YnI+DQom
Z3Q7IDxicj4NCiZndDsgSGkgVG9yc3Rlbiw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhbSBhc3N1
bWluZyB0aGF0IHRoZXNlIHJlY29tbWVuZGF0aW9ucyBhcmUgbWFpbmx5IGZvciBQdWJsaWMgQ2xp
ZW50cywgbm90IENvbmZpZGVudGlhbCBDbGllbnRzOyBpcyB0aGF0IGNvcnJlY3Q/PGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZuYnNwOyBSaWZhYXQ8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgPGJyPg0KJmd0OyBPbiBTdW4sIE5vdiAyNSwgMjAxOCBhdCAxMjozMyBQTSBUb3Jz
dGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5u
ZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3Rl
Ojxicj4NCiZndDsgSGkgYWxsLCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB3b3VsZCBsaWtlIHRv
IHN0YXRlIGFnYWluIHdoYXQgdGhlIHByb3Bvc2FsIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBTZWN1
cml0eSBCQ1AgaXM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhlcmUgaXMgdGhlIHJlc3BlY3RpdmUg
dGV4dCBmcm9tIHRoZSBkcmFmdDo8YnI+DQomZ3Q7IDxicj4NCiZndDsg4oCU4oCUPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDIuMS4yLiZuYnNwOyBJbXBsaWNpdCBHcmFudDxicj4NCiZndDsgPGJyPg0K
Jmd0OyZuYnNwOyAmbmJzcDsgVGhlIGltcGxpY2l0IGdyYW50IChyZXNwb25zZSB0eXBlICZxdW90
O3Rva2VuJnF1b3Q7KSBhbmQgb3RoZXIgcmVzcG9uc2UgdHlwZXM8YnI+DQomZ3Q7Jm5ic3A7ICZu
YnNwOyBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBpc3N1ZSBhY2Nlc3MgdG9r
ZW5zIGluIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGF1dGhvcml6YXRpb24gcmVzcG9uc2Ug
YXJlIHZ1bG5lcmFibGUgdG8gYWNjZXNzIHRva2VuIGxlYWthZ2UgYW5kPGJyPg0KJmd0OyZuYnNw
OyAmbmJzcDsgYWNjZXNzIHRva2VuIHJlcGxheSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEs
IFNlY3Rpb24gMy4yLCBTZWN0aW9uIDMuMywgYW5kIFNlY3Rpb24gMy42Ljxicj4NCiZndDsgPGJy
Pg0KJmd0OyZuYnNwOyAmbmJzcDsgTW9yZW92ZXIsIG5vIHZpYWJsZSBtZWNoYW5pc20gZXhpc3Rz
IHRvIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgYWNjZXNzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg
dG9rZW5zIGlzc3VlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSB0byBhIGNlcnRhaW4g
Y2xpZW50IGFzIGl0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgaXMgcmVjb21tZW5kZWQgaW4gU2Vj
dGlvbiAyLjIuJm5ic3A7IFRoaXMgbWFrZXMgcmVwbGF5IGRldGVjdGlvbiBmb3Igc3VjaDxicj4N
CiZndDsmbmJzcDsgJm5ic3A7IGFjY2VzcyB0b2tlbnMgYXQgcmVzb3VyY2Ugc2VydmVycyBpbXBv
c3NpYmxlLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgSW4gb3JkZXIgdG8gYXZv
aWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdDxicj4N
CiZndDsmbmJzcDsgJm5ic3A7IGdyYW50IG9yIGFueSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNp
bmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgaXNz
dWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgQ2xpZW50cyBTSE9VTEQgaW5zdGVhZCB1c2UgdGhl
IHJlc3BvbnNlIHR5cGUgJnF1b3Q7Y29kZSZxdW90OyAoYWthPGJyPg0KJmd0OyZuYnNwOyAmbmJz
cDsgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUpIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9u
IDIuMS4xIG9yIGFueTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG90aGVyIHJlc3BvbnNlIHR5cGUg
dGhhdCBjYXVzZXMgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGlzc3VlPGJyPg0KJmd0OyZu
YnNwOyAmbmJzcDsgYWNjZXNzIHRva2VucyBpbiB0aGUgdG9rZW4gcmVzcG9uc2UuJm5ic3A7IFRo
aXMgYWxsb3dzIHRoZSBhdXRob3JpemF0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgc2VydmVy
IHRvIGRldGVjdCByZXBsYXkgYXR0ZW1wdHMgYW5kIGdlbmVyYWxseSByZWR1Y2VzIHRoZSBhdHRh
Y2s8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBzdXJmYWNlIHNpbmNlIGFjY2VzcyB0b2tlbnMgYXJl
IG5vdCBleHBvc2VkIGluIFVSTHMuJm5ic3A7IEl0IGFsc28gYWxsb3dzPGJyPg0KJmd0OyZuYnNw
OyAmbmJzcDsgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIHNlbmRlci1jb25zdHJhaW4gdGhl
IGlzc3VlZCB0b2tlbnMuPGJyPg0KJmd0OyDigJTigJQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4g
bXkgb2JzZXJ2YXRpb24sIGRpc2NvdXJhZ2luZyBpbXBsaWNpdCBzZWVtcyB0byBiZSB0aGUgbGVz
cyBjb250cm92ZXJzaWFsIGlzc3VlLjxicj4NCiZndDsgPGJyPg0KJmd0OyDigJ5vciBhbnkgb3Ro
ZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBpc3N1
ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2Uu4oCcIGluIHRo
ZSAzcmQgcGFyYWdyYXBoIGNhdXNlZCBkaXNjdXNzaW9ucyBiZWNhdXNlIGl0IHN1Z2dlc3RzIHRv
IGRpc2NvdXJhZ2UgZGV2ZWxvcGVycyBmcm9tIHVzaW5nIEFOWSByZXNwb25zZSB0eXBlIGlzc3Vp
bmcgYWNjZXNzIHRva2VucyBpbg0KIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLiBUaGlzIGlu
Y2x1ZGVzIE9JREPigJlzIHJlc3BvbnNlIHR5cGVzIOKAnnRva2VuIGlkX3Rva2Vu4oCcLCDigJ5j
b2RlIHRva2Vu4oCcICZhbXA7IOKAnmNvZGUgdG9rZW4gaWRfdG9rZW7igJwsIHdoZXJlIGF0IGxl
YXN0Jm5ic3A7IOKAnnRva2VuIGlkX3Rva2Vu4oCcIGlzIHVzZWQgaW4gdGhlIHdpbGQgdG8gaW1w
bGVtZW50IFNQQXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoeSBkaWQgd2UgY29tZSB1cCB3aXRo
IHRoaXMgcHJvcG9zYWwgZ2l2ZW4gYXQgbGVhc3Qg4oCedG9rZW4gaWRfdG9rZW7igJwgJmFtcDsg
4oCeY29kZSB0b2tlbiBpZF90b2tlbuKAnCBwcm90ZWN0IGFnYWluc3QgaW5qZWN0aW9uPzxicj4N
CiZndDsgPGJyPg0KJmd0OyBUd28gcmVhc29uczogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEpIOKA
nnRva2VuIGlkX3Rva2Vu4oCcIGRvZXMgbm90IHN1cHBvcnQgc2VuZGVyIGNvbnN0cmFpbmVkIHRv
a2Vucy4gQWxzbyB1c2Ugb2YgcmVmcmVzaCB0b2tlbnMgdG8gZnJlcXVlbnRseSBpc3N1ZSBuZXcg
bGl2ZS10aW1lIGFuZCBwcml2aWxlZ2UgcmVzdHJpY3RlZCBhY2Nlc3MgdG9rZW5zIGlzIG5vdCBz
dXBwb3J0ZWQuIOKAnmNvZGUgdG9rZW4gaWRfdG9rZW7igJwgc2VlbXMgbW9yZSBjb21wbGV4IHRo
YW4ganVzdCDigJ5jb2Rl4oCcJiM0Mztwa2NlIGZvciBhY2hpZXZpbmcNCiB0aGUgc2FtZSBnb2Fs
Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAyKSBQcm90ZWN0aW9uIGFnYWluc3QgdG9rZW4gbGVha2Fn
ZSBpcyByYXRoZXIgdGhpbiBhbmQgZnJhZ2lsZS4gVGhlcmUgaXMganVzdCBhIHNpbmdsZSBsaW5l
IG9mIGRlZmVuc2UgKENTUCwgb3BlbiByZWRpcmVjdGlvbiBwcmV2ZW50aW9uLCBicm93c2VyIGhp
c3RvcnkgbWFuaXB1bGF0aW9uKSBpbXBsZW1lbnRlZCBieSB0aGUgY2xpZW50Lg0KPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IERhbmllbCBhbmQgSSBjb2xsZWN0ZWQgc29tZSBtb3JlIGluZm9ybWF0aW9u
IGFuZCBhcmd1bWVudCBhdCA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGxvZGRlcnN0ZWR0
L29hdXRoMl9zcGEvYmxvYi9tYXN0ZXIvUkVBRE1FLm1kIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw
czovL2dpdGh1Yi5jb20vdGxvZGRlcnN0ZWR0L29hdXRoMl9zcGEvYmxvYi9tYXN0ZXIvUkVBRE1F
Lm1kPC9hPiB0aGF0IHlvdSBtaWdodCBsaWtlIHRvIGdpdmUgYSByZWFkLjxicj4NCiZndDsgPGJy
Pg0KJmd0OyBNeSBjb25jbHVzaW9uIGFmdGVyIDIgd2Vla3Mgb2YgaW50ZW5zaXZlIGRpc2N1c3Np
b25zIHdpdGggU1BBIGRldmVsb3BlcnMgKG1vc3RseSBvbiB0d2l0dGVyKTogY29kZSYjNDM7cGtj
ZSBpcyB0aGUgbW9yZSBzZWN1cmUsIHNpbXBsZXIsIGFuZCBtb3JlIHZlcnNhdGlsZSBhcHByb2Fj
aCB0byAoYWxzbykgaW1wbGVtZW50IFNQQXMuIEkgcHJlZmVyIHRvIGFwcHJvYWNoIGRldmVsb3Bl
cnMgd2l0aCBhIGNsZWFuIGFuZCByb2J1c3QgbWVzc2FnZSBpbnN0ZWFkDQogb2YgYSBsZW5ndGh5
IGRlc2NyaXB0aW9uIG9mIHdoYXQgbmVlZHMgdG8gZ28gcmlnaHQgaW4gb3JkZXIgdG8gc2VjdXJl
IGEgU1BBIHVzaW5nIE9BdXRoLiBUaGF04oCZcyB3aHkgSSB0aGluayBjb2RlJiM0Mztwa2NlIHNo
b3VsZCBiZSB0aGUgcmVjb21tZW5kYXRpb24gb2Ygb3VyIHdvcmtpbmcgZ3JvdXAuPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IFNvIHBsZWFzZSB2b3RlIGluIGZhdm9yIG9mIG91ciBwcm9wb3NhbC4gSSB0
aGluayB0aGF04oCZcyBhIGh1Z2UgaW1wcm92ZW1lbnQgZm9yIE9BdXRoLjxicj4NCiZndDsgPGJy
Pg0KJmd0OyBraW5kIHJlZ2FyZHMsIDxicj4NCiZndDsgVG9yc3Rlbi4gPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBBbSAyNS4xMS4yMDE4IHVtIDEyOjU1IHNjaHJpZWIgSGFu
cyBaYW5kYmVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1
IiB0YXJnZXQ9Il9ibGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+Jmd0Ozo8YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgc3Ryb25nbHkgc3VwcG9ydCB0aGUgcmVjb21t
ZW5kYXRpb24gb2YgdXNpbmcgY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0LiBJIGRvIHNvIGJhc2Vk
IG9uIG15IG93biBleHBlcmllbmNlIGluIHRoZSBmaWVsZCBbMV0gYW5kIHN0aWNrIHRvIHRoYXQg
YWxzbyBhZnRlciByZWFkaW5nIHRoZSBjb21tZW50cyBhbmQgKHdoYXQgSSB3b3VsZCBjYWxsKSB3
b3JrYXJvdW5kcyBvbiB0aGlzIHRocmVhZC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IEhhbnMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBbMV0gPGEgaHJlZj0iaHR0cHM6
Ly9oYW5zemFuZGJlbHQud29yZHByZXNzLmNvbS8yMDE3LzAyLzI0L29wZW5pZC1jb25uZWN0LWZv
ci1zaW5nbGUtcGFnZS1hcHBsaWNhdGlvbnMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2hh
bnN6YW5kYmVsdC53b3JkcHJlc3MuY29tLzIwMTcvMDIvMjQvb3BlbmlkLWNvbm5lY3QtZm9yLXNp
bmdsZS1wYWdlLWFwcGxpY2F0aW9ucy88L2E+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyBPbiBUaHUsIE5vdiAyMiwgMjAxOCBhdCA1OjQ1IEFNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0
OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsi
PnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IHRo
YXTigJlzIGNlcnRhaW5seSB0cnVlLCBidXQgdGhhdCBtaWdodCBieSBhIHdlYiBzZXJ2ZXIgd2l0
aCBzdGF0aWMgY29udGVudCBvbmx5Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSWYg
dGhlIHNlcnZlciBpcyBhIHJlYWwgYmFja2VuZCwgdGhlcmUgaXMgZXZlbiBsZXNzIHJlYXNvbnMg
dG8gdXNlIGEgaW1wbGljaXQgb3IgaHlicmlkLiBObyBldmVuIGEgcGVyZm9ybWFuY2UgZ2FpbiBp
biBjb21wYXJpc29uIHRvIGNvZGUuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbSAy
MS4uMTEuMjAxOCB1bSAxNDoyNCBzY2hyaWViIEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmdmZmxldGNoQGFvbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nZmZsZXRjaEBhb2wuY29t
PC9hPiZndDs6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQW4gU1BBIGhhcyBh
IGJhY2tlbmQgYmVjYXVzZSBpdCBoYXMgdG8gYmUgbG9hZGVkIGZyb20gc29tZXdoZXJlIDopPGJy
Pg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IE9uIDExLzIxLzE4IDM6NDcgQU0s
IFRvcnN0ZW4gTG9kZGVyc3RlZHQgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgV2UgaGFk
IGEgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIHRvcGljIG9uIFR3aXR0ZXIgPGEgaHJlZj0iaHR0cHM6
Ly90d2l0dGVyLmNvbS9BcGwzYi9zdGF0dXMvMTA2NDg1NDUwNzYwNjIwODUxMyIgdGFyZ2V0PSJf
YmxhbmsiPg0KaHR0cHM6Ly90d2l0dGVyLmNvbS9BcGwzYi9zdGF0dXMvMTA2NDg1NDUwNzYwNjIw
ODUxMzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8
YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBPdXRjb21lIGlzIFBPU1QgcmVxdWlyZXMgYSBiYWNrZW5k
IHRvIHJlY2VpdmUgdGhlIHJlcXVlc3Qgc28gaXTigJlzIG5vdCBhIHZpYWJsZSBzb2x1dGlvbiBm
b3IgU1BBcy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8
YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgQW0gMjAuMTEuMjAxOCB1bSAyMzoyOSBzY2hyaWVi
IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyA6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyBQb3N0IHJlc3BvbnNlIHdvcmtzIE9LIGZvciBzZXJ2ZXIgYmFzZWQgY2xpZW50cy4m
bmJzcDsgSSBkb24ndCB0aGluayBQT1NUIHdvcmtzIGZvciBzaW5nbGUgcGFnZSBhcHBsaWNhdGlv
bnMuJm5ic3A7DQo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0
OyZndDsmZ3Q7IEJhc2ljYWxseSB0aGF0IHdvdWxkIGJlIHNvbWV0aGluZyBtb3JlIGxpa2UgcG9z
dG1lc3NhZ2UgYmV0d2VlbiB0d28gSlMgYXBwcy4mbmJzcDsNCjxicj4NCiZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUG9zdG1lc3NhZ2UgYWxzbyBoYXMg
c2VjdXJpdHkgaXNzdWVzIHBhc3NpbmcgYSBhY2Nlc3MgdG9rZW4gYW5kIGxlYWtpbmcuJm5ic3A7
IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
UGVyaGFwcyBzb21lb25lIG1vcmUgZmFtaWxpYXIgd2l0aCBTUEEgY2FuIGNvbW1lbnQgb24gUE9T
VC4mbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyBKb2huIEIuIDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0
OyZndDsmZ3Q7Jmd0OyBPbiBUdWUsIE5vdiAyMCwgMjAxOCwgNjo0MCBQTSBHZW9yZ2UgRmxldGNo
ZXIgJmx0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86Z2ZmbGV0
Y2hAYW9sLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdmZmxldGNoQGFvbC5jb208L2E+PGJyPg0KJmd0
OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0
OyBIaSBNaWtlLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsgVGhlIEZvcm0gUG9zdCBSZXNwb25zZSBNb2RlIGtlZXBzIHRoZSBhY2Nlc3NfdG9r
ZW4gb3V0IG9mIHRoZSBVUkwsIGJ1dCBpdCBkb2Vzbid0IHByZXZlbnQgdGhlIHRva2VuIGZyb20g
dHJhdmVyc2luZyB0aHJvdWdoIHRoZSBicm93c2VyLiBTbyBhIG1hbi1pbi10aGUtYnJvd3NlciBh
dHRhY2sgbWF5IGJlIGFibGUgdG8gaW50ZXJjZXB0IHRoZSB2YWx1ZXMuIEl0IHNob3VsZCBoZWxw
IHdpdGggbGVha2FnZSBpbiBsb2dzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom
Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBH
ZW9yZ2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm
Z3Q7IE9uIDExLzIwLzE4IDQ6MDAgUE0sIE1pa2UgSm9uZXMgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTmV4dCBxdWVzdGlv
biDigJMgZG9lc27igJl0IHVzaW5nIHRoZSBGb3JtIFBvc3QgUmVzcG9uc2UgTW9kZSA8YSBocmVm
PSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItZm9ybS1wb3N0LXJlc3BvbnNlLW1v
ZGUtMV8wLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9v
YXV0aC12Mi1mb3JtLXBvc3QtcmVzcG9uc2UtbW9kZS0xXzAuaHRtbDwvYT48YnI+DQomZ3Q7ICZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IG1pdGlnYXRlIHRoZSB0aHJlYXRzIHlvdeKAmXJlIGRl
c2NyaWJpbmcgYmVsb3cgSm9obj8mbmJzcDsgSWYgc28sIEkgYmVsaWV2ZSB0aGUgU2VjdXJpdHkg
VG9waWNzIGRyYWZ0IHNob3VsZCBzYXkgdGhpcy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYmVsaWV2
ZSB3ZSBvd2UgaXQgdG8gcmVhZGVycyB0byBwcmVzZW50IHRoZSBjb21wbGV0ZSBwaWN0dXJlLCB3
aGljaCBpcyB3aHkgSSBiZWxpZXZlIHRoYXQgZGVzY3JpYmluZyBwcm9maWxlcyB1c2luZyBJRCBU
b2tlbnMgYW5kIHRoZSBGb3JtIFBvc3QgUmVzcG9uc2UgTW9kZSBhcmUgaW4gc2NvcGUuPGJyPg0K
Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSBNaWtlPGJyPg0KJmd0OyAm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7
IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyBGcm9tOiBPQXV0aCA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8
YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmbmJzcDsgT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjAsIDIwMTggNzo0NyBBTTxicj4NCiZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA
aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5
IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGlj
aXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7
ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFllcyB0aGUgYXRfaGFzaCBwcm90ZWN0cyB0aGUgY2xpZW50
IGZyb20gYWNjZXB0aW5nIGFuIGluamVjdGVkIEFULiA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVW5mb3J0dW5hdGVseSBpdCBk
b2Vzbid0IGRvIGFueXRoaW5nIHRvIHByb3RlY3QgYWdhaW5zdCBsZWFrYWdlIGluIGxvZ3Mgb3Ig
cmVkaXJlY3RzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyBTbyB3aXRob3V0IHRoZSBBVCB1c2luZyBzb21lIHNvcnQgb2YgUE9Q
IG1lY2hhbmlzbSBpdCBpcyBoYXJkIHRvIHNheSBzZW5kaW5nIGl0IGluIGEgcmVkaXJlY3QgaXMg
YSBnb29kIHNlY3VyaXR5IHByYWN0aWNlLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKb2huIEIuPGJyPg0KJmd0OyAmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDExLzIwLzIw
MTggNDozNSBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgTWlrZSwgPGJy
Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IEkgYWdyZWUgdGhhdCBPSURDIGh5YnJpZCBmbG93cyBvZmZlciBhZGRpdGlvbmFs
IHNlY3VyaXR5IG92ZXIgdGhlIE9BdXRoIGltcGxpY2l0IGdyYW50IGFuZCBhcmUgdXNlZCBpbiB0
aGUgd2lsZC4gT24gbXkgc2xpZGVzIGFuZCBpbiB0aGUgaW5pdGlhbCB2ZXJzaW9uIG9mIHRoZSBu
ZXcgc2VjdGlvbiwgd2UgaGFkIGluY2x1ZGVkIHRoZSBoeWJyaWQgT0lEQyBmbG93cyBiZWNhdXNl
IG9mIHRoZWlyIGtub3duIHRva2VuIGluamVjdGlvbg0KIGNvdW50ZXJtZWFzdXJlcy48YnI+DQom
Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgSSBuZXZlcnRoZWxlc3MgZmVlbCB2ZXJ5IHVuY29tZm9ydGFibGUgdG8gcmVjb21tZW5k
IHRob3NlIGZsb3dzIGFuZCBhbnkgZmxvdyBpc3N1aW5nIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGZy
b250IGNoYW5uZWwuIEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGRldGFpbGVkIHJldmlldyBvZiB0aGUg
bmV3IHRleHQgd2UgcmVhbGl6ZWQgdHdvIGlzc3VlczoNCjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxKSBTaW5jZSB0
aGUgYWNjZXNzIHRva2VuIGlzIGV4cG9zZWQgaW4gdGhlIFVSTCwgc3VjaCBmbG93cyBwb3NzZXNz
IGEgc2lnbmlmaWNhbnRseSBoaWdoZXIgcmlzayB0byBsZWFrIHRoZSBhY2Nlc3MgdG9rZW4gKGUu
Zy4gdGhyb3VnaCBicm93c2VyIGhpc3RvcnksIG9wZW4gcmVkaXJlY3Rpb24gYW5kIGV2ZW4gcmVm
ZXJyZXIgaGVhZGVycykgdGhhbiB0aGUgY29kZSBncmFudC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IDIpIFRoZXJlIGlzIG5vIHZpYWJsZSB3YXkgdG8gc2VuZGVyIGNvbnN0cmFpbiBh
Y2Nlc3MgdG9rZW5zIGlzc3VlZCBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gR2l2ZW4gdGhlIFdHIGRl
Y2lkZWQgdG8gcmVjb21tZW5kIHVzZSBvZiBzZW5kZXIgY29uc3RyYWludCB0b2tlbnMgKDxicj4N
CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTA5I3NlY3Rpb24tMi4uLjIi
IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wOSNzZWN0aW9uLTIuLi4yPC9hPjxicj4NCiZndDsgJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgKSwgaXQgc2VlbXMgY29udHJhZGljdG9yeSB0byByZWNvbW1lbmQg
cmVzcG9uc2UgdHlwZXMgbm90IHN1cHBvcnRpbmcgc3VjaCBhbiBhcHByb2FjaC4NCjxicj4NCiZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyBraW5kIHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUb3JzdGVu
LiA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgQW0gMTkuMTEuMjAxOCB1bSAyMzoxMyBzY2hyaWViIE1pa2UgSm9uZXMg
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVm
PSJtYWlsdG86NDBtaWNyb3NvZnQuLi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJy
Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGRlc2NyaXB0aW9uIG9mIHRoZSBzaXR1
YXRpb24gaXMgYW4gb3ZlcnNpbXBsaWZpY2F0aW9uLi4mbmJzcDsgT3BlbklEIENvbm5lY3Qgc2Vj
dXJlcyB0aGUgaW1wbGljaXQgZmxvdyBhZ2FpbnN0IHRva2VuIGluamVjdGlvbiBhdHRhY2tzIGJ5
IGluY2x1ZGluZyB0aGUgYXRfaGFzaCAoYWNjZXNzIHRva2VuIGhhc2gpIGluIHRoZSBJRCBUb2tl
biwgZW5hYmxpbmcgdGhlIGNsaWVudCB0byB2YWxpZGF0ZSB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4N
CiB3YXMgY3JlYXRlZCBieSB0aGUgaXNzdWVyIGluIHRoZSBJRCBUb2tlbiAod2hpY2ggaXMgYWxz
byB0aGUgT0F1dGggSXNzdWVyLCBhcyBkZXNjcmliZWQgaW4gUkZDIDg0MTQpLiZuYnNwOyAoTm90
ZSB0aGF0IHRoaXMgbWl0aWdhdGlvbiB3YXMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtb2F1dGgt
bWl4LXVwLW1pdGlnYXRpb24uKTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBHaXZlbiB0aGUgcHJldmFsZW5jZSBvZiB0
aGlzIGtub3duLWdvb2Qgc29sdXRpb24gZm9yIHNlY3VyaW5nIHRoZSBpbXBsaWNpdCBmbG93LCBJ
IHdvdWxkIHJlcXVlc3QgdGhhdCB0aGUgZHJhZnQgYmUgdXBkYXRlZCB0byBkZXNjcmliZSB0aGlz
IG1pdGlnYXRpb24uJm5ic3A7IEF0IHRoZSBzYW1lIHRpbWUsIEnigJltIGZpbmUgd2l0aCB0aGUg
ZHJhZnQgcmVjb21tZW5kaW5nIHRoZSBjb2RlIGZsb3cgb3ZlciB0aGUgaW1wbGljaXQgZmxvdyB3
aGVuDQogdGhpcyBtaXRpZ2F0aW9uIGlzIG5vdCB1c2VkLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhhbmsgeW91
LDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tIE1pa2U8YnI+DQomZ3Q7ICZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJv
bTogT0F1dGggPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IE9u
IEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAxOCAyOjM0IEFNPGJyPg0KJmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogb2F1dGggPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1
dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K
Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIFNlY3Vy
aXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1w
bGljaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgSGkgYWxsLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgYXV0aG9ycyBvZiB0aGUg
T0F1dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNhbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBp
dCBpcyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVseSBzZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cg
YWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2UgcG90ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRv
a2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFybHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZv
cg0KIHRoaXMgcmVhc29uLCBhbmQgc2luY2UgQ09SUyBhbGxvd3MgYnJvd3Nlci1iYXNlZCBhcHBz
IHRvIHNlbmQgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LCBUb3JzdGVuIHN1Z2dlc3Rl
ZCB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIHRoZSBpbXBsaWNpdCBn
cmFudCBpbiBjYWxsIGNhc2VzIGluIGhpcyBwcmVzZW50YXRpb24gKHNlZWh0dHBzOi8vPGJyPg0K
Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtb2F1dGgtc2Vzc2ItZHJhZnQt
aWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDEiIHRhcmdldD0iX2JsYW5rIj4NCmRhdGF0cmFj
a2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLW9hdXRoLXNlc3Ni
LWRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTAxPC9hPjxicj4NCiZndDsgJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgKS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IDxi
cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQSBodW0gaW4gdGhlIHJvb20gYXQgSUVURiMx
MDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0IGZvciBoaXMgcmVjb21tZW5kYXRpb25zLiBXZSB3
b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuPGJyPg0KJmd0
OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IFBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIgM3JkLjxicj4NCiZndDsg
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyBDaWFvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIYW5uZXMgJmFtcDsgUmlmYWF0
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls
IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp
dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl
bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3INCiBhbnkgcHVycG9zZSwgb3Igc3Rv
cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Ljxicj4N
CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8
YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0
aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsg
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7
ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+
DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0
OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0
aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsg
Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg
Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOk9B
dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0
OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoPC9hPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IC0tIDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpv
bmUuZXUiIHRhcmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT48YnI+
DQomZ3Q7ICZndDsgWm1hcnRab25lIElBTSAtIDxhIGhyZWY9Imh0dHA6Ly93d3cuem1hcnR6b25l
LmV1IiB0YXJnZXQ9Il9ibGFuayI+d3d3LnptYXJ0em9uZS5ldTwvYT48YnI+DQomZ3Q7IDxicj4N
CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRo
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv
YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_OSBPR01MB2869CF11BB05CC93E092044AF9D00OSBPR01MB2869jpnp_--


From nobody Tue Nov 27 01:44:30 2018
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 4AA57130DE2 for ; Tue, 27 Nov 2018 01:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.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 HKc_ZLPH_KfR for ; Tue, 27 Nov 2018 01:44:24 -0800 (PST)
Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [134.147.53.149]) (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 896A71292AD for ; Tue, 27 Nov 2018 01:44:24 -0800 (PST)
Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 433zQR52w1z4ypb for ; Tue, 27 Nov 2018 10:44:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1543311871; bh=wXCUL1V5sPjJyAHj7/odMfAks8Jwy0wuQFEFOVVlblQ=; h=To:From:Subject:Cc:Date:From; b=J292mwIgXEpyRXI45oZIg2+zM6BC4ixbIGhCMMIRBwSBIPzbf5UP4O1UAie/ALz/o X/svnJgqWOOhrxdKxF2m9N6eCZHtomCz7HzSLxvlc7IaF4qfKs89DKpgVZRqR1r2tc 8He0TMOrWny/KLhPxk8ltqPguN1ZNFfAcrmeNaX8=
Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 433zQR4BxHz4yml; Tue, 27 Nov 2018 10:44:31 +0100 (CET)
X-Envelope-Sender: 
X-RUB-Notes: Internal origin=134.147.42.227
Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 433zQR3vQjz4yb5; Tue, 27 Nov 2018 10:44:31 +0100 (CET)
Received: from excelsior.nds.ruhr-uni-bochum.de (dyn-ff2c09c5d308669400129000.nds.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:9:2100:4966:803d:5c90:c2ff]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 433zQG2qKPzysx; Tue, 27 Nov 2018 10:44:22 +0100 (CET)
To: oauth@ietf.org
From: Christian Mainka 
Openpgp: preference=signencrypt
Autocrypt: addr=Christian.Mainka@rub.de; prefer-encrypt=mutual; keydata= xsFNBEefF5YBEADa0W+FyzUZStHhp8YmnjPZm4Bws4sKmwXRxfSJp89Z5r79kxaXdLErifPS w4uyQuhosugg65KlNwFgtMprtGeEvQpqnsGFz1ZJFnMDZnMho48NDXdFA8KWUUTFHZTlv8fy NOH3EQ/jcWfq2VizuIewJNqyrVpbUimosQmLsBB9xLeiT6u8B0zh0hCYhnX77Y87MnPYlW1T fxT7mjGe2SJnGdm85CH2Q/9aIj7OTA5vZhrCdrbddo0c5h6WMqeYSbxUYrJ0/zBHFpfbWmFD OIEtvYLjKhEtjIpvKL6U7fJaJNPqTFp+Y0T+folxRMYIxWPMtacnvMa9YqBiEmdK8VyFBMmi gkhVqdrTKLtsxQrutKaRxJ+ACbEdNuGpjnK5ON+sNmPTmqs816x+JJGLu1ci03gbCIXXvwXF /pV2tX/dBGbTgYWZ4DAIdIJoHKgAjC0r64409nDwb4BKWtEDTAxbP+2mPVqH0uthGBz8J29Q zWUDztfy3AK7nZjhg0NRabBUYe6PPGaV81tluH5nEMvvcXSstbwAcg8BPmuSGp3G6VE4BxS6 bnRIbL9XQP24xn3TFiAus79Wmzz3yBangmUCo616qWJqpqie6arce+Zce8szwMIJD753gEo8 L+GXJ8H/jQWS8C9qPvmD9GlW+RaWoTRb4BkTds305e0HPyl9aQARAQABzSpDaHJpc3RpYW4g TWFpbmthIDxDaHJpc3RpYW4uTWFpbmthQHJ1Yi5kZT7CwXsEEwECACUCGyMGCwkIBwMCBhUI AgkKCwQWAgMBAh4BAheABQJRCCWaAhkBAAoJEBxg1ZHbyZM9PuYP/3a/1kPLhy11Hjqz12SJ oQi10JlTpRILcWXAoUOFmOQlPkMzwp+jvyg0XMW7VHfRpNyFDhMofAsibVFj6OvWRmg6Mrps z0IwbH6k7ukcb0Uvv/EWhBHvqDpkGdIo0iAkoyuygTIVsLRjJmU0QrnaS9J/QQTQSzpMG0Y/ NXmt8a6j0aR92hYllhTdWbHGgQlcMa6RJBBR9fExoOlc9LZM3gyFI89STpWZcvFviO6VYlIK TqCFiH8W4u/yzP3fvjz2JLSS3SAAyd4zoaqMGSDqb97iJI39jja2BrJCkHDGpb0god0IMz+L MSXFc5faewBy5HfIsOj2tt4J9gUoKOwpfIDccOMirO5qywo5w79ofzx4AWDl+O1q4SXJmFUQ WdnanM9TwR0wRmFa2q5ZugHlQbIdGMqRpy5XrcTBcSoQRxGiFdjchJAYeNNQnOIMdHtolcSH pwKUc0CLIjrzMMnAui1WIr8jcdxiuqrUEJDZWiVZhxetq1An8lDX8q5IDmq1ZnS5PfmlOpMm L3QduEEqQQ40St2pbfCyCMz19jK/d6KblVoG4MhGq1ofIKu6KfWZmIEsiLGidNPByL84AB+8 B9VArlS5pG4esIF5c5nyv1InlNCz5aNZXzRxvJVqYEcTnM6f+29BDNGCPGfIVCyiocYCE2Z6 TSA//VyQXMGdxB1UzsFNBEefF9IBEACaoaSOVrtoEx+1FFoFHro9mI2rViLcHY44EyPBSlgU QgNeyMBnV9yrFf2awpZimXkXYOJ39dtDKOleiJ+XpM7n0tEDJ+tPz4Avc2iQ4RMyIndrM4ok mfmTHuWZkV5ZJAERF59hMRDp8dRBzFDBXDEVhFsOZGFaf5qJE78774Jb/I0Sh6wn4FY2Pr/Z dEA5FOlzHNa8LlMv2Qeh8t+HdL/ySTDGJAI2qTeszqWtDSnMT+ExYH+zWCiYYw0/2/U01L/Q n5wNiEihAv4XYkkQsMecMw9H8zZ7Ob1hrSwWR1pYJIiJ94cHDTeLIq2bY0yHuxiQLbUMyCkP QhTXvz1mdkzVHlhMZefHkeo25dvbnCot6JoWOyyCghEixtMeRpYReKOmkHDVMRLqo1VJSxYh yrmmdZUfJjTBqqpl4nvYPj5cLvogI2CpGeKFgkfzZ3/OIMamipJOLQHoX80Y04Ug9k5BxUHJ PPX054g+GB6YT1xYncPDj+J+aP1EvOSMh4DyAspB9gZoI5Xx8swL3UvQySpakgHoGeOfz0ws YOijoGW9UCkwqIWbrQ44Y+SgjxKEp3rkZ0a5PCcOSNPynIIxyWukbIDk6nhqp/Ni3vzpoAjG Hs05w+YqP/sv8wykeK/2JejNkpZIDVopnvXFDc5QLc+cn70X1Ny9sYYj1+/KmS7d4QARAQAB wsFfBBgBAgAJBQJHnxfSAhsMAAoJEBxg1ZHbyZM9DIIP/iBxx1yb3Iy7m23GcNsfWRUnSmkA dkLf9VoEESvxtuC1l8AEUCeoTiQ0LSasZ2asV6yoMQOStv3eW6/WL6ZUL0jTm7x3Ki0/Ej+o bnKpCKV3E45ku7unilXI4+TSPXxmwQOi0ZVa+MwZn7jhwQuk60EgBUW0VyPmpgYnxtcb2HGG Rj3V06A+T2963AyrM6gFBDSm5ulSwKydLBDsbOpD9JXCvVrAFwCs8isa0snhhuipQZR3fKYh Q8pbCGSFYJ+BAgZuj02eeEQZP8J04LAYItcsuO01B27svDJRF6BcoYljfO6Cat625mxsjYvI TTsq0iCTx0d/OOee7nPhChB7bsRm9/F//N0STfbQVRyt0RZS0uGzo5lESk+TnlteNx6oJUpW TgO7FXr4j2ZpSGznjV57Sjgh8QttUubIDPrjFSGiY8z0DxZrIdWVtgDj2LeVnjql5eZpOn2B Ce/+dRg581t5vZvCaIlpu+YBxWmJHU7VPyAY6Sq4xY6JW6B3yqkqTmOPE/ARUIYRzHPmv15k CINS/Jpw6fWTzsD1HPaRVVEwDuFRSxaKtoDFOB7DktTf2NsyKDC0GN3w6x+I9VUHjJePK3wX qjQs0g/DXc7OBJV+1nBkj0ZlHqtuiNomfhycC18ZvUs6re/gu2jSSK3ME5Tll/qYGq5DcuzS TSnNS1Q3
Message-ID: 
Date: Tue, 27 Nov 2018 10:44:08 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de
X-Virus-Status: Clean
Archived-At: 
Subject: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 27 Nov 2018 09:44:28 -0000

Hi,

we just stumbled upon this [1] statement:
"Except when using a mechanism like Dynamic Client Registration
=C2=A0=C2=A0 [RFC7591] to provision per-instance secrets, native apps are=

=C2=A0=C2=A0 classified as public clients ..."

What does this mean for us? Native App + Dynamic Client Registration =3D
Confidential Client?
Which threats are covered if Dynamic Client Registration is used on
Native Apps?

Best Regards,
Vladi/Christian

[1]: https://tools.ietf.org/html/rfc8252#section-8.4

--=20
Dr.-Ing. Christian Mainka
Horst G=C3=B6rtz Institute for IT-Security=20
Chair for Network and Data Security=20
Ruhr-University Bochum, Germany

Universit=C3=A4tsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX



From nobody Tue Nov 27 01:44:37 2018
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 46E7E1292AD for ; Tue, 27 Nov 2018 01:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.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 xznEzEoEDz44 for ; Tue, 27 Nov 2018 01:44:25 -0800 (PST)
Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:3595]) (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 CCD9D12E7C1 for ; Tue, 27 Nov 2018 01:44:24 -0800 (PST)
Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 433zQQ4yVcz4x3S for ; Tue, 27 Nov 2018 10:44:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1543311870; bh=1JmIHOX0mAihaoh3aEE8GfaPhsEed0VywQGpRccG4dQ=; h=To:From:Subject:Date:From; b=m4n8j9QW15aTtH5f+QrrPIW1yxPEAAdfb7i+v2D1CzBkSOJovM2J7IAKpZIwcSW9h IXb8CMQk6r5qDbKvihnmyOsFP53sdIfG4P6qlvmKze4ZmyHVvF4x9aHHvFV8ffh0tZ LAMBmkAkJE9zymGuUWYbwoC3wbyGuNdSM7aQfp3E=
Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 433zQQ4GV3z4ym3 for ; Tue, 27 Nov 2018 10:44:30 +0100 (CET)
X-Envelope-Sender: 
X-RUB-Notes: Internal origin=134.147.42.227
Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 433zQQ2WfVz4x3S for ; Tue, 27 Nov 2018 10:44:30 +0100 (CET)
Received: from excelsior.nds.ruhr-uni-bochum.de (dyn-ff2c09c5d308669400129000.nds.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:9:2100:4966:803d:5c90:c2ff]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 433zQD6LC5zysx for ; Tue, 27 Nov 2018 10:44:20 +0100 (CET)
To: oauth@ietf.org
From: Christian Mainka 
Openpgp: preference=signencrypt
Autocrypt: addr=Christian.Mainka@rub.de; prefer-encrypt=mutual; keydata= xsFNBEefF5YBEADa0W+FyzUZStHhp8YmnjPZm4Bws4sKmwXRxfSJp89Z5r79kxaXdLErifPS w4uyQuhosugg65KlNwFgtMprtGeEvQpqnsGFz1ZJFnMDZnMho48NDXdFA8KWUUTFHZTlv8fy NOH3EQ/jcWfq2VizuIewJNqyrVpbUimosQmLsBB9xLeiT6u8B0zh0hCYhnX77Y87MnPYlW1T fxT7mjGe2SJnGdm85CH2Q/9aIj7OTA5vZhrCdrbddo0c5h6WMqeYSbxUYrJ0/zBHFpfbWmFD OIEtvYLjKhEtjIpvKL6U7fJaJNPqTFp+Y0T+folxRMYIxWPMtacnvMa9YqBiEmdK8VyFBMmi gkhVqdrTKLtsxQrutKaRxJ+ACbEdNuGpjnK5ON+sNmPTmqs816x+JJGLu1ci03gbCIXXvwXF /pV2tX/dBGbTgYWZ4DAIdIJoHKgAjC0r64409nDwb4BKWtEDTAxbP+2mPVqH0uthGBz8J29Q zWUDztfy3AK7nZjhg0NRabBUYe6PPGaV81tluH5nEMvvcXSstbwAcg8BPmuSGp3G6VE4BxS6 bnRIbL9XQP24xn3TFiAus79Wmzz3yBangmUCo616qWJqpqie6arce+Zce8szwMIJD753gEo8 L+GXJ8H/jQWS8C9qPvmD9GlW+RaWoTRb4BkTds305e0HPyl9aQARAQABzSpDaHJpc3RpYW4g TWFpbmthIDxDaHJpc3RpYW4uTWFpbmthQHJ1Yi5kZT7CwXsEEwECACUCGyMGCwkIBwMCBhUI AgkKCwQWAgMBAh4BAheABQJRCCWaAhkBAAoJEBxg1ZHbyZM9PuYP/3a/1kPLhy11Hjqz12SJ oQi10JlTpRILcWXAoUOFmOQlPkMzwp+jvyg0XMW7VHfRpNyFDhMofAsibVFj6OvWRmg6Mrps z0IwbH6k7ukcb0Uvv/EWhBHvqDpkGdIo0iAkoyuygTIVsLRjJmU0QrnaS9J/QQTQSzpMG0Y/ NXmt8a6j0aR92hYllhTdWbHGgQlcMa6RJBBR9fExoOlc9LZM3gyFI89STpWZcvFviO6VYlIK TqCFiH8W4u/yzP3fvjz2JLSS3SAAyd4zoaqMGSDqb97iJI39jja2BrJCkHDGpb0god0IMz+L MSXFc5faewBy5HfIsOj2tt4J9gUoKOwpfIDccOMirO5qywo5w79ofzx4AWDl+O1q4SXJmFUQ WdnanM9TwR0wRmFa2q5ZugHlQbIdGMqRpy5XrcTBcSoQRxGiFdjchJAYeNNQnOIMdHtolcSH pwKUc0CLIjrzMMnAui1WIr8jcdxiuqrUEJDZWiVZhxetq1An8lDX8q5IDmq1ZnS5PfmlOpMm L3QduEEqQQ40St2pbfCyCMz19jK/d6KblVoG4MhGq1ofIKu6KfWZmIEsiLGidNPByL84AB+8 B9VArlS5pG4esIF5c5nyv1InlNCz5aNZXzRxvJVqYEcTnM6f+29BDNGCPGfIVCyiocYCE2Z6 TSA//VyQXMGdxB1UzsFNBEefF9IBEACaoaSOVrtoEx+1FFoFHro9mI2rViLcHY44EyPBSlgU QgNeyMBnV9yrFf2awpZimXkXYOJ39dtDKOleiJ+XpM7n0tEDJ+tPz4Avc2iQ4RMyIndrM4ok mfmTHuWZkV5ZJAERF59hMRDp8dRBzFDBXDEVhFsOZGFaf5qJE78774Jb/I0Sh6wn4FY2Pr/Z dEA5FOlzHNa8LlMv2Qeh8t+HdL/ySTDGJAI2qTeszqWtDSnMT+ExYH+zWCiYYw0/2/U01L/Q n5wNiEihAv4XYkkQsMecMw9H8zZ7Ob1hrSwWR1pYJIiJ94cHDTeLIq2bY0yHuxiQLbUMyCkP QhTXvz1mdkzVHlhMZefHkeo25dvbnCot6JoWOyyCghEixtMeRpYReKOmkHDVMRLqo1VJSxYh yrmmdZUfJjTBqqpl4nvYPj5cLvogI2CpGeKFgkfzZ3/OIMamipJOLQHoX80Y04Ug9k5BxUHJ PPX054g+GB6YT1xYncPDj+J+aP1EvOSMh4DyAspB9gZoI5Xx8swL3UvQySpakgHoGeOfz0ws YOijoGW9UCkwqIWbrQ44Y+SgjxKEp3rkZ0a5PCcOSNPynIIxyWukbIDk6nhqp/Ni3vzpoAjG Hs05w+YqP/sv8wykeK/2JejNkpZIDVopnvXFDc5QLc+cn70X1Ny9sYYj1+/KmS7d4QARAQAB wsFfBBgBAgAJBQJHnxfSAhsMAAoJEBxg1ZHbyZM9DIIP/iBxx1yb3Iy7m23GcNsfWRUnSmkA dkLf9VoEESvxtuC1l8AEUCeoTiQ0LSasZ2asV6yoMQOStv3eW6/WL6ZUL0jTm7x3Ki0/Ej+o bnKpCKV3E45ku7unilXI4+TSPXxmwQOi0ZVa+MwZn7jhwQuk60EgBUW0VyPmpgYnxtcb2HGG Rj3V06A+T2963AyrM6gFBDSm5ulSwKydLBDsbOpD9JXCvVrAFwCs8isa0snhhuipQZR3fKYh Q8pbCGSFYJ+BAgZuj02eeEQZP8J04LAYItcsuO01B27svDJRF6BcoYljfO6Cat625mxsjYvI TTsq0iCTx0d/OOee7nPhChB7bsRm9/F//N0STfbQVRyt0RZS0uGzo5lESk+TnlteNx6oJUpW TgO7FXr4j2ZpSGznjV57Sjgh8QttUubIDPrjFSGiY8z0DxZrIdWVtgDj2LeVnjql5eZpOn2B Ce/+dRg581t5vZvCaIlpu+YBxWmJHU7VPyAY6Sq4xY6JW6B3yqkqTmOPE/ARUIYRzHPmv15k CINS/Jpw6fWTzsD1HPaRVVEwDuFRSxaKtoDFOB7DktTf2NsyKDC0GN3w6x+I9VUHjJePK3wX qjQs0g/DXc7OBJV+1nBkj0ZlHqtuiNomfhycC18ZvUs6re/gu2jSSK3ME5Tll/qYGq5DcuzS TSnNS1Q3
Message-ID: <7a2af167-93db-461a-a2a0-47a2f4782c04@rub.de>
Date: Tue, 27 Nov 2018 10:04:20 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de
X-Virus-Status: Clean
Archived-At: 
Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-01
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, 27 Nov 2018 09:44:28 -0000

Hi Aaron,

I just reviewed the latest update. Thank you for this very interesting
guideline!

Here are my thoughts:

- Section 4: "For authorizing users within a browser-based application"
I would like to know whether this guide is for JavaScript Applications
(such as SPas), for Browser Extensions, or for both?

- Section 5: "applicaiton" -> "application"; "an web email" -> "a web email"

- Section 6: "and MUST use a unique value for each authorization request."
I would prefer:
'The "state" parameter MUST be a unique value for each authorization
request, which is bound to the end-user's HTTP session, and must be
verified upon receiving it in the authorization response.'
Otherwise, it sounds like a nonce for me.

- Section 7.3: "If authorization servers restrict redirect URIs to a
fixed set of absolute HTTPS URIs without wildcard domains or paths"
Covert redirect can be used by abusing unprotected GET parameters (which
are technically not the PATH).
So maybe it would be better to say simply "without wildcards" or
"without wildcard domains, paths, or querys"?

- Section 7.6: "dynamic registration" -> "dynamic client registration"

Best Regards
Christian

-- 
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX


From nobody Tue Nov 27 01:54:02 2018
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 02F3B127B4C for ; Tue, 27 Nov 2018 01:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 EzI-p-OWyDSd for ; Tue, 27 Nov 2018 01:53:57 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7511276D0 for ; Tue, 27 Nov 2018 01:53:57 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id r11-v6so21034888wmb.2 for ; Tue, 27 Nov 2018 01:53:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Vwll5ZY0x8kTO5xgZKkRKSYG7/1CrB/TZplmMAWwIM=; b=Eqhh7zTdApojlmbzsxSJmj6D/7FoFRPDAnIktLW8HHKboiGb6uu3SY+Wrh2noboIoW LteMSQTNsvWMiO5eHCtawQu5aeSHFAfk234yP1lbTVG/El3Vx4TY2bkE459sU4uN16t/ T3IteiUpYLJHtkTOOl3bsODQNDPGpvuCC4QAo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Vwll5ZY0x8kTO5xgZKkRKSYG7/1CrB/TZplmMAWwIM=; b=OKjFh/PjJiYfBiQPRb9ZiHWJct5oC/rkLPlC3FVKXXBH82zhz3v3eQm8zkILyynjcy lrQ0F6go2rx/9kbZAvQxZNJn8x1Bsw6PjgYIP+U/ewaW8P+uNQbSSgHKrFYwtkSMMHit PCNeYWP2A2jzZCNXQWA2v8pj9gQac5u7lrMLLFb8IzC0AiKmDcHCAhHsPoOmyab7Vq6Y 1cVP+AblaLAqA9JpAkqEOcjliBROi4Ws+v7Ed+Wq0I1ztiUntiCN1z6lniXiAGfuT6El 1fkiHwaugZvQOimTQBJC2QnQ42lNBUBLfxiHRR1OITswAEvjOkN+n/gzEVfAiLGTOFV/ xY1w==
X-Gm-Message-State: AA+aEWaaHVLe24k+gjzIiYZqdXBqYBVzZ9tReHfixRQbQ8oudDbni0GO ODGfgxI7t+9/WHdQBGQ/vYLyxA==
X-Google-Smtp-Source: AFSGD/Xn/2ULphMIu7iSEu9gxNMbxzGYsExtKraaACr7X0MNw1+1C1VoSCwdVFRyJlmp7P4TLg33dA==
X-Received: by 2002:a1c:8b42:: with SMTP id n63mr26422324wmd.38.1543312435336;  Tue, 27 Nov 2018 01:53:55 -0800 (PST)
Received: from guest2s-mbp.lan (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id h4sm2440774wrt.66.2018.11.27.01.53.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 01:53:54 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Neil Madden 
In-Reply-To: 
Date: Tue, 27 Nov 2018 09:53:53 +0000
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 09:54:00 -0000

On 19 Nov 2018, at 10:34, Hannes Tschofenig  =
wrote:
>=20
> Hi all,
> The authors of the OAuth Security Topics draft came to the conclusion =
that it is not possible to adequately secure the implicit flow against =
token injection since potential solutions like token binding or JARM are =
in an early stage of adoption. For this reason, and since CORS allows =
browser-based apps to send requests to the token endpoint, Torsten =
suggested to use the authorization code instead of the implicit grant in =
call cases in his presentation =
(seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-se=
ssb-draft-ietf-oauth-security-topics-01).
> A hum in the room at IETF#103 concluded strong support for his =
recommendations. We would like to confirm the discussion on the list.
> Please provide a response by December 3rd.


ForgeRock are in favour of deprecating the implicit flow in favour of =
the authorization code flow as suggested.

In our opinion, it is more secure and more consistent to prefer the =
authorization code in all such cases.

Kind regards,

Neil Madden
Security Director, ForgeRock Engineering=


From nobody Tue Nov 27 05:21:40 2018
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 86B8B128D09 for ; Tue, 27 Nov 2018 05:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2jJUGyZ7tzJ for ; Tue, 27 Nov 2018 05:21:31 -0800 (PST)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0: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 78273130DF9 for ; Tue, 27 Nov 2018 05:21:31 -0800 (PST)
Received: by mail-pf1-x42b.google.com with SMTP id b85so8368321pfc.3 for ; Tue, 27 Nov 2018 05:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=l+56pmVed7ZrevOGXhSJ4x+r7Cfysd3lW/lIGrigcUY=; b=GwZewUTHejZBnK/M6Fvz7Lgdmbmq2NmDoKInkEH3/Xh1NP/VcbYUWIa+XhjXQxQQ2O NWpXsq027DInnXXNgqH2qaOZDMmj+NbI3/l5lZexRO3nbmNH96MT/qM7j7Xb7hF5Y3Xb +uoPpfFxrP29dEhguJfgvF6QAP6JSo3onyeUIFWIBAYJkK96xYLNvvA/xPM5jQ9ceUoK LtrZWSjJkVNW1CoA+Ycf3nwU+IfKhXMAJwZgrVpAsfqPi3U+3xbe2MVmvG2Zk4Z8H7CQ 3yTA3BGOB7wV9tA5eoHnoXjYgZ3JJUPXkufJs6XuSt0d5ZXzr6IKE0W5s0Q9KOGVRQxu YDVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=l+56pmVed7ZrevOGXhSJ4x+r7Cfysd3lW/lIGrigcUY=; b=dlmG328X8hqAsO6GUpFmTTPGszqsbJkMgANX/SxqCXmUGw8kE3x07cZwHUE/Prc/e4 zsje2DoIgJNXpej8pGYI8vp9N6MVVWuLLlJJWrDR4rmRFK5F4elG1XaWzPTVZzKcrKsI c4BbFUJiK6gILNOnNE0givLMAL1Knzug0/G99NMIv0NMwauJsaZP5X6gAueGk6xE9z9t R1aZ1Kb+E7ZPM+sRCzpIhxwWG1uxHcuSMKYAAh+9GqOZWxnVOdh+iMv6Nmohz8F57a35 XBx5cLs3kztk5suSBhZHDUoQ4qEgDCOLqZK7KY0bv99t4qf98Lp3XxlBv6CknLH4zpko LIgg==
X-Gm-Message-State: AA+aEWZiELoyfwxtXJp0fa0LNldaTmWtY+TrKOOz3KzGZ3B0Ke2zF6KG KH6+/EluU0LY3dDs8E+rkYYRY1EQTGLguh7i
X-Google-Smtp-Source: AFSGD/XEgMuOOR78zrsua9apF5uZn2ED9S0JVRGilWv3Jl545BcBArEW+tGb5qtmvBI9wXqEVLtFEQ==
X-Received: by 2002:a63:5026:: with SMTP id e38mr29316359pgb.123.1543324890639;  Tue, 27 Nov 2018 05:21:30 -0800 (PST)
Received: from heembo.local (zipline.atenlabs.com. [206.251.244.230]) by smtp.googlemail.com with ESMTPSA id m20sm4141306pgv.93.2018.11.27.05.21.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 05:21:29 -0800 (PST)
To: Hannes Tschofenig , oauth 
References: 
From: Jim Manico 
Openpgp: preference=signencrypt
Autocrypt: addr=jim@manicode.com; prefer-encrypt=mutual; keydata= xsFNBFcMHBYBEADN65JL/EhBkLog2kXXIvM90vyMfDgHWK0qP5lKaMWJdrZ/0AKJnGzOGWFg 8ezOlLp7yJQO/QBm+XDq6yda3uSNg3EugBjnPa24fcsb0fuEmoG0xq1TiF3G8byBxdr7TQqn 9xLUvkivl7XUfpeoKiHXpAwahLJiJsT3Y8oc32qF7IPiQLvqZBNNTesK+cz+MLm5UZxI5ZtH 1bfiyht+5eFrWIOQKFu7EEapRtBScY561xj7WKsLmj0F6cK/vG9CNss8lBsBgpBUXD1aE+Iy BJb98cZwbebfJA/AMg4W/HTcQSxfael8GfbOFidxT5uu45o/X6kjfa3ITU5YKM2EYaDZHiMo Qoojny83O7PrIJaB7JoIRD1h6Jtq0WjtSv08YO8r+d8QmEQ9gMt8oON7YYP69OsK+lBU+mKZ C5OfTW7GEW3egHqd7UtfzU/Sadp8MXr54/U3Elg0/E/da/OoxYyvoBInJVcR8QlfcA1JEr+R YFutoISigv6qSFHBssvaRK93W+R3TdHcJZUu33lk65FKnbbdcPmKWWXk1ZWBcaXZ2Rwa+NyR RCCVw2Sy/jVPCNvTtZuI9oeNXxgKfF2o5pVH3J/P7viKXFQafE9zLJC9Y2E5gP/FfHkFNaem X/RCggxQFtABhhOmHnho4tPeu55Jv0pd8d4xW4YlaeZb15wzGwARAQABzR1KaW0gTWFuaWNv IDxqaW1AbWFuaWNvZGUuY29tPsLBfQQTAQoAJwUCVwwcFgIbIwUJCWYBgAULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAAKCRBMeWW7x/Jmpp2VD/9lhjkr35vO7ZYRvTRnUeF/eDgfCYcRO1MD X0UNjX0rp02MB8BOqlFDiwUR9B3Mzh54GGHUsuUcmClTHm19SSGKvp8m8N68Uo47tc1BV7R9 6sINqgAr6LmIzCjhfABL4WhvpFu4i6eCcx/9kThWuX86IOAdXFiwvaUkYVr8krEDHyQaUn2j 9CbYqnXm6Ig9stJo9mrzB9lOKAxFTDuV7dMcV3zYTZ8T8AqwwRzoWFAT30n8/pU+rYyRmA6w B54LRCcsv7JxkVowmuXcsOZs5hw/qLN6Q1X5LJRAhYCjl+juX1FbiSNV4j3cEiEMKhOjtSVG iwgKHs94yfR9Y6zVcSVhYgUGb6luGLaZo3LbOEB3vinS+VU0yLM7EWDz41CAdPuiue/L4/+n ZnNEdOgSaLB1e9nX5AjbHIb7MYzYH359MwhXJv1uyY5PTg2CWPfJjtoh5R75NjjruZn3XZ1q 9PYVsmw4BiWia+0y7WBqR5UYPUHvqiMoqPxIYSFwECxuXlDDQvqYlaWBMDObxXTFbrHtg4I/ eDsMDWJtj1H/zDaD67DjoRLrZ/iL1eqWAweFXiaPg+q3071W1IxAeYrMoyDM0m5ZYUrwWubT U/T04VV/fJ+1r1Neu+hPEvquH9AguPHn2qYM/nnD8u7TLXd6q6gFQnfpBbsDPPWiqaGEW80m ys7BTQRXDBwWARAAnVe6i3g1q8YnoHsUwmF8XqkIntMJzRSLORr/bkNQ8Z8ajq6wgXcLQlVk cha5Acn/FKhcd8dyForbQvURlrnOrw3h8gna8Jq3muqIMfa6H/F889CPVkx7vW5rGUB7NsmH toSx7TH1IQPUfq99y0cwKGfWttdKBiUG5D7gpKtH3B78hz78+wSK3SUR4KEPdYXSzVqFlnOY McPwoY0jC2q991k4rSZeSEN7iXYhoUqzpMyeMItGhDskmE/0lYiB/ZlBUmq7LP7khQ1fJUf+ BeDyCBHNrK/kYi/ur597cyd92KuIUeDkuNIB/ZxVIZ24f9MTw5JHLcyk6IMzpgdw2NFfxzTL htoHtNhlzLkFAEfWu1OSjlZGh2YfybUt4cxp7ntV5tNRR/MDKrHSABbR4seX5L68KA/74osM LNK7KbpFAViZghoMFB/USzNrog8OBuktczdTYthi/U/UiE8n/sJ7IQ0WFuF2srfAlNrUdPnW QeJhVhKutyajTXai9M+RJ49p30fRhEpcWlvS1Rd7GXTJrLnEiL4u0E9Q5UA/khq2TwXZ4M6C 7KutaBBqz12dc/ENrJv0o6MI9srq14HmE2qqO46/PFJFWKSHWyousaMbKpmB8qPTP2S+swm+ xpk20Ck3Bco5sW8rv+Fza0i3+gXgTeMZ79gRMiWKxpQGaqvUsjkAEQEAAcLBZQQYAQoADwUC VwwcFgIbDAUJCWYBgAAKCRBMeWW7x/JmpgrrEADJ0BEmJX286qV/tT6WBoxffmOJm8ThrxVb NMrNjkQrEX2GiQTcZ93NTX39k7jctG6UFbvIAjhMm3lymAppXIXu66hA2sgnlNwYJkpj6xLj LhkK9rLNFDjWeBeqm4yfsnrST0CoO3j/1KkMSRuLnkFBGLiLjoijfRLudcR+wmRI5Nj0MWD0 3ejNEFyiMn34di3ULHvYdAjPdyIqvUjj9MPuRFz+rYEeBPoAMKsDdl5mQ/3UHGHzxNTTgN8B P1ansWK2oSB0bIBdjB13lUeBYctGUuH89c+3OzuBIwnvGc/J7aYwnLxr/qgPB6bvUltJ8FUz S6nSoFFNr+NIayVCrE3jzgsfyZxQZznX2Faa8dogIcOl5LiosgjUZG1T+7Zt8taaMBBeT6NZ hP/mmd5Oep/5kl+MihTdfj5w9evMItGIfIXr7OUDnO/zOPxL7e8CpZkR95j9Gjy7PrV5ahqK EAKb0rNV3k1XI1OJNefnfZRDMH/oGfhiGmT6KW/43lF18wfIH0u6ysALKGGOC+XCu4/k0xsJ MAdIvVGKXirAoA98RvSlstqMAPj7j7xX3/JWMQ5ynlpaecWtahzscLSut9IxhTIFWpstTGrH TI6CzZ3akG7EQJAN0OxhrA6iGfhL1bNoQZ7HvTf8yYZQSQBaFBqJvwqXFMyfV9QhhXiIQO9H Bw==
Message-ID: <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com>
Date: Tue, 27 Nov 2018 18:51:26 +0530
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1FEC292D2809F4B9916FDC6C"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 13:21:34 -0000

This is a multi-part message in MIME format.
--------------1FEC292D2809F4B9916FDC6C
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

Manicode Security is strongly in favor of deprecating the implicit flow in favor of the authorization code flow as suggested by this recommendation.

We're also eager to see secure implementations for SPA delegation be clarified by the working group as well.

Thank you for this important work!

Aloha and Well Wishes,
-- 
Jim Manico
Manicode Security
https://www.manicode.com

On 11/19/18 4:04 PM, Hannes Tschofenig wrote:

> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM
> are in an early stage of adoption. For this reason, and since CORS
> allows browser-based apps to send requests to the token endpoint,
> Torsten suggested to use the authorization code instead of the
> implicit grant in call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>
> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
>
> Hannes & Rifaat
>
>  
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please 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.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------1FEC292D2809F4B9916FDC6C
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    Manicode Security is strongly in favor of deprecating the implicit flow in favor of the authorization code flow as suggested by this recommendation.

We're also eager to see secure implementations for SPA delegation be clarified by the working group as well.

Thank you for this important work!

Aloha and Well Wishes,
-- 
Jim Manico
Manicode Security
https://www.manicode.com

On 11/19/18 4:04 PM, Hannes Tschofenig wrote:

    
    
    
      
      
      
      
    
        
    Hi all,
    
        
    
        
    The authors of the OAuth Security Topics
          draft came to the conclusion that it is not possible to
          adequately secure the implicit flow against token injection
          since potential solutions like token binding or JARM are in an
          early stage of adoption. For this reason, and since CORS
          allows browser-based apps to send requests to the token
          endpoint, Torsten suggested to use the authorization code
          instead of the implicit grant in call cases in his
          presentation (see
          
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
    
        
    
        
    A hum in the room at IETF#103 concluded
          strong support for his recommendations. We would like to
          confirm the discussion on the list.
    
        
    
        
    Please provide a response by December
          3rd.
    
        
    
        
    Ciao
    
        
    Hannes & Rifaat
    
        
     
    
      
    
      IMPORTANT NOTICE: The contents of this email and any attachments
      are confidential and may also be privileged. If you are not the
      intended recipient, please 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.
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  


--------------1FEC292D2809F4B9916FDC6C--


From nobody Tue Nov 27 07:00:55 2018
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 9BB12130EB5 for ; Tue, 27 Nov 2018 07:00:41 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 PALUuKa1N6Mg for ; Tue, 27 Nov 2018 07:00:35 -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 37E27130E90 for ; Tue, 27 Nov 2018 07:00:35 -0800 (PST)
Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id Reqngc9GiVguCReqng7mzt; Tue, 27 Nov 2018 08:00:34 -0700
To: oauth@ietf.org
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com>
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>
Date: Tue, 27 Nov 2018 17:00:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-CMAE-Envelope: MS4wfM1aXRWfGP36Lpufq/0tw4RqJk7FLkFddQGMk2wnr5Aj1NmisPXEaZLXhk5mY1tSeyUCeRsiic1VBdNya/4ZaA2hVqCv8cVXyrig+RGOEZNzdCqQHw5x axdNr1F9lMjU+fchh/2Lc7dQmKnVUQyyL62d+0NvUKG9eQkQ1YLhAuR9
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 15:00:53 -0000

+1 to recommend the deprecation of implicit.

I don't see a compelling reason to keep implicit when there is an
established alternative that is more secure.

Our duty as WG is to give developers the best and most sensible practice.=


CORS adoption is currently at 94% according to
https://caniuse.com/#feat=3Dcors

Vladimir



From nobody Tue Nov 27 07:30:54 2018
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 BECCF130DF3 for ; Tue, 27 Nov 2018 07:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NPHfjSUuI-IL for ; Tue, 27 Nov 2018 07:30:49 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F02130DDA for ; Tue, 27 Nov 2018 07:30:49 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id v13so19672009wrw.5 for ; Tue, 27 Nov 2018 07:30: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 :cc; bh=/YGiwiZlVynWx5JIbA6RqT0lOw4ztJPIdYNsow/0HgI=; b=dTOVY/qRtS96N2yyDx3wz40y5g+x5ql0HG+91QEeFgpwOxSaAhd5K3ZD7zXdA8k2qV to8DfPwNRT7H9fDT3GhXH2tIDE6Yqsk9LR9/jNkWgbontRd5095x4QfEIT+RhdJN4Pb7 m0Ztda8n4g7Atp5AvCPSzp8HbdV1SfPsPn4U3Q2xyMg8Xzf3RVU+8Wm9KqjuloTMIZEm nOWG4bxpR8U4JWbPSSJFUJXiJmKqPgkQ5R7uv2TU29X28G/KE532XPY4JAkND4kFI4Dd bJWlgF8cxfRXKF4ynaRpgqjOLsiXc0y90j1XAB38SlkAfErMSEZbHM7Q+QGxpO4KzgqQ 8/yA==
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=/YGiwiZlVynWx5JIbA6RqT0lOw4ztJPIdYNsow/0HgI=; b=U5Q+cgNc9en7Ey+pQ/aqVsCD0/akUyuur6YgHMSJDO6cz8lf3YzjzWNZZS+gl0mGsx 4BBqqfWvZcG+Zdfxcu3IINeeAMEBzn/yU2M6v7Mg0amUnsp3L/SpgH7EgUSTAgk1zBCK 3COLGGr1nlm5h35GKd5bstP3K3fxNg+xa+ChIfK5z4JSlfZ7JrRRMkZhxKgWtlHdZ9B4 4jG6fthKruGdm3N3OmbwFOA7Rsw2Wsy0dQVaqPMnf88LxLdDuGJmUANG72u2IIWsyR/o hTDLji0GI3d6m3JM2iwqcgTU+e2oBF9BVz6UTQOybGvT1J1NJJi+7w3Wdq00PZB84T6c MdDA==
X-Gm-Message-State: AA+aEWaC1QNC9odaCHEXtvRLYJIgs0UqUdvyZ7+KTYcQ0HvPm1eUq7F3 PAR+eRkKDD5/nVUexuVwYprHjQvCtIKwsPkjIiE=
X-Google-Smtp-Source: AFSGD/VBDtEgQioM6nn4nWxmLTRrnwEQb7ucdLdG8Q3KIiJHZezGWtn+EqVKVftj90zikrDxm0k2DeL62u2yvIdzoLI=
X-Received: by 2002:a05:6000:1189:: with SMTP id g9mr29893530wrx.221.1543332647711;  Tue, 27 Nov 2018 07:30:47 -0800 (PST)
MIME-Version: 1.0
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>
In-Reply-To: <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>
From: Nat Sakimura 
Date: Tue, 27 Nov 2018 16:30:35 +0100
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth@ietf.org,  "openid-specs-ab@lists.openid.net Ab" 
Content-Type: multipart/alternative; boundary="0000000000003cb7fc057ba722c0"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 15:30:52 -0000

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

I am actually -1.

+1 for public client and the tokens that are not sender/key constrained.

Just not being used right now does not mean that it is not useful. In fact,
I see it coming.
Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is very use=
ful in certain
cases.
Specifically, when the client is confidential (based on public key pair),
and uses sender constrained (key-constrained) token such as the one
explained in
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
very useful.
(Key-constrained token is the remaining portion of this draft that did not
get incorporated in the MTLS draft. )
In fact it is the only viable method for Self-Issued OpenID Provider.

So, the text is generally good but it needs to be constrained like =E2=80=
=9CUnless
the client is confidential and the access token issued is key constrained,
... =E2=80=9C

Best,

Nat Sakimura


2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvinov :

> +1 to recommend the deprecation of implicit.
>
> I don't see a compelling reason to keep implicit when there is an
> established alternative that is more secure.
>
> Our duty as WG is to give developers the best and most sensible practice.
>
> CORS adoption is currently at 94% according to
> https://caniuse.com/#feat=3Dcors
>
> Vladimir
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


    I am actually -1.=C2=A0

    +1 for public client and the tokens that are n=
ot sender/key constrained.=C2=A0

    Just not being used right now does not mean that it is not useful=
. In fact, I see it coming.=C2=A0
    Implicit (well, Hy=
brid =E2=80=9Ctoken id_token=E2=80=9D really) is very useful in certain cas=
es.=C2=A0
    Specifically, when the client is confident=
ial (based on public key pair), and uses sender constrained (key-constraine=
d) token such as the one explained in https://tools.ietf.org/html/draft=
-sakimura-oauth-jpop-04#section-5, it is very useful.=C2=A0
    (Key-constrained token is the remaining portion of this draft t=
hat did not get incorporated in the MTLS draft. )
    In=
 fact it is the only viable method for Self-Issued OpenID Provider.=C2=A0

    So, the text is generally=
 good but it needs to be constrained like =E2=80=9CUnless the client is con=
fidential and the access token issued is key constrained, ... =E2=80=9C

    Best,=C2=A0

    Nat Sakimura

    2018=E5=
=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvinov <vladimir@connect2id.com>:
    +1 to recommend the deprecation of impli=
cit.
    

    
I don't see a compelling reason to keep implicit when there is an
    
established alternative that is more secure.
    

    
Our duty as WG is to give developers the best and most sensible practice.

    
CORS adoption is currently at 94% according to
    
https://caniuse.com/#feat=3Dcors
    

    
Vladimir
    

    

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

    -- 
    Nat Sakimura (=3Dnat)
    Chairman, Open=
ID Foundation
    htt=
p://nat.sakimura.org/
    @_nat_en
    

--0000000000003cb7fc057ba722c0--


From nobody Tue Nov 27 07:55:14 2018
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 C2B6B130DC4 for ; Tue, 27 Nov 2018 07:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkTUk-J6FQZr for ; Tue, 27 Nov 2018 07:55:09 -0800 (PST)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5165112D4E9 for ; Tue, 27 Nov 2018 07:55:09 -0800 (PST)
Received: by mail-pf1-x42c.google.com with SMTP id c72so8580768pfc.6 for ; Tue, 27 Nov 2018 07:55:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=iCTtuYp14fzvxMii2P+MQ+Ap0mlpH7h3eMLysjYMdas=; b=RLZvwm/eE/t8mVlmaOf9TJLiXxgpdb9CQLEiYJ4VTCJe5Nz5N2yhXHwugAr5IJvarJ AnDIlgz4JOVOh4MS2EE/Zoe4xGm0WIuPaM7qVu0o1uUBjAQMXnewJU3Oo+GReKvpOh/J FYYIpOwdIL18YcOlO92PoENtIFlSya5C/lCp/i2+KK4QPei7cXi1fW4x0SfXcR/x+eR3 XPD2A4rDoAzAARozlpvOy26Z0m2Smjwnbx4OGwr7BYk5uE6tAsRiycdjCJKD53ZyemZz ExCRJ17Q7teyggV7O8r8wJRSzSLHmLRCkXgl0Eqym8eh/0UVQHSXjRYCU3obPusIIVEm M/sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=iCTtuYp14fzvxMii2P+MQ+Ap0mlpH7h3eMLysjYMdas=; b=fl3uuuD3Vd0M4vInOZd3kyXPLTao5W3bHgGUfzaWNcU4k+QyXQO41YwoaQc+9lbGJn 6DEEd4tfx5G72G+iWb1yLTwSLU1DkGD8WQoalJDPXlx0f1mgtr7SQ2Ool8KgQjAgr0rj 9nSmGvb6A+n4TAcllG+gd8s/J1wvaKQoV79LqK3rTlW1rUIIqpyxoeup/5XOmkQ2tmDI WF1i2Xaj5B3FFCMnEcyMvxJG68+9/lIMq/RnMDaeiY4JVwo5OwgKyo4RoaAsbW2+nDqu gr10zWcucRn7fNRiRg7NhOneud9tm4I2bxC/1ar7kCS02/0Y+HX3ydJUB8qj/MNbB6ea qrIw==
X-Gm-Message-State: AA+aEWY/0HIDZa8uRftXatOTSzdhxrJ0xVP+QiZv0uzNaW15qRXOBMlU jgTzKzAzezpgBiJj/LrJU7x/GOkuuuXmdQMQ
X-Google-Smtp-Source: AFSGD/WXu/x2ZhDDTdenjFPo94rfefNI5AClmFIW6Fe2obYxYjO5RiPVFnKXRlG5xe9ZpmRuM0kOoA==
X-Received: by 2002:a63:f811:: with SMTP id n17mr30466590pgh.23.1543334108465;  Tue, 27 Nov 2018 07:55:08 -0800 (PST)
Received: from heembo.local (zipline.atenlabs.com. [206.251.244.230]) by smtp.googlemail.com with ESMTPSA id s2-v6sm11314300pfk.133.2018.11.27.07.55.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 07:55:07 -0800 (PST)
To: Nat Sakimura , Vladimir Dzhuvinov 
Cc: "openid-specs-ab@lists.openid.net Ab" ,  oauth@ietf.org
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com> 
From: Jim Manico 
Openpgp: preference=signencrypt
Autocrypt: addr=jim@manicode.com; prefer-encrypt=mutual; keydata= xsFNBFcMHBYBEADN65JL/EhBkLog2kXXIvM90vyMfDgHWK0qP5lKaMWJdrZ/0AKJnGzOGWFg 8ezOlLp7yJQO/QBm+XDq6yda3uSNg3EugBjnPa24fcsb0fuEmoG0xq1TiF3G8byBxdr7TQqn 9xLUvkivl7XUfpeoKiHXpAwahLJiJsT3Y8oc32qF7IPiQLvqZBNNTesK+cz+MLm5UZxI5ZtH 1bfiyht+5eFrWIOQKFu7EEapRtBScY561xj7WKsLmj0F6cK/vG9CNss8lBsBgpBUXD1aE+Iy BJb98cZwbebfJA/AMg4W/HTcQSxfael8GfbOFidxT5uu45o/X6kjfa3ITU5YKM2EYaDZHiMo Qoojny83O7PrIJaB7JoIRD1h6Jtq0WjtSv08YO8r+d8QmEQ9gMt8oON7YYP69OsK+lBU+mKZ C5OfTW7GEW3egHqd7UtfzU/Sadp8MXr54/U3Elg0/E/da/OoxYyvoBInJVcR8QlfcA1JEr+R YFutoISigv6qSFHBssvaRK93W+R3TdHcJZUu33lk65FKnbbdcPmKWWXk1ZWBcaXZ2Rwa+NyR RCCVw2Sy/jVPCNvTtZuI9oeNXxgKfF2o5pVH3J/P7viKXFQafE9zLJC9Y2E5gP/FfHkFNaem X/RCggxQFtABhhOmHnho4tPeu55Jv0pd8d4xW4YlaeZb15wzGwARAQABzR1KaW0gTWFuaWNv IDxqaW1AbWFuaWNvZGUuY29tPsLBfQQTAQoAJwUCVwwcFgIbIwUJCWYBgAULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAAKCRBMeWW7x/Jmpp2VD/9lhjkr35vO7ZYRvTRnUeF/eDgfCYcRO1MD X0UNjX0rp02MB8BOqlFDiwUR9B3Mzh54GGHUsuUcmClTHm19SSGKvp8m8N68Uo47tc1BV7R9 6sINqgAr6LmIzCjhfABL4WhvpFu4i6eCcx/9kThWuX86IOAdXFiwvaUkYVr8krEDHyQaUn2j 9CbYqnXm6Ig9stJo9mrzB9lOKAxFTDuV7dMcV3zYTZ8T8AqwwRzoWFAT30n8/pU+rYyRmA6w B54LRCcsv7JxkVowmuXcsOZs5hw/qLN6Q1X5LJRAhYCjl+juX1FbiSNV4j3cEiEMKhOjtSVG iwgKHs94yfR9Y6zVcSVhYgUGb6luGLaZo3LbOEB3vinS+VU0yLM7EWDz41CAdPuiue/L4/+n ZnNEdOgSaLB1e9nX5AjbHIb7MYzYH359MwhXJv1uyY5PTg2CWPfJjtoh5R75NjjruZn3XZ1q 9PYVsmw4BiWia+0y7WBqR5UYPUHvqiMoqPxIYSFwECxuXlDDQvqYlaWBMDObxXTFbrHtg4I/ eDsMDWJtj1H/zDaD67DjoRLrZ/iL1eqWAweFXiaPg+q3071W1IxAeYrMoyDM0m5ZYUrwWubT U/T04VV/fJ+1r1Neu+hPEvquH9AguPHn2qYM/nnD8u7TLXd6q6gFQnfpBbsDPPWiqaGEW80m ys7BTQRXDBwWARAAnVe6i3g1q8YnoHsUwmF8XqkIntMJzRSLORr/bkNQ8Z8ajq6wgXcLQlVk cha5Acn/FKhcd8dyForbQvURlrnOrw3h8gna8Jq3muqIMfa6H/F889CPVkx7vW5rGUB7NsmH toSx7TH1IQPUfq99y0cwKGfWttdKBiUG5D7gpKtH3B78hz78+wSK3SUR4KEPdYXSzVqFlnOY McPwoY0jC2q991k4rSZeSEN7iXYhoUqzpMyeMItGhDskmE/0lYiB/ZlBUmq7LP7khQ1fJUf+ BeDyCBHNrK/kYi/ur597cyd92KuIUeDkuNIB/ZxVIZ24f9MTw5JHLcyk6IMzpgdw2NFfxzTL htoHtNhlzLkFAEfWu1OSjlZGh2YfybUt4cxp7ntV5tNRR/MDKrHSABbR4seX5L68KA/74osM LNK7KbpFAViZghoMFB/USzNrog8OBuktczdTYthi/U/UiE8n/sJ7IQ0WFuF2srfAlNrUdPnW QeJhVhKutyajTXai9M+RJ49p30fRhEpcWlvS1Rd7GXTJrLnEiL4u0E9Q5UA/khq2TwXZ4M6C 7KutaBBqz12dc/ENrJv0o6MI9srq14HmE2qqO46/PFJFWKSHWyousaMbKpmB8qPTP2S+swm+ xpk20Ck3Bco5sW8rv+Fza0i3+gXgTeMZ79gRMiWKxpQGaqvUsjkAEQEAAcLBZQQYAQoADwUC VwwcFgIbDAUJCWYBgAAKCRBMeWW7x/JmpgrrEADJ0BEmJX286qV/tT6WBoxffmOJm8ThrxVb NMrNjkQrEX2GiQTcZ93NTX39k7jctG6UFbvIAjhMm3lymAppXIXu66hA2sgnlNwYJkpj6xLj LhkK9rLNFDjWeBeqm4yfsnrST0CoO3j/1KkMSRuLnkFBGLiLjoijfRLudcR+wmRI5Nj0MWD0 3ejNEFyiMn34di3ULHvYdAjPdyIqvUjj9MPuRFz+rYEeBPoAMKsDdl5mQ/3UHGHzxNTTgN8B P1ansWK2oSB0bIBdjB13lUeBYctGUuH89c+3OzuBIwnvGc/J7aYwnLxr/qgPB6bvUltJ8FUz S6nSoFFNr+NIayVCrE3jzgsfyZxQZznX2Faa8dogIcOl5LiosgjUZG1T+7Zt8taaMBBeT6NZ hP/mmd5Oep/5kl+MihTdfj5w9evMItGIfIXr7OUDnO/zOPxL7e8CpZkR95j9Gjy7PrV5ahqK EAKb0rNV3k1XI1OJNefnfZRDMH/oGfhiGmT6KW/43lF18wfIH0u6ysALKGGOC+XCu4/k0xsJ MAdIvVGKXirAoA98RvSlstqMAPj7j7xX3/JWMQ5ynlpaecWtahzscLSut9IxhTIFWpstTGrH TI6CzZ3akG7EQJAN0OxhrA6iGfhL1bNoQZ7HvTf8yYZQSQBaFBqJvwqXFMyfV9QhhXiIQO9H Bw==
Message-ID: <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>
Date: Tue, 27 Nov 2018 21:25:03 +0530
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A549AABB3A1EED42F8395AF5"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 15:55:12 -0000

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

Nat,

How is proof of possession established in a modern web browser in the
implicit flow?

My understanding is that token binding was removed from Chrome recently
effectively killing browser-based PoP tokens.

https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/

Am I missing something?

Aloha, Jim


On 11/27/18 9:00 PM, Nat Sakimura wrote:
> I am actually -1.=C2=A0
>
> +1 for public client and the tokens that are not sender/key constrained=
=2E=C2=A0
>
> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming.=C2=A0
> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is very=
 useful in
> certain cases.=C2=A0
> Specifically, when the client is confidential (based on public key
> pair), and uses sender constrained (key-constrained) token such as the
> one explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it
> is very useful.=C2=A0
> (Key-constrained token is the remaining portion of this draft that did
> not get incorporated in the MTLS draft. )
> In fact it is the only viable method for Self-Issued OpenID Provider.=C2=
=A0
>
> So, the text is generally good but it needs to be constrained like
> =E2=80=9CUnless the client is confidential and the access token issued =
is key
> constrained, ... =E2=80=9C
>
> Best,=C2=A0
>
> Nat Sakimura
>
>
> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvinov=
  >:
>
>     +1 to recommend the deprecation of implicit.
>
>     I don't see a compelling reason to keep implicit when there is an
>     established alternative that is more secure.
>
>     Our duty as WG is to give developers the best and most sensible
>     practice.
>
>     CORS adoption is currently at 94% according to
>     https://caniuse.com/#feat=3Dcors
>
>     Vladimir
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Jim Manico
Manicode Security
https://www.manicode.com


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


  
    
  
  
    
    Nat,
    
    
    How is proof of possession established in a modern web browser in
      the implicit flow?
    
    
    My understanding is that token binding was removed from Chrome
      recently effectively killing browser-based PoP tokens.
    
    
    
    
    https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
    
    
    Am I missing something?
    
    
    Aloha, Jim
    
    

    
    
    
    
    On 11/27/18 9:00 PM, Nat Sakimura
      wrote:
    
    
    
    
    
      
      
    
        
    I am actually -1. 
    
      
    
      

    
      
    
      
    +1 for public client and the tokens that are not
        sender/key constrained. 
    
      

    
      
    
      
    Just not being used right now does not mean that
        it is not useful.. In fact, I see it coming. 
    
      
    Implicit (well, Hybrid “token id_token†really) is
        very useful in certain cases. 
    
      
    Specifically, when the client is confidential
        (based on public key pair), and uses sender constrained
        (key-constrained) token such as the one explained in https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5,
        it is very useful. 
    
      
    (Key-constrained token is the remaining portion of
        this draft that did not get incorporated in the MTLS draft. )
    
      
    In fact it is the only viable method for
        Self-Issued OpenID Provider. 
    
      

    
      
    
      
    So, the text is generally good but it needs to be
        constrained like “Unless the client is confidential and the
        access token issued is key constrained, ... “
    
      

    
      
    
      
    Best, 
    
      

    
      
    
      
    Nat Sakimura
    
        

    
        
    
      
    
      

    
        
    
          
    2018å¹´11月27æ—¥(ç«) 16:01 Vladimir Dzhuvinov <vladimir@connect2id.com>:
    
          
    
          
    +1 to
            recommend the deprecation of implicit.
    
            
    
            I don't see a compelling reason to keep implicit when there
            is an
    
            established alternative that is more secure.
    
            
    
            Our duty as WG is to give developers the best and most
            sensible practice.
    
            
    
            CORS adoption is currently at 94% according to
    
            https://caniuse.com/#feat=cors
    
            
    
            Vladimir
    
            
    
            
    
            _______________________________________________
    
            OAuth mailing list
    
            OAuth@ietf.org
    
            https://www.ietf.org/mailman/listinfo/oauth
    
          
    
        
    
      
    
      -- 
    
      
    Nat Sakimura (=nat)
        
    Chairman, OpenID Foundation
    
          http://nat.sakimura.org/
    
          @_nat_en
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    -- 
Jim Manico
Manicode Security
https://www.manicode.com
    
  


--------------A549AABB3A1EED42F8395AF5--


From nobody Tue Nov 27 07:58:22 2018
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 94214130E72 for ; Tue, 27 Nov 2018 07:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Xh6LHXA_uRm1 for ; Tue, 27 Nov 2018 07:58:11 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 45501130E67 for ; Tue, 27 Nov 2018 07:58:11 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id k198so22848143wmd.3 for ; Tue, 27 Nov 2018 07:58:11 -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=D8PrpXM0D4a4+cdEEXyOGdWbn3peI8jOHqyL6P1n51I=; b=RmZjZL7uCr1M5oedDnij7Ox0yhRFbefk8hI5NaAEP4E7zKKvaUOmwaK++/CzbylwWD 6QsXhFTfYEiIrGLyXcMEwkx3XG/gZ95ajLccIcqj2hMGGJ0xES6WqKgYpu9l4VGG/nI1 N7ekLfSt9uyhFl+R+eUwloZvC1umcS1SJXmcrMY7DWFS/CQf0tJpgA8WaDQ4++n7Qhwv tnIMDdRBzTLqrhNxiXbESIdR6+BwGDFfCB43KhI4fKZX8ERIByEDIbkPgXF6YErzSlcK eCaNmb/FcG5ZTCwYaXN3YqZZ+quIRTD1Q8+D+cWGdD/evY1/HaQz4xnfhawlkVCPqHXG RgDw==
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=D8PrpXM0D4a4+cdEEXyOGdWbn3peI8jOHqyL6P1n51I=; b=o+UKEwdGmI6p/LJQ5pT6+UyaOYzQClA+KaB3neQ9UjDVwZUp57Cb8KuoeaDlieqBP6 c/s7xuhkCrvDruDsXn+TrKfTwL9zPX/Z+H9n8MN4D7VcYCsHaVlUgrcjXoDYLm/nFOIF YbbreeAcQnkqGUctKSpyxzGCMgKROLxBQ4AV9sUuiYwTLQLW9Xt6HJfzR7wIxzGJlYN5 am/0vPKhlqPQPjQLHC6JV1ruuCIp6ogzs/V+EP+4A7bhN1gC1BIitO0/JnLEChP7jSpq yRNL4oHAJ9DYLVpfEt3Bc2v72VlyddhdKB8obaMuf+rF9DlfQQRlA4IPcjCgETfN2dB0 c2lg==
X-Gm-Message-State: AA+aEWZxyQCznLDUdsABwppXJs96YQBX9VFFXxAjv5XRt1BeD0i9sbyw bapMPYJKukLsNkkxkTo+WuRtCg3LVOD0jTZfK2kbppgt
X-Google-Smtp-Source: AFSGD/WgJg3wrxB6+1ykfvCLh8eXB4zM9Aok4bWh0MinKEGMYmcbdaFBnPWOqEXI7UBKw2LDGH679WhwA//jkfOaIEg=
X-Received: by 2002:a1c:9855:: with SMTP id a82mr5379011wme.20.1543334289439;  Tue, 27 Nov 2018 07:58:09 -0800 (PST)
MIME-Version: 1.0
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>
In-Reply-To: <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>
From: Nat Sakimura 
Date: Tue, 27 Nov 2018 16:57:57 +0100
Message-ID: 
To: Jim Manico 
Cc: Vladimir Dzhuvinov , oauth@ietf.org,  "openid-specs-ab@lists.openid.net Ab" 
Content-Type: multipart/alternative; boundary="000000000000178328057ba784e9"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 15:58:21 -0000

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

I am not talking about SPA.
The client is a regular confidential client that is running on a server.

Best,

Nat Sakimura


2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico :

> Nat,
>
> How is proof of possession established in a modern web browser in the
> implicit flow?
>
> My understanding is that token binding was removed from Chrome recently
> effectively killing browser-based PoP tokens.
>
> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>
> Am I missing something?
>
> Aloha, Jim
>
>
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>
> I am actually -1.
>
> +1 for public client and the tokens that are not sender/key constrained.
>
> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming.
>
> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is very u=
seful in certain
> cases.
> Specifically, when the client is confidential (based on public key pair),
> and uses sender constrained (key-constrained) token such as the one
> explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
> very useful.
> (Key-constrained token is the remaining portion of this draft that did no=
t
> get incorporated in the MTLS draft. )
> In fact it is the only viable method for Self-Issued OpenID Provider.
>
> So, the text is generally good but it needs to be constrained like =E2=80=
=9CUnless
> the client is confidential and the access token issued is key constrained=
,
> ... =E2=80=9C
>
> Best,
>
> Nat Sakimura
>
>
> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvinov <=
vladimir@connect2id.com>:
>
>> +1 to recommend the deprecation of implicit.
>>
>> I don't see a compelling reason to keep implicit when there is an
>> established alternative that is more secure.
>>
>> Our duty as WG is to give developers the best and most sensible practice=
.
>>
>> CORS adoption is currently at 94% according to
>> https://caniuse.com/#feat=3Dcors
>>
>> Vladimir
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> --
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


    I am not talking about SPA.=C2=A0
    The client is a regular confidential client that is running on a=
 server.=C2=A0

    Best,=C2=
=A0

    Nat Sakimura


    2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico <jim@manicode.com>:
    
 =20
   =20
 =20
  
    
    
    Nat,
    
    
    How is proof of possession established in a modern web browser in
      the implicit flow?
    
    
    My understanding is that token binding was removed from Chrome
      recently effectively killing browser-based PoP tokens.
    
    
    
    
    https://identiverse.com/2018/10/31/chrome-puts-token-binding-in=
-a-bind/
    
    
    Am I missing something?
    
    
    Aloha, Jim
    
    

    
    
    
    
    On 11/27/18 9:00 PM=
, Nat Sakimura
      wrote:
    
    
    
    
    
     =20
      
    
        
    I am actually -1.=C2=A0
    
      
    
      

    
      
    
      
    +1 for public client and the tokens that are not
        sender/key constrained.=C2=A0
    
      

    
      
    
      
    Just not being used right now does not mean that
        it is not useful.. In fact, I see it coming.=C2=A0
    
      
    Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=
=80=9D really) is
        very useful in certain cases.=C2=A0
    
      
    Specifically, when the client is confidential
        (based on public key pair), and uses sender constrained
        (key-constrained) token such as the one explained in https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5<=
/a>,
        it is very useful.=C2=A0
    
      
    (Key-constrained token is the remaining portion of
        this draft that did not get incorporated in the MTLS draft. )
    
      
    In fact it is the only viable method for
        Self-Issued OpenID Provider.=C2=A0
    
      

    
      
    
      
    So, the text is generally good but it needs to be
        constrained like =E2=80=9CUnless the client is confidential and the
        access token issued is key constrained, ... =E2=80=9C
    
      

    
      
    
      
    Best,=C2=A0
    
      

    
      
    
      
    Nat Sakimura
    
        

    
        
    
      
    
      

    
        
    
          
          
    +1 to
            recommend the deprecation of implicit.
    
            
    
            I don't see a compelling reason to keep implicit when there
            is an
    
            established alternative that is more secure.
    
            
    
            Our duty as WG is to give developers the best and most
            sensible practice.
    
            
    
            CORS adoption is currently at 94% according to
    
            https://caniuse.com/#feat=3Dcors
    
            
    
            Vladimir
    
            
    
            
    
            _______________________________________________
    
            OAuth mailing list
    
            OAuth@ietf.=
org
    
            https://www.ietf.org/mailman/listinfo/oauth
    
          
    
        
    
      
    
      -- 
    
      
    Nat Sakimura (=3Dnat)
        
      
    
      
    
      
    
      
    ___________________=
____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth

    
    
    
    
    --=20
Jim Manico
Manicode Security
https://www.manicode.com
    
  
    


    -- 
    Nat Sakimura (=3Dnat)
    Chairman, Open=
ID Foundation
    htt=
p://nat.sakimura.org/
    @_nat_en
    

--000000000000178328057ba784e9--


From nobody Tue Nov 27 11:30:58 2018
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 254C2124D68 for ; Tue, 27 Nov 2018 11:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 cS2Ihu5Jh7y6 for ; Tue, 27 Nov 2018 11:30:53 -0800 (PST)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.99]) (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 00FFE128DFD for ; Tue, 27 Nov 2018 11:30:52 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRj4K-0001ha-Re; Tue, 27 Nov 2018 20:30:48 +0100
From: Torsten Lodderstedt 
Message-Id: <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_D7ED3932-6335-4DB7-8AEF-A83EDB1DD124"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 27 Nov 2018 20:30:45 +0100
In-Reply-To: 
Cc: Jim Manico , "openid-specs-ab@lists.openid.net Ab" , oauth@ietf.org
To: Nat Sakimura 
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com> 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 19:30:57 -0000

--Apple-Mail=_D7ED3932-6335-4DB7-8AEF-A83EDB1DD124
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Nat,=20

I understand you are saying your draft could provide clients with an =
application level mechanism to sender constrain access tokens. That=E2=80=99=
s great!=20

But I don=E2=80=99t see a binding to response type =E2=80=9Etoken =
id_token=E2=80=9C. Why do you want to expose the tokens via the URL to =
attackers?=20

You could easily use your mechanism with code. That would also give you =
the chance to really authenticate the confidential client before you =
issue the token.

kind regards,
Torsten.

> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
>=20
> I am not talking about SPA.=20
> The client is a regular confidential client that is running on a =
server.=20
>=20
> Best,=20
>=20
> Nat Sakimura
>=20
>=20
> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico =
:
> Nat,
>=20
> How is proof of possession established in a modern web browser in the =
implicit flow?
>=20
> My understanding is that token binding was removed from Chrome =
recently effectively killing browser-based PoP tokens.
>=20
> =
https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>=20
> Am I missing something?
>=20
> Aloha, Jim
>=20
>=20
>=20
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>> I am actually -1.=20
>>=20
>> +1 for public client and the tokens that are not sender/key =
constrained.=20
>>=20
>> Just not being used right now does not mean that it is not useful.. =
In fact, I see it coming.=20
>> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is =
very useful in certain cases.=20
>> Specifically, when the client is confidential (based on public key =
pair), and uses sender constrained (key-constrained) token such as the =
one explained in =
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it =
is very useful.=20
>> (Key-constrained token is the remaining portion of this draft that =
did not get incorporated in the MTLS draft. )
>> In fact it is the only viable method for Self-Issued OpenID Provider.=20=

>>=20
>> So, the text is generally good but it needs to be constrained like =
=E2=80=9CUnless the client is confidential and the access token issued =
is key constrained, ... =E2=80=9C
>>=20
>> Best,=20
>>=20
>> Nat Sakimura
>>=20
>>=20
>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir =
Dzhuvinov :
>> +1 to recommend the deprecation of implicit.
>>=20
>> I don't see a compelling reason to keep implicit when there is an
>> established alternative that is more secure.
>>=20
>> Our duty as WG is to give developers the best and most sensible =
practice.
>>=20
>> CORS adoption is currently at 94% according to
>> https://caniuse.com/#feat=3Dcors
>>=20
>> Vladimir
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> --=20
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat..sakimura.org/
>> @_nat_en
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>>=20
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> --=20
> Jim Manico
> Manicode Security
>=20
> https://www.manicode.com
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_D7ED3932-6335-4DB7-8AEF-A83EDB1DD124
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjcxOTMwNDVaMC8GCSqGSIb3DQEJBDEiBCAT
hNuN8F84way4Inip40lUXQHSBZ/A0U2R5CvjICoYPjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAMV4J+7rEyQZo/5312qe+1Iam
tSdc13kEVxA5qLE7MNp38OFCNTigA2vRDn76/NGwfU7thvBZggkanCZeavKrvid0fPQLBFA7U5qU
eneRhQ2FgKT0dGDp9KO2w1Yb99Np342/q4NQtcDDosskdWQ48jB1RIHq3RCWWS1oOrVzTs/ri5B1
nDLiovUnYQhfSpxqkz8oJWiVa0gbd0FCBwA1V/ubsQya5l7XF3kP6sDrz6KD/lVSKexZPjCeBQ0O
68BsXoZTNTDm+cE8LLgvniKKfDdgf1Xuou7i5n0rTM9F0RlznVwGSU8tZvjwxR6M7En3xEmYIx3X
V0pd6/GClfK4WgAAAAAAAA==
--Apple-Mail=_D7ED3932-6335-4DB7-8AEF-A83EDB1DD124--


From nobody Tue Nov 27 11:54:35 2018
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 75D73124408 for ; Tue, 27 Nov 2018 11:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 DhLxROAXEEcr for ; Tue, 27 Nov 2018 11:54:30 -0800 (PST)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 AF1451241F6 for ; Tue, 27 Nov 2018 11:54:29 -0800 (PST)
Received: by mail-wm1-x344.google.com with SMTP id s11so261047wmh.1 for ; Tue, 27 Nov 2018 11:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xDahITsc/6i0pzwJqXyu+++Esc+hxQkM8M+wetJmIt0=; b=iWKWlTumpNGcTes6rukRAFaAAnO0XNSPsQhzGl6laAg9+hFLIfF4WDL15bTSMr5HkA GM+cSblVab+m6fKfqeteq5Cu6fR01fhk1Tl0VA1947F++IuvtRALnpEtCr56TVvkA1n1 ipNM0EWvPq1kPe687eFrVAwdCxOGZ+SJ1/cvEbsObco3E3Slkrnmx1K0hmS6App6Sj7H KhPJhH6fwSAkGQ3lXFItDzauQmmi7hNuZrpWNg0GVsBjyjsN1oT7XFWCJJcexmDcyD54 z/s6fwzHZdYPzAxrAXaH1WBsE1Crtzem8OXxWedOr20qJ3odmC9Vyac2PJWftUld7ds2 DsHQ==
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=xDahITsc/6i0pzwJqXyu+++Esc+hxQkM8M+wetJmIt0=; b=AzyHlozCotc/1JgztA7p0mLQqj0wxBCrSne8AavkCa+u3BqoQN+8SmICofMvSg7/t6 3N49DkeDBCBnpYl+iyyTI8D1FdIUmXqwl491CVHnEa9okuMHS7eU1q0L9rQ1W0DAXG1W vBS253z7pCYenhiWFFnky6ZQDHcrUMf22FyKT4u64NDXKjJK9Lws2GQyTb+X/XHzzgVl NNMqX5wdGuuZZp6fT4Hq8aDSnxHo6gqhrCpS/XKdBwSGs8K5ex3l6yhFrC4KF0yWH+th N+X/7WLJNcLotfKpBdlpNtkIleSTghCuK1yDdDN94ZLnfkUTbZtGyONBklknQBbs0hez 3WSA==
X-Gm-Message-State: AA+aEWaOGdt5GAzqaQHhBR51tMGWlM7FMYi/eSHBJLGocKZBFvD/4BdQ 1ul3bkC6gWAiHcofwI5NKTeGEGJpZvxg4YJf50InVA==
X-Google-Smtp-Source: AFSGD/XGHgKsFT0pbkcdlehPwme0Ubxe6fuSYm90BlGNf/GXzik53aLFhs1x/hvurRSuUMGXNxbyVVd9MqeoEA65KVA=
X-Received: by 2002:a7b:c1d6:: with SMTP id a22mr239237wmj.48.1543348467472; Tue, 27 Nov 2018 11:54:27 -0800 (PST)
MIME-Version: 1.0
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>
In-Reply-To: <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>
From: John Bradley 
Date: Tue, 27 Nov 2018 16:54:15 -0300
Message-ID: 
To: "openid-specs-ab@lists.openid.net Ab" 
Cc: Nat Sakimura , Torsten Lodderstedt , oauth@ietf.org,  Jim Manico 
Content-Type: multipart/alternative; boundary="0000000000002b37f9057baad17f"
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 19:54:33 -0000

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

I talked to Nat about this a bit today.

The thing he is concerned about is mostly around the self issued IDP that
doesn't have a token endpoint(atleast not easaly).

The main use case for that is the id_token response type where claims are
retuned in the id_token.

Because it is fragment encoded some people call that implicit.   That is
not what we are trying to stop.

In some cases in that flow there may be distributed claims returned with
access Token inside the id_token.    I think most people would agree that
those should be pop or sender constrained tokens.

In the case of self issued the RP would be a server and could do sender
constrained via some mechinisim that is yet to be defined.

So if someone wanted to return a access token in a id_token to do
distributed claims I don't think we have a problem with that as long as the
token is protected by being sender constrained in some reasonable way.

This is a touch hypothetical from the basic OAuth perspective, so I don't
know how deep we want to go into it.

I think the point is not to accidently prohibit something that could be
done in future.

I also think we should not conflate confidential clients that can
authenticate to the token endpoint with sender constrained/PoP clients that
can deal with bound tokens.   Yes both have keys but it is better to
describe them separately.

John B.

On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
openid-specs-ab@lists.openid.net wrote:

> Hi Nat,
>
> I understand you are saying your draft could provide clients with an
> application level mechanism to sender constrain access tokens. That=E2=80=
=99s
> great!
>
> But I don=E2=80=99t see a binding to response type =E2=80=9Etoken id_toke=
n=E2=80=9C. Why do you
> want to expose the tokens via the URL to attackers?
>
> You could easily use your mechanism with code. That would also give you
> the chance to really authenticate the confidential client before you issu=
e
> the token.
>
> kind regards,
> Torsten.
>
> > Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> >
> > I am not talking about SPA.
> > The client is a regular confidential client that is running on a server=
.
> >
> > Best,
> >
> > Nat Sakimura
> >
> >
> > 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico :
> > Nat,
> >
> > How is proof of possession established in a modern web browser in the
> implicit flow?
> >
> > My understanding is that token binding was removed from Chrome recently
> effectively killing browser-based PoP tokens.
> >
> > https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> >
> > Am I missing something?
> >
> > Aloha, Jim
> >
> >
> >
> > On 11/27/18 9:00 PM, Nat Sakimura wrote:
> >> I am actually -1.
> >>
> >> +1 for public client and the tokens that are not sender/key
> constrained.
> >>
> >> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming.
> >> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is ver=
y useful in
> certain cases.
> >> Specifically, when the client is confidential (based on public key
> pair), and uses sender constrained (key-constrained) token such as the on=
e
> explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
> very useful.
> >> (Key-constrained token is the remaining portion of this draft that did
> not get incorporated in the MTLS draft. )
> >> In fact it is the only viable method for Self-Issued OpenID Provider.
> >>
> >> So, the text is generally good but it needs to be constrained like
> =E2=80=9CUnless the client is confidential and the access token issued is=
 key
> constrained, ... =E2=80=9C
> >>
> >> Best,
> >>
> >> Nat Sakimura
> >>
> >>
> >> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvino=
v :
> >> +1 to recommend the deprecation of implicit.
> >>
> >> I don't see a compelling reason to keep implicit when there is an
> >> established alternative that is more secure.
> >>
> >> Our duty as WG is to give developers the best and most sensible
> practice.
> >>
> >> CORS adoption is currently at 94% according to
> >> https://caniuse.com/#feat=3Dcors
> >>
> >> Vladimir
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> --
> >> Nat Sakimura (=3Dnat)
> >> Chairman, OpenID Foundation
> >> http://nat..sakimura.org/
> >> @_nat_en
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >>
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> > --
> > Jim Manico
> > Manicode Security
> >
> > https://www.manicode.com
> > --
> > Nat Sakimura (=3Dnat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

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


    I talked to Nat about this a bit today.=C2=A0=C2=A0

    The thing he is concerned about is =
mostly around the self issued IDP that doesn't have a token endpoint(at=
least not easaly).=C2=A0=C2=A0

    The main use case for that is the id_token response type where claim=
s are retuned in the id_token.=C2=A0=C2=A0

    Because it is fragment encoded some people call that imp=
licit.=C2=A0 =C2=A0That is not what we are trying to stop.=C2=A0 =C2=A0

    In some cases in that flow =
there may be distributed claims returned with access Token inside the id_to=
ken.=C2=A0 =C2=A0 I think most people would agree that those should be pop =
or sender constrained tokens.=C2=A0=C2=A0

    =

    In the case of self issued the RP would be a server and c=
ould do sender constrained via some mechinisim that is yet to be defined.=
=C2=A0=C2=A0

    So if someo=
ne wanted to return a access token in a id_token to do distributed claims I=
 don't think we have a problem with that as long as the token is protec=
ted by being sender constrained in some reasonable way.

    This is a touch hypothetical from the basic=
 OAuth perspective, so I don't know how deep we want to go into it.

    I think the point is not to=
 accidently prohibit something that could be done in future.=C2=A0=C2=A0

    I also think we should not=
 conflate confidential clients that can authenticate to the token endpoint =
with sender constrained/PoP clients that can deal with bound tokens.=C2=A0 =
=C2=A0Yes both have keys but it is better to describe them separately.=C2=
=A0=C2=A0

    John B.=C2=A0<=
/div>

    On Tue, Nov 27, =
2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <openid-specs-ab@lists.openid.net wro=
te:
    Hi Nat, 
    

    
I understand you are saying your draft could provide clients with an applic=
ation level mechanism to sender constrain access tokens. That=E2=80=99s gre=
at! 
    

    
But I don=E2=80=99t see a binding to response type =E2=80=9Etoken id_token=
=E2=80=9C. Why do you want to expose the tokens via the URL to attackers? <=
br>

    
You could easily use your mechanism with code. That would also give you the=
 chance to really authenticate the confidential client before you issue the=
 token.
    

    
kind regards,
    
Torsten.
    

    
> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <sakimura@gmail.com=
>:
    
> 
    
> I am not talking about SPA. 
    
> The client is a regular confidential client that is running on a serve=
r. 
    
> 
    
> Best, 
    
> 
    
> Nat Sakimura
    
> 
    
> 
    
> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico <jim@=
manicode.com>:
    
> Nat,
    
> 
    
> How is proof of possession established in a modern web browser in the =
implicit flow?
    
> 
    
> My understanding is that token binding was removed from Chrome recentl=
y effectively killing browser-based PoP tokens.
    
> 
    
> https://ident=
iverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
    
> 
    
> Am I missing something?
    
> 
    
> Aloha, Jim
    
> 
    
> 
    
> 
    
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
    
>> I am actually -1. 
    
>> 
    
>> +1 for public client and the tokens that are not sender/key constr=
ained. 
    
>> 
    
>> Just not being used right now does not mean that it is not useful.=
. In fact, I see it coming. 
    
>> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is=
 very useful in certain cases. 
    
>> Specifically, when the client is confidential (based on public key=
 pair), and uses sender constrained (key-constrained) token such as the one=
 explained in https://t=
ools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is very u=
seful. 
    
>> (Key-constrained token is the remaining portion of this draft that=
 did not get incorporated in the MTLS draft. )
    
>> In fact it is the only viable method for Self-Issued OpenID Provid=
er. 
    
>> 
    
>> So, the text is generally good but it needs to be constrained like=
 =E2=80=9CUnless the client is confidential and the access token issued is =
key constrained, ... =E2=80=9C
    
>> 
    
>> Best, 
    
>> 
    
>> Nat Sakimura
    
>> 
    
>> 
    
>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhu=
vinov <vladimir@connect2id.com>:
    
>> +1 to recommend the deprecation of implicit.
    
>> 
    
>> I don't see a compelling reason to keep implicit when there is=
 an
    
>> established alternative that is more secure.
    
>> 
    
>> Our duty as WG is to give developers the best and most sensible pr=
actice.
    
>> 
    
>> CORS adoption is currently at 94% according to
    
>> https://caniuse.com/#feat=3Dcors
    
>> 
    
>> Vladimir
    
>> 
    
>> 
    
>> _______________________________________________
    
>> OAuth mailing list
    
>> OAuth@ietf.org
    
>> https://www.ietf.org/mailman/listinfo=
/oauth
    
>> -- 
    
>> Nat Sakimura (=3Dnat)
    
>> Chairman, OpenID Foundation
    
>> http://nat..sakimura.org/
    
>> @_nat_en
    
>> 
    
>> 
    
>> _______________________________________________
    
>> OAuth mailing list
    
>> 
    
>> OAuth@ietf.org
    
>> https://www.ietf.org/mailman/listinfo=
/oauth
    
> -- 
    
> Jim Manico
    
> Manicode Security
    
> 
    
> https://www.manicode.com
    
> -- 
    
> Nat Sakimura (=3Dnat)
    
> Chairman, OpenID Foundation
    
> http://nat.sakimura.org/
    
> @_nat_en
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org
    
> https://www.ietf.org/mailman/listinfo/oau=
th
    

    
_______________________________________________
    
Openid-specs-ab mailing list
    
Openid-specs-ab@lists.openid.net
    
http://lists.openid.net/mailman/l=
istinfo/openid-specs-ab
    

    

--0000000000002b37f9057baad17f--


From nobody Tue Nov 27 12:28:21 2018
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 2D377126F72 for ; Tue, 27 Nov 2018 12:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Ee3mhz1LbpZQ for ; Tue, 27 Nov 2018 12:28:17 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) (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 36817124408 for ; Tue, 27 Nov 2018 12:28:17 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRjxt-0003j8-7Q; Tue, 27 Nov 2018 21:28:13 +0100
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_9136D831-337C-4881-BDA9-3C99907EAF90"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 27 Nov 2018 21:28:11 +0100
In-Reply-To: 
Cc: "openid-specs-ab@lists.openid.net Ab" ,  Nat Sakimura , oauth , Jim Manico 
To: John Bradley 
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net> 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 20:28:20 -0000

--Apple-Mail=_9136D831-337C-4881-BDA9-3C99907EAF90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi John,=20

as you said, self issued IDPs =
(https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are =
supposed to provide the response type =E2=80=9Eid_token=E2=80=9C only. I =
don=E2=80=99t think the proposal being discussed here is related to this =
OIDC mode.=20

best regards,
Torsten.=20

> Am 27.11.2018 um 20:54 schrieb John Bradley :
>=20
> I talked to Nat about this a bit today. =20
>=20
> The thing he is concerned about is mostly around the self issued IDP =
that doesn't have a token endpoint(atleast not easaly). =20
>=20
> The main use case for that is the id_token response type where claims =
are retuned in the id_token. =20
>=20
> Because it is fragment encoded some people call that implicit.   That =
is not what we are trying to stop.  =20
>=20
> In some cases in that flow there may be distributed claims returned =
with access Token inside the id_token.    I think most people would =
agree that those should be pop or sender constrained tokens. =20
>=20
> In the case of self issued the RP would be a server and could do =
sender constrained via some mechinisim that is yet to be defined. =20
>=20
> So if someone wanted to return a access token in a id_token to do =
distributed claims I don't think we have a problem with that as long as =
the token is protected by being sender constrained in some reasonable =
way.
>=20
> This is a touch hypothetical from the basic OAuth perspective, so I =
don't know how deep we want to go into it.
>=20
> I think the point is not to accidently prohibit something that could =
be done in future. =20
>=20
> I also think we should not conflate confidential clients that can =
authenticate to the token endpoint with sender constrained/PoP clients =
that can deal with bound tokens.   Yes both have keys but it is better =
to describe them separately. =20
>=20
> John B.=20
>=20
> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab =
 Hi Nat,=20
>=20
> I understand you are saying your draft could provide clients with an =
application level mechanism to sender constrain access tokens. That=E2=80=99=
s great!=20
>=20
> But I don=E2=80=99t see a binding to response type =E2=80=9Etoken =
id_token=E2=80=9C. Why do you want to expose the tokens via the URL to =
attackers?=20
>=20
> You could easily use your mechanism with code. That would also give =
you the chance to really authenticate the confidential client before you =
issue the token.
>=20
> kind regards,
> Torsten.
>=20
> > Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> >=20
> > I am not talking about SPA.=20
> > The client is a regular confidential client that is running on a =
server.=20
> >=20
> > Best,=20
> >=20
> > Nat Sakimura
> >=20
> >=20
> > 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico =
:
> > Nat,
> >=20
> > How is proof of possession established in a modern web browser in =
the implicit flow?
> >=20
> > My understanding is that token binding was removed from Chrome =
recently effectively killing browser-based PoP tokens.
> >=20
> > =
https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> >=20
> > Am I missing something?
> >=20
> > Aloha, Jim
> >=20
> >=20
> >=20
> > On 11/27/18 9:00 PM, Nat Sakimura wrote:
> >> I am actually -1.=20
> >>=20
> >> +1 for public client and the tokens that are not sender/key =
constrained.=20
> >>=20
> >> Just not being used right now does not mean that it is not useful.. =
In fact, I see it coming.=20
> >> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is =
very useful in certain cases.=20
> >> Specifically, when the client is confidential (based on public key =
pair), and uses sender constrained (key-constrained) token such as the =
one explained in =
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it =
is very useful.=20
> >> (Key-constrained token is the remaining portion of this draft that =
did not get incorporated in the MTLS draft. )
> >> In fact it is the only viable method for Self-Issued OpenID =
Provider.=20
> >>=20
> >> So, the text is generally good but it needs to be constrained like =
=E2=80=9CUnless the client is confidential and the access token issued =
is key constrained, ... =E2=80=9C
> >>=20
> >> Best,=20
> >>=20
> >> Nat Sakimura
> >>=20
> >>=20
> >> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir =
Dzhuvinov :
> >> +1 to recommend the deprecation of implicit.
> >>=20
> >> I don't see a compelling reason to keep implicit when there is an
> >> established alternative that is more secure.
> >>=20
> >> Our duty as WG is to give developers the best and most sensible =
practice.
> >>=20
> >> CORS adoption is currently at 94% according to
> >> https://caniuse.com/#feat=3Dcors
> >>=20
> >> Vladimir
> >>=20
> >>=20
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> --=20
> >> Nat Sakimura (=3Dnat)
> >> Chairman, OpenID Foundation
> >> http://nat..sakimura.org/
> >> @_nat_en
> >>=20
> >>=20
> >> _______________________________________________
> >> OAuth mailing list
> >>=20
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> > --=20
> > Jim Manico
> > Manicode Security
> >=20
> > https://www.manicode.com
> > --=20
> > Nat Sakimura (=3Dnat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab


--Apple-Mail=_9136D831-337C-4881-BDA9-3C99907EAF90
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjcyMDI4MTFaMC8GCSqGSIb3DQEJBDEiBCDI
y9OwPWU707llXHduFji3yZqdrGFoDG6t4Yd1alPxrzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAdavaUQgT+wAuzOIZT1kgFg5m
icLjE2OsJXorKTZ7SMCopixawfkMqgtwuDxF1Zpxs/cBFlcecsQl5ELgV6E28bwz21ByCx9uTfqs
kOn6zxING6dolaWmmLRmKDfK0infOhki7c67XSQIadGwkSQDbQUH6qEgzLU6G4ShmgyLFMdYBdm6
mMf0x9MoG6lfk6W3ETge2kGkiJhCfemA5KZHkez6UOF7zZeDAEgjDT0br3K+9iJneIEr9rliuupv
NSrsamoCLDD9ybxPeOqda/FpJ+HnoMp8hxQldZOkfXDsNcaxAwEzsa0rXpkHqf7hywEf+rhOSd+7
9mGIXyQuzEJuPgAAAAAAAA==
--Apple-Mail=_9136D831-337C-4881-BDA9-3C99907EAF90--


From nobody Tue Nov 27 12:28:44 2018
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 ABD4F126F72 for ; Tue, 27 Nov 2018 12:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.959
X-Spam-Level: 
X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWwPdMQhlESX for ; Tue, 27 Nov 2018 12:28:33 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 3C479130DC5 for ; Tue, 27 Nov 2018 12:28:33 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id t24so12353165ioi.0 for ; Tue, 27 Nov 2018 12:28:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xtAtjmCOspxllWiTJJiVH81NLw+jJMwHt7R5oczahPk=; b=UECcLAqPQ9SMkjIkBOXJBNfymFN+eFRalHMUuKcAGd7BMbMoGgTUa7NbWh1C+34lA0 N0ANPrRWxtzTruwyuopk6vU83/FyU6JXw+Rggfs+ivc+mcF4F8bhaBVSxrTYvwgIk8wx SsYyoVjvy7YcTrj3xhIxCxIpLu8LbxXR2R83OaECnTnDdaH56PJzBEqkYgb79DnRo6ZU tiIS4j4WGpd1xCzix9ukzBuKtenjvIJj0JmEjBCNdSv1IJczR+shdX48WgMgoEB3wuWp TRucXLy9fZ18/v1rz2gWQk7vNFFSK8NYTOyOqdrMnD0+qlM+K+t970sH09oIx/h66Ecu du7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xtAtjmCOspxllWiTJJiVH81NLw+jJMwHt7R5oczahPk=; b=SQguYOeOXFR0Fr0eoBqak4lyKBO2pIs38d3k53GWoXNMwJucbpKONvSyxpBZ3Aknee 4Ps3TuHVLWvQjvmmylAGw6yiXm2rBNfFRxDaU6DeoagaBIxYeuZND4+agZdDVmYqu+dY EgCPKTtdSauYytgPjg05eGdtxupSn/lVhdv4/i5FjJH9iwxcPEcRsw4tnEZZLh6z63YB 8gqjuNkR3B1VXwt+/IFo1EC00TqD6Ol6G5vDZ/w2IyrE3N45Njq9YRfrAa/ecb5gxNpz gX0Moy2zw28Ii8/lbgmDvtc1YC3pkANmj4f2e9NAMIe+S6rHMOGJhdKsUwh1rjJup4A4 Wq/w==
X-Gm-Message-State: AA+aEWbpb+tg6bN4VvZpFDD3IT99y0znA8FlLzk/85ry6v2xh1V3YQNp T7JJNNT72uBF6NpmoqAeuv1esQ+fUrRdxCK6pTNFQo5lbzM=
X-Google-Smtp-Source: AFSGD/VGv0rzU/Y4iIibe8w3HlHQ4E5988koWM91y0CyTxQLvEjyfSTc0kJLgQDisYgc/dr7zY03L8WIDun/sRxUD9M=
X-Received: by 2002:a6b:8f8d:: with SMTP id r135mr26226623iod.5.1543350512152;  Tue, 27 Nov 2018 12:28:32 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a6b:5102:0:0:0:0:0 with HTTP; Tue, 27 Nov 2018 12:28:11 -0800 (PST)
In-Reply-To: 
References: 
From: William Denniss 
Date: Tue, 27 Nov 2018 12:28:11 -0800
Message-ID: 
To: Christian Mainka 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000000ae2cc057bab4b4d"
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 27 Nov 2018 20:28:43 -0000

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

If the secret is dynamically provisioned then you have a confidential
client. Anyone reverse engineering their own installation of the native app
would only extract their own client's credentials, as opposed to the shared
secret of all installations. Having a confidential client means that
requests to the token endpoint (code, refresh) are client authenticated, so
PKCE wouldn't be needed.

On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <
Christian.Mainka=3D40rub.de@dmarc.ietf.org> wrote:

> Hi,
>
> we just stumbled upon this [1] statement:
> "Except when using a mechanism like Dynamic Client Registration
>    [RFC7591] to provision per-instance secrets, native apps are
>    classified as public clients ..."
>
> What does this mean for us? Native App + Dynamic Client Registration =3D
> Confidential Client?
> Which threats are covered if Dynamic Client Registration is used on
> Native Apps?
>
> Best Regards,
> Vladi/Christian
>
> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>
> --
> Dr.-Ing. Christian Mainka
> Horst G=C3=B6rtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universit=C3=A4tsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347
> http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    If the secret is dynamically provisioned then you have a c=
onfidential client.=C2=A0Anyone reverse engineering their own installation =
of the native app would only extract their own client's credentials, as=
 opposed to the shared secret of all installations. Having a confidential c=
lient means that requests to the token endpoint (code, refresh) are client =
authenticated, so PKCE wouldn't be needed.

    On Tue, Nov 27, 2018 at 1:44 AM, Christi=
an Mainka <Christian.Mainka=3D40rub.de@dmarc.ietf=
.org> wrote:
    Hi,
    

    
we just stumbled upon this [1] statement:
    
"Except when using a mechanism like Dynamic Client Registration
    
=C2=A0=C2=A0 [RFC7591] to provision per-instance secrets, native apps are
=C2=A0=C2=A0 classified as public clients ..."
    

    
What does this mean for us? Native App + Dynamic Client Registration =3D
Confidential Client?
    
Which threats are covered if Dynamic Client Registration is used on
    
Native Apps?
    

    
Best Regards,
    
Vladi/Christian
    

    
[1]: https://tools.ietf.org/html/rfc8252#section=
-8.4
    

    
-- 
    
Dr.-Ing. Christian Mainka
    
Horst G=C3=B6rtz Institute for IT-Security 
    
Chair for Network and Data Security 
    
Ruhr-University Bochum, Germany
    

    
Universit=C3=A4tsstr. 150, ID 2/463
    
D-44801 Bochum, Germany
    

    
Telefon: +49 (0) 234 / 32-26796
    
Fax: +49 (0) 234 / 32-14347
    
http://nds.rub.de/chair/people/cmainka/
    
@CheariX
    

    

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


    

--0000000000000ae2cc057bab4b4d--


From nobody Tue Nov 27 12:37:09 2018
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 03BBA124D68 for ; Tue, 27 Nov 2018 12:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 Fmule8oodc0W for ; Tue, 27 Nov 2018 12:37:04 -0800 (PST)
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 3DA66126F72 for ; Tue, 27 Nov 2018 12:37:04 -0800 (PST)
Received: by mail-qk1-x742.google.com with SMTP id o89so15519571qko.0 for ; Tue, 27 Nov 2018 12:37:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=PNxguyTuEv8zrULfS/wQcW85RUcMdotWPbe9Mm/uFMA=; b=IHmGZI5tsex51lkn3GAoePLr2rLh+RvUcpRpAksnxtYcrQOVukUYiiiEksbSnhdFzs q1CZakPDsQxwGXSO7+3l0LYxcrbF5dGwxhOetiSFtMiIr+X3yf1O0huZsq2UN8V+GVVJ SRbqLAxnIzD53626ukvjpB8UzRptfc/lolKfollAwNUu/iJ1mD1r8KuzOp6qhAXtZU8m Wo6Av1xwHX2+2OvtzpmHFHm9ig2xT9crlPYvczYXKjhE2zFSght8YQx9kzZRIfOAeE4u GqECRp43m6IwFnfnrVUO0miCzBFyT2WlWQt4GtocT5a1GyLpRPceuY0Us9KBARyy4hPI L4FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=PNxguyTuEv8zrULfS/wQcW85RUcMdotWPbe9Mm/uFMA=; b=LnNxUxUrC90U5IhbyRgSbTfx9hlsBKeTNJDv2tUFWqDraTagplu24KeYtE9PkXqnzH JgLgP4wruURJtNMuPDrGmIzMs3iQyAz1SfiIq9pbLIsB/yQfGeFIjN2TztobNxBabiy4 eft2/M80kwmUpNY3uOZnIHf6qwJHMVDn8JHJVfvMk5mznrsy2r5dQp0X+Vdn8BzZOMCU Bpudz7AzNmdmzonTvZFrM0UdYpGdYbBzN2DAREsxbgX3xkhwphEBxeSc8rxIifXmSiOE WR6JBGAiY/eygXuASddZim9CsPFjJrsVxXy8MAMoyd15hjlSWuM+1D8+34ZoaUhYg95A x+pA==
X-Gm-Message-State: AA+aEWZZJ+ltFRqZj9il7QHGJjCLEhNVQF1coHLgFoOBF8KA3BW3D2eG l2cjLNs1zjMyUdetV8YEE1ehTg==
X-Google-Smtp-Source: AFSGD/X1ON3nJ3zBMw3AvT8+AjeWdTMugRKr1wEBTFycOgD91yGz995IYLgDP0TqsqTSEeQ5foW7WA==
X-Received: by 2002:a37:ad0:: with SMTP id 199mr31331184qkk.345.1543351022730;  Tue, 27 Nov 2018 12:37:02 -0800 (PST)
Received: from [192.168.8.103] ([191.125.134.153]) by smtp.gmail.com with ESMTPSA id o27sm3187000qkh.35.2018.11.27.12.37.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 12:37:01 -0800 (PST)
From: John Bradley 
X-Google-Original-From: John Bradley 
To: Torsten Lodderstedt 
Cc: "openid-specs-ab@lists.openid.net Ab" ,  Nat Sakimura , oauth , Jim Manico 
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>  
Message-ID: <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com>
Date: Tue, 27 Nov 2018 17:36:58 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 20:37:07 -0000

I understand that, but hat is Nat's concern as I understand it.

When we say no implicit people, have a problem because implicit is 
imprecise.

We are saying no AT returned in the response from the authorization 
endpoint.

Nat points out that id_token may contain AT for the self issued client.

So unless we say that is OK if the AT are sender constrained we wind up 
implying that a OpenID profile of OAuth is in violation of the BCP.

I am just trying to make sure everyone is on the same page with why Nat 
was -1.

It really has nothing to do with the SPA use case.

John B.

On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
> Hi John,
>
> as you said, self issued IDPs (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are supposed to provide the response type „id_token“ only. I don’t think the proposal being discussed here is related to this OIDC mode.
>
> best regards,
> Torsten.
>
>> Am 27.11.2018 um 20:54 schrieb John Bradley :
>>
>> I talked to Nat about this a bit today.
>>
>> The thing he is concerned about is mostly around the self issued IDP that doesn't have a token endpoint(atleast not easaly).
>>
>> The main use case for that is the id_token response type where claims are retuned in the id_token.
>>
>> Because it is fragment encoded some people call that implicit.   That is not what we are trying to stop.
>>
>> In some cases in that flow there may be distributed claims returned with access Token inside the id_token.    I think most people would agree that those should be pop or sender constrained tokens.
>>
>> In the case of self issued the RP would be a server and could do sender constrained via some mechinisim that is yet to be defined.
>>
>> So if someone wanted to return a access token in a id_token to do distributed claims I don't think we have a problem with that as long as the token is protected by being sender constrained in some reasonable way.
>>
>> This is a touch hypothetical from the basic OAuth perspective, so I don't know how deep we want to go into it.
>>
>> I think the point is not to accidently prohibit something that could be done in future.
>>
>> I also think we should not conflate confidential clients that can authenticate to the token endpoint with sender constrained/PoP clients that can deal with bound tokens.   Yes both have keys but it is better to describe them separately.
>>
>> John B.
>>
>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab > Hi Nat,
>>
>> I understand you are saying your draft could provide clients with an application level mechanism to sender constrain access tokens. That’s great!
>>
>> But I don’t see a binding to response type „token id_token“. Why do you want to expose the tokens via the URL to attackers?
>>
>> You could easily use your mechanism with code. That would also give you the chance to really authenticate the confidential client before you issue the token.
>>
>> kind regards,
>> Torsten.
>>
>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
>>>
>>> I am not talking about SPA.
>>> The client is a regular confidential client that is running on a server.
>>>
>>> Best,
>>>
>>> Nat Sakimura
>>>
>>>
>>> 2018å¹´11月27æ—¥(ç«) 16:55 Jim Manico :
>>> Nat,
>>>
>>> How is proof of possession established in a modern web browser in the implicit flow?
>>>
>>> My understanding is that token binding was removed from Chrome recently effectively killing browser-based PoP tokens.
>>>
>>> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>>>
>>> Am I missing something?
>>>
>>> Aloha, Jim
>>>
>>>
>>>
>>> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>>>> I am actually -1.
>>>>
>>>> +1 for public client and the tokens that are not sender/key constrained.
>>>>
>>>> Just not being used right now does not mean that it is not useful.. In fact, I see it coming.
>>>> Implicit (well, Hybrid “token id_token†really) is very useful in certain cases.
>>>> Specifically, when the client is confidential (based on public key pair), and uses sender constrained (key-constrained) token such as the one explained in https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is very useful.
>>>> (Key-constrained token is the remaining portion of this draft that did not get incorporated in the MTLS draft. )
>>>> In fact it is the only viable method for Self-Issued OpenID Provider.
>>>>
>>>> So, the text is generally good but it needs to be constrained like “Unless the client is confidential and the access token issued is key constrained, ... “
>>>>
>>>> Best,
>>>>
>>>> Nat Sakimura
>>>>
>>>>
>>>> 2018å¹´11月27æ—¥(ç«) 16:01 Vladimir Dzhuvinov :
>>>> +1 to recommend the deprecation of implicit.
>>>>
>>>> I don't see a compelling reason to keep implicit when there is an
>>>> established alternative that is more secure.
>>>>
>>>> Our duty as WG is to give developers the best and most sensible practice.
>>>>
>>>> CORS adoption is currently at 94% according to
>>>> https://caniuse.com/#feat=cors
>>>>
>>>> Vladimir
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> -- 
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat..sakimura.org/
>>>> @_nat_en
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> -- 
>>> Jim Manico
>>> Manicode Security
>>>
>>> https://www.manicode.com
>>> -- 
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab


From nobody Tue Nov 27 12:54:40 2018
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 9D40F130DC9 for ; Tue, 27 Nov 2018 12:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.959
X-Spam-Level: 
X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 LlsZvYjwYwmz for ; Tue, 27 Nov 2018 12:54:30 -0800 (PST)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B07A130934 for ; Tue, 27 Nov 2018 12:54:30 -0800 (PST)
Received: by mail-it1-x134.google.com with SMTP id h193so737746ita.5 for ; Tue, 27 Nov 2018 12:54:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M+9S2E0aPpbTTsG0W8I2YPQ+TilDV0y/mzsH6d5YjzQ=; b=prG06/2h5VK80mKhcvNuvX3zbrYITxOVXln5rTtoZNdZsnlCozb9kGkXtv760u/cmS fSPBK/WfT1fkUf1EJlvAnktPHiSOFH5vctT/OMsQP1h1fSfxJn+lGiAK59M/fdh/YKjW hICZBFFl/1dWCkXfibRzQnev97aIvvPQ9z7bfPVpkIdFVdRxJ3xmAX0MJCua/NPj56Oc ThZ5X8eaaFS2e0r3XkdfwCr7D4uZdGDKIvZqBU6f65m5QecKaGohwGoAYtMzkD5vShPB 8b6NPBU8AdZjpdmNmzQm8teA0yBgWUHPTKzPsrAqeuvvvYl43kFXo/O+VbYAxMUu4Iid y3Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M+9S2E0aPpbTTsG0W8I2YPQ+TilDV0y/mzsH6d5YjzQ=; b=Ejs5Z2ddPTqfr0bBkww5a80DQqlSWO5+Yz9V1/SsezGP3AtCTOXE9IVPDg7HWD5Ujg ODZbGjwqHZFMGYTxmLC8eUNlDcWA+WnyU/UCl2DmnZdMnjEDolGSQIY8viQ8UsbhHcNC 2HgYOxQeMKN5dOh/5FNIwBZm+ATQN+xb6ZGYKrrXicSkzuiPeShx9WMYE9FoQUWNSwdv OU75I0Kk2bJv2sP/SjwZh+qdmbA9v193SP0M0Rkf634+x/hVT75a6PvkE4+ncRH/iKKX Y/lR7JWFzA8J+7tQt8ExdksGjgoBCZo4+jd9HN1xQywS6udduAj4RW/ieW6I9JD7Xcpu YQIQ==
X-Gm-Message-State: AA+aEWaNmBl64K2ts+837i+uUN698l9zT//Y2JAZMHiY9AcxMTLewUCi s33/EQ1pz/h0rR84FBKgs6XkMSEdknODMoobsae4wA==
X-Google-Smtp-Source: AFSGD/V6kXV6Jc2POPJj1yG8+rNI/yjRwj9DBHDq/GOZvQTRDcuHhXin07S/kgHQdsJrPEDq/29O5xfzX18OxlX10HQ=
X-Received: by 2002:a24:6254:: with SMTP id d81mr511115itc.162.1543352069112;  Tue, 27 Nov 2018 12:54:29 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a6b:5102:0:0:0:0:0 with HTTP; Tue, 27 Nov 2018 12:54:07 -0800 (PST)
In-Reply-To: <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com>
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>   <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com>
From: William Denniss 
Date: Tue, 27 Nov 2018 12:54:07 -0800
Message-ID: 
To: "Artifact Binding/Connect Working Group" 
Cc: Torsten Lodderstedt , John Bradley , oauth ,  Jim Manico 
Content-Type: multipart/alternative; boundary="000000000000d84dad057baba74e"
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 20:54:39 -0000

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

In BCP 212 we currently recommend against using implicit flow for native
apps (Section 8.2), due to the inability to protect against interception
with PKCE. AppAuth iOS & Android don't implement it, and the JS version
didn't initially although it was requested by users who needed to do
implicit auth and was eventually supported.

To me the usefulness of implicit on the web is limited, as the code flow
can be used for public clients anyway. The one place I've seen implicit
come up in discussions was for situations where reducing complexity for
third-party developers who needed to implement an OAuth server was a high
priority (one less endpoint to implement).

+1 to have language recommending against the use in most cases (without
needing to exclude Nat's use-case). The code flow has better security
properties, and reducing optionality in the spec reduces the surface area
and simplifies implementations.


On Tue, Nov 27, 2018 at 12:36 PM, John Bradley via Openid-specs-ab <
openid-specs-ab@lists.openid.net> wrote:

> I understand that, but hat is Nat's concern as I understand it.
>
> When we say no implicit people, have a problem because implicit is
> imprecise.
>
> We are saying no AT returned in the response from the authorization
> endpoint.
>
> Nat points out that id_token may contain AT for the self issued client.
>
> So unless we say that is OK if the AT are sender constrained we wind up
> implying that a OpenID profile of OAuth is in violation of the BCP.
>
> I am just trying to make sure everyone is on the same page with why Nat
> was -1.
>
> It really has nothing to do with the SPA use case.
>
> John B.
>
>
> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>
>> Hi John,
>>
>> as you said, self issued IDPs (https://openid.net/specs/open
>> id-connect-core-1_0.html#SelfIssued) are supposed to provide the
>> response type =E2=80=9Eid_token=E2=80=9C only. I don=E2=80=99t think the=
 proposal being discussed
>> here is related to this OIDC mode.
>>
>> best regards,
>> Torsten.
>>
>> Am 27.11.2018 um 20:54 schrieb John Bradley :
>>>
>>> I talked to Nat about this a bit today.
>>>
>>> The thing he is concerned about is mostly around the self issued IDP
>>> that doesn't have a token endpoint(atleast not easaly).
>>>
>>> The main use case for that is the id_token response type where claims
>>> are retuned in the id_token.
>>>
>>> Because it is fragment encoded some people call that implicit.   That i=
s
>>> not what we are trying to stop.
>>>
>>> In some cases in that flow there may be distributed claims returned wit=
h
>>> access Token inside the id_token.    I think most people would agree th=
at
>>> those should be pop or sender constrained tokens.
>>>
>>> In the case of self issued the RP would be a server and could do sender
>>> constrained via some mechinisim that is yet to be defined.
>>>
>>> So if someone wanted to return a access token in a id_token to do
>>> distributed claims I don't think we have a problem with that as long as=
 the
>>> token is protected by being sender constrained in some reasonable way.
>>>
>>> This is a touch hypothetical from the basic OAuth perspective, so I
>>> don't know how deep we want to go into it.
>>>
>>> I think the point is not to accidently prohibit something that could be
>>> done in future.
>>>
>>> I also think we should not conflate confidential clients that can
>>> authenticate to the token endpoint with sender constrained/PoP clients =
that
>>> can deal with bound tokens.   Yes both have keys but it is better to
>>> describe them separately.
>>>
>>> John B.
>>>
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
>>> openid-specs-ab@lists.openid.net wrote:
>>> Hi Nat,
>>>
>>> I understand you are saying your draft could provide clients with an
>>> application level mechanism to sender constrain access tokens. That=E2=
=80=99s great!
>>>
>>> But I don=E2=80=99t see a binding to response type =E2=80=9Etoken id_to=
ken=E2=80=9C. Why do you
>>> want to expose the tokens via the URL to attackers?
>>>
>>> You could easily use your mechanism with code. That would also give you
>>> the chance to really authenticate the confidential client before you is=
sue
>>> the token.
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
>>>>
>>>> I am not talking about SPA.
>>>> The client is a regular confidential client that is running on a serve=
r.
>>>>
>>>> Best,
>>>>
>>>> Nat Sakimura
>>>>
>>>>
>>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico :
>>>> Nat,
>>>>
>>>> How is proof of possession established in a modern web browser in the
>>>> implicit flow?
>>>>
>>>> My understanding is that token binding was removed from Chrome recentl=
y
>>>> effectively killing browser-based PoP tokens.
>>>>
>>>> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind=
/
>>>>
>>>> Am I missing something?
>>>>
>>>> Aloha, Jim
>>>>
>>>>
>>>>
>>>> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>>>>
>>>>> I am actually -1.
>>>>>
>>>>> +1 for public client and the tokens that are not sender/key
>>>>> constrained.
>>>>>
>>>>> Just not being used right now does not mean that it is not useful.. I=
n
>>>>> fact, I see it coming.
>>>>> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is ve=
ry useful in
>>>>> certain cases.
>>>>> Specifically, when the client is confidential (based on public key
>>>>> pair), and uses sender constrained (key-constrained) token such as th=
e one
>>>>> explained in https://tools.ietf.org/html/dr
>>>>> aft-sakimura-oauth-jpop-04#section-5, it is very useful.
>>>>> (Key-constrained token is the remaining portion of this draft that di=
d
>>>>> not get incorporated in the MTLS draft. )
>>>>> In fact it is the only viable method for Self-Issued OpenID Provider.
>>>>>
>>>>> So, the text is generally good but it needs to be constrained like
>>>>> =E2=80=9CUnless the client is confidential and the access token issue=
d is key
>>>>> constrained, ... =E2=80=9C
>>>>>
>>>>> Best,
>>>>>
>>>>> Nat Sakimura
>>>>>
>>>>>
>>>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvin=
ov :
>>>>> +1 to recommend the deprecation of implicit.
>>>>>
>>>>> I don't see a compelling reason to keep implicit when there is an
>>>>> established alternative that is more secure.
>>>>>
>>>>> Our duty as WG is to give developers the best and most sensible
>>>>> practice.
>>>>>
>>>>> CORS adoption is currently at 94% according to
>>>>> https://caniuse.com/#feat=3Dcors
>>>>>
>>>>> Vladimir
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> --
>>>>> Nat Sakimura (=3Dnat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat..sakimura.org/
>>>>> @_nat_en
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> --
>>>> Jim Manico
>>>> Manicode Security
>>>>
>>>> https://www.manicode.com
>>>> --
>>>> Nat Sakimura (=3Dnat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab@lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

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


    In BCP 212 we currently recommend ag=
ainst using implicit flow for native apps (Section 8.2), due to the inabili=
ty to protect against interception with PKCE. AppAuth iOS & Android don=
't implement it, and the JS version didn't initially although it wa=
s requested by users who needed to do implicit auth and was eventually supp=
orted.

    To me the usefulness of implicit on the web=
 is limited, as the code flow can be used for public clients anyway. The on=
e place I've seen implicit come up in discussions was for situations wh=
ere reducing complexity for third-party developers who needed to implement =
an OAuth server was a high priority (one less endpoint to implement).
    =


    +1 to have language recommending against the use in mos=
t cases (without needing to exclude Nat's use-case). The code flow has =
better security properties, and reducing optionality in the spec reduces th=
e surface area and simplifies implementations.


    On Tue, Nov 27, 201=
8 at 12:36 PM, John Bradley via Openid-specs-ab <openid-spe=
cs-ab@lists.openid.net> wrote:
    I understand that, but hat is Nat's concern as I understand it=
.
    

    
When we say no implicit people, have a problem because implicit is imprecis=
e.
    

    
We are saying no AT returned in the response from the authorization endpoin=
t.
    

    
Nat points out that id_token may contain AT for the self issued client.
    

    
So unless we say that is OK if the AT are sender constrained we wind up imp=
lying that a OpenID profile of OAuth is in violation of the BCP.
    

    
I am just trying to make sure everyone is on the same page with why Nat was=
 -1.
    

    
It really has nothing to do with the SPA use case.
    

    
John B.

    

    
On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
    

    
Hi John,
    

    
as you said, self issued IDPs (https=
://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) =
are supposed to provide the response type =E2=80=9Eid_token=E2=80=9C only. =
I don=E2=80=99t think the proposal being discussed here is related to this =
OIDC mode.
    

    
best regards,
    
Torsten.
    

    

    
Am 27.11.2018 um 20:54 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    

    
I talked to Nat about this a bit today.
    

    
The thing he is concerned about is mostly around the self issued IDP that d=
oesn't have a token endpoint(atleast not easaly).
    

    
The main use case for that is the id_token response type where claims are r=
etuned in the id_token.
    

    
Because it is fragment encoded some people call that implicit.=C2=A0 =C2=A0=
That is not what we are trying to stop.
    

    
In some cases in that flow there may be distributed claims returned with ac=
cess Token inside the id_token.=C2=A0 =C2=A0 I think most people would agre=
e that those should be pop or sender constrained tokens.
    

    
In the case of self issued the RP would be a server and could do sender con=
strained via some mechinisim that is yet to be defined.
    

    
So if someone wanted to return a access token in a id_token to do distribut=
ed claims I don't think we have a problem with that as long as the toke=
n is protected by being sender constrained in some reasonable way.
    

    
This is a touch hypothetical from the basic OAuth perspective, so I don'=
;t know how deep we want to go into it.
    

    
I think the point is not to accidently prohibit something that could be don=
e in future.
    

    
I also think we should not conflate confidential clients that can authentic=
ate to the token endpoint with sender constrained/PoP clients that can deal=
 with bound tokens.=C2=A0 =C2=A0Yes both have keys but it is better to desc=
ribe them separately.
    

    
John B.
    

    
On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <<=
a href=3D"mailto:openid-specs-ab@lists.openid.net" target=3D"_blank">openid=
-specs-ab@lists.openid.net wrote:
    
Hi Nat,
    

    
I understand you are saying your draft could provide clients with an applic=
ation level mechanism to sender constrain access tokens. That=E2=80=99s gre=
at!
    

    
But I don=E2=80=99t see a binding to response type =E2=80=9Etoken id_token=
=E2=80=9C. Why do you want to expose the tokens via the URL to attackers?

    
You could easily use your mechanism with code. That would also give you the=
 chance to really authenticate the confidential client before you issue the=
 token.
    

    
kind regards,
    
Torsten.
    

    

    
Am 27.11.2018 um 16:57 schrieb Nat Sakimura <sakimura@gmail.com>:
    

    
I am not talking about SPA.
    
The client is a regular confidential client that is running on a server.

    
Best,
    

    
Nat Sakimura
    

    

    
2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico <jim@manicode.com>:
Nat,
    

    
How is proof of possession established in a modern web browser in the impli=
cit flow?
    

    
My understanding is that token binding was removed from Chrome recently eff=
ectively killing browser-based PoP tokens.
    

    
https://identiverse.com/2018/=
10/31/chrome-puts-token-binding-in-a-bind/
    

    
Am I missing something?
    

    
Aloha, Jim
    

    

    

    
On 11/27/18 9:00 PM, Nat Sakimura wrote:
    

    
I am actually -1.
    

    
+1 for public client and the tokens that are not sender/key constrained.

    
Just not being used right now does not mean that it is not useful.. In fact=
, I see it coming.
    
Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is very use=
ful in certain cases.
    
Specifically, when the client is confidential (based on public key pair), a=
nd uses sender constrained (key-constrained) token such as the one explaine=
d in https://tools.ietf.org/html/d=
raft-sakimura-oauth-jpop-04#section-5, it is very useful.
    
(Key-constrained token is the remaining portion of this draft that did not =
get incorporated in the MTLS draft. )
    
In fact it is the only viable method for Self-Issued OpenID Provider.
    

    
So, the text is generally good but it needs to be constrained like =E2=80=
=9CUnless the client is confidential and the access token issued is key con=
strained, ... =E2=80=9C
    

    
Best,
    

    
Nat Sakimura
    

    

    
2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvinov <=
;vladimir@conn=
ect2id.com>:
    
+1 to recommend the deprecation of implicit.
    

    
I don't see a compelling reason to keep implicit when there is an
    
established alternative that is more secure.
    

    
Our duty as WG is to give developers the best and most sensible practice.

    
CORS adoption is currently at 94% according to
    
https://caniuse.com/#feat=3Dcors
    

    
Vladimir
    

    

    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    
-- 
    
Nat Sakimura (=3Dnat)
    
Chairman, OpenID Foundation
    
http://nat..sak=
imura.org/
    
@_nat_en
    

    

    
_______________________________________________
    
OAuth mailing list
    

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

    
-- 
    
Jim Manico
    
Manicode Security
    

    
h=
ttps://www.manicode.com
    
-- 
    
Nat Sakimura (=3Dnat)
    
Chairman, OpenID Foundation
    
h=
ttp://nat.sakimura.org/
    
@_nat_en
    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    

    
_______________________________________________
    
Openid-specs-ab mailing list
    
Openi=
d-specs-ab@lists.openid.net
    
http://lists.openid.net/mailman/listinf=
o/openid-specs-ab
    

    
_______________________________________________
    
Openid-specs-ab mailing list
    
Openi=
d-specs-ab@lists.openid.net
    
http://lists.openid.net/mailman/listinf=
o/openid-specs-ab
    


    

--000000000000d84dad057baba74e--


From nobody Tue Nov 27 12:59:14 2018
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 B17BA1286E7 for ; Tue, 27 Nov 2018 12:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 ChLTkv3d1hJ5 for ; Tue, 27 Nov 2018 12:59:08 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) (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 3EEBF124D68 for ; Tue, 27 Nov 2018 12:59:08 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.126]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRkRk-000560-1v; Tue, 27 Nov 2018 21:59:04 +0100
Content-Type: multipart/signed; boundary=Apple-Mail-8D04AE3C-91ED-4A2F-B9FC-235137754D7C; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (16B92)
In-Reply-To: 
Date: Tue, 27 Nov 2018 21:59:03 +0100
Cc: Artifact Binding/Connect Working Group ,  John Bradley , oauth , Jim Manico 
Content-Transfer-Encoding: 7bit
Message-Id: <9D414C6D-A83D-48A3-B718-96DE04B7F2B6@lodderstedt.net>
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>   <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com> 
To: William Denniss 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 20:59:11 -0000

--Apple-Mail-8D04AE3C-91ED-4A2F-B9FC-235137754D7C
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


> Am 27.11.2018 um 21:54 schrieb William Denniss :
>=20
> +1 to have language recommending against the use in most cases (without ne=
eding to exclude Nat's use-case).

Can you (or someone else) propose text?=

--Apple-Mail-8D04AE3C-91ED-4A2F-B9FC-235137754D7C
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBT4w
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MYIDyjCCA8YCAQEwga0wgZcxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQME
AgEFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTI3
MjA1OTAzWjAvBgkqhkiG9w0BCQQxIgQgpVAL6VCcFnSe5fiwWXCeNYK4owZwrQCwlQ/po9nIBrow
gb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEB
AQUABIIBALdjePw4s45JGM3oXFTapfe2yHl12+WFuYeEWeUhOGAfz93UrhmTbBlJSyfp312bT+61
CewwBW7oxB+/BFQmaqkD8Tab6K8ukYpW+vADXnw/Ay4ZtfbjX4XgHIyoBjW7h7Dw5Xbza+XtLWJi
HxazrZ1jFRWmO8PglfwYz9i+YOSKZMwjCPAGBF6P9BTj0ow4wVgJ4ZxopaP+FFQWTzAi+DANSvkj
nIMnTEyzP486a8yM+nNJpWd4dLfn/ZQr+tXSVawpSafvpt1g9bfz/6LTwqI6gFn2/qDtY09fD69B
KQOJ0fwevE1O00DXPUXNzbzPidgEHt9nXr3DfEmGxSQShhAAAAAAAAA=

--Apple-Mail-8D04AE3C-91ED-4A2F-B9FC-235137754D7C--


From nobody Tue Nov 27 13:03:38 2018
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 53C85130DF4 for ; Tue, 27 Nov 2018 13:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ViQuMi-8QG-D for ; Tue, 27 Nov 2018 13:03:33 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) (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 B3521130DCF for ; Tue, 27 Nov 2018 13:03:33 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.126]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRkW1-0000S1-LM; Tue, 27 Nov 2018 22:03:29 +0100
Content-Type: multipart/signed; boundary=Apple-Mail-A89EA627-DF30-485F-B8B9-F18FDD98C549; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (16B92)
In-Reply-To: <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com>
Date: Tue, 27 Nov 2018 22:03:28 +0100
Cc: "openid-specs-ab@lists.openid.net Ab" ,  Nat Sakimura , oauth , Jim Manico 
Content-Transfer-Encoding: 7bit
Message-Id: <02FFD6C6-1EDB-460D-BB6E-7975362DD377@lodderstedt.net>
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>   <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com>
To: John Bradley 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 21:03:38 -0000

--Apple-Mail-A89EA627-DF30-485F-B8B9-F18FDD98C549
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I still don=E2=80=99t understand why the use case must be solved using a flo=
w issuing something in the front channel.=20

I would also like to take a closer look. Can you or Nat provide pointers to e=
xisting implementations?=20

> Am 27.11.2018 um 21:36 schrieb John Bradley :
>=20
> I understand that, but hat is Nat's concern as I understand it.
>=20
> When we say no implicit people, have a problem because implicit is impreci=
se.
>=20
> We are saying no AT returned in the response from the authorization endpoi=
nt.
>=20
> Nat points out that id_token may contain AT for the self issued client.
>=20
> So unless we say that is OK if the AT are sender constrained we wind up im=
plying that a OpenID profile of OAuth is in violation of the BCP.
>=20
> I am just trying to make sure everyone is on the same page with why Nat wa=
s -1.
>=20
> It really has nothing to do with the SPA use case.
>=20
> John B.
>=20
>> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>> Hi John,
>>=20
>> as you said, self issued IDPs (https://openid.net/specs/openid-connect-co=
re-1_0.html#SelfIssued) are supposed to provide the response type =E2=80=9Ei=
d_token=E2=80=9C only. I don=E2=80=99t think the proposal being discussed he=
re is related to this OIDC mode.
>>=20
>> best regards,
>> Torsten.
>>=20
>>> Am 27.11.2018 um 20:54 schrieb John Bradley :
>>>=20
>>> I talked to Nat about this a bit today.
>>>=20
>>> The thing he is concerned about is mostly around the self issued IDP tha=
t doesn't have a token endpoint(atleast not easaly).
>>>=20
>>> The main use case for that is the id_token response type where claims ar=
e retuned in the id_token.
>>>=20
>>> Because it is fragment encoded some people call that implicit.   That is=
 not what we are trying to stop.
>>>=20
>>> In some cases in that flow there may be distributed claims returned with=
 access Token inside the id_token.    I think most people would agree that t=
hose should be pop or sender constrained tokens.
>>>=20
>>> In the case of self issued the RP would be a server and could do sender c=
onstrained via some mechinisim that is yet to be defined.
>>>=20
>>> So if someone wanted to return a access token in a id_token to do distri=
buted claims I don't think we have a problem with that as long as the token i=
s protected by being sender constrained in some reasonable way.
>>>=20
>>> This is a touch hypothetical from the basic OAuth perspective, so I don'=
t know how deep we want to go into it.
>>>=20
>>> I think the point is not to accidently prohibit something that could be d=
one in future.
>>>=20
>>> I also think we should not conflate confidential clients that can authen=
ticate to the token endpoint with sender constrained/PoP clients that can de=
al with bound tokens.   Yes both have keys but it is better to describe them=
 separately.
>>>=20
>>> John B.
>>>=20
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab >> Hi Nat,
>>>=20
>>> I understand you are saying your draft could provide clients with an app=
lication level mechanism to sender constrain access tokens. That=E2=80=99s g=
reat!
>>>=20
>>> But I don=E2=80=99t see a binding to response type =E2=80=9Etoken id_tok=
en=E2=80=9C. Why do you want to expose the tokens via the URL to attackers?
>>>=20
>>> You could easily use your mechanism with code. That would also give you t=
he chance to really authenticate the confidential client before you issue th=
e token.
>>>=20
>>> kind regards,
>>> Torsten.
>>>=20
>>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
>>>>=20
>>>> I am not talking about SPA.
>>>> The client is a regular confidential client that is running on a server=
.
>>>>=20
>>>> Best,
>>>>=20
>>>> Nat Sakimura
>>>>=20
>>>>=20
>>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico :
>>>> Nat,
>>>>=20
>>>> How is proof of possession established in a modern web browser in the i=
mplicit flow?
>>>>=20
>>>> My understanding is that token binding was removed from Chrome recently=
 effectively killing browser-based PoP tokens.
>>>>=20
>>>> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/=

>>>>=20
>>>> Am I missing something?
>>>>=20
>>>> Aloha, Jim
>>>>=20
>>>>=20
>>>>=20
>>>>> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>>>>> I am actually -1.
>>>>>=20
>>>>> +1 for public client and the tokens that are not sender/key constraine=
d.
>>>>>=20
>>>>> Just not being used right now does not mean that it is not useful.. In=
 fact, I see it coming.
>>>>> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is ver=
y useful in certain cases.
>>>>> Specifically, when the client is confidential (based on public key pai=
r), and uses sender constrained (key-constrained) token such as the one expl=
ained in https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5,=
 it is very useful.
>>>>> (Key-constrained token is the remaining portion of this draft that did=
 not get incorporated in the MTLS draft. )
>>>>> In fact it is the only viable method for Self-Issued OpenID Provider.
>>>>>=20
>>>>> So, the text is generally good but it needs to be constrained like =E2=
=80=9CUnless the client is confidential and the access token issued is key c=
onstrained, ... =E2=80=9C
>>>>>=20
>>>>> Best,
>>>>>=20
>>>>> Nat Sakimura
>>>>>=20
>>>>>=20
>>>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuvino=
v :
>>>>> +1 to recommend the deprecation of implicit.
>>>>>=20
>>>>> I don't see a compelling reason to keep implicit when there is an
>>>>> established alternative that is more secure.
>>>>>=20
>>>>> Our duty as WG is to give developers the best and most sensible practi=
ce.
>>>>>=20
>>>>> CORS adoption is currently at 94% according to
>>>>> https://caniuse.com/#feat=3Dcors
>>>>>=20
>>>>> Vladimir
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> --=20
>>>>> Nat Sakimura (=3Dnat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat..sakimura.org/
>>>>> @_nat_en
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> --=20
>>>> Jim Manico
>>>> Manicode Security
>>>>=20
>>>> https://www.manicode.com
>>>> --=20
>>>> Nat Sakimura (=3Dnat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab@lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab

--Apple-Mail-A89EA627-DF30-485F-B8B9-F18FDD98C549
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBT4w
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MYIDyjCCA8YCAQEwga0wgZcxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQME
AgEFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTI3
MjEwMzI4WjAvBgkqhkiG9w0BCQQxIgQghj3gWSF6P+L8L9cQWoIbhqh21VvVCo2ZSPzz3mgcOkYw
gb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEB
AQUABIIBAF76yPhlYmjt+OkRD7mv2+h83hyOxePQk5SyAR3nLUj98rFrNbl3c8VA8Dc2kpfDo5Wb
zb9rNF0GCXF97F5Peut/8tmxtqg3iOsaRAsnhwurH9PcX4z+T600GrY+iLmB4ScJzLcC+6iEt63F
hsir0rTgyv3+yRx4ojxfKGabocIC1IF3mpFKuDeCY8OnJHKhqdtdJpTgo1a9QBXScfiEuIOQV3BJ
f+N3W9YR+slSd6YU00laKBikMplffMnxuuINSe7E5Fk3o2DvNLCoj3spUn7oWs9SPm5pY4XWjdDE
WCok5rnn5U8JxCQzERiBEUxLr0/YonIcJrak59cGFBOhU+kAAAAAAAA=

--Apple-Mail-A89EA627-DF30-485F-B8B9-F18FDD98C549--


From kristian.antic@gmail.com  Tue Nov 27 00:03:26 2018
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 29A00128CB7 for ; Tue, 27 Nov 2018 00:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 m2iR-i10ffJv for ; Tue, 27 Nov 2018 00:03:25 -0800 (PST)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 D9277127133 for ; Tue, 27 Nov 2018 00:03:21 -0800 (PST)
Received: by mail-ua1-x92e.google.com with SMTP id n7so7287797uao.7 for ; Tue, 27 Nov 2018 00:03:21 -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=ITkvwZvGJDw3+j66OZ1j7gdEVL/SDuztjTwN8/ot+fQ=; b=TxnyZYCYkWOcNkdrS25qHxyvNvoVUfntk/7i+oRpPGOn5U+yMgTRPrW4H+9lUqJ9uD 9F3LZARMbQwbhCBf8PFckNhl4q6GgPn5nx2D0NZQH4abBFuuW6w0HRh5Am6EEIQSg2FD 2QNDcS8LVKh+99zJKAV1Ak29soTEu5s7LPUULQDir87+fNks3m9kfrPpOMlqNdJrMiGv Y4Pdhbx3JC9iiuSk3Nf6M99j2+4i2vKZxsRqbRE5OJqKYTXqo0kOpVTPTdBabWZoLlWR PIe3I6PzWbSAYIFvHo9Q5THxQIDqKhB3cM7vX6HRhFPES2XNzQx1ImgGL3JQb3Mj+7uR s20w==
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=ITkvwZvGJDw3+j66OZ1j7gdEVL/SDuztjTwN8/ot+fQ=; b=YKB23oFqwgc7xylk7ndcwXfg92VlAjbxycrrfbipXQdIsol1O87Dn8yIyXkkH5lcwl F/s4+NsIG3eOnHyW5olk+UO4kcamIQ/RAXpxxJsHLMkDtacW46hlp8ASgFe5lt45yZxL KSpszrbqVj4KnbgPg4CrSeUXK0AnZrfuGGA//0HQX8x0110ZDjBhGppbwkh4GYZq/wSZ pg0y3jrh47A22jS12GYbxpUfB7lYtP5EARihVQCR6dwj8Q9ErK8xf3/3W3FUXit4Ijte eO9tycJuSDCcs+now6nCRt3dxy5TJBnru/xFRwauqr6t2gqbVOo9q1nqVMAlup5D5aI/ h2JQ==
X-Gm-Message-State: AA+aEWYNuhxbL6xLhNm+TmgyzozLByaNVbv8W1+Obl1xBZSWjiaFCVvh pcKnmyZrPgOtw0qyG6iz49X1zYOZ43ehKlkLGsR9/w==
X-Google-Smtp-Source: AFSGD/WnaBp+eMLkwXxJYqe1QANXye/fXGMkwTmPrRHqB2z3xQVQunmd/XHZ0ObilsouB1nuB3t5V+KldbFqmcewifM=
X-Received: by 2002:ab0:3111:: with SMTP id e17mr13100646ual.61.1543305800293;  Tue, 27 Nov 2018 00:03:20 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a67:8097:0:0:0:0:0 with HTTP; Tue, 27 Nov 2018 00:03:19 -0800 (PST)
From: Kristian Antic 
Date: Tue, 27 Nov 2018 08:03:19 +0000
Message-ID: 
To: OAuth@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [OAUTH-WG] Remark on OAuth 2.0 Device Flow name
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, 27 Nov 2018 21:04:03 -0000

Dear all,

I've been working through the OAuth 2.0 Device Flow spec since early
draft versions
and noticed the name change in draft-ietf-oauth-device-flow-04.

As the OAuth 2.0 Device flow is an OAuth 2.0 authorization grant/OAuth
2.0 extension grant, I always wonder why it is called OAuth 2.0 Device
flow.

Could you tell me why you called it OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices and not OAuth 2.0 Device
Grant for Browserless and Input Constrained Devices?

>From my point of view this would better fit into the naming scheme of
the OAuth 2.0 framework.

Best regards,

Kristian


From nobody Tue Nov 27 14:58:23 2018
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 9ACE912D4ED for ; Tue, 27 Nov 2018 14:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 3l4x24d7b0lI for ; Tue, 27 Nov 2018 14:58:18 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 22D36128CFD for ; Tue, 27 Nov 2018 14:58:18 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id 96so24425060wrb.2 for ; Tue, 27 Nov 2018 14:58:18 -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=+j9jhjxIn78H7NxCS87pSn9/d3J9625AslzxWj8SnPk=; b=kxNTqW3MqbLdc/PsX9Krjlt8DiLIGmUwRbd6rklTXXWvlajoS9CSQ9teD4YCF4rMor ClqshovEVpcL/J/0RC7bL/g83zApBSbpxGf03kdph0vUSto4lPrp5Z9TTDHtKhAfZEpw vDjBvwHpXoFF/alPXo2Z5tm/2pofqXuUS7if3gL2A7CZ5f4vNmGctwJZZ4TPmT+wj7DG 0zlbU19gEux4PHLAAXQp3QM0ncNuFzxjSbqcOAt16qRLSxDv8/08/MPxW5BVmspg6qtv KW4GfaHabqijPYxiZbkF6ESOhw0ct0+7emegEclv5Hs/ma1wEz5+ekXPBdgGmkGmz5za WXzw==
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=+j9jhjxIn78H7NxCS87pSn9/d3J9625AslzxWj8SnPk=; b=RDlimWXFCU8jCtmmNaJRTRCZH8toBOjhzaLa9vibrVVw0cou3Ur8ap7m8S0JEtH3N2 TlQYsWniD6pcirqDqt034liLPDIMuN4p/iChb8641IxBGTqYEXKMUE9KTarONS5f9HiZ pHYA0QfEemFXIsNRW/Cs7CMq+nA0SWhluJGvh21HRs8Xvu912bT2knp8r4OuHbArmr+V jAlmpZiATn4m7ugUz8kP1yQoxBHOPaYmraNQ+c5xssdD8Swl22bKCwYfAkSEpfCk1Yq+ 3qWHmdbAQUvaJCF63wJFdJtTSZrj1Y5GGDB1Xu4wNV+SAp/0o7X7rz0alR8zan3FPBBI bI7g==
X-Gm-Message-State: AA+aEWZ1GK8LS0IF43o68qg27N25XvzielGNjowGt4kzXkJXAtlrMQ0R KTbGe7/PIUbdftGp9/LSP06jAL7O5DOXTOCcSQWuQ69g
X-Google-Smtp-Source: AFSGD/WYstO6TZjHwmJMUTsI9rAS72MthPQ6agSsTgV6EWUtWLc59jmWJ3m+bJPxDrn21gH12coAhz2ot+YfBO0VViU=
X-Received: by 2002:a05:6000:1c8:: with SMTP id t8mr30137962wrx.146.1543359496099;  Tue, 27 Nov 2018 14:58:16 -0800 (PST)
MIME-Version: 1.0
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>   <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com> <02FFD6C6-1EDB-460D-BB6E-7975362DD377@lodderstedt.net>
In-Reply-To: <02FFD6C6-1EDB-460D-BB6E-7975362DD377@lodderstedt.net>
From: Nat Sakimura 
Date: Wed, 28 Nov 2018 07:58:04 +0900
Message-ID: 
To: Torsten Lodderstedt 
Cc: John Bradley ,  "openid-specs-ab@lists.openid.net Ab" , oauth , Jim Manico 
Content-Type: multipart/alternative; boundary="000000000000869cb2057bad6217"
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 22:58:22 -0000

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

Self Issued OP is described in Chapter 7 of the OpenID Connect Core 1.0.
It lives on a local machine, typically a phone. Even if it did provide an
authorization code to the client, the client cannot establish a direct
connection to the local machine (phone) as it is not addressable.
Therefore, a token endpoint cannot be provided unless it is coupled with
some kind of cloud-based service, which would negate some of the very
reason for having the Self-issued OP. In other words, only the viable
communication channel between the SIOP and the client is the front channel.
The situation could be true to other "wallet" type of implementations.

This is one of the exotic features of OpenID Connect that never got a
traction but it is getting a renewed interest as "Self-sovereign Identity"
gained some interest.



On Wed, Nov 28, 2018 at 6:03 AM Torsten Lodderstedt 
wrote:

> I still don=E2=80=99t understand why the use case must be solved using a =
flow
> issuing something in the front channel.
>
> I would also like to take a closer look. Can you or Nat provide pointers
> to existing implementations?
>
> > Am 27.11.2018 um 21:36 schrieb John Bradley :
> >
> > I understand that, but hat is Nat's concern as I understand it.
> >
> > When we say no implicit people, have a problem because implicit is
> imprecise.
> >
> > We are saying no AT returned in the response from the authorization
> endpoint.
> >
> > Nat points out that id_token may contain AT for the self issued client.
> >
> > So unless we say that is OK if the AT are sender constrained we wind up
> implying that a OpenID profile of OAuth is in violation of the BCP.
> >
> > I am just trying to make sure everyone is on the same page with why Nat
> was -1.
> >
> > It really has nothing to do with the SPA use case.
> >
> > John B.
> >
> >> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
> >> Hi John,
> >>
> >> as you said, self issued IDPs (
> https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are
> supposed to provide the response type =E2=80=9Eid_token=E2=80=9C only. I =
don=E2=80=99t think the
> proposal being discussed here is related to this OIDC mode.
> >>
> >> best regards,
> >> Torsten.
> >>
> >>> Am 27.11.2018 um 20:54 schrieb John Bradley :
> >>>
> >>> I talked to Nat about this a bit today.
> >>>
> >>> The thing he is concerned about is mostly around the self issued IDP
> that doesn't have a token endpoint(atleast not easaly).
> >>>
> >>> The main use case for that is the id_token response type where claims
> are retuned in the id_token.
> >>>
> >>> Because it is fragment encoded some people call that implicit.   That
> is not what we are trying to stop.
> >>>
> >>> In some cases in that flow there may be distributed claims returned
> with access Token inside the id_token.    I think most people would agree
> that those should be pop or sender constrained tokens.
> >>>
> >>> In the case of self issued the RP would be a server and could do
> sender constrained via some mechinisim that is yet to be defined.
> >>>
> >>> So if someone wanted to return a access token in a id_token to do
> distributed claims I don't think we have a problem with that as long as t=
he
> token is protected by being sender constrained in some reasonable way.
> >>>
> >>> This is a touch hypothetical from the basic OAuth perspective, so I
> don't know how deep we want to go into it.
> >>>
> >>> I think the point is not to accidently prohibit something that could
> be done in future.
> >>>
> >>> I also think we should not conflate confidential clients that can
> authenticate to the token endpoint with sender constrained/PoP clients th=
at
> can deal with bound tokens.   Yes both have keys but it is better to
> describe them separately.
> >>>
> >>> John B.
> >>>
> >>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab=
 <
> openid-specs-ab@lists.openid.net wrote:
> >>> Hi Nat,
> >>>
> >>> I understand you are saying your draft could provide clients with an
> application level mechanism to sender constrain access tokens. That=E2=80=
=99s great!
> >>>
> >>> But I don=E2=80=99t see a binding to response type =E2=80=9Etoken id_=
token=E2=80=9C. Why do
> you want to expose the tokens via the URL to attackers?
> >>>
> >>> You could easily use your mechanism with code. That would also give
> you the chance to really authenticate the confidential client before you
> issue the token.
> >>>
> >>> kind regards,
> >>> Torsten.
> >>>
> >>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> >>>>
> >>>> I am not talking about SPA.
> >>>> The client is a regular confidential client that is running on a
> server.
> >>>>
> >>>> Best,
> >>>>
> >>>> Nat Sakimura
> >>>>
> >>>>
> >>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim Manico :
> >>>> Nat,
> >>>>
> >>>> How is proof of possession established in a modern web browser in th=
e
> implicit flow?
> >>>>
> >>>> My understanding is that token binding was removed from Chrome
> recently effectively killing browser-based PoP tokens.
> >>>>
> >>>>
> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> >>>>
> >>>> Am I missing something?
> >>>>
> >>>> Aloha, Jim
> >>>>
> >>>>
> >>>>
> >>>>> On 11/27/18 9:00 PM, Nat Sakimura wrote:
> >>>>> I am actually -1.
> >>>>>
> >>>>> +1 for public client and the tokens that are not sender/key
> constrained.
> >>>>>
> >>>>> Just not being used right now does not mean that it is not useful..
> In fact, I see it coming.
> >>>>> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=9D really) is =
very useful in
> certain cases.
> >>>>> Specifically, when the client is confidential (based on public key
> pair), and uses sender constrained (key-constrained) token such as the on=
e
> explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
> very useful.
> >>>>> (Key-constrained token is the remaining portion of this draft that
> did not get incorporated in the MTLS draft. )
> >>>>> In fact it is the only viable method for Self-Issued OpenID Provide=
r.
> >>>>>
> >>>>> So, the text is generally good but it needs to be constrained like
> =E2=80=9CUnless the client is confidential and the access token issued is=
 key
> constrained, ... =E2=80=9C
> >>>>>
> >>>>> Best,
> >>>>>
> >>>>> Nat Sakimura
> >>>>>
> >>>>>
> >>>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 Vladimir Dzhuv=
inov :
> >>>>> +1 to recommend the deprecation of implicit.
> >>>>>
> >>>>> I don't see a compelling reason to keep implicit when there is an
> >>>>> established alternative that is more secure.
> >>>>>
> >>>>> Our duty as WG is to give developers the best and most sensible
> practice.
> >>>>>
> >>>>> CORS adoption is currently at 94% according to
> >>>>> https://caniuse.com/#feat=3Dcors
> >>>>>
> >>>>> Vladimir
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>> --
> >>>>> Nat Sakimura (=3Dnat)
> >>>>> Chairman, OpenID Foundation
> >>>>> http://nat..sakimura.org/
> >>>>> @_nat_en
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> --
> >>>> Jim Manico
> >>>> Manicode Security
> >>>>
> >>>> https://www.manicode.com
> >>>> --
> >>>> Nat Sakimura (=3Dnat)
> >>>> Chairman, OpenID Foundation
> >>>> http://nat.sakimura.org/
> >>>> @_nat_en
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>> _______________________________________________
> >>> Openid-specs-ab mailing list
> >>> Openid-specs-ab@lists.openid.net
> >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


    Self Issued OP is described in Chapter 7 of the OpenID Con=
nect Core 1.0.=C2=A0
    It lives on a local machine, typically a phone. Ev=
en if it did provide an authorization code to the client, the client cannot=
 establish a direct connection to the local machine (phone) as it is not ad=
dressable. Therefore, a=C2=A0token endpoint cannot be provided unless it is=
 coupled with some kind of cloud-based service, which would negate some of =
the very reason for having the Self-issued OP. In other words, only the via=
ble communication channel between the SIOP and the client is the front chan=
nel. The situation could be true to other "wallet" type of implem=
entations.=C2=A0

    This is one of the exotic feature=
s of OpenID Connect that never got a traction=C2=A0but it is getting a rene=
wed interest as "Self-sovereign Identity" gained some interest.=
=C2=A0



    On Wed, Nov 28, 2018 at 6:03 AM Torsten Lodderstedt &l=
t;torsten@lodderstedt.net>=
; wrote:
    I still don=E2=80=99t unde=
rstand why the use case must be solved using a flow issuing something in th=
e front channel. 
    

    
I would also like to take a closer look. Can you or Nat provide pointers to=
 existing implementations? 
    

    
> Am 27.11.2018 um 21:36 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
> 
    
> I understand that, but hat is Nat's concern as I understand it.
> 
    
> When we say no implicit people, have a problem because implicit is imp=
recise.
    
> 
    
> We are saying no AT returned in the response from the authorization en=
dpoint.
    
> 
    
> Nat points out that id_token may contain AT for the self issued client=
.
    
> 
    
> So unless we say that is OK if the AT are sender constrained we wind u=
p implying that a OpenID profile of OAuth is in violation of the BCP.
    
> 
    
> I am just trying to make sure everyone is on the same page with why Na=
t was -1.
    
> 
    
> It really has nothing to do with the SPA use case.
    
> 
    
> John B.
    
> 
    
>> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
    
>> Hi John,
    
>> 
    
>> as you said, self issued IDPs (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) a=
re supposed to provide the response type =E2=80=9Eid_token=E2=80=9C only. I=
 don=E2=80=99t think the proposal being discussed here is related to this O=
IDC mode.
    
>> 
    
>> best regards,
    
>> Torsten.
    
>> 
    
>>> Am 27.11.2018 um 20:54 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
>>> 
    
>>> I talked to Nat about this a bit today.
    
>>> 
    
>>> The thing he is concerned about is mostly around the self issu=
ed IDP that doesn't have a token endpoint(atleast not easaly).
    
>>> 
    
>>> The main use case for that is the id_token response type where=
 claims are retuned in the id_token.
    
>>> 
    
>>> Because it is fragment encoded some people call that implicit.=
=C2=A0 =C2=A0That is not what we are trying to stop.
    
>>> 
    
>>> In some cases in that flow there may be distributed claims ret=
urned with access Token inside the id_token.=C2=A0 =C2=A0 I think most peop=
le would agree that those should be pop or sender constrained tokens.
    
>>> 
    
>>> In the case of self issued the RP would be a server and could =
do sender constrained via some mechinisim that is yet to be defined.
    
>>> 
    
>>> So if someone wanted to return a access token in a id_token to=
 do distributed claims I don't think we have a problem with that as lon=
g as the token is protected by being sender constrained in some reasonable =
way.
    
>>> 
    
>>> This is a touch hypothetical from the basic OAuth perspective,=
 so I don't know how deep we want to go into it.
    
>>> 
    
>>> I think the point is not to accidently prohibit something that=
 could be done in future.
    
>>> 
    
>>> I also think we should not conflate confidential clients that =
can authenticate to the token endpoint with sender constrained/PoP clients =
that can deal with bound tokens.=C2=A0 =C2=A0Yes both have keys but it is b=
etter to describe them separately.
    
>>> 
    
>>> John B.
    
>>> 
    
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-s=
pecs-ab <openid-specs-ab@lists.openid.net wrote:
    
>>> Hi Nat,
    
>>> 
    
>>> I understand you are saying your draft could provide clients w=
ith an application level mechanism to sender constrain access tokens. That=
=E2=80=99s great!
    
>>> 
    
>>> But I don=E2=80=99t see a binding to response type =E2=80=9Eto=
ken id_token=E2=80=9C. Why do you want to expose the tokens via the URL to =
attackers?
    
>>> 
    
>>> You could easily use your mechanism with code. That would also=
 give you the chance to really authenticate the confidential client before =
you issue the token.
    
>>> 
    
>>> kind regards,
    
>>> Torsten.
    
>>> 
    
>>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <sakimura@gmail.com>:
>>>> 
    
>>>> I am not talking about SPA.
    
>>>> The client is a regular confidential client that is runnin=
g on a server.
    
>>>> 
    
>>>> Best,
    
>>>> 
    
>>>> Nat Sakimura
    
>>>> 
    
>>>> 
    
>>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:55 Jim M=
anico <jim@manicod=
e.com>:
    
>>>> Nat,
    
>>>> 
    
>>>> How is proof of possession established in a modern web bro=
wser in the implicit flow?
    
>>>> 
    
>>>> My understanding is that token binding was removed from Ch=
rome recently effectively killing browser-based PoP tokens.
    
>>>> 
    
>>>> https://iden=
tiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
    
>>>> 
    
>>>> Am I missing something?
    
>>>> 
    
>>>> Aloha, Jim
    
>>>> 
    
>>>> 
    
>>>> 
    
>>>>> On 11/27/18 9:00 PM, Nat Sakimura wrote:
    
>>>>> I am actually -1.
    
>>>>> 
    
>>>>> +1 for public client and the tokens that are not sende=
r/key constrained.
    
>>>>> 
    
>>>>> Just not being used right now does not mean that it is=
 not useful.. In fact, I see it coming.
    
>>>>> Implicit (well, Hybrid =E2=80=9Ctoken id_token=E2=80=
=9D really) is very useful in certain cases.
    
>>>>> Specifically, when the client is confidential (based o=
n public key pair), and uses sender constrained (key-constrained) token suc=
h as the one explained in https://=
tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is very =
useful.
    
>>>>> (Key-constrained token is the remaining portion of thi=
s draft that did not get incorporated in the MTLS draft. )
    
>>>>> In fact it is the only viable method for Self-Issued O=
penID Provider.
    
>>>>> 
    
>>>>> So, the text is generally good but it needs to be cons=
trained like =E2=80=9CUnless the client is confidential and the access toke=
n issued is key constrained, ... =E2=80=9C
    
>>>>> 
    
>>>>> Best,
    
>>>>> 
    
>>>>> Nat Sakimura
    
>>>>> 
    
>>>>> 
    
>>>>> 2018=E5=B9=B411=E6=9C=8827=E6=97=A5(=E7=81=AB) 16:01 V=
ladimir Dzhuvinov <vladimir@connect2id.com>:
    
>>>>> +1 to recommend the deprecation of implicit.
    
>>>>> 
    
>>>>> I don't see a compelling reason to keep implicit w=
hen there is an
    
>>>>> established alternative that is more secure.
    
>>>>> 
    
>>>>> Our duty as WG is to give developers the best and most=
 sensible practice.
    
>>>>> 
    
>>>>> CORS adoption is currently at 94% according to
    
>>>>> https://caniuse.com/#feat=3Dcors
    
>>>>> 
    
>>>>> Vladimir
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> OA=
uth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinf=
o/oauth
    
>>>>> -- 
    
>>>>> Nat Sakimura (=3Dnat)
    
>>>>> Chairman, OpenID Foundation
    
>>>>> http://nat..sakimura.org/
    
>>>>> @_nat_en
    
>>>>> 
    
>>>>> 
    
>>>>> _______________________________________________
    
>>>>> OAuth mailing list
    
>>>>> 
    
>>>>> OA=
uth@ietf.org
    
>>>>> https://www.ietf.org/mailman/listinf=
o/oauth
    
>>>> -- 
    
>>>> Jim Manico
    
>>>> Manicode Security
    
>>>> 
    
>>>> https://www.manicode.com
    
>>>> -- 
    
>>>> Nat Sakimura (=3Dnat)
    
>>>> Chairman, OpenID Foundation
    
>>>> http://nat.sakimura.org/
    
>>>> @_nat_en
    
>>>> _______________________________________________
    
>>>> OAuth mailing list
    
>>>> OAuth@=
ietf.org
    
>>>> https://www.ietf.org/mailman/listinfo/oa=
uth
    
>>> _______________________________________________
    
>>> Openid-specs-ab mailing list
    
>>> Openid-specs-ab@lists.openid.net
    
>>> http://lists.openid.net/mailman=
/listinfo/openid-specs-ab
    



    -- 
    Nat Sakimura =
(=3Dnat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en
    

--000000000000869cb2057bad6217--


From nobody Tue Nov 27 15:50:25 2018
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 BC4EE129C6B for ; Tue, 27 Nov 2018 15:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0D0QfQkrTjl for ; Tue, 27 Nov 2018 15:50:20 -0800 (PST)
Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B4A128CFD for ; Tue, 27 Nov 2018 15:50:19 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id D07B377F20; Wed, 28 Nov 2018 08:50:18 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 5693B4E0046; Wed, 28 Nov 2018 08:50:18 +0900 (JST)
Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wARNoI0M012477; Wed, 28 Nov 2018 08:50:18 +0900
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp with ESMTP id wARNoHt3012476; Wed, 28 Nov 2018 08:50:18 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wARNoKWW052823; Wed, 28 Nov 2018 08:50:20 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wARNoKBu052822; Wed, 28 Nov 2018 08:50:20 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wARNoK9r052819; Wed, 28 Nov 2018 08:50:20 +0900
Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM01PA.cu.nri.co.jp (172.159.253.19) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 08:50:16 +0900
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.177) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 08:50:16 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yVf2dcJruX7x6uuGJaHPRJpcxjRnlLHlN9gqJ89b+10=; b=rzdlF/ibGAO/X+6MGKFPdsxIXBUwrs7pzkGmEovovfVch2Nv/+bvAMKVSTu8KuH0Elyb5QVq3F1I9hLRDtEfXrGt02mR6AzoKRqIKn3lMkaMqXGFMJab62dUicquBz7lfPYJAov66DMv2oyzRv4igncS5TAyOey+bG7N4vtBWGg=
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB3541.jpnprd01.prod.outlook.com (20.178.96.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.15; Tue, 27 Nov 2018 23:50:15 +0000
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Tue, 27 Nov 2018 23:50:15 +0000
From: n-sakimura 
To: Artifact Binding/Connect Working Group 
CC: Tom Jones , "oauth@ietf.org" , "jim@manicode.com" 
Thread-Topic: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AQHUhmmvazGUOUu3zUW6qxGAce3IH6VjxxqAgAA7dICAAAaRgIAACXuAgAACdACAAAdoAIAAIAUAgAAE5YCAAAYKAA==
Date: Tue, 27 Nov 2018 23:50:15 +0000
Message-ID: 
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>   <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com> <02FFD6C6-1EDB-460D-BB6E-7975362DD377@lodderstedt.net>  
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailadviser: 20170719
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [37.71.28.34]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; OSBPR01MB3541; 6:g37IE7TrUNjlTaiVCAHUaSry2Xg3bCQdNvmCs3ti7flMH7j371Q13JrORp23+NBWC87/iY554sLlBcwg2iLjyDZgaYLVH71TO8qg6C/Q7XV/pXfgKR3FycmNpd7rAo7vLsGltttX7ITiOy8BFe9Dt0/H8v/6mAKL8vIfMAqBJEkqNoy03naJXA6q9Eev94EpSP+Pn318DhRShBNXZw/uxy4TrE7lksJ2N3Po2os+DMR9+rqrqDdec+U+Adhr8e3surChkpxF68PlYtayUb7hW49/AoabDeRUjUd6cfTEI3mI6060RxRQsYMQn0EIM7p90z4D3b8RRVU2Gc9rCWVeDVx2JOPcaHQBldvHSZFkLUlGZ8rSlEkV3fDdzXG/bLUxhM9f+yvs9KTQx0c4yeUQ1V79b4t434wTwDKdGtPLbzZH6A7ZT6HNmCWSY7JHhsF5jUrQPZU5PY50uX7X8qi4kA==; 5:x2SgrZWrNB4qaNNSgV5o05SERxLlXr8WI2/C+6NbMfUEZXaq6qev7OdPz3IKVyc8UgTFpmbT0wfUiTiE2ot58MnhLHhL42bcuHMX21LFSED8omIU6Fac7xdzSyW5B8J3IMClUxIOlXaEn3yCyTj5tNi6AaORK34wvYkZkZA8whE=; 7:n32l+APLK7ziJqbem7zlZ30Z1u/4jTEt1B8rG+Y4WRXC771PajHyY+r3p+QoTUG/GHItwxAhVF/JjYUXeR8oipBYgFBNHsvqP01zikkwBt62FPraCNDC8S1LwrSN9fd44U0zmX8RJ9gT7Otikh6MLA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2bbb1bb2-4827-4f6f-7137-08d654c3142d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB3541; 
x-ms-traffictypediagnostic: OSBPR01MB3541:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231443)(944501410)(4982022)(52105112)(148016)(149066)(150057)(6041310)(2016111802025)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB3541; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB3541; 
x-forefront-prvs: 086943A159
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(39840400004)(366004)(396003)(365934003)(189003)(199004)(790700001)(3846002)(6116002)(68736007)(93886005)(14454004)(561944003)(105586002)(256004)(33656002)(74316002)(39060400002)(14444005)(97736004)(6246003)(446003)(81156014)(66574009)(81166006)(54906003)(6916009)(71190400001)(71200400001)(74482002)(86362001)(966005)(508600001)(316002)(8676002)(2906002)(2420400007)(15650500001)(7110500001)(10710500007)(229853002)(4744004)(53936002)(5660300001)(102836004)(4326008)(25786009)(6506007)(53546011)(186003)(76176011)(8936002)(606006)(7696005)(99286004)(54896002)(9686003)(55016002)(7736002)(66066001)(11346002)(236005)(6306002)(53376002)(476003)(6436002)(106356001)(486006)(26005)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB3541; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xDDO3JJ1rSvqPxlI2QHZmeN6ei4a5TDindLhRNc4h1TsXD+vPbXgbR5kw34dNd4g1+Z6n24PT4WGMjJBu7dEB9kIKhXEr0jHH6LE0wdEFiXufVrM79eLu1UC1kLqiF2t3s3NLPfIceiw0fWdV3sCSGN5NV56JuGUkWeUnhGU7JnhyZmZXO+iPtdzdAumdj8EIAl89hETTowEj/Js30hhkhdp0WOhGG99Ze1ZqS+lsczhY8x1jUCw7+R9nwQUZvoCgJzTvv71Jj41CpOW0ThqZWv/A1xzZVcfTJP2d2gjKoLGM3Lg4PoJYwN4L4nYnx1CFrlvVYWBoDQPiyVEAzbTqjfaNyyFRkOUAFbCpXyS2i4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB286955E2DF450308CE63EED0F9D00OSBPR01MB2869jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bbb1bb2-4827-4f6f-7137-08d654c3142d
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2018 23:50:15.1951 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB3541
X-OrganizationHeadersPreserved: OSBPR01MB3541.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 27 Nov 2018 23:50:23 -0000

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

VG9tLA0KDQpJdCBpcyBnb29kIHRvIGhlYXIgdGhhdCB5b3Ugd2lsbCBiZSB0aGVyZS4NCkkgdW5k
ZXJzdGFuZCBKb2huIHdpbGwgYWxzbyBiZSB0aGVyZS4NCg0KVG8geW91ciBxdWVzdGlvbiwgc2Vs
Zi1pc3N1ZWQgSUQgZG9lcyBub3QgcmVxdWlyZSBhIChzZW1pLSlwZXJtYW5lbnQgVVJMIGFzIHRo
ZSB1c2Vy4oCZcyBpZGVudGlmaWVyLCBhcyBpdCBpcyBhbHdheXMg4oCcbG9jYWxob3N04oCdLg0K
VGhlIGlkZW50aWZpZXIgaXMgZGVyaXZlZCBhcyB0aGUgaGFzaCBvZiB0aGUgcHVibGljIGtleSB0
aGF0IHdhcyBnZW5lcmF0ZWQgYnkgdGhlIFNlbGYtaXNzdWVkIE9QLg0KSWYgeW91ciBxdWVzdGlv
biB3YXMg4oCcVVJJ4oCdLCB0aGVuIHllcy4gSXRzIGlzc3VlciBpcyBhbHdheXMgaHR0cHM6Ly9z
ZWxmLWlzc3VlZC5tZSBhbmQgdGhlcmUgaXMgYSBgc3ViYCBmb3IgdGhhdCBpZGVudGl0eSwgc28g
c3ludGhlc2l6ZWQgVVJJIGZvciB0aGUgdXNlciB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSBodHRw
czovL3NlbGYtaXNzdWVkLm1lL3tzdWJ9PGh0dHBzOi8vc2VsZi1pc3N1ZWQubWUvJTdic3ViJTdk
PiB3aGVyZSB7c3VifSByZXByZXNlbnRzIHRoZSB2YWx1ZSBvZiB0aGUgYHN1YmAgY2xhaW0uIGBz
dWJgIGNsYWltIHZhbHVlIGlzIGRlZmluZWQgYXMgZm9sbG93czoNCg0Kc3ViIChzdWJqZWN0KSBD
bGFpbSB2YWx1ZSBpcyB0aGUgYmFzZTY0dXJsIGVuY29kZWQgcmVwcmVzZW50YXRpb24gb2YgdGhl
IHRodW1icHJpbnQgb2YgdGhlIGtleSBpbiB0aGUgc3ViX2p3ayBDbGFpbS4gVGhpcyB0aHVtYnBy
aW50IHZhbHVlIGlzIGNvbXB1dGVkIGFzIHRoZSBTSEEtMjU2IGhhc2ggb2YgdGhlIG9jdGV0cyBv
ZiB0aGUgVVRGLTggcmVwcmVzZW50YXRpb24gb2YgYSBKV0sgY29uc3RydWN0ZWQgY29udGFpbmlu
ZyBvbmx5IHRoZSBSRVFVSVJFRCBtZW1iZXJzIHRvIHJlcHJlc2VudCB0aGUga2V5LCB3aXRoIHRo
ZSBtZW1iZXIgbmFtZXMgc29ydGVkIGludG8gbGV4aWNvZ3JhcGhpYyBvcmRlciwgYW5kIHdpdGgg
bm8gd2hpdGUgc3BhY2Ugb3IgbGluZSBicmVha3MuIEZvciBpbnN0YW5jZSwgd2hlbiB0aGUga3R5
IHZhbHVlIGlzIFJTQSwgdGhlIG1lbWJlciBuYW1lcyBlLCBrdHksIGFuZCBuIGFyZSB0aGUgb25l
cyBwcmVzZW50IGluIHRoZSBjb25zdHJ1Y3RlZCBKV0sgdXNlZCBpbiB0aGUgdGh1bWJwcmludCBj
b21wdXRhdGlvbiBhbmQgYXBwZWFyIGluIHRoYXQgb3JkZXI7IHdoZW4gdGhlIGt0eSB2YWx1ZSBp
cyBFQywgdGhlIG1lbWJlciBuYW1lcyBjcnYsIGt0eSwgeCwgYW5kIHkgYXJlIHByZXNlbnQgaW4g
dGhhdCBvcmRlci4gTm90ZSB0aGF0IHRoaXMgdGh1bWJwcmludCBjYWxjdWxhdGlvbiBpcyB0aGUg
c2FtZSBhcyB0aGF0IGRlZmluZWQgaW4gdGhlIEpXSyBUaHVtYnByaW50IFtKV0suVGh1bWJwcmlu
dF1Kb25lcywgTS4sIOKAnEpTT04gV2ViIEtleSAoSldLKSBUaHVtYnByaW50LOKAnSBKdWx5IDIw
MTQuPGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1s
I0pXSy5UaHVtYnByaW50PiBzcGVjaWZpY2F0aW9uLg0KDQpTbywgeWVzLiBUaGUgc3RyaW5nIGh0
dHBzOi8vc2VsZi1pc3N1ZWQubWUve3N1Yn08aHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS8lN2JzdWIl
N2Q+IGlzIHByb2JhYmlsaXN0aWNhbGx5IHVuaXF1ZSBhbmQg4oCccGVyc2lzdGVudOKAnSAoYmV0
dGVyIHRvIHBocmFzZSBpdCBhcyDigJhuZXZlciByZS1hc3NpZ25lZOKAmSkuDQoNClRoZSByZWFz
b24gaXQgaXMgbm90IGEg4oCcVVJM4oCdIGlzIHRoYXQgeW91IGNhbm5vdCByZWFjaCBpdC4gSG93
ZXZlciwgSXQgaXMgYSDigJxVUknigJ0uDQoNCkNoZWVycywNCg0KDQpOYXQgU2FraW11cmEgPG4t
c2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcD4+DQoNClBMRUFT
RSBSRUFEIDpUaGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUg
bmFtZWQgcmVjaXBpZW50IG9ubHkuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVu
dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuDQoNCg0K
DQpGcm9tOiBPcGVuaWQtc3BlY3MtYWIgPG9wZW5pZC1zcGVjcy1hYi1ib3VuY2VzQGxpc3RzLm9w
ZW5pZC5uZXQ+IE9uIEJlaGFsZiBPZiBUb20gSm9uZXMgdmlhIE9wZW5pZC1zcGVjcy1hYg0KU2Vu
dDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOCwgMjAxOCA4OjE2IEFNDQpUbzogQXJ0aWZhY3QgQmlu
ZGluZy9Db25uZWN0IFdvcmtpbmcgR3JvdXAgPG9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQu
bmV0Pg0KQ2M6IFRvbSBKb25lcyA8dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbT47IG9hdXRo
QGlldGYub3JnOyBqaW1AbWFuaWNvZGUuY29tDQpTdWJqZWN0OiBSZTogW09wZW5pZC1zcGVjcy1h
Yl0gW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6
YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0DQoNCkkgYW0gaGVhZGVkIHRvIGEgdzNjIG1l
ZXRpbmcgdGhhdCB3aWxsIHRhbGsgYWJvdXQgRElEcyBmb3IgdGhlIGZ1dHVyZS4gSSB3b3VsZCBs
aWtlIHRvIHVuZGVyc3RhbmQgaWYgdGhlIHNlbGYtaXNzdWVkIElEIHJlcXVpcmVzIChvciBzaG91
bGQgcmVxdWlyZSkgc29tZSBzb3J0IG9mIChzZW1pKSBwZXJtYW5lbnQgVVJMIG9uIHRoZSBpbnRl
cm5ldC4gKGluY2x1ZGluZyBvbiBhIGJsb2NrLWNoYWluLCBmb3IgZXhhbXBsZS4pICBXaXRob3V0
IHRoYXQgaSBjYW5ub3QgdW5kZXJzdGFuZCB3aGF0IGEgc2VsZi1pc3N1ZWQgSUQgbWlnaHQgZXZl
biBtZWFuLg0KDQpQZWFjZSAuLnRvbQ0KDQoNCk9uIFR1ZSwgTm92IDI3LCAyMDE4IGF0IDM6MDYg
UE0gTmF0IFNha2ltdXJhIHZpYSBPcGVuaWQtc3BlY3MtYWIgPG9wZW5pZC1zcGVjcy1hYkBsaXN0
cy5vcGVuaWQubmV0PG1haWx0bzpvcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldD4+IHdy
b3RlOg0KU2VsZiBJc3N1ZWQgT1AgaXMgZGVzY3JpYmVkIGluIENoYXB0ZXIgNyBvZiB0aGUgT3Bl
bklEIENvbm5lY3QgQ29yZSAxLjAuDQpJdCBsaXZlcyBvbiBhIGxvY2FsIG1hY2hpbmUsIHR5cGlj
YWxseSBhIHBob25lLiBFdmVuIGlmIGl0IGRpZCBwcm92aWRlIGFuIGF1dGhvcml6YXRpb24gY29k
ZSB0byB0aGUgY2xpZW50LCB0aGUgY2xpZW50IGNhbm5vdCBlc3RhYmxpc2ggYSBkaXJlY3QgY29u
bmVjdGlvbiB0byB0aGUgbG9jYWwgbWFjaGluZSAocGhvbmUpIGFzIGl0IGlzIG5vdCBhZGRyZXNz
YWJsZS4gVGhlcmVmb3JlLCBhIHRva2VuIGVuZHBvaW50IGNhbm5vdCBiZSBwcm92aWRlZCB1bmxl
c3MgaXQgaXMgY291cGxlZCB3aXRoIHNvbWUga2luZCBvZiBjbG91ZC1iYXNlZCBzZXJ2aWNlLCB3
aGljaCB3b3VsZCBuZWdhdGUgc29tZSBvZiB0aGUgdmVyeSByZWFzb24gZm9yIGhhdmluZyB0aGUg
U2VsZi1pc3N1ZWQgT1AuIEluIG90aGVyIHdvcmRzLCBvbmx5IHRoZSB2aWFibGUgY29tbXVuaWNh
dGlvbiBjaGFubmVsIGJldHdlZW4gdGhlIFNJT1AgYW5kIHRoZSBjbGllbnQgaXMgdGhlIGZyb250
IGNoYW5uZWwuIFRoZSBzaXR1YXRpb24gY291bGQgYmUgdHJ1ZSB0byBvdGhlciAid2FsbGV0IiB0
eXBlIG9mIGltcGxlbWVudGF0aW9ucy4NCg0KVGhpcyBpcyBvbmUgb2YgdGhlIGV4b3RpYyBmZWF0
dXJlcyBvZiBPcGVuSUQgQ29ubmVjdCB0aGF0IG5ldmVyIGdvdCBhIHRyYWN0aW9uIGJ1dCBpdCBp
cyBnZXR0aW5nIGEgcmVuZXdlZCBpbnRlcmVzdCBhcyAiU2VsZi1zb3ZlcmVpZ24gSWRlbnRpdHki
IGdhaW5lZCBzb21lIGludGVyZXN0Lg0KDQoNCg0KT24gV2VkLCBOb3YgMjgsIDIwMTggYXQgNjow
MyBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86
dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCkkgc3RpbGwgZG9u4oCZdCB1bmRlcnN0
YW5kIHdoeSB0aGUgdXNlIGNhc2UgbXVzdCBiZSBzb2x2ZWQgdXNpbmcgYSBmbG93IGlzc3Vpbmcg
c29tZXRoaW5nIGluIHRoZSBmcm9udCBjaGFubmVsLg0KDQpJIHdvdWxkIGFsc28gbGlrZSB0byB0
YWtlIGEgY2xvc2VyIGxvb2suIENhbiB5b3Ugb3IgTmF0IHByb3ZpZGUgcG9pbnRlcnMgdG8gZXhp
c3RpbmcgaW1wbGVtZW50YXRpb25zPw0KDQo+IEFtIDI3LjExLjIwMTggdW0gMjE6MzYgc2Nocmll
YiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNv
bT4+Og0KPg0KPiBJIHVuZGVyc3RhbmQgdGhhdCwgYnV0IGhhdCBpcyBOYXQncyBjb25jZXJuIGFz
IEkgdW5kZXJzdGFuZCBpdC4NCj4NCj4gV2hlbiB3ZSBzYXkgbm8gaW1wbGljaXQgcGVvcGxlLCBo
YXZlIGEgcHJvYmxlbSBiZWNhdXNlIGltcGxpY2l0IGlzIGltcHJlY2lzZS4NCj4NCj4gV2UgYXJl
IHNheWluZyBubyBBVCByZXR1cm5lZCBpbiB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgYXV0aG9yaXph
dGlvbiBlbmRwb2ludC4NCj4NCj4gTmF0IHBvaW50cyBvdXQgdGhhdCBpZF90b2tlbiBtYXkgY29u
dGFpbiBBVCBmb3IgdGhlIHNlbGYgaXNzdWVkIGNsaWVudC4NCj4NCj4gU28gdW5sZXNzIHdlIHNh
eSB0aGF0IGlzIE9LIGlmIHRoZSBBVCBhcmUgc2VuZGVyIGNvbnN0cmFpbmVkIHdlIHdpbmQgdXAg
aW1wbHlpbmcgdGhhdCBhIE9wZW5JRCBwcm9maWxlIG9mIE9BdXRoIGlzIGluIHZpb2xhdGlvbiBv
ZiB0aGUgQkNQLg0KPg0KPiBJIGFtIGp1c3QgdHJ5aW5nIHRvIG1ha2Ugc3VyZSBldmVyeW9uZSBp
cyBvbiB0aGUgc2FtZSBwYWdlIHdpdGggd2h5IE5hdCB3YXMgLTEuDQo+DQo+IEl0IHJlYWxseSBo
YXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBTUEEgdXNlIGNhc2UuDQo+DQo+IEpvaG4gQi4NCj4N
Cj4+IE9uIDExLzI3LzIwMTggNToyOCBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZToNCj4+
IEhpIEpvaG4sDQo+Pg0KPj4gYXMgeW91IHNhaWQsIHNlbGYgaXNzdWVkIElEUHMgKGh0dHBzOi8v
b3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sI1NlbGZJc3N1ZWQp
IGFyZSBzdXBwb3NlZCB0byBwcm92aWRlIHRoZSByZXNwb25zZSB0eXBlIOKAnmlkX3Rva2Vu4oCc
IG9ubHkuIEkgZG9u4oCZdCB0aGluayB0aGUgcHJvcG9zYWwgYmVpbmcgZGlzY3Vzc2VkIGhlcmUg
aXMgcmVsYXRlZCB0byB0aGlzIE9JREMgbW9kZS4NCj4+DQo+PiBiZXN0IHJlZ2FyZHMsDQo+PiBU
b3JzdGVuLg0KPj4NCj4+PiBBbSAyNy4xMS4yMDE4IHVtIDIwOjU0IHNjaHJpZWIgSm9obiBCcmFk
bGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoNCj4+Pg0K
Pj4+IEkgdGFsa2VkIHRvIE5hdCBhYm91dCB0aGlzIGEgYml0IHRvZGF5Lg0KPj4+DQo+Pj4gVGhl
IHRoaW5nIGhlIGlzIGNvbmNlcm5lZCBhYm91dCBpcyBtb3N0bHkgYXJvdW5kIHRoZSBzZWxmIGlz
c3VlZCBJRFAgdGhhdCBkb2Vzbid0IGhhdmUgYSB0b2tlbiBlbmRwb2ludChhdGxlYXN0IG5vdCBl
YXNhbHkpLg0KPj4+DQo+Pj4gVGhlIG1haW4gdXNlIGNhc2UgZm9yIHRoYXQgaXMgdGhlIGlkX3Rv
a2VuIHJlc3BvbnNlIHR5cGUgd2hlcmUgY2xhaW1zIGFyZSByZXR1bmVkIGluIHRoZSBpZF90b2tl
bi4NCj4+Pg0KPj4+IEJlY2F1c2UgaXQgaXMgZnJhZ21lbnQgZW5jb2RlZCBzb21lIHBlb3BsZSBj
YWxsIHRoYXQgaW1wbGljaXQuICAgVGhhdCBpcyBub3Qgd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIHN0
b3AuDQo+Pj4NCj4+PiBJbiBzb21lIGNhc2VzIGluIHRoYXQgZmxvdyB0aGVyZSBtYXkgYmUgZGlz
dHJpYnV0ZWQgY2xhaW1zIHJldHVybmVkIHdpdGggYWNjZXNzIFRva2VuIGluc2lkZSB0aGUgaWRf
dG9rZW4uICAgIEkgdGhpbmsgbW9zdCBwZW9wbGUgd291bGQgYWdyZWUgdGhhdCB0aG9zZSBzaG91
bGQgYmUgcG9wIG9yIHNlbmRlciBjb25zdHJhaW5lZCB0b2tlbnMuDQo+Pj4NCj4+PiBJbiB0aGUg
Y2FzZSBvZiBzZWxmIGlzc3VlZCB0aGUgUlAgd291bGQgYmUgYSBzZXJ2ZXIgYW5kIGNvdWxkIGRv
IHNlbmRlciBjb25zdHJhaW5lZCB2aWEgc29tZSBtZWNoaW5pc2ltIHRoYXQgaXMgeWV0IHRvIGJl
IGRlZmluZWQuDQo+Pj4NCj4+PiBTbyBpZiBzb21lb25lIHdhbnRlZCB0byByZXR1cm4gYSBhY2Nl
c3MgdG9rZW4gaW4gYSBpZF90b2tlbiB0byBkbyBkaXN0cmlidXRlZCBjbGFpbXMgSSBkb24ndCB0
aGluayB3ZSBoYXZlIGEgcHJvYmxlbSB3aXRoIHRoYXQgYXMgbG9uZyBhcyB0aGUgdG9rZW4gaXMg
cHJvdGVjdGVkIGJ5IGJlaW5nIHNlbmRlciBjb25zdHJhaW5lZCBpbiBzb21lIHJlYXNvbmFibGUg
d2F5Lg0KPj4+DQo+Pj4gVGhpcyBpcyBhIHRvdWNoIGh5cG90aGV0aWNhbCBmcm9tIHRoZSBiYXNp
YyBPQXV0aCBwZXJzcGVjdGl2ZSwgc28gSSBkb24ndCBrbm93IGhvdyBkZWVwIHdlIHdhbnQgdG8g
Z28gaW50byBpdC4NCj4+Pg0KPj4+IEkgdGhpbmsgdGhlIHBvaW50IGlzIG5vdCB0byBhY2NpZGVu
dGx5IHByb2hpYml0IHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGRvbmUgaW4gZnV0dXJlLg0KPj4+
DQo+Pj4gSSBhbHNvIHRoaW5rIHdlIHNob3VsZCBub3QgY29uZmxhdGUgY29uZmlkZW50aWFsIGNs
aWVudHMgdGhhdCBjYW4gYXV0aGVudGljYXRlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIHNl
bmRlciBjb25zdHJhaW5lZC9Qb1AgY2xpZW50cyB0aGF0IGNhbiBkZWFsIHdpdGggYm91bmQgdG9r
ZW5zLiAgIFllcyBib3RoIGhhdmUga2V5cyBidXQgaXQgaXMgYmV0dGVyIHRvIGRlc2NyaWJlIHRo
ZW0gc2VwYXJhdGVseS4NCj4+Pg0KPj4+IEpvaG4gQi4NCj4+Pg0KPj4+IE9uIFR1ZSwgTm92IDI3
LCAyMDE4LCA0OjMwIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgdmlhIE9wZW5pZC1zcGVjcy1hYiA8
b3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ8bWFpbHRvOm9wZW5pZC1zcGVjcy1hYkBs
aXN0cy5vcGVuaWQubmV0PiB3cm90ZToNCj4+PiBIaSBOYXQsDQo+Pj4NCj4+PiBJIHVuZGVyc3Rh
bmQgeW91IGFyZSBzYXlpbmcgeW91ciBkcmFmdCBjb3VsZCBwcm92aWRlIGNsaWVudHMgd2l0aCBh
biBhcHBsaWNhdGlvbiBsZXZlbCBtZWNoYW5pc20gdG8gc2VuZGVyIGNvbnN0cmFpbiBhY2Nlc3Mg
dG9rZW5zLiBUaGF04oCZcyBncmVhdCENCj4+Pg0KPj4+IEJ1dCBJIGRvbuKAmXQgc2VlIGEgYmlu
ZGluZyB0byByZXNwb25zZSB0eXBlIOKAnnRva2VuIGlkX3Rva2Vu4oCcLiBXaHkgZG8geW91IHdh
bnQgdG8gZXhwb3NlIHRoZSB0b2tlbnMgdmlhIHRoZSBVUkwgdG8gYXR0YWNrZXJzPw0KPj4+DQo+
Pj4gWW91IGNvdWxkIGVhc2lseSB1c2UgeW91ciBtZWNoYW5pc20gd2l0aCBjb2RlLiBUaGF0IHdv
dWxkIGFsc28gZ2l2ZSB5b3UgdGhlIGNoYW5jZSB0byByZWFsbHkgYXV0aGVudGljYXRlIHRoZSBj
b25maWRlbnRpYWwgY2xpZW50IGJlZm9yZSB5b3UgaXNzdWUgdGhlIHRva2VuLg0KPj4+DQo+Pj4g
a2luZCByZWdhcmRzLA0KPj4+IFRvcnN0ZW4uDQo+Pj4NCj4+Pj4gQW0gMjcuMTEuMjAxOCB1bSAx
Njo1NyBzY2hyaWViIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtp
bXVyYUBnbWFpbC5jb20+PjoNCj4+Pj4NCj4+Pj4gSSBhbSBub3QgdGFsa2luZyBhYm91dCBTUEEu
DQo+Pj4+IFRoZSBjbGllbnQgaXMgYSByZWd1bGFyIGNvbmZpZGVudGlhbCBjbGllbnQgdGhhdCBp
cyBydW5uaW5nIG9uIGEgc2VydmVyLg0KPj4+Pg0KPj4+PiBCZXN0LA0KPj4+Pg0KPj4+PiBOYXQg
U2FraW11cmENCj4+Pj4NCj4+Pj4NCj4+Pj4gMjAxOOW5tDEx5pyIMjfml6Uo54GrKSAxNjo1NSBK
aW0gTWFuaWNvIDxqaW1AbWFuaWNvZGUuY29tPG1haWx0bzpqaW1AbWFuaWNvZGUuY29tPj46DQo+
Pj4+IE5hdCwNCj4+Pj4NCj4+Pj4gSG93IGlzIHByb29mIG9mIHBvc3Nlc3Npb24gZXN0YWJsaXNo
ZWQgaW4gYSBtb2Rlcm4gd2ViIGJyb3dzZXIgaW4gdGhlIGltcGxpY2l0IGZsb3c/DQo+Pj4+DQo+
Pj4+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0b2tlbiBiaW5kaW5nIHdhcyByZW1vdmVkIGZy
b20gQ2hyb21lIHJlY2VudGx5IGVmZmVjdGl2ZWx5IGtpbGxpbmcgYnJvd3Nlci1iYXNlZCBQb1Ag
dG9rZW5zLg0KPj4+Pg0KPj4+PiBodHRwczovL2lkZW50aXZlcnNlLmNvbS8yMDE4LzEwLzMxL2No
cm9tZS1wdXRzLXRva2VuLWJpbmRpbmctaW4tYS1iaW5kLw0KPj4+Pg0KPj4+PiBBbSBJIG1pc3Np
bmcgc29tZXRoaW5nPw0KPj4+Pg0KPj4+PiBBbG9oYSwgSmltDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+
Pj4+PiBPbiAxMS8yNy8xOCA5OjAwIFBNLCBOYXQgU2FraW11cmEgd3JvdGU6DQo+Pj4+PiBJIGFt
IGFjdHVhbGx5IC0xLg0KPj4+Pj4NCj4+Pj4+ICsxIGZvciBwdWJsaWMgY2xpZW50IGFuZCB0aGUg
dG9rZW5zIHRoYXQgYXJlIG5vdCBzZW5kZXIva2V5IGNvbnN0cmFpbmVkLg0KPj4+Pj4NCj4+Pj4+
IEp1c3Qgbm90IGJlaW5nIHVzZWQgcmlnaHQgbm93IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBu
b3QgdXNlZnVsLi4gSW4gZmFjdCwgSSBzZWUgaXQgY29taW5nLg0KPj4+Pj4gSW1wbGljaXQgKHdl
bGwsIEh5YnJpZCDigJx0b2tlbiBpZF90b2tlbuKAnSByZWFsbHkpIGlzIHZlcnkgdXNlZnVsIGlu
IGNlcnRhaW4gY2FzZXMuDQo+Pj4+PiBTcGVjaWZpY2FsbHksIHdoZW4gdGhlIGNsaWVudCBpcyBj
b25maWRlbnRpYWwgKGJhc2VkIG9uIHB1YmxpYyBrZXkgcGFpciksIGFuZCB1c2VzIHNlbmRlciBj
b25zdHJhaW5lZCAoa2V5LWNvbnN0cmFpbmVkKSB0b2tlbiBzdWNoIGFzIHRoZSBvbmUgZXhwbGFp
bmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1q
cG9wLTA0I3NlY3Rpb24tNSwgaXQgaXMgdmVyeSB1c2VmdWwuDQo+Pj4+PiAoS2V5LWNvbnN0cmFp
bmVkIHRva2VuIGlzIHRoZSByZW1haW5pbmcgcG9ydGlvbiBvZiB0aGlzIGRyYWZ0IHRoYXQgZGlk
IG5vdCBnZXQgaW5jb3Jwb3JhdGVkIGluIHRoZSBNVExTIGRyYWZ0LiApDQo+Pj4+PiBJbiBmYWN0
IGl0IGlzIHRoZSBvbmx5IHZpYWJsZSBtZXRob2QgZm9yIFNlbGYtSXNzdWVkIE9wZW5JRCBQcm92
aWRlci4NCj4+Pj4+DQo+Pj4+PiBTbywgdGhlIHRleHQgaXMgZ2VuZXJhbGx5IGdvb2QgYnV0IGl0
IG5lZWRzIHRvIGJlIGNvbnN0cmFpbmVkIGxpa2Ug4oCcVW5sZXNzIHRoZSBjbGllbnQgaXMgY29u
ZmlkZW50aWFsIGFuZCB0aGUgYWNjZXNzIHRva2VuIGlzc3VlZCBpcyBrZXkgY29uc3RyYWluZWQs
IC4uLiDigJwNCj4+Pj4+DQo+Pj4+PiBCZXN0LA0KPj4+Pj4NCj4+Pj4+IE5hdCBTYWtpbXVyYQ0K
Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiAyMDE45bm0MTHmnIgyN+aXpSjngaspIDE2OjAxIFZsYWRpbWly
IER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWlyQGNvbm5l
Y3QyaWQuY29tPj46DQo+Pj4+PiArMSB0byByZWNvbW1lbmQgdGhlIGRlcHJlY2F0aW9uIG9mIGlt
cGxpY2l0Lg0KPj4+Pj4NCj4+Pj4+IEkgZG9uJ3Qgc2VlIGEgY29tcGVsbGluZyByZWFzb24gdG8g
a2VlcCBpbXBsaWNpdCB3aGVuIHRoZXJlIGlzIGFuDQo+Pj4+PiBlc3RhYmxpc2hlZCBhbHRlcm5h
dGl2ZSB0aGF0IGlzIG1vcmUgc2VjdXJlLg0KPj4+Pj4NCj4+Pj4+IE91ciBkdXR5IGFzIFdHIGlz
IHRvIGdpdmUgZGV2ZWxvcGVycyB0aGUgYmVzdCBhbmQgbW9zdCBzZW5zaWJsZSBwcmFjdGljZS4N
Cj4+Pj4+DQo+Pj4+PiBDT1JTIGFkb3B0aW9uIGlzIGN1cnJlbnRseSBhdCA5NCUgYWNjb3JkaW5n
IHRvDQo+Pj4+PiBodHRwczovL2Nhbml1c2UuY29tLyNmZWF0PWNvcnMNCj4+Pj4+DQo+Pj4+PiBW
bGFkaW1pcg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+PiBPQXV0
aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+PiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+PiAtLQ0KPj4+Pj4gTmF0IFNha2ltdXJh
ICg9bmF0KQ0KPj4+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+Pj4+PiBodHRwOi8v
bmF0Li5zYWtpbXVyYS5vcmcvPGh0dHA6Ly9zYWtpbXVyYS5vcmcvPg0KPj4+Pj4gQF9uYXRfZW4N
Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4NCj4+Pj4+IE9BdXRo
QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+Pj4gLS0NCj4+Pj4gSmltIE1hbmljbw0KPj4+
PiBNYW5pY29kZSBTZWN1cml0eQ0KPj4+Pg0KPj4+PiBodHRwczovL3d3dy5tYW5pY29kZS5jb20N
Cj4+Pj4gLS0NCj4+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPj4+PiBDaGFpcm1hbiwgT3BlbklE
IEZvdW5kYXRpb24NCj4+Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+Pj4+IEBfbmF0X2Vu
DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
Pj4+IE9wZW5pZC1zcGVjcy1hYiBtYWlsaW5nIGxpc3QNCj4+PiBPcGVuaWQtc3BlY3MtYWJAbGlz
dHMub3BlbmlkLm5ldDxtYWlsdG86T3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ+DQo+
Pj4gaHR0cDovL2xpc3RzLm9wZW5pZC5uZXQvbWFpbG1hbi9saXN0aW5mby9vcGVuaWQtc3BlY3Mt
YWINCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0
aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT3BlbmlkLXNwZWNzLWFiIG1haWxpbmcg
bGlzdA0KT3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ8bWFpbHRvOk9wZW5pZC1zcGVj
cy1hYkBsaXN0cy5vcGVuaWQubmV0Pg0KaHR0cDovL2xpc3RzLm9wZW5pZC5uZXQvbWFpbG1hbi9s
aXN0aW5mby9vcGVuaWQtc3BlY3MtYWINCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Ik5vdG8gU2FucyBDSksgSlAgTWVkaXVtIjsNCglwYW5vc2UtMToyIDEx
IDYgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE5vdG8gU2Fu
cyBDSksgSlAgTWVkaXVtIjt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDj
grTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxl
IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs
DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu
bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At
YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLjE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCnNwYW4uaW5mbw0KCXttc28tc3R5bGUtbmFtZTppbmZvO30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo5OS4yNXB0
IDMuMGNtIDMuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs
dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk
bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5U
b20sIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SXQgaXMgZ29vZCB0byBoZWFy
IHRoYXQgeW91IHdpbGwgYmUgdGhlcmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZiI+SSB1bmRlcnN0YW5kIEpvaG4gd2lsbCBhbHNvIGJlIHRoZXJlLg0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UbyB5b3VyIHF1ZXN0aW9uLCBzZWxmLWlzc3Vl
ZCBJRCBkb2VzIG5vdCByZXF1aXJlIGEgKHNlbWktKXBlcm1hbmVudCBVUkwgYXMgdGhlIHVzZXLi
gJlzIGlkZW50aWZpZXIsIGFzIGl0IGlzIGFsd2F5cyDigJxsb2NhbGhvc3TigJ0uDQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGlkZW50aWZpZXIgaXMgZGVy
aXZlZCBhcyB0aGUgaGFzaCBvZiB0aGUgcHVibGljIGtleSB0aGF0IHdhcyBnZW5lcmF0ZWQgYnkg
dGhlIFNlbGYtaXNzdWVkIE9QLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPklmIHlvdXIgcXVlc3Rpb24gd2FzIOKAnFVSSeKAnSwgdGhlbiB5ZXMuIEl0cyBpc3N1
ZXIgaXMgYWx3YXlzDQo8YSBocmVmPSJodHRwczovL3NlbGYtaXNzdWVkLm1lIj5odHRwczovL3Nl
bGYtaXNzdWVkLm1lPC9hPiBhbmQgdGhlcmUgaXMgYSBgc3ViYCBmb3IgdGhhdCBpZGVudGl0eSwg
c28gc3ludGhlc2l6ZWQgVVJJIGZvciB0aGUgdXNlciB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZQ0K
PGEgaHJlZj0iaHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS8lN2JzdWIlN2QiPmh0dHBzOi8vc2VsZi1p
c3N1ZWQubWUve3N1Yn08L2E+IHdoZXJlIHtzdWJ9IHJlcHJlc2VudHMgdGhlIHZhbHVlIG9mIHRo
ZSBgc3ViYCBjbGFpbS4gYHN1YmAgY2xhaW0gdmFsdWUgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOiAm
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3VuZDp3aGl0ZSI+c3ViPC9z
cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiZu
YnNwOyhzdWJqZWN0KSBDbGFpbSB2YWx1ZSBpcyB0aGUgYmFzZTY0dXJsIGVuY29kZWQgcmVwcmVz
ZW50YXRpb24NCiBvZiB0aGUgdGh1bWJwcmludCBvZiB0aGUga2V5IGluIHRoZSZuYnNwOzwvc3Bh
bj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3Jv
dW5kOndoaXRlIj5zdWJfandrPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr
O2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwO0NsYWltLiBUaGlzIHRodW1icHJpbnQgdmFsdWUgaXMg
Y29tcHV0ZWQNCiBhcyB0aGUgU0hBLTI1NiBoYXNoIG9mIHRoZSBvY3RldHMgb2YgdGhlIFVURi04
IHJlcHJlc2VudGF0aW9uIG9mIGEgSldLIGNvbnN0cnVjdGVkIGNvbnRhaW5pbmcgb25seSB0aGUg
UkVRVUlSRUQgbWVtYmVycyB0byByZXByZXNlbnQgdGhlIGtleSwgd2l0aCB0aGUgbWVtYmVyIG5h
bWVzIHNvcnRlZCBpbnRvIGxleGljb2dyYXBoaWMgb3JkZXIsIGFuZCB3aXRoIG5vIHdoaXRlIHNw
YWNlIG9yIGxpbmUgYnJlYWtzLiBGb3IgaW5zdGFuY2UsIHdoZW4NCiB0aGUmbmJzcDs8L3NwYW4+
PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3Vu
ZDp3aGl0ZSI+a3R5PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tn
cm91bmQ6d2hpdGUiPiZuYnNwO3ZhbHVlIGlzJm5ic3A7PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtjb2xvcjojMDAzMzY2O2JhY2tncm91bmQ6d2hpdGUiPlJTQTwvc3Bh
bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl
cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj4sDQog
dGhlIG1lbWJlciBuYW1lcyZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5lPC9zcGFuPjwvdHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiwmbmJzcDs8L3NwYW4+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3VuZDp3
aGl0ZSI+a3R5PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91
bmQ6d2hpdGUiPiwNCiBhbmQmbmJzcDs8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3VuZDp3aGl0ZSI+bjwvc3Bhbj48L3R0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDthcmUgdGhlIG9u
ZXMgcHJlc2VudCBpbiB0aGUgY29uc3RydWN0ZWQgSldLIHVzZWQgaW4gdGhlIHRodW1icHJpbnQg
Y29tcHV0YXRpb24NCiBhbmQgYXBwZWFyIGluIHRoYXQgb3JkZXI7IHdoZW4gdGhlJm5ic3A7PC9z
cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMDAzMzY2O2JhY2tn
cm91bmQ6d2hpdGUiPmt0eTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazti
YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDt2YWx1ZSBpcyZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5FQzwv
c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj4s
DQogdGhlIG1lbWJlciBuYW1lcyZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5jcnY8L3NwYW4+PC90dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+LCZuYnNwOzwvc3Bh
bj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3Jv
dW5kOndoaXRlIj5rdHk8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm
b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFj
a2dyb3VuZDp3aGl0ZSI+LCZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj54PC9zcGFuPjwvdHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiwNCiBhbmQmbmJzcDs8L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dy
b3VuZDp3aGl0ZSI+eTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNr
Z3JvdW5kOndoaXRlIj4mbmJzcDthcmUgcHJlc2VudCBpbiB0aGF0IG9yZGVyLiBOb3RlIHRoYXQg
dGhpcyB0aHVtYnByaW50IGNhbGN1bGF0aW9uIGlzIHRoZQ0KIHNhbWUgYXMgdGhhdCBkZWZpbmVk
IGluIHRoZSBKV0sgVGh1bWJwcmludCZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL29wZW5p
ZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNKV0suVGh1bWJwcmludCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu
YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlO2JhY2tncm91bmQ6Izk5MDAwMDt0ZXh0LWRl
Y29yYXRpb246bm9uZSI+W0pXSy5UaHVtYnByaW50XTwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9Imlu
Zm8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl
cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMDAwO2JvcmRlcjpzb2xpZCAjMzMzMzMz
IDEuMHB0O3BhZGRpbmc6Mi4wcHQ7YmFja2dyb3VuZDojRUVFRUVFO3RleHQtZGVjb3JhdGlvbjpu
b25lIj5Kb25lcywNCiBNLiwg4oCcSlNPTiBXZWIgS2V5IChKV0spIFRodW1icHJpbnQs4oCdIEp1
bHkmbmJzcDsyMDE0Ljwvc3Bhbj48L2I+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7c3BlY2lmaWNhdGlvbi48L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U28sIHllcy4gVGhlIHN0cmluZw0KPGEgaHJlZj0i
aHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS8lN2JzdWIlN2QiPmh0dHBzOi8vc2VsZi1pc3N1ZWQubWUv
e3N1Yn08L2E+IGlzIHByb2JhYmlsaXN0aWNhbGx5IHVuaXF1ZSBhbmQg4oCccGVyc2lzdGVudOKA
nSAoYmV0dGVyIHRvIHBocmFzZSBpdCBhcyDigJhuZXZlciByZS1hc3NpZ25lZOKAmSkuDQo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSByZWFzb24gaXQgaXMgbm90IGEg4oCc
VVJM4oCdIGlzIHRoYXQgeW91IGNhbm5vdCByZWFjaCBpdC4gSG93ZXZlciwgSXQgaXMgYSDigJxV
UknigJ0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycywgPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Tm90
byBTYW5zIENKSyBKUCBNZWRpdW0mcXVvdDssc2Fucy1zZXJpZiI+TmF0IFNha2ltdXJhICZsdDs8
YSBocmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDU2M0MxIj5uLXNha2ltdXJhQG5yaS5jby5qcDwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtOb3RvIFNhbnMgQ0pLIEpQIE1lZGl1bSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O05vdG8gU2FucyBDSksgSlAgTWVkaXVtJnF1
b3Q7LHNhbnMtc2VyaWYiPlBMRUFTRSBSRUFEIDpUaGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwg
YW5kIGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50IG9ubHkuIElmIHlvdSBhcmUgbm90
IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl
dGUNCiB0aGlzIGUtbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT3Blbmlk
LXNwZWNzLWFiICZsdDtvcGVuaWQtc3BlY3MtYWItYm91bmNlc0BsaXN0cy5vcGVuaWQubmV0Jmd0
Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Ub20gSm9uZXMgdmlhIE9wZW5pZC1zcGVjcy1hYjxicj4N
CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDI4LCAyMDE4IDg6MTYgQU08YnI+DQo8
Yj5Ubzo8L2I+IEFydGlmYWN0IEJpbmRpbmcvQ29ubmVjdCBXb3JraW5nIEdyb3VwICZsdDtvcGVu
aWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IFRvbSBKb25l
cyAmbHQ7dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbSZndDs7IG9hdXRoQGlldGYub3JnOyBq
aW1AbWFuaWNvZGUuY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT3BlbmlkLXNwZWNzLWFi
XSBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXph
dGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgYW0gaGVhZGVkIHRvIGEgdzNjIG1lZXRpbmcgdGhhdCB3aWxsIHRhbGsgYWJvdXQgRElE
cyBmb3IgdGhlIGZ1dHVyZS4gSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgaWYgdGhlIHNlbGYt
aXNzdWVkIElEIHJlcXVpcmVzIChvciBzaG91bGQgcmVxdWlyZSkgc29tZSBzb3J0IG9mIChzZW1p
KSBwZXJtYW5lbnQgVVJMIG9uIHRoZSBpbnRlcm5ldC4gKGluY2x1ZGluZyBvbiBhIGJsb2NrLWNo
YWluLCBmb3IgZXhhbXBsZS4pJm5ic3A7DQogV2l0aG91dCB0aGF0IGkgY2Fubm90IHVuZGVyc3Rh
bmQgd2hhdCBhIHNlbGYtaXNzdWVkIElEIG1pZ2h0IGV2ZW4gbWVhbi48bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q
ZWFjZSAuLnRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMjcsIDIwMTggYXQgMzowNiBQ
TSBOYXQgU2FraW11cmEgdmlhIE9wZW5pZC1zcGVjcy1hYiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9w
ZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0Ij5vcGVuaWQtc3BlY3MtYWJAbGlzdHMub3Bl
bmlkLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbGYgSXNzdWVkIE9QIGlzIGRlc2NyaWJl
ZCBpbiBDaGFwdGVyIDcgb2YgdGhlIE9wZW5JRCBDb25uZWN0IENvcmUgMS4wLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGxpdmVzIG9uIGEgbG9j
YWwgbWFjaGluZSwgdHlwaWNhbGx5IGEgcGhvbmUuIEV2ZW4gaWYgaXQgZGlkIHByb3ZpZGUgYW4g
YXV0aG9yaXphdGlvbiBjb2RlIHRvIHRoZSBjbGllbnQsIHRoZSBjbGllbnQgY2Fubm90IGVzdGFi
bGlzaCBhIGRpcmVjdCBjb25uZWN0aW9uIHRvIHRoZSBsb2NhbCBtYWNoaW5lIChwaG9uZSkgYXMg
aXQgaXMgbm90IGFkZHJlc3NhYmxlLiBUaGVyZWZvcmUsIGEmbmJzcDt0b2tlbiBlbmRwb2ludA0K
IGNhbm5vdCBiZSBwcm92aWRlZCB1bmxlc3MgaXQgaXMgY291cGxlZCB3aXRoIHNvbWUga2luZCBv
ZiBjbG91ZC1iYXNlZCBzZXJ2aWNlLCB3aGljaCB3b3VsZCBuZWdhdGUgc29tZSBvZiB0aGUgdmVy
eSByZWFzb24gZm9yIGhhdmluZyB0aGUgU2VsZi1pc3N1ZWQgT1AuIEluIG90aGVyIHdvcmRzLCBv
bmx5IHRoZSB2aWFibGUgY29tbXVuaWNhdGlvbiBjaGFubmVsIGJldHdlZW4gdGhlIFNJT1AgYW5k
IHRoZSBjbGllbnQgaXMgdGhlIGZyb250IGNoYW5uZWwuDQogVGhlIHNpdHVhdGlvbiBjb3VsZCBi
ZSB0cnVlIHRvIG90aGVyICZxdW90O3dhbGxldCZxdW90OyB0eXBlIG9mIGltcGxlbWVudGF0aW9u
cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhpcyBpcyBvbmUgb2YgdGhlIGV4b3RpYyBmZWF0dXJlcyBvZiBPcGVuSUQgQ29ubmVj
dCB0aGF0IG5ldmVyIGdvdCBhIHRyYWN0aW9uJm5ic3A7YnV0IGl0IGlzIGdldHRpbmcgYSByZW5l
d2VkIGludGVyZXN0IGFzICZxdW90O1NlbGYtc292ZXJlaWduIElkZW50aXR5JnF1b3Q7IGdhaW5l
ZCBzb21lIGludGVyZXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgMjgsIDIwMTggYXQgNjowMyBBTSBU
b3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk
dC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SSBzdGlsbCBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHRoZSB1c2UgY2FzZSBtdXN0IGJl
IHNvbHZlZCB1c2luZyBhIGZsb3cgaXNzdWluZyBzb21ldGhpbmcgaW4gdGhlIGZyb250IGNoYW5u
ZWwuDQo8YnI+DQo8YnI+DQpJIHdvdWxkIGFsc28gbGlrZSB0byB0YWtlIGEgY2xvc2VyIGxvb2su
IENhbiB5b3Ugb3IgTmF0IHByb3ZpZGUgcG9pbnRlcnMgdG8gZXhpc3RpbmcgaW1wbGVtZW50YXRp
b25zPw0KPGJyPg0KPGJyPg0KJmd0OyBBbSAyNy4xMS4yMDE4IHVtIDIxOjM2IHNjaHJpZWIgSm9o
biBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0i
X2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsgPGJyPg0KJmd0OyBJ
IHVuZGVyc3RhbmQgdGhhdCwgYnV0IGhhdCBpcyBOYXQncyBjb25jZXJuIGFzIEkgdW5kZXJzdGFu
ZCBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hlbiB3ZSBzYXkgbm8gaW1wbGljaXQgcGVvcGxl
LCBoYXZlIGEgcHJvYmxlbSBiZWNhdXNlIGltcGxpY2l0IGlzIGltcHJlY2lzZS48YnI+DQomZ3Q7
IDxicj4NCiZndDsgV2UgYXJlIHNheWluZyBubyBBVCByZXR1cm5lZCBpbiB0aGUgcmVzcG9uc2Ug
ZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTmF0
IHBvaW50cyBvdXQgdGhhdCBpZF90b2tlbiBtYXkgY29udGFpbiBBVCBmb3IgdGhlIHNlbGYgaXNz
dWVkIGNsaWVudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgU28gdW5sZXNzIHdlIHNheSB0aGF0IGlz
IE9LIGlmIHRoZSBBVCBhcmUgc2VuZGVyIGNvbnN0cmFpbmVkIHdlIHdpbmQgdXAgaW1wbHlpbmcg
dGhhdCBhIE9wZW5JRCBwcm9maWxlIG9mIE9BdXRoIGlzIGluIHZpb2xhdGlvbiBvZiB0aGUgQkNQ
Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIGp1c3QgdHJ5aW5nIHRvIG1ha2Ugc3VyZSBldmVy
eW9uZSBpcyBvbiB0aGUgc2FtZSBwYWdlIHdpdGggd2h5IE5hdCB3YXMgLTEuPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IEl0IHJlYWxseSBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBTUEEgdXNlIGNh
c2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEpvaG4gQi48YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7
IE9uIDExLzI3LzIwMTggNToyOCBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZTo8YnI+DQom
Z3Q7Jmd0OyBIaSBKb2huLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IGFzIHlvdSBzYWlk
LCBzZWxmIGlzc3VlZCBJRFBzICg8YSBocmVmPSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3Bl
bmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNTZWxmSXNzdWVkIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUtMV8wLmh0bWwjU2VsZklz
c3VlZDwvYT4pIGFyZSBzdXBwb3NlZCB0byBwcm92aWRlIHRoZSByZXNwb25zZSB0eXBlIOKAnmlk
X3Rva2Vu4oCcIG9ubHkuIEkgZG9u4oCZdA0KIHRoaW5rIHRoZSBwcm9wb3NhbCBiZWluZyBkaXNj
dXNzZWQgaGVyZSBpcyByZWxhdGVkIHRvIHRoaXMgT0lEQyBtb2RlLjxicj4NCiZndDsmZ3Q7IDxi
cj4NCiZndDsmZ3Q7IGJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyBUb3JzdGVuLjxicj4NCiZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBBbSAyNy4xMS4yMDE4IHVtIDIwOjU0IHNjaHJpZWIg
Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdl
dD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyA8
YnI+DQomZ3Q7Jmd0OyZndDsgSSB0YWxrZWQgdG8gTmF0IGFib3V0IHRoaXMgYSBiaXQgdG9kYXku
PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgdGhpbmcgaGUgaXMgY29u
Y2VybmVkIGFib3V0IGlzIG1vc3RseSBhcm91bmQgdGhlIHNlbGYgaXNzdWVkIElEUCB0aGF0IGRv
ZXNuJ3QgaGF2ZSBhIHRva2VuIGVuZHBvaW50KGF0bGVhc3Qgbm90IGVhc2FseSkuPGJyPg0KJmd0
OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgbWFpbiB1c2UgY2FzZSBmb3IgdGhhdCBp
cyB0aGUgaWRfdG9rZW4gcmVzcG9uc2UgdHlwZSB3aGVyZSBjbGFpbXMgYXJlIHJldHVuZWQgaW4g
dGhlIGlkX3Rva2VuLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgQmVjYXVz
ZSBpdCBpcyBmcmFnbWVudCBlbmNvZGVkIHNvbWUgcGVvcGxlIGNhbGwgdGhhdCBpbXBsaWNpdC4m
bmJzcDsgJm5ic3A7VGhhdCBpcyBub3Qgd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIHN0b3AuPGJyPg0K
Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBJbiBzb21lIGNhc2VzIGluIHRoYXQgZmxv
dyB0aGVyZSBtYXkgYmUgZGlzdHJpYnV0ZWQgY2xhaW1zIHJldHVybmVkIHdpdGggYWNjZXNzIFRv
a2VuIGluc2lkZSB0aGUgaWRfdG9rZW4uJm5ic3A7ICZuYnNwOyBJIHRoaW5rIG1vc3QgcGVvcGxl
IHdvdWxkIGFncmVlIHRoYXQgdGhvc2Ugc2hvdWxkIGJlIHBvcCBvciBzZW5kZXIgY29uc3RyYWlu
ZWQgdG9rZW5zLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSW4gdGhlIGNh
c2Ugb2Ygc2VsZiBpc3N1ZWQgdGhlIFJQIHdvdWxkIGJlIGEgc2VydmVyIGFuZCBjb3VsZCBkbyBz
ZW5kZXIgY29uc3RyYWluZWQgdmlhIHNvbWUgbWVjaGluaXNpbSB0aGF0IGlzIHlldCB0byBiZSBk
ZWZpbmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgU28gaWYgc29tZW9u
ZSB3YW50ZWQgdG8gcmV0dXJuIGEgYWNjZXNzIHRva2VuIGluIGEgaWRfdG9rZW4gdG8gZG8gZGlz
dHJpYnV0ZWQgY2xhaW1zIEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhIHByb2JsZW0gd2l0aCB0aGF0
IGFzIGxvbmcgYXMgdGhlIHRva2VuIGlzIHByb3RlY3RlZCBieSBiZWluZyBzZW5kZXIgY29uc3Ry
YWluZWQgaW4gc29tZSByZWFzb25hYmxlIHdheS48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0
OyZndDsmZ3Q7IFRoaXMgaXMgYSB0b3VjaCBoeXBvdGhldGljYWwgZnJvbSB0aGUgYmFzaWMgT0F1
dGggcGVyc3BlY3RpdmUsIHNvIEkgZG9uJ3Qga25vdyBob3cgZGVlcCB3ZSB3YW50IHRvIGdvIGlu
dG8gaXQuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBJIHRoaW5rIHRoZSBw
b2ludCBpcyBub3QgdG8gYWNjaWRlbnRseSBwcm9oaWJpdCBzb21ldGhpbmcgdGhhdCBjb3VsZCBi
ZSBkb25lIGluIGZ1dHVyZS48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEkg
YWxzbyB0aGluayB3ZSBzaG91bGQgbm90IGNvbmZsYXRlIGNvbmZpZGVudGlhbCBjbGllbnRzIHRo
YXQgY2FuIGF1dGhlbnRpY2F0ZSB0byB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBzZW5kZXIgY29u
c3RyYWluZWQvUG9QIGNsaWVudHMgdGhhdCBjYW4gZGVhbCB3aXRoIGJvdW5kIHRva2Vucy4mbmJz
cDsgJm5ic3A7WWVzIGJvdGggaGF2ZSBrZXlzIGJ1dCBpdCBpcyBiZXR0ZXIgdG8gZGVzY3JpYmUg
dGhlbSBzZXBhcmF0ZWx5Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSm9o
biBCLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgT24gVHVlLCBOb3YgMjcs
IDIwMTgsIDQ6MzAgUE0gVG9yc3RlbiBMb2RkZXJzdGVkdCB2aWEgT3BlbmlkLXNwZWNzLWFiICZs
dDs8YSBocmVmPSJtYWlsdG86b3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQiIHRhcmdl
dD0iX2JsYW5rIj5vcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldDwvYT4gd3JvdGU6PGJy
Pg0KJmd0OyZndDsmZ3Q7IEhpIE5hdCw8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm
Z3Q7IEkgdW5kZXJzdGFuZCB5b3UgYXJlIHNheWluZyB5b3VyIGRyYWZ0IGNvdWxkIHByb3ZpZGUg
Y2xpZW50cyB3aXRoIGFuIGFwcGxpY2F0aW9uIGxldmVsIG1lY2hhbmlzbSB0byBzZW5kZXIgY29u
c3RyYWluIGFjY2VzcyB0b2tlbnMuIFRoYXTigJlzIGdyZWF0ITxicj4NCiZndDsmZ3Q7Jmd0OyA8
YnI+DQomZ3Q7Jmd0OyZndDsgQnV0IEkgZG9u4oCZdCBzZWUgYSBiaW5kaW5nIHRvIHJlc3BvbnNl
IHR5cGUg4oCedG9rZW4gaWRfdG9rZW7igJwuIFdoeSBkbyB5b3Ugd2FudCB0byBleHBvc2UgdGhl
IHRva2VucyB2aWEgdGhlIFVSTCB0byBhdHRhY2tlcnM/PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7Jmd0OyBZb3UgY291bGQgZWFzaWx5IHVzZSB5b3VyIG1lY2hhbmlzbSB3aXRoIGNv
ZGUuIFRoYXQgd291bGQgYWxzbyBnaXZlIHlvdSB0aGUgY2hhbmNlIHRvIHJlYWxseSBhdXRoZW50
aWNhdGUgdGhlIGNvbmZpZGVudGlhbCBjbGllbnQgYmVmb3JlIHlvdSBpc3N1ZSB0aGUgdG9rZW4u
PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBraW5kIHJlZ2FyZHMsPGJyPg0K
Jmd0OyZndDsmZ3Q7IFRvcnN0ZW4uPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsgQW0gMjcuMTEuMjAxOCB1bSAxNjo1NyBzY2hyaWViIE5hdCBTYWtpbXVyYSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJh
QGdtYWlsLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyBJIGFtIG5vdCB0YWxraW5nIGFib3V0IFNQQS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
IFRoZSBjbGllbnQgaXMgYSByZWd1bGFyIGNvbmZpZGVudGlhbCBjbGllbnQgdGhhdCBpcyBydW5u
aW5nIG9uIGEgc2VydmVyLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyBCZXN0LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBO
YXQgU2FraW11cmE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAyMDE4PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7Ij7lubQ8L3NwYW4+MTE8c3BhbiBs
YW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVv
dDsiPuaciDwvc3Bhbj4yNzxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
77yt77yzIOOCtOOCt+ODg+OCryZxdW90OyI+5pelPC9zcGFuPig8c3BhbiBsYW5nPSJKQSIgc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDsiPueBqzwvc3Bh
bj4pIDE2OjU1IEppbSBNYW5pY28gJmx0OzxhIGhyZWY9Im1haWx0bzpqaW1AbWFuaWNvZGUuY29t
IiB0YXJnZXQ9Il9ibGFuayI+amltQG1hbmljb2RlLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsgTmF0LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyBIb3cgaXMgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBlc3RhYmxpc2hlZCBpbiBhIG1vZGVybiB3ZWIg
YnJvd3NlciBpbiB0aGUgaW1wbGljaXQgZmxvdz88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRva2VuIGJpbmRpbmcg
d2FzIHJlbW92ZWQgZnJvbSBDaHJvbWUgcmVjZW50bHkgZWZmZWN0aXZlbHkga2lsbGluZyBicm93
c2VyLWJhc2VkIFBvUCB0b2tlbnMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vaWRlbnRpdmVyc2UuY29tLzIwMTgvMTAvMzEvY2hy
b21lLXB1dHMtdG9rZW4tYmluZGluZy1pbi1hLWJpbmQvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw
czovL2lkZW50aXZlcnNlLmNvbS8yMDE4LzEwLzMxL2Nocm9tZS1wdXRzLXRva2VuLWJpbmRpbmct
aW4tYS1iaW5kLzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsgQWxvaGEsIEppbTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IE9uIDExLzI3LzE4IDk6MDAgUE0sIE5hdCBTYWtpbXVyYSB3cm90ZTo8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIGFjdHVhbGx5IC0xLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICYjNDM7MSBmb3IgcHVibGljIGNsaWVudCBh
bmQgdGhlIHRva2VucyB0aGF0IGFyZSBub3Qgc2VuZGVyL2tleSBjb25zdHJhaW5lZC48YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKdXN0IG5vdCBi
ZWluZyB1c2VkIHJpZ2h0IG5vdyBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgbm90IHVzZWZ1bC4u
IEluIGZhY3QsIEkgc2VlIGl0IGNvbWluZy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbXBs
aWNpdCAod2VsbCwgSHlicmlkIOKAnHRva2VuIGlkX3Rva2Vu4oCdIHJlYWxseSkgaXMgdmVyeSB1
c2VmdWwgaW4gY2VydGFpbiBjYXNlcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTcGVjaWZp
Y2FsbHksIHdoZW4gdGhlIGNsaWVudCBpcyBjb25maWRlbnRpYWwgKGJhc2VkIG9uIHB1YmxpYyBr
ZXkgcGFpciksIGFuZCB1c2VzIHNlbmRlciBjb25zdHJhaW5lZCAoa2V5LWNvbnN0cmFpbmVkKSB0
b2tlbiBzdWNoIGFzIHRoZSBvbmUgZXhwbGFpbmVkIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtanBvcC0wNCNzZWN0aW9uLTUiIHRh
cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVy
YS1vYXV0aC1qcG9wLTA0I3NlY3Rpb24tNTwvYT4sIGl0IGlzIHZlcnkgdXNlZnVsLjxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IChLZXktY29uc3RyYWluZWQgdG9rZW4gaXMgdGhlIHJlbWFpbmlu
ZyBwb3J0aW9uIG9mIHRoaXMgZHJhZnQgdGhhdCBkaWQgbm90IGdldCBpbmNvcnBvcmF0ZWQgaW4g
dGhlIE1UTFMgZHJhZnQuICk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBmYWN0IGl0IGlz
IHRoZSBvbmx5IHZpYWJsZSBtZXRob2QgZm9yIFNlbGYtSXNzdWVkIE9wZW5JRCBQcm92aWRlci48
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTbywg
dGhlIHRleHQgaXMgZ2VuZXJhbGx5IGdvb2QgYnV0IGl0IG5lZWRzIHRvIGJlIGNvbnN0cmFpbmVk
IGxpa2Ug4oCcVW5sZXNzIHRoZSBjbGllbnQgaXMgY29uZmlkZW50aWFsIGFuZCB0aGUgYWNjZXNz
IHRva2VuIGlzc3VlZCBpcyBrZXkgY29uc3RyYWluZWQsIC4uLiDigJw8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCZXN0LDxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5hdCBTYWtpbXVyYTxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIwMTg8c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDsiPuW5tDwvc3Bhbj4xMTxzcGFuIGxhbmc9
IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90OyI+
5pyIPC9zcGFuPjI3PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvvvK3v
vLMg44K044K344OD44KvJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIGxhbmc9IkpBIiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90OyI+54GrPC9zcGFuPikg
MTY6MDEgVmxhZGltaXIgRHpodXZpbm92DQogJmx0OzxhIGhyZWY9Im1haWx0bzp2bGFkaW1pckBj
b25uZWN0MmlkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9h
PiZndDs6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJiM0MzsxIHRvIHJlY29tbWVuZCB0aGUg
ZGVwcmVjYXRpb24gb2YgaW1wbGljaXQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkb24ndCBzZWUgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBr
ZWVwIGltcGxpY2l0IHdoZW4gdGhlcmUgaXMgYW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBl
c3RhYmxpc2hlZCBhbHRlcm5hdGl2ZSB0aGF0IGlzIG1vcmUgc2VjdXJlLjxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE91ciBkdXR5IGFzIFdHIGlz
IHRvIGdpdmUgZGV2ZWxvcGVycyB0aGUgYmVzdCBhbmQgbW9zdCBzZW5zaWJsZSBwcmFjdGljZS48
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDT1JT
IGFkb3B0aW9uIGlzIGN1cnJlbnRseSBhdCA5NCUgYWNjb3JkaW5nIHRvPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9jYW5pdXNlLmNvbS8jZmVhdD1jb3JzIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly9jYW5pdXNlLmNvbS8jZmVhdD1jb3JzPC9hPjxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFZsYWRpbWlyPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hhaXJt
YW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i
aHR0cDovL25hdC4iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LjwvYT4uPGEgaHJlZj0iaHR0
cDovL3Nha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYS5vcmcvPC9hPjxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tIDxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsgSmltIE1hbmljbzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgTWFuaWNvZGUgU2VjdXJpdHk8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6
Ly93d3cubWFuaWNvZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cubWFuaWNvZGUu
Y29tPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgLS0gPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBO
YXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDaGFpcm1hbiwgT3BlbklE
IEZvdW5kYXRpb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9uYXQuc2Fr
aW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm
PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv
YT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBP
cGVuaWQtc3BlY3MtYWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1h
aWx0bzpPcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPk9w
ZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBo
cmVmPSJodHRwOi8vbGlzdHMub3BlbmlkLm5ldC9tYWlsbWFuL2xpc3RpbmZvL29wZW5pZC1zcGVj
cy1hYiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2xpc3RzLm9wZW5pZC5uZXQvbWFpbG1hbi9s
aXN0aW5mby9vcGVuaWQtc3BlY3MtYWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u
PGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPcGVuaWQtc3BlY3MtYWIgbWFpbGlu
ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQu
bmV0IiB0YXJnZXQ9Il9ibGFuayI+T3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ8L2E+
PGJyPg0KPGEgaHJlZj0iaHR0cDovL2xpc3RzLm9wZW5pZC5uZXQvbWFpbG1hbi9saXN0aW5mby9v
cGVuaWQtc3BlY3MtYWIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGlzdHMub3BlbmlkLm5ldC9t
YWlsbWFuL2xpc3RpbmZvL29wZW5pZC1zcGVjcy1hYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_OSBPR01MB286955E2DF450308CE63EED0F9D00OSBPR01MB2869jpnp_--


From nobody Tue Nov 27 16:56:26 2018
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 2193C12875B for ; Tue, 27 Nov 2018 16:56:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0zF-55jKsvK for ; Tue, 27 Nov 2018 16:56:18 -0800 (PST)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id E914F12F18C for ; Tue, 27 Nov 2018 16:56:17 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id F01A5196864; Wed, 28 Nov 2018 09:56:16 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 7F1564E0046; Wed, 28 Nov 2018 09:56:16 +0900 (JST)
Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wAS0uGQM012692; Wed, 28 Nov 2018 09:56:16 +0900
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp with ESMTP id wAS0uGfT012691; Wed, 28 Nov 2018 09:56:16 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAS0uIjU054865; Wed, 28 Nov 2018 09:56:18 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wAS0uI9Q054864; Wed, 28 Nov 2018 09:56:18 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wAS0uIrd054861; Wed, 28 Nov 2018 09:56:18 +0900
Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM09PA.cu.nri.co.jp (172.159.253.51) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 09:56:14 +0900
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (23.103.139.152) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 09:56:14 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TDH8lg+MkTnJzZrx2q1qjkAIijzAQeQm3q0ow81HaVs=; b=VLtv+xiEQdR0YZ3mP80K1cKm1WcckDLMw1CN1vgRIF7gke182v6pI7lKySkRpj0qR/eJ7CbNkOkFtAFqT0C+h99bdrrZo53vJ/6bj2V3RG2AYMX/u01KMoZY5DZUAgQMiw/M+JBmCxgeM9GgQJEWB7yGHXklR+IHAksop5hF79Y=
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB3110.jpnprd01.prod.outlook.com (52.134.254.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.20; Wed, 28 Nov 2018 00:56:13 +0000
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Wed, 28 Nov 2018 00:56:13 +0000
From: n-sakimura 
To: Tom Jones , Nat Sakimura 
CC: Artifact Binding/Connect Working Group ,  "oauth@ietf.org" , "jim@manicode.com" 
Thread-Topic: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AQHUhmmvazGUOUu3zUW6qxGAce3IH6VjxxqAgAA7dICAAAaRgIAACXuAgAACdACAAAdoAIAAIAUAgAAE5YCAAAYKAIAAClWAgAAIjOA=
Date: Wed, 28 Nov 2018 00:56:13 +0000
Message-ID: 
References:  <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com>  <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>  <327B68FD-9449-4809-A3B8-BC79C5B1D42C@lodderstedt.net>   <99e3a87e-1904-b756-d3c2-936ea5bb5b6e@ve7jtb.com> <02FFD6C6-1EDB-460D-BB6E-7975362DD377@lodderstedt.net>    
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailadviser: 20170719
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [37.71.28.34]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; OSBPR01MB3110; 6:oho/V3pUs8VoBMKyMcn78oXxeH3zeT5c3ECJZae6lFGIzp/SSw8mfUkKccubav3ZliyhAUsmKSK4/v9IsiAd3LqPBJ8RHjLAAsGKy7zSwXqs3rMoiJoPIB2WzwFP/aKF+MrSEmIWPJJ4vub3hWwkhLrsqG0/mRUrph3ZnWHW0U4logbwbrfqy8v+FpmV5lHl8HAMeOWz9n/tlEaZDNOhASs3atWAQvj1Yo28X8Tsy6sZd3CWNLRaYXRcX3Mmgp1GL2mTbb/y5AIZRn3QgunjieEKAU4cm2Rnh1FbF29WeoG5qsfOIp5joWchgp09YFwRJuSQxn/4nMUA80ZCSN6GIFWxRyfiTn+axWP08p+A0Ix5xXAnL8vQyGujzyVKqJl5667psHoYvOohaZJrlGXlo6HO6LC2Kb3djru2GS7fCJPUka/QnJUMq5NbhXwVoom+umyLQo51T6cmhS5qas7u3g==; 5:3mmpiuBg/KC2M1OUTSdeF771JUwd4nHuDHpKGkOguxqr6F6RzWy5gB6uLGIhDeE+ANcXygj6qNJZhEPuQ7KZvk2NqPeV4KhmtqiYHC/RbPSi9UsPXw2MIxpPhsFYY+jMfSmDJTAOKoFehnYNSV+daVjzUMa1rehqcO8FFN4LNkE=; 7:/TROIVwObKenykS98Ai4mNKB4Yqle3iTNmaOKdcO6RmWxkr2sJWAsez+2bugV5rnp4N2xGuxtIkaQCC0+XwwPHlgjkBTZnkI9s33WIUw0HMzZpBvRxcOi2vZF2B2hxVfvrP3taiCKp8GX1OkD2fGjg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: db25075d-f124-42b3-eb0d-08d654cc4b6a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB3110; 
x-ms-traffictypediagnostic: OSBPR01MB3110:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231443)(944501410)(4982022)(52105112)(93006095)(93001095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(2016111802025)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB3110; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB3110; 
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(39840400004)(376002)(396003)(365934003)(189003)(199004)(86362001)(7110500001)(551544002)(74316002)(4326008)(68736007)(606006)(508600001)(76176011)(39060400002)(316002)(186003)(25786009)(5660300001)(71190400001)(53546011)(6506007)(71200400001)(4744004)(66574009)(26005)(93886005)(7736002)(561944003)(10710500007)(102836004)(11346002)(66066001)(53946003)(2906002)(476003)(229853002)(14444005)(53936002)(14454004)(256004)(446003)(6116002)(6436002)(3846002)(33656002)(790700001)(236005)(15650500001)(486006)(2420400007)(9686003)(6306002)(54896002)(74482002)(55016002)(8676002)(7696005)(97736004)(6246003)(966005)(81156014)(81166006)(106356001)(110136005)(53376002)(8936002)(105586002)(99286004)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB3110; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-microsoft-antispam-message-info: fkr8WlQA9nV/3XB3u6BlWWX7s6OLbSL38g1dYWyiPc1rT7tYuwqyYsrOj0P2ws5e6RlrkdpT2rAnNFA0AFiHdvt+WCUkEZf7+onoZRKVkcFl1wpylVnIBSoEJYShMb4knfutg1WmAKrdpj6r/eBgS5GYA81qA+iG1o14AV9+T15fyVr2UkEuI/52e6gTv+0zts5BTefHr+OZjlQxdyXJGstV6V3hJEzqfH93RwD1mgTT4CLI9FjjMuWrGnhhJqRaEFI+u+zPLngiavzv8bEx6nd9v41B+wx9X1qEzeVaDrqBggeChrb9pfk/ujDBTbJLLmsyWFhsc/sU7sy0kw4tr6PZMHrvz5zOxzVxSdzVR28=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB286966400838D4CD0CE0214DF9D10OSBPR01MB2869jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: db25075d-f124-42b3-eb0d-08d654cc4b6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 00:56:13.3222 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB3110
X-OrganizationHeadersPreserved: OSBPR01MB3110.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 00:56:23 -0000

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

Tm90IHJlYWxseS4NCg0KSXQgaXMgbm90IGEgcmVxdWlyZW1lbnQgb2YgU0lPUCB0byBsZXZlcmFn
ZSB0aGUgZGV2aWNl4oCZcyBzZWN1cmUgZWxlbWVudCB0byBjcmVhdGUga2V5LXBhaXJzLiBTbywg
dGhlIGtleXMgY2FuIGJlIGV4cG9ydGVkIGFuZCBwb3J0ZWQgdG8gb3RoZXIgZGV2aWNlcyBhcyB3
ZWxsLiBUaGVyZSBjb3VsZCBiZSBrZXkgc3luY2luZyBtZWNoYW5pc20gYXMgd2VsbCwgbGlrZSAx
cGFzc3dvcmQsIGJ1dCBpdCBpcyBub3Qgc3RhbmRhcmRpemVkLg0KDQpSZTogZGlzY292ZXJ5DQpJ
biB0aGUgdXNlLWNhc2Ugb2YgU0lPUCwgZnJvbSB0aGUgY2xpZW504oCZcyBwb2ludCBvZiB2aWV3
LCBTSU9QIGlzIGFsd2F5cyBpbiB0aGUgdXNlcuKAmXMgZGV2aWNlLCBpLmUuLCBsb2NhbGhvc3Qu
IFNvLCB0aGVyZSBpcyBubyBuZWVkIGZvciBkaXNjb3ZlcnkuDQoNCkhhdmluZyBzYWlkIHRoYXQ6
IFNJT1Agc3BlYyBpcyBhIGJpdCBvbGQgYW5kIGRlcGVuZHMgb24gY3VzdG9tIHNjaGVtZSBvbiBp
T1MuIE5vdyBpT1MgaGFzIG5ld2VyIGNhcGFiaWxpdHkgbGlrZSBjbGFpbWVkIFVSSSwgd2hpY2gg
aXMgbW9yZSBzZWN1cmUuIFNvLCBoYXZpbmcgYSBkaXNjb3ZlcnkgbWVjaGFuaXNtIHRoYXQgcmV0
dXJucyAgW1NlbGYtaXNzdWVkIElkZW50aWZpZXIg4oCTIGRldmljZSB0eXBlIOKAkyBjbGFpbWVk
IFVSSV0gdHJpcGxlIGtpbmQgb2YgdGhpbmcgbWF5IGJlIHVzZWZ1bC4gKE5vdGUsIEkganVzdCBj
YW1lIHVwIHdpdGggaXQgbm93IGFuZCBpdOKAmXMgMiBBTSBoZXJlIHNvIGl0IG1heSBiZSBhIGJh
ZCBpZGVhIGFmdGVyIGFsbC4pDQoNCg0KTmF0IFNha2ltdXJhIDxuLXNha2ltdXJhQG5yaS5jby5q
cDxtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanA+Pg0KDQpQTEVBU0UgUkVBRCA6VGhpcyBlLW1h
aWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBv
bmx5LiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg
dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgZS1tYWlsLg0KDQoNCg0KRnJvbTogVG9tIEpvbmVz
IDx0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJl
ciAyOCwgMjAxOCA5OjE0IEFNDQpUbzogTmF0IFNha2ltdXJhIDxuLXNha2ltdXJhQG5yaS5jby5q
cD4NCkNjOiBBcnRpZmFjdCBCaW5kaW5nL0Nvbm5lY3QgV29ya2luZyBHcm91cCA8b3BlbmlkLXNw
ZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ+OyBvYXV0aEBpZXRmLm9yZzsgamltQG1hbmljb2RlLmNv
bQ0KU3ViamVjdDogUmU6IFtPcGVuaWQtc3BlY3MtYWJdIFtPQVVUSC1XR10gT0F1dGggU2VjdXJp
dHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBs
aWNpdA0KDQpJIHNlZSwgc28gdGhlbiB0aGUgc2VsZi1pc3N1ZWQgSUQgaXMgZGV2aWNlLWxvY2tl
ZD8gaXQgc291bmRzIG1vcmUgbGlrZSBhIGRldmljZSBJRCB0aGFuIGEgdXNlciBJRC4gIFdoaWNo
IGlzIHVzZWZ1bCwgYnV0IG5vdCB0b28gaGVscGZ1bCBpbiBhIG11bHRpcGxlIGRldmljZSB3b3Js
ZC4gVGhlIHNjcmVlbiBpIGFtIHVzaW5nIHJpZ2h0IG5vdyBoYXMgMyBkZXZpY2VzIGRyaXZpbmcg
aXQgaW4gb25lIGZvcm0gb3IgYW5vdGhlci4gSXMgdGhlcmUgYW55IHdheSB0aGF0IGEgc2VsZi1p
c3N1ZWQgSUQgb2YgdGhpcyBmb3JtIGNhbiBiZSBtYWRlIHVzZWZ1bCBpbiB0b2RheSdzIHdvcmxk
PyAgQlRXIC0gaSBsaWtlIHRoZSBpZGVhIG9mIFVSTidzIHJhdGhlciB0aGFuIFVSTCdzLCBidXQg
c29tZSByZXNvbHZlciBjYXBhYmlsaXR5IHNlZW1zIHRvIGJlIGEgcmVxdWlyZW1lbnQ/DQpQZWFj
ZSAuLnRvbQ0KDQoNCk9uIFR1ZSwgTm92IDI3LCAyMDE4IGF0IDM6NTAgUE0gbi1zYWtpbXVyYSA8
bi1zYWtpbXVyYUBucmkuY28uanA8bWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwPj4gd3JvdGU6
DQpUb20sDQoNCkl0IGlzIGdvb2QgdG8gaGVhciB0aGF0IHlvdSB3aWxsIGJlIHRoZXJlLg0KSSB1
bmRlcnN0YW5kIEpvaG4gd2lsbCBhbHNvIGJlIHRoZXJlLg0KDQpUbyB5b3VyIHF1ZXN0aW9uLCBz
ZWxmLWlzc3VlZCBJRCBkb2VzIG5vdCByZXF1aXJlIGEgKHNlbWktKXBlcm1hbmVudCBVUkwgYXMg
dGhlIHVzZXLigJlzIGlkZW50aWZpZXIsIGFzIGl0IGlzIGFsd2F5cyDigJxsb2NhbGhvc3TigJ0u
DQpUaGUgaWRlbnRpZmllciBpcyBkZXJpdmVkIGFzIHRoZSBoYXNoIG9mIHRoZSBwdWJsaWMga2V5
IHRoYXQgd2FzIGdlbmVyYXRlZCBieSB0aGUgU2VsZi1pc3N1ZWQgT1AuDQpJZiB5b3VyIHF1ZXN0
aW9uIHdhcyDigJxVUknigJ0sIHRoZW4geWVzLiBJdHMgaXNzdWVyIGlzIGFsd2F5cyBodHRwczov
L3NlbGYtaXNzdWVkLm1lIGFuZCB0aGVyZSBpcyBhIGBzdWJgIGZvciB0aGF0IGlkZW50aXR5LCBz
byBzeW50aGVzaXplZCBVUkkgZm9yIHRoZSB1c2VyIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlIGh0
dHBzOi8vc2VsZi1pc3N1ZWQubWUve3N1Yn08aHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS8lN2JzdWIl
N2Q+IHdoZXJlIHtzdWJ9IHJlcHJlc2VudHMgdGhlIHZhbHVlIG9mIHRoZSBgc3ViYCBjbGFpbS4g
YHN1YmAgY2xhaW0gdmFsdWUgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KDQpzdWIgKHN1YmplY3Qp
IENsYWltIHZhbHVlIGlzIHRoZSBiYXNlNjR1cmwgZW5jb2RlZCByZXByZXNlbnRhdGlvbiBvZiB0
aGUgdGh1bWJwcmludCBvZiB0aGUga2V5IGluIHRoZSBzdWJfandrIENsYWltLiBUaGlzIHRodW1i
cHJpbnQgdmFsdWUgaXMgY29tcHV0ZWQgYXMgdGhlIFNIQS0yNTYgaGFzaCBvZiB0aGUgb2N0ZXRz
IG9mIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiBhIEpXSyBjb25zdHJ1Y3RlZCBjb250YWlu
aW5nIG9ubHkgdGhlIFJFUVVJUkVEIG1lbWJlcnMgdG8gcmVwcmVzZW50IHRoZSBrZXksIHdpdGgg
dGhlIG1lbWJlciBuYW1lcyBzb3J0ZWQgaW50byBsZXhpY29ncmFwaGljIG9yZGVyLCBhbmQgd2l0
aCBubyB3aGl0ZSBzcGFjZSBvciBsaW5lIGJyZWFrcy4gRm9yIGluc3RhbmNlLCB3aGVuIHRoZSBr
dHkgdmFsdWUgaXMgUlNBLCB0aGUgbWVtYmVyIG5hbWVzIGUsIGt0eSwgYW5kIG4gYXJlIHRoZSBv
bmVzIHByZXNlbnQgaW4gdGhlIGNvbnN0cnVjdGVkIEpXSyB1c2VkIGluIHRoZSB0aHVtYnByaW50
IGNvbXB1dGF0aW9uIGFuZCBhcHBlYXIgaW4gdGhhdCBvcmRlcjsgd2hlbiB0aGUga3R5IHZhbHVl
IGlzIEVDLCB0aGUgbWVtYmVyIG5hbWVzIGNydiwga3R5LCB4LCBhbmQgeSBhcmUgcHJlc2VudCBp
biB0aGF0IG9yZGVyLiBOb3RlIHRoYXQgdGhpcyB0aHVtYnByaW50IGNhbGN1bGF0aW9uIGlzIHRo
ZSBzYW1lIGFzIHRoYXQgZGVmaW5lZCBpbiB0aGUgSldLIFRodW1icHJpbnQgW0pXSy5UaHVtYnBy
aW50XUpvbmVzLCBNLiwg4oCcSlNPTiBXZWIgS2V5IChKV0spIFRodW1icHJpbnQs4oCdIEp1bHkg
MjAxNC48aHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUtMV8wLmh0
bWwjSldLLlRodW1icHJpbnQ+IHNwZWNpZmljYXRpb24uDQoNClNvLCB5ZXMuIFRoZSBzdHJpbmcg
aHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS97c3VifTxodHRwczovL3NlbGYtaXNzdWVkLm1lLyU3YnN1
YiU3ZD4gaXMgcHJvYmFiaWxpc3RpY2FsbHkgdW5pcXVlIGFuZCDigJxwZXJzaXN0ZW504oCdIChi
ZXR0ZXIgdG8gcGhyYXNlIGl0IGFzIOKAmG5ldmVyIHJlLWFzc2lnbmVk4oCZKS4NCg0KVGhlIHJl
YXNvbiBpdCBpcyBub3QgYSDigJxVUkzigJ0gaXMgdGhhdCB5b3UgY2Fubm90IHJlYWNoIGl0LiBI
b3dldmVyLCBJdCBpcyBhIOKAnFVSSeKAnS4NCg0KQ2hlZXJzLA0KDQoNCk5hdCBTYWtpbXVyYSA8
bi1zYWtpbXVyYUBucmkuY28uanA8bWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwPj4NCg0KUExF
QVNFIFJFQUQgOlRoaXMgZS1tYWlsIGlzIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRo
ZSBuYW1lZCByZWNpcGllbnQgb25seS4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBp
ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGUtbWFpbC4NCg0K
DQoNCkZyb206IE9wZW5pZC1zcGVjcy1hYiA8b3BlbmlkLXNwZWNzLWFiLWJvdW5jZXNAbGlzdHMu
b3BlbmlkLm5ldDxtYWlsdG86b3BlbmlkLXNwZWNzLWFiLWJvdW5jZXNAbGlzdHMub3BlbmlkLm5l
dD4+IE9uIEJlaGFsZiBPZiBUb20gSm9uZXMgdmlhIE9wZW5pZC1zcGVjcy1hYg0KU2VudDogV2Vk
bmVzZGF5LCBOb3ZlbWJlciAyOCwgMjAxOCA4OjE2IEFNDQpUbzogQXJ0aWZhY3QgQmluZGluZy9D
b25uZWN0IFdvcmtpbmcgR3JvdXAgPG9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PG1h
aWx0bzpvcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldD4+DQpDYzogVG9tIEpvbmVzIDx0
aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPG1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21h
aWwuY29tPj47IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz47IGppbUBtYW5p
Y29kZS5jb208bWFpbHRvOmppbUBtYW5pY29kZS5jb20+DQpTdWJqZWN0OiBSZTogW09wZW5pZC1z
cGVjcy1hYl0gW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1
dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0DQoNCkkgYW0gaGVhZGVkIHRvIGEg
dzNjIG1lZXRpbmcgdGhhdCB3aWxsIHRhbGsgYWJvdXQgRElEcyBmb3IgdGhlIGZ1dHVyZS4gSSB3
b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgaWYgdGhlIHNlbGYtaXNzdWVkIElEIHJlcXVpcmVzIChv
ciBzaG91bGQgcmVxdWlyZSkgc29tZSBzb3J0IG9mIChzZW1pKSBwZXJtYW5lbnQgVVJMIG9uIHRo
ZSBpbnRlcm5ldC4gKGluY2x1ZGluZyBvbiBhIGJsb2NrLWNoYWluLCBmb3IgZXhhbXBsZS4pICBX
aXRob3V0IHRoYXQgaSBjYW5ub3QgdW5kZXJzdGFuZCB3aGF0IGEgc2VsZi1pc3N1ZWQgSUQgbWln
aHQgZXZlbiBtZWFuLg0KDQpQZWFjZSAuLnRvbQ0KDQoNCk9uIFR1ZSwgTm92IDI3LCAyMDE4IGF0
IDM6MDYgUE0gTmF0IFNha2ltdXJhIHZpYSBPcGVuaWQtc3BlY3MtYWIgPG9wZW5pZC1zcGVjcy1h
YkBsaXN0cy5vcGVuaWQubmV0PG1haWx0bzpvcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5l
dD4+IHdyb3RlOg0KU2VsZiBJc3N1ZWQgT1AgaXMgZGVzY3JpYmVkIGluIENoYXB0ZXIgNyBvZiB0
aGUgT3BlbklEIENvbm5lY3QgQ29yZSAxLjAuDQpJdCBsaXZlcyBvbiBhIGxvY2FsIG1hY2hpbmUs
IHR5cGljYWxseSBhIHBob25lLiBFdmVuIGlmIGl0IGRpZCBwcm92aWRlIGFuIGF1dGhvcml6YXRp
b24gY29kZSB0byB0aGUgY2xpZW50LCB0aGUgY2xpZW50IGNhbm5vdCBlc3RhYmxpc2ggYSBkaXJl
Y3QgY29ubmVjdGlvbiB0byB0aGUgbG9jYWwgbWFjaGluZSAocGhvbmUpIGFzIGl0IGlzIG5vdCBh
ZGRyZXNzYWJsZS4gVGhlcmVmb3JlLCBhIHRva2VuIGVuZHBvaW50IGNhbm5vdCBiZSBwcm92aWRl
ZCB1bmxlc3MgaXQgaXMgY291cGxlZCB3aXRoIHNvbWUga2luZCBvZiBjbG91ZC1iYXNlZCBzZXJ2
aWNlLCB3aGljaCB3b3VsZCBuZWdhdGUgc29tZSBvZiB0aGUgdmVyeSByZWFzb24gZm9yIGhhdmlu
ZyB0aGUgU2VsZi1pc3N1ZWQgT1AuIEluIG90aGVyIHdvcmRzLCBvbmx5IHRoZSB2aWFibGUgY29t
bXVuaWNhdGlvbiBjaGFubmVsIGJldHdlZW4gdGhlIFNJT1AgYW5kIHRoZSBjbGllbnQgaXMgdGhl
IGZyb250IGNoYW5uZWwuIFRoZSBzaXR1YXRpb24gY291bGQgYmUgdHJ1ZSB0byBvdGhlciAid2Fs
bGV0IiB0eXBlIG9mIGltcGxlbWVudGF0aW9ucy4NCg0KVGhpcyBpcyBvbmUgb2YgdGhlIGV4b3Rp
YyBmZWF0dXJlcyBvZiBPcGVuSUQgQ29ubmVjdCB0aGF0IG5ldmVyIGdvdCBhIHRyYWN0aW9uIGJ1
dCBpdCBpcyBnZXR0aW5nIGEgcmVuZXdlZCBpbnRlcmVzdCBhcyAiU2VsZi1zb3ZlcmVpZ24gSWRl
bnRpdHkiIGdhaW5lZCBzb21lIGludGVyZXN0Lg0KDQoNCg0KT24gV2VkLCBOb3YgMjgsIDIwMTgg
YXQgNjowMyBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt
YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCkkgc3RpbGwgZG9u4oCZdCB1
bmRlcnN0YW5kIHdoeSB0aGUgdXNlIGNhc2UgbXVzdCBiZSBzb2x2ZWQgdXNpbmcgYSBmbG93IGlz
c3Vpbmcgc29tZXRoaW5nIGluIHRoZSBmcm9udCBjaGFubmVsLg0KDQpJIHdvdWxkIGFsc28gbGlr
ZSB0byB0YWtlIGEgY2xvc2VyIGxvb2suIENhbiB5b3Ugb3IgTmF0IHByb3ZpZGUgcG9pbnRlcnMg
dG8gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zPw0KDQo+IEFtIDI3LjExLjIwMTggdW0gMjE6MzYg
c2NocmllYiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3
anRiLmNvbT4+Og0KPg0KPiBJIHVuZGVyc3RhbmQgdGhhdCwgYnV0IGhhdCBpcyBOYXQncyBjb25j
ZXJuIGFzIEkgdW5kZXJzdGFuZCBpdC4NCj4NCj4gV2hlbiB3ZSBzYXkgbm8gaW1wbGljaXQgcGVv
cGxlLCBoYXZlIGEgcHJvYmxlbSBiZWNhdXNlIGltcGxpY2l0IGlzIGltcHJlY2lzZS4NCj4NCj4g
V2UgYXJlIHNheWluZyBubyBBVCByZXR1cm5lZCBpbiB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgYXV0
aG9yaXphdGlvbiBlbmRwb2ludC4NCj4NCj4gTmF0IHBvaW50cyBvdXQgdGhhdCBpZF90b2tlbiBt
YXkgY29udGFpbiBBVCBmb3IgdGhlIHNlbGYgaXNzdWVkIGNsaWVudC4NCj4NCj4gU28gdW5sZXNz
IHdlIHNheSB0aGF0IGlzIE9LIGlmIHRoZSBBVCBhcmUgc2VuZGVyIGNvbnN0cmFpbmVkIHdlIHdp
bmQgdXAgaW1wbHlpbmcgdGhhdCBhIE9wZW5JRCBwcm9maWxlIG9mIE9BdXRoIGlzIGluIHZpb2xh
dGlvbiBvZiB0aGUgQkNQLg0KPg0KPiBJIGFtIGp1c3QgdHJ5aW5nIHRvIG1ha2Ugc3VyZSBldmVy
eW9uZSBpcyBvbiB0aGUgc2FtZSBwYWdlIHdpdGggd2h5IE5hdCB3YXMgLTEuDQo+DQo+IEl0IHJl
YWxseSBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBTUEEgdXNlIGNhc2UuDQo+DQo+IEpvaG4g
Qi4NCj4NCj4+IE9uIDExLzI3LzIwMTggNToyOCBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90
ZToNCj4+IEhpIEpvaG4sDQo+Pg0KPj4gYXMgeW91IHNhaWQsIHNlbGYgaXNzdWVkIElEUHMgKGh0
dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sI1NlbGZJ
c3N1ZWQpIGFyZSBzdXBwb3NlZCB0byBwcm92aWRlIHRoZSByZXNwb25zZSB0eXBlIOKAnmlkX3Rv
a2Vu4oCcIG9ubHkuIEkgZG9u4oCZdCB0aGluayB0aGUgcHJvcG9zYWwgYmVpbmcgZGlzY3Vzc2Vk
IGhlcmUgaXMgcmVsYXRlZCB0byB0aGlzIE9JREMgbW9kZS4NCj4+DQo+PiBiZXN0IHJlZ2FyZHMs
DQo+PiBUb3JzdGVuLg0KPj4NCj4+PiBBbSAyNy4xMS4yMDE4IHVtIDIwOjU0IHNjaHJpZWIgSm9o
biBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoN
Cj4+Pg0KPj4+IEkgdGFsa2VkIHRvIE5hdCBhYm91dCB0aGlzIGEgYml0IHRvZGF5Lg0KPj4+DQo+
Pj4gVGhlIHRoaW5nIGhlIGlzIGNvbmNlcm5lZCBhYm91dCBpcyBtb3N0bHkgYXJvdW5kIHRoZSBz
ZWxmIGlzc3VlZCBJRFAgdGhhdCBkb2Vzbid0IGhhdmUgYSB0b2tlbiBlbmRwb2ludChhdGxlYXN0
IG5vdCBlYXNhbHkpLg0KPj4+DQo+Pj4gVGhlIG1haW4gdXNlIGNhc2UgZm9yIHRoYXQgaXMgdGhl
IGlkX3Rva2VuIHJlc3BvbnNlIHR5cGUgd2hlcmUgY2xhaW1zIGFyZSByZXR1bmVkIGluIHRoZSBp
ZF90b2tlbi4NCj4+Pg0KPj4+IEJlY2F1c2UgaXQgaXMgZnJhZ21lbnQgZW5jb2RlZCBzb21lIHBl
b3BsZSBjYWxsIHRoYXQgaW1wbGljaXQuICAgVGhhdCBpcyBub3Qgd2hhdCB3ZSBhcmUgdHJ5aW5n
IHRvIHN0b3AuDQo+Pj4NCj4+PiBJbiBzb21lIGNhc2VzIGluIHRoYXQgZmxvdyB0aGVyZSBtYXkg
YmUgZGlzdHJpYnV0ZWQgY2xhaW1zIHJldHVybmVkIHdpdGggYWNjZXNzIFRva2VuIGluc2lkZSB0
aGUgaWRfdG9rZW4uICAgIEkgdGhpbmsgbW9zdCBwZW9wbGUgd291bGQgYWdyZWUgdGhhdCB0aG9z
ZSBzaG91bGQgYmUgcG9wIG9yIHNlbmRlciBjb25zdHJhaW5lZCB0b2tlbnMuDQo+Pj4NCj4+PiBJ
biB0aGUgY2FzZSBvZiBzZWxmIGlzc3VlZCB0aGUgUlAgd291bGQgYmUgYSBzZXJ2ZXIgYW5kIGNv
dWxkIGRvIHNlbmRlciBjb25zdHJhaW5lZCB2aWEgc29tZSBtZWNoaW5pc2ltIHRoYXQgaXMgeWV0
IHRvIGJlIGRlZmluZWQuDQo+Pj4NCj4+PiBTbyBpZiBzb21lb25lIHdhbnRlZCB0byByZXR1cm4g
YSBhY2Nlc3MgdG9rZW4gaW4gYSBpZF90b2tlbiB0byBkbyBkaXN0cmlidXRlZCBjbGFpbXMgSSBk
b24ndCB0aGluayB3ZSBoYXZlIGEgcHJvYmxlbSB3aXRoIHRoYXQgYXMgbG9uZyBhcyB0aGUgdG9r
ZW4gaXMgcHJvdGVjdGVkIGJ5IGJlaW5nIHNlbmRlciBjb25zdHJhaW5lZCBpbiBzb21lIHJlYXNv
bmFibGUgd2F5Lg0KPj4+DQo+Pj4gVGhpcyBpcyBhIHRvdWNoIGh5cG90aGV0aWNhbCBmcm9tIHRo
ZSBiYXNpYyBPQXV0aCBwZXJzcGVjdGl2ZSwgc28gSSBkb24ndCBrbm93IGhvdyBkZWVwIHdlIHdh
bnQgdG8gZ28gaW50byBpdC4NCj4+Pg0KPj4+IEkgdGhpbmsgdGhlIHBvaW50IGlzIG5vdCB0byBh
Y2NpZGVudGx5IHByb2hpYml0IHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGRvbmUgaW4gZnV0dXJl
Lg0KPj4+DQo+Pj4gSSBhbHNvIHRoaW5rIHdlIHNob3VsZCBub3QgY29uZmxhdGUgY29uZmlkZW50
aWFsIGNsaWVudHMgdGhhdCBjYW4gYXV0aGVudGljYXRlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3
aXRoIHNlbmRlciBjb25zdHJhaW5lZC9Qb1AgY2xpZW50cyB0aGF0IGNhbiBkZWFsIHdpdGggYm91
bmQgdG9rZW5zLiAgIFllcyBib3RoIGhhdmUga2V5cyBidXQgaXQgaXMgYmV0dGVyIHRvIGRlc2Ny
aWJlIHRoZW0gc2VwYXJhdGVseS4NCj4+Pg0KPj4+IEpvaG4gQi4NCj4+Pg0KPj4+IE9uIFR1ZSwg
Tm92IDI3LCAyMDE4LCA0OjMwIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgdmlhIE9wZW5pZC1zcGVj
cy1hYiA8b3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ8bWFpbHRvOm9wZW5pZC1zcGVj
cy1hYkBsaXN0cy5vcGVuaWQubmV0PiB3cm90ZToNCj4+PiBIaSBOYXQsDQo+Pj4NCj4+PiBJIHVu
ZGVyc3RhbmQgeW91IGFyZSBzYXlpbmcgeW91ciBkcmFmdCBjb3VsZCBwcm92aWRlIGNsaWVudHMg
d2l0aCBhbiBhcHBsaWNhdGlvbiBsZXZlbCBtZWNoYW5pc20gdG8gc2VuZGVyIGNvbnN0cmFpbiBh
Y2Nlc3MgdG9rZW5zLiBUaGF04oCZcyBncmVhdCENCj4+Pg0KPj4+IEJ1dCBJIGRvbuKAmXQgc2Vl
IGEgYmluZGluZyB0byByZXNwb25zZSB0eXBlIOKAnnRva2VuIGlkX3Rva2Vu4oCcLiBXaHkgZG8g
eW91IHdhbnQgdG8gZXhwb3NlIHRoZSB0b2tlbnMgdmlhIHRoZSBVUkwgdG8gYXR0YWNrZXJzPw0K
Pj4+DQo+Pj4gWW91IGNvdWxkIGVhc2lseSB1c2UgeW91ciBtZWNoYW5pc20gd2l0aCBjb2RlLiBU
aGF0IHdvdWxkIGFsc28gZ2l2ZSB5b3UgdGhlIGNoYW5jZSB0byByZWFsbHkgYXV0aGVudGljYXRl
IHRoZSBjb25maWRlbnRpYWwgY2xpZW50IGJlZm9yZSB5b3UgaXNzdWUgdGhlIHRva2VuLg0KPj4+
DQo+Pj4ga2luZCByZWdhcmRzLA0KPj4+IFRvcnN0ZW4uDQo+Pj4NCj4+Pj4gQW0gMjcuMTEuMjAx
OCB1bSAxNjo1NyBzY2hyaWViIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0
bzpzYWtpbXVyYUBnbWFpbC5jb20+PjoNCj4+Pj4NCj4+Pj4gSSBhbSBub3QgdGFsa2luZyBhYm91
dCBTUEEuDQo+Pj4+IFRoZSBjbGllbnQgaXMgYSByZWd1bGFyIGNvbmZpZGVudGlhbCBjbGllbnQg
dGhhdCBpcyBydW5uaW5nIG9uIGEgc2VydmVyLg0KPj4+Pg0KPj4+PiBCZXN0LA0KPj4+Pg0KPj4+
PiBOYXQgU2FraW11cmENCj4+Pj4NCj4+Pj4NCj4+Pj4gMjAxOOW5tDEx5pyIMjfml6Uo54GrKSAx
Njo1NSBKaW0gTWFuaWNvIDxqaW1AbWFuaWNvZGUuY29tPG1haWx0bzpqaW1AbWFuaWNvZGUuY29t
Pj46DQo+Pj4+IE5hdCwNCj4+Pj4NCj4+Pj4gSG93IGlzIHByb29mIG9mIHBvc3Nlc3Npb24gZXN0
YWJsaXNoZWQgaW4gYSBtb2Rlcm4gd2ViIGJyb3dzZXIgaW4gdGhlIGltcGxpY2l0IGZsb3c/DQo+
Pj4+DQo+Pj4+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0b2tlbiBiaW5kaW5nIHdhcyByZW1v
dmVkIGZyb20gQ2hyb21lIHJlY2VudGx5IGVmZmVjdGl2ZWx5IGtpbGxpbmcgYnJvd3Nlci1iYXNl
ZCBQb1AgdG9rZW5zLg0KPj4+Pg0KPj4+PiBodHRwczovL2lkZW50aXZlcnNlLmNvbS8yMDE4LzEw
LzMxL2Nocm9tZS1wdXRzLXRva2VuLWJpbmRpbmctaW4tYS1iaW5kLw0KPj4+Pg0KPj4+PiBBbSBJ
IG1pc3Npbmcgc29tZXRoaW5nPw0KPj4+Pg0KPj4+PiBBbG9oYSwgSmltDQo+Pj4+DQo+Pj4+DQo+
Pj4+DQo+Pj4+PiBPbiAxMS8yNy8xOCA5OjAwIFBNLCBOYXQgU2FraW11cmEgd3JvdGU6DQo+Pj4+
PiBJIGFtIGFjdHVhbGx5IC0xLg0KPj4+Pj4NCj4+Pj4+ICsxIGZvciBwdWJsaWMgY2xpZW50IGFu
ZCB0aGUgdG9rZW5zIHRoYXQgYXJlIG5vdCBzZW5kZXIva2V5IGNvbnN0cmFpbmVkLg0KPj4+Pj4N
Cj4+Pj4+IEp1c3Qgbm90IGJlaW5nIHVzZWQgcmlnaHQgbm93IGRvZXMgbm90IG1lYW4gdGhhdCBp
dCBpcyBub3QgdXNlZnVsLi4gSW4gZmFjdCwgSSBzZWUgaXQgY29taW5nLg0KPj4+Pj4gSW1wbGlj
aXQgKHdlbGwsIEh5YnJpZCDigJx0b2tlbiBpZF90b2tlbuKAnSByZWFsbHkpIGlzIHZlcnkgdXNl
ZnVsIGluIGNlcnRhaW4gY2FzZXMuDQo+Pj4+PiBTcGVjaWZpY2FsbHksIHdoZW4gdGhlIGNsaWVu
dCBpcyBjb25maWRlbnRpYWwgKGJhc2VkIG9uIHB1YmxpYyBrZXkgcGFpciksIGFuZCB1c2VzIHNl
bmRlciBjb25zdHJhaW5lZCAoa2V5LWNvbnN0cmFpbmVkKSB0b2tlbiBzdWNoIGFzIHRoZSBvbmUg
ZXhwbGFpbmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1v
YXV0aC1qcG9wLTA0I3NlY3Rpb24tNSwgaXQgaXMgdmVyeSB1c2VmdWwuDQo+Pj4+PiAoS2V5LWNv
bnN0cmFpbmVkIHRva2VuIGlzIHRoZSByZW1haW5pbmcgcG9ydGlvbiBvZiB0aGlzIGRyYWZ0IHRo
YXQgZGlkIG5vdCBnZXQgaW5jb3Jwb3JhdGVkIGluIHRoZSBNVExTIGRyYWZ0LiApDQo+Pj4+PiBJ
biBmYWN0IGl0IGlzIHRoZSBvbmx5IHZpYWJsZSBtZXRob2QgZm9yIFNlbGYtSXNzdWVkIE9wZW5J
RCBQcm92aWRlci4NCj4+Pj4+DQo+Pj4+PiBTbywgdGhlIHRleHQgaXMgZ2VuZXJhbGx5IGdvb2Qg
YnV0IGl0IG5lZWRzIHRvIGJlIGNvbnN0cmFpbmVkIGxpa2Ug4oCcVW5sZXNzIHRoZSBjbGllbnQg
aXMgY29uZmlkZW50aWFsIGFuZCB0aGUgYWNjZXNzIHRva2VuIGlzc3VlZCBpcyBrZXkgY29uc3Ry
YWluZWQsIC4uLiDigJwNCj4+Pj4+DQo+Pj4+PiBCZXN0LA0KPj4+Pj4NCj4+Pj4+IE5hdCBTYWtp
bXVyYQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAyMDE45bm0MTHmnIgyN+aXpSjngaspIDE2OjAxIFZs
YWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWly
QGNvbm5lY3QyaWQuY29tPj46DQo+Pj4+PiArMSB0byByZWNvbW1lbmQgdGhlIGRlcHJlY2F0aW9u
IG9mIGltcGxpY2l0Lg0KPj4+Pj4NCj4+Pj4+IEkgZG9uJ3Qgc2VlIGEgY29tcGVsbGluZyByZWFz
b24gdG8ga2VlcCBpbXBsaWNpdCB3aGVuIHRoZXJlIGlzIGFuDQo+Pj4+PiBlc3RhYmxpc2hlZCBh
bHRlcm5hdGl2ZSB0aGF0IGlzIG1vcmUgc2VjdXJlLg0KPj4+Pj4NCj4+Pj4+IE91ciBkdXR5IGFz
IFdHIGlzIHRvIGdpdmUgZGV2ZWxvcGVycyB0aGUgYmVzdCBhbmQgbW9zdCBzZW5zaWJsZSBwcmFj
dGljZS4NCj4+Pj4+DQo+Pj4+PiBDT1JTIGFkb3B0aW9uIGlzIGN1cnJlbnRseSBhdCA5NCUgYWNj
b3JkaW5nIHRvDQo+Pj4+PiBodHRwczovL2Nhbml1c2UuY29tLyNmZWF0PWNvcnMNCj4+Pj4+DQo+
Pj4+PiBWbGFkaW1pcg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+
PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+PiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+PiAtLQ0KPj4+Pj4gTmF0IFNh
a2ltdXJhICg9bmF0KQ0KPj4+Pj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+Pj4+PiBo
dHRwOi8vbmF0Li5zYWtpbXVyYS5vcmcvPGh0dHA6Ly9zYWtpbXVyYS5vcmcvPg0KPj4+Pj4gQF9u
YXRfZW4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4NCj4+Pj4+
IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+Pj4gLS0NCj4+Pj4gSmltIE1hbmlj
bw0KPj4+PiBNYW5pY29kZSBTZWN1cml0eQ0KPj4+Pg0KPj4+PiBodHRwczovL3d3dy5tYW5pY29k
ZS5jb20NCj4+Pj4gLS0NCj4+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPj4+PiBDaGFpcm1hbiwg
T3BlbklEIEZvdW5kYXRpb24NCj4+Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+Pj4+IEBf
bmF0X2VuDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPj4+IE9wZW5pZC1zcGVjcy1hYiBtYWlsaW5nIGxpc3QNCj4+PiBPcGVuaWQtc3BlY3Mt
YWJAbGlzdHMub3BlbmlkLm5ldDxtYWlsdG86T3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5u
ZXQ+DQo+Pj4gaHR0cDovL2xpc3RzLm9wZW5pZC5uZXQvbWFpbG1hbi9saXN0aW5mby9vcGVuaWQt
c3BlY3MtYWINCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBG
b3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT3BlbmlkLXNwZWNzLWFiIG1h
aWxpbmcgbGlzdA0KT3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ8bWFpbHRvOk9wZW5p
ZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0Pg0KaHR0cDovL2xpc3RzLm9wZW5pZC5uZXQvbWFp
bG1hbi9saXN0aW5mby9vcGVuaWQtc3BlY3MtYWINCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Ik5vdG8gU2FucyBDSksgSlAgTWVkaXVtIjsNCglwYW5vc2UtMToyIDEx
IDYgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE5vdG8gU2Fu
cyBDSksgSlAgTWVkaXVtIjt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDj
grTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6IsO/MmTDvzMzICAwYjQwYjcwYzMwYWYiOw0KCXBhbm9zZS0xOjAg
MCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQp0dA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1z
b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l
Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u
bS04NDM5MDExMzMxODEyNzc4MDM3aW5mbw0KCXttc28tc3R5bGUtbmFtZTptXy04NDM5MDExMzMx
ODEyNzc4MDM3aW5mbzt9DQpzcGFuLjIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6
ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46OTkuMjVwdCAzLjBjbSAz
LjBjbSAzLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Tm90IHJlYWxs
eS4gPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IGlzIG5vdCBhIHJlcXVp
cmVtZW50IG9mIFNJT1AgdG8gbGV2ZXJhZ2UgdGhlIGRldmljZeKAmXMgc2VjdXJlIGVsZW1lbnQg
dG8gY3JlYXRlIGtleS1wYWlycy4gU28sIHRoZSBrZXlzIGNhbiBiZSBleHBvcnRlZCBhbmQgcG9y
dGVkIHRvIG90aGVyIGRldmljZXMgYXMgd2VsbC4gVGhlcmUgY291bGQgYmUga2V5IHN5bmNpbmcg
bWVjaGFuaXNtDQogYXMgd2VsbCwgbGlrZSAxcGFzc3dvcmQsIGJ1dCBpdCBpcyBub3Qgc3RhbmRh
cmRpemVkLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlOiBkaXNjb3Zlcnk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIHVzZS1jYXNl
IG9mIFNJT1AsIGZyb20gdGhlIGNsaWVudOKAmXMgcG9pbnQgb2YgdmlldywgU0lPUCBpcyBhbHdh
eXMgaW4gdGhlIHVzZXLigJlzIGRldmljZSwgaS5lLiwgbG9jYWxob3N0LiBTbywgdGhlcmUgaXMg
bm8gbmVlZCBmb3IgZGlzY292ZXJ5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij5IYXZpbmcgc2FpZCB0aGF0OiBTSU9QIHNwZWMgaXMgYSBiaXQgb2xkIGFuZCBkZXBlbmRzIG9u
IGN1c3RvbSBzY2hlbWUgb24gaU9TLiBOb3cgaU9TIGhhcyBuZXdlciBjYXBhYmlsaXR5IGxpa2Ug
Y2xhaW1lZCBVUkksIHdoaWNoIGlzIG1vcmUgc2VjdXJlLiBTbywgaGF2aW5nIGEgZGlzY292ZXJ5
IG1lY2hhbmlzbSB0aGF0IHJldHVybnMNCiAmbmJzcDtbU2VsZi1pc3N1ZWQgSWRlbnRpZmllciDi
gJMgZGV2aWNlIHR5cGUg4oCTIGNsYWltZWQgVVJJXSB0cmlwbGUga2luZCBvZiB0aGluZyBtYXkg
YmUgdXNlZnVsLiAoTm90ZSwgSSBqdXN0IGNhbWUgdXAgd2l0aCBpdCBub3cgYW5kIGl04oCZcyAy
IEFNIGhlcmUgc28gaXQgbWF5IGJlIGEgYmFkIGlkZWEgYWZ0ZXIgYWxsLikNCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O05vdG8gU2Fu
cyBDSksgSlAgTWVkaXVtJnF1b3Q7LHNhbnMtc2VyaWYiPk5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjND
MSI+bi1zYWtpbXVyYUBucmkuY28uanA8L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
Tm90byBTYW5zIENKSyBKUCBNZWRpdW0mcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtOb3RvIFNhbnMgQ0pLIEpQIE1lZGl1bSZxdW90Oyxz
YW5zLXNlcmlmIj5QTEVBU0UgUkVBRCA6VGhpcyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBp
bnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBvbmx5LiBJZiB5b3UgYXJlIG5vdCBhbiBp
bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlDQog
dGhpcyBlLW1haWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFRvbSBKb25lcyAm
bHQ7dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdl
ZG5lc2RheSwgTm92ZW1iZXIgMjgsIDIwMTggOToxNCBBTTxicj4NCjxiPlRvOjwvYj4gTmF0IFNh
a2ltdXJhICZsdDtuLXNha2ltdXJhQG5yaS5jby5qcCZndDs8YnI+DQo8Yj5DYzo8L2I+IEFydGlm
YWN0IEJpbmRpbmcvQ29ubmVjdCBXb3JraW5nIEdyb3VwICZsdDtvcGVuaWQtc3BlY3MtYWJAbGlz
dHMub3BlbmlkLm5ldCZndDs7IG9hdXRoQGlldGYub3JnOyBqaW1AbWFuaWNvZGUuY29tPGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbT3BlbmlkLXNwZWNzLWFiXSBbT0FVVEgtV0ddIE9BdXRoIFNl
Y3VyaXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2Yg
aW1wbGljaXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlLCBzbyB0aGVuIHRo
ZSBzZWxmLWlzc3VlZCBJRCBpcyBkZXZpY2UtbG9ja2VkPyBpdCBzb3VuZHMgbW9yZSBsaWtlIGEg
ZGV2aWNlIElEIHRoYW4gYSB1c2VyIElELiZuYnNwOyBXaGljaCBpcyB1c2VmdWwsIGJ1dCBub3Qg
dG9vIGhlbHBmdWwgaW4gYSBtdWx0aXBsZSBkZXZpY2Ugd29ybGQuIFRoZSBzY3JlZW4gaSBhbSB1
c2luZyByaWdodCBub3cgaGFzIDMgZGV2aWNlcyBkcml2aW5nIGl0IGluIG9uZSBmb3JtIG9yDQog
YW5vdGhlci4gSXMgdGhlcmUgYW55IHdheSB0aGF0IGEgc2VsZi1pc3N1ZWQgSUQgb2YgdGhpcyBm
b3JtIGNhbiBiZSBtYWRlIHVzZWZ1bCBpbiB0b2RheSdzIHdvcmxkPyZuYnNwOyBCVFcgLSBpIGxp
a2UgdGhlIGlkZWEgb2YgVVJOJ3MgcmF0aGVyIHRoYW4gVVJMJ3MsIGJ1dCBzb21lIHJlc29sdmVy
IGNhcGFiaWxpdHkgc2VlbXMgdG8gYmUgYSByZXF1aXJlbWVudD88YnIgY2xlYXI9ImFsbCI+DQo8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5QZWFjZSAuLnRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92IDI3LCAyMDE4IGF0IDM6NTAg
UE0gbi1zYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwIj5u
LXNha2ltdXJhQG5yaS5jby5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Ub20sDQo8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JdCBpcyBnb29kIHRvIGhlYXIg
dGhhdCB5b3Ugd2lsbCBiZSB0aGVyZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWYiPkkgdW5kZXJzdGFuZCBKb2huIHdpbGwgYWxzbyBiZSB0aGVyZS4NCjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIHlvdXIgcXVlc3Rpb24sIHNlbGYt
aXNzdWVkIElEIGRvZXMgbm90IHJlcXVpcmUgYSAoc2VtaS0pcGVybWFuZW50IFVSTCBhcyB0aGUg
dXNlcuKAmXMgaWRlbnRpZmllciwgYXMgaXQgaXMgYWx3YXlzIOKAnGxvY2FsaG9zdOKAnS4NCjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBpZGVudGlmaWVy
IGlzIGRlcml2ZWQgYXMgdGhlIGhhc2ggb2YgdGhlIHB1YmxpYyBrZXkgdGhhdCB3YXMgZ2VuZXJh
dGVkIGJ5IHRoZSBTZWxmLWlzc3VlZCBPUC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LHNhbnMtc2VyaWYiPklmIHlvdXIgcXVlc3Rpb24gd2FzIOKAnFVSSeKAnSwgdGhlbiB5ZXMu
IEl0cyBpc3N1ZXIgaXMgYWx3YXlzDQo8YSBocmVmPSJodHRwczovL3NlbGYtaXNzdWVkLm1lIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZWxmLWlzc3VlZC5tZTwvYT4gYW5kIHRoZXJlIGlzIGEg
YHN1YmAgZm9yIHRoYXQgaWRlbnRpdHksIHNvIHN5bnRoZXNpemVkIFVSSSBmb3IgdGhlIHVzZXIg
d291bGQgYmUgc29tZXRoaW5nIGxpa2UNCjxhIGhyZWY9Imh0dHBzOi8vc2VsZi1pc3N1ZWQubWUv
JTdic3ViJTdkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS97c3VifTwv
YT4gd2hlcmUge3N1Yn0gcmVwcmVzZW50cyB0aGUgdmFsdWUgb2YgdGhlIGBzdWJgIGNsYWltLiBg
c3ViYCBjbGFpbSB2YWx1ZSBpcyBkZWZpbmVkIGFzIGZvbGxvd3M6ICZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3VuZDp3aGl0ZSI+c3ViPC9zcGFuPjwvdHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyhzdWJqZWN0
KQ0KIENsYWltIHZhbHVlIGlzIHRoZSBiYXNlNjR1cmwgZW5jb2RlZCByZXByZXNlbnRhdGlvbiBv
ZiB0aGUgdGh1bWJwcmludCBvZiB0aGUga2V5IGluIHRoZSZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5z
dWJfandrPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6
d2hpdGUiPiZuYnNwO0NsYWltLg0KIFRoaXMgdGh1bWJwcmludCB2YWx1ZSBpcyBjb21wdXRlZCBh
cyB0aGUgU0hBLTI1NiBoYXNoIG9mIHRoZSBvY3RldHMgb2YgdGhlIFVURi04IHJlcHJlc2VudGF0
aW9uIG9mIGEgSldLIGNvbnN0cnVjdGVkIGNvbnRhaW5pbmcgb25seSB0aGUgUkVRVUlSRUQgbWVt
YmVycyB0byByZXByZXNlbnQgdGhlIGtleSwgd2l0aCB0aGUgbWVtYmVyIG5hbWVzIHNvcnRlZCBp
bnRvIGxleGljb2dyYXBoaWMgb3JkZXIsIGFuZCB3aXRoIG5vIHdoaXRlIHNwYWNlIG9yDQogbGlu
ZSBicmVha3MuIEZvciBpbnN0YW5jZSwgd2hlbiB0aGUmbmJzcDs8L3NwYW4+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3VuZDp3aGl0ZSI+a3R5
PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUi
PiZuYnNwO3ZhbHVlIGlzJm5ic3A7PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtjb2xvcjojMDAzMzY2O2JhY2tncm91bmQ6d2hpdGUiPlJTQTwvc3Bhbj48L3R0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj4sDQogdGhlIG1lbWJlciBu
YW1lcyZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6
IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5lPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiwmbmJzcDs8L3NwYW4+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3VuZDp3aGl0ZSI+a3R5PC9z
cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiwN
CiBhbmQmbmJzcDs8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y
OiMwMDMzNjY7YmFja2dyb3VuZDp3aGl0ZSI+bjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDthcmUgdGhlIG9uZXMgcHJlc2VudCBp
biB0aGUgY29uc3RydWN0ZWQgSldLIHVzZWQgaW4gdGhlIHRodW1icHJpbnQgY29tcHV0YXRpb24N
CiBhbmQgYXBwZWFyIGluIHRoYXQgb3JkZXI7IHdoZW4gdGhlJm5ic3A7PC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMDAzMzY2O2JhY2tncm91bmQ6d2hpdGUi
Pmt0eTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndo
aXRlIj4mbmJzcDt2YWx1ZSBpcyZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5FQzwvc3Bhbj48L3R0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj4sDQogdGhlIG1lbWJl
ciBuYW1lcyZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s
b3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5jcnY8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+LCZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj5r
dHk8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom
cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0
ZSI+LCZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6
IzAwMzM2NjtiYWNrZ3JvdW5kOndoaXRlIj54PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiwNCiBhbmQmbmJzcDs8L3NwYW4+PHR0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMwMDMzNjY7YmFja2dyb3VuZDp3aGl0ZSI+
eTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl
Ij4mbmJzcDthcmUgcHJlc2VudCBpbiB0aGF0IG9yZGVyLiBOb3RlIHRoYXQgdGhpcyB0aHVtYnBy
aW50IGNhbGN1bGF0aW9uIGlzIHRoZQ0KIHNhbWUgYXMgdGhhdCBkZWZpbmVkIGluIHRoZSBKV0sg
VGh1bWJwcmludCZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mv
b3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNKV0suVGh1bWJwcmludCIgdGFyZ2V0PSJfYmxh
bmsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl
cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZTtiYWNrZ3JvdW5kOiM5OTAwMDA7dGV4
dC1kZWNvcmF0aW9uOm5vbmUiPltKV0suVGh1bWJwcmludF08L3NwYW4+PC9iPjxzcGFuIGNsYXNz
PSJtLTg0MzkwMTEzMzE4MTI3NzgwMzdpbmZvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5
MDAwMDtib3JkZXI6c29saWQgIzMzMzMzMyAxLjBwdDtwYWRkaW5nOjIuMHB0O2JhY2tncm91bmQ6
I0VFRUVFRTt0ZXh0LWRlY29yYXRpb246bm9uZSI+Sm9uZXMsDQogTS4sIOKAnEpTT04gV2ViIEtl
eSAoSldLKSBUaHVtYnByaW50LOKAnSBKdWx5Jm5ic3A7MjAxNC48L3NwYW4+PC9iPjwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu
YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwO3Nw
ZWNpZmljYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U28sIHll
cy4gVGhlIHN0cmluZw0KPGEgaHJlZj0iaHR0cHM6Ly9zZWxmLWlzc3VlZC5tZS8lN2JzdWIlN2Qi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlbGYtaXNzdWVkLm1lL3tzdWJ9PC9hPiBpcyBwcm9i
YWJpbGlzdGljYWxseSB1bmlxdWUgYW5kIOKAnHBlcnNpc3RlbnTigJ0gKGJldHRlciB0byBwaHJh
c2UgaXQgYXMg4oCYbmV2ZXIgcmUtYXNzaWduZWTigJkpLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+VGhlIHJlYXNvbiBpdCBpcyBub3QgYSDigJxVUkzigJ0gaXMgdGhh
dCB5b3UgY2Fubm90IHJlYWNoIGl0LiBIb3dldmVyLCBJdCBpcyBhIOKAnFVSSeKAnS4NCjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycywNCjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O05vdG8g
U2FucyBDSksgSlAgTWVkaXVtJnF1b3Q7LHNhbnMtc2VyaWYiPk5hdCBTYWtpbXVyYSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwNTYzQzEiPm4tc2FraW11cmFAbnJpLmNvLmpwPC9zcGFuPjwvYT4mZ3Q7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Tm90byBTYW5zIENKSyBKUCBNZWRpdW0mcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O05vdG8gU2Fu
cyBDSksgSlAgTWVkaXVtJnF1b3Q7LHNhbnMtc2VyaWYiPlBMRUFTRSBSRUFEIDpUaGlzIGUtbWFp
bCBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50IG9u
bHkuIElmIHlvdSBhcmUgbm90DQogYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5
IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGUtbWFpbC48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxiPkZyb206PC9iPiBPcGVuaWQtc3BlY3MtYWIgJmx0OzxhIGhyZWY9Im1haWx0bzpv
cGVuaWQtc3BlY3MtYWItYm91bmNlc0BsaXN0cy5vcGVuaWQubmV0IiB0YXJnZXQ9Il9ibGFuayI+
b3BlbmlkLXNwZWNzLWFiLWJvdW5jZXNAbGlzdHMub3BlbmlkLm5ldDwvYT4mZ3Q7DQo8Yj5PbiBC
ZWhhbGYgT2YgPC9iPlRvbSBKb25lcyB2aWEgT3BlbmlkLXNwZWNzLWFiPGJyPg0KPGI+U2VudDo8
L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMjgsIDIwMTggODoxNiBBTTxicj4NCjxiPlRvOjwvYj4g
QXJ0aWZhY3QgQmluZGluZy9Db25uZWN0IFdvcmtpbmcgR3JvdXAgJmx0OzxhIGhyZWY9Im1haWx0
bzpvcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm9wZW5p
ZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFRvbSBK
b25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20iIHRh
cmdldD0iX2JsYW5rIj50aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPC9hPiZndDs7DQo8YSBo
cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9y
ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpqaW1AbWFuaWNvZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+
DQpqaW1AbWFuaWNvZGUuY29tPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09wZW5pZC1z
cGVjcy1hYl0gW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1
dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+SSBhbSBoZWFkZWQgdG8gYSB3M2MgbWVldGluZyB0aGF0IHdpbGwgdGFs
ayBhYm91dCBESURzIGZvciB0aGUgZnV0dXJlLiBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBp
ZiB0aGUgc2VsZi1pc3N1ZWQgSUQgcmVxdWlyZXMgKG9yIHNob3VsZCByZXF1aXJlKSBzb21lIHNv
cnQgb2YgKHNlbWkpIHBlcm1hbmVudA0KIFVSTCBvbiB0aGUgaW50ZXJuZXQuIChpbmNsdWRpbmcg
b24gYSBibG9jay1jaGFpbiwgZm9yIGV4YW1wbGUuKSZuYnNwOyBXaXRob3V0IHRoYXQgaSBjYW5u
b3QgdW5kZXJzdGFuZCB3aGF0IGEgc2VsZi1pc3N1ZWQgSUQgbWlnaHQgZXZlbiBtZWFuLjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwi
Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5QZWFjZSAuLnRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBO
b3YgMjcsIDIwMTggYXQgMzowNiBQTSBOYXQgU2FraW11cmEgdmlhIE9wZW5pZC1zcGVjcy1hYiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0IiB0YXJn
ZXQ9Il9ibGFuayI+b3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9wZW5pZC5uZXQ8L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWxmIElz
c3VlZCBPUCBpcyBkZXNjcmliZWQgaW4gQ2hhcHRlciA3IG9mIHRoZSBPcGVuSUQgQ29ubmVjdCBD
b3JlIDEuMC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkl0IGxpdmVzIG9uIGEgbG9jYWwgbWFjaGluZSwgdHlwaWNhbGx5IGEgcGhvbmUuIEV2ZW4g
aWYgaXQgZGlkIHByb3ZpZGUgYW4gYXV0aG9yaXphdGlvbiBjb2RlIHRvIHRoZSBjbGllbnQsIHRo
ZSBjbGllbnQgY2Fubm90IGVzdGFibGlzaCBhIGRpcmVjdCBjb25uZWN0aW9uIHRvIHRoZSBsb2Nh
bCBtYWNoaW5lDQogKHBob25lKSBhcyBpdCBpcyBub3QgYWRkcmVzc2FibGUuIFRoZXJlZm9yZSwg
YSZuYnNwO3Rva2VuIGVuZHBvaW50IGNhbm5vdCBiZSBwcm92aWRlZCB1bmxlc3MgaXQgaXMgY291
cGxlZCB3aXRoIHNvbWUga2luZCBvZiBjbG91ZC1iYXNlZCBzZXJ2aWNlLCB3aGljaCB3b3VsZCBu
ZWdhdGUgc29tZSBvZiB0aGUgdmVyeSByZWFzb24gZm9yIGhhdmluZyB0aGUgU2VsZi1pc3N1ZWQg
T1AuIEluIG90aGVyIHdvcmRzLCBvbmx5IHRoZSB2aWFibGUgY29tbXVuaWNhdGlvbg0KIGNoYW5u
ZWwgYmV0d2VlbiB0aGUgU0lPUCBhbmQgdGhlIGNsaWVudCBpcyB0aGUgZnJvbnQgY2hhbm5lbC4g
VGhlIHNpdHVhdGlvbiBjb3VsZCBiZSB0cnVlIHRvIG90aGVyICZxdW90O3dhbGxldCZxdW90OyB0
eXBlIG9mIGltcGxlbWVudGF0aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgaXMgb25lIG9mIHRoZSBleG90aWMg
ZmVhdHVyZXMgb2YgT3BlbklEIENvbm5lY3QgdGhhdCBuZXZlciBnb3QgYSB0cmFjdGlvbiZuYnNw
O2J1dCBpdCBpcyBnZXR0aW5nIGEgcmVuZXdlZCBpbnRlcmVzdCBhcyAmcXVvdDtTZWxmLXNvdmVy
ZWlnbiBJZGVudGl0eSZxdW90OyBnYWluZWQgc29tZSBpbnRlcmVzdC4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
T24gV2VkLCBOb3YgMjgsIDIwMTggYXQgNjowMyBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8
YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50
b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzdGlsbCBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHRoZSB1
c2UgY2FzZSBtdXN0IGJlIHNvbHZlZCB1c2luZyBhIGZsb3cgaXNzdWluZyBzb21ldGhpbmcgaW4g
dGhlIGZyb250IGNoYW5uZWwuDQo8YnI+DQo8YnI+DQpJIHdvdWxkIGFsc28gbGlrZSB0byB0YWtl
IGEgY2xvc2VyIGxvb2suIENhbiB5b3Ugb3IgTmF0IHByb3ZpZGUgcG9pbnRlcnMgdG8gZXhpc3Rp
bmcgaW1wbGVtZW50YXRpb25zPw0KPGJyPg0KPGJyPg0KJmd0OyBBbSAyNy4xMS4yMDE4IHVtIDIx
OjM2IHNjaHJpZWIgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0
Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7Ojxicj4NCiZn
dDsgPGJyPg0KJmd0OyBJIHVuZGVyc3RhbmQgdGhhdCwgYnV0IGhhdCBpcyBOYXQncyBjb25jZXJu
IGFzIEkgdW5kZXJzdGFuZCBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hlbiB3ZSBzYXkgbm8g
aW1wbGljaXQgcGVvcGxlLCBoYXZlIGEgcHJvYmxlbSBiZWNhdXNlIGltcGxpY2l0IGlzIGltcHJl
Y2lzZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2UgYXJlIHNheWluZyBubyBBVCByZXR1cm5lZCBp
biB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC48YnI+DQomZ3Q7
IDxicj4NCiZndDsgTmF0IHBvaW50cyBvdXQgdGhhdCBpZF90b2tlbiBtYXkgY29udGFpbiBBVCBm
b3IgdGhlIHNlbGYgaXNzdWVkIGNsaWVudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgU28gdW5sZXNz
IHdlIHNheSB0aGF0IGlzIE9LIGlmIHRoZSBBVCBhcmUgc2VuZGVyIGNvbnN0cmFpbmVkIHdlIHdp
bmQgdXAgaW1wbHlpbmcgdGhhdCBhIE9wZW5JRCBwcm9maWxlIG9mIE9BdXRoIGlzIGluIHZpb2xh
dGlvbiBvZiB0aGUgQkNQLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIGp1c3QgdHJ5aW5nIHRv
IG1ha2Ugc3VyZSBldmVyeW9uZSBpcyBvbiB0aGUgc2FtZSBwYWdlIHdpdGggd2h5IE5hdCB3YXMg
LTEuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0IHJlYWxseSBoYXMgbm90aGluZyB0byBkbyB3aXRo
IHRoZSBTUEEgdXNlIGNhc2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEpvaG4gQi48YnI+DQomZ3Q7
IDxicj4NCiZndDsmZ3Q7IE9uIDExLzI3LzIwMTggNToyOCBQTSwgVG9yc3RlbiBMb2RkZXJzdGVk
dCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIaSBKb2huLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm
Z3Q7IGFzIHlvdSBzYWlkLCBzZWxmIGlzc3VlZCBJRFBzICg8YSBocmVmPSJodHRwczovL29wZW5p
ZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNTZWxmSXNzdWVkIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUt
MV8wLmh0bWwjU2VsZklzc3VlZDwvYT4pIGFyZSBzdXBwb3NlZCB0byBwcm92aWRlIHRoZSByZXNw
b25zZSB0eXBlIOKAnmlkX3Rva2Vu4oCcIG9ubHkuIEkgZG9u4oCZdA0KIHRoaW5rIHRoZSBwcm9w
b3NhbCBiZWluZyBkaXNjdXNzZWQgaGVyZSBpcyByZWxhdGVkIHRvIHRoaXMgT0lEQyBtb2RlLjxi
cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IGJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyBU
b3JzdGVuLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBBbSAyNy4xMS4yMDE4IHVt
IDIwOjU0IHNjaHJpZWIgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZl
N2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7Ojxicj4N
CiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSSB0YWxrZWQgdG8gTmF0IGFib3V0IHRo
aXMgYSBiaXQgdG9kYXkuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUg
dGhpbmcgaGUgaXMgY29uY2VybmVkIGFib3V0IGlzIG1vc3RseSBhcm91bmQgdGhlIHNlbGYgaXNz
dWVkIElEUCB0aGF0IGRvZXNuJ3QgaGF2ZSBhIHRva2VuIGVuZHBvaW50KGF0bGVhc3Qgbm90IGVh
c2FseSkuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgbWFpbiB1c2Ug
Y2FzZSBmb3IgdGhhdCBpcyB0aGUgaWRfdG9rZW4gcmVzcG9uc2UgdHlwZSB3aGVyZSBjbGFpbXMg
YXJlIHJldHVuZWQgaW4gdGhlIGlkX3Rva2VuLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyZndDsgQmVjYXVzZSBpdCBpcyBmcmFnbWVudCBlbmNvZGVkIHNvbWUgcGVvcGxlIGNhbGwg
dGhhdCBpbXBsaWNpdC4mbmJzcDsgJm5ic3A7VGhhdCBpcyBub3Qgd2hhdCB3ZSBhcmUgdHJ5aW5n
IHRvIHN0b3AuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBJbiBzb21lIGNh
c2VzIGluIHRoYXQgZmxvdyB0aGVyZSBtYXkgYmUgZGlzdHJpYnV0ZWQgY2xhaW1zIHJldHVybmVk
IHdpdGggYWNjZXNzIFRva2VuIGluc2lkZSB0aGUgaWRfdG9rZW4uJm5ic3A7ICZuYnNwOyBJIHRo
aW5rIG1vc3QgcGVvcGxlIHdvdWxkIGFncmVlIHRoYXQgdGhvc2Ugc2hvdWxkIGJlIHBvcCBvciBz
ZW5kZXIgY29uc3RyYWluZWQgdG9rZW5zLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0
OyZndDsgSW4gdGhlIGNhc2Ugb2Ygc2VsZiBpc3N1ZWQgdGhlIFJQIHdvdWxkIGJlIGEgc2VydmVy
IGFuZCBjb3VsZCBkbyBzZW5kZXIgY29uc3RyYWluZWQgdmlhIHNvbWUgbWVjaGluaXNpbSB0aGF0
IGlzIHlldCB0byBiZSBkZWZpbmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn
dDsgU28gaWYgc29tZW9uZSB3YW50ZWQgdG8gcmV0dXJuIGEgYWNjZXNzIHRva2VuIGluIGEgaWRf
dG9rZW4gdG8gZG8gZGlzdHJpYnV0ZWQgY2xhaW1zIEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhIHBy
b2JsZW0gd2l0aCB0aGF0IGFzIGxvbmcgYXMgdGhlIHRva2VuIGlzIHByb3RlY3RlZCBieSBiZWlu
ZyBzZW5kZXIgY29uc3RyYWluZWQgaW4gc29tZSByZWFzb25hYmxlIHdheS48YnI+DQomZ3Q7Jmd0
OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRoaXMgaXMgYSB0b3VjaCBoeXBvdGhldGljYWwgZnJv
bSB0aGUgYmFzaWMgT0F1dGggcGVyc3BlY3RpdmUsIHNvIEkgZG9uJ3Qga25vdyBob3cgZGVlcCB3
ZSB3YW50IHRvIGdvIGludG8gaXQuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0
OyBJIHRoaW5rIHRoZSBwb2ludCBpcyBub3QgdG8gYWNjaWRlbnRseSBwcm9oaWJpdCBzb21ldGhp
bmcgdGhhdCBjb3VsZCBiZSBkb25lIGluIGZ1dHVyZS48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0K
Jmd0OyZndDsmZ3Q7IEkgYWxzbyB0aGluayB3ZSBzaG91bGQgbm90IGNvbmZsYXRlIGNvbmZpZGVu
dGlhbCBjbGllbnRzIHRoYXQgY2FuIGF1dGhlbnRpY2F0ZSB0byB0aGUgdG9rZW4gZW5kcG9pbnQg
d2l0aCBzZW5kZXIgY29uc3RyYWluZWQvUG9QIGNsaWVudHMgdGhhdCBjYW4gZGVhbCB3aXRoIGJv
dW5kIHRva2Vucy4mbmJzcDsgJm5ic3A7WWVzIGJvdGggaGF2ZSBrZXlzIGJ1dCBpdCBpcyBiZXR0
ZXIgdG8gZGVzY3JpYmUgdGhlbSBzZXBhcmF0ZWx5Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQom
Z3Q7Jmd0OyZndDsgSm9obiBCLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsg
T24gVHVlLCBOb3YgMjcsIDIwMTgsIDQ6MzAgUE0gVG9yc3RlbiBMb2RkZXJzdGVkdCB2aWEgT3Bl
bmlkLXNwZWNzLWFiICZsdDs8YSBocmVmPSJtYWlsdG86b3BlbmlkLXNwZWNzLWFiQGxpc3RzLm9w
ZW5pZC5uZXQiIHRhcmdldD0iX2JsYW5rIj5vcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5l
dDwvYT4gd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7IEhpIE5hdCw8YnI+DQomZ3Q7Jmd0OyZndDsg
PGJyPg0KJmd0OyZndDsmZ3Q7IEkgdW5kZXJzdGFuZCB5b3UgYXJlIHNheWluZyB5b3VyIGRyYWZ0
IGNvdWxkIHByb3ZpZGUgY2xpZW50cyB3aXRoIGFuIGFwcGxpY2F0aW9uIGxldmVsIG1lY2hhbmlz
bSB0byBzZW5kZXIgY29uc3RyYWluIGFjY2VzcyB0b2tlbnMuIFRoYXTigJlzIGdyZWF0ITxicj4N
CiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgQnV0IEkgZG9u4oCZdCBzZWUgYSBiaW5k
aW5nIHRvIHJlc3BvbnNlIHR5cGUg4oCedG9rZW4gaWRfdG9rZW7igJwuIFdoeSBkbyB5b3Ugd2Fu
dCB0byBleHBvc2UgdGhlIHRva2VucyB2aWEgdGhlIFVSTCB0byBhdHRhY2tlcnM/PGJyPg0KJmd0
OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBZb3UgY291bGQgZWFzaWx5IHVzZSB5b3VyIG1l
Y2hhbmlzbSB3aXRoIGNvZGUuIFRoYXQgd291bGQgYWxzbyBnaXZlIHlvdSB0aGUgY2hhbmNlIHRv
IHJlYWxseSBhdXRoZW50aWNhdGUgdGhlIGNvbmZpZGVudGlhbCBjbGllbnQgYmVmb3JlIHlvdSBp
c3N1ZSB0aGUgdG9rZW4uPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBraW5k
IHJlZ2FyZHMsPGJyPg0KJmd0OyZndDsmZ3Q7IFRvcnN0ZW4uPGJyPg0KJmd0OyZndDsmZ3Q7IDxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsgQW0gMjcuMTEuMjAxOCB1bSAxNjo1NyBzY2hyaWViIE5hdCBT
YWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIG5vdCB0YWxraW5nIGFib3V0IFNQQS48YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7IFRoZSBjbGllbnQgaXMgYSByZWd1bGFyIGNvbmZpZGVudGlhbCBjbGll
bnQgdGhhdCBpcyBydW5uaW5nIG9uIGEgc2VydmVyLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBCZXN0LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAyMDE4PHNwYW4gbGFuZz0iSkEi
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7Ij7lubQ8
L3NwYW4+MTE8c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O++8re+8syDj
grTjgrfjg4Pjgq8mcXVvdDsiPuaciDwvc3Bhbj4yNzxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90OyI+5pelPC9zcGFuPig8c3Bh
biBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8m
cXVvdDsiPueBqzwvc3Bhbj4pIDE2OjU1IEppbSBNYW5pY28gJmx0OzxhIGhyZWY9Im1haWx0bzpq
aW1AbWFuaWNvZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+amltQG1hbmljb2RlLmNvbTwvYT4mZ3Q7
Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgTmF0LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgaXMgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBlc3RhYmxpc2hlZCBp
biBhIG1vZGVybiB3ZWIgYnJvd3NlciBpbiB0aGUgaW1wbGljaXQgZmxvdz88YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0
IHRva2VuIGJpbmRpbmcgd2FzIHJlbW92ZWQgZnJvbSBDaHJvbWUgcmVjZW50bHkgZWZmZWN0aXZl
bHkga2lsbGluZyBicm93c2VyLWJhc2VkIFBvUCB0b2tlbnMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vaWRlbnRpdmVyc2UuY29t
LzIwMTgvMTAvMzEvY2hyb21lLXB1dHMtdG9rZW4tYmluZGluZy1pbi1hLWJpbmQvIiB0YXJnZXQ9
Il9ibGFuayI+DQpodHRwczovL2lkZW50aXZlcnNlLmNvbS8yMDE4LzEwLzMxL2Nocm9tZS1wdXRz
LXRva2VuLWJpbmRpbmctaW4tYS1iaW5kLzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz88YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQWxvaGEsIEppbTxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDExLzI3LzE4IDk6MDAgUE0sIE5hdCBTYWtpbXVyYSB3
cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIGFjdHVhbGx5IC0xLjxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICYjNDM7MSBmb3Ig
cHVibGljIGNsaWVudCBhbmQgdGhlIHRva2VucyB0aGF0IGFyZSBub3Qgc2VuZGVyL2tleSBjb25z
dHJhaW5lZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyBKdXN0IG5vdCBiZWluZyB1c2VkIHJpZ2h0IG5vdyBkb2VzIG5vdCBtZWFuIHRoYXQgaXQg
aXMgbm90IHVzZWZ1bC4uIEluIGZhY3QsIEkgc2VlIGl0IGNvbWluZy48YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBJbXBsaWNpdCAod2VsbCwgSHlicmlkIOKAnHRva2VuIGlkX3Rva2Vu4oCdIHJl
YWxseSkgaXMgdmVyeSB1c2VmdWwgaW4gY2VydGFpbiBjYXNlcy48YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyBTcGVjaWZpY2FsbHksIHdoZW4gdGhlIGNsaWVudCBpcyBjb25maWRlbnRpYWwgKGJh
c2VkIG9uIHB1YmxpYyBrZXkgcGFpciksIGFuZCB1c2VzIHNlbmRlciBjb25zdHJhaW5lZCAoa2V5
LWNvbnN0cmFpbmVkKSB0b2tlbiBzdWNoIGFzIHRoZSBvbmUgZXhwbGFpbmVkIGluDQo8YSBocmVm
PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtanBvcC0w
NCNzZWN0aW9uLTUiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1qcG9wLTA0I3NlY3Rpb24tNTwvYT4sIGl0IGlzIHZlcnkg
dXNlZnVsLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChLZXktY29uc3RyYWluZWQgdG9rZW4g
aXMgdGhlIHJlbWFpbmluZyBwb3J0aW9uIG9mIHRoaXMgZHJhZnQgdGhhdCBkaWQgbm90IGdldCBp
bmNvcnBvcmF0ZWQgaW4gdGhlIE1UTFMgZHJhZnQuICk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyBJbiBmYWN0IGl0IGlzIHRoZSBvbmx5IHZpYWJsZSBtZXRob2QgZm9yIFNlbGYtSXNzdWVkIE9w
ZW5JRCBQcm92aWRlci48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBTbywgdGhlIHRleHQgaXMgZ2VuZXJhbGx5IGdvb2QgYnV0IGl0IG5lZWRzIHRv
IGJlIGNvbnN0cmFpbmVkIGxpa2Ug4oCcVW5sZXNzIHRoZSBjbGllbnQgaXMgY29uZmlkZW50aWFs
IGFuZCB0aGUgYWNjZXNzIHRva2VuIGlzc3VlZCBpcyBrZXkgY29uc3RyYWluZWQsIC4uLiDigJw8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCZXN0
LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5h
dCBTYWtpbXVyYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIwMTg8c3BhbiBsYW5nPSJKQSIgc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDsiPuW5tDwvc3Bh
bj4xMTxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOC
t+ODg+OCryZxdW90OyI+5pyIPC9zcGFuPjI3PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIGxh
bmc9IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90
OyI+54GrPC9zcGFuPikgMTY6MDEgVmxhZGltaXIgRHpodXZpbm92DQogJmx0OzxhIGhyZWY9Im1h
aWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZsYWRpbWlyQGNv
bm5lY3QyaWQuY29tPC9hPiZndDs6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJiM0MzsxIHRv
IHJlY29tbWVuZCB0aGUgZGVwcmVjYXRpb24gb2YgaW1wbGljaXQuPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkb24ndCBzZWUgYSBjb21wZWxs
aW5nIHJlYXNvbiB0byBrZWVwIGltcGxpY2l0IHdoZW4gdGhlcmUgaXMgYW48YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyBlc3RhYmxpc2hlZCBhbHRlcm5hdGl2ZSB0aGF0IGlzIG1vcmUgc2VjdXJl
Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE91
ciBkdXR5IGFzIFdHIGlzIHRvIGdpdmUgZGV2ZWxvcGVycyB0aGUgYmVzdCBhbmQgbW9zdCBzZW5z
aWJsZSBwcmFjdGljZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBDT1JTIGFkb3B0aW9uIGlzIGN1cnJlbnRseSBhdCA5NCUgYWNjb3JkaW5nIHRv
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9jYW5pdXNlLmNvbS8j
ZmVhdD1jb3JzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jYW5pdXNlLmNvbS8jZmVhdD1jb3Jz
PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IFZsYWRpbWlyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLSA8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgPGEgaHJlZj0iaHR0cDovL25hdC4iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0Ljwv
YT4uPGEgaHJlZj0iaHR0cDovL3Nha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVy
YS5vcmcvPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tIDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgSmltIE1hbmljbzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgTWFuaWNv
ZGUgU2VjdXJpdHk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg
PGEgaHJlZj0iaHR0cHM6Ly93d3cubWFuaWNvZGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cubWFuaWNvZGUuY29tPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgLS0gPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBD
aGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9
Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2Fr
aW11cmEub3JnLzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P
QXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsmZ3Q7
Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N
CiZndDsmZ3Q7Jmd0OyBPcGVuaWQtc3BlY3MtYWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsm
Z3Q7IDxhIGhyZWY9Im1haWx0bzpPcGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldCIgdGFy
Z2V0PSJfYmxhbmsiPk9wZW5pZC1zcGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PC9hPjxicj4NCiZn
dDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vbGlzdHMub3BlbmlkLm5ldC9tYWlsbWFuL2xpc3Rp
bmZvL29wZW5pZC1zcGVjcy1hYiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2xpc3RzLm9wZW5p
ZC5uZXQvbWFpbG1hbi9saXN0aW5mby9vcGVuaWQtc3BlY3MtYWI8L2E+PG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFy
PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0K
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5OYXQgU2FraW11
cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5D
aGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2lt
dXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJy
Pg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KT3BlbmlkLXNwZWNzLWFiIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpP
cGVuaWQtc3BlY3MtYWJAbGlzdHMub3BlbmlkLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPk9wZW5pZC1z
cGVjcy1hYkBsaXN0cy5vcGVuaWQubmV0PC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9saXN0cy5v
cGVuaWQubmV0L21haWxtYW4vbGlzdGluZm8vb3BlbmlkLXNwZWNzLWFiIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cDovL2xpc3RzLm9wZW5pZC5uZXQvbWFpbG1hbi9saXN0aW5mby9vcGVuaWQtc3BlY3Mt
YWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_OSBPR01MB286966400838D4CD0CE0214DF9D10OSBPR01MB2869jpnp_--


From nobody Wed Nov 28 02:07:33 2018
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 23B96128C65 for ; Wed, 28 Nov 2018 02:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 XUV45jhwlmSS for ; Wed, 28 Nov 2018 02:07:29 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) (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 CF8F012D4ED for ; Wed, 28 Nov 2018 02:07:28 -0800 (PST)
Received: from [80.155.34.3] (helo=[10.3.12.54]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRwkf-0007S3-5L; Wed, 28 Nov 2018 11:07:25 +0100
From: Torsten Lodderstedt 
Message-Id: <505C88D4-2FE2-44CC-99F9-9200984FE495@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_31BCAD23-A67C-4361-9072-00AAFEECEA68"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 11:07:24 +0100
In-Reply-To: 
Cc: OAuth WG 
To: Aaron Parecki 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 28 Nov 2018 10:07:32 -0000

--Apple-Mail=_31BCAD23-A67C-4361-9072-00AAFEECEA68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Aaron,

> Am 20.11.2018 um 21:37 schrieb Aaron Parecki :
>=20
> The new section on refresh tokens is great! I have a couple =
questions/comments about some of the details.
>=20
> Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o  logout at the authorization server
> =20
> This doesn't sound like the desired behavior for mobile apps, where =
the user's expectation of how long they are logged in to the mobile app =
is not tied to their web session where they authorized the app. However =
this does likely match a user's expectation when authorizing a =
browser-based app. Should this be clarified that it should not apply to =
the mobile app case, or only apply to browser-based apps?

The Security BCP=E2=80=99s is intended to describe threats and potential =
countermeasures for implementors. There is such a variety of design =
option even within a class of apps, I don=E2=80=99t think we can cover =
them all. I think this kind of consideration should go into app type =
specific BCPs, like your=E2=80=99s.

Nevertheless, if you come up with a concrete text proposal, we can =
discuss it=E2=80=99s inclusion. =20

>=20
> Refresh tokens should expire if the client has been inactive for some =
time
>=20
> This is a good suggestion, but I think it would benefit from a little =
more clarity. Specifically pointing out that what counts as "activity" =
is use of the access token and/or refresh token, if that's the =
intention. That will help avoid confusion that "inactivity" may be =
referring to the user's session at the authorization server.

You are right. Acivity here means =E2=80=9Erefresh=E2=80=9C. How about =
this:

Refresh tokens SHOULD expire if the client has been inactive for some =
time,=20
    	i.e. the refresh token has not been used to obtain fresh access =
tokens for=20
    	some time. The expiration time is at the discretion of the =
authorization server.=20
    	It might be a global value or determined based on the client =
policy or
    	the grant associated with the refresh token (and its =
sensitivity).

>=20
> Is this supposed to be a capital "SHOULD" or lowercase "should=E2=80=9C?=


Changed it (see above)
=20
>=20

> It is also unclear whether this is meant to apply to public clients, =
private clients, or both, as well as whether it should apply to mobile =
apps or browser-based apps or both. I am curious what the intent is =
here, since I feel like that can have some serious implications for the =
user experience in some cases and is worth pointing out.


It=E2=80=99s supposed to by applicable to all sorts of clients. The text =
explicitly distinguishes protection mechanisms for public and =
confidential clients. What do you miss? Any text proposal is helpful.=20

>=20
> Lastly, minor nit, I see the comment about changing occurrences of =
"SHALL" to "MUST", but the new refresh token section still has two uses =
of "SHALL=E2=80=9C.

Fixed it.

>=20
> Thanks! Overall I'm happy to see this guidance!

Thanks.

kind regards,
Torsten.

>=20
> ----
> Aaron Parecki
> aaronparecki.com
>=20
>=20
>=20
> On Tue, Nov 20, 2018 at 11:33 AM Torsten Lodderstedt =
 wrote:
> Hi all,=20
>=20
> the new revision contains the following changes:
>=20
> * added section on refresh tokens=20
> * additional justifications for recommendation for code
> * refactored 2.1 in order to distinguish CSRF, authz response replay =
and mix-up (based on feedback by Joseph Heenan)
> * added requirement to authenticate clients during code exchange (PKCE =
or client credential) to 2.1.1.
> * changed occurrences of SHALL to MUST
>=20
> As always: looking forward for your feedback.
>=20
> kind regards,
> Torsten.=20
>=20
> > Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org:
> >=20
> >=20
> > A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> > This draft is a work item of the Web Authorization Protocol WG of =
the IETF.
> >=20
> >        Title           : OAuth 2.0 Security Best Current Practice
> >        Authors         : Torsten Lodderstedt
> >                          John Bradley
> >                          Andrey Labunets
> >                          Daniel Fett
> >       Filename        : draft-ietf-oauth-security-topics-10.txt
> >       Pages           : 38
> >       Date            : 2018-11-20
> >=20
> > Abstract:
> >   This document describes best current security practice for OAuth =
2.0.
> >   It updates and extends the OAuth 2.0 Security Threat Model to
> >   incorporate practical experiences gathered since OAuth 2.0 was
> >   published and covers new threats relevant due to the broader
> >   application of OAuth 2.0.
> >=20
> >=20
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> >=20
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
> > =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
> >=20
> > A diff from the previous version is available at:
> > =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
> >=20
> >=20
> > Please note that it may take a couple of minutes from the time of =
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >=20
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >=20
> > _______________________________________________
> > 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=_31BCAD23-A67C-4361-9072-00AAFEECEA68
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjgxMDA3MjVaMC8GCSqGSIb3DQEJBDEiBCD7
5tdCBg1Kdgy0o2AcnZ09kzxfahozGg5KrthiRcEMCDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAW07QVnHa3wo6rDrd7luZzlyQ
cHWObq0bakBuIMnYstJ3ebsqdgxA59ztV226fjC/w2hxHbVw/txOCcAmuAwLFJvT47yE6iD+UENm
OdsLPmC5+OBgtpYK83oGBSKp32OLTuYbAkXGP1j75H1ULPLz9398PpklgjnvQ8ooMNCPFb38NA82
emPpo5OMGcp+MKadYckTy2UVkHzSBLJzMq+6KBga5j3AjW2w3IURdTn48trSK1r6phV/vAXM9QqA
SfmGNmYc408IuKG6SzxAMY6jzC87rb7GVWqd7ks3kvcSWoiCeUZPJ739BOPN9KkuPikGOZpL4bKP
SAomjAew0zaTxwAAAAAAAA==
--Apple-Mail=_31BCAD23-A67C-4361-9072-00AAFEECEA68--


From nobody Wed Nov 28 02:11:49 2018
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 D6ACD12D4ED for ; Wed, 28 Nov 2018 02:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 Jbzsu24RR055 for ; Wed, 28 Nov 2018 02:11:46 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) (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 D6451123FFD for ; Wed, 28 Nov 2018 02:11:45 -0800 (PST)
Received: from [80.155.34.3] (helo=[10.3.12.54]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRwop-0003ye-JX; Wed, 28 Nov 2018 11:11:43 +0100
From: Torsten Lodderstedt 
Message-Id: <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_2FE4D7CE-383B-4888-B3A5-71F91FD7FE16"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 11:11:42 +0100
In-Reply-To: <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com>
Cc: oauth 
To: George Fletcher 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com>
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 28 Nov 2018 10:11:48 -0000

--Apple-Mail=_2FE4D7CE-383B-4888-B3A5-71F91FD7FE16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi George,=20

> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>=20
> Thanks for the additional section on refresh_tokens. Some additional =
recommendations...
>=20
> 1. By default refresh_tokens are bound to the user's authenticated =
session. When the authenticated session expires or is terminated =
(whether by the user or for some other reason) the refresh_tokenis =
implicitly revoked.

SHOULD or MUST? I would suggest to go with a SHOULD.

> 2. Clients that need to obtain a refresh_token that exists beyond the =
lifetime of the user's authentication session MUST indicate this need by =
requesting the "offline_access" scope =
(https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). =
This provides for a user consent event making it clear to the user that =
the client is requesting access even when the user's authentication =
session expires. This then becomes the default for mobile apps as the =
refresh_token should not be tied to the web session used to authorize =
the app.

Sounds reasonable, just the scope =E2=80=9Eoffline_access=E2=80=9C is =
OIDC specific. Is it time to move it down the stack to OAuth?

> 3. The AS MAY consider putting an upper bound on the lifetime of a =
refresh_token (e.g. 1 year). There is no real need to issue a =
refresh_token that is good indefinitely.=20

I thought I had covered that in the last section. It=E2=80=99s now:=20

Refresh tokens SHOULD expire if the client has been inactive for some =
time,=20
    	i.e. the refresh token has not been used to obtain fresh access =
tokens for=20
    	some time. The expiration time is at the discretion of the =
authorization server.=20
    	It might be a global value or determined based on the client =
policy or
    	the grant associated with the refresh token (and its =
sensitivity).

Proposals are welcome!

kind regards,
Torsten.=20


>=20
> This is in addition to the other best practices described.
>=20
> Thanks,
> George
>=20
> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>> Hi all,=20
>>=20
>> the new revision contains the following changes:
>>=20
>> * added section on refresh tokens=20
>> * additional justifications for recommendation for code
>> * refactored 2.1 in order to distinguish CSRF, authz response replay =
and mix-up (based on feedback by Joseph Heenan)
>> * added requirement to authenticate clients during code exchange =
(PKCE or client credential) to 2.1.1.
>> * changed occurrences of SHALL to MUST
>>=20
>> As always: looking forward for your feedback.
>>=20
>> kind regards,
>> Torsten.=20
>>=20
>>=20
>>> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org
>>> :
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>> This draft is a work item of the Web Authorization Protocol WG of =
the IETF.
>>>=20
>>>        Title           : OAuth 2.0 Security Best Current Practice
>>>        Authors         : Torsten Lodderstedt
>>>                          John Bradley
>>>                          Andrey Labunets
>>>                          Daniel Fett
>>> 	Filename        : draft-ietf-oauth-security-topics-10.txt
>>> 	Pages           : 38
>>> 	Date            : 2018-11-20
>>>=20
>>> Abstract:
>>>   This document describes best current security practice for OAuth =
2.0.
>>>   It updates and extends the OAuth 2.0 Security Threat Model to
>>>   incorporate practical experiences gathered since OAuth 2.0 was
>>>   published and covers new threats relevant due to the broader
>>>   application of OAuth 2.0.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>>=20
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>=20
>>>=20
>>> There are also htmlized versions available at:
>>>=20
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>>> =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>>>=20
>>>=20
>>> A diff from the previous version is available at:
>>>=20
>>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
>>>=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
>>> Internet-Drafts are also available by anonymous FTP at:
>>>=20
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>>=20
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>>=20
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_2FE4D7CE-383B-4888-B3A5-71F91FD7FE16
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjgxMDExNDNaMC8GCSqGSIb3DQEJBDEiBCCW
QzmyGUSZPf67YxrNTMlpOF/Rh2Up0R1WzeSzvvLp5zCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAgggIjWWVYQF8AKCkJM14pHDj
5/u6ng/RLpFaJhaz5qTKR3pkMlbMQgS1wz6gKDWocVzUW3bmqvuwSuHpcmuXsSA2YFf7zTLC8yH5
dxHaSzmXYut8hKIccG6Tk7hmc9rofaGnyo6VRm/6EgIRp65bKnC+YNvZL0WlvuwiSePyL1wWZe0l
S+1+5GFpmb8jzkJk1UVNMX6xyvnObNbxPIanPgQ8Ka2XlbKlnnPHlzxfkyn1MXT6i4kTsFEZfeCW
815KDO3wXzXcQI1bd0Gz7cn7O0VQA1CIQNWfri6ogjzsI9IsDqOIbgOfHDzQcmaUNt9hnaiUZTS9
6FvpwpECaWHbfwAAAAAAAA==
--Apple-Mail=_2FE4D7CE-383B-4888-B3A5-71F91FD7FE16--


From nobody Wed Nov 28 02:20:12 2018
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 3AEF8130E4F for ; Wed, 28 Nov 2018 02:20:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 mDSOwK0wfcGQ for ; Wed, 28 Nov 2018 02:20:08 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) (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 0A7E912D4ED for ; Wed, 28 Nov 2018 02:20:08 -0800 (PST)
Received: from [80.187.100.249] (helo=[172.20.10.2]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gRwws-0008DB-KC; Wed, 28 Nov 2018 11:20:03 +0100
From: Torsten Lodderstedt 
Message-Id: <3D954B49-010C-43FD-9878-C3CE905C8588@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_BD022AA2-6700-46D1-B5AD-5D64DAECDBE6"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 11:20:00 +0100
In-Reply-To: 
Cc: George Fletcher , OAuth WG 
To: Thomas Broyer 
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com> <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net> <45488c5d-54c8-a680-dc66-7fd5d4d41a7b@aol.com> 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 28 Nov 2018 10:20:10 -0000

--Apple-Mail=_BD022AA2-6700-46D1-B5AD-5D64DAECDBE6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

with the default cookie policy?=20

> Am 23.11.2018 um 14:34 schrieb Thomas Broyer :
>=20
> Just tested my OpenID Connect Session Management implementation with =
Safari 12.0.1 and it works like a charm.
>=20
> On Thu, Nov 22, 2018 at 8:09 PM George Fletcher =
 wrote:
> My understanding is that cookies are not blocked on redirects =
(IPT2/Safari) but I haven't done extensive testing. So from a full-page =
redirect perspective there should be no issues, from a hidden iframe I'm =
not sure... but I believe it will work.
>=20
>=20
> On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
>> Hi George,
>>=20
>>=20
>>> Am 20.11.2018 um 22:15 schrieb George Fletcher 
>>> :
>>>=20
>>> OIDC provides a "prompt=3Dnone" mechanism that allows the browser =
app to request a new token in a hidden iframe. OAuth2 doesn't describe =
this flow. Note that full authentications of users should NOT happen in =
iframes due to click-jacking attacks.
>>>=20
>> Does this still work reliably given the limitations imposed by the =
browser=E2=80=98s 3rd party cookie policies?
>>=20
>> kind regards,
>> Torsten.
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_BD022AA2-6700-46D1-B5AD-5D64DAECDBE6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjgxMDIwMDFaMC8GCSqGSIb3DQEJBDEiBCBJ
KJgFWNgQELAj2tpISJjFUSvtd91du2ZPwWRAzQVAEDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAlZ0zfPJJcHark+TQDoDUqH7+
/ifyQ7CCae64I+BpF7KRr/5YFEk3pEZooTK6NoumX8FJo9Tg4wIUXOSYX/6oStb4YNw/HOGAdYIz
kvDMSPac7GSTCNN/H1GIyOfmtAeJhdWmz+zRkhuPcbST0rxIPZdJ9D7mwXk9uyHQ3HHKb8r0ReLr
O9v3gpypyxXDNMkwATqb9TvwzSEhoQzCuOhf/GZ94+JjgDe4+dXhgW014RG+775fy++SgnmU38he
oKOqXIUdM/HiiocbKMmCFzpBvnwV8pMBLjxT9G/hcd/m2s1kAVTWMhGOnwd5v95i6neXO3NCPZ9h
IniajwhnYhjXUgAAAAAAAA==
--Apple-Mail=_BD022AA2-6700-46D1-B5AD-5D64DAECDBE6--


From nobody Wed Nov 28 03:00:11 2018
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 EC627130F73 for ; Wed, 28 Nov 2018 03:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63Dz5keHoocB for ; Wed, 28 Nov 2018 03:00:05 -0800 (PST)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA87D130E25 for ; Wed, 28 Nov 2018 03:00:04 -0800 (PST)
Received: by mail-oi1-x235.google.com with SMTP id t204so22173563oie.7 for ; Wed, 28 Nov 2018 03:00:04 -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=3P0AcE6Jmce8fXQsR7+GCIJdmm2si2T2gWGISr0V6A8=; b=P49T27Wu1yaVxGFlZwVNoV0PCmz5mmqNpxsEsNZ+YhQwEMUmL3y/yQiFPVTZImZMVM uZ2Qeh4TM65p8BeKk9iPSG9zYnYhiCgA2H8nmhqbvBdworFh6vIWOB5wXgYPhMhonXYp M8SHFSwWiTghSXuB1eM0hX05G3wUWbo5RxRnb4OZn0VXX42b9jw4IoMr11BXl0kySfuy KNYzO9STYRe79rZ2ZyfB5WcOCpR2q0dKsLCfaPw68xsnbqOfDJkGTluMySnYNTD8hm2w OrRem7walS/Nu3MG/N7K0znu9hX0D/QEecpk8WQeLAZB7UCuuHvOQ48IbA3QdbuPp5YY TMfg==
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=3P0AcE6Jmce8fXQsR7+GCIJdmm2si2T2gWGISr0V6A8=; b=YDww7pl8WbEVgryecvyXeXaDcRHI/V1XIDoQm4k217bF1fEVarwN+Id80efrmwzPpU aanmxnzlhNuo58SrkNH0mrz1TElfSEhsRgwaKw2Ixiw8GrweEa1pQu+Ep1jX9boNEwxD RqT9VVsCtztbzpibE5CD9yqa1m/2ZdoTN8r6Z/Uv7hfth9WHPe//tJyT1gHRGMRceNDs w2a5qibK93j5Ng66me2rw0xMwewU0+uldAfh37r3cFkgj0pncaZgxea4GKqXMQGjBq4T 5Tva6PE5AAH95gqN9pdDfkUfkGNeoHTSQehvluJ5MzWwFBsOizrjQprhXsowdVct8OZt AtdQ==
X-Gm-Message-State: AA+aEWZMqZx3wiN6fYBBMoTEoQV5uFuIJoA1mMu68uvTgANCSoWLNKQ2 DpNUhgwesm/PQ5RgdhsbRjEKTg293r472XF6ch1nww==
X-Google-Smtp-Source: AFSGD/XHLFt8wGZ5DOQ1B+CZtZDchyZDW8EKCIZpr5dFiNlIeIYdyZMTWDfiePUTCiEBPOl4NaB5U2uIqW9z+H9TH9s=
X-Received: by 2002:aca:368a:: with SMTP id d132mr21113390oia.193.1543402804078;  Wed, 28 Nov 2018 03:00:04 -0800 (PST)
MIME-Version: 1.0
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com> <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net> <45488c5d-54c8-a680-dc66-7fd5d4d41a7b@aol.com>  <3D954B49-010C-43FD-9878-C3CE905C8588@lodderstedt.net>
In-Reply-To: <3D954B49-010C-43FD-9878-C3CE905C8588@lodderstedt.net>
From: Thomas Broyer 
Date: Wed, 28 Nov 2018 11:59:52 +0100
Message-ID: 
To: Torsten Lodderstedt 
Cc: George Fletcher , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000e1ee42057bb777b4"
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 28 Nov 2018 11:00:08 -0000

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

Yes, that was with the default cookie policy (on a coworker's macbook, and
he doesn't use safari as his main browser)

On Wed, Nov 28, 2018 at 11:20 AM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> with the default cookie policy?
>
> > Am 23.11.2018 um 14:34 schrieb Thomas Broyer :
> >
> > Just tested my OpenID Connect Session Management implementation with
> Safari 12.0.1 and it works like a charm.
> >
> > On Thu, Nov 22, 2018 at 8:09 PM George Fletcher  40aol.com@dmarc.ietf.org> wrote:
> > My understanding is that cookies are not blocked on redirects
> (IPT2/Safari) but I haven't done extensive testing. So from a full-page
> redirect perspective there should be no issues, from a hidden iframe I'm
> not sure... but I believe it will work.
> >
> >
> > On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
> >> Hi George,
> >>
> >>
> >>> Am 20.11.2018 um 22:15 schrieb George Fletcher 
> >>> :
> >>>
> >>> OIDC provides a "prompt=3Dnone" mechanism that allows the browser app=
 to
> request a new token in a hidden iframe. OAuth2 doesn't describe this flow=
.
> Note that full authentications of users should NOT happen in iframes due =
to
> click-jacking attacks.
> >>>
> >> Does this still work reliably given the limitations imposed by the
> browser=E2=80=98s 3rd party cookie policies?
> >>
> >> kind regards,
> >> Torsten.
> >>
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>

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


    Yes, that was with the default cookie policy (on a coworke=
r's macbook, and he doesn't use safari as his main browser)
    On Wed, Nov 28, 2018 at 11:20=
 AM Torsten Lodderstedt <tors=
ten@lodderstedt.net> wrote:
    =
with the default cookie policy? 
    

    
> Am 23.11.2018 um 14:34 schrieb Thomas Broyer <t.broyer@gmail.com>:
    
> 
    
> Just tested my OpenID Connect Session Management implementation with S=
afari 12.0.1 and it works like a charm.
    
> 
    
> On Thu, Nov 22, 2018 at 8:09 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf=
.org> wrote:
    
> My understanding is that cookies are not blocked on redirects (IPT2/Sa=
fari) but I haven't done extensive testing. So from a full-page redirec=
t perspective there should be no issues, from a hidden iframe I'm not s=
ure... but I believe it will work.
    
> 
    
> 
    
> On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
    
>> Hi George,
    
>> 
    
>> 
    
>>> Am 20.11.2018 um 22:15 schrieb George Fletcher <gffletch@aol.com>
    
>>> :
    
>>> 
    
>>> OIDC provides a "prompt=3Dnone" mechanism that allow=
s the browser app to request a new token in a hidden iframe. OAuth2 doesn&#=
39;t describe this flow. Note that full authentications of users should NOT=
 happen in iframes due to click-jacking attacks.
    
>>> 
    
>> Does this still work reliably given the limitations imposed by the=
 browser=E2=80=98s 3rd party cookie policies?
    
>> 
    
>> kind regards,
    
>> Torsten.
    
>> 
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org=

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

    

    

--000000000000e1ee42057bb777b4--


From nobody Wed Nov 28 04:22:27 2018
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 EB97B130F5F for ; Wed, 28 Nov 2018 04:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDLLPBwncapO for ; Wed, 28 Nov 2018 04:22:23 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961E2130DCE for ; Wed, 28 Nov 2018 04:22:21 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id q1so16571707qkf.13 for ; Wed, 28 Nov 2018 04:22:21 -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=OqKLX4pBrTU9rOY4zJ+DMyhs4L0z/vUJEMUBR772GIE=; b=UhB/zR28bhchEhJriLmYLjd/9U99N36RP7mQw6PpW5mDwpj6DRqtCuO1fKa9jVdCgP 7IfhyyFGtPyOMC3gy2pbjSKfbXF6vg20tV6rv35r931dnXLK9d2r7MW/8IThMx+P5F5r ngHRZUQnHYus1Xuds2Z5BkIrJ/tV88VOExdvBKKuylnwh6zWmHGl2MvPxFyR0l+EPdI+ dD/dnDl41m8XxJZJnGzznd70uUJPhILmATu95FkfyOpv/Tw7TrGy6zryr/yGfFMNf38q hiMWOUpi52DBFrnl6jjvLPC07uf/K/pP7NmohuNy6Ok3RYLQK//cDGDwUM7kp/am+GM0 ht7w==
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=OqKLX4pBrTU9rOY4zJ+DMyhs4L0z/vUJEMUBR772GIE=; b=c0yd+JQKxtERZ8PLzSmfP3q0jpjibZqPDrwX9XfgUnDbLVNOJdrpUU4QcmjTu35HTm 465epCSDzsoGJw32+IhDJsucBeAgtqpIznOvTp5xOH3/O+cuorBitUpGFGa7+jARH/og bSu5mqiurMQkoBFNqZIJDG1uzd6qbp9BgCX23G5Jaqx+cWAPxsicK0zUq+Syc5Qg/GGC nQzGwv50zlVt4xkM9qCqJm/hGJIzsxzsex5pA9Dn0WQmAaMbcE581P8+3PLLLibhV7q2 Ongi6WoW6K4533tPg7eZTvxRSvDy95n2hLQSu2VRGlwNRLYnX0YQFC9aiap/0SnQR6P3 ZccQ==
X-Gm-Message-State: AA+aEWY0kD+4UmKkfbt/mXCy4M+uGvxPxJ41pjXd9jAoraXZiQ6nQNi6 hFA9zMbRm3RM7daQoIlFsHwPT2rLUoLr1M1uHA==
X-Google-Smtp-Source: AFSGD/XS2ZROTqeST0SPNxmkcBCg6l++gDTZWjFCeqyhFMnopUUyLvkI1oVgr+g4w8+c1eFId6A3/SLeFI8zDRTiPUU=
X-Received: by 2002:a37:c3c3:: with SMTP id r64mr33469528qkl.70.1543407740654;  Wed, 28 Nov 2018 04:22:20 -0800 (PST)
MIME-Version: 1.0
References: <00A97A82-1D5E-47C5-8C90-40C7E66651C0@lodderstedt.net>   <848fbf40-dfb9-249f-a2d8-6ca24a422e1d@aol.com> <5D13E8C2-A995-4A7A-A27C-8DDB8E4E73F2@lodderstedt.net> <45488c5d-54c8-a680-dc66-7fd5d4d41a7b@aol.com>  <3D954B49-010C-43FD-9878-C3CE905C8588@lodderstedt.net> 
In-Reply-To: 
From: Reman Child 
Date: Wed, 28 Nov 2018 04:22:09 -0800
Message-ID: 
To: Thomas Broyer 
Cc: torsten@lodderstedt.net, gffletch=40aol.com@dmarc.ietf.org, oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000201968057bb89e9b"
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh Token Expiration
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, 28 Nov 2018 12:22:25 -0000

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

ITP cookie blocking doesn't kick in until a site is classified as a tracker
- if it's a fresh browser, everything will work. That's why you need to
test with the ITP debug tools to set your site as prevalent.

On Wed, Nov 28, 2018 at 3:00 AM Thomas Broyer  wrote:

> Yes, that was with the default cookie policy (on a coworker's macbook, an=
d
> he doesn't use safari as his main browser)
>
> On Wed, Nov 28, 2018 at 11:20 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> with the default cookie policy?
>>
>> > Am 23.11.2018 um 14:34 schrieb Thomas Broyer :
>> >
>> > Just tested my OpenID Connect Session Management implementation with
>> Safari 12.0.1 and it works like a charm.
>> >
>> > On Thu, Nov 22, 2018 at 8:09 PM George Fletcher > 40aol.com@dmarc.ietf..org <40aol.com@dmarc.ietf.org>> wrote:
>> > My understanding is that cookies are not blocked on redirects
>> (IPT2/Safari) but I haven't done extensive testing. So from a full-page
>> redirect perspective there should be no issues, from a hidden iframe I'm
>> not sure... but I believe it will work.
>> >
>> >
>> > On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
>> >> Hi George,
>> >>
>> >>
>> >>> Am 20.11.2018 um 22:15 schrieb George Fletcher 
>> >>> :
>> >>>
>> >>> OIDC provides a "prompt=3Dnone" mechanism that allows the browser ap=
p
>> to request a new token in a hidden iframe. OAuth2 doesn't describe this
>> flow. Note that full authentications of users should NOT happen in ifram=
es
>> due to click-jacking attacks.
>> >>>
>> >> Does this still work reliably given the limitations imposed by the
>> browser=E2=80=98s 3rd party cookie policies?
>> >>
>> >> kind regards,
>> >> Torsten.
>> >>
>> >
>> > _______________________________________________
>> > 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
>

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


    ITP cookie blocking doesn't kick in until a site is cl=
assified as a tracker - if it's a fresh browser, everything will work. =
That's why you need to test with the ITP debug tools to set your site a=
s prevalent.

    On Wed, N=
ov 28, 2018 at 3:00 AM Thomas Broyer <t.broyer@gmail.com> wrote:
    Yes, that was with the default cookie policy (on a cowo=
rker's macbook, and he doesn't use safari as his main browser)
    On Wed, Nov 28, 2018 at 11=
:20 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    with the default cookie policy? 
    

    
> Am 23.11.2018 um 14:34 schrieb Thomas Broyer <t.broyer@gmail.com>:
    
> 
    
> Just tested my OpenID Connect Session Management implementation with S=
afari 12.0.1 and it works like a charm.
    
> 
    
> On Thu, Nov 22, 2018 at 8:09 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf=
..org> wrote:
    
> My understanding is that cookies are not blocked on redirects (IPT2/Sa=
fari) but I haven't done extensive testing. So from a full-page redirec=
t perspective there should be no issues, from a hidden iframe I'm not s=
ure... but I believe it will work.
    
> 
    
> 
    
> On 11/21/18 11:49 PM, Torsten Lodderstedt wrote:
    
>> Hi George,
    
>> 
    
>> 
    
>>> Am 20.11.2018 um 22:15 schrieb George Fletcher <gffletch@aol.com>
    
>>> :
    
>>> 
    
>>> OIDC provides a "prompt=3Dnone" mechanism that allow=
s the browser app to request a new token in a hidden iframe. OAuth2 doesn&#=
39;t describe this flow. Note that full authentications of users should NOT=
 happen in iframes due to click-jacking attacks.
    
>>> 
    
>> Does this still work reliably given the limitations imposed by the=
 browser=E2=80=98s 3rd party cookie policies?
    
>> 
    
>> kind regards,
    
>> Torsten.
    
>> 
    
> 
    
> _______________________________________________
    
> 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
    

    

--000000000000201968057bb89e9b--


From nobody Wed Nov 28 05:20:20 2018
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 15069130F82 for ; Wed, 28 Nov 2018 05:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 kceu_gDN62zM for ; Wed, 28 Nov 2018 05:20:15 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 F27D3130F7B for ; Wed, 28 Nov 2018 05:20:14 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id x6so19937179ioa.9 for ; Wed, 28 Nov 2018 05:20:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v5un9+wYmVZD82w5oE1V1U99PnoHbR2eKGD5dmNJf3I=; b=OHvw+A/C2p1X7f9Q6i5D2vBiiSKlhXxeG2cnUFUHq2hLbkfJ6M+G2LvHa9iclvXw1N XAK5aRim3cC3Y/aMesK4JFXCfFCGWhAbPjnqpipeCGXDVdTbe4T7TUoZ9LSOJmRlAmtI Wn/Xr4k13qSUCLchhQF0xH7nNanvUe8R/9o94=
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=v5un9+wYmVZD82w5oE1V1U99PnoHbR2eKGD5dmNJf3I=; b=SfcHIB9iaIy34uCcbeXsWhXKQ6MbEZwoHbC4GZDUuLRa616FSgaKg3sCLAz6ngWFHI o3Kz6OhyZQ+2rKdGC3bU0SstpeMtxRlq/RAiLzoYeqCzetsr3jrCMelXnLtZVbn4K284 BQtRVPpk2F4SZCf364+LkaGiI/ylPQ69QgoPa+p6myYgQxK+ZajlDPLn9LN+I+YnPT3z ySbMgAQYqDoqLOQLRgC60/VqXKeq0hPH+ZQW4hLrdhiImrmFjxMeQhAWGbvkVu1I62hn 9gggXfW1grn7FrfKptH1KZMF0PJcTOOm7E4PQAl1PhL3/rmnPjzU0OSHlH3EXRDiq2y0 tPow==
X-Gm-Message-State: AA+aEWbL7wnJgJhdaf4I8TPr/ooAbXpeOs23q6jqIHy9td0zZB2pZhjL SGM5PB2aOvWQfJ0r2IVe+ip6yAMDcwuwlExQ4GDzBwYuiKDIwhHcAGLxJYSkLhx6uiMQe2JlkBw XXRlJdCW3Io9lbw==
X-Google-Smtp-Source: AFSGD/Xx33llGM7hzxJNz2uuOyBuC1731G96r+1yPwpVOVj9hSiWkXQqAKDp0Nb4p7IW2CAXrSm7bGfTKVu4+k+dW10=
X-Received: by 2002:a5d:8597:: with SMTP id f23mr25762420ioj.238.1543411214149;  Wed, 28 Nov 2018 05:20:14 -0800 (PST)
MIME-Version: 1.0
References: <154275717351.29758.7019772753190449469.idtracker@ietfa.amsl.com>
In-Reply-To: <154275717351.29758.7019772753190449469.idtracker@ietfa.amsl.com>
From: Brian Campbell 
Date: Wed, 28 Nov 2018 06:19:47 -0700
Message-ID: 
To: Adam Roach 
Cc: The IESG , oauth ,  draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000298b3e057bb96d7c"
Archived-At: 
Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 13:20:19 -0000

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

Thank you for the review, Adam. I do sincerely hope that your time with the
document didn't drive you to drink (too much anyway). Please see below for
inline comments/responses.

On Tue, Nov 20, 2018 at 4:39 PM Adam Roach  wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-oauth-token-exchange-16: Discuss
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to everyone who worked on this document. I have a blocking issue
> that
> should be easy to resolve, and a handful of more minor issues.
>
> =C2=A72.1:
>
> >  The client makes a token exchange request to the token endpoint with
> >  an extension grant type by including the following parameters using
> >  the "application/x-www-form-urlencoded" format
>
> This document needs a normative citation for this media type.
>
> My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as
> this
> appears to be the most recent stable description of how to encode this
> media
> type. I'd love to hear rationale behind other citations being more
> appropriate,
> since I'm not entirely happy with the one I suggest above (given that it'=
s
> been
> superseded by HTML 5.2); but every other plausible citation I can find is
> even
> less palatable (with HTML 5.2 itself having the drawback of not actually
> defining how to encode the media type, instead pointing to an unstable,
> unversioned document).
>

What about a pointer to RFC6749's Appendix B. on the "Use of
application/x-www-form-urlencoded Media Type"
? I had admittedly forgot
about it until looking back at the original OAuth 2.0 document as a result
of you raising this DISCUSS to see what citation was used there.

Despite citing an older HTML document I think the few paragraphs there do a
nice job of explaining the situation in a pragmatic and actionable way.
And as the original OAuth 2.0 Authorization Framework is responsible for
the use of "application/x-www-form-urlencoded" in extensions like this
token exchange, it seems fitting to point back to it.

I'm happy to cite REC-html5-20141028 section 4.10.22.6, if you feel that's
more appropriate. But wanted to throw that other idea out there to see if
you find that any more palatable.



>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Abstract:
>
> >  This specification defines a protocol for an HTTP- and JSON- based
>
> Nit: "...JSON-based..."
>
>
Will fix.



> -------------------------------------------------------------------------=
--
>
> =C2=A71.1:
>
> >  impersonates principal B, then in so far as any entity receiving such
>
> Nit: "insofar"
>
>
This will be fixed insofar as you are right.


---------------------------------------------------------------------------
>
> =C2=A72.1:
>
> >  The client makes a token exchange request to the token endpoint with
> >  an extension grant type by including the following parameters using
> >  the "application/x-www-form-urlencoded" format with a character
> >  encoding of UTF-8 in the HTTP request entity-body:
>
> I think there's an implication here that POST is used, but that probably
> needs
> to be made explicit.
>

The use of POST is effectively inherited by token exchange utilizing
an extension
grant  via the token
endpoint  where the
'client MUST use the HTTP "POST" method when making access token requests'.

But there's no harm in this document restating that its POST. So I'll
change it to make that explicit.



>
> -------------------------------------------------------------------------=
--
>
> =C2=A72.2.1:
>
> >  response using the "application/json" media type, as specified by
> >  [RFC7159], and an HTTP 200 status code.  The parameters are
>
> RFC 7159 has been replaced by RFC 8259.
>

I remember feeling rather cutting edge 3ish years ago when using the RFC
7159 citation rather than 4627. But times change. I'll update the document
to cite 8259.



> -------------------------------------------------------------------------=
--
>
> =C2=A73:
>
> >  urn:ietf:params:oauth:token-type:refresh_token
> >     Indicates that the token is an OAuth 2.0 refreshe token issued by
>
> nit: "refresh"
>

I seem to have had a bit of a Freudian slip there revealing my affection
for (or addiction to) the cheap Safeway store brand of sparkling water.
I'll fix that in the document.

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

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


    Thank you for the review, Adam. I do sincerel=
y hope that your time with the document didn't drive you to drink (too =
much anyway). Please see below for inline comments/responses.=C2=A0 

    On Tue, Nov 20, 2018 at 4=
:39 PM Adam Roach <adam@nostrum.com> wrote:
    Adam Roach has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss
    

    
Please refer to https://www.ietf.org/iesg/s=
tatement/discuss-criteria.html
    
for more information about IESG DISCUSS and COMMENT positions.
    

    

    
The document, along with other ballot positions, can be found here:
    
https://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-token-exchange/
    

    

    

    
----------------------------------------------------------------------
    
DISCUSS:
    
----------------------------------------------------------------------
    

    
Thanks to everyone who worked on this document. I have a blocking issue tha=
t
    
should be easy to resolve, and a handful of more minor issues.
    

    
=C2=A72.1:
    

    
>=C2=A0 The client makes a token exchange request to the token endpoint =
with
    
>=C2=A0 an extension grant type by including the following parameters us=
ing
    
>=C2=A0 the "application/x-www-form-urlencoded" format
    

    
This document needs a normative citation for this media type.
    

    
My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as thi=
s
    
appears to be the most recent stable description of how to encode this medi=
a
    
type. I'd love to hear rationale behind other citations being more appr=
opriate,
    
since I'm not entirely happy with the one I suggest above (given that i=
t's been
    
superseded by HTML 5.2); but every other plausible citation I can find is e=
ven
    
less palatable (with HTML 5.2 itself having the drawback of not actually
defining how to encode the media type, instead pointing to an unstable,
    
unversioned document).

    What about a poi=
nter to RFC6749's Appendix B. on the "Use of application/x-www=
-form-urlencoded Media Type"? I had admittedly forgot about it unt=
il looking back at the original OAuth 2.0 document as a result of you raisi=
ng this DISCUSS to see what citation was used there.

     Despite citing an older HTML document I think the few paragraphs there =
do a nice job of explaining the situation in a pragmatic and actionable way=
.=C2=A0 And as the original OAuth 2.0 Authorization Framework is responsibl=
e for the use of "application/x-www-form-urlencoded" in extension=
s like this token exchange, it seems fitting to point back to it.

    I'm happy to cite REC-html5-20141028 section 4.10.22.6,=
 if you feel that's more appropriate. But wanted to throw that other id=
ea out there to see if you find that any more palatable. 
    =C2=
=A0

    

    

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

    
Abstract:
    

    
>=C2=A0 This specification defines a protocol for an HTTP- and JSON- bas=
ed
    

    
Nit: "...JSON-based..."
    


    Will fix.

    =C2=
=A0
    
---------------------------------------------------------------------------=

    

    
=C2=A71.1:
    

    
>=C2=A0 impersonates principal B, then in so far as any entity receiving=
 such
    

    
Nit: "insofar"
    


    This will be fixed insofar as you are =
right. 
    =C2=A0

    
---------------------------------------------------------------------------=

    

    
=C2=A72.1:
    

    
>=C2=A0 The client makes a token exchange request to the token endpoint =
with
    
>=C2=A0 an extension grant type by including the following parameters us=
ing
    
>=C2=A0 the "application/x-www-form-urlencoded" format with a =
character
    
>=C2=A0 encoding of UTF-8 in the HTTP request entity-body:
    

    
I think there's an implication here that POST is used, but that probabl=
y needs
    
to be made explicit.

    The use of POST is=
 effectively inherited by token exchange utilizing an extension grant via the token endpoint where the 'client MUST use the HTTP &qu=
ot;POST" method when making access token requests'. 

    But there's no harm in this document restating that its=
 POST. So I'll change it to make that explicit.

    =C2=A0
    

    
---------------------------------------------------------------------------=

    

    
=C2=A72.2.1:
    

    
>=C2=A0 response using the "application/json" media type, as s=
pecified by
    
>=C2=A0 [RFC7159], and an HTTP 200 status code.=C2=A0 The parameters are=

    

    
RFC 7159 has been replaced by RFC 8259.

    I remember feeling rather cutting edge 3ish years ago when using the RFC 7=
159 citation rather than 4627. But times change. I'll update the docume=
nt to cite 8259.
    =C2=A0

    

    
---------------------------------------------------------------------------=

    

    
=C2=A73:
    

    
>=C2=A0 urn:ietf:params:oauth:token-type:refresh_token
    
>=C2=A0 =C2=A0 =C2=A0Indicates that the token is an OAuth 2.0 refreshe t=
oken issued by
    

    
nit: "refresh"

    I seem to have=
 had a bit of a Freudian slip there revealing my affection for (or addictio=
n to) the cheap Safeway store brand of sparkling water. I'll fix that i=
n the document. 
    <=
/div>
    


    
<=
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.
--000000000000298b3e057bb96d7c--


From nobody Wed Nov 28 07:47:40 2018
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 4206E130E19 for ; Wed, 28 Nov 2018 07:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlzWYIbr7e_T for ; Wed, 28 Nov 2018 07:47:34 -0800 (PST)
Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (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 83FDD128CF3 for ; Wed, 28 Nov 2018 07:47:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1543420052; bh=3WsmAzeN8xE64JQd3FdE/pyteT6j2l2lptEXlQ/B10Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=TfUz5E9mf0/iXNFvw7mJ7jyIAaI3ZiXFvr9aaVYLzS6w9dIf7Jdp9CU5+a4sehkMCOP+3aP9atzXyWYxvkKbfz3QHpv/fCWaEOlQb+zWVkvQng9LXXoOcvC8jTR9Sf7tR1GQRXbgb1BkHOcu705E9bY+pJGDgk2ZckF08ubw3jJ6uh0Nw5g+YqhqCRbxJQSGTSo/EBMZBYkXIkiFGiLJgDlZV37UpjdSnNltUIA0uIhLFEUZu03QtRrRtYN5N1T+Y3CENjTXIuPEvSnJGED7e3IpJXgMCtF1Aviu4PDPiNL0WVi+oZQO9fAckwKdiRGVRWlbdmFSOzDgGWPQJFnuzg==
X-YMail-OSG: wT4v61EVM1kAGdISZC0dPCY2akQsfqMjOpGblHREdzEre.I4xb5LSShaebIu7zb U8V9BRRHpBAkph9EbkhCd9ZnPba.Of7C5Tf6g9iqoFqBg5K6Ia8Xn51zqe295rKhmk8NgtWFi51Z GfNiDqgCoqG.86m_YAPriGoY2l.Pc0GLpoPMWnxWh_E5tNx0Wj718p4w0Pa6xDqqQbexAPT2IjtS hIiXb0QOkwvJ2DJsZS6IQv6Umla8dDd2Hy687RoFWN67.v9WP00BVMbYdQN2IqGvx2iYYQOuZXt8 NB2Es9u.fDzFhLE4jsCrz32eNd_XqrPsaMhmQkfstHAyod5pTFOGZE_poP5DFA_El.DVFNupK3o6 jl3XjJqFJAAm7QuUqq_cNNIiPN86SpJSzZKHMGHR3RYl9CdgBzauV6sBcOZS5FuaDsVENy7D1DFb dio6DJnP8dvVyZ9c_6G0gGTXLj.rJF7Z7gosqnuKrDbrtnABbW3Nvks4yiJKmiTzY8TLDZ9f.0TV J9mRlIEmzfvzDA6F59EVbYWAx9a3SK7tAiIfi5tp83qM8Nz_.yqmSR.5wz5rZgwbRO7CJMVXeOW5 D.CQiQDUzc95THcU3sRhwOdKzH7Gybnx50vRm5ESXwkOe0E6oYwHwuexL4UZVejGNCW9H42HEDEp z5gXZlzPn19_jCw_3Nv0VZMhFed6cIDaJTsmVsK0d_zicAJeYAT2_ygihRVPTJfmQ6E5CYV3aCON Bt97MOfR6637dL4cJRUPNo4apOvMRfPMJ5IjTkeEealcsT9j0AsGJQK9EIRKCz4trCJ_ifsv2ECI Bnvul6bitn6Vy9MRWSjYrhaAJllrTxk0iCcYrTicpxRWKIHarkY4Mwjn78VTT82zA_Brm5QfWBxa 05_g3i9Mpb3fVVVVq1s_cKC2VwxszIBY4uln5AxoOPOpISnS5REW_t.Cu9gwm.H8AlPpNOCtVq1r xsuJxBn13zzvy61vedGd09Y8aZEDSdXOYZGhbdOpr2KSFNBVxj3OPkF6pc9AeX9yQIECdbRCNA7A jxyCBg792XKVSUQ7DMNkMx4nCplxFHd2vvUi8olTHAcMR7xeEfZVZ
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Nov 2018 15:47:32 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID aea8c48f71b1ad0fca42c7fc8e57161e;  Wed, 28 Nov 2018 15:47:28 +0000 (UTC)
To: William Denniss , Christian Mainka 
Cc: oauth 
References:  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>
Date: Wed, 28 Nov 2018 10:47:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F27B06A66E00259BFB1697A6"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 28 Nov 2018 15:47:38 -0000

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

In addition, a few additional patterns are enabled...

1. The native app can generate a public/private key pair and then use 
private_secret_jwt as the client credential validation method via the 
client credentials flow (defined in OpenID Connect).

2. Maybe more simply, if the native app is issued a shared secret, the 
app can use client_secret_jwt method for client authentication which 
ensures the shared secret never leaves the device. (Again defined in the 
OpenID Connect spec).

3. Once the native app instance has credentials, they can be used for 
additional securing of app API transactions in addition to just the 
OAuth2/OpenID Connect flows.

Thanks,
George

On 11/27/18 3:28 PM, William Denniss wrote:
> If the secret is dynamically provisioned then you have a confidential 
> client. Anyone reverse engineering their own installation of the 
> native app would only extract their own client's credentials, as 
> opposed to the shared secret of all installations. Having a 
> confidential client means that requests to the token endpoint (code, 
> refresh) are client authenticated, so PKCE wouldn't be needed.
>
> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka 
>  > wrote:
>
>     Hi,
>
>     we just stumbled upon this [1] statement:
>     "Except when using a mechanism like Dynamic Client Registration
>        [RFC7591] to provision per-instance secrets, native apps are
>        classified as public clients ..."
>
>     What does this mean for us? Native App + Dynamic Client Registration =
>     Confidential Client?
>     Which threats are covered if Dynamic Client Registration is used on
>     Native Apps?
>
>     Best Regards,
>     Vladi/Christian
>
>     [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>     
>
>     -- 
>     Dr.-Ing. Christian Mainka
>     Horst Görtz Institute for IT-Security
>     Chair for Network and Data Security
>     Ruhr-University Bochum, Germany
>
>     Universitätsstr. 150, ID 2/463
>     D-44801 Bochum, Germany
>
>     Telefon: +49 (0) 234 / 32-26796
>     Fax: +49 (0) 234 / 32-14347
>     http://nds.rub.de/chair/people/cmainka/
>     
>     @CheariX
>
>
>     _______________________________________________
>     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


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


  
    
  
  
    In addition, a few
      additional patterns are enabled...
    
      
    
      1. The native app can generate a public/private key pair and then
      use private_secret_jwt as the client credential validation method
      via the client credentials flow (defined in OpenID Connect).
    
      
    
      2. Maybe more simply, if the native app is issued a shared secret,
      the app can use client_secret_jwt method for client authentication
      which ensures the shared secret never leaves the device. (Again
      defined in the OpenID Connect spec).
    
      
    
      3. Once the native app instance has credentials, they can be used
      for additional securing of app API transactions in addition to
      just the OAuth2/OpenID Connect flows.
    
      
    
      Thanks,
    
      George
    
      
    
        
    
    On 11/27/18 3:28 PM, William Denniss
      wrote:
    
    
    
    
    
      
      
    If the secret is dynamically provisioned then you
        have a confidential client. Anyone reverse engineering their own
        installation of the native app would only extract their own
        client's credentials, as opposed to the shared secret of all
        installations. Having a confidential client means that requests
        to the token endpoint (code, refresh) are client authenticated,
        so PKCE wouldn't be needed.
    
      

    
        
    On Tue, Nov 27, 2018 at 1:44 AM,
          Christian Mainka <Christian.Mainka=40rub.de@dmarc.ietf..org>
          wrote:
    
          
    Hi,
    
            
    
            we just stumbled upon this [1] statement:
    
            "Except when using a mechanism like Dynamic Client
            Registration
    
               [RFC7591] to provision per-instance secrets, native apps
            are
    
               classified as public clients ..."
    
            
    
            What does this mean for us? Native App + Dynamic Client
            Registration =
    
            Confidential Client?
    
            Which threats are covered if Dynamic Client Registration is
            used on
    
            Native Apps?
    
            
    
            Best Regards,
    
            Vladi/Christian
    
            
    
            [1]: https://tools.ietf.org/html/rfc8252#section-8.4
    
            
    
            -- 
    
            Dr.-Ing. Christian Mainka
    
            Horst Görtz Institute for IT-Security 
    
            Chair for Network and Data Security 
    
            Ruhr-University Bochum, Germany
    
            
    
            Universitätsstr. 150, ID 2/463
    
            D-44801 Bochum, Germany
    
            
    
            Telefon: +49 (0) 234 / 32-26796
    
            Fax: +49 (0) 234 / 32-14347
    
            http://nds.rub.de/chair/people/cmainka/
    
            @CheariX
    
            
    
            
    
            _______________________________________________
    
            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

    
    
    
    
    
  


--------------F27B06A66E00259BFB1697A6--


From nobody Wed Nov 28 07:54:00 2018
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 A3718129385 for ; Wed, 28 Nov 2018 07:53:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 q0j4gc-4UE68 for ; Wed, 28 Nov 2018 07:53:56 -0800 (PST)
Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 1C623128CF3 for ; Wed, 28 Nov 2018 07:53:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1543420434; bh=Q/z9FdnWQ0p+NXjn4oAMhGVCZM+hLdlOiiGVKfWcoo4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=aT30+bqNnauorzSwd1IIEgOkliaRwezAy/JknIT09+GWb6arDYj/UnyFRb8pBNdBPs+M1T4OYgT6F3B8JQk0ClE0ATnohpa+Ugxd/vrfEoWaVt/+GPTSM/M396vGAb+nRlCffPDsfFkNpzvwmvFD7r9vgeKMniXBq+ZhGg2Q3oAOIQIjtqjfVlKj8/b6C1+Tw/VejVlP/XKa6ylh9gPVEQaIJ9XqgJugVATxkZ4FCWeKJinE9zrn0X5xoUJPhXlHq/ZpL/9v2d6wNFBIx1a12/1CDKaiF23PGSgm3qgtn+yrXhangXfYUL+Y8MNYr/sIcvWJqjAcN/g+lvWoR2nAlg==
X-YMail-OSG: Brgqc1IVM1kpIzXCRSdHERn.uI7bNUAWSkKpO5XnTosbF7uteh_NxmYFcKIpXe6 Up7wfHS1mkkk8g5oGg9srLUQTZ6ukabyd.tSo3HzgZ260jYPOq.r5kT.QGAMGsSCGm1oZYPxC8B5 Ra.tJpCxSuEkvB6ettJhbTe1HGCkl.aANdGN1Ox4vHqpJKL0Zw9bktP31FX0x27nOj2I4Y.NDyH8 pf5mok2OZTPw7eyVgD4Fna9_kQmgRF4QMy5NJV3L.gt0labIYnawHlLdcLzCA81fpXMVRZ2Mx8DI G1wxmqW2iIXjOOdfgD20NQ9wwrTzijx0PpJlsJs1cNINUCdpwFyCFO8MWheJmXuwWbGYOWUtIXl2 NO4Fkf6eppOLJ87OxlKarrAydt0bK9lVbwLNKE_5cwbv.A.wPs2kRYzEJ2RCOOfY.wYDdXKLc950 lUz6P8WebH7P26ssPmx9qLN_XodgzNTg0t6CaHeob5DVg.be7jXUfILZNssEqEujmBNqWEAefhGp AGyjTRyZXN14GrJM.Qig4n.7rAd.ctOo1pIHSU3QZNyo9FSni7s6aYRPZAR8iA1beyUpUdnEvZza u92AhSLJMMRbu1Or8kH3J2nAi5cM9hFFbwGf9OfdZzPwX1VxQxaLCgmSU3F4keNMBBVIQyDnlSsq vIveWfv22QWo3gzmJmlRI0eCGsR7Bz8VUI04mKG.5qb8FGIlh42.NIDHR6x0M.nOVBESg.Ulupes 0DlG6qjO_smwKjkiWcdCft9kd0WbkfyYB3W7z2k.SzKXOoA6inZHuFJjn9YK4ThnhxelcmPHJOQG ax_nXq8mc7iyQoQUEEeL3A2QqmT94xaa3qlWP86in0ajx7_DpLBMiBkzR1t.FrY3RdFH.CA1URcl ex2NQEig.dwjc3.lgjNS9eZq5onoc1RpX39PTLuiMnyD83l_ghXCmaBoQUXMmUTuj1N58wg3cQEW OpSRhD6uzFr8ZM29XQ.N458N8Da05d4RnwWrmHyFxA4t67potbK5eJCNp4_0za_rOTCTckJuOM9N d3Xd4kZDa6v1AwoV.T.kfSRoKlDZ4n46YvtyWm9Wiw76WsPzbgHE8jcA.TWshzijsAA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Nov 2018 15:53:54 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 715276a4a41282184678f25a87ac210d;  Wed, 28 Nov 2018 15:53:52 +0000 (UTC)
To: Torsten Lodderstedt 
Cc: oauth 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com> <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Wed, 28 Nov 2018 10:53:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 28 Nov 2018 15:53:59 -0000

On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
> Hi George,
>
>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>
>> Thanks for the additional section on refresh_tokens. Some additional recommendations...
>>
>> 1. By default refresh_tokens are bound to the user's authenticated session. When the authenticated session expires or is terminated (whether by the user or for some other reason) the refresh_tokenis implicitly revoked.
> SHOULD or MUST? I would suggest to go with a SHOULD.
I would say that the AS SHOULD bind the refresh_token to the user's 
authentication. However, I'd lean more to MUST for session bound 
refresh_tokens being revoked when the session is terminated.
>
>> 2. Clients that need to obtain a refresh_token that exists beyond the lifetime of the user's authentication session MUST indicate this need by requesting the "offline_access" scope (https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). This provides for a user consent event making it clear to the user that the client is requesting access even when the user's authentication session expires. This then becomes the default for mobile apps as the refresh_token should not be tied to the web session used to authorize the app.
> Sounds reasonable, just the scope „offline_access“ is OIDC specific. Is it time to move it down the stack to OAuth?
It may be if we want more consistency in the implementation of 
refresh_token policy across authorization servers.
>
>> 3. The AS MAY consider putting an upper bound on the lifetime of a refresh_token (e.g. 1 year). There is no real need to issue a refresh_token that is good indefinitely.
> I thought I had covered that in the last section. It’s now:
>
> Refresh tokens SHOULD expire if the client has been inactive for some time,
>      	i.e. the refresh token has not been used to obtain fresh access tokens for
>      	some time. The expiration time is at the discretion of the authorization server.
>      	It might be a global value or determined based on the client policy or
>      	the grant associated with the refresh token (and its sensitivity).
This is slightly different but sufficient so +1 for the text :)
>
> Proposals are welcome!
>
> kind regards,
> Torsten.
>
>
>> This is in addition to the other best practices described.
>>
>> Thanks,
>> George
>>
>> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>>> Hi all,
>>>
>>> the new revision contains the following changes:
>>>
>>> * added section on refresh tokens
>>> * additional justifications for recommendation for code
>>> * refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up (based on feedback by Joseph Heenan)
>>> * added requirement to authenticate clients during code exchange (PKCE or client credential) to 2.1.1.
>>> * changed occurrences of SHALL to MUST
>>>
>>> As always: looking forward for your feedback.
>>>
>>> kind regards,
>>> Torsten.
>>>
>>>
>>>> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org
>>>> :
>>>>
>>>>
>>>> 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 Security Best Current Practice
>>>>         Authors         : Torsten Lodderstedt
>>>>                           John Bradley
>>>>                           Andrey Labunets
>>>>                           Daniel Fett
>>>> 	Filename        : draft-ietf-oauth-security-topics-10.txt
>>>> 	Pages           : 38
>>>> 	Date            : 2018-11-20
>>>>
>>>> Abstract:
>>>>    This document describes best current security practice for OAuth 2.0.
>>>>    It updates and extends the OAuth 2.0 Security Threat Model to
>>>>    incorporate practical experiences gathered since OAuth 2.0 was
>>>>    published and covers new threats relevant due to the broader
>>>>    application of OAuth 2.0.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>
>>>>
>>>> There are also htmlized versions available at:
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>>>>
>>>>
>>>> A diff from the previous version is available at:
>>>>
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10
>>>>
>>>>
>>>>
>>>> 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/
>>>>
>>>>
>>>> _______________________________________________
>>>> 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


From nobody Wed Nov 28 08:03:39 2018
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 69CD9130E12 for ; Wed, 28 Nov 2018 08:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 l11rZ2-hXPpo for ; Wed, 28 Nov 2018 08:03:30 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA14130DCD for ; Wed, 28 Nov 2018 08:03:30 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id y23so23000155oia.4 for ; Wed, 28 Nov 2018 08:03: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;  bh=MpTg1mYVQ+sH+rtZLl/VRpy0ZpIjxhMwzm1GZ3c+Kk8=; b=NFgTlmt7iGVYDMUtoKCRJFiRrS4CAMl0qbYPrzEnW4RcYJtM0aKfZ0PDESZhMzbXwy rG1YJY20GkD//cZLtMcaUNnhvfuIXaUjrpQI3TclkUJFvC2i5u/Vi9upuX1z6QCYk2fg W1i3BZMnXNpJOeOwlzAbtwBYmh4sfp1fT5c06avziflUkR+MTreX18jkx1dJd3wGrjBj UfrSOgqjBXksEAgfIfUFceVG5jr9JixGN0+jonEgK8O8PAYOzexCeGpBEmZeOwxtPDVT qM78NXnWtybSGeHo5QbeIQq3xBkIOmyUpmqZPbXzVJQCDpoS04zMZDlGPRc9+ZT3AzOr G9lw==
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=MpTg1mYVQ+sH+rtZLl/VRpy0ZpIjxhMwzm1GZ3c+Kk8=; b=Xm939Umy8m9iBupsA2YuJAYuETJd+Kdk7Ro+caJS6AV694Hcc86B/5sP0qhEhYlxVR d56JgUqIkGe8BDKKTowaetgBwcDk8taX4IHQcAT5ecbBpUPghCZEEBYTkq0qtSJIqQbt CYl6FBjnW0clvhvhSiPYNHpZXvcL8cd5oNriXRmFT6lejRhVvwcRRQm4Lf5TKDdCdGbo XRp/awwlxwY16PNWGwt6kRCvcvoNPOq4QpCPdaSd+XMvnfkqegJzS3HNyaVix+V3JXLg yMy9W/yx3jutAvXRLocuiQBShJ6HG7NmXWekIWdpgOzs4lX50hFqI6ls+LIZ7lpiEyLa S6ag==
X-Gm-Message-State: AA+aEWY2pV2dccnPX+XYhunefFKjDzHZT6xuvNJ3Z4rAcN55cetmaLFD w4LDHSJtsAVFrW0jojtxFm3ChYk6DfhrNUzFYAr5
X-Google-Smtp-Source: AFSGD/XZTFlno3iC9cSlouQSj47RqYO7J0UxRlvGJWG6drHnPCbI3OxvFybNh10m1inshaTu7nwVxXxx+8natcfV4os=
X-Received: by 2002:aca:60c1:: with SMTP id u184mr3422732oib.45.1543421009218;  Wed, 28 Nov 2018 08:03:29 -0800 (PST)
MIME-Version: 1.0
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>
In-Reply-To: <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>
From: Filip Skokan 
Date: Wed, 28 Nov 2018 17:03:17 +0100
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000fe5306057bbbb4b4"
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 28 Nov 2018 16:03:38 -0000

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

Hi George,

#2 doesn't seem confidential, it's still a secret shared amongst
installations and anyone reverse engineering the apk, extracting the
secret, can form the client_secret_jwt client_assertion with it just fine.

Best,
Filip

On Wed, Nov 28, 2018 at 4:48 PM George Fletcher  wrote:

> In addition, a few additional patterns are enabled...
>
> 1. The native app can generate a public/private key pair and then use
> private_secret_jwt as the client credential validation method via the
> client credentials flow (defined in OpenID Connect).
>
> 2. Maybe more simply, if the native app is issued a shared secret, the ap=
p
> can use client_secret_jwt method for client authentication which ensures
> the shared secret never leaves the device. (Again defined in the OpenID
> Connect spec).
>
> 3. Once the native app instance has credentials, they can be used for
> additional securing of app API transactions in addition to just the
> OAuth2/OpenID Connect flows.
>
> Thanks,
> George
>
> On 11/27/18 3:28 PM, William Denniss wrote:
>
> If the secret is dynamically provisioned then you have a confidential
> client. Anyone reverse engineering their own installation of the native a=
pp
> would only extract their own client's credentials, as opposed to the shar=
ed
> secret of all installations. Having a confidential client means that
> requests to the token endpoint (code, refresh) are client authenticated, =
so
> PKCE wouldn't be needed.
>
> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <
> Christian.Mainka=3D40rub.de@dmarc.ietf..org
> > wrote:
>
>> Hi,
>>
>> we just stumbled upon this [1] statement:
>> "Except when using a mechanism like Dynamic Client Registration
>>    [RFC7591] to provision per-instance secrets, native apps are
>>    classified as public clients ..."
>>
>> What does this mean for us? Native App + Dynamic Client Registration =3D
>> Confidential Client?
>> Which threats are covered if Dynamic Client Registration is used on
>> Native Apps?
>>
>> Best Regards,
>> Vladi/Christian
>>
>> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>>
>> --
>> Dr.-Ing. Christian Mainka
>> Horst G=C3=B6rtz Institute for IT-Security
>> Chair for Network and Data Security
>> Ruhr-University Bochum, Germany
>>
>> Universit=C3=A4tsstr. 150, ID 2/463
>> D-44801 Bochum, Germany
>>
>> Telefon: +49 (0) 234 / 32-26796
>> Fax: +49 (0) 234 / 32-14347
>> http://nds.rub.de/chair/people/cmainka/
>> @CheariX
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    Hi George,

    #2 doesn't se=
em confidential, it's still a secret shared amongst installations and a=
nyone reverse engineering the apk, extracting the secret, can form the clie=
nt_secret_jwt client_assertion with it just fine.

    Best,
    Filip

    On Wed, Nov 28, 2018 at 4:48 PM George Fletch=
er <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
    
 =20
   =20
 =20
  
    
    In addition, a few
      additional patterns are enabled...
    
      
    
      1. The native app can generate a public/private key pair and then
      use private_secret_jwt as the client credential validation method
      via the client credentials flow (defined in OpenID Connect).
    
      
    
      2. Maybe more simply, if the native app is issued a shared secret,
      the app can use client_secret_jwt method for client authentication
      which ensures the shared secret never leaves the device. (Again
      defined in the OpenID Connect spec).
    
      
    
      3. Once the native app instance has credentials, they can be used
      for additional securing of app API transactions in addition to
      just the OAuth2/OpenID Connect flows.
    
      
    
      Thanks,
    
      George
    
      
    
        
    
    On 11/27/18 3:28 PM, William Denniss
      wrote:
    
    
    
    
    
     =20
      
    If the secret is dynamically provisioned then you
        have a confidential client.=C2=A0Anyone reverse engineering their o=
wn
        installation of the native app would only extract their own
        client's credentials, as opposed to the shared secret of all
        installations. Having a confidential client means that requests
        to the token endpoint (code, refresh) are client authenticated,
        so PKCE wouldn't be needed.
    
      

    
        
    On Tue, Nov 27, 2018 at 1:44 AM,
          Christian Mainka <Christian.Mainka=3D40=
rub.de@dmarc.ietf..org>
          wrote:
    
          
    Hi,
    
            
    
            we just stumbled upon this [1] statement:
    
            "Except when using a mechanism like Dynamic Client
            Registration
    
            =C2=A0=C2=A0 [RFC7591] to provision per-instance secrets, nativ=
e apps
            are
    
            =C2=A0=C2=A0 classified as public clients ..."
    
            
    
            What does this mean for us? Native App + Dynamic Client
            Registration =3D
    
            Confidential Client?
    
            Which threats are covered if Dynamic Client Registration is
            used on
    
            Native Apps?
    
            
    
            Best Regards,
    
            Vladi/Christian
    
            
    
            [1]: https://tools.ietf.org/html/rfc8252#=
section-8.4
    
            
    
            -- 
    
            Dr.-Ing. Christian Mainka
    
            Horst G=C3=B6rtz Institute for IT-Security 
    
            Chair for Network and Data Security 
    
            Ruhr-University Bochum, Germany
    
            
    
            Universit=C3=A4tsstr. 150, ID 2/463
    
            D-44801 Bochum, Germany
    
            
    
            Telefon: +49 (0) 234 / 32-26796
    
            Fax: +49 (0) 234 / 32-14347
    
            http://nds.rub.de/chair/people/cmainka/
    
            @CheariX
    
            
    
            
    
            _______________________________________________
    
            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
    

    

--000000000000fe5306057bbbb4b4--


From nobody Wed Nov 28 09:03:30 2018
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 441A9131011 for ; Wed, 28 Nov 2018 09:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 GZNvAYaW8cHV for ; Wed, 28 Nov 2018 09:03:19 -0800 (PST)
Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.123]) (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 F20B0131002 for ; Wed, 28 Nov 2018 09:03:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1543424597; bh=ADEepILCyDqykjl4zq8P1BrnKlHj9z35js8R4jZSqJY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=OJDs/DX2DGG/6HNL4CeOeeloYYc6YM7yg/OZtYUKDiY7pyxS2VnRKZdstV0Jvsy6V+/jnFvBGBNGwL42sXAY9ZUz+156oCUyoJMJHvc3PZQ4lSaEbre/7K2AHumuPFt1pvM3yPK5n3cM+DlYyo9y5ahWC2P7SUT5t1Efk/+et2BVW5sgjMUl6jlfHmgwIaoDm8xi1F6kSo9ZFcGye4iDOmP56MhUE+f5+KwBF0x1DQVcA8jvJI6OP6tEBuTdrXXonKHsMHqe4H5IlMXxaom1OIc5weyHpJ5kpynEWlbafAbF5yDhroo/MaGl6Qj3Ljh8YzZ6NfEcYQsDviHU5HzNpw==
X-YMail-OSG: 5Qf7f8IVM1kPtayIfaLMO1zEpQTrDFfVfojXy.sNCVvh76pR0IdaNydUiYyfoPQ f80.XWe6xEMVvTybjt_S5XcBgO8phBX0yQqbs9BqsF3XKBaSByo7IZ22sl52juUVkWmVW.Me3_su B3SsBzx4jVdVskZx0ItX51jQclBYTTaNGKwiAriXwuACXZKznLZAzBV_Z1u3Aj1qoBsfBo6F12qF Rj1ijCs4wmSfFxEQLuTHbHVInLNwtKFvRbQp9sDUlAy26TUy8xI_lO8P9m5J3owRmUGrYAOaFbOe TvavzZenAMXI8eKqMCpZk98oMwB433ANynY1zHpd1JM7m6xEZ5MYI7PjAht4Al476fVsOlHZ_jL0 7iw6CRvvsf1AGj4NzFyB7Am6kybhHrluDqqR5tLzGj4D8zuQjDASrhJm8KhcMjLZaRvwasaMVlzv vfnyYFvqD_51IZoNOSmC3QtUnoQ3CcLzz.SUMDxZdN0ZHnTSTUk6ejbZxVk6Ba1qsQeyX5VrgaN0 rtE9ldzQ7hPlKFGxf1EYny63lRunwxNPdAlwiQI9rF0U3Z4Q6acS_33jxtJc5Sn5BZ5URZrZr5hV J4xeDlET7LkeqQjVObY785l6w96ngtb5NY6cBbeIoGSp.eYOp2_OOVD4n8tdGp11d9NouKXZpOOV GCfCUymFTWrMA2iANwMylkRlDDZlj28Np8HLebF54dqFSZi59hBAGHD6TQFhSIAME7.ld8kfBOqW eSrCQVuovlmsdgtWVVwF4UrATFroszrgN_jTQ_ywwdTWkE7COaefZmUjm3CzaKjET8_4H7WvUzoo RJX9r1oAymByavgfEU1LlAzzUEiEjXe9qd_nH21DYRo.7hLKM2jP2.l2CAYjZncTQzaeihL0dEQw XAV0DRGBwY4LZeGVUXfJYGhqXE.5ZAijjyB3Io1bAP4U_BM30EqXkpOH821Adsdx.Mct2B3PYIvf Wzffl5m52cCYNvoYoM9Mo0qQemjRxMfFDmCmpVDWnCm_90tl2PLergYRi8YdS2YQ5IKGedtFwym2 CusXgDAibMMx6MjN.6DpPDy8fd9PU60rgjSCw4D9PLGiD
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Nov 2018 17:03:17 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9e730eb06a2c1b0fbd9032bf043024ea;  Wed, 28 Nov 2018 17:03:14 +0000 (UTC)
To: Filip Skokan , oauth 
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Wed, 28 Nov 2018 12:03:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------41B3863FF760F6CF903532F2"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 28 Nov 2018 17:03:29 -0000

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

It's "confidential" in that the shared secret is unique to that app 
instance registration (as Dennis described in his response). If an 
attacker gets my phone and compromises the data stored on my device, 
they only get the secret for my device. This is no different than a 
server side client having their client secret compromised through an 
attack (and in some ways is better because it's instance specific).

The main point I was trying to make, is that the 'client_secret_jwt' 
method allows the client to never send the shared secret across the wire 
as is created in the default OAuth2 HTTP Basic Authentication method.

Thanks,
George

On 11/28/18 11:03 AM, Filip Skokan wrote:
> Hi George,
>
> #2 doesn't seem confidential, it's still a secret shared amongst 
> installations and anyone reverse engineering the apk, extracting the 
> secret, can form the client_secret_jwt client_assertion with it just fine.
>
> Best,
> Filip
>
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher 
> > 
> wrote:
>
>     In addition, a few additional patterns are enabled...
>
>     1. The native app can generate a public/private key pair and then
>     use private_secret_jwt as the client credential validation method
>     via the client credentials flow (defined in OpenID Connect).
>
>     2. Maybe more simply, if the native app is issued a shared secret,
>     the app can use client_secret_jwt method for client authentication
>     which ensures the shared secret never leaves the device. (Again
>     defined in the OpenID Connect spec).
>
>     3. Once the native app instance has credentials, they can be used
>     for additional securing of app API transactions in addition to
>     just the OAuth2/OpenID Connect flows.
>
>     Thanks,
>     George
>
>     On 11/27/18 3:28 PM, William Denniss wrote:
>>     If the secret is dynamically provisioned then you have a
>>     confidential client. Anyone reverse engineering their own
>>     installation of the native app would only extract their own
>>     client's credentials, as opposed to the shared secret of all
>>     installations. Having a confidential client means that requests
>>     to the token endpoint (code, refresh) are client authenticated,
>>     so PKCE wouldn't be needed.
>>
>>     On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka
>>     >     > wrote:
>>
>>         Hi,
>>
>>         we just stumbled upon this [1] statement:
>>         "Except when using a mechanism like Dynamic Client Registration
>>            [RFC7591] to provision per-instance secrets, native apps are
>>            classified as public clients ..."
>>
>>         What does this mean for us? Native App + Dynamic Client
>>         Registration =
>>         Confidential Client?
>>         Which threats are covered if Dynamic Client Registration is
>>         used on
>>         Native Apps?
>>
>>         Best Regards,
>>         Vladi/Christian
>>
>>         [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>>
>>         -- 
>>         Dr.-Ing. Christian Mainka
>>         Horst Görtz Institute for IT-Security
>>         Chair for Network and Data Security
>>         Ruhr-University Bochum, Germany
>>
>>         Universitätsstr. 150, ID 2/463
>>         D-44801 Bochum, Germany
>>
>>         Telefon: +49 (0) 234 / 32-26796
>>         Fax: +49 (0) 234 / 32-14347
>>         http://nds.rub.de/chair/people/cmainka/
>>         @CheariX
>>
>>
>>         _______________________________________________
>>         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


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


  
    
  
  
    It's "confidential" in that the shared secret is unique to that app
    instance registration (as Dennis described in his response). If an
    attacker gets my phone and compromises the data stored on my device,
    they only get the secret for my device. This is no different than a
    server side client having their client secret compromised through an
    attack (and in some ways is better because it's instance specific).
    
    
    
    The main point I was trying to make, is that the 'client_secret_jwt'
    method allows the client to never send the shared secret across the
    wire as is created in the default OAuth2 HTTP Basic Authentication
    method.
    
    
    
    Thanks,
    
    George
    
    
    
    
    On 11/28/18 11:03 AM, Filip Skokan
      wrote:
    
    
    
    
    
      
      
    
        
    Hi George,
    
        

    
        
    
        
    #2 doesn't seem confidential, it's still a secret shared
          amongst installations and anyone reverse engineering the apk,
          extracting the secret, can form the client_secret_jwt
          client_assertion with it just fine.
    
        
    
        
    
          
    Best,
    
        
    
        
    Filip
    
        
    
        
    
          
    On Wed, Nov 28, 2018 at 4:48 PM George Fletcher
            <gffletch=40aol.com@dmarc.ietf.org>
            wrote:
    
          
    
          
    
            
     In addition, a few
                additional patterns are enabled...
    
                
    
                1. The native app can generate a public/private key pair
                and then use private_secret_jwt as the client credential
                validation method via the client credentials flow
                (defined in OpenID Connect).
    
                
    
                2. Maybe more simply, if the native app is issued a
                shared secret, the app can use client_secret_jwt method
                for client authentication which ensures the shared
                secret never leaves the device. (Again defined in the
                OpenID Connect spec).
    
                
    
                3. Once the native app instance has credentials, they
                can be used for additional securing of app API
                transactions in addition to just the OAuth2/OpenID
                Connect flows.
    
                
    
                Thanks,
    
                George
    
                
    
                  
              
    On
                11/27/18 3:28 PM, William Denniss wrote:
    
              
    
              
    
                
    If the secret is dynamically provisioned
                  then you have a confidential client. Anyone reverse
                  engineering their own installation of the native app
                  would only extract their own client's credentials, as
                  opposed to the shared secret of all installations.
                  Having a confidential client means that requests to
                  the token endpoint (code, refresh) are client
                  authenticated, so PKCE wouldn't be needed.
    
                

    
                  
    On Tue, Nov 27, 2018 at 1:44
                    AM, Christian Mainka <Christian.Mainka=40rub.de@dmarc.ietf..org>
                    wrote:
    
                    
    Hi,
    
                      
    
                      we just stumbled upon this [1] statement:
    
                      "Except when using a mechanism like Dynamic Client
                      Registration
    
                         [RFC7591] to provision per-instance secrets,
                      native apps are
    
                         classified as public clients ..."
    
                      
    
                      What does this mean for us? Native App + Dynamic
                      Client Registration =
    
                      Confidential Client?
    
                      Which threats are covered if Dynamic Client
                      Registration is used on
    
                      Native Apps?
    
                      
    
                      Best Regards,
    
                      Vladi/Christian
    
                      
    
                      [1]: https://tools.ietf.org/html/rfc8252#section-8.4
    
                      
    
                      -- 
    
                      Dr.-Ing. Christian Mainka
    
                      Horst Görtz Institute for IT-Security 
    
                      Chair for Network and Data Security 
    
                      Ruhr-University Bochum, Germany
    
                      
    
                      Universitätsstr. 150, ID 2/463
    
                      D-44801 Bochum, Germany
    
                      
    
                      Telefon: +49 (0) 234 / 32-26796
    
                      Fax: +49 (0) 234 / 32-14347
    
                      http://nds.rub.de/chair/people/cmainka/
    
                      @CheariX
    
                      
    
                      
    
                      _______________________________________________
    
                      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

    
    
    
    
    
  


--------------41B3863FF760F6CF903532F2--


From nobody Wed Nov 28 09:10:10 2018
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 9FD6D130E8B for ; Wed, 28 Nov 2018 09:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tO6PF-e7co7o for ; Wed, 28 Nov 2018 09:10:06 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C95E130E88 for ; Wed, 28 Nov 2018 09:10:06 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id u18so23197793oie.10 for ; Wed, 28 Nov 2018 09:10: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=sZwxRTgWC/iHAgZ74/l7G8JZKExBjx/bhaif7pgxSBM=; b=o8pMXOg9CB363FOGKweMNZ9PemC4PuV7fqn5QPSYkGf9Yts4rcqd/0n0bKE5+fG4ho WrXVouGHezr2GU51OUhTXeOnyZXXMKsktGDrrWNFTuLNtJtqvZvXC6U4lf5SmqCdenTY PiPyZIlPZ8whUTCPe63304vrCe06aG5CSAR+UN5GUOFgCPomQ1VW6QL98lmzlXtmy4Vs XNg11E2iROpsfRBx4z9EtA72qIPZB36DZZd0ztak/v3QeFufjmiDrIq4lSf9e/3M3PKD VxvUgTvu8/H3TBlaBQeNp4S89jKuf3TUM0GcBeerBKlrkg5KyGi0drQwc4sbnVmdMlIm /mNQ==
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=sZwxRTgWC/iHAgZ74/l7G8JZKExBjx/bhaif7pgxSBM=; b=a7OhShQUmmIbVMY+RfqM4bKkQnjnbnJntzdHXJlw4e54YKgFc+bU2ZOpXgO0CBS6Yu 5RodTCaheLGJ2+98KhBYW5sN0eHwjZdMfhDnfoKiLBF3b69VS8sov/RM6g+KVuF1tuwQ HreF+9ehI4c0W0jxBk2wX4yO6GbD45T+Rnj5mlgme8BiBkGRERe4kBsAupQZLnQAe2kO ayqT4COXlHeztp3iXNLqLIebPmTLD4adtvdBsmL+4pQyl4SPsBmg4nEzCT9qaQuP5J08 BzR9b5Jfex3yK8r9mhE7IfqHoU++WvZiMJNZ+cfFBiyspVJERHFkTYrp4K4zBgMq681X M//A==
X-Gm-Message-State: AA+aEWZUggXoBuyjgqnFPaDfEtc/MpvAZ7i6MQrSdlCbIatnJd6IW0i9 ZSl1d5bQP7EYzdz7Fa9qbYkiwLZ0i7uBs8KwDilShqg=
X-Google-Smtp-Source: AFSGD/XcA80u0It6uZFyLGtSIROWD/Tbp1SDIPQ/ua4imtPhPod1DBhRSADwHzGtgGh3Y8/iplpkqqBbXGEMD4zzYRA=
X-Received: by 2002:aca:60c1:: with SMTP id u184mr3575740oib.45.1543425005539;  Wed, 28 Nov 2018 09:10:05 -0800 (PST)
MIME-Version: 1.0
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>  
In-Reply-To: 
From: Filip Skokan 
Date: Wed, 28 Nov 2018 18:09:54 +0100
Message-ID: 
To: George Fletcher 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000315762057bbca30d"
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 28 Nov 2018 17:10:08 -0000

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

Apologies, I missed the *issued* in "issued a shared secret", just reading
"shared secret" alone is the exact opposite of a per-instance secret. The
rest is clear and as you say it brings the benefit of the secret never
being sent over the wire (except during the initial registration via TLS).

Best,
*Filip*


On Wed, Nov 28, 2018 at 6:03 PM George Fletcher  wrote:

> It's "confidential" in that the shared secret is unique to that app
> instance registration (as Dennis described in his response). If an attack=
er
> gets my phone and compromises the data stored on my device, they only get
> the secret for my device. This is no different than a server side client
> having their client secret compromised through an attack (and in some way=
s
> is better because it's instance specific).
>
> The main point I was trying to make, is that the 'client_secret_jwt'
> method allows the client to never send the shared secret across the wire =
as
> is created in the default OAuth2 HTTP Basic Authentication method.
>
> Thanks,
> George
>
> On 11/28/18 11:03 AM, Filip Skokan wrote:
>
> Hi George,
>
> #2 doesn't seem confidential, it's still a secret shared amongst
> installations and anyone reverse engineering the apk, extracting the
> secret, can form the client_secret_jwt client_assertion with it just fine=
.
>
> Best,
> Filip
>
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher  40aol.com@dmarc.ietf.org> wrote:
>
>> In addition, a few additional patterns are enabled...
>>
>> 1. The native app can generate a public/private key pair and then use
>> private_secret_jwt as the client credential validation method via the
>> client credentials flow (defined in OpenID Connect).
>>
>> 2. Maybe more simply, if the native app is issued a shared secret, the
>> app can use client_secret_jwt method for client authentication which
>> ensures the shared secret never leaves the device. (Again defined in the
>> OpenID Connect spec).
>>
>> 3. Once the native app instance has credentials, they can be used for
>> additional securing of app API transactions in addition to just the
>> OAuth2/OpenID Connect flows.
>>
>> Thanks,
>> George
>>
>> On 11/27/18 3:28 PM, William Denniss wrote:
>>
>> If the secret is dynamically provisioned then you have a confidential
>> client. Anyone reverse engineering their own installation of the native =
app
>> would only extract their own client's credentials, as opposed to the sha=
red
>> secret of all installations. Having a confidential client means that
>> requests to the token endpoint (code, refresh) are client authenticated,=
 so
>> PKCE wouldn't be needed.
>>
>> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <
>> Christian.Mainka=3D40rub.de@dmarc.ietf..org
>> > wrote:
>>
>>> Hi,
>>>
>>> we just stumbled upon this [1] statement:
>>> "Except when using a mechanism like Dynamic Client Registration
>>>    [RFC7591] to provision per-instance secrets, native apps are
>>>    classified as public clients ..."
>>>
>>> What does this mean for us? Native App + Dynamic Client Registration =
=3D
>>> Confidential Client?
>>> Which threats are covered if Dynamic Client Registration is used on
>>> Native Apps?
>>>
>>> Best Regards,
>>> Vladi/Christian
>>>
>>> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>>>
>>> --
>>> Dr.-Ing. Christian Mainka
>>> Horst G=C3=B6rtz Institute for IT-Security
>>> Chair for Network and Data Security
>>> Ruhr-University Bochum, Germany
>>>
>>> Universit=C3=A4tsstr. 150, ID 2/463
>>> D-44801 Bochum, Germany
>>>
>>> Telefon: +49 (0) 234 / 32-26796
>>> Fax: +49 (0) 234 / 32-14347
>>> http://nds.rub.de/chair/people/cmainka/
>>> @CheariX
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>>
>> _______________________________________________
>> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>

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


    Apologies, I missed th=
e issued in "issued a shared secret", just reading "shar=
ed secret" alone is the exact opposite of a per-instance secret.=C2=A0=
The rest is clear and as you say it brings the benefit of the secret ne=
ver being sent over the wire (except during the initial registration via TL=
S).

    Best,
    Filip


    On=
 Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffletch@aol.com> wrote:
    
 =20
   =20
 =20
  
    
    It's "confidential" in that the shared secret is unique t=
o that app
    instance registration (as Dennis described in his response). If an
    attacker gets my phone and compromises the data stored on my device,
    they only get the secret for my device. This is no different than a
    server side client having their client secret compromised through an
    attack (and in some ways is better because it's instance specific).=

    
    
    
    The main point I was trying to make, is that the 'client_secret_jwt=
'
    method allows the client to never send the shared secret across the
    wire as is created in the default OAuth2 HTTP Basic Authentication
    method.
    
    
    
    Thanks,
    
    George
    
    
    
    
    On 11/28/18 11:03 A=
M, Filip Skokan
      wrote:
    
    
    
    
    
     =20
      
    
        
    Hi George,
    
        

    
        
    
        
    #2 doesn't seem confidential, it's still a secret shar=
ed
          amongst installations and anyone reverse engineering the apk,
          extracting the secret, can form the client_secret_jwt
          client_assertion with it just fine.
    
        
    
        
    
          
    Best,
    
        
    
        
    Filip
    
        
    
        
    
          
    On Wed, Nov 28, 2018 at 4:48 PM George Fletcher
            <gffletch=3D40aol.com@dmarc.ietf.org>
            wrote:
    
          
    
          
    
            
     In addition, a few
                additional patterns are enabled...
    
                
    
                1. The native app can generate a public/private key pair
                and then use private_secret_jwt as the client credential
                validation method via the client credentials flow
                (defined in OpenID Connect).
    
                
    
                2. Maybe more simply, if the native app is issued a
                shared secret, the app can use client_secret_jwt method
                for client authentication which ensures the shared
                secret never leaves the device. (Again defined in the
                OpenID Connect spec).
    
                
    
                3. Once the native app instance has credentials, they
                can be used for additional securing of app API
                transactions in addition to just the OAuth2/OpenID
                Connect flows.
    
                
    
                Thanks,
    
                George
    
                
    
                  
              
    On
                11/27/18 3:28 PM, William Denniss wrote:
    
              
    
              
    
                
    If the secret is dynamically provisioned
                  then you have a confidential client.=C2=A0Anyone reverse
                  engineering their own installation of the native app
                  would only extract their own client's credentials, as
                  opposed to the shared secret of all installations.
                  Having a confidential client means that requests to
                  the token endpoint (code, refresh) are client
                  authenticated, so PKCE wouldn't be needed.
    
                

    
                  
    On Tue, Nov 27, 2018 at 1:44
                    AM, Christian Mainka <Christi=
an.Mainka=3D40rub.de@dmarc.ietf..org>
                    wrote:
    
                    
    Hi,
    
                      
    
                      we just stumbled upon this [1] statement:
    
                      "Except when using a mechanism like Dynamic Clie=
nt
                      Registration
    
                      =C2=A0=C2=A0 [RFC7591] to provision per-instance secr=
ets,
                      native apps are
    
                      =C2=A0=C2=A0 classified as public clients ..."
                      
    
                      What does this mean for us? Native App + Dynamic
                      Client Registration =3D
    
                      Confidential Client?
    
                      Which threats are covered if Dynamic Client
                      Registration is used on
    
                      Native Apps?
    
                      
    
                      Best Regards,
    
                      Vladi/Christian
    
                      
    
                      [1]: https://tools.ietf.org/htm=
l/rfc8252#section-8.4
    
                      
    
                      -- 
    
                      Dr.-Ing. Christian Mainka
    
                      Horst G=C3=B6rtz Institute for IT-Security 
    
                      Chair for Network and Data Security 
    
                      Ruhr-University Bochum, Germany
    
                      
    
                      Universit=C3=A4tsstr. 150, ID 2/463
    
                      D-44801 Bochum, Germany
    
                      
    
                      Telefon: +49 (0) 234 / 32-26796
    
                      Fax: +49 (0) 234 / 32-14347
    
                      http://nds.rub.de/chair/people/cmainka/=

    
                      @CheariX
    
                      
    
                      
    
                      _______________________________________________
    
                      OAuth mailing list
    
                      O=
Auth@ietf.org
    
                      https://www.ietf.org/mailman/listin=
fo/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/ma=
ilman/listinfo/oauth

    
    
    
    
    
  
    


    

--000000000000315762057bbca30d--


From nobody Wed Nov 28 09:19:23 2018
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 8E077130F8A for ; Wed, 28 Nov 2018 09:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 nenTBuq-e2FX for ; Wed, 28 Nov 2018 09:19:18 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (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 23070130E8B for ; Wed, 28 Nov 2018 09:19:18 -0800 (PST)
Received: from [80.187.100.5] (helo=[172.20.10.2]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gS3UZ-0006ut-EQ; Wed, 28 Nov 2018 18:19:15 +0100
From: Torsten Lodderstedt 
Message-Id: <1198DA32-4E63-4966-89CA-398478226209@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_5648CF9A-2620-4172-A2E2-1ABD324F748A"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 18:19:14 +0100
In-Reply-To: 
To: oauth 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com> <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net> 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 28 Nov 2018 17:19:22 -0000

--Apple-Mail=_5648CF9A-2620-4172-A2E2-1ABD324F748A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Am 28.11.2018 um 16:53 schrieb George Fletcher :
>=20
> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>> Hi George,
>>=20
>>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>>=20
>>> Thanks for the additional section on refresh_tokens. Some additional =
recommendations...
>>>=20
>>> 1. By default refresh_tokens are bound to the user's authenticated =
session. When the authenticated session expires or is terminated =
(whether by the user or for some other reason) the refresh_tokenis =
implicitly revoked.
>> SHOULD or MUST? I would suggest to go with a SHOULD.
> I would say that the AS SHOULD bind the refresh_token to the user's =
authentication. However, I'd lean more to MUST for session bound =
refresh_tokens being revoked when the session is terminated.

wfm=20

Anyone on the list wanting to object?=20

>>=20
>>> 2. Clients that need to obtain a refresh_token that exists beyond =
the lifetime of the user's authentication session MUST indicate this =
need by requesting the "offline_access" scope =
(https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). =
This provides for a user consent event making it clear to the user that =
the client is requesting access even when the user's authentication =
session expires. This then becomes the default for mobile apps as the =
refresh_token should not be tied to the web session used to authorize =
the app.
>> Sounds reasonable, just the scope =E2=80=9Eoffline_access=E2=80=9C is =
OIDC specific. Is it time to move it down the stack to OAuth?
> It may be if we want more consistency in the implementation of =
refresh_token policy across authorization servers.

Who has an opinion on that topic?

>>=20
>>> 3. The AS MAY consider putting an upper bound on the lifetime of a =
refresh_token (e.g. 1 year). There is no real need to issue a =
refresh_token that is good indefinitely.
>> I thought I had covered that in the last section. It=E2=80=99s now:
>>=20
>> Refresh tokens SHOULD expire if the client has been inactive for some =
time,
>>     	i.e. the refresh token has not been used to obtain fresh access =
tokens for
>>     	some time. The expiration time is at the discretion of the =
authorization server.
>>     	It might be a global value or determined based on the client =
policy or
>>     	the grant associated with the refresh token (and its =
sensitivity).
> This is slightly different but sufficient so +1 for the text :)

Ok, thanks.=20

>>=20
>> Proposals are welcome!
>>=20
>> kind regards,
>> Torsten.
>>=20
>>=20
>>> This is in addition to the other best practices described.
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>>>> Hi all,
>>>>=20
>>>> the new revision contains the following changes:
>>>>=20
>>>> * added section on refresh tokens
>>>> * additional justifications for recommendation for code
>>>> * refactored 2.1 in order to distinguish CSRF, authz response =
replay and mix-up (based on feedback by Joseph Heenan)
>>>> * added requirement to authenticate clients during code exchange =
(PKCE or client credential) to 2.1.1.
>>>> * changed occurrences of SHALL to MUST
>>>>=20
>>>> As always: looking forward for your feedback.
>>>>=20
>>>> kind regards,
>>>> Torsten.
>>>>=20
>>>>=20
>>>>> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org
>>>>> :
>>>>>=20
>>>>>=20
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>>>> This draft is a work item of the Web Authorization Protocol WG of =
the IETF.
>>>>>=20
>>>>>        Title           : OAuth 2.0 Security Best Current Practice
>>>>>        Authors         : Torsten Lodderstedt
>>>>>                          John Bradley
>>>>>                          Andrey Labunets
>>>>>                          Daniel Fett
>>>>> 	Filename        : draft-ietf-oauth-security-topics-10.txt
>>>>> 	Pages           : 38
>>>>> 	Date            : 2018-11-20
>>>>>=20
>>>>> Abstract:
>>>>>   This document describes best current security practice for OAuth =
2.0.
>>>>>   It updates and extends the OAuth 2.0 Security Threat Model to
>>>>>   incorporate practical experiences gathered since OAuth 2.0 was
>>>>>   published and covers new threats relevant due to the broader
>>>>>   application of OAuth 2.0.
>>>>>=20
>>>>>=20
>>>>> The IETF datatracker status page for this draft is:
>>>>>=20
>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>>=20
>>>>>=20
>>>>> There are also htmlized versions available at:
>>>>>=20
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>>>>> =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>>>>>=20
>>>>>=20
>>>>> A diff from the previous version is available at:
>>>>>=20
>>>>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
>>>>>=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
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>=20
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_5648CF9A-2620-4172-A2E2-1ABD324F748A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjgxNzE5MTRaMC8GCSqGSIb3DQEJBDEiBCAh
xyPN10p9S0MbPNKYDZ7UtzXOBhEuuklipdgTXH+FzTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAE33WFCSo0GG6HfuejOz6WtCp
vDG139Hh36B3rLkwd1lhEy4YNLaiPAoFjGG4l6EFXJo8nfOURKyD056VrYCPQbe58IeKNsgo8bpI
NhYC7sySarypWDaxbBFXTYa4svsI6bfCTUTkaHKl9tUzcMZ88KQBp2P6zyKg3RaPlpGNcjO8MIDO
HwodwLPXa1pASQWtULDqlH59lgaeDuvWxoMd8KJZXZKvJUQTqOzJd3qfPGJy5VWXrdVSr4qBenmw
eLirhbRIPtLjPer7kfQ/t6UcZV7WS2j3it726ftgJ6V7bvJMxuA8Xg9VXcluLdck3jLWhgEkQi/l
Ox+PLtEuwsfbZgAAAAAAAA==
--Apple-Mail=_5648CF9A-2620-4172-A2E2-1ABD324F748A--


From nobody Wed Nov 28 09:37:02 2018
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 A0BAC128D68 for ; Wed, 28 Nov 2018 09:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.759
X-Spam-Level: 
X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T6jOA2tYPbG for ; Wed, 28 Nov 2018 09:36:56 -0800 (PST)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 44A991277BB for ; Wed, 28 Nov 2018 09:36:56 -0800 (PST)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wASHYEnb077557; Wed, 28 Nov 2018 17:36:55 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=5lYrapEsW1ytQyl4B+HLT2moFMf8Y/BwJMerNX6Pnik=; b=BplgyiMnXToAJlptWC2fd1vJBUhKerScSmswgdncpci/Dp0yZF5xn+RKqsDx+sN7/QSE YrQ8lRczZ4+eAUHxCR9WXWccJQhgrdpGLW9XXjdW2hk+VR/Lp1KhQlz44ajt6MPAL6so my7bOO6ZGfYQhCc5k9BO01gVZsC12XvlCtTpsIQPCjq3xM+sY0ZDCiP3Nf0PgRWpg+gB ZVVHB9/skp5EKS2qctjqMKVc22ZmQ625vsCDHqTQYRWTs2d00ISiGCMk9b41oOp7D1dM 8jaxoM38MPjamZBX5zLD7srgmrdB1xsKRUfkWdQhQ9aqjVNDc9KG4asLwT6u1G5/pQuX Xw== 
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2nxxkqknv1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Nov 2018 17:36:54 +0000
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wASHan9C027832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Nov 2018 17:36:49 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wASHanWZ002692; Wed, 28 Nov 2018 17:36:49 GMT
Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Nov 2018 09:36:48 -0800
From: Phil Hunt 
Message-Id: <91ED75EE-C9F0-49E8-AAF8-149560102A75@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D61600FF-BF03-44EE-A980-893A4A6EEEA5"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 09:36:45 -0800
In-Reply-To: <1198DA32-4E63-4966-89CA-398478226209@lodderstedt.net>
Cc: oauth 
To: Torsten Lodderstedt 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com> <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net>  <1198DA32-4E63-4966-89CA-398478226209@lodderstedt.net>
X-Mailer: Apple Mail (2.3445.101.1)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9091 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811280153
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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, 28 Nov 2018 17:36:59 -0000

--Apple-Mail=_D61600FF-BF03-44EE-A980-893A4A6EEEA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Apologies, I may be speaking out of turn by not fully understanding the =
use cases that this thread may be focused on. I=E2=80=99m interpreting =
the conclusions you are proposing as general recommendations rather than =
addressing a specific case.

IMO the biggest general value of refresh is a periodic =
proof-of-possession demonstration by the client. It also serves as a =
non-user-present recovery for when access tokens are revoked for =
non-security reasons (e.g. for administrative reasons because token =
claims may change over time).  If a token were revoked due to a detected =
security threat, then one would presume the refresh and the grant are =
also revoked (not sure if this is always true).

Responses inline=E2=80=A6.

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com =
phil.hunt@oracle.com =


> On Nov 28, 2018, at 9:19 AM, Torsten Lodderstedt =
 wrote:
>=20
>=20
>=20
>> Am 28.11.2018 um 16:53 schrieb George Fletcher :
>>=20
>> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>>> Hi George,
>>>=20
>>>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>>>=20
>>>> Thanks for the additional section on refresh_tokens. Some =
additional recommendations...
>>>>=20
>>>> 1. By default refresh_tokens are bound to the user's authenticated =
session. When the authenticated session expires or is terminated =
(whether by the user or for some other reason) the refresh_tokenis =
implicitly revoked.
>>> SHOULD or MUST? I would suggest to go with a SHOULD.
>> I would say that the AS SHOULD bind the refresh_token to the user's =
authentication. However, I'd lean more to MUST for session bound =
refresh_tokens being revoked when the session is terminated.
>=20
> wfm=20
>=20
> Anyone on the list wanting to object?=20

In some cases, maybe due to the nature of the client (e.g. is it a =
native app) you could make these assumptions. These cases are where the =
client becomes effectively a new type of user-agent representing the =
active user. The agent acts on behalf of direct user interactions.

In other cases, an independent agent is delegated some rights. For =
example, a web service is assigned the rights to survey bank accounts =
and investments to produce consolidated financial reports on a weekly =
basis.

These cases represent true delegated authority.  Another example, =
setting up long-term associations for IoT devices and apps.


>=20
>>>=20
>>>> 2. Clients that need to obtain a refresh_token that exists beyond =
the lifetime of the user's authentication session MUST indicate this =
need by requesting the "offline_access" scope =
(https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). =
This provides for a user consent event making it clear to the user that =
the client is requesting access even when the user's authentication =
session expires. This then becomes the default for mobile apps as the =
refresh_token should not be tied to the web session used to authorize =
the app.
>>> Sounds reasonable, just the scope =E2=80=9Eoffline_access=E2=80=9C =
is OIDC specific. Is it time to move it down the stack to OAuth?
>> It may be if we want more consistency in the implementation of =
refresh_token policy across authorization servers.
>=20
> Who has an opinion on that topic?

I think this intrudes on the scope parameter which is so far, not =
standardized in OAuth2.  This will cause breaking changes for many.  Are =
there any clients that would switch between =E2=80=9Csession=E2=80=9D =
mode and =E2=80=9Coffline=E2=80=9D mode dynamically. I would assert that =
in most cases clients tend to be one or the other.

This would be better handled as part the client=E2=80=99s registration =
metadata.

>=20
>>>=20
>>>> 3. The AS MAY consider putting an upper bound on the lifetime of a =
refresh_token (e.g. 1 year). There is no real need to issue a =
refresh_token that is good indefinitely.
>>> I thought I had covered that in the last section. It=E2=80=99s now:
>>>=20
>>> Refresh tokens SHOULD expire if the client has been inactive for =
some time,
>>>    	i.e. the refresh token has not been used to obtain fresh access =
tokens for
>>>    	some time. The expiration time is at the discretion of the =
authorization server.
>>>    	It might be a global value or determined based on the client =
policy or
>>>    	the grant associated with the refresh token (and its =
sensitivity).
>> This is slightly different but sufficient so +1 for the text :)
>=20
> Ok, thanks.=20
>=20
>>>=20
>>> Proposals are welcome!
>>>=20
>>> kind regards,
>>> Torsten.
>>>=20
>>>=20
>>>> This is in addition to the other best practices described.
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>>>>> Hi all,
>>>>>=20
>>>>> the new revision contains the following changes:
>>>>>=20
>>>>> * added section on refresh tokens
>>>>> * additional justifications for recommendation for code
>>>>> * refactored 2.1 in order to distinguish CSRF, authz response =
replay and mix-up (based on feedback by Joseph Heenan)
>>>>> * added requirement to authenticate clients during code exchange =
(PKCE or client credential) to 2.1.1.
>>>>> * changed occurrences of SHALL to MUST
>>>>>=20
>>>>> As always: looking forward for your feedback.
>>>>>=20
>>>>> kind regards,
>>>>> Torsten.
>>>>>=20
>>>>>=20
>>>>>> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org
>>>>>> :
>>>>>>=20
>>>>>>=20
>>>>>> A New Internet-Draft is available from the on-line =
Internet-Drafts directories.
>>>>>> This draft is a work item of the Web Authorization Protocol WG of =
the IETF.
>>>>>>=20
>>>>>>       Title           : OAuth 2.0 Security Best Current Practice
>>>>>>       Authors         : Torsten Lodderstedt
>>>>>>                         John Bradley
>>>>>>                         Andrey Labunets
>>>>>>                         Daniel Fett
>>>>>> 	Filename        : draft-ietf-oauth-security-topics-10.txt
>>>>>> 	Pages           : 38
>>>>>> 	Date            : 2018-11-20
>>>>>>=20
>>>>>> Abstract:
>>>>>>  This document describes best current security practice for OAuth =
2.0.
>>>>>>  It updates and extends the OAuth 2.0 Security Threat Model to
>>>>>>  incorporate practical experiences gathered since OAuth 2.0 was
>>>>>>  published and covers new threats relevant due to the broader
>>>>>>  application of OAuth 2.0.
>>>>>>=20
>>>>>>=20
>>>>>> The IETF datatracker status page for this draft is:
>>>>>>=20
>>>>>> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>>>=20
>>>>>>=20
>>>>>> There are also htmlized versions available at:
>>>>>>=20
>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>>>>>> =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>>>>>>=20
>>>>>>=20
>>>>>> A diff from the previous version is available at:
>>>>>>=20
>>>>>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
>>>>>>=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
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>=20
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>>=20
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_D61600FF-BF03-44EE-A980-893A4A6EEEA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Apologies, I may be speaking out of turn by not fully =
understanding the use cases that this thread may be focused on. I=E2=80=99=
m interpreting the conclusions you are proposing as general =
recommendations rather than addressing a specific case.
    IMO the biggest general value of =
refresh is a periodic proof-of-possession demonstration by the client. =
It also serves as a non-user-present recovery for when access tokens are =
revoked for non-security reasons (e.g. for administrative reasons =
because token claims may change over time).  If a token were =
revoked due to a detected security threat, then one would presume the =
refresh and the grant are also revoked (not sure if this is always =
true).

    Responses=
 inline=E2=80=A6.

    

    Phil

    Oracle Corporation, Cloud Security and =
Identity Architect
    @independentid
    www.independentid.com
    phil.hunt@oracle.com
    

    


    On Nov 28, 2018, at 9:19 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



    Am =
28.11.2018 um 16:53 schrieb George Fletcher <gffletch@aol.com>:

    On 11/28/18 5:11 AM, Torsten Lodderstedt =
wrote:
    Hi George,

    Am =
20.11.2018 um 23:38 schrieb George Fletcher <gffletch@aol.com>:

    Thanks for the additional section on =
refresh_tokens. Some additional recommendations...

    1. By default refresh_tokens are bound to the user's =
authenticated session. When the authenticated session expires or is =
terminated (whether by the user or for some other reason) the =
refresh_tokenis implicitly revoked.
    SHOULD or =
MUST? I would suggest to go with a SHOULD.
    I =
would say that the AS SHOULD bind the refresh_token to the user's =
authentication. However, I'd lean more to MUST for session bound =
refresh_tokens being revoked when the session is terminated.

    wfm 

    Anyone on the list wanting to object? 

    In some =
cases, maybe due to the nature of the client (e.g. is it a native app) =
you could make these assumptions. These cases are where the client =
becomes effectively a new type of user-agent representing the active =
user. The agent acts on behalf of direct user =
interactions.

    In other cases, an =
independent agent is delegated some rights. For example, a web service =
is assigned the rights to survey bank accounts and investments to =
produce consolidated financial reports on a weekly basis.

    These cases represent true delegated authority. =
 Another example, setting up long-term associations for IoT devices =
and apps.




    2. Clients that need to obtain a refresh_token =
that exists beyond the lifetime of the user's authentication session =
MUST indicate this need by requesting the "offline_access" scope (https://openid.net/specs/openid-connect-core-1_0.html#OfflineAc=
cess). This provides for a user consent event making it clear to the =
user that the client is requesting access even when the user's =
authentication session expires. This then becomes the default for mobile =
apps as the refresh_token should not be tied to the web session used to =
authorize the app.
    Sounds reasonable, just =
the scope =E2=80=9Eoffline_access=E2=80=9C is OIDC specific. Is it time =
to move it down the stack to OAuth?
    It may be =
if we want more consistency in the implementation of refresh_token =
policy across authorization servers.

    Who has an opinion on that topic?

    I think =
this intrudes on the scope parameter which is so far, not standardized =
in OAuth2.  This will cause breaking changes for many.  Are =
there any clients that would switch between =E2=80=9Csession=E2=80=9D =
mode and =E2=80=9Coffline=E2=80=9D mode dynamically. I would assert that =
in most cases clients tend to be one or the other.

    This would be better handled as part the =
client=E2=80=99s registration metadata.



    3. The AS MAY consider putting an upper bound on the lifetime =
of a refresh_token (e.g. 1 year). There is no real need to issue a =
refresh_token that is good indefinitely.
    I =
thought I had covered that in the last section. It=E2=80=99s now:

    Refresh tokens SHOULD expire if the client has =
been inactive for some time,
        	i.e. the =
refresh token has not been used to obtain fresh access tokens for
        	some time. The expiration time is =
at the discretion of the authorization server.
     =
   	It might be a global value or =
determined based on the client policy or
     =
   	the grant associated with the =
refresh token (and its sensitivity).
    This is =
slightly different but sufficient so +1 for the text :)

    Ok, thanks. 


    Proposals are welcome!

    kind regards,
    Torsten.


    This is =
in addition to the other best practices described.

    Thanks,
    George

    On =
11/20/18 2:32 PM, Torsten Lodderstedt wrote:
    Hi all,

    the new =
revision contains the following changes:

    * =
added section on refresh tokens
    * additional =
justifications for recommendation for code
    * refactored =
2.1 in order to distinguish CSRF, authz response replay and mix-up =
(based on feedback by Joseph Heenan)
    * added requirement =
to authenticate clients during code exchange (PKCE or client credential) =
to 2.1.1.
    * changed occurrences of SHALL to MUST

    As always: looking forward for your =
feedback.

    kind regards,
    Torsten.


    Am 20.11.2018 um 20:26 =
schrieb internet-drafts@ietf.org
    :


    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 =
Security Best Current Practice
     =
      Authors =
        : Torsten Lodderstedt
     =
            &n=
bsp;           John=
 Bradley
     =
            &n=
bsp;           Andr=
ey Labunets
     =
            &n=
bsp;           Dani=
el Fett
    	Filename =
       : =
draft-ietf-oauth-security-topics-10.txt
    	Pages =
          : 38
    	=
Date =
           : =
2018-11-20

    Abstract:
     =
 This document describes best current security practice for OAuth =
2.0.
      It updates and extends the OAuth 2.0 Security =
Threat Model to
      incorporate practical experiences =
gathered since OAuth 2.0 was
      published and covers =
new threats relevant due to the broader
      application =
of OAuth 2.0.


    The IETF =
datatracker status page for this draft is:

    https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topi=
cs/


    There are also =
htmlized versions available at:

    https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10=

    https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security=
-topics-10


    A diff from the =
previous version is available at:

    https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-t=
opics-10



    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/


    _______________________________________________
    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=_D61600FF-BF03-44EE-A980-893A4A6EEEA5--


From nobody Wed Nov 28 10:38:58 2018
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 4208C130FB1 for ; Wed, 28 Nov 2018 10:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 gVnQp6phIwHc for ; Wed, 28 Nov 2018 10:38:47 -0800 (PST)
Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0: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 A8D6F130FBD for ; Wed, 28 Nov 2018 10:38:39 -0800 (PST)
Received: by mail-it1-x12e.google.com with SMTP id i7so6034380iti.2 for ; Wed, 28 Nov 2018 10:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1lHPTQiuIQHeNMkMLvTxPt/EyOGGIHswJQWh3CmX3Gc=; b=E/r7qaiFjbVCEfrUIyP6BNjm6OvctheN+lQX9pt3MLR8HGgGVRHXFA+qw+HHzOAVbM KpFYGgNVMs/kki2wbKKYKcBrJgBiilg/kEUzWNg05u+u/xXDHvqowEAa5MxP38nQ7Qn6 jRQiXJM1Xl/HzM0g45n3ReQk45pkFnjQz2Tj4=
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=1lHPTQiuIQHeNMkMLvTxPt/EyOGGIHswJQWh3CmX3Gc=; b=hf9SvlFQN0sd2P0DgEEhZKI6lKBdR2Yhq75jLKhKTkGYUbHLHWWyxUiFa7lzQw0iMl KbEH/jNWu4ERg7bJqdz42D1s1aqZ0SxGFIdFpWI76vAlpTpxA7UIjmlNSqN25y5eEYsO YL1Um5EBjPV/E1kwSGQt877a+LG4BkBwXdLBPH45NSSSISDDEKtA/s2w13grG1lkZBrx JylM0PvrdzJwbn4tTxQ3q2ALvGhRILwD49XKVfM75gvQp4FKR+xQBmjP/EN7vrbwaRB6 Q248Jwah5oK/jk1FhKNZXQwthhYB9MVlGul0Knztf63lMy+7LZffEl3YW1BPb8z5OlrU o0Iw==
X-Gm-Message-State: AA+aEWZklYQpfCZFaQ6ojuH5EPZjg8p7V0EyAxSHqV+yXDGtn1FFhRNk VL6Rz1YzzTvSiKI7ETngP/wCVKe0HGbqpybGHI1BNsHs43OFaEvSnTqcPQngk4MZsBXgy3UL2EG Dka6sTwO/REoSqQ==
X-Google-Smtp-Source: AFSGD/WMIH8+htkgindmFMToa0inYYXwJQ2m7USlxMeo57su4arFzop+bH2k9w+fUBDTzYmU+P+/2MMtCTbT3zzE41c=
X-Received: by 2002:a24:8ac7:: with SMTP id v190mr3949175itd.174.1543430318708;  Wed, 28 Nov 2018 10:38:38 -0800 (PST)
MIME-Version: 1.0
References: <154274344398.29963.11727425335350408375.idtracker@ietfa.amsl.com>
In-Reply-To: <154274344398.29963.11727425335350408375.idtracker@ietfa.amsl.com>
From: Brian Campbell 
Date: Wed, 28 Nov 2018 11:38:12 -0700
Message-ID: 
To: Alissa Cooper 
Cc: The IESG , oauth ,  draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e2069b057bbddf4c"
Archived-At: 
Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 18:38:50 -0000

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

Thank you, Alissa, for the review. Please see below for inline
comments/responses and note that this is also my response to your last
message on the related thread at
https://mailarchive.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB38nWv4


On Tue, Nov 20, 2018 at 12:50 PM Alissa Cooper  wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-oauth-token-exchange-16: Discuss
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 6: The requirements around confidentiality here are weaker than i=
n
> both
> RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?
>

I think the why of it is some unintentional drift in the language along
with my general reluctance in using the 2119 words out of a fear of
overusing them (which I'm admittedly inconsistent about but it certainly
manifested itself in this text).

They should all say basically the same thing, which was really the intent,
if the actual wording didn't end up that way.

I think that changing a few of the little shoulds to big MUSTs or SHOULDs
would bring the requirements around confidentiality here in line with RFC
7519 Sec. 12 and RFC 6749 Sec. 10.8.. That updated text would be as
follows. Would this address your question/concern?

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



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 3:
>
> If I understand this correctly:
>
> "The distinction between an access token and a JWT is subtle."
>
> I think it would be clearer if it said:
>
> "The distinction between an access token type and a JWT token type is
> subtle."
>

In that sentence and paragraph I'm really meaning to talk about the things
themselves (access tokens and JWTs) rather than the type, which is more
like a way of naming those things. I don't think it's necessarily wrong
either way but my intention in writing is better reflected in the current
text. Furthermore, when the acronym in "JWT token" is expanded you get
"JSON Web Token token", which is something I'd like to avoid having in the
document.



> Section 4.1:
>
> What is the value of maintaining the whole delegation chain rather than
> expressing just the most recent delegation? Doesn't it potentially expose
> information about past exchanges unnecessarily?
>

There's value, in some situations, to being able to see/track the whole
delegation chain - primarily for auditing and troubleshooting type purposes
and typically when the parties in the chain are under the same domain of
organizational control where allowing that information to be available
isn't a concern but rather a benefit.

And, of course, there's no requirement that the whole delegation chain be
maintained. The syntax and structure of the claim allows for the info to be
represented when appropriate but doesn't mean that it has to be.

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

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


    Thank you, Alissa, for the review. Please s=
ee below for inline comments/responses and note that this is also my respon=
se to your last message on the related thread at https://mailarchi=
ve.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB38nWv4

    On Tue, Nov 20, 201=
8 at 12:50 PM Alissa Cooper <alissa@cooperw.in> wrote:
    Alissa Cooper has entered the following ballot=
 position for
    
draft-ietf-oauth-token-exchange-16: Discuss
    

    
Please refer to https://www.ietf.org/iesg/s=
tatement/discuss-criteria.html
    
for more information about IESG DISCUSS and COMMENT positions.
    

    

    
The document, along with other ballot positions, can be found here:
    
https://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-token-exchange/
    

    

    

    
----------------------------------------------------------------------
    
DISCUSS:
    
----------------------------------------------------------------------
    

    
Section 6: The requirements around confidentiality here are weaker than in =
both
    
RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?

    I think the why of it is some unintentional drift in the language al=
ong with my general reluctance in using the 2119 words out of a fear of ove=
rusing them (which I'm admittedly inconsistent about but it certainly m=
anifested itself in this text).
     =C2=A0 
    They shoul=
d all say basically the same thing, which was really the intent, if the act=
ual wording didn't end up that way.

    I think th=
at changing a few of the little shoulds to big MUSTs or SHOULDs would bring=
 the requirements around confidentiality here in line with RFC 7519 Sec. 12=
 and RFC 6749 Sec. 10.8.. That updated text would be as follows. Would this=
 address your question/concern?=C2=A0 
       Tokens employed in the context of the functionality described her=
ein
   may contain privacy-sensitive information and, to prevent disclosure
   of such information to unintended parties, MUST only be transmitted
   over encrypted channels, such as Transport Layer Security (TLS).  In
   cases where it is desirable to prevent disclosure of certain
   information to the client, the token MUST be encrypted to its
   intended recipient.  Deployments SHOULD determine the minimally
   necessary amount of data and only include such information in issued
   tokens.  In some cases, data minimization may include representing
   only an anonymous or pseudonymous user.

    

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

    
Section 3:
    

    
If I understand this correctly:
    

    
"The distinction between an access token and a JWT is subtle."

    
I think it would be clearer if it said:
    

    
"The distinction between an access token type and a JWT token type is =
subtle."

    In that sentence and para=
graph I'm really meaning to talk about the things themselves (access to=
kens and JWTs) rather than the type, which is more like a way of naming tho=
se things. I don't think it's necessarily wrong either way but my i=
ntention in writing is better reflected in the current text. Furthermore, w=
hen the acronym in "JWT token" is expanded you get "JSON Web=
 Token token", which is something I'd like to avoid having in the =
document.=C2=A0 

    =C2=A0
    
Section 4.1:
    

    
What is the value of maintaining the whole delegation chain rather than
    
expressing just the most recent delegation? Doesn't it potentially expo=
se
    
information about past exchanges unnecessarily?

    There's value, in some situations, to being able to see/track =
the whole delegation chain - primarily for auditing and troubleshooting typ=
e purposes and typically when the parties in the chain are under the same d=
omain of organizational control where allowing that information to be avail=
able isn't a concern but rather a benefit. 

    And, of course, there's no requirement that the whole delegation chai=
n be maintained. The syntax and structure of the claim allows for the info =
to be represented when appropriate but doesn't mean that it has to be. =


     
    


    
<=
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.
--000000000000e2069b057bbddf4c--


From nobody Wed Nov 28 11:58:10 2018
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 E99AC127B92 for ; Wed, 28 Nov 2018 11:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nDbKdfAZ8VrO for ; Wed, 28 Nov 2018 11:58:06 -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 6C2671277D2 for ; Wed, 28 Nov 2018 11:58:06 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id v15-v6so24567352ljh.13 for ; Wed, 28 Nov 2018 11:58: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=zcZpDFJzQCvdWfDejhOYegiAJ0EJi1/ZocJ4kPsBqk4=; b=VLxHE6ZRtIIvoQgkoT58aextgHCvLaBiCwqF/O+0iS196b3QXHEjioNJ2GVLWNcuYH 3mU0aTTP9DLFwqNWFQlk8D2U9ggEeF1nhkM67ryYVKXJ9V7hG7v98sPVdAwQ7ULdes0N JKKnuHDYfMN56nwoKe4z+B3G+fWfN8FgEIxjyWLopXl254FsrPBB4g0juuJADkgWchA8 MdcAZMuG+snzHeDaQJESqkjfPbB8Q5cpgkSmnlamFdHgzeqCkaVq9Vel89qZ1zSWoVsG POvAGJhxoF98Jseyl7g5vzAftThZMm7ov1P+oIJIonebvf+7shlHu4RlTfB73RR2uq+Z GaKw==
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=zcZpDFJzQCvdWfDejhOYegiAJ0EJi1/ZocJ4kPsBqk4=; b=inbiH0q4e3F6I6oPnroj2WHKdRTj+7WfPxUucMsITS/RF6nzvcLMEYMLl/urHBFqui e22nq42D439Zw1EUnekUpWsXlUVUsNVKkjD+7VM0MT+8A/euHdbf/P9d4iBVz3aCvD0N NjzJ4AGgNWKTsoVJLKXJUNZVmi3/QjGzBujJ+sZ70Q+F80m41B/eCPVn8hNYvzSBGva2 f3BY/6XREsEk6wp6kHPhvjzw3FUDUrn+/HO3N5w/DcmCR9fSgp0qKOodWuJbxb14J0Fa XJbRMCdQwx1kmgttCOVJ6TixiUoMjKs9qeE/6ps24M19gfc7Ha/wwYz9DKO/zlW24kVG 7ExQ==
X-Gm-Message-State: AGRZ1gLnVVHa9+mdlYIsmQgRYJDpjJJdoWnJQ3a2zAFL+cllhamLzi6U QDQvaiOlab7kQhyEe86WjL23/OGIUMlqZV4zZvU=
X-Google-Smtp-Source: AJdET5e5NgO5AzJaeFh5TovPfyPKGQ/2l8SAH1YE35l1X3wr9jPRfJA3deSH+sRGv+O+5TzIHYxWFmea7lvOKd2DByI=
X-Received: by 2002:a2e:9059:: with SMTP id n25-v6mr23746403ljg.155.1543435084144;  Wed, 28 Nov 2018 11:58:04 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 28 Nov 2018 11:57:50 -0800
Message-ID: 
To: Hannes Tschofenig 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000eca5c2057bbefb74"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 19:58:09 -0000

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

+1

While there are various mechanisms to alleviate some of the issues of
implicit, I don't think we can recommend specifics, and there may be future
ones in the future. I think we all agree that implicit without any
mitigation is problematic.

How about we recommend against using implicit alone?


On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig 
wrote:

> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion that
> it is not possible to adequately secure the implicit flow against token
> injection since potential solutions like token binding or JARM are in an
> early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
> ).
>
> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
>
> Hannes & Rifaat
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please 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.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    +1

    While there are various mechanisms t=
o alleviate some of the issues of implicit, I don't think we can recomm=
end specifics, and there may be future ones in the future. I think we all a=
gree that implicit without any mitigation is problematic.=C2=A0
    <=
br>
    How about we recommend against using implicit alone?=C2=A0


    On =
Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
    






    

    

    Hi all,
    

    

    The authors of the OAuth Sec=
urity Topics draft came to the conclusion that it is not possible to adequa=
tely secure the implicit flow against token injection since potential solut=
ions like token binding or JARM are in an early stage of
 adoption. For this reason, and since CORS allows browser-based apps to sen=
d requests to the token endpoint, Torsten suggested to use the authorizatio=
n code instead of the implicit grant in call cases in his presentation (see

https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d=
raft-ietf-oauth-security-topics-01).
    

    

    A hum in the room at IETF#10=
3 concluded strong support for his recommendations. We would like to confir=
m the discussion on the list.
    

    

    Please provide a response by=
 December 3rd.
    

    

    Ciao
    

    Hannes & Rifaat
    

    =C2=A0
    

    
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.

    

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

    

--000000000000eca5c2057bbefb74--


From nobody Wed Nov 28 12:10:14 2018
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 2139C130FDE for ; Wed, 28 Nov 2018 12:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAnIJyG5Z08L for ; Wed, 28 Nov 2018 12:10:10 -0800 (PST)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5ED130E5D for ; Wed, 28 Nov 2018 12:10:10 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id C5DB0196871; Thu, 29 Nov 2018 05:10:09 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 926884E0046; Thu, 29 Nov 2018 05:10:09 +0900 (JST)
Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wASKA9L0024766; Thu, 29 Nov 2018 05:10:09 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp with ESMTP id wASKA9lr024764; Thu, 29 Nov 2018 05:10:09 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wASKA9Ak034000; Thu, 29 Nov 2018 05:10:09 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wASKA9Jo033999; Thu, 29 Nov 2018 05:10:09 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wASKA8qI033996; Thu, 29 Nov 2018 05:10:09 +0900
Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM08PA.cu.nri.co.jp (172.159.253.50) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 05:10:08 +0900
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.176) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 05:10:08 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1F/MjAqXsOwWFlKPqfI3jt3VRYDGzRjTcYTGWgD+nMg=; b=qqavqbSzCcIITgY9FBSeSd4CStqTOQ61p0hSvR+RfTEkLKiouAuEkU1A3mNGrZbHFoQNu3MAAWfFnCNc0Co9KdKoXHFqgA5FYZUtaEP+txGE6FIxnUvYniDA0BIYTVwcWEnC+pKZTEP3TCKk3rbNknsmL+M4VJKFF2c04V/xduA=
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB4296.jpnprd01.prod.outlook.com (20.179.180.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.15; Wed, 28 Nov 2018 20:10:06 +0000
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Wed, 28 Nov 2018 20:10:06 +0000
From: n-sakimura 
To: Dick Hardt , Hannes Tschofenig 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwfc=
Date: Wed, 28 Nov 2018 20:10:06 +0000
Message-ID: 
References: , 
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [40.67.187.8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; OSBPR01MB4296; 6:fuBp3S2NCmT6Vv6RMkExbw587tl5YDQu6mTJqxqjRG/fe4QxBcEFHNTU4KzqnVwWEBPqG5++Tb+UF+dOYjQrHd9InmfTHlhy1O/hbO3TxgGrZXSn+O5afv9N61Cr5OiyGEj3RG5MYmG2jZSmtCg7ziUjMLP74hRrXYCIKkz8VHWsBw1E+srxcNuwnIrcIMWC/taPagDrmbl5MwJ/cn4uUODDvWbsjr2l2ORlEl/0nOlHshsUsLkgl2iX6fp5HN+U+TC+NEAk+VemrhMWDDi0qY789Lo4INDivFyUY+pWrJgWOD1ZdsGL8+dKjc92SP1qGT6da/pWO3HePHMm0c1PDnjiUo+eb6MJQC3LaKbhORa4hd4VvDSAmGfaEhs63ig/PK6xGVleJ14G2DtmZZ197556/mF3aTrH4csPANKYGQtdrTm+BH6x8Ba72S+LQVWCnd7us91flvR7wCz6yxPLbw==; 5:OwK2y7Kmg2HfErVNVDERuxvSHeUkesrha4Tx2nd76/zsmNzKmqZCdOjQB4xz71Dls2tF01ScahWwD5t8GUJWzfcTK27qWBSLTiQIy08Hz8hN3W23in1ioFrBcs98mcXcJ8V6Kzg2lh5fzMSZxgKHRiQ0A49AMqtFlTsyz8ZA/X4=; 7:Ej/jwR/cGei/CT1H018UC0iBhlPaYC+tR8B/YKkMu/Rn/7pP46+/qcF75VekpDZtJeaujLA6ytZFSNy4QbdDI+NeMHbqK8ngoHdRXJ2jEoF0g1rWy8r7E7Rb+mHulHRwXx6VchFI9LFEKtU4lO/Ifg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1df5abc8-c4d9-4c74-f54f-08d6556d7da3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB4296; 
x-ms-traffictypediagnostic: OSBPR01MB4296:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231443)(999002)(944501410)(52105112)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123562045)(2016111802025)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB4296; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB4296; 
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39840400004)(136003)(396003)(376002)(40434004)(53754006)(199004)(189003)(6246003)(39060400002)(486006)(66066001)(236005)(6306002)(55016002)(9686003)(54896002)(53936002)(74316002)(25786009)(4326008)(446003)(5660300001)(71200400001)(71190400001)(66574009)(476003)(11346002)(256004)(5024004)(14444005)(229853002)(86362001)(74482002)(508600001)(6436002)(7736002)(45080400002)(966005)(606006)(316002)(3846002)(6116002)(102836004)(26005)(186003)(6506007)(53546011)(110136005)(97736004)(2906002)(8936002)(7696005)(68736007)(33656002)(14454004)(76176011)(99286004)(81166006)(15650500001)(81156014)(106356001)(8676002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB4296; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-microsoft-antispam-message-info: kTOcRRBDNcy5eoVGVAGNdL7vBW5qorq0dVO9HncDncQrU6gKKg6f6VY64QFlfcDw4aALrOswP0TBj5ntCwS5M/Ghu0NmF8fvu8pXTcrm1WpHxuJ9y7PJ1tRsLwMV16xrh0fLbqDuUEJyI4PW9SQsHKc1ecYdYl6PoT3YA3IqXsezeLICDNo3Hb1zndboljVSJAUgJf2nbh020+PDvTJLtVmNaM6GXVhdvzqiF76aaD37URZeHDshKqVS4RSN5YY+3+IsU9/qhlaGehr0YueYJV9vuccTm4BEft3h4ONe+iwyWDLAj3mR0GoDhDhati7EReZjwyhEl6nyHJtYAkZf+uPzVGc7U8w19nWcLqkP//8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB2869E83F37046C7FCD4463DDF9D10OSBPR01MB2869jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1df5abc8-c4d9-4c74-f54f-08d6556d7da3
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 20:10:06.6666 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB4296
X-OrganizationHeadersPreserved: OSBPR01MB4296.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 20:10:13 -0000

--_000_OSBPR01MB2869E83F37046C7FCD4463DDF9D10OSBPR01MB2869jpnp_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

I would support

1) clearly defining Implicit as the flow that returns access token from the=
 authorization endpoint ( some people confuses implicit as the flow that re=
turns ID Token in the front channel)

2) Banning the returning of the access token that are not sender constraine=
d from the authorization endpoint

Best,

Nat


Outlook for iOS =1B$B$rF~ (Dick Hardt  =1B$B$NBeM}=1B(B)
=1B$BAw?.F|;~=1B(B: =1B$B?eMKF|=1B(B, 11=1B$B7n=1B(B 28, 2018 8:58 =1B$B8a8=
e=1B(B
=1B$B08@h=1B(B: Hannes Tschofenig
Cc: oauth@ietf.org
=1B$B7oL>=1B(B: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza=
tion code instead of implicit

+1

While there are various mechanisms to alleviate some of the issues of impli=
cit, I don't think we can recommend specifics, and there may be future ones=
 in the future. I think we all agree that implicit without any mitigation i=
s problematic.

How about we recommend against using implicit alone?


On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig > wrote:

Hi all,

The authors of the OAuth Security Topics draft came to the conclusion that =
it is not possible to adequately secure the implicit flow against token inj=
ection since potential solutions like token binding or JARM are in an early=
 stage of adoption. For this reason, and since CORS allows browser-based ap=
ps to send requests to the token endpoint, Torsten suggested to use the aut=
horization code instead of the implicit grant in call cases in his presenta=
tion (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oau=
th-sessb-draft-ietf-oauth-security-topics-01).

A hum in the room at IETF#103 concluded strong support for his recommendati=
ons. We would like to confirm the discussion on the list.

Please provide a response by December 3rd.

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_OSBPR01MB2869E83F37046C7FCD4463DDF9D10OSBPR01MB2869jpnp_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable







    

    

    

    I would support 
    


    

    

    1) clearly defining Implicit as the flow tha=
t returns access token from the authorization endpoint ( some people confus=
es implicit as the flow that returns ID Token in the front channel)

    


    

    

    2) Banning the returning of the access token=
 that are not sender constrained from the authorization endpoint

    


    

    

    Best, 
    


    

    

    Nat 
    


    

    

    


    

    

    O=
utlook for iOS =1B$B$rF~

    

     
    

    

    =1B$B:9=3DP?M=
=1B(B: OAuth <oauth-bounces@ietf.org> (Dick Hardt <dick.hardt@=
gmail.com> =1B$B$NBeM}=1B(B)
    
=1B$BAw?.F|;~=1B(B: =1B$B?eMKF|=1B(B, 11=1B$B7n=1B(B 28, 2018 8:58 =
=1B$B8a8e=1B(B
    
=1B$B08@h=1B(B: Hannes Tschofenig
    
Cc: oauth@ietf.org
    
=1B$B7oL>=1B(B: Re: [OAUTH-WG] OAuth Security Topics -- Recommend au=
thorization code instead of implicit

     
    

    


    +1


    

    

    While there are various mechanisms to alleviate some of the issues of =
implicit, I don't think we can recommend specifics, and there may be future=
 ones in the future. I think we all agree that implicit without any mitigat=
ion is problematic. 
    


    

    

    How about we recommend against using implicit alone? 
    


    

    

    

    

    

    On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>=
 wrote:
    

    

    

    

    

    Hi all,
    

    

    The authors of the OAuth Sec=
urity Topics draft came to the conclusion that it is not possible to adequa=
tely secure the implicit flow against token injection since potential solut=
ions like token binding or JARM are
 in an early stage of adoption. For this reason, and since CORS allows brow=
ser-based apps to send requests to the token endpoint, Torsten suggested to=
 use the authorization code instead of the implicit grant in call cases in =
his presentation (see

https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d=
raft-ietf-oauth-security-topics-01).
    

    

    A hum in the room at IETF#10=
3 concluded strong support for his recommendations. We would like to confir=
m the discussion on the list.
    

    

    Please provide a response by=
 December 3rd.
    

    

    Ciao
    

    Hannes & Rifaat
    

     
    

    
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose,
 or store or copy the information in any medium. Thank you. 
    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    

    

    

    



--_000_OSBPR01MB2869E83F37046C7FCD4463DDF9D10OSBPR01MB2869jpnp_--


From nobody Wed Nov 28 13:44:50 2018
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 9AF8C131054 for ; Wed, 28 Nov 2018 13:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.259
X-Spam-Level: 
X-Spam-Status: No, score=-13.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 zJpgJxpP9jWF for ; Wed, 28 Nov 2018 13:44:46 -0800 (PST)
Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CAD13104D for ; Wed, 28 Nov 2018 13:44:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1543441485; x=1574977485; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vwHaDaIdrmDI3hiz38UgKWe/O4o0LNPmIufpSzbJY8Y=; b=Us9u7d95kcWk5pQ+EDjpmMoMfybXKIRBlp5QSFga0JVXfycztCH9XtPH RYJ0U4U+Zmp8+kSMVog6pBfeijP6gPpbEjkbo2cYTjUH1KVJVpvwxrcsU uPZsvvfeaswDcyOgIUC/Bxo5og8y9Ibq2BRerNhkP9LXHrhEqH1MPZ2+C I=;
X-IronPort-AV: E=Sophos;i="5.56,253,1539648000";  d="scan'208,217";a="370074402"
Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-98acfc19.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  28 Nov 2018 21:44:43 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-98acfc19.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id wASLia0S036764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Nov 2018 21:44:42 GMT
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 21:44:41 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 21:44:41 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 28 Nov 2018 21:44:41 +0000
From: "Richard Backman, Annabelle" 
To: n-sakimura , Dick Hardt , Hannes Tschofenig 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwff//5WYgA==
Date: Wed, 28 Nov 2018 21:44:41 +0000
Message-ID: <2F9B53BD-23B3-4176-B2CE-466AF2D406D1@amazon.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.63]
Content-Type: multipart/alternative; boundary="_000_2F9B53BD23B34176B2CE466AF2D406D1amazoncom_"
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 21:44:49 -0000

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

SSBzdHJvbmdseSBzdXBwb3J0IHRoZSBhdXRob3LigJlzIHByb3Bvc2VkIHRleHQgcmVjb21tZW5k
aW5nIHRoYXQg4oCcQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQgZ3JhbnQgb3Ig
YW55IG90aGVyIHJlc3BvbnNlIHR5cGUgY2F1c2luZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg
dG8gaXNzdWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLuKA
nSBXaGlsZSBpdCBtYXkgYmUgcG9zc2libGUgdG8gY29uc3RydWN0IHNjZW5hcmlvcyBpbiB3aGlj
aCB1c2Ugb2Ygc2VuZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgbWl0aWdhdGVzIHRoZSBt
YWpvciBrbm93biB0aHJlYXRzLCB0aGlzIHN0cmlrZXMgbWUgYXMgYSBuaWNoZSB1c2UgY2FzZSB0
aGF0IHdpbGwgYmUgdmVyeSBoYXJkIGZvciBkZXZlbG9wZXJzIHRvIGdldCByaWdodCwgaW4gcHJh
Y3RpY2UgKHBhcnRpY3VsYXJseSBpZiBicm93c2VycyBkb27igJl0IHN1cHBvcnQgdG9rZW4gYmlu
ZGluZykuIFRoaXMgc2VlbXMgdG8gbWVldCB0aGUgY3JpdGVyaWEgZm9yIOKAnFNIT1VMRCBOT1Qu
4oCdDQoNCkJlYXIgaW4gbWluZCB0aGF0IHRoZSBwcm9wb3NlZCB0ZXh0IGRvZXMgbm90IHByb2hp
Yml0IHRoZSBwcmFjdGljZSwgYnV0IGl0IGluZm9ybXMgdGhlIHJlYWRlciB0aGF0IHRoZXkgaGFk
IGJldHRlciBrbm93IHdoYXQgdGhleSBhcmUgZG9pbmcgaWYgdGhleeKAmXJlIGdvaW5nIHRvIHVz
ZSBpbXBsaWNpdCBncmFudCAob3IgdGhlIE9JREMgaHlicmlkIGZsb3csIGV0Yy4pLiBJIHRoaW5r
IHRoYXQgaXMgZ29vZCBndWlkYW5jZSDigJMgc2VuZGluZyBhY2Nlc3MgdG9rZW5zIHRocm91Z2gg
YSBmcm9udCBjaGFubmVsIGlzIGRlZmluaXRlIOKAnGhlcmUgdGhlcmUgYmUgZHJhZ29uc+KAnSB0
ZXJyaXRvcnkuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkN
Cg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG4t
c2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJl
ciAyOCwgMjAxOCBhdCAxMjoxMSBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu
Y29tPiwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGFybS5jb20+DQpDYzog
Im9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBp
bnN0ZWFkIG9mIGltcGxpY2l0DQoNCkkgd291bGQgc3VwcG9ydA0KDQoxKSBjbGVhcmx5IGRlZmlu
aW5nIEltcGxpY2l0IGFzIHRoZSBmbG93IHRoYXQgcmV0dXJucyBhY2Nlc3MgdG9rZW4gZnJvbSB0
aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCAoIHNvbWUgcGVvcGxlIGNvbmZ1c2VzIGltcGxpY2l0
IGFzIHRoZSBmbG93IHRoYXQgcmV0dXJucyBJRCBUb2tlbiBpbiB0aGUgZnJvbnQgY2hhbm5lbCkN
Cg0KMikgQmFubmluZyB0aGUgcmV0dXJuaW5nIG9mIHRoZSBhY2Nlc3MgdG9rZW4gdGhhdCBhcmUg
bm90IHNlbmRlciBjb25zdHJhaW5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50DQoN
CkJlc3QsDQoNCk5hdA0KDQoNCk91dGxvb2sgZm9yIGlPUzxodHRwczovL2FrYS5tcy9vMHVrZWY+
IOOCkuWFpeaJiw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5beu5Ye65Lq6
OiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gKERpY2sgSGFyZHQgPGRpY2suaGFyZHRA
Z21haWwuY29tPiDjga7ku6PnkIYpDQrpgIHkv6Hml6XmmYI6IOawtOabnOaXpSwgMTHmnIggMjgs
IDIwMTggODo1OCDljYjlvowNCuWum+WFiDogSGFubmVzIFRzY2hvZmVuaWcNCkNjOiBvYXV0aEBp
ZXRmLm9yZw0K5Lu25ZCNOiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0g
UmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0DQoNCisxDQoN
CldoaWxlIHRoZXJlIGFyZSB2YXJpb3VzIG1lY2hhbmlzbXMgdG8gYWxsZXZpYXRlIHNvbWUgb2Yg
dGhlIGlzc3VlcyBvZiBpbXBsaWNpdCwgSSBkb24ndCB0aGluayB3ZSBjYW4gcmVjb21tZW5kIHNw
ZWNpZmljcywgYW5kIHRoZXJlIG1heSBiZSBmdXR1cmUgb25lcyBpbiB0aGUgZnV0dXJlLiBJIHRo
aW5rIHdlIGFsbCBhZ3JlZSB0aGF0IGltcGxpY2l0IHdpdGhvdXQgYW55IG1pdGlnYXRpb24gaXMg
cHJvYmxlbWF0aWMuDQoNCkhvdyBhYm91dCB3ZSByZWNvbW1lbmQgYWdhaW5zdCB1c2luZyBpbXBs
aWNpdCBhbG9uZT8NCg0KDQpPbiBNb24sIE5vdiAxOSwgMjAxOCBhdCAyOjM0IEFNIEhhbm5lcyBU
c2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuLlRzY2hv
ZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNClRoZSBhdXRob3JzIG9mIHRoZSBP
QXV0aCBTZWN1cml0eSBUb3BpY3MgZHJhZnQgY2FtZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IGl0
IGlzIG5vdCBwb3NzaWJsZSB0byBhZGVxdWF0ZWx5IHNlY3VyZSB0aGUgaW1wbGljaXQgZmxvdyBh
Z2FpbnN0IHRva2VuIGluamVjdGlvbiBzaW5jZSBwb3RlbnRpYWwgc29sdXRpb25zIGxpa2UgdG9r
ZW4gYmluZGluZyBvciBKQVJNIGFyZSBpbiBhbiBlYXJseSBzdGFnZSBvZiBhZG9wdGlvbi4gRm9y
IHRoaXMgcmVhc29uLCBhbmQgc2luY2UgQ09SUyBhbGxvd3MgYnJvd3Nlci1iYXNlZCBhcHBzIHRv
IHNlbmQgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LCBUb3JzdGVuIHN1Z2dlc3RlZCB0
byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIHRoZSBpbXBsaWNpdCBncmFu
dCBpbiBjYWxsIGNhc2VzIGluIGhpcyBwcmVzZW50YXRpb24gKHNlZSBodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLW9hdXRoLXNlc3Ni
LWRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTAxKS4NCg0KQSBodW0gaW4gdGhlIHJv
b20gYXQgSUVURiMxMDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0IGZvciBoaXMgcmVjb21tZW5k
YXRpb25zLiBXZSB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRpc2N1c3Npb24gb24gdGhlIGxp
c3QuDQoNClBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIgM3JkLg0KDQpDaWFv
DQoNCkhhbm5lcyAmIFJpZmFhdA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2Yg
dGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBh
bHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs
IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3Nl
IHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl
LCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5
b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1
dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=

--_000_2F9B53BD23B34176B2CE466AF2D406D1amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <480FF48984E9AC47A027BBC451A20D9D@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToy
IDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5
IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsN
CglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv
LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp
bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6
MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KcC5tLTQyNTczOTY0MTc1MjYxNjgxOG1zb3BsYWludGV4dCwgbGkubS00MjU3Mzk2NDE3
NTI2MTY4MThtc29wbGFpbnRleHQsIGRpdi5tLTQyNTczOTY0MTc1MjYxNjgxOG1zb3BsYWludGV4
dA0KCXttc28tc3R5bGUtbmFtZTptXy00MjU3Mzk2NDE3NTI2MTY4MThtc29wbGFpbnRleHQ7DQoJ
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx
LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0cm9uZ2x5IHN1
cHBvcnQgdGhlIGF1dGhvcuKAmXMgcHJvcG9zZWQgdGV4dCByZWNvbW1lbmRpbmcgdGhhdCDigJxD
bGllbnRzIFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdCBncmFudCBvciBhbnkgb3RoZXIgcmVz
cG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBpc3N1ZSBhbiBh
Y2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2Uu4oCdIFdoaWxlIGl0IG1h
eQ0KIGJlIHBvc3NpYmxlIHRvIGNvbnN0cnVjdCBzY2VuYXJpb3MgaW4gd2hpY2ggdXNlIG9mIHNl
bmRlci1jb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIG1pdGlnYXRlcyB0aGUgbWFqb3Iga25vd24g
dGhyZWF0cywgdGhpcyBzdHJpa2VzIG1lIGFzIGEgbmljaGUgdXNlIGNhc2UgdGhhdCB3aWxsIGJl
IHZlcnkgaGFyZCBmb3IgZGV2ZWxvcGVycyB0byBnZXQgcmlnaHQsIGluIHByYWN0aWNlIChwYXJ0
aWN1bGFybHkgaWYgYnJvd3NlcnMgZG9u4oCZdCBzdXBwb3J0DQogdG9rZW4gYmluZGluZykuIFRo
aXMgc2VlbXMgdG8gbWVldCB0aGUgY3JpdGVyaWEgZm9yIOKAnFNIT1VMRCBOT1Qu4oCdPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkJlYXIgaW4gbWluZCB0aGF0IHRoZSBwcm9wb3NlZCB0ZXh0IGRv
ZXMgbm90IHByb2hpYml0IHRoZSBwcmFjdGljZSwgYnV0IGl0IGluZm9ybXMgdGhlIHJlYWRlciB0
aGF0IHRoZXkgaGFkIGJldHRlciBrbm93IHdoYXQgdGhleSBhcmUgZG9pbmcgaWYgdGhleeKAmXJl
IGdvaW5nIHRvIHVzZSBpbXBsaWNpdCBncmFudCAob3IgdGhlIE9JREMgaHlicmlkIGZsb3csIGV0
Yy4pLiBJIHRoaW5rIHRoYXQgaXMgZ29vZCBndWlkYW5jZQ0KIOKAkyBzZW5kaW5nIGFjY2VzcyB0
b2tlbnMgdGhyb3VnaCBhIGZyb250IGNoYW5uZWwgaXMgZGVmaW5pdGUg4oCcaGVyZSB0aGVyZSBi
ZSBkcmFnb25z4oCdIHRlcnJpdG9yeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt
YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDssc2VyaWYiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y
OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv
bG9yOmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm
IG9mIG4tc2FraW11cmEgJmx0O24tc2FraW11cmFAbnJpLmNvLmpwJmd0Ozxicj4NCjxiPkRhdGU6
IDwvYj5XZWRuZXNkYXksIE5vdmVtYmVyIDI4LCAyMDE4IGF0IDEyOjExIFBNPGJyPg0KPGI+VG86
IDwvYj5EaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDssIEhhbm5lcyBUc2No
b2ZlbmlnICZsdDtoYW5uZXMudHNjaG9mZW5pZ0Bhcm0uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+
JnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxi
PlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVj
b21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxpY2l0PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JIHdvdWxkIHN1cHBvcnQgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIGNsZWFybHkgZGVmaW5pbmcgSW1wbGljaXQg
YXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0
aW9uIGVuZHBvaW50ICggc29tZSBwZW9wbGUgY29uZnVzZXMgaW1wbGljaXQgYXMgdGhlIGZsb3cg
dGhhdCByZXR1cm5zIElEIFRva2VuIGluIHRoZSBmcm9udCBjaGFubmVsKQ0KPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIEJhbm5pbmcgdGhl
IHJldHVybmluZyBvZiB0aGUgYWNjZXNzIHRva2VuIHRoYXQgYXJlIG5vdCBzZW5kZXIgY29uc3Ry
YWluZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludA0KPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsIDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQgPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo
cmVmPSJodHRwczovL2FrYS5tcy9vMHVrZWYiPk91dGxvb2sgZm9yIGlPUzwvYT4gPHNwYW4gbGFu
Zz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPg0K44KS5YWl
5omLPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhy
IHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJk
aXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkpBIiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7lt67l
h7rkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5v
cmcmZ3Q7IChEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDsNCjwvc3Bhbj48
c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztj
b2xvcjpibGFjayI+44Gu5Luj55CGPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+KTxi
cj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01T
IEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+6YCB5L+h5pel5pmCPC9zcGFuPjwvYj48Yj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH
b3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuawtOabnOaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiwgMTE8L3NwYW4+PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPiAyOCwgMjAxOCA4OjU4DQo8L3NwYW4+PHNwYW4gbGFuZz0iSkEiIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuWNiOW+jDwv
c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5n
PSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFj
ayI+5a6b5YWIPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KPGI+
Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJKQSIgc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+5Lu25ZCN
PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5IFRvcGlj
cyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGljaXQNCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIDxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhlcmUgYXJlIHZhcmlvdXMg
bWVjaGFuaXNtcyB0byBhbGxldmlhdGUgc29tZSBvZiB0aGUgaXNzdWVzIG9mIGltcGxpY2l0LCBJ
IGRvbid0IHRoaW5rIHdlIGNhbiByZWNvbW1lbmQgc3BlY2lmaWNzLCBhbmQgdGhlcmUgbWF5IGJl
IGZ1dHVyZSBvbmVzIGluIHRoZSBmdXR1cmUuIEkgdGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgaW1w
bGljaXQgd2l0aG91dCBhbnkgbWl0aWdhdGlvbiBpcyBwcm9ibGVtYXRpYy4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGFib3V0
IHdlIHJlY29tbWVuZCBhZ2FpbnN0IHVzaW5nIGltcGxpY2l0IGFsb25lPyZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwg
Tm92IDE5LCAyMDE4IGF0IDI6MzQgQU0gSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1h
aWx0bzpIYW5uZXMuLlRzY2hvZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0ibS00MjU3Mzk2NDE3NTI2MTY4MThtc29wbGFpbnRleHQiPjxz
cGFuIGxhbmc9IkVOLUdCIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Im0tNDI1NzM5NjQxNzUyNjE2ODE4bXNvcGxhaW50ZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+VGhl
IGF1dGhvcnMgb2YgdGhlIE9BdXRoIFNlY3VyaXR5IFRvcGljcyBkcmFmdCBjYW1lIHRvIHRoZSBj
b25jbHVzaW9uIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGFkZXF1YXRlbHkgc2VjdXJlIHRo
ZSBpbXBsaWNpdCBmbG93IGFnYWluc3QgdG9rZW4gaW5qZWN0aW9uIHNpbmNlIHBvdGVudGlhbCBz
b2x1dGlvbnMgbGlrZSB0b2tlbg0KIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFybHkgc3Rh
Z2Ugb2YgYWRvcHRpb24uIEZvciB0aGlzIHJlYXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dzIGJy
b3dzZXItYmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwg
VG9yc3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBv
ZiB0aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9uDQog
KHNlZSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAzL21h
dGVyaWFscy9zbGlkZXMtMTAzLW9hdXRoLXNlc3NiLWRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHkt
dG9waWNzLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLW9hdXRoLXNlc3NiLWRyYWZ0LWlldGYt
b2F1dGgtc2VjdXJpdHktdG9waWNzLTAxPC9hPikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Im0tNDI1NzM5NjQxNzUyNjE2ODE4bXNvcGxhaW50ZXh0Ij48c3BhbiBsYW5nPSJFTi1H
QiI+QSBodW0gaW4gdGhlIHJvb20gYXQgSUVURiMxMDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0
IGZvciBoaXMgcmVjb21tZW5kYXRpb25zLiBXZSB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRp
c2N1c3Npb24gb24gdGhlIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im0t
NDI1NzM5NjQxNzUyNjE2ODE4bXNvcGxhaW50ZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+UGxlYXNl
IHByb3ZpZGUgYSByZXNwb25zZSBieSBEZWNlbWJlciAzcmQuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Im0tNDI1NzM5NjQxNzUyNjE2ODE4bXNvcGxhaW50ZXh0Ij48c3BhbiBsYW5n
PSJFTi1HQiI+Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtLTQyNTczOTY0
MTc1MjYxNjgxOG1zb3BsYWludGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPkhhbm5lcyAmYW1wOyBS
aWZhYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUg
Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp
YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g
bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cw0KIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm
b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt
ZWRpdW0uIFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_2F9B53BD23B34176B2CE466AF2D406D1amazoncom_--


From nobody Wed Nov 28 14:38:20 2018
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 889DF13107A for ; Wed, 28 Nov 2018 14:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 FLcTdC0A97ow for ; Wed, 28 Nov 2018 14:38:08 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 9C41D124C04 for ; Wed, 28 Nov 2018 14:38:08 -0800 (PST)
Received: from [84.175.172.56] (helo=torstens-mbp.speedport_w_921v_1_44_000) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gS8T6-0002gZ-LF; Wed, 28 Nov 2018 23:38:04 +0100
From: Torsten Lodderstedt 
Message-Id: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_D38A91DD-696F-4B78-B726-6D8D7C752A1C"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 23:38:03 +0100
In-Reply-To: 
Cc: Dick Hardt , Hannes Tschofenig , "oauth@ietf.org" 
To: n-sakimura 
References:   
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 22:38:19 -0000

--Apple-Mail=_D38A91DD-696F-4B78-B726-6D8D7C752A1C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CCC1F36A-02EA-4D85-B2A4-CFB18E09CF5E"


--Apple-Mail=_CCC1F36A-02EA-4D85-B2A4-CFB18E09CF5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Nat,=20

> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>=20
> I would support
>=20
> 1) clearly defining Implicit as the flow that returns access token =
from the authorization endpoint ( some people confuses implicit as the =
flow that returns ID Token in the front channel)

That=E2=80=99s the current text:=20

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

What would you like to modify?=20

>=20
> 2) Banning the returning of the access token that are not sender =
constrained from the authorization endpoint

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response, if this access =
tokens is not sender-constraint.

What about this?

kind regards,
Torsten.

>=20
> Best,
>=20
> Nat
>=20
>=20
> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> =20
> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick =
Hardt  =E3=81=AE=E4=BB=A3=E7=90=86)
> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> Cc: oauth@ietf.org
> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
> =20
> +1
>=20
> While there are various mechanisms to alleviate some of the issues of =
implicit, I don't think we can recommend specifics, and there may be =
future ones in the future. I think we all agree that implicit without =
any mitigation is problematic.=20
>=20
> How about we recommend against using implicit alone?=20
>=20
>=20
> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig =
 wrote:
> Hi all,
>=20
> The authors of the OAuth Security Topics draft came to the conclusion =
that it is not possible to adequately secure the implicit flow against =
token injection since potential solutions like token binding or JARM are =
in an early stage of adoption. For this reason, and since CORS allows =
browser-based apps to send requests to the token endpoint, Torsten =
suggested to use the authorization code instead of the implicit grant in =
call cases in his presentation (see =
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-=
draft-ietf-oauth-security-topics-01).
>=20
> A hum in the room at IETF#103 concluded strong support for his =
recommendations. We would like to confirm the discussion on the list.
>=20
> Please provide a response by December 3rd.
>=20
> Ciao
>=20
> Hannes & Rifaat
>=20
> =20
>=20
> IMPORTANT NOTICE: The contents of this email and any attachments are =
confidential and may also be privileged. If you are not the intended =
recipient, please 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.
> _______________________________________________
> 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=_CCC1F36A-02EA-4D85-B2A4-CFB18E09CF5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi Nat, 
    Am 28.11.2018 um 21:10 =
schrieb n-sakimura <n-sakimura@nri.co.jp>:

    I =
would support

    1) clearly defining Implicit =
as the flow that returns access token from the authorization endpoint ( =
some people confuses implicit as the flow that returns ID Token in =
the front channel)

    That=E2=80=99s the current =
text: 

    In =
order to avoid these issues, Clients SHOULD NOT use the =
implicit
       grant or any other response =
type causing the authorization server to
      =
 issue an access token in the authorization response.

    What would you like to =
modify? 


    2) Banning the returning of the =
access token that are not sender constrained from the authorization =
endpoint

    In order to avoid these issues, Clients SHOULD NOT use =
the implicit
       grant or any other response type =
causing the authorization server to
       issue an =
access token in the authorization response, if this access =
tokens is not sender-constraint.

    What about this?
    kind regards,
    Torsten.


    Best,

    Nat


    Outlook for =
iOS =E3=82=92=E5=85=A5=E6=89=8B
     
    =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick Hardt <dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    =E5=AE=9B=E5=85=88: Hannes Tschofenig
    Cc: oauth@ietf.org
    =E4=BB=B6=E5=90=8D: Re: =
[OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead =
of implicit
     
    +1

    While there are various mechanisms to alleviate some of the =
issues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that =
implicit without any mitigation is problematic. 

    How about we recommend against using implicit alone? 


    On Mon, Nov 19, 2018 at 2:34 AM =
Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
    Hi =
all,

    The authors of the OAuth Security =
Topics draft came to the conclusion that it is not possible to =
adequately secure the implicit flow against token injection since =
potential solutions like token binding or JARM are in an early =
stage of adoption. For this reason, and since CORS allows =
browser-based apps to send requests to the token endpoint, Torsten =
suggested to use the authorization code instead of the implicit =
grant in call cases in his presentation =
(see https://datatracker.ietf.org/meeting/103/materials/slides-103-oa=
uth-sessb-draft-ietf-oauth-security-topics-01).

    A hum in the room at IETF#103 concluded strong support for =
his recommendations. We would like to confirm the discussion on =
the list.

    Please provide a response by =
December 3rd.

    Ciao

    Hannes & Rifaat

     

    IMPORTANT NOTICE: The contents of this email =
and any attachments are confidential and may also be privileged. If you =
are not the intended recipient, please 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.
    _______________________________________________
    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=_CCC1F36A-02EA-4D85-B2A4-CFB18E09CF5E--

--Apple-Mail=_D38A91DD-696F-4B78-B726-6D8D7C752A1C
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjgyMjM4MDRaMC8GCSqGSIb3DQEJBDEiBCDU
0zk8zD+AjKXszKaweyXiZ3fmUKnQSr6z9QXLHIOJZzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAESMuwCFISFE2QkCBh/IAQn9i
/fz6R/1oiu3Mn50ooRkBvG92tIOymORdMFLDYYuxSJtokKWWh+hIy2ODjuLpAK00YlBHUbJm6Dw1
NXMSzacox5201fGtJ/94F6aVp7mrsIrf0Iht/xi5O6/XWjO/MM7unyX9oscd1nVfdcRcGXhDKRkC
Nbm6KzjD5yRTNPo95H8p31dVUKEYmBnz4u2ft6gBuosBXSYQXuCSR/EutYwK3tHIN3ir7MhV4LR/
npHn2Hd8BDlVXjjko5y++5QI+2nBZrFn5p20IOMYZeKaTXeasSj45f9J1ldvWkLtOQTSQxwIWwQ3
/sh0rm9e63uYxgAAAAAAAA==
--Apple-Mail=_D38A91DD-696F-4B78-B726-6D8D7C752A1C--


From nobody Wed Nov 28 14:51:02 2018
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 5E5B4130DC0 for ; Wed, 28 Nov 2018 14:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZvzhn7gZeBx for ; Wed, 28 Nov 2018 14:50:59 -0800 (PST)
Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A562130E27 for ; Wed, 28 Nov 2018 14:50:58 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id 8BCFB77EE5; Thu, 29 Nov 2018 07:50:57 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 2ECEE4E0046; Thu, 29 Nov 2018 07:50:57 +0900 (JST)
Received: from nriea02.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wASMovnw010702; Thu, 29 Nov 2018 07:50:57 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp with ESMTP id wASMouR4010692; Thu, 29 Nov 2018 07:50:57 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wASMouXE061794; Thu, 29 Nov 2018 07:50:56 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wASMoumm061793; Thu, 29 Nov 2018 07:50:56 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wASMou1M061790; Thu, 29 Nov 2018 07:50:56 +0900
Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM06PA.cu.nri.co.jp (172.159.253.48) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 07:50:55 +0900
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.175) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 07:50:55 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vjkoa9Ki/r2tDW9QJL5A3nwaGQJQCqg5tJ+jxdsCjlA=; b=b7ED8nzKJspkWTTTaruPr/R4bufRQM/EjCqh+pICfqfidezRf9DMCdFh8QqQaupwko/xT5AGC5lbpYZV1J9FosJxHkVCzjyp+omFPSaEmMxfWOlx+uYD2fbPrm1oZEgqthIxmrIcTtLUri3HD3rFUD0NEQ26fG5B57RbSqnTo8w=
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB3607.jpnprd01.prod.outlook.com (20.178.96.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.16; Wed, 28 Nov 2018 22:50:53 +0000
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Wed, 28 Nov 2018 22:50:53 +0000
From: n-sakimura 
To: Torsten Lodderstedt , n-sakimura 
CC: Dick Hardt , Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwfcABVOygAAAbOyY
Date: Wed, 28 Nov 2018 22:50:53 +0000
Message-ID: 
References:   , <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>
In-Reply-To: <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>
Accept-Language: ja-JP, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [40.67.190.194]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; OSBPR01MB3607; 6:9xDUzNl9ghwn5wRZxSMVVHg/0WWbzZi8ZRKAPz60qjDWHpCHXHQFihPt4EBgrvUp0z+i6ZwtRElV+xd1KdONRrUE/Z+Ojost8vFq4n7XNyHSf5jRp+F7FuLGBfZ6Y5i/r3nynczkTAaGQ23IhphHtteXzP+DVQITD4q11JSee47ufrfqeSbZv83jkWPGUu4mksQSN31DVn61cDPit1sIw08Ivhc3yJh0XWIA0LmcC2ZgohH6FBV0uh3bCfGljr/NV8pPV19fB4IoXPxczIBdtsVve2E8CB1pSZtQ2O9gODYe1/DOqTmQQ+LA4d7Mywnt4ua6lPanRRlsupvZdP2pTHGKXLTYE4nLQwqYAcn9by8Soo2VRhKQlg/o4w8/Fsyj+N+dR/de4ylYwxGsfi9FS4MHtgj+8INNpUADO+XKOuZrAmH+GVFiI6cnFrtgRhMmmhWVSE5kMVhF8U8UQZsqdg==; 5:cmQjS47b5SxJ3GhnRcE9iTfk5EtPhjcw2dQ136wTfMjdp0IZSld0xwqRlbvy0cq609dEmWpe4+znF9ppi75fYDpu9PHF6Wie8qdFdc9wzl+bl1nXZ/jObZ9Wyx5OtsvIrve4bkpV31zdAHSoSmCB22pPULFZmqRDkPUJTzi97Js=; 7:4tr+HN+tzj/VaHXuftcBsSxalQESbZfprMyB1/fAO6a9K15wLfJ3Q5Gsqv5ygJ2y1kptHpUUuNOMkT6/glJNbmWHD2SWg0fu3PWS+o19hjHgIzTaStDga3NgzjOP2xvrRtTvIr+hoVxpKnWWUv2+4Q==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 591c3de0-6ddd-45c9-3dc9-08d65583f3bf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB3607; 
x-ms-traffictypediagnostic: OSBPR01MB3607:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231443)(999002)(944501410)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(2016111802025)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB3607; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB3607; 
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(366004)(39840400004)(396003)(53754006)(365934003)(40434004)(189003)(199004)(110136005)(39060400002)(25786009)(71190400001)(54896002)(71200400001)(9686003)(74316002)(6306002)(55016002)(8936002)(14444005)(5024004)(54906003)(236005)(66574009)(7736002)(45080400002)(508600001)(2906002)(66066001)(86362001)(105586002)(106356001)(966005)(74482002)(4326008)(229853002)(81166006)(93886005)(81156014)(7696005)(8676002)(26005)(53936002)(446003)(186003)(14454004)(102836004)(6246003)(97736004)(3846002)(6116002)(11346002)(33656002)(256004)(76176011)(486006)(6436002)(99286004)(316002)(15650500001)(476003)(6506007)(53546011)(5660300001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB3607; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-microsoft-antispam-message-info: c8kAx4Tiy/9VRMe8DfrQS6G6ACmLsX6JQ5AmN82uMKsdnpKuwnBthg84Ntm+s6GvsAMqAR1qF1zimnWO7DRlYZ+VN83Y2Sz+WYZvHW/gALtLoMbjJ8NOUGOt9yVrUbCOfytytjQnkav5Tt+GpBI6U+35JdxhJM0OYEkBqs14QahLjQlTZAXcw5SctdOt1U3Ja6sukGx0V1edEWKkOzpaof0zWABvwdATPIkQyohWGpFdTUI/YAhgt/gSiCqV5g/ZHqs3ITG+attNErciN5pU/HyTGp9A+8QEVdtwEwsG0BT3IG7Wi0AIntZ+RMp7bR7wCQuSxSdivc0Vf3/D6O1jDHF7/N54N5NAdeGMOD6XfYM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB28690F77DFFB2A85BDB83FBAF9D10OSBPR01MB2869jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 591c3de0-6ddd-45c9-3dc9-08d65583f3bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 22:50:53.7336 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB3607
X-OrganizationHeadersPreserved: OSBPR01MB3607.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 22:51:02 -0000

--_000_OSBPR01MB28690F77DFFB2A85BDB83FBAF9D10OSBPR01MB2869jpnp_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

That works.

In fact, I would further go and say MUST NOT but that probably is too much =
for a security consideration.

Best,

Nat

Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276

=1B$B$3$N%a!<%k$K$O!"K\Mh$N08@h$NJ}$N$_$K8BDj$5$l$?5!L)>pJs$,4^$^$l$F$$$k>l=
9g$,$4$6$$$^$9!#$*?4$"$?$j$N$J$$>l9g$O!"@?$K?=3D$7Lu$4$6$$$^$;$s$,!"Aw?.e$2$^$9!#=1B(B

PLEASE READ :This e-mail is confidential and intended for the named recipie=
nt only.
If you are not an intended recipient, please notify the sender and delete t=
his e-mail.

________________________________
=1B$B:9=3DP?M=1B(B: Torsten Lodderstedt 
=1B$BAw?.F|;~=1B(B: =1B$B?eMKF|=1B(B, 11=1B$B7n=1B(B 28, 2018 11:38 =1B$B8a=
8e=1B(B
=1B$B08@h=1B(B: n-sakimura
Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
=1B$B7oL>=1B(B: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza=
tion code instead of implicit

Hi Nat,

Am 28.11.2018 um 21:10 schrieb n-sakimura >:

I would support

1) clearly defining Implicit as the flow that returns access token from the=
 authorization endpoint ( some people confuses implicit as the flow that re=
turns ID Token in the front channel)

That=1B$B!G=1B(Bs the current text:

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

What would you like to modify?


2) Banning the returning of the access token that are not sender constraine=
d from the authorization endpoint

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response, if this access toke=
ns is not sender-constraint.

What about this?

kind regards,
Torsten.


Best,

Nat


Outlook for iOS =1B$B$rF~> (Dick Hardt > =1B$=
B$NBeM}=1B(B)
=1B$BAw?.F|;~=1B(B: =1B$B?eMKF|=1B(B, 11=1B$B7n=1B(B 28, 2018 8:58 =1B$B8a8=
e=1B(B
=1B$B08@h=1B(B: Hannes Tschofenig
Cc: oauth@ietf.org
=1B$B7oL>=1B(B: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza=
tion code instead of implicit

+1

While there are various mechanisms to alleviate some of the issues of impli=
cit, I don't think we can recommend specifics, and there may be future ones=
 in the future. I think we all agree that implicit without any mitigation i=
s problematic.

How about we recommend against using implicit alone?


On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig > wrote:
Hi all,

The authors of the OAuth Security Topics draft came to the conclusion that =
it is not possible to adequately secure the implicit flow against token inj=
ection since potential solutions like token binding or JARM are in an early=
 stage of adoption. For this reason, and since CORS allows browser-based ap=
ps to send requests to the token endpoint, Torsten suggested to use the aut=
horization code instead of the implicit grant in call cases in his presenta=
tion (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oau=
th-sessb-draft-ietf-oauth-security-topics-01).

A hum in the room at IETF#103 concluded strong support for his recommendati=
ons. We would like to confirm the discussion on the list.

Please provide a response by December 3rd.

Ciao

Hannes & Rifaat



IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.
_______________________________________________
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


--_000_OSBPR01MB28690F77DFFB2A85BDB83FBAF9D10OSBPR01MB2869jpnp_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable







    

    

    

    That works. 
    


    

    

    In fact, I would further go and say MUST NOT=
 but that probably is too much for a security consideration.

    


    

    

    Best, 
    


    

    

    Nat
    

    


    

    

    

    Nat Sakimura / n-sakimura@nri.co.jp / +8=
1-90-6013-6276
    


    

    

    =1B$B$3$N%a!<%k$K$O!"K\Mh$N08@h$NJ}$N$_$K8BD=
j$5$l$?5!L)>pJs$,4^$^$l$F$$$k>l9g$,$4$6$$$^$9!#$*?4$"$?$j$N$J$$>l9g$O!"@?$K=
?=3D$7Lu$4$6$$$^$;$s$,!"Aw?.e$2$^$9!#=1B(B
    


    

    

    PLEASE READ :This e-mail is confidential and=
 intended for the named recipient only.
    

    If you are not an intended recipient, please=
 notify the sender and delete this e-mail.

    

    

    

     
    

    

    =1B$B:9=3DP?M=
=1B(B: Torsten Lodderstedt <torsten@lodderstedt.net>
    
=1B$BAw?.F|;~=1B(B: =1B$B?eMKF|=1B(B, 11=1B$B7n=1B(B 28, 2018 11:38 =
=1B$B8a8e=1B(B
    
=1B$B08@h=1B(B: n-sakimura
    
Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
    
=1B$B7oL>=1B(B: Re: [OAUTH-WG] OAuth Security Topics -- Recommend au=
thorization code instead of implicit

     
    

    

Hi Nat, 
    

    

    Am 28.11.2018 um 21:10 schrieb n-sakim=
ura <n-sakimura@nri.c=
o.jp>:
    

    
I would support
    

    
1) clearly defining Implicit as the flow that returns access token from the=
 authorization endpoint ( some people confuses implicit as the flow th=
at returns ID Token in the front channel)
    

    


    

    

    That=1B$B!G=1B(Bs the current text: 
    


    

    

    In order to avoid these issues, Clients SHOULD NOT use the =
implicit
    

       grant or any other response type causing the a=
uthorization server to
    

       issue an access token in the authorization res=
ponse.
    


    

    

    What would you like to modify? 
    


    

    


    
2) Banning the returning of the access token that are not sender constraine=
d from the authorization endpoint
    

    


    

    
In order to avoid these issues, Clients SHOULD NOT use the implicit
    
   grant or any other response type causing the authorization ser=
ver to
    
   issue an access token in the authorization response, if this access tokens is not sender-constraint.


    

    

    What about this?
    


    

    

    kind regards,
    

    Torsten.
    


    


    
Best,
    

    
Nat
    

    

    
Outlook for iOS =1B$B$rF~
 
    
=1B$B:9=3DP?M=1B(B: OAuth <oauth-bounces@ietf.org> (Dick Hardt <dick.hardt@gmail.com> =1B$B$NBeM=
}=1B(B)
    
=1B$BAw?.F|;~=1B(B: =1B$B?eMKF|=1B(B, 11=1B$B7n=1B(B 28, 2018 8:58 =1B=
$B8a8e=1B(B
    
=1B$B08@h=1B(B: Hannes Tschofenig
    
Cc: oauth@ietf.org
=1B$B7oL>=1B(B: Re: [OAUTH-WG] OAuth Security Topics -- Recommend auth=
orization code instead of implicit
    
 
    
+1
    

    
While there are various mechanisms to alleviate some of the issues of impli=
cit, I don't think we can recommend specifics, and there may be future=
 ones in the future. I think we all agree that implicit without any mitigat=
ion is problematic. 
    

    
How about we recommend against using implicit alone? 
    

    

    
On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:=

    
Hi all,
    

    
The authors of the OAuth Security Topics draft came to the conclusion that =
it is not possible to adequately secure the implicit flow against toke=
n injection since potential solutions like token binding or JARM are i=
n an early stage of adoption. For this reason,
 and since CORS allows browser-based apps to send requests to the toke=
n endpoint, Torsten suggested to use the authorization code instead of=
 the implicit grant in call cases in his presentation (see https://dat=
atracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-o=
auth-security-topics-01).
    

    
A hum in the room at IETF#103 concluded strong support for his recommendati=
ons. We would like to confirm the discussion on the list.
    

    
Please provide a response by December 3rd.
    

    
Ciao
    

    
Hannes & Rifaat
    

    
 
    

    
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipie=
nt, please notify the sender immediately and do not disclose the contents t=
o any other person, use it for any purpose, or
 store or copy the information in any medium. Thank you.
    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    

    

    

    

    



--_000_OSBPR01MB28690F77DFFB2A85BDB83FBAF9D10OSBPR01MB2869jpnp_--


From nobody Wed Nov 28 15:03:40 2018
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 29778131063 for ; Wed, 28 Nov 2018 15:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 QlbrQa9Cxp4B for ; Wed, 28 Nov 2018 15:03:34 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) (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 76EAF131056 for ; Wed, 28 Nov 2018 15:03:34 -0800 (PST)
Received: from [84.175.172.56] (helo=torstens-mbp.speedport_w_921v_1_44_000) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gS8rj-0003lT-0h; Thu, 29 Nov 2018 00:03:31 +0100
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_FBE7783C-CB7E-4042-A505-B31FD1E3603B"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Thu, 29 Nov 2018 00:03:27 +0100
In-Reply-To: 
Cc: Dick Hardt , Hannes Tschofenig , "oauth@ietf.org" 
To: n-sakimura 
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> 
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 23:03:39 -0000

--Apple-Mail=_FBE7783C-CB7E-4042-A505-B31FD1E3603B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> Am 28.11.2018 um 23:50 schrieb n-sakimura :
>=20
> That works.

Good!

I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C =
(only). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token =
would sender constrained. This completely ignores the fact implicit also =
shall be abandoned because of its vulnerability for access token =
injection.=20

I therefore propose a modified text:=20

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant. Furthermore, clients SHOULD only use other response types =
causing the authorization server to
   issue an access token in the authorization response, if the =
particular response type detects access token=20
   injection and the issued access tokens are sender-constrained.

Or we just state:

  In order to avoid these issues, Clients SHOULD NOT use the response =
type =E2=80=9Etoken". The response types
=E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=9C=
 SOULD NOT be used, if the issued access tokens are not=20
sender-constrained.

>=20
> In fact, I would further go and say MUST NOT but that probably is too =
much for a security consideration.
>=20

Mike suggested to go with a SHOULD NOT to get the message out but give =
implementors time to move/change.

> Best,
>=20
> Nat
>=20
> Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>=20
> =
=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6=
=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81=
=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=
=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=
=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=
=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=
=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3=
=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81=
=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5=
=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4=
=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89=
=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=
=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=
=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>=20
> PLEASE READ :This e-mail is confidential and intended for the named =
recipient only.
> If you are not an intended recipient, please notify the sender and =
delete this e-mail.
> =20
> =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt =

> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> =E5=AE=9B=E5=85=88: n-sakimura
> Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
> =20
> Hi Nat,=20
>=20
>> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>>=20
>> I would support
>>=20
>> 1) clearly defining Implicit as the flow that returns access token =
from the authorization endpoint ( some people confuses implicit as the =
flow that returns ID Token in the front channel)
>=20
> That=E2=80=99s the current text:=20
>=20
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant or any other response type causing the authorization server =
to
>    issue an access token in the authorization response.
>=20
> What would you like to modify?=20
>=20
>>=20
>> 2) Banning the returning of the access token that are not sender =
constrained from the authorization endpoint
>=20
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant or any other response type causing the authorization server =
to
>    issue an access token in the authorization response, if this access =
tokens is not sender-constraint.
>=20
> What about this?
>=20
> kind regards,
> Torsten.
>=20
>>=20
>> Best,
>>=20
>> Nat
>>=20
>>=20
>> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>> =20
>> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick =
Hardt  =E3=81=AE=E4=BB=A3=E7=90=86)
>> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>> Cc: oauth@ietf.org
>> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
>> =20
>> +1
>>=20
>> While there are various mechanisms to alleviate some of the issues of =
implicit, I don't think we can recommend specifics, and there may be =
future ones in the future. I think we all agree that implicit without =
any mitigation is problematic.=20
>>=20
>> How about we recommend against using implicit alone?=20
>>=20
>>=20
>> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig =
 wrote:
>> Hi all,
>>=20
>> The authors of the OAuth Security Topics draft came to the conclusion =
that it is not possible to adequately secure the implicit flow against =
token injection since potential solutions like token binding or JARM are =
in an early stage of adoption. For this reason, and since CORS allows =
browser-based apps to send requests to the token endpoint, Torsten =
suggested to use the authorization code instead of the implicit grant in =
call cases in his presentation (see =
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-=
draft-ietf-oauth-security-topics-01).
>>=20
>> A hum in the room at IETF#103 concluded strong support for his =
recommendations. We would like to confirm the discussion on the list.
>>=20
>> Please provide a response by December 3rd.
>>=20
>> Ciao
>>=20
>> Hannes & Rifaat
>>=20
>> =20
>>=20
>> IMPORTANT NOTICE: The contents of this email and any attachments are =
confidential and may also be privileged. If you are not the intended =
recipient, please 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.
>> _______________________________________________
>> 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


--Apple-Mail=_FBE7783C-CB7E-4042-A505-B31FD1E3603B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjgyMzAzMjdaMC8GCSqGSIb3DQEJBDEiBCA6
mMIZfHWwuNb39lM/AxoUcF8XvVxvgRT/w5e24Y/d9jCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEADxHsonKPUm+OWgm0+bYqz1vJ
c1HOD27gHfOuRPcyhMQ8ul42xNtzAnXGJAbmcvv22fIm3MWfm6Q4HY+7uPzlsdXZwbkazhKueIih
GwBhrVEE5T6lNFIseWXmMWtlKCNfh0n0irvCkwCJUXw/pbCIVItl5ycM/P8FEy6OnvWG1yFB3PCy
+DfJ8TKB3srDm2/6OZ32Ie7gtumYc8QKfAPFUG7M05l+znmi14vWPU9kJHTzwpnzAT4GD9IClemJ
XrSRu5W7neGHWDPINkNCzlKxBti9FJ/3vKZ0CoMCMureXqb8XPhR9zBejzaAq3khjDdx+fpV9zM1
SRiz0xub55BSnAAAAAAAAA==
--Apple-Mail=_FBE7783C-CB7E-4042-A505-B31FD1E3603B--


From nobody Wed Nov 28 15:16:31 2018
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 6E326131056 for ; Wed, 28 Nov 2018 15:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.958
X-Spam-Level: 
X-Spam-Status: No, score=-18.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLA-KO-9RqrH for ; Wed, 28 Nov 2018 15:16:26 -0800 (PST)
Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3971277C8 for ; Wed, 28 Nov 2018 15:16:26 -0800 (PST)
Received: by mail-it1-x12a.google.com with SMTP id p197so717004itp.0 for ; Wed, 28 Nov 2018 15:16:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SwPYxmeb9EY8U8K6iXHcmeyjYcqHRPk/YW5TWzdR/c0=; b=B+Uc6GQmgs4zf1F9Aen/d3MjlHEzVaAFd3hYn2woFjMTHvH9eDURVWvEW4Z3rjwrtV rIB55oAl5yrBteGQsz/Gi9KjQsWRToEwjsy1/jGiAJFHpMe9H2iAyTQ4leDl4DYkz0Zu bBux+KXKEgJyv23cqa7K36s3MzCJgRD7X4SeF+gMTpvVV2efzz4C5i2fG6hCQy9AlI0x dLAqkdMj37weZj28Tj86UptryCEmtoJlrSICPGSPNu5aIlwRhdEen3wiXtj48seTQCkF aSTetQD2krWiG+snLuKxqWheekamkpB5Dde/CxEcJLhJYr+2VbE79sscL3SShe0Plpf4 PLZw==
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=SwPYxmeb9EY8U8K6iXHcmeyjYcqHRPk/YW5TWzdR/c0=; b=Ah7awkdpLvhU0CRCLYNw4v8tWjkbXiNRghyyYHh/J7zu+lQtaiB//RFrPRSnOiFKjG RhO2C+uS+/FawRZA2kcFuM2B0ewPqQYZjWxZcGDDmSo5F/6S7l7TES7dW2NkThqgt8aS /5tf8QgEHAiVhKisApTDw7WUFQ5I88Dw7Bv5CXGdFcbCG8hYF0YWm2URjSioIpFdwobp sWzsDhDNlMegBPv93sLqfpZLynQAkMvO14VJIWRalYq8gi7z24dyl3rw29AG+LH0BbtN Dm4CWW/HnvHrFHzZnlp78TRzv2dFPLM/mNh5ux594gMaD3lfL4JkCUmXmgKKvDa4em3v YtJQ==
X-Gm-Message-State: AA+aEWZnA+9mHj4kNQSEChkpGmIy1BU6bll7wVJsqKifMeJIrpoZ7xVt GRYnE0M1GdIKNEz32wJnJd0Q+4j5Hug/51hd8Hz6XvR0W8Lysw==
X-Google-Smtp-Source: AFSGD/XAcLF5cozZfuTYkQBXbbmYxUaDbQYCbJnXQAiizggS+aHZRiEbujFbk8F0nCfOHneOnehwsz0eJYUTGLIwdHk=
X-Received: by 2002:a24:97c3:: with SMTP id k186mr5169820ite.125.1543446985324;  Wed, 28 Nov 2018 15:16:25 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> 
In-Reply-To: 
From: William Denniss 
Date: Wed, 28 Nov 2018 15:16:13 -0800
Message-ID: 
To: Nat Sakimura 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="0000000000004ac31a057bc1c1f8"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 23:16:30 -0000

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

On Wed, Nov 28, 2018 at 2:51 PM n-sakimura  wrote:

> That works.
>
> In fact, I would further go and say MUST NOT but that probably is too muc=
h
> for a security consideration.
>
>
Personally I think it's fine for a MUST NOT to appear in a security
consideration section of a BCP. If you break it, then you're not following
the BCP.

We did exactly this in BCP 212:

"This best current
   practice requires that native apps MUST NOT use embedded user-agents
   to perform authorization requests
"

William

Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>
>
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>
> PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> If you are not an intended recipient, please notify the sender and delete
> this e-mail.
>
> ------------------------------
> *=E5=B7=AE=E5=87=BA=E4=BA=BA:* Torsten Lodderstedt 
> *=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82:* =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> *=E5=AE=9B=E5=85=88:* n-sakimura
> *Cc:* Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> *=E4=BB=B6=E5=90=8D:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend a=
uthorization
> code instead of implicit
>
> Hi Nat,
>
> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>
> I would support
>
> 1) clearly defining Implicit as the flow that returns access token from
> the authorization endpoint ( some people confuses implicit as the flow th=
at
> returns ID Token in the front channel)
>
>
> That=E2=80=99s the current text:
>
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant or any other response type causing the authorization server to
>    issue an access token in the authorization response.
>
> What would you like to modify?
>
>
> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
>
>
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant or any other response type causing the authorization server to
>    issue an access token in the authorization response*, if this access
> tokens is not sender-constraint.*
>
> What about this?
>
> kind regards,
> Torsten.
>
>
> Best,
>
> Nat
>
>
> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>
> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Hardt <=
dick.hardt@gmail.com>
> =E3=81=AE=E4=BB=A3=E7=90=86)
> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=E6=
=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> Cc: oauth@ietf.org
> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend aut=
horization code
> instead of implicit
>
> +1
>
> While there are various mechanisms to alleviate some of the issues of
> implicit, I don't think we can recommend specifics, and there may be futu=
re
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
>
> How about we recommend against using implicit alone?
>
>
> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion tha=
t
> it is not possible to adequately secure the implicit flow against token
> injection since potential solutions like token binding or JARM are in an
> early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
> ).
>
> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
>
> Hannes & Rifaat
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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




    On Wed, Nov 28, 2018 at 2:51 PM n-sakimura <n-sakimura@nri.co.jp> wrote:
    




    

    

    

    

    That works. 
    


    

    

    In fact, I would further go and say MUST NOT b=
ut that probably is too much for a security consideration.

    



    Per=
sonally I think it's fine for a MUST NOT to appear in a security consid=
eration section of a BCP. If you break it, then you're not following th=
e BCP.=C2=A0

    We did exactly this in BCP 212:
    =


    "This best current
    =C2=A0 =C2=A0pra=
ctice requires that native apps MUST NOT use embedded user-agents
    =C2=A0 =C2=A0to perform authorization requests
    "
    =C2=A0
    William

    Nat Sakimura /=
 n-sakimura@nri.c=
o.jp / +81-90-6013-6276
    


    

    

    =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=
=E3=81=AB=E3=81=AF=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=
=81=AE=E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=
=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=
=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=
=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=
=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=
=E8=AA=A0=E3=81=AB=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=
=BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=
=E3=81=BE=E3=81=9F=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=
=83=BC=E3=83=AB=E3=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=
=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=
=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82


    

    

    PLEASE READ :This e-mail is confidential and i=
ntended for the named recipient only.
    

    If you are not an intended recipient, please n=
otify the sender and delete this e-mail.

    

    

    

    =C2=A0
    

    

    =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt=
.net>
    
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
=E5=AE=9B=E5=85=88: n-sakimura
    
Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
    
=E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization code instead of implicit

    =C2=A0
    

    

Hi Nat,=C2=A0
    

    

    Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp=
>:
    

    
I would support
    

    
1) clearly defining Implicit as the flow that returns access token from the=
 authorization endpoint ( some people confuses implicit as the=C2=A0flow th=
at returns ID Token in the front channel)
    

    


    

    

    That=E2=80=99s the current text:=C2=A0
    


    

    

    In order to avoid these issues, Clients SHOULD NOT use the implicit

    =C2=A0 =C2=A0grant or any other response type causing the authorizatio=
n server to
    

    =C2=A0 =C2=A0issue an access token in the authorization response.


    

    

    What would you like to modify?=C2=A0
    


    

    


    
2) Banning the returning of the access token that are not sender constraine=
d from the authorization endpoint
    

    


    

    
In order to avoid these issues, Clients SHOULD NOT use the implicit
    
=C2=A0 =C2=A0grant or any other response type causing the authorization ser=
ver to
    
=C2=A0 =C2=A0issue an access token in the authorization response, if thi=
s access tokens is not sender-constraint.


    

    

    What about this?
    


    

    

    kind regards,
    

    Torsten.
    


    


    
Best,
    

    
Nat
    

    

    
Outlook for iOS=C2=A0=E3=82=92=E5=85=A5=E6=89=8B
    
=C2=A0
    
=E5=B7=AE=E5=87=BA=E4=BA=BA:=C2=A0OAuth <oauth-bounces@ietf.org> (Dick Hardt <=
;dick.hardt@gmail=
.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82:=C2=A0=E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
=E5=AE=9B=E5=85=88:=C2=A0Hannes Tschofenig
    
Cc:=C2=A0oauth@ietf.org=

    
=E4=BB=B6=E5=90=8D:=C2=A0Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
    
=C2=A0
    
+1
    

    
While there are various mechanisms to alleviate some of the issues of impli=
cit, I don't think we can recommend specifics, and there may=C2=A0be fu=
ture ones in the future. I think we all agree that implicit without any mit=
igation is problematic.=C2=A0
    

    
How about we recommend against using implicit alone?=C2=A0
    

    

    
On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>=
 wrote:
    
Hi all,
    

    
The authors of the OAuth Security Topics draft came to the conclusion that =
it is not possible to adequately secure the implicit flow=C2=A0against toke=
n injection since potential solutions like token binding or JARM are=C2=A0i=
n an early stage of adoption. For this reason,
 and=C2=A0since CORS allows browser-based apps to send requests to the toke=
n endpoint, Torsten suggested to use the authorization code=C2=A0instead of=
 the implicit grant in call cases in his presentation (see=C2=A0https://datatracker.i=
etf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-secur=
ity-topics-01).
    

    
A hum in the room at IETF#103 concluded strong support for his recommendati=
ons. We would like to confirm the discussion on the=C2=A0list.
    

    
Please provide a response by December 3rd.
    

    
Ciao
    

    
Hannes & Rifaat
    

    
=C2=A0
    

    
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the=C2=A0intended recipie=
nt, please notify the sender immediately and do not disclose the contents t=
o any other person, use it for any purpose,=C2=A0or
 store or copy the information in any medium. Thank you.
    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
h=
ttps://www.ietf.org/mailman/listinfo/oauth
    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
h=
ttps://www.ietf.org/mailman/listinfo/oauth
    

    

    

    

    

    

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

    

--0000000000004ac31a057bc1c1f8--


From nobody Wed Nov 28 15:33:53 2018
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 BB962131095 for ; Wed, 28 Nov 2018 15:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level: 
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 5RsqvnaH97Qd for ; Wed, 28 Nov 2018 15:33:49 -0800 (PST)
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 BC15213109A for ; Wed, 28 Nov 2018 15:33:48 -0800 (PST)
Received: by mail-wm1-f50.google.com with SMTP id s14so404674wmh.1 for ; Wed, 28 Nov 2018 15:33:48 -0800 (PST)
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=ncedDVhsjxNzrR0SFwPptlVe4TeNXY6DUqViaKuAdJo=; b=bKPAnMxyQpSv8cJCAoFgYpHcOrZ2yBPWst2b34LHIDm5pDOzc90IpeOyHiISHBq+k9 0vdLL47DciGJLbxkRAOrwBDatModkbRe6t62Oo/9sfs4L2an5MrjmLVllPul5SFXCdg+ zUCjkVzGBkG4JRD0czRgBo9Kc74emvZrc86MzgZURcmZ3UpYx8ukCZv34MVKemWfGr8o R1f9kTnffEpYrMOvehd347/RaQTgpghhlzURGOr62Z8r7D+y1PvcXTkuYLXZnzRkk2Ht Ak3Nwe3tUqy5nOLZPNg6YRYYscc7HGDi6U784+Oigmu+tA9COknQmwGMEKhqD5BovN99 gNEw==
X-Gm-Message-State: AA+aEWY0tFADV/1Y2B8vJ7mKt+3RTwiboRMLBxh9jDaGjLzDxU/Ty7T+ 4kBTg7ybDZ5PQgcjSIb0/5poaiTnuGMy9UAGpZv5hdlm
X-Google-Smtp-Source: AFSGD/VavCkEG4pqSDgzNMnfbYUGUBbsEWwi0jWjdWq5xXa9c4dqjMT6kkD2k3vRWaAmVqdinwDWeKjQevFESqYkQcg=
X-Received: by 2002:a1c:164a:: with SMTP id 71mr4370531wmw.126.1543448026815;  Wed, 28 Nov 2018 15:33:46 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>  
In-Reply-To: 
From: Nat Sakimura 
Date: Thu, 29 Nov 2018 00:33:34 +0100
Message-ID: 
To: Torsten Lodderstedt 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005e2239057bc1fff9"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 28 Nov 2018 23:33:52 -0000

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

Inline:

2018=E5=B9=B411=E6=9C=8829=E6=97=A5(=E6=9C=A8) 0:03 Torsten Lodderstedt :

>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (only=
). It would allow
> =E2=80=9Etoken=E2=80=9C to be used if the token would sender constrained.=
 This completely
> ignores the fact implicit also shall be abandoned because of its
> vulnerability for access token injection.
>
> I therefore propose a modified text:
>
>    In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant. Furthermore, clients SHOULD only use other response types
> causing the authorization server to
>    issue an access token in the authorization response, if the particular
> response type detects access token
>    injection and the issued access tokens are sender-constrained.


A friendly amendment.

In order to avoid these issues, clients SHOULD NOT return access token in
the authorization response unless the particular response type detects
access token injection and the issued access tokens are sender-constrained.



>
> Or we just state:
>
>   In order to avoid these issues, Clients SHOULD NOT use the response typ=
e
> =E2=80=9Etoken". The response types
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the
> issued access tokens are not
> sender-constrained.


This one looks on the surface but as John points out, it misses out the
cases where response types are expanded.


>
> >
> > In fact, I would further go and say MUST NOT but that probably is too
> much for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give
> implementors time to move/change.


As William says, I actually advocate MUST NOT but OK with SHOULD NOT as
well.

>
>
> > Best,
> >
> > Nat
> >
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> >
> >
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> >
> > PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> > If you are not an intended recipient, please notify the sender and
> delete this e-mail.
> >
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > =E5=AE=9B=E5=85=88: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend a=
uthorization code
> instead of implicit
> >
> > Hi Nat,
> >
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> >>
> >> I would support
> >>
> >> 1) clearly defining Implicit as the flow that returns access token fro=
m
> the authorization endpoint ( some people confuses implicit as the flow th=
at
> returns ID Token in the front channel)
> >
> > That=E2=80=99s the current text:
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server to
> >    issue an access token in the authorization response.
> >
> > What would you like to modify?
> >
> >>
> >> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server to
> >    issue an access token in the authorization response, if this access
> tokens is not sender-constraint.
> >
> > What about this?
> >
> > kind regards,
> > Torsten.
> >
> >>
> >> Best,
> >>
> >> Nat
> >>
> >>
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> >>
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Hard=
t 
> =E3=81=AE=E4=BB=A3=E7=90=86)
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> >> Cc: oauth@ietf.org
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization
> code instead of implicit
> >>
> >> +1
> >>
> >> While there are various mechanisms to alleviate some of the issues of
> implicit, I don't think we can recommend specifics, and there may be futu=
re
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
> >>
> >> How about we recommend against using implicit alone?
> >>
> >>
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> >> Hi all,
> >>
> >> The authors of the OAuth Security Topics draft came to the conclusion
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM are =
in
> an early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
> ).
> >>
> >> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> >>
> >> Please provide a response by December 3rd.
> >>
> >> Ciao
> >>
> >> Hannes & Rifaat
> >>
> >>
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

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


    Inline:=C2=A0

    2018=E5=B9=B411=E6=9C=8829=E6=97=A5(=E6=9C=A8) 0:=
03 Torsten Lodderstedt <torst=
en@lodderstedt.net>:

    
> Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> 
    
> That works.
    

    
Good!
    

    
I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (only).=
 It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would sende=
r constrained. This completely ignores the fact implicit also shall be aban=
doned because of its vulnerability for access token injection. 
    

    
I therefore propose a modified text: 
    

    
=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the imp=
licit
    
=C2=A0 =C2=A0grant. Furthermore, clients SHOULD only use other response typ=
es causing the authorization server to
    
=C2=A0 =C2=A0issue an access token in the authorization response, if the pa=
rticular response type detects access token 
    
=C2=A0 =C2=A0injection and the issued access tokens are sender-constrained.=


    A friendly amend=
ment.=C2=A0

    In order to =
avoid these issues, clients SHOULD NOT return access token in the authoriza=
tion response unless the particular response type detects access token inje=
ction and the issued access tokens are sender-constrained.=C2=A0



    

    
Or we just state:
    

    
=C2=A0 In order to avoid these issues, Clients SHOULD NOT use the response =
type =E2=80=9Etoken". The response types
    
=E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=9C =
SOULD NOT be used, if the issued access tokens are not 
    
sender-constrained.

    This one looks on the surface but as John points out, it misses out the =
cases where response types are expanded.=C2=A0

    <=
/div>

    

    
> 
    
> In fact, I would further go and say MUST NOT but that probably is too =
much for a security consideration.
    
> 
    

    
Mike suggested to go with a SHOULD NOT to get the message out but give impl=
ementors time to move/change.

    As William says, I actually advocate MUST NOT but OK with SHOU=
LD NOT as well.=C2=A0

    

    
> Best,
    
> 
    
> Nat
    
> 
    
> Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> 
    
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=
=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=
=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=
=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=
=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=
=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=
=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=
=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=
=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=
=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=
=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=
=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=
=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=
=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> 
    
> PLEASE READ :This e-mail is confidential and intended for the named re=
cipient only.
    
> If you are not an intended recipient, please notify the sender and del=
ete this e-mail.
    
>=C2=A0 
    
> =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>=

    
> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> =E5=AE=9B=E5=85=88: n-sakimura
    
> Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
    
> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
    
>=C2=A0 
    
> Hi Nat, 
    
> 
    
>> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
>> 
    
>> I would support
    
>> 
    
>> 1) clearly defining Implicit as the flow that returns access token=
 from the authorization endpoint ( some people confuses implicit as the flo=
w that returns ID Token in the front channel)
    
> 
    
> That=E2=80=99s the current text: 
    
> 
    
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>=C2=A0 =C2=A0 grant or any other response type causing the authorizatio=
n server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response.
    
> 
    
> What would you like to modify? 
    
> 
    
>> 
    
>> 2) Banning the returning of the access token that are not sender c=
onstrained from the authorization endpoint
    
> 
    
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>=C2=A0 =C2=A0 grant or any other response type causing the authorizatio=
n server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
his access tokens is not sender-constraint.
    
> 
    
> What about this?
    
> 
    
> kind regards,
    
> Torsten.
    
> 
    
>> 
    
>> Best,
    
>> 
    
>> Nat
    
>> 
    
>> 
    
>> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
>>=C2=A0 
    
>> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick Hardt=
 <dick.hardt@g=
mail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
>> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,=
 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
>> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
>> Cc: oauth@ietf=
.org
    
>> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm=
end authorization code instead of implicit
    
>>=C2=A0 
    
>> +1
    
>> 
    
>> While there are various mechanisms to alleviate some of the issues=
 of implicit, I don't think we can recommend specifics, and there may b=
e future ones in the future. I think we all agree that implicit without any=
 mitigation is problematic. 
    
>> 
    
>> How about we recommend against using implicit alone? 
    
>> 
    
>> 
    
>> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.co=
m> wrote:
    
>> Hi all,
    
>> 
    
>> The authors of the OAuth Security Topics draft came to the conclus=
ion that it is not possible to adequately secure the implicit flow against =
token injection since potential solutions like token binding or JARM are in=
 an early stage of adoption. For this reason, and since CORS allows browser=
-based apps to send requests to the token endpoint, Torsten suggested to us=
e the authorization code instead of the implicit grant in call cases in his=
 presentation (see https://datatracker.ietf.org/meeting/103/materi=
als/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
    
>> 
    
>> A hum in the room at IETF#103 concluded strong support for his rec=
ommendations. We would like to confirm the discussion on the list.
    
>> 
    
>> Please provide a response by December 3rd.
    
>> 
    
>> Ciao
    
>> 
    
>> Hannes & Rifaat
    
>> 
    
>>=C2=A0 
    
>> 
    
>> IMPORTANT NOTICE: The contents of this email and any attachments a=
re confidential and may also be privileged. If you are not the intended rec=
ipient, please notify the sender immediately and do not disclose the conten=
ts to any other person, use it for any purpose, or store or copy the inform=
ation in any medium. Thank you.
    
>> _______________________________________________
    
>> OAuth mailing list
    
>> OAuth@ietf.org=

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

    
>> https://www.ietf.org/mailman/listinfo/oauth<=
br>
> 
    

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

    -- 
    Nat Sakimura (=3Dnat)
    http://www.sakimura.org/en/<=
br>http://twitter.=
com/_nat_en
    

--0000000000005e2239057bc1fff9--


From nobody Wed Nov 28 15:38:56 2018
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 1E9A313103C for ; Wed, 28 Nov 2018 15:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Level: 
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 E_b0L9gt2YuX for ; Wed, 28 Nov 2018 15:38:51 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30537130E1A for ; Wed, 28 Nov 2018 15:38:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1543448331; x=1574984331; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0SNCz05ZqWi72SMhXetkSD250o2dMmIGwIp+mFFyvrQ=; b=e/thcWLW0bgW/MXaUtyRheZb61Es1vD7QwTBfmrJz8ZxKA0BRYO+XvWB CDJZUuj3BDfta2/Vb3NbJPM16Ha+EdT32oIfjADqVhwOgaCdpm8hWxH5m M468Mdup49LYKnR4RfNBD+EnDbMfZpgFoFTD14kul2Hd5vzjk8ZhUTOGd Q=;
X-IronPort-AV: E=Sophos;i="5.56,253,1539648000";  d="scan'208,217";a="773033626"
Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  28 Nov 2018 23:38:48 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id wASNcjER038305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Nov 2018 23:38:46 GMT
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 23:38:44 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 28 Nov 2018 23:38:44 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 28 Nov 2018 23:38:44 +0000
From: "Richard Backman, Annabelle" 
To: Filip Skokan , George Fletcher 
CC: oauth 
Thread-Topic: [OAUTH-WG] Dynamic Client Registration with Native Apps
Thread-Index: AQHUhjXapIsebfMrH0elqz8N/SiwVaVkEwKAgAFD5YCAAARtgIAAEL0AgAAB3wD//+aIAA==
Date: Wed, 28 Nov 2018 23:38:44 +0000
Message-ID: 
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.115]
Content-Type: multipart/alternative; boundary="_000_D6AFB7CEEDBF4309BA0C2A4AAF62D3EAamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 28 Nov 2018 23:38:54 -0000

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

SXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQg4oCcdHJhZGl0aW9uYWzigJ0gY29uZmlkZW50aWFsIGNs
aWVudHMgd2l0aCByZWdpc3RlcmVkIHJldHVybiBVUkxzIGFuZCBzZXJ2ZXItc2lkZSBzZWNyZXRz
IG1heSBwcm92aWRlIGEgaGlnaGVyIGRlZ3JlZSBvZiBjb25maWRlbmNlIGluIHRoZSB0cnVlIGlk
ZW50aXR5IG9mIHRoZSBjbGllbnQgdGhhdCBkb2VzbuKAmXQgY2Fycnkgb3ZlciB0byBjb25maWRl
bnRpYWwgbmF0aXZlIGFwcCBjbGllbnRzLiBBIG5hdGl2ZSBhcHAgaW5zdGFuY2XigJlzIHJlZ2lz
dHJhdGlvbiBjYWxsIGlzIG5lY2Vzc2FyaWx5IHVuYXV0aGVudGljYXRlZCAoZm9yIHRoZSBzYW1l
IHJlYXNvbnMgdGhhdCBzdGF0aWNhbGx5IHJlZ2lzdGVyZWQgbmF0aXZlIGFwcCBjbGllbnRzIGFy
ZSBwdWJsaWMgY2xpZW50cyksIHNvIHRoZSBDbGllbnQgSW1wZXJzb25hdGlvbiBjb25jZXJucyBk
ZXNjcmliZWQgaW4gc2VjdGlvbiA4LjYgb2YgUkZDODI1MjxodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjODI1MiNzZWN0aW9uLTguNj4gc3RpbGwgYXBwbHkuDQotLQ0KQW5uYWJlbGxlIFJp
Y2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBGaWxpcCBTa29rYW4gPHBhbnZhLmlwQGdtYWlsLmNv
bT4NCkRhdGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjgsIDIwMTggYXQgOToxMSBBTQ0KVG86IEdl
b3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5v
cmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24g
d2l0aCBOYXRpdmUgQXBwcw0KDQpBcG9sb2dpZXMsIEkgbWlzc2VkIHRoZSBpc3N1ZWQgaW4gImlz
c3VlZCBhIHNoYXJlZCBzZWNyZXQiLCBqdXN0IHJlYWRpbmcgInNoYXJlZCBzZWNyZXQiIGFsb25l
IGlzIHRoZSBleGFjdCBvcHBvc2l0ZSBvZiBhIHBlci1pbnN0YW5jZSBzZWNyZXQuIFRoZSByZXN0
IGlzIGNsZWFyIGFuZCBhcyB5b3Ugc2F5IGl0IGJyaW5ncyB0aGUgYmVuZWZpdCBvZiB0aGUgc2Vj
cmV0IG5ldmVyIGJlaW5nIHNlbnQgb3ZlciB0aGUgd2lyZSAoZXhjZXB0IGR1cmluZyB0aGUgaW5p
dGlhbCByZWdpc3RyYXRpb24gdmlhIFRMUykuDQoNCkJlc3QsDQpGaWxpcA0KDQoNCk9uIFdlZCwg
Tm92IDI4LCAyMDE4IGF0IDY6MDMgUE0gR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29t
PG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPj4gd3JvdGU6DQpJdCdzICJjb25maWRlbnRpYWwiIGlu
IHRoYXQgdGhlIHNoYXJlZCBzZWNyZXQgaXMgdW5pcXVlIHRvIHRoYXQgYXBwIGluc3RhbmNlIHJl
Z2lzdHJhdGlvbiAoYXMgRGVubmlzIGRlc2NyaWJlZCBpbiBoaXMgcmVzcG9uc2UpLiBJZiBhbiBh
dHRhY2tlciBnZXRzIG15IHBob25lIGFuZCBjb21wcm9taXNlcyB0aGUgZGF0YSBzdG9yZWQgb24g
bXkgZGV2aWNlLCB0aGV5IG9ubHkgZ2V0IHRoZSBzZWNyZXQgZm9yIG15IGRldmljZS4gVGhpcyBp
cyBubyBkaWZmZXJlbnQgdGhhbiBhIHNlcnZlciBzaWRlIGNsaWVudCBoYXZpbmcgdGhlaXIgY2xp
ZW50IHNlY3JldCBjb21wcm9taXNlZCB0aHJvdWdoIGFuIGF0dGFjayAoYW5kIGluIHNvbWUgd2F5
cyBpcyBiZXR0ZXIgYmVjYXVzZSBpdCdzIGluc3RhbmNlIHNwZWNpZmljKS4NCg0KVGhlIG1haW4g
cG9pbnQgSSB3YXMgdHJ5aW5nIHRvIG1ha2UsIGlzIHRoYXQgdGhlICdjbGllbnRfc2VjcmV0X2p3
dCcgbWV0aG9kIGFsbG93cyB0aGUgY2xpZW50IHRvIG5ldmVyIHNlbmQgdGhlIHNoYXJlZCBzZWNy
ZXQgYWNyb3NzIHRoZSB3aXJlIGFzIGlzIGNyZWF0ZWQgaW4gdGhlIGRlZmF1bHQgT0F1dGgyIEhU
VFAgQmFzaWMgQXV0aGVudGljYXRpb24gbWV0aG9kLg0KDQpUaGFua3MsDQpHZW9yZ2UNCk9uIDEx
LzI4LzE4IDExOjAzIEFNLCBGaWxpcCBTa29rYW4gd3JvdGU6DQpIaSBHZW9yZ2UsDQoNCiMyIGRv
ZXNuJ3Qgc2VlbSBjb25maWRlbnRpYWwsIGl0J3Mgc3RpbGwgYSBzZWNyZXQgc2hhcmVkIGFtb25n
c3QgaW5zdGFsbGF0aW9ucyBhbmQgYW55b25lIHJldmVyc2UgZW5naW5lZXJpbmcgdGhlIGFwaywg
ZXh0cmFjdGluZyB0aGUgc2VjcmV0LCBjYW4gZm9ybSB0aGUgY2xpZW50X3NlY3JldF9qd3QgY2xp
ZW50X2Fzc2VydGlvbiB3aXRoIGl0IGp1c3QgZmluZS4NCg0KQmVzdCwNCkZpbGlwDQoNCk9uIFdl
ZCwgTm92IDI4LCAyMDE4IGF0IDQ6NDggUE0gR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFv
bC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdy
b3RlOg0KSW4gYWRkaXRpb24sIGEgZmV3IGFkZGl0aW9uYWwgcGF0dGVybnMgYXJlIGVuYWJsZWQu
Li4NCg0KMS4gVGhlIG5hdGl2ZSBhcHAgY2FuIGdlbmVyYXRlIGEgcHVibGljL3ByaXZhdGUga2V5
IHBhaXIgYW5kIHRoZW4gdXNlIHByaXZhdGVfc2VjcmV0X2p3dCBhcyB0aGUgY2xpZW50IGNyZWRl
bnRpYWwgdmFsaWRhdGlvbiBtZXRob2QgdmlhIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdyAo
ZGVmaW5lZCBpbiBPcGVuSUQgQ29ubmVjdCkuDQoNCjIuIE1heWJlIG1vcmUgc2ltcGx5LCBpZiB0
aGUgbmF0aXZlIGFwcCBpcyBpc3N1ZWQgYSBzaGFyZWQgc2VjcmV0LCB0aGUgYXBwIGNhbiB1c2Ug
Y2xpZW50X3NlY3JldF9qd3QgbWV0aG9kIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gd2hpY2gg
ZW5zdXJlcyB0aGUgc2hhcmVkIHNlY3JldCBuZXZlciBsZWF2ZXMgdGhlIGRldmljZS4gKEFnYWlu
IGRlZmluZWQgaW4gdGhlIE9wZW5JRCBDb25uZWN0IHNwZWMpLg0KDQozLiBPbmNlIHRoZSBuYXRp
dmUgYXBwIGluc3RhbmNlIGhhcyBjcmVkZW50aWFscywgdGhleSBjYW4gYmUgdXNlZCBmb3IgYWRk
aXRpb25hbCBzZWN1cmluZyBvZiBhcHAgQVBJIHRyYW5zYWN0aW9ucyBpbiBhZGRpdGlvbiB0byBq
dXN0IHRoZSBPQXV0aDIvT3BlbklEIENvbm5lY3QgZmxvd3MuDQoNClRoYW5rcywNCkdlb3JnZQ0K
T24gMTEvMjcvMTggMzoyOCBQTSwgV2lsbGlhbSBEZW5uaXNzIHdyb3RlOg0KSWYgdGhlIHNlY3Jl
dCBpcyBkeW5hbWljYWxseSBwcm92aXNpb25lZCB0aGVuIHlvdSBoYXZlIGEgY29uZmlkZW50aWFs
IGNsaWVudC4gQW55b25lIHJldmVyc2UgZW5naW5lZXJpbmcgdGhlaXIgb3duIGluc3RhbGxhdGlv
biBvZiB0aGUgbmF0aXZlIGFwcCB3b3VsZCBvbmx5IGV4dHJhY3QgdGhlaXIgb3duIGNsaWVudCdz
IGNyZWRlbnRpYWxzLCBhcyBvcHBvc2VkIHRvIHRoZSBzaGFyZWQgc2VjcmV0IG9mIGFsbCBpbnN0
YWxsYXRpb25zLiBIYXZpbmcgYSBjb25maWRlbnRpYWwgY2xpZW50IG1lYW5zIHRoYXQgcmVxdWVz
dHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IChjb2RlLCByZWZyZXNoKSBhcmUgY2xpZW50IGF1dGhl
bnRpY2F0ZWQsIHNvIFBLQ0Ugd291bGRuJ3QgYmUgbmVlZGVkLg0KDQpPbiBUdWUsIE5vdiAyNywg
MjAxOCBhdCAxOjQ0IEFNLCBDaHJpc3RpYW4gTWFpbmthIDxDaHJpc3RpYW4uTWFpbmthPTQwcnVi
LmRlQGRtYXJjLmlldGYuLm9yZzxtYWlsdG86Q2hyaXN0aWFuLk1haW5rYT00MHJ1Yi5kZUBkbWFy
Yy5pZXRmLm9yZz4+IHdyb3RlOg0KSGksDQoNCndlIGp1c3Qgc3R1bWJsZWQgdXBvbiB0aGlzIFsx
XSBzdGF0ZW1lbnQ6DQoiRXhjZXB0IHdoZW4gdXNpbmcgYSBtZWNoYW5pc20gbGlrZSBEeW5hbWlj
IENsaWVudCBSZWdpc3RyYXRpb24NCiAgIFtSRkM3NTkxXSB0byBwcm92aXNpb24gcGVyLWluc3Rh
bmNlIHNlY3JldHMsIG5hdGl2ZSBhcHBzIGFyZQ0KICAgY2xhc3NpZmllZCBhcyBwdWJsaWMgY2xp
ZW50cyAuLi4iDQoNCldoYXQgZG9lcyB0aGlzIG1lYW4gZm9yIHVzPyBOYXRpdmUgQXBwICsgRHlu
YW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uID0NCkNvbmZpZGVudGlhbCBDbGllbnQ/DQpXaGljaCB0
aHJlYXRzIGFyZSBjb3ZlcmVkIGlmIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBpcyB1c2Vk
IG9uDQpOYXRpdmUgQXBwcz8NCg0KQmVzdCBSZWdhcmRzLA0KVmxhZGkvQ2hyaXN0aWFuDQoNClsx
XTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgyNTIjc2VjdGlvbi04LjQNCg0KLS0N
CkRyLi1JbmcuIENocmlzdGlhbiBNYWlua2ENCkhvcnN0IEfDtnJ0eiBJbnN0aXR1dGUgZm9yIElU
LVNlY3VyaXR5DQpDaGFpciBmb3IgTmV0d29yayBhbmQgRGF0YSBTZWN1cml0eQ0KUnVoci1Vbml2
ZXJzaXR5IEJvY2h1bSwgR2VybWFueQ0KDQpVbml2ZXJzaXTDpHRzc3RyLiAxNTAsIElEIDIvNDYz
DQpELTQ0ODAxIEJvY2h1bSwgR2VybWFueQ0KDQpUZWxlZm9uOiArNDkgKDApIDIzNCAvIDMyLTI2
Nzk2DQpGYXg6ICs0OSAoMCkgMjM0IC8gMzItMTQzNDcNCmh0dHA6Ly9uZHMucnViLmRlL2NoYWly
L3Blb3BsZS9jbWFpbmthLw0KQENoZWFyaVgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y
ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGgg
bWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy4u
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg
MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN
YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0
IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z
ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z
b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm
b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9y
bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv
bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1M
UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv
cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5
bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx
LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQg4oCcdHJhZGl0aW9uYWzigJ0gY29uZmlkZW50aWFs
IGNsaWVudHMgd2l0aCByZWdpc3RlcmVkIHJldHVybiBVUkxzIGFuZCBzZXJ2ZXItc2lkZSBzZWNy
ZXRzIG1heSBwcm92aWRlIGEgaGlnaGVyIGRlZ3JlZSBvZiBjb25maWRlbmNlIGluIHRoZSB0cnVl
IGlkZW50aXR5IG9mIHRoZSBjbGllbnQgdGhhdCBkb2VzbuKAmXQgY2Fycnkgb3ZlciB0byBjb25m
aWRlbnRpYWwgbmF0aXZlIGFwcA0KIGNsaWVudHMuIEEgbmF0aXZlIGFwcCBpbnN0YW5jZeKAmXMg
cmVnaXN0cmF0aW9uIGNhbGwgaXMgbmVjZXNzYXJpbHkgdW5hdXRoZW50aWNhdGVkIChmb3IgdGhl
IHNhbWUgcmVhc29ucyB0aGF0IHN0YXRpY2FsbHkgcmVnaXN0ZXJlZCBuYXRpdmUgYXBwIGNsaWVu
dHMgYXJlIHB1YmxpYyBjbGllbnRzKSwgc28gdGhlIENsaWVudCBJbXBlcnNvbmF0aW9uIGNvbmNl
cm5zIGRlc2NyaWJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm
YzgyNTIjc2VjdGlvbi04LjYiPnNlY3Rpb24gOC42IG9mIFJGQzgyNTI8L2E+IHN0aWxsIGFwcGx5
LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz
ZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1i
b3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgRmlsaXAgU2tva2FuICZsdDtwYW52YS5p
cEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgTm92ZW1iZXIgMjgs
IDIwMTggYXQgOToxMSBBTTxicj4NCjxiPlRvOiA8L2I+R2VvcmdlIEZsZXRjaGVyICZsdDtnZmZs
ZXRjaEBhb2wuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0O29hdXRoQGlldGYub3Jn
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBS
ZWdpc3RyYXRpb24gd2l0aCBOYXRpdmUgQXBwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+QXBvbG9naWVzLCBJPC9zcGFuPiBtaXNzZWQgdGhlIDxpPg0KaXNzdWVkPC9pPiBp
biAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5p
c3N1ZWQgYSBzaGFyZWQgc2VjcmV0JnF1b3Q7LCBqdXN0IHJlYWRpbmcgJnF1b3Q7c2hhcmVkIHNl
Y3JldCZxdW90OyBhbG9uZSBpcyB0aGUgZXhhY3Qgb3Bwb3NpdGUgb2YgYSBwZXItaW5zdGFuY2Ug
c2VjcmV0LiZuYnNwO1RoZSByZXN0IGlzIGNsZWFyIGFuZCBhcyB5b3Ugc2F5IGl0IGJyaW5ncyB0
aGUgYmVuZWZpdCBvZiB0aGUgc2VjcmV0IG5ldmVyIGJlaW5nIHNlbnQNCiBvdmVyIHRoZSB3aXJl
IChleGNlcHQgZHVyaW5nIHRoZSBpbml0aWFsIHJlZ2lzdHJhdGlvbiB2aWEgVExTKS48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIg
Y2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+QmVzdCw8YnI+DQo8Yj5GaWxpcDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgMjgsIDIwMTggYXQg
NjowMyBQTSBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wu
Y29tIj5nZmZsZXRjaEBhb2wuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij5JdCdzICZxdW90O2NvbmZpZGVudGlhbCZxdW90OyBpbiB0aGF0IHRo
ZSBzaGFyZWQgc2VjcmV0IGlzIHVuaXF1ZSB0byB0aGF0IGFwcCBpbnN0YW5jZSByZWdpc3RyYXRp
b24gKGFzIERlbm5pcyBkZXNjcmliZWQgaW4gaGlzIHJlc3BvbnNlKS4gSWYgYW4gYXR0YWNrZXIg
Z2V0cyBteSBwaG9uZSBhbmQgY29tcHJvbWlzZXMgdGhlIGRhdGEgc3RvcmVkIG9uIG15IGRldmlj
ZSwgdGhleQ0KIG9ubHkgZ2V0IHRoZSBzZWNyZXQgZm9yIG15IGRldmljZS4gVGhpcyBpcyBubyBk
aWZmZXJlbnQgdGhhbiBhIHNlcnZlciBzaWRlIGNsaWVudCBoYXZpbmcgdGhlaXIgY2xpZW50IHNl
Y3JldCBjb21wcm9taXNlZCB0aHJvdWdoIGFuIGF0dGFjayAoYW5kIGluIHNvbWUgd2F5cyBpcyBi
ZXR0ZXIgYmVjYXVzZSBpdCdzIGluc3RhbmNlIHNwZWNpZmljKS48YnI+DQo8YnI+DQpUaGUgbWFp
biBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSwgaXMgdGhhdCB0aGUgJ2NsaWVudF9zZWNyZXRf
and0JyBtZXRob2QgYWxsb3dzIHRoZSBjbGllbnQgdG8gbmV2ZXIgc2VuZCB0aGUgc2hhcmVkIHNl
Y3JldCBhY3Jvc3MgdGhlIHdpcmUgYXMgaXMgY3JlYXRlZCBpbiB0aGUgZGVmYXVsdCBPQXV0aDIg
SFRUUCBCYXNpYyBBdXRoZW50aWNhdGlvbiBtZXRob2QuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4N
Ckdlb3JnZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEx
LzI4LzE4IDExOjAzIEFNLCBGaWxpcCBTa29rYW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBHZW9yZ2UsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiMyIGRvZXNu
J3Qgc2VlbSBjb25maWRlbnRpYWwsIGl0J3Mgc3RpbGwgYSBzZWNyZXQgc2hhcmVkIGFtb25nc3Qg
aW5zdGFsbGF0aW9ucyBhbmQgYW55b25lIHJldmVyc2UgZW5naW5lZXJpbmcgdGhlIGFwaywgZXh0
cmFjdGluZyB0aGUgc2VjcmV0LCBjYW4gZm9ybSB0aGUgY2xpZW50X3NlY3JldF9qd3QgY2xpZW50
X2Fzc2VydGlvbiB3aXRoIGl0IGp1c3QgZmluZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpbGlwPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE5vdiAyOCwgMjAxOCBh
dCA0OjQ4IFBNIEdlb3JnZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2g9PGEgaHJlZj0ibWFpbHRvOjQw
YW9sLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW9sLmNvbUBkbWFyYy5p
ZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+SW4gYWRkaXRpb24sIGEgZmV3
IGFkZGl0aW9uYWwgcGF0dGVybnMgYXJlIGVuYWJsZWQuLi48YnI+DQo8YnI+DQoxLiBUaGUgbmF0
aXZlIGFwcCBjYW4gZ2VuZXJhdGUgYSBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpciBhbmQgdGhlbiB1
c2UgcHJpdmF0ZV9zZWNyZXRfand0IGFzIHRoZSBjbGllbnQgY3JlZGVudGlhbCB2YWxpZGF0aW9u
IG1ldGhvZCB2aWEgdGhlIGNsaWVudCBjcmVkZW50aWFscyBmbG93IChkZWZpbmVkIGluIE9wZW5J
RCBDb25uZWN0KS48YnI+DQo8YnI+DQoyLiBNYXliZSBtb3JlIHNpbXBseSwgaWYgdGhlIG5hdGl2
ZSBhcHAgaXMgaXNzdWVkIGEgc2hhcmVkIHNlY3JldCwgdGhlIGFwcCBjYW4gdXNlIGNsaWVudF9z
ZWNyZXRfand0IG1ldGhvZCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHdoaWNoIGVuc3VyZXMg
dGhlIHNoYXJlZCBzZWNyZXQgbmV2ZXIgbGVhdmVzIHRoZSBkZXZpY2UuIChBZ2FpbiBkZWZpbmVk
IGluIHRoZSBPcGVuSUQgQ29ubmVjdCBzcGVjKS48YnI+DQo8YnI+DQozLiBPbmNlIHRoZSBuYXRp
dmUgYXBwIGluc3RhbmNlIGhhcyBjcmVkZW50aWFscywgdGhleSBjYW4gYmUgdXNlZCBmb3IgYWRk
aXRpb25hbCBzZWN1cmluZyBvZiBhcHAgQVBJIHRyYW5zYWN0aW9ucyBpbiBhZGRpdGlvbiB0byBq
dXN0IHRoZSBPQXV0aDIvT3BlbklEIENvbm5lY3QgZmxvd3MuPGJyPg0KPGJyPg0KVGhhbmtzLDxi
cj4NCkdlb3JnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiAxMS8yNy8xOCAzOjI4IFBNLCBXaWxsaWFtIERlbm5pc3Mgd3JvdGU6PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBzZWNy
ZXQgaXMgZHluYW1pY2FsbHkgcHJvdmlzaW9uZWQgdGhlbiB5b3UgaGF2ZSBhIGNvbmZpZGVudGlh
bCBjbGllbnQuJm5ic3A7QW55b25lIHJldmVyc2UgZW5naW5lZXJpbmcgdGhlaXIgb3duIGluc3Rh
bGxhdGlvbiBvZiB0aGUgbmF0aXZlIGFwcCB3b3VsZCBvbmx5IGV4dHJhY3QgdGhlaXIgb3duIGNs
aWVudCdzIGNyZWRlbnRpYWxzLCBhcyBvcHBvc2VkIHRvIHRoZSBzaGFyZWQgc2VjcmV0IG9mIGFs
bA0KIGluc3RhbGxhdGlvbnMuIEhhdmluZyBhIGNvbmZpZGVudGlhbCBjbGllbnQgbWVhbnMgdGhh
dCByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgKGNvZGUsIHJlZnJlc2gpIGFyZSBjbGll
bnQgYXV0aGVudGljYXRlZCwgc28gUEtDRSB3b3VsZG4ndCBiZSBuZWVkZWQuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiAyNywgMjAxOCBh
dCAxOjQ0IEFNLCBDaHJpc3RpYW4gTWFpbmthICZsdDs8YSBocmVmPSJtYWlsdG86Q2hyaXN0aWFu
Lk1haW5rYT00MHJ1Yi5kZUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdGlh
bi5NYWlua2E9NDBydWIuZGVAZG1hcmMuaWV0Zi4ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJyPg0K
d2UganVzdCBzdHVtYmxlZCB1cG9uIHRoaXMgWzFdIHN0YXRlbWVudDo8YnI+DQomcXVvdDtFeGNl
cHQgd2hlbiB1c2luZyBhIG1lY2hhbmlzbSBsaWtlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlv
bjxicj4NCiZuYnNwOyZuYnNwOyBbUkZDNzU5MV0gdG8gcHJvdmlzaW9uIHBlci1pbnN0YW5jZSBz
ZWNyZXRzLCBuYXRpdmUgYXBwcyBhcmU8YnI+DQombmJzcDsmbmJzcDsgY2xhc3NpZmllZCBhcyBw
dWJsaWMgY2xpZW50cyAuLi4mcXVvdDs8YnI+DQo8YnI+DQpXaGF0IGRvZXMgdGhpcyBtZWFuIGZv
ciB1cz8gTmF0aXZlIEFwcCAmIzQzOyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gPTxicj4N
CkNvbmZpZGVudGlhbCBDbGllbnQ/PGJyPg0KV2hpY2ggdGhyZWF0cyBhcmUgY292ZXJlZCBpZiBE
eW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gaXMgdXNlZCBvbjxicj4NCk5hdGl2ZSBBcHBzPzxi
cj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpWbGFkaS9DaHJpc3RpYW48YnI+DQo8YnI+DQpb
MV06IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MjUyI3NlY3Rpb24t
OC40IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgyNTIj
c2VjdGlvbi04LjQ8L2E+PGJyPg0KPGJyPg0KLS0gPGJyPg0KRHIuLUluZy4gQ2hyaXN0aWFuIE1h
aW5rYTxicj4NCkhvcnN0IEfDtnJ0eiBJbnN0aXR1dGUgZm9yIElULVNlY3VyaXR5IDxicj4NCkNo
YWlyIGZvciBOZXR3b3JrIGFuZCBEYXRhIFNlY3VyaXR5IDxicj4NClJ1aHItVW5pdmVyc2l0eSBC
b2NodW0sIEdlcm1hbnk8YnI+DQo8YnI+DQpVbml2ZXJzaXTDpHRzc3RyLiAxNTAsIElEIDIvNDYz
PGJyPg0KRC00NDgwMSBCb2NodW0sIEdlcm1hbnk8YnI+DQo8YnI+DQpUZWxlZm9uOiAmIzQzOzQ5
ICgwKSAyMzQgLyAzMi0yNjc5Njxicj4NCkZheDogJiM0Mzs0OSAoMCkgMjM0IC8gMzItMTQzNDc8
YnI+DQo8YSBocmVmPSJodHRwOi8vbmRzLnJ1Yi5kZS9jaGFpci9wZW9wbGUvY21haW5rYS8iIHRh
cmdldD0iX2JsYW5rIj5odHRwOi8vbmRzLnJ1Yi5kZS9jaGFpci9wZW9wbGUvY21haW5rYS88L2E+
PGJyPg0KQENoZWFyaVg8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxw
cmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86
cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0
aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0
bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Li5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D6AFB7CEEDBF4309BA0C2A4AAF62D3EAamazoncom_--


From nobody Wed Nov 28 16:20:31 2018
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 183EF129C6A for ; Wed, 28 Nov 2018 16:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Level: 
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 wghEE5xMth0A for ; Wed, 28 Nov 2018 16:20:27 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE29D12426E for ; Wed, 28 Nov 2018 16:20:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1543450827; x=1574986827; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qc+4TCtJZorjRtjKTlNWgq76mD4P6yb1P9nwGdO3ab4=; b=nzcbNo2DecItLOQlkT5hcp1h/wG1KinvqnBySz7qcN9d7jZ4wTh5Cxht SI0F/aw1fX5DHeG7YhT00FAzdXkkyDrUQ/q+GOPvhfa/fSjTzNlHspQty bhMkWDqUk+AiWikYKYvwYzL5OavGY1RxQ9BXdpvsN/KXiROPHLQPcyNQ8 Q=;
X-IronPort-AV: E=Sophos;i="5.56,253,1539648000"; d="scan'208";a="773038629"
Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  29 Nov 2018 00:20:25 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id wAT0KBfR106067 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Nov 2018 00:20:24 GMT
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 00:20:23 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 00:20:23 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 29 Nov 2018 00:20:23 +0000
From: "Richard Backman, Annabelle" 
To: Torsten Lodderstedt , oauth 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
Thread-Index: AQHUgQc3xPB9SU/Gg0Oh5hvfyqkDNaVZDZYAgAAzzICAC8IUAIAAX5iAgAAX2wD//++PgA==
Date: Thu, 29 Nov 2018 00:20:23 +0000
Message-ID: 
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com> <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net>  <1198DA32-4E63-4966-89CA-398478226209@lodderstedt.net>
In-Reply-To: <1198DA32-4E63-4966-89CA-398478226209@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.172]
Content-Type: text/plain; charset="utf-8"
Content-ID: <22BC1197402DD94D9191F6D6AE403BE0@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Nov 2018 00:20:30 -0000

SSB0aGluayB3ZSBuZWVkIHRvIGJlIHZlcnkgY2FyZWZ1bCBhYm91dCBwcmVzY3JpYmluZyBiZWhh
dmlvciBhcm91bmQgcmVmcmVzaCB0b2tlbiBsaWZldGltZSwgYW5kIHNldHRpbmcgZXhwZWN0YXRp
b25zIGZvciB3aGF0IGRlZ3JlZSBvZiBjb25zaXN0ZW5jeSBpcyBhdHRhaW5hYmxlLiBDb25zaWRl
cmluZyB0aGUgdGVybXMgInNlc3Npb24iLCAiYXV0aGVudGljYXRlZCBzZXNzaW9uIiwgIm9mZmxp
bmUiLCAiZXhwaXJhdGlvbiIsICJ0ZXJtaW5hdGlvbiIsIGFuZCAibG9nIG91dCIgY2FuIG1lYW4g
ZGlmZmVyZW50IHRoaW5ncyB0byBkaWZmZXJlbnQgc2VydmljZXMgKGFuZCB0aG9zZSB0aW55IG51
YW5jZXMgbWF0dGVyISkgSSBhbSBhZ2FpbnN0IHRleHQgdGhhdCBtYWtlcyBiaW5kaW5nIHJlZnJl
c2ggdG9rZW5zIHRvIHRoZSBhdXRoZW50aWNhdGVkIHNlc3Npb24gYSAiU0hPVUxELiIgUmF0aGVy
LCB3ZSBzaG91bGQgcmVjb21tZW5kIHRoYXQgdGhlIEFTIHByb3ZpZGUgdGhlIGVuZCB1c2VyIHdp
dGggYSBtZWNoYW5pc20gYnkgd2hpY2ggdGhleSBtYXkgdGVybWluYXRlIHJlZnJlc2ggdG9rZW5z
LiBXZSBjYW4gYWxzbyBkZXNjcmliZSBzZXNzaW9uLWJvdW5kIHJlZnJlc2ggdG9rZW5zIGFzIG9u
ZSBzdWNoIG1ldGhvZCB0aGF0IG1heSBvciBtYXkgbm90IGJlIGFwcHJvcHJpYXRlIGRlcGVuZGlu
ZyBvbiB0aGUgdXNlIGNhc2UuDQoNClRvIGJhY2sgdXAgbXkgY2xhaW0gdGhhdCBjb25zaXN0ZW5j
eSBpcyBIYXJkLCBoZXJlIGFyZSBhIGZldyBzY2VuYXJpb3MgdG8gY29uc2lkZXI6DQoNCjEpDQpB
IG1vYmlsZSBhcHAgbG9hZHMgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpbiBhbiBpbi1hcHAg
YnJvd3NlciB0YWIgdGhhdCBoYXMgYW4gYXBwLXNjb3BlZCBjb29raWUgamFyIGFuZCBpcyBuZXZl
ciBwcmVzZW50ZWQgYnkgdGhlIGFwcCBhZ2FpbiBhZnRlciB0aGUgZmxvdyBpcyBjb21wbGV0ZS4g
SG93IGRvZXMgdGhlIHVzZXIgc2lnbiBvdXQgb2YgdGhhdCBzZXNzaW9uPyBTaG91bGQgdGhlIEFT
IGtpbGwgdGhlIHNlc3Npb24gZHVlIHRvIGluYWN0aXZpdHk/IFdvbid0IHRoYXQgY29uZnVzZSB0
aGUgdXNlciB3aGVuIHN1ZGRlbmx5IHRoZSBpbnRlZ3JhdGlvbiBiZXR3ZWVuIGFwcCBhbmQgc2Vy
dmljZSBzdG9wcyB3b3JraW5nIGZvciBubyBkaXNjZXJuYWJsZSByZWFzb24/IElmIHRoaXMgc2Nl
bmFyaW8gc291bmRzIHVubGlrZWx5LCBpdCdzIG5vdC4gVGhpcyBpcyB0aGUgYmVoYXZpb3Igb2Yg
ZXZlcnkgYXBwIHRoYXQgaW50ZWdyYXRlZCB3aXRoIHRoZSBTYWZhcmkgaW4tYXBwIGJyb3dzZXIg
dGFiIGluIGlPUyA5IGFuZCBuZXZlciB1cGRhdGVkIHRvIHRoZSBhdXRoZW50aWNhdGlvbi1vcmll
bnRlZCByZXBsYWNlbWVudHMgaW50cm9kdWNlZCBsYXRlciwgYXMgd2VsbCBhcyB0aGF0IG9mIGV2
ZXJ5IGFwcCB0aGF0IG9wZW5zIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgaW4gYSB3ZWIgdmll
dyAodWdoKS4NCg0KMikNCkEgbW9iaWxlIGFwcCBsb2FkcyB0aGUgYXV0aG9yaXphdGlvbiByZXF1
ZXN0IGluIHRoZSBleHRlcm5hbCBicm93c2VyLCBidXQgdGhlIHVzZXIgYWx3YXlzIHVzZXMgdGhl
IEFTJ3MgYXBwIG9uIHRoZWlyIGRldmljZSBpbnN0ZWFkIG9mIHZpc2l0aW5nIHRoZWlyIHdlYnNp
dGUgKGUuZy4sIHVzaW5nIHRoZSBHbWFpbCBhcHAgaW5zdGVhZCBvZiBnb2luZyB0byBnbWFpbC5j
b20gaW4gdGhlIGJyb3dzZXIpLCBzbyB0aGVpciBicm93c2VyIHNlc3Npb24gcXVpY2tseSB0aW1l
cyBvdXQgZHVlIHRvIGluYWN0aXZpdHkuIEFnYWluLCB3b24ndCB0aGF0IGNvbmZ1c2UgdGhlIHVz
ZXIgd2hlbiB0aGUgY2xpZW50IG1vYmlsZSBhcHAgc3RvcHMgd29ya2luZz8NCg0KMykNCkEgc2V0
LXRvcCBib3ggdXNlcyB0aGUgZGV2aWNlIGZsb3csIGFuZCB0aGUgdG9rZW5zIGl0IHJlY2VpdmVz
IGFyZSBib3VuZCB0byB0aGUgdXNlcidzIHNlc3Npb24gaW4gdGhlIHdlYiBicm93c2VyIG9uIHRo
ZWlyIGxhcHRvcCwgd2hlcmUgdGhleSBjb21wbGV0ZWQgdGhlIGRldmljZSBmbG93LiBUaGUgdXNl
ciBidXlzIGEgbmV3IGxhcHRvcCwgdGhlaXIgc2Vzc2lvbiBvbiB0aGVpciBvbGQgbGFwdG9wIHRp
bWVzIG91dCBkdWUgdG8gaW5hY3Rpdml0eSwgYW5kIHRoZWlyIHNldC10b3AgYm94IGNhbid0IHN0
cmVhbSB2aWRlb3MgYW55bW9yZS4gwq9cXyjjg4QpXy/Crw0KDQotLSANCkFubmFiZWxsZSBSaWNo
YXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KIA0KDQrvu79PbiAxMS8yOC8xOCwgOToyMCBBTSwg
Ik9BdXRoIG9uIGJlaGFsZiBvZiBUb3JzdGVuIExvZGRlcnN0ZWR0IiA8b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZyBvbiBiZWhhbGYgb2YgdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQog
ICAgDQogICAgDQogICAgPiBBbSAyOC4xMS4yMDE4IHVtIDE2OjUzIHNjaHJpZWIgR2VvcmdlIEZs
ZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPjoNCiAgICA+IA0KICAgID4gT24gMTEvMjgvMTggNTox
MSBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZToNCiAgICA+PiBIaSBHZW9yZ2UsDQogICAg
Pj4gDQogICAgPj4+IEFtIDIwLjExLjIwMTggdW0gMjM6Mzggc2NocmllYiBHZW9yZ2UgRmxldGNo
ZXIgPGdmZmxldGNoQGFvbC5jb20+Og0KICAgID4+PiANCiAgICA+Pj4gVGhhbmtzIGZvciB0aGUg
YWRkaXRpb25hbCBzZWN0aW9uIG9uIHJlZnJlc2hfdG9rZW5zLiBTb21lIGFkZGl0aW9uYWwgcmVj
b21tZW5kYXRpb25zLi4uDQogICAgPj4+IA0KICAgID4+PiAxLiBCeSBkZWZhdWx0IHJlZnJlc2hf
dG9rZW5zIGFyZSBib3VuZCB0byB0aGUgdXNlcidzIGF1dGhlbnRpY2F0ZWQgc2Vzc2lvbi4gV2hl
biB0aGUgYXV0aGVudGljYXRlZCBzZXNzaW9uIGV4cGlyZXMgb3IgaXMgdGVybWluYXRlZCAod2hl
dGhlciBieSB0aGUgdXNlciBvciBmb3Igc29tZSBvdGhlciByZWFzb24pIHRoZSByZWZyZXNoX3Rv
a2VuaXMgaW1wbGljaXRseSByZXZva2VkLg0KICAgID4+IFNIT1VMRCBvciBNVVNUPyBJIHdvdWxk
IHN1Z2dlc3QgdG8gZ28gd2l0aCBhIFNIT1VMRC4NCiAgICA+IEkgd291bGQgc2F5IHRoYXQgdGhl
IEFTIFNIT1VMRCBiaW5kIHRoZSByZWZyZXNoX3Rva2VuIHRvIHRoZSB1c2VyJ3MgYXV0aGVudGlj
YXRpb24uIEhvd2V2ZXIsIEknZCBsZWFuIG1vcmUgdG8gTVVTVCBmb3Igc2Vzc2lvbiBib3VuZCBy
ZWZyZXNoX3Rva2VucyBiZWluZyByZXZva2VkIHdoZW4gdGhlIHNlc3Npb24gaXMgdGVybWluYXRl
ZC4NCiAgICANCiAgICB3Zm0gDQogICAgDQogICAgQW55b25lIG9uIHRoZSBsaXN0IHdhbnRpbmcg
dG8gb2JqZWN0PyANCiAgICANCiAgICA+PiANCiAgICA+Pj4gMi4gQ2xpZW50cyB0aGF0IG5lZWQg
dG8gb2J0YWluIGEgcmVmcmVzaF90b2tlbiB0aGF0IGV4aXN0cyBiZXlvbmQgdGhlIGxpZmV0aW1l
IG9mIHRoZSB1c2VyJ3MgYXV0aGVudGljYXRpb24gc2Vzc2lvbiBNVVNUIGluZGljYXRlIHRoaXMg
bmVlZCBieSByZXF1ZXN0aW5nIHRoZSAib2ZmbGluZV9hY2Nlc3MiIHNjb3BlIChodHRwczovL29w
ZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNPZmZsaW5lQWNjZXNz
KS4gVGhpcyBwcm92aWRlcyBmb3IgYSB1c2VyIGNvbnNlbnQgZXZlbnQgbWFraW5nIGl0IGNsZWFy
IHRvIHRoZSB1c2VyIHRoYXQgdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFjY2VzcyBldmVuIHdo
ZW4gdGhlIHVzZXIncyBhdXRoZW50aWNhdGlvbiBzZXNzaW9uIGV4cGlyZXMuIFRoaXMgdGhlbiBi
ZWNvbWVzIHRoZSBkZWZhdWx0IGZvciBtb2JpbGUgYXBwcyBhcyB0aGUgcmVmcmVzaF90b2tlbiBz
aG91bGQgbm90IGJlIHRpZWQgdG8gdGhlIHdlYiBzZXNzaW9uIHVzZWQgdG8gYXV0aG9yaXplIHRo
ZSBhcHAuDQogICAgPj4gU291bmRzIHJlYXNvbmFibGUsIGp1c3QgdGhlIHNjb3BlIOKAnm9mZmxp
bmVfYWNjZXNz4oCcIGlzIE9JREMgc3BlY2lmaWMuIElzIGl0IHRpbWUgdG8gbW92ZSBpdCBkb3du
IHRoZSBzdGFjayB0byBPQXV0aD8NCiAgICA+IEl0IG1heSBiZSBpZiB3ZSB3YW50IG1vcmUgY29u
c2lzdGVuY3kgaW4gdGhlIGltcGxlbWVudGF0aW9uIG9mIHJlZnJlc2hfdG9rZW4gcG9saWN5IGFj
cm9zcyBhdXRob3JpemF0aW9uIHNlcnZlcnMuDQogICAgDQogICAgV2hvIGhhcyBhbiBvcGluaW9u
IG9uIHRoYXQgdG9waWM/DQogICAgDQogICAgPj4gDQogICAgPj4+IDMuIFRoZSBBUyBNQVkgY29u
c2lkZXIgcHV0dGluZyBhbiB1cHBlciBib3VuZCBvbiB0aGUgbGlmZXRpbWUgb2YgYSByZWZyZXNo
X3Rva2VuIChlLmcuIDEgeWVhcikuIFRoZXJlIGlzIG5vIHJlYWwgbmVlZCB0byBpc3N1ZSBhIHJl
ZnJlc2hfdG9rZW4gdGhhdCBpcyBnb29kIGluZGVmaW5pdGVseS4NCiAgICA+PiBJIHRob3VnaHQg
SSBoYWQgY292ZXJlZCB0aGF0IGluIHRoZSBsYXN0IHNlY3Rpb24uIEl04oCZcyBub3c6DQogICAg
Pj4gDQogICAgPj4gUmVmcmVzaCB0b2tlbnMgU0hPVUxEIGV4cGlyZSBpZiB0aGUgY2xpZW50IGhh
cyBiZWVuIGluYWN0aXZlIGZvciBzb21lIHRpbWUsDQogICAgPj4gICAgIAlpLmUuIHRoZSByZWZy
ZXNoIHRva2VuIGhhcyBub3QgYmVlbiB1c2VkIHRvIG9idGFpbiBmcmVzaCBhY2Nlc3MgdG9rZW5z
IGZvcg0KICAgID4+ICAgICAJc29tZSB0aW1lLiBUaGUgZXhwaXJhdGlvbiB0aW1lIGlzIGF0IHRo
ZSBkaXNjcmV0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCiAgICA+PiAgICAgCUl0
IG1pZ2h0IGJlIGEgZ2xvYmFsIHZhbHVlIG9yIGRldGVybWluZWQgYmFzZWQgb24gdGhlIGNsaWVu
dCBwb2xpY3kgb3INCiAgICA+PiAgICAgCXRoZSBncmFudCBhc3NvY2lhdGVkIHdpdGggdGhlIHJl
ZnJlc2ggdG9rZW4gKGFuZCBpdHMgc2Vuc2l0aXZpdHkpLg0KICAgID4gVGhpcyBpcyBzbGlnaHRs
eSBkaWZmZXJlbnQgYnV0IHN1ZmZpY2llbnQgc28gKzEgZm9yIHRoZSB0ZXh0IDopDQogICAgDQog
ICAgT2ssIHRoYW5rcy4gDQogICAgDQogICAgPj4gDQogICAgPj4gUHJvcG9zYWxzIGFyZSB3ZWxj
b21lIQ0KICAgID4+IA0KICAgID4+IGtpbmQgcmVnYXJkcywNCiAgICA+PiBUb3JzdGVuLg0KICAg
ID4+IA0KICAgID4+IA0KICAgID4+PiBUaGlzIGlzIGluIGFkZGl0aW9uIHRvIHRoZSBvdGhlciBi
ZXN0IHByYWN0aWNlcyBkZXNjcmliZWQuDQogICAgPj4+IA0KICAgID4+PiBUaGFua3MsDQogICAg
Pj4+IEdlb3JnZQ0KICAgID4+PiANCiAgICA+Pj4gT24gMTEvMjAvMTggMjozMiBQTSwgVG9yc3Rl
biBMb2RkZXJzdGVkdCB3cm90ZToNCiAgICA+Pj4+IEhpIGFsbCwNCiAgICA+Pj4+IA0KICAgID4+
Pj4gdGhlIG5ldyByZXZpc2lvbiBjb250YWlucyB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQogICAg
Pj4+PiANCiAgICA+Pj4+ICogYWRkZWQgc2VjdGlvbiBvbiByZWZyZXNoIHRva2Vucw0KICAgID4+
Pj4gKiBhZGRpdGlvbmFsIGp1c3RpZmljYXRpb25zIGZvciByZWNvbW1lbmRhdGlvbiBmb3IgY29k
ZQ0KICAgID4+Pj4gKiByZWZhY3RvcmVkIDIuMSBpbiBvcmRlciB0byBkaXN0aW5ndWlzaCBDU1JG
LCBhdXRoeiByZXNwb25zZSByZXBsYXkgYW5kIG1peC11cCAoYmFzZWQgb24gZmVlZGJhY2sgYnkg
Sm9zZXBoIEhlZW5hbikNCiAgICA+Pj4+ICogYWRkZWQgcmVxdWlyZW1lbnQgdG8gYXV0aGVudGlj
YXRlIGNsaWVudHMgZHVyaW5nIGNvZGUgZXhjaGFuZ2UgKFBLQ0Ugb3IgY2xpZW50IGNyZWRlbnRp
YWwpIHRvIDIuMS4xLg0KICAgID4+Pj4gKiBjaGFuZ2VkIG9jY3VycmVuY2VzIG9mIFNIQUxMIHRv
IE1VU1QNCiAgICA+Pj4+IA0KICAgID4+Pj4gQXMgYWx3YXlzOiBsb29raW5nIGZvcndhcmQgZm9y
IHlvdXIgZmVlZGJhY2suDQogICAgPj4+PiANCiAgICA+Pj4+IGtpbmQgcmVnYXJkcywNCiAgICA+
Pj4+IFRvcnN0ZW4uDQogICAgPj4+PiANCiAgICA+Pj4+IA0KICAgID4+Pj4+IEFtIDIwLjExLjIw
MTggdW0gMjA6MjYgc2NocmllYiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCiAgICA+Pj4+PiA6
DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg
aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz
Lg0KICAgID4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRob3Jp
emF0aW9uIFByb3RvY29sIFdHIG9mIHRoZSBJRVRGLg0KICAgID4+Pj4+IA0KICAgID4+Pj4+ICAg
ICAgICBUaXRsZSAgICAgICAgICAgOiBPQXV0aCAyLjAgU2VjdXJpdHkgQmVzdCBDdXJyZW50IFBy
YWN0aWNlDQogICAgPj4+Pj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRvcnN0ZW4gTG9kZGVy
c3RlZHQNCiAgICA+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgSm9obiBCcmFkbGV5DQog
ICAgPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIEFuZHJleSBMYWJ1bmV0cw0KICAgID4+
Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBEYW5pZWwgRmV0dA0KICAgID4+Pj4+IAlGaWxl
bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMC50eHQNCiAg
ICA+Pj4+PiAJUGFnZXMgICAgICAgICAgIDogMzgNCiAgICA+Pj4+PiAJRGF0ZSAgICAgICAgICAg
IDogMjAxOC0xMS0yMA0KICAgID4+Pj4+IA0KICAgID4+Pj4+IEFic3RyYWN0Og0KICAgID4+Pj4+
ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYmVzdCBjdXJyZW50IHNlY3VyaXR5IHByYWN0aWNl
IGZvciBPQXV0aCAyLjAuDQogICAgPj4+Pj4gICBJdCB1cGRhdGVzIGFuZCBleHRlbmRzIHRoZSBP
QXV0aCAyLjAgU2VjdXJpdHkgVGhyZWF0IE1vZGVsIHRvDQogICAgPj4+Pj4gICBpbmNvcnBvcmF0
ZSBwcmFjdGljYWwgZXhwZXJpZW5jZXMgZ2F0aGVyZWQgc2luY2UgT0F1dGggMi4wIHdhcw0KICAg
ID4+Pj4+ICAgcHVibGlzaGVkIGFuZCBjb3ZlcnMgbmV3IHRocmVhdHMgcmVsZXZhbnQgZHVlIHRv
IHRoZSBicm9hZGVyDQogICAgPj4+Pj4gICBhcHBsaWNhdGlvbiBvZiBPQXV0aCAyLjAuDQogICAg
Pj4+Pj4gDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz
IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3Mv
DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6
ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgID4+Pj4+IA0KICAgID4+Pj4+IGh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMA0K
ICAgID4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0
Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTANCiAgICA+Pj4+PiANCiAgICA+Pj4+PiANCiAgICA+
Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQog
ICAgPj4+Pj4gDQogICAgPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy
YWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEwDQogICAgPj4+Pj4gDQogICAgPj4+Pj4g
DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv
dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4+Pj4+IHVu
dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu
aWV0Zi5vcmcuDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv
IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgID4+Pj4+IA0KICAgID4+Pj4+IGZ0
cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAgPj4+Pj4gDQogICAgPj4+Pj4g
DQogICAgPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCiAgICA+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBP
QXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCiAgICA+Pj4+IA0KICAgID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAg
ID4+Pj4gDQogICAgPj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4gDQogICAgDQogICAgDQoNCg==


From nobody Wed Nov 28 17:23:05 2018
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 343CE126BED for ; Wed, 28 Nov 2018 17:23:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.961
X-Spam-Level: 
X-Spam-Status: No, score=-15.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 NKXXK2DX5Sph for ; Wed, 28 Nov 2018 17:23:00 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B7B12426A for ; Wed, 28 Nov 2018 17:23:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1543454580; x=1574990580; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=36QmgQMNs8veQCBQMsLHDKM2yKSMSlHtpaF8YgtVQXw=; b=hnHIPwi5J60NjUbR8fwBTygFTStA2oLXcVcIHoq4EEHGIag/H/YktmDr 1IcVqCRXA94N3kmo6E0TD8Sc/e4lnfAu5hUN0EJ4n9+sHbPz0RyIr8Eqb UaIebLMPtIpNUDOWa6L3qSahLNSvV9wjNEGdN7Go//gkQU537zcYY+maj I=;
X-IronPort-AV: E=Sophos;i="5.56,253,1539648000"; d="scan'208";a="706483630"
Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-2b-5bdc5131.us-west-2.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  29 Nov 2018 01:22:58 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2b-5bdc5131.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id wAT1MvuX014637 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Nov 2018 01:22:57 GMT
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 01:22:56 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 29 Nov 2018 01:22:56 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 29 Nov 2018 01:22:56 +0000
From: "Richard Backman, Annabelle" 
To: Neil Madden , Daniel Fett 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Binding Access Tokens is not enough!
Thread-Index: AQHUgnGyRzIZ9vJFBUG3HfeCInd9AKVdYxUAgAN2XYCAAOragIAAHa6AgAOXIoA=
Date: Thu, 29 Nov 2018 01:22:56 +0000
Message-ID: <21B0104D-F7B7-4F94-AC55-A7172037A669@amazon.com>
References:   <15ECD17C-C2E3-487B-B61D-E67E5A060DE4@lodderstedt.net>  <584108B8-3293-48D4-9FD6-86DCF6CC34A3@forgerock.com>
In-Reply-To: <584108B8-3293-48D4-9FD6-86DCF6CC34A3@forgerock.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.109]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [OAUTH-WG] Binding Access Tokens is not enough!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Nov 2018 01:23:03 -0000

SW4gc29tZSBjYXNlcywgdGhlIHJlc291cmNlIHNlcnZlciB3aWxsIG5lZWQgdG8gc3VwcG9ydCBD
T1JTIGluIG9yZGVyIHRvIHN1cHBvcnQgU1BBIGNsaWVudHMgdGhhdCBhcmUgb24gZGlmZmVyZW50
IG9yaWdpbnMuIEluIHRoaXMgY2FzZSwgdGhlIHJlc291cmNlIHNlcnZlciBtdXN0IG9wdGltaXN0
aWNhbGx5IGFsbG93IHRoZSBDT1JTIHJlcXVlc3QgdG8gYmUgbWFkZSwgdGhlbiB2YWxpZGF0ZSB0
aGF0IHRoZSByZXF1ZXN0IG9yaWdpbiBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGFjY2VzcyB0b2tl
biBwcm92aWRlZCBpbiB0aGUgcmVxdWVzdC4gVG8gbXkga25vd2xlZGdlLCBJIGhhdmVuJ3Qgc2Vl
biAib3JpZ2luLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMiIHJhaXNlZCBhcyBhIHJlcXVpcmVt
ZW50IGFueXdoZXJlLCBidXQgaGVyZSB3ZSBhcmUuDQoNCi0tIA0KQW5uYWJlbGxlIFJpY2hhcmQg
QmFja21hbg0KQVdTIElkZW50aXR5DQogDQoNCu+7v09uIDExLzI2LzE4LCAyOjM0IEFNLCAiT0F1
dGggb24gYmVoYWxmIG9mIE5laWwgTWFkZGVuIiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBi
ZWhhbGYgb2YgbmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQoNCiAgICBJIHdvdWxk
IHBlcmhhcHMgY2xhcmlmeSB0aGlzIGEgbGl0dGxlLCBhcyBpdOKAmXMgbm90IHJlYWxseSBDT1JT
IHRoYXQgaXMgZG9pbmcgdGhlIHdvcmsgaGVyZSwgYnV0IHJhdGhlciB0aGUgc2FtZS1vcmlnaW4g
cG9saWN5IChTT1ApIOKAlCB3aGljaCBpcyBhY3R1YWxseSAqcmVsYXhlZCogYnkgQ09SUy4gDQog
ICAgDQogICAgSXQgaXMgdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIG5vbi1zYWZlIGhlYWRlciAo
QXV0aG9yaXphdGlvbikgb24gdGhlIHJlcXVlc3QgdGhhdCB0cmlnZ2VycyB0aGUgU09QIHByb3Rl
Y3Rpb25zIC0gYW5kIGl0IHdvdWxkIGRvIHNvIGV2ZW4gaW4gYW4gb2xkIHByZS1DT1JTIGJyb3dz
ZXIuIE90aGVyd2lzZSBDT1JTIHdvdWxkbuKAmXQgZXZlbiBiZSBpbnZvbHZlZCBhcyB0aGUgcmVx
dWVzdCB3b3VsZCBiZSBjb25zaWRlcmVkIOKAnHNhZmXigJ0uIEZvciBpbnN0YW5jZSwgaWYgeW91
ciAoUlMpIEFQSSBqdXN0IHJlcXVpcmVzIGFuIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBQT1NUIGJv
ZHkgd2l0aCB0aGUgYWNjZXNzIHRva2VuIGFzIG9uZSBvZiB0aGUgZmllbGRzIHRoZW4gSSBjYW4g
YWx3YXlzIGp1c3QgY3JlYXRlIGEgZm9ybSBpbiBhIGhpZGRlbiBpZnJhbWUgYW5kIHN1Ym1pdCBp
dCBjcm9zcy1vcmlnaW4gd2l0aCBubyBwcm9ibGVtcywgQ09SUyBvciBub3QuIEFkZGluZyB0aGUg
QXV0aG9yaXphdGlvbiBoZWFkZXIgcHJldmVudHMgdGhhdCAtIHlvdSBjYW7igJl0IGFkZCBhIGN1
c3RvbSBoZWFkZXIgdG8gYSBmb3JtIHN1Ym1pc3Npb24sIGFuZCBBamF4IHdvdWxkIG5vdCBiZSBh
bGxvd2VkIHRvIG1ha2UgdGhhdCByZXF1ZXN0Lg0KICAgIA0KICAgIFdoYXQgQ09SUyBjaGFuZ2Vz
IGlzIHRoYXQgdGhpbmdzIHRoYXQgd291bGQgcHJldmlvdXNseSBiZSBibG9ja2VkIG91dHJpZ2h0
IG5vdyBwcm9kdWNlIGEgQ09SUyBwcmVmbGlnaHQgdG8gYWxsb3cgdGhlIGRlc3RpbmF0aW9uIG9y
aWdpbiB0byBvdmVycmlkZSB0aGUgU09QIGFuZCBhbGxvdyBhIHJlcXVlc3QgdG8gZ28gYWhlYWQg
YW55d2F5Lg0KICAgIA0KICAgIOKAlCBOZWlsDQogICAgDQogICAgPiBPbiAyNiBOb3YgMjAxOCwg
YXQgMDg6NDYsIERhbmllbCBGZXR0IDxkYW5pZWxmK29hdXRoQHllcy5jb20+IHdyb3RlOg0KICAg
ID4gDQogICAgPiBZZXMuIFRva2VuIEJpbmRpbmcgZW5mb3JjZXMgdGhhdCBvbmx5IHRoZSByaWdo
dCBicm93c2VyIGNhbiBzZW5kIHRoZSB0b2tlbjsgaW4gdGhpcyBicm93c2VyLCBDT1JTIGVuZm9y
Y2VzIHRoYXQgb25seSB0aGUgY29ycmVjdCBvcmlnaW4gY2FuIHNlbmQgdGhlIHRva2VuLg0KICAg
ID4gDQogICAgPiBBbSAyNS4xMS4xOCB1bSAxOTo0NiBzY2hyaWViIFRvcnN0ZW4gTG9kZGVyc3Rl
ZHQ6DQogICAgPj4gRG9lcyB0aGlzIG1lYW4gdGhlIFJTIGVmZmVjdGl2ZWx5IHJlbGllcyBvbiB0
aGUgdXNlciBhZ2VudCB0byBlbmZvcmNlIHRoZSBzZW5kZXIgY29uc3RyYWludCAodmlhIENPUlMg
cG9saWN5KT8NCiAgICA+PiANCiAgICA+PiANCiAgICA+Pj4gQW0gMjMuMTEuMjAxOCB1bSAxNDo1
NCBzY2hyaWViIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPg0KICAgID4+
PiA6DQogICAgPj4+IA0KICAgID4+PiBUaGFua3MgZm9yIGRvaW5nIHRoaXMgRGFuaWVsLCBJIHRo
aW5rIHRoZSBwcm9wb3NlZCB0ZXh0IGlzIGdvb2QuDQogICAgPj4+IA0KICAgID4+PiDigJQgTmVp
bA0KICAgID4+PiANCiAgICA+Pj4gDQogICAgPj4+PiBPbiAyMiBOb3YgMjAxOCwgYXQgMTQ6NDIs
IERhbmllbCBGZXR0IDxkYW5pZWxmK29hdXRoQHllcy5jb20+DQogICAgPj4+PiAgd3JvdGU6DQog
ICAgPj4+PiANCiAgICA+Pj4+IEhpIGFsbCwNCiAgICA+Pj4+IA0KICAgID4+Pj4gSSB3b3VsZCBs
aWtlIHRvIGRpc2N1c3MgYSB0ZXh0IHByb3Bvc2FsIGZvciB0aGUgc2VjdXJpdHkgQkNQLg0KICAg
ID4+Pj4gDQogICAgPj4+PiBCYWNrZ3JvdW5kOg0KICAgID4+Pj4gDQogICAgPj4+PiBZZXN0ZXJk
YXksIE5laWwgcG9pbnRlZCBvdXQgdGhlIGZvbGxvd2luZyBwcm9ibGVtIHdpdGggYmluZGluZyBh
Y2Nlc3MgdG9rZW5zIHVzaW5nIG1UTFMgb3IgdG9rZW4gYmluZGluZyBpbiBTUEFzOg0KICAgID4+
Pj4gDQogICAgPj4+PiAiSSBhbSB0YWxraW5nIGFib3V0IHNjcmlwdHMgZnJvbSBwbGFjZXMgbGlr
ZSBhZCBzZXJ2ZXJzIHRoYXQgYXJlIHVzdWFsbHkgaW5jbHVkZWQgdmlhIGFuIGlmcmFtZSB0byBl
bmZvcmNlIHRoZSBTT1AgYW5kIHNhbmRib3ggdGhlbSBmcm9tIG90aGVyIHNjcmlwdHMuIElmIHRo
ZXkgZ2V0IGFjY2VzcyB0byBhbiBhY2Nlc3MgdG9rZW4gLSBlLmcuIHZpYSBkb2N1bWVudC5yZWZl
cnJlciBvciBhIHJlZGlyZWN0IG9yIHNvbWUgb3RoZXIgbGVhaywgdGhlbiB0aGV5IHN0aWxsIGFj
dCB3aXRoaW4gdGhlIHNhbWUgVExTIGNvbnRleHQgYXMgdGhlIGxlZ2l0aW1hdGUgY2xpZW50LiIN
CiAgICA+Pj4+IA0KICAgID4+Pj4gVGhlIHByb2JsZW0gaXMgdGhhdCBhIGJyb3dzZXIncyBUTFMg
c3RhY2sgd2lsbCBhdHRhY2ggdGhlIHByb29mIG9mIHBvc3Nlc3Npb24gbm8gbWF0dGVyIHdoaWNo
IG9yaWdpbiBzdGFydGVkIGEgcmVxdWVzdC4NCiAgICA+Pj4+IA0KICAgID4+Pj4gKFRoaXMgc2Vl
bXMgbGlrZSBhIHJlYWwgZG93bnNpZGUgb2YgdG9rZW4gYmluZGluZyAtIHdoeSBkb2VzIGl0IG5v
dCBoYXZlIHRoZSAic2FtZSBzaXRlIiBvcHRpb24gdGhhdCBjb29raWVzIG5vd2FkYXlzIGhhdmU/
KQ0KICAgID4+Pj4gDQogICAgPj4+PiBJIHByZXBhcmVkIHRoZSBmb2xsb3dpbmcgYWRkaXRpb24g
dG8gdGhlIHNlY3VyaXR5IEJDUCBhbmQgd291bGQgbGlrZSB0byBoZWFyIHlvdXIgb3BpbmlvbnM6
DQogICAgPj4+PiANCiAgICA+Pj4+ICJJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IGNvbnN0
cmFpbmluZyB0aGUgc2VuZGVyIG9mIGEgdG9rZW4gdG8gYSB3ZWIgYnJvd3NlciAodXNpbmcgYSBU
TFMtYmFzZWQgbWV0aG9kKSBkb2VzIG5vdCBjb25zdHJhaW4gdGhlIG9yaWdpbiBvZiB0aGUgc2Ny
aXB0IHRoYXQgdXNlcyB0aGUgdG9rZW4gKGxhY2sgb2Ygb3JpZ2luIGJpbmRpbmcpLiBJbiBvdGhl
ciB3b3JkcywgaWYgYWNjZXNzIHRva2VucyBhcmUgdXNlZCBpbiBhIGJyb3dzZXIgKGFzIGluIGEg
c2luZ2xlLXBhZ2UgYXBwbGljYXRpb24sIFNQQSkgYW5kIHRoZSBhY2Nlc3MgdG9rZW5zIGFyZSBz
ZW5kZXItY29uc3RyYWluZWQgdXNpbmcgYSBUTFMtYmFzZWQgbWV0aG9kLCBpdCBtdXN0IGJlIGVu
c3VyZWQgdGhhdCBvcmlnaW5zIG90aGVyIHRoYW4gdGhlIG9yaWdpbiBvZiB0aGUgU1BBIGNhbm5v
dCBtaXN1c2UgdGhlIFRMUy1iYXNlZCBzZW5kZXIgYXV0aGVudGljYXRpb24uDQogICAgPj4+PiAN
CiAgICA+Pj4+IFRoZSBwcm9ibGVtIGNhbiBiZSBpbGx1c3RyYXRlZCB1c2luZyBhbiBTUEEgb24g
b3JpZ2luIEEgdGhhdCB1c2VzIGFuIGFjY2VzcyB0b2tlbiBBVCB0aGF0IGlzIGJvdW5kIHRvIHRo
ZSBUTFMgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBicm93c2VyIGFuZCB0aGUgcmVzb3VyY2Ugc2Vy
dmVyIFIuIElmIEFUIGxlYWtzIHRvIGFuIGF0dGFja2VyIEUsIGFuZCB0aGVyZSBpcywgZm9yIGV4
YW1wbGUsIGFuIGlmcmFtZSBmcm9tIEUncyBvcmlnaW4gbG9hZGVkIGluIHRoZSB3ZWIgYnJvd3Nl
ciwgdGhhdCBpZnJhbWUgY2FuIHNlbmQgYSByZXF1ZXN0IHRvIG9yaWdpbiBSIHVzaW5nIHRoZSBh
Y2Nlc3MgdG9rZW4gQVQuIFRoaXMgcmVxdWVzdCB3aWxsIGNvbnRhaW4gdGhlIHByb29mLW9mLXBv
c2Vzc2lvbiBvZiB0aGUgKG1UTFMgb3IgdG9rZW4gYmluZGluZykga2V5LiBUaGUgcmVzb3VyY2Ug
c2VydmVyIFIgdGhlcmVmb3JlIGNhbm5vdCBkaXN0aW5ndWlzaCBpZiBhIHJlcXVlc3QgY29udGFp
bmluZyBhIHZhbGlkIGFjY2VzcyB0b2tlbiBvcmlnaW5hdGVzIGZyb20gb3JpZ2luIEEgb3Igb3Jp
Z2luIEUuDQogICAgPj4+PiANCiAgICA+Pj4+IElmIHRoZSByZXNvdXJjZSBzZXJ2ZXIgb25seSBh
Y2NlcHRzIHRoZSBhY2Nlc3MgdG9rZW4gaW4gYW4gQXV0aG9yaXphdGlvbiBoZWFkZXIsIHRoZW4g
Q3Jvc3MtT3JpZ2luIFJlc291cmNlIFNoYXJpbmcgKENPUlMpIHdpbGwgcHJvdGVjdCBhZ2FpbnN0
IHRoaXMgYXR0YWNrIGJ5IGRlZmF1bHQuIElmIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYWNjZXB0cyB0
aGUgYWNjZXNzIHRva2VucyBpbiBvdGhlciB3YXlzIChlLmcuLCBhcyBhIFVSTCBwYXJhbWV0ZXIp
LCBvciBpZiB0aGUgQ09SUyBwb2xpY3kgb2YgdGhlIHJlc291cmNlIHNlcnZlciBwZXJtaXRzIHJl
cXVlc3RzIGJ5IG9yaWdpbiBFLCB0aGVuIHRoZSBUTFMtYmFzZWQgdG9rZW4gYmluZGluZyBvbmx5
IHByb3ZpZGVzIHByb3RlY3Rpb24gaWYgdGhlIGJyb3dzZXIgaXMgb2ZmbGluZS4iDQogICAgPj4+
PiANCiAgICA+Pj4+IA0KICAgID4+Pj4gVGhlICJzdW1tYXJ5IiBhYm92ZSB0aGlzIHRleHQgcmVh
ZHMgYXMgZm9sbG93czoNCiAgICA+Pj4+IA0KICAgID4+Pj4gIklmIGFjY2VzcyB0b2tlbnMgYXJl
IHNlbmRlci1jb25zdHJhaW5lZCB0byBhIHdlYiBicm93c2VyLCB0aGUgcmVzb3VyY2Ugc2VydmVy
IE1VU1QgZW5zdXJlIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiBjYW4gb25seSBiZSB1c2VkIGJ5IHRo
ZSBvcmlnaW4gdG8gd2hpY2ggdGhlIGFjY2VzcyB0b2tlbiB3YXMgaXNzdWVkIChvcmlnaW4gYmlu
ZGluZykuIE9uZSBzb2x1dGlvbiBmb3IgdGhlIHJlc291cmNlIHNlcnZlciB0byBhY2NvbXBsaXNo
IHRoaXMgaXMgdG8gb25seSBhY2NlcHQgdGhlIGFjY2VzcyB0b2tlbiBpbiBhbiBBdXRob3JpemF0
aW9uIGhlYWRlciAoYXMgZGVzY3JpYmVkIGluIFJGQyA2NzUwKSBhbmQgdG8gZW5zdXJlIHRoYXQg
dGhlIGFjdGl2ZSBDT1JTIHBvbGljeSBwcmV2ZW50cyB0aGlyZCBwYXJ0aWVzIGZyb20gc2VuZGlu
ZyBBdXRob3JpemF0aW9uIGhlYWRlcnMuIFNlZSA8eHJlZiB0YXJnZXQ9InBvcF90b2tlbnMiLz4g
Zm9yIGRldGFpbHMuIg0KICAgID4+Pj4gDQogICAgPj4+PiBXaGF0IGRvIHlvdSB0aGluaz8NCiAg
ICA+Pj4+IA0KICAgID4+Pj4gLURhbmllbA0KICAgID4+Pj4gDQogICAgPj4+PiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4gT0F1dGggbWFp
bGluZyBsaXN0DQogICAgPj4+PiANCiAgICA+Pj4+IE9BdXRoQGlldGYub3JnDQogICAgPj4+PiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgPj4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4+IE9BdXRo
IG1haWxpbmcgbGlzdA0KICAgID4+PiANCiAgICA+Pj4gT0F1dGhAaWV0Zi5vcmcNCiAgICA+Pj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4gDQogICAg
PiANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KICAgIE9BdXRoIG1haWxpbmcgbGlzdA0KICAgIE9BdXRoQGlldGYub3JnDQogICAgaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgIA0KDQo=


From nobody Wed Nov 28 22:19:00 2018
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 6682B130E33 for ; Wed, 28 Nov 2018 22:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SrKNVjNXBB-4 for ; Wed, 28 Nov 2018 22:18:54 -0800 (PST)
Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450: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 0518F12F1AC for ; Wed, 28 Nov 2018 22:18:54 -0800 (PST)
Received: by mail-wr1-x441.google.com with SMTP id v6so584512wrr.12 for ; Wed, 28 Nov 2018 22:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=woNgzlRKyAapk9o0t1MvIFC4k7RJbLuqHO0mvW+dsbE=; b=bAjczLW/e16UvR3ts7Nqoqn5clVItFx8HrsSmLXGglR/lSN1ZENcbXglEg22nLc/vI fz47FuWT8fxv0aNi5Ov4Oc/bngZ/XauapFladofSlhvg8lRfPif2dCHjbV8EbT4Svx95 S2mpLLuGMCyhLZcdL/wz06gPu8NOmwdMM6U68=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=woNgzlRKyAapk9o0t1MvIFC4k7RJbLuqHO0mvW+dsbE=; b=nIE5m1bcjCH5IY3CrUdTOi3mS2AB94TYDyDtItZz+DuUOwamNST+OmZzY5O85SUmvy JcFU3Kz6CatVzqevk0yYLzNRIt8C/cYO4WkH70qP3HRVcnSmlGIu3dhUgYTXTJ/BKB/L KAUw744CX1BYql86Qwe43IomorVxJUxDsmS4svfHyPi4MyLSn8WGXOoz+jmHnf5XMB0a h+DEPGDSv9SoWGmiseYQ/zr5tKZMZuuLUbYeTZt4hHCX9z8UlDOvRUfS32XqnhOd576N HSBpBLeC6Ga1CKsho8r0oYd3vyDuHnU4ZZSPAi0mS0r14zlNelLIW61VrJaDNUbnxtxq q6lA==
X-Gm-Message-State: AA+aEWYG69KqyZR5WxWSHPc+KMM1s5u6MrbSOigaWt/HMcI+rFI+ZFoh 5GsEDrqQJPGSVD2AZ4lGr0woCw==
X-Google-Smtp-Source: AFSGD/Xyn+z9PzziqadHDBeb2g/28PbDz/2slkEB1asObiJrCvGtPxX2O8AVF9HPiBS/aHVckEZgaA==
X-Received: by 2002:adf:90e5:: with SMTP id i92mr175944wri.210.1543472332361;  Wed, 28 Nov 2018 22:18:52 -0800 (PST)
Received: from [192.168.1.65] (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id y145sm812201wmd.30.2018.11.28.22.18.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 22:18:51 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-23DDF053-3CA6-4DEF-9747-8817B0EF6289
Mime-Version: 1.0 (1.0)
From: Neil Madden 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: 
Date: Thu, 29 Nov 2018 06:18:50 +0000
Cc: Torsten Lodderstedt , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <8C2C26DF-68E1-4D09-91A5-B0165C2F4997@forgerock.com>
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com> <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net>  <1198DA32-4E63-4966-89CA-398478226209@lodderstedt.net> 
To: "Richard Backman, Annabelle" 
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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: Thu, 29 Nov 2018 06:18:58 -0000

--Apple-Mail-23DDF053-3CA6-4DEF-9747-8817B0EF6289
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Agreed. Consider also service account flows such as the JWT-bearer approach u=
sed by Google: https://developers.google.com/identity/protocols/OAuth2Servic=
eAccount#authorizingrequests

It=E2=80=99s not clear there is any session at all in these cases. (Although=
 I don=E2=80=99t think there is a refresh token in this specific case).=20

I think spectrum of desired behaviours is too wide to recommend any particul=
ar option. Perhaps tying the refresh token to a session could be included as=
 a MAY just to document it as something to consider?

=E2=80=94 Neil

> On 29 Nov 2018, at 00:20, Richard Backman, Annabelle  wrote:
>=20
> I think we need to be very careful about prescribing behavior around refre=
sh token lifetime, and setting expectations for what degree of consistency i=
s attainable. Considering the terms "session", "authenticated session", "off=
line", "expiration", "termination", and "log out" can mean different things t=
o different services (and those tiny nuances matter!) I am against text that=
 makes binding refresh tokens to the authenticated session a "SHOULD." Rathe=
r, we should recommend that the AS provide the end user with a mechanism by w=
hich they may terminate refresh tokens. We can also describe session-bound r=
efresh tokens as one such method that may or may not be appropriate dependin=
g on the use case.
>=20
> To back up my claim that consistency is Hard, here are a few scenarios to c=
onsider:
>=20
> 1)
> A mobile app loads the authorization request in an in-app browser tab that=
 has an app-scoped cookie jar and is never presented by the app again after t=
he flow is complete. How does the user sign out of that session? Should the A=
S kill the session due to inactivity? Won't that confuse the user when sudde=
nly the integration between app and service stops working for no discernable=
 reason? If this scenario sounds unlikely, it's not. This is the behavior of=
 every app that integrated with the Safari in-app browser tab in iOS 9 and n=
ever updated to the authentication-oriented replacements introduced later, a=
s well as that of every app that opens the authorization request in a web vi=
ew (ugh).
>=20
> 2)
> A mobile app loads the authorization request in the external browser, but t=
he user always uses the AS's app on their device instead of visiting their w=
ebsite (e.g., using the Gmail app instead of going to gmail.com in the brows=
er), so their browser session quickly times out due to inactivity. Again, wo=
n't that confuse the user when the client mobile app stops working?
>=20
> 3)
> A set-top box uses the device flow, and the tokens it receives are bound t=
o the user's session in the web browser on their laptop, where they complete=
d the device flow. The user buys a new laptop, their session on their old la=
ptop times out due to inactivity, and their set-top box can't stream videos a=
nymore. =C2=AF\_(=E3=83=84)_/=C2=AF
>=20
> --=20
> Annabelle Richard Backman
> AWS Identity
>=20
>=20
> =EF=BB=BFOn 11/28/18, 9:20 AM, "OAuth on behalf of Torsten Lodderstedt"  wrote:
>=20
>=20
>=20
>> Am 28.11.2018 um 16:53 schrieb George Fletcher :
>>=20
>> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>>> Hi George,
>>>=20
>>>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>>>=20
>>>> Thanks for the additional section on refresh_tokens. Some additional re=
commendations...
>>>>=20
>>>> 1. By default refresh_tokens are bound to the user's authenticated sess=
ion. When the authenticated session expires or is terminated (whether by the=
 user or for some other reason) the refresh_tokenis implicitly revoked.
>>> SHOULD or MUST? I would suggest to go with a SHOULD.
>> I would say that the AS SHOULD bind the refresh_token to the user's authe=
ntication. However, I'd lean more to MUST for session bound refresh_tokens b=
eing revoked when the session is terminated.
>=20
>    wfm=20
>=20
>    Anyone on the list wanting to object?=20
>=20
>>>=20
>>>> 2. Clients that need to obtain a refresh_token that exists beyond the l=
ifetime of the user's authentication session MUST indicate this need by requ=
esting the "offline_access" scope (https://openid.net/specs/openid-connect-c=
ore-1_0.html#OfflineAccess). This provides for a user consent event making i=
t clear to the user that the client is requesting access even when the user'=
s authentication session expires. This then becomes the default for mobile a=
pps as the refresh_token should not be tied to the web session used to autho=
rize the app.
>>> Sounds reasonable, just the scope =E2=80=9Eoffline_access=E2=80=9C is OI=
DC specific. Is it time to move it down the stack to OAuth?
>> It may be if we want more consistency in the implementation of refresh_to=
ken policy across authorization servers.
>=20
>    Who has an opinion on that topic?
>=20
>>>=20
>>>> 3. The AS MAY consider putting an upper bound on the lifetime of a refr=
esh_token (e.g. 1 year). There is no real need to issue a refresh_token that=
 is good indefinitely.
>>> I thought I had covered that in the last section. It=E2=80=99s now:
>>>=20
>>> Refresh tokens SHOULD expire if the client has been inactive for some ti=
me,
>>>        i.e. the refresh token has not been used to obtain fresh access t=
okens for
>>>        some time. The expiration time is at the discretion of the author=
ization server.
>>>        It might be a global value or determined based on the client poli=
cy or
>>>        the grant associated with the refresh token (and its sensitivity)=
.
>> This is slightly different but sufficient so +1 for the text :)
>=20
>    Ok, thanks.=20
>=20
>>>=20
>>> Proposals are welcome!
>>>=20
>>> kind regards,
>>> Torsten.
>>>=20
>>>=20
>>>> This is in addition to the other best practices described.
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>>> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>>>>> Hi all,
>>>>>=20
>>>>> the new revision contains the following changes:
>>>>>=20
>>>>> * added section on refresh tokens
>>>>> * additional justifications for recommendation for code
>>>>> * refactored 2.1 in order to distinguish CSRF, authz response replay a=
nd mix-up (based on feedback by Joseph Heenan)
>>>>> * added requirement to authenticate clients during code exchange (PKCE=
 or client credential) to 2.1.1.
>>>>> * changed occurrences of SHALL to MUST
>>>>>=20
>>>>> As always: looking forward for your feedback.
>>>>>=20
>>>>> kind regards,
>>>>> Torsten.
>>>>>=20
>>>>>=20
>>>>>> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org
>>>>>> :
>>>>>>=20
>>>>>>=20
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts di=
rectories.
>>>>>> This draft is a work item of the Web Authorization Protocol WG of the=
 IETF.
>>>>>>=20
>>>>>>       Title           : OAuth 2.0 Security Best Current Practice
>>>>>>       Authors         : Torsten Lodderstedt
>>>>>>                         John Bradley
>>>>>>                         Andrey Labunets
>>>>>>                         Daniel Fett
>>>>>>    Filename        : draft-ietf-oauth-security-topics-10.txt
>>>>>>    Pages           : 38
>>>>>>    Date            : 2018-11-20
>>>>>>=20
>>>>>> Abstract:
>>>>>>  This document describes best current security practice for OAuth 2.0=
.
>>>>>>  It updates and extends the OAuth 2.0 Security Threat Model to
>>>>>>  incorporate practical experiences gathered since OAuth 2.0 was
>>>>>>  published and covers new threats relevant due to the broader
>>>>>>  application of OAuth 2.0.
>>>>>>=20
>>>>>>=20
>>>>>> The IETF datatracker status page for this draft is:
>>>>>>=20
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>>>=20
>>>>>>=20
>>>>>> There are also htmlized versions available at:
>>>>>>=20
>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topic=
s-10
>>>>>>=20
>>>>>>=20
>>>>>> A diff from the previous version is available at:
>>>>>>=20
>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-=
10
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Please note that it may take a couple of minutes from the time of sub=
mission
>>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>>=20
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>=20
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>>=20
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-23DDF053-3CA6-4DEF-9747-8817B0EF6289
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Agr=
eed. Consider also service account flows such as the JWT-bearer approach use=
d by Google: https://developers.google.com/id=
entity/protocols/OAuth2ServiceAccount#authorizingrequests

    It=E2=80=99s not clear there is any session=
 at all in these cases. (Although I don=E2=80=99t think there is a refresh t=
oken in this specific case). 

    I think spectrum of desired behaviours is too wide to recommend any pa=
rticular option. Perhaps tying the refresh token to a session could be inclu=
ded as a MAY just to document it as something to consider?

    =E2=80=94 Neil

    On 2=
9 Nov 2018, at 00:20, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

    I=
 think we need to be very careful about prescribing behavior around refresh t=
oken lifetime, and setting expectations for what degree of consistency is at=
tainable. Considering the terms "session", "authenticated session", "offline=
", "expiration", "termination", and "log out" can mean different things to d=
ifferent services (and those tiny nuances matter!) I am against text that ma=
kes binding refresh tokens to the authenticated session a "SHOULD." Rather, w=
e should recommend that the AS provide the end user with a mechanism by whic=
h they may terminate refresh tokens. We can also describe session-bound refr=
esh tokens as one such method that may or may not be appropriate depending o=
n the use case.

    To back up my claim that co=
nsistency is Hard, here are a few scenarios to consider:

    1)
    A mobile app loads the authorization reques=
t in an in-app browser tab that has an app-scoped cookie jar and is never pr=
esented by the app again after the flow is complete. How does the user sign o=
ut of that session? Should the AS kill the session due to inactivity? Won't t=
hat confuse the user when suddenly the integration between app and service s=
tops working for no discernable reason? If this scenario sounds unlikely, it=
's not. This is the behavior of every app that integrated with the Safari in=
-app browser tab in iOS 9 and never updated to the authentication-oriented r=
eplacements introduced later, as well as that of every app that opens the au=
thorization request in a web view (ugh).

    2)=

    A mobile app loads the authorization request in the externa=
l browser, but the user always uses the AS's app on their device instead of v=
isiting their website (e.g., using the Gmail app instead of going to     gmail.com in the browser), so their browser sessio=
n quickly times out due to inactivity. Again, won't that confuse the user wh=
en the client mobile app stops working?

    3)<=
/span>
    A set-top box uses the device flow, and the tokens it receiv=
es are bound to the user's session in the web browser on their laptop, where=
 they completed the device flow. The user buys a new laptop, their session o=
n their old laptop times out due to inactivity, and their set-top box can't s=
tream videos anymore. =C2=AF\_(=E3=83=84)_/=C2=AF
    -- 
    Annabelle Richard Backman
    AWS Ide=
ntity


    =EF=BB=BFOn 11/28/18=
, 9:20 AM, "OAuth on behalf of Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten@lodderstedt.net> wrote:


    Am 28.11.2018 um 16:53 schrieb George Fletcher <gffletch@aol.com>:

    <=
span>On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
    =

    Hi George,<=
br>

    Am 20.11.2018 um 23:=
38 schrieb George Fletcher <gffletch@=
aol.com>:

    Thanks for the addit=
ional section on refresh_tokens. Some additional recommendations...

    <=
blockquote type=3D"cite">1. By default refresh_tokens are bound to the=
 user's authenticated session. When the authenticated session expires or is t=
erminated (whether by the user or for some other reason) the refresh_tokenis=
 implicitly revoked.
    SHOULD or MUST? I would s=
uggest to go with a SHOULD.
    I would say that the AS SHOULD bind the refresh_token to t=
he user's authentication. However, I'd lean more to MUST for session bound r=
efresh_tokens being revoked when the session is terminated.

        wfm 

        Anyone on the list wanting to object? <=
br>

    2. Clients that need to obtai=
n a refresh_token that exists beyond the lifetime of the user's authenticati=
on session MUST indicate this need by requesting the "offline_access" scope (=
https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess)=
. This provides for a user consent event making it clear to the user that th=
e client is requesting access even when the user's authentication session ex=
pires. This then becomes the default for mobile apps as the refresh_token sh=
ould not be tied to the web session used to authorize the app.
    Sounds reasonable, just the scope =E2=80=9Eoffline_access=E2=
=80=9C is OIDC specific. Is it time to move it down the stack to OAuth?
    It may be if=
 we want more consistency in the implementation of refresh_token policy acro=
ss authorization servers.

     &nb=
sp;  Who has an opinion on that topic?

    =


    3. The AS MAY consider putting an upper bound on t=
he lifetime of a refresh_token (e.g. 1 year). There is no real need to issue=
 a refresh_token that is good indefinitely.
    I=
 thought I had covered that in the last section. It=E2=80=99s now:

    Refresh tokens SHOULD expire if the client has b=
een inactive for some time,
           &nbs=
p;i.e. the refresh token has not been used to obtain fresh access tokens for=

            some time. The expiratio=
n time is at the discretion of the authorization server.
     &=
nbsp;      It might be a global value or determined base=
d on the client policy or
            =
;the grant associated with the refresh token (and its sensitivity).
    This is slightly=
 different but sufficient so +1 for the text :)

        Ok, thanks. 

    Proposals are welcome!

    kind regards,<=
/span>
    Torsten.


    <=
/blockquote>
    This is in addition to the other best pract=
ices described.

    Thanks,
    George
    =


    On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
    Hi all,<=
/span>

    the new revision contains the followi=
ng changes:
    =


    * added section on refr=
esh tokens
    <=
blockquote type=3D"cite">* additional justifications for recommendatio=
n for code
    <=
blockquote type=3D"cite">* refactored 2.1 in order to distinguish CSRF,=
 authz response replay and mix-up (based on feedback by Joseph Heenan)
    * added requirement to authenticate clients during code exchang=
e (PKCE or client credential) to 2.1.1.
    =

    * changed occurr=
ences of SHALL to MUST

    As always: l=
ooking forward for your feedback.

    k=
ind regards,
    <=
blockquote type=3D"cite">
    Torsten.

    <=
blockquote type=3D"cite">

    Am 20.11.2018 um 20:26=
 schrieb internet-drafts@ietf.or=
g
    :

    =


    A New Internet-Draft is available from the on-line Interne=
t-Drafts directories.
    <=
span>This draft is a work item of the Web Authorization Protocol WG of the I=
ETF.

    <=
/blockquote>
         &nbs=
p; Title           : O=
Auth 2.0 Security Best Current Practice
    =

           Authors  &n=
bsp;      : Torsten Lodderstedt
          =
            &nbs=
p;      John Bradley
    =

            =
;            &nb=
sp;    Andrey Labunets
             &=
nbsp;            =
;   Daniel Fett
        Filename       &nbs=
p;: draft-ietf-oauth-security-topics-10.txt
        Pages      =
;     : 38
        Date       &n=
bsp;    : 2018-11-20

    =

    Abstract:
      This document describes best current security practice for OAuth 2.0=
.
      It updat=
es and extends the OAuth 2.0 Security Threat Model to
      incorporate practical experience=
s gathered since OAuth 2.0 was
      published and covers new threats relevant due to the bro=
ader
      appli=
cation of OAuth 2.0.


    <=
/blockquote>
    The IETF datatracker status p=
age for this draft is:
    =

    https://=
datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/


    There are also htmlized versions available at:

    =

    https://tools.ietf.org/html/draft-ietf-oauth-security=
-topics-10
    https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topi=
cs-10
    =


    A diff from the previous version is ava=
ilable at:

    https://www.ie=
tf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10



    =

    Ple=
ase note that it may take a couple of minutes from the time of submission
    <=
blockquote type=3D"cite">
    until the htmlized v=
ersion and diff are available at tools.iet=
f.org.

    Internet-Drafts are al=
so available by anonymous FTP at:

    =

    ftp://ftp.ietf.org/internet-draf=
ts/

    =


    <=
blockquote type=3D"cite">
    ___________________________________________=
____
    OAuth mailin=
g list

    =

    OAuth@ietf.org
    <=
/blockquote>
    https://www=
.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    <=
span>OAuth mailing list

    OAuth@ietf.org
    https://www.ietf.org/mailman/listi=
nfo/oauth
    =





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

    =

--Apple-Mail-23DDF053-3CA6-4DEF-9747-8817B0EF6289--


From nobody Wed Nov 28 22:51:47 2018
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 18CE8130E1D for ; Wed, 28 Nov 2018 22:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 KNfggxFUaNaP for ; Wed, 28 Nov 2018 22:51:39 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970EB12F1AC for ; Wed, 28 Nov 2018 22:51:38 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id q26so989928wmf.5 for ; Wed, 28 Nov 2018 22:51:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/gTLSrsvSSsmqByRSKkPswBEZ0pqwwU9zEheeDYMNUw=; b=NhwN8BFu1lAkIx8eZ+4fYeZtUVIllpPO+a+ojfHgo5eYPLu2rIaJna//e+4QeFEGwD ecJehNroreVtvibm0tqnjiv3i87g1r6tOZhcW0hkn8ElzTQd794WMnAXG2JTwIWt08Ro 5oZZbcNAomsf4aLmjK5xQuGPMgDwmlrZjJHs4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/gTLSrsvSSsmqByRSKkPswBEZ0pqwwU9zEheeDYMNUw=; b=dFXzkpWJzcQln8Xn3u8HsDPOiBmCt4I3JdK4Xw2ooA670P0IxALMAY2zkFJLJzW7me Z/JEV5dqwD6pjOFFDxWVi5vnSR+MlPVTZKivRZkUU8qeA0dNfZmaK4WdxR8qc0L0zagP rXCr9ILPA9MgtND4I39A+J6lweApfoyWffx/d0GyT3wSyRwT5BN2cyAEzdO59fdiCaw7 A4vK9bCqKwdlT6nOa0aMVCqQ6bhLaYe3K1wMIymCcJMlBzXlNw4hb1LoR2hJnRRqFGHU qfkvdwnI82U0Awd2juPi0JmISWBqmuW82JfyiVYgAc1sx2VTDZu4bxgxEui8pwVAZPVE 9z4g==
X-Gm-Message-State: AA+aEWbRGYK11PD+5r1waa+4wtTIQge95DbWF15imxRPTX/SXGG2itJ8 it+8xUYL693pVu6VtOWtsOfBkQ==
X-Google-Smtp-Source: AFSGD/Upf5dDjEtkGPfgCGk2w0Bl2t+kGyRdDJGvF9YRerKDFeBvjEp/CVwxQGzPY1/abUFHeDf2RA==
X-Received: by 2002:a1c:2b82:: with SMTP id r124mr549384wmr.151.1543474296669;  Wed, 28 Nov 2018 22:51:36 -0800 (PST)
Received: from [192.168.1.65] (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id r12sm683857wrq.3.2018.11.28.22.51.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 22:51:35 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Neil Madden 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <21B0104D-F7B7-4F94-AC55-A7172037A669@amazon.com>
Date: Thu, 29 Nov 2018 06:51:34 +0000
Cc: Daniel Fett , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CB2E55D-231D-4783-89FD-9216F902595A@forgerock.com>
References:   <15ECD17C-C2E3-487B-B61D-E67E5A060DE4@lodderstedt.net>  <584108B8-3293-48D4-9FD6-86DCF6CC34A3@forgerock.com> <21B0104D-F7B7-4F94-AC55-A7172037A669@amazon.com>
To: "Richard Backman, Annabelle" 
Archived-At: 
Subject: Re: [OAUTH-WG] Binding Access Tokens is not enough!
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, 29 Nov 2018 06:51:42 -0000

My intent wasn=E2=80=99t to suggest that tokens *must* be origin constrained=
, just to point out if you are using TLS-based sender constrained tokens the=
n you may also want to consider that aspect.=20

In some cases you may be comfortable that protections against in-browser tok=
en theft are adequate without any sender/origin constraint. Sometimes a plai=
n old bearer token is fine.=20

=E2=80=94 Neil

> On 29 Nov 2018, at 01:22, Richard Backman, Annabelle =
 wrote:
>=20
> In some cases, the resource server will need to support CORS in order to s=
upport SPA clients that are on different origins. In this case, the resource=
 server must optimistically allow the CORS request to be made, then validate=
 that the request origin is appropriate for the access token provided in the=
 request. To my knowledge, I haven't seen "origin-constrained access tokens"=
 raised as a requirement anywhere, but here we are.
>=20
> --=20
> Annabelle Richard Backman
> AWS Identity
>=20
>=20
> =EF=BB=BFOn 11/26/18, 2:34 AM, "OAuth on behalf of Neil Madden"  wrote:
>=20
>    I would perhaps clarify this a little, as it=E2=80=99s not really CORS t=
hat is doing the work here, but rather the same-origin policy (SOP) =E2=80=94=
 which is actually *relaxed* by CORS.=20
>=20
>    It is the fact that there is a non-safe header (Authorization) on the r=
equest that triggers the SOP protections - and it would do so even in an old=
 pre-CORS browser. Otherwise CORS wouldn=E2=80=99t even be involved as the r=
equest would be considered =E2=80=9Csafe=E2=80=9D. For instance, if your (RS=
) API just requires an x-www-form-urlencoded POST body with the access token=
 as one of the fields then I can always just create a form in a hidden ifram=
e and submit it cross-origin with no problems, CORS or not. Adding the Autho=
rization header prevents that - you can=E2=80=99t add a custom header to a f=
orm submission, and Ajax would not be allowed to make that request.
>=20
>    What CORS changes is that things that would previously be blocked outri=
ght now produce a CORS preflight to allow the destination origin to override=
 the SOP and allow a request to go ahead anyway.
>=20
>    =E2=80=94 Neil
>=20
>> On 26 Nov 2018, at 08:46, Daniel Fett  wrote:
>>=20
>> Yes. Token Binding enforces that only the right browser can send the toke=
n; in this browser, CORS enforces that only the correct origin can send the t=
oken.
>>=20
>>> Am 25.11.18 um 19:46 schrieb Torsten Lodderstedt:
>>> Does this mean the RS effectively relies on the user agent to enforce th=
e sender constraint (via CORS policy)?
>>>=20
>>>=20
>>>> Am 23.11.2018 um 14:54 schrieb Neil Madden 
>>>> :
>>>>=20
>>>> Thanks for doing this Daniel, I think the proposed text is good.
>>>>=20
>>>> =E2=80=94 Neil
>>>>=20
>>>>=20
>>>>> On 22 Nov 2018, at 14:42, Daniel Fett 
>>>>> wrote:
>>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> I would like to discuss a text proposal for the security BCP.
>>>>>=20
>>>>> Background:
>>>>>=20
>>>>> Yesterday, Neil pointed out the following problem with binding access t=
okens using mTLS or token binding in SPAs:
>>>>>=20
>>>>> "I am talking about scripts from places like ad servers that are usual=
ly included via an iframe to enforce the SOP and sandbox them from other scr=
ipts. If they get access to an access token - e.g. via document.referrer or a=
 redirect or some other leak, then they still act within the same TLS contex=
t as the legitimate client."
>>>>>=20
>>>>> The problem is that a browser's TLS stack will attach the proof of pos=
session no matter which origin started a request.
>>>>>=20
>>>>> (This seems like a real downside of token binding - why does it not ha=
ve the "same site" option that cookies nowadays have?)
>>>>>=20
>>>>> I prepared the following addition to the security BCP and would like t=
o hear your opinions:
>>>>>=20
>>>>> "It is important to note that constraining the sender of a token to a w=
eb browser (using a TLS-based method) does not constrain the origin of the s=
cript that uses the token (lack of origin binding). In other words, if acces=
s tokens are used in a browser (as in a single-page application, SPA) and th=
e access tokens are sender-constrained using a TLS-based method, it must be e=
nsured that origins other than the origin of the SPA cannot misuse the TLS-b=
ased sender authentication.
>>>>>=20
>>>>> The problem can be illustrated using an SPA on origin A that uses an a=
ccess token AT that is bound to the TLS connection between the browser and t=
he resource server R. If AT leaks to an attacker E, and there is, for exampl=
e, an iframe from E's origin loaded in the web browser, that iframe can send=
 a request to origin R using the access token AT. This request will contain t=
he proof-of-posession of the (mTLS or token binding) key. The resource serve=
r R therefore cannot distinguish if a request containing a valid access toke=
n originates from origin A or origin E.
>>>>>=20
>>>>> If the resource server only accepts the access token in an Authorizati=
on header, then Cross-Origin Resource Sharing (CORS) will protect against th=
is attack by default. If the resource server accepts the access tokens in ot=
her ways (e.g., as a URL parameter), or if the CORS policy of the resource s=
erver permits requests by origin E, then the TLS-based token binding only pr=
ovides protection if the browser is offline."
>>>>>=20
>>>>>=20
>>>>> The "summary" above this text reads as follows:
>>>>>=20
>>>>> "If access tokens are sender-constrained to a web browser, the resourc=
e server MUST ensure that the access token can only be used by the origin to=
 which the access token was issued (origin binding). One solution for the re=
source server to accomplish this is to only accept the access token in an Au=
thorization header (as described in RFC 6750) and to ensure that the active C=
ORS policy prevents third parties from sending Authorization headers. See  for details."
>>>>>=20
>>>>> What do you think?
>>>>>=20
>>>>> -Daniel
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>=20
>    _______________________________________________
>    OAuth mailing list
>    OAuth@ietf.org
>    https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20


From nobody Thu Nov 29 05:26:51 2018
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 76DC4130DC8 for ; Thu, 29 Nov 2018 05:26:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ubisecure.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN1-pID5X4_I for ; Thu, 29 Nov 2018 05:26:43 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150075.outbound.protection.outlook.com [40.107.15.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73398130DD4 for ; Thu, 29 Nov 2018 05:26:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ubisecure.onmicrosoft.com; s=selector1-ubisecure-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=021ZV2QiiO0Lg4CEOpNO9KmYQXkQXucvA4jKTaXzvIo=; b=WGCsp5KFu91CpqhLMBTY1pGEwzS59OsRNoFTgZESU3LCaqZcLxK1i1byJoelFKap+nwc1ttnmp3eaP1mTi473Es+ENdE+Uz1ZemJNR0ZQ6Ooi9oEbuTTbRAFpGDel4I6FvjhEskUWWJSroNY3nQnpvM1FTO71Z0GDcLDxcUUnNE=
Received: from HE1PR05MB4713.eurprd05.prod.outlook.com (20.176.164.14) by HE1PR05MB1820.eurprd05.prod.outlook.com (10.166.86.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.19; Thu, 29 Nov 2018 13:26:37 +0000
Received: from HE1PR05MB4713.eurprd05.prod.outlook.com ([fe80::d5ec:45e3:efda:8da9]) by HE1PR05MB4713.eurprd05.prod.outlook.com ([fe80::d5ec:45e3:efda:8da9%4]) with mapi id 15.20.1361.019; Thu, 29 Nov 2018 13:26:37 +0000
From: Petteri Stenius 
To: Torsten Lodderstedt , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwAYRRbAABPdaIAAES+SAAAK3nrAAAF3OoAAAbNqgAAVmmqAAAmlbIAAICS4gACl6t6AAAvL3oAAv//tMA==
Date: Thu, 29 Nov 2018 13:26:37 +0000
Message-ID: 
References:   <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <90e0cb05-5245-1a67-4eca-16996e7db2fc@ve7jtb.com>  <3485431a-74fc-408e-5360-c87c4bafc1fa@aol.com>   <21a00a22-0524-07de-ac0e-77d597e5a9a1@aol.com>   <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
In-Reply-To: <0263F10B-0CDA-4CE4-A5B0-06221C1673B8@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Petteri.Stenius@ubisecure.com; 
x-originating-ip: [195.197.205.34]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR05MB1820; 6:GsGSld5bZpSq/v/yb1/nYqnSNlY38bSB9t1nk3cvZs4umR0Eoie5rx0UzA+uODrnXBRvDTvy8iikEuKBCu8JYDfT6DFPYJw6AFxWsmfZbtCgzga2m89EtQAa8mvcEieWxwZ2/Q1SZXWuktT535zig33jKHc66p2G3bHVuqegkGzCATGktPL8NWGmBnO8ZVxHbooLhdF9o+F08sjzB4l3FKNq05ccd/MmOJJcvWyTEAqrsAwIjmFk9JThbJuJVXdDDZqVp2s2+ouZUDwgYZ11PZU7WFBFYmjfwAo1sKnBtMM5rsUnmSoWK56P/OkRtQx5M/peI92/OX7ASr9kv90v8f2VymvEi+D1RbwYB1sXQxszXfVxluNtcUoiYH1EQKo2LwY37IV6MbiyGnvaOqJBbowmGC5rY0TTMzOo+6lcYmxNvVwYWW7HheHtUWYxQUKpCXmJt13NaTBu1XOzXeZEoA==; 5:A1F9+7yfPiEI5neCHJ3X9i0rKY6iZSF8w/LodAVb/rSxGvpubWcWBo8gXAKJtsQd37Q79jjsbjOqx4stJKgEzmryRszsyLAD0EKkoEw7vWT+OT+MKaFD6/hIulvvCcOFQ6/F4UHwTMxSYdBm0yOsBNrgxWCdlWSOgqyN2t022Zs=; 7:3WuIDol8uiXlqpbwLid+dt4p77UlH5ESuYUl6luEzD4Wyc319UOM5E87OiSku8mdfy2fQVf6GPZlg6FPrGrNA80LgWqI5ES2eoZLBZ/Z4rbzgxSqBFaeu2mEKWxSMNFWSXNYHjcgFkEg17lBn7nO+w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c0f4209a-8881-4531-1a59-08d655fe4a51
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR05MB1820; 
x-ms-traffictypediagnostic: HE1PR05MB1820:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231453)(999002)(944501410)(52105112)(148016)(149066)(150057)(6041310)(2016111802025)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6043046)(201708071742011)(7699051)(76991095); SRVR:HE1PR05MB1820; BCL:0; PCL:0; RULEID:; SRVR:HE1PR05MB1820; 
x-forefront-prvs: 0871917CDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39840400004)(366004)(346002)(396003)(51444003)(40434004)(53754006)(189003)(199004)(13464003)(99286004)(6246003)(14444005)(8676002)(486006)(8936002)(14454004)(81166006)(81156014)(71200400001)(71190400001)(7696005)(93886005)(229853002)(15974865002)(66574009)(316002)(53546011)(6436002)(106356001)(105586002)(508600001)(2906002)(6506007)(68736007)(15650500001)(966005)(6116002)(72206003)(86362001)(3846002)(5660300001)(102836004)(305945005)(53936002)(2501003)(26005)(110136005)(25786009)(7736002)(476003)(74316002)(6306002)(66066001)(76176011)(4744004)(5024004)(446003)(33656002)(11346002)(97736004)(256004)(55016002)(9686003)(561944003)(186003)(18886075002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR05MB1820; H:HE1PR05MB4713.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ubisecure.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gTCpRNyJKH8qNlCF+/ToVlxJFfLwQPIk9latPk6Fu0Ujhv9EV4gWTEPk5AV9c1ZwEhhjIYet21xmuo4NKn/PXBdjtXh7ykVXiL4wifEQKM1ww3OG5zZcdqU+hizM+FlN6WFsjjjSYuIXsWs2+4LIwMvqfLTchDGHPtlVcj+PyvmAD3/LGlhbIy1FPwDWYk+YKdWgcyAoJWBel/TPKQWcxd7YQpqeETnWgCIM9PL3yiCt4DETm4PzHgNxlO/+nO1L723AkXyscxb/oL44EU5tIcsHvpFX9SP90WJHn4ti34h22fftysAtrkJyc8+pgSPT2OkUHuZ6gzfZ+x4TYfZDxbkGXaBfVzuJ8Hgobdtlhsw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ubisecure.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0f4209a-8881-4531-1a59-08d655fe4a51
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2018 13:26:37.4824 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: feaa1139-6ffc-4422-9c7b-980ad003c1a7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR05MB1820
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 29 Nov 2018 13:26:51 -0000

SGkgYWxsLA0KDQpJIHN1cHBvcnQgdGhpcyBwcm9wb3NhbCBvZiByZWNvbW1lbmRpbmcgYXV0aG9y
aXphdGlvbiBjb2RlIGdyYW50IGFuZCBhZHZpc2luZyB0byBub3QgdXNlIGltcGxpY2l0IGdyYW50
Lg0KQXMgYSBkZXZlbG9wZXIgd2UgdmFsdWUgY2xlYW4gYW5kIHJvYnVzdCBzcGVjaWZpY2F0aW9u
cyB3aXRoIGxlc3Mgb3Bwb3J0dW5pdHkgZm9yIG1pc3Rha2VzLg0KDQpUaGFuayB5b3UsDQpQZXR0
ZXJpIFN0ZW5pdXMgLyBVYmlzZWN1cmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVG9yc3RlbiBM
b2RkZXJzdGVkdA0KU2VudDogc3VubnVudGFpIDI1LiBtYXJyYXNrdXV0YSAyMDE4IDE5LjMzDQpU
bzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5
IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGlj
aXQNCg0KSGkgYWxsLCANCg0KSSB3b3VsZCBsaWtlIHRvIHN0YXRlIGFnYWluIHdoYXQgdGhlIHBy
b3Bvc2FsIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBTZWN1cml0eSBCQ1AgaXM6DQoNCkhlcmUgaXMg
dGhlIHJlc3BlY3RpdmUgdGV4dCBmcm9tIHRoZSBkcmFmdDoNCg0K4oCU4oCUDQoNCjIuMS4yLiAg
SW1wbGljaXQgR3JhbnQNCg0KICAgVGhlIGltcGxpY2l0IGdyYW50IChyZXNwb25zZSB0eXBlICJ0
b2tlbiIpIGFuZCBvdGhlciByZXNwb25zZSB0eXBlcw0KICAgY2F1c2luZyB0aGUgYXV0aG9yaXph
dGlvbiBzZXJ2ZXIgdG8gaXNzdWUgYWNjZXNzIHRva2VucyBpbiB0aGUNCiAgIGF1dGhvcml6YXRp
b24gcmVzcG9uc2UgYXJlIHZ1bG5lcmFibGUgdG8gYWNjZXNzIHRva2VuIGxlYWthZ2UgYW5kDQog
ICBhY2Nlc3MgdG9rZW4gcmVwbGF5IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMSwgU2VjdGlv
biAzLjIsIFNlY3Rpb24gMy4zLCBhbmQgU2VjdGlvbiAzLjYuDQoNCiAgIE1vcmVvdmVyLCBubyB2
aWFibGUgbWVjaGFuaXNtIGV4aXN0cyB0byBjcnlwdG9ncmFwaGljYWxseSBiaW5kIGFjY2Vzcw0K
ICAgdG9rZW5zIGlzc3VlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSB0byBhIGNlcnRh
aW4gY2xpZW50IGFzIGl0DQogICBpcyByZWNvbW1lbmRlZCBpbiBTZWN0aW9uIDIuMi4gIFRoaXMg
bWFrZXMgcmVwbGF5IGRldGVjdGlvbiBmb3Igc3VjaA0KICAgYWNjZXNzIHRva2VucyBhdCByZXNv
dXJjZSBzZXJ2ZXJzIGltcG9zc2libGUuDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlz
c3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQNCiAgIGdyYW50IG9yIGFu
eSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRv
DQogICBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2Uu
DQoNCiAgIENsaWVudHMgU0hPVUxEIGluc3RlYWQgdXNlIHRoZSByZXNwb25zZSB0eXBlICJjb2Rl
IiAoYWthDQogICBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSkgYXMgc3BlY2lmaWVkIGlu
IFNlY3Rpb24gMi4xLjEgb3IgYW55DQogICBvdGhlciByZXNwb25zZSB0eXBlIHRoYXQgY2F1c2Vz
IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBpc3N1ZQ0KICAgYWNjZXNzIHRva2VucyBpbiB0
aGUgdG9rZW4gcmVzcG9uc2UuICBUaGlzIGFsbG93cyB0aGUgYXV0aG9yaXphdGlvbg0KICAgc2Vy
dmVyIHRvIGRldGVjdCByZXBsYXkgYXR0ZW1wdHMgYW5kIGdlbmVyYWxseSByZWR1Y2VzIHRoZSBh
dHRhY2sNCiAgIHN1cmZhY2Ugc2luY2UgYWNjZXNzIHRva2VucyBhcmUgbm90IGV4cG9zZWQgaW4g
VVJMcy4gIEl0IGFsc28gYWxsb3dzDQogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gc2Vu
ZGVyLWNvbnN0cmFpbiB0aGUgaXNzdWVkIHRva2Vucy4NCuKAlOKAlA0KDQpJbiBteSBvYnNlcnZh
dGlvbiwgZGlzY291cmFnaW5nIGltcGxpY2l0IHNlZW1zIHRvIGJlIHRoZSBsZXNzIGNvbnRyb3Zl
cnNpYWwgaXNzdWUuDQoNCuKAnm9yIGFueSBvdGhlciByZXNwb25zZSB0eXBlIGNhdXNpbmcgdGhl
IGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0
aG9yaXphdGlvbiByZXNwb25zZS7igJwgaW4gdGhlIDNyZCBwYXJhZ3JhcGggY2F1c2VkIGRpc2N1
c3Npb25zIGJlY2F1c2UgaXQgc3VnZ2VzdHMgdG8gZGlzY291cmFnZSBkZXZlbG9wZXJzIGZyb20g
dXNpbmcgQU5ZIHJlc3BvbnNlIHR5cGUgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBhdXRo
b3JpemF0aW9uIHJlc3BvbnNlLiBUaGlzIGluY2x1ZGVzIE9JREPigJlzIHJlc3BvbnNlIHR5cGVz
IOKAnnRva2VuIGlkX3Rva2Vu4oCcLCDigJ5jb2RlIHRva2Vu4oCcICYg4oCeY29kZSB0b2tlbiBp
ZF90b2tlbuKAnCwgd2hlcmUgYXQgbGVhc3QgIOKAnnRva2VuIGlkX3Rva2Vu4oCcIGlzIHVzZWQg
aW4gdGhlIHdpbGQgdG8gaW1wbGVtZW50IFNQQXMuDQoNCldoeSBkaWQgd2UgY29tZSB1cCB3aXRo
IHRoaXMgcHJvcG9zYWwgZ2l2ZW4gYXQgbGVhc3Qg4oCedG9rZW4gaWRfdG9rZW7igJwgJiDigJ5j
b2RlIHRva2VuIGlkX3Rva2Vu4oCcIHByb3RlY3QgYWdhaW5zdCBpbmplY3Rpb24/DQoNClR3byBy
ZWFzb25zOiANCg0KMSkg4oCedG9rZW4gaWRfdG9rZW7igJwgZG9lcyBub3Qgc3VwcG9ydCBzZW5k
ZXIgY29uc3RyYWluZWQgdG9rZW5zLiBBbHNvIHVzZSBvZiByZWZyZXNoIHRva2VucyB0byBmcmVx
dWVudGx5IGlzc3VlIG5ldyBsaXZlLXRpbWUgYW5kIHByaXZpbGVnZSByZXN0cmljdGVkIGFjY2Vz
cyB0b2tlbnMgaXMgbm90IHN1cHBvcnRlZC4g4oCeY29kZSB0b2tlbiBpZF90b2tlbuKAnCBzZWVt
cyBtb3JlIGNvbXBsZXggdGhhbiBqdXN0IOKAnmNvZGXigJwrcGtjZSBmb3IgYWNoaWV2aW5nIHRo
ZSBzYW1lIGdvYWwuDQoNCjIpIFByb3RlY3Rpb24gYWdhaW5zdCB0b2tlbiBsZWFrYWdlIGlzIHJh
dGhlciB0aGluIGFuZCBmcmFnaWxlLiBUaGVyZSBpcyBqdXN0IGEgc2luZ2xlIGxpbmUgb2YgZGVm
ZW5zZSAoQ1NQLCBvcGVuIHJlZGlyZWN0aW9uIHByZXZlbnRpb24sIGJyb3dzZXIgaGlzdG9yeSBt
YW5pcHVsYXRpb24pIGltcGxlbWVudGVkIGJ5IHRoZSBjbGllbnQuIA0KDQpEYW5pZWwgYW5kIEkg
Y29sbGVjdGVkIHNvbWUgbW9yZSBpbmZvcm1hdGlvbiBhbmQgYXJndW1lbnQgYXQgaHR0cHM6Ly9n
aXRodWIuY29tL3Rsb2RkZXJzdGVkdC9vYXV0aDJfc3BhL2Jsb2IvbWFzdGVyL1JFQURNRS5tZCB0
aGF0IHlvdSBtaWdodCBsaWtlIHRvIGdpdmUgYSByZWFkLg0KDQpNeSBjb25jbHVzaW9uIGFmdGVy
IDIgd2Vla3Mgb2YgaW50ZW5zaXZlIGRpc2N1c3Npb25zIHdpdGggU1BBIGRldmVsb3BlcnMgKG1v
c3RseSBvbiB0d2l0dGVyKTogY29kZStwa2NlIGlzIHRoZSBtb3JlIHNlY3VyZSwgc2ltcGxlciwg
YW5kIG1vcmUgdmVyc2F0aWxlIGFwcHJvYWNoIHRvIChhbHNvKSBpbXBsZW1lbnQgU1BBcy4gSSBw
cmVmZXIgdG8gYXBwcm9hY2ggZGV2ZWxvcGVycyB3aXRoIGEgY2xlYW4gYW5kIHJvYnVzdCBtZXNz
YWdlIGluc3RlYWQgb2YgYSBsZW5ndGh5IGRlc2NyaXB0aW9uIG9mIHdoYXQgbmVlZHMgdG8gZ28g
cmlnaHQgaW4gb3JkZXIgdG8gc2VjdXJlIGEgU1BBIHVzaW5nIE9BdXRoLiBUaGF04oCZcyB3aHkg
SSB0aGluayBjb2RlK3BrY2Ugc2hvdWxkIGJlIHRoZSByZWNvbW1lbmRhdGlvbiBvZiBvdXIgd29y
a2luZyBncm91cC4NCg0KU28gcGxlYXNlIHZvdGUgaW4gZmF2b3Igb2Ygb3VyIHByb3Bvc2FsLiBJ
IHRoaW5rIHRoYXTigJlzIGEgaHVnZSBpbXByb3ZlbWVudCBmb3IgT0F1dGguDQoNCmtpbmQgcmVn
YXJkcywgDQpUb3JzdGVuLiANCg0KDQo+IEFtIDI1LjExLjIwMTggdW0gMTI6NTUgc2NocmllYiBI
YW5zIFphbmRiZWx0IDxoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT46DQo+IA0KPiBJIHN0cm9u
Z2x5IHN1cHBvcnQgdGhlIHJlY29tbWVuZGF0aW9uIG9mIHVzaW5nIGNvZGUgaW5zdGVhZCBvZiBp
bXBsaWNpdC4gSSBkbyBzbyBiYXNlZCBvbiBteSBvd24gZXhwZXJpZW5jZSBpbiB0aGUgZmllbGQg
WzFdIGFuZCBzdGljayB0byB0aGF0IGFsc28gYWZ0ZXIgcmVhZGluZyB0aGUgY29tbWVudHMgYW5k
ICh3aGF0IEkgd291bGQgY2FsbCkgd29ya2Fyb3VuZHMgb24gdGhpcyB0aHJlYWQuDQo+IA0KPiBI
YW5zLg0KPiANCj4gWzFdIGh0dHBzOi8vaGFuc3phbmRiZWx0LndvcmRwcmVzcy5jb20vMjAxNy8w
Mi8yNC9vcGVuaWQtY29ubmVjdC1mb3Itc2luZ2xlLXBhZ2UtYXBwbGljYXRpb25zLw0KPiANCj4g
T24gVGh1LCBOb3YgMjIsIDIwMTggYXQgNTo0NSBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3Jz
dGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQo+IHRoYXTigJlzIGNlcnRhaW5seSB0cnVlLCBi
dXQgdGhhdCBtaWdodCBieSBhIHdlYiBzZXJ2ZXIgd2l0aCBzdGF0aWMgY29udGVudCBvbmx5Lg0K
PiANCj4gSWYgdGhlIHNlcnZlciBpcyBhIHJlYWwgYmFja2VuZCwgdGhlcmUgaXMgZXZlbiBsZXNz
IHJlYXNvbnMgdG8gdXNlIGEgaW1wbGljaXQgb3IgaHlicmlkLiBObyBldmVuIGEgcGVyZm9ybWFu
Y2UgZ2FpbiBpbiBjb21wYXJpc29uIHRvIGNvZGUuDQo+IA0KPiBBbSAyMS4uMTEuMjAxOCB1bSAx
NDoyNCBzY2hyaWViIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbT46DQo+IA0KPj4g
QW4gU1BBIGhhcyBhIGJhY2tlbmQgYmVjYXVzZSBpdCBoYXMgdG8gYmUgbG9hZGVkIGZyb20gc29t
ZXdoZXJlIDopDQo+PiANCj4+IE9uIDExLzIxLzE4IDM6NDcgQU0sIFRvcnN0ZW4gTG9kZGVyc3Rl
ZHQgd3JvdGU6DQo+Pj4gV2UgaGFkIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIHRvcGljIG9uIFR3
aXR0ZXIgaHR0cHM6Ly90d2l0dGVyLmNvbS9BcGwzYi9zdGF0dXMvMTA2NDg1NDUwNzYwNjIwODUx
Mw0KPj4+IA0KPj4+IA0KPj4+IE91dGNvbWUgaXMgUE9TVCByZXF1aXJlcyBhIGJhY2tlbmQgdG8g
cmVjZWl2ZSB0aGUgcmVxdWVzdCBzbyBpdOKAmXMgbm90IGEgdmlhYmxlIHNvbHV0aW9uIGZvciBT
UEFzLg0KPj4+IA0KPj4+IA0KPj4+PiBBbSAyMC4xMS4yMDE4IHVtIDIzOjI5IHNjaHJpZWIgSm9o
biBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4NCj4+Pj4gOg0KPj4+PiANCj4+Pj4gUG9zdCBy
ZXNwb25zZSB3b3JrcyBPSyBmb3Igc2VydmVyIGJhc2VkIGNsaWVudHMuICBJIGRvbid0IHRoaW5r
IFBPU1Qgd29ya3MgZm9yIHNpbmdsZSBwYWdlIGFwcGxpY2F0aW9ucy4gIA0KPj4+PiANCj4+Pj4g
QmFzaWNhbGx5IHRoYXQgd291bGQgYmUgc29tZXRoaW5nIG1vcmUgbGlrZSBwb3N0bWVzc2FnZSBi
ZXR3ZWVuIHR3byBKUyBhcHBzLiAgDQo+Pj4+IA0KPj4+PiBQb3N0bWVzc2FnZSBhbHNvIGhhcyBz
ZWN1cml0eSBpc3N1ZXMgcGFzc2luZyBhIGFjY2VzcyB0b2tlbiBhbmQgbGVha2luZy4gIA0KPj4+
PiANCj4+Pj4gUGVyaGFwcyBzb21lb25lIG1vcmUgZmFtaWxpYXIgd2l0aCBTUEEgY2FuIGNvbW1l
bnQgb24gUE9TVC4gIA0KPj4+PiANCj4+Pj4gSm9obiBCLiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiAN
Cj4+Pj4gT24gVHVlLCBOb3YgMjAsIDIwMTgsIDY6NDAgUE0gR2VvcmdlIEZsZXRjaGVyIDwNCj4+
Pj4gZ2ZmbGV0Y2hAYW9sLmNvbQ0KPj4+PiAgd3JvdGU6DQo+Pj4+IEhpIE1pa2UsDQo+Pj4+IA0K
Pj4+PiBUaGUgRm9ybSBQb3N0IFJlc3BvbnNlIE1vZGUga2VlcHMgdGhlIGFjY2Vzc190b2tlbiBv
dXQgb2YgdGhlIFVSTCwgYnV0IGl0IGRvZXNuJ3QgcHJldmVudCB0aGUgdG9rZW4gZnJvbSB0cmF2
ZXJzaW5nIHRocm91Z2ggdGhlIGJyb3dzZXIuIFNvIGEgbWFuLWluLXRoZS1icm93c2VyIGF0dGFj
ayBtYXkgYmUgYWJsZSB0byBpbnRlcmNlcHQgdGhlIHZhbHVlcy4gSXQgc2hvdWxkIGhlbHAgd2l0
aCBsZWFrYWdlIGluIGxvZ3MuDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IEdlb3JnZQ0KPj4+
PiANCj4+Pj4gT24gMTEvMjAvMTggNDowMCBQTSwgTWlrZSBKb25lcyB3cm90ZToNCj4+Pj4gDQo+
Pj4+PiBOZXh0IHF1ZXN0aW9uIOKAkyBkb2VzbuKAmXQgdXNpbmcgdGhlIEZvcm0gUG9zdCBSZXNw
b25zZSBNb2RlIGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1mb3JtLXBvc3QtcmVz
cG9uc2UtbW9kZS0xXzAuaHRtbA0KPj4+Pj4gIG1pdGlnYXRlIHRoZSB0aHJlYXRzIHlvdeKAmXJl
IGRlc2NyaWJpbmcgYmVsb3cgSm9obj8gIElmIHNvLCBJIGJlbGlldmUgdGhlIFNlY3VyaXR5IFRv
cGljcyBkcmFmdCBzaG91bGQgc2F5IHRoaXMuDQo+Pj4+PiANCj4+Pj4+ICANCj4+Pj4+IA0KPj4+
Pj4gSSBiZWxpZXZlIHdlIG93ZSBpdCB0byByZWFkZXJzIHRvIHByZXNlbnQgdGhlIGNvbXBsZXRl
IHBpY3R1cmUsIHdoaWNoIGlzIHdoeSBJIGJlbGlldmUgdGhhdCBkZXNjcmliaW5nIHByb2ZpbGVz
IHVzaW5nIElEIFRva2VucyBhbmQgdGhlIEZvcm0gUG9zdCBSZXNwb25zZSBNb2RlIGFyZSBpbiBz
Y29wZS4NCj4+Pj4+IA0KPj4+Pj4gIA0KPj4+Pj4gDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPj4+Pj4gDQo+Pj4+
PiAgDQo+Pj4+PiANCj4+Pj4+IEZyb206IE9BdXRoIA0KPj4+Pj4gPG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc+DQo+Pj4+PiAgT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KPj4+Pj4gU2VudDogVHVl
c2RheSwgTm92ZW1iZXIgMjAsIDIwMTggNzo0NyBBTQ0KPj4+Pj4gVG86IA0KPj4+Pj4gb2F1dGhA
aWV0Zi5vcmcNCj4+Pj4+IA0KPj4+Pj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggU2Vj
dXJpdHkgVG9waWNzIC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBp
bXBsaWNpdA0KPj4+Pj4gDQo+Pj4+PiAgDQo+Pj4+PiANCj4+Pj4+IFllcyB0aGUgYXRfaGFzaCBw
cm90ZWN0cyB0aGUgY2xpZW50IGZyb20gYWNjZXB0aW5nIGFuIGluamVjdGVkIEFULiANCj4+Pj4+
IA0KPj4+Pj4gVW5mb3J0dW5hdGVseSBpdCBkb2Vzbid0IGRvIGFueXRoaW5nIHRvIHByb3RlY3Qg
YWdhaW5zdCBsZWFrYWdlIGluIGxvZ3Mgb3IgcmVkaXJlY3RzLg0KPj4+Pj4gDQo+Pj4+PiBTbyB3
aXRob3V0IHRoZSBBVCB1c2luZyBzb21lIHNvcnQgb2YgUE9QIG1lY2hhbmlzbSBpdCBpcyBoYXJk
IHRvIHNheSBzZW5kaW5nIGl0IGluIGEgcmVkaXJlY3QgaXMgYSBnb29kIHNlY3VyaXR5IHByYWN0
aWNlLg0KPj4+Pj4gDQo+Pj4+PiBKb2huIEIuDQo+Pj4+PiANCj4+Pj4+IE9uIDExLzIwLzIwMTgg
NDozNSBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gSGkgTWlr
ZSwgDQo+Pj4+PiAgDQo+Pj4+PiBJIGFncmVlIHRoYXQgT0lEQyBoeWJyaWQgZmxvd3Mgb2ZmZXIg
YWRkaXRpb25hbCBzZWN1cml0eSBvdmVyIHRoZSBPQXV0aCBpbXBsaWNpdCBncmFudCBhbmQgYXJl
IHVzZWQgaW4gdGhlIHdpbGQuIE9uIG15IHNsaWRlcyBhbmQgaW4gdGhlIGluaXRpYWwgdmVyc2lv
biBvZiB0aGUgbmV3IHNlY3Rpb24sIHdlIGhhZCBpbmNsdWRlZCB0aGUgaHlicmlkIE9JREMgZmxv
d3MgYmVjYXVzZSBvZiB0aGVpciBrbm93biB0b2tlbiBpbmplY3Rpb24gY291bnRlcm1lYXN1cmVz
Lg0KPj4+Pj4gIA0KPj4+Pj4gSSBuZXZlcnRoZWxlc3MgZmVlbCB2ZXJ5IHVuY29tZm9ydGFibGUg
dG8gcmVjb21tZW5kIHRob3NlIGZsb3dzIGFuZCBhbnkgZmxvdyBpc3N1aW5nIGFjY2VzcyB0b2tl
bnMgaW4gdGhlIGZyb250IGNoYW5uZWwuIEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGRldGFpbGVkIHJl
dmlldyBvZiB0aGUgbmV3IHRleHQgd2UgcmVhbGl6ZWQgdHdvIGlzc3VlczogDQo+Pj4+PiAgDQo+
Pj4+PiAxKSBTaW5jZSB0aGUgYWNjZXNzIHRva2VuIGlzIGV4cG9zZWQgaW4gdGhlIFVSTCwgc3Vj
aCBmbG93cyBwb3NzZXNzIGEgc2lnbmlmaWNhbnRseSBoaWdoZXIgcmlzayB0byBsZWFrIHRoZSBh
Y2Nlc3MgdG9rZW4gKGUuZy4gdGhyb3VnaCBicm93c2VyIGhpc3RvcnksIG9wZW4gcmVkaXJlY3Rp
b24gYW5kIGV2ZW4gcmVmZXJyZXIgaGVhZGVycykgdGhhbiB0aGUgY29kZSBncmFudC4NCj4+Pj4+
IDIpIFRoZXJlIGlzIG5vIHZpYWJsZSB3YXkgdG8gc2VuZGVyIGNvbnN0cmFpbiBhY2Nlc3MgdG9r
ZW5zIGlzc3VlZCBpbiB0aGUgZnJvbnQgY2hhbm5lbC4gR2l2ZW4gdGhlIFdHIGRlY2lkZWQgdG8g
cmVjb21tZW5kIHVzZSBvZiBzZW5kZXIgY29uc3RyYWludCB0b2tlbnMgKA0KPj4+Pj4gaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTA5
I3NlY3Rpb24tMi4uLjINCj4+Pj4+ICksIGl0IHNlZW1zIGNvbnRyYWRpY3RvcnkgdG8gcmVjb21t
ZW5kIHJlc3BvbnNlIHR5cGVzIG5vdCBzdXBwb3J0aW5nIHN1Y2ggYW4gYXBwcm9hY2guIA0KPj4+
Pj4gIA0KPj4+Pj4ga2luZCByZWdhcmRzLA0KPj4+Pj4gVG9yc3Rlbi4gDQo+Pj4+PiAgDQo+Pj4+
PiBBbSAxOS4xMS4yMDE4IHVtIDIzOjEzIHNjaHJpZWIgTWlrZSBKb25lcyANCj4+Pj4+IDxNaWNo
YWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4+Pj4+IDoNCj4+Pj4+
ICANCj4+Pj4+IFRoaXMgZGVzY3JpcHRpb24gb2YgdGhlIHNpdHVhdGlvbiBpcyBhbiBvdmVyc2lt
cGxpZmljYXRpb24uLiAgT3BlbklEIENvbm5lY3Qgc2VjdXJlcyB0aGUgaW1wbGljaXQgZmxvdyBh
Z2FpbnN0IHRva2VuIGluamVjdGlvbiBhdHRhY2tzIGJ5IGluY2x1ZGluZyB0aGUgYXRfaGFzaCAo
YWNjZXNzIHRva2VuIGhhc2gpIGluIHRoZSBJRCBUb2tlbiwgZW5hYmxpbmcgdGhlIGNsaWVudCB0
byB2YWxpZGF0ZSB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2FzIGNyZWF0ZWQgYnkgdGhlIGlzc3Vl
ciBpbiB0aGUgSUQgVG9rZW4gKHdoaWNoIGlzIGFsc28gdGhlIE9BdXRoIElzc3VlciwgYXMgZGVz
Y3JpYmVkIGluIFJGQyA4NDE0KS4gIChOb3RlIHRoYXQgdGhpcyBtaXRpZ2F0aW9uIHdhcyBkZXNj
cmliZWQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi4pDQo+Pj4+PiAgDQo+
Pj4+PiBHaXZlbiB0aGUgcHJldmFsZW5jZSBvZiB0aGlzIGtub3duLWdvb2Qgc29sdXRpb24gZm9y
IHNlY3VyaW5nIHRoZSBpbXBsaWNpdCBmbG93LCBJIHdvdWxkIHJlcXVlc3QgdGhhdCB0aGUgZHJh
ZnQgYmUgdXBkYXRlZCB0byBkZXNjcmliZSB0aGlzIG1pdGlnYXRpb24uICBBdCB0aGUgc2FtZSB0
aW1lLCBJ4oCZbSBmaW5lIHdpdGggdGhlIGRyYWZ0IHJlY29tbWVuZGluZyB0aGUgY29kZSBmbG93
IG92ZXIgdGhlIGltcGxpY2l0IGZsb3cgd2hlbiB0aGlzIG1pdGlnYXRpb24gaXMgbm90IHVzZWQu
DQo+Pj4+PiAgDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmsgeW91LA0KPj4+Pj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN
Cj4+Pj4+ICANCj4+Pj4+IEZyb206IE9BdXRoIA0KPj4+Pj4gPG9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmc+DQo+Pj4+PiAgT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQo+Pj4+PiBTZW50OiBN
b25kYXksIE5vdmVtYmVyIDE5LCAyMDE4IDI6MzQgQU0NCj4+Pj4+IFRvOiBvYXV0aCANCj4+Pj4+
IDxvYXV0aEBpZXRmLm9yZz4NCj4+Pj4+IA0KPj4+Pj4gU3ViamVjdDogW09BVVRILVdHXSBPQXV0
aCBTZWN1cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFk
IG9mIGltcGxpY2l0DQo+Pj4+PiAgDQo+Pj4+PiBIaSBhbGwsDQo+Pj4+PiAgDQo+Pj4+PiBUaGUg
YXV0aG9ycyBvZiB0aGUgT0F1dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNhbWUgdG8gdGhlIGNv
bmNsdXNpb24gdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVseSBzZWN1cmUgdGhl
IGltcGxpY2l0IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2UgcG90ZW50aWFsIHNv
bHV0aW9ucyBsaWtlIHRva2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFybHkgc3RhZ2Ug
b2YgYWRvcHRpb24uIEZvciB0aGlzIHJlYXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dzIGJyb3dz
ZXItYmFzZWQgYXBwcyB0byBzZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgVG9y
c3RlbiBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiB0
aGUgaW1wbGljaXQgZ3JhbnQgaW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9uIChzZWVo
dHRwczovLw0KPj4+Pj4gZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxz
L3NsaWRlcy0xMDMtb2F1dGgtc2Vzc2ItZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3Mt
MDENCj4+Pj4+ICkuDQo+Pj4+PiAgDQo+Pj4+PiBBIGh1bSBpbiB0aGUgcm9vbSBhdCBJRVRGIzEw
MyBjb25jbHVkZWQgc3Ryb25nIHN1cHBvcnQgZm9yIGhpcyByZWNvbW1lbmRhdGlvbnMuIFdlIHdv
dWxkIGxpa2UgdG8gY29uZmlybSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4NCj4+Pj4+ICAN
Cj4+Pj4+IFBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2UgYnkgRGVjZW1iZXIgM3JkLg0KPj4+Pj4g
IA0KPj4+Pj4gQ2lhbw0KPj4+Pj4gSGFubmVzICYgUmlmYWF0DQo+Pj4+PiAgDQo+Pj4+PiBJTVBP
UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l
bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh
cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp
bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg
cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv
cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+Pj4+PiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0
DQo+Pj4+PiANCj4+Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+PiANCj4+Pj4+ICANCj4+Pj4+IA0KPj4+Pj4g
DQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IA0KPj4+Pj4gT0F1dGhAaWV0
Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IA0K
Pj4+Pj4gDQo+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gDQo+Pj4+
IE9BdXRoQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgNCj4+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiANCj4gDQo+IC0tIA0KPiBo
YW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldQ0KPiBabWFydFpvbmUgSUFNIC0gd3d3LnptYXJ0em9u
ZS5ldQ0KDQo=


From nobody Thu Nov 29 06:02:55 2018
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 41553129533 for ; Thu, 29 Nov 2018 06:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.279
X-Spam-Level: 
X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.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 J3xyMwGHhk0K for ; Thu, 29 Nov 2018 06:02:50 -0800 (PST)
Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [134.147.42.229]) (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 1F4B5128CE4 for ; Thu, 29 Nov 2018 06:02:50 -0800 (PST)
Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 435K3W492Nz4yfS for ; Thu, 29 Nov 2018 15:02:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1543500167; bh=4A/ZCUXGRgjDWdu056ygJzfpkWpvNDSmNfWBMj0uKk0=; h=From:Subject:Cc:References:Date:In-Reply-To:From; b=CizJWcMbYKMHACTFn0hMnLkRWCMHRgWG+1/9JWJ5IIVowPd2NmEqd0Ypw95dxcWhJ D27elZI+B33nm7L37FEA7RtulacW/LVwXDARGlvYNM6RfPqNYWuJzm78mfyE39O7XQ 9EXf3izW462916epQvRNCS0h7IZT9vUZ8ANhneaA=
Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 435K3W3Gf9z4yhJ for ; Thu, 29 Nov 2018 15:02:47 +0100 (CET)
X-Envelope-Sender: 
X-RUB-Notes: Internal origin=134.147.42.227
Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 435K3W2ljJz4yfS for ; Thu, 29 Nov 2018 15:02:46 +0100 (CET)
Received: from excelsior.nds.ruhr-uni-bochum.de (dyn-082310aa78cef71000129000.nds.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:9:2100:17f:ec87:aa01:3280]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 435K3V1TNgzysy for ; Thu, 29 Nov 2018 15:02:46 +0100 (CET)
From: Christian Mainka 
Cc: oauth@ietf.org
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>    
Openpgp: preference=signencrypt
Autocrypt: addr=Christian.Mainka@rub.de; prefer-encrypt=mutual; keydata= xsFNBEefF5YBEADa0W+FyzUZStHhp8YmnjPZm4Bws4sKmwXRxfSJp89Z5r79kxaXdLErifPS w4uyQuhosugg65KlNwFgtMprtGeEvQpqnsGFz1ZJFnMDZnMho48NDXdFA8KWUUTFHZTlv8fy NOH3EQ/jcWfq2VizuIewJNqyrVpbUimosQmLsBB9xLeiT6u8B0zh0hCYhnX77Y87MnPYlW1T fxT7mjGe2SJnGdm85CH2Q/9aIj7OTA5vZhrCdrbddo0c5h6WMqeYSbxUYrJ0/zBHFpfbWmFD OIEtvYLjKhEtjIpvKL6U7fJaJNPqTFp+Y0T+folxRMYIxWPMtacnvMa9YqBiEmdK8VyFBMmi gkhVqdrTKLtsxQrutKaRxJ+ACbEdNuGpjnK5ON+sNmPTmqs816x+JJGLu1ci03gbCIXXvwXF /pV2tX/dBGbTgYWZ4DAIdIJoHKgAjC0r64409nDwb4BKWtEDTAxbP+2mPVqH0uthGBz8J29Q zWUDztfy3AK7nZjhg0NRabBUYe6PPGaV81tluH5nEMvvcXSstbwAcg8BPmuSGp3G6VE4BxS6 bnRIbL9XQP24xn3TFiAus79Wmzz3yBangmUCo616qWJqpqie6arce+Zce8szwMIJD753gEo8 L+GXJ8H/jQWS8C9qPvmD9GlW+RaWoTRb4BkTds305e0HPyl9aQARAQABzSpDaHJpc3RpYW4g TWFpbmthIDxDaHJpc3RpYW4uTWFpbmthQHJ1Yi5kZT7CwXsEEwECACUCGyMGCwkIBwMCBhUI AgkKCwQWAgMBAh4BAheABQJRCCWaAhkBAAoJEBxg1ZHbyZM9PuYP/3a/1kPLhy11Hjqz12SJ oQi10JlTpRILcWXAoUOFmOQlPkMzwp+jvyg0XMW7VHfRpNyFDhMofAsibVFj6OvWRmg6Mrps z0IwbH6k7ukcb0Uvv/EWhBHvqDpkGdIo0iAkoyuygTIVsLRjJmU0QrnaS9J/QQTQSzpMG0Y/ NXmt8a6j0aR92hYllhTdWbHGgQlcMa6RJBBR9fExoOlc9LZM3gyFI89STpWZcvFviO6VYlIK TqCFiH8W4u/yzP3fvjz2JLSS3SAAyd4zoaqMGSDqb97iJI39jja2BrJCkHDGpb0god0IMz+L MSXFc5faewBy5HfIsOj2tt4J9gUoKOwpfIDccOMirO5qywo5w79ofzx4AWDl+O1q4SXJmFUQ WdnanM9TwR0wRmFa2q5ZugHlQbIdGMqRpy5XrcTBcSoQRxGiFdjchJAYeNNQnOIMdHtolcSH pwKUc0CLIjrzMMnAui1WIr8jcdxiuqrUEJDZWiVZhxetq1An8lDX8q5IDmq1ZnS5PfmlOpMm L3QduEEqQQ40St2pbfCyCMz19jK/d6KblVoG4MhGq1ofIKu6KfWZmIEsiLGidNPByL84AB+8 B9VArlS5pG4esIF5c5nyv1InlNCz5aNZXzRxvJVqYEcTnM6f+29BDNGCPGfIVCyiocYCE2Z6 TSA//VyQXMGdxB1UzsFNBEefF9IBEACaoaSOVrtoEx+1FFoFHro9mI2rViLcHY44EyPBSlgU QgNeyMBnV9yrFf2awpZimXkXYOJ39dtDKOleiJ+XpM7n0tEDJ+tPz4Avc2iQ4RMyIndrM4ok mfmTHuWZkV5ZJAERF59hMRDp8dRBzFDBXDEVhFsOZGFaf5qJE78774Jb/I0Sh6wn4FY2Pr/Z dEA5FOlzHNa8LlMv2Qeh8t+HdL/ySTDGJAI2qTeszqWtDSnMT+ExYH+zWCiYYw0/2/U01L/Q n5wNiEihAv4XYkkQsMecMw9H8zZ7Ob1hrSwWR1pYJIiJ94cHDTeLIq2bY0yHuxiQLbUMyCkP QhTXvz1mdkzVHlhMZefHkeo25dvbnCot6JoWOyyCghEixtMeRpYReKOmkHDVMRLqo1VJSxYh yrmmdZUfJjTBqqpl4nvYPj5cLvogI2CpGeKFgkfzZ3/OIMamipJOLQHoX80Y04Ug9k5BxUHJ PPX054g+GB6YT1xYncPDj+J+aP1EvOSMh4DyAspB9gZoI5Xx8swL3UvQySpakgHoGeOfz0ws YOijoGW9UCkwqIWbrQ44Y+SgjxKEp3rkZ0a5PCcOSNPynIIxyWukbIDk6nhqp/Ni3vzpoAjG Hs05w+YqP/sv8wykeK/2JejNkpZIDVopnvXFDc5QLc+cn70X1Ny9sYYj1+/KmS7d4QARAQAB wsFfBBgBAgAJBQJHnxfSAhsMAAoJEBxg1ZHbyZM9DIIP/iBxx1yb3Iy7m23GcNsfWRUnSmkA dkLf9VoEESvxtuC1l8AEUCeoTiQ0LSasZ2asV6yoMQOStv3eW6/WL6ZUL0jTm7x3Ki0/Ej+o bnKpCKV3E45ku7unilXI4+TSPXxmwQOi0ZVa+MwZn7jhwQuk60EgBUW0VyPmpgYnxtcb2HGG Rj3V06A+T2963AyrM6gFBDSm5ulSwKydLBDsbOpD9JXCvVrAFwCs8isa0snhhuipQZR3fKYh Q8pbCGSFYJ+BAgZuj02eeEQZP8J04LAYItcsuO01B27svDJRF6BcoYljfO6Cat625mxsjYvI TTsq0iCTx0d/OOee7nPhChB7bsRm9/F//N0STfbQVRyt0RZS0uGzo5lESk+TnlteNx6oJUpW TgO7FXr4j2ZpSGznjV57Sjgh8QttUubIDPrjFSGiY8z0DxZrIdWVtgDj2LeVnjql5eZpOn2B Ce/+dRg581t5vZvCaIlpu+YBxWmJHU7VPyAY6Sq4xY6JW6B3yqkqTmOPE/ARUIYRzHPmv15k CINS/Jpw6fWTzsD1HPaRVVEwDuFRSxaKtoDFOB7DktTf2NsyKDC0GN3w6x+I9VUHjJePK3wX qjQs0g/DXc7OBJV+1nBkj0ZlHqtuiNomfhycC18ZvUs6re/gu2jSSK3ME5Tll/qYGq5DcuzS TSnNS1Q3
Message-ID: <065bba73-eade-2f07-038f-8afa708e38be@rub.de>
Date: Thu, 29 Nov 2018 15:02:46 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------76FA1FF3873060C479544F33"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de
X-Virus-Status: Clean
Archived-At: 
Subject: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 29 Nov 2018 14:02:54 -0000

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

Hi,

thanks for pointing this out!
This was exactly what confused us during reading *-* the main threat we
see and which is not addressed is related to the app impersonation attack.
Even PKCE does not help against the app impersonation attack.

So a "Native App + Dynamic Client Registration" can be seen at a
different "confidentiality level" than a "public client", because every
native App can dynamically register itself on the IdP.
The IdP cannot distinguish, for example, an honest native client from an
malicious client starting an app impersonation attack.

We agree that, e.g., a leaked code cannot be redeemed unless you have
the respective client_id/client_secret.

But... we asked ourselfs, in which cases does a code leak?

1) In the front-channel. In this case, it is true that no client
credentials leak and an attacker cannot redeem the code.

2) In the back-channel. But if this channel is insecure, you directly
get client credentials (unless client_secret_jwt is used as pointed out
by George).

So, Dynamic Client Registration only helps if the code leaks alone (as
in 1.), or if it leaks on different levels (e.g. logfiles).

On the opposite site, if Dynamic Registration is available, an attacker
can very easily do an app impersonation attack by registering on the
IdP. To be clear, it is not "impersonation" as in the "one secret per
software" scenario, because different client_id and client_secret is
used, but to the best of my knowledge, the IdP cannot distinguish
between an honest app and an app impersonation client that has simply
registered.

In addition, if the IdP supports the dynamic client registration:
How can the IdP distinguish between confidential and public/native clients?
With respect to the consent page, which must be shown every time for
native apps, this is an important issue, which should be addressed properly.

Best Regards
Vladi/Christian

Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle:
> It should be noted that “traditional†confidential clients with registered return URLs and server-side secrets may provide a higher degree of confidence in the true identity of the client that doesn’t carry over to confidential native app clients. A native app instance’s registration call is necessarily unauthenticated (for the same reasons that statically registered native app clients are public clients), so the Client Impersonation concerns described in section 8.6 of RFC8252 still apply.
> --
> Annabelle Richard Backman
> AWS Identity
>
>
> From: OAuth  on behalf of Filip Skokan 
> Date: Wednesday, November 28, 2018 at 9:11 AM
> To: George Fletcher 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>
> Apologies, I missed the issued in "issued a shared secret", just reading "shared secret" alone is the exact opposite of a per-instance secret. The rest is clear and as you say it brings the benefit of the secret never being sent over the wire (except during the initial registration via TLS).
>
> Best,
> Filip
>
>
> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher > wrote:
> It's "confidential" in that the shared secret is unique to that app instance registration (as Dennis described in his response). If an attacker gets my phone and compromises the data stored on my device, they only get the secret for my device. This is no different than a server side client having their client secret compromised through an attack (and in some ways is better because it's instance specific).
>
> The main point I was trying to make, is that the 'client_secret_jwt' method allows the client to never send the shared secret across the wire as is created in the default OAuth2 HTTP Basic Authentication method.
>
> Thanks,
> George
> On 11/28/18 11:03 AM, Filip Skokan wrote:
> Hi George,
>
> #2 doesn't seem confidential, it's still a secret shared amongst installations and anyone reverse engineering the apk, extracting the secret, can form the client_secret_jwt client_assertion with it just fine.
>
> Best,
> Filip
>
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher > wrote:
> In addition, a few additional patterns are enabled...
>
> 1. The native app can generate a public/private key pair and then use private_secret_jwt as the client credential validation method via the client credentials flow (defined in OpenID Connect).
>
> 2. Maybe more simply, if the native app is issued a shared secret, the app can use client_secret_jwt method for client authentication which ensures the shared secret never leaves the device. (Again defined in the OpenID Connect spec).
>
> 3. Once the native app instance has credentials, they can be used for additional securing of app API transactions in addition to just the OAuth2/OpenID Connect flows.
>
> Thanks,
> George
> On 11/27/18 3:28 PM, William Denniss wrote:
> If the secret is dynamically provisioned then you have a confidential client. Anyone reverse engineering their own installation of the native app would only extract their own client's credentials, as opposed to the shared secret of all installations. Having a confidential client means that requests to the token endpoint (code, refresh) are client authenticated, so PKCE wouldn't be needed.
>
> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka > wrote:
> Hi,
>
> we just stumbled upon this [1] statement:
> "Except when using a mechanism like Dynamic Client Registration
>    [RFC7591] to provision per-instance secrets, native apps are
>    classified as public clients ..."
>
> What does this mean for us? Native App + Dynamic Client Registration =
> Confidential Client?
> Which threats are covered if Dynamic Client Registration is used on
> Native Apps?
>
> Best Regards,
> Vladi/Christian
>
> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>
> --
> Dr.-Ing. Christian Mainka
> Horst Görtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universitätsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347
> http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
>
> _______________________________________________
> 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

-- 
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX


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


  
    
  
  
    
     Hi,
    
      
    
      thanks for pointing this out!
    
      This was exactly what confused us during reading - the
      main threat we see and which is not addressed is related to the
      app impersonation attack.
    
      Even PKCE does not help against the app impersonation attack.
    
      
    
      So a "Native App + Dynamic Client Registration" can be seen at a
      different "confidentiality level" than a "public client", because
      every native App can dynamically register itself on the IdP.
    
      The IdP cannot distinguish, for example, an honest native client
      from an malicious client starting an app impersonation attack.
    
      
    
      We agree that, e.g., a leaked code cannot be redeemed unless you
      have the respective client_id/client_secret.
    
      
    
      But... we asked ourselfs, in which cases does a code leak?
    
      
    
      1) In the front-channel. In this case, it is true that no client
      credentials leak and an attacker cannot redeem the code.
    
      
    
      2) In the back-channel. But if this channel is insecure, you
      directly get client credentials (unless client_secret_jwt is used
      as pointed out by George).
    
      
    
      So, Dynamic Client Registration only helps if the code leaks alone
      (as in 1.), or if it leaks on different levels (e.g. logfiles).
    
      
    
      On the opposite site, if Dynamic Registration is available, an
      attacker can very easily do an app impersonation attack by
      registering on the IdP. To be clear, it is not "impersonation" as
      in the "one secret per software" scenario, because different
      client_id and client_secret is used, but to the best of my
      knowledge, the IdP cannot distinguish between an honest app and an
      app impersonation client that has simply registered.
    
      
    
      In addition, if the IdP supports the dynamic client registration:
    
    
    How can the IdP
      distinguish between confidential and public/native clients?
    
      With respect to the consent page, which must be shown every time
      for native apps, this is an important issue, which should be
      addressed properly.
    
      
    
      Best Regards
    
      Vladi/Christian 
    
    
    
    

    
    
    
    
    Am 29.11.18 um 00:38 schrieb Richard
      Backman, Annabelle:
    
    
    
    
    
      
    It should be noted that “traditional†confidential clients with registered return URLs and server-side secrets may provide a higher degree of confidence in the true identity of the client that doesn’t carry over to confidential native app clients. A native app instance’s registration call is necessarily unauthenticated (for the same reasons that statically registered native app clients are public clients), so the Client Impersonation concerns described in section 8.6 of RFC8252<https://tools.ietf.org/html/rfc8252#section-8.6> still apply.
--
Annabelle Richard Backman
AWS Identity


From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Wednesday, November 28, 2018 at 9:11 AM
To: George Fletcher <gffletch@aol.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Apologies, I missed the issued in "issued a shared secret", just reading "shared secret" alone is the exact opposite of a per-instance secret. The rest is clear and as you say it brings the benefit of the secret never being sent over the wire (except during the initial registration via TLS).

Best,
Filip


On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffletch@aol.com<mailto:gffletch@aol.com>> wrote:
It's "confidential" in that the shared secret is unique to that app instance registration (as Dennis described in his response). If an attacker gets my phone and compromises the data stored on my device, they only get the secret for my device. This is no different than a server side client having their client secret compromised through an attack (and in some ways is better because it's instance specific).

The main point I was trying to make, is that the 'client_secret_jwt' method allows the client to never send the shared secret across the wire as is created in the default OAuth2 HTTP Basic Authentication method.

Thanks,
George
On 11/28/18 11:03 AM, Filip Skokan wrote:
Hi George,

#2 doesn't seem confidential, it's still a secret shared amongst installations and anyone reverse engineering the apk, extracting the secret, can form the client_secret_jwt client_assertion with it just fine.

Best,
Filip

On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org<mailto:40aol.com@dmarc.ietf.org>> wrote:
In addition, a few additional patterns are enabled...

1. The native app can generate a public/private key pair and then use private_secret_jwt as the client credential validation method via the client credentials flow (defined in OpenID Connect).

2. Maybe more simply, if the native app is issued a shared secret, the app can use client_secret_jwt method for client authentication which ensures the shared secret never leaves the device. (Again defined in the OpenID Connect spec).

3. Once the native app instance has credentials, they can be used for additional securing of app API transactions in addition to just the OAuth2/OpenID Connect flows.

Thanks,
George
On 11/27/18 3:28 PM, William Denniss wrote:
If the secret is dynamically provisioned then you have a confidential client. Anyone reverse engineering their own installation of the native app would only extract their own client's credentials, as opposed to the shared secret of all installations. Having a confidential client means that requests to the token endpoint (code, refresh) are client authenticated, so PKCE wouldn't be needed.

On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.Mainka=40rub.de@dmarc.ietf..org<mailto:Christian.Mainka=40rub.de@dmarc.ietf.org>> wrote:
Hi,

we just stumbled upon this [1] statement:
"Except when using a mechanism like Dynamic Client Registration
   [RFC7591] to provision per-instance secrets, native apps are
   classified as public clients ..."

What does this mean for us? Native App + Dynamic Client Registration =
Confidential Client?
Which threats are covered if Dynamic Client Registration is used on
Native Apps?

Best Regards,
Vladi/Christian

[1]: https://tools.ietf.org/html/rfc8252#section-8.4

--
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX


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




_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

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

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



_______________________________________________

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

    
    
    
    
    -- 
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX
    
  


--------------76FA1FF3873060C479544F33--


From nobody Thu Nov 29 06:16:08 2018
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 9C9B2130E0E for ; Thu, 29 Nov 2018 06:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 wf8wMhcJ4fm8 for ; Thu, 29 Nov 2018 06:15:58 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70F8130DF7 for ; Thu, 29 Nov 2018 06:15:52 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id 96so2082286wrb.2 for ; Thu, 29 Nov 2018 06:15:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Km+NkS/4OstVx6rmAiGfqzotD8tVKxo0XQyMGtdreY8=; b=oK1Ca5wHn6ZKs4Uf/lVLDgE7jny6Blw6Kk8LC8+RsBWgxQMAmPO5EHxZyi2NMNTxDx ytoHIFEdnZ/NSy0QsOhnvWWMOCyPU9GQkuJDoBf9789+2dsqHsOAFBbTlTg7mKFa4dJ7 KjTxExHNDIdsz8n3tUYoOOoHRZU0KueErev9LGUt2dOrpJFOzq9ql5pmXpo/jZUVjJhn Qp6OlTytE3mFUZyb8p60pm++vd+FjBj5ysOGbBvBkprlEyF7gtxAnpOjdvSWHD7mmMk4 fPBJvgbmcMpukLBdOGMn3G1sC4Uh7rI7cGYFsbURLb96O7gKp3u+kKlNDHhzrnHahry5 xckw==
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=Km+NkS/4OstVx6rmAiGfqzotD8tVKxo0XQyMGtdreY8=; b=B5e0rxp/qESam2LLRKHHtSqx3uwDRIH2hTg93+kk0s7N/z2ha9XpFDiaF6VRIhH84O iOZQ1DJ1W3H8M3fZ+oBjsMeq2YMc0RdyztS+UqwSGOrwRfpHJJ7pyrrwfNz88/odh4aV nPnZ9m6XYut9BEIwzI5mKo+hIViKQH6NVBT2KVf6ZinL0g9WPpkevpgLYafZ9HDkEYaq 4ov8ruMP/H+uDxOHvnIkQTi1XNPnoZWIuHagDznHIZE7qCjg09wk5cd8WwPpirjZq6ks gl5T4pUy5er+2b1bbeZZMJEVhHF2tl3wqopx4yr5DrAvGd7XsEDzuxUPhi4NsF9kq7/P Gs3A==
X-Gm-Message-State: AA+aEWaPAQcFRUWpbdCeRsExJHZ8Or4AvLj+0RTDdeHBL1NMigXCF81O u4PgRUwpSFQzesLsPvCCn7Q2W79l3OkC+nXBuAOWZA==
X-Google-Smtp-Source: AFSGD/XO5JzwkvSql4qPptK57/RkX21q8gNVeqCyIedtcZQ+maQoubO7cMzo/VeC3YBPDHJluVuAxb2VirX+QW5Y5DE=
X-Received: by 2002:adf:8264:: with SMTP id 91mr1531550wrb.312.1543500950477;  Thu, 29 Nov 2018 06:15:50 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>  
In-Reply-To: 
From: John Bradley 
Date: Thu, 29 Nov 2018 11:15:36 -0300
Message-ID: 
To: Torsten Lodderstedt 
Cc: Nat Sakimura , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000dd30a8057bce5124"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 29 Nov 2018 14:16:06 -0000

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

I am ok with that.

On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt 
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (only=
). It would allow
> =E2=80=9Etoken=E2=80=9C to be used if the token would sender constrained.=
 This completely
> ignores the fact implicit also shall be abandoned because of its
> vulnerability for access token injection.
>
> I therefore propose a modified text:
>
>    In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant. Furthermore, clients SHOULD only use other response types
> causing the authorization server to
>    issue an access token in the authorization response, if the particular
> response type detects access token
>    injection and the issued access tokens are sender-constrained.
>
> Or we just state:
>
>   In order to avoid these issues, Clients SHOULD NOT use the response typ=
e
> =E2=80=9Etoken". The response types
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the
> issued access tokens are not
> sender-constrained.
>
> >
> > In fact, I would further go and say MUST NOT but that probably is too
> much for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give
> implementors time to move/change.
>
> > Best,
> >
> > Nat
> >
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> >
> >
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> >
> > PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> > If you are not an intended recipient, please notify the sender and
> delete this e-mail.
> >
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > =E5=AE=9B=E5=85=88: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend a=
uthorization code
> instead of implicit
> >
> > Hi Nat,
> >
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> >>
> >> I would support
> >>
> >> 1) clearly defining Implicit as the flow that returns access token fro=
m
> the authorization endpoint ( some people confuses implicit as the flow th=
at
> returns ID Token in the front channel)
> >
> > That=E2=80=99s the current text:
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server to
> >    issue an access token in the authorization response.
> >
> > What would you like to modify?
> >
> >>
> >> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server to
> >    issue an access token in the authorization response, if this access
> tokens is not sender-constraint.
> >
> > What about this?
> >
> > kind regards,
> > Torsten.
> >
> >>
> >> Best,
> >>
> >> Nat
> >>
> >>
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> >>
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Hard=
t 
> =E3=81=AE=E4=BB=A3=E7=90=86)
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> >> Cc: oauth@ietf.org
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization
> code instead of implicit
> >>
> >> +1
> >>
> >> While there are various mechanisms to alleviate some of the issues of
> implicit, I don't think we can recommend specifics, and there may be futu=
re
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
> >>
> >> How about we recommend against using implicit alone?
> >>
> >>
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> >> Hi all,
> >>
> >> The authors of the OAuth Security Topics draft came to the conclusion
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM are =
in
> an early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
> ).
> >>
> >> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> >>
> >> Please provide a response by December 3rd.
> >>
> >> Ciao
> >>
> >> Hannes & Rifaat
> >>
> >>
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    I am ok with that.=C2=A0=C2=A0

    On Wed, Nov 28, 2018, 8:03 PM Torsten Loddersted=
t <torsten@lodderstedt.net wrote:

    
> Am 28.11.2018 um 23:50 schrieb n-sakimura <    n-sakimura@nri.co.jp>:
    
> 
    
> That works.
    

    
Good!
    

    
I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (only).=
 It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would sende=
r constrained. This completely ignores the fact implicit also shall be aban=
doned because of its vulnerability for access token injection. 
    

    
I therefore propose a modified text: 
    

    
=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the imp=
licit
    
=C2=A0 =C2=A0grant. Furthermore, clients SHOULD only use other response typ=
es causing the authorization server to
    
=C2=A0 =C2=A0issue an access token in the authorization response, if the pa=
rticular response type detects access token 
    
=C2=A0 =C2=A0injection and the issued access tokens are sender-constrained.=

    

    
Or we just state:
    

    
=C2=A0 In order to avoid these issues, Clients SHOULD NOT use the response =
type =E2=80=9Etoken". The response types
    
=E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=9C =
SOULD NOT be used, if the issued access tokens are not 
    
sender-constrained.
    

    
> 
    
> In fact, I would further go and say MUST NOT but that probably is too =
much for a security consideration.
    
> 
    

    
Mike suggested to go with a SHOULD NOT to get the message out but give impl=
ementors time to move/change.
    

    
> Best,
    
> 
    
> Nat
    
> 
    
> Nat Sakimura /     n-sakimura@nri.co.jp / +81-90-6013-6276
    
> 
    
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=
=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=
=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=
=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=
=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=
=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=
=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=
=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=
=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=
=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=
=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=
=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=
=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=
=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> 
    
> PLEASE READ :This e-mail is confidential and intended for the named re=
cipient only.
    
> If you are not an intended recipient, please notify the sender and del=
ete this e-mail.
    
>=C2=A0 
    
> =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodd=
erstedt.net>
    
> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> =E5=AE=9B=E5=85=88: n-sakimura
    
> Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
    
> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend =
authorization code instead of implicit
    
>=C2=A0 
    
> Hi Nat, 
    
> 
    
>> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.=
jp>:
    
>> 
    
>> I would support
    
>> 
    
>> 1) clearly defining Implicit as the flow that returns access token=
 from the authorization endpoint ( some people confuses implicit as the flo=
w that returns ID Token in the front channel)
    
> 
    
> That=E2=80=99s the current text: 
    
> 
    
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>=C2=A0 =C2=A0 grant or any other response type causing the authorizatio=
n server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response.
    
> 
    
> What would you like to modify? 
    
> 
    
>> 
    
>> 2) Banning the returning of the access token that are not sender c=
onstrained from the authorization endpoint
    
> 
    
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>=C2=A0 =C2=A0 grant or any other response type causing the authorizatio=
n server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
his access tokens is not sender-constraint.
    
> 
    
> What about this?
    
> 
    
> kind regards,
    
> Torsten.
    
> 
    
>> 
    
>> Best,
    
>> 
    
>> Nat
    
>> 
    
>> 
    
>> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
>>=C2=A0 
    
>> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org<=
/a>> (Dick Hardt <dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=
=E7=90=86)
    
>> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,=
 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
>> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
>> Cc: oauth@ietf.org
    
>> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm=
end authorization code instead of implicit
    
>>=C2=A0 
    
>> +1
    
>> 
    
>> While there are various mechanisms to alleviate some of the issues=
 of implicit, I don't think we can recommend specifics, and there may b=
e future ones in the future. I think we all agree that implicit without any=
 mitigation is problematic. 
    
>> 
    
>> How about we recommend against using implicit alone? 
    
>> 
    
>> 
    
>> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hanne=
s.Tschofenig@arm.com> wrote:
    
>> Hi all,
    
>> 
    
>> The authors of the OAuth Security Topics draft came to the conclus=
ion that it is not possible to adequately secure the implicit flow against =
token injection since potential solutions like token binding or JARM are in=
 an early stage of adoption. For this reason, and since CORS allows browser=
-based apps to send requests to the token endpoint, Torsten suggested to us=
e the authorization code instead of the implicit grant in call cases in his=
 presentation (see https://datatracker.ietf.org/meeting=
/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
    
>> 
    
>> A hum in the room at IETF#103 concluded strong support for his rec=
ommendations. We would like to confirm the discussion on the list.
    
>> 
    
>> Please provide a response by December 3rd.
    
>> 
    
>> Ciao
    
>> 
    
>> Hannes & Rifaat
    
>> 
    
>>=C2=A0 
    
>> 
    
>> IMPORTANT NOTICE: The contents of this email and any attachments a=
re confidential and may also be privileged. If you are not the intended rec=
ipient, please notify the sender immediately and do not disclose the conten=
ts to any other person, use it for any purpose, or store or copy the inform=
ation in any medium. Thank you.
    
>> _______________________________________________
    
>> OAuth mailing list
    
>>     OAuth@ietf.org
    
>> https://www.ietf.org/mailman/listinfo=
/oauth
    
>> _______________________________________________
    
>> OAuth mailing list
    
>> OAuth@ietf.org
    
>> https://www.ietf.org/mailman/listinfo=
/oauth
    
> 
    

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

    

--000000000000dd30a8057bce5124--


From nobody Thu Nov 29 08:18:56 2018
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 E4940130DCD for ; Thu, 29 Nov 2018 08:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level: 
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 vqOl51TPIqw0 for ; Thu, 29 Nov 2018 08:18:51 -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 AAA3B1271FF for ; Thu, 29 Nov 2018 08:18:50 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id j10so2498918wru.4 for ; Thu, 29 Nov 2018 08:18:50 -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=aUqVt4+KKG/b3JudKlVHgMe54hb9K0YrvgmKZsZlAB8=; b=rlOmqrN8/nYE9Pi+WwqSBkME71MEqlJnRAHWIRGDSwGReQyB6WvX9vmAQ5ZbUPTJ06 h+26/hwgwkL9ABAyWJBbhnmB9fZfCi1cmSPtEogJ6XR+ZbALM28ZSPd6Ix40ObtRDnrI 8p9ISNbQGThuc8HllgUhF72NEOW80giww4vL4J3ipdzsSVO5OS2J81AEudpBBwsOrPQw ZuOJ/rnQ57y1ZNig8DDo50VpV0DaZpCGgS4u8fSupyj6JQIEaRBYFwp2laXQtYyIGgxF fBQrslgpjUx9Q7akjyDz7A1cyLI9OopatCmXcHyqLuE7Wv3esEEX7XgfmHYiaAAl4b5r auJw==
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=aUqVt4+KKG/b3JudKlVHgMe54hb9K0YrvgmKZsZlAB8=; b=aTIlRvlsSXMRNlOal5V9Gdz6o2ZyeCL9v5lMKzdgh6LL0Igi2Lww4sRShcCeXL+ifS nhI3ehgswl9YFa54v6yxg9VksQwtnSSLociOifaybtLenvNx8hau8/waqJjHh+AuYNL6 D3mshL2RU9+BCFqu//Uy5T5nZvv2n74d2hm0jLca5lqWpEy7mRxu7ETl+lq9blVD5QBF RTrB/IMknJm+HtbJN5/mptNklqFnAj28fFsrx0qomA46UvnZqFCNGbwY8TQ91621bn1f 8Z/jdvqdzUCuvVILfqM4HFDROcOZ3Mjh1eVxfF4DkRciqmsYPvCPjylkLC9P/xeKrBKv XDuA==
X-Gm-Message-State: AA+aEWbPoyOJmEsTBzsQVkvb91+UwyHqC010BjeZF+Qm2kV8pzsI15wE ROdQRXSGm2qjAkMhWXjBryPGJ+HY71I=
X-Google-Smtp-Source: AFSGD/WuHRo8zRJWTaWJacsMwgNk6pPgt8h2jby+FGZziQ/4/4q6Ub1KXds69TsV7FyxCNwYcC8VSg==
X-Received: by 2002:a5d:5089:: with SMTP id a9mr2042503wrt.327.1543508328671;  Thu, 29 Nov 2018 08:18:48 -0800 (PST)
Received: from [192.168.78.172] (glasgow.emobix.co.uk. [87.117.93.88]) by smtp.gmail.com with ESMTPSA id s202sm3268238wme.40.2018.11.29.08.18.47 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Nov 2018 08:18:47 -0800 (PST)
From: Joseph Heenan 
Content-Type: multipart/alternative; boundary="Apple-Mail=_71790711-515E-446E-B864-8A8F9DAF04BC"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Thu, 29 Nov 2018 16:18:46 +0000
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>     <065bba73-eade-2f07-038f-8afa708e38be@rub.de>
To: oauth 
In-Reply-To: <065bba73-eade-2f07-038f-8afa708e38be@rub.de>
Message-Id: <44FD54EC-6506-499E-AD98-65F8D04AAD41@authlete.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 29 Nov 2018 16:18:55 -0000

--Apple-Mail=_71790711-515E-446E-B864-8A8F9DAF04BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

It=E2=80=99s worth adding that a per-instance dynamic registration of a =
native client can still imply a higher level of trust than a public =
client and registration isn=E2=80=99t necessarily unauthenticated. =
https://tools.ietf.org/html/rfc7591 defines an =E2=80=9Cinitial access =
token=E2=80=9D:

> OAuth 2.0 access token optionally issued by an authorization
> server to a developer or client and used to authorize calls to the
> client registration endpoint.  The type and format of this token
> are likely service specific and are out of scope for this
> specification.  The means by which the authorization server issues
> this token as well as the means by which the registration endpoint
> validates this token are out of scope for this specification.  Use
> of an initial access token is required when the authorization
> server limits the parties that can register a client.

This can be used [for example] to bind a client to a specific user, =
though the bootstrapping can be a little involved and potentially the =
bootstrapping still has weaknesses. Use of white box crypto (or other =
tools like device attestations) can potentially also bring dynamically =
registered native apps up to a sufficiently trusted level.

Joseph


> On 29 Nov 2018, at 14:02, Christian Mainka =
 wrote:
>=20
> Hi,
>=20
> thanks for pointing this out!
> This was exactly what confused us during reading - the main threat we =
see and which is not addressed is related to the app impersonation =
attack.
> Even PKCE does not help against the app impersonation attack.
>=20
> So a "Native App + Dynamic Client Registration" can be seen at a =
different "confidentiality level" than a "public client", because every =
native App can dynamically register itself on the IdP.
> The IdP cannot distinguish, for example, an honest native client from =
an malicious client starting an app impersonation attack.
>=20
> We agree that, e.g., a leaked code cannot be redeemed unless you have =
the respective client_id/client_secret.
>=20
> But... we asked ourselfs, in which cases does a code leak?
>=20
> 1) In the front-channel. In this case, it is true that no client =
credentials leak and an attacker cannot redeem the code.
>=20
> 2) In the back-channel. But if this channel is insecure, you directly =
get client credentials (unless client_secret_jwt is used as pointed out =
by George).
>=20
> So, Dynamic Client Registration only helps if the code leaks alone (as =
in 1.), or if it leaks on different levels (e.g. logfiles).
>=20
> On the opposite site, if Dynamic Registration is available, an =
attacker can very easily do an app impersonation attack by registering =
on the IdP. To be clear, it is not "impersonation" as in the "one secret =
per software" scenario, because different client_id and client_secret is =
used, but to the best of my knowledge, the IdP cannot distinguish =
between an honest app and an app impersonation client that has simply =
registered.
>=20
> In addition, if the IdP supports the dynamic client registration:
> How can the IdP distinguish between confidential and public/native =
clients?
> With respect to the consent page, which must be shown every time for =
native apps, this is an important issue, which should be addressed =
properly.
>=20
> Best Regards
> Vladi/Christian=20
>=20
> Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle:
>> It should be noted that =E2=80=9Ctraditional=E2=80=9D confidential =
clients with registered return URLs and server-side secrets may provide =
a higher degree of confidence in the true identity of the client that =
doesn=E2=80=99t carry over to confidential native app clients. A native =
app instance=E2=80=99s registration call is necessarily unauthenticated =
(for the same reasons that statically registered native app clients are =
public clients), so the Client Impersonation concerns described in =
section 8.6 of RFC8252 =
 still apply.
>> --
>> Annabelle Richard Backman
>> AWS Identity
>>=20
>>=20
>> From: OAuth   =
on behalf of Filip Skokan  =

>> Date: Wednesday, November 28, 2018 at 9:11 AM
>> To: George Fletcher  
>> Cc: oauth  
>> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>>=20
>> Apologies, I missed the issued in "issued a shared secret", just =
reading "shared secret" alone is the exact opposite of a per-instance =
secret. The rest is clear and as you say it brings the benefit of the =
secret never being sent over the wire (except during the initial =
registration via TLS).
>>=20
>> Best,
>> Filip
>>=20
>>=20
>> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher  =
> wrote:
>> It's "confidential" in that the shared secret is unique to that app =
instance registration (as Dennis described in his response). If an =
attacker gets my phone and compromises the data stored on my device, =
they only get the secret for my device. This is no different than a =
server side client having their client secret compromised through an =
attack (and in some ways is better because it's instance specific).
>>=20
>> The main point I was trying to make, is that the 'client_secret_jwt' =
method allows the client to never send the shared secret across the wire =
as is created in the default OAuth2 HTTP Basic Authentication method.
>>=20
>> Thanks,
>> George
>> On 11/28/18 11:03 AM, Filip Skokan wrote:
>> Hi George,
>>=20
>> #2 doesn't seem confidential, it's still a secret shared amongst =
installations and anyone reverse engineering the apk, extracting the =
secret, can form the client_secret_jwt client_assertion with it just =
fine.
>>=20
>> Best,
>> Filip
>>=20
>> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher =
 > wrote:
>> In addition, a few additional patterns are enabled...
>>=20
>> 1. The native app can generate a public/private key pair and then use =
private_secret_jwt as the client credential validation method via the =
client credentials flow (defined in OpenID Connect).
>>=20
>> 2. Maybe more simply, if the native app is issued a shared secret, =
the app can use client_secret_jwt method for client authentication which =
ensures the shared secret never leaves the device. (Again defined in the =
OpenID Connect spec).
>>=20
>> 3. Once the native app instance has credentials, they can be used for =
additional securing of app API transactions in addition to just the =
OAuth2/OpenID Connect flows.
>>=20
>> Thanks,
>> George
>> On 11/27/18 3:28 PM, William Denniss wrote:
>> If the secret is dynamically provisioned then you have a confidential =
client. Anyone reverse engineering their own installation of the native =
app would only extract their own client's credentials, as opposed to the =
shared secret of all installations. Having a confidential client means =
that requests to the token endpoint (code, refresh) are client =
authenticated, so PKCE wouldn't be needed.
>>=20
>> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka =
 =
> wrote:
>> Hi,
>>=20
>> we just stumbled upon this [1] statement:
>> "Except when using a mechanism like Dynamic Client Registration
>>    [RFC7591] to provision per-instance secrets, native apps are
>>    classified as public clients ..."
>>=20
>> What does this mean for us? Native App + Dynamic Client Registration =
=3D
>> Confidential Client?
>> Which threats are covered if Dynamic Client Registration is used on
>> Native Apps?
>>=20
>> Best Regards,
>> Vladi/Christian
>>=20
>> [1]: https://tools.ietf.org/html/rfc8252#section-8.4 =

>>=20
>> --
>> Dr.-Ing. Christian Mainka
>> Horst G=C3=B6rtz Institute for IT-Security
>> Chair for Network and Data Security
>> Ruhr-University Bochum, Germany
>>=20
>> Universit=C3=A4tsstr. 150, ID 2/463
>> D-44801 Bochum, Germany
>>=20
>> Telefon: +49 (0) 234 / 32-26796
>> Fax: +49 (0) 234 / 32-14347
>> http://nds.rub.de/chair/people/cmainka/ =

>> @CheariX
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org  =

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

>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> OAuth mailing list
>>=20
>> OAuth@ietf.org  =

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

>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org  =

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

>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> OAuth mailing list
>>=20
>> OAuth@ietf.org  =

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

> --=20
> Dr.-Ing. Christian Mainka
> Horst G=C3=B6rtz Institute for IT-Security=20
> Chair for Network and Data Security=20
> Ruhr-University Bochum, Germany
>=20
> Universit=C3=A4tsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>=20
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347
> http://nds.rub.de/chair/people/cmainka/ =

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


--Apple-Mail=_71790711-515E-446E-B864-8A8F9DAF04BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
all,

    It=E2=80=99s =
worth adding that a per-instance dynamic registration of a native client =
can still imply a higher level of trust than a public client and =
registration isn=E2=80=99t necessarily unauthenticated. https://tools.ietf.org/html/rfc7591 defines an =E2=80=9Cini=
tial access token=E2=80=9D:

    OAuth 2.0 access token =
optionally issued by an authorization
server to a developer or client and used to authorize calls to the
client registration endpoint.  The type and format of this token
are likely service specific and are out of scope for this
specification.  The means by which the authorization server issues
this token as well as the means by which the registration endpoint
validates this token are out of scope for this specification.  Use
of an initial access token is required when the authorization
server limits the parties that can register a =
client.

    This =
can be used [for example] to bind a client to a specific user, though =
the bootstrapping can be a little involved and potentially the =
bootstrapping still has weaknesses. Use of white box crypto (or other =
tools like device attestations) can potentially also bring dynamically =
registered native apps up to a sufficiently trusted level.

    Joseph


    On 29 Nov 2018, at 14:02, Christian Mainka <Christian.Mainka=3D40rub.de@dmarc.ietf.org> =
wrote:

    
 =20
    
 =20
  
    
    
     Hi,
    
      
    
      thanks for pointing this out!
    
      This was exactly what confused us during reading -=
 the
      main threat we see and which is not addressed is related to the
      app impersonation attack.
    
      Even PKCE does not help against the app impersonation attack.
    
      
    
      So a "Native App + Dynamic Client Registration" can be seen at a
      different "confidentiality level" than a "public client", because
      every native App can dynamically register itself on the IdP.
    
      The IdP cannot distinguish, for example, an honest native client
      from an malicious client starting an app impersonation attack.
    
      
    
      We agree that, e.g., a leaked code cannot be redeemed unless you
      have the respective client_id/client_secret.
    
      
    
      But... we asked ourselfs, in which cases does a code leak?
    
      
    
      1) In the front-channel. In this case, it is true that no client
      credentials leak and an attacker cannot redeem the code.
    
      
    
      2) In the back-channel. But if this channel is insecure, you
      directly get client credentials (unless client_secret_jwt is used
      as pointed out by George).
    
      
    
      So, Dynamic Client Registration only helps if the code leaks alone
      (as in 1.), or if it leaks on different levels (e.g. logfiles).
    
      
    
      On the opposite site, if Dynamic Registration is available, an
      attacker can very easily do an app impersonation attack by
      registering on the IdP. To be clear, it is not "impersonation" as
      in the "one secret per software" scenario, because different
      client_id and client_secret is used, but to the best of my
      knowledge, the IdP cannot distinguish between an honest app and an
      app impersonation client that has simply registered.
    
      
    
      In addition, if the IdP supports the dynamic client =
registration:
    
    
    How can the IdP
      distinguish between confidential and public/native clients?
    
      With respect to the consent page, which must be shown every time
      for native apps, this is an important issue, which should be
      addressed properly.
    
      
    
      Best Regards
    
      Vladi/Christian 
    
    
    
    

    
    
    
    
    Am 29.11.18 um 00:38 schrieb Richard
      Backman, Annabelle:
    
    
    
    
    
      
    It should be noted that =
=E2=80=9Ctraditional=E2=80=9D confidential clients with registered =
return URLs and server-side secrets may provide a higher degree of =
confidence in the true identity of the client that doesn=E2=80=99t carry =
over to confidential native app clients. A native app instance=E2=80=99s =
registration call is necessarily unauthenticated (for the same reasons =
that statically registered native app clients are public clients), so =
the Client Impersonation concerns described in section 8.6 of RFC8252<https://tools=
.ietf.org/html/rfc8252#section-8.6> still apply.
--
Annabelle Richard Backman
AWS Identity


From: OAuth <oauth-bounces@ietf.org> =
on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Wednesday, November 28, 2018 at 9:11 AM
To: George Fletcher <gffletch@aol.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Apologies, I missed the issued in "issued a shared secret", just reading =
"shared secret" alone is the exact opposite of a per-instance secret. =
The rest is clear and as you say it brings the benefit of the secret =
never being sent over the wire (except during the initial registration =
via TLS).

Best,
Filip


On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffletch@aol.com<mailto:gffletch@aol.com>> =
wrote:
It's "confidential" in that the shared secret is unique to that app =
instance registration (as Dennis described in his response). If an =
attacker gets my phone and compromises the data stored on my device, =
they only get the secret for my device. This is no different than a =
server side client having their client secret compromised through an =
attack (and in some ways is better because it's instance specific).

The main point I was trying to make, is that the 'client_secret_jwt' =
method allows the client to never send the shared secret across the wire =
as is created in the default OAuth2 HTTP Basic Authentication method.

Thanks,
George
On 11/28/18 11:03 AM, Filip Skokan wrote:
Hi George,

#2 doesn't seem confidential, it's still a secret shared amongst =
installations and anyone reverse engineering the apk, extracting the =
secret, can form the client_secret_jwt client_assertion with it just =
fine.

Best,
Filip

On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=3D40aol.com@d=
marc.ietf.org<mailto:40aol.com@dmarc.ietf.o=
rg>> wrote:
In addition, a few additional patterns are enabled...

1. The native app can generate a public/private key pair and then use =
private_secret_jwt as the client credential validation method via the =
client credentials flow (defined in OpenID Connect).

2. Maybe more simply, if the native app is issued a shared secret, the =
app can use client_secret_jwt method for client authentication which =
ensures the shared secret never leaves the device. (Again defined in the =
OpenID Connect spec).

3. Once the native app instance has credentials, they can be used for =
additional securing of app API transactions in addition to just the =
OAuth2/OpenID Connect flows.

Thanks,
George
On 11/27/18 3:28 PM, William Denniss wrote:
If the secret is dynamically provisioned then you have a confidential =
client. Anyone reverse engineering their own installation of the native =
app would only extract their own client's credentials, as opposed to the =
shared secret of all installations. Having a confidential client means =
that requests to the token endpoint (code, refresh) are client =
authenticated, so PKCE wouldn't be needed.

On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.Main=
ka=3D40rub.de@dmarc.ietf..org<mailto:Chri=
stian.Mainka=3D40rub.de@dmarc.ietf.org>> wrote:
Hi,

we just stumbled upon this [1] statement:
"Except when using a mechanism like Dynamic Client Registration
   [RFC7591] to provision per-instance secrets, native apps are
   classified as public clients ..."

What does this mean for us? Native App + Dynamic Client Registration =3D
Confidential Client?
Which threats are covered if Dynamic Client Registration is used on
Native Apps?

Best Regards,
Vladi/Christian

[1]: https://tools.iet=
f.org/html/rfc8252#section-8.4

--
Dr.-Ing. Christian Mainka
Horst G=C3=B6rtz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum, Germany

Universit=C3=A4tsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/p=
eople/cmainka/
@CheariX


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




_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

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

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/=
mailman/listinfo/oauth<https://www..iet=
f.org/mailman/listinfo/oauth>


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

    
    
    
    
    --=20
Dr.-Ing. Christian Mainka
Horst G=C3=B6rtz Institute for IT-Security=20
Chair for Network and Data Security=20
Ruhr-University Bochum, Germany

Universit=C3=A4tsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/p=
eople/cmainka/
@CheariX
    
  
    

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

    =

--Apple-Mail=_71790711-515E-446E-B864-8A8F9DAF04BC--


From nobody Thu Nov 29 08:48:25 2018
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 480D3130E6A for ; Thu, 29 Nov 2018 08:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level: 
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uXycPmo7G2Y for ; Thu, 29 Nov 2018 08:48:13 -0800 (PST)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45E0130E73 for ; Thu, 29 Nov 2018 08:48:12 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id 0C6FA472EDF; Fri, 30 Nov 2018 01:48:12 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id AAC604E0046; Fri, 30 Nov 2018 01:48:11 +0900 (JST)
Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wATGmBO8019499; Fri, 30 Nov 2018 01:48:11 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp with ESMTP id wATGmBi2019498; Fri, 30 Nov 2018 01:48:11 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wATGmBUX038887; Fri, 30 Nov 2018 01:48:11 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wATGmBgw038886; Fri, 30 Nov 2018 01:48:11 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wATGmBFP038883; Fri, 30 Nov 2018 01:48:11 +0900
Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM07PA.cu.nri.co.jp (172.159.253.49) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 01:48:10 +0900
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (23.103.139.149) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 01:48:10 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cSzDD4AEK1/BdZZ+tyHcnJPApbhIjbskljW37ft6h2U=; b=O7pvU0lDvCVcJ+SB6RolZjpOiEDbnlV/5Hl9/fx2ym5oE6GYpZKB2hYV8u1FtKAAUMtjs5gEn5x3i/nDV/PnAaZrNw0/8/icN4TFHFPAjJZWBYVCfJ8ccRbtn3uFLR5T0iIcIzBq3BIetjp5LgHigf9E4Re4miQRNem+m65I3tw=
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB3783.jpnprd01.prod.outlook.com (20.178.97.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.19; Thu, 29 Nov 2018 16:48:09 +0000
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Thu, 29 Nov 2018 16:48:09 +0000
From: n-sakimura 
To: Joseph Heenan , oauth 
Thread-Topic: [OAUTH-WG] Dynamic Client Registration with Native Apps
Thread-Index: AQHUhjXrmcNyRkgabUmMjB8NrYEzBKVkEwKAgAFD5YCAAARsgIAAEL4AgAAB3wCAAGykAIAA8WgAgAAmAACAAAe6bQ==
Date: Thu, 29 Nov 2018 16:48:08 +0000
Message-ID: 
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>     <065bba73-eade-2f07-038f-8afa708e38be@rub.de>, <44FD54EC-6506-499E-AD98-65F8D04AAD41@authlete.com>
In-Reply-To: <44FD54EC-6506-499E-AD98-65F8D04AAD41@authlete.com>
Accept-Language: ja-JP, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [13.86.120.249]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; OSBPR01MB3783; 6:D5Y4Xd7ibG/hwpRFLeBxnUwgJjKdmBU8el+VJ6mDTDoFZD0vfWDmvSV5UvUzARa0gbpXhPFpLpqlFm9aQBvWi/M4ziAdi62Q6a/VBjEaPtXT7wXA/+7u4S1Aa4GtFEi3GCQcHEYo24/kwQbH3xXYvbyYlI9cnTUCn76/CsC5hQI644okY5q2lxe5Cw+sIz+YuTRIE01rYanUXv1S6o1IP46D0++zxOVLLUfp0qRkkuBfYI1Is1YjlBbofDEovUWbMobNPKEYNGgyrnAWSLoJMeqe24bm2/QCCygCXK6Qr1UheJvmsnehrmrG3aS1lLC92+NMONIjt4PCE0iOlO6MxSNevgXqvlAvBL8ulPHuhlVg6R2MdVuCELZZPTQCblVY1AtctqConHLjV7xGBSGEX4lC4IqEnmtKmCnCl5IL9eubDNC3EnWbtpZAYLtBnLMNZhGadBbF3YDYZILj3eQs2w==; 5:kAAmkw/dkP9Onu/M91QMvK+PoG55bl4/TJmx1r23ZQUUSm9wRX0qiBkSj5xSHf7AgLPFhSUa4ZIGCKT+fOidvM5TWJLs+eKfhjPA9Eh0xYDT05tu7qndRrx30jbnSA04PKucPAas0CA8mQ/SMsHDXIrH8g1y7k7mzVCw3Thteyk=; 7:ef4VbwEHcpyxdhGAA0jU2QetXzGmgwYE7J73xN53THqi//XjG2W8AWU6lqHQz6K7nvHn1c5Sjn216xaNaVWMfrv+uIQZPqDA2wq2+W9RNhtN+UYnx1c46NsIwdRwLJ2kIbtN0Nc1AufSWdVe4sexVw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c51c54aa-5144-4166-9aa1-08d6561a7159
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB3783; 
x-ms-traffictypediagnostic: OSBPR01MB3783:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231453)(999002)(944501447)(4982022)(52105112)(3002001)(93006095)(93001095)(148016)(149066)(150057)(6041310)(2016111802025)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB3783; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB3783; 
x-forefront-prvs: 0871917CDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(136003)(39840400004)(346002)(199004)(189003)(53754006)(365934003)(68736007)(25786009)(74482002)(236005)(508600001)(55016002)(6306002)(9686003)(2906002)(446003)(5660300001)(54896002)(53546011)(66574009)(6506007)(76176011)(7696005)(99286004)(14444005)(256004)(66066001)(486006)(476003)(105586002)(606006)(11346002)(33656002)(106356001)(81156014)(316002)(93886005)(53936002)(8936002)(8676002)(81166006)(6246003)(110136005)(3846002)(6116002)(6436002)(966005)(229853002)(97736004)(74316002)(71200400001)(71190400001)(186003)(26005)(102836004)(14454004)(86362001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB3783; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Lb93uyjV+Q0qdoVKaLty/0wDQRiARaOt2M6UY9SCLOqjqOodn3r7Xasu2Q0Dd3mq6L6kjygJon+xsHR/77ilb1YZNJDGgoWzABwWkEfMKtAk8LuYJOmdaZkBXnuYPJXdQRa+UkTkZTYbmh5bAU7epT7tgv9gp+r/w0cYg9PIuSgR7jU2NPO/X8HGn534B9df+LHG6XVDVMnmXmf9XBo1UMz+njbhBNcPO/MWAWs2e1Kt/ojvJ6t8Xalj2KRB4/KHwkT+R2sqwxozxPOBChdrkNMsidlTPgY6OLMhWtKNdtT7kPta+um1d/vdmXcOZTg5NJudo5mO6gUFk35BTYaumcqDeiaPIEidtQKhAJuXvHY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB286944CFB04C0E88801478AAF9D20OSBPR01MB2869jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c51c54aa-5144-4166-9aa1-08d6561a7159
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2018 16:48:08.9279 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB3783
X-OrganizationHeadersPreserved: OSBPR01MB3783.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 29 Nov 2018 16:48:24 -0000

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

SW4gdGhlIGNhc2Ugb2YgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIGZvciBhcHBzLCBJIHN1
cHBvc2UgdGhlIGltcGxlbWVudGF0aW9ucyB3aWxsIHVzZSBvdGhlciB0ZWNobmlxdWVzIChtYW55
IG9mIHRoZW0gYXJlIHByb3ByaWV0YXJ5KSB0byB0ZXN0IGlmIHRoZSBhcHAgaXMgdGhlIG9uZSBj
cmVhdGVkIGJ5IHRoZW1zZWx2ZXMgb3Igbm90LiBPdGhlcndpc2UsIGl0IHdvdWxkIG5vdCBpbXBy
b3ZlIHRoZSBzaXR1YXRpb24gdmVyeSBtdWNoLg0KDQpOYXQNCg0KTmF0IFNha2ltdXJhIC8gbi1z
YWtpbXVyYUBucmkuY28uanAgLyArODEtOTAtNjAxMy02Mjc2DQoNCuOBk+OBruODoeODvOODq+OB
q+OBr+OAgeacrOadpeOBruWum+WFiOOBruaWueOBruOBv+OBq+mZkOWumuOBleOCjOOBn+apn+Wv
huaDheWgseOBjOWQq+OBvuOCjOOBpuOBhOOCi+WgtOWQiOOBjOOBlOOBluOBhOOBvuOBmeOAguOB
iuW/g+OBguOBn+OCiuOBruOBquOBhOWgtOWQiOOBr+OAgeiqoOOBq+eUs+OBl+ios+OBlOOBluOB
hOOBvuOBm+OCk+OBjOOAgemAgeS/oeiAheOBvuOBp+OBiuefpeOCieOBm+mgguOBjeOAgeOBvuOB
n+WPl+S/oeOBleOCjOOBn+ODoeODvOODq+OBr+WJiumZpOOBl+OBpuOBj+OBoOOBleOBhOOBvuOB
meOCiOOBhuOBiumhmOOBhOeUs+OBl+S4iuOBkuOBvuOBmeOAgg0KDQpQTEVBU0UgUkVBRCA6VGhp
cyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lw
aWVudCBvbmx5Lg0KSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGUtbWFpbC4NCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCuW3ruWHuuS6ujogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc+IChKb3NlcGggSGVlbmFuIDxqb3NlcGhAYXV0aGxldGUuY29tPiDjga7ku6PnkIYpDQrp
gIHkv6Hml6XmmYI6IOacqOabnOaXpSwgMTHmnIggMjksIDIwMTggNToxOSDljYjlvowNCuWum+WF
iDogb2F1dGgNCuS7tuWQjTogUmU6IFtPQVVUSC1XR10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0
aW9uIHdpdGggTmF0aXZlIEFwcHMNCg0KSGkgYWxsLA0KDQpJdOKAmXMgd29ydGggYWRkaW5nIHRo
YXQgYSBwZXItaW5zdGFuY2UgZHluYW1pYyByZWdpc3RyYXRpb24gb2YgYSBuYXRpdmUgY2xpZW50
IGNhbiBzdGlsbCBpbXBseSBhIGhpZ2hlciBsZXZlbCBvZiB0cnVzdCB0aGFuIGEgcHVibGljIGNs
aWVudCBhbmQgcmVnaXN0cmF0aW9uIGlzbuKAmXQgbmVjZXNzYXJpbHkgdW5hdXRoZW50aWNhdGVk
LiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzU5MSBkZWZpbmVzIGFuIOKAnGluaXRp
YWwgYWNjZXNzIHRva2Vu4oCdOg0KDQoNCk9BdXRoIDIuMCBhY2Nlc3MgdG9rZW4gb3B0aW9uYWxs
eSBpc3N1ZWQgYnkgYW4gYXV0aG9yaXphdGlvbg0Kc2VydmVyIHRvIGEgZGV2ZWxvcGVyIG9yIGNs
aWVudCBhbmQgdXNlZCB0byBhdXRob3JpemUgY2FsbHMgdG8gdGhlDQpjbGllbnQgcmVnaXN0cmF0
aW9uIGVuZHBvaW50LiAgVGhlIHR5cGUgYW5kIGZvcm1hdCBvZiB0aGlzIHRva2VuDQphcmUgbGlr
ZWx5IHNlcnZpY2Ugc3BlY2lmaWMgYW5kIGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMNCnNwZWNp
ZmljYXRpb24uICBUaGUgbWVhbnMgYnkgd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlz
c3Vlcw0KdGhpcyB0b2tlbiBhcyB3ZWxsIGFzIHRoZSBtZWFucyBieSB3aGljaCB0aGUgcmVnaXN0
cmF0aW9uIGVuZHBvaW50DQp2YWxpZGF0ZXMgdGhpcyB0b2tlbiBhcmUgb3V0IG9mIHNjb3BlIGZv
ciB0aGlzIHNwZWNpZmljYXRpb24uICBVc2UNCm9mIGFuIGluaXRpYWwgYWNjZXNzIHRva2VuIGlz
IHJlcXVpcmVkIHdoZW4gdGhlIGF1dGhvcml6YXRpb24NCnNlcnZlciBsaW1pdHMgdGhlIHBhcnRp
ZXMgdGhhdCBjYW4gcmVnaXN0ZXIgYSBjbGllbnQuDQoNClRoaXMgY2FuIGJlIHVzZWQgW2ZvciBl
eGFtcGxlXSB0byBiaW5kIGEgY2xpZW50IHRvIGEgc3BlY2lmaWMgdXNlciwgdGhvdWdoIHRoZSBi
b290c3RyYXBwaW5nIGNhbiBiZSBhIGxpdHRsZSBpbnZvbHZlZCBhbmQgcG90ZW50aWFsbHkgdGhl
IGJvb3RzdHJhcHBpbmcgc3RpbGwgaGFzIHdlYWtuZXNzZXMuIFVzZSBvZiB3aGl0ZSBib3ggY3J5
cHRvIChvciBvdGhlciB0b29scyBsaWtlIGRldmljZSBhdHRlc3RhdGlvbnMpIGNhbiBwb3RlbnRp
YWxseSBhbHNvIGJyaW5nIGR5bmFtaWNhbGx5IHJlZ2lzdGVyZWQgbmF0aXZlIGFwcHMgdXAgdG8g
YSBzdWZmaWNpZW50bHkgdHJ1c3RlZCBsZXZlbC4NCg0KSm9zZXBoDQoNCg0KT24gMjkgTm92IDIw
MTgsIGF0IDE0OjAyLCBDaHJpc3RpYW4gTWFpbmthIDxDaHJpc3RpYW4uTWFpbmthPTQwcnViLmRl
QGRtYXJjLmlldGYub3JnPG1haWx0bzpDaHJpc3RpYW4uTWFpbmthPTQwcnViLmRlQGRtYXJjLmll
dGYub3JnPj4gd3JvdGU6DQoNCkhpLA0KDQp0aGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0IQ0K
VGhpcyB3YXMgZXhhY3RseSB3aGF0IGNvbmZ1c2VkIHVzIGR1cmluZyByZWFkaW5nIC0gdGhlIG1h
aW4gdGhyZWF0IHdlIHNlZSBhbmQgd2hpY2ggaXMgbm90IGFkZHJlc3NlZCBpcyByZWxhdGVkIHRv
IHRoZSBhcHAgaW1wZXJzb25hdGlvbiBhdHRhY2suDQpFdmVuIFBLQ0UgZG9lcyBub3QgaGVscCBh
Z2FpbnN0IHRoZSBhcHAgaW1wZXJzb25hdGlvbiBhdHRhY2suDQoNClNvIGEgIk5hdGl2ZSBBcHAg
KyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24iIGNhbiBiZSBzZWVuIGF0IGEgZGlmZmVyZW50
ICJjb25maWRlbnRpYWxpdHkgbGV2ZWwiIHRoYW4gYSAicHVibGljIGNsaWVudCIsIGJlY2F1c2Ug
ZXZlcnkgbmF0aXZlIEFwcCBjYW4gZHluYW1pY2FsbHkgcmVnaXN0ZXIgaXRzZWxmIG9uIHRoZSBJ
ZFAuDQpUaGUgSWRQIGNhbm5vdCBkaXN0aW5ndWlzaCwgZm9yIGV4YW1wbGUsIGFuIGhvbmVzdCBu
YXRpdmUgY2xpZW50IGZyb20gYW4gbWFsaWNpb3VzIGNsaWVudCBzdGFydGluZyBhbiBhcHAgaW1w
ZXJzb25hdGlvbiBhdHRhY2suDQoNCldlIGFncmVlIHRoYXQsIGUuZy4sIGEgbGVha2VkIGNvZGUg
Y2Fubm90IGJlIHJlZGVlbWVkIHVubGVzcyB5b3UgaGF2ZSB0aGUgcmVzcGVjdGl2ZSBjbGllbnRf
aWQvY2xpZW50X3NlY3JldC4NCg0KQnV0Li4uIHdlIGFza2VkIG91cnNlbGZzLCBpbiB3aGljaCBj
YXNlcyBkb2VzIGEgY29kZSBsZWFrPw0KDQoxKSBJbiB0aGUgZnJvbnQtY2hhbm5lbC4gSW4gdGhp
cyBjYXNlLCBpdCBpcyB0cnVlIHRoYXQgbm8gY2xpZW50IGNyZWRlbnRpYWxzIGxlYWsgYW5kIGFu
IGF0dGFja2VyIGNhbm5vdCByZWRlZW0gdGhlIGNvZGUuDQoNCjIpIEluIHRoZSBiYWNrLWNoYW5u
ZWwuIEJ1dCBpZiB0aGlzIGNoYW5uZWwgaXMgaW5zZWN1cmUsIHlvdSBkaXJlY3RseSBnZXQgY2xp
ZW50IGNyZWRlbnRpYWxzICh1bmxlc3MgY2xpZW50X3NlY3JldF9qd3QgaXMgdXNlZCBhcyBwb2lu
dGVkIG91dCBieSBHZW9yZ2UpLg0KDQpTbywgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIG9u
bHkgaGVscHMgaWYgdGhlIGNvZGUgbGVha3MgYWxvbmUgKGFzIGluIDEuKSwgb3IgaWYgaXQgbGVh
a3Mgb24gZGlmZmVyZW50IGxldmVscyAoZS5nLiBsb2dmaWxlcykuDQoNCk9uIHRoZSBvcHBvc2l0
ZSBzaXRlLCBpZiBEeW5hbWljIFJlZ2lzdHJhdGlvbiBpcyBhdmFpbGFibGUsIGFuIGF0dGFja2Vy
IGNhbiB2ZXJ5IGVhc2lseSBkbyBhbiBhcHAgaW1wZXJzb25hdGlvbiBhdHRhY2sgYnkgcmVnaXN0
ZXJpbmcgb24gdGhlIElkUC4gVG8gYmUgY2xlYXIsIGl0IGlzIG5vdCAiaW1wZXJzb25hdGlvbiIg
YXMgaW4gdGhlICJvbmUgc2VjcmV0IHBlciBzb2Z0d2FyZSIgc2NlbmFyaW8sIGJlY2F1c2UgZGlm
ZmVyZW50IGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCBpcyB1c2VkLCBidXQgdG8gdGhlIGJl
c3Qgb2YgbXkga25vd2xlZGdlLCB0aGUgSWRQIGNhbm5vdCBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFu
IGhvbmVzdCBhcHAgYW5kIGFuIGFwcCBpbXBlcnNvbmF0aW9uIGNsaWVudCB0aGF0IGhhcyBzaW1w
bHkgcmVnaXN0ZXJlZC4NCg0KSW4gYWRkaXRpb24sIGlmIHRoZSBJZFAgc3VwcG9ydHMgdGhlIGR5
bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbjoNCkhvdyBjYW4gdGhlIElkUCBkaXN0aW5ndWlzaCBi
ZXR3ZWVuIGNvbmZpZGVudGlhbCBhbmQgcHVibGljL25hdGl2ZSBjbGllbnRzPw0KV2l0aCByZXNw
ZWN0IHRvIHRoZSBjb25zZW50IHBhZ2UsIHdoaWNoIG11c3QgYmUgc2hvd24gZXZlcnkgdGltZSBm
b3IgbmF0aXZlIGFwcHMsIHRoaXMgaXMgYW4gaW1wb3J0YW50IGlzc3VlLCB3aGljaCBzaG91bGQg
YmUgYWRkcmVzc2VkIHByb3Blcmx5Lg0KDQpCZXN0IFJlZ2FyZHMNClZsYWRpL0NocmlzdGlhbg0K
DQpBbSAyOS4xMS4xOCB1bSAwMDozOCBzY2hyaWViIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl
Og0KDQpJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCDigJx0cmFkaXRpb25hbOKAnSBjb25maWRlbnRp
YWwgY2xpZW50cyB3aXRoIHJlZ2lzdGVyZWQgcmV0dXJuIFVSTHMgYW5kIHNlcnZlci1zaWRlIHNl
Y3JldHMgbWF5IHByb3ZpZGUgYSBoaWdoZXIgZGVncmVlIG9mIGNvbmZpZGVuY2UgaW4gdGhlIHRy
dWUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudCB0aGF0IGRvZXNu4oCZdCBjYXJyeSBvdmVyIHRvIGNv
bmZpZGVudGlhbCBuYXRpdmUgYXBwIGNsaWVudHMuIEEgbmF0aXZlIGFwcCBpbnN0YW5jZeKAmXMg
cmVnaXN0cmF0aW9uIGNhbGwgaXMgbmVjZXNzYXJpbHkgdW5hdXRoZW50aWNhdGVkIChmb3IgdGhl
IHNhbWUgcmVhc29ucyB0aGF0IHN0YXRpY2FsbHkgcmVnaXN0ZXJlZCBuYXRpdmUgYXBwIGNsaWVu
dHMgYXJlIHB1YmxpYyBjbGllbnRzKSwgc28gdGhlIENsaWVudCBJbXBlcnNvbmF0aW9uIGNvbmNl
cm5zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDguNiBvZiBSRkM4MjUyPGh0dHBzOi8vdG9vbHMuLmll
dGYub3JnL2h0bWwvcmZjODI1MiNzZWN0aW9uLTguNj48aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzgyNTIjc2VjdGlvbi04LjY+IHN0aWxsIGFwcGx5Lg0KLS0NCkFubmFiZWxsZSBSaWNo
YXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2Vz
QGlldGYub3JnPjxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEZp
bGlwIFNrb2thbiA8cGFudmEuaXBAZ21haWwuY29tPjxtYWlsdG86cGFudmEuaXBAZ21haWwuY29t
Pg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOCwgMjAxOCBhdCA5OjExIEFNDQpUbzogR2Vv
cmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPjxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4N
CkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1Ympl
Y3Q6IFJlOiBbT0FVVEgtV0ddIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiB3aXRoIE5hdGl2
ZSBBcHBzDQoNCkFwb2xvZ2llcywgSSBtaXNzZWQgdGhlIGlzc3VlZCBpbiAiaXNzdWVkIGEgc2hh
cmVkIHNlY3JldCIsIGp1c3QgcmVhZGluZyAic2hhcmVkIHNlY3JldCIgYWxvbmUgaXMgdGhlIGV4
YWN0IG9wcG9zaXRlIG9mIGEgcGVyLWluc3RhbmNlIHNlY3JldC4gVGhlIHJlc3QgaXMgY2xlYXIg
YW5kIGFzIHlvdSBzYXkgaXQgYnJpbmdzIHRoZSBiZW5lZml0IG9mIHRoZSBzZWNyZXQgbmV2ZXIg
YmVpbmcgc2VudCBvdmVyIHRoZSB3aXJlIChleGNlcHQgZHVyaW5nIHRoZSBpbml0aWFsIHJlZ2lz
dHJhdGlvbiB2aWEgVExTKS4NCg0KQmVzdCwNCkZpbGlwDQoNCg0KT24gV2VkLCBOb3YgMjgsIDIw
MTggYXQgNjowMyBQTSBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoQGFvbC5jb208bWFpbHRvOmdm
ZmxldGNoQGFvbC5jb20+PG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPjxtYWlsdG86Z2ZmbGV0Y2hA
YW9sLmNvbT4+IHdyb3RlOg0KSXQncyAiY29uZmlkZW50aWFsIiBpbiB0aGF0IHRoZSBzaGFyZWQg
c2VjcmV0IGlzIHVuaXF1ZSB0byB0aGF0IGFwcCBpbnN0YW5jZSByZWdpc3RyYXRpb24gKGFzIERl
bm5pcyBkZXNjcmliZWQgaW4gaGlzIHJlc3BvbnNlKS4gSWYgYW4gYXR0YWNrZXIgZ2V0cyBteSBw
aG9uZSBhbmQgY29tcHJvbWlzZXMgdGhlIGRhdGEgc3RvcmVkIG9uIG15IGRldmljZSwgdGhleSBv
bmx5IGdldCB0aGUgc2VjcmV0IGZvciBteSBkZXZpY2UuIFRoaXMgaXMgbm8gZGlmZmVyZW50IHRo
YW4gYSBzZXJ2ZXIgc2lkZSBjbGllbnQgaGF2aW5nIHRoZWlyIGNsaWVudCBzZWNyZXQgY29tcHJv
bWlzZWQgdGhyb3VnaCBhbiBhdHRhY2sgKGFuZCBpbiBzb21lIHdheXMgaXMgYmV0dGVyIGJlY2F1
c2UgaXQncyBpbnN0YW5jZSBzcGVjaWZpYykuDQoNClRoZSBtYWluIHBvaW50IEkgd2FzIHRyeWlu
ZyB0byBtYWtlLCBpcyB0aGF0IHRoZSAnY2xpZW50X3NlY3JldF9qd3QnIG1ldGhvZCBhbGxvd3Mg
dGhlIGNsaWVudCB0byBuZXZlciBzZW5kIHRoZSBzaGFyZWQgc2VjcmV0IGFjcm9zcyB0aGUgd2ly
ZSBhcyBpcyBjcmVhdGVkIGluIHRoZSBkZWZhdWx0IE9BdXRoMiBIVFRQIEJhc2ljIEF1dGhlbnRp
Y2F0aW9uIG1ldGhvZC4NCg0KVGhhbmtzLA0KR2VvcmdlDQpPbiAxMS8yOC8xOCAxMTowMyBBTSwg
RmlsaXAgU2tva2FuIHdyb3RlOg0KSGkgR2VvcmdlLA0KDQojMiBkb2Vzbid0IHNlZW0gY29uZmlk
ZW50aWFsLCBpdCdzIHN0aWxsIGEgc2VjcmV0IHNoYXJlZCBhbW9uZ3N0IGluc3RhbGxhdGlvbnMg
YW5kIGFueW9uZSByZXZlcnNlIGVuZ2luZWVyaW5nIHRoZSBhcGssIGV4dHJhY3RpbmcgdGhlIHNl
Y3JldCwgY2FuIGZvcm0gdGhlIGNsaWVudF9zZWNyZXRfand0IGNsaWVudF9hc3NlcnRpb24gd2l0
aCBpdCBqdXN0IGZpbmUuDQoNCkJlc3QsDQpGaWxpcA0KDQpPbiBXZWQsIE5vdiAyOCwgMjAxOCBh
dCA0OjQ4IFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYu
b3JnPG1haWx0bzpnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PG1haWx0bzo0MGFv
bC5jb21AZG1hcmMuaWV0Zi5vcmc+PG1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3
cm90ZToNCkluIGFkZGl0aW9uLCBhIGZldyBhZGRpdGlvbmFsIHBhdHRlcm5zIGFyZSBlbmFibGVk
Li4uDQoNCjEuIFRoZSBuYXRpdmUgYXBwIGNhbiBnZW5lcmF0ZSBhIHB1YmxpYy9wcml2YXRlIGtl
eSBwYWlyIGFuZCB0aGVuIHVzZSBwcml2YXRlX3NlY3JldF9qd3QgYXMgdGhlIGNsaWVudCBjcmVk
ZW50aWFsIHZhbGlkYXRpb24gbWV0aG9kIHZpYSB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGZsb3cg
KGRlZmluZWQgaW4gT3BlbklEIENvbm5lY3QpLg0KDQoyLiBNYXliZSBtb3JlIHNpbXBseSwgaWYg
dGhlIG5hdGl2ZSBhcHAgaXMgaXNzdWVkIGEgc2hhcmVkIHNlY3JldCwgdGhlIGFwcCBjYW4gdXNl
IGNsaWVudF9zZWNyZXRfand0IG1ldGhvZCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHdoaWNo
IGVuc3VyZXMgdGhlIHNoYXJlZCBzZWNyZXQgbmV2ZXIgbGVhdmVzIHRoZSBkZXZpY2UuIChBZ2Fp
biBkZWZpbmVkIGluIHRoZSBPcGVuSUQgQ29ubmVjdCBzcGVjKS4NCg0KMy4gT25jZSB0aGUgbmF0
aXZlIGFwcCBpbnN0YW5jZSBoYXMgY3JlZGVudGlhbHMsIHRoZXkgY2FuIGJlIHVzZWQgZm9yIGFk
ZGl0aW9uYWwgc2VjdXJpbmcgb2YgYXBwIEFQSSB0cmFuc2FjdGlvbnMgaW4gYWRkaXRpb24gdG8g
anVzdCB0aGUgT0F1dGgyL09wZW5JRCBDb25uZWN0IGZsb3dzLg0KDQpUaGFua3MsDQpHZW9yZ2UN
Ck9uIDExLzI3LzE4IDM6MjggUE0sIFdpbGxpYW0gRGVubmlzcyB3cm90ZToNCklmIHRoZSBzZWNy
ZXQgaXMgZHluYW1pY2FsbHkgcHJvdmlzaW9uZWQgdGhlbiB5b3UgaGF2ZSBhIGNvbmZpZGVudGlh
bCBjbGllbnQuIEFueW9uZSByZXZlcnNlIGVuZ2luZWVyaW5nIHRoZWlyIG93biBpbnN0YWxsYXRp
b24gb2YgdGhlIG5hdGl2ZSBhcHAgd291bGQgb25seSBleHRyYWN0IHRoZWlyIG93biBjbGllbnQn
cyBjcmVkZW50aWFscywgYXMgb3Bwb3NlZCB0byB0aGUgc2hhcmVkIHNlY3JldCBvZiBhbGwgaW5z
dGFsbGF0aW9ucy4gSGF2aW5nIGEgY29uZmlkZW50aWFsIGNsaWVudCBtZWFucyB0aGF0IHJlcXVl
c3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCAoY29kZSwgcmVmcmVzaCkgYXJlIGNsaWVudCBhdXRo
ZW50aWNhdGVkLCBzbyBQS0NFIHdvdWxkbid0IGJlIG5lZWRlZC4NCg0KT24gVHVlLCBOb3YgMjcs
IDIwMTggYXQgMTo0NCBBTSwgQ2hyaXN0aWFuIE1haW5rYSA8Q2hyaXN0aWFuLk1haW5rYT00MHJ1
Yi5kZUBkbWFyYy5pZXRmLi5vcmc8bWFpbHRvOkNocmlzdGlhbi5NYWlua2E9NDBydWIuZGVAZG1h
cmMuaWV0Zi4ub3JnPjxtYWlsdG86Q2hyaXN0aWFuLk1haW5rYT00MHJ1Yi5kZUBkbWFyYy5pZXRm
Lm9yZz48bWFpbHRvOkNocmlzdGlhbi5NYWlua2E9NDBydWIuZGVAZG1hcmMuaWV0Zi5vcmc+PiB3
cm90ZToNCkhpLA0KDQp3ZSBqdXN0IHN0dW1ibGVkIHVwb24gdGhpcyBbMV0gc3RhdGVtZW50Og0K
IkV4Y2VwdCB3aGVuIHVzaW5nIGEgbWVjaGFuaXNtIGxpa2UgRHluYW1pYyBDbGllbnQgUmVnaXN0
cmF0aW9uDQogICBbUkZDNzU5MV0gdG8gcHJvdmlzaW9uIHBlci1pbnN0YW5jZSBzZWNyZXRzLCBu
YXRpdmUgYXBwcyBhcmUNCiAgIGNsYXNzaWZpZWQgYXMgcHVibGljIGNsaWVudHMgLi4uIg0KDQpX
aGF0IGRvZXMgdGhpcyBtZWFuIGZvciB1cz8gTmF0aXZlIEFwcCArIER5bmFtaWMgQ2xpZW50IFJl
Z2lzdHJhdGlvbiA9DQpDb25maWRlbnRpYWwgQ2xpZW50Pw0KV2hpY2ggdGhyZWF0cyBhcmUgY292
ZXJlZCBpZiBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gaXMgdXNlZCBvbg0KTmF0aXZlIEFw
cHM/DQoNCkJlc3QgUmVnYXJkcywNClZsYWRpL0NocmlzdGlhbg0KDQpbMV06IGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM4MjUyI3NlY3Rpb24tOC40DQoNCi0tDQpEci4tSW5nLiBDaHJp
c3RpYW4gTWFpbmthDQpIb3JzdCBHw7ZydHogSW5zdGl0dXRlIGZvciBJVC1TZWN1cml0eQ0KQ2hh
aXIgZm9yIE5ldHdvcmsgYW5kIERhdGEgU2VjdXJpdHkNClJ1aHItVW5pdmVyc2l0eSBCb2NodW0s
IEdlcm1hbnkNCg0KVW5pdmVyc2l0w6R0c3N0ci4gMTUwLCBJRCAyLzQ2Mw0KRC00NDgwMSBCb2No
dW0sIEdlcm1hbnkNCg0KVGVsZWZvbjogKzQ5ICgwKSAyMzQgLyAzMi0yNjc5Ng0KRmF4OiArNDkg
KDApIDIzNCAvIDMyLTE0MzQ3DQpodHRwOi8vbmRzLnJ1Yi5kZS9jaGFpci9wZW9wbGUvY21haW5r
YS8NCkBDaGVhcmlYDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFp
bGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRv
Ok9BdXRoQGlldGYub3JnPjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpP
QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vd3d3Li5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPjxodHRwczovL3d3dy4uaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aD4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y
ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQoNCg0KLS0NCkRyLi1JbmcuIENocmlzdGlhbiBNYWlua2ENCkhvcnN0IEfD
tnJ0eiBJbnN0aXR1dGUgZm9yIElULVNlY3VyaXR5DQpDaGFpciBmb3IgTmV0d29yayBhbmQgRGF0
YSBTZWN1cml0eQ0KUnVoci1Vbml2ZXJzaXR5IEJvY2h1bSwgR2VybWFueQ0KDQpVbml2ZXJzaXTD
pHRzc3RyLiAxNTAsIElEIDIvNDYzDQpELTQ0ODAxIEJvY2h1bSwgR2VybWFueQ0KDQpUZWxlZm9u
OiArNDkgKDApIDIzNCAvIDMyLTI2Nzk2DQpGYXg6ICs0OSAoMCkgMjM0IC8gMzItMTQzNDcNCmh0
dHA6Ly9uZHMucnViLmRlL2NoYWlyL3Blb3BsZS9jbWFpbmthLw0KQENoZWFyaVgNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg
bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj48IS0tIFRo
aXMgZmlsZSBoYXMgYmVlbiBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZC4gU2VlIHdlYi9SRUFETUUu
bWQgLS0+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyI+SW4gdGhl
IGNhc2Ugb2YgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIGZvciBhcHBzLCBJIHN1cHBvc2Ug
dGhlIGltcGxlbWVudGF0aW9ucyB3aWxsIHVzZSBvdGhlciB0ZWNobmlxdWVzIChtYW55IG9mIHRo
ZW0gYXJlIHByb3ByaWV0YXJ5KSB0byB0ZXN0IGlmIHRoZSBhcHAgaXMgdGhlIG9uZSBjcmVhdGVk
IGJ5IHRoZW1zZWx2ZXMgb3Igbm90LiBPdGhlcndpc2UsIGl0IHdvdWxkIG5vdCBpbXByb3ZlDQog
dGhlIHNpdHVhdGlvbiB2ZXJ5IG11Y2guIDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYg
c3R5bGU9ImRpcmVjdGlvbjogbHRyOyI+TmF0PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSJtcy1vdXRsb29rLWlvcy1zaWduYXR1cmUiPg0KPGRpdiBzdHlsZT0i
ZGlyZWN0aW9uOiBsdHI7Ij5OYXQgU2FraW11cmEgLyBuLXNha2ltdXJhQG5yaS5jby5qcCAvICYj
NDM7ODEtOTAtNjAxMy02Mjc2PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i
ZGlyZWN0aW9uOiBsdHI7Ij7jgZPjga7jg6Hjg7zjg6vjgavjga/jgIHmnKzmnaXjga7lrpvlhYjj
ga7mlrnjga7jgb/jgavpmZDlrprjgZXjgozjgZ/mqZ/lr4bmg4XloLHjgYzlkKvjgb7jgozjgabj
gYTjgovloLTlkIjjgYzjgZTjgZbjgYTjgb7jgZnjgILjgYrlv4PjgYLjgZ/jgorjga7jgarjgYTl
oLTlkIjjga/jgIHoqqDjgavnlLPjgZfoqLPjgZTjgZbjgYTjgb7jgZvjgpPjgYzjgIHpgIHkv6Ho
gIXjgb7jgafjgYrnn6XjgonjgZvpoILjgY3jgIHjgb7jgZ/lj5fkv6HjgZXjgozjgZ/jg6Hjg7zj
g6vjga/liYrpmaTjgZfjgabjgY/jgaDjgZXjgYTjgb7jgZnjgojjgYbjgYrpoZjjgYTnlLPjgZfk
uIrjgZLjgb7jgZnjgII8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJl
Y3Rpb246IGx0cjsiPlBMRUFTRSBSRUFEIDpUaGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5k
IGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50IG9ubHkuPC9kaXY+DQo8ZGl2IHN0eWxl
PSJkaXJlY3Rpb246IGx0cjsiPklmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwg
cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuDQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5Omlu
bGluZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5Rndk
TXNnIiBkaXI9ImRpcj0mcXVvdDtsdHImcXVvdDsiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMt
c2VyaWYiIHN0eWxlPSJmb250LXNpemU6MTFwdCIgY29sb3I9IiMwMDAwMDAiPjxiPuW3ruWHuuS6
ujo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyAoSm9zZXBoIEhlZW5h
biAmbHQ7am9zZXBoQGF1dGhsZXRlLmNvbSZndDsg44Gu5Luj55CGKTxicj4NCjxiPumAgeS/oeaX
peaZgjo8L2I+IOacqOabnOaXpSwgMTHmnIggMjksIDIwMTggNToxOSDljYjlvow8YnI+DQo8Yj7l
rpvlhYg6PC9iPiBvYXV0aDxicj4NCjxiPuS7tuWQjTo8L2I+IFJlOiBbT0FVVEgtV0ddIER5bmFt
aWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiB3aXRoIE5hdGl2ZSBBcHBzDQo8ZGl2PiZuYnNwOzwvZGl2
Pg0KPC9mb250PjwvZGl2Pg0KPG1ldGEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04
Ij4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPkl04oCZcyB3b3J0aCBhZGRpbmcgdGhhdCBhIHBlci1pbnN0YW5jZSBkeW5hbWljIHJl
Z2lzdHJhdGlvbiBvZiBhIG5hdGl2ZSBjbGllbnQgY2FuIHN0aWxsIGltcGx5IGEgaGlnaGVyIGxl
dmVsIG9mIHRydXN0IHRoYW4gYSBwdWJsaWMgY2xpZW50IGFuZCByZWdpc3RyYXRpb24gaXNu4oCZ
dCBuZWNlc3NhcmlseSB1bmF1dGhlbnRpY2F0ZWQuJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzc1OTEiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9yZmM3NTkxPC9hPg0KIGRlZmluZXMgYW4g4oCcaW5pdGlhbCBhY2Nlc3MgdG9rZW7igJ06
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzMzMzMDE1NDQx
ODk1cHg7IG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweCI+PC9wcmU+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJm
b250LXNpemU6MTMuMzMzMzMzMDE1NDQxODk1cHg7IG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90
dG9tOjBweCI+T0F1dGggMi4wIGFjY2VzcyB0b2tlbiBvcHRpb25hbGx5IGlzc3VlZCBieSBhbiBh
dXRob3JpemF0aW9uDQpzZXJ2ZXIgdG8gYSBkZXZlbG9wZXIgb3IgY2xpZW50IGFuZCB1c2VkIHRv
IGF1dGhvcml6ZSBjYWxscyB0byB0aGUNCmNsaWVudCByZWdpc3RyYXRpb24gZW5kcG9pbnQuICBU
aGUgdHlwZSBhbmQgZm9ybWF0IG9mIHRoaXMgdG9rZW4NCmFyZSBsaWtlbHkgc2VydmljZSBzcGVj
aWZpYyBhbmQgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhpcw0Kc3BlY2lmaWNhdGlvbi4gIFRoZSBt
ZWFucyBieSB3aGljaCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzDQp0aGlzIHRva2Vu
IGFzIHdlbGwgYXMgdGhlIG1lYW5zIGJ5IHdoaWNoIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQN
CnZhbGlkYXRlcyB0aGlzIHRva2VuIGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNh
dGlvbi4gIFVzZQ0Kb2YgYW4gaW5pdGlhbCBhY2Nlc3MgdG9rZW4gaXMgcmVxdWlyZWQgd2hlbiB0
aGUgYXV0aG9yaXphdGlvbg0Kc2VydmVyIGxpbWl0cyB0aGUgcGFydGllcyB0aGF0IGNhbiByZWdp
c3RlciBhIGNsaWVudC48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoaXMgY2FuIGJlIHVzZWQgW2ZvciBleGFtcGxlXSB0byBi
aW5kIGEgY2xpZW50IHRvIGEgc3BlY2lmaWMgdXNlciwgdGhvdWdoIHRoZSBib290c3RyYXBwaW5n
IGNhbiBiZSBhIGxpdHRsZSBpbnZvbHZlZCBhbmQgcG90ZW50aWFsbHkgdGhlIGJvb3RzdHJhcHBp
bmcgc3RpbGwgaGFzIHdlYWtuZXNzZXMuIFVzZSBvZiB3aGl0ZSBib3ggY3J5cHRvIChvciBvdGhl
ciB0b29scyBsaWtlIGRldmljZSBhdHRlc3RhdGlvbnMpIGNhbiBwb3RlbnRpYWxseQ0KIGFsc28g
YnJpbmcgZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBuYXRpdmUgYXBwcyB1cCB0byBhIHN1ZmZpY2ll
bnRseSB0cnVzdGVkIGxldmVsLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk
aXY+Sm9zZXBoPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N
CjxkaXYgY2xhc3M9IiI+T24gMjkgTm92IDIwMTgsIGF0IDE0OjAyLCBDaHJpc3RpYW4gTWFpbmth
ICZsdDs8YSBocmVmPSJtYWlsdG86Q2hyaXN0aWFuLk1haW5rYT00MHJ1Yi5kZUBkbWFyYy5pZXRm
Lm9yZyIgY2xhc3M9IiI+Q2hyaXN0aWFuLk1haW5rYT00MHJ1Yi5kZUBkbWFyYy5pZXRmLm9yZzwv
YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l
Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPg0KPGRp
diBjbGFzcz0ibW96LXRleHQtaHRtbCIgbGFuZz0ieC11bmljb2RlIj5IaSw8YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQp0aGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0ITxiciBjbGFzcz0i
Ij4NClRoaXMgd2FzIGV4YWN0bHkgd2hhdCBjb25mdXNlZCB1cyBkdXJpbmcgcmVhZGluZyA8YiBj
bGFzcz0iIj4tPC9iPiB0aGUgbWFpbiB0aHJlYXQgd2Ugc2VlIGFuZCB3aGljaCBpcyBub3QgYWRk
cmVzc2VkIGlzIHJlbGF0ZWQgdG8gdGhlIGFwcCBpbXBlcnNvbmF0aW9uIGF0dGFjay48YnIgY2xh
c3M9IiI+DQpFdmVuIFBLQ0UgZG9lcyBub3QgaGVscCBhZ2FpbnN0IHRoZSBhcHAgaW1wZXJzb25h
dGlvbiBhdHRhY2suPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU28gYSAmcXVvdDtOYXRp
dmUgQXBwICYjNDM7IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiZxdW90OyBjYW4gYmUgc2Vl
biBhdCBhIGRpZmZlcmVudCAmcXVvdDtjb25maWRlbnRpYWxpdHkgbGV2ZWwmcXVvdDsgdGhhbiBh
ICZxdW90O3B1YmxpYyBjbGllbnQmcXVvdDssIGJlY2F1c2UgZXZlcnkgbmF0aXZlIEFwcCBjYW4g
ZHluYW1pY2FsbHkgcmVnaXN0ZXIgaXRzZWxmIG9uIHRoZSBJZFAuPGJyIGNsYXNzPSIiPg0KVGhl
IElkUCBjYW5ub3QgZGlzdGluZ3Vpc2gsIGZvciBleGFtcGxlLCBhbiBob25lc3QgbmF0aXZlIGNs
aWVudCBmcm9tIGFuIG1hbGljaW91cyBjbGllbnQgc3RhcnRpbmcgYW4gYXBwIGltcGVyc29uYXRp
b24gYXR0YWNrLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldlIGFncmVlIHRoYXQsIGUu
Zy4sIGEgbGVha2VkIGNvZGUgY2Fubm90IGJlIHJlZGVlbWVkIHVubGVzcyB5b3UgaGF2ZSB0aGUg
cmVzcGVjdGl2ZSBjbGllbnRfaWQvY2xpZW50X3NlY3JldC48YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpCdXQuLi4gd2UgYXNrZWQgb3Vyc2VsZnMsIGluIHdoaWNoIGNhc2VzIGRvZXMgYSBj
b2RlIGxlYWs/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KMSkgSW4gdGhlIGZyb250LWNo
YW5uZWwuIEluIHRoaXMgY2FzZSwgaXQgaXMgdHJ1ZSB0aGF0IG5vIGNsaWVudCBjcmVkZW50aWFs
cyBsZWFrIGFuZCBhbiBhdHRhY2tlciBjYW5ub3QgcmVkZWVtIHRoZSBjb2RlLjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCjIpIEluIHRoZSBiYWNrLWNoYW5uZWwuIEJ1dCBpZiB0aGlzIGNo
YW5uZWwgaXMgaW5zZWN1cmUsIHlvdSBkaXJlY3RseSBnZXQgY2xpZW50IGNyZWRlbnRpYWxzICh1
bmxlc3MgY2xpZW50X3NlY3JldF9qd3QgaXMgdXNlZCBhcyBwb2ludGVkIG91dCBieSBHZW9yZ2Up
LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvLCBEeW5hbWljIENsaWVudCBSZWdpc3Ry
YXRpb24gb25seSBoZWxwcyBpZiB0aGUgY29kZSBsZWFrcyBhbG9uZSAoYXMgaW4gMS4pLCBvciBp
ZiBpdCBsZWFrcyBvbiBkaWZmZXJlbnQgbGV2ZWxzIChlLmcuIGxvZ2ZpbGVzKS48YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiB0aGUgb3Bwb3NpdGUgc2l0ZSwgaWYgRHluYW1pYyBSZWdp
c3RyYXRpb24gaXMgYXZhaWxhYmxlLCBhbiBhdHRhY2tlciBjYW4gdmVyeSBlYXNpbHkgZG8gYW4g
YXBwIGltcGVyc29uYXRpb24gYXR0YWNrIGJ5IHJlZ2lzdGVyaW5nIG9uIHRoZSBJZFAuIFRvIGJl
IGNsZWFyLCBpdCBpcyBub3QgJnF1b3Q7aW1wZXJzb25hdGlvbiZxdW90OyBhcyBpbiB0aGUgJnF1
b3Q7b25lIHNlY3JldCBwZXIgc29mdHdhcmUmcXVvdDsgc2NlbmFyaW8sIGJlY2F1c2UgZGlmZmVy
ZW50IGNsaWVudF9pZA0KIGFuZCBjbGllbnRfc2VjcmV0IGlzIHVzZWQsIGJ1dCB0byB0aGUgYmVz
dCBvZiBteSBrbm93bGVkZ2UsIHRoZSBJZFAgY2Fubm90IGRpc3Rpbmd1aXNoIGJldHdlZW4gYW4g
aG9uZXN0IGFwcCBhbmQgYW4gYXBwIGltcGVyc29uYXRpb24gY2xpZW50IHRoYXQgaGFzIHNpbXBs
eSByZWdpc3RlcmVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkluIGFkZGl0aW9uLCBp
ZiB0aGUgSWRQIHN1cHBvcnRzIHRoZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb246PC9kaXY+
DQo8ZGl2IGNsYXNzPSJtb3otdGV4dC1odG1sIiBsYW5nPSJ4LXVuaWNvZGUiPkhvdyBjYW4gdGhl
IElkUCBkaXN0aW5ndWlzaCBiZXR3ZWVuIGNvbmZpZGVudGlhbCBhbmQgcHVibGljL25hdGl2ZSBj
bGllbnRzPzxiciBjbGFzcz0iIj4NCldpdGggcmVzcGVjdCB0byB0aGUgY29uc2VudCBwYWdlLCB3
aGljaCBtdXN0IGJlIHNob3duIGV2ZXJ5IHRpbWUgZm9yIG5hdGl2ZSBhcHBzLCB0aGlzIGlzIGFu
IGltcG9ydGFudCBpc3N1ZSwgd2hpY2ggc2hvdWxkIGJlIGFkZHJlc3NlZCBwcm9wZXJseS48YnIg
Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0IFJlZ2FyZHM8YnIgY2xhc3M9IiI+DQpWbGFk
aS9DaHJpc3RpYW4gPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJtb3otdGV4dC1o
dG1sIiBsYW5nPSJ4LXVuaWNvZGUiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
bW96LWNpdGUtcHJlZml4Ij5BbSAyOS4xMS4xOCB1bSAwMDozOCBzY2hyaWViIFJpY2hhcmQgQmFj
a21hbiwgQW5uYWJlbGxlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIj5JdCBzaG91bGQgYmUg
bm90ZWQgdGhhdCDigJx0cmFkaXRpb25hbOKAnSBjb25maWRlbnRpYWwgY2xpZW50cyB3aXRoIHJl
Z2lzdGVyZWQgcmV0dXJuIFVSTHMgYW5kIHNlcnZlci1zaWRlIHNlY3JldHMgbWF5IHByb3ZpZGUg
YSBoaWdoZXIgZGVncmVlIG9mIGNvbmZpZGVuY2UgaW4gdGhlIHRydWUgaWRlbnRpdHkgb2YgdGhl
IGNsaWVudCB0aGF0IGRvZXNu4oCZdCBjYXJyeSBvdmVyIHRvIGNvbmZpZGVudGlhbCBuYXRpdmUg
YXBwIGNsaWVudHMuIEEgbmF0aXZlIGFwcCBpbnN0YW5jZeKAmXMgcmVnaXN0cmF0aW9uIGNhbGwg
aXMgbmVjZXNzYXJpbHkgdW5hdXRoZW50aWNhdGVkIChmb3IgdGhlIHNhbWUgcmVhc29ucyB0aGF0
IHN0YXRpY2FsbHkgcmVnaXN0ZXJlZCBuYXRpdmUgYXBwIGNsaWVudHMgYXJlIHB1YmxpYyBjbGll
bnRzKSwgc28gdGhlIENsaWVudCBJbXBlcnNvbmF0aW9uIGNvbmNlcm5zIGRlc2NyaWJlZCBpbiBz
ZWN0aW9uIDguNiBvZiBSRkM4MjUyPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJl
Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgyNTIjc2VjdGlvbi04LjYiPiZsdDto
dHRwczovL3Rvb2xzLi5pZXRmLm9yZy9odG1sL3JmYzgyNTIjc2VjdGlvbi04LjYmZ3Q7PC9hPiBz
dGlsbCBhcHBseS4NCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkN
Cg0KDQpGcm9tOiBPQXV0aCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJt
YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+Jmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcm
Z3Q7PC9hPiBvbiBiZWhhbGYgb2YgRmlsaXAgU2tva2FuIDxhIGNsYXNzPSJtb3otdHh0LWxpbmst
cmZjMjM5NkUiIGhyZWY9Im1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20iPiZsdDtwYW52YS5pcEBn
bWFpbC5jb20mZ3Q7PC9hPg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOCwgMjAxOCBhdCA5
OjExIEFNDQpUbzogR2VvcmdlIEZsZXRjaGVyIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5
NkUiIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wuY29tIj4mbHQ7Z2ZmbGV0Y2hAYW9sLmNvbSZn
dDs8L2E+DQpDYzogb2F1dGggPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPg0KU3ViamVj
dDogUmU6IFtPQVVUSC1XR10gRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIHdpdGggTmF0aXZl
IEFwcHMNCg0KQXBvbG9naWVzLCBJIG1pc3NlZCB0aGUgaXNzdWVkIGluICZxdW90O2lzc3VlZCBh
IHNoYXJlZCBzZWNyZXQmcXVvdDssIGp1c3QgcmVhZGluZyAmcXVvdDtzaGFyZWQgc2VjcmV0JnF1
b3Q7IGFsb25lIGlzIHRoZSBleGFjdCBvcHBvc2l0ZSBvZiBhIHBlci1pbnN0YW5jZSBzZWNyZXQu
IFRoZSByZXN0IGlzIGNsZWFyIGFuZCBhcyB5b3Ugc2F5IGl0IGJyaW5ncyB0aGUgYmVuZWZpdCBv
ZiB0aGUgc2VjcmV0IG5ldmVyIGJlaW5nIHNlbnQgb3ZlciB0aGUgd2lyZSAoZXhjZXB0IGR1cmlu
ZyB0aGUgaW5pdGlhbCByZWdpc3RyYXRpb24gdmlhIFRMUykuDQoNCkJlc3QsDQpGaWxpcA0KDQoN
Ck9uIFdlZCwgTm92IDI4LCAyMDE4IGF0IDY6MDMgUE0gR2VvcmdlIEZsZXRjaGVyICZsdDs8YSBj
bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9s
LmNvbSI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZF
IiBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSI+Jmx0O21haWx0bzpnZmZsZXRjaEBhb2wu
Y29tJmd0OzwvYT4mZ3Q7IHdyb3RlOg0KSXQncyAmcXVvdDtjb25maWRlbnRpYWwmcXVvdDsgaW4g
dGhhdCB0aGUgc2hhcmVkIHNlY3JldCBpcyB1bmlxdWUgdG8gdGhhdCBhcHAgaW5zdGFuY2UgcmVn
aXN0cmF0aW9uIChhcyBEZW5uaXMgZGVzY3JpYmVkIGluIGhpcyByZXNwb25zZSkuIElmIGFuIGF0
dGFja2VyIGdldHMgbXkgcGhvbmUgYW5kIGNvbXByb21pc2VzIHRoZSBkYXRhIHN0b3JlZCBvbiBt
eSBkZXZpY2UsIHRoZXkgb25seSBnZXQgdGhlIHNlY3JldCBmb3IgbXkgZGV2aWNlLiBUaGlzIGlz
IG5vIGRpZmZlcmVudCB0aGFuIGEgc2VydmVyIHNpZGUgY2xpZW50IGhhdmluZyB0aGVpciBjbGll
bnQgc2VjcmV0IGNvbXByb21pc2VkIHRocm91Z2ggYW4gYXR0YWNrIChhbmQgaW4gc29tZSB3YXlz
IGlzIGJldHRlciBiZWNhdXNlIGl0J3MgaW5zdGFuY2Ugc3BlY2lmaWMpLg0KDQpUaGUgbWFpbiBw
b2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSwgaXMgdGhhdCB0aGUgJ2NsaWVudF9zZWNyZXRfand0
JyBtZXRob2QgYWxsb3dzIHRoZSBjbGllbnQgdG8gbmV2ZXIgc2VuZCB0aGUgc2hhcmVkIHNlY3Jl
dCBhY3Jvc3MgdGhlIHdpcmUgYXMgaXMgY3JlYXRlZCBpbiB0aGUgZGVmYXVsdCBPQXV0aDIgSFRU
UCBCYXNpYyBBdXRoZW50aWNhdGlvbiBtZXRob2QuDQoNClRoYW5rcywNCkdlb3JnZQ0KT24gMTEv
MjgvMTggMTE6MDMgQU0sIEZpbGlwIFNrb2thbiB3cm90ZToNCkhpIEdlb3JnZSwNCg0KIzIgZG9l
c24ndCBzZWVtIGNvbmZpZGVudGlhbCwgaXQncyBzdGlsbCBhIHNlY3JldCBzaGFyZWQgYW1vbmdz
dCBpbnN0YWxsYXRpb25zIGFuZCBhbnlvbmUgcmV2ZXJzZSBlbmdpbmVlcmluZyB0aGUgYXBrLCBl
eHRyYWN0aW5nIHRoZSBzZWNyZXQsIGNhbiBmb3JtIHRoZSBjbGllbnRfc2VjcmV0X2p3dCBjbGll
bnRfYXNzZXJ0aW9uIHdpdGggaXQganVzdCBmaW5lLg0KDQpCZXN0LA0KRmlsaXANCg0KT24gV2Vk
LCBOb3YgMjgsIDIwMTggYXQgNDo0OCBQTSBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGNsYXNzPSJt
b3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpnZmZsZXRjaD00MGFvbC5jb21A
ZG1hcmMuaWV0Zi5vcmciPmdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT48YSBj
bGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86NDBhb2wuY29tQGRtYXJj
LmlldGYub3JnIj4mbHQ7bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8L2E+Jmd0
OyB3cm90ZToNCkluIGFkZGl0aW9uLCBhIGZldyBhZGRpdGlvbmFsIHBhdHRlcm5zIGFyZSBlbmFi
bGVkLi4uDQoNCjEuIFRoZSBuYXRpdmUgYXBwIGNhbiBnZW5lcmF0ZSBhIHB1YmxpYy9wcml2YXRl
IGtleSBwYWlyIGFuZCB0aGVuIHVzZSBwcml2YXRlX3NlY3JldF9qd3QgYXMgdGhlIGNsaWVudCBj
cmVkZW50aWFsIHZhbGlkYXRpb24gbWV0aG9kIHZpYSB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGZs
b3cgKGRlZmluZWQgaW4gT3BlbklEIENvbm5lY3QpLg0KDQoyLiBNYXliZSBtb3JlIHNpbXBseSwg
aWYgdGhlIG5hdGl2ZSBhcHAgaXMgaXNzdWVkIGEgc2hhcmVkIHNlY3JldCwgdGhlIGFwcCBjYW4g
dXNlIGNsaWVudF9zZWNyZXRfand0IG1ldGhvZCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHdo
aWNoIGVuc3VyZXMgdGhlIHNoYXJlZCBzZWNyZXQgbmV2ZXIgbGVhdmVzIHRoZSBkZXZpY2UuIChB
Z2FpbiBkZWZpbmVkIGluIHRoZSBPcGVuSUQgQ29ubmVjdCBzcGVjKS4NCg0KMy4gT25jZSB0aGUg
bmF0aXZlIGFwcCBpbnN0YW5jZSBoYXMgY3JlZGVudGlhbHMsIHRoZXkgY2FuIGJlIHVzZWQgZm9y
IGFkZGl0aW9uYWwgc2VjdXJpbmcgb2YgYXBwIEFQSSB0cmFuc2FjdGlvbnMgaW4gYWRkaXRpb24g
dG8ganVzdCB0aGUgT0F1dGgyL09wZW5JRCBDb25uZWN0IGZsb3dzLg0KDQpUaGFua3MsDQpHZW9y
Z2UNCk9uIDExLzI3LzE4IDM6MjggUE0sIFdpbGxpYW0gRGVubmlzcyB3cm90ZToNCklmIHRoZSBz
ZWNyZXQgaXMgZHluYW1pY2FsbHkgcHJvdmlzaW9uZWQgdGhlbiB5b3UgaGF2ZSBhIGNvbmZpZGVu
dGlhbCBjbGllbnQuIEFueW9uZSByZXZlcnNlIGVuZ2luZWVyaW5nIHRoZWlyIG93biBpbnN0YWxs
YXRpb24gb2YgdGhlIG5hdGl2ZSBhcHAgd291bGQgb25seSBleHRyYWN0IHRoZWlyIG93biBjbGll
bnQncyBjcmVkZW50aWFscywgYXMgb3Bwb3NlZCB0byB0aGUgc2hhcmVkIHNlY3JldCBvZiBhbGwg
aW5zdGFsbGF0aW9ucy4gSGF2aW5nIGEgY29uZmlkZW50aWFsIGNsaWVudCBtZWFucyB0aGF0IHJl
cXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCAoY29kZSwgcmVmcmVzaCkgYXJlIGNsaWVudCBh
dXRoZW50aWNhdGVkLCBzbyBQS0NFIHdvdWxkbid0IGJlIG5lZWRlZC4NCg0KT24gVHVlLCBOb3Yg
MjcsIDIwMTggYXQgMTo0NCBBTSwgQ2hyaXN0aWFuIE1haW5rYSAmbHQ7PGEgY2xhc3M9Im1vei10
eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkNocmlzdGlhbi5NYWlua2E9NDBydWIu
ZGVAZG1hcmMuaWV0Zi4ub3JnIj5DaHJpc3RpYW4uTWFpbmthPTQwcnViLmRlQGRtYXJjLmlldGYu
Lm9yZzwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86Q2hy
aXN0aWFuLk1haW5rYT00MHJ1Yi5kZUBkbWFyYy5pZXRmLm9yZyI+Jmx0O21haWx0bzpDaHJpc3Rp
YW4uTWFpbmthPTQwcnViLmRlQGRtYXJjLmlldGYub3JnJmd0OzwvYT4mZ3Q7IHdyb3RlOg0KSGks
DQoNCndlIGp1c3Qgc3R1bWJsZWQgdXBvbiB0aGlzIFsxXSBzdGF0ZW1lbnQ6DQomcXVvdDtFeGNl
cHQgd2hlbiB1c2luZyBhIG1lY2hhbmlzbSBsaWtlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlv
bg0KICAgW1JGQzc1OTFdIHRvIHByb3Zpc2lvbiBwZXItaW5zdGFuY2Ugc2VjcmV0cywgbmF0aXZl
IGFwcHMgYXJlDQogICBjbGFzc2lmaWVkIGFzIHB1YmxpYyBjbGllbnRzIC4uLiZxdW90Ow0KDQpX
aGF0IGRvZXMgdGhpcyBtZWFuIGZvciB1cz8gTmF0aXZlIEFwcCAmIzQzOyBEeW5hbWljIENsaWVu
dCBSZWdpc3RyYXRpb24gPQ0KQ29uZmlkZW50aWFsIENsaWVudD8NCldoaWNoIHRocmVhdHMgYXJl
IGNvdmVyZWQgaWYgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIGlzIHVzZWQgb24NCk5hdGl2
ZSBBcHBzPw0KDQpCZXN0IFJlZ2FyZHMsDQpWbGFkaS9DaHJpc3RpYW4NCg0KWzFdOiA8YSBjbGFz
cz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvcmZjODI1MiNzZWN0aW9uLTguNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgy
NTIjc2VjdGlvbi04LjQ8L2E+DQoNCi0tDQpEci4tSW5nLiBDaHJpc3RpYW4gTWFpbmthDQpIb3Jz
dCBHw7ZydHogSW5zdGl0dXRlIGZvciBJVC1TZWN1cml0eQ0KQ2hhaXIgZm9yIE5ldHdvcmsgYW5k
IERhdGEgU2VjdXJpdHkNClJ1aHItVW5pdmVyc2l0eSBCb2NodW0sIEdlcm1hbnkNCg0KVW5pdmVy
c2l0w6R0c3N0ci4gMTUwLCBJRCAyLzQ2Mw0KRC00NDgwMSBCb2NodW0sIEdlcm1hbnkNCg0KVGVs
ZWZvbjogJiM0Mzs0OSAoMCkgMjM0IC8gMzItMjY3OTYNCkZheDogJiM0Mzs0OSAoMCkgMjM0IC8g
MzItMTQzNDcNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly9u
ZHMucnViLmRlL2NoYWlyL3Blb3BsZS9jbWFpbmthLyI+aHR0cDovL25kcy5ydWIuZGUvY2hhaXIv
cGVvcGxlL2NtYWlua2EvPC9hPg0KQENoZWFyaVgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0i
bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B
dXRoQGlldGYub3JnPC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyI+Jmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8L2E+DQo8
YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KPGEgY2xhc3M9Im1vei10
eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp
ZXRmLm9yZzwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciPiZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPg0KDQo8YSBj
bGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoPC9hPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJl
dmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxh
IGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyI+Jmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1s
aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPg0K
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
T0F1dGggbWFpbGluZyBsaXN0DQoNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGEgY2xhc3M9
Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj4mbHQ7
bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0OzwvYT4NCg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1m
cmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YSBjbGFz
cz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJodHRwczovL3d3dy4uaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCI+Jmx0O2h0dHBzOi8vd3d3Li5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoJmd0OzwvYT4NCg0KPC9wcmU+DQo8YnIgY2xhc3M9IiI+DQo8ZmllbGRzZXQg
Y2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0Pg0KPHByZSBjbGFzcz0ibW96
LXF1b3RlLXByZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRl
ZCIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4NCjxhIGNs
YXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgY2xhc3M9Im1vei1zaWdu
YXR1cmUiIGNvbHM9IjcyIj4tLSANCkRyLi1JbmcuIENocmlzdGlhbiBNYWlua2ENCkhvcnN0IEfD
tnJ0eiBJbnN0aXR1dGUgZm9yIElULVNlY3VyaXR5IA0KQ2hhaXIgZm9yIE5ldHdvcmsgYW5kIERh
dGEgU2VjdXJpdHkgDQpSdWhyLVVuaXZlcnNpdHkgQm9jaHVtLCBHZXJtYW55DQoNClVuaXZlcnNp
dMOkdHNzdHIuIDE1MCwgSUQgMi80NjMNCkQtNDQ4MDEgQm9jaHVtLCBHZXJtYW55DQoNClRlbGVm
b246ICYjNDM7NDkgKDApIDIzNCAvIDMyLTI2Nzk2DQpGYXg6ICYjNDM7NDkgKDApIDIzNCAvIDMy
LTE0MzQ3DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vbmRz
LnJ1Yi5kZS9jaGFpci9wZW9wbGUvY21haW5rYS8iPmh0dHA6Ly9uZHMucnViLmRlL2NoYWlyL3Bl
b3BsZS9jbWFpbmthLzwvYT4NCkBDaGVhcmlYPC9wcmU+DQo8L2Rpdj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBj
bGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_OSBPR01MB286944CFB04C0E88801478AAF9D20OSBPR01MB2869jpnp_--


From nobody Thu Nov 29 10:06:10 2018
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 0305F130E02 for ; Thu, 29 Nov 2018 10:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 v7IsPND215TP for ; Thu, 29 Nov 2018 10:06:04 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) (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 D58A4130DE9 for ; Thu, 29 Nov 2018 10:06:03 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gSQhN-0004wJ-8S; Thu, 29 Nov 2018 19:06:01 +0100
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_A6298A0F-5FFB-47E4-A87B-6DCAE57064F5"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Thu, 29 Nov 2018 19:06:00 +0100
In-Reply-To: 
Cc: Daniel Fett 
To: IETF oauth WG 
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>   
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 29 Nov 2018 18:06:09 -0000

--Apple-Mail=_A6298A0F-5FFB-47E4-A87B-6DCAE57064F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,=20

based on your feedback on the list and off list, Daniel and I polished =
the text. That=E2=80=99s our proposal:

=E2=80=94
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing access=20=

tokens in the authorization response, such as "token id_token" and "code =
token id_token=E2=80=9C,=20
unless the issued access tokens are sender-constrained and access token =
injection in=20
the authorization response is prevented.=20
=E2=80=94

Explantation:=20
- we wanted to have the right balance between a generic definition of =
the response types we do not recommend/allow to be used and a =
concrete/actionable list of the affected response types.=20
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and =
supported by William

We look forward to seeing your feedback.

kind regards,
Torsten. =20

> Am 29.11.2018 um 15:15 schrieb John Bradley :
>=20
> I am ok with that. =20
>=20
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt =
=20
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> >=20
> > That works.
>=20
> Good!
>=20
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C =
(only). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token =
would sender constrained. This completely ignores the fact implicit also =
shall be abandoned because of its vulnerability for access token =
injection.=20
>=20
> I therefore propose a modified text:=20
>=20
>    In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant. Furthermore, clients SHOULD only use other response types =
causing the authorization server to
>    issue an access token in the authorization response, if the =
particular response type detects access token=20
>    injection and the issued access tokens are sender-constrained.
>=20
> Or we just state:
>=20
>   In order to avoid these issues, Clients SHOULD NOT use the response =
type =E2=80=9Etoken". The response types
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=9C=
 SOULD NOT be used, if the issued access tokens are not=20
> sender-constrained.
>=20
> >=20
> > In fact, I would further go and say MUST NOT but that probably is =
too much for a security consideration.
> >=20
>=20
> Mike suggested to go with a SHOULD NOT to get the message out but give =
implementors time to move/change.
>=20
> > Best,
> >=20
> > Nat
> >=20
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> >=20
> > =
=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6=
=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81=
=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=
=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=
=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=
=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=
=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3=
=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81=
=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5=
=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4=
=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89=
=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=
=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=
=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> >=20
> > PLEASE READ :This e-mail is confidential and intended for the named =
recipient only.
> > If you are not an intended recipient, please notify the sender and =
delete this e-mail.
> > =20
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt =

> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > =E5=AE=9B=E5=85=88: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- =
Recommend authorization code instead of implicit
> > =20
> > Hi Nat,=20
> >=20
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> >>=20
> >> I would support
> >>=20
> >> 1) clearly defining Implicit as the flow that returns access token =
from the authorization endpoint ( some people confuses implicit as the =
flow that returns ID Token in the front channel)
> >=20
> > That=E2=80=99s the current text:=20
> >=20
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server =
to
> >    issue an access token in the authorization response.
> >=20
> > What would you like to modify?=20
> >=20
> >>=20
> >> 2) Banning the returning of the access token that are not sender =
constrained from the authorization endpoint
> >=20
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server =
to
> >    issue an access token in the authorization response, if this =
access tokens is not sender-constraint.
> >=20
> > What about this?
> >=20
> > kind regards,
> > Torsten.
> >=20
> >>=20
> >> Best,
> >>=20
> >> Nat
> >>=20
> >>=20
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> >> =20
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick =
Hardt  =E3=81=AE=E4=BB=A3=E7=90=86)
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> >> Cc: oauth@ietf.org
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- =
Recommend authorization code instead of implicit
> >> =20
> >> +1
> >>=20
> >> While there are various mechanisms to alleviate some of the issues =
of implicit, I don't think we can recommend specifics, and there may be =
future ones in the future. I think we all agree that implicit without =
any mitigation is problematic.=20
> >>=20
> >> How about we recommend against using implicit alone?=20
> >>=20
> >>=20
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig =
 wrote:
> >> Hi all,
> >>=20
> >> The authors of the OAuth Security Topics draft came to the =
conclusion that it is not possible to adequately secure the implicit =
flow against token injection since potential solutions like token =
binding or JARM are in an early stage of adoption. For this reason, and =
since CORS allows browser-based apps to send requests to the token =
endpoint, Torsten suggested to use the authorization code instead of the =
implicit grant in call cases in his presentation (see =
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-=
draft-ietf-oauth-security-topics-01).
> >>=20
> >> A hum in the room at IETF#103 concluded strong support for his =
recommendations. We would like to confirm the discussion on the list.
> >>=20
> >> Please provide a response by December 3rd.
> >>=20
> >> Ciao
> >>=20
> >> Hannes & Rifaat
> >>=20
> >> =20
> >>=20
> >> IMPORTANT NOTICE: The contents of this email and any attachments =
are confidential and may also be privileged. If you are not the intended =
recipient, please 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.
> >> _______________________________________________
> >> 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
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A6298A0F-5FFB-47E4-A87B-6DCAE57064F5
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCygw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ
uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzAp
BgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAw
WhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtM
taDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlA
ckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHW
se9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4E
FgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RD
QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwF
AAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr
rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU
50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9Dqqq
AJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/5
6ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3
ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+
IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBr
Gk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggy
h/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9K
VkfKehIxggPKMIIDxgIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7
BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCSJtR3C5gtrmIWapJ6EgOVMA0GCWCGSAFlAwQCAQUAoIIB7TAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODExMjkxODA2MDBaMC8GCSqGSIb3DQEJBDEiBCAU
PXe1VGjMDoYpL3PF13cPT7nP/BIxQV2nuiaut8sNAzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJIm1HcLmC2uYhZqknoSA5UwgcAG
CyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsG
A1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIRAJIm1HcLmC2uYhZqknoSA5UwDQYJKoZIhvcNAQEBBQAEggEAtKComejUrpuu62gyl+RGDnhe
Wmp3fpvs3GC8jzKE2ijo4A+OqX3h/gdMErvVwHd7/wGiyq/Wh4BvAGM9fPArYwjA1oocXI09ezPf
tYkXdA8JD/qi00xBc81vHKWoxHIw94IcSK20YPlj7BimJ7+y4L7E9Ds083oMp9/zSK4nYZ73VEx3
23W/zSvtw+yAPIhx+WCFbSKz3gvX4+jfMluNvvfVi8GjRXuw28oqGlMA1r5JIKxll/mXl/kwwElE
3hi5cFlwKU6YOaD3jyKDDPbq3WOlkLmdSMmP94SWQKaTMAWwHlgothgO3VACzaiuV5vqW4P5cIP3
7iNJYbPs1JduNgAAAAAAAA==
--Apple-Mail=_A6298A0F-5FFB-47E4-A87B-6DCAE57064F5--


From nobody Thu Nov 29 10:34:19 2018
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 2F4E4130E4A for ; Thu, 29 Nov 2018 10:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 COQtgskzVqMw for ; Thu, 29 Nov 2018 10:34:13 -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 6F8EF130E47 for ; Thu, 29 Nov 2018 10:34:13 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id p4so2914237wrt.7 for ; Thu, 29 Nov 2018 10:34:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yeElllRClDst3eGhT+jSmzlDmbZNfzNMKXHG3JyqJhQ=; b=Ud5+swtH3U398ZGg0JlOkdGqOtFXkL80o5flYSGQ4kPmbJMo/mgnOMPlLq1F6tPxU3 JhiN2ZRvSyS89AKkrQyXpIQVV2UdvcquG6SlGVuMfplmWT3hy1pSVoaOL1Pgl3x3SOex s9XBBCAT3mmc5Hayx0t3Nfnlmp8HBMFugDL+8hhMoogFt9ED+BDEuAoG10X40/ieSNPo +ZInZVE3jjho//DAZiSm2kVMNZ7prltfXiaHqYUrZTQPrbpXi45b+dT7S+wSMSRyV0Gj 2m6CYnabsyOCfPRNw9o4pdDeAPD5pTFzotBxnq4q8UchbNTpYq0aYa8YaXavanFcVVMh HK5Q==
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=yeElllRClDst3eGhT+jSmzlDmbZNfzNMKXHG3JyqJhQ=; b=kgGASsAv0EY2pGpKZTuu9aKCIKtcrBggd+LMg7d4NJIbu+xc28WmWSE5rmQGGuXSeo l1wY6xvgA3qBooVvkGaJrEYcp7Cp52ri+xhmDqBOt7z/w7zpf2bOkzmK53Ic3BYtdZqW B6mvt5c+7FgDoqtHu8tzKee47971l9yXX5wk7wTpfJlMrq7T9TVpH1Ew4XpDUlDs7uOg AeLGCpADvu5s8+Fmks6FRDvesHYv9MB51rCZnJErgJmoZYxNwI892KD2AKPdC+q20wbU m7lqIk00BegrYs4+0mCn329Nm/jZQLaASTahm9Xc460TNeSm74z85vCb4QLWr+d4sCVi YVtg==
X-Gm-Message-State: AA+aEWbok+9cl4zx/osDjysn5xDzvMrPeR1he6/8emoV+qilS/AGAfUI oUrw4CUkALVN1GAZUpP7JECh0P2f5Kd6rSr5RPfyUw==
X-Google-Smtp-Source: AFSGD/U2DsrIYG2g6f4zNu+3UFmWbfuVrql/W4o3nMIH+/D79zIX9l40l5ePg4p8/Y3M3fQn5TtplcXrIVv25M4s380=
X-Received: by 2002:adf:9422:: with SMTP id 31mr2552463wrq.106.1543516451158;  Thu, 29 Nov 2018 10:34:11 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>    
In-Reply-To: 
From: John Bradley 
Date: Thu, 29 Nov 2018 15:33:57 -0300
Message-ID: 
To: Torsten Lodderstedt 
Cc: IETF oauth WG , Daniel Fett 
Content-Type: multipart/alternative; boundary="000000000000c6ddcc057bd1ed86"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 29 Nov 2018 18:34:17 -0000

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

+1

On Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt  Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished th=
e
> text. That=E2=80=99s our proposal:
>
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access
> tokens in the authorization response, such as "token id_token" and "code
> token id_token=E2=80=9C,
> unless the issued access tokens are sender-constrained and access token
> injection in
> the authorization response is prevented.
> =E2=80=94
>
> Explantation:
> - we wanted to have the right balance between a generic definition of the
> response types we do not recommend/allow to be used and a
> concrete/actionable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supporte=
d
> by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten.
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley :
> >
> > I am ok with that.
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
> torsten@lodderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (on=
ly). It would
> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender constr=
ained. This
> completely ignores the fact implicit also shall be abandoned because of i=
ts
> vulnerability for access token injection.
> >
> > I therefore propose a modified text:
> >
> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant. Furthermore, clients SHOULD only use other response types
> causing the authorization server to
> >    issue an access token in the authorization response, if the
> particular response type detects access token
> >    injection and the issued access tokens are sender-constrained.
> >
> > Or we just state:
> >
> >   In order to avoid these issues, Clients SHOULD NOT use the response
> type =E2=80=9Etoken". The response types
> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the
> issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probably is too
> much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but give
> implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> > >
> > >
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> > >
> > > PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> > > If you are not an intended recipient, please notify the sender and
> delete this e-mail.
> > >
> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > > =E5=AE=9B=E5=85=88: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend=
 authorization
> code instead of implicit
> > >
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns access token
> from the authorization endpoint ( some people confuses implicit as the fl=
ow
> that returns ID Token in the front channel)
> > >
> > > That=E2=80=99s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response, if this acces=
s
> tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> > >>
> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Ha=
rdt 
> =E3=81=AE=E4=BB=A3=E7=90=86)
> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> > >> Cc: oauth@ietf.org
> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization
> code instead of implicit
> > >>
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of the issues o=
f
> implicit, I don't think we can recommend specifics, and there may be futu=
re
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone?
> > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to the conclusio=
n
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM are =
in
> an early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
> ).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> Ciao
> > >>
> > >> Hannes & Rifaat
> > >>
> > >>
> > >>
> > >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    +1

    O=
n Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt <torsten@lodderstedt.net wrote:
    Hi all, 
    

    
based on your feedback on the list and off list, Daniel and I polished the =
text. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing =
access 
    
tokens in the authorization response, such as "token id_token" an=
d "code token id_token=E2=80=9C, 
    
unless the issued access tokens are sender-constrained and access token inj=
ection in 
    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionabl=
e list of the affected response types. 
    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported =
by William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.=C2=A0 
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com&g=
t;:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lod=
derstedt.net wrote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co=
.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token 
    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten=
@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nr=
i.co.jp>:
    
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf=
.org> (Dick Hardt <dick.hardt@gmail.com> =E3=81=AE=E4=BB=
=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <=
Hannes.Tschofenig@arm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this reason, and since CORS allows br=
owser-based apps to send requests to the token endpoint, Torsten suggested =
to use the authorization code instead of the implicit grant in call cases i=
n his presentation (see https://datatracker.ietf.org/m=
eeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topic=
s-01).
    
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy the i=
nformation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@ietf.org
    
> >> https://www.ietf.org/mailman/l=
istinfo/oauth
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@ietf.org
    
> >> https://www.ietf.org/mailman/l=
istinfo/oauth
    
> > 
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org
    
> https://www.ietf.org/mailman/listinfo/oau=
th
    

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

    

--000000000000c6ddcc057bd1ed86--


From nobody Thu Nov 29 10:43:14 2018
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 6890D130E5C for ; Thu, 29 Nov 2018 10:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDnjqTOg2OOR for ; Thu, 29 Nov 2018 10:43:10 -0800 (PST)
Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864ED130E58 for ; Thu, 29 Nov 2018 10:43:09 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id E2A9677EE8; Fri, 30 Nov 2018 03:43:08 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 834F34E0046; Fri, 30 Nov 2018 03:43:08 +0900 (JST)
Received: from nriea02.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id wATIh8kY010061; Fri, 30 Nov 2018 03:43:08 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp with ESMTP id wATIh8TF010060; Fri, 30 Nov 2018 03:43:08 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wATIh7iD041865; Fri, 30 Nov 2018 03:43:07 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id wATIh7tn041864; Fri, 30 Nov 2018 03:43:07 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id wATIh7gX041861; Fri, 30 Nov 2018 03:43:07 +0900
Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM05PA.cu.nri.co.jp (172.159.253.47) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 03:43:06 +0900
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (23.103.139.145) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 03:43:06 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vfJUDDLSsELdcSGqoilg56yAKSiOr9DKLRX2PofCfyw=; b=Pk8VDpJ9l/nxM4ul2yjoZ20XMQCHDqGdcVhCQrRhZu/3HVkAk8H8D2Tl2hOdQBin4/neuz9aNCcSpFzERKlriuQD6WpZYa0AMSi0lVVcXvBStT3HLkfrQgdNS1QsbJe4OJL3bGEmt/mlKznqb0WAeRMFY+iouOjILm7XZ6Xbn+o=
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com (52.134.253.15) by OSBPR01MB4471.jpnprd01.prod.outlook.com (20.179.181.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.15; Thu, 29 Nov 2018 18:43:05 +0000
Received: from OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c]) by OSBPR01MB2869.jpnprd01.prod.outlook.com ([fe80::d1ae:ff36:e681:ce6c%4]) with mapi id 15.20.1294.045; Thu, 29 Nov 2018 18:43:05 +0000
From: n-sakimura 
To: John Bradley , Torsten Lodderstedt 
CC: Daniel Fett , IETF oauth WG 
Thread-Topic: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Thread-Index: AdR/8wsdlCSgLoNZTem+1MxrAorhbwHYZjwAAABEwfcABVOygAAAbOyYAAB2LIAAH9tBAAAIC/AAAAD55YAAAFGgTA==
Date: Thu, 29 Nov 2018 18:43:05 +0000
Message-ID: 
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>    , 
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [13.86.120.238]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; OSBPR01MB4471; 6:f+fwwcsJTLVaciQwejyt1PU0P/E6hsg3Q7r37gDX3zqqmdMFljoLA+DbqXZLpa99Vv5T0bSBvqfD11AaATyFEOY/f1rzt3pmFYCQMtW1Y3yMSsqw+WVpo/Bocz75uYH2r7uF9FAXaodhxhkcwujuhg5CSqWoopJ3c9j4Y8WF20DQtnBXrBaInbB6f/u9ThKXkc2/HUvwD2f6YZSsvKcBkTF9JYDNG1HQ/4qQirEPqTKMjnHO2Ysiq/GgBVNMEldHEWs/Lbevz+rYv4BAvm2MCdjmrKOVcnXbvW35Y4o/568vOQXrYd578juf1trnfJl+mR0LEvmPzG0w7RvWGuLM50/fRnomH5Kq8b5KP/gNG4vnm/wICFRI4RX9gmTcLmiXO+VN+S7VUAeGSt63750OdH9pmEnTjVjPeNDyPA8xxCpnFiG3UKpMthmI79t5GAy7bBfj5I3Faxtb4KbyPQdDig==; 5:GJ1kvjtbApH2xpUVv6sCprg/e3dEO4OaEAQQ4Llsxz5s3cr04gHfjPr7UuALCkpqZzHw0/czzbWDaRMmz5axnEwxQfdw5NQ2Atf68si2HmGWrKlI1jOrh5/LbDgz6Uz2FIwMt4/7fUZ5Q+hNSdcKMpzXHJrovYUOSCpUmGGd7jc=; 7:53TSD2r8zfXlJ+N3wsk+agq9Hka1E2PhigXOjfDKuF6fjlNXzjDfCuTjHL5Lb7rzjeC5YZCxGX8eSikq55cktRluyNS2siAt2Ld3EEgAA+BNY9xT/LBWpKNCh/xCg8KURH4du0BEG2JoFn8FOtwYLg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: eaf5d306-cffc-43be-713c-08d6562a7fd1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB4471; 
x-ms-traffictypediagnostic: OSBPR01MB4471:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231453)(999002)(944501410)(52105112)(10201501046)(148016)(149066)(150057)(6041310)(2016111802025)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSBPR01MB4471; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB4471; 
x-forefront-prvs: 0871917CDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(136003)(39840400004)(366004)(53754006)(40434004)(365934003)(189003)(199004)(93886005)(6306002)(26005)(486006)(186003)(25786009)(561944003)(33656002)(97736004)(11346002)(446003)(606006)(476003)(3846002)(8676002)(6116002)(81166006)(81156014)(8936002)(5024004)(14444005)(256004)(6506007)(99286004)(102836004)(71200400001)(45080400002)(68736007)(71190400001)(7696005)(966005)(508600001)(53546011)(5660300001)(76176011)(86362001)(15650500001)(66066001)(66574009)(74316002)(14454004)(105586002)(229853002)(106356001)(6246003)(110136005)(54906003)(6436002)(9686003)(236005)(2906002)(316002)(7736002)(54896002)(74482002)(4326008)(55016002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB4471; H:OSBPR01MB2869.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-microsoft-antispam-message-info: /CzIXbeEvI+I9HPQo7e3ijA/usVwRDd3QbluSG9GDpLuiZ/gQGcQjlPBsNI0ommSNhCf9kUp7Q3a1uUMZf9CIiSQQWTqnhlau3BGY86I2EtPLrBunRnfVjr+sIAuBzsojFJlN8oGxkbq2+0hmJ9/qQjLqV/6/BqKhSYgLXkN1KAcocotT5y299C34Gl1wwIlPJ91xvKvwZQdu9fOxkij6VZtO9SVkiaz+viWGX6gsppxdJfKI4pCUlFAIpOvaAx17o6un6mnydIbaz8IIEWfOBNezrBD2UEXqshlEHRUYhNt83SMDaAp1PTXl9CHHoz/+CqD+hybCUSu6GL40p3T1DT0qlKueuVJQWx1dCVcVy4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_OSBPR01MB28696549CFF704BFDEA6A6EFF9D20OSBPR01MB2869jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: eaf5d306-cffc-43be-713c-08d6562a7fd1
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2018 18:43:05.1610 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB4471
X-OrganizationHeadersPreserved: OSBPR01MB4471.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 29 Nov 2018 18:43:13 -0000

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

KzENCg0KTmF0IFNha2ltdXJhIC8gbi1zYWtpbXVyYUBucmkuY28uanAgLyArODEtOTAtNjAxMy02
Mjc2DQoNCuOBk+OBruODoeODvOODq+OBq+OBr+OAgeacrOadpeOBruWum+WFiOOBruaWueOBruOB
v+OBq+mZkOWumuOBleOCjOOBn+apn+WvhuaDheWgseOBjOWQq+OBvuOCjOOBpuOBhOOCi+WgtOWQ
iOOBjOOBlOOBluOBhOOBvuOBmeOAguOBiuW/g+OBguOBn+OCiuOBruOBquOBhOWgtOWQiOOBr+OA
geiqoOOBq+eUs+OBl+ios+OBlOOBluOBhOOBvuOBm+OCk+OBjOOAgemAgeS/oeiAheOBvuOBp+OB
iuefpeOCieOBm+mgguOBjeOAgeOBvuOBn+WPl+S/oeOBleOCjOOBn+ODoeODvOODq+OBr+WJiumZ
pOOBl+OBpuOBj+OBoOOBleOBhOOBvuOBmeOCiOOBhuOBiumhmOOBhOeUs+OBl+S4iuOBkuOBvuOB
meOAgg0KDQpQTEVBU0UgUkVBRCA6VGhpcyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRl
bmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBvbmx5Lg0KSWYgeW91IGFyZSBub3QgYW4gaW50
ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz
IGUtbWFpbC4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBPQXV0aCA8
b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpvaG4gQnJhZGxleSA8dmU3anRi
QHZlN2p0Yi5jb20+DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjksIDIwMTggNzozMzo1NyBQ
TQ0KVG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCkNjOiBEYW5pZWwgRmV0dDsgSUVURiBvYXV0aCBX
Rw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNzIC0tIFJlY29t
bWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KDQorMQ0KDQpPbiBU
aHUsIE5vdiAyOSwgMjAxOCwgMzowNiBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxv
ZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KSGkg
YWxsLA0KDQpiYXNlZCBvbiB5b3VyIGZlZWRiYWNrIG9uIHRoZSBsaXN0IGFuZCBvZmYgbGlzdCwg
RGFuaWVsIGFuZCBJIHBvbGlzaGVkIHRoZSB0ZXh0LiBUaGF04oCZcyBvdXIgcHJvcG9zYWw6DQoN
CuKAlA0KSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBjbGllbnRzIE1VU1QgTk9UIHVz
ZSB0aGUgaW1wbGljaXQNCmdyYW50IChyZXNwb25zZSB0eXBlICJ0b2tlbiIpIG9yIGFueSBvdGhl
ciByZXNwb25zZSB0eXBlIGlzc3VpbmcgYWNjZXNzDQp0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRp
b24gcmVzcG9uc2UsIHN1Y2ggYXMgInRva2VuIGlkX3Rva2VuIiBhbmQgImNvZGUgdG9rZW4gaWRf
dG9rZW7igJwsDQp1bmxlc3MgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW5zIGFyZSBzZW5kZXItY29u
c3RyYWluZWQgYW5kIGFjY2VzcyB0b2tlbiBpbmplY3Rpb24gaW4NCnRoZSBhdXRob3JpemF0aW9u
IHJlc3BvbnNlIGlzIHByZXZlbnRlZC4NCuKAlA0KDQpFeHBsYW50YXRpb246DQotIHdlIHdhbnRl
ZCB0byBoYXZlIHRoZSByaWdodCBiYWxhbmNlIGJldHdlZW4gYSBnZW5lcmljIGRlZmluaXRpb24g
b2YgdGhlIHJlc3BvbnNlIHR5cGVzIHdlIGRvIG5vdCByZWNvbW1lbmQvYWxsb3cgdG8gYmUgdXNl
ZCBhbmQgYSBjb25jcmV0ZS9hY3Rpb25hYmxlIGxpc3Qgb2YgdGhlIGFmZmVjdGVkIHJlc3BvbnNl
IHR5cGVzLg0KLSB3ZSBjaGFuZ2VkIGZyb20gU0hPVUxEIE5PVCB0byBNVVNUIE5PVCBhcyBzdWdn
ZXN0ZWQgYnkgTmF0IGFuZCBzdXBwb3J0ZWQgYnkgV2lsbGlhbQ0KDQpXZSBsb29rIGZvcndhcmQg
dG8gc2VlaW5nIHlvdXIgZmVlZGJhY2suDQoNCmtpbmQgcmVnYXJkcywNClRvcnN0ZW4uDQoNCj4g
QW0gMjkuMTEuMjAxOCB1bSAxNToxNSBzY2hyaWViIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0
Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj46DQo+DQo+IEkgYW0gb2sgd2l0aCB0aGF0
Lg0KPg0KPiBPbiBXZWQsIE5vdiAyOCwgMjAxOCwgODowMyBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0
IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+
IHdyb3RlOg0KPg0KPiA+IEFtIDI4LjExLjIwMTggdW0gMjM6NTAgc2NocmllYiBuLXNha2ltdXJh
IDxuLXNha2ltdXJhQG5yaS5jby4uanA8bWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwPj46DQo+
ID4NCj4gPiBUaGF0IHdvcmtzLg0KPg0KPiBHb29kIQ0KPg0KPiBJIGp1c3QgcmVhbGl6ZWQgdGhp
cyB0ZXh0IGhhcyBhbiBpc3N1ZSB3aXRoIOKAnnRva2Vu4oCcIChvbmx5KS4gSXQgd291bGQgYWxs
b3cg4oCedG9rZW7igJwgdG8gYmUgdXNlZCBpZiB0aGUgdG9rZW4gd291bGQgc2VuZGVyIGNvbnN0
cmFpbmVkLiBUaGlzIGNvbXBsZXRlbHkgaWdub3JlcyB0aGUgZmFjdCBpbXBsaWNpdCBhbHNvIHNo
YWxsIGJlIGFiYW5kb25lZCBiZWNhdXNlIG9mIGl0cyB2dWxuZXJhYmlsaXR5IGZvciBhY2Nlc3Mg
dG9rZW4gaW5qZWN0aW9uLg0KPg0KPiBJIHRoZXJlZm9yZSBwcm9wb3NlIGEgbW9kaWZpZWQgdGV4
dDoNCj4NCj4gICAgSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VM
RCBOT1QgdXNlIHRoZSBpbXBsaWNpdA0KPiAgICBncmFudC4gRnVydGhlcm1vcmUsIGNsaWVudHMg
U0hPVUxEIG9ubHkgdXNlIG90aGVyIHJlc3BvbnNlIHR5cGVzIGNhdXNpbmcgdGhlIGF1dGhvcml6
YXRpb24gc2VydmVyIHRvDQo+ICAgIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiBpbiB0aGUgYXV0aG9y
aXphdGlvbiByZXNwb25zZSwgaWYgdGhlIHBhcnRpY3VsYXIgcmVzcG9uc2UgdHlwZSBkZXRlY3Rz
IGFjY2VzcyB0b2tlbg0KPiAgICBpbmplY3Rpb24gYW5kIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2Vu
cyBhcmUgc2VuZGVyLWNvbnN0cmFpbmVkLg0KPg0KPiBPciB3ZSBqdXN0IHN0YXRlOg0KPg0KPiAg
IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0
aGUgcmVzcG9uc2UgdHlwZSDigJ50b2tlbiIuIFRoZSByZXNwb25zZSB0eXBlcw0KPiDigJ50b2tl
biBpZF90b2tlbuKAnCBhbmQg4oCeY29kZSB0b2tlbiBpZF90b2tlbuKAnCBTT1VMRCBOT1QgYmUg
dXNlZCwgaWYgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW5zIGFyZSBub3QNCj4gc2VuZGVyLWNvbnN0
cmFpbmVkLg0KPg0KPiA+DQo+ID4gSW4gZmFjdCwgSSB3b3VsZCBmdXJ0aGVyIGdvIGFuZCBzYXkg
TVVTVCBOT1QgYnV0IHRoYXQgcHJvYmFibHkgaXMgdG9vIG11Y2ggZm9yIGEgc2VjdXJpdHkgY29u
c2lkZXJhdGlvbi4NCj4gPg0KPg0KPiBNaWtlIHN1Z2dlc3RlZCB0byBnbyB3aXRoIGEgU0hPVUxE
IE5PVCB0byBnZXQgdGhlIG1lc3NhZ2Ugb3V0IGJ1dCBnaXZlIGltcGxlbWVudG9ycyB0aW1lIHRv
IG1vdmUvY2hhbmdlLg0KPg0KPiA+IEJlc3QsDQo+ID4NCj4gPiBOYXQNCj4gPg0KPiA+IE5hdCBT
YWtpbXVyYSAvIG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5q
cD4gLyArODEtOTAtNjAxMy02Mjc2DQo+ID4NCj4gPiDjgZPjga7jg6Hjg7zjg6vjgavjga/jgIHm
nKzmnaXjga7lrpvlhYjjga7mlrnjga7jgb/jgavpmZDlrprjgZXjgozjgZ/mqZ/lr4bmg4XloLHj
gYzlkKvjgb7jgozjgabjgYTjgovloLTlkIjjgYzjgZTjgZbjgYTjgb7jgZnjgILjgYrlv4PjgYLj
gZ/jgorjga7jgarjgYTloLTlkIjjga/jgIHoqqDjgavnlLPjgZfoqLPjgZTjgZbjgYTjgb7jgZvj
gpPjgYzjgIHpgIHkv6HogIXjgb7jgafjgYrnn6XjgonjgZvpoILjgY3jgIHjgb7jgZ/lj5fkv6Hj
gZXjgozjgZ/jg6Hjg7zjg6vjga/liYrpmaTjgZfjgabjgY/jgaDjgZXjgYTjgb7jgZnjgojjgYbj
gYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIINCj4gPg0KPiA+IFBMRUFTRSBSRUFEIDpUaGlz
IGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBp
ZW50IG9ubHkuDQo+ID4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGUtbWFpbC4NCj4gPg0KPiA+IOW3
ruWHuuS6ujogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFp
bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4NCj4gPiDpgIHkv6Hml6XmmYI6IOawtOabnOaX
pSwgMTHmnIggMjgsIDIwMTggMTE6Mzgg5Y2I5b6MDQo+ID4g5a6b5YWIOiBuLXNha2ltdXJhDQo+
ID4gQ2M6IERpY2sgSGFyZHQ7IEhhbm5lcyBUc2Nob2ZlbmlnOyBvYXV0aEBpZXRmLm9yZzxtYWls
dG86b2F1dGhAaWV0Zi5vcmc+DQo+ID4g5Lu25ZCNOiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1
cml0eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGlt
cGxpY2l0DQo+ID4NCj4gPiBIaSBOYXQsDQo+ID4NCj4gPj4gQW0gMjguMTEuMjAxOCB1bSAyMTox
MCBzY2hyaWViIG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2lt
dXJhQG5yaS5jby5qcD4+Og0KPiA+Pg0KPiA+PiBJIHdvdWxkIHN1cHBvcnQNCj4gPj4NCj4gPj4g
MSkgY2xlYXJseSBkZWZpbmluZyBJbXBsaWNpdCBhcyB0aGUgZmxvdyB0aGF0IHJldHVybnMgYWNj
ZXNzIHRva2VuIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgKCBzb21lIHBlb3BsZSBj
b25mdXNlcyBpbXBsaWNpdCBhcyB0aGUgZmxvdyB0aGF0IHJldHVybnMgSUQgVG9rZW4gaW4gdGhl
IGZyb250IGNoYW5uZWwpDQo+ID4NCj4gPiBUaGF04oCZcyB0aGUgY3VycmVudCB0ZXh0Og0KPiA+
DQo+ID4gSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGllbnRzIFNIT1VMRCBOT1Qg
dXNlIHRoZSBpbXBsaWNpdA0KPiA+ICAgIGdyYW50IG9yIGFueSBvdGhlciByZXNwb25zZSB0eXBl
IGNhdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvDQo+ID4gICAgaXNzdWUgYW4gYWNj
ZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLg0KPiA+DQo+ID4gV2hhdCB3
b3VsZCB5b3UgbGlrZSB0byBtb2RpZnk/DQo+ID4NCj4gPj4NCj4gPj4gMikgQmFubmluZyB0aGUg
cmV0dXJuaW5nIG9mIHRoZSBhY2Nlc3MgdG9rZW4gdGhhdCBhcmUgbm90IHNlbmRlciBjb25zdHJh
aW5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50DQo+ID4NCj4gPiBJbiBvcmRlciB0
byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0
DQo+ID4gICAgZ3JhbnQgb3IgYW55IG90aGVyIHJlc3BvbnNlIHR5cGUgY2F1c2luZyB0aGUgYXV0
aG9yaXphdGlvbiBzZXJ2ZXIgdG8NCj4gPiAgICBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhl
IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIGlmIHRoaXMgYWNjZXNzIHRva2VucyBpcyBub3Qgc2Vu
ZGVyLWNvbnN0cmFpbnQuDQo+ID4NCj4gPiBXaGF0IGFib3V0IHRoaXM/DQo+ID4NCj4gPiBraW5k
IHJlZ2FyZHMsDQo+ID4gVG9yc3Rlbi4NCj4gPg0KPiA+Pg0KPiA+PiBCZXN0LA0KPiA+Pg0KPiA+
PiBOYXQNCj4gPj4NCj4gPj4NCj4gPj4gT3V0bG9vayBmb3IgaU9TIOOCkuWFpeaJiw0KPiA+Pg0K
PiA+PiDlt67lh7rkuro6IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYuLm9yZzxtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZz4+IChEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxt
YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiDjga7ku6PnkIYpDQo+ID4+IOmAgeS/oeaXpeaZ
gjog5rC05puc5pelLCAxMeaciCAyOCwgMjAxOCA4OjU4IOWNiOW+jA0KPiA+PiDlrpvlhYg6IEhh
bm5lcyBUc2Nob2ZlbmlnDQo+ID4+IENjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+DQo+ID4+IOS7tuWQjTogUmU6IFtPQVVUSC1XR10gT0F1dGggU2VjdXJpdHkgVG9waWNz
IC0tIFJlY29tbWVuZCBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiBpbXBsaWNpdA0KPiA+
Pg0KPiA+PiArMQ0KPiA+Pg0KPiA+PiBXaGlsZSB0aGVyZSBhcmUgdmFyaW91cyBtZWNoYW5pc21z
IHRvIGFsbGV2aWF0ZSBzb21lIG9mIHRoZSBpc3N1ZXMgb2YgaW1wbGljaXQsIEkgZG9uJ3QgdGhp
bmsgd2UgY2FuIHJlY29tbWVuZCBzcGVjaWZpY3MsIGFuZCB0aGVyZSBtYXkgYmUgZnV0dXJlIG9u
ZXMgaW4gdGhlIGZ1dHVyZS4gSSB0aGluayB3ZSBhbGwgYWdyZWUgdGhhdCBpbXBsaWNpdCB3aXRo
b3V0IGFueSBtaXRpZ2F0aW9uIGlzIHByb2JsZW1hdGljLg0KPiA+Pg0KPiA+PiBIb3cgYWJvdXQg
d2UgcmVjb21tZW5kIGFnYWluc3QgdXNpbmcgaW1wbGljaXQgYWxvbmU/DQo+ID4+DQo+ID4+DQo+
ID4+IE9uIE1vbiwgTm92IDE5LCAyMDE4IGF0IDI6MzQgQU0gSGFubmVzIFRzY2hvZmVuaWcgPEhh
bm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+
PiB3cm90ZToNCj4gPj4gSGkgYWxsLA0KPiA+Pg0KPiA+PiBUaGUgYXV0aG9ycyBvZiB0aGUgT0F1
dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNhbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBpdCBp
cyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVseSBzZWN1cmUgdGhlIGltcGxpY2l0IGZsb3cgYWdh
aW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2UgcG90ZW50aWFsIHNvbHV0aW9ucyBsaWtlIHRva2Vu
IGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFybHkgc3RhZ2Ugb2YgYWRvcHRpb24uIEZvciB0
aGlzIHJlYXNvbiwgYW5kIHNpbmNlIENPUlMgYWxsb3dzIGJyb3dzZXItYmFzZWQgYXBwcyB0byBz
ZW5kIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwgVG9yc3RlbiBzdWdnZXN0ZWQgdG8g
dXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaW5zdGVhZCBvZiB0aGUgaW1wbGljaXQgZ3JhbnQg
aW4gY2FsbCBjYXNlcyBpbiBoaXMgcHJlc2VudGF0aW9uIChzZWUgaHR0cHM6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy1vYXV0aC1zZXNzYi1k
cmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMSkuDQo+ID4+DQo+ID4+IEEgaHVtIGlu
IHRoZSByb29tIGF0IElFVEYjMTAzIGNvbmNsdWRlZCBzdHJvbmcgc3VwcG9ydCBmb3IgaGlzIHJl
Y29tbWVuZGF0aW9ucy4gV2Ugd291bGQgbGlrZSB0byBjb25maXJtIHRoZSBkaXNjdXNzaW9uIG9u
IHRoZSBsaXN0Lg0KPiA+Pg0KPiA+PiBQbGVhc2UgcHJvdmlkZSBhIHJlc3BvbnNlIGJ5IERlY2Vt
YmVyIDNyZC4NCj4gPj4NCj4gPj4gQ2lhbw0KPiA+Pg0KPiA+PiBIYW5uZXMgJiBSaWZhYXQNCj4g
Pj4NCj4gPj4NCj4gPj4NCj4gPj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo
aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz
byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw
bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0
aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg
b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91
Lg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+ID4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCj4gPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP
QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh
cnNldD11dGYtOCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
ZGlyZWN0aW9uOmx0ciI+JiM0MzsxPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2IGNsYXNzPSJtcy1vdXRsb29rLWlvcy1zaWduYXR1cmUiPg0KPGRpdiBzdHlsZT0iZGlyZWN0
aW9uOmx0ciI+TmF0IFNha2ltdXJhIC8gbi1zYWtpbXVyYUBucmkuY28uanAgLyAmIzQzOzgxLTkw
LTYwMTMtNjI3NjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlv
bjpsdHIiPuOBk+OBruODoeODvOODq+OBq+OBr+OAgeacrOadpeOBruWum+WFiOOBruaWueOBruOB
v+OBq+mZkOWumuOBleOCjOOBn+apn+WvhuaDheWgseOBjOWQq+OBvuOCjOOBpuOBhOOCi+WgtOWQ
iOOBjOOBlOOBluOBhOOBvuOBmeOAguOBiuW/g+OBguOBn+OCiuOBruOBquOBhOWgtOWQiOOBr+OA
geiqoOOBq+eUs+OBl+ios+OBlOOBluOBhOOBvuOBm+OCk+OBjOOAgemAgeS/oeiAheOBvuOBp+OB
iuefpeOCieOBm+mgguOBjeOAgeOBvuOBn+WPl+S/oeOBleOCjOOBn+ODoeODvOODq+OBr+WJiumZ
pOOBl+OBpuOBj+OBoOOBleOBhOOBvuOBmeOCiOOBhuOBiumhmOOBhOeUs+OBl+S4iuOBkuOBvuOB
meOAgjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjpsdHIi
PlBMRUFTRSBSRUFEIDpUaGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZv
ciB0aGUgbmFtZWQgcmVjaXBpZW50IG9ubHkuPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246
bHRyIj5JZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg
dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgZS1tYWlsLg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrOyB3aWR0aDo5
OCUiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGli
cmksIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxi
PkZyb206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm
IG9mIEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPg0KPGI+U2VudDo8
L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAyOSwgMjAxOCA3OjMzOjU3IFBNPGJyPg0KPGI+VG86PC9i
PiBUb3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+Q2M6PC9iPiBEYW5pZWwgRmV0dDsgSUVURiBv
YXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBTZWN1cml0
eSBUb3BpY3MgLS0gUmVjb21tZW5kIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIGltcGxp
Y2l0PC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJh
dXRvIj4mIzQzOzE8L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYg
ZGlyPSJsdHIiPk9uIFRodSwgTm92IDI5LCAyMDE4LCAzOjA2IFBNIFRvcnN0ZW4gTG9kZGVyc3Rl
ZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBs
b2RkZXJzdGVkdC5uZXQ8L2E+IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9
ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7IGJvcmRlci1sZWZ0OjFweCAj
Y2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhpIGFsbCwgPGJyPg0KPGJyPg0KYmFzZWQg
b24geW91ciBmZWVkYmFjayBvbiB0aGUgbGlzdCBhbmQgb2ZmIGxpc3QsIERhbmllbCBhbmQgSSBw
b2xpc2hlZCB0aGUgdGV4dC4gVGhhdOKAmXMgb3VyIHByb3Bvc2FsOjxicj4NCjxicj4NCuKAlDxi
cj4NCkluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgY2xpZW50cyBNVVNUIE5PVCB1c2Ug
dGhlIGltcGxpY2l0PGJyPg0KZ3JhbnQgKHJlc3BvbnNlIHR5cGUgJnF1b3Q7dG9rZW4mcXVvdDsp
IG9yIGFueSBvdGhlciByZXNwb25zZSB0eXBlIGlzc3VpbmcgYWNjZXNzIDxicj4NCnRva2VucyBp
biB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgc3VjaCBhcyAmcXVvdDt0b2tlbiBpZF90b2tl
biZxdW90OyBhbmQgJnF1b3Q7Y29kZSB0b2tlbiBpZF90b2tlbuKAnCwNCjxicj4NCnVubGVzcyB0
aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRlci1jb25zdHJhaW5lZCBhbmQgYWNjZXNz
IHRva2VuIGluamVjdGlvbiBpbg0KPGJyPg0KdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgaXMg
cHJldmVudGVkLiA8YnI+DQrigJQ8YnI+DQo8YnI+DQpFeHBsYW50YXRpb246IDxicj4NCi0gd2Ug
d2FudGVkIHRvIGhhdmUgdGhlIHJpZ2h0IGJhbGFuY2UgYmV0d2VlbiBhIGdlbmVyaWMgZGVmaW5p
dGlvbiBvZiB0aGUgcmVzcG9uc2UgdHlwZXMgd2UgZG8gbm90IHJlY29tbWVuZC9hbGxvdyB0byBi
ZSB1c2VkIGFuZCBhIGNvbmNyZXRlL2FjdGlvbmFibGUgbGlzdCBvZiB0aGUgYWZmZWN0ZWQgcmVz
cG9uc2UgdHlwZXMuDQo8YnI+DQotIHdlIGNoYW5nZWQgZnJvbSBTSE9VTEQgTk9UIHRvIE1VU1Qg
Tk9UIGFzIHN1Z2dlc3RlZCBieSBOYXQgYW5kIHN1cHBvcnRlZCBieSBXaWxsaWFtPGJyPg0KPGJy
Pg0KV2UgbG9vayBmb3J3YXJkIHRvIHNlZWluZyB5b3VyIGZlZWRiYWNrLjxicj4NCjxicj4NCmtp
bmQgcmVnYXJkcyw8YnI+DQpUb3JzdGVuLiZuYnNwOyA8YnI+DQo8YnI+DQomZ3Q7IEFtIDI5LjEx
LjIwMTggdW0gMTU6MTUgc2NocmllYiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2
ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+dmU3anRi
QHZlN2p0Yi5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhbSBvayB3aXRoIHRo
YXQuJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBXZWQsIE5vdiAyOCwgMjAxOCwgODow
MyBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2Rk
ZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPnRvcnN0ZW5AbG9k
ZGVyc3RlZHQubmV0PC9hPiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBBbSAyOC4x
MS4yMDE4IHVtIDIzOjUwIHNjaHJpZWIgbi1zYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm4t
c2FraW11cmFAbnJpLmNvLmpwIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5uLXNh
a2ltdXJhQG5yaS5jby4uanA8L2E+Jmd0Ozo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IFRoYXQgd29ya3MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEdvb2QhPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IEkganVzdCByZWFsaXplZCB0aGlzIHRleHQgaGFzIGFuIGlzc3VlIHdpdGgg4oCedG9rZW7i
gJwgKG9ubHkpLiBJdCB3b3VsZCBhbGxvdyDigJ50b2tlbuKAnCB0byBiZSB1c2VkIGlmIHRoZSB0
b2tlbiB3b3VsZCBzZW5kZXIgY29uc3RyYWluZWQuIFRoaXMgY29tcGxldGVseSBpZ25vcmVzIHRo
ZSBmYWN0IGltcGxpY2l0IGFsc28gc2hhbGwgYmUgYWJhbmRvbmVkIGJlY2F1c2Ugb2YgaXRzIHZ1
bG5lcmFiaWxpdHkgZm9yIGFjY2VzcyB0b2tlbiBpbmplY3Rpb24uDQo8YnI+DQomZ3Q7IDxicj4N
CiZndDsgSSB0aGVyZWZvcmUgcHJvcG9zZSBhIG1vZGlmaWVkIHRleHQ6IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyZuYnNwOyAmbmJzcDsgSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBDbGll
bnRzIFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGdy
YW50LiBGdXJ0aGVybW9yZSwgY2xpZW50cyBTSE9VTEQgb25seSB1c2Ugb3RoZXIgcmVzcG9uc2Ug
dHlwZXMgY2F1c2luZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG88YnI+DQomZ3Q7Jm5ic3A7
ICZuYnNwOyBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9u
c2UsIGlmIHRoZSBwYXJ0aWN1bGFyIHJlc3BvbnNlIHR5cGUgZGV0ZWN0cyBhY2Nlc3MgdG9rZW4N
Cjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGluamVjdGlvbiBhbmQgdGhlIGlzc3VlZCBhY2Nlc3Mg
dG9rZW5zIGFyZSBzZW5kZXItY29uc3RyYWluZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9yIHdl
IGp1c3Qgc3RhdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO0luIG9yZGVyIHRv
IGF2b2lkIHRoZXNlIGlzc3VlcywgQ2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgcmVzcG9uc2Ug
dHlwZSDigJ50b2tlbiZxdW90Oy4gVGhlIHJlc3BvbnNlIHR5cGVzPGJyPg0KJmd0OyDigJ50b2tl
biBpZF90b2tlbuKAnCBhbmQg4oCeY29kZSB0b2tlbiBpZF90b2tlbuKAnCBTT1VMRCBOT1QgYmUg
dXNlZCwgaWYgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW5zIGFyZSBub3QNCjxicj4NCiZndDsgc2Vu
ZGVyLWNvbnN0cmFpbmVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyBJbiBmYWN0LCBJIHdvdWxkIGZ1cnRoZXIgZ28gYW5kIHNheSBNVVNUIE5PVCBidXQgdGhhdCBw
cm9iYWJseSBpcyB0b28gbXVjaCBmb3IgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9uLjxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTWlrZSBzdWdnZXN0ZWQgdG8gZ28gd2l0aCBh
IFNIT1VMRCBOT1QgdG8gZ2V0IHRoZSBtZXNzYWdlIG91dCBidXQgZ2l2ZSBpbXBsZW1lbnRvcnMg
dGltZSB0byBtb3ZlL2NoYW5nZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBCZXN0LDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTmF0PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyBOYXQgU2FraW11cmEgLyA8YSBocmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAi
IHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPg0Kbi1zYWtpbXVyYUBucmkuY28uanA8
L2E+IC8gJiM0Mzs4MS05MC02MDEzLTYyNzY8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IOOBk+OBruODoeODvOODq+OBq+OBr+OAgeacrOadpeOBruWum+WFiOOBruaWueOBruOBv+OBq+mZ
kOWumuOBleOCjOOBn+apn+WvhuaDheWgseOBjOWQq+OBvuOCjOOBpuOBhOOCi+WgtOWQiOOBjOOB
lOOBluOBhOOBvuOBmeOAguOBiuW/g+OBguOBn+OCiuOBruOBquOBhOWgtOWQiOOBr+OAgeiqoOOB
q+eUs+OBl+ios+OBlOOBluOBhOOBvuOBm+OCk+OBjOOAgemAgeS/oeiAheOBvuOBp+OBiuefpeOC
ieOBm+mgguOBjeOAgeOBvuOBn+WPl+S/oeOBleOCjOOBn+ODoeODvOODq+OBr+WJiumZpOOBl+OB
puOBj+OBoOOBleOBhOOBvuOBmeOCiOOBhuOBiumhmOOBhOeUs+OBl+S4iuOBkuOBvuOBmeOAgjxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUExFQVNFIFJFQUQgOlRoaXMgZS1tYWlsIGlz
IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGllbnQgb25seS48
YnI+DQomZ3Q7ICZndDsgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGUtbWFpbC48YnI+DQomZ3Q7ICZn
dDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IOW3ruWHuuS6ujogVG9yc3RlbiBMb2RkZXJzdGVkdCAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFu
ayIgcmVsPSJub3JlZmVycmVyIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7IOmAgeS/oeaXpeaZgjog5rC05puc5pelLCAxMeaciCAyOCwgMjAxOCAxMTozOCDl
jYjlvow8YnI+DQomZ3Q7ICZndDsg5a6b5YWIOiBuLXNha2ltdXJhPGJyPg0KJmd0OyAmZ3Q7IENj
OiBEaWNrIEhhcmR0OyBIYW5uZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj4NCm9hdXRoQGlldGYub3Jn
PC9hPjxicj4NCiZndDsgJmd0OyDku7blkI06IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3VyaXR5
IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1wbGlj
aXQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIE5hdCwgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQW0gMjguMTEuMjAxOCB1bSAyMToxMCBzY2hyaWVi
IG4tc2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIgdGFy
Z2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+bi1zYWtpbXVyYUBucmkuY28uanA8L2E+Jmd0
Ozo8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSSB3b3VsZCBzdXBwb3J0
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDEpIGNsZWFybHkgZGVmaW5p
bmcgSW1wbGljaXQgYXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIGFjY2VzcyB0b2tlbiBmcm9tIHRo
ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50ICggc29tZSBwZW9wbGUgY29uZnVzZXMgaW1wbGljaXQg
YXMgdGhlIGZsb3cgdGhhdCByZXR1cm5zIElEIFRva2VuIGluIHRoZSBmcm9udCBjaGFubmVsKTxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhhdOKAmXMgdGhlIGN1cnJlbnQgdGV4dDog
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBp
c3N1ZXMsIENsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KJmd0OyAmZ3Q7
Jm5ic3A7ICZuYnNwOyBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgaXNz
dWUgYW4gYWNjZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLjxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2hhdCB3b3VsZCB5b3UgbGlrZSB0byBtb2RpZnk/IDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgMikg
QmFubmluZyB0aGUgcmV0dXJuaW5nIG9mIHRoZSBhY2Nlc3MgdG9rZW4gdGhhdCBhcmUgbm90IHNl
bmRlciBjb25zdHJhaW5lZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50PGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIENs
aWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu
YnNwOyBncmFudCBvciBhbnkgb3RoZXIgcmVzcG9uc2UgdHlwZSBjYXVzaW5nIHRoZSBhdXRob3Jp
emF0aW9uIHNlcnZlciB0bzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgaXNzdWUgYW4gYWNj
ZXNzIHRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCBpZiB0aGlzIGFjY2VzcyB0
b2tlbnMgaXMgbm90IHNlbmRlci1jb25zdHJhaW50Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgV2hhdCBhYm91dCB0aGlzPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsga2lu
ZCByZWdhcmRzLDxicj4NCiZndDsgJmd0OyBUb3JzdGVuLjxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQmVzdCw8YnI+DQomZ3Q7ICZndDsmZ3Q7
IDxicj4NCiZndDsgJmd0OyZndDsgTmF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn
dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgT3V0bG9vayBmb3IgaU9TIOOCkuWFpeaJizxicj4N
CiZndDsgJmd0OyZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyDlt67lh7rkuro6IE9BdXRo
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiIHJlbD0ibm9yZWZlcnJlciI+b2F1dGgtYm91bmNlc0BpZXRmLi5vcmc8L2E+Jmd0OyAoRGlj
ayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9
Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IOOB
ruS7o+eQhik8YnI+DQomZ3Q7ICZndDsmZ3Q7IOmAgeS/oeaXpeaZgjog5rC05puc5pelLCAxMeac
iCAyOCwgMjAxOCA4OjU4IOWNiOW+jDxicj4NCiZndDsgJmd0OyZndDsg5a6b5YWIOiBIYW5uZXMg
VHNjaG9mZW5pZzxicj4NCiZndDsgJmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+b2F1dGhAaWV0Zi5vcmc8
L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyDku7blkI06IFJlOiBbT0FVVEgtV0ddIE9BdXRoIFNlY3Vy
aXR5IFRvcGljcyAtLSBSZWNvbW1lbmQgYXV0aG9yaXphdGlvbiBjb2RlIGluc3RlYWQgb2YgaW1w
bGljaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZndDsgJiM0Mzsx
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFdoaWxlIHRoZXJlIGFyZSB2
YXJpb3VzIG1lY2hhbmlzbXMgdG8gYWxsZXZpYXRlIHNvbWUgb2YgdGhlIGlzc3VlcyBvZiBpbXBs
aWNpdCwgSSBkb24ndCB0aGluayB3ZSBjYW4gcmVjb21tZW5kIHNwZWNpZmljcywgYW5kIHRoZXJl
IG1heSBiZSBmdXR1cmUgb25lcyBpbiB0aGUgZnV0dXJlLiBJIHRoaW5rIHdlIGFsbCBhZ3JlZSB0
aGF0IGltcGxpY2l0IHdpdGhvdXQgYW55IG1pdGlnYXRpb24gaXMgcHJvYmxlbWF0aWMuDQo8YnI+
DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSG93IGFib3V0IHdlIHJlY29tbWVu
ZCBhZ2FpbnN0IHVzaW5nIGltcGxpY2l0IGFsb25lPyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4N
CiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPbiBNb24sIE5vdiAxOSwgMjAxOCBh
dCAyOjM0IEFNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRz
Y2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+SGFubmVz
LlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsgSGkg
YWxsLDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGUgYXV0aG9ycyBv
ZiB0aGUgT0F1dGggU2VjdXJpdHkgVG9waWNzIGRyYWZ0IGNhbWUgdG8gdGhlIGNvbmNsdXNpb24g
dGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gYWRlcXVhdGVseSBzZWN1cmUgdGhlIGltcGxpY2l0
IGZsb3cgYWdhaW5zdCB0b2tlbiBpbmplY3Rpb24gc2luY2UgcG90ZW50aWFsIHNvbHV0aW9ucyBs
aWtlIHRva2VuIGJpbmRpbmcgb3IgSkFSTSBhcmUgaW4gYW4gZWFybHkgc3RhZ2Ugb2YgYWRvcHRp
b24uIEZvciB0aGlzDQogcmVhc29uLCBhbmQgc2luY2UgQ09SUyBhbGxvd3MgYnJvd3Nlci1iYXNl
ZCBhcHBzIHRvIHNlbmQgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LCBUb3JzdGVuIHN1
Z2dlc3RlZCB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbnN0ZWFkIG9mIHRoZSBpbXBs
aWNpdCBncmFudCBpbiBjYWxsIGNhc2VzIGluIGhpcyBwcmVzZW50YXRpb24gKHNlZQ0KPGEgaHJl
Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xp
ZGVzLTEwMy1vYXV0aC1zZXNzYi1kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wMSIg
cmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvbWF0ZXJpYWxzL3NsaWRlcy0xMDMtb2F1dGgt
c2Vzc2ItZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDE8L2E+KS48YnI+DQomZ3Q7
ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQSBodW0gaW4gdGhlIHJvb20gYXQgSUVURiMx
MDMgY29uY2x1ZGVkIHN0cm9uZyBzdXBwb3J0IGZvciBoaXMgcmVjb21tZW5kYXRpb25zLiBXZSB3
b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuPGJyPg0KJmd0
OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFBsZWFzZSBwcm92aWRlIGEgcmVzcG9uc2Ug
YnkgRGVjZW1iZXIgM3JkLjxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBD
aWFvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IEhhbm5lcyAmYW1wOyBS
aWZhYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmbmJzcDsgPGJyPg0K
Jmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj
b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh
bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk
IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu
b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig
YW55DQogcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l
ZGl1bS4gVGhhbmsgeW91Ljxicj4NCiZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7IE9BdXRoIG1haWxp
bmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+
DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZn
dDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQomZ3Q7ICZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZn
dDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJu
b3JlZmVycmVyIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZl
cnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRo
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5PQXV0aEBpZXRmLm9y
ZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0
YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9
Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_OSBPR01MB28696549CFF704BFDEA6A6EFF9D20OSBPR01MB2869jpnp_--


From nobody Thu Nov 29 10:49:28 2018
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 50C2E130E61 for ; Thu, 29 Nov 2018 10:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.959
X-Spam-Level: 
X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 67RKxmbwNlFW for ; Thu, 29 Nov 2018 10:49:22 -0800 (PST)
Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0: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 A0FF0130E5C for ; Thu, 29 Nov 2018 10:49:22 -0800 (PST)
Received: by mail-it1-x12b.google.com with SMTP id a6so5319859itl.4 for ; Thu, 29 Nov 2018 10:49:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/cbLD3MXRBWn4GA3Q3py+9EIvL0NRKSs+rxcNC6K7M=; b=JoOLebtShNVx+vG9wsd750DEMjGqBJXjcgmjtol/hLqNGz+1XE7oj7psKQdvP5KlmG n6knos7QfvoAboSLUWvx9jfC2c8iwo1y39nfsg23bqjTwfOyVeec1yGwZx5A+mS32/x0 ZrslqrXA3YDOE2yVxC2PmUYDrVCkmRKxM/FEI8ZW/G8nplO2z4Q2L0OQre80+hs1Nvai cI/wOPzWi9LZy0YhMMcjRGLZxeRBCZQUgIvRU0sreKiEwuPHtlQIClWWmys9VvgbBs6Z w5vh9WvMNH93baAfHt36QDE/1WvnIyh1NrxkrBlTktGNKXOp2fVUGRP8bVH9E4pU2RU9 f91w==
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=B/cbLD3MXRBWn4GA3Q3py+9EIvL0NRKSs+rxcNC6K7M=; b=UhimL9Qrb1vFpte03EFJcN/U2l2A/8lH/ibftbbxJQJWrWVjBGR5Jyq/cVlbNs0Nuh PVBtc2ywKJvUAP2MQkf/Pmqb8IZ8sTEmpZOmczmBjboTpME3EZCHR4SwngN/U6/eA4I5 Xvd1c9YAt+KYSqOZ4FDaEp/XLnWqPurmuw0d4rR1Vp8/NgJzgsivvnqkFmLmKsBi90MQ fze8IivcghWx25cupZvgCC9AG8uIMA5xGi1tuHIUkyPUfMoGsa3O8utROfCbk6aODBru sonfUSuZzKz2E1X8vMbOUXCi4KC6UT1/8ILi9tD6pzSYD7dwij/V3KXcOhyYS3ALOFy5 52zg==
X-Gm-Message-State: AA+aEWbkCTxMRGCuZJ44Bq7OLFJmGRrHYGlNZpD0ybh01PrxVpn2qQEI R3o3aJT1SOoTwj+tzDCrOscYWGLa0f5vyKWSpoK6yIxzoRyopQ==
X-Google-Smtp-Source: AFSGD/XBd8mgsr7amynqSpSCnR4allYuNU5+annMAAeVelpA5VxK0ZUv/pHH2ysIAeaJCwsrOEJ/ccWh5iRY/z7eSco=
X-Received: by 2002:a24:97c3:: with SMTP id k186mr2755430ite.125.1543517361504;  Thu, 29 Nov 2018 10:49:21 -0800 (PST)
MIME-Version: 1.0
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>     <065bba73-eade-2f07-038f-8afa708e38be@rub.de>
In-Reply-To: <065bba73-eade-2f07-038f-8afa708e38be@rub.de>
From: William Denniss 
Date: Thu, 29 Nov 2018 10:49:09 -0800
Message-ID: 
To: Christian Mainka 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000000a07d8057bd224e5"
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 29 Nov 2018 18:49:27 -0000

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

On Thu, Nov 29, 2018 at 6:03 AM Christian Mainka  wrote:

> Hi,
>
> thanks for pointing this out!
> This was exactly what confused us during reading *-* the main threat we
> see and which is not addressed is related to the app impersonation attack=
.
> Even PKCE does not help against the app impersonation attack.
>

Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide some
identity guarantees (security considerations in Sec 8.6), as the OS will
only open apps that can verify domain ownership to process the redirect.
This is what I would recommend as a starting point if you want assurances
over the app's identity.

A spoofing app can still use a web-view to intercept the response that way,
but in that case they'd also have full access to the session cookie (due to
the use of webview for the sign-in), which is potentially a more valuable
token (i.e. you have bigger issues). It does effectively prevent against
tokens issued form the browser SSO session being intercepted by the wrong
app.



>
> So a "Native App + Dynamic Client Registration" can be seen at a differen=
t
> "confidentiality level" than a "public client", because every native App
> can dynamically register itself on the IdP.
> The IdP cannot distinguish, for example, an honest native client from an
> malicious client starting an app impersonation attack.
>
> We agree that, e.g., a leaked code cannot be redeemed unless you have the
> respective client_id/client_secret.
>
> But... we asked ourselfs, in which cases does a code leak?
>
> 1) In the front-channel. In this case, it is true that no client
> credentials leak and an attacker cannot redeem the code.
>
> 2) In the back-channel. But if this channel is insecure, you directly get
> client credentials (unless client_secret_jwt is used as pointed out by
> George).
>
> So, Dynamic Client Registration only helps if the code leaks alone (as in
> 1.), or if it leaks on different levels (e.g. logfiles).
>
> On the opposite site, if Dynamic Registration is available, an attacker
> can very easily do an app impersonation attack by registering on the IdP.
> To be clear, it is not "impersonation" as in the "one secret per software=
"
> scenario, because different client_id and client_secret is used, but to t=
he
> best of my knowledge, the IdP cannot distinguish between an honest app an=
d
> an app impersonation client that has simply registered.
>
> In addition, if the IdP supports the dynamic client registration:
> How can the IdP distinguish between confidential and public/native client=
s?
> With respect to the consent page, which must be shown every time for
> native apps, this is an important issue, which should be addressed proper=
ly.
>
> Best Regards
> Vladi/Christian
>
> Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle:
>
> It should be noted that =E2=80=9Ctraditional=E2=80=9D confidential client=
s with registered return URLs and server-side secrets may provide a higher =
degree of confidence in the true identity of the client that doesn=E2=80=99=
t carry over to confidential native app clients. A native app instance=E2=
=80=99s registration call is necessarily unauthenticated (for the same reas=
ons that statically registered native app clients are public clients), so t=
he Client Impersonation concerns described in section 8.6 of RFC8252  still apply.
> --
> Annabelle Richard Backman
> AWS Identity
>
>
> From: OAuth   on behalf o=
f Filip Skokan  
> Date: Wednesday, November 28, 2018 at 9:11 AM
> To: George Fletcher  
> Cc: oauth  
> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>
> Apologies, I missed the issued in "issued a shared secret", just reading =
"shared secret" alone is the exact opposite of a per-instance secret. The r=
est is clear and as you say it brings the benefit of the secret never being=
 sent over the wire (except during the initial registration via TLS).
>
> Best,
> Filip
>
>
> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher  > wrote:
> It's "confidential" in that the shared secret is unique to that app insta=
nce registration (as Dennis described in his response). If an attacker gets=
 my phone and compromises the data stored on my device, they only get the s=
ecret for my device. This is no different than a server side client having =
their client secret compromised through an attack (and in some ways is bett=
er because it's instance specific).
>
> The main point I was trying to make, is that the 'client_secret_jwt' meth=
od allows the client to never send the shared secret across the wire as is =
created in the default OAuth2 HTTP Basic Authentication method.
>
> Thanks,
> George
> On 11/28/18 11:03 AM, Filip Skokan wrote:
> Hi George,
>
> #2 doesn't seem confidential, it's still a secret shared amongst installa=
tions and anyone reverse engineering the apk, extracting the secret, can fo=
rm the client_secret_jwt client_assertion with it just fine.
>
> Best,
> Filip
>
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher  <40aol.com@dmarc.ietf.org>> wr=
ote:
> In addition, a few additional patterns are enabled...
>
> 1. The native app can generate a public/private key pair and then use pri=
vate_secret_jwt as the client credential validation method via the client c=
redentials flow (defined in OpenID Connect).
>
> 2. Maybe more simply, if the native app is issued a shared secret, the ap=
p can use client_secret_jwt method for client authentication which ensures =
the shared secret never leaves the device. (Again defined in the OpenID Con=
nect spec).
>
> 3. Once the native app instance has credentials, they can be used for add=
itional securing of app API transactions in addition to just the OAuth2/Ope=
nID Connect flows.
>
> Thanks,
> George
> On 11/27/18 3:28 PM, William Denniss wrote:
> If the secret is dynamically provisioned then you have a confidential cli=
ent. Anyone reverse engineering their own installation of the native app wo=
uld only extract their own client's credentials, as opposed to the shared s=
ecret of all installations. Having a confidential client means that request=
s to the token endpoint (code, refresh) are client authenticated, so PKCE w=
ouldn't be needed.
>
> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka  > wrote:
> Hi,
>
> we just stumbled upon this [1] statement:
> "Except when using a mechanism like Dynamic Client Registration
>    [RFC7591] to provision per-instance secrets, native apps are
>    classified as public clients ..."
>
> What does this mean for us? Native App + Dynamic Client Registration =3D
> Confidential Client?
> Which threats are covered if Dynamic Client Registration is used on
> Native Apps?
>
> Best Regards,
> Vladi/Christian
>
> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>
> --
> Dr.-Ing. Christian Mainka
> Horst G=C3=B6rtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universit=C3=A4tsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.org h=
ttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.org h=
ttps://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
>
> --
> Dr.-Ing. Christian Mainka
> Horst G=C3=B6rtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universit=C3=A4tsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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




    
 =20
   =20
 =20
  
    
    
     Hi,
    
      
    
      thanks for pointing this out!
    
      This was exactly what confused us during reading - the
      main threat we see and which is not addressed is related to the
      app impersonation attack.
    
      Even PKCE does not help against the app impersonation attack.

    Claimed "https" scheme U=
RIs (RFC 8252, Sec 7.2) can be used to provide some identity guarantees (se=
curity considerations in Sec 8.6), as the OS will only open apps that can v=
erify domain ownership to process the redirect. This is what I would recomm=
end as a starting point if you want assurances over the app's identity.=


    A spoofing app can still use a web-view to interc=
ept the response that way, but in that case they'd also have full acces=
s to the session cookie (due to the use of webview for the sign-in), which =
is potentially a more valuable token (i.e. you have bigger issues). It does=
 effectively prevent against tokens issued form the browser SSO session bei=
ng intercepted by the wrong app.

    =C2=A0
    <=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
    <=
div class=3D"gmail-m_5849561394811738800moz-text-html" lang=3D"x-unicode">
      
    
      So a "Native App + Dynamic Client Registration" can be seen=
 at a
      different "confidentiality level" than a "public clien=
t", because
      every native App can dynamically register itself on the IdP.
    
      The IdP cannot distinguish, for example, an honest native client
      from an malicious client starting an app impersonation attack.
    
      
    
      We agree that, e.g., a leaked code cannot be redeemed unless you
      have the respective client_id/client_secret.
    
      
    
      But... we asked ourselfs, in which cases does a code leak?
    
      
    
      1) In the front-channel. In this case, it is true that no client
      credentials leak and an attacker cannot redeem the code.
    
      
    
      2) In the back-channel. But if this channel is insecure, you
      directly get client credentials (unless client_secret_jwt is used
      as pointed out by George).
    
      
    
      So, Dynamic Client Registration only helps if the code leaks alone
      (as in 1.), or if it leaks on different levels (e.g. logfiles).
    
      
    
      On the opposite site, if Dynamic Registration is available, an
      attacker can very easily do an app impersonation attack by
      registering on the IdP. To be clear, it is not "impersonation&qu=
ot; as
      in the "one secret per software" scenario, because differen=
t
      client_id and client_secret is used, but to the best of my
      knowledge, the IdP cannot distinguish between an honest app and an
      app impersonation client that has simply registered.
    
      
    
      In addition, if the IdP supports the dynamic client registration:
    
    How can the IdP
      distinguish between confidential and public/native clients?
    
      With respect to the consent page, which must be shown every time
      for native apps, this is an important issue, which should be
      addressed properly.
    
      
    
      Best Regards
    
      Vladi/Christian 
    
    
    
    

    
    
    
    
    Am 29.11.18 u=
m 00:38 schrieb Richard
      Backman, Annabelle:
    
    
    
    
    
      
    It should be =
noted that =E2=80=9Ctraditional=E2=80=9D confidential clients with register=
ed return URLs and server-side secrets may provide a higher degree of confi=
dence in the true identity of the client that doesn=E2=80=99t carry over to=
 confidential native app clients. A native app instance=E2=80=99s registrat=
ion call is necessarily unauthenticated (for the same reasons that statical=
ly registered native app clients are public clients), so the Client Imperso=
nation concerns described in section 8.6 of RFC8252<https://tools.ietf.org/html/rfc82=
52#section-8.6> still apply.
--
Annabelle Richard Backman
AWS Identity


From: OAuth <oauth-bounces@i=
etf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Wednesday, November 28, 2018 at 9:11 AM
To: George Fletcher <gffletch@aol.=
com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Apologies, I missed the issued in "issued a shared secret", just =
reading "shared secret" alone is the exact opposite of a per-inst=
ance secret. The rest is clear and as you say it brings the benefit of the =
secret never being sent over the wire (except during the initial registrati=
on via TLS).

Best,
Filip


On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffletch@aol.com<mailto:gffletch@aol.com>> wrote:
It's "confidential" in that the shared secret is unique to th=
at app instance registration (as Dennis described in his response). If an a=
ttacker gets my phone and compromises the data stored on my device, they on=
ly get the secret for my device. This is no different than a server side cl=
ient having their client secret compromised through an attack (and in some =
ways is better because it's instance specific).

The main point I was trying to make, is that the 'client_secret_jwt'=
; method allows the client to never send the shared secret across the wire =
as is created in the default OAuth2 HTTP Basic Authentication method.

Thanks,
George
On 11/28/18 11:03 AM, Filip Skokan wrote:
Hi George,

#2 doesn't seem confidential, it's still a secret shared amongst in=
stallations and anyone reverse engineering the apk, extracting the secret, =
can form the client_secret_jwt client_assertion with it just fine.

Best,
Filip

On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org<mailto:40aol.com@dmarc.i=
etf.org>> wrote:
In addition, a few additional patterns are enabled...

1. The native app can generate a public/private key pair and then use priva=
te_secret_jwt as the client credential validation method via the client cre=
dentials flow (defined in OpenID Connect).

2. Maybe more simply, if the native app is issued a shared secret, the app =
can use client_secret_jwt method for client authentication which ensures th=
e shared secret never leaves the device. (Again defined in the OpenID Conne=
ct spec).

3. Once the native app instance has credentials, they can be used for addit=
ional securing of app API transactions in addition to just the OAuth2/OpenI=
D Connect flows.

Thanks,
George
On 11/27/18 3:28 PM, William Denniss wrote:
If the secret is dynamically provisioned then you have a confidential clien=
t. Anyone reverse engineering their own installation of the native app woul=
d only extract their own client's credentials, as opposed to the shared=
 secret of all installations. Having a confidential client means that reque=
sts to the token endpoint (code, refresh) are client authenticated, so PKCE=
 wouldn't be needed.

On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.Mainka=3D40rub.de@=
dmarc.ietf..org<mailto:Christian.Mainka=3D40rub.de@dmarc.ietf.org>> w=
rote:
Hi,

we just stumbled upon this [1] statement:
"Except when using a mechanism like Dynamic Client Registration
   [RFC7591] to provision per-instance secrets, native apps are
   classified as public clients ..."

What does this mean for us? Native App + Dynamic Client Registration =3D
Confidential Client?
Which threats are covered if Dynamic Client Registration is used on
Native Apps?

Best Regards,
Vladi/Christian

[1]: https://=
tools.ietf.org/html/rfc8252#section-8.4

--
Dr.-Ing. Christian Mainka
Horst G=C3=B6rtz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum, Germany

Universit=C3=A4tsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/cha=
ir/people/cmainka/
@CheariX


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




_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

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

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

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


    
      
    
      
    <=
/fieldset>
      
    _____________=
__________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth

    
    
    
    
    --=
=20
Dr.-Ing. Christian Mainka
Horst G=C3=B6rtz Institute for IT-Security=20
Chair for Network and Data Security=20
Ruhr-University Bochum, Germany

Universit=C3=A4tsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/cha=
ir/people/cmainka/
@CheariX
    
  
    

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

    

--0000000000000a07d8057bd224e5--


From nobody Thu Nov 29 10:49:47 2018
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 E953F130E96 for ; Thu, 29 Nov 2018 10:49:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.959
X-Spam-Level: 
X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 zuxVelqFiRD3 for ; Thu, 29 Nov 2018 10:49:42 -0800 (PST)
Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7484130E74 for ; Thu, 29 Nov 2018 10:49:41 -0800 (PST)
Received: by mail-it1-x12f.google.com with SMTP id i145so4373674ita.4 for ; Thu, 29 Nov 2018 10:49:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ouu4u2TEGOUSrJ2CODNv7pSBV/cM8ZO2XwFRqTk13u8=; b=e+wvinE4eWPZ0pcbYWy8px/O+hNmcoJitgKBtHsqSjWjV3X4Og7vQO5zrHRXeFcGCV OBCwb58AfvOEAN2hscYZRLPvg12EtpbO0dnZzGMXgaMRR+j8sjpFb8VtjSzJAzpO/ZPj vhWAJwRxFtMvCpsS/MBf/uciYmG7jKAtaHp2SAGMQdF67xfSm6I5gfjMQb7GAkdkSsHs rFfcXPUzDboOGzyK3TCzYIzXLEiWEGbA2aqS57kOzHFWldcPvMAea3KUiYw2bySw/eBQ 5OseqgG1zuStdev6gikCjZ+iIJ+dH/tT/H8u/S+D6Vys327eP+IQBI0XOFKFniSD4xOr K6jQ==
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=ouu4u2TEGOUSrJ2CODNv7pSBV/cM8ZO2XwFRqTk13u8=; b=l6c2c8v0F1QliQhDG6hrGcUSP+ZP/K7VyZox3DJeiyhX2irJmFmRPV06wfpvDuMzxu pfEQTuZJ/jGAPb/LdKq8qziS0HVsW74ENaff8jGGAnpLOCjkA2Y8omDpgG07FHsEXota G5QsHMDr4KjO49ZsPjDd15ZudTvo9fb82uiwG+ih3h8HvTSTfwMhTJAkQ9FMF9la5nMu o64hf9nJ4Lp1XV1DqoW6S7HhwxuR8zRQi535Mz1kKBsiMpnKjbFjp3wrGwkRADKma77H 4qsTY/NJBHfLRPxLVzjvaNR1VSHqkr1wkMbpDI22gTX9rPH26wLS82ujBgbLw3mKJdSb 7M7A==
X-Gm-Message-State: AA+aEWZB+vheJwTrsTTBgPpoYli87Bt5DfjdS8BQ1/HPGc5K5f9nA2+W oGfejPPdflKTPigzJopAaIDiQdKJogfdzbUe+XDYpSr2spQ=
X-Google-Smtp-Source: AFSGD/V/qmIbQNCKDcrnrbnyCR4mYN+/WCNjgQVzyVy59OmIvKtRfM0DAjOtYZNgSz82XR43IVDsV0Gs7GifwPfG1ak=
X-Received: by 2002:a24:97c3:: with SMTP id k186mr2756409ite.125.1543517380553;  Thu, 29 Nov 2018 10:49:40 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>      
In-Reply-To: 
From: William Denniss 
Date: Thu, 29 Nov 2018 10:49:27 -0800
Message-ID: 
To: Nat Sakimura 
Cc: John Bradley , Torsten Lodderstedt , fett@danielfett.de,  oauth 
Content-Type: multipart/alternative; boundary="0000000000002c79a5057bd2258e"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 29 Nov 2018 18:49:45 -0000

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

+1

On Thu, Nov 29, 2018 at 10:43 AM n-sakimura  wrote:

> +1
>
> Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>
>
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>
> PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> If you are not an intended recipient, please notify the sender and delete
> this e-mail.
> ------------------------------
> *From:* OAuth  on behalf of John Bradley <
> ve7jtb@ve7jtb.com>
> *Sent:* Thursday, November 29, 2018 7:33:57 PM
> *To:* Torsten Lodderstedt
> *Cc:* Daniel Fett; IETF oauth WG
> *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
>
> +1
>
> On Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt  wrote:
>
>> Hi all,
>>
>> based on your feedback on the list and off list, Daniel and I polished
>> the text. That=E2=80=99s our proposal:
>>
>> =E2=80=94
>> In order to avoid these issues, clients MUST NOT use the implicit
>> grant (response type "token") or any other response type issuing access
>> tokens in the authorization response, such as "token id_token" and "code
>> token id_token=E2=80=9C,
>> unless the issued access tokens are sender-constrained and access token
>> injection in
>> the authorization response is prevented.
>> =E2=80=94
>>
>> Explantation:
>> - we wanted to have the right balance between a generic definition of th=
e
>> response types we do not recommend/allow to be used and a
>> concrete/actionable list of the affected response types.
>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and
>> supported by William
>>
>> We look forward to seeing your feedback.
>>
>> kind regards,
>> Torsten.
>>
>> > Am 29.11.2018 um 15:15 schrieb John Bradley :
>> >
>> > I am ok with that.
>> >
>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
>> torsten@lodderstedt.net wrote:
>> >
>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura > >:
>> > >
>> > > That works.
>> >
>> > Good!
>> >
>> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would
>> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender const=
rained. This
>> completely ignores the fact implicit also shall be abandoned because of =
its
>> vulnerability for access token injection.
>> >
>> > I therefore propose a modified text:
>> >
>> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
>> >    grant. Furthermore, clients SHOULD only use other response types
>> causing the authorization server to
>> >    issue an access token in the authorization response, if the
>> particular response type detects access token
>> >    injection and the issued access tokens are sender-constrained.
>> >
>> > Or we just state:
>> >
>> >   In order to avoid these issues, Clients SHOULD NOT use the response
>> type =E2=80=9Etoken". The response types
>> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the
>> issued access tokens are not
>> > sender-constrained.
>> >
>> > >
>> > > In fact, I would further go and say MUST NOT but that probably is to=
o
>> much for a security consideration.
>> > >
>> >
>> > Mike suggested to go with a SHOULD NOT to get the message out but give
>> implementors time to move/change.
>> >
>> > > Best,
>> > >
>> > > Nat
>> > >
>> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>> > >
>> > >
>> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>> > >
>> > > PLEASE READ :This e-mail is confidential and intended for the named
>> recipient only.
>> > > If you are not an intended recipient, please notify the sender and
>> delete this e-mail.
>> > >
>> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
>> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
>> > > =E5=AE=9B=E5=85=88: n-sakimura
>> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
>> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization
>> code instead of implicit
>> > >
>> > > Hi Nat,
>> > >
>> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>> > >>
>> > >> I would support
>> > >>
>> > >> 1) clearly defining Implicit as the flow that returns access token
>> from the authorization endpoint ( some people confuses implicit as the f=
low
>> that returns ID Token in the front channel)
>> > >
>> > > That=E2=80=99s the current text:
>> > >
>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>> > >    grant or any other response type causing the authorization server
>> to
>> > >    issue an access token in the authorization response.
>> > >
>> > > What would you like to modify?
>> > >
>> > >>
>> > >> 2) Banning the returning of the access token that are not sender
>> constrained from the authorization endpoint
>> > >
>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>> > >    grant or any other response type causing the authorization server
>> to
>> > >    issue an access token in the authorization response, if this
>> access tokens is not sender-constraint.
>> > >
>> > > What about this?
>> > >
>> > > kind regards,
>> > > Torsten.
>> > >
>> > >>
>> > >> Best,
>> > >>
>> > >> Nat
>> > >>
>> > >>
>> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>> > >>
>> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth > (Dick
>> Hardt  =E3=81=AE=E4=BB=A3=E7=90=86)
>> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>> > >> Cc: oauth@ietf.org
>> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomme=
nd authorization
>> code instead of implicit
>> > >>
>> > >> +1
>> > >>
>> > >> While there are various mechanisms to alleviate some of the issues
>> of implicit, I don't think we can recommend specifics, and there may be
>> future ones in the future. I think we all agree that implicit without an=
y
>> mitigation is problematic.
>> > >>
>> > >> How about we recommend against using implicit alone?
>> > >>
>> > >>
>> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
>> Hannes.Tschofenig@arm.com> wrote:
>> > >> Hi all,
>> > >>
>> > >> The authors of the OAuth Security Topics draft came to the
>> conclusion that it is not possible to adequately secure the implicit flo=
w
>> against token injection since potential solutions like token binding or
>> JARM are in an early stage of adoption. For this reason, and since CORS
>> allows browser-based apps to send requests to the token endpoint, Torste=
n
>> suggested to use the authorization code instead of the implicit grant in
>> call cases in his presentation (see
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sess=
b-draft-ietf-oauth-security-topics-01
>> ).
>> > >>
>> > >> A hum in the room at IETF#103 concluded strong support for his
>> recommendations. We would like to confirm the discussion on the list.
>> > >>
>> > >> Please provide a response by December 3rd.
>> > >>
>> > >> Ciao
>> > >>
>> > >> Hannes & Rifaat
>> > >>
>> > >>
>> > >>
>> > >> IMPORTANT NOTICE: The contents of this email and any attachments ar=
e
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy t=
he
>> information in any medium. Thank you.
>> > >> _______________________________________________
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>> > >> _______________________________________________
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>> > >
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> 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
>

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


    +1

    On Thu, Nov 29, 2018 at 10:43 AM n-sakimura <n-sakimura@nri.co.jp> wrote:
    





    

    

    

    +1
    

    


    

    

    

    Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276


    

    

    =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=
=E3=81=AB=E3=81=AF=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=
=81=AE=E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=
=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=
=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=
=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=
=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=
=E8=AA=A0=E3=81=AB=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=
=BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=
=E3=81=BE=E3=81=9F=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=
=83=BC=E3=83=AB=E3=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=
=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=
=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82


    

    

    PLEASE READ :This e-mail is confidential and i=
ntended for the named recipient only.
    

    If you are not an intended recipient, please n=
otify the sender and delete this e-mail.

    

    

    

    

    From: =
OAuth <oauth=
-bounces@ietf.org> on behalf of John Bradley <ve7jtb@ve7jtb.com>
    
Sent: Thursday, November 29, 2018 7:33:57 PM
    
To: Torsten Lodderstedt
    
Cc: Daniel Fett; IETF oauth WG
    
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authoriza=
tion code instead of implicit    

    =C2=A0
    

    

    

    +1
    

    

    

    On Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt <torsten@loddersted=
t.net wrote:
    

    

    
Hi all, 
    

    
based on your feedback on the list and off list, Daniel and I polished the =
text. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing =
access 
    
tokens in the authorization response, such as "token id_token" an=
d "code token id_token=E2=80=9C,

    
unless the issued access tokens are sender-constrained and access token inj=
ection in

    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionabl=
e list of the affected response types.

    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported =
by William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.=C2=A0 
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com&g=
t;:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lod=
derstedt.net wrote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co=
..jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection.

    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token

    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not

    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / 
n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten=
@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig; 
oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nr=
i.co.jp>:
    
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf=
..org> (Dick Hardt <dick.hardt@gmail.com> =E3=81=AE=E4=
=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic.

    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <=
Hannes.Tschofenig@arm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this
 reason, and since CORS allows browser-based apps to send requests to the t=
oken endpoint, Torsten suggested to use the authorization code instead of t=
he implicit grant in call cases in his presentation (see

https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-d=
raft-ietf-oauth-security-topics-01).
    
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any
 purpose, or store or copy the information in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@ietf.org
    
> >> 
https://www.ietf.org/mailman/listinfo/oauth
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@ietf.org
    
> >> 
https://www.ietf.org/mailman/listinfo/oauth
    
> > 
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org
    
> 
https://www.ietf.org/mailman/listinfo/oauth
    

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

    

    

    

    

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

    

--0000000000002c79a5057bd2258e--


From nobody Thu Nov 29 12:23:08 2018
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 58E64130ECA for ; Thu, 29 Nov 2018 12:23:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O37gCRXWlQEU for ; Thu, 29 Nov 2018 12:23:04 -0800 (PST)
Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 2BAB4130EA9 for ; Thu, 29 Nov 2018 12:23:04 -0800 (PST)
Received: by mail-it1-x144.google.com with SMTP id h65so5793285ith.3 for ; Thu, 29 Nov 2018 12:23:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PTCxGf+USMNkZFeOFY2xdGlFA23miH3Urw/nyQkd/I4=; b=EIsSuNtBx4zQ1crFIJ16POG1BORMlnhPc7Y3zWUXYNq9bVd4NlY1O/HYmgtNypekde nfgOX7oMpkwB7coYO3pxemkyrdxttik5kTGykE0TzudeBA58uX2oCQatgTvLOvNtegee JpxNu5ZABBO4c2uAiGMqMGN1cisB+LlSyABAI=
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=PTCxGf+USMNkZFeOFY2xdGlFA23miH3Urw/nyQkd/I4=; b=WAgjwNjN8m1x9e7+CopqcZFAUGGHbHZ8oehV0AkoLyaykUXOHYNCzVaPVdt+Lk6mT1 nJPMN13ZWR/JY+Qs5ws1eElFDr6t/mH4E0DMFyNQ5g/AVYRSO9DdlwqfX9r087IweSML GtaKUQwsvggo5LuhibxgIElOmQ3TE0yCwnRSd/vHJEoQspTkCtbNYOg8LEGZaXVcvv/J xXIEbb1J+B29T6zJzM91D/qz0IHzY7QHrHyLlRUlY+KppfI15WorQYNO7ElNMA5JiSRq Zy74pJTITCQlKpGOR9EaS/ApQ75Jndr0sdO8pd5zjo5aHQO2K/ogE5DXHOrZdtbBQYst K+Fw==
X-Gm-Message-State: AA+aEWZbeaMpoTAxDHO4mXq8BhKbdqgLLjCoUM/g41gm0OHH/NeEKbEZ nE2cjklxiIxzmMdmIfQ9/22MFBBrO/WCHCil4l8WhfqEczulIUTKVoVpf7uOVvWqEkqDfZFNaTH jgpFbTq2Pv0pRLw==
X-Google-Smtp-Source: AFSGD/W5Wl7sQanwqNqVSaVOiKsCTGaE9uGBDpATkt9xiUuK9iI5iuBUhYqp/l7X/bkgVFZPgsXSM+5Lx/2+ZderhrI=
X-Received: by 2002:a24:85d4:: with SMTP id r203-v6mr2795482itd.124.1543522983271;  Thu, 29 Nov 2018 12:23:03 -0800 (PST)
MIME-Version: 1.0
References: <154274201815.29841.1388851667499826707@ietfa.amsl.com>  <554faba4-77c1-4b7c-693e-6a67367e85bb@aol.com> <34366F0A-D361-4C1E-847A-0C812E8D627B@lodderstedt.net>  <1198DA32-4E63-4966-89CA-398478226209@lodderstedt.net>  <8C2C26DF-68E1-4D09-91A5-B0165C2F4997@forgerock.com>
In-Reply-To: <8C2C26DF-68E1-4D09-91A5-B0165C2F4997@forgerock.com>
From: Brian Campbell 
Date: Thu, 29 Nov 2018 13:22:36 -0700
Message-ID: 
To: Neil Madden 
Cc: richanna=40amazon.com@dmarc.ietf.org, oauth 
Content-Type: multipart/alternative; boundary="0000000000001ef8ad057bd3730a"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.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: Thu, 29 Nov 2018 20:23:07 -0000

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

Big +1 here. I'd be in favor of the document discussing the potential
benefits of tying the refresh token to a session in some situations but
very much agree that the spectrum of desired behaviors is much too wide to
normatively recommend any particular option.

On Wed, Nov 28, 2018 at 11:19 PM Neil Madden 
wrote:

> Agreed. Consider also service account flows such as the JWT-bearer
> approach used by Google:
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount#aut=
horizingrequests
>
> It=E2=80=99s not clear there is any session at all in these cases. (Altho=
ugh I
> don=E2=80=99t think there is a refresh token in this specific case).
>
> I think spectrum of desired behaviours is too wide to recommend any
> particular option. Perhaps tying the refresh token to a session could be
> included as a MAY just to document it as something to consider?
>
> =E2=80=94 Neil
>
> On 29 Nov 2018, at 00:20, Richard Backman, Annabelle <
> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> I think we need to be very careful about prescribing behavior around
> refresh token lifetime, and setting expectations for what degree of
> consistency is attainable. Considering the terms "session", "authenticate=
d
> session", "offline", "expiration", "termination", and "log out" can mean
> different things to different services (and those tiny nuances matter!) I
> am against text that makes binding refresh tokens to the authenticated
> session a "SHOULD." Rather, we should recommend that the AS provide the e=
nd
> user with a mechanism by which they may terminate refresh tokens. We can
> also describe session-bound refresh tokens as one such method that may or
> may not be appropriate depending on the use case.
>
> To back up my claim that consistency is Hard, here are a few scenarios to
> consider:
>
> 1)
> A mobile app loads the authorization request in an in-app browser tab tha=
t
> has an app-scoped cookie jar and is never presented by the app again afte=
r
> the flow is complete. How does the user sign out of that session? Should
> the AS kill the session due to inactivity? Won't that confuse the user wh=
en
> suddenly the integration between app and service stops working for no
> discernable reason? If this scenario sounds unlikely, it's not. This is t=
he
> behavior of every app that integrated with the Safari in-app browser tab =
in
> iOS 9 and never updated to the authentication-oriented replacements
> introduced later, as well as that of every app that opens the authorizati=
on
> request in a web view (ugh).
>
> 2)
> A mobile app loads the authorization request in the external browser, but
> the user always uses the AS's app on their device instead of visiting the=
ir
> website (e.g., using the Gmail app instead of going to gmail.com in the
> browser), so their browser session quickly times out due to inactivity.
> Again, won't that confuse the user when the client mobile app stops worki=
ng?
>
> 3)
> A set-top box uses the device flow, and the tokens it receives are bound
> to the user's session in the web browser on their laptop, where they
> completed the device flow. The user buys a new laptop, their session on
> their old laptop times out due to inactivity, and their set-top box can't
> stream videos anymore. =C2=AF\_(=E3=83=84)_/=C2=AF
>
> --
> Annabelle Richard Backman
> AWS Identity
>
>
> =EF=BB=BFOn 11/28/18, 9:20 AM, "OAuth on behalf of Torsten Lodderstedt" <
> oauth-bounces@ietf.org on behalf of torsten@lodderstedt.net> wrote:
>
>
>
> Am 28.11.2018 um 16:53 schrieb George Fletcher :
>
>
> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>
> Hi George,
>
>
> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>
>
> Thanks for the additional section on refresh_tokens. Some additional
> recommendations...
>
>
> 1. By default refresh_tokens are bound to the user's authenticated
> session. When the authenticated session expires or is terminated (whether
> by the user or for some other reason) the refresh_tokenis implicitly
> revoked.
>
> SHOULD or MUST? I would suggest to go with a SHOULD.
>
> I would say that the AS SHOULD bind the refresh_token to the user's
> authentication. However, I'd lean more to MUST for session bound
> refresh_tokens being revoked when the session is terminated.
>
>
>    wfm
>
>    Anyone on the list wanting to object?
>
>
> 2. Clients that need to obtain a refresh_token that exists beyond the
> lifetime of the user's authentication session MUST indicate this need by
> requesting the "offline_access" scope (
> https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess)..
> This provides for a user consent event making it clear to the user that t=
he
> client is requesting access even when the user's authentication session
> expires. This then becomes the default for mobile apps as the refresh_tok=
en
> should not be tied to the web session used to authorize the app.
>
> Sounds reasonable, just the scope =E2=80=9Eoffline_access=E2=80=9C is OID=
C specific. Is it
> time to move it down the stack to OAuth?
>
> It may be if we want more consistency in the implementation of
> refresh_token policy across authorization servers.
>
>
>    Who has an opinion on that topic?
>
>
> 3. The AS MAY consider putting an upper bound on the lifetime of a
> refresh_token (e.g. 1 year). There is no real need to issue a refresh_tok=
en
> that is good indefinitely.
>
> I thought I had covered that in the last section. It=E2=80=99s now:
>
>
> Refresh tokens SHOULD expire if the client has been inactive for some tim=
e,
>
>        i.e. the refresh token has not been used to obtain fresh access
> tokens for
>
>        some time. The expiration time is at the discretion of the
> authorization server.
>
>        It might be a global value or determined based on the client polic=
y
> or
>
>        the grant associated with the refresh token (and its sensitivity).
>
> This is slightly different but sufficient so +1 for the text :)
>
>
>    Ok, thanks.
>
>
> Proposals are welcome!
>
>
> kind regards,
>
> Torsten.
>
>
>
> This is in addition to the other best practices described.
>
>
> Thanks,
>
> George
>
>
> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>
> Hi all,
>
>
> the new revision contains the following changes:
>
>
> * added section on refresh tokens
>
> * additional justifications for recommendation for code
>
> * refactored 2.1 in order to distinguish CSRF, authz response replay and
> mix-up (based on feedback by Joseph Heenan)
>
> * added requirement to authenticate clients during code exchange (PKCE or
> client credential) to 2.1.1.
>
> * changed occurrences of SHALL to MUST
>
>
> As always: looking forward for your feedback.
>
>
> kind regards,
>
> Torsten.
>
>
>
> Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org
>
> :
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> This draft is a work item of the Web Authorization Protocol WG of the IET=
F.
>
>
>       Title           : OAuth 2.0 Security Best Current Practice
>
>       Authors         : Torsten Lodderstedt
>
>                         John Bradley
>
>                         Andrey Labunets
>
>                         Daniel Fett
>
>    Filename        : draft-ietf-oauth-security-topics-10.txt
>
>    Pages           : 38
>
>    Date            : 2018-11-20
>
>
> Abstract:
>
>  This document describes best current security practice for OAuth 2.0..
>
>  It updates and extends the OAuth 2.0 Security Threat Model to
>
>  incorporate practical experiences gathered since OAuth 2.0 was
>
>  published and covers new threats relevant due to the broader
>
>  application of OAuth 2.0.
>
>
>
> The IETF datatracker status page for this draft is:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
>
>
> There are also htmlized versions available at:
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10
>
>
>
> A diff from the previous version is available at:
>
>
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-10
> 
>
>
>
>
> 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/
>
>
>
> _______________________________________________
>
> 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
_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._

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


    Big +1 here. I'd be in favor of the document discussin=
g the potential benefits of tying the refresh token to a session in some si=
tuations but very much agree that the spectrum of desired behaviors is much=
 too wide to normatively recommend any particular option.

    On Wed, Nov 28, 2018 at 11:19 PM Neil Ma=
dden <neil.madden@forgerock=
.com> wrote:
    Agreed. Consider also service ac=
count flows such as the JWT-bearer approach used by Google:=C2=A0https://developers.google.com/identity/p=
rotocols/OAuth2ServiceAccount#authorizingrequests

    It=E2=80=99s not clear there is any session at =
all in these cases. (Although I don=E2=80=99t think there is a refresh toke=
n in this specific case).=C2=A0

    I think spectrum of desired behaviours is too wide to recommend any p=
articular option. Perhaps tying the refresh token to a session could be inc=
luded as a MAY just to document it as something to consider?

    =E2=80=94 Neil
    On 29 Nov 2018, at 00:20, Richard Backman, Annabelle <richanna=3D40am=
azon.com@dmarc.ietf.org> wrote:

    I think we need to be very careful about prescrib=
ing behavior around refresh token lifetime, and setting expectations for wh=
at degree of consistency is attainable. Considering the terms "session=
", "authenticated session", "offline", "expir=
ation", "termination", and "log out" can mean diff=
erent things to different services (and those tiny nuances matter!) I am ag=
ainst text that makes binding refresh tokens to the authenticated session a=
 "SHOULD." Rather, we should recommend that the AS provide the en=
d user with a mechanism by which they may terminate refresh tokens. We can =
also describe session-bound refresh tokens as one such method that may or m=
ay not be appropriate depending on the use case.
    To back up my claim that consistency is Hard, here are a few scenari=
os to consider:

    1)
    A mobil=
e app loads the authorization request in an in-app browser tab that has an =
app-scoped cookie jar and is never presented by the app again after the flo=
w is complete. How does the user sign out of that session? Should the AS ki=
ll the session due to inactivity? Won't that confuse the user when sudd=
enly the integration between app and service stops working for no discernab=
le reason? If this scenario sounds unlikely, it's not. This is the beha=
vior of every app that integrated with the Safari in-app browser tab in iOS=
 9 and never updated to the authentication-oriented replacements introduced=
 later, as well as that of every app that opens the authorization request i=
n a web view (ugh).

    2)
    A m=
obile app loads the authorization request in the external browser, but the =
user always uses the AS's app on their device instead of visiting their=
 website (e.g., using the Gmail app instead of going to gmail.com in the browser), so their browser=
 session quickly times out due to inactivity. Again, won't that confuse=
 the user when the client mobile app stops working?
    =

    3)
    A set-top box uses the device flow, and the to=
kens it receives are bound to the user's session in the web browser on =
their laptop, where they completed the device flow. The user buys a new lap=
top, their session on their old laptop times out due to inactivity, and the=
ir set-top box can't stream videos anymore. =C2=AF\_(=E3=83=84)_/=C2=AF=


    -- 
    Annabelle Richard Bac=
kman
    AWS Identity

    <=
br>=EF=BB=BFOn 11/28/18, 9:20 AM, "OAuth on behalf of Torsten Lo=
dderstedt" <oauth-bounces@ietf.org on behalf of torsten@lodderstedt.net> wrote:



    Am 28.11.2018 um 16:53 schrieb George Fletcher <gffletch@aol.com>:=


    On 11/28/18 5:11 AM, Torsten Lodderstedt wrot=
e:
    Hi George,

    Am 20.11.2018 um 23:38 schrieb George Fletcher <gffletch@aol.com>:

    Thanks for the additional section on refre=
sh_tokens. Some additional recommendations...

    1. By default refresh_tokens are bound to the user's authe=
nticated session. When the authenticated session expires or is terminated (=
whether by the user or for some other reason) the refresh_tokenis implicitl=
y revoked.
    SHOULD or MUST? I would suggest =
to go with a SHOULD.
    I would say that the AS SHOULD bind the refresh_token to th=
e user's authentication. However, I'd lean more to MUST for session=
 bound refresh_tokens being revoked when the session is terminated.<=
br>

     =C2=A0=C2=A0=C2=A0wfm 

     =C2=A0=C2=A0=C2=A0Anyone on the list wanting to objec=
t? 


    2. Clients th=
at need to obtain a refresh_token that exists beyond the lifetime of the us=
er's authentication session MUST indicate this need by requesting the &=
quot;offline_access" scope (https://openid.net/=
specs/openid-connect-core-1_0.html#OfflineAccess).. This provides for a=
 user consent event making it clear to the user that the client is requesti=
ng access even when the user's authentication session expires. This the=
n becomes the default for mobile apps as the refresh_token should not be ti=
ed to the web session used to authorize the app.
    =
Sounds reasonable, just the scope =E2=80=9Eoffline_access=E2=80=9C is=
 OIDC specific. Is it time to move it down the stack to OAuth?
    It may be if we wan=
t more consistency in the implementation of refresh_token policy across aut=
horization servers.

     =C2=A0=
=C2=A0=C2=A0Who has an opinion on that topic?


    3. The AS MAY consider putting an upper bound on=
 the lifetime of a refresh_token (e.g. 1 year). There is no real need to is=
sue a refresh_token that is good indefinitely.
    I thought I had covered that in the last section. It=E2=80=99s now:

    Refresh tokens SHOULD expire if the cli=
ent has been inactive for some time,
     =C2=A0=C2=A0=C2=A0=
 =C2=A0 =C2=A0i.e. the refresh token has not been used to obtain fresh acce=
ss tokens for
     =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0some time=
. The expiration time is at the discretion of the authorization server.
     =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0It might be a global value=
 or determined based on the client policy or
     =C2=A0=C2=
=A0=C2=A0 =C2=A0 =C2=A0the grant associated with the refresh token (and its=
 sensitivity).
    This is slightly different but sufficient so +1 for the text :)

     =C2=A0=C2=A0=C2=A0Ok, thanks. <=
/span>


    Proposals are welcome!

    kind regards,
    Torsten.


    This i=
s in addition to the other best practices described.

    Thanks,
    George

    On 11/20/18 2:3=
2 PM, Torsten Lodderstedt wrote:
    Hi all,

    the new revision contains the following changes:=


    * added section on refresh tokens
    * additional justifications for recommendation for code=

    * refactored 2.1 in order to distinguish CSRF, authz=
 response replay and mix-up (based on feedback by Joseph Heenan)
    =

    * added requirement to authenticate clients during code exchang=
e (PKCE or client credential) to 2.1.1.
    * changed occ=
urrences of SHALL to MUST
    =


    As a=
lways: looking forward for your feedback.

    =

    kind regards,
    =

    Torsten.


    Am 20.11.2018 um 20:26 schrieb internet-drafts@ietf.org
    <=
blockquote type=3D"cite">
    :

    =


    A Ne=
w 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.

     =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ti=
tle =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: OAuth 2.0=
 Security Best Current Practice
     =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =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=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0John 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Andrey Labunets
     =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Daniel Fett
    <=
/blockquote>
     =C2=A0 =C2=A0Filename =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-ietf-oauth-security-topics-10.txt=

     =C2=A0 =C2=A0Pages =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 38
    =

     =C2=A0 =C2=A0Date =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-11-20=


    Abstract:
     =C2=A0This document describes=
 best current security practice for OAuth 2.0..
    <=
blockquote type=3D"cite">
     =C2=A0It updates and extends the OAuth 2=
.0 Security Threat Model to
     =C2=A0incorporate practical experiences gathered since OAu=
th 2.0 was
     =
=C2=A0published and covers new threats relevant due to the broader
     =C2=A0application of =
OAuth 2.0.


    The IETF datatracker status p=
age for this draft is:
    =


    https://datatracker.ietf.org/doc/draft-ietf-oauth-securit=
y-topics/
    =


    There are also htmlized ve=
rsions available at:

    https://tools.ietf.org/html/draft-ietf-oauth-security-topics-1=
0
    https://datatracker.ietf.org/doc/html/draft-ietf-oaut=
h-security-topics-10
    <=
/blockquote>

    <=
/blockquote>

    <=
blockquote type=3D"cite">
    A diff from the=
 previous version is available at:

    <=
blockquote type=3D"cite">
    https://www.ietf.org/rfcdiff?url2=3Ddra=
ft-ietf-oauth-security-topics-10



    Please note that=
 it may take a couple of minutes from the time of submission
    until the htmlized version a=
nd diff are available at tools.ietf.org.
    <=
blockquote type=3D"cite">

    Inter=
net-Drafts are also available by anonymous FTP at:
    <=
/blockquote>

    <=
/blockquote>
    ftp://ftp.ietf.org/internet-drafts/


    _______________________________________________
    <=
/blockquote>
    OAuth mailing list=


    OAuth@ietf.org
    <=
/blockquote>
    https://www..ietf.org/mailman/listinfo/oauth
    =


    ____________________=
___________________________
    OAuth mailing list=


    OAuth@ietf.org
    <=
blockquote type=3D"cite">
    https://www.ietf.or=
g/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
    

    


    
<=
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.
--0000000000001ef8ad057bd3730a--


From nobody Thu Nov 29 16:17:48 2018
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 6A1D012D4F0 for ; Thu, 29 Nov 2018 16:17:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Level: 
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 CCotXn_csrYh for ; Thu, 29 Nov 2018 16:17:43 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3717112D4E7 for ; Thu, 29 Nov 2018 16:17:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1543537063; x=1575073063; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eN+DKvket/XAHQRgUpSAFg8jzcznGrFMKW9z4BckEPg=; b=V/BIoKWJBl+imTWZUfsBbFx6d9TvQdUwZW+cJpsjYqxiJ/iq0RmXFTXN Sxbouptt8eQtMUr4AM2rsoB0ck22EUvEjg5n1kamiRCQ1nHutj/6KEvWG YvKq/JEsGd+tTyUs5WgV4XoJlVxBAql4rvaD0Uwm8a2T0XYFFojQX6Del 0=;
X-IronPort-AV: E=Sophos;i="5.56,253,1539648000";  d="scan'208,217";a="706636109"
Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  30 Nov 2018 00:17:38 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id wAU0HVlx069744 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Nov 2018 00:17:37 GMT
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 00:17:37 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 00:17:36 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 30 Nov 2018 00:17:36 +0000
From: "Richard Backman, Annabelle" 
To: William Denniss , Christian Mainka 
CC: oauth 
Thread-Topic: [OAUTH-WG] Dynamic Client Registration with Native Apps
Thread-Index: AQHUhjXapIsebfMrH0elqz8N/SiwVaVkEwKAgAFD5YCAAARtgIAAEL0AgAAB3wD//+aIAIABd4QAgABQBID//9WoAA==
Date: Fri, 30 Nov 2018 00:17:36 +0000
Message-ID: 
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>     <065bba73-eade-2f07-038f-8afa708e38be@rub.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.175]
Content-Type: multipart/alternative; boundary="_000_E02ADBF5DC7E4BBC8346D9D3A53B9FE1amazoncom_"
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Nov 2018 00:17:47 -0000

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

PiBDbGFpbWVkICJodHRwcyIgc2NoZW1lIFVSSXMgKFJGQyA4MjUyLCBTZWMgNy4yKSBjYW4gYmUg
dXNlZCB0byBwcm92aWRlIHNvbWUgaWRlbnRpdHkgZ3VhcmFudGVlc+KApg0KDQpZZXMsIHByb3Zp
ZGVkIHRoYXQgdGhlIEFTIGNhbiB2ZXJpZnkgdGhhdCB0aGUgY2xhaW1lZCBVUkkgaXMgYSB2YWxp
ZCBVUkkgZm9yIHRoZSBpZGVudGl0eSBiZWluZyBhc3NlcnRlZCBieSB0aGUgY2xpZW50LiBBbmQg
dGhpcyBpZGVudGl0eSBndWFyYW50ZWUgd291bGQgYXBwbHkgdG8gYW4gcHVibGljIG5hdGl2ZSBh
cHAgY2xpZW50IGp1c3QgYXMgd2VsbCBhcyBvbmUgdGhhdCBoYXMgZXN0YWJsaXNoZWQgYSBjbGll
bnQgc2VjcmV0IHZpYSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24uDQoNClNlY3Rpb24gMi4z
IG9mIFJGQzY3NDk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0y
LjM+IGlzIHJlbGV2YW50IGhlcmU6DQoNClRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZXN0
YWJsaXNoIGEgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZA0Kd2l0aCBwdWJsaWMgY2xpZW50
cy4gIEhvd2V2ZXIsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIE5PVCByZWx5DQpvbiBw
dWJsaWMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciB0aGUgcHVycG9zZSBvZiBpZGVudGlmeWlu
ZyB0aGUNCmNsaWVudC4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVu
dGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg
b2YgV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzcz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+
DQpEYXRlOiBUaHVyc2RheSwgTm92ZW1iZXIgMjksIDIwMTggYXQgMTA6NDkgQU0NClRvOiBDaHJp
c3RpYW4gTWFpbmthIDxDaHJpc3RpYW4uTWFpbmthPTQwcnViLmRlQGRtYXJjLmlldGYub3JnPg0K
Q2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIER5bmFt
aWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiB3aXRoIE5hdGl2ZSBBcHBzDQoNCg0KT24gVGh1LCBOb3Yg
MjksIDIwMTggYXQgNjowMyBBTSBDaHJpc3RpYW4gTWFpbmthIDxDaHJpc3RpYW4uTWFpbmthPTQw
cnViLmRlQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MHJ1Yi5kZUBkbWFyYy5pZXRmLm9yZz4+IHdy
b3RlOg0KSGksDQoNCnRoYW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQhDQpUaGlzIHdhcyBleGFj
dGx5IHdoYXQgY29uZnVzZWQgdXMgZHVyaW5nIHJlYWRpbmcgLSB0aGUgbWFpbiB0aHJlYXQgd2Ug
c2VlIGFuZCB3aGljaCBpcyBub3QgYWRkcmVzc2VkIGlzIHJlbGF0ZWQgdG8gdGhlIGFwcCBpbXBl
cnNvbmF0aW9uIGF0dGFjay4NCkV2ZW4gUEtDRSBkb2VzIG5vdCBoZWxwIGFnYWluc3QgdGhlIGFw
cCBpbXBlcnNvbmF0aW9uIGF0dGFjay4NCg0KQ2xhaW1lZCAiaHR0cHMiIHNjaGVtZSBVUklzIChS
RkMgODI1MiwgU2VjIDcuMikgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBzb21lIGlkZW50aXR5IGd1
YXJhbnRlZXMgKHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIFNlYyA4LjYpLCBhcyB0aGUgT1Mg
d2lsbCBvbmx5IG9wZW4gYXBwcyB0aGF0IGNhbiB2ZXJpZnkgZG9tYWluIG93bmVyc2hpcCB0byBw
cm9jZXNzIHRoZSByZWRpcmVjdC4gVGhpcyBpcyB3aGF0IEkgd291bGQgcmVjb21tZW5kIGFzIGEg
c3RhcnRpbmcgcG9pbnQgaWYgeW91IHdhbnQgYXNzdXJhbmNlcyBvdmVyIHRoZSBhcHAncyBpZGVu
dGl0eS4NCg0KQSBzcG9vZmluZyBhcHAgY2FuIHN0aWxsIHVzZSBhIHdlYi12aWV3IHRvIGludGVy
Y2VwdCB0aGUgcmVzcG9uc2UgdGhhdCB3YXksIGJ1dCBpbiB0aGF0IGNhc2UgdGhleSdkIGFsc28g
aGF2ZSBmdWxsIGFjY2VzcyB0byB0aGUgc2Vzc2lvbiBjb29raWUgKGR1ZSB0byB0aGUgdXNlIG9m
IHdlYnZpZXcgZm9yIHRoZSBzaWduLWluKSwgd2hpY2ggaXMgcG90ZW50aWFsbHkgYSBtb3JlIHZh
bHVhYmxlIHRva2VuIChpLmUuIHlvdSBoYXZlIGJpZ2dlciBpc3N1ZXMpLiBJdCBkb2VzIGVmZmVj
dGl2ZWx5IHByZXZlbnQgYWdhaW5zdCB0b2tlbnMgaXNzdWVkIGZvcm0gdGhlIGJyb3dzZXIgU1NP
IHNlc3Npb24gYmVpbmcgaW50ZXJjZXB0ZWQgYnkgdGhlIHdyb25nIGFwcC4NCg0KDQoNClNvIGEg
Ik5hdGl2ZSBBcHAgKyBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24iIGNhbiBiZSBzZWVuIGF0
IGEgZGlmZmVyZW50ICJjb25maWRlbnRpYWxpdHkgbGV2ZWwiIHRoYW4gYSAicHVibGljIGNsaWVu
dCIsIGJlY2F1c2UgZXZlcnkgbmF0aXZlIEFwcCBjYW4gZHluYW1pY2FsbHkgcmVnaXN0ZXIgaXRz
ZWxmIG9uIHRoZSBJZFAuDQpUaGUgSWRQIGNhbm5vdCBkaXN0aW5ndWlzaCwgZm9yIGV4YW1wbGUs
IGFuIGhvbmVzdCBuYXRpdmUgY2xpZW50IGZyb20gYW4gbWFsaWNpb3VzIGNsaWVudCBzdGFydGlu
ZyBhbiBhcHAgaW1wZXJzb25hdGlvbiBhdHRhY2suDQoNCldlIGFncmVlIHRoYXQsIGUuZy4sIGEg
bGVha2VkIGNvZGUgY2Fubm90IGJlIHJlZGVlbWVkIHVubGVzcyB5b3UgaGF2ZSB0aGUgcmVzcGVj
dGl2ZSBjbGllbnRfaWQvY2xpZW50X3NlY3JldC4NCg0KQnV0Li4uIHdlIGFza2VkIG91cnNlbGZz
LCBpbiB3aGljaCBjYXNlcyBkb2VzIGEgY29kZSBsZWFrPw0KDQoxKSBJbiB0aGUgZnJvbnQtY2hh
bm5lbC4gSW4gdGhpcyBjYXNlLCBpdCBpcyB0cnVlIHRoYXQgbm8gY2xpZW50IGNyZWRlbnRpYWxz
IGxlYWsgYW5kIGFuIGF0dGFja2VyIGNhbm5vdCByZWRlZW0gdGhlIGNvZGUuDQoNCjIpIEluIHRo
ZSBiYWNrLWNoYW5uZWwuIEJ1dCBpZiB0aGlzIGNoYW5uZWwgaXMgaW5zZWN1cmUsIHlvdSBkaXJl
Y3RseSBnZXQgY2xpZW50IGNyZWRlbnRpYWxzICh1bmxlc3MgY2xpZW50X3NlY3JldF9qd3QgaXMg
dXNlZCBhcyBwb2ludGVkIG91dCBieSBHZW9yZ2UpLg0KDQpTbywgRHluYW1pYyBDbGllbnQgUmVn
aXN0cmF0aW9uIG9ubHkgaGVscHMgaWYgdGhlIGNvZGUgbGVha3MgYWxvbmUgKGFzIGluIDEuKSwg
b3IgaWYgaXQgbGVha3Mgb24gZGlmZmVyZW50IGxldmVscyAoZS5nLiBsb2dmaWxlcykuDQoNCk9u
IHRoZSBvcHBvc2l0ZSBzaXRlLCBpZiBEeW5hbWljIFJlZ2lzdHJhdGlvbiBpcyBhdmFpbGFibGUs
IGFuIGF0dGFja2VyIGNhbiB2ZXJ5IGVhc2lseSBkbyBhbiBhcHAgaW1wZXJzb25hdGlvbiBhdHRh
Y2sgYnkgcmVnaXN0ZXJpbmcgb24gdGhlIElkUC4gVG8gYmUgY2xlYXIsIGl0IGlzIG5vdCAiaW1w
ZXJzb25hdGlvbiIgYXMgaW4gdGhlICJvbmUgc2VjcmV0IHBlciBzb2Z0d2FyZSIgc2NlbmFyaW8s
IGJlY2F1c2UgZGlmZmVyZW50IGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCBpcyB1c2VkLCBi
dXQgdG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCB0aGUgSWRQIGNhbm5vdCBkaXN0aW5ndWlz
aCBiZXR3ZWVuIGFuIGhvbmVzdCBhcHAgYW5kIGFuIGFwcCBpbXBlcnNvbmF0aW9uIGNsaWVudCB0
aGF0IGhhcyBzaW1wbHkgcmVnaXN0ZXJlZC4NCg0KSW4gYWRkaXRpb24sIGlmIHRoZSBJZFAgc3Vw
cG9ydHMgdGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbjoNCkhvdyBjYW4gdGhlIElkUCBk
aXN0aW5ndWlzaCBiZXR3ZWVuIGNvbmZpZGVudGlhbCBhbmQgcHVibGljL25hdGl2ZSBjbGllbnRz
Pw0KV2l0aCByZXNwZWN0IHRvIHRoZSBjb25zZW50IHBhZ2UsIHdoaWNoIG11c3QgYmUgc2hvd24g
ZXZlcnkgdGltZSBmb3IgbmF0aXZlIGFwcHMsIHRoaXMgaXMgYW4gaW1wb3J0YW50IGlzc3VlLCB3
aGljaCBzaG91bGQgYmUgYWRkcmVzc2VkIHByb3Blcmx5Lg0KDQpCZXN0IFJlZ2FyZHMNClZsYWRp
L0NocmlzdGlhbg0KDQpBbSAyOS4xMS4xOCB1bSAwMDozOCBzY2hyaWViIFJpY2hhcmQgQmFja21h
biwgQW5uYWJlbGxlOg0KDQpJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCDigJx0cmFkaXRpb25hbOKA
nSBjb25maWRlbnRpYWwgY2xpZW50cyB3aXRoIHJlZ2lzdGVyZWQgcmV0dXJuIFVSTHMgYW5kIHNl
cnZlci1zaWRlIHNlY3JldHMgbWF5IHByb3ZpZGUgYSBoaWdoZXIgZGVncmVlIG9mIGNvbmZpZGVu
Y2UgaW4gdGhlIHRydWUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudCB0aGF0IGRvZXNu4oCZdCBjYXJy
eSBvdmVyIHRvIGNvbmZpZGVudGlhbCBuYXRpdmUgYXBwIGNsaWVudHMuIEEgbmF0aXZlIGFwcCBp
bnN0YW5jZeKAmXMgcmVnaXN0cmF0aW9uIGNhbGwgaXMgbmVjZXNzYXJpbHkgdW5hdXRoZW50aWNh
dGVkIChmb3IgdGhlIHNhbWUgcmVhc29ucyB0aGF0IHN0YXRpY2FsbHkgcmVnaXN0ZXJlZCBuYXRp
dmUgYXBwIGNsaWVudHMgYXJlIHB1YmxpYyBjbGllbnRzKSwgc28gdGhlIENsaWVudCBJbXBlcnNv
bmF0aW9uIGNvbmNlcm5zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDguNiBvZiBSRkM4MjUyPGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MjUyI3NlY3Rpb24tOC42PjxodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjODI1MiNzZWN0aW9uLTguNj4gc3RpbGwgYXBwbHkuDQoNCi0tDQoN
CkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCg0KQVdTIElkZW50aXR5DQoNCg0KDQoNCg0KRnJv
bTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aC1ib3VuY2VzQGll
dGYub3JnPiBvbiBiZWhhbGYgb2YgRmlsaXAgU2tva2FuIDxwYW52YS5pcEBnbWFpbC5jb20+PG1h
aWx0bzpwYW52YS5pcEBnbWFpbC5jb20+DQoNCkRhdGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjgs
IDIwMTggYXQgOToxMSBBTQ0KDQpUbzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29t
PjxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4NCg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz48
bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEeW5hbWlj
IENsaWVudCBSZWdpc3RyYXRpb24gd2l0aCBOYXRpdmUgQXBwcw0KDQoNCg0KQXBvbG9naWVzLCBJ
IG1pc3NlZCB0aGUgaXNzdWVkIGluICJpc3N1ZWQgYSBzaGFyZWQgc2VjcmV0IiwganVzdCByZWFk
aW5nICJzaGFyZWQgc2VjcmV0IiBhbG9uZSBpcyB0aGUgZXhhY3Qgb3Bwb3NpdGUgb2YgYSBwZXIt
aW5zdGFuY2Ugc2VjcmV0LiBUaGUgcmVzdCBpcyBjbGVhciBhbmQgYXMgeW91IHNheSBpdCBicmlu
Z3MgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3JldCBuZXZlciBiZWluZyBzZW50IG92ZXIgdGhlIHdp
cmUgKGV4Y2VwdCBkdXJpbmcgdGhlIGluaXRpYWwgcmVnaXN0cmF0aW9uIHZpYSBUTFMpLg0KDQoN
Cg0KQmVzdCwNCg0KRmlsaXANCg0KDQoNCg0KDQpPbiBXZWQsIE5vdiAyOCwgMjAxOCBhdCA2OjAz
IFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86Z2ZmbGV0Y2hAYW9s
LmNvbT48bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+PG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPj4g
d3JvdGU6DQoNCkl0J3MgImNvbmZpZGVudGlhbCIgaW4gdGhhdCB0aGUgc2hhcmVkIHNlY3JldCBp
cyB1bmlxdWUgdG8gdGhhdCBhcHAgaW5zdGFuY2UgcmVnaXN0cmF0aW9uIChhcyBEZW5uaXMgZGVz
Y3JpYmVkIGluIGhpcyByZXNwb25zZSkuIElmIGFuIGF0dGFja2VyIGdldHMgbXkgcGhvbmUgYW5k
IGNvbXByb21pc2VzIHRoZSBkYXRhIHN0b3JlZCBvbiBteSBkZXZpY2UsIHRoZXkgb25seSBnZXQg
dGhlIHNlY3JldCBmb3IgbXkgZGV2aWNlLiBUaGlzIGlzIG5vIGRpZmZlcmVudCB0aGFuIGEgc2Vy
dmVyIHNpZGUgY2xpZW50IGhhdmluZyB0aGVpciBjbGllbnQgc2VjcmV0IGNvbXByb21pc2VkIHRo
cm91Z2ggYW4gYXR0YWNrIChhbmQgaW4gc29tZSB3YXlzIGlzIGJldHRlciBiZWNhdXNlIGl0J3Mg
aW5zdGFuY2Ugc3BlY2lmaWMpLg0KDQoNCg0KVGhlIG1haW4gcG9pbnQgSSB3YXMgdHJ5aW5nIHRv
IG1ha2UsIGlzIHRoYXQgdGhlICdjbGllbnRfc2VjcmV0X2p3dCcgbWV0aG9kIGFsbG93cyB0aGUg
Y2xpZW50IHRvIG5ldmVyIHNlbmQgdGhlIHNoYXJlZCBzZWNyZXQgYWNyb3NzIHRoZSB3aXJlIGFz
IGlzIGNyZWF0ZWQgaW4gdGhlIGRlZmF1bHQgT0F1dGgyIEhUVFAgQmFzaWMgQXV0aGVudGljYXRp
b24gbWV0aG9kLg0KDQoNCg0KVGhhbmtzLA0KDQpHZW9yZ2UNCg0KT24gMTEvMjgvMTggMTE6MDMg
QU0sIEZpbGlwIFNrb2thbiB3cm90ZToNCg0KSGkgR2VvcmdlLA0KDQoNCg0KIzIgZG9lc24ndCBz
ZWVtIGNvbmZpZGVudGlhbCwgaXQncyBzdGlsbCBhIHNlY3JldCBzaGFyZWQgYW1vbmdzdCBpbnN0
YWxsYXRpb25zIGFuZCBhbnlvbmUgcmV2ZXJzZSBlbmdpbmVlcmluZyB0aGUgYXBrLCBleHRyYWN0
aW5nIHRoZSBzZWNyZXQsIGNhbiBmb3JtIHRoZSBjbGllbnRfc2VjcmV0X2p3dCBjbGllbnRfYXNz
ZXJ0aW9uIHdpdGggaXQganVzdCBmaW5lLg0KDQoNCg0KQmVzdCwNCg0KRmlsaXANCg0KDQoNCk9u
IFdlZCwgTm92IDI4LCAyMDE4IGF0IDQ6NDggUE0gR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00
MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5p
ZXRmLm9yZz48bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZz48bWFpbHRvOjQwYW9sLmNv
bUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpJbiBhZGRpdGlvbiwgYSBmZXcgYWRkaXRpb25h
bCBwYXR0ZXJucyBhcmUgZW5hYmxlZC4uLg0KDQoNCg0KMS4gVGhlIG5hdGl2ZSBhcHAgY2FuIGdl
bmVyYXRlIGEgcHVibGljL3ByaXZhdGUga2V5IHBhaXIgYW5kIHRoZW4gdXNlIHByaXZhdGVfc2Vj
cmV0X2p3dCBhcyB0aGUgY2xpZW50IGNyZWRlbnRpYWwgdmFsaWRhdGlvbiBtZXRob2QgdmlhIHRo
ZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdyAoZGVmaW5lZCBpbiBPcGVuSUQgQ29ubmVjdCkuDQoN
Cg0KDQoyLiBNYXliZSBtb3JlIHNpbXBseSwgaWYgdGhlIG5hdGl2ZSBhcHAgaXMgaXNzdWVkIGEg
c2hhcmVkIHNlY3JldCwgdGhlIGFwcCBjYW4gdXNlIGNsaWVudF9zZWNyZXRfand0IG1ldGhvZCBm
b3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHdoaWNoIGVuc3VyZXMgdGhlIHNoYXJlZCBzZWNyZXQg
bmV2ZXIgbGVhdmVzIHRoZSBkZXZpY2UuIChBZ2FpbiBkZWZpbmVkIGluIHRoZSBPcGVuSUQgQ29u
bmVjdCBzcGVjKS4NCg0KDQoNCjMuIE9uY2UgdGhlIG5hdGl2ZSBhcHAgaW5zdGFuY2UgaGFzIGNy
ZWRlbnRpYWxzLCB0aGV5IGNhbiBiZSB1c2VkIGZvciBhZGRpdGlvbmFsIHNlY3VyaW5nIG9mIGFw
cCBBUEkgdHJhbnNhY3Rpb25zIGluIGFkZGl0aW9uIHRvIGp1c3QgdGhlIE9BdXRoMi9PcGVuSUQg
Q29ubmVjdCBmbG93cy4NCg0KDQoNClRoYW5rcywNCg0KR2VvcmdlDQoNCk9uIDExLzI3LzE4IDM6
MjggUE0sIFdpbGxpYW0gRGVubmlzcyB3cm90ZToNCg0KSWYgdGhlIHNlY3JldCBpcyBkeW5hbWlj
YWxseSBwcm92aXNpb25lZCB0aGVuIHlvdSBoYXZlIGEgY29uZmlkZW50aWFsIGNsaWVudC4gQW55
b25lIHJldmVyc2UgZW5naW5lZXJpbmcgdGhlaXIgb3duIGluc3RhbGxhdGlvbiBvZiB0aGUgbmF0
aXZlIGFwcCB3b3VsZCBvbmx5IGV4dHJhY3QgdGhlaXIgb3duIGNsaWVudCdzIGNyZWRlbnRpYWxz
LCBhcyBvcHBvc2VkIHRvIHRoZSBzaGFyZWQgc2VjcmV0IG9mIGFsbCBpbnN0YWxsYXRpb25zLiBI
YXZpbmcgYSBjb25maWRlbnRpYWwgY2xpZW50IG1lYW5zIHRoYXQgcmVxdWVzdHMgdG8gdGhlIHRv
a2VuIGVuZHBvaW50IChjb2RlLCByZWZyZXNoKSBhcmUgY2xpZW50IGF1dGhlbnRpY2F0ZWQsIHNv
IFBLQ0Ugd291bGRuJ3QgYmUgbmVlZGVkLg0KDQoNCg0KT24gVHVlLCBOb3YgMjcsIDIwMTggYXQg
MTo0NCBBTSwgQ2hyaXN0aWFuIE1haW5rYSA8Q2hyaXN0aWFuLk1haW5rYT00MHJ1Yi5kZUBkbWFy
Yy5pZXRmLi5vcmc8bWFpbHRvOkNocmlzdGlhbi5NYWlua2E9NDBydWIuZGVAZG1hcmMuaWV0Zi4u
b3JnPjxtYWlsdG86Q2hyaXN0aWFuLk1haW5rYT00MHJ1Yi5kZUBkbWFyYy5pZXRmLm9yZz48bWFp
bHRvOkNocmlzdGlhbi5NYWlua2E9NDBydWIuZGVAZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0K
SGksDQoNCg0KDQp3ZSBqdXN0IHN0dW1ibGVkIHVwb24gdGhpcyBbMV0gc3RhdGVtZW50Og0KDQoi
RXhjZXB0IHdoZW4gdXNpbmcgYSBtZWNoYW5pc20gbGlrZSBEeW5hbWljIENsaWVudCBSZWdpc3Ry
YXRpb24NCg0KICAgW1JGQzc1OTFdIHRvIHByb3Zpc2lvbiBwZXItaW5zdGFuY2Ugc2VjcmV0cywg
bmF0aXZlIGFwcHMgYXJlDQoNCiAgIGNsYXNzaWZpZWQgYXMgcHVibGljIGNsaWVudHMgLi4uIg0K
DQoNCg0KV2hhdCBkb2VzIHRoaXMgbWVhbiBmb3IgdXM/IE5hdGl2ZSBBcHAgKyBEeW5hbWljIENs
aWVudCBSZWdpc3RyYXRpb24gPQ0KDQpDb25maWRlbnRpYWwgQ2xpZW50Pw0KDQpXaGljaCB0aHJl
YXRzIGFyZSBjb3ZlcmVkIGlmIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBpcyB1c2VkIG9u
DQoNCk5hdGl2ZSBBcHBzPw0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpWbGFkaS9DaHJpc3RpYW4N
Cg0KDQoNClsxXTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgyNTIjc2VjdGlvbi04
LjQNCg0KDQoNCi0tDQoNCkRyLi1JbmcuIENocmlzdGlhbiBNYWlua2ENCg0KSG9yc3QgR8O2cnR6
IEluc3RpdHV0ZSBmb3IgSVQtU2VjdXJpdHkNCg0KQ2hhaXIgZm9yIE5ldHdvcmsgYW5kIERhdGEg
U2VjdXJpdHkNCg0KUnVoci1Vbml2ZXJzaXR5IEJvY2h1bSwgR2VybWFueQ0KDQoNCg0KVW5pdmVy
c2l0w6R0c3N0ci4gMTUwLCBJRCAyLzQ2Mw0KDQpELTQ0ODAxIEJvY2h1bSwgR2VybWFueQ0KDQoN
Cg0KVGVsZWZvbjogKzQ5ICgwKSAyMzQgLyAzMi0yNjc5Ng0KDQpGYXg6ICs0OSAoMCkgMjM0IC8g
MzItMTQzNDcNCg0KaHR0cDovL25kcy5ydWIuZGUvY2hhaXIvcGVvcGxlL2NtYWlua2EvDQoNCkBD
aGVhcmlYDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP
QXV0aEBpZXRmLm9yZz48bWFpbHRvOk9BdXRoQGlldGYub3JnPjxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoN
Cg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNCg0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KDQoNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRvOk9BdXRoQGlldGYub3JnPjxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+DQoNCg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KT0F1
dGggbWFpbGluZyBsaXN0DQoNCg0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQoNCg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy4u
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD48aHR0cHM6Ly93d3cuLmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg+DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KDQotLQ0KDQpEci4tSW5nLiBDaHJpc3RpYW4gTWFpbmthDQoN
CkhvcnN0IEfDtnJ0eiBJbnN0aXR1dGUgZm9yIElULVNlY3VyaXR5DQoNCkNoYWlyIGZvciBOZXR3
b3JrIGFuZCBEYXRhIFNlY3VyaXR5DQoNClJ1aHItVW5pdmVyc2l0eSBCb2NodW0sIEdlcm1hbnkN
Cg0KDQoNClVuaXZlcnNpdMOkdHNzdHIuIDE1MCwgSUQgMi80NjMNCg0KRC00NDgwMSBCb2NodW0s
IEdlcm1hbnkNCg0KDQoNClRlbGVmb246ICs0OSAoMCkgMjM0IC8gMzItMjY3OTYNCg0KRmF4OiAr
NDkgKDApIDIzNCAvIDMyLTE0MzQ3DQoNCmh0dHA6Ly9uZHMucnViLmRlL2NoYWlyL3Blb3BsZS9j
bWFpbmthLw0KDQpAQ2hlYXJpWA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0K

--_000_E02ADBF5DC7E4BBC8346D9D3A53B9FE1amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <5976C5AD685DF749A0FFD7110B349C8B@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAy
IDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp
Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv
cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i
b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt
bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0
OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz
cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4u
RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mZ3Q7IENsYWltZWQgJnF1b3Q7aHR0cHMmcXVvdDsgc2NoZW1lIFVSSXMgKFJG
QyA4MjUyLCBTZWMgNy4yKSBjYW4gYmUgdXNlZCB0byBwcm92aWRlIHNvbWUgaWRlbnRpdHkgZ3Vh
cmFudGVlc+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHByb3ZpZGVkIHRoYXQgdGhl
IEFTIGNhbiB2ZXJpZnkgdGhhdCB0aGUgY2xhaW1lZCBVUkkgaXMgYSB2YWxpZCBVUkkgZm9yIHRo
ZSBpZGVudGl0eSBiZWluZyBhc3NlcnRlZCBieSB0aGUgY2xpZW50LiBBbmQgdGhpcyBpZGVudGl0
eSBndWFyYW50ZWUgd291bGQgYXBwbHkgdG8gYW4gcHVibGljIG5hdGl2ZSBhcHAgY2xpZW50IGp1
c3QgYXMgd2VsbCBhcyBvbmUgdGhhdCBoYXMgZXN0YWJsaXNoZWQgYSBjbGllbnQNCiBzZWNyZXQg
dmlhIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0yLjMi
PlNlY3Rpb24gMi4zIG9mIFJGQzY3NDk8L2E+IGlzIHJlbGV2YW50IGhlcmU6PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN
QVkgZXN0YWJsaXNoIGEgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPndpdGggcHVi
bGljIGNsaWVudHMuJm5ic3A7IEhvd2V2ZXIsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU
IE5PVCByZWx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+b24gcHVibGljIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgdGhlIHB1
cnBvc2Ugb2YgaWRlbnRpZnlpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Y2xpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFu
bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv
dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFdpbGxpYW0gRGVubmlzcyAmbHQ7d2Rlbm5pc3M9NDBn
b29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwg
Tm92ZW1iZXIgMjksIDIwMTggYXQgMTA6NDkgQU08YnI+DQo8Yj5UbzogPC9iPkNocmlzdGlhbiBN
YWlua2EgJmx0O0NocmlzdGlhbi5NYWlua2E9NDBydWIuZGVAZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJy
Pg0KPGI+Q2M6IDwvYj5vYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj
dDogPC9iPlJlOiBbT0FVVEgtV0ddIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiB3aXRoIE5h
dGl2ZSBBcHBzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIFRodSwgTm92IDI5LCAyMDE4IGF0IDY6MDMgQU0gQ2hyaXN0aWFuIE1haW5rYSAmbHQ7Q2hy
aXN0aWFuLk1haW5rYT08YSBocmVmPSJtYWlsdG86NDBydWIuZGVAZG1hcmMuaWV0Zi5vcmciPjQw
cnViLmRlQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxi
cj4NCjxicj4NCnRoYW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQhPGJyPg0KVGhpcyB3YXMgZXhh
Y3RseSB3aGF0IGNvbmZ1c2VkIHVzIGR1cmluZyByZWFkaW5nIDxiPi08L2I+IHRoZSBtYWluIHRo
cmVhdCB3ZSBzZWUgYW5kIHdoaWNoIGlzIG5vdCBhZGRyZXNzZWQgaXMgcmVsYXRlZCB0byB0aGUg
YXBwIGltcGVyc29uYXRpb24gYXR0YWNrLjxicj4NCkV2ZW4gUEtDRSBkb2VzIG5vdCBoZWxwIGFn
YWluc3QgdGhlIGFwcCBpbXBlcnNvbmF0aW9uIGF0dGFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D
bGFpbWVkICZxdW90O2h0dHBzJnF1b3Q7IHNjaGVtZSBVUklzIChSRkMgODI1MiwgU2VjIDcuMikg
Y2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBzb21lIGlkZW50aXR5IGd1YXJhbnRlZXMgKHNlY3VyaXR5
IGNvbnNpZGVyYXRpb25zIGluIFNlYyA4LjYpLCBhcyB0aGUgT1Mgd2lsbCBvbmx5IG9wZW4gYXBw
cyB0aGF0IGNhbiB2ZXJpZnkgZG9tYWluIG93bmVyc2hpcCB0byBwcm9jZXNzIHRoZSByZWRpcmVj
dC4gVGhpcyBpcyB3aGF0IEkNCiB3b3VsZCByZWNvbW1lbmQgYXMgYSBzdGFydGluZyBwb2ludCBp
ZiB5b3Ugd2FudCBhc3N1cmFuY2VzIG92ZXIgdGhlIGFwcCdzIGlkZW50aXR5LjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHNwb29maW5nIGFw
cCBjYW4gc3RpbGwgdXNlIGEgd2ViLXZpZXcgdG8gaW50ZXJjZXB0IHRoZSByZXNwb25zZSB0aGF0
IHdheSwgYnV0IGluIHRoYXQgY2FzZSB0aGV5J2QgYWxzbyBoYXZlIGZ1bGwgYWNjZXNzIHRvIHRo
ZSBzZXNzaW9uIGNvb2tpZSAoZHVlIHRvIHRoZSB1c2Ugb2Ygd2VidmlldyBmb3IgdGhlIHNpZ24t
aW4pLCB3aGljaCBpcyBwb3RlbnRpYWxseSBhIG1vcmUgdmFsdWFibGUgdG9rZW4gKGkuZS4NCiB5
b3UgaGF2ZSBiaWdnZXIgaXNzdWVzKS4gSXQgZG9lcyBlZmZlY3RpdmVseSBwcmV2ZW50IGFnYWlu
c3QgdG9rZW5zIGlzc3VlZCBmb3JtIHRoZSBicm93c2VyIFNTTyBzZXNzaW9uIGJlaW5nIGludGVy
Y2VwdGVkIGJ5IHRoZSB3cm9uZyBhcHAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo
dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpTbyBhICZx
dW90O05hdGl2ZSBBcHAgJiM0MzsgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uJnF1b3Q7IGNh
biBiZSBzZWVuIGF0IGEgZGlmZmVyZW50ICZxdW90O2NvbmZpZGVudGlhbGl0eSBsZXZlbCZxdW90
OyB0aGFuIGEgJnF1b3Q7cHVibGljIGNsaWVudCZxdW90OywgYmVjYXVzZSBldmVyeSBuYXRpdmUg
QXBwIGNhbiBkeW5hbWljYWxseSByZWdpc3RlciBpdHNlbGYgb24gdGhlIElkUC48YnI+DQpUaGUg
SWRQIGNhbm5vdCBkaXN0aW5ndWlzaCwgZm9yIGV4YW1wbGUsIGFuIGhvbmVzdCBuYXRpdmUgY2xp
ZW50IGZyb20gYW4gbWFsaWNpb3VzIGNsaWVudCBzdGFydGluZyBhbiBhcHAgaW1wZXJzb25hdGlv
biBhdHRhY2suPGJyPg0KPGJyPg0KV2UgYWdyZWUgdGhhdCwgZS5nLiwgYSBsZWFrZWQgY29kZSBj
YW5ub3QgYmUgcmVkZWVtZWQgdW5sZXNzIHlvdSBoYXZlIHRoZSByZXNwZWN0aXZlIGNsaWVudF9p
ZC9jbGllbnRfc2VjcmV0Ljxicj4NCjxicj4NCkJ1dC4uLiB3ZSBhc2tlZCBvdXJzZWxmcywgaW4g
d2hpY2ggY2FzZXMgZG9lcyBhIGNvZGUgbGVhaz88YnI+DQo8YnI+DQoxKSBJbiB0aGUgZnJvbnQt
Y2hhbm5lbC4gSW4gdGhpcyBjYXNlLCBpdCBpcyB0cnVlIHRoYXQgbm8gY2xpZW50IGNyZWRlbnRp
YWxzIGxlYWsgYW5kIGFuIGF0dGFja2VyIGNhbm5vdCByZWRlZW0gdGhlIGNvZGUuPGJyPg0KPGJy
Pg0KMikgSW4gdGhlIGJhY2stY2hhbm5lbC4gQnV0IGlmIHRoaXMgY2hhbm5lbCBpcyBpbnNlY3Vy
ZSwgeW91IGRpcmVjdGx5IGdldCBjbGllbnQgY3JlZGVudGlhbHMgKHVubGVzcyBjbGllbnRfc2Vj
cmV0X2p3dCBpcyB1c2VkIGFzIHBvaW50ZWQgb3V0IGJ5IEdlb3JnZSkuPGJyPg0KPGJyPg0KU28s
IER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBvbmx5IGhlbHBzIGlmIHRoZSBjb2RlIGxlYWtz
IGFsb25lIChhcyBpbiAxLiksIG9yIGlmIGl0IGxlYWtzIG9uIGRpZmZlcmVudCBsZXZlbHMgKGUu
Zy4gbG9nZmlsZXMpLjxicj4NCjxicj4NCk9uIHRoZSBvcHBvc2l0ZSBzaXRlLCBpZiBEeW5hbWlj
IFJlZ2lzdHJhdGlvbiBpcyBhdmFpbGFibGUsIGFuIGF0dGFja2VyIGNhbiB2ZXJ5IGVhc2lseSBk
byBhbiBhcHAgaW1wZXJzb25hdGlvbiBhdHRhY2sgYnkgcmVnaXN0ZXJpbmcgb24gdGhlIElkUC4g
VG8gYmUgY2xlYXIsIGl0IGlzIG5vdCAmcXVvdDtpbXBlcnNvbmF0aW9uJnF1b3Q7IGFzIGluIHRo
ZSAmcXVvdDtvbmUgc2VjcmV0IHBlciBzb2Z0d2FyZSZxdW90OyBzY2VuYXJpbywgYmVjYXVzZSBk
aWZmZXJlbnQgY2xpZW50X2lkDQogYW5kIGNsaWVudF9zZWNyZXQgaXMgdXNlZCwgYnV0IHRvIHRo
ZSBiZXN0IG9mIG15IGtub3dsZWRnZSwgdGhlIElkUCBjYW5ub3QgZGlzdGluZ3Vpc2ggYmV0d2Vl
biBhbiBob25lc3QgYXBwIGFuZCBhbiBhcHAgaW1wZXJzb25hdGlvbiBjbGllbnQgdGhhdCBoYXMg
c2ltcGx5IHJlZ2lzdGVyZWQuPGJyPg0KPGJyPg0KSW4gYWRkaXRpb24sIGlmIHRoZSBJZFAgc3Vw
cG9ydHMgdGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBjYW4gdGhlIElkUCBkaXN0aW5n
dWlzaCBiZXR3ZWVuIGNvbmZpZGVudGlhbCBhbmQgcHVibGljL25hdGl2ZSBjbGllbnRzPzxicj4N
CldpdGggcmVzcGVjdCB0byB0aGUgY29uc2VudCBwYWdlLCB3aGljaCBtdXN0IGJlIHNob3duIGV2
ZXJ5IHRpbWUgZm9yIG5hdGl2ZSBhcHBzLCB0aGlzIGlzIGFuIGltcG9ydGFudCBpc3N1ZSwgd2hp
Y2ggc2hvdWxkIGJlIGFkZHJlc3NlZCBwcm9wZXJseS48YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHM8
YnI+DQpWbGFkaS9DaHJpc3RpYW4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkFtIDI5LjExLjE4IHVtIDAwOjM4IHNjaHJpZWIgUmljaGFyZCBC
YWNrbWFuLCBBbm5hYmVsbGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5JdCBzaG91
bGQgYmUgbm90ZWQgdGhhdCDigJx0cmFkaXRpb25hbOKAnSBjb25maWRlbnRpYWwgY2xpZW50cyB3
aXRoIHJlZ2lzdGVyZWQgcmV0dXJuIFVSTHMgYW5kIHNlcnZlci1zaWRlIHNlY3JldHMgbWF5IHBy
b3ZpZGUgYSBoaWdoZXIgZGVncmVlIG9mIGNvbmZpZGVuY2UgaW4gdGhlIHRydWUgaWRlbnRpdHkg
b2YgdGhlIGNsaWVudCB0aGF0IGRvZXNu4oCZdCBjYXJyeSBvdmVyIHRvIGNvbmZpZGVudGlhbCBu
YXRpdmUgYXBwIGNsaWVudHMuIEEgbmF0aXZlIGFwcCBpbnN0YW5jZeKAmXMgcmVnaXN0cmF0aW9u
IGNhbGwgaXMgbmVjZXNzYXJpbHkgdW5hdXRoZW50aWNhdGVkIChmb3IgdGhlIHNhbWUgcmVhc29u
cyB0aGF0IHN0YXRpY2FsbHkgcmVnaXN0ZXJlZCBuYXRpdmUgYXBwIGNsaWVudHMgYXJlIHB1Ymxp
YyBjbGllbnRzKSwgc28gdGhlIENsaWVudCBJbXBlcnNvbmF0aW9uIGNvbmNlcm5zIGRlc2NyaWJl
ZCBpbiBzZWN0aW9uIDguNiBvZiBSRkM4MjUyPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL3JmYzgyNTIjc2VjdGlvbi04LjYiIHRhcmdldD0iX2JsYW5rIj4mbHQ7aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL3JmYzgyNTIjc2VjdGlvbi04LjYmZ3Q7PC9hPiBzdGlsbCBhcHBs
eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFubmFi
ZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BV1MgSWRlbnRpdHk8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBPQXV0aCA8YSBocmVmPSJtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtvYXV0aC1ib3VuY2VzQGll
dGYub3JnJmd0OzwvYT4gb24gYmVoYWxmIG9mIEZpbGlwIFNrb2thbiA8YSBocmVmPSJtYWlsdG86
cGFudmEuaXBAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3BhbnZhLmlwQGdtYWlsLmNv
bSZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+RGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJl
ciAyOCwgMjAxOCBhdCA5OjExIEFNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IEdlb3JnZSBG
bGV0Y2hlciA8YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PiZsdDtnZmZsZXRjaEBhb2wuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzog
b2F1dGggPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0
O29hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gd2l0aCBOYXRpdmUgQXBw
czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFw
b2xvZ2llcywgSSBtaXNzZWQgdGhlIGlzc3VlZCBpbiAmcXVvdDtpc3N1ZWQgYSBzaGFyZWQgc2Vj
cmV0JnF1b3Q7LCBqdXN0IHJlYWRpbmcgJnF1b3Q7c2hhcmVkIHNlY3JldCZxdW90OyBhbG9uZSBp
cyB0aGUgZXhhY3Qgb3Bwb3NpdGUgb2YgYSBwZXItaW5zdGFuY2Ugc2VjcmV0LiBUaGUgcmVzdCBp
cyBjbGVhciBhbmQgYXMgeW91IHNheSBpdCBicmluZ3MgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3Jl
dCBuZXZlciBiZWluZyBzZW50IG92ZXIgdGhlIHdpcmUgKGV4Y2VwdCBkdXJpbmcgdGhlIGluaXRp
YWwgcmVnaXN0cmF0aW9uIHZpYSBUTFMpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPkJlc3QsPG86cD48L286cD48L3ByZT4NCjxwcmU+RmlsaXA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiBXZWQsIE5vdiAyOCwgMjAxOCBhdCA2OjAzIFBN
IEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFvbC5jb20iIHRh
cmdldD0iX2JsYW5rIj5nZmZsZXRjaEBhb2wuY29tPC9hPjxhIGhyZWY9Im1haWx0bzpnZmZsZXRj
aEBhb2wuY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O21haWx0bzpnZmZsZXRjaEBhb2wuY29tJmd0
OzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkl0J3MgJnF1b3Q7Y29uZmlk
ZW50aWFsJnF1b3Q7IGluIHRoYXQgdGhlIHNoYXJlZCBzZWNyZXQgaXMgdW5pcXVlIHRvIHRoYXQg
YXBwIGluc3RhbmNlIHJlZ2lzdHJhdGlvbiAoYXMgRGVubmlzIGRlc2NyaWJlZCBpbiBoaXMgcmVz
cG9uc2UpLiBJZiBhbiBhdHRhY2tlciBnZXRzIG15IHBob25lIGFuZCBjb21wcm9taXNlcyB0aGUg
ZGF0YSBzdG9yZWQgb24gbXkgZGV2aWNlLCB0aGV5IG9ubHkgZ2V0IHRoZSBzZWNyZXQgZm9yIG15
IGRldmljZS4gVGhpcyBpcyBubyBkaWZmZXJlbnQgdGhhbiBhIHNlcnZlciBzaWRlIGNsaWVudCBo
YXZpbmcgdGhlaXIgY2xpZW50IHNlY3JldCBjb21wcm9taXNlZCB0aHJvdWdoIGFuIGF0dGFjayAo
YW5kIGluIHNvbWUgd2F5cyBpcyBiZXR0ZXIgYmVjYXVzZSBpdCdzIGluc3RhbmNlIHNwZWNpZmlj
KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5U
aGUgbWFpbiBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSwgaXMgdGhhdCB0aGUgJ2NsaWVudF9z
ZWNyZXRfand0JyBtZXRob2QgYWxsb3dzIHRoZSBjbGllbnQgdG8gbmV2ZXIgc2VuZCB0aGUgc2hh
cmVkIHNlY3JldCBhY3Jvc3MgdGhlIHdpcmUgYXMgaXMgY3JlYXRlZCBpbiB0aGUgZGVmYXVsdCBP
QXV0aDIgSFRUUCBCYXNpYyBBdXRoZW50aWNhdGlvbiBtZXRob2QuPG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhhbmtzLDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkdlb3JnZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9uIDExLzI4LzE4IDExOjAz
IEFNLCBGaWxpcCBTa29rYW4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+SGkgR2Vvcmdl
LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiMy
IGRvZXNuJ3Qgc2VlbSBjb25maWRlbnRpYWwsIGl0J3Mgc3RpbGwgYSBzZWNyZXQgc2hhcmVkIGFt
b25nc3QgaW5zdGFsbGF0aW9ucyBhbmQgYW55b25lIHJldmVyc2UgZW5naW5lZXJpbmcgdGhlIGFw
aywgZXh0cmFjdGluZyB0aGUgc2VjcmV0LCBjYW4gZm9ybSB0aGUgY2xpZW50X3NlY3JldF9qd3Qg
Y2xpZW50X2Fzc2VydGlvbiB3aXRoIGl0IGp1c3QgZmluZS48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5CZXN0LDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPkZpbGlwPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+T24gV2VkLCBOb3YgMjgsIDIwMTggYXQgNDo0OCBQTSBHZW9yZ2UgRmxldGNoZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5nZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+PGEgaHJlZj0i
bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDttYWls
dG86NDBhb2wuY29tQGRtYXJjLmlldGYub3JnJmd0OzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPkluIGFkZGl0aW9uLCBhIGZldyBhZGRpdGlvbmFsIHBhdHRlcm5zIGFyZSBl
bmFibGVkLi4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+MS4gVGhlIG5hdGl2ZSBhcHAgY2FuIGdlbmVyYXRlIGEgcHVibGljL3ByaXZhdGUga2V5
IHBhaXIgYW5kIHRoZW4gdXNlIHByaXZhdGVfc2VjcmV0X2p3dCBhcyB0aGUgY2xpZW50IGNyZWRl
bnRpYWwgdmFsaWRhdGlvbiBtZXRob2QgdmlhIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdyAo
ZGVmaW5lZCBpbiBPcGVuSUQgQ29ubmVjdCkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+Mi4gTWF5YmUgbW9yZSBzaW1wbHksIGlmIHRoZSBuYXRp
dmUgYXBwIGlzIGlzc3VlZCBhIHNoYXJlZCBzZWNyZXQsIHRoZSBhcHAgY2FuIHVzZSBjbGllbnRf
c2VjcmV0X2p3dCBtZXRob2QgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiB3aGljaCBlbnN1cmVz
IHRoZSBzaGFyZWQgc2VjcmV0IG5ldmVyIGxlYXZlcyB0aGUgZGV2aWNlLiAoQWdhaW4gZGVmaW5l
ZCBpbiB0aGUgT3BlbklEIENvbm5lY3Qgc3BlYykuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+My4gT25jZSB0aGUgbmF0aXZlIGFwcCBpbnN0YW5j
ZSBoYXMgY3JlZGVudGlhbHMsIHRoZXkgY2FuIGJlIHVzZWQgZm9yIGFkZGl0aW9uYWwgc2VjdXJp
bmcgb2YgYXBwIEFQSSB0cmFuc2FjdGlvbnMgaW4gYWRkaXRpb24gdG8ganVzdCB0aGUgT0F1dGgy
L09wZW5JRCBDb25uZWN0IGZsb3dzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5HZW9yZ2U8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PbiAxMS8yNy8xOCAzOjI4IFBNLCBXaWxsaWFtIERlbm5p
c3Mgd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgdGhlIHNlY3JldCBpcyBkeW5hbWlj
YWxseSBwcm92aXNpb25lZCB0aGVuIHlvdSBoYXZlIGEgY29uZmlkZW50aWFsIGNsaWVudC4gQW55
b25lIHJldmVyc2UgZW5naW5lZXJpbmcgdGhlaXIgb3duIGluc3RhbGxhdGlvbiBvZiB0aGUgbmF0
aXZlIGFwcCB3b3VsZCBvbmx5IGV4dHJhY3QgdGhlaXIgb3duIGNsaWVudCdzIGNyZWRlbnRpYWxz
LCBhcyBvcHBvc2VkIHRvIHRoZSBzaGFyZWQgc2VjcmV0IG9mIGFsbCBpbnN0YWxsYXRpb25zLiBI
YXZpbmcgYSBjb25maWRlbnRpYWwgY2xpZW50IG1lYW5zIHRoYXQgcmVxdWVzdHMgdG8gdGhlIHRv
a2VuIGVuZHBvaW50IChjb2RlLCByZWZyZXNoKSBhcmUgY2xpZW50IGF1dGhlbnRpY2F0ZWQsIHNv
IFBLQ0Ugd291bGRuJ3QgYmUgbmVlZGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9uIFR1ZSwgTm92IDI3LCAyMDE4IGF0IDE6NDQgQU0sIENo
cmlzdGlhbiBNYWlua2EgJmx0OzxhIGhyZWY9Im1haWx0bzpDaHJpc3RpYW4uTWFpbmthPTQwcnVi
LmRlQGRtYXJjLmlldGYuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdGlhbi5NYWlua2E9NDBy
dWIuZGVAZG1hcmMuaWV0Zi4ub3JnPC9hPjxhIGhyZWY9Im1haWx0bzpDaHJpc3RpYW4uTWFpbmth
PTQwcnViLmRlQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O21haWx0bzpDaHJp
c3RpYW4uTWFpbmthPTQwcnViLmRlQGRtYXJjLmlldGYub3JnJmd0OzwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhpLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPndlIGp1c3Qgc3R1bWJsZWQgdXBvbiB0aGlzIFsxXSBzdGF0
ZW1lbnQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7RXhjZXB0IHdoZW4gdXNpbmcgYSBt
ZWNoYW5pc20gbGlrZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb248bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgW1JGQzc1OTFdIHRvIHByb3Zpc2lvbiBwZXItaW5zdGFuY2Ug
c2VjcmV0cywgbmF0aXZlIGFwcHMgYXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IGNsYXNzaWZpZWQgYXMgcHVibGljIGNsaWVudHMgLi4uJnF1b3Q7PG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2hhdCBkb2VzIHRoaXMgbWVh
biBmb3IgdXM/IE5hdGl2ZSBBcHAgJiM0MzsgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uID08
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Db25maWRlbnRpYWwgQ2xpZW50PzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPldoaWNoIHRocmVhdHMgYXJlIGNvdmVyZWQgaWYgRHluYW1pYyBDbGllbnQgUmVn
aXN0cmF0aW9uIGlzIHVzZWQgb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5OYXRpdmUgQXBwcz88
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5CZXN0
IFJlZ2FyZHMsPG86cD48L286cD48L3ByZT4NCjxwcmU+VmxhZGkvQ2hyaXN0aWFuPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+WzFdOiA8YSBocmVm
PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODI1MiNzZWN0aW9uLTguNCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MjUyI3NlY3Rpb24tOC40
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
Pi0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RHIuLUluZy4gQ2hyaXN0aWFuIE1haW5rYTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkhvcnN0IEfDtnJ0eiBJbnN0aXR1dGUgZm9yIElULVNlY3VyaXR5
PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hhaXIgZm9yIE5ldHdvcmsgYW5kIERhdGEgU2VjdXJp
dHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SdWhyLVVuaXZlcnNpdHkgQm9jaHVtLCBHZXJtYW55
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VW5p
dmVyc2l0w6R0c3N0ci4gMTUwLCBJRCAyLzQ2MzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkQtNDQ4
MDEgQm9jaHVtLCBHZXJtYW55PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+VGVsZWZvbjogJiM0Mzs0OSAoMCkgMjM0IC8gMzItMjY3OTY8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5GYXg6ICYjNDM7NDkgKDApIDIzNCAvIDMyLTE0MzQ3PG86cD48L286
cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL25kcy5ydWIuZGUvY2hhaXIvcGVvcGxlL2Nt
YWlua2EvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25kcy5ydWIuZGUvY2hhaXIvcGVvcGxlL2Nt
YWlua2EvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkBDaGVhcmlYPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5PQXV0aEBpZXRmLm9yZzwvYT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj4mbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDttYWlsdG86
T0F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48
L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8L2E+PG86cD48
L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0
Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4mbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0OzwvYT48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48
YSBocmVmPSJodHRwczovL3d3dy4uaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy
Z2V0PSJfYmxhbmsiPiZsdDtodHRwczovL3d3dy4uaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aCZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHBy
ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRyLi1JbmcuIENo
cmlzdGlhbiBNYWlua2E8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ib3JzdCBHw7ZydHogSW5zdGl0
dXRlIGZvciBJVC1TZWN1cml0eSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DaGFpciBmb3IgTmV0
d29yayBhbmQgRGF0YSBTZWN1cml0eSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SdWhyLVVuaXZl
cnNpdHkgQm9jaHVtLCBHZXJtYW55PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+VW5pdmVyc2l0w6R0c3N0ci4gMTUwLCBJRCAyLzQ2MzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkQtNDQ4MDEgQm9jaHVtLCBHZXJtYW55PG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGVsZWZvbjogJiM0Mzs0OSAoMCkg
MjM0IC8gMzItMjY3OTY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5GYXg6ICYjNDM7NDkgKDApIDIz
NCAvIDMyLTE0MzQ3PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL25kcy5y
dWIuZGUvY2hhaXIvcGVvcGxlL2NtYWlua2EvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25kcy5y
dWIuZGUvY2hhaXIvcGVvcGxlL2NtYWlua2EvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkBD
aGVhcmlYPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_E02ADBF5DC7E4BBC8346D9D3A53B9FE1amazoncom_--


From nobody Thu Nov 29 16:22:12 2018
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 1F49412D4F0 for ; Thu, 29 Nov 2018 16:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.961
X-Spam-Level: 
X-Spam-Status: No, score=-15.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 D-v5Mqq4VCIh for ; Thu, 29 Nov 2018 16:22:08 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902A112D4E7 for ; Thu, 29 Nov 2018 16:22:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1543537328; x=1575073328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3Hy51B/TMrnvjdue0T9rlz90WKKPY6lLbX6qU412qR4=; b=ThJdOjuJ/gkO6mgk69Lu4AjkdyNgmpbA50ttLn7w0l8dYtmkEZERaKr2 eAiP3qlzZCRE5QlRZKAVfa8iXTR0WfPQp1oKJFiVMiuJU6wu0jeUXYXyM 8aiwZUtIih80IsLii31Z+AnIa5CLjAx3Y1gWOYaCYabBsc6IdyO5kOu31 8=;
X-IronPort-AV: E=Sophos;i="5.56,253,1539648000"; d="scan'208";a="773247672"
Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  30 Nov 2018 00:22:05 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id wAU0Lx0e104623 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Nov 2018 00:22:04 GMT
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 00:22:04 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 30 Nov 2018 00:22:04 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 30 Nov 2018 00:22:03 +0000
From: "Richard Backman, Annabelle" 
To: Neil Madden 
CC: Daniel Fett , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Binding Access Tokens is not enough!
Thread-Index: AQHUgnGyRzIZ9vJFBUG3HfeCInd9AKVdYxUAgAN2XYCAAOragIAAHa6AgAOXIoCAAOHvAIAAn2SA
Date: Fri, 30 Nov 2018 00:22:03 +0000
Message-ID: 
References:   <15ECD17C-C2E3-487B-B61D-E67E5A060DE4@lodderstedt.net>  <584108B8-3293-48D4-9FD6-86DCF6CC34A3@forgerock.com> <21B0104D-F7B7-4F94-AC55-A7172037A669@amazon.com> <0CB2E55D-231D-4783-89FD-9216F902595A@forgerock.com>
In-Reply-To: <0CB2E55D-231D-4783-89FD-9216F902595A@forgerock.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.175]
Content-Type: text/plain; charset="utf-8"
Content-ID: <24AF6F34FF26534591224C5FB73863B5@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [OAUTH-WG] Binding Access Tokens is not enough!
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Nov 2018 00:22:11 -0000

U3VyZS4gQnV0IGdpdmVuIHRoYXQgVExTIHRva2VuIGJpbmRpbmcgaXMgb2Z0ZW4gcHV0IGZvcnRo
IGFzIGEgbWl0aWdhdGlvbiBhZ2FpbnN0IHRva2VuIHRoZWZ0IGFuZCByZXBsYXksIGl0J3Mgd29y
dGggbm90aW5nIHRoYXQgb24gaXRzIG93biBpdCBkb2VzIG5vdCBhZGRyZXNzIHRoaXMgcmlzayB3
aGVuIHRoZSByZXBsYXkgaXMgY29taW5nIGZyb20gdGhlIHNhbWUgYnJvd3NlciwgYW5kIHRoZSBS
UyBuZWVkcyB0byBzdXBwb3J0IENPUlMuDQoNCi0tIA0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21h
bg0KQVdTIElkZW50aXR5DQogDQoNCu+7v09uIDExLzI4LzE4LCAxMDo1MSBQTSwgIk5laWwgTWFk
ZGVuIiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQoNCiAgICBNeSBpbnRlbnQg
d2FzbuKAmXQgdG8gc3VnZ2VzdCB0aGF0IHRva2VucyAqbXVzdCogYmUgb3JpZ2luIGNvbnN0cmFp
bmVkLCBqdXN0IHRvIHBvaW50IG91dCBpZiB5b3UgYXJlIHVzaW5nIFRMUy1iYXNlZCBzZW5kZXIg
Y29uc3RyYWluZWQgdG9rZW5zIHRoZW4geW91IG1heSBhbHNvIHdhbnQgdG8gY29uc2lkZXIgdGhh
dCBhc3BlY3QuIA0KICAgIA0KICAgIEluIHNvbWUgY2FzZXMgeW91IG1heSBiZSBjb21mb3J0YWJs
ZSB0aGF0IHByb3RlY3Rpb25zIGFnYWluc3QgaW4tYnJvd3NlciB0b2tlbiB0aGVmdCBhcmUgYWRl
cXVhdGUgd2l0aG91dCBhbnkgc2VuZGVyL29yaWdpbiBjb25zdHJhaW50LiBTb21ldGltZXMgYSBw
bGFpbiBvbGQgYmVhcmVyIHRva2VuIGlzIGZpbmUuIA0KICAgIA0KICAgIOKAlCBOZWlsDQogICAg
DQogICAgPiBPbiAyOSBOb3YgMjAxOCwgYXQgMDE6MjIsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl
bGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gSW4gc29tZSBj
YXNlcywgdGhlIHJlc291cmNlIHNlcnZlciB3aWxsIG5lZWQgdG8gc3VwcG9ydCBDT1JTIGluIG9y
ZGVyIHRvIHN1cHBvcnQgU1BBIGNsaWVudHMgdGhhdCBhcmUgb24gZGlmZmVyZW50IG9yaWdpbnMu
IEluIHRoaXMgY2FzZSwgdGhlIHJlc291cmNlIHNlcnZlciBtdXN0IG9wdGltaXN0aWNhbGx5IGFs
bG93IHRoZSBDT1JTIHJlcXVlc3QgdG8gYmUgbWFkZSwgdGhlbiB2YWxpZGF0ZSB0aGF0IHRoZSBy
ZXF1ZXN0IG9yaWdpbiBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGFjY2VzcyB0b2tlbiBwcm92aWRl
ZCBpbiB0aGUgcmVxdWVzdC4gVG8gbXkga25vd2xlZGdlLCBJIGhhdmVuJ3Qgc2VlbiAib3JpZ2lu
LWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMiIHJhaXNlZCBhcyBhIHJlcXVpcmVtZW50IGFueXdo
ZXJlLCBidXQgaGVyZSB3ZSBhcmUuDQogICAgPiANCiAgICA+IC0tIA0KICAgID4gQW5uYWJlbGxl
IFJpY2hhcmQgQmFja21hbg0KICAgID4gQVdTIElkZW50aXR5DQogICAgPiANCiAgICA+IA0KICAg
ID4gT24gMTEvMjYvMTgsIDI6MzQgQU0sICJPQXV0aCBvbiBiZWhhbGYgb2YgTmVpbCBNYWRkZW4i
IDxvYXV0aC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuZWlsLm1hZGRlbkBmb3JnZXJv
Y2suY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gICAgSSB3b3VsZCBwZXJoYXBzIGNsYXJpZnkg
dGhpcyBhIGxpdHRsZSwgYXMgaXTigJlzIG5vdCByZWFsbHkgQ09SUyB0aGF0IGlzIGRvaW5nIHRo
ZSB3b3JrIGhlcmUsIGJ1dCByYXRoZXIgdGhlIHNhbWUtb3JpZ2luIHBvbGljeSAoU09QKSDigJQg
d2hpY2ggaXMgYWN0dWFsbHkgKnJlbGF4ZWQqIGJ5IENPUlMuIA0KICAgID4gDQogICAgPiAgICBJ
dCBpcyB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgbm9uLXNhZmUgaGVhZGVyIChBdXRob3JpemF0
aW9uKSBvbiB0aGUgcmVxdWVzdCB0aGF0IHRyaWdnZXJzIHRoZSBTT1AgcHJvdGVjdGlvbnMgLSBh
bmQgaXQgd291bGQgZG8gc28gZXZlbiBpbiBhbiBvbGQgcHJlLUNPUlMgYnJvd3Nlci4gT3RoZXJ3
aXNlIENPUlMgd291bGRu4oCZdCBldmVuIGJlIGludm9sdmVkIGFzIHRoZSByZXF1ZXN0IHdvdWxk
IGJlIGNvbnNpZGVyZWQg4oCcc2FmZeKAnS4gRm9yIGluc3RhbmNlLCBpZiB5b3VyIChSUykgQVBJ
IGp1c3QgcmVxdWlyZXMgYW4geC13d3ctZm9ybS11cmxlbmNvZGVkIFBPU1QgYm9keSB3aXRoIHRo
ZSBhY2Nlc3MgdG9rZW4gYXMgb25lIG9mIHRoZSBmaWVsZHMgdGhlbiBJIGNhbiBhbHdheXMganVz
dCBjcmVhdGUgYSBmb3JtIGluIGEgaGlkZGVuIGlmcmFtZSBhbmQgc3VibWl0IGl0IGNyb3NzLW9y
aWdpbiB3aXRoIG5vIHByb2JsZW1zLCBDT1JTIG9yIG5vdC4gQWRkaW5nIHRoZSBBdXRob3JpemF0
aW9uIGhlYWRlciBwcmV2ZW50cyB0aGF0IC0geW91IGNhbuKAmXQgYWRkIGEgY3VzdG9tIGhlYWRl
ciB0byBhIGZvcm0gc3VibWlzc2lvbiwgYW5kIEFqYXggd291bGQgbm90IGJlIGFsbG93ZWQgdG8g
bWFrZSB0aGF0IHJlcXVlc3QuDQogICAgPiANCiAgICA+ICAgIFdoYXQgQ09SUyBjaGFuZ2VzIGlz
IHRoYXQgdGhpbmdzIHRoYXQgd291bGQgcHJldmlvdXNseSBiZSBibG9ja2VkIG91dHJpZ2h0IG5v
dyBwcm9kdWNlIGEgQ09SUyBwcmVmbGlnaHQgdG8gYWxsb3cgdGhlIGRlc3RpbmF0aW9uIG9yaWdp
biB0byBvdmVycmlkZSB0aGUgU09QIGFuZCBhbGxvdyBhIHJlcXVlc3QgdG8gZ28gYWhlYWQgYW55
d2F5Lg0KICAgID4gDQogICAgPiAgICDigJQgTmVpbA0KICAgID4gDQogICAgPj4gT24gMjYgTm92
IDIwMTgsIGF0IDA4OjQ2LCBEYW5pZWwgRmV0dCA8ZGFuaWVsZitvYXV0aEB5ZXMuY29tPiB3cm90
ZToNCiAgICA+PiANCiAgICA+PiBZZXMuIFRva2VuIEJpbmRpbmcgZW5mb3JjZXMgdGhhdCBvbmx5
IHRoZSByaWdodCBicm93c2VyIGNhbiBzZW5kIHRoZSB0b2tlbjsgaW4gdGhpcyBicm93c2VyLCBD
T1JTIGVuZm9yY2VzIHRoYXQgb25seSB0aGUgY29ycmVjdCBvcmlnaW4gY2FuIHNlbmQgdGhlIHRv
a2VuLg0KICAgID4+IA0KICAgID4+PiBBbSAyNS4xMS4xOCB1bSAxOTo0NiBzY2hyaWViIFRvcnN0
ZW4gTG9kZGVyc3RlZHQ6DQogICAgPj4+IERvZXMgdGhpcyBtZWFuIHRoZSBSUyBlZmZlY3RpdmVs
eSByZWxpZXMgb24gdGhlIHVzZXIgYWdlbnQgdG8gZW5mb3JjZSB0aGUgc2VuZGVyIGNvbnN0cmFp
bnQgKHZpYSBDT1JTIHBvbGljeSk/DQogICAgPj4+IA0KICAgID4+PiANCiAgICA+Pj4+IEFtIDIz
LjExLjIwMTggdW0gMTQ6NTQgc2NocmllYiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vy
b2NrLmNvbT4NCiAgICA+Pj4+IDoNCiAgICA+Pj4+IA0KICAgID4+Pj4gVGhhbmtzIGZvciBkb2lu
ZyB0aGlzIERhbmllbCwgSSB0aGluayB0aGUgcHJvcG9zZWQgdGV4dCBpcyBnb29kLg0KICAgID4+
Pj4gDQogICAgPj4+PiDigJQgTmVpbA0KICAgID4+Pj4gDQogICAgPj4+PiANCiAgICA+Pj4+PiBP
biAyMiBOb3YgMjAxOCwgYXQgMTQ6NDIsIERhbmllbCBGZXR0IDxkYW5pZWxmK29hdXRoQHllcy5j
b20+DQogICAgPj4+Pj4gd3JvdGU6DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gSGkgYWxsLA0KICAg
ID4+Pj4+IA0KICAgID4+Pj4+IEkgd291bGQgbGlrZSB0byBkaXNjdXNzIGEgdGV4dCBwcm9wb3Nh
bCBmb3IgdGhlIHNlY3VyaXR5IEJDUC4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBCYWNrZ3JvdW5k
Og0KICAgID4+Pj4+IA0KICAgID4+Pj4+IFllc3RlcmRheSwgTmVpbCBwb2ludGVkIG91dCB0aGUg
Zm9sbG93aW5nIHByb2JsZW0gd2l0aCBiaW5kaW5nIGFjY2VzcyB0b2tlbnMgdXNpbmcgbVRMUyBv
ciB0b2tlbiBiaW5kaW5nIGluIFNQQXM6DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gIkkgYW0gdGFs
a2luZyBhYm91dCBzY3JpcHRzIGZyb20gcGxhY2VzIGxpa2UgYWQgc2VydmVycyB0aGF0IGFyZSB1
c3VhbGx5IGluY2x1ZGVkIHZpYSBhbiBpZnJhbWUgdG8gZW5mb3JjZSB0aGUgU09QIGFuZCBzYW5k
Ym94IHRoZW0gZnJvbSBvdGhlciBzY3JpcHRzLiBJZiB0aGV5IGdldCBhY2Nlc3MgdG8gYW4gYWNj
ZXNzIHRva2VuIC0gZS5nLiB2aWEgZG9jdW1lbnQucmVmZXJyZXIgb3IgYSByZWRpcmVjdCBvciBz
b21lIG90aGVyIGxlYWssIHRoZW4gdGhleSBzdGlsbCBhY3Qgd2l0aGluIHRoZSBzYW1lIFRMUyBj
b250ZXh0IGFzIHRoZSBsZWdpdGltYXRlIGNsaWVudC4iDQogICAgPj4+Pj4gDQogICAgPj4+Pj4g
VGhlIHByb2JsZW0gaXMgdGhhdCBhIGJyb3dzZXIncyBUTFMgc3RhY2sgd2lsbCBhdHRhY2ggdGhl
IHByb29mIG9mIHBvc3Nlc3Npb24gbm8gbWF0dGVyIHdoaWNoIG9yaWdpbiBzdGFydGVkIGEgcmVx
dWVzdC4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiAoVGhpcyBzZWVtcyBsaWtlIGEgcmVhbCBkb3du
c2lkZSBvZiB0b2tlbiBiaW5kaW5nIC0gd2h5IGRvZXMgaXQgbm90IGhhdmUgdGhlICJzYW1lIHNp
dGUiIG9wdGlvbiB0aGF0IGNvb2tpZXMgbm93YWRheXMgaGF2ZT8pDQogICAgPj4+Pj4gDQogICAg
Pj4+Pj4gSSBwcmVwYXJlZCB0aGUgZm9sbG93aW5nIGFkZGl0aW9uIHRvIHRoZSBzZWN1cml0eSBC
Q1AgYW5kIHdvdWxkIGxpa2UgdG8gaGVhciB5b3VyIG9waW5pb25zOg0KICAgID4+Pj4+IA0KICAg
ID4+Pj4+ICJJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IGNvbnN0cmFpbmluZyB0aGUgc2Vu
ZGVyIG9mIGEgdG9rZW4gdG8gYSB3ZWIgYnJvd3NlciAodXNpbmcgYSBUTFMtYmFzZWQgbWV0aG9k
KSBkb2VzIG5vdCBjb25zdHJhaW4gdGhlIG9yaWdpbiBvZiB0aGUgc2NyaXB0IHRoYXQgdXNlcyB0
aGUgdG9rZW4gKGxhY2sgb2Ygb3JpZ2luIGJpbmRpbmcpLiBJbiBvdGhlciB3b3JkcywgaWYgYWNj
ZXNzIHRva2VucyBhcmUgdXNlZCBpbiBhIGJyb3dzZXIgKGFzIGluIGEgc2luZ2xlLXBhZ2UgYXBw
bGljYXRpb24sIFNQQSkgYW5kIHRoZSBhY2Nlc3MgdG9rZW5zIGFyZSBzZW5kZXItY29uc3RyYWlu
ZWQgdXNpbmcgYSBUTFMtYmFzZWQgbWV0aG9kLCBpdCBtdXN0IGJlIGVuc3VyZWQgdGhhdCBvcmln
aW5zIG90aGVyIHRoYW4gdGhlIG9yaWdpbiBvZiB0aGUgU1BBIGNhbm5vdCBtaXN1c2UgdGhlIFRM
Uy1iYXNlZCBzZW5kZXIgYXV0aGVudGljYXRpb24uDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gVGhl
IHByb2JsZW0gY2FuIGJlIGlsbHVzdHJhdGVkIHVzaW5nIGFuIFNQQSBvbiBvcmlnaW4gQSB0aGF0
IHVzZXMgYW4gYWNjZXNzIHRva2VuIEFUIHRoYXQgaXMgYm91bmQgdG8gdGhlIFRMUyBjb25uZWN0
aW9uIGJldHdlZW4gdGhlIGJyb3dzZXIgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXIgUi4gSWYgQVQg
bGVha3MgdG8gYW4gYXR0YWNrZXIgRSwgYW5kIHRoZXJlIGlzLCBmb3IgZXhhbXBsZSwgYW4gaWZy
YW1lIGZyb20gRSdzIG9yaWdpbiBsb2FkZWQgaW4gdGhlIHdlYiBicm93c2VyLCB0aGF0IGlmcmFt
ZSBjYW4gc2VuZCBhIHJlcXVlc3QgdG8gb3JpZ2luIFIgdXNpbmcgdGhlIGFjY2VzcyB0b2tlbiBB
VC4gVGhpcyByZXF1ZXN0IHdpbGwgY29udGFpbiB0aGUgcHJvb2Ytb2YtcG9zZXNzaW9uIG9mIHRo
ZSAobVRMUyBvciB0b2tlbiBiaW5kaW5nKSBrZXkuIFRoZSByZXNvdXJjZSBzZXJ2ZXIgUiB0aGVy
ZWZvcmUgY2Fubm90IGRpc3Rpbmd1aXNoIGlmIGEgcmVxdWVzdCBjb250YWluaW5nIGEgdmFsaWQg
YWNjZXNzIHRva2VuIG9yaWdpbmF0ZXMgZnJvbSBvcmlnaW4gQSBvciBvcmlnaW4gRS4NCiAgICA+
Pj4+PiANCiAgICA+Pj4+PiBJZiB0aGUgcmVzb3VyY2Ugc2VydmVyIG9ubHkgYWNjZXB0cyB0aGUg
YWNjZXNzIHRva2VuIGluIGFuIEF1dGhvcml6YXRpb24gaGVhZGVyLCB0aGVuIENyb3NzLU9yaWdp
biBSZXNvdXJjZSBTaGFyaW5nIChDT1JTKSB3aWxsIHByb3RlY3QgYWdhaW5zdCB0aGlzIGF0dGFj
ayBieSBkZWZhdWx0LiBJZiB0aGUgcmVzb3VyY2Ugc2VydmVyIGFjY2VwdHMgdGhlIGFjY2VzcyB0
b2tlbnMgaW4gb3RoZXIgd2F5cyAoZS5nLiwgYXMgYSBVUkwgcGFyYW1ldGVyKSwgb3IgaWYgdGhl
IENPUlMgcG9saWN5IG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcGVybWl0cyByZXF1ZXN0cyBieSBv
cmlnaW4gRSwgdGhlbiB0aGUgVExTLWJhc2VkIHRva2VuIGJpbmRpbmcgb25seSBwcm92aWRlcyBw
cm90ZWN0aW9uIGlmIHRoZSBicm93c2VyIGlzIG9mZmxpbmUuIg0KICAgID4+Pj4+IA0KICAgID4+
Pj4+IA0KICAgID4+Pj4+IFRoZSAic3VtbWFyeSIgYWJvdmUgdGhpcyB0ZXh0IHJlYWRzIGFzIGZv
bGxvd3M6DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gIklmIGFjY2VzcyB0b2tlbnMgYXJlIHNlbmRl
ci1jb25zdHJhaW5lZCB0byBhIHdlYiBicm93c2VyLCB0aGUgcmVzb3VyY2Ugc2VydmVyIE1VU1Qg
ZW5zdXJlIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiBjYW4gb25seSBiZSB1c2VkIGJ5IHRoZSBvcmln
aW4gdG8gd2hpY2ggdGhlIGFjY2VzcyB0b2tlbiB3YXMgaXNzdWVkIChvcmlnaW4gYmluZGluZyku
IE9uZSBzb2x1dGlvbiBmb3IgdGhlIHJlc291cmNlIHNlcnZlciB0byBhY2NvbXBsaXNoIHRoaXMg
aXMgdG8gb25seSBhY2NlcHQgdGhlIGFjY2VzcyB0b2tlbiBpbiBhbiBBdXRob3JpemF0aW9uIGhl
YWRlciAoYXMgZGVzY3JpYmVkIGluIFJGQyA2NzUwKSBhbmQgdG8gZW5zdXJlIHRoYXQgdGhlIGFj
dGl2ZSBDT1JTIHBvbGljeSBwcmV2ZW50cyB0aGlyZCBwYXJ0aWVzIGZyb20gc2VuZGluZyBBdXRo
b3JpemF0aW9uIGhlYWRlcnMuIFNlZSA8eHJlZiB0YXJnZXQ9InBvcF90b2tlbnMiLz4gZm9yIGRl
dGFpbHMuIg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IFdoYXQgZG8geW91IHRoaW5rPw0KICAgID4+
Pj4+IA0KICAgID4+Pj4+IC1EYW5pZWwNCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4+IE9BdXRoIG1h
aWxpbmcgbGlzdA0KICAgID4+Pj4+IA0KICAgID4+Pj4+IE9BdXRoQGlldGYub3JnDQogICAgPj4+
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4+Pj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+
IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4+Pj4gDQogICAgPj4+PiBPQXV0aEBpZXRmLm9yZw0K
ICAgID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAg
ID4+IA0KICAgID4+IA0KICAgID4gDQogICAgPiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgT0F1dGggbWFpbGluZyBsaXN0DQogICAg
PiAgICBPQXV0aEBpZXRmLm9yZw0KICAgID4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0KICAgID4gDQogICAgPiANCiAgICANCg0K


From nobody Thu Nov 29 21:03:50 2018
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 22013126CB6 for ; Thu, 29 Nov 2018 21:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level: 
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzb2Vg6jgqdo for ; Thu, 29 Nov 2018 21:03:45 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465CE126C7E for ; Thu, 29 Nov 2018 21:03:45 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id v1-v6so3854944ljd.0 for ; Thu, 29 Nov 2018 21:03:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HX1kAoEy4A4HDx+h/iSgFc42aahxgJCYcAj05mfxHdA=; b=fpkQyrOxaIkYJLZijhhm3O8Wn9e3m1XyW/L22db++W4MtgFbovY6FcBOJyBlxctxIl Q18lFAVj46FfG2a21Jj6jc7MyCxiepGy5bGBMG0TOMcJz155TEIaihV42uJCQHCM22Ad mVDF48qywBIJb2VFzuTBvTGjwf+WeVUDvXkZY=
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=HX1kAoEy4A4HDx+h/iSgFc42aahxgJCYcAj05mfxHdA=; b=f/nGBhFopDcWDCEEodsXJso1C3ZnbdyUu1YuYdeXrDNOzoPDnVcWMFDuevJ1av2prn PbNW1e8ZAgmio0Xl8A9s0MThOywTYnqY1VZ4Pg2z0/VKKZYYBXJgqOIVmFl9RTDq111o QuYCktTlTIR/3ZONp8qmKJezCiL2mw3zhPj3QuRGICh4HClPaWUDPF2an6R73rm2f9kL 5PfUv//A76lcdKFEqNRnPAocldWyy9yIpq5moow4uOjAT8Qeq1NNGwPf1Cb4/9goB2sw QbdrsNnFNgRSNyecKMbYR+60GRq7UaPvKLJoLJy6c3LZFGu+ePolo9piwkfbTZHz5MR6 LLfQ==
X-Gm-Message-State: AA+aEWak02w9DcgF02DfM1wwBKJfwxAsyJMTzdJDerighTHVkiyiebxK Xz6LjT59IiiGu/Xpfzji3sjjwaY60yd+vJ6WWcC1t1hTwoA=
X-Google-Smtp-Source: AFSGD/WsmG8+UTBQ2FPyd87dP+fc9O6Yg3189IsrO+9orPEabn6nqF3gTNNKVyEsPrkbiR/w/M+3A5VHaEToRCF5W5w=
X-Received: by 2002:a2e:88cf:: with SMTP id a15-v6mr2768794ljk.76.1543554223296;  Thu, 29 Nov 2018 21:03:43 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>    
In-Reply-To: 
From: Dave Tonge 
Date: Fri, 30 Nov 2018 06:03:30 +0100
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth , fett@danielfett.de
Content-Type: multipart/alternative; boundary="0000000000002be467057bdab945"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 30 Nov 2018 05:03:49 -0000

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

+1

On Thu, 29 Nov 2018 at 19:06, Torsten Lodderstedt 
wrote:

> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished th=
e
> text. That=E2=80=99s our proposal:
>
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access
> tokens in the authorization response, such as "token id_token" and "code
> token id_token=E2=80=9C,
> unless the issued access tokens are sender-constrained and access token
> injection in
> the authorization response is prevented.
> =E2=80=94
>
> Explantation:
> - we wanted to have the right balance between a generic definition of the
> response types we do not recommend/allow to be used and a
> concrete/actionable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supporte=
d
> by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten.
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley :
> >
> > I am ok with that.
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
> torsten@lodderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (on=
ly). It would
> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender constr=
ained. This
> completely ignores the fact implicit also shall be abandoned because of i=
ts
> vulnerability for access token injection.
> >
> > I therefore propose a modified text:
> >
> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant. Furthermore, clients SHOULD only use other response types
> causing the authorization server to
> >    issue an access token in the authorization response, if the
> particular response type detects access token
> >    injection and the issued access tokens are sender-constrained.
> >
> > Or we just state:
> >
> >   In order to avoid these issues, Clients SHOULD NOT use the response
> type =E2=80=9Etoken". The response types
> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the
> issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probably is too
> much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but give
> implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> > >
> > >
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> > >
> > > PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> > > If you are not an intended recipient, please notify the sender and
> delete this e-mail.
> > >
> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > > =E5=AE=9B=E5=85=88: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend=
 authorization
> code instead of implicit
> > >
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns access token
> from the authorization endpoint ( some people confuses implicit as the fl=
ow
> that returns ID Token in the front channel)
> > >
> > > That=E2=80=99s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response, if this acces=
s
> tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> > >>
> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Ha=
rdt 
> =E3=81=AE=E4=BB=A3=E7=90=86)
> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> > >> Cc: oauth@ietf.org
> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization
> code instead of implicit
> > >>
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of the issues o=
f
> implicit, I don't think we can recommend specifics, and there may be futu=
re
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone?
> > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to the conclusio=
n
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM are =
in
> an early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
> ).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> Ciao
> > >>
> > >> Hannes & Rifaat
> > >>
> > >>
> > >>
> > >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--=20
Dave Tonge

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


    +1

    On Thu, 29 Nov 2018 at 19:06, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi all, 
    

    
based on your feedback on the list and off list, Daniel and I polished the =
text. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing =
access 
    
tokens in the authorization response, such as "token id_token" an=
d "code token id_token=E2=80=9C, 
    
unless the issued access tokens are sender-constrained and access token inj=
ection in 
    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionabl=
e list of the affected response types. 
    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported =
by William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.=C2=A0 
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr=
ote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token 
    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig;     oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick =
Hardt <dick.ha=
rdt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth=
@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a=
rm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this reason, and since CORS allows br=
owser-based apps to send requests to the token endpoint, Torsten suggested =
to use the authorization code instead of the implicit grant in call cases i=
n his presentation (see https://datatracker.ietf.org/meeting/103/=
materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<=
br>
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy the i=
nformation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> > 
    
> 
    
> _______________________________________________
    
> 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
    



    -- 
    Dave Tonge

    

--0000000000002be467057bdab945--


From nobody Thu Nov 29 23:23:16 2018
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 41484130E74 for ; Thu, 29 Nov 2018 23:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.958
X-Spam-Level: 
X-Spam-Status: No, score=-18.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XIDvDjadLFw for ; Thu, 29 Nov 2018 23:23:10 -0800 (PST)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0: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 D0BF712F1A2 for ; Thu, 29 Nov 2018 23:23:09 -0800 (PST)
Received: by mail-it1-x132.google.com with SMTP id g85so7808954ita.3 for ; Thu, 29 Nov 2018 23:23:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DMmChKojkP2BkqoHywZIZ0xkLd2XdAbE5VIlwd0ELDc=; b=quOiL1168bM+XCm65i+CNGcBIc5yJB9veEkvpwkB94Gsrb/oTnsjqx6THXa0PLY8co 1wmvr6oO2esW09IK6OXRD2J+o+wz+MI/Bz8aR6WzPGkEYegxnYFlVVgMjT2kwmLn/4uz FCZCqdUH1FLCGcOj+JbGs8a2KGy5ARRAJltbS263KYUjAY7Oz+GoBgbZR3BgxzVT1Dq5 avBUiaIDONN0JV6pXvfPzERXas3RLXC3bkRs9LfMDGIYyG5njqATpjdxOydsYoYYdCu4 3qGpj7Ojbl2AZXysu4n9i0Ywo/ytARQwpTYRz/tNMLGQAQyHL2oWs2wFUPrC9UsRiLXP cNkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DMmChKojkP2BkqoHywZIZ0xkLd2XdAbE5VIlwd0ELDc=; b=VT+CHi4DjIzuCP13DB/CCqGrsUpXtlOlZRRpfp/H6FRHpjw3/Amu/+1/TOFaSo37QM lVOqYVPtnIL85dR29en+LRIIVOZ+Q2mEBx8N17QGcXw1gEVEBAcqkVLj3yn9u4FmKWCv QwNx8MHK/428KknMaktLQJMmoHPyXCxoxYjC1VAr99/pZKLP9OGoJfVb3n0vdmCncu9i vSL6WVeCMYIO+xqYW0B0mBO8MLaREYZ1ijnrn7aBJxv+fJtD99v87xnEkpLSg4UI4VRU lknUsAn2XrnR5sVYbj05tflKF/jlX662Ghjc3CsA5c3TXFAT96+Y5YbOqiWSTyDOAf/V X70Q==
X-Gm-Message-State: AA+aEWZVY3GUgm9yRGzYqho9QgPk9Pk4GVQTqc79T5tohb+8pK0JBNk+ bKOnrUtD5pHKMUZgDzc4P6O1vgH0BmRFcXJbTqReyw==
X-Google-Smtp-Source: AFSGD/Xe6d2e1dkzv2+2yJNlK7YxMcGSEovKlOk5xPIPf+Beb8ZqxPyzzNBKEbQFc+z0qX/VzpG56Fpdu06bGgiyII0=
X-Received: by 2002:a24:6254:: with SMTP id d81mr4686662itc.162.1543562588674;  Thu, 29 Nov 2018 23:23:08 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a6b:5102:0:0:0:0:0 with HTTP; Thu, 29 Nov 2018 23:22:47 -0800 (PST)
In-Reply-To: 
References:   <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com>     <065bba73-eade-2f07-038f-8afa708e38be@rub.de>  
From: William Denniss 
Date: Thu, 29 Nov 2018 23:22:47 -0800
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Christian Mainka , oauth 
Content-Type: multipart/alternative; boundary="000000000000c9d777057bdcab70"
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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, 30 Nov 2018 07:23:15 -0000

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

On Thu, Nov 29, 2018 at 4:17 PM, Richard Backman, Annabelle <
richanna=3D40amazon.com@dmarc.ietf.org> wrote:

> > Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide
> some identity guarantees=E2=80=A6
>
>
>
> Yes, provided that the AS can verify that the claimed URI is a valid URI
> for the identity being asserted by the client. And this identity guarante=
e
> would apply to an public native app client just as well as one that has
> established a client secret via dynamic client registration.
>

I agree.



>
>
> Section 2.3 of RFC6749 
> is relevant here:
>
>
>
> The authorization server MAY establish a client authentication method
>
> with public clients.  However, the authorization server MUST NOT rely
>
> on public client authentication for the purpose of identifying the
>
> client.
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of William Denniss
> 
> *Date: *Thursday, November 29, 2018 at 10:49 AM
> *To: *Christian Mainka 
>
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>
>
>
>
>
> On Thu, Nov 29, 2018 at 6:03 AM Christian Mainka  40rub.de@dmarc.ietf.org> wrote:
>
> Hi,
>
> thanks for pointing this out!
> This was exactly what confused us during reading *-* the main threat we
> see and which is not addressed is related to the app impersonation attack=
.
> Even PKCE does not help against the app impersonation attack.
>
>
>
> Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide
> some identity guarantees (security considerations in Sec 8.6), as the OS
> will only open apps that can verify domain ownership to process the
> redirect. This is what I would recommend as a starting point if you want
> assurances over the app's identity.
>
>
>
> A spoofing app can still use a web-view to intercept the response that
> way, but in that case they'd also have full access to the session cookie
> (due to the use of webview for the sign-in), which is potentially a more
> valuable token (i.e. you have bigger issues). It does effectively prevent
> against tokens issued form the browser SSO session being intercepted by t=
he
> wrong app.
>
>
>
>
>
>
> So a "Native App + Dynamic Client Registration" can be seen at a differen=
t
> "confidentiality level" than a "public client", because every native App
> can dynamically register itself on the IdP.
> The IdP cannot distinguish, for example, an honest native client from an
> malicious client starting an app impersonation attack.
>
> We agree that, e.g., a leaked code cannot be redeemed unless you have the
> respective client_id/client_secret.
>
> But... we asked ourselfs, in which cases does a code leak?
>
> 1) In the front-channel. In this case, it is true that no client
> credentials leak and an attacker cannot redeem the code.
>
> 2) In the back-channel. But if this channel is insecure, you directly get
> client credentials (unless client_secret_jwt is used as pointed out by
> George).
>
> So, Dynamic Client Registration only helps if the code leaks alone (as in
> 1.), or if it leaks on different levels (e.g. logfiles).
>
> On the opposite site, if Dynamic Registration is available, an attacker
> can very easily do an app impersonation attack by registering on the IdP.
> To be clear, it is not "impersonation" as in the "one secret per software=
"
> scenario, because different client_id and client_secret is used, but to t=
he
> best of my knowledge, the IdP cannot distinguish between an honest app an=
d
> an app impersonation client that has simply registered.
>
> In addition, if the IdP supports the dynamic client registration:
>
> How can the IdP distinguish between confidential and public/native client=
s?
> With respect to the consent page, which must be shown every time for
> native apps, this is an important issue, which should be addressed proper=
ly.
>
> Best Regards
> Vladi/Christian
>
>
>
> Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle:
>
> It should be noted that =E2=80=9Ctraditional=E2=80=9D confidential client=
s with registered return URLs and server-side secrets may provide a higher =
degree of confidence in the true identity of the client that doesn=E2=80=99=
t carry over to confidential native app clients. A native app instance=E2=
=80=99s registration call is necessarily unauthenticated (for the same reas=
ons that statically registered native app clients are public clients), so t=
he Client Impersonation concerns described in section 8.6 of RFC8252  still apply.
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> From: OAuth   on behalf o=
f Filip Skokan  
>
> Date: Wednesday, November 28, 2018 at 9:11 AM
>
> To: George Fletcher  
>
> Cc: oauth  
>
> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>
>
>
> Apologies, I missed the issued in "issued a shared secret", just reading =
"shared secret" alone is the exact opposite of a per-instance secret. The r=
est is clear and as you say it brings the benefit of the secret never being=
 sent over the wire (except during the initial registration via TLS).
>
>
>
> Best,
>
> Filip
>
>
>
>
>
> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher  > wrote:
>
> It's "confidential" in that the shared secret is unique to that app insta=
nce registration (as Dennis described in his response). If an attacker gets=
 my phone and compromises the data stored on my device, they only get the s=
ecret for my device. This is no different than a server side client having =
their client secret compromised through an attack (and in some ways is bett=
er because it's instance specific).
>
>
>
> The main point I was trying to make, is that the 'client_secret_jwt' meth=
od allows the client to never send the shared secret across the wire as is =
created in the default OAuth2 HTTP Basic Authentication method.
>
>
>
> Thanks,
>
> George
>
> On 11/28/18 11:03 AM, Filip Skokan wrote:
>
> Hi George,
>
>
>
> #2 doesn't seem confidential, it's still a secret shared amongst installa=
tions and anyone reverse engineering the apk, extracting the secret, can fo=
rm the client_secret_jwt client_assertion with it just fine.
>
>
>
> Best,
>
> Filip
>
>
>
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher  <40aol.com@dmarc.ietf.org>> wr=
ote:
>
> In addition, a few additional patterns are enabled...
>
>
>
> 1. The native app can generate a public/private key pair and then use pri=
vate_secret_jwt as the client credential validation method via the client c=
redentials flow (defined in OpenID Connect).
>
>
>
> 2. Maybe more simply, if the native app is issued a shared secret, the ap=
p can use client_secret_jwt method for client authentication which ensures =
the shared secret never leaves the device. (Again defined in the OpenID Con=
nect spec).
>
>
>
> 3. Once the native app instance has credentials, they can be used for add=
itional securing of app API transactions in addition to just the OAuth2/Ope=
nID Connect flows.
>
>
>
> Thanks,
>
> George
>
> On 11/27/18 3:28 PM, William Denniss wrote:
>
> If the secret is dynamically provisioned then you have a confidential cli=
ent. Anyone reverse engineering their own installation of the native app wo=
uld only extract their own client's credentials, as opposed to the shared s=
ecret of all installations. Having a confidential client means that request=
s to the token endpoint (code, refresh) are client authenticated, so PKCE w=
ouldn't be needed.
>
>
>
> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka  > wrote:
>
> Hi,
>
>
>
> we just stumbled upon this [1] statement:
>
> "Except when using a mechanism like Dynamic Client Registration
>
>    [RFC7591] to provision per-instance secrets, native apps are
>
>    classified as public clients ..."
>
>
>
> What does this mean for us? Native App + Dynamic Client Registration =3D
>
> Confidential Client?
>
> Which threats are covered if Dynamic Client Registration is used on
>
> Native Apps?
>
>
>
> Best Regards,
>
> Vladi/Christian
>
>
>
> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>
>
>
> --
>
> Dr.-Ing. Christian Mainka
>
> Horst G=C3=B6rtz Institute for IT-Security
>
> Chair for Network and Data Security
>
> Ruhr-University Bochum, Germany 
>
>
>
> Universit=C3=A4tsstr. 150 , ID 2/463
>
> D-44801 Bochum, Germany
>
>
>
> Telefon: +49 (0) 234 / 32-26796
>
> Fax: +49 (0) 234 / 32-14347
>
> http://nds.rub.de/chair/people/cmainka/
>
> @CheariX
>
>
>
>
>
> _______________________________________________
>
> 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
>
> --
>
> Dr.-Ing. Christian Mainka
>
> Horst G=C3=B6rtz Institute for IT-Security
>
> Chair for Network and Data Security
>
> Ruhr-University Bochum, Germany 
>
>
>
> Universit=C3=A4tsstr. 150 , ID 2/463
>
> D-44801 Bochum, Germany
>
>
>
> Telefon: +49 (0) 234 / 32-26796
>
> Fax: +49 (0) 234 / 32-14347
>
> http://nds.rub.de/chair/people/cmainka/
>
> @CheariX
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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




    On Thu, Nov 29, 2018 at 4:17 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:<=
br>
    






    

    

    > Claimed "https" scheme URIs (RFC 8252=
, Sec 7.2) can be used to provide some identity guarantees=E2=80=A6<=
u>
    

    =C2=A0
    

    Yes, provided that the AS can verify that the claime=
d URI is a valid URI for the identity being asserted by the client. And thi=
s identity guarantee would apply to an public native app client just as wel=
l as one that has established a client
 secret via dynamic client registration.
    <=
br>
    I agree.

    =C2=A0
    

    =C2=A0
    

    Section 2.3 of RFC6749 is relevant here:
    

    =C2=A0
    

    The authorization server MAY establish a client =
authentication method
    

    with public clients.=C2=A0 However, the authoriz=
ation server MUST NOT rely
    

    on public client authentication for the purpose =
of identifying the
    

    client.
    

    =C2=A0
    

    

    --=C2=A0
    

    Annabelle Richard Backman

    AWS Identity
    

    

    =C2=A0
    

    =C2=A0
    

    

    From=
: OAuth <oauth-bounces@ietf.org=
> on behalf of William Denniss <wdenniss=3D40google.com@dmarc.ietf.org=
>
    
Date: Thursday, November 29, 2018 at 10:49 AM
    
To: Christian Mainka <Christian.Mainka=3D40rub.de@dmarc.ietf.org>

    
Cc: oauth <oa=
uth@ietf.org>
    
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps=

    

    

    

    =C2=A0
    

    

    

    

    

    =C2=A0<=
/p>

    

    

    On Thu, Nov 29, 2018 at 6:03 AM Christian Mainka <=
;Christian.Mainka=3D40rub.de@dmarc.ietf.org> wrote:
    

    

    

    

    

    Hi,
    

    
thanks for pointing this out!
    
This was exactly what confused us during reading - the main threat w=
e see and which is not addressed is related to the app impersonation attack=
.
    
Even PKCE does not help against the app impersonation attack.=

    

    

    

    

    

    =C2=A0
    

    

    

    Claimed "https" scheme URIs (RFC 8252, Sec=
 7.2) can be used to provide some identity guarantees (security considerati=
ons in Sec 8.6), as the OS will only open apps that can verify domain owner=
ship to process the redirect. This is what I
 would recommend as a starting point if you want assurances over the app=
9;s identity.
    

    

    

    =C2=A0
    

    

    

    A spoofing app can still use a web-view to intercept=
 the response that way, but in that case they'd also have full access t=
o the session cookie (due to the use of webview for the sign-in), which is =
potentially a more valuable token (i.e.
 you have bigger issues). It does effectively prevent against tokens issued=
 form the browser SSO session being intercepted by the wrong app.=

    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

    


    
So a "Native App + Dynamic Client Registration" can be seen at a =
different "confidentiality level" than a "public client"=
;, because every native App can dynamically register itself on the IdP.
    
The IdP cannot distinguish, for example, an honest native client from an ma=
licious client starting an app impersonation attack.
    

    
We agree that, e.g., a leaked code cannot be redeemed unless you have the r=
espective client_id/client_secret.
    

    
But... we asked ourselfs, in which cases does a code leak?
    

    
1) In the front-channel. In this case, it is true that no client credential=
s leak and an attacker cannot redeem the code.
    

    
2) In the back-channel. But if this channel is insecure, you directly get c=
lient credentials (unless client_secret_jwt is used as pointed out by Georg=
e).
    

    
So, Dynamic Client Registration only helps if the code leaks alone (as in 1=
.), or if it leaks on different levels (e.g. logfiles).
    

    
On the opposite site, if Dynamic Registration is available, an attacker can=
 very easily do an app impersonation attack by registering on the IdP. To b=
e clear, it is not "impersonation" as in the "one secret per=
 software" scenario, because different client_id
 and client_secret is used, but to the best of my knowledge, the IdP cannot=
 distinguish between an honest app and an app impersonation client that has=
 simply registered.
    

    
In addition, if the IdP supports the dynamic client registration:=

    

    

    

    How can the IdP distinguish between confidential and=
 public/native clients?
    
With respect to the consent page, which must be shown every time for native=
 apps, this is an important issue, which should be addressed properly.
    

    
Best Regards
    
Vladi/Christian 
    

    

    

    =C2=A0
    

    

    

    Am 29.11.18 um 00:38 schrieb Richard Backman, Annabe=
lle:
    

    

    

    It should be noted that =E2=80=9Ctraditional=E2=80=9D confidential cli=
ents with registered return URLs and server-side secrets may provide a high=
er degree of confidence in the true identity of the client that doesn=E2=80=
=99t carry over to confidential native app clients. A native app instance=
=E2=80=99s registration call is necessarily unauthenticated (for the same r=
easons that statically registered native app clients are public clients), s=
o the Client Impersonation concerns described in section 8.6 of RFC8252&=
lt;https://tools.ietf.org/html/rfc8252#section-8.6> still apply=
.
    

    --
    

    Annabelle Richard Backman
    

    AWS Identity
    

    =C2=A0
    

    =C2=A0
    

    From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com><=
u>
    

    Date: Wednesday, November 28, 2018 at 9:11 AM
    

    To: George Fletcher <gffletch@aol.com>
    

    Cc: oauth <oaut=
h@ietf.org>
    

    Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
    

    =C2=A0
    

    Apologies, I missed the issued in "issued a shared secret", =
just reading "shared secret" alone is the exact opposite of a per=
-instance secret. The rest is clear and as you say it brings the benefit of=
 the secret never being sent over the wire (except during the initial regis=
tration via TLS).
    

    =C2=A0
    

    Best,
    

    Filip
    

    =C2=A0
    

    =C2=A0
    

    On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffletch@aol.com<mailto:gffletch@aol.com>=
> wrote:
    

    It's "confidential" in that the shared secret is unique =
to that app instance registration (as Dennis described in his response). If=
 an attacker gets my phone and compromises the data stored on my device, th=
ey only get the secret for my device. This is no different than a server si=
de client having their client secret compromised through an attack (and in =
some ways is better because it's instance specific).

    =C2=A0
    

    The main point I was trying to make, is that the 'client_secret_jw=
t' method allows the client to never send the shared secret across the =
wire as is created in the default OAuth2 HTTP Basic Authentication method.<=
u>
    

    =C2=A0
    

    Thanks,
    

    George
    

    On 11/28/18 11:03 AM, Filip Skokan wrote:
    

    Hi George,
    

    =C2=A0
    

    #2 doesn't seem confidential, it's still a secret shared among=
st installations and anyone reverse engineering the apk, extracting the sec=
ret, can form the client_secret_jwt client_assertion with it just fine.<=
/u>
    

    =C2=A0
    

    Best,
    

    Filip
    

    =C2=A0
    

    On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=3D40aol.com=
@dmarc.ietf.org<mailto:40aol.com@dmarc.ietf.org>> wrote:<=
/u>
    

    In addition, a few additional patterns are enabled...

    =C2=A0
    

    1. The native app can generate a public/private key pair and then use =
private_secret_jwt as the client credential validation method via the clien=
t credentials flow (defined in OpenID Connect).
    

    =C2=A0
    

    2. Maybe more simply, if the native app is issued a shared secret, the=
 app can use client_secret_jwt method for client authentication which ensur=
es the shared secret never leaves the device. (Again defined in the OpenID =
Connect spec).
    

    =C2=A0
    

    3. Once the native app instance has credentials, they can be used for =
additional securing of app API transactions in addition to just the OAuth2/=
OpenID Connect flows.
    

    =C2=A0
    

    Thanks,
    

    George
    

    On 11/27/18 3:28 PM, William Denniss wrote:
    

    If the secret is dynamically provisioned then you have a confidential =
client. Anyone reverse engineering their own installation of the native app=
 would only extract their own client's credentials, as opposed to the s=
hared secret of all installations. Having a confidential client means that =
requests to the token endpoint (code, refresh) are client authenticated, so=
 PKCE wouldn't be needed.
    

    =C2=A0
    

    On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.=
Mainka=3D40rub.de@dmarc.ietf..org<mailto:Christian.Ma=
inka=3D40rub.de@dmarc.ietf.org>> wrote:
    

    Hi,
    

    =C2=A0
    

    we just stumbled upon this [1] statement:
    

    "Except when using a mechanism like Dynamic Client Registration
    

    =C2=A0=C2=A0 [RFC7591] to provision per-instance secrets, native apps =
are
    

    =C2=A0=C2=A0 classified as public clients ..."

    =C2=A0
    

    What does this mean for us? Native App + Dynamic Client Registration =
=3D
    

    Confidential Client?
    

    Which threats are covered if Dynamic Client Registration is used on=

    

    Native Apps?
    

    =C2=A0
    

    Best Regards,
    

    Vladi/Christian
    

    =C2=A0
    

    [1]: https://tools.ietf.org/html/rfc8252#section-8.4
    

    =C2=A0
    

    --
    

    Dr.-Ing. Christian Mainka
    

    Horst G=C3=B6rtz Institute for IT-Security
    

    Chair for Network and Data Security
    

    Ruhr-University Bochum, Germany
    

    =C2=A0
    

    Universit=C3=A4=
tsstr. 150, ID 2/463
    

    D-44801 Bochum, Germany
    

    =C2=A0
    

    Telefon: +49 (0) 234 / 32-26796
    

    Fax: +49 (0) 234 / 32-14347
    

    =
http://nds.rub.de/chair/people/cmainka/
    

    @CheariX
    

    =C2=A0
    

    =C2=A0
    

    _______________________________________________

    OAuth mailing list
    

    OAuth@ietf.org=
<mailto:OAuth@i=
etf.org>
    

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

    =C2=A0
    

    =C2=A0
    

    =C2=A0
    

    =C2=A0
    

    _______________________________________________

    =C2=A0
    

    OAuth mailing list
    

    =C2=A0
    

    OAuth@ietf.org=
<mailto:OAuth@i=
etf.org>
    

    =C2=A0
    

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

    =C2=A0
    

    _______________________________________________

    OAuth mailing list
    

    OAuth@ietf.org=
<mailto:OAuth@i=
etf.org>
    

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

    =C2=A0
    

    =C2=A0
    

    =C2=A0
    

    _______________________________________________

    =C2=A0
    

    OAuth mailing list
    

    =C2=A0
    

    OAuth@ietf.org=
<mailto:OAuth@i=
etf.org>
    

    =C2=A0
    

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

    =C2=A0
    


    

    

    

    _______________________________________________

    OAuth mailing list
    

    OAuth@ietf.org=

    

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

    

    -- 
    

    Dr.-Ing. Christian Mainka
    

    Horst G=C3=B6rtz Institute for IT-Security 
    

    Chair for Network and Data Security 
    

    Ruhr-University Bochum, Germany
    

    =C2=A0
    

    Universit=C3=A4=
tsstr. 150, ID 2/463
    

    D-44801 Bochum, Germany
    

    =C2=A0
    

    Telefon: +49 (0) 234 / 32-26796
    

    Fax: +49 (0) 234 / 32-14347
    

    =
http://nds.rub.de/chair/people/cmainka/
    

    @CheariX
    

    

    _______________________________________________=

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

    

    

    

    

    

    

    



    

--000000000000c9d777057bdcab70--


From nobody Fri Nov 30 00:27:00 2018
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 DB3D1130934 for ; Fri, 30 Nov 2018 00:26:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 WBZ4qLkMWE_P for ; Fri, 30 Nov 2018 00:26:56 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBF112F1A2 for ; Fri, 30 Nov 2018 00:26:55 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id v6so4363896wrr.12 for ; Fri, 30 Nov 2018 00:26:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zAo8eSujJe0nAhPk62MrOu1TYEM7mr5uG4mZrCEoUcE=; b=LuPVxX4LnJ/07o2OZ1P8b9XGirngN1uFQgHWa7h8x5oXxd7iX/ajZLVK8BvROwthJL zFXyuMWCiRZPH4+EhA7nek1qPYQF2edJSEAWOWMAkUrCTyw6QJSo1bjchq8qIBuloYHg kQ98352aqGsOUTP51igDj6z8kxBWUstLYHCJM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zAo8eSujJe0nAhPk62MrOu1TYEM7mr5uG4mZrCEoUcE=; b=oLAka/+s8A2aqcgB2hMSB0MiILL8Gf8NpMzV4FI7AWEz1llaKcRfQmRQ9d3fFE5Vmg Qb9XrIDL2Wd1ZJphAkJ29Q/jOtHKUulYTx52vfobKiRKteduFESqZvJLTQt5l2cBz3Kv J0cNwJqNsldIDqQlpfEI/NyyGiETUo+dqE60+p9yiz8QOCalSNgq90UtFOZqjmAaNswc ywlwDLpNRci9/DNpWAFHSf9mmftFEaf7m4M+pcSflSE2xLOht51xukQmxB7573lVJ7Er pZYfnSig16lFnQvM7BKWmEmXCia4DZE8sUgJ/EkVo87OSEqIJEfvaSNMnvNVbPpcubR+ 92FQ==
X-Gm-Message-State: AA+aEWaFgQXZgyFnrms4bQTlumrYgFBrCnbwGSon1nz9nowrxQYmrWoh B+ge6SYMtSlRmn11W56yNGlk8iPkhV47l9Q6gr6UVo8PbP8O0ACOlEPuouwzdFxKAkDjfUE3883 wXLdd4gM+MT+rAR5mF/T8g8WEncV1Wakgm4j2fsrHI5IqS4Uky/u/oDFxuUqwLPg=
X-Google-Smtp-Source: AFSGD/WjfCyTwpiJgvq8d6ZG9JeDkDK++3pBdi7eILThgLnBmM8MZ07Yno9VAHbDx2h3RHVTa7SB7Q==
X-Received: by 2002:adf:f691:: with SMTP id v17mr3928134wrp.114.1543566413678;  Fri, 30 Nov 2018 00:26:53 -0800 (PST)
Received: from ?IPv6:2a01:4c8:c:5949:601e:f94b:ee1c:c567? ([2a01:4c8:c:5949:601e:f94b:ee1c:c567]) by smtp.gmail.com with ESMTPSA id x15sm3733749wrs.27.2018.11.30.00.26.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 00:26:52 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Neil Madden 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: 
Date: Fri, 30 Nov 2018 08:26:51 +0000
Cc: IETF oauth WG , Daniel Fett 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>    
To: Torsten Lodderstedt 
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 30 Nov 2018 08:26:59 -0000

+1 from me too.=20

> On 29 Nov 2018, at 18:06, Torsten Lodderstedt  wr=
ote:
>=20
> Hi all,=20
>=20
> based on your feedback on the list and off list, Daniel and I polished the=
 text. That=E2=80=99s our proposal:
>=20
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access=20=

> tokens in the authorization response, such as "token id_token" and "code t=
oken id_token=E2=80=9C,=20
> unless the issued access tokens are sender-constrained and access token in=
jection in=20
> the authorization response is prevented.=20
> =E2=80=94
>=20
> Explantation:=20
> - we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionable=
 list of the affected response types.=20
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported=
 by William
>=20
> We look forward to seeing your feedback.
>=20
> kind regards,
> Torsten. =20
>=20
>> Am 29.11.2018 um 15:15 schrieb John Bradley :
>>=20
>> I am ok with that. =20
>>=20
>>>> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt >>=20
>>> Am 28.11.2018 um 23:50 schrieb n-sakimura :
>>>=20
>>> That works.
>>=20
>> Good!
>>=20
>> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (only=
). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would send=
er constrained. This completely ignores the fact implicit also shall be aban=
doned because of its vulnerability for access token injection.=20
>>=20
>> I therefore propose a modified text:=20
>>=20
>>   In order to avoid these issues, Clients SHOULD NOT use the implicit
>>   grant. Furthermore, clients SHOULD only use other response types causin=
g the authorization server to
>>   issue an access token in the authorization response, if the particular r=
esponse type detects access token=20
>>   injection and the issued access tokens are sender-constrained.
>>=20
>> Or we just state:
>>=20
>>  In order to avoid these issues, Clients SHOULD NOT use the response type=
 =E2=80=9Etoken". The response types
>> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=9C=
 SOULD NOT be used, if the issued access tokens are not=20
>> sender-constrained.
>>=20
>>>=20
>>> In fact, I would further go and say MUST NOT but that probably is too mu=
ch for a security consideration.
>>>=20
>>=20
>> Mike suggested to go with a SHOULD NOT to get the message out but give im=
plementors time to move/change.
>>=20
>>> Best,
>>>=20
>>> Nat
>>>=20
>>> Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>>>=20
>>> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81=
=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=
=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=
=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=80=
=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84=E5=
=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3=81=97=E8=A8=B3=
=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=
=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=
=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=
=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=
=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=
=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=
=E3=80=82
>>>=20
>>> PLEASE READ :This e-mail is confidential and intended for the named reci=
pient only.
>>> If you are not an intended recipient, please notify the sender and delet=
e this e-mail.
>>>=20
>>> =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
>>> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=E6=
=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
>>> =E5=AE=9B=E5=85=88: n-sakimura
>>> Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
>>> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend au=
thorization code instead of implicit
>>>=20
>>> Hi Nat,=20
>>>=20
>>>> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>>>>=20
>>>> I would support
>>>>=20
>>>> 1) clearly defining Implicit as the flow that returns access token from=
 the authorization endpoint ( some people confuses implicit as the flow that=
 returns ID Token in the front channel)
>>>=20
>>> That=E2=80=99s the current text:=20
>>>=20
>>> In order to avoid these issues, Clients SHOULD NOT use the implicit
>>>   grant or any other response type causing the authorization server to
>>>   issue an access token in the authorization response.
>>>=20
>>> What would you like to modify?=20
>>>=20
>>>>=20
>>>> 2) Banning the returning of the access token that are not sender constr=
ained from the authorization endpoint
>>>=20
>>> In order to avoid these issues, Clients SHOULD NOT use the implicit
>>>   grant or any other response type causing the authorization server to
>>>   issue an access token in the authorization response, if this access to=
kens is not sender-constraint.
>>>=20
>>> What about this?
>>>=20
>>> kind regards,
>>> Torsten.
>>>=20
>>>>=20
>>>> Best,
>>>>=20
>>>> Nat
>>>>=20
>>>>=20
>>>> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>>>>=20
>>>> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Hardt=
  =E3=81=AE=E4=BB=A3=E7=90=86)
>>>> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=E6=
=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>>>> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>>>> Cc: oauth@ietf.org
>>>> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend a=
uthorization code instead of implicit
>>>>=20
>>>> +1
>>>>=20
>>>> While there are various mechanisms to alleviate some of the issues of i=
mplicit, I don't think we can recommend specifics, and there may be future o=
nes in the future. I think we all agree that implicit without any mitigation=
 is problematic.=20
>>>>=20
>>>> How about we recommend against using implicit alone?=20
>>>>=20
>>>>=20
>>>> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig  wrote:
>>>> Hi all,
>>>>=20
>>>> The authors of the OAuth Security Topics draft came to the conclusion t=
hat it is not possible to adequately secure the implicit flow against token i=
njection since potential solutions like token binding or JARM are in an earl=
y stage of adoption. For this reason, and since CORS allows browser-based ap=
ps to send requests to the token endpoint, Torsten suggested to use the auth=
orization code instead of the implicit grant in call cases in his presentati=
on (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-=
sessb-draft-ietf-oauth-security-topics-01).
>>>>=20
>>>> A hum in the room at IETF#103 concluded strong support for his recommen=
dations. We would like to confirm the discussion on the list.
>>>>=20
>>>> Please provide a response by December 3rd.
>>>>=20
>>>> Ciao
>>>>=20
>>>> Hannes & Rifaat
>>>>=20
>>>>=20
>>>>=20
>>>> IMPORTANT NOTICE: The contents of this email and any attachments are co=
nfidential and may also be privileged. If you are not the intended recipient=
, please notify the sender immediately and do not disclose the contents to a=
ny other person, use it for any purpose, or store or copy the information in=
 any medium. Thank you.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Fri Nov 30 11:45:05 2018
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 6FD7E130F96 for ; Fri, 30 Nov 2018 11:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=curity-io.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 hAyNBSnGramw for ; Fri, 30 Nov 2018 11:45:01 -0800 (PST)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E461130F81 for ; Fri, 30 Nov 2018 11:45:00 -0800 (PST)
Received: by mail-ot1-x32a.google.com with SMTP id n8so2317846otl.6 for ; Fri, 30 Nov 2018 11:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nLVyF4J3emTnLZ7ShNjN91gCLr3OIRN4S5Lg53rI1RI=; b=Z8YZI46DZA5SeO1+u8pn33dAIcp1NIl40HsEJwyFFPBA5iXl/3wVZY1DTKAdeugRDg RmRHMK28uhSiJWGqn2GBnLKwJ2IId8AyryhcMWFNYE5xYxtyqGLGWmRHrsLCCN55ocZ9 NXdIghVrIvonTLf6crwqNlZqelUiZPrylcf570aPqQkjhgp41WeaWveLFhorI+L5szkJ xZGq91cNf0mHOA5kygZvPC1teTk/li65rezsy6asue0mmBSMZbj89DDiCiUlLdwvvivd W5INcc1eeXBNmw1062CQlTTXmcKx7x++VCRddjTt4TXfrPmF/K/cEQm8637XwNH/qckN fw/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nLVyF4J3emTnLZ7ShNjN91gCLr3OIRN4S5Lg53rI1RI=; b=htEOASgxHlo8Nki8hT52eGdBAn7AudPEiUM6LIWfG4K00V8ryNHSKFgNMWYTLkRFej qDBZiQIoVIGHxt89mAyIXeukDHvbtELzETbEVWwXx6DUOtrKEl5N3wdUJa4WRjjSLVaz 8XMHnUWFJyGHU3a5+v9mL7Ltm3E6pFQ/0RlPIyAb9IT6QBJ28ddEWYqKGpKaKU2flBOI GKqeP/rRZIAOZ4FV9CiTnmuc2reqNVhbCibFmW4k7rNM0jQXB9zHl3fqdgipdabnNcD6 KYKd1oIfIewOTai95gcyYiTj8E13k3UP2kN1PHugd1X2q3SOLIduNROMXpW8ciwqqLjQ wZqQ==
X-Gm-Message-State: AA+aEWbDeRsR7F7n6xXoqrCIngfOtUixXDxuSYO+AMYVx7jEF8tdZd/0 2ryFVNh2Ozq+F8Qy9zWmfVD03g3RUqkZnmhDBBgEOQ==
X-Google-Smtp-Source: AFSGD/UPppjT3AAAoxYk1JhZoDODPJiJUGLwHDWsaAURw3CSxRPWUmi/wWgIlR1sQ3vLlg86DIfrXo0rr6MzmLfE05o=
X-Received: by 2002:a9d:60b:: with SMTP id 11mr4155996otn.200.1543607100324; Fri, 30 Nov 2018 11:45:00 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Travis Spencer 
Date: Fri, 30 Nov 2018 20:44:48 +0100
Message-ID: 
To: panva.ip@gmail.com
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000e34da9057be70858"
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Client Registration - client_secret_expires_at
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, 30 Nov 2018 19:45:03 -0000

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

On Tue, Nov 20, 2018 at 12:45 PM Filip Skokan  wrote:

> This is my best shot at an implementable policy when it comes to clients
> with expired client secrets: *"all operations requiring a secret will be
> rejected when an expired one is presented"*
>

This is a good list and hopefully something that would find its way into a
spec and not be buried in an email archive. With this info, its a lot
easier to make use of this feature of the spec. Thanks for sharing it,
Filip.

it is not valid for client secret based endpoint auth (basic, post, client
> secret jwt), the AS will reject with 401 invalid_client in those cases
>

Or instead of invalid_client, need_info.

it will not be used for validating symmetrically signed request object
> (JAR), the AS will reject the authorization request with ...?
>

400 invalid_request_object

it will not be used by the AS to symmetrically sign id tokens, userinfo,
> introspection or authorization responses (JARM), the AS will reject the
> requests with ...?
>

403 need_info.

In the case of introspection, a client secret can't be used to sign the JWT
if application/jwt was requested because access will be denied will be
denied before that point. So, that's 401 (first point above)

anything else?
>

Revoke -- 401

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


    On Tue, Nov 20, 2018 at 12:45 PM Filip Skokan <panva.ip@gmail.com> wrote:
    This is my best shot at an implementable policy when it=
 comes to clients with expired client secrets: "all operations requ=
iring a secret will be rejected when an expired one is presented"<=
/div>

    T=
his is a good list and hopefully something that would find its way into a s=
pec and not be buried in an email archive. With this info, its a lot easier=
 to make use of this feature of the spec. Thanks for sharing it, Filip.

    it is not valid for client secret =
based endpoint auth (basic, post, client secret jwt), the AS will reject wi=
th 401 invalid_client in those cases

    Or instead of invalid_client,=
 need_info. 

    <=
div dir=3D"ltr">
    it will not be used =
for validating symmetrically signed request object (JAR), the AS will rejec=
t the authorization request with ...?
    =C2=A0
    400 invalid_request_=
object 

    =

    it will not be used=
 by the AS to symmetrically sign id tokens, userinfo, introspection or auth=
orization responses (JARM), the AS will reject the requests with=C2=A0...?<=
br>

    403 need_info. 

    In the case of intros=
pection, a client secret can't be used to sign the JWT if application/j=
wt was requested because access will be denied will be denied before that p=
oint. So, that's 401 (first point above)

    anything =
else?
    =C2=
=A0
    Revoke -- 401
    

--000000000000e34da9057be70858--


From nobody Fri Nov 30 12:04:26 2018
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 BDFD5130F7C for ; Fri, 30 Nov 2018 12:04:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 UsgrL7omHXn9 for ; Fri, 30 Nov 2018 12:04:21 -0800 (PST)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B15B130FDF for ; Fri, 30 Nov 2018 12:03:13 -0800 (PST)
Received: by mail-it1-x134.google.com with SMTP id i7so290314iti.2 for ; Fri, 30 Nov 2018 12:03:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eL7MO0kEJfJBx/tYncMcU5qoiEr2QM21qxPnVw2BEy0=; b=knrqwdtc+LRSV7Bhr6ho9gqAtPf/EausEmJ2/k+rFH/qIbmKau2xNBJXf32N781dKp bDCCfokiVOlR14mXIM9UD4pjed/JLgV3Si/kbeLSMVtWwdrn1tKRqc/9nvW1/jim+9tZ HH5CbL8RR9PYBr+NLlRuR1hPyT36xU9rjUvsw=
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=eL7MO0kEJfJBx/tYncMcU5qoiEr2QM21qxPnVw2BEy0=; b=O+GKsIGDPY9Mdcg2W5HJPw4D5JtxCee/Vv1YJR+0yElLM0vlEMcQIWajLa4KUwpa1H iswHjG2rxCTmq/FeU7ppJ915bwN7K1YROKzseaRNhWKepC3rHlOAKVlGiDZZuJRbR8L1 nQeI+Gr+3bZg5wO4duPbTRSTpggFBImbmk50a6owiBBK2SsUTR8SfLogAjpUUYB3049+ tF8K0mml9sFBcjl0ECf4d0kVPnZjIAgldjqucDAlo+QA6CDrBonmKfnbk184mRXOuPRu YclVhYtGW+PpUQyJIHsXUyIt2PR1qxLGPmgT5BJu55Nq8FjJH5FNt+D73PsuQsLN4eLC rwnA==
X-Gm-Message-State: AA+aEWbTkWwYaFGSWmf5EBGYzop8+NnD2sIRMgpjvVzRNWAo53Oju0Ma hmRyawxJmy4u6LOlN5HYTLJ1KrcjZa+0P1uBUemOZmUxLLoRtQ/ByJ3iayILbHu3WuPuH5F/6x9 MVBBryWXvuk5fS/AbI2g=
X-Google-Smtp-Source: AFSGD/WMVtoySsCbE0df8GOzZINQGxRq9+l1GwR+1dybToTdtZB7u2Xg385m0+UmeD3eoXzaPn2Jv/Ituw3Y7BVgLuY=
X-Received: by 2002:a02:7127:: with SMTP id n39mr6369095jac.91.1543608192029;  Fri, 30 Nov 2018 12:03:12 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>    
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 30 Nov 2018 13:02:44 -0700
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth , fett@danielfett.de
Content-Type: multipart/alternative; boundary="000000000000f57610057be7497b"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 30 Nov 2018 20:04:25 -0000

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

As was pointed out to me in WGLC review of the MTLS document,
"sender-constrained" has or is likely to be interpreted with a pretty
specific meaning of the token being bound to the client and the client
authenticating itself to the resource and the resource checking all that
matches up. That makes the text more restrictive than is likely intended.
Perhaps the text should say something like "sender or key constrained" to
allow for different variants of PoP access tokens?



On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished th=
e
> text. That=E2=80=99s our proposal:
>
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access
> tokens in the authorization response, such as "token id_token" and "code
> token id_token=E2=80=9C,
> unless the issued access tokens are sender-constrained and access token
> injection in
> the authorization response is prevented.
> =E2=80=94
>
> Explantation:
> - we wanted to have the right balance between a generic definition of the
> response types we do not recommend/allow to be used and a
> concrete/actionable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supporte=
d
> by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten.
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley :
> >
> > I am ok with that.
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
> torsten@lodderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (on=
ly). It would
> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender constr=
ained. This
> completely ignores the fact implicit also shall be abandoned because of i=
ts
> vulnerability for access token injection.
> >
> > I therefore propose a modified text:
> >
> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant. Furthermore, clients SHOULD only use other response types
> causing the authorization server to
> >    issue an access token in the authorization response, if the
> particular response type detects access token
> >    injection and the issued access tokens are sender-constrained.
> >
> > Or we just state:
> >
> >   In order to avoid these issues, Clients SHOULD NOT use the response
> type =E2=80=9Etoken". The response types
> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the
> issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probably is too
> much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but give
> implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> > >
> > >
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> > >
> > > PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> > > If you are not an intended recipient, please notify the sender and
> delete this e-mail.
> > >
> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > > =E5=AE=9B=E5=85=88: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend=
 authorization
> code instead of implicit
> > >
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns access token
> from the authorization endpoint ( some people confuses implicit as the fl=
ow
> that returns ID Token in the front channel)
> > >
> > > That=E2=80=99s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response, if this acces=
s
> tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> > >>
> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Ha=
rdt 
> =E3=81=AE=E4=BB=A3=E7=90=86)
> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> > >> Cc: oauth@ietf.org
> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization
> code instead of implicit
> > >>
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of the issues o=
f
> implicit, I don't think we can recommend specifics, and there may be futu=
re
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone?
> > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to the conclusio=
n
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM are =
in
> an early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
> ).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> Ciao
> > >>
> > >> Hannes & Rifaat
> > >>
> > >>
> > >>
> > >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> 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._

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


    As was pointed out to me in WGLC review of the MTLS d=
ocument, "sender-constrained" has or is likely to be interpreted =
with a pretty specific meaning of the token being bound to the client and t=
he client authenticating itself to the resource and the resource checking a=
ll that matches up. That makes the text more restrictive than is likely int=
ended. Perhaps the text should say something like "sender or key const=
rained" to allow for different variants of PoP access tokens? 



    On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<=
br>
    Hi all, 
    

    
based on your feedback on the list and off list, Daniel and I polished the =
text. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing =
access 
    
tokens in the authorization response, such as "token id_token" an=
d "code token id_token=E2=80=9C, 
    
unless the issued access tokens are sender-constrained and access token inj=
ection in 
    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionabl=
e list of the affected response types. 
    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported =
by William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.=C2=A0 
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr=
ote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token 
    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig;     oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick =
Hardt <dick.ha=
rdt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth=
@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a=
rm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this reason, and since CORS allows br=
owser-based apps to send requests to the token endpoint, Torsten suggested =
to use the authorization code instead of the implicit grant in call cases i=
n his presentation (see https://datatracker.ietf.org/meeting/103/=
materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<=
br>
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy the i=
nformation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> > 
    
> 
    
> _______________________________________________
    
> 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
    

    


    
<=
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.
--000000000000f57610057be7497b--


From nobody Fri Nov 30 12:32:09 2018
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 79BB1130FDC for ; Fri, 30 Nov 2018 12:32:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7P2ZQv8Pdjk for ; Fri, 30 Nov 2018 12:32:05 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80075.outbound.protection.outlook.com [40.107.8.75]) (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 DA85A130EAF for ; Fri, 30 Nov 2018 12:32:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ROABytHpdNRZdIx37pmT1ld11CoCyZPq35DoHlaZSLU=; b=VD986ZT1pWmcYMwyVRRafZ2mPuhufahK6qtrEtkdZF88iY1EOOdkzjJ6R5Zic21yh3jmhuDq+yMVdf+Y1dO8C0Pw9gem4RRf1bLraFExXk3t2X5EXW1kr7J/y2F8g+Or8CwbhDs/9GACl/q7+eFwXKRtPcrJ91HBG7s4KRZroLU=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1615.eurprd08.prod.outlook.com (10.167.211.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.21; Fri, 30 Nov 2018 20:31:59 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::2056:1db1:e01:4670%3]) with mapi id 15.20.1361.019; Fri, 30 Nov 2018 20:31:59 +0000
From: Hannes Tschofenig 
To: oauth 
Thread-Topic: draft-ietf-oauth-token-exchange/audience & draft-ietf-oauth-resource-indicators
Thread-Index: AdSI6ubIseoXCzkuQPaMEIlbtbJkzQ==
Date: Fri, 30 Nov 2018 20:31:59 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [80.92.115.19]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1615; 6:u8F8SLaeyzaOEDIF276hUBDPfzHLAw4JAsQ7tybCPOCjwjb8u8FkKqUGp9K7wLQ0kdyKb9Bfdi61ceWTO5raACptt1rocFDANS0OMKt4UX8v5srFkz5Egb524R0LrgscgmM10yT9v+Z1RbnqMGWzuqLhErrvbCZqz1AqT305gvzHSWAy7IfipblGdK2NjptYFr/JxG0loZl35gcl7uMmtfduO1ZzIGEZFzKiAaB5RKBbjnL2Kk67rIrGxuP7fUGRkconoZ9H8d8xobp1aYPe6qtuc2P7aX/9KlMXGB1ztg4TOOqmIZki4NLAmBP/z2v3gm0YeuHufwr5tbMZivhCwQJ4OidhYa3pyt2HZTNVNT6442qB7x+eC2RBAxjFEDzTlV1CkTAercLDPOvwig54rUywpcRlLQCVXSahQWGl4Ev2AIgLONLWXFcODrq9WnzCORKxghvLviU3mX4tWPpqWQ==; 5:MxU9rrBmg0Jbxt/vOzCtbwlobsz+QWqewBn140KRBq+MUPRR/K9dmM1XP8Y4nJCSASq1NYMoNxQ3V4Lwa7dlv29+GTjEijb6nPweVM1jQoxailSxrSaMgIPXG2iepEWJxCaQpmesbVppvKaiTTxgNt7QFCOSEV/iP5sfRPyx194=; 7:aoXG+naxL+u1E8rzsVkosP3lFq/L+snumboBC81z9tEZDYV2pmPeYeIIh22Vw/skmFnrAJjrjBdk/x1+FLGrTIMTaZiiuW6bgoFlTaDdTZnryrizFUAI/zqYxdeka2OtOo30MHiRd2yJ9/WGsOcTWA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 96bd6a57-1dbe-44ba-51fc-08d65702e0f5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1615; 
x-ms-traffictypediagnostic: VI1PR0801MB1615:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231453)(999002)(944501468)(52105112)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1615; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1615; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(136003)(396003)(366004)(189003)(199004)(53754006)(40434004)(3846002)(7696005)(6116002)(53936002)(2906002)(99286004)(5660300001)(7736002)(74316002)(305945005)(9686003)(102836004)(6506007)(105586002)(186003)(26005)(33656002)(478600001)(66066001)(72206003)(14454004)(6916009)(6436002)(81166006)(55016002)(106356001)(81156014)(316002)(8676002)(25786009)(476003)(68736007)(97736004)(14444005)(5024004)(86362001)(8936002)(256004)(71190400001)(71200400001)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1615; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: dTgobLy5VwVqIbOrRJjwPIzi9K1yRP9olBebgchcFQ9j9TbhjagagDu/aq3Kgg4upHh3bUNKJkjn6auTTCo72u0TC1NaULsmQvuejmQu+EvPmXQxDGXG6QM/kvgBjbx+Qv9oiaM3Cu9kD1WeeMbkiwz9Te62P/zlcXGtt8W9AjrlxtHE6koe+6ksZdLovIFpMhUOjEjmVp8QEdXgFExh9encyWBwQy61mDGH7MdJqwbL53KfWpPUN4YryCag7en65WzIdr8AlrgGD/xA2cnBbUwGC3V5co6buj3Brt1+mYxPSY2+wHPEiN9yh34D1JLNqXqxn/mjuBD1telBFmsVllF7+MYxlR+f3ld5v25TGOw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96bd6a57-1dbe-44ba-51fc-08d65702e0f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 20:31:59.3777 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1615
Archived-At: 
Subject: [OAUTH-WG] draft-ietf-oauth-token-exchange/audience & draft-ietf-oauth-resource-indicators
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, 30 Nov 2018 20:32:07 -0000

Hi all,

Token exchange registers the 'resource' parameter, at least to a large exte=
nd, and draft-ietf-oauth-resource-indicators indicates this in the IANA con=
sideration section.

What isn't mentioned in draft-ietf-oauth-resource-indicators is that token =
exchange also defines the audience parameter. The audience parameter is def=
ined as

"
Audience:
      The logical name of the target service where the client
      intends to use the requested security token.  This serves a
      purpose similar to the "resource" parameter, but with the client
      providing a logical name rather than a location.
"

I am mentioning this also because draft-ietf-ace-oauth-params defines a par=
ameter 'req_aud', which was supposed to be similar to resource but at the l=
ast IETF meeting the argument was that it is a logical name. As such, it wo=
uld correspond to the audience parameter registered in the token exchange.

Is my observation correct?

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.


From nobody Fri Nov 30 12:43:04 2018
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 EB21C130FF2 for ; Fri, 30 Nov 2018 12:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Epb7biPWqeGe for ; Fri, 30 Nov 2018 12:42:57 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (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 303C1130FEC for ; Fri, 30 Nov 2018 12:42:57 -0800 (PST)
Received: from [91.13.153.47] (helo=[192.168.71.112]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gSpcj-0006Qd-5k; Fri, 30 Nov 2018 21:42:53 +0100
Content-Type: multipart/signed; boundary=Apple-Mail-AAFC2B07-F549-42C7-9D1F-08C7A56BDF95; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: 
Date: Fri, 30 Nov 2018 21:42:52 +0100
Cc: oauth , fett@danielfett.de
Content-Transfer-Encoding: 7bit
Message-Id: <558F050A-AC67-45B5-8D55-A025444539A2@lodderstedt.net>
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>     
To: Brian Campbell 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 30 Nov 2018 20:43:02 -0000

--Apple-Mail-AAFC2B07-F549-42C7-9D1F-08C7A56BDF95
Content-Type: multipart/alternative;
	boundary=Apple-Mail-70AB1637-69BF-4772-BC94-98DB594DA847
Content-Transfer-Encoding: 7bit


--Apple-Mail-70AB1637-69BF-4772-BC94-98DB594DA847
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Brian,

we use =E2=80=9Esender constrained tokens=E2=80=9C throughout the BCP to den=
ote tokens bound to a sender in possession of a certain key/secret and I tho=
ught that was established terminology in the group. Are you suggesting =E2=80=
=9Ekey constrained=E2=80=9D would be more appropriate?

kind regards,
Torsten.

> Am 30.11.2018 um 21:02 schrieb Brian Campbell =
:
>=20
> As was pointed out to me in WGLC review of the MTLS document, "sender-cons=
trained" has or is likely to be interpreted with a pretty specific meaning o=
f the token being bound to the client and the client authenticating itself t=
o the resource and the resource checking all that matches up. That makes the=
 text more restrictive than is likely intended. Perhaps the text should say s=
omething like "sender or key constrained" to allow for different variants of=
 PoP access tokens?=20
>=20
>=20
>=20
>> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt  wrote:
>> Hi all,=20
>>=20
>> based on your feedback on the list and off list, Daniel and I polished th=
e text. That=E2=80=99s our proposal:
>>=20
>> =E2=80=94
>> In order to avoid these issues, clients MUST NOT use the implicit
>> grant (response type "token") or any other response type issuing access=20=

>> tokens in the authorization response, such as "token id_token" and "code t=
oken id_token=E2=80=9C,=20
>> unless the issued access tokens are sender-constrained and access token i=
njection in=20
>> the authorization response is prevented.=20
>> =E2=80=94
>>=20
>> Explantation:=20
>> - we wanted to have the right balance between a generic definition of the=
 response types we do not recommend/allow to be used and a concrete/actionab=
le list of the affected response types.=20
>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supporte=
d by William
>>=20
>> We look forward to seeing your feedback.
>>=20
>> kind regards,
>> Torsten. =20
>>=20
>> > Am 29.11.2018 um 15:15 schrieb John Bradley :
>> >=20
>> > I am ok with that. =20
>> >=20
>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt > >=20
>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
>> > >=20
>> > > That works.
>> >=20
>> > Good!
>> >=20
>> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (on=
ly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would se=
nder constrained. This completely ignores the fact implicit also shall be ab=
andoned because of its vulnerability for access token injection.=20
>> >=20
>> > I therefore propose a modified text:=20
>> >=20
>> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
>> >    grant. Furthermore, clients SHOULD only use other response types cau=
sing the authorization server to
>> >    issue an access token in the authorization response, if the particul=
ar response type detects access token=20
>> >    injection and the issued access tokens are sender-constrained.
>> >=20
>> > Or we just state:
>> >=20
>> >   In order to avoid these issues, Clients SHOULD NOT use the response t=
ype =E2=80=9Etoken". The response types
>> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the issued access tokens are not=20
>> > sender-constrained.
>> >=20
>> > >=20
>> > > In fact, I would further go and say MUST NOT but that probably is too=
 much for a security consideration.
>> > >=20
>> >=20
>> > Mike suggested to go with a SHOULD NOT to get the message out but give i=
mplementors time to move/change.
>> >=20
>> > > Best,
>> > >=20
>> > > Nat
>> > >=20
>> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>> > >=20
>> > > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=
=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=
=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=82=
=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=
=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84=
=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3=81=97=E8=A8=
=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=
=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=
=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=
=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=
=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=
=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=
=99=E3=80=82
>> > >=20
>> > > PLEASE READ :This e-mail is confidential and intended for the named r=
ecipient only.
>> > > If you are not an intended recipient, please notify the sender and de=
lete this e-mail.
>> > > =20
>> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
>> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
>> > > =E5=AE=9B=E5=85=88: n-sakimura
>> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
>> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend=
 authorization code instead of implicit
>> > > =20
>> > > Hi Nat,=20
>> > >=20
>> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>> > >>=20
>> > >> I would support
>> > >>=20
>> > >> 1) clearly defining Implicit as the flow that returns access token f=
rom the authorization endpoint ( some people confuses implicit as the flow t=
hat returns ID Token in the front channel)
>> > >=20
>> > > That=E2=80=99s the current text:=20
>> > >=20
>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>> > >    grant or any other response type causing the authorization server t=
o
>> > >    issue an access token in the authorization response.
>> > >=20
>> > > What would you like to modify?=20
>> > >=20
>> > >>=20
>> > >> 2) Banning the returning of the access token that are not sender con=
strained from the authorization endpoint
>> > >=20
>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>> > >    grant or any other response type causing the authorization server t=
o
>> > >    issue an access token in the authorization response, if this acces=
s tokens is not sender-constraint.
>> > >=20
>> > > What about this?
>> > >=20
>> > > kind regards,
>> > > Torsten.
>> > >=20
>> > >>=20
>> > >> Best,
>> > >>=20
>> > >> Nat
>> > >>=20
>> > >>=20
>> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>> > >> =20
>> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Ha=
rdt  =E3=81=AE=E4=BB=A3=E7=90=86)
>> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>> > >> Cc: oauth@ietf.org
>> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization code instead of implicit
>> > >> =20
>> > >> +1
>> > >>=20
>> > >> While there are various mechanisms to alleviate some of the issues o=
f implicit, I don't think we can recommend specifics, and there may be futur=
e ones in the future. I think we all agree that implicit without any mitigat=
ion is problematic.=20
>> > >>=20
>> > >> How about we recommend against using implicit alone?=20
>> > >>=20
>> > >>=20
>> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig  wrote:
>> > >> Hi all,
>> > >>=20
>> > >> The authors of the OAuth Security Topics draft came to the conclusio=
n that it is not possible to adequately secure the implicit flow against tok=
en injection since potential solutions like token binding or JARM are in an e=
arly stage of adoption. For this reason, and since CORS allows browser-based=
 apps to send requests to the token endpoint, Torsten suggested to use the a=
uthorization code instead of the implicit grant in call cases in his present=
ation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oau=
th-sessb-draft-ietf-oauth-security-topics-01).
>> > >>=20
>> > >> A hum in the room at IETF#103 concluded strong support for his recom=
mendations. We would like to confirm the discussion on the list.
>> > >>=20
>> > >> Please provide a response by December 3rd.
>> > >>=20
>> > >> Ciao
>> > >>=20
>> > >> Hannes & Rifaat
>> > >>=20
>> > >> =20
>> > >>=20
>> > >> IMPORTANT NOTICE: The contents of this email and any attachments are=
 confidential and may also be privileged. If you are not the intended recipi=
ent, please notify the sender immediately and do not disclose the contents t=
o any other person, use it for any purpose, or store or copy the information=
 in any medium. Thank you.
>> > >> _______________________________________________
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>> > >> _______________________________________________
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>> > >=20
>> >=20
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
 material for the sole use of the intended recipient(s). Any review, use, di=
stribution or disclosure by others is strictly prohibited.  If you have rece=
ived this communication in error, please notify the sender immediately by e-=
mail and delete the message and any file attachments from your computer. Tha=
nk you.

--Apple-Mail-70AB1637-69BF-4772-BC94-98DB594DA847
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Hi B=
rian,

    we use =E2=80=9Esende=
r constrained tokens=E2=80=9C throughout the BCP to denote tokens bound to a=
 sender in possession of a certain key/secret and I thought that was establi=
shed terminology in the group. Are you suggesting =E2=80=9Ekey constrained=E2=
=80=9D would be more appropriate?

    kind regards,
    Torsten.
    Am 30.11.2018 um 21:02 schrieb Brian Campbell <bcampbell@pingidentity.com>:

    As was pointed ou=
t to me in WGLC review of the MTLS document, "sender-constrained" has or is l=
ikely to be interpreted with a pretty specific meaning of the token being bo=
und to the client and the client authenticating itself to the resource and t=
he resource checking all that matches up. That makes the text more restricti=
ve than is likely intended. Perhaps the text should say something like "send=
er or key constrained" to allow for different variants of PoP access tokens?=
 



    On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <=
torsten@lodderstedt.net> w=
rote:
    Hi all, 
    

    
based on your feedback on the list and off list, Daniel and I polished the t=
ext. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing access 
    =

tokens in the authorization response, such as "token id_token" and "code tok=
en id_token=E2=80=9C, 
    
unless the issued access tokens are sender-constrained and access token inje=
ction in 
    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the re=
sponse types we do not recommend/allow to be used and a concrete/actionable l=
ist of the affected response types. 
    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported b=
y William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.  
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
> 
    
> I am ok with that.  
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wrot=
e:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (on=
ly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would se=
nder constrained. This completely ignores the fact implicit also shall be ab=
andoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>    In order to avoid these issues, Clients SHOULD NOT use the=
 implicit
    
>    grant. Furthermore, clients SHOULD only use other response=
 types causing the authorization server to
    
>    issue an access token in the authorization response, if th=
e particular response type detects access token 
    
>    injection and the issued access tokens are sender-constrai=
ned.
    
> 
    
> Or we just state:
    
> 
    
>   In order to avoid these issues, Clients SHOULD NOT use the r=
esponse type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is t=
oo much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give i=
mplementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=
=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=
=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=
=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=99=
=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=
=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=E3=81=97=E8=
=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=
=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=
=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=E4=BF=A1=E3=81=95=E3=
=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=89=8A=E9=99=A4=E3=81=97=
=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=
=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=
=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the name=
d recipient only.
    
> > If you are not an intended recipient, please notify the sender and=
 delete this e-mail.
    
> >  
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net&=
gt;
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,=
 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm=
end authorization code instead of implicit
    
> >  
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access t=
oken from the authorization endpoint ( some people confuses implicit as the f=
low that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implici=
t
    
> >    grant or any other response type causing the authoriz=
ation server to
    
> >    issue an access token in the authorization response.<=
br>
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not send=
er constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implici=
t
    
> >    grant or any other response type causing the authoriz=
ation server to
    
> >    issue an access token in the authorization response, i=
f this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>  
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick Ha=
rdt <dick.hardt=
@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=
=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth@=
ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Re=
commend authorization code instead of implicit
    
> >>  
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the is=
sues of implicit, I don't think we can recommend specifics, and there may be=
 future ones in the future. I think we all agree that implicit without any m=
itigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.c=
om> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the con=
clusion that it is not possible to adequately secure the implicit flow again=
st token injection since potential solutions like token binding or JARM are i=
n an early stage of adoption. For this reason, and since CORS allows browser=
-based apps to send requests to the token endpoint, Torsten suggested to use=
 the authorization code instead of the implicit grant in call cases in his p=
resentation (see https://datatracker.ietf.org/meeting/103/materials/s=
lides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
    
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for his=
 recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>  
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachmen=
ts are confidential and may also be privileged. If you are not the intended r=
ecipient, please notify the sender immediately and do not disclose the conte=
nts to any other person, use it for any purpose, or store or copy the inform=
ation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@ietf=
.org
    
> >> https://www.ietf.org/mailman/listinfo/oauth
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >>     OAuth@ietf=
.org
    
> >> https://www.ietf.org/mailman/listinfo/oauth
    
> > 
    
> 
    
> _______________________________________________
    
> OAuth mailing list
    
>     OAuth@ietf.org<=
br>
> https://www.ietf.org/mailman/listinfo/oauth
    

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

    


    
CONFIDENTIALITY NOTICE: This email may contain confidential and pr=
ivileged material for the sole use of the intended recipient(s). Any review,=
 use, distribution or disclosure by others is strictly prohibited.  If y=
ou have received this communication in error, please notify the sender immed=
iately by e-mail and delete the message and any file attachments from your c=
omputer. Thank you.
    =

--Apple-Mail-70AB1637-69BF-4772-BC94-98DB594DA847--

--Apple-Mail-AAFC2B07-F549-42C7-9D1F-08C7A56BDF95
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw
ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1
OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6
ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm
EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/
9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m
2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC
Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A
mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG
A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu
Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB
AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe
pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o
qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/
ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM
04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED
e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/
BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX
dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu
wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT
QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs
0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F
dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX
Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG
CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB
Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy
ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j
b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp
bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB
F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976
FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz
62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4
wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq
8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4
Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM
aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMTMwMjA0MjUyWjAvBgkqhkiG
9w0BCQQxIgQg1rfoMegM82uzPDb1qR3yYd+cDamSax0oiV+C4kRlfSkwgcEGCSsGAQQBgjcQBDGB
szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT
SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3
mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB
IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBADE1
6YUOLH9lMnVtJXRjSxR4KZQWMNKq41EMUDiib2qpJIbr2LOjak9gfbi3F9Ov9TpG+G/oJLbtC8uD
ns13onqoV6jJ6gPUS8ksDndtFgY2Q1xgVYY3p31k/1fn9xmPId7MA6q22nbg0z6epNh+60V5oo2h
euy1A/zldtzh7ItwTL4IopSx534bAlHliss/JJkmvB9Nl0X7yz0+wLMXN2+znrfzzVUtiyHS0BDy
qgA642Vy00ufvOswij8N4KEmdI/I9M5Cu6K9r9PjEVlga8e3izmtTVrl6kyJvgfoojiFCYd19iFO
YwlDktWYcGiNBpmhxAGNVZCKdX4i4BU4/sYAAAAAAAA=

--Apple-Mail-AAFC2B07-F549-42C7-9D1F-08C7A56BDF95--


From nobody Fri Nov 30 13:04:59 2018
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 0581D131007 for ; Fri, 30 Nov 2018 13:04:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 XjnhwfPXg8sa for ; Fri, 30 Nov 2018 13:04:55 -0800 (PST)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771A9131008 for ; Fri, 30 Nov 2018 13:04:55 -0800 (PST)
Received: by mail-it1-x134.google.com with SMTP id c9so510428itj.1 for ; Fri, 30 Nov 2018 13:04:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=79CTrdySRf0vbhzklsVUntdmWk6O8CzpkWloX6mArQM=; b=bUwpen/7HuUNYj9z+pBv1cCGW0CT5LniT8Tyl3yVgFw7dsdrLhQWiMHaa7zySR23CS +IacBQVkLPfYRRo/S5aRp3dE2UbT00SK08xIBvG8exFEK9aliBbjwFg3GxJnz3oXbxbX 7vRjRxLiYe6u091y2xGUs5xv1bAgMpguK9Gyw=
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=79CTrdySRf0vbhzklsVUntdmWk6O8CzpkWloX6mArQM=; b=VpnH4oQ0WHz/1WLIRaQxPgezkR6pkKU77nafgzdgBGEBqvctNlZuI2v+PeEAT4UvRa jeswdXFTze+oTzQ+/mxtwq0sKp2sQLxnM5jwbF8yoPBbH2K/TFesZjaCMGrMx1Ce2YWl CdQVOuz1VZUo65FUCzg23rHuEsd0P05hxHKRtDHP11G26T3GuPlDvaRGde+WVWCNUOA3 lnu87SezyqBrnZ/w88JgM3x4SfQs2849FzFj9nnQe/CMbDVwEUuILASiFV8Mv84BqClR 7tahiNwjuYB6A9c1JKjj/NEiFi1uAzA/WOYnjVcPgfX8MsnlhVNn7vQmX1j1WeyMfSwm xTxw==
X-Gm-Message-State: AA+aEWZbBSaSxoC9zo3lkmSgD0/PKJZd59XCOLIqUoELtRQ3uiFIkmWm euQA3FFrcYZs8YM3htgqbujz58hEWzQbi8f6oSwAc/PGo2KW4V6gqvFT97CX1k8G5w3rzM72ja+ 2f9Dn8aOcNU2f7Q==
X-Google-Smtp-Source: AFSGD/VNEvD0Tdi3ulF8IrWyY5NVpn5C7/NeGKRSe/WCEuwJ9FTJk+9FRSTKPpukhHl8lSwKdy1tTyVkl4haH6CmhgU=
X-Received: by 2002:a02:5f9d:: with SMTP id x29mr6947215jad.28.1543611894615;  Fri, 30 Nov 2018 13:04:54 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 30 Nov 2018 14:04:28 -0700
Message-ID: 
To: Hannes Tschofenig 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000a6b3da057be8266e"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-token-exchange/audience & draft-ietf-oauth-resource-indicators
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, 30 Nov 2018 21:04:58 -0000

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

Seems correct, yes.

On Fri, Nov 30, 2018 at 1:32 PM Hannes Tschofenig 
wrote:

> Hi all,
>
> Token exchange registers the 'resource' parameter, at least to a large
> extend, and draft-ietf-oauth-resource-indicators indicates this in the IA=
NA
> consideration section.
>
> What isn't mentioned in draft-ietf-oauth-resource-indicators is that toke=
n
> exchange also defines the audience parameter. The audience parameter is
> defined as
>
> "
> Audience:
>       The logical name of the target service where the client
>       intends to use the requested security token.  This serves a
>       purpose similar to the "resource" parameter, but with the client
>       providing a logical name rather than a location.
> "
>
> I am mentioning this also because draft-ietf-ace-oauth-params defines a
> parameter 'req_aud', which was supposed to be similar to resource but at
> the last IETF meeting the argument was that it is a logical name. As such=
,
> it would correspond to the audience parameter registered in the token
> exchange.
>
> Is my observation correct?
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
>
> _______________________________________________
> 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._

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


    Seems correct, yes. 

    On Fri, Nov 30, 2018 at 1:32 PM Hannes Tschofenig <<=
a href=3D"mailto:Hannes.Tschofenig@arm.com">Hannes.Tschofenig@arm.com&g=
t; wrote:
    Hi all,
    

    
Token exchange registers the 'resource' parameter, at least to a la=
rge extend, and draft-ietf-oauth-resource-indicators indicates this in the =
IANA consideration section.
    

    
What isn't mentioned in draft-ietf-oauth-resource-indicators is that to=
ken exchange also defines the audience parameter. The audience parameter is=
 defined as
    

    
"
    
Audience:
    
=C2=A0 =C2=A0 =C2=A0 The logical name of the target service where the clien=
t
    
=C2=A0 =C2=A0 =C2=A0 intends to use the requested security token.=C2=A0 Thi=
s serves a
    
=C2=A0 =C2=A0 =C2=A0 purpose similar to the "resource" parameter,=
 but with the client
    
=C2=A0 =C2=A0 =C2=A0 providing a logical name rather than a location.
    
"
    

    
I am mentioning this also because draft-ietf-ace-oauth-params defines a par=
ameter 'req_aud', which was supposed to be similar to resource but =
at the last IETF meeting the argument was that it is a logical name. As suc=
h, it would correspond to the audience parameter registered in the token ex=
change.
    

    
Is my observation correct?
    

    
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.
    

    
_______________________________________________
    
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.
--000000000000a6b3da057be8266e--


From nobody Fri Nov 30 14:24:05 2018
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 C1B561310CD for ; Fri, 30 Nov 2018 14:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 1myNGMalRqXG for ; Fri, 30 Nov 2018 14:23:54 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8B01310A2 for ; Fri, 30 Nov 2018 14:23:54 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id n9so5809274ioh.7 for ; Fri, 30 Nov 2018 14:23:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JdGUrLM/79FgEyDND3//28cOVHSFxuSYHfMhyf7fa6c=; b=ixFfsi3nVgLYFUmGKPffl0h1bc2NzR1aWHAv389CXUvdgagH1cZ9hbit+MuOZC/iw3 i1SxJqQHFD2CppvlJU/u2WhqBydWinf3E4lpfNh3Ioy5cD66KvxUIZpfSx+eYQtIQe8l UbaFkLWSphwrYbw6so3cgIbTYKE53K60DZjFc=
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=JdGUrLM/79FgEyDND3//28cOVHSFxuSYHfMhyf7fa6c=; b=L7v0J3RlWNPLn3iZr4KdfgI4Fg9JyFK4Q5fWP2VpoEGYkNH1EQdggPhFZEqRXq7/oZ +B7zJsgF49Bk3TTWHXQyt2L1Gey4wHpciAsinJMVH55qknFNcSUJhX+et6srVBROxq0F R4KBicLq0DAPMNFTc3iI/M95JF+EfuYZKACycM3IuZjlqgY0GuiPAORVqyHvOMDwouZx Y4ABwUBTLJwSWP3AcG2Gj16zhmc4ceotCLNJKkIbd3/Hbj3aIwtynZn1aaW29119p8D7 NpuCfCOwKyZg7GwDIZspCf1Q5C8+pmtgfBS3HEojfJ70flhOjEheDf2HCtypJpkpFm69 R/qg==
X-Gm-Message-State: AA+aEWaMu4aFSKzy9qGHOSF+iFuLX9bDnV/rIqq/JsTeuzcjqMbDuHr7 +nqE3jdIWh6KXlRig9JYzWm9rF2OKrp4HrGy+qpE+NaqrfrdTW2JRhGx/Kr7GxxL9M07gZWY45e /CzBNUnEppe/a/OCUhzw=
X-Google-Smtp-Source: AFSGD/VFJ+ujtn+/4Zbi1pBafqHMHbuKWESnVzRKefvCwE2WD76yViyGxPnd8xUlaO+xhNNlMFR1DclHNsTBcjbguWY=
X-Received: by 2002:a6b:b345:: with SMTP id c66mr6315843iof.59.1543616633448;  Fri, 30 Nov 2018 14:23:53 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>      <558F050A-AC67-45B5-8D55-A025444539A2@lodderstedt.net>
In-Reply-To: <558F050A-AC67-45B5-8D55-A025444539A2@lodderstedt.net>
From: Brian Campbell 
Date: Fri, 30 Nov 2018 15:23:26 -0700
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth , fett@danielfett.de
Content-Type: multipart/alternative; boundary="0000000000001b45da057be94133"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 30 Nov 2018 22:24:03 -0000

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

Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
constrained might be more appropriate. But the Security Topics document
probably should allow for both/either.

I don't think that these are necessarily terms with widely agreed upon or
understood meaning. But it was pointed out to me that the OAuth 2.0 Pop
Architecture draft defines sender constraint and key confirmation as
different things (
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.=
2
and
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.=
3).
And the definitions their do kind of make sense when thinking about the
words used. The line between sender and key constrained isn't exactly clear
but it seems MTLS and token binding access tokens are more key constrained
than sender. The -08 version of the MTLS draft dropped the use of the
"sender constrained" terminology based on that feedback.

I dunno. Maybe the Security Topics could say something in a terminology
section that says when sender or key constrained is used within they can be
taken to mean the same concept. Or something like that.

On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt 
wrote:

> Hi Brian,
>
> we use =E2=80=9Esender constrained tokens=E2=80=9C throughout the BCP to =
denote tokens
> bound to a sender in possession of a certain key/secret and I thought tha=
t
> was established terminology in the group. Are you suggesting =E2=80=9Ekey
> constrained=E2=80=9D would be more appropriate?
>
> kind regards,
> Torsten.
>
> Am 30.11.2018 um 21:02 schrieb Brian Campbell  >:
>
> As was pointed out to me in WGLC review of the MTLS document,
> "sender-constrained" has or is likely to be interpreted with a pretty
> specific meaning of the token being bound to the client and the client
> authenticating itself to the resource and the resource checking all that
> matches up. That makes the text more restrictive than is likely intended.
> Perhaps the text should say something like "sender or key constrained" to
> allow for different variants of PoP access tokens?
>
>
>
> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> based on your feedback on the list and off list, Daniel and I polished
>> the text. That=E2=80=99s our proposal:
>>
>> =E2=80=94
>> In order to avoid these issues, clients MUST NOT use the implicit
>> grant (response type "token") or any other response type issuing access
>> tokens in the authorization response, such as "token id_token" and "code
>> token id_token=E2=80=9C,
>> unless the issued access tokens are sender-constrained and access token
>> injection in
>> the authorization response is prevented.
>> =E2=80=94
>>
>> Explantation:
>> - we wanted to have the right balance between a generic definition of th=
e
>> response types we do not recommend/allow to be used and a
>> concrete/actionable list of the affected response types.
>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and
>> supported by William
>>
>> We look forward to seeing your feedback.
>>
>> kind regards,
>> Torsten.
>>
>> > Am 29.11.2018 um 15:15 schrieb John Bradley :
>> >
>> > I am ok with that.
>> >
>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
>> torsten@lodderstedt.net wrote:
>> >
>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
>> > >
>> > > That works.
>> >
>> > Good!
>> >
>> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would
>> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender const=
rained. This
>> completely ignores the fact implicit also shall be abandoned because of =
its
>> vulnerability for access token injection.
>> >
>> > I therefore propose a modified text:
>> >
>> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
>> >    grant. Furthermore, clients SHOULD only use other response types
>> causing the authorization server to
>> >    issue an access token in the authorization response, if the
>> particular response type detects access token
>> >    injection and the issued access tokens are sender-constrained.
>> >
>> > Or we just state:
>> >
>> >   In order to avoid these issues, Clients SHOULD NOT use the response
>> type =E2=80=9Etoken". The response types
>> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the
>> issued access tokens are not
>> > sender-constrained.
>> >
>> > >
>> > > In fact, I would further go and say MUST NOT but that probably is to=
o
>> much for a security consideration.
>> > >
>> >
>> > Mike suggested to go with a SHOULD NOT to get the message out but give
>> implementors time to move/change.
>> >
>> > > Best,
>> > >
>> > > Nat
>> > >
>> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>> > >
>> > >
>> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>> > >
>> > > PLEASE READ :This e-mail is confidential and intended for the named
>> recipient only.
>> > > If you are not an intended recipient, please notify the sender and
>> delete this e-mail.
>> > >
>> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
>> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
>> > > =E5=AE=9B=E5=85=88: n-sakimura
>> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
>> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization
>> code instead of implicit
>> > >
>> > > Hi Nat,
>> > >
>> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>> > >>
>> > >> I would support
>> > >>
>> > >> 1) clearly defining Implicit as the flow that returns access token
>> from the authorization endpoint ( some people confuses implicit as the f=
low
>> that returns ID Token in the front channel)
>> > >
>> > > That=E2=80=99s the current text:
>> > >
>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>> > >    grant or any other response type causing the authorization server
>> to
>> > >    issue an access token in the authorization response.
>> > >
>> > > What would you like to modify?
>> > >
>> > >>
>> > >> 2) Banning the returning of the access token that are not sender
>> constrained from the authorization endpoint
>> > >
>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>> > >    grant or any other response type causing the authorization server
>> to
>> > >    issue an access token in the authorization response, if this
>> access tokens is not sender-constraint.
>> > >
>> > > What about this?
>> > >
>> > > kind regards,
>> > > Torsten.
>> > >
>> > >>
>> > >> Best,
>> > >>
>> > >> Nat
>> > >>
>> > >>
>> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>> > >>
>> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick H=
ardt <
>> dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
>> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>> > >> Cc: oauth@ietf.org
>> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomme=
nd authorization
>> code instead of implicit
>> > >>
>> > >> +1
>> > >>
>> > >> While there are various mechanisms to alleviate some of the issues
>> of implicit, I don't think we can recommend specifics, and there may be
>> future ones in the future. I think we all agree that implicit without an=
y
>> mitigation is problematic.
>> > >>
>> > >> How about we recommend against using implicit alone?
>> > >>
>> > >>
>> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
>> Hannes.Tschofenig@arm.com> wrote:
>> > >> Hi all,
>> > >>
>> > >> The authors of the OAuth Security Topics draft came to the
>> conclusion that it is not possible to adequately secure the implicit flo=
w
>> against token injection since potential solutions like token binding or
>> JARM are in an early stage of adoption. For this reason, and since CORS
>> allows browser-based apps to send requests to the token endpoint, Torste=
n
>> suggested to use the authorization code instead of the implicit grant in
>> call cases in his presentation (see
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sess=
b-draft-ietf-oauth-security-topics-01
>> ).
>> > >>
>> > >> A hum in the room at IETF#103 concluded strong support for his
>> recommendations. We would like to confirm the discussion on the list.
>> > >>
>> > >> Please provide a response by December 3rd.
>> > >>
>> > >> Ciao
>> > >>
>> > >> Hannes & Rifaat
>> > >>
>> > >>
>> > >>
>> > >> IMPORTANT NOTICE: The contents of this email and any attachments ar=
e
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy t=
he
>> information in any medium. Thank you.
>> > >> _______________________________________________
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>> > >> _______________________________________________
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>> > >
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

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


    Kind of, yes. I guess so. I think. It's just semantics. =
But yeah. Key constrained might be more appropriate. But the Security Topic=
s document probably should allow for both/either. 

    =

    I don't think that these are necessarily terms with widely agreed =
upon or understood meaning. But it was pointed out to me that the OAuth 2.0=
 Pop Architecture draft defines sender =
constraint and key confirmation as different things (https://tools.ietf.org/html/draft-ietf-=
oauth-pop-architecture-08#section-6.2 and https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section=
-6.3). And the definitions their do kind of make sense when thinking ab=
out the words used. The line between sender and key constrained isn't e=
xactly clear but it seems MTLS and token binding access tokens are more key=
 constrained than sender. The -08 version of the MTLS draft dropped the use=
 of the "sender constrained" terminology based on that feedback. =


    I dunno. Maybe the Security Topics could say =
something in a terminology section that says when sender or key constrained=
 is used within they can be taken to mean the same concept. Or something li=
ke that. 

    On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt &=
lt;torsten@lod=
derstedt.net> wrote:
    Hi Brian,

    we use =E2=80=9Esender constrained toke=
ns=E2=80=9C throughout the BCP to denote tokens bound to a sender in posses=
sion of a certain key/secret and I thought that was established terminology=
 in the group. Are you suggesting =E2=80=9Ekey constrained=E2=80=9D would b=
e more appropriate?

    kind r=
egards,
    Torsten.

    Am 30.11.2=
018 um 21:02 schrieb Brian Campbell <bcampbell@pingidentity.com>:

    As was =
pointed out to me in WGLC review of the MTLS document, "sender-constra=
ined" has or is likely to be interpreted with a pretty specific meanin=
g of the token being bound to the client and the client authenticating itse=
lf to the resource and the resource checking all that matches up. That make=
s the text more restrictive than is likely intended. Perhaps the text shoul=
d say something like "sender or key constrained" to allow for dif=
ferent variants of PoP access tokens? 



    On Thu, Nov 29, 20=
18 at 11:06 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi all, 
    

    
based on your feedback on the list and off list, Daniel and I polished the =
text. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing =
access 
    
tokens in the authorization response, such as "token id_token" an=
d "code token id_token=E2=80=9C, 
    
unless the issued access tokens are sender-constrained and access token inj=
ection in 
    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionabl=
e list of the affected response types. 
    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported =
by William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.=C2=A0 
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr=
ote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token 
    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig;     oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick =
Hardt <dick.ha=
rdt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth=
@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a=
rm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this reason, and since CORS allows br=
owser-based apps to send requests to the token endpoint, Torsten suggested =
to use the authorization code instead of the implicit grant in call cases i=
n his presentation (see https://datatracker.ietf.org/meeting/103/=
materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<=
br>
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy the i=
nformation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> > 
    
> 
    
> _______________________________________________
    
> 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
    

    


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


    
<=
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.
--0000000000001b45da057be94133--


From nobody Fri Nov 30 14:36:01 2018
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 3963C13108E for ; Fri, 30 Nov 2018 14:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WGKxf3ZSjaJR for ; Fri, 30 Nov 2018 14:35:55 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C4D130F29 for ; Fri, 30 Nov 2018 14:35:55 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id l15-v6so6356223lja.9 for ; Fri, 30 Nov 2018 14:35:55 -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=gRTvdnM2vhhoynHWM8hJA/87gvbzWG41QFNV4kbvM5k=; b=I0wW+uMxTk/D3P0DoAMjRoNrbuUc5/9Abocd3BprC2hfQpWk7CZkV4eN7ClsytHeW/ xXZrsw2Fc+VtfgJrV43pjYy0zksyjS0M+NwIvgx/3UcD8/+ammQ2zlvxSoTphAk69XI7 1laP4nw6t93jte8s3RfBlTJDX2cotm92sDEy5H42zBL7pieD4X8wjFIrm3ueOxk5fauR GT3yYmnslpj9iIPUfU4CPhbDPjubWQwzeH2NsuixxDUr822AtfUXSv7k4MJUL+vCGAlW WMfZIycOZeiVO1J/EXAWNzxepiFjbZ8E5xJXcerMcVehtn5EOsycxqRyoH2vnxlbA0f4 Uflw==
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=gRTvdnM2vhhoynHWM8hJA/87gvbzWG41QFNV4kbvM5k=; b=i6/Rza4+vJjdJr0mWxKMHvT0FLyAkz0H7sSrB0cPylkfdguIVBLT2YgTJuIoMWSDsa KyITD4zGDwXjNNgt6nV8ev/uLIB0t0mxfr/cXXEV8PeWlcS+NxzppaxvcY+/uwPM3b79 QvCl1yQwIp2cJXxkJ6dCQjtlODizknQtZHy/0Nspw5Ua16bW8AMLSm4XckX6Sp2h+0QN h56CW4qBPm+xfhXMpVQdNgqLaZ61Gdq6N6qy1wzJdADfuUI+ZyGKiYV+jba/pI1Lx5wI Vb1rWFPcgOJtyao27eMzCLVmzyoN8/Jtt9OYFr9Mxg+QKpYSIbpY63yxAzCjH0zisn2c GrcA==
X-Gm-Message-State: AA+aEWbkMlfGcAjPXjqz849ugTuDvNDID7BGE/V5s5ENwnGBPl82TSx6 Q/V9IVj2RkmfBUAAbyauk5NQ8mTfee7ZsAocNv4=
X-Google-Smtp-Source: AFSGD/VeycBf8kdOLW9FO1Pl9q0hmD10hwazEzzwz8oZ547VBo3MIw1PW4wVd2LfHpl7ghv4RXD9gJCpaI3CbNimHg0=
X-Received: by 2002:a2e:9e03:: with SMTP id e3-v6mr5057954ljk.4.1543617353093;  Fri, 30 Nov 2018 14:35:53 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>      <558F050A-AC67-45B5-8D55-A025444539A2@lodderstedt.net> 
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 30 Nov 2018 14:35:39 -0800
Message-ID: 
To: Brian Campbell 
Cc: Torsten Lodderstedt , fett@danielfett.de, oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000017cf057be96cfb"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 30 Nov 2018 22:35:59 -0000

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

+ 1 to the change

I'd suggest we work to define terms such as "sender constrained" in the BCP
so that it is clear what is meant by it.

On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell  wrote:

> Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
> constrained might be more appropriate. But the Security Topics document
> probably should allow for both/either.
>
> I don't think that these are necessarily terms with widely agreed upon or
> understood meaning. But it was pointed out to me that the OAuth 2.0 Pop
> Architecture draft defines sender constraint and key confirmation as
> different things (
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-=
6.2
> and
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-=
6.3
> ).
> And the definitions their do kind of make sense when thinking about the
> words used. The line between sender and key constrained isn't exactly cle=
ar
> but it seems MTLS and token binding access tokens are more key constraine=
d
> than sender. The -08 version of the MTLS draft dropped the use of the
> "sender constrained" terminology based on that feedback.
>
> I dunno. Maybe the Security Topics could say something in a terminology
> section that says when sender or key constrained is used within they can =
be
> taken to mean the same concept. Or something like that.
>
> On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi Brian,
>>
>> we use =E2=80=9Esender constrained tokens=E2=80=9C throughout the BCP to=
 denote tokens
>> bound to a sender in possession of a certain key/secret and I thought th=
at
>> was established terminology in the group. Are you suggesting =E2=80=9Eke=
y
>> constrained=E2=80=9D would be more appropriate?
>>
>> kind regards,
>> Torsten.
>>
>> Am 30.11.2018 um 21:02 schrieb Brian Campbell > >:
>>
>> As was pointed out to me in WGLC review of the MTLS document,
>> "sender-constrained" has or is likely to be interpreted with a pretty
>> specific meaning of the token being bound to the client and the client
>> authenticating itself to the resource and the resource checking all that
>> matches up. That makes the text more restrictive than is likely intended=
.
>> Perhaps the text should say something like "sender or key constrained" t=
o
>> allow for different variants of PoP access tokens?
>>
>>
>>
>> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>>
>>> Hi all,
>>>
>>> based on your feedback on the list and off list, Daniel and I polished
>>> the text. That=E2=80=99s our proposal:
>>>
>>> =E2=80=94
>>> In order to avoid these issues, clients MUST NOT use the implicit
>>> grant (response type "token") or any other response type issuing access
>>> tokens in the authorization response, such as "token id_token" and "cod=
e
>>> token id_token=E2=80=9C,
>>> unless the issued access tokens are sender-constrained and access token
>>> injection in
>>> the authorization response is prevented.
>>> =E2=80=94
>>>
>>> Explantation:
>>> - we wanted to have the right balance between a generic definition of
>>> the response types we do not recommend/allow to be used and a
>>> concrete/actionable list of the affected response types.
>>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and
>>> supported by William
>>>
>>> We look forward to seeing your feedback.
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> > Am 29.11.2018 um 15:15 schrieb John Bradley :
>>> >
>>> > I am ok with that.
>>> >
>>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
>>> torsten@lodderstedt.net wrote:
>>> >
>>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
>>> > >
>>> > > That works.
>>> >
>>> > Good!
>>> >
>>> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (=
only). It would
>>> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender cons=
trained. This
>>> completely ignores the fact implicit also shall be abandoned because of=
 its
>>> vulnerability for access token injection.
>>> >
>>> > I therefore propose a modified text:
>>> >
>>> >    In order to avoid these issues, Clients SHOULD NOT use the implici=
t
>>> >    grant. Furthermore, clients SHOULD only use other response types
>>> causing the authorization server to
>>> >    issue an access token in the authorization response, if the
>>> particular response type detects access token
>>> >    injection and the issued access tokens are sender-constrained.
>>> >
>>> > Or we just state:
>>> >
>>> >   In order to avoid these issues, Clients SHOULD NOT use the response
>>> type =E2=80=9Etoken". The response types
>>> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the
>>> issued access tokens are not
>>> > sender-constrained.
>>> >
>>> > >
>>> > > In fact, I would further go and say MUST NOT but that probably is
>>> too much for a security consideration.
>>> > >
>>> >
>>> > Mike suggested to go with a SHOULD NOT to get the message out but giv=
e
>>> implementors time to move/change.
>>> >
>>> > > Best,
>>> > >
>>> > > Nat
>>> > >
>>> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>>> > >
>>> > >
>>> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=
=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=
=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=
=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=
=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=
=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=
=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=
=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=
=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=
=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=
=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=
=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=
=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=
=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>>> > >
>>> > > PLEASE READ :This e-mail is confidential and intended for the named
>>> recipient only.
>>> > > If you are not an intended recipient, please notify the sender and
>>> delete this e-mail.
>>> > >
>>> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
>>> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, =
11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
>>> > > =E5=AE=9B=E5=85=88: n-sakimura
>>> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
>>> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomme=
nd authorization
>>> code instead of implicit
>>> > >
>>> > > Hi Nat,
>>> > >
>>> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>>> > >>
>>> > >> I would support
>>> > >>
>>> > >> 1) clearly defining Implicit as the flow that returns access token
>>> from the authorization endpoint ( some people confuses implicit as the =
flow
>>> that returns ID Token in the front channel)
>>> > >
>>> > > That=E2=80=99s the current text:
>>> > >
>>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>>> > >    grant or any other response type causing the authorization serve=
r
>>> to
>>> > >    issue an access token in the authorization response.
>>> > >
>>> > > What would you like to modify?
>>> > >
>>> > >>
>>> > >> 2) Banning the returning of the access token that are not sender
>>> constrained from the authorization endpoint
>>> > >
>>> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
>>> > >    grant or any other response type causing the authorization serve=
r
>>> to
>>> > >    issue an access token in the authorization response, if this
>>> access tokens is not sender-constraint.
>>> > >
>>> > > What about this?
>>> > >
>>> > > kind regards,
>>> > > Torsten.
>>> > >
>>> > >>
>>> > >> Best,
>>> > >>
>>> > >> Nat
>>> > >>
>>> > >>
>>> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>>> > >>
>>> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick =
Hardt <
>>> dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
>>> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,=
 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>>> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>>> > >> Cc: oauth@ietf.org
>>> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm=
end authorization
>>> code instead of implicit
>>> > >>
>>> > >> +1
>>> > >>
>>> > >> While there are various mechanisms to alleviate some of the issues
>>> of implicit, I don't think we can recommend specifics, and there may be
>>> future ones in the future. I think we all agree that implicit without a=
ny
>>> mitigation is problematic.
>>> > >>
>>> > >> How about we recommend against using implicit alone?
>>> > >>
>>> > >>
>>> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
>>> Hannes.Tschofenig@arm.com> wrote:
>>> > >> Hi all,
>>> > >>
>>> > >> The authors of the OAuth Security Topics draft came to the
>>> conclusion that it is not possible to adequately secure the implicit fl=
ow
>>> against token injection since potential solutions like token binding or
>>> JARM are in an early stage of adoption. For this reason, and since CORS
>>> allows browser-based apps to send requests to the token endpoint, Torst=
en
>>> suggested to use the authorization code instead of the implicit grant i=
n
>>> call cases in his presentation (see
>>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-ses=
sb-draft-ietf-oauth-security-topics-01
>>> ).
>>> > >>
>>> > >> A hum in the room at IETF#103 concluded strong support for his
>>> recommendations. We would like to confirm the discussion on the list.
>>> > >>
>>> > >> Please provide a response by December 3rd.
>>> > >>
>>> > >> Ciao
>>> > >>
>>> > >> Hannes & Rifaat
>>> > >>
>>> > >>
>>> > >>
>>> > >> IMPORTANT NOTICE: The contents of this email and any attachments
>>> are confidential and may also be privileged. If you are not the intende=
d
>>> recipient, please 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.
>>> > >> _______________________________________________
>>> > >> 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
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
..
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.*
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    + 1 to the change

    I'd suggest w=
e work to define terms such as "sender constrained" in the BCP so=
 that it is clear what is meant by it.

    On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell <b=
campbell=3D40pingident=
ity.com@dmarc.ietf.org> wrote:
    Kind of, yes. I guess so. I think. It's just semantic=
s. But yeah. Key constrained might be more appropriate. But the Security To=
pics document probably should allow for both/either. 

    I don't think that these are necessarily terms with widely agre=
ed upon or understood meaning. But it was pointed out to me that the OAuth =
2.0 Pop Architecture draft defines sender constraint and key co=
nfirmation as different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#se=
ction-6.2 and https://tools.ietf.org/h=
tml/draft-ietf-oauth-pop-architecture-08#section-6.3). And the definiti=
ons their do kind of make sense when thinking about the words used. The lin=
e between sender and key constrained isn't exactly clear but it seems M=
TLS and token binding access tokens are more key constrained than sender. T=
he -08 version of the MTLS draft dropped the use of the "sender constr=
ained" terminology based on that feedback. 

    I dunno. Maybe the Security Topics could say something in a terminology =
section that says when sender or key constrained is used within they can be=
 taken to mean the same concept. Or something like that. 

    On Fr=
i, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:=

    Hi Brian,

    we use =E2=80=9Esender constrained tokens=E2=80=9C throughout the =
BCP to denote tokens bound to a sender in possession of a certain key/secre=
t and I thought that was established terminology in the group. Are you sugg=
esting =E2=80=9Ekey constrained=E2=80=9D would be more appropriate?

    kind regards,
    Torsten.

    Am 30.11.2018 um 21:02 schrieb Brian =
Campbell <bcampbell@pingidentity.com>:

    As was pointed out to me in WGLC r=
eview of the MTLS document, "sender-constrained" has or is likely=
 to be interpreted with a pretty specific meaning of the token being bound =
to the client and the client authenticating itself to the resource and the =
resource checking all that matches up. That makes the text more restrictive=
 than is likely intended. Perhaps the text should say something like "=
sender or key constrained" to allow for different variants of PoP acce=
ss tokens? 



    On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodd=
erstedt <to=
rsten@lodderstedt.net> wrote:
    ve7jtb@ve7jtb.com>:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr=
ote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token 
    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig;     oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick =
Hardt <dick.ha=
rdt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth=
@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a=
rm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this reason, and since CORS allows br=
owser-based apps to send requests to the token endpoint, Torsten suggested =
to use the authorization code instead of the implicit grant in call cases i=
n his presentation (see https://datatracker.ietf.org/meeting/103/=
materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<=
br>
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy the i=
nformation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> > 
    
> 
    
> _______________________________________________
    
> 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
    

    


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


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

    

--0000000000000017cf057be96cfb--


From nobody Fri Nov 30 14:43:41 2018
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 4B0F0131083 for ; Fri, 30 Nov 2018 14:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 5SQjiu91EYSx for ; Fri, 30 Nov 2018 14:43:38 -0800 (PST)
Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0: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 7BD4E130EC8 for ; Fri, 30 Nov 2018 14:43:38 -0800 (PST)
Received: by mail-it1-x131.google.com with SMTP id a6so812053itl.4 for ; Fri, 30 Nov 2018 14:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=itqU6li7yMqzibCGwXTG0lCUTZ1NyiNQieINqXqGsjI=; b=jk+tfR3W8iAldwdRmxY7W0JhurOaF57zPgO1Oi2iLsL7+w+PgQ9+j6mrSIm7x2ScYE GosS9+TJVjBLnHnVDtM2DL0HiQrc7fzHikVrM3sf9MPTgEfGQNft0IrT/aawVJJeQt3N SGV22tzySdKRWWeeSMozqchTdce3X5urNhSKM=
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=itqU6li7yMqzibCGwXTG0lCUTZ1NyiNQieINqXqGsjI=; b=ih+20ZclXY9CpEOU6gQqIR7Ipy3JpZZiqEzMhuzjnqAwvehiy0/XWqmu9DecFFZt2A KF/x1Z8McsJsPLlwOPz7oRF/3i7h5oQrC7tpDwTW/KzQakU7R3IwiA96PSfG0pd0Qfk3 lAlvxzG+jwwcEWeKJx8/fjvwLhdsqNjsrgfDZwaFJs/hV6e8ig/GR8a3w4OxuDnWr8TI qC6UGM9CLZJPr7grvl252BnTvp2EgGDJ5FFAZJ+xDzLOjnwaSOScBArtpvOynt9T7Lg9 UgZge+0iB15vt+R55zUuuElajXtHBEM2IocFw93lbm8furRFn9cTjgB/GgRKkUBC5T/f fvyA==
X-Gm-Message-State: AA+aEWYAwpf4vEBKFaJfHvNWk9kWs1g1jCGWbU7fXn+6fFz+CTvmhSXm zB2XCd5tPkH+at6mtS+3Y8KA8tDnroTG/wT6sIX0993HidAlCLyojbqkag0YTOKvxaICM5+zrJQ UB//zhQgwR5E06A==
X-Google-Smtp-Source: AFSGD/XUTlD4WnTUOe0DbnbAsrv+l0e/EllOCKqqNNSI7Z0/7RNd7bOxQk3lZYgueH49IN0lquzU7wZnvK7ulEwGi9s=
X-Received: by 2002:a24:85d4:: with SMTP id r203-v6mr601160itd.124.1543617817694;  Fri, 30 Nov 2018 14:43:37 -0800 (PST)
MIME-Version: 1.0
References:   <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net>
In-Reply-To: <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net>
From: Brian Campbell 
Date: Fri, 30 Nov 2018 15:43:11 -0700
Message-ID: 
To: Torsten Lodderstedt 
Cc: Brock Allen , oauth 
Content-Type: multipart/alternative; boundary="000000000000b17322057be98769"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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, 30 Nov 2018 22:43:40 -0000

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

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
wrote:

> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which is still some time off)?
>
> Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based met=
hods for
> sender constraining access tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2=
..2).
> Token Binding for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as
> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-1=
2)
> are the options available.
>

Unfortunately even when using the token endpoint, for SPA / in-browser
client applications, the potential mechanisms for sender/key-constraining
access tokens don't work very well or maybe don't work at all. So I don't
know that the recommendation is very realistic.

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

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




    On Sat=
, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<=
br>
    
> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>:
    
> 
    
> So you mean at the resource server ensuring the token was really issue=
d to the client? Isn't that an inherent limitation of all bearer tokens=
 (modulo HTTP token binding, which is still some time off)?
    

    
Sure. That=E2=80=99s why the Security BCP recommends use of TLS-based metho=
ds for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-top=
ics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://too=
ls.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available. <=
br>

    Unfortunately even when using the token=
 endpoint, for SPA / in-browser client applications, the potential mechanis=
ms for sender/key-constraining access tokens don't work very well or ma=
ybe don't work at all. So I don't know that the recommendation is v=
ery realistic. 

    


    
<=
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.
--000000000000b17322057be98769--


From nobody Fri Nov 30 14:47:43 2018
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 B66E6131047 for ; Fri, 30 Nov 2018 14:47:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level: 
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-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 kGshgWbfMPnl for ; Fri, 30 Nov 2018 14:47:36 -0800 (PST)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87407130F19 for ; Fri, 30 Nov 2018 14:47:36 -0800 (PST)
Received: by mail-oi1-x22e.google.com with SMTP id b141so6107586oii.12 for ; Fri, 30 Nov 2018 14:47:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Wf2uA1TXJc1k5Rkp8aXY8ZVMUdSBCRX+0Y1L7G3UYm0=; b=VODfAfD3z5QMzFEnpg/LVDrYqaIzyCLFNgcxNGWPJXmXp3OySXhoOIjOH/FO/i9CH5 +8XrADQh5HtQ48m0eelUMUdmks6fe6/TeHJVHFXL4HhHtyqdbO1svQXmJCo/jouNGjoC mpnW4t4qfb5EG9hbjyvFXf1PJc0uV9H6hGb+F7YUehcZY6MFbXfWNIXH2t5wSlYCU8O7 /15WZeqPoxfSuoSmO7m9vLtGNDhK0rNv4KqQOQ2WFc/prG/mvEhBVEayG8qoCzcJFZPh pXzLKBiUBc8Cj0zreqLmvN5v2V7SF9HONuoNYAWstt4s0aAAyV+XaddvsK6FE+yb8dSz UTXA==
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=Wf2uA1TXJc1k5Rkp8aXY8ZVMUdSBCRX+0Y1L7G3UYm0=; b=a8vPH2al7CzNycGf6JP0MOtNM3kusH+pqz2rAYGDSezW2oy7/ZWCr8uo5JHDRWLw7x QCzhIK1shHIw1j5Zrz5FGvlW+f884iFXZdo/skHzYbEBjjJl3hByWp5mk4BUJDyePZCI lp/2J59G12UuQgMN3CRZgp773ETdKUkV7wbtlEw4eL2lkEZzc451EJcfIz4QWJApjo9P NUo/eumGHE3YqJAQOppbIycglX8tXuw3gatr6MJBOedgtohzTHB6uP2KTBikiKMfxpZR WlFzFTVwuLXs3G8aWEw+Diyx0e0BwLKh/noEvnII1qC6DohIQm2x1FcWLtkw764cnvdd LXXA==
X-Gm-Message-State: AA+aEWZQJsclCbOmZTL66hv/X7YwDf1YFvIUhGikBHyY/zi43z8zOlO+ Hqz2StxN9JuKw5+9fBB4TPVlXkDDoGMysCIBSBuyM+Gl
X-Google-Smtp-Source: AFSGD/W1OejQNkRy8aoOOwNWlxKZcj9ftXk737PuWoVldh7oEhOGEilEm4Kb8KOJa06mhP+yWd0l6VwTbAhyciROxxw=
X-Received: by 2002:aca:4208:: with SMTP id p8mr4658026oia.331.1543618055375;  Fri, 30 Nov 2018 14:47:35 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>      <558F050A-AC67-45B5-8D55-A025444539A2@lodderstedt.net>  
In-Reply-To: 
From: Jim Willeke 
Date: Fri, 30 Nov 2018 17:46:58 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000dc2309057be99527"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 30 Nov 2018 22:47:41 -0000

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

+1 for the change.
--
-jim
Jim Willeke


On Fri, Nov 30, 2018 at 5:36 PM Dick Hardt  wrote:

> + 1 to the change
>
> I'd suggest we work to define terms such as "sender constrained" in the
> BCP so that it is clear what is meant by it.
>
> On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
>
>> Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
>> constrained might be more appropriate. But the Security Topics document
>> probably should allow for both/either.
>>
>> I don't think that these are necessarily terms with widely agreed upon o=
r
>> understood meaning. But it was pointed out to me that the OAuth 2.0 Pop
>> Architecture draft defines sender constraint and key confirmation as
>> different things (
>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section=
-6.2
>> and
>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section=
-6.3
>> ).
>> And the definitions their do kind of make sense when thinking about the
>> words used. The line between sender and key constrained isn't exactly cl=
ear
>> but it seems MTLS and token binding access tokens are more key constrain=
ed
>> than sender. The -08 version of the MTLS draft dropped the use of the
>> "sender constrained" terminology based on that feedback.
>>
>> I dunno. Maybe the Security Topics could say something in a terminology
>> section that says when sender or key constrained is used within they can=
 be
>> taken to mean the same concept. Or something like that.
>>
>> On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>>
>>> Hi Brian,
>>>
>>> we use =E2=80=9Esender constrained tokens=E2=80=9C throughout the BCP t=
o denote tokens
>>> bound to a sender in possession of a certain key/secret and I thought t=
hat
>>> was established terminology in the group. Are you suggesting =E2=80=9Ek=
ey
>>> constrained=E2=80=9D would be more appropriate?
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> Am 30.11.2018 um 21:02 schrieb Brian Campbell <
>>> bcampbell@pingidentity.com>:
>>>
>>> As was pointed out to me in WGLC review of the MTLS document,
>>> "sender-constrained" has or is likely to be interpreted with a pretty
>>> specific meaning of the token being bound to the client and the client
>>> authenticating itself to the resource and the resource checking all tha=
t
>>> matches up. That makes the text more restrictive than is likely intende=
d.
>>> Perhaps the text should say something like "sender or key constrained" =
to
>>> allow for different variants of PoP access tokens?
>>>
>>>
>>>
>>> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>>
>>>> Hi all,
>>>>
>>>> based on your feedback on the list and off list, Daniel and I polished
>>>> the text. That=E2=80=99s our proposal:
>>>>
>>>> =E2=80=94
>>>> In order to avoid these issues, clients MUST NOT use the implicit
>>>> grant (response type "token") or any other response type issuing acces=
s
>>>> tokens in the authorization response, such as "token id_token" and
>>>> "code token id_token=E2=80=9C,
>>>> unless the issued access tokens are sender-constrained and access toke=
n
>>>> injection in
>>>> the authorization response is prevented.
>>>> =E2=80=94
>>>>
>>>> Explantation:
>>>> - we wanted to have the right balance between a generic definition of
>>>> the response types we do not recommend/allow to be used and a
>>>> concrete/actionable list of the affected response types.
>>>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and
>>>> supported by William
>>>>
>>>> We look forward to seeing your feedback.
>>>>
>>>> kind regards,
>>>> Torsten.
>>>>
>>>> > Am 29.11.2018 um 15:15 schrieb John Bradley :
>>>> >
>>>> > I am ok with that.
>>>> >
>>>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
>>>> torsten@lodderstedt.net wrote:
>>>> >
>>>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
>>>> > >
>>>> > > That works.
>>>> >
>>>> > Good!
>>>> >
>>>> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C =
(only). It would
>>>> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender con=
strained. This
>>>> completely ignores the fact implicit also shall be abandoned because o=
f its
>>>> vulnerability for access token injection.
>>>> >
>>>> > I therefore propose a modified text:
>>>> >
>>>> >    In order to avoid these issues, Clients SHOULD NOT use the implic=
it
>>>> >    grant. Furthermore, clients SHOULD only use other response types
>>>> causing the authorization server to
>>>> >    issue an access token in the authorization response, if the
>>>> particular response type detects access token
>>>> >    injection and the issued access tokens are sender-constrained.
>>>> >
>>>> > Or we just state:
>>>> >
>>>> >   In order to avoid these issues, Clients SHOULD NOT use the respons=
e
>>>> type =E2=80=9Etoken". The response types
>>>> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the
>>>> issued access tokens are not
>>>> > sender-constrained.
>>>> >
>>>> > >
>>>> > > In fact, I would further go and say MUST NOT but that probably is
>>>> too much for a security consideration.
>>>> > >
>>>> >
>>>> > Mike suggested to go with a SHOULD NOT to get the message out but
>>>> give implementors time to move/change.
>>>> >
>>>> > > Best,
>>>> > >
>>>> > > Nat
>>>> > >
>>>> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
>>>> > >
>>>> > >
>>>> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=
=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=
=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=
=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=
=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=
=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=
=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=
=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=
=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=
=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=
=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=
=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=
=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=
=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
>>>> > >
>>>> > > PLEASE READ :This e-mail is confidential and intended for the name=
d
>>>> recipient only.
>>>> > > If you are not an intended recipient, please notify the sender and
>>>> delete this e-mail.
>>>> > >
>>>> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
>>>> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5,=
 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
>>>> > > =E5=AE=9B=E5=85=88: n-sakimura
>>>> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
>>>> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recomm=
end authorization
>>>> code instead of implicit
>>>> > >
>>>> > > Hi Nat,
>>>> > >
>>>> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>>>> > >>
>>>> > >> I would support
>>>> > >>
>>>> > >> 1) clearly defining Implicit as the flow that returns access toke=
n
>>>> from the authorization endpoint ( some people confuses implicit as the=
 flow
>>>> that returns ID Token in the front channel)
>>>> > >
>>>> > > That=E2=80=99s the current text:
>>>> > >
>>>> > > In order to avoid these issues, Clients SHOULD NOT use the implici=
t
>>>> > >    grant or any other response type causing the authorization
>>>> server to
>>>> > >    issue an access token in the authorization response.
>>>> > >
>>>> > > What would you like to modify?
>>>> > >
>>>> > >>
>>>> > >> 2) Banning the returning of the access token that are not sender
>>>> constrained from the authorization endpoint
>>>> > >
>>>> > > In order to avoid these issues, Clients SHOULD NOT use the implici=
t
>>>> > >    grant or any other response type causing the authorization
>>>> server to
>>>> > >    issue an access token in the authorization response, if this
>>>> access tokens is not sender-constraint.
>>>> > >
>>>> > > What about this?
>>>> > >
>>>> > > kind regards,
>>>> > > Torsten.
>>>> > >
>>>> > >>
>>>> > >> Best,
>>>> > >>
>>>> > >> Nat
>>>> > >>
>>>> > >>
>>>> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
>>>> > >>
>>>> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick=
 Hardt <
>>>> dick.hardt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
>>>> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
>>>> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
>>>> > >> Cc: oauth@ietf.org
>>>> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend
>>>> authorization code instead of implicit
>>>> > >>
>>>> > >> +1
>>>> > >>
>>>> > >> While there are various mechanisms to alleviate some of the issue=
s
>>>> of implicit, I don't think we can recommend specifics, and there may b=
e
>>>> future ones in the future. I think we all agree that implicit without =
any
>>>> mitigation is problematic.
>>>> > >>
>>>> > >> How about we recommend against using implicit alone?
>>>> > >>
>>>> > >>
>>>> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
>>>> Hannes.Tschofenig@arm.com> wrote:
>>>> > >> Hi all,
>>>> > >>
>>>> > >> The authors of the OAuth Security Topics draft came to the
>>>> conclusion that it is not possible to adequately secure the implicit f=
low
>>>> against token injection since potential solutions like token binding o=
r
>>>> JARM are in an early stage of adoption. For this reason, and since COR=
S
>>>> allows browser-based apps to send requests to the token endpoint, Tors=
ten
>>>> suggested to use the authorization code instead of the implicit grant =
in
>>>> call cases in his presentation (see
>>>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-se=
ssb-draft-ietf-oauth-security-topics-01
>>>> ).
>>>> > >>
>>>> > >> A hum in the room at IETF#103 concluded strong support for his
>>>> recommendations. We would like to confirm the discussion on the list.
>>>> > >>
>>>> > >> Please provide a response by December 3rd.
>>>> > >>
>>>> > >> Ciao
>>>> > >>
>>>> > >> Hannes & Rifaat
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> IMPORTANT NOTICE: The contents of this email and any attachments
>>>> are confidential and may also be privileged. If you are not the intend=
ed
>>>> recipient, please notify the sender immediately and do not disclose th=
e
>>>> contents to any other person, use it for any purpose, or store or copy=
 the
>>>> information in any medium. Thank you.
>>>> > >> _______________________________________________
>>>> > >> OAuth mailing list
>>>> > >> OAuth@ietf.org
>>>> > >> https://www.ietf.org/mailman/listinfo/oauth
>>>> > >> _______________________________________________
>>>> > >> OAuth mailing list
>>>> > >> OAuth@ietf.org
>>>> > >> https://www.ietf.org/mailman/listinfo/oauth
>>>> > >
>>>> >
>>>> > _______________________________________________
>>>> > OAuth mailing list
>>>> > OAuth@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> 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.*
>>>
>>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited...  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and any f=
ile
>> attachments from your computer. Thank you.*
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


    +1 for the change.
    --
    -jim
    Jim Willeke


    On Fri, Nov 30, 2018 at=
 5:36 PM Dick Hardt <dick.hardt@=
gmail.com> wrote:
    + 1 to the change

    I'd suggest we work t=
o define terms such as "sender constrained" in the BCP so that it=
 is clear what is meant by it.

    On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell <bcampbell=
=3D4=
0pingidentity.com@dmarc.ietf.org> wrote:
    Kind of, yes. I guess so. I think. It's =
just semantics. But yeah. Key constrained might be more appropriate. But th=
e Security Topics document probably should allow for both/either. 

    I don't think that these are necessarily terms wit=
h widely agreed upon or understood meaning. But it was pointed out to me th=
at the OAuth 2.0 Pop Architecture draft defines sender=
 constraint and key confirmation as diff=
erent things (https://to=
ols.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2 and =
https://tools.ietf.org/html/draft-ietf-oau=
th-pop-architecture-08#section-6.3). And the definitions their do kind =
of make sense when thinking about the words used. The line between sender a=
nd key constrained isn't exactly clear but it seems MTLS and token bind=
ing access tokens are more key constrained than sender. The -08 version of =
the MTLS draft dropped the use of the "sender constrained" termin=
ology based on that feedback. 

    I dunno. Maybe =
the Security Topics could say something in a terminology section that says =
when sender or key constrained is used within they can be taken to mean the=
 same concept. Or something like that. 

    On Fri, Nov 30, 2018 at=
 1:42 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Brian,

    we use =E2=
=80=9Esender constrained tokens=E2=80=9C throughout the BCP to denote token=
s bound to a sender in possession of a certain key/secret and I thought tha=
t was established terminology in the group. Are you suggesting =E2=80=9Ekey=
 constrained=E2=80=9D would be more appropriate?

    =

    kind regards,
    Torsten.

    Am 30.11.2018 um 21:02 schrieb Brian Campbell <bcampbell@pingide=
ntity.com>:

    =

    As was pointed out to me in WGLC review of the MTLS d=
ocument, "sender-constrained" has or is likely to be interpreted =
with a pretty specific meaning of the token being bound to the client and t=
he client authenticating itself to the resource and the resource checking a=
ll that matches up. That makes the text more restrictive than is likely int=
ended. Perhaps the text should say something like "sender or key const=
rained" to allow for different variants of PoP access tokens? 



    On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <torsten@lodderstedt.n=
et> wrote:
    Hi all, 
    

    
based on your feedback on the list and off list, Daniel and I polished the =
text. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing =
access 
    
tokens in the authorization response, such as "token id_token" an=
d "code token id_token=E2=80=9C, 
    
unless the issued access tokens are sender-constrained and access token inj=
ection in 
    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionabl=
e list of the affected response types. 
    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported =
by William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.=C2=A0 
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr=
ote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token 
    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig;     oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick =
Hardt <dick.ha=
rdt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth=
@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a=
rm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this reason, and since CORS allows br=
owser-based apps to send requests to the token endpoint, Torsten suggested =
to use the authorization code instead of the implicit grant in call cases i=
n his presentation (see https://datatracker.ietf.org/meeting/103/=
materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<=
br>
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy the i=
nformation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> > 
    
> 
    
> _______________________________________________
    
> 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
    

    


    
<=
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 t=
he sender immediately by e-mail and delete the message and any file attachm=
ents from your computer. Thank you.
    


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

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

    

--000000000000dc2309057be99527--


From nobody Fri Nov 30 18:18:18 2018
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 C13D712D4EF for ; Fri, 30 Nov 2018 18:18:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqdun-Q5ROzM for ; Fri, 30 Nov 2018 18:18:14 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56911293FB for ; Fri, 30 Nov 2018 18:18:13 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id u19so6131021ioc.2 for ; Fri, 30 Nov 2018 18:18:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pLSd8NtgZ59CuEZKrHXnMjnH5WMcCZINONYZBzlWeuY=; b=REJqW7V/vsYmWPKrPuLqarCPBELrC5BcbXnGXuqg2QKTgz5O2MNCThfU8smysPnLwM eda+omikYTsLSJos5EsbgoMZY6oL2k8Vpc8/cfWjmzQmikDWub+xc1wHMTEFQnORa1y0 OawK6C4R2Ol1huhgup5G5x2qDCh3jCw7WMiDXboOt8m4zvSeCS1QTnUzqgqkp0OIqrGl +nSE0gzAsks44AGKKYZTTT0Atp/Fi8jZvZTczbDKE1+N60XgXDFy78XF0DgshYNPu2Fe Wk1tTT/X6AlnLG+HgT5Sgu6k+QzywcP9uJL1x4UJVSfXh1NLnTkffAj0yaP6pw2blzsq iWzQ==
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=pLSd8NtgZ59CuEZKrHXnMjnH5WMcCZINONYZBzlWeuY=; b=QiLLo9Z79wHnDK2+hA3GgdeYDaaeYYGqcJxPShUNIYmgjAV/aXZ4+x/y4lut+T59Q5 TIE2GNDW2kefwVLrOSJjtFp5kbfi0i4ZJE/Inx1N96wmRxd/SQ9p3rtekea0bP2NMPsT 48pzEHrcRhZoTeXyjYMWo3rNnM+34zp22/7OGoVFdCmb1v0TQYSjk55IxEdk+lb0sov2 CccWqUoaN2Rg8My9KGa5fkNLrYZXQ2HpOKlDawTHKTwJkYIUasvvcX7pNHQLyqmRQVhD efyqClozP0C0Ljg9o0TiUKYz4wDm+gXu0ffXk2EW1P2j83ckpEOeWhjYjo1H+WQR0jIY RiKw==
X-Gm-Message-State: AA+aEWah0xyMuyxlU+wgVGUEzca8MKvPTbmIm/YugFnh3wQGO2UXud+p aCg+K+0mNW6rduGAYdnssYDNAN5wmNE=
X-Google-Smtp-Source: AFSGD/UvchD3Ljt4zLpuXCAC7lcr8m512ShD/ffwiz1Uro5Y07YQVdCOvHb7JaafRa1OUYlvyjTpWg==
X-Received: by 2002:a6b:7019:: with SMTP id l25mr7073163ioc.145.1543630692586;  Fri, 30 Nov 2018 18:18:12 -0800 (PST)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id u68-v6sm1874339itd.1.2018.11.30.18.18.10 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 18:18:10 -0800 (PST)
Received: by mail-io1-f54.google.com with SMTP id f6so6133687iob.1 for ; Fri, 30 Nov 2018 18:18:10 -0800 (PST)
X-Received: by 2002:a6b:b502:: with SMTP id e2mr6200133iof.43.1543630690131; Fri, 30 Nov 2018 18:18:10 -0800 (PST)
MIME-Version: 1.0
References:    <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net>    
In-Reply-To: 
From: Aaron Parecki 
Date: Fri, 30 Nov 2018 18:17:57 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Torsten Lodderstedt 
Cc: Daniel Fett , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000f32470057bec8678"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Dec 2018 02:18:17 -0000

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

+1

I would also like to ensure there is a clear definition of "sender
constrained" tokens in this BCP.

Aaron


On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished th=
e
> text. That=E2=80=99s our proposal:
>
> =E2=80=94
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response type issuing access
> tokens in the authorization response, such as "token id_token" and "code
> token id_token=E2=80=9C,
> unless the issued access tokens are sender-constrained and access token
> injection in
> the authorization response is prevented.
> =E2=80=94
>
> Explantation:
> - we wanted to have the right balance between a generic definition of the
> response types we do not recommend/allow to be used and a
> concrete/actionable list of the affected response types.
> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supporte=
d
> by William
>
> We look forward to seeing your feedback.
>
> kind regards,
> Torsten.
>
> > Am 29.11.2018 um 15:15 schrieb John Bradley :
> >
> > I am ok with that.
> >
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <
> torsten@lodderstedt.net wrote:
> >
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> > >
> > > That works.
> >
> > Good!
> >
> > I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (on=
ly). It would
> allow =E2=80=9Etoken=E2=80=9C to be used if the token would sender constr=
ained. This
> completely ignores the fact implicit also shall be abandoned because of i=
ts
> vulnerability for access token injection.
> >
> > I therefore propose a modified text:
> >
> >    In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant. Furthermore, clients SHOULD only use other response types
> causing the authorization server to
> >    issue an access token in the authorization response, if the
> particular response type detects access token
> >    injection and the issued access tokens are sender-constrained.
> >
> > Or we just state:
> >
> >   In order to avoid these issues, Clients SHOULD NOT use the response
> type =E2=80=9Etoken". The response types
> > =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=80=
=9C SOULD NOT be used, if the
> issued access tokens are not
> > sender-constrained.
> >
> > >
> > > In fact, I would further go and say MUST NOT but that probably is too
> much for a security consideration.
> > >
> >
> > Mike suggested to go with a SHOULD NOT to get the message out but give
> implementors time to move/change.
> >
> > > Best,
> > >
> > > Nat
> > >
> > > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
> > >
> > >
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=E7=94=B3=
=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=82=93=E3=
=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=8A=E7=9F=
=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=E5=8F=97=
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E5=
=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=
=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=
=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
> > >
> > > PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> > > If you are not an intended recipient, please notify the sender and
> delete this e-mail.
> > >
> > > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt 
> > > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 11=
=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
> > > =E5=AE=9B=E5=85=88: n-sakimura
> > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> > > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommend=
 authorization
> code instead of implicit
> > >
> > > Hi Nat,
> > >
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura :
> > >>
> > >> I would support
> > >>
> > >> 1) clearly defining Implicit as the flow that returns access token
> from the authorization endpoint ( some people confuses implicit as the fl=
ow
> that returns ID Token in the front channel)
> > >
> > > That=E2=80=99s the current text:
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response.
> > >
> > > What would you like to modify?
> > >
> > >>
> > >> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
> > >
> > > In order to avoid these issues, Clients SHOULD NOT use the implicit
> > >    grant or any other response type causing the authorization server =
to
> > >    issue an access token in the authorization response, if this acces=
s
> tokens is not sender-constraint.
> > >
> > > What about this?
> > >
> > > kind regards,
> > > Torsten.
> > >
> > >>
> > >> Best,
> > >>
> > >> Nat
> > >>
> > >>
> > >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
> > >>
> > >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth  (Dick Ha=
rdt 
> =E3=81=AE=E4=BB=A3=E7=90=86)
> > >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5, 1=
1=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
> > >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
> > >> Cc: oauth@ietf.org
> > >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recommen=
d authorization
> code instead of implicit
> > >>
> > >> +1
> > >>
> > >> While there are various mechanisms to alleviate some of the issues o=
f
> implicit, I don't think we can recommend specifics, and there may be futu=
re
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
> > >>
> > >> How about we recommend against using implicit alone?
> > >>
> > >>
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> > >> Hi all,
> > >>
> > >> The authors of the OAuth Security Topics draft came to the conclusio=
n
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM are =
in
> an early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb=
-draft-ietf-oauth-security-topics-01
> ).
> > >>
> > >> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> > >>
> > >> Please provide a response by December 3rd.
> > >>
> > >> Ciao
> > >>
> > >> Hannes & Rifaat
> > >>
> > >>
> > >>
> > >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
----
Aaron Parecki
aaronparecki.com
@aaronpk 

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


    +1

    I would also like to ensure there is a clear definition of "=
sender constrained" tokens in this BCP.

    Aaron


    On Thu, Nov 29, 2018 at 10:06 AM Tors=
ten Lodderstedt <torsten@lodd=
erstedt.net> wrote:
    Hi all, =

    

    
based on your feedback on the list and off list, Daniel and I polished the =
text. That=E2=80=99s our proposal:
    

    
=E2=80=94
    
In order to avoid these issues, clients MUST NOT use the implicit
    
grant (response type "token") or any other response type issuing =
access 
    
tokens in the authorization response, such as "token id_token" an=
d "code token id_token=E2=80=9C, 
    
unless the issued access tokens are sender-constrained and access token inj=
ection in 
    
the authorization response is prevented. 
    
=E2=80=94
    

    
Explantation: 
    
- we wanted to have the right balance between a generic definition of the r=
esponse types we do not recommend/allow to be used and a concrete/actionabl=
e list of the affected response types. 
    
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported =
by William
    

    
We look forward to seeing your feedback.
    

    
kind regards,
    
Torsten.=C2=A0 
    

    
> Am 29.11.2018 um 15:15 schrieb John Bradley <ve7jtb@ve7jtb.com>:
    
> 
    
> I am ok with that.=C2=A0 
    
> 
    
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <torsten@lodderstedt.net wr=
ote:
    
> 
    
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@nri.co.jp>:
    
> > 
    
> > That works.
    
> 
    
> Good!
    
> 
    
> I just realized this text has an issue with =E2=80=9Etoken=E2=80=9C (o=
nly). It would allow =E2=80=9Etoken=E2=80=9C to be used if the token would =
sender constrained. This completely ignores the fact implicit also shall be=
 abandoned because of its vulnerability for access token injection. 
    
> 
    
> I therefore propose a modified text: 
    
> 
    
>=C2=A0 =C2=A0 In order to avoid these issues, Clients SHOULD NOT use th=
e implicit
    
>=C2=A0 =C2=A0 grant. Furthermore, clients SHOULD only use other respons=
e types causing the authorization server to
    
>=C2=A0 =C2=A0 issue an access token in the authorization response, if t=
he particular response type detects access token 
    
>=C2=A0 =C2=A0 injection and the issued access tokens are sender-constra=
ined.
    
> 
    
> Or we just state:
    
> 
    
>=C2=A0 =C2=A0In order to avoid these issues, Clients SHOULD NOT use the=
 response type =E2=80=9Etoken". The response types
    
> =E2=80=9Etoken id_token=E2=80=9C and =E2=80=9Ecode token id_token=E2=
=80=9C SOULD NOT be used, if the issued access tokens are not 
    
> sender-constrained.
    
> 
    
> > 
    
> > In fact, I would further go and say MUST NOT but that probably is=
 too much for a security consideration.
    
> > 
    
> 
    
> Mike suggested to go with a SHOULD NOT to get the message out but give=
 implementors time to move/change.
    
> 
    
> > Best,
    
> > 
    
> > Nat
    
> > 
    
> > Nat Sakimura / n-sakimura@nri.co.jp / +81-90-6013-6276
    
> > 
    
> > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=
=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=
=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=
=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=
=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=
=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=
=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E8=AA=A0=E3=81=AB=
=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=9B=E3=
=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7=E3=81=
=8A=E7=9F=A5=E3=82=89=E3=81=9B=E9=A0=82=E3=81=8D=E3=80=81=E3=81=BE=E3=81=9F=
=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=
=81=AF=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=
=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=
=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
    
> > 
    
> > PLEASE READ :This e-mail is confidential and intended for the nam=
ed recipient only.
    
> > If you are not an intended recipient, please notify the sender an=
d delete this e-mail.
    
> >=C2=A0 
    
> > =E5=B7=AE=E5=87=BA=E4=BA=BA: Torsten Lodderstedt <torsten@lodderstedt.net>
    
> > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=97=A5=
, 11=E6=9C=88 28, 2018 11:38 =E5=8D=88=E5=BE=8C
    
> > =E5=AE=9B=E5=85=88: n-sakimura
    
> > Cc: Dick Hardt; Hannes Tschofenig;     oauth@ietf.org
    
> > =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- Recom=
mend authorization code instead of implicit
    
> >=C2=A0 
    
> > Hi Nat, 
    
> > 
    
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakimura@nri.co.jp>:
> >> 
    
> >> I would support
    
> >> 
    
> >> 1) clearly defining Implicit as the flow that returns access =
token from the authorization endpoint ( some people confuses implicit as th=
e flow that returns ID Token in the front channel)
    
> > 
    
> > That=E2=80=99s the current text: 
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response.=

    
> > 
    
> > What would you like to modify? 
    
> > 
    
> >> 
    
> >> 2) Banning the returning of the access token that are not sen=
der constrained from the authorization endpoint
    
> > 
    
> > In order to avoid these issues, Clients SHOULD NOT use the implic=
it
    
> >=C2=A0 =C2=A0 grant or any other response type causing the authori=
zation server to
    
> >=C2=A0 =C2=A0 issue an access token in the authorization response,=
 if this access tokens is not sender-constraint.
    
> > 
    
> > What about this?
    
> > 
    
> > kind regards,
    
> > Torsten.
    
> > 
    
> >> 
    
> >> Best,
    
> >> 
    
> >> Nat
    
> >> 
    
> >> 
    
> >> Outlook for iOS =E3=82=92=E5=85=A5=E6=89=8B
    
> >>=C2=A0 
    
> >> =E5=B7=AE=E5=87=BA=E4=BA=BA: OAuth <oauth-bounces@ietf.org> (Dick =
Hardt <dick.ha=
rdt@gmail.com> =E3=81=AE=E4=BB=A3=E7=90=86)
    
> >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: =E6=B0=B4=E6=9B=9C=E6=
=97=A5, 11=E6=9C=88 28, 2018 8:58 =E5=8D=88=E5=BE=8C
    
> >> =E5=AE=9B=E5=85=88: Hannes Tschofenig
    
> >> Cc: oauth=
@ietf.org
    
> >> =E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] OAuth Security Topics -- R=
ecommend authorization code instead of implicit
    
> >>=C2=A0 
    
> >> +1
    
> >> 
    
> >> While there are various mechanisms to alleviate some of the i=
ssues of implicit, I don't think we can recommend specifics, and there =
may be future ones in the future. I think we all agree that implicit withou=
t any mitigation is problematic. 
    
> >> 
    
> >> How about we recommend against using implicit alone? 
    
> >> 
    
> >> 
    
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@a=
rm.com> wrote:
    
> >> Hi all,
    
> >> 
    
> >> The authors of the OAuth Security Topics draft came to the co=
nclusion that it is not possible to adequately secure the implicit flow aga=
inst token injection since potential solutions like token binding or JARM a=
re in an early stage of adoption. For this reason, and since CORS allows br=
owser-based apps to send requests to the token endpoint, Torsten suggested =
to use the authorization code instead of the implicit grant in call cases i=
n his presentation (see https://datatracker.ietf.org/meeting/103/=
materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).<=
br>
> >> 
    
> >> A hum in the room at IETF#103 concluded strong support for hi=
s recommendations. We would like to confirm the discussion on the list.
    
> >> 
    
> >> Please provide a response by December 3rd.
    
> >> 
    
> >> Ciao
    
> >> 
    
> >> Hannes & Rifaat
    
> >> 
    
> >>=C2=A0 
    
> >> 
    
> >> IMPORTANT NOTICE: The contents of this email and any attachme=
nts are confidential and may also be privileged. If you are not the intende=
d recipient, please notify the sender immediately and do not disclose the c=
ontents to any other person, use it for any purpose, or store or copy the i=
nformation in any medium. Thank you.
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> >> _______________________________________________
    
> >> OAuth mailing list
    
> >> OAuth@iet=
f.org
    
> >> https://www.ietf.org/mailman/listinfo/oau=
th
    
> > 
    
> 
    
> _______________________________________________
    
> 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
    

    -- 
    ----
    Aaron Parecki
    <=
div>aaronparecki.com<=
/a>

    

--000000000000f32470057bec8678--