Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD241201CF for ; Thu, 25 Jul 2019 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQqNFfEgueKc for ; Thu, 25 Jul 2019 12:01:59 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44A91201C9 for ; Thu, 25 Jul 2019 12:01:59 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id c2so23727328plz.13 for ; Thu, 25 Jul 2019 12:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ti9CWX6wlRJE82DmdueofLymWpMc425Mrov1vFW5YxQ=; b=EQizy8YSTcqm5S79/rhnLNAGlzOXDlmNoCFAhj7uBZNPPD6ulLf6FKeZu8xTth40Ot vpGhpsURiKSy50sukzIfgppUHYQIrrfmetQsazXlQOj84rDZMrkLKUEHEmWgWjHNAlDp OXOxVZkd6E+1KOrUUSDx0dMBfgTq4hr3knV/nmR/Z04ZzVce1kRF83mzYFYWxCXC4nF+ ZkJtZESnpJr0P28FaEcVHrofPsxVTlCtK+uDl8DckQN1yIUPdYTFr+LUORguZ11x3rwU PngzhR0cuoolQuN0Yx+VEFfNZYgntmWSQznaL0dyReXSeCpj7coQi4ie4wTkP/2HXhxI yENA== 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=Ti9CWX6wlRJE82DmdueofLymWpMc425Mrov1vFW5YxQ=; b=kIkiel7ZWi7mrDFdBRsDp8xzo5Iz+yJpZorFjMO9V/HKGchylCNSx6R07y/XifB7fi cJcay/fBiIPknxADpwfIzrlSMqOQHITrRXvm/Pn45EcV7nE1e/iH0jgl8GN8LboH691d zn8FgfFVTIAhB8lUf3S9ewmF49tmBk1HrKOXe2/4vSuKl0/sfEfI/NrRbKHnECwEl1P3 HJouiOjgza+G+EkvijzWdBoNm7uggPpgicEg8yovJ9LkunL9aons//fvTNiClHss5Pw8 0YAVFiSI/9ME3M5bE9iiBHGt3n5Ki4yMX/zF6fU7NANMvRcWI7GYDA+e6sREmcMPMViq 6r7A== X-Gm-Message-State: APjAAAW+cRFEZkS5K33cyTlc7ZbiPBoDwzoyYC1bVrXqCFHQOQhOdYss qdxdyruEF85cnogJO8ScIwwm2jdfyHpUQE52EL4= X-Google-Smtp-Source: APXvYqxMp2Y6FjhCKZSMZPw2NOkxRsjBhTmiRWbpK9mN2hjukhCPlPkQ8kYOD0NUZn8YqQzMYI/z21XavUM1T30KoaM= X-Received: by 2002:a17:902:4401:: with SMTP id k1mr68682980pld.193.1564081318890; Thu, 25 Jul 2019 12:01:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Leo Tohill Date: Thu, 25 Jul 2019 15:01:48 -0400 Message-ID: To: Justin Richer Cc: Filip Skokan , OAuth WG Content-Type: multipart/alternative; boundary="000000000000699798058e860f9d" Archived-At: Subject: Re: [OAUTH-WG] Feedback on OAuth 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: Thu, 25 Jul 2019 19:02:11 -0000 --000000000000699798058e860f9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I agree, I removed the mention of OIDC. If that means you'd leave the OAuth prohibition, it's still misleading or confusing. OIDC is of course an extension of or layer over OAuth. If you prohibit OAuth, you prohibit OIDC. You don't mean it that way, but that's the way it reads. On Thu, Jul 25, 2019 at 12:51 PM Justin Richer wrote: > I also think it would be useful, but a problem is that things like > =E2=80=9Capplication type=E2=80=9D are usually a stand in for a whole bun= ch of different > attributes that we actually care about. That=E2=80=99s what happened with > web/native and why, to my knowledge, nobody really uses those in lieu of > things like public/confidential and redirect URI locations instead for > policy decisions. If we do enumerate these, we would also need to enumera= te > all of the things it means. > > I tried to shy away from =E2=80=9Capplication type=E2=80=9D style switche= s in XYZ=E2=80=99s straw > man, and instead opt for recipes of applying the different options to > different kinds of clients. I don=E2=80=99t know how long that will hold = up though. > > =E2=80=94 Justin > > On Jul 25, 2019, at 8:11 AM, Filip Skokan wrote: > > Obviously it can do it on a per-client basis still, but now an AS is goin= g >> to have to know a bit more about the app itself. Perhaps we finally need= a >> few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata para= meter from OIDC=E2=80=99s >> extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80= =9D? But we at least probably want >> to point out to AS implementors that this is something they want to >> consider tracking in their data model for clients. >> > > I would very much like to see that. native/web possibly in combination > with token_endpoint_auth_method and the client being DCR or "static" is f= ar > from being enough to make a policy decision. > > S pozdravem, > *Filip Skokan* > > > On Thu, 25 Jul 2019 at 13:45, Justin Richer wrote: > >> This raises an interesting question that I don=E2=80=99t think we=E2=80= =99ve addressed >> yet: how to appropriately vary token lifetimes and access for different >> clients. >> >> Previously, an AS could see that a client was using the implicit flow an= d >> decide to limit token lifetimes or scopes based on that alone. Similarly= , I >> know of at least some AS implementations that let you limit what scopes = you >> allow under the client credentials grant. The key issue is that if all y= our >> clients are using the auth code flow (which I agree they should), then h= ow >> does an AS tell the difference in capabilities between incoming clients? >> >> Obviously it can do it on a per-client basis still, but now an AS is >> going to have to know a bit more about the app itself. Perhaps we finall= y >> need a few more entries in the =E2=80=9Capplication_type=E2=80=9D metada= ta parameter from >> OIDC=E2=80=99s extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2= =80=9Cweb=E2=80=9D? But we at least >> probably want to point out to AS implementors that this is something the= y >> want to consider tracking in their data model for clients. >> >> =E2=80=94 Justin >> >> On Jul 25, 2019, at 4:04 AM, David Waite >> wrote: >> >> >> >> >> On Jul 24, 2019, at 3:03 PM, Aaron Parecki wrote: >> >> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier >> wrote: >> >> >> >> I would rather say that ANY JS app should use CSP to lock down the >> browser features to a minimal attack surface. In addition, if refresh or >> access tokens are involved - further settings like disabling inline >> scripting (unsafe inline) and eval should be disabled. >> >> >> I'm not sure what to do with this suggestion. It feels like a blanket >> recommendation of enabling CSP will likely be ignored since it's too >> broad, and recommending disabling inline scripts is overreaching >> unless backed up by a specific threat it's protecting against. Did you >> have a particular threat in mind? >> >> >> I would say that browser applications should take measures to harden >> their applications again code injection and arbitrary code execution. >> Examples include eliminating inline script (and limiting embeddable obje= cts >> as much as possible) via CSP, and versioning third party resources via >> techniques like subresource integrity. Mechanisms such as augmenting th= e >> codebase to make sure all appropriate user input, data storage, and outp= ut >> properly sanitize data may be used - although they may be more expensive= to >> implement and audit. >> >> The AS should likewise take into account an application=E2=80=99s overal= l >> security posture when deciding appropriate policies around delegated >> authorization scopes and token lifetimes. >> >> Best current practices include turning the screws tightly around CSP. Bu= t >> it is (theoretically) possible to accomplish the same with brute-force >> sanitization, which has been made simpler with framework support. It is >> still ultimately the AS job to decide which clients have which capabilit= ies. >> >> -DW >> _______________________________________________ >> OAuth 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 > --000000000000699798058e860f9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I agree, I removed the mention of= OIDC.

If that= means you'd leave the OAuth prohibition, it's still misleading or = confusing.=C2=A0 OIDC is of course an extension of or layer over OAuth.=C2= =A0 If you prohibit OAuth, you prohibit OIDC. You don't mean it that wa= y, but that's the way it reads.
=C2=A0

= On Thu, Jul 25, 2019 at 12:51 PM Justin Richer <jricher@mit.edu> wrote:
I also think it would be useful, but a problem is that things like =E2=80= =9Capplication type=E2=80=9D are usually a stand in for a whole bunch of di= fferent attributes that we actually care about. That=E2=80=99s what happene= d with web/native and why, to my knowledge, nobody really uses those in lieu of things like public/confidential and redirect URI loc= ations instead for policy decisions. If we do enumerate these, we would als= o need to enumerate all of the things it means.=C2=A0

I tried to shy away from =E2=80=9Capplication type=E2=80=9D style swit= ches in XYZ=E2=80=99s straw man, and instead opt for recipes of applying th= e different options to different kinds of clients. I don=E2=80=99t know how= long that will hold up though.

=E2=80=94 Justin

On Jul 25, 2019, at 8:11 AM, Filip Skokan <panva.ip@gmail.com> wrote:

Obviously it can do it on a per-client basis still, but now an AS is g= oing to have to know a bit more about the app itself. Perhaps we finally ne= ed a few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata pa= rameter from OIDC=E2=80=99s extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=9D? But we = at least probably want to point out to AS implementors that this is somethi= ng they want to consider tracking in their data model for clients.

I would very much like to see that. native/web possibly in combination= with token_endpoint_auth_method and the client being DCR or "static&q= uot; is far from being enough to make a policy decision.

S poz= dravem,
Filip Skokan


On Thu, 25 Jul 2019 at 13:45, Justin = Richer <jricher@mit= .edu> wrote:
This raises an interesting question that I don=E2=80=99t think we=E2= =80=99ve addressed yet: how to appropriately vary token lifetimes and acces= s for different clients.

Previously, an AS could see that a client was using the implicit flow = and decide to limit token lifetimes or scopes based on that alone. Similarl= y, I know of at least some AS implementations that let you limit what scope= s you allow under the client credentials grant. The key issue is that if all your clients are using the= auth code flow (which I agree they should), then how does an AS tell the d= ifference in capabilities between incoming clients?=C2=A0

Obviously it can do it on a per-client basis still, but now an AS is g= oing to have to know a bit more about the app itself. Perhaps we finally ne= ed a few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata pa= rameter from OIDC=E2=80=99s extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=9D? But we at least probab= ly want to point out to AS implementors that this is something they want to= consider tracking in their data model for clients.

=E2=80=94 Justin

On Jul 25, 2019, at 4:04 AM, David Waite <david@alkaline-solutions.com&g= t; wrote:




On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aaron@parecki.com&= gt; wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
<dbaier@l= eastprivilege.com> wrote:

<snip>

I would rather say that ANY JS app should use CSP= to lock down the browser features to a minimal attack surface. In addition= , if refresh or access tokens are involved - further settings like disablin= g inline scripting (unsafe inline) and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket recommendation of enabling CSP will likely be ignored since it's too broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you<= br> have a particular threat in mind?

I would say that browser applications should take measures to harden their = applications again code injection and arbitrary code execution. Examples in= clude eliminating inline script (and limiting embeddable objects as much as= possible) via CSP, and versioning third party resources via techniques like subresource integrity.=C2=A0 Mec= hanisms such as augmenting the codebase to make sure all appropriate user i= nput, data storage, and output properly sanitize data may be used - althoug= h they may be more expensive to implement and audit.

The AS should likewise take into account an application=E2=80=99s overall s= ecurity posture when deciding appropriate policies around delegated authori= zation scopes and token lifetimes.

Best current practices include turning the screws tightly around CSP. But i= t is (theoretically) possible to accomplish the same with brute-force sanit= ization, which has been made simpler with framework support. It is still ul= timately the AS job to decide which clients have which capabilities.

-DW
_______________________________________________
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

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