From nobody Tue May 1 02: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 6AC86126BF7 for ; Tue, 1 May 2018 02:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 zBSxVV1RaLBP for ; Tue, 1 May 2018 02:08:23 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A952120047 for ; Tue, 1 May 2018 02:08:22 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id j4so16934020wme.1 for ; Tue, 01 May 2018 02:08:22 -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=f14MbIKECY/iOH9hz5spU72zP6RSGNDaEUSKpmEKkk4=; b=ae3/tbgKblTXdLCrbx58V1Ktl66QC7e5QFUHoK+q4HvYRjCqPZXsqxDg/6QlBjRuS3 i7Opzh1XJadquSfivfItrBNJtyeajyw+dvqDhX+HZXiHrf5uOvqUDrqCVZnl1sJe2R8Y kgI8ScgkvxGj7zXLL1wIdd0qDIvYiWh7URdkk= 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=f14MbIKECY/iOH9hz5spU72zP6RSGNDaEUSKpmEKkk4=; b=UQgiudDknnBLF1qZClsTd/fZVMQPAlR/O3biw5IBJJnxTsHEm4qq43vdD3Dwv3BHCq VCo/AeIfEyrI9MLCF06XeGuWVqca7wQu3gonuNB8xNpGqFJiGl7fecr+Xg/PT22ARIRk c2RkqqVx1hznyGBJba13toBCrVfY6CclayeuXj+x1i51sLXyhcOGJlt6LIERPNapGyJ5 1boQFiPqW3nkYNl5Me+f0XyELdX70+Pb4nzVBUMvXTfeQLgQlsfKqnWUA5hTBcR8ASEf SJdG8HuqMpzgedCWjA7lpHppgrCDsj4VayHkaUEP6xT59Zlzca+ANhBk8er22fp8Uqah d1sw== X-Gm-Message-State: ALQs6tCqA+lsiC1HYId7mXGHydLGarlHkDzoen7Pvr3gADa/Yr5R/eCu YunPqykVVL7VbBYll02EoWWGaA== X-Google-Smtp-Source: AB8JxZrAT1/Eny9fIfY38gG8MIb5Mrx627C28mVXhrvArixol6KtQequ371ET583VjmQpuJCN6cexA== X-Received: by 10.28.12.134 with SMTP id 128mr8667386wmm.18.1525165701176; Tue, 01 May 2018 02:08:21 -0700 (PDT) Received: from guest2s-mbp.home (72.142.200.146.dyn.plus.net. [146.200.142.72]) by smtp.gmail.com with ESMTPSA id y9-v6sm9127737wrh.63.2018.05.01.02.08.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 02:08:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Neil Madden In-Reply-To: <2B100423-8427-4E02-BFBE-82FAEF873666@ve7jtb.com> Date: Tue, 1 May 2018 10:08:17 +0100 Cc: Brian Campbell , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <55701B63-2B8B-4921-B57A-E6A5638C00C0@forgerock.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> <22823827-5743-4458-8C30-F5F386839630@ve7jtb.com> <2B100423-8427-4E02-BFBE-82FAEF873666@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 09:08:26 -0000 JOSE and many other specs have allowed algorithms to be specified at = multiple security levels: a baseline 128-bit level, and then usually = 192- and 256-bit levels too. It seems odd that a draft that is = ostensibly for high security assurance environments would choose to only = specify the lowest acceptable security level, especially when the = 256-bit level has essentially negligible overhead. (OK, ~60 bytes = additional overhead in a JWT - I=E2=80=99d be surprised if that was a = deal breaker though). Still, if the consensus of the WG is that this is not worth it, then I = don=E2=80=99t want to delay the draft any further. I can always submit a = 2 line RFC in future to add a SHA-512 confirmation method. =E2=80=94 Neil > On 30 Apr 2018, at 23:58, John Bradley wrote: >=20 > We allow for new thumbprint algorithms to be defined and used with = this spec. > I think that we all agree that is a good thing. >=20 > The question is if we should define them here or as part of JWT/CWT = based on broader demand. >=20 > Including them in this document may be a distraction in my opinion. = There is no attack against SHA256 with a short duration token/key (days) = that is better solved by using a long duration token/key (years) with a = longer hash. >=20 > That said it woiulden't like me. I just think it will distract people = in the wrong direction. >=20 > John B. >=20 >> On Apr 30, 2018, at 7:23 PM, Neil Madden = wrote: >>=20 >> Responses inline again.=20 >>=20 >> On Mon, 30 Apr 2018 at 19:44, John Bradley wrote: >> Inline. >>=20 >>=20 >>> On Apr 30, 2018, at 12:57 PM, Neil Madden = wrote: >>>=20 >>> Hi John, >>>=20 >>>> On 30 Apr 2018, at 15:07, John Bradley wrote: >>>>=20 >>>> I lean towards letting new certificate thumbprints be defined = someplace else. >>>>=20 >>>> With SHA256, it is really second preimage resistance that we care = about for a certificate thumbprint, rather than simple collision = resistance. =20 >>>=20 >>> That=E2=80=99s not true if you consider a malicious client. If I can = find any pair of certificates c1 and c2 such that SHA256(c1) =3D=3D = SHA256(c2) then I can present c1 to the AS when I request an access = token and later present c2 to the protected resource when I use it. I = don=E2=80=99t know if there is an actual practical attack based on this, = but a successful attack would violate the security goal implied by the = draft: that that requests made to the protected resource "MUST be made = [=E2=80=A6] using the same certificate that was used for mutual TLS at = the token endpoint.=E2=80=9D >>>=20 >>> NB: this is obviously easier if the client gets to choose its own = client_id, as it can find the colliding certificates and then sign up = with whatever subject ended up in c1. >>>=20 >>=20 >> Both C1 and C2 need to be valid certificates, so not just any = collision will do. =20 >>=20 >> That doesn=E2=80=99t help much. There=E2=80=99s still enough you can = vary in a certificate to generate collisions.=20 >>=20 >> If the client produces C1 and C2 and has the private keys for them, I = have a hard time seeing what advantage it could get by having colliding = certificate hashes. >>=20 >> Me too. But if the security goal is proof of possession, then this = attack (assuming practical collisions) would break that goal.=20 >>=20 >>=20 >> If the AS is trusting a CA, the attacker producing a certificate that = matches the hash of another certificate so that it seems like the fake = certificate was issued by the CA, is an attack that worked on MD5 given = some predictability. That is why we now have entropy requirements for = certificate serial numbers, that reduce known prefix attacks. >>=20 >> The draft allows for self-signed certificates.=20 >>=20 >> Second-preimage Resistance is being computationaly infusible to find = a second preimage that has the same output as the first preimage. The = second preimage strength for SHA256 is 201-256bits and collision = resistance strength is 128 bits. See Appendix A of = https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r= 1.pdf if you want to understand the relationship between message length = and second Preimage resistance. >>=20 >> RFC 4270 is old but still has some relevant info. = https://tools.ietf.org/html/rfc4270 >>=20 >> Think of the confirmation method as the out of band integrity check = for the certificate that is presented in the TLS session. >>=20 >> This is all largely irrelevant.=20 >>=20 >>>> MD5 failed quite badly with chosen prefix collision attacks against = certificates (Thanks to some X.509 extensions). >>>> SHA1 has also been shown to be vulnerable to a PDF chosen prefix = attack (http://shattered.io) >>>>=20 >>>> The reason NIST pushed for development of SHA3 was concern that a = preimage attack might eventually be found agains the SHA2 family of hash = algorithms.=20 >>>>=20 >>>> While SHA512 may have double the number of bytes it may not help = much against a SHA2 preimage attack,. (Some papers suggest that the = double word size of SHA512 it may be more vulnerable than SHA256 to some = attacks) >>>=20 >>> This is really something where the input of a cryptographer would be = welcome. As far as I am aware, the collision resistance of SHA-256 is = still considered at around the 128-bit level, while it is considered at = around the 256-bit level for SHA-512. Absent a total break of SHA2, it = is likely that SHA-512 will remain at a higher security level than = SHA-256 even if both are weakened by cryptanalytic advances. They are = based on the same algorithm, with different parameters and word/block = sizes. >>>=20 >> SHA512 uses double words and more rounds, true. It also has more = rounds broken by known attacks than SHA256 = https://en.wikipedia.org/wiki/SHA-2.. So it is slightly more complex = than doubling the output size doubles the strength. >>=20 >> SHA-512 also has more rounds (80) than SHA-256 (64), so still has = more rounds left to go... >>=20 >>=20 >>>>=20 >>>> It is currently believed that SHA256 has 256 bits of second = preimage strength. That could always turn out to be wrong as SHA2 has = some similarities to SHA1, and yes post quantum that is reduced to = 128bits.=20 >>>>=20 >>>> To have a safe future option we would probably want to go with = SHA3-512. However I don=E2=80=99t see that getting much traction in = the near term. =20 >>>=20 >>> SHA3 is also slower than SHA2 in software. >> Yes roughly half the speed in software but generally faster in = hardware. =20 >>=20 >> I am not necessarily arguing for SHA3, rather I think this issue is = larger than this spec and selecting alternate hashing algorithms for = security should be separate from this spec. >>=20 >> I am for agility, but I don=E2=80=99t want to accidentally have = people doing something that is just theatre. >>=20 >> Rotating certificates, and having the lifetime of a certificates = validity is as useful as doubling the hash size.=20 >>=20 >> Why not allow both?=20 >>=20 >>=20 >> I don=E2=80=99t think the confirmation hash length is the weakest = link. >>=20 >> Shouldn=E2=80=99t we allow all the parts to be as strong as possible? >>=20 >>=20 >> John B. >>=20 >>>=20 >>>>=20 >>>> Practical things people should do run more along the lines of: >>>> 1: Put at least 64 bits of entropy into the certificate serial = number if using self signed or a local CA. Commercial CA need to do = that now. >>>> 2: Rotate certificates on a regular basis, using a registered JWKS = URI >>>>=20 >>>> My concern is that people will see a bigger number and decide it is = better if we define it in the spec. =20 >>>> We may be getting people to do additional work and increasing token = size without a good reason by putting it in the spec directly. >>>=20 >>> I=E2=80=99m not sure why this is a concern. As previously pointed = out, SHA-512 is often *faster* than SHA-256, and an extra 32 bytes = doesn=E2=80=99t seem worth worrying about. >>>=20 >>> [snip] >>>=20 >>> =E2=80=94 Neil >> =E2=80=94 Neil >=20 From nobody Tue May 1 13:16: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 0FF2512EAB3 for ; Tue, 1 May 2018 13:16:51 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kHT9nOz2Iu1G for ; Tue, 1 May 2018 13:16:48 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 8EFF612EAA5 for ; Tue, 1 May 2018 13:16:48 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id j5so20724274wme.5 for ; Tue, 01 May 2018 13:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XfIkVVJDOv0f6tfn8huoBxilcsG2H10nfTzrJO16uEw=; b=NAGYk3uA8Ry9/RdCyEyWcSEIlwk3l+sIczHSptn/6PCZUFxsjKgEpA57FipnI1EWxU 5YWe8aLWrR6oHtoLHkaJzcGAa9JmjCJg3A05PN5MZkHyHBddbbGPu9Ubb7Uwz3nFu2Ck lG8YtToNq2bKUBZ8eDEqjrkJpFGswl5N93kizGyWm7TphrkIN5dHSm+8FDsJNaV9v1TX niGF+760Lu+cQIjMZ3A8uwoqgN8rahzCZJLLfVpsYPZvRM3oG38eb/I19rirN5vGn7hw PkDxP+9sY1PmEtXkKufuGIITciVOTyr7AKL4kAuG1yAw5rf7nwUC/wGhOr5Y60xznqEv jv/Q== 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 :content-transfer-encoding; bh=XfIkVVJDOv0f6tfn8huoBxilcsG2H10nfTzrJO16uEw=; b=Nr+eUUc1ETaauFdAVVrjFNJlEtB4HbDw+qzLzs7lJ942xrPnyNMm0ssQXSySPMROkN ifr50LRTUZOGst6hRsqQPtofXeaJfBeFQEcudqwU9S3RhdVfprPBbJDmNb7IyS3uQg3j kRAQ27KRBm133uh9IpLPaJDITAuiIfR2V6296mk9wS5wUFDVyxh9lYp9zH1ceHlCIpor eNpADHpXXdgQBCKthL3tuxTcs5yBseOm9Cg4od95Yl/mx/Xc7xxWTRjYwcUvKWnQz40y pJPu0El7byGdBBa1v9Gs0J4E+xNfLVoAg8lYaGjKBQi7FeEmZdyLPIcJ4xWeEttO95eR D58w== X-Gm-Message-State: ALQs6tDcwvL5Kuh43yCNww/oAlJhd+Sxc9xws3llhfIiwuk1yeIhMRk8 mUlAXCi+GhPKXh078+l4ZNdiXCq4 X-Google-Smtp-Source: AB8JxZoCwe98fqN4QdVMmt7gn1HlWLnsHVZZdzE1M1ZF6Rvfs2Amdklpq/Ro2vYvJRS+u3b3lYHoyQ== X-Received: by 10.28.218.80 with SMTP id r77mr9774993wmg.105.1525205806768; Tue, 01 May 2018 13:16:46 -0700 (PDT) Received: from [10.0.0.140] (bzq-79-178-9-247.red.bezeqint.net. [79.178.9.247]) by smtp.gmail.com with ESMTPSA id x70sm10741072wma.9.2018.05.01.13.16.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 13:16:45 -0700 (PDT) To: oauth@ietf.org References: From: Yaron Sheffer Message-ID: Date: Tue, 1 May 2018 23:16:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] reference for invalid point attack [-jwt-bcp] ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:16:51 -0000 Will add to the draft. Thank you Jeff! > ------------------------------ > > From: =JeffH > To: IETF OAuth WG > Subject: [OAUTH-WG] reference for invalid point attack [-jwt-bcp] ? > Message-ID: <0c2d1ad2-1239-26e0-87c1-9be2bd1e79c4@KingsMountain.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > In search of CurveSwap: > Measuring elliptic curve implementations in the wild > Luke Valenta, Nick Sullivan, Antonio Sanso, Nadia Heninger > https://eprint.iacr.org/2018/298.pdf (see section 7.1) > > ...is perhaps a suitable reference for section 3.4 of -jwt-bcp ? > > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01#section-3.4 > > > HTH, > =JeffH From nobody Wed May 2 01:26:23 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 5CD491242F5; Wed, 2 May 2018 01:26:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152524957732.10707.10790428000209374707@ietfa.amsl.com> Date: Wed, 02 May 2018 01:26:17 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 08:26:17 -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-02.txt Pages : 13 Date : 2018-05-02 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 2 01:36: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 5B1321270A0 for ; Wed, 2 May 2018 01:36:08 -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, 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 GiG1jyBUxMjh for ; Wed, 2 May 2018 01:36:04 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 2B16F1242F5 for ; Wed, 2 May 2018 01:36:04 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id g21-v6so13044844wrb.8 for ; Wed, 02 May 2018 01:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=M9P4egI/WOll4CuuR5/1UJ6XtroyTWJ3x43U9vT36ps=; b=Q8ZEsOeyBQmrTJL1UhxOIkas3f9jggnRhv3gJVXOHty6Fl2XvEvHvxJc5mpgIstx06 DON2D/bUBHm5sQ4EGNIdV85ZvsEG0g52180DT/XiUzBD0Ry37iHB3s4whsxl4L3CbV0K tSHlGJODMkcKUmejGv30S8P3+JSodVxKBp0gFvTRUxENtddycAH+z3rIkdPi4UFzneBR i0ED3PnS7DlVigmWNucNayfKZd7GbAAlrQadnNbmBo6EB8POgSaZ8Y/0UhX03C/LklkW tZ1+o1VxYohzrTvwhJDlP3iLqa021b7a6fYRwg/JfTcOA9eS8NRWXp34kfVa66gJQkof 6PlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M9P4egI/WOll4CuuR5/1UJ6XtroyTWJ3x43U9vT36ps=; b=RlvpZgfksZDrEU6fKpH1EjtwPWGEpFVjZ4o6vC8JoQUj468mOCR4winye9OfzzRUUT MKw22JJqo7N/jyWGNejMZfiHHMuljLV1jsqJ66xL0cM8y1iwg/htPEJYBIVnTU/sDWXH Ya6sXgMYJVXcObeNxmf12jWmysQ9dKaYHMG62/qQUNNo7fF6RspujONxtZx16q/pL8Dl hUqLFrn3uDWhAjSs0mqEtEUbayoEXwu4Kd4dUYWalHRKxsIJzfKzAWtqr0boNJ9rkIjT H5ooo2ZZtD8tfRtOBEdWiK/6EyAJXVBZQ9+G9ccfptTY7yYhnuJMQIMHyiQmicqFLwB2 ukuQ== X-Gm-Message-State: ALQs6tBx4tkWnwIeU+ejBikmYE4q9dewd2DcnBPGsfePvf3xmn+mL/jp AHgGPmzaEJgr8g/ZgzbDse6pJPV9 X-Google-Smtp-Source: AB8JxZpqdfWM9Zq1C54CPxgzab0CNMi3qGvzG8QyXINNh+7epqUb0V3KaMycZzPqLV1gki0kruQ2DQ== X-Received: by 2002:adf:d245:: with SMTP id o5-v6mr13576031wri.134.1525250162395; Wed, 02 May 2018 01:36:02 -0700 (PDT) Received: from [172.21.2.7] (bzq-164-168-31-230.red.bezeqint.net. [31.168.164.230]) by smtp.gmail.com with ESMTPSA id m134sm13912927wmg.4.2018.05.02.01.36.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 01:36:01 -0700 (PDT) References: <152524957750.10707.16363318021232931449.idtracker@ietfa.amsl.com> To: oauth@ietf.org From: Yaron Sheffer X-Forwarded-Message-Id: <152524957750.10707.16363318021232931449.idtracker@ietfa.amsl.com> Message-ID: <53552a40-c1df-0a97-fce0-4a39c5e32182@gmail.com> Date: Wed, 2 May 2018 11:36:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152524957750.10707.16363318021232931449.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 08:36:08 -0000 This new version should address all WGLC comments. Please let us know if there's anything missing. Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt Date: Wed, 02 May 2018 01:26:17 -0700 From: internet-drafts@ietf.org To: Michael B. Jones , Yaron Sheffer , Dick Hardt , Michael Jones A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-ietf-oauth-jwt-bcp Revision: 02 Title: JSON Web Token Best Current Practices Document date: 2018-05-02 Group: oauth Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-02 Abstract: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed May 2 06:26: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 22952126FDC for ; Wed, 2 May 2018 06:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQJhZWDwStxM for ; Wed, 2 May 2018 06:26:35 -0700 (PDT) Received: from pv42p49im-ztdg05061101.me.com (pv42p49im-ztdg05061101.me.com [17.139.149.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F1D126FB3 for ; Wed, 2 May 2018 06:26:35 -0700 (PDT) Received: from process-dkim-sign-daemon.pv42p49im-ztdg05061101.me.com by pv42p49im-ztdg05061101.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P8300100RYVO300@pv42p49im-ztdg05061101.me.com> for oauth@ietf.org; Wed, 02 May 2018 13:26:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1525267595; bh=/TMDSkPwIOZlJuT6sFI/pMreLP3swqpXP6sloJBwM18=; h=Content-type:From:MIME-version:Date:Message-id:To; b=bMUZ4AqqZ9dniV8rH62HVxZ2ooutI7tgcg4QuxeIItMS2X7GgbwMI1MSgDFh0y1WN MxsAQCq6OmRn95bGITBtNxLvCxXVbbLWOKXAnh+H6FJk1IAKin/Cm5bF5ykqUopMi/ uFtvX5H8SJ8FVJwPadBLr+MpfjyzM4+rBIr9qKz/xrcGovtWzO/C6xOpAe7yF/RttV 379Gq3hQh///N7K0A4JsVGymJl3T9sM0wdnEhjApxnrjkR/4Vjtpn0l8+mdtEgfgjC 2Zs5CZiP6p5BS7e8288utgu8Ia7IR/juWfElWQ0xIxRFDrEDoBdF7XXnU0YlSVcyR6 y89CuSJtatPNg== Received: from icloud.com ([127.0.0.1]) by pv42p49im-ztdg05061101.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P830021XS01TM40@pv42p49im-ztdg05061101.me.com> for oauth@ietf.org; Wed, 02 May 2018 13:26:34 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-05-02_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1805020111 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit From: Woop Crabtree MIME-version: 1.0 (1.0) Date: Wed, 02 May 2018 04:30:06 -0700 Message-id: To: oauth@ietf.org X-Mailer: iPhone Mail (15E216) Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 13:26:38 -0000 Sent from Email From nobody Fri May 4 11:30: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 10BC1129502 for ; Fri, 4 May 2018 11:30:13 -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 mjbqvhvbKpKf for ; Fri, 4 May 2018 11:30:09 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 E81F3124234 for ; Fri, 4 May 2018 11:30:08 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e20-v6so4552275itc.1 for ; Fri, 04 May 2018 11:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cgs5AF+LxCiwsatufJDroKj/F4Dk+2DzH9Cm8Q49820=; b=XfI2BIe3mFYtj7Zv8xI/2t2aa0ctj+rYW/2OKSckgLpmNTSP+VNQgbR65MzlMrOgk9 SeZakxvTrX9UH3+W4itl0lULtN5ky5iPVHx/GLANFB0ipUcqe3cJSVa3yqG5YXPvaks2 +nAoGoFTKY4WJtaR9XvGwBcrWZ8GKOrZCAdq0= 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=Cgs5AF+LxCiwsatufJDroKj/F4Dk+2DzH9Cm8Q49820=; b=M55dU7Z+OyrhYMqqLTl1fCEDhGoryCfLEgmA/LK4GBiY7Ic7sKOz/8IJtyiJXqBEOy bVFKrwX/BQpAl5lUs8AgyIClfGZiDQzqG4c7q2Krf14FMm6v8Eb8LP+2kyhVa8Cb7vnB Z+IsCsFdOVC71hssF1BcK8dxqjHN6HBV5sMopMOT0pdRSioIR1i+ZBBBHo8SYgvxf5pc 5R3DwXXvd50SoWZarM5uQssNrQ3ZBB6EIdlWSAwum+2wI4hPxjySJA+7G9fLL9j9T7Ly hflfkmVN6PlWlHX82lXm8n3f1dRITubjyMfNN8FGnhSb7EoBl23fQfs4t5zLVKpZg50e 4RLA== X-Gm-Message-State: ALQs6tDWn1AZssnTABGmvOoaSIcIJDNz0xb6UQXgI+lCXDnpqYsQa5mW fQ/k9fXXRVwlFyLn0NmCuNVXPtqElUlH5ANMVUG04Gnrv0v5pwWVoG6Ecnzxk3tMBsPQuRvDqjY eJbjkDsJTVjoxfQ== X-Google-Smtp-Source: AB8JxZpM7U0n1nNEOh6Xi/CDaDRKLXOS162DrW517HPKnm3lmpRg9hGsg06dN1hJDiSpX6mIWxtM09OFWR5PEI4ILds= X-Received: by 2002:a24:1f4a:: with SMTP id d71-v6mr10689383itd.53.1525458607807; Fri, 04 May 2018 11:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Fri, 4 May 2018 11:29:37 -0700 (PDT) In-Reply-To: <55701B63-2B8B-4921-B57A-E6A5638C00C0@forgerock.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> <22823827-5743-4458-8C30-F5F386839630@ve7jtb.com> <2B100423-8427-4E02-BFBE-82FAEF873666@ve7jtb.com> <55701B63-2B8B-4921-B57A-E6A5638C00C0@forgerock.com> From: Brian Campbell Date: Fri, 4 May 2018 12:29:37 -0600 Message-ID: To: Neil Madden Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="0000000000007085a5056b658201" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 18:30:13 -0000 --0000000000007085a5056b658201 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wearing my editor's hat here (did I do that right?) and looking to bring this to a close so the draft can proceed - I don't see a consensus for additional confirmation methods in this draft. On Tue, May 1, 2018 at 3:08 AM, Neil Madden wrote: > JOSE and many other specs have allowed algorithms to be specified at > multiple security levels: a baseline 128-bit level, and then usually 192- > and 256-bit levels too. It seems odd that a draft that is ostensibly for > high security assurance environments would choose to only specify the > lowest acceptable security level, especially when the 256-bit level has > essentially negligible overhead. (OK, ~60 bytes additional overhead in a > JWT - I=E2=80=99d be surprised if that was a deal breaker though). > > Still, if the consensus of the WG is that this is not worth it, then I > don=E2=80=99t want to delay the draft any further. I can always submit a = 2 line RFC > in future to add a SHA-512 confirmation method. > > =E2=80=94 Neil > > > On 30 Apr 2018, at 23:58, John Bradley wrote: > > > > We allow for new thumbprint algorithms to be defined and used with this > spec. > > I think that we all agree that is a good thing. > > > > The question is if we should define them here or as part of JWT/CWT > based on broader demand. > > > > Including them in this document may be a distraction in my opinion. > There is no attack against SHA256 with a short duration token/key (days) > that is better solved by using a long duration token/key (years) with a > longer hash. > > > > That said it woiulden't like me. I just think it will distract people > in the wrong direction. > > > > John B. > > > >> On Apr 30, 2018, at 7:23 PM, Neil Madden > wrote: > >> > >> Responses inline again. > >> > >> On Mon, 30 Apr 2018 at 19:44, John Bradley wrote: > >> Inline. > >> > >> > >>> On Apr 30, 2018, at 12:57 PM, Neil Madden > wrote: > >>> > >>> Hi John, > >>> > >>>> On 30 Apr 2018, at 15:07, John Bradley wrote: > >>>> > >>>> I lean towards letting new certificate thumbprints be defined > someplace else. > >>>> > >>>> With SHA256, it is really second preimage resistance that we care > about for a certificate thumbprint, rather than simple collision > resistance. > >>> > >>> That=E2=80=99s not true if you consider a malicious client. If I can = find any > pair of certificates c1 and c2 such that SHA256(c1) =3D=3D SHA256(c2) the= n I > can present c1 to the AS when I request an access token and later present > c2 to the protected resource when I use it. I don=E2=80=99t know if there= is an > actual practical attack based on this, but a successful attack would > violate the security goal implied by the draft: that that requests made t= o > the protected resource "MUST be made [=E2=80=A6] using the same certifica= te that > was used for mutual TLS at the token endpoint.=E2=80=9D > >>> > >>> NB: this is obviously easier if the client gets to choose its own > client_id, as it can find the colliding certificates and then sign up wit= h > whatever subject ended up in c1. > >>> > >> > >> Both C1 and C2 need to be valid certificates, so not just any collisio= n > will do. > >> > >> That doesn=E2=80=99t help much. There=E2=80=99s still enough you can v= ary in a > certificate to generate collisions. > >> > >> If the client produces C1 and C2 and has the private keys for them, I > have a hard time seeing what advantage it could get by having colliding > certificate hashes. > >> > >> Me too. But if the security goal is proof of possession, then this > attack (assuming practical collisions) would break that goal. > >> > >> > >> If the AS is trusting a CA, the attacker producing a certificate that > matches the hash of another certificate so that it seems like the fake > certificate was issued by the CA, is an attack that worked on MD5 given > some predictability. That is why we now have entropy requirements for > certificate serial numbers, that reduce known prefix attacks. > >> > >> The draft allows for self-signed certificates. > >> > >> Second-preimage Resistance is being computationaly infusible to find a > second preimage that has the same output as the first preimage. The > second preimage strength for SHA256 is 201-256bits and collision resistan= ce > strength is 128 bits. See Appendix A of https://nvlpubs.nist.gov/ > nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf if you want to > understand the relationship between message length and second Preimage > resistance. > >> > >> RFC 4270 is old but still has some relevant info. > https://tools.ietf.org/html/rfc4270 > >> > >> Think of the confirmation method as the out of band integrity check fo= r > the certificate that is presented in the TLS session. > >> > >> This is all largely irrelevant. > >> > >>>> MD5 failed quite badly with chosen prefix collision attacks against > certificates (Thanks to some X.509 extensions). > >>>> SHA1 has also been shown to be vulnerable to a PDF chosen prefix > attack (http://shattered.io) > >>>> > >>>> The reason NIST pushed for development of SHA3 was concern that a > preimage attack might eventually be found agains the SHA2 family of hash > algorithms. > >>>> > >>>> While SHA512 may have double the number of bytes it may not help muc= h > against a SHA2 preimage attack,. (Some papers suggest that the double wo= rd > size of SHA512 it may be more vulnerable than SHA256 to some attacks) > >>> > >>> This is really something where the input of a cryptographer would be > welcome. As far as I am aware, the collision resistance of SHA-256 is sti= ll > considered at around the 128-bit level, while it is considered at around > the 256-bit level for SHA-512. Absent a total break of SHA2, it is likely > that SHA-512 will remain at a higher security level than SHA-256 even if > both are weakened by cryptanalytic advances. They are based on the same > algorithm, with different parameters and word/block sizes. > >>> > >> SHA512 uses double words and more rounds, true. It also has more > rounds broken by known attacks than SHA256 https://en.wikipedia.org/wiki/ > SHA-2.. So it is slightly more complex than doubling the output size > doubles the strength. > >> > >> SHA-512 also has more rounds (80) than SHA-256 (64), so still has more > rounds left to go... > >> > >> > >>>> > >>>> It is currently believed that SHA256 has 256 bits of second preimage > strength. That could always turn out to be wrong as SHA2 has some > similarities to SHA1, and yes post quantum that is reduced to 128bits. > >>>> > >>>> To have a safe future option we would probably want to go with > SHA3-512. However I don=E2=80=99t see that getting much traction in the= near > term. > >>> > >>> SHA3 is also slower than SHA2 in software. > >> Yes roughly half the speed in software but generally faster in > hardware. > >> > >> I am not necessarily arguing for SHA3, rather I think this issue is > larger than this spec and selecting alternate hashing algorithms for > security should be separate from this spec. > >> > >> I am for agility, but I don=E2=80=99t want to accidentally have people= doing > something that is just theatre. > >> > >> Rotating certificates, and having the lifetime of a certificates > validity is as useful as doubling the hash size. > >> > >> Why not allow both? > >> > >> > >> I don=E2=80=99t think the confirmation hash length is the weakest link= . > >> > >> Shouldn=E2=80=99t we allow all the parts to be as strong as possible? > >> > >> > >> John B. > >> > >>> > >>>> > >>>> Practical things people should do run more along the lines of: > >>>> 1: Put at least 64 bits of entropy into the certificate serial numbe= r > if using self signed or a local CA. Commercial CA need to do that now. > >>>> 2: Rotate certificates on a regular basis, using a registered JWKS > URI > >>>> > >>>> My concern is that people will see a bigger number and decide it is > better if we define it in the spec. > >>>> We may be getting people to do additional work and increasing token > size without a good reason by putting it in the spec directly. > >>> > >>> I=E2=80=99m not sure why this is a concern. As previously pointed out= , SHA-512 > is often *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99t see= m worth > worrying about. > >>> > >>> [snip] > >>> > >>> =E2=80=94 Neil > >> =E2=80=94 Neil > > > > --=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._ --0000000000007085a5056b658201 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wearing my editor's hat here (did I do that right?) an= d looking to bring this to a close so the draft can proceed - I don't s= ee a consensus for additional confirmation methods in this draft.

On Tue, May 1, 2= 018 at 3:08 AM, Neil Madden <neil.madden@forgerock.com> wrote:
JOSE and many other specs have= allowed algorithms to be specified at multiple security levels: a baseline= 128-bit level, and then usually 192- and 256-bit levels too. It seems odd = that a draft that is ostensibly for high security assurance environments wo= uld choose to only specify the lowest acceptable security level, especially= when the 256-bit level has essentially negligible overhead. (OK, ~60 bytes= additional overhead in a JWT - I=E2=80=99d be surprised if that was a deal= breaker though).

Still, if the consensus of the WG is that this is not worth it, then I don= =E2=80=99t want to delay the draft any further. I can always submit a 2 lin= e RFC in future to add a SHA-512 confirmation method.

=E2=80=94 Neil

> On 30 Apr 2018, at 23:58, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> We allow for new thumbprint algorithms to be defined and used with thi= s spec.
> I think that we all agree that is a good thing.
>
> The question is if we should define them here or as part of JWT/CWT ba= sed on broader demand.
>
> Including them in this document may be a distraction in my opinion.=C2= =A0 =C2=A0There is no attack against SHA256 with a short duration token/key= (days) that is better solved by using a long duration token/key (years) wi= th a longer hash.
>
> That said it woiulden't like me.=C2=A0 I just think it will distra= ct people in the wrong direction.
>
> John B.
>
>> On Apr 30, 2018, at 7:23 PM, Neil Madden <neil.madden@forgerock.com> wrote:
>>
>> Responses inline again.
>>
>> On Mon, 30 Apr 2018 at 19:44, John Bradley <ve7jtb@ve7jtb.com> wrote:
>> Inline.
>>
>>
>>> On Apr 30, 2018, at 12:57 PM, Neil Madden <neil.madden@forgerock.com> wrote:
>>>
>>> Hi John,
>>>
>>>> On 30 Apr 2018, at 15:07, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>>
>>>> I lean towards letting new certificate thumbprints be defi= ned someplace else.
>>>>
>>>> With SHA256, it is really second preimage resistance that = we care about for a certificate thumbprint, rather than simple collision re= sistance.=C2=A0
>>>
>>> That=E2=80=99s not true if you consider a malicious client. If= I can find any pair of certificates c1 and c2 such that SHA256(c1) =3D=3D = SHA256(c2) then I can present c1 to the AS when I request an access token a= nd later present c2 to the protected resource when I use it. I don=E2=80=99= t know if there is an actual practical attack based on this, but a successf= ul attack would violate the security goal implied by the draft: that that r= equests made to the protected resource "MUST be made [=E2=80=A6] using= the same certificate that was used for mutual TLS at the token endpoint.= =E2=80=9D
>>>
>>> NB: this is obviously easier if the client gets to choose its = own client_id, as it can find the colliding certificates and then sign up w= ith whatever subject ended up in c1.
>>>
>>
>> Both C1 and C2 need to be valid certificates, so not just any coll= ision will do.=C2=A0
>>
>> That doesn=E2=80=99t help much. There=E2=80=99s still enough you c= an vary in a certificate to generate collisions.
>>
>> If the client produces C1 and C2 and has the private keys for them= , I have a hard time seeing what advantage it could get by having colliding= certificate hashes.
>>
>> Me too. But if the security goal is proof of possession, then this= attack (assuming practical collisions) would break that goal.
>>
>>
>> If the AS is trusting a CA, the attacker producing a certificate t= hat matches the hash of another certificate so that it seems like the fake = certificate was issued by the CA, is an attack that worked on MD5 given som= e predictability.=C2=A0 That is why we now have entropy requirements for ce= rtificate serial numbers, that reduce known prefix attacks.
>>
>> The draft allows for self-signed certificates.
>>
>> Second-preimage Resistance is being computationaly infusible to fi= nd a second preimage that has the same output as the first preimage.=C2=A0 = =C2=A0The second preimage strength for SHA256 is 201-256bits and collision = resistance strength is 128 bits.=C2=A0 See Appendix A of https://nvlpubs.nist.gov/nistpubs/= Legacy/SP/nistspecialpublication800-107r1.pdf if you want to = understand the relationship between message length and second Preimage resi= stance.
>>
>> RFC 4270 is old but still has some relevant info. https:= //tools.ietf.org/html/rfc4270
>>
>> Think of the confirmation method as the out of band integrity chec= k for the certificate that is presented in the TLS session.
>>
>> This is all largely irrelevant.
>>
>>>> MD5 failed quite badly with chosen prefix collision attack= s against certificates (Thanks to some X.509 extensions).
>>>> SHA1 has also been shown to be vulnerable to a PDF chosen = prefix attack (http://shattered.io)
>>>>
>>>> The reason NIST pushed for development of SHA3 was concern= that a preimage attack might eventually be found agains the SHA2 family of= hash algorithms.
>>>>
>>>> While SHA512 may have double the number of bytes it may no= t help much against a SHA2 preimage attack,. (Some papers=C2=A0 suggest tha= t the double word size of SHA512 it may be more vulnerable than SHA256 to s= ome attacks)
>>>
>>> This is really something where the input of a cryptographer wo= uld be welcome. As far as I am aware, the collision resistance of SHA-256 i= s still considered at around the 128-bit level, while it is considered at a= round the 256-bit level for SHA-512. Absent a total break of SHA2, it is li= kely that SHA-512 will remain at a higher security level than SHA-256 even = if both are weakened by cryptanalytic advances. They are based on the same = algorithm, with different parameters and word/block sizes.
>>>
>> SHA512 uses double words and more rounds, true.=C2=A0 It also has = more rounds broken by known attacks than SHA256 https://en.wikipe= dia.org/wiki/SHA-2.. So it is slightly more complex than doubling = the output size doubles the strength.
>>
>> SHA-512 also has more rounds (80) than SHA-256 (64), so still has = more rounds left to go...
>>
>>
>>>>
>>>> It is currently believed that SHA256 has 256 bits of secon= d preimage strength.=C2=A0 =C2=A0That could always turn out to be wrong as = SHA2 has some similarities to SHA1, and yes post quantum that is reduced to= 128bits.
>>>>
>>>> To have a safe future option we would probably want to go = with SHA3-512.=C2=A0 =C2=A0However I don=E2=80=99t see that getting much tr= action in the near term.=C2=A0
>>>
>>> SHA3 is also slower than SHA2 in software.
>> Yes roughly half the speed in software but generally faster in har= dware.=C2=A0
>>
>> I am not necessarily arguing for SHA3, rather I think this issue i= s larger than this spec and selecting alternate hashing algorithms for secu= rity should be separate from this spec.
>>
>> I am for agility, but I don=E2=80=99t want to accidentally have pe= ople doing something that is just theatre.
>>
>> Rotating certificates, and having the lifetime of a certificates v= alidity is as useful as doubling the hash size.
>>
>> Why not allow both?
>>
>>
>> I don=E2=80=99t think the confirmation hash length is the weakest = link.
>>
>> Shouldn=E2=80=99t we allow all the parts to be as strong as possib= le?
>>
>>
>> John B.
>>
>>>
>>>>
>>>> Practical things people should do run more along the lines= of:
>>>> 1: Put at least 64 bits of entropy into the certificate se= rial number if using self signed or a local CA.=C2=A0 Commercial CA need to= do that now.
>>>> 2: Rotate certificates on a regular basis,=C2=A0 using a r= egistered JWKS URI
>>>>
>>>> My concern is that people will see a bigger number and dec= ide it is better if we define it in the spec.=C2=A0
>>>> We may be getting people to do additional work and increas= ing token size without a good reason by putting it in the spec directly. >>>
>>> I=E2=80=99m not sure why this is a concern. As previously poin= ted out, SHA-512 is often *faster* than SHA-256, and an extra 32 bytes does= n=E2=80=99t seem worth worrying about.
>>>
>>> [snip]
>>>
>>> =E2=80=94 Neil
>> =E2=80=94 Neil
>



<= 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. --0000000000007085a5056b658201-- From nobody Fri May 4 14:56: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 0A4D612DA15 for ; Fri, 4 May 2018 14:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, 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 1nLyabazM8V6 for ; Fri, 4 May 2018 14:56:52 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 24EEA12DA12 for ; Fri, 4 May 2018 14:56:52 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g14-v6so23623492ioc.7 for ; Fri, 04 May 2018 14:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc; bh=Ygj7usMAj6NjkFMmUjksNrowXkzM0j0i5goUCGNYu6M=; b=pjby4W7rMRlXnjv6bnKiUn/WgmbRkkWIEYigwBMEGjnzDD09EqZoWmQUtxA5+OaBxC u7TOF7JRZKp4jEldBKmovyNyXhNVp2p45CFzn2AkGoAzxe5/BS41PQkhFzUDEAAZuyvH J+B7hSyzetga/x5G2qqbbhwTTobyVOqyKOkpk= 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=Ygj7usMAj6NjkFMmUjksNrowXkzM0j0i5goUCGNYu6M=; b=D6sTgY3iXDP9C6+UOvmtOzo6uvWRc2agSgMKWXDXirioVtWA3LEQ+aLkHtEi/1/s5Q /AYx0EAZ+1ZAWMbNpPmCb+dQmfV71OeaPODbgm4HgijHXfJ7wGDFUsAX4BFzZ0/MULD8 z/O+nXrN0ZNsbWtHvcBD1dh9AfRjbzDj01HkP65QPEQ0RyHdTlqNUo+z4G7xCMuSTvSJ xJtZ2IOLAzNCD0ydlaVsUsQgZtdfa1s/cGsDCAhm0BmwYkN+5TIlEkl70Z+ZhxJEo09X P6LVAEZszptBO8pU8Rh6G3ZVWqaRSXciW8eEk+VTULK1ntuMYm1T5C5KeP1Gaawow2qW vDbg== X-Gm-Message-State: ALQs6tCFWKbjBrbue0wjAOgSBy6/8M4Ljgmn2YurjyKTFHgNU9oIe8VJ lunKtCY1hq/4ESOr1WoT1vvTmYMICbAtGtFcdyJQqZ+slgjGI9WQWNcEPIYKjfLII9Clx5dJbSD xU7QEx+G3NYCDSg== X-Google-Smtp-Source: AB8JxZobITQT0HI/XhV+EjH5tlppQt83bzmdhZuH9RRVplnQCWrSEZ4DYMOo5p0PmdqxD/oUNzv77vUJHEk7QIaLOhY= X-Received: by 2002:a6b:591:: with SMTP id 139-v6mr28345511iof.282.1525471011313; Fri, 04 May 2018 14:56:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Fri, 4 May 2018 14:56:20 -0700 (PDT) From: Brian Campbell Date: Fri, 4 May 2018 15:56:20 -0600 Message-ID: To: Yaron Sheffer Cc: oauth Content-Type: multipart/alternative; boundary="000000000000beb2c4056b686555" Archived-At: Subject: [OAUTH-WG] deterministic ECDSA (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 21:56:55 -0000 --000000000000beb2c4056b686555 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable New in this version of draft-ietf-oauth-jwt-bcp is a rather strong recommendation to use deterministic ECDSA from RFC 6979 (the new text with a SHOULD is copy/pasted below for the lazy among us that might be reading this). Is this consistent with the general thinking or advice out of the IETF or CFRG these days? RFC6979 talks a lot about it's usefulness in environments without a source of high-quality randomness. Should this here JWT BCP qualify its 'SHOULD' with something about that? Or is deterministic the gold standard recommendation now regardless? I get that it can be used in environments even that have good randomness but I'm wondering if that's truly the expert recommendation? Are there any reasons not to use it or situations where it wouldn't be appropriate? I don't ask to try and be critical but to try and better understand. As a WG participant, is this the right recommendation? As a maintainer of a JWT/JOSE library that doesn't do deterministic ECDSA (and I suspect isn't particularly unique in that respect), is it something I SHOULD be implementing? https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02#section-3.2 : - ECDSA signatures require a unique random value for every message that is signed. If even just a few bits of the random value are predictable across multiple messages then the security of the signature scheme may be compromised. In the worst case, the private key may be recoverable by an attacker. To counter these attacks, JWT libraries SHOULD implement ECDSA using the deterministic approach defined in [RFC6979 ]. This approach is completely compatible with existing ECDSA verifiers and so can be implemented without new algorithm identifiers being required. On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer wrote= : > This new version should address all WGLC comments. Please let us know if > there's anything missing. > > Thanks, > Yaron > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt > Date: Wed, 02 May 2018 01:26:17 -0700 > From: internet-drafts@ietf.org > To: Michael B. Jones , Yaron Sheffer < > yaronf.ietf@gmail.com>, Dick Hardt , Michael Jones < > mbj@microsoft.com> > > > A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Name: draft-ietf-oauth-jwt-bcp > Revision: 02 > Title: JSON Web Token Best Current Practices > Document date: 2018-05-02 > Group: oauth > Pages: 13 > URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-02.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp= / > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bcp-02 > > Abstract: > JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security > tokens that contain a set of claims that can be signed and/or > encrypted. JWTs are being widely used and deployed as a simple > security token format in numerous protocols and applications, both in > the area of digital identity, and in other application areas. The > goal of this Best Current Practices document is to provide actionable > guidance leading to secure implementation and deployment of JWTs. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > 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._ --000000000000beb2c4056b686555 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
New in this version of draft-ietf-oauth-jwt-bcp = is a rather strong recommendation to use deterministic ECDSA from=C2=A0RFC = 6979 (the new text with a SHOULD is copy/pasted below for the lazy among us= that might be reading this).

Is this consistent with the gen= eral thinking or advice out of the IETF or CFRG these days? RFC6979 talks a= lot about it's usefulness in environments without a source of high-qua= lity randomness. Should this here JWT BCP qualify its 'SHOULD' with= something about that? Or is deterministic the gold standard recommendation= now regardless? I get that it can be used in environments even that have g= ood randomness but I'm wondering if that's truly the expert recomme= ndation? Are there any reasons not to use it or situations where it wouldn&= #39;t be appropriate?

I don't ask to try and b= e critical but to try and better understand. As a WG participant, is this t= he right recommendation? As a maintainer of a JWT/JOSE library that doesn&#= 39;t do deterministic ECDSA (and I suspect isn't particularly unique in= that respect), is it something I SHOULD be implementing?

=C2=A0


https://tools.ietf.= org/html/draft-ietf-oauth-jwt-bcp-02#section-3.2 :
   -  ECDSA signatures require =
a unique random value for every message
      that is signed.  If even just a few bits of the random value are
      predictable across multiple messages then the security of the
      signature scheme may be compromised.  In the worst case, the
      private key may be recoverable by an attacker.  To counter these
      attacks, JWT libraries SHOULD implement ECDSA using the
      deterministic approach defined in [RFC6979].  This approach is
      completely compatible with existing ECDSA verifiers and so can be
      implemented without new algorithm identifiers being required.

On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer <yaronf.ietf@gmail.co= m> wrote:
interne= t-drafts@ietf.org
To: Michael B. Jones <mbj@microsoft.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Dick Hardt= <dick@amazon.com>, Michael Jones <mbj@microsoft.com>


A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-jwt-bcp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSON Web Token Best Current Practi= ces
Document date:=C2=A0 2018-05-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL: https://www.ietf.org/intern= et-drafts/draft-ietf-oauth-jwt-bcp-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02
Htmlized: https://datatracker.ietf.org= /doc/html/draft-ietf-oauth-jwt-bcp
Diff: https://www.ietf.org/rfcdiff?u<= wbr>rl2=3Ddraft-ietf-oauth-jwt-bcp-02

Abstract:
=C2=A0 =C2=A0JSON Web Tokens, also known as JWTs, are URL-safe JSON-based s= ecurity
=C2=A0 =C2=A0tokens that contain a set of claims that can be signed and/or<= br> =C2=A0 =C2=A0encrypted.=C2=A0 JWTs are being widely used and deployed as a = simple
=C2=A0 =C2=A0security token format in numerous protocols and applications, = both in
=C2=A0 =C2=A0the area of digital identity, and in other application areas.= =C2=A0 The
=C2=A0 =C2=A0goal of this Best Current Practices document is to provide act= ionable
=C2=A0 =C2=A0guidance leading to secure implementation and deployment of JW= Ts.




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.

The IETF Secretariat

_______________________________________________
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. --000000000000beb2c4056b686555-- From nobody Fri May 4 15:07:29 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 3EC2612DA12 for ; Fri, 4 May 2018 15:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, 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 cS9kx6Niih8X for ; Fri, 4 May 2018 15:07:24 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 B733912708C for ; Fri, 4 May 2018 15:07:24 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id f21-v6so27302535iob.13 for ; Fri, 04 May 2018 15:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc; bh=nK1WYplmp3i9GrHwgJgWHTBx6QX6Dgr1CO5JWUQwe7s=; b=h6YMjko6x0HqUEeVarno9jXCuVXEouHyxPZ47G/cjdVMu7yvZM9o2ZzduQu4Pq8PGm O8xw/kB/gSUDtF+ZD9CXSo0kGy3fToUgnW5MVnVJmVUqtMOpf3wWaaiial5B8cmZsVGS fShl9GZeJBeQNFHg3h6KWdqqX8VjBUsNPsqVs= 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=nK1WYplmp3i9GrHwgJgWHTBx6QX6Dgr1CO5JWUQwe7s=; b=TfThH95VcTUUFbTkj6KUjBLqV/a3DXL4XJKefMabrxWmj+iyiu1RBsf2sjzucnsXva wWzEZzL22DrCEvQOJDhIomomhe/i9fP2B2vP6V66Heqjv2uDe8MpQH9s+hvTbXSLgRKu nINgZsCRIwWHoxmVQXmRYXHaGIgnni1iAC/MGcjNsSHODxV3KGkioIX16j1NkLwO5EBX GpnAf+CbPvsCHuJ38GK5Z2gCXW1d/ky23mm1vb+euIU6Nddst+pr4CoXm/Fiv0qf0pLV SHicb1sp54TmesX1FIjDikKm4BQQQXayW6NZuXwbt6xQ3ZR5K7aERZnDqevcHyJVhVQV 89Jw== X-Gm-Message-State: ALQs6tBDDrTnmF8lGnAN3/BDarcJ6b/W4pMO8oSp3yZ8nQj0jEk1Y+8W y/hq7YM+At7czh39d5ynclQV+TIciKq2ptorGkWNjCzEZnU7HS+kpkmFfV9jDkWavVFrta1UVqd kC8GWRncKdTZH94Gv X-Google-Smtp-Source: AB8JxZpbKeWiKI1zdNNrgqfREqGOlqbexewliodmdYvNn1W9M+U7VobJrGw7fuh9NAgGo5Is8PHZ15UCQ2p673rJZfw= X-Received: by 2002:a6b:1c06:: with SMTP id c6-v6mr33014615ioc.247.1525471643915; Fri, 04 May 2018 15:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Fri, 4 May 2018 15:06:53 -0700 (PDT) From: Brian Campbell Date: Fri, 4 May 2018 16:06:53 -0600 Message-ID: To: Yaron Sheffer Cc: oauth Content-Type: multipart/alternative; boundary="0000000000007372a5056b688b77" Archived-At: Subject: [OAUTH-WG] JWT BCP Acknowledgements (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 22:07:27 -0000 --0000000000007372a5056b688b77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable AFAIK, Tim McLean was the first to bring the HMAC/RSA switching attack to the attention of JWS/JWT implementers - https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries= / Perhaps he should be acknowledged similar to how Antonio is for the invalid point attack? I've also provided a little (admittedly very little) review and feedback on the draft... On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer wrote= : > This new version should address all WGLC comments. Please let us know if > there's anything missing. > > Thanks, > Yaron > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt > Date: Wed, 02 May 2018 01:26:17 -0700 > From: internet-drafts@ietf.org > To: Michael B. Jones , Yaron Sheffer < > yaronf.ietf@gmail.com>, Dick Hardt , Michael Jones < > mbj@microsoft.com> > > > A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Name: draft-ietf-oauth-jwt-bcp > Revision: 02 > Title: JSON Web Token Best Current Practices > Document date: 2018-05-02 > Group: oauth > Pages: 13 > URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-02.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp= / > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bcp-02 > > Abstract: > JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security > tokens that contain a set of claims that can be signed and/or > encrypted. JWTs are being widely used and deployed as a simple > security token format in numerous protocols and applications, both in > the area of digital identity, and in other application areas. The > goal of this Best Current Practices document is to provide actionable > guidance leading to secure implementation and deployment of JWTs. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > 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._ --0000000000007372a5056b688b77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
AFAIK, Tim McLean was the first to bring the HMA= C/RSA switching attack to the attention of JWS/JWT implementers - https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-li= braries/

Perhaps he should be acknowledged similar to how= Antonio is for the invalid point attack?

I've also p= rovided a little (admittedly very little) review and feedback on the draft.= ..



On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer <yaronf.ie= tf@gmail.com> wrote:
This new version should address all WGLC comments. Please let = us know if there's anything missing.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt<= br> Date: Wed, 02 May 2018 01:26:17 -0700
From: interne= t-drafts@ietf.org
To: Michael B. Jones <mbj@microsoft.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Dick Hardt= <dick@amazon.com>, Michael Jones <mbj@microsoft.com>


A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-jwt-bcp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSON Web Token Best Current Practi= ces
Document date:=C2=A0 2018-05-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL: https://www.ietf.org/intern= et-drafts/draft-ietf-oauth-jwt-bcp-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02
Htmlized: https://datatracker.ietf.org= /doc/html/draft-ietf-oauth-jwt-bcp
Diff: https://www.ietf.org/rfcdiff?u<= wbr>rl2=3Ddraft-ietf-oauth-jwt-bcp-02

Abstract:
=C2=A0 =C2=A0JSON Web Tokens, also known as JWTs, are URL-safe JSON-based s= ecurity
=C2=A0 =C2=A0tokens that contain a set of claims that can be signed and/or<= br> =C2=A0 =C2=A0encrypted.=C2=A0 JWTs are being widely used and deployed as a = simple
=C2=A0 =C2=A0security token format in numerous protocols and applications, = both in
=C2=A0 =C2=A0the area of digital identity, and in other application areas.= =C2=A0 The
=C2=A0 =C2=A0goal of this Best Current Practices document is to provide act= ionable
=C2=A0 =C2=A0guidance leading to secure implementation and deployment of JW= Ts.




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.

The IETF Secretariat

_______________________________________________
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. --0000000000007372a5056b688b77-- From nobody Fri May 4 23:24: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 0510D12E049 for ; Fri, 4 May 2018 23:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, 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 ggDfdk2FrQH2 for ; Fri, 4 May 2018 23:24:19 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 75A9F12D775 for ; Fri, 4 May 2018 23:24:19 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a137-v6so9312890wme.1 for ; Fri, 04 May 2018 23:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=iiQhvxrVFSWmvoVL8GAHchWvXTv1Qb8MoHfF6VYpHts=; b=MdZ4mtHVWery2DUc5cokeYeqwqLNchGFOESHPmwy+YoNr0oOSP8W9KiVv3X5eOr9pJ ievIknYi/hdwK9UZrEAq11iW8X41wJKF+xgXKl6IspHjcf3PIlxLG8xixV4DahwoyDq/ 3w1F+LZJudjGMsbNVw9Gm9WcYg/N0B+xlc2KY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=iiQhvxrVFSWmvoVL8GAHchWvXTv1Qb8MoHfF6VYpHts=; b=mEyHaRLbUpjiMVvKaOJYtRo8a5eql6tXUsQkufs2TAHIQMwFijie2N8Z9lkQDRGpqJ i+Z6pcFgBPuLuMPslxCKm4+SLm/hfbuKxJLXPX52O3fF2CMEZTYmF0WKd3sOzRw34E+i doDb2lcJTYDWZu0bcY2vm4P/M5dNg3snxes2IC4YJB2ffL35Zjhuk+s6yVlElWvBuRiA lCNnI0Mei+jyQKRKW8yq3Y1stIo4yWacHsexyHGcyOEyJStgnK0lzcNqPewiTmdsR8jX I6ZxHiRtkyx4FZuCjLEdvgkvwryxNyUnJ8QjUlKcL5XsW6QqhnNsCfpGRIsO4pQReiXl c1Bw== X-Gm-Message-State: ALQs6tDHo05xGeiPbc3CHpgre+MUK9SvO9a9GucWhNi37C5ZvgYL+NNk DeC+F7WeDp0tt9DkNc3fYNh+9kGG8ww= X-Google-Smtp-Source: AB8JxZoQuQ9alfL4fDq4AEtPwyhaG+oGtz/F8Kks/9TCOHTIO0BQxb1i1pHvEOnJUOJi54qru0XhMg== X-Received: by 10.28.143.143 with SMTP id r137mr18237304wmd.103.1525501457672; Fri, 04 May 2018 23:24:17 -0700 (PDT) Received: from [192.168.1.81] (72.142.200.146.dyn.plus.net. [146.200.142.72]) by smtp.gmail.com with ESMTPSA id m1-v6sm3369823wma.8.2018.05.04.23.24.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 23:24:16 -0700 (PDT) Date: Sat, 5 May 2018 07:24:12 +0100 From: Neil Madden To: Brian Campbell , Yaron Sheffer Cc: oauth Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="5aed4e0e_327b23c6_118"; protocol="application/pgp-signature" Archived-At: Subject: Re: [OAUTH-WG] deterministic ECDSA (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 06:24:23 -0000 --5aed4e0e_327b23c6_118 Content-Type: multipart/alternative; boundary="5aed4e0e_6b8b4567_118" --5aed4e0e_6b8b4567_118 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think it=E2=80=99s generally recommended in most situations these days.= =46or instance, use of R=46C 6979 is RECOMMENDED in TLS 1.3 - see end of= https://tools.ietf.org/html/draft-ietf-tls-tls13-28=23appendix-C.3 Some more recent research suggests you need to be careful of fault attack= s in embedded/IoT deployments where attackers with physical access to the= chips may be a threat - https://eprint.iacr.org/2017/975. =E2=80=94 Neil > On =46riday, May 04, 2018 at 10:57 pm, Brian Campbell wrote: > New in this version of draft-ietf-oauth-jwt-bcp is a rather strong reco= mmendation to use deterministic ECDSA from R=46C 6979 (the new text with = a SHOULD is copy/pasted below for the lazy among us that might be reading= this). > > Is this consistent with the general thinking or advice out of the IET=46= or C=46RG these days=3F R=46C6979 talks a lot about it's usefulness in e= nvironments without a source of high-quality randomness. Should this here= JWT BCP qualify its 'SHOULD' with something about that=3F Or is determin= istic the gold standard recommendation now regardless=3F I get that it ca= n be used in environments even that have good randomness but I'm wonderin= g if that's truly the expert recommendation=3F Are there any reasons not = to use it or situations where it wouldn't be appropriate=3F > > I don't ask to try and be critical but to try and better understand. As= a WG participant, is this the right recommendation=3F As a maintainer of= a JWT/JOSE library that doesn't do deterministic ECDSA (and I suspect is= n't particularly unique in that respect), is it something I SHOULD be imp= lementing=3F > > > > > > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02=23section-3.2 := > - ECDSA signatures require a unique random value for every message that= is signed. If even just a few bits of the random value are predictable a= cross multiple messages then the security of the signature scheme may be = compromised. In the worst case, the private key may be recoverable by an = attacker. To counter these attacks, JWT libraries SHOULD implement ECDSA = using the deterministic approach defined in =5BR=46C6979 (https://tools.i= etf.org/html/rfc6979)=5D. This approach is completely compatible with exi= sting ECDSA verifiers and so can be implemented without new algorithm ide= ntifiers being required. > > On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer wrote: > > This new version should address all WGLC comments. Please let us know= if there's anything missing. > > > > Thanks, > > Yaron > > > > > > -------- =46orwarded Message -------- > > Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt= > > Date: Wed, 02 May 2018 01:26:17 -0700 > > =46rom: internet-drafts=40ietf.org (mailto:internet-drafts=40ietf.org= ) > > To: Michael B. Jones , Yaron Sheffer , Dick Hardt , Michael J= ones > > > > > > A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt > > has been successfully submitted by Yaron Sheffer and posted to the > > IET=46 repository. > > > > Name: draft-ietf-oauth-jwt-bcp > > Revision: 02 > > Title: JSON Web Token Best Current Practices > > Document date: 2018-05-02 > > Group: oauth > > Pages: 13 > > URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-02= .txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-= bcp > > Diff: https://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-oauth-jwt-bcp-= 02 > > > > Abstract: > > JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security= > > tokens that contain a set of claims that can be signed and/or > > encrypted. JWTs are being widely used and deployed as a simple > > security token format in numerous protocols and applications, both in= > > the area of digital identity, and in other application areas. The > > goal of this Best Current Practices document is to provide actionable= > > guidance leading to secure implementation and deployment of JWTs. > > > > > > > > > > Please note that it may take a couple of minutes from the time of sub= mission > > until the htmlized version and diff are available at tools.ietf.org (= http://tools.ietf.org). > > > > The IET=46 Secretariat > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > OAuth mailing list > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > https://www.ietf.org/mailman/listinfo/oauth > > > CON=46IDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.. If yo= u have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F > OAuth mailing list > OAuth=40ietf.org > https://www.ietf.org/mailman/listinfo/oauth --5aed4e0e_6b8b4567_118 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22>
= I think it=E2=80=99s generally recommended in most situations these days.= =46or instance, use of R=46C 6979 is RECOMMENDED in TLS 1.3 - see end of= =C2=A0https://tools.ietf.org/html/draft-ietf-tls-tls13-28=23app= endix-C.3

Some more recent research sug= gests you need to be careful of fault attacks in embedded/IoT deployments= where attackers with physical access to the chips may be a threat -=C2=A0= https://eprint.iacr.org/= 2017/975.

=E2=80=94 Neil

On =46riday, May 04, 2018 at 10:57 pm, Brian Campbell = <bcampbell=40pingi= dentity.com> wrote:
= New in this version of draft-ietf-oauth-jwt-bcp is a rather strong recomm= endation to use deterministic ECDSA from=C2=A0R=46C 6979 (the new text wi= th a SHOULD is copy/pasted below for the lazy among us that might be read= ing this).

Is this consistent with the general thinking or = advice out of the IET=46 or C=46RG these days=3F R=46C6979 talks a lot ab= out it's usefulness in environments without a source of high-quality rand= omness. Should this here JWT BCP qualify its 'SHOULD' with something abou= t that=3F Or is deterministic the gold standard recommendation now regard= less=3F I get that it can be used in environments even that have good ran= domness but I'm wondering if that's truly the expert recommendation=3F Ar= e there any reasons not to use it or situations where it wouldn't be appr= opriate=3F

I don't ask to try and be critical bu= t to try and better understand. As a WG participant, is this the right re= commendation=3F As a maintainer of a JWT/JOSE library that doesn't do det= erministic ECDSA (and I suspect isn't particularly unique in that respect= ), is it something I SHOULD be implementing=3F


=C2=A0=


https://tools.= ietf.org/html/draft-ietf-oauth-jwt-bcp-02=23section-3.2 :
 - ECDSA signatures require a unique random value for every message that=
 is signed. If even just a few bits of the random value are predictable a=
cross multiple messages then the security of the signature scheme may be =
compromised. In the worst case, the private key may be recoverable by an =
attacker. To counter these attacks, JWT libraries SHOULD implement ECDSA =
using the deterministic approach defined in =5BR=46C6979=5D. This appr=
oach is completely compatible with existing ECDSA verifiers and so can be=
 implemented without new algorithm identifiers being required.

<= /div>

On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer <yaronf.ietf=40gmail.com> wrote:
This new version should ad= dress all WGLC comments. Please let us know if there's anything missing.<= br>
Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


----= ---- =46orwarded Message --------
Subject: New Version Notification f= or draft-ietf-oauth-jwt-bcp-02.txt
Date: Wed, 02 May 2018 01:26:= 17 -0700
=46rom: internet-drafts=40ietf.org
To: Michael B. J= ones <mbj=40microsoft.com>, Yaron Sheffer <yaronf.ietf=40gmail.com= >, Dick Hardt <dick=40amazon.com>, Michael Jones <mbj=40microsoft.com>


A new version of I-D, draft-ietf-oauth-jwt-bcp-02.tx<= wbr>t
has been successfully submitted by Yaron Sheffer and posted to = the
IET=46 repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0draft-ietf-oauth-jwt-bcp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A00= 2
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSON Web Token Best Curren= t Practices
Document date:=C2=A0 2018-05-02
Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13 URL: https:= //www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-02.txt<= /a>
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf= -oauth-jwt-bcp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-i= etf-oauth-jwt-bcp-02
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-= oauth-jwt-bcp
Diff: https://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-oaut= h-jwt-bcp-02

Abstract:
=C2=A0 =C2=A0JSON Web Tokens= , also known as JWTs, are URL-safe JSON-based security
=C2=A0 =C2=A0t= okens that contain a set of claims that can be signed and/or
=C2=A0 =C2= =A0encrypted.=C2=A0 JWTs are being widely used and deployed as a simple =C2=A0 =C2=A0security token format in numerous protocols and applicati= ons, both in
=C2=A0 =C2=A0the area of digital identity, and in other = application areas.=C2=A0 The
=C2=A0 =C2=A0goal of this Best Current P= ractices document is to provide actionable
=C2=A0 =C2=A0guidance lead= ing to secure implementation and deployment of JWTs.



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

The IET=46 Secretariat

=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mai= ling list
OAuth=40ietf.org
https://w= ww.ietf.org/mailman/listinfo/oauth


CON= =46IDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited..=C2=A0 If y= ou have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from = your computer. Thank you.=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40i= etf.org
https://www.ietf.org/mailman/listinfo/oauth
=
--5aed4e0e_6b8b4567_118-- --5aed4e0e_327b23c6_118 Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary Comment: https://www.canarymail.io Charset: UTF-8 wsFcBAABCgAGBQJa7U4OAAoJEJD4Q99O3axdWZUQAIWV6zRua4FFujFNiUg2Owh/5J/9v4cYiG/F yRr2gLpRHNKkr94KuJrVljgn6seb+oasAethe5ozb5UrVrkQELHt5BF2pyQQfKgkE614gKKsFtUK kiSHflOP5eUTbmN8IGf3H1bAWgFmmdNEGHPJ692mdoUjw25BQQ41n+AFdvqAFWiGCKRPYlsrHIA/ o5Ptq+igAuj3nG/SreDxtVWksdzofe7OLagofTenHmBXaajXBTiGMmZjBYG5LXQDyEj5cT0U9f0R n1kxFlaRWn5g/gzcgLWiK5VAiBNyjrF0B3ZoOGpZlQUqfMO8wJpDX97ZvWUYqV33zoKahzzbgZwb Mu5MXeL1Jk2/9PCt8uYA+tSwCCI/EwD0g2CyxaARS4LRbQJLlP+s2EuLVl0bask0rdi7UqIwbXCJ kAhmJOSIUiyFQZewKx1LDHDOr8XzcgUwQe2zH7OebbgoR6feFLRo3GssdZ/du7LxeWvm3LSh/P6L D6nx8dSOUiU7hvTC7Fy/EadFiCeGTdQLfGzTLp3njwib2+3j9eet7yzWVwa4EbzrEbnf6xCfh0SI ikoVEVn/dfvGrSOx4RLX5hvKnCtUBRzkgYMAEBI7MXNqFwu5B2KE+RgY1VGDEKUz/LjUc7/1qQoa PEBShBa/Q3330v1TdgI8BiuNroBLohRaE5NTcvsq =rMQX -----END PGP SIGNATURE----- --5aed4e0e_327b23c6_118-- From nobody Sat May 5 05:16: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 AF9EF126B7E for ; Sat, 5 May 2018 05:16:18 -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, 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 ua8QFQZuJWqk for ; Sat, 5 May 2018 05:16:16 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 EF7F3120227 for ; Sat, 5 May 2018 05:16:15 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id q3-v6so23531836wrj.6 for ; Sat, 05 May 2018 05:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yTvcGCOOImEBSA5lnYuQibcuurtEti77LuGtp5Y1gyY=; b=AvtHLgyytR4S/y7UB/T0LCyQgr8TmOHtCtlJQ3K2rKFAPDiRbqE8Qo+ofCYn8nMKD2 4yqIxECibNU5wCKfKwN00ofWkRPkaYc2YJSOU7dtZQHY136bbc4bReR5dOWhu/412Tk9 XtphgbHsdDb+MY32/c8ycHnDvmLy3uoEd1XzVrgDWxGeUSDgRwlUHU0xQ/jB+mXBSw33 8IIFAbz7VTGsppdu6iJ5RrbYjVv1YYc1qp+eZ5LZ/plmdVzGDMwqtmPZmnzJInblphom pNnwlR8sHF6g6weo277zRqHiPultX858ekEDwavcYQyDSFLG60wSLCcJ7MPyzZipGvRA ywsg== 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 :content-transfer-encoding; bh=yTvcGCOOImEBSA5lnYuQibcuurtEti77LuGtp5Y1gyY=; b=Dl18/nHlBIMuSIHzl1/2lir92se5HKPKzh0rwuJF0xcCE0hSI+nJQkFpwIEOIhn+Io uLOmdd6KkVtZOMviRNlL+RpA7hYu6fvLNrn/LqLi0p1vBSoJpBZijY2eBMUkD/DmtyQc /N5SfdUOqHAfjRosW2s7rU++elTxAFQtSVffNUm0aC5gZOkLPu5mhx6wIocb2xnPmkLZ fso7UKktWSAu7ZiP4t7w7oHn1nBG39mnJuQiloDtQTtQW9kbBbX5rXhT6qtGP9wq3MVV 9ahGYcR6SaJ3X/nr4xQu027C4dxX1IM/D2r5umFT9aHWnLkrXC25u3hOYbaWWpYhx7Va TEyQ== X-Gm-Message-State: ALQs6tDvG9GNIFCW+UTMMeD8qYo84bV9OnKXp+AmbbRgOBdufvMvrJue pp3Z+oGJWLjWDgVAo03sXLHFbPIS X-Google-Smtp-Source: AB8JxZryAL+dT8Z4hcfeoeCtRqBhbVGpXsDNLMblrErNz20wN+XCSBl1UdxfhCm5F4pPU3tSH/r/Nw== X-Received: by 2002:adf:96c2:: with SMTP id u60-v6mr24947441wrb.204.1525522574193; Sat, 05 May 2018 05:16:14 -0700 (PDT) Received: from [10.0.0.142] (bzq-79-177-105-104.red.bezeqint.net. [79.177.105.104]) by smtp.gmail.com with ESMTPSA id x24sm2969357wmh.18.2018.05.05.05.16.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 May 2018 05:16:13 -0700 (PDT) To: Brian Campbell Cc: oauth References: From: Yaron Sheffer Message-ID: <51ae29af-d9b8-019c-2d43-c1ecc4694d4f@gmail.com> Date: Sat, 5 May 2018 15:16:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] JWT BCP Acknowledgements (was Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 12:16:19 -0000 Thanks Brian for the reminder. Will update the draft. Yaron On 05/05/18 01:06, Brian Campbell wrote: > AFAIK, Tim McLean was the first to bring the HMAC/RSA switching attack > to the attention of JWS/JWT implementers - > https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ > > > Perhaps he should be acknowledged similar to how Antonio is for the > invalid point attack? > > I've also provided a little (admittedly very little) review and feedback > on the draft... > > > > On Wed, May 2, 2018 at 2:36 AM, Yaron Sheffer > wrote: > > This new version should address all WGLC comments. Please let us > know if there's anything missing. > > Thanks, >         Yaron > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-02.txt > Date: Wed, 02 May 2018 01:26:17 -0700 > From: internet-drafts@ietf.org > To: Michael B. Jones >, > Yaron Sheffer >, Dick Hardt >, Michael Jones > > > > A new version of I-D, draft-ietf-oauth-jwt-bcp-02.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Name:           draft-ietf-oauth-jwt-bcp > Revision:       02 > Title:          JSON Web Token Best Current Practices > Document date:  2018-05-02 > Group:          oauth > Pages:          13 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-02.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp > > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-02 > > > Abstract: >    JSON Web Tokens, also known as JWTs, are URL-safe JSON-based > security >    tokens that contain a set of claims that can be signed and/or >    encrypted.  JWTs are being widely used and deployed as a simple >    security token format in numerous protocols and applications, > both in >    the area of digital identity, and in other application areas.  The >    goal of this Best Current Practices document is to provide > actionable >    guidance leading to secure implementation and deployment of JWTs. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > _______________________________________________ > 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./ From nobody Sat May 5 08:40: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 D46C312E8CB for ; Sat, 5 May 2018 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 I_sH1ee-JhGI for ; Sat, 5 May 2018 08:40:29 -0700 (PDT) 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 8299012D80F for ; Sat, 5 May 2018 08:40:29 -0700 (PDT) Received: from [84.158.233.58] (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 1fEzIQ-0000r6-Ny; Sat, 05 May 2018 17:40:26 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_026B4D75-ED53-4EDA-B38C-CB4C0013CD9D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sat, 5 May 2018 17:40:21 +0200 In-Reply-To: Cc: "Richard Backman, Annabelle" , oauth To: Nat Sakimura References: <88C79981-4D1B-402F-A284-A636153DE082@amazon.com> X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 15:40:33 -0000 --Apple-Mail=_026B4D75-ED53-4EDA-B38C-CB4C0013CD9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > Am 24.04.2018 um 05:33 schrieb Nat Sakimura : >=20 > +1 >=20 > On Thu, Apr 19, 2018 at 3:28 AM Richard Backman, Annabelle = > wrote: > I support adoption of OAuth 2.0 Incremental Authorization as a WG = document. >=20 > =20 >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Amazon =E2=80=93 Identity Services >=20 > =20 >=20 > From: OAuth > on behalf of Brian Campbell = > > Date: Wednesday, April 18, 2018 at 8:23 AM > To: Rifaat Shekh-Yusef > > Cc: oauth > > Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental = Authorization >=20 > =20 >=20 > I support adoption of OAuth 2.0 Incremental Authorization as a WG = document. <> > =20 >=20 > On Mon, Apr 16, 2018 at 8:47 AM, Rifaat Shekh-Yusef = > wrote: >=20 > All, >=20 > =20 >=20 > We would like to get a confirmation on the mailing list for the = adoption of the OAuth 2.0 Incremental Authorization as a WG document >=20 > = https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/ = <> > =20 >=20 > Please, let us know if you support or object to the adoption of this = document. >=20 > =20 >=20 > Regards, >=20 > Rifaat & Hannes >=20 > =20 >=20 >=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 > Nat Sakimura >=20 > Chairman of the Board, OpenID Foundation >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_026B4D75-ED53-4EDA-B38C-CB4C0013CD9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

Am 24.04.2018 um 05:33 schrieb Nat Sakimura <sakimura@gmail.com>:

+1

On Thu, Apr 19, 2018 = at 3:28 AM Richard Backman, Annabelle <richanna@amazon.com>= wrote:

I = support adoption of OAuth 2.0 Incremental Authorization as a WG = document.

 

-- 

Annabelle Richard Backman

Amazon =E2=80=93 Identity Services

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell = <bcampbell@pingidentity.com>
Date: Wednesday, April 18, 2018 at 8:23 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 = Incremental Authorization

 

I support = adoption of OAuth 2.0 Incremental Authorization as a WG document.

 

On Mon, Apr 16, = 2018 at 8:47 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

We would like to = get a confirmation on the mailing list for the adoption of the OAuth 2.0 Incremental Authorization as = a WG document

https://datatracker.ietf.org/doc/draft-wdenniss-oauth-increment= al-auth/

 

Please, let us know if you support or object to = the adoption of this document.

 

Regards,

 Rifaat & Hannes

 


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

Nat Sakimura

Chairman = of the Board, OpenID Foundation

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

= --Apple-Mail=_026B4D75-ED53-4EDA-B38C-CB4C0013CD9D-- From nobody Mon May 7 08:30: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 663E8120727 for ; Mon, 7 May 2018 08:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rIZ2NbfeaAt8 for ; Mon, 7 May 2018 08:30:47 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.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 8A28712025C for ; Mon, 7 May 2018 08:30:47 -0700 (PDT) X-AuditID: 1209190d-cf7ff70000006b25-e2-5af071263c10 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.66.27429.62170FA5; Mon, 7 May 2018 11:30:46 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w47FUjVH026519; Mon, 7 May 2018 11:30:46 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w47FUiNQ005138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2018 11:30:45 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Justin Richer In-Reply-To: Date: Mon, 7 May 2018 11:30:43 -0400 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrKtW+CHK4MMGVYubM04xWZx8+4rN gcljzbw1jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp41XeHqWAdV8XDCYeYGxgXcXQxcnJICJhI HL9/hLmLkYtDSGAxk8SlORsYIZwNjBILnt5ihXCuMUl8edXIBtLCLKApsb97OQuIzQvUvuNK GzuILSygIzFr0zlmEJtNQFVi+poWJhCbUyBRovXNS7AaFgEViRe71gLVcADNUZdoP+kCMVJb YtnC18wQI60kZj//CWYLCSRIrN23jhXEFhEwlNjbfIgV4molif+7jjBPYBSYheSiWUgumoVk 7AJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxjBgSrJu4Px312vQ4wCHIxK PLw/Cj5ECbEmlhVX5h5ilORgUhLl5X7wPkqILyk/pTIjsTgjvqg0J7X4EKMEB7OSCC+bMlA5 b0piZVVqUT5MSpqDRUmcd9H+vVFCAumJJanZqakFqUUwWRkODiUJ3nSQPYJFqempFWmZOSUI aSYOTpDhPEDD20BqeIsLEnOLM9Mh8qcYdTn+3dzfyyzEkpeflyolzqsLUiQAUpRRmgc3B5Rg 3NfZWbxiFAd6S5i3F6SKB5ic4Ca9AlrCBLREEOQ73uKSRISUVAOjavOM2SerZ/Fkle/86TWr oCb/gHD6gn/S1g+mWi08cuhPQafOhiqtwzw5vw/HBs+e2/S6b8vph1/kpD/Xcif3ceVo9vM8 XeRiMXXS/4VvO96+CXM5+LZZUHrW3ZrpWfFdeif7rsfabXi85Yax8P97ufE325xfi29q6i95 5yGxcpqW1v5Z7gE6SizFGYmGWsxFxYkA8IFlagsDAAA= Archived-At: Subject: Re: [OAUTH-WG] Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 15:30:49 -0000 I had this on my calendar but no call-in information, is this happening = today? =E2=80=94 Justin > On Apr 16, 2018, at 11:29 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > Rifaat and I had the idea to offer folks the possibility to discuss = current issues with us on a regular basis. Starting with Monday, May 7th = we will dial into a conference bridge at 8:30 PDT and stay on the bridge = for 1 hour. Everyone who has something to discuss with us can join and = we will help as much as we can. We will do this twice per month. >=20 > There is obviously no obligation for anyone to join. If nobody joins = then Rifaat and I will use the time to sync-up among ourselves. = Conference bridge details will follow. >=20 > We hope you find this useful. >=20 > 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. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon May 7 08:35: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 D428F124B0A for ; Mon, 7 May 2018 08:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 8EwyxMvPxBz9 for ; Mon, 7 May 2018 08:34:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0057.outbound.protection.outlook.com [104.47.0.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1B4120727 for ; Mon, 7 May 2018 08:34:55 -0700 (PDT) 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; bh=14O/uqEtHXNx4foODba2Ullvy1fJfuv/nj0Kg+ZgUIU=; b=WJOj29Hn6rEb1+okhfpfvlt6VBFQw2/Ik1dknYUvnnrNYffo5a2tfwZcRnjv0RSPcGxxybFpMFwLLH2hjWaPPOH4LX9DXHASE8XC16m3iezGil/xoQY1dI8JShaG/ZeXic09dRlDpZCu/gkK4mPhSyy2qU7c45ZBqRPvtkJo5UY= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2095.eurprd08.prod.outlook.com (10.173.75.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.17; Mon, 7 May 2018 15:34:52 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88%18]) with mapi id 15.20.0735.018; Mon, 7 May 2018 15:34:52 +0000 From: Hannes Tschofenig To: Justin Richer CC: "" Thread-Topic: [OAUTH-WG] Virtual Office Hours Thread-Index: AdPVlsucOQv81oWSR0mo7aVbojYPcQQgZDuAAAAZk8A= Date: Mon, 7 May 2018 15:34:52 +0000 Message-ID: References: In-Reply-To: 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.121.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2095; 7:GL9TM2k/s/h2Ay94vKZA1DbcB0YyoHreNp/VkuFFjZvMLdXqQLTaIE0pxw3UeJvm/qmQWk4V5VWbE5kaUeinA/ILtmucpzDBen9Rg4akCM5t+t/5mtP1v+Lc3+cDHTV1AoBfDOJHvtqki9f0De64puRyk52x1m8/VQOtsIQd/m0vQvn6z7luVzb+l8FBcds+YWplbLBItxlXElJfUsm7iw5nTZoZbiJJhSgAC/ggMDtRs48g5Z/EpXdyucKw3L/Y x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2095; x-ms-traffictypediagnostic: VI1PR0801MB2095: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(94707916325470)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB2095; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2095; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39380400002)(39860400002)(376002)(346002)(40434004)(199004)(189003)(53754006)(38314003)(13464003)(25786009)(229853002)(186003)(76176011)(14454004)(72206003)(8936002)(7736002)(81166006)(305945005)(81156014)(26005)(102836004)(7696005)(106356001)(966005)(16799955002)(105586002)(446003)(486006)(476003)(11346002)(97736004)(59450400001)(99286004)(6916009)(8676002)(2900100001)(478600001)(5660300001)(6506007)(53546011)(86362001)(6436002)(316002)(74316002)(2906002)(66066001)(53936002)(6306002)(6246003)(68736007)(3660700001)(2171002)(3280700002)(4326008)(33656002)(3846002)(6116002)(5890100001)(9686003)(5250100002)(551544002)(55016002)(14444003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2095; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1fVJou6eyXUB27H7qhhnWxWabI70zV/ZFnIiWbPAKfMbmg9HzGRuRg7brUTCnYDsKlX/M2W5WHlTcZuLSNpOX383oax6m8UkT050YWVQCVuDEjkskODzTx5j8hVAjrjqHxSH06qg0aCS+ETqQvDlUHunKa3f3Gia3ZGcfecidkJHyNCruhZoWzcZ5I8lBH0W spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c0c69b8f-8a3d-46ca-c6fd-08d5b430138c X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0c69b8f-8a3d-46ca-c6fd-08d5b430138c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 15:34:52.1434 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2095 Archived-At: Subject: Re: [OAUTH-WG] Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 15:34:59 -0000 R3Jyci4NCg0KVGhlIGNhbGVuZGFyIGludml0YXRpb24gZ290IHRyYXBwZWQgaW4gb3VyIGJvdW5j ZSBmb2xkZXIuIEhlcmUgaXMgdGhlIGluZm8NCg0KV2ViRXggbWVldGluZyA6IGh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00YjdjNTg4YjY0ZjcwNDRiYjMxMTgwODQ2YmY3 ZWIwOA0KTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMzEwIDE2NSAxNzYNCk1lZXRpbmcg cGFzc3dvcmQ6V01VZ0pwMngNCg0KQ2lhbw0KSGFubmVzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBtaXQuZWR1XQ0KU2Vu dDogMDcgTWF5IDIwMTggMTc6MzENClRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KQ2M6IDxvYXV0aEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFZpcnR1YWwgT2ZmaWNlIEhvdXJzDQoN CkkgaGFkIHRoaXMgb24gbXkgY2FsZW5kYXIgYnV0IG5vIGNhbGwtaW4gaW5mb3JtYXRpb24sIGlz IHRoaXMgaGFwcGVuaW5nIHRvZGF5Pw0KDQog4oCUIEp1c3Rpbg0KDQo+IE9uIEFwciAxNiwgMjAx OCwgYXQgMTE6MjkgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tPiB3cm90ZToNCj4NCj4gSGkgYWxsLA0KPg0KPiBSaWZhYXQgYW5kIEkgaGFkIHRoZSBpZGVh IHRvIG9mZmVyIGZvbGtzIHRoZSBwb3NzaWJpbGl0eSB0byBkaXNjdXNzIGN1cnJlbnQgaXNzdWVz IHdpdGggdXMgb24gYSByZWd1bGFyIGJhc2lzLiBTdGFydGluZyB3aXRoIE1vbmRheSwgTWF5IDd0 aCB3ZSB3aWxsIGRpYWwgaW50byBhIGNvbmZlcmVuY2UgYnJpZGdlIGF0IDg6MzAgUERUIGFuZCBz dGF5IG9uIHRoZSBicmlkZ2UgZm9yIDEgaG91ci4gRXZlcnlvbmUgd2hvIGhhcyBzb21ldGhpbmcg dG8gZGlzY3VzcyB3aXRoIHVzIGNhbiBqb2luIGFuZCB3ZSB3aWxsIGhlbHAgYXMgbXVjaCBhcyB3 ZSBjYW4uIFdlIHdpbGwgZG8gdGhpcyB0d2ljZSBwZXIgbW9udGguDQo+DQo+IFRoZXJlIGlzIG9i dmlvdXNseSBubyBvYmxpZ2F0aW9uIGZvciBhbnlvbmUgdG8gam9pbi4gSWYgbm9ib2R5IGpvaW5z IHRoZW4gUmlmYWF0IGFuZCBJIHdpbGwgdXNlIHRoZSB0aW1lIHRvIHN5bmMtdXAgYW1vbmcgb3Vy c2VsdmVzLiBDb25mZXJlbmNlIGJyaWRnZSBkZXRhaWxzIHdpbGwgZm9sbG93Lg0KPg0KPiBXZSBo b3BlIHlvdSBmaW5kIHRoaXMgdXNlZnVsLg0KPg0KPiBDaWFvDQo+IEhhbm5lcyAmIFJpZmFhdA0K PiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlz dA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3Jl IG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Mon May 7 08:38: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 22112126CC4 for ; Mon, 7 May 2018 08:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 1kqbYjkroUL8 for ; Mon, 7 May 2018 08:38:38 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50060.outbound.protection.outlook.com [40.107.5.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B18120727 for ; Mon, 7 May 2018 08:38:37 -0700 (PDT) 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; bh=xv6v6ubat4NF/mtSNozflgZDiuHmSbKE/Bcu5y17Wt8=; b=d/uJGy0zAkpSQBsu9XzDO9Gwv4MZNylrJyIy7Lj2YITvsd1hvrrHoXTW9M94gphq0WvflS2VasSIynSQNssgjLVcknaTxZQyFnlwIc0YnpYESpwd2yWpGGsXGDoXh9xC/p48xIou5DYCcyFbtk+1KxN7GF5k4geE+Qokl7bb4N0= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1406.eurprd08.prod.outlook.com (10.167.198.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.17; Mon, 7 May 2018 15:38:35 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88%18]) with mapi id 15.20.0735.018; Mon, 7 May 2018 15:38:35 +0000 From: Hannes Tschofenig To: "" Thread-Topic: OAuth Webex Info Thread-Index: AdPmGUR21zdeQ3Z0Thq0G59cPy0F9A== Date: Mon, 7 May 2018 15:38:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1406; 6:/kJBLBXrdg1sO/4gtwzHMo5sGCZW4y29oobu5zAXRnJIJ1YNvqwvFnNaMJNlhlevaoY5p66NUouOjMovohUd/CU8xaPAGL9RJd1uvTfYhboXFYayPuh3Mfx8Rxcsy+zy3erXpx3Lm0tgXz8QzskAuqu01yIh0frCU++rUTBqRUKRv9tsg9uZx+NWPMrUhIf19/kYoZsiK86qs5l5C9JYZYqGinZ2UAndeq13711MmvG/XURkgQatqK8CtiCv8v4cmX6k56G8t1j/3FDBaL9kVxO/SKua9Fall6rCEKsI9hm1HJosSQv4FH8Phueqqx904GVnPDnms9B10+ZCN55qhq98KBmOufst/ya018hou1Q=; 5:H4ol3scI43skTJ1q1emqCgBKxkQF6+eE5/sBMTFqgAwKY/VELCq/Uwv4q4w6RHV6l8CrYQ8B1vZMhUprMBcIZqMMrafhTeWs07XRLWgP2Yyf+nGxvGNUFX7ZGvExKWGFqmGyyv1Xm9igm01TNBBO/5vqW+i0cKg4aE187dP6cL4=; 24:UbAeq+aOmeZW/iFMmJiSYY+rUf9d7uB1N242sRLPhXQZE5i9nw9j0saN8rjEXEeLiUUneOB4VlBLKU1zkB8qG2QwxNoMnHUV3oUtcBf1dds=; 7:NeWNJJ+KA68K4na3TlyVWrGKnB2VFpKcxTCXILMTWTmYRG7UP761nuF4ONaYlzBS00XKColBnCyax5l7my/DRaCOVaB8SuoZvt3hXIZ9S3o/wLNwH6aiPKPMuuAIubVyD9izUUZUQrb1Pp2cwKfuHveykjHQmjMq7K8mTO/KL5fJjHOowTYM8BXwsE2n1iRHsrnbgxuonsTqBRDRn8/45vyBrHmq/YlCAsyFxbyDlKHLIBW3/cA2kax4pdv21fwa x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0801MB1406; x-ms-traffictypediagnostic: VI1PR0801MB1406: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1406; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1406; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(396003)(366004)(376002)(39860400002)(199004)(189003)(40434004)(106356001)(6506007)(99936001)(59450400001)(3480700004)(53936002)(6116002)(86362001)(55016002)(97736004)(68736007)(6306002)(54896002)(74316002)(790700001)(9686003)(7736002)(8676002)(6436002)(2900100001)(3846002)(33656002)(8936002)(14454004)(7696005)(99286004)(105586002)(5890100001)(66066001)(2906002)(316002)(25786009)(81156014)(102836004)(478600001)(72206003)(5250100002)(7116003)(186003)(26005)(476003)(3280700002)(5660300001)(486006)(3660700001)(81166006)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1406; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: alQY7i1QWCBbU2lFDSSwNmh0l2wA/J/KReWBCFHN6fPSqT+iyoA/cbdt2zSalbPP9xkaxQnk3Vo9Dcdqy0BUUD0rAAwaOnjv59IMe1NtdJUuzQVGVaCar/78qI95AwoXdJ6brZxFEdPJPjF/LEKYzoZCtFb9dF4vHG4QVyhlsUKrbcwi5L5gwdP3iJD02KXj spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 337f4636-c48e-47f1-3507-08d5b4309863 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 337f4636-c48e-47f1-3507-08d5b4309863 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 15:38:34.9455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1406 Archived-At: Subject: [OAUTH-WG] OAuth Webex Info X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 15:38:40 -0000 --_004_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_ Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_" --_000_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

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_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_-- --_004_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_ Content-Type: text/calendar; name="OAuth_WebEx_Meeting.ics" Content-Description: OAuth_WebEx_Meeting.ics Content-Disposition: attachment; filename="OAuth_WebEx_Meeting.ics"; size=3696; creation-date="Mon, 07 May 2018 13:41:54 GMT"; modification-date="Mon, 07 May 2018 15:36:52 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpQYWNpZmljIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE2MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA3MDAKVFpPRkZTRVRUTzotMDgwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE2MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDgw MApUWk9GRlNFVFRPOi0wNzAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXph dGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZB TFNFOk1BSUxUTzpvYXV0aC1jaGFpcnNAaWV0Zi5vcmcKT1JHQU5JWkVSO0NOPSJ3ZWJleCI6TUFJ TFRPOm1lc3NlbmdlckB3ZWJleC5jb20KRFRTVEFSVDtUWklEPSJQYWNpZmljIFRpbWUiOjIwMTgw NTA3VDA4MzAwMApEVEVORDtUWklEPSJQYWNpZmljIFRpbWUiOjIwMTgwNTA3VDA5MzAwMApMT0NB VElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRTox NTI1NzAwNTI5ClVJRDphYTljMjc5MC1lODAzLTQ4YjgtODE0NS1mYTdiODdmZGMwZmIKRFRTVEFN UDoyMDE4MDUwN1QxNTMwMDBaCkRFU0NSSVBUSU9OOlxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00YjdjNTg4YjY0ZjcwNDRiYjMx MTgwODQ2YmY3ZWIwOFxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMzEwIDE2NSAxNzZc bk1lZXRpbmcgcGFzc3dvcmQ6IFdNVWdKcDJ4XG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTg3Ny02 NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgXG4xLTY1MC00Nzkt MzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblRvbGwtZnJlZSBkaWFsaW5n IHJlc3RyaWN0aW9uczogXG5odHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3Ry aWN0aW9ucy5wZGZcblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9y dCBoZXJlOlxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5P VElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRl ZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gWW91IHNob3Vs ZCBpbmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9yIHRvIHJlY29yZGluZyBpZiB5b3Ug aW50ZW5kIHRvIHJlY29yZCB0aGUgbWVldGluZy5cbgpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9o dG1sOgk8Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJ QUwiPgkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTRi N2M1ODhiNjRmNzA0NGJiMzExODA4NDZiZjdlYjA4Ij48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzAw QUZGOSIgRkFDRT0iQXJpYWwiPkpvaW4gV2ViRXggbWVldGluZzwvRk9OVD48L2E+CQkJPHRhYmxl PgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAzMTAgMTY1IDE3NjwvRk9O VD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0 ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkhvc3Qg a2V5OiA0NzkwODg8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwvdGFibGU+CQkJPHRhYmxl Pjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0 aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5XTVVnSnAyeDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4JCTwvRk9O VD48YnI+PEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiPjwvRk9OVD48YnI+PEZPTlQgU0la RT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxGT05UIFNJWkU9 IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJz cDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS02NTAt NDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9G T05UPiZuYnNwOyA8QlI+PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJl ZV9yZXN0cmljdGlvbnMucGRmIj48Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0i YXJpYWwiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8 QlI+PC9GT05UPjxCUj48QlI+CSZuYnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj4JCQkJQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhy ZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9S PSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNw OzxCUj4mbmJzcDs8QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFs Ij5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVj b3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLjwvRk9OVD48L0ZPTlQ+ ClNVTU1BUlk6T0F1dGggV0cgVmlydHVhbCBPZmZpY2UgSG91cnMKUFJJT1JJVFk6NQpDTEFTUzpQ VUJMSUMKQkVHSU46VkFMQVJNClRSSUdHRVI6LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJ T046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_004_VI1PR0801MB2112A925E7862549116B6457FA9B0VI1PR0801MB2112_-- From nobody Mon May 7 09:24: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 4C642120726 for ; Mon, 7 May 2018 09:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 bmcGyD8S3Of3 for ; Mon, 7 May 2018 09:23:56 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 C223B126DFF for ; Mon, 7 May 2018 09:23:55 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id f13-v6so27263910qtp.10 for ; Mon, 07 May 2018 09:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jt9hiPR1MYb2DW7GMendEZNnEDI7FeT7am/xtE3F66w=; b=dDtUW7bW9aZTB4TjN/mn+z7QfN8j+FGKEQG0B205pA3AIkFX6KmlkStE/JKkZkwLLB /oiS+5nGYxdgwrggD1I82sz/iCKyFO8dq6J/JaJMdRVCnYREkr0j5CqAPwyOtjWI9zto nNmvVoWc5kE/e8YZiqOJI5fZedDLUSUt3mKcThADbSYncZoTA0MhAMxoeamlMaR3dEYx i339aaDK2Ra8cLq2goy2Ep9ZORgz6MjQc0sZQlQpVj6kjO9ZhoUOw9/CGEPk+5MTF4BG C+cFPnVLSzy32gjK7rpMl7IWeilk9oVXOapMCM2HUuXLv1dAkoFTPy7WUT+B3otwopeu IzVw== 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=jt9hiPR1MYb2DW7GMendEZNnEDI7FeT7am/xtE3F66w=; b=Um30uiJ0JEcJe+dt2ET+IFZ7jm4jVVvTdWr3qkmLkMCCyJgqKIGHkFqApOCq7s6/a4 +16LN3Bz7CCAYnemBV1yRSaSGRpw86OqT/ZrC3XggYbqigA0s5wksX6DpBJlog8+DfRl UAfGbUy0C6bo/qiB8w9vPIU8GIoGGiUf0FWivR9r5Z0qVFk0+XGkxJu5vMipfpR7GUMc 6dqTq/oZHKsWOhYfkWfOXaJt1lofJpuEvFEEhTtpQjAtuKTMp+xUucdio/6wXzYGi5B5 7Kixs5VvTi+/TapN39Xikj1QcKIYOboIaNttyaQikJ31lq/VVtFLcD+utAADqmY9Jgsm 5gcQ== X-Gm-Message-State: ALQs6tAxBcRmoiPmTZ559ExnZ9L5ELFoIrx62MUtDtAl8lbxmWIfnWFm JRMVJe7LaL11GByY7XL36fQ7WPUwinY= X-Google-Smtp-Source: AB8JxZpG4MsJYxvaV9tFaw8qeU3KuN/XUBwEVk6cD5K5cHKgcF8L5fGw9S99ZlF4XeAFaBnJKRj34w== X-Received: by 2002:a0c:e242:: with SMTP id x2-v6mr18383568qvl.60.1525710234482; Mon, 07 May 2018 09:23:54 -0700 (PDT) Received: from [192.168.8.102] ([181.203.105.125]) by smtp.gmail.com with ESMTPSA id l38-v6sm21167490qta.86.2018.05.07.09.23.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 09:23:53 -0700 (PDT) From: John Bradley Message-Id: <248B2290-2548-44CE-BEE5-DBD198435E8E@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BD05775C-C27E-45B1-807E-21707A368BD3" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 7 May 2018 13:23:50 -0300 In-Reply-To: Cc: "" To: Hannes Tschofenig References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] OAuth Webex Info X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 16:23:58 -0000 --Apple-Mail=_BD05775C-C27E-45B1-807E-21707A368BD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry, you must have ended the call before I saw this. John B. > On May 7, 2018, at 12:38 PM, Hannes Tschofenig = wrote: >=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 = --Apple-Mail=_BD05775C-C27E-45B1-807E-21707A368BD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sorry, you must have ended the call before I saw this.

John B.

On May 7, 2018, at 12:38 PM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

 
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.&= lt;OAuth_WebEx_Meeting.ics>_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_BD05775C-C27E-45B1-807E-21707A368BD3-- From nobody Mon May 7 09:52: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 5666A1270A3 for ; Mon, 7 May 2018 09:52:03 -0700 (PDT) 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 kwfGB2MPyIkP for ; Mon, 7 May 2018 09:52:01 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 42E171270AE for ; Mon, 7 May 2018 09:52:01 -0700 (PDT) X-AuditID: 12074423-687ff70000007356-5f-5af0842db694 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id BD.C4.29526.E2480FA5; Mon, 7 May 2018 12:51:59 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w47GpscQ006182; Mon, 7 May 2018 12:51:55 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w47GppKc021560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2018 12:51:52 -0400 From: Justin Richer Message-Id: <42BF0AF3-A0C8-45BB-93C4-5F87A65680DE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2BDE1059-B2D2-4DFA-870C-B6562570A388" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 7 May 2018 12:51:51 -0400 In-Reply-To: <248B2290-2548-44CE-BEE5-DBD198435E8E@ve7jtb.com> Cc: Hannes Tschofenig , "" To: John Bradley References: <248B2290-2548-44CE-BEE5-DBD198435E8E@ve7jtb.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixG6nrqvf8iHK4NM7GYubM04xWZx8+4rN YvXdv2wOzB5r5q1h9Fiy5CeTx+3bG1kCmKO4bFJSczLLUov07RK4MrqvZBdMtqq4s+40cwPj WuMuRk4OCQETiVNf3jF1MXJxCAksZpI4OukRG0hCSGADo0RPbyaEfY1J4t8tBRCbTUBVYvqa FiYQm1fASuLgouXMXYwcHMwCSRLNXZEQYROJHVfa2EFsYQENiSt/XzCD2CwCKhLb924Bi3MK 2EkcW/ILqjVe4n+vM0hYBKhk375HjBDnTGGUWPRuLRvEnUoS/3cdYZ7AyD8LYdssJNtAbGYB bYllC18zQ9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqRrplebmaJ XmpK6SZGcJC7KO9gfNnnfYhRgINRiYf3R8GHKCHWxLLiytxDjJIcTEqivNwP3kcJ8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuFlUwYq501JrKxKLcqHSUlzsCiJ8y7evzdKSCA9sSQ1OzW1ILUI JivDwaEkwfutCahRsCg1PbUiLTOnBCHNxMEJMpwHaPg1kBre4oLE3OLMdIj8KUZLjkPvp/Qw c5wDk/9u7u9lFmLJy89LlRLn5WkGahAAacgozYObCUpa7uvsLF4xigO9KMybClLFA0x4cFNf AS1kAlooCPIpb3FJIkJKqoGx7vaSO9/uJW1oLM+30v1j/JKn4nbVcYtnMWwVyzy//DNfsUWm KeG5y6KGR53rL+U0/flaPFvOr6a9yWLX2+s3dNptGsrLj6brTQ1oivyV99x47oHlxRUf1PmX PzWVXCFznXHN7r+Mr5VvFIo+PZe03yE+dOXqmKs96ZJGNyJ58sSvbL35+tUNJZbijERDLeai 4kQAACs7WzUDAAA= Archived-At: Subject: Re: [OAUTH-WG] OAuth Webex Info X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 16:52:03 -0000 --Apple-Mail=_2BDE1059-B2D2-4DFA-870C-B6562570A388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It was a quick call and there were only a handful of us on this time. =E2=80=94 Justin > On May 7, 2018, at 12:23 PM, John Bradley wrote: >=20 > Sorry, you must have ended the call before I saw this. >=20 > John B. >=20 >> On May 7, 2018, at 12:38 PM, Hannes Tschofenig = > wrote: >>=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=_2BDE1059-B2D2-4DFA-870C-B6562570A388 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = was a quick call and there were only a handful of us on this time.

 =E2=80=94 = Justin

On May 7, 2018, at 12:23 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:

Sorry, you must have ended the call before I saw this.

John B.

On May 7, 2018, at 12:38 PM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

 
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_WebEx_Meeting.ics>_______________________________________________
OAuth mailing 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=_2BDE1059-B2D2-4DFA-870C-B6562570A388-- From nobody Mon May 7 13:00:34 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 F36DB129C51; Mon, 7 May 2018 13:00:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152572323194.1316.16504160657904107453@ietfa.amsl.com> Date: Mon, 07 May 2018 13:00:31 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 20:00:32 -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 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-08.txt Pages : 21 Date : 2018-05-07 Abstract: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either single certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-08 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 Mon May 7 13:14: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 54212129C6E for ; Mon, 7 May 2018 13:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, 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 kFOuOsRfwXjP for ; Mon, 7 May 2018 13:14:35 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 274A5129C5D for ; Mon, 7 May 2018 13:14:35 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id p124-v6so35707208iod.1 for ; Mon, 07 May 2018 13:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=y+d++YGljJqAbkhdRMjYYXKOE1O/POkhfv289c0FJco=; b=pW6aAd3ZNQnZ6XbomgF1OEne8kI9/3GBilnHcBKMH1IWs+PTlpIfMFwIZLx7Fis7Mq V37uyWirN2OegjUW8hebZfvevdaCpf7vjGkQQPxDqB6VOeaxp1XhZ7RXgQVCWXnZg0Qy tqtPSkdAoPQQo3FM2u8cTyKx5ptMLdJxvj7Gs= 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; bh=y+d++YGljJqAbkhdRMjYYXKOE1O/POkhfv289c0FJco=; b=U8PPoofxEbYveX5eSLL9/r0Ck6ango9GFsET89lrrR1A/ucL3Mc6dcBulQjEAVswmT FnzLTM0/Qsvi9DQRFj/849i+n1wjCzYVzE727VrG8Yu1FNm990Wk8lbGj4J049JXmpCT U1nhZiJln7aXZyKtrhMwQf9iEkZPDVNUJEq6XjpiC7rhQ9h19vSw04v/fBGYA7Aoxkss +42HOz9CzW58tn4NxOfhS6K6+WCaz75ZcxWXMlfXVHO1DfFwgKpbWZxLgwxeNxHIOUpj k5TzMcgJjWisY1GrjWviK4f7ROhDFHeyDUTlxYwLeFleggpZBoNrD3jLaIsXKJR4d+Tv gt/w== X-Gm-Message-State: ALKqPwe3NbQaAiblhOG97Hz+C019HsVd8rNldX4VuFN0lfgY8xR40GSb UG4b5RzTM0CJ6QuJruLuyMJ753uin0CNgZiRHEiGS8FThEl2HfTxwxEHuaI0Z5fvc2tnfmA7cwj 96uEgBkqvDnpyYIKM X-Google-Smtp-Source: AB8JxZpL5B94nbwz/yLSiY2O29Xbqw/eNUW0V6n+gBNnAmDalF/LmSFMtNwXqBzQ7qm/IdGoyjUjCTJ0Ub7qSRbc9+Y= X-Received: by 2002:a6b:1c06:: with SMTP id c6-v6mr466069ioc.247.1525724073962; Mon, 07 May 2018 13:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 7 May 2018 13:14:03 -0700 (PDT) In-Reply-To: <152572323194.1316.16504160657904107453@ietfa.amsl.com> References: <152572323194.1316.16504160657904107453@ietfa.amsl.com> From: Brian Campbell Date: Mon, 7 May 2018 14:14:03 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000744667056ba3510f" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 20:14:37 -0000 --000000000000744667056ba3510f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A new draft of the OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens specification has published with changes addressing review comments from Working Group Last Call. Thanks in particular to Justin Richer and Neil Madden for the detailed reviews. A summary of the changes (copied from the document history) is below. draft-ietf-oauth-mtls-08 o Incorporate clarifications and editorial improvements from Justin Richer's WGLC review o Drop the use of the "sender constrained" terminology per WGLC feedback from Neil Madden (including changing the metadata parameters from mutual_tls_sender_constrained_access_tokens to tls_client_certificate_bound_access_tokens) o Add a new security considerations section on X.509 parsing and validation per WGLC feedback from Neil Madden and Benjamin Kaduk o Note that a server can terminate TLS at a load balancer, reverse proxy, etc. but how the client certificate metadata is securely communicated to the backend is out of scope per WGLC feedback o Note that revocation checking is at the discretion of the AS per WGLC feedback o Editorial updates and clarifications o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf- oauth-token-binding to -06 o Add folks involved in WGLC feedback to the acknowledgements list ---------- Forwarded message ---------- From: Date: Mon, May 7, 2018 at 2:00 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt To: i-d-announce@ietf.org Cc: oauth@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 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-08.txt Pages : 21 Date : 2018-05-07 Abstract: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either single certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000744667056ba3510f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A new draft of the OAuth 2.0 Mutual TLS Client Authenticat= ion and Certificate Bound Access Tokens specification has=20 published with changes addressing review comments from Working Group=20 Last Call. Thanks in particular to Justin Richer and Neil Madden for the de= tailed reviews. A summary of the changes (copied from the document history)= is below.

=C2=A0=C2=A0 draft-ietf-oauth-mtls-08

=C2=A0=C2=A0= o=C2=A0 Incorporate clarifications and editorial improvements from Justin<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Richer's WGLC review
=C2=A0=C2=A0 = o=C2=A0 Drop the use of the "sender constrained" terminology per = WGLC
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 feedback from Neil Madden (including= changing the metadata
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parameters from mu= tual_tls_sender_constrained_access_tokens to
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 tls_client_certificate_bound_access_tokens)
=C2=A0=C2=A0 = o=C2=A0 Add a new security considerations section on X.509 parsing and
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 validation per WGLC feedback from Neil Madde= n and Benjamin Kaduk
=C2=A0=C2=A0 o=C2=A0 Note that a server can termina= te TLS at a load balancer, reverse
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 proxy,= etc. but how the client certificate metadata is securely
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 communicated to the backend is out of scope per WGLC fee= dback
=C2=A0=C2=A0 o=C2=A0 Note that revocation checking is at the discr= etion of the AS per
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WGLC feedback
=C2= =A0=C2=A0 o=C2=A0 Editorial updates and clarifications
=C2=A0=C2=A0 o=C2= =A0 Update draft-ietf-oauth-discovery reference to -10 and draft-ietf-
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 oauth-token-binding to -06
=C2=A0=C2=A0 o= =C2=A0 Add folks involved in WGLC feedback to the acknowledgements list
=

---------- Forwarded message ----------<= br>From: <internet-drafts@ietf= .org>
Date: Mon, May 7, 2018 at 2:00 PM
Subject: [OAUTH= -WG] I-D Action: draft-ietf-oauth-mtls-08.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access To= kens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-05-07

Abstract:
=C2=A0 =C2=A0This document describes OAuth client authentication and certif= icate
=C2=A0 =C2=A0bound access tokens using mutual Transport Layer Security (TLS= )
=C2=A0 =C2=A0authentication with X.509 certificates.=C2=A0 OAuth clients ar= e provided a
=C2=A0 =C2=A0mechanism for authentication to the authorization sever using = mutual
=C2=A0 =C2=A0TLS, based on either single certificates or public key infrast= ructure
=C2=A0 =C2=A0(PKI).=C2=A0 OAuth authorization servers are provided a mechan= ism for
=C2=A0 =C2=A0binding access tokens to a client's mutual TLS certificate= , and OAuth
=C2=A0 =C2=A0protected resources are provided a method for ensuring that su= ch an
=C2=A0 =C2=A0access token presented to it was issued to the client presenti= ng the
=C2=A0 =C2=A0token.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oaut= h-mtls-08
https://datatracker.ietf.org/doc/= html/draft-ietf-oauth-mtls-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-oauth-mtls-08


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000744667056ba3510f-- From nobody Mon May 7 13:17: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 B00BF129C5D for ; Mon, 7 May 2018 13:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 s8WXgo7LRBHq for ; Mon, 7 May 2018 13:17:04 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB81129C6E for ; Mon, 7 May 2018 13:17:03 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id f21-v6so35685194iob.13 for ; Mon, 07 May 2018 13:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wzOkfo4lJOke1Gs3AS8aib1NBebo+wSfd9Jk+OYqJU0=; b=LZ3HdEKlsWtwNbH9c1dKVhnFPRcuo5hDL45aw2KZRddqrJvyICrBomJoIQ3j0/sl++ drMscNqiyPhSruMrKu0BBI7GP8AAVSMQjMewTq6hVFE2Kc61eOVBYQMC7ia8c57UhcWi sxAr08c//Fug/kcHb6y1ZywE7T/VchiA8Fj5Q= 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; bh=wzOkfo4lJOke1Gs3AS8aib1NBebo+wSfd9Jk+OYqJU0=; b=uKHUCwQwKL+oG0SS8fvfSZF+qhEzY5NoJHUvFEWtzLTGTkIXLePz4t8UZ4a8n7prCv nSNMw5OQIENA0KtnN7H0Cm4Hd4938yvLIVRxbdirMp2pWqE5j1+tBTtzhXWP41f4lUmY P0IHblMCx4FUrhPQnuGOYftknF09Vn+h2S9aieL1sCsY7Hg0QFtk/4n7xMT1m0NWKmEK h3HrIse1NuSZ7Uk+CI/NPCThLfxyC7DYHiN/kgowsMb/R0wPOs5bQGHktbmSq0TAMENf xTrBgjvRSWQBm1PtX9MCJRDdOz7cQfNJClazoAnhc3KlTe0FrlT0/zkJgKDG+K67HSo6 yHrQ== X-Gm-Message-State: ALQs6tCP3peIciDzPZ+eLaVUilzmyRSSYA5zJnrtEX4YwfUp0SQIM3fI BZwA2ZVzaPE2obx6Kfk29MCPTTVdYqGBhyJKWt783UbQ+nhWr90wdBb3iZjyX1/gxqWr0vj4+yi YPvx3lsz3j01w/NTl X-Google-Smtp-Source: AB8JxZo4Bjp2M0BYtU3kDvSkZkAGwMAcBwU0idU/r6m+tP83rVNtDp3TslkkhCzX8w1Ur3oX1p42TCDGJk5ms3qM80o= X-Received: by 2002:a6b:8361:: with SMTP id f94-v6mr39354091iod.17.1525724222587; Mon, 07 May 2018 13:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 7 May 2018 13:16:32 -0700 (PDT) In-Reply-To: References: <152572323194.1316.16504160657904107453@ietfa.amsl.com> From: Brian Campbell Date: Mon, 7 May 2018 14:16:32 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000050289c056ba35a0f" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 20:17:07 -0000 --00000000000050289c056ba35a0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable has *been* published sigh On Mon, May 7, 2018 at 2:14 PM, Brian Campbell wrote: > A new draft of the OAuth 2.0 Mutual TLS Client Authentication and > Certificate Bound Access Tokens specification has published with changes > addressing review comments from Working Group Last Call. Thanks in > particular to Justin Richer and Neil Madden for the detailed reviews. A > summary of the changes (copied from the document history) is below. > > draft-ietf-oauth-mtls-08 > > o Incorporate clarifications and editorial improvements from Justin > Richer's WGLC review > o Drop the use of the "sender constrained" terminology per WGLC > feedback from Neil Madden (including changing the metadata > parameters from mutual_tls_sender_constrained_access_tokens to > tls_client_certificate_bound_access_tokens) > o Add a new security considerations section on X.509 parsing and > validation per WGLC feedback from Neil Madden and Benjamin Kaduk > o Note that a server can terminate TLS at a load balancer, reverse > proxy, etc. but how the client certificate metadata is securely > communicated to the backend is out of scope per WGLC feedback > o Note that revocation checking is at the discretion of the AS per > WGLC feedback > o Editorial updates and clarifications > o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf- > oauth-token-binding to -06 > o Add folks involved in WGLC feedback to the acknowledgements list > > > > ---------- Forwarded message ---------- > From: > Date: Mon, May 7, 2018 at 2:00 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt > To: i-d-announce@ietf.org > Cc: oauth@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 Mutual TLS Client Authentication and > Certificate Bound Access Tokens > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-08.txt > Pages : 21 > Date : 2018-05-07 > > Abstract: > This document describes OAuth client authentication and certificate > bound access tokens using mutual Transport Layer Security (TLS) > authentication with X.509 certificates. OAuth clients are provided a > mechanism for authentication to the authorization sever using mutual > TLS, based on either single certificates or public key infrastructure > (PKI). OAuth authorization servers are provided a mechanism for > binding access tokens to a client's mutual TLS certificate, and OAuth > protected resources are provided a method for ensuring that such an > access token presented to it was issued to the client presenting the > token. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-08 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-08 > > > 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 > > --=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._ --00000000000050289c056ba35a0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
has *been* published

sigh

On Mon, M= ay 7, 2018 at 2:14 PM, Brian Campbell <bcampbell@pingidentity.com= > wrote:
A= new draft of the OAuth 2.0 Mutual TLS Client Authentication and Certificat= e Bound Access Tokens specification has=20 published with changes addressing review comments from Working Group=20 Last Call. Thanks in particular to Justin Richer and Neil Madden for the de= tailed reviews. A summary of the changes (copied from the document history)= is below.

=C2=A0=C2=A0 draft-ietf-oauth-mtls-08

=C2=A0=C2=A0= o=C2=A0 Incorporate clarifications and editorial improvements from Justin<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Richer's WGLC review
=C2=A0=C2=A0 = o=C2=A0 Drop the use of the "sender constrained" terminology per = WGLC
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 feedback from Neil Madden (including= changing the metadata
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parameters from mu= tual_tls_sender_constrained_access_tokens to
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 tls_client_certificate_bound_access_tokens)
=C2=A0=C2=A0 = o=C2=A0 Add a new security considerations section on X.509 parsing and
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 validation per WGLC feedback from Neil Madde= n and Benjamin Kaduk
=C2=A0=C2=A0 o=C2=A0 Note that a server can termina= te TLS at a load balancer, reverse
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 proxy,= etc. but how the client certificate metadata is securely
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 communicated to the backend is out of scope per WGLC fee= dback
=C2=A0=C2=A0 o=C2=A0 Note that revocation checking is at the discr= etion of the AS per
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WGLC feedback
=C2= =A0=C2=A0 o=C2=A0 Editorial updates and clarifications
=C2=A0=C2=A0 o=C2= =A0 Update draft-ietf-oauth-discovery reference to -10 and draft-ietf-
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 oauth-token-binding to -06
=C2=A0=C2=A0 o= =C2=A0 Add folks involved in WGLC feedback to the acknowledgements list



---------- Forwar= ded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 7, 2018 at 2:00 = PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt
To: <= a href=3D"mailto:i-d-announce@ietf.org" target=3D"_blank">i-d-announce@ietf= .org
Cc: oauth@i= etf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access To= kens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-05-07

Abstract:
=C2=A0 =C2=A0This document describes OAuth client authentication and certif= icate
=C2=A0 =C2=A0bound access tokens using mutual Transport Layer Security (TLS= )
=C2=A0 =C2=A0authentication with X.509 certificates.=C2=A0 OAuth clients ar= e provided a
=C2=A0 =C2=A0mechanism for authentication to the authorization sever using = mutual
=C2=A0 =C2=A0TLS, based on either single certificates or public key infrast= ructure
=C2=A0 =C2=A0(PKI).=C2=A0 OAuth authorization servers are provided a mechan= ism for
=C2=A0 =C2=A0binding access tokens to a client's mutual TLS certificate= , and OAuth
=C2=A0 =C2=A0protected resources are provided a method for ensuring that su= ch an
=C2=A0 =C2=A0access token presented to it was issued to the client presenti= ng the
=C2=A0 =C2=A0token.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oaut= h-mtls-08
https://datatracker.ietf.org/doc/= html/draft-ietf-oauth-mtls-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-oauth-mtls-08


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000050289c056ba35a0f-- From nobody Mon May 7 15:35: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 9A923124239; Mon, 7 May 2018 15:35:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152573253859.20101.13765310889276893523@ietfa.amsl.com> Date: Mon, 07 May 2018 15:35:38 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 22:35:39 -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-03.txt Pages : 13 Date : 2018-05-07 Abstract: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-03 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 May 8 00: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 D923512D877 for ; Tue, 8 May 2018 00:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-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=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 LFy9Or_ZYptQ for ; Tue, 8 May 2018 00:26:58 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0102.outbound.protection.outlook.com [104.47.38.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9BD12704A for ; Tue, 8 May 2018 00:26:57 -0700 (PDT) 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; bh=wM/9ZhHoen0xDUeT0bL4KJWEKiSXZD1INMOauUxjKUU=; b=dlsZcOu6rlYb97IiFgDHdyfCTSiiij/YVdo9QjQtGtKaPtpCtCcYJSu6xCJbENFOa/40pWGYM3Y5Sxloa33FW0VNwYue79EEF7eupuZgdChItWlocsB7PY7plvsGgLSXt9ufJ+iPRRrSZT1yCR0l7fxxNoLGGsnKOuGBa/V0iQw= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0337.namprd00.prod.outlook.com (2603:10b6:207:1f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.789.0; Tue, 8 May 2018 07:26:50 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0788.000; Tue, 8 May 2018 07:26:50 +0000 From: Mike Jones To: Hannes Tschofenig , Rifaat Shekh-Yusef CC: "oauth@ietf.org" , Benjamin Kaduk , "Kathleen.Moriarty.ietf@gmail.com" Thread-Topic: Working Group Last Call: JSON Web Token Best Current Practices Thread-Index: AdPVqurCFfBabyqeSkmiBPeLsGrqowQ8jdsg Date: Tue, 8 May 2018 07:26:50 +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-05-08T07:26:48.5737142Z; 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: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0337; 7:tbkdZqwbk7E1pB9GmguZNhVvyP9QxYtlrHxz9EGEaZK77ASDIWBeD/ECk1JRSFRtPokrkfSiReuMXVjlChwxEHjRXqSjHCpcovGE++r1nr0v8WWXcKv/6rYj9ysnmtw2QEzubyNYyMjLZuvcvB0zLMzbgRCAfloEGWu9NyaYxC3yoLFMU1nUa5IXfHnqX5M+WrnjU68ii2M9duev3F6mPpQo6TY9yPMGQyd6eOcIavpI1xRm9ET0WP62nq+pFFiQ; 20:bJl4X5yC04w029FBJtBAjs+H1xKSsuzBog4gHaoGV94WReaPm46BzBA4ftQzaIOsc6q3T25aQa2XsgU51Y3424Te3uNkWxic+leRsjv/fwV/YG44eofnAO86WORT5Im/pgb1W8oWnHmIW9pvRm5EJhlCqHsC5xzzhQEHRqPeoIA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0337; x-ms-traffictypediagnostic: BL0PR00MB0337: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BL0PR00MB0337; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0337; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(366004)(39380400002)(53754006)(189003)(199004)(13464003)(40434004)(966005)(4326008)(72206003)(10290500003)(8936002)(413944005)(8676002)(55016002)(9686003)(25786009)(14454004)(33656002)(6506007)(53546011)(3660700001)(2906002)(68736007)(7736002)(74316002)(97736004)(53936002)(86362001)(8990500004)(22452003)(316002)(6306002)(81166006)(81156014)(6246003)(305945005)(39060400002)(478600001)(2900100001)(10090500001)(110136005)(54906003)(486006)(229853002)(6436002)(476003)(86612001)(102836004)(76176011)(52396003)(5890100001)(5250100002)(11346002)(446003)(7696005)(99286004)(106356001)(5660300001)(26005)(105586002)(59450400001)(66066001)(6346003)(6116002)(3846002)(186003)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0337; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: /qxJ/gvPr3gBeQf+thdeFEalYQH2G68LpCIDKXL10ViOhkJa3MVw240Upr/QLH3VctnMX/jNxv3Aax2MohnfwGWsTnNYSWnFTJdDndJ/ZCxBHdOMm0HdYzENafWqQHpBw5Rm6k9eFCZLG7P3qVFQfgNzc7DFMzYgSdUM/crS7/QYAMpevNG+yLo/e+X6qx29 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8b19b5cb-0a56-4c8c-bbc5-08d5b4b510e7 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b19b5cb-0a56-4c8c-bbc5-08d5b4b510e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 07:26:50.6564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0337 Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 07:27:01 -0000 Dear OAuth chairs, The editors of the JWT BCP published https://tools.ietf.org/html/draft-ietf= -oauth-jwt-bcp-02 to address all the WGLC feedback received and https://too= ls.ietf.org/html/draft-ietf-oauth-jwt-bcp-03 to add an acknowledgement. Gi= ven that the WGLC expired 1.5 weeks ago and all the comments have been addr= essed, the editors believe that it's time to request publication. Could yo= u please take the necessary chair actions to do so? I know that I'm personally finding more and more circumstances in which I'm= referring people to content in this draft BCP and so it seems to me that i= t would be useful to get it published soon as a real BCP. Thanks again, -- Mike P.S. Thanks again to Kathleen for urging us to create this BCP, based on t= he increasingly widespread use of JWT within the IETF! -----Original Message----- From: OAuth On Behalf Of Hannes Tschofenig Sent: Monday, April 16, 2018 10:49 AM To: oauth Subject: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Pr= actices Hi all, this is a last call for comments on https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01 Please have your comments in no later than April 30th. Do remember to send a note in if you have read the document and have no oth= er comments other than "its ready to go" - we need those as much as we need= "I found a problem". 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 From nobody Tue May 8 05:06: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 071BE12DA07 for ; Tue, 8 May 2018 05:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 vQw6nIOhhRhY for ; Tue, 8 May 2018 05:06:21 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 03DCE12D96B for ; Tue, 8 May 2018 05:06:20 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id a12-v6so1154297wrn.13 for ; Tue, 08 May 2018 05:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=/E11XDdFGBBVHzPZ2KNM50dYFxrWIEizYsxmffmYbOc=; b=fhG4Ev4W8u6lLVnadWa9BP7e0VC+xBkyPsDGBIFZsfpR9QoKUxPDl6kOjznOgeVzB8 BD+tMmcZVfKulyOblrqsulW6B76yPIy6b44AqBG0974Z+NdSH9WZP96vYW+dJroq+j2t Xn8eKQY0YcwQn7uzHSI23n4CLrOk3RhydiFa8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=/E11XDdFGBBVHzPZ2KNM50dYFxrWIEizYsxmffmYbOc=; b=bBZq5R+p8pFgZMfQJJgcrLDxNhHPA3pfKF8PaOyw+O05GLv38T9F/XGq4o/gxIsBqB TmB4iOJYtErwmchF4/WQCrtlkH9mj/jcPqYMLoFwtyaKVVwjYgREfcuPFJxG015CIn8s Peckk+O58TfKVBkOx1wn9Amivr2OfsbqGZf1ZkQ/Zt8QAB2WfmQYyYcYqaXHIDAv6IUD jwqBJK0p3oGDVwS0Bmif82Cl4tQtrnpD6XVy5L+336x3v8yVCWk+SfFC3kmaUidBrv9x I9NO5mDY3PbXVAGds2cyiA3GDMdDbwnxyOqE5j8KxH1jp3nB9sVE4JS1AQWQ7n7y1dT+ WBzw== X-Gm-Message-State: ALQs6tCupcm/xTfdRkIt3seXeKwcnZcYx7Kgq7eEq1gaJnvm+Ca6YNZj +VKxUP46/XWeR2VWltRE+IfI6NIiQdFU36pWakYKGSl/7258zbS2bgvGw8SdMrAC+vCd70eEZra PaxjEVklHPBYgtZib17rFO/ug6hsfm5uoEVbj/qJZgIz3Jql3JT2OMa2JkxqQ960= X-Google-Smtp-Source: AB8JxZo3NbOWicoxxlg1pe0dV1jTkAP/d9cysAJxrbE/khSwN7Q1Sv1Hrp16H/HnlEd8O+70kRG2+Q== X-Received: by 2002:adf:b0c1:: with SMTP id j1-v6mr30567705wra.3.1525781179154; Tue, 08 May 2018 05:06:19 -0700 (PDT) Received: from guest2s-mbp.home (72.142.200.146.dyn.plus.net. [146.200.142.72]) by smtp.gmail.com with ESMTPSA id i30-v6sm49117557wra.38.2018.05.08.05.06.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 May 2018 05:06:18 -0700 (PDT) From: Neil Madden Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 8 May 2018 13:06:17 +0100 References: <152573253859.20101.13765310889276893523@ietfa.amsl.com> To: oauth In-Reply-To: <152573253859.20101.13765310889276893523@ietfa.amsl.com> Message-Id: <0DA0C828-494D-42DD-B179-FEEEEC8EF717@forgerock.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 12:06:24 -0000 I was just checking over this latest draft and I noticed that the = reference to [nist-sp-800-56a-r3] currently links to = https://csrc.nist.gov/CSRC/media/Publications/sp/800-56a/rev-3/draft/docum= ents/sp800-56ar3-draft.pdf, which is a superseded draft. The final = revision 3 is available at = https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pd= f (or https://doi.org/10.6028/NIST.SP.800-56Ar3 might be preferable for = long-term stability). Kind regards, =E2=80=94 Neil > On 7 May 2018, at 23:35, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : JSON Web Token Best Current Practices > Authors : Yaron Sheffer > Dick Hardt > Michael B. Jones > Filename : draft-ietf-oauth-jwt-bcp-03.txt > Pages : 13 > Date : 2018-05-07 >=20 > Abstract: > JSON Web Tokens, also known as JWTs, are URL-safe JSON-based = security > tokens that contain a set of claims that can be signed and/or > encrypted. JWTs are being widely used and deployed as a simple > security token format in numerous protocols and applications, both = in > the area of digital identity, and in other application areas. The > goal of this Best Current Practices document is to provide = actionable > guidance leading to secure implementation and deployment of JWTs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bcp-03 >=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 From nobody Tue May 8 06:16: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 2A6D8120725 for ; Tue, 8 May 2018 06:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lmnKPVr4r099 for ; Tue, 8 May 2018 06:16:17 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9697F12E86E for ; Tue, 8 May 2018 06:16:10 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id b25so13958416uak.3 for ; Tue, 08 May 2018 06:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9L5PKONpETb/UNF9pHoUcKXiF2V7CUztzhZEJasED00=; b=JCdPQ7r8BVockKvjxJqSuONEcUNCmXLDcoTC1nTDJxWKkDF1E3Q4PZA1jRnKRJcYNy Tm41CSi236KodpQGaMkpNNTEO02sFPNtaNhBaHc11PCIDxrvXKOQxhdm+WbyyJn7LmHS TgHoreQG+3Qne59cbeLh+T54kCgnVoj0VA/XXS61JIuTp3igbaERl84XWkT3cFOl3MpE Anvxr0EGDnDs2frQ9AzkX3xddMeaQ+QDQ8/P9Qwt3BQhf5D+c0Yp5qbUOyQWYQmLoOzu Jvd/tvFByRqH0OKUSS6awYVWZwVQV0qn9Cpc9xeun7Y2d9mSvc7eYX2tl0PQxhxwMNeI D5GA== 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=9L5PKONpETb/UNF9pHoUcKXiF2V7CUztzhZEJasED00=; b=KlOMfG1tAfefeZZT7SjZD4mlJulhwmla3nWRrGuO1mqcLqAX9FA+wIvBPK5d0D08CJ i5F+t6kiMWHsC9B7XtlU2gWpiz3bQs3LyDITnU3Msv0F6ZLQmzAKAZJP5iRSTQGHAI06 s7LaBfskpUyYz4Fc336ZR7codZEv4ITXdWlb9BdNouf0rBrKibYRESYDDC3OrT3t/eeS Y0MUzCN0FT5SM83ep1J3WG8jW2a6qfntPoqDtjJMiF3coDqW2vGyXJjZE1i/TSWTH3AW aq9etOMrUMYrlcVjUUjWi3oaZLCwWl0iV6okqJWpwL+KWWgomqdd3e6OQA1iQ+gJo3uE zaRQ== X-Gm-Message-State: ALQs6tDRvaSVmg6u+vctEWuDV41e0ctyOLtoJH/DcWrOc0fmznIIIgKi iqhG2cBeSg6mV4rM4V8cPcdSWMvESIf8R7l3RyM= X-Google-Smtp-Source: AB8JxZqopl2btBY6d11m3iI162KGhkEOw2y5XewumBjtieTEl2juqGQL/12pd7MK+peUdOBg+5OJpNcpr90gZnE3g9M= X-Received: by 10.176.82.87 with SMTP id j23mr34899708uaa.70.1525785369725; Tue, 08 May 2018 06:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.109 with HTTP; Tue, 8 May 2018 06:16:09 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Tue, 8 May 2018 09:16:09 -0400 Message-ID: To: Mike Jones Cc: Hannes Tschofenig , "oauth@ietf.org" , Benjamin Kaduk , "Kathleen.Moriarty.ietf@gmail.com" Content-Type: multipart/alternative; boundary="94eb2c19101ef75137056bb1964a" Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 13:16:19 -0000 --94eb2c19101ef75137056bb1964a Content-Type: text/plain; charset="UTF-8" Thanks Mike! Hannes and I will review the document and get back to you on this next week. Regards, Rifaat On Tue, May 8, 2018 at 3:26 AM, Mike Jones wrote: > Dear OAuth chairs, > > The editors of the JWT BCP published https://tools.ietf.org/html/ > draft-ietf-oauth-jwt-bcp-02 to address all the WGLC feedback received and > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03 to add an > acknowledgement. Given that the WGLC expired 1.5 weeks ago and all the > comments have been addressed, the editors believe that it's time to request > publication. Could you please take the necessary chair actions to do so? > > I know that I'm personally finding more and more circumstances in which > I'm referring people to content in this draft BCP and so it seems to me > that it would be useful to get it published soon as a real BCP. > > Thanks again, > -- Mike > > P.S. Thanks again to Kathleen for urging us to create this BCP, based on > the increasingly widespread use of JWT within the IETF! > > -----Original Message----- > From: OAuth On Behalf Of Hannes Tschofenig > Sent: Monday, April 16, 2018 10:49 AM > To: oauth > Subject: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current > Practices > > Hi all, > > this is a last call for comments on > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01 > > Please have your comments in no later than April 30th. > > Do remember to send a note in if you have read the document and have no > other comments other than "its ready to go" - we need those as much as we > need "I found a problem". > > 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 > --94eb2c19101ef75137056bb1964a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mike!

Hannes and I will review t= he document and get back to you on this next week.

Regards,
=C2=A0Rifaat


On Tue, May 8, 2018 at 3:26 AM, M= ike Jones <Michael.Jones@microsoft.com> wrote:
=
Dear OAuth chairs,

The editors of the JWT BCP published https://= tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-02 to address all the= WGLC feedback received and https://tools.iet= f.org/html/draft-ietf-oauth-jwt-bcp-03 to add an acknowledgement.= =C2=A0 Given that the WGLC expired 1.5 weeks ago and all the comments have = been addressed, the editors believe that it's time to request publicati= on.=C2=A0 Could you please take the necessary chair actions to do so?

I know that I'm personally finding more and more circumstances in which= I'm referring people to content in this draft BCP and so it seems to m= e that it would be useful to get it published soon as a real BCP.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks again,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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

P.S.=C2=A0 Thanks again to Kathleen for urging us to create this BCP, based= on the increasingly widespread use of JWT within the IETF!

-----Original Message-----
From: OAuth <oauth-bounces@iet= f.org> On Behalf Of Hannes Tschofenig
Sent: Monday, April 16, 2018 10:49 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Pr= actices

Hi all,

this is a last call for comments on
https://tools.ietf.org/html/draft-ietf-o= auth-jwt-bcp-01

Please have your comments in no later than April 30th.

Do remember to send a note in if you have read the document and have no oth= er comments other than "its ready to go" - we need those as much = as we need "I found a problem".

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

--94eb2c19101ef75137056bb1964a-- From nobody Tue May 8 12:04: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 5A53512D94A for ; Tue, 8 May 2018 12:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-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=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 p5qtL07doGZz for ; Tue, 8 May 2018 12:04:49 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0092.outbound.protection.outlook.com [104.47.37.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1B112D77E for ; Tue, 8 May 2018 12:04:49 -0700 (PDT) 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; bh=0EquYmsmDXYkZO8tjBrslCFXvB48TzJfiE8cVlF/RIk=; b=kDq37ViwEc60H2zxDwb7WvTwS7mD8dTLfSi4/ffUDjEYsbp8cb8Ba2puhvtyG4vAM1HAKA8AmDXSwpQGzqF+mCYCHC6Do/4gOol+nX6pksQXliTpxEg6kp02DLToPMP9jqRXMlry7HXlSxFphtjpbMnoJfLYisz+Wq8SF3+f+6c= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0307.namprd00.prod.outlook.com (2603:10b6:207:1e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.791.0; Tue, 8 May 2018 19:04:47 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0792.000; Tue, 8 May 2018 19:04:47 +0000 From: Mike Jones To: Neil Madden , oauth Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-03.txt Thread-Index: AQHT5lPQcV+KSzkdOE6+kyTB8cl2C6QlvUiAgAB0BeA= Date: Tue, 8 May 2018 19:04:47 +0000 Message-ID: References: <152573253859.20101.13765310889276893523@ietfa.amsl.com> <0DA0C828-494D-42DD-B179-FEEEEC8EF717@forgerock.com> In-Reply-To: <0DA0C828-494D-42DD-B179-FEEEEC8EF717@forgerock.com> 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-05-08T19:04:46.2163659Z; 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:3::291] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0307; 7:7Bt7jRq+v8zRN7JeMPLvGI5luV5zCbJfUYGm8oNTjcMgfZ4UDupiuvAuK/JQgyyJAmYK5pO/GFonJsiKQMN+fbEYXBU+pAlHKLhBTEzLVOwOCtloCTi1JyyoLWyPS1bhBQFkN+Uk4M3rmACYVtYrfXyOyT6y38H/j9898Kqp9q8wFPjmhXyURabI5UDjqPJSi+ZwMhys98AVs24KBmNqQLP/Uns0jxrVnarOUXsVHJtYNeKm1HPR1UZs6vubKZ+O; 20:l8QO6gfezOnaOGq/CUWwF/yf5msbpYNvg3f4wQF/AW0+KT3pHwPw+eGoOsDBtuUrFvLYPodYQMStSPG7ZQQbXGJHZS5ypxPMJOlCjR4J/AtE39QVzrMCNgmgk0Enfpff/a7uEQRwJ3EYqQ0jcgNh5aG1fTvlBENzoxWf0+nCZcg= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:BL0PR00MB0307; x-ms-traffictypediagnostic: BL0PR00MB0307: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(165104125076784)(65766998875637)(278428928389397)(120809045254105)(192374486261705)(131022147185803); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BL0PR00MB0307; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0307; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39860400002)(39380400002)(346002)(376002)(189003)(199004)(13464003)(377424004)(86612001)(14454004)(86362001)(446003)(11346002)(316002)(6436002)(2906002)(8990500004)(478600001)(74316002)(52396003)(6306002)(53936002)(486006)(2900100001)(476003)(9686003)(6246003)(5250100002)(46003)(97736004)(22452003)(110136005)(25786009)(229853002)(59450400001)(105586002)(55016002)(102836004)(76176011)(6346003)(6506007)(33656002)(72206003)(6116002)(68736007)(53546011)(966005)(106356001)(3280700002)(305945005)(5660300001)(7736002)(186003)(7696005)(3660700001)(99286004)(81166006)(81156014)(8676002)(10090500001)(8936002)(10290500003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0307; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: cXldVXaR+KkSGJluJVLi33NO0Gbv1PBVpzkz4OSxVwpJGSHCPwPta6p7qtbZ5xHqe/c8f2HUt3fPUBj6SnIAlLM4vCZyobuQkDSkYC5fhPXe/epnjImrEFwfw3Ne4FjQT5TbQUhmVMuQd3hzsu/eED42F1I3wet5XibtbtdQYXPhlGOsCjC9KcIuPacKBAp3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4e9aafca-95c4-4c25-f44c-08d5b516918b X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e9aafca-95c4-4c25-f44c-08d5b516918b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 19:04:47.7358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0307 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 19:04:53 -0000 VGhhbmtzLCBOZWlsLiAgSSd2ZSBtYWRlIGEgbm90ZSBvZiB0aGlzIHNvIHRoYXQgd2UgY2FuIHVw ZGF0ZSB0aGUgcmVmZXJlbmNlIHRoZSBuZXh0IHRpbWUgd2UncmUgZWRpdGluZyB0aGUgc3BlYy4N Cg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9BdXRo IDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTmVpbCBNYWRkZW4NClNlbnQ6 IFR1ZXNkYXksIE1heSA4LCAyMDE4IDU6MDYgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWp3 dC1iY3AtMDMudHh0DQoNCkkgd2FzIGp1c3QgY2hlY2tpbmcgb3ZlciB0aGlzIGxhdGVzdCBkcmFm dCBhbmQgSSBub3RpY2VkIHRoYXQgdGhlIHJlZmVyZW5jZSB0byBbbmlzdC1zcC04MDAtNTZhLXIz XSBjdXJyZW50bHkgbGlua3MgdG8gaHR0cHM6Ly9jc3JjLm5pc3QuZ292L0NTUkMvbWVkaWEvUHVi bGljYXRpb25zL3NwLzgwMC01NmEvcmV2LTMvZHJhZnQvZG9jdW1lbnRzL3NwODAwLTU2YXIzLWRy YWZ0LnBkZiwgd2hpY2ggaXMgYSBzdXBlcnNlZGVkIGRyYWZ0LiBUaGUgZmluYWwgcmV2aXNpb24g MyBpcyBhdmFpbGFibGUgYXQgaHR0cHM6Ly9udmxwdWJzLm5pc3QuZ292L25pc3RwdWJzL1NwZWNp YWxQdWJsaWNhdGlvbnMvTklTVC5TUC44MDAtNTZBcjMucGRmIChvciBodHRwczovL2RvaS5vcmcv MTAuNjAyOC9OSVNULlNQLjgwMC01NkFyMyBtaWdodCBiZSBwcmVmZXJhYmxlIGZvciBsb25nLXRl cm0gc3RhYmlsaXR5KS4NCg0KS2luZCByZWdhcmRzLA0KDQrigJQgTmVpbA0KDQo+IE9uIDcgTWF5 IDIwMTgsIGF0IDIzOjM1LCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+IA0KPiAN Cj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXRyBvZiB0aGUgSUVURi4NCj4gDQo+ICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBKU09OIFdlYiBUb2tlbiBCZXN0IEN1cnJlbnQgUHJhY3Rp Y2VzDQo+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBZYXJvbiBTaGVmZmVyDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICBEaWNrIEhhcmR0DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBN aWNoYWVsIEIuIEpvbmVzDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW9hdXRoLWp3 dC1iY3AtMDMudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAxMw0KPiAJRGF0ZSAgICAgICAgICAg IDogMjAxOC0wNS0wNw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgSlNPTiBXZWIgVG9rZW5zLCBhbHNv IGtub3duIGFzIEpXVHMsIGFyZSBVUkwtc2FmZSBKU09OLWJhc2VkIHNlY3VyaXR5DQo+ICAgdG9r ZW5zIHRoYXQgY29udGFpbiBhIHNldCBvZiBjbGFpbXMgdGhhdCBjYW4gYmUgc2lnbmVkIGFuZC9v cg0KPiAgIGVuY3J5cHRlZC4gIEpXVHMgYXJlIGJlaW5nIHdpZGVseSB1c2VkIGFuZCBkZXBsb3ll ZCBhcyBhIHNpbXBsZQ0KPiAgIHNlY3VyaXR5IHRva2VuIGZvcm1hdCBpbiBudW1lcm91cyBwcm90 b2NvbHMgYW5kIGFwcGxpY2F0aW9ucywgYm90aCBpbg0KPiAgIHRoZSBhcmVhIG9mIGRpZ2l0YWwg aWRlbnRpdHksIGFuZCBpbiBvdGhlciBhcHBsaWNhdGlvbiBhcmVhcy4gIFRoZQ0KPiAgIGdvYWwg b2YgdGhpcyBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGRvY3VtZW50IGlzIHRvIHByb3ZpZGUgYWN0 aW9uYWJsZQ0KPiAgIGd1aWRhbmNlIGxlYWRpbmcgdG8gc2VjdXJlIGltcGxlbWVudGF0aW9uIGFu ZCBkZXBsb3ltZW50IG9mIEpXVHMuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtand0LWJjcC8NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGh0 bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJjcC0wMw0KPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJjcC0wMw0KPiANCj4gQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLTAzDQo+IA0K PiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0 aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQo= From nobody Tue May 8 12:28: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 5D30512E8AF for ; Tue, 8 May 2018 12:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-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=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 32Sjd02dLvCr for ; Tue, 8 May 2018 12:27:56 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0131.outbound.protection.outlook.com [104.47.34.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18FF12EB15 for ; Tue, 8 May 2018 12:27:55 -0700 (PDT) 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; bh=kU9rgBED3oL6CajPOjaMlfRbefONn7pwfHW8wK8sEG8=; b=Rh0hMRlglhu9vQtXruv6J3Kqy2qbNSUigioM2ZePdEeiWc8urabEgNYvweqFFDgd9F91kzgRoUiNxVvnrP/LpqByenrE7PtabC4ujRpQmLSXFCThjqsFw+jLwg8mOJ8ZyfsBqjh0x1X9+djEfa2NIommT36+6/bxLZnTXFb8hxM= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.792.0; Tue, 8 May 2018 19:27:52 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0792.000; Tue, 8 May 2018 19:27:52 +0000 From: Mike Jones To: Carsten Bormann , Hannes Tschofenig CC: oauth Thread-Topic: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices Thread-Index: AdPVqurCFfBabyqeSkmiBPeLsGrqowAi18cAAANH+4AEL6mvQA== Date: Tue, 8 May 2018 19:27:51 +0000 Message-ID: References: <2A008301-0BB6-4DAB-98AF-0728FEE5F205@tzi.org> 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-05-08T19:27:49.1961735Z; 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:3::291] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0292; 7:eFgBA/yG6cg45vTF1Qg5GMlW+AHI79DvMmgUEvogIahCKGYb/6b6gkR8ZaDIFCjUN0LTVj9GXGyoweZJjCmlLwZoObI/hTCY7hfSQwJ9orNaAIaBpUD9zukGWOyWVtt5k0sCa7WDWFY9YEwbKFvEbX6R2Lr1s9HpLI0d98FJjhSu0yqJHNIM0aMkjN4Gs13c4t+FED+7s9ZxF6fXtEADx4OXImRbHjSr2/kx38mjKzBbVT7oBbJU6b1LSSTo6MTn; 20:egNnv/nUu8rTBri9zcOkv1cygyxKVvn22ZUcaGn9wvUJaVSGWuEcPJR1AlIkzPzQHegjTCWe2FsODbABsxuDXsxsqDLITCxVfCbkf/nDk4gPqPg4nqftHHLfFzwj4gtLJPhx/ePiyXF8SRtDqpYBJ5FPxDepcrZCDCEf8PxaxVA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:BL0PR00MB0292; x-ms-traffictypediagnostic: BL0PR00MB0292: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BL0PR00MB0292; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0292; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(39380400002)(376002)(346002)(13464003)(189003)(199004)(99286004)(478600001)(6436002)(110136005)(966005)(4326008)(72206003)(86362001)(6246003)(229853002)(76176011)(7696005)(55016002)(6346003)(6306002)(102836004)(9686003)(25786009)(59450400001)(486006)(53936002)(476003)(186003)(52396003)(10290500003)(316002)(22452003)(5250100002)(11346002)(53546011)(6506007)(446003)(68736007)(8990500004)(46003)(14454004)(305945005)(7736002)(33656002)(81156014)(8676002)(81166006)(8936002)(5660300001)(105586002)(106356001)(6116002)(2900100001)(86612001)(2906002)(74316002)(3660700001)(97736004)(10090500001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0292; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: efFaTnpT8XueLdnbivP/HhoiuAp/0OgvSSv3doq2R8nNEBqKiMb8zrVNSSFtHYGH1lBe5jjccPPW2J4fQGxMPKDjunV+jKeqbe2OftI1okCuabaU40Jg2qDs9X4aku/wGhZMYsww6N61uuM6oSeTEjm22zhQfHL1yd09ASOonSpojcSrhOJcIKaxD9ZlfDj4 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 590b90f3-5b55-4d06-8c90-08d5b519caa2 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 590b90f3-5b55-4d06-8c90-08d5b519caa2 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 19:27:52.0362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0292 Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 19:28:01 -0000 SGkgQ2Fyc3RlbiwNCg0KSW4gcHJlcGFyaW5nIGEgZGVzY3JpcHRpb24gb2YgdGhlIGNoYW5nZXMg bWFkZSBmb3IgV0dMQywgSSByZXJlYWQgeW91ciBjb21tZW50cyBiZWxvdyBhbmQgc2F3IHRoYXQg d2UgZmFpbGVkIHRvIGRvIHRoZSB1cGRhdGUgdG8gdGhlIFJGQyA4MTc0IHRlbXBsYXRlLiAgSSd2 ZSBtYWRlIGEgbm90ZSBvZiBpdCBhbmQgd2lsbCBwbGFuIHRvIGRvIHNvIHdoZW4gd2UgbmV4dCBl ZGl0IHRoZSBkb2N1bWVudC4NCg0KUmVzcG9uZGluZyB0byB5b3VyIHBvaW50IGFib3V0IHRoZSAi K2p3dCIgc3RydWN0dXJlZCBzeW50YXggcmVnaXN0cmF0aW9uIC0gdGhpcyByZWdpc3RyYXRpb24g aXMgYmVpbmcgZG9uZSBieSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1z ZWNldmVudC10b2tlbi0xMSNzZWN0aW9uLTcuMi4gIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBkaXNj dXNzZWQgb24gdGhpcyB3ZWVrJ3MgdGVsZWNoYXQuDQoNCkkgYmVsaWV2ZSB0aGF0IGFsbCB5b3Vy IG90aGVyIHBvaW50cyBiZWxvdyBoYXZlIGJlZW4gYWRkcmVzc2VkLg0KDQoJCQkJVGhhbmtzIGFn YWluLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9B dXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5u DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxOCA0OjU5IEFNDQpUbzogSGFubmVzIFRzY2hv ZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGw6IEpT T04gV2ViIFRva2VuIEJlc3QgQ3VycmVudCBQcmFjdGljZXMNCg0KT24gQXByIDE3LCAyMDE4LCBh dCAxMjoyNCwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KPiANCj4gICoq IE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6IFJGQyA3MTU5IChPYnNvbGV0ZWQgYnkgUkZD IDgyNTkpDQoNClRoYXQgYWxzbyBnaXZlcyByaXNlIHRvOg0KDQpNaW5vciB0ZWNobmljYWwgY29t bWVudDogMi4zIGNsYWltcyB0aGF0IEpTT04gY2FuIGJlIGluIGRpZmZlcmVudCBlbmNvZGluZ3Mu ICBUaGlzIGlzIG5vIGxvbmdlciByZWFsbHkgdGhlIGNhc2Ugd2l0aCBSRkMgODI1OSAoc2VlIFNl Y3Rpb24gOC4xKS4gIFBsZWFzZSBmaXggdGhlIHdvcmRpbmcgdG8gcmVtb3ZlIHRoZSB1bnRydWUg Y2xhaW0gKG5vIHB1biBpbnRlbmRlZCkuDQoNCk1ham9yIHRlY2huaWNhbCBjb21tZW50OiBTZWN0 aW9uIDMuOSByZWNvbW1lbmRzIHRoZSB1c2Ugb2YgbWVkaWEgdHlwZXMgb2YgdGhlIGZvcm0gYXBw bGljYXRpb24vZXhhbXBsZStqd3QuDQpJIGRvbuKAmXQgZmluZCBhIHJlZ2lzdHJhdGlvbiBmb3Ig dGhlIFJGQyA2ODM5IHN0cnVjdHVyZWQgc3ludGF4IHN1ZmZpeCAiK2p3dCIuICBJZiB0aGlzIHJl Y29tbWVuZGF0aW9uIGlzIGRlc2lyZWQsIHRoaXMgZG9jdW1lbnQgd2lsbCBuZWVkIHRvIHJlZ2lz dGVyIGl0IChwcmVmZXJyZWQpIG9yIHJlZmVyIHRvIGEgZG9jdW1lbnQgdGhhdCBkb2VzLg0KDQpO aXQ6IFNlY3Rpb24gMS4yIGNvdWxkIHVzZSB0aGUgbmV3ZXIgdGVtcGxhdGUgKGFzIHBlciBSRkMg ODE3NCkgaGVyZS4NCk5pdDogU2VjdGlvbiAzLjY6IHMvdXNlL3VzZSBvciBhZG1pdCB0aGUgdXNl IG9mLw0KTml0OiBTZWN0aW9uIDMuODogcy9ub3Qvbm90IHByZXNlbnQgb3Igbm90Lw0KDQpJIHRo aW5rIHRoZXNlIGFyZSBhbGwgc29sdmVkIGluIGFuIG9idmlvdXMgd2F5LCBhbmQgb25jZSBkb25l IEkgc3Ryb25nbHkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IHRvIGdvIGZvcndhcmQuDQoNCkdyw7zD n2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From nobody Tue May 8 13:12: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 2FEDF12EAB0 for ; Tue, 8 May 2018 13:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 ga9RNp_b91dn for ; Tue, 8 May 2018 13:12:42 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.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 12D5812E88A for ; Tue, 8 May 2018 13:12:41 -0700 (PDT) X-AuditID: 12074424-089ff70000006e8f-72-5af204b614de Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id BD.D8.28303.7B402FA5; Tue, 8 May 2018 16:12:40 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w48KCYsw030501; Tue, 8 May 2018 16:12:36 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w48KCWpa014657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2018 16:12:34 -0400 From: Justin Richer Message-Id: <77961237-AEE4-44CA-8D31-85E52980F399@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B9EF0357-6CB2-49FC-953F-BD7174D0DF87" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 8 May 2018 16:12:32 -0400 In-Reply-To: Cc: "" To: Brian Campbell References: <152572323194.1316.16504160657904107453@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6noruD5VOUwfQ9Qhar/99ktDj59hWb A5PHkiU/mTzuHr3IEsAUxWWTkpqTWZZapG+XwJVx4ekO1oKt1RU/OluYGxjfZ3YxcnJICJhI tN1sYuxi5OIQEljMJPHo32M2CGcDo8S062egnGtMEts+nmQEaWETUJWYvqaFCcTmFbCSeLKk mRXEZhZIkti77wMjRNxEYseVNnYQW1jAQWLegd1g9SwCKhLz/84Gi3MKBEp0L28CsjmAetUl 2k+6gIRFBPQlbj+dww6x9yKjRMONpcwQpypJ/N91hHkCI/8sJOtmIVkHEdeWWLbwNTOErSmx v3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6+VmluilppRuYgSHtovK DsbuHu9DjAIcjEo8vBI7P0YJsSaWFVfmHmKU5GBSEuX1+QAU4kvKT6nMSCzOiC8qzUktPsQo wcGsJMKrLAuU401JrKxKLcqHSUlzsCiJ8wpu/hAlJJCeWJKanZpakFoEk5Xh4FCS4H3J/ClK SLAoNT21Ii0zpwQhzcTBCTKcB2j4FZAa3uKCxNzizHSI/ClGe45D76f0MHOcA5PHLk8Dkv9u 7u9lFmLJy89LlRLndQRpEwBpyyjNg5sMSlvu6+wsXjGKAz0qzKsATGJCPMCUBzf7FdBaJqC1 gg/eg6wtSURISTUw6l7Y+923p6nRK3Jl4aOv/RfbrvyTn1XN5n3cMIhVfJHu2YzEuYkvGxcf aY0qO5S0rTU61nR3+m/hgI7FP9pXrkiZdfXVEhltff+IP5OC1itk3z/4RX5/bTzDhxv2ebsu r30kI7IyQiX49GXZ4Pwd0q8/eLcdjC6+JpIfmtbxsqB9lUeAW/NzJZbijERDLeai4kQANPiT rDYDAAA= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 20:12:45 -0000 --Apple-Mail=_B9EF0357-6CB2-49FC-953F-BD7174D0DF87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve reviewed the changes and it looks good to me. Thanks, = Brian! =E2=80=94 Justin > On May 7, 2018, at 4:16 PM, Brian Campbell = wrote: >=20 > has *been* published=20 >=20 > sigh=20 >=20 > On Mon, May 7, 2018 at 2:14 PM, Brian Campbell = > wrote: > A new draft of the OAuth 2.0 Mutual TLS Client Authentication and = Certificate Bound Access Tokens specification has published with changes = addressing review comments from Working Group Last Call. Thanks in = particular to Justin Richer and Neil Madden for the detailed reviews. A = summary of the changes (copied from the document history) is below. >=20 > draft-ietf-oauth-mtls-08 >=20 > o Incorporate clarifications and editorial improvements from = Justin > Richer's WGLC review > o Drop the use of the "sender constrained" terminology per WGLC > feedback from Neil Madden (including changing the metadata > parameters from mutual_tls_sender_constrained_access_tokens to > tls_client_certificate_bound_access_tokens) > o Add a new security considerations section on X.509 parsing and > validation per WGLC feedback from Neil Madden and Benjamin Kaduk > o Note that a server can terminate TLS at a load balancer, reverse > proxy, etc. but how the client certificate metadata is securely > communicated to the backend is out of scope per WGLC feedback > o Note that revocation checking is at the discretion of the AS per > WGLC feedback > o Editorial updates and clarifications > o Update draft-ietf-oauth-discovery reference to -10 and = draft-ietf- > oauth-token-binding to -06 > o Add folks involved in WGLC feedback to the acknowledgements list >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: > > Date: Mon, May 7, 2018 at 2:00 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt > To: i-d-announce@ietf..org > Cc: oauth@ietf.org >=20 >=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 Mutual TLS Client Authentication = and Certificate Bound Access Tokens > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-08.txt > Pages : 21 > Date : 2018-05-07 >=20 > Abstract: > This document describes OAuth client authentication and certificate > bound access tokens using mutual Transport Layer Security (TLS) > authentication with X.509 certificates. OAuth clients are provided = a > mechanism for authentication to the authorization sever using = mutual > TLS, based on either single certificates or public key = infrastructure > (PKI). OAuth authorization servers are provided a mechanism for > binding access tokens to a client's mutual TLS certificate, and = OAuth > protected resources are provided a method for ensuring that such an > access token presented to it was issued to the client presenting = the > token. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-08 = > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08 = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-08 = >=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 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B9EF0357-6CB2-49FC-953F-BD7174D0DF87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve reviewed the changes and it looks good to me. = Thanks, Brian!

 =E2=80=94 Justin

On May = 7, 2018, at 4:16 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

has *been* = published

sigh

On Mon, May 7, 2018 at 2:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:
A new draft of the OAuth 2.0 Mutual TLS Client Authentication = and Certificate Bound Access Tokens specification has=20 published with changes addressing review comments from Working Group=20 Last Call. Thanks in particular to Justin Richer and Neil Madden for the = detailed reviews. A summary of the changes (copied from the document = history) is below.

   = draft-ietf-oauth-mtls-08

   = o  Incorporate clarifications and editorial improvements from = Justin
      Richer's WGLC = review
   o  Drop the use of the "sender = constrained" terminology per WGLC
      feedback from Neil Madden = (including changing the metadata
      parameters from = mutual_tls_sender_constrained_access_tokens to
      = tls_client_certificate_bound_access_tokens)
   o  Add a new security considerations = section on X.509 parsing and
      = validation per WGLC feedback from Neil Madden and Benjamin Kaduk
   o  Note that a server can terminate TLS at = a load balancer, reverse
      = proxy, etc. but how the client certificate metadata is securely
      communicated to the backend is = out of scope per WGLC feedback
   o  Note = that revocation checking is at the discretion of the AS per
      WGLC feedback
   o  Editorial updates and clarifications
   o  Update draft-ietf-oauth-discovery = reference to -10 and draft-ietf-
      oauth-token-binding to -06
   o  Add folks involved in WGLC feedback to = the acknowledgements list



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 7, 2018 at 2:00 PM
Subject: = [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-08.txt
To: i-d-announce@ietf..org
Cc: oauth@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 Mutual TLS Client Authentication and Certificate Bound = Access Tokens
        Authors         : = Brian Campbell
                    =       John Bradley
                    =       Nat Sakimura
                    =       Torsten Lodderstedt
        Filename        : = draft-ietf-oauth-mtls-08.txt
        Pages          =  : 21
        Date          =   : 2018-05-07

Abstract:
   This document describes OAuth client authentication and = certificate
   bound access tokens using mutual Transport Layer Security = (TLS)
   authentication with X.509 certificates.  OAuth clients = are provided a
   mechanism for authentication to the authorization sever = using mutual
   TLS, based on either single certificates or public key = infrastructure
   (PKI).  OAuth authorization servers are provided a = mechanism for
   binding access tokens to a client's mutual TLS certificate, = and OAuth
   protected resources are provided a method for ensuring that = such an
   access token presented to it was issued to the client = presenting the
   token.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-08


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



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=_B9EF0357-6CB2-49FC-953F-BD7174D0DF87-- From nobody Wed May 9 17:02: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 377DF126C19 for ; Wed, 9 May 2018 17:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-0.01] 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 WYZgH06bX0f8 for ; Wed, 9 May 2018 17:02:33 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0129.outbound.protection.outlook.com [104.47.36.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 2E7B0124234 for ; Wed, 9 May 2018 17:02:33 -0700 (PDT) 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; bh=VqHVs0n+HcDArarLn7jmHkwxVcU7hf6H1Je3q7wSq/Q=; b=AfNgbOrAEq/K2JhGtForzFkRjswbt3dw5Q4TRatfUf8RFc2fVT7RkNpcbzqIzEYwAjEyDsY2Zj9FPWVBjQRmudtheD4RBkrLpDF2Z8Vpz4R316L1j7bVsPUcEXiNBKfNY9YkM0ZhypgdEwDFbj8cYAeq8QQ03+csWmFhGu0p6C4= Received: from SN6PR00MB0304.namprd00.prod.outlook.com (2603:10b6:805:b::30) by SN6PR00MB0366.namprd00.prod.outlook.com (2603:10b6:805:c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.793.0; Thu, 10 May 2018 00:02:31 +0000 Received: from SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::78c2:1262:2203:b29]) by SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::78c2:1262:2203:b29%4]) with mapi id 15.20.0796.000; Thu, 10 May 2018 00:02:31 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JWT BCP updates addressing WGLC feedback Thread-Index: AdPn8AGpcsWKiWuLTiCXCDaJYzjVyw== Date: Thu, 10 May 2018 00:02:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_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-05-10T00:02:29.4699672Z; 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:b::145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0366; 7:5C9BHEalPaZqsRe3SrrtAXapgeTWInwsx8oO+OfY0VYqMUY9gWrsRmN1DzNv8XCfk0Zar8083u8Ym5nzDME68EvP0uGj9DWrYwk5e5Azk21wLv4/x2axg82KTa6taIC/n+/aTZLUERpr09HH8aYEs4Bl4esXmQoXgpfSPCFYhMK4zAoTz+F54MHBhOmtCsRR6BxpAVEzSS6sCv822k+CxxpfR3ubcXj8VVKIZhIxvAJNcPapRTyCzOubzsPmCsb1; 20:vWPWq/q6R9Ly0MYEynft7/CnDIH6MX0d8J6NHvacha6+ThBtA8JNM2ssixs4jCO4pblkHmMnvTApsXp1GMHHmagZwrvsUbOfb0/kMWOx4dOb6+D3o2JSNs+0liH6NdEmf6cTjhxDJO7UpfkrA14EkaMjHEuAoip6kEJZEwx5bVM= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0366; x-ms-traffictypediagnostic: SN6PR00MB0366: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(31418570063057)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:SN6PR00MB0366; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0366; x-forefront-prvs: 066898046A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(366004)(39380400002)(346002)(376002)(39860400002)(209900001)(189003)(199004)(105586002)(1730700003)(86362001)(86612001)(14454004)(2351001)(486006)(5250100002)(476003)(97736004)(236005)(52396003)(22452003)(2501003)(53936002)(8676002)(68736007)(72206003)(5640700003)(6116002)(2906002)(46003)(81166006)(81156014)(10290500003)(790700001)(9686003)(5630700001)(7696005)(7736002)(99286004)(25786009)(21615005)(3280700002)(478600001)(316002)(59450400001)(5660300001)(3660700001)(186003)(6346003)(74316002)(53376002)(6506007)(966005)(6306002)(2900100001)(55016002)(8936002)(10090500001)(106356001)(102836004)(6916009)(2420400007)(33656002)(606006)(6436002)(54896002)(7110500001)(15650500001)(8990500004)(217873001)(6606295002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0366; H:SN6PR00MB0304.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: tcXDhoIDiec/Xv9HbrrodCMcGve5993XxQ2wibOgzPajlP8PIuxwu305/Jtyvv15KdU1oPpfJ853kFMA1krjmSn25SEaiBJ3cTE0VYCzWhhVlNhuEGQeAaklO7HfLafugVai0EM/URsjPUxU36FLCTPips7cXF5YFIaqlNIfT9sEv2B6s9Yn29zWYIQXRG8+ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR00MB03044DD73EAEF9BBDF7B2609F5980SN6PR00MB0304namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 50e2c5f3-cd25-46c3-35b7-08d5b6095392 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50e2c5f3-cd25-46c3-35b7-08d5b6095392 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 00:02:31.4654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0366 Archived-At: Subject: [OAUTH-WG] JWT BCP updates addressing WGLC feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 00:02:35 -0000 --_000_SN6PR00MB03044DD73EAEF9BBDF7B2609F5980SN6PR00MB0304namp_ 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 Working Group Last Call (WGLC) feedback received. = Thanks to Neil Madden for his numerous comments and to Carsten Bormann and= Brian Campbell for their reviews. Assuming the chairs concur, the next step should be to request publication. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-jwt-bcp-03.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1847 and a= s @selfissued. --_000_SN6PR00MB03044DD73EAEF9BBDF7B2609F5980SN6PR00MB0304namp_ 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 Working Group Last Call (WG= LC) feedback received.  Thanks to Neil Madden for his numerous comment= s and to Carsten Bormann and Brian Campbell for their reviews.

 

Assuming the chairs concur, the next step should be = to request publication.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

P.S. This notice was also posted at http://self-issued.info/?p=3D1847 and as @selfissued.

 

--_000_SN6PR00MB03044DD73EAEF9BBDF7B2609F5980SN6PR00MB0304namp_-- From nobody Sat May 12 15:21: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 5341F1270AC for ; Sat, 12 May 2018 15:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 Z89lEgj6uT1i for ; Sat, 12 May 2018 15:21:03 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB9E126CC7 for ; Sat, 12 May 2018 15:21:02 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id a20-v6so349124pfo.0 for ; Sat, 12 May 2018 15:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=+QVgnz8NR8Vz+GpmzciGealsZEnqZZIJEXmcbfI4trE=; b=NAedS4pgBWMzJ+QuZlv1nqBtUaeFLI7fyG/CtPvNFBoHC5/T1QngEe2/arLxPz5+bn F5Lvs+lE4kZBdfXlnyf/D0NABWTaVTHNbcdJB7aNjC/U26SeynYx13sC7aVXGS4Fd2UN wRMDpXX0tgN3xalNJrA9gX7xlDA5A6862hEFhJk1u/NfgIFUvQFqq8L0FOhfefcU//hA 2GlH6eJX43WqTfKiL83sc60OCNUMSYvBbdRq7BMcZk4VJdGsu07yAYPU2a6Eyc/HNdkN MWwabuYEw0cjkkErprUnhBdbJNWEy4frLB77HMLoVpVQkzUULsPkiauac3okebMlb88S hjkQ== 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=+QVgnz8NR8Vz+GpmzciGealsZEnqZZIJEXmcbfI4trE=; b=PyPZZE0giMe2yEQAF12wvLF1CTpnU+HVoGzxbquybEDVTgUnYpWIbzQSQ9eb1u1DOH IuIK/yAxh5g7xMF3VDmZRev5fxRca2vEt6cneI2yfwpwRrTklAMxqrM/OUSY4aQ/OzNC p99MZlPWD7Ahlv+0mRIHi56j7Vk5iZxXhrQsec0gXux/Ab2XVc4QSoyiJDg+jV47aEOg xG18lECQMA1JtYp58P3/9Fxwcd6rNVwX8PJI3eUy0ZkO37qGCgiAGA/8b2BFo/AdeoY4 7JwqgGbqHbTPnrVUPlwZLLAU/mFA6bsYdYKEDgTKfF1/kRfx5OTMMSa3VWDfS4L5sQrj pgvA== X-Gm-Message-State: ALKqPwd/j1PXMA3gIznvDXZZPUA8cDsTZE5yadbP25zj1Xs6opfbyco+ b7bQsPU75X4dTGgEWBSeTemJ10IW3VWDU0HSyveyAg== X-Google-Smtp-Source: AB8JxZqKhpBi/ECyvugvGAbiRFIdsxnf8Fbv8in08H82OUYigdqH8wjy8Z1Co1me8I7jOzF/y/49ZiN6Fc+WaoCuIws= X-Received: by 2002:a62:20c7:: with SMTP id m68-v6mr4423602pfj.110.1526163662333; Sat, 12 May 2018 15:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:5d05:0:0:0:0 with HTTP; Sat, 12 May 2018 15:21:01 -0700 (PDT) From: Samuel Erdtman Date: Sun, 13 May 2018 00:21:01 +0200 Message-ID: To: Brian Campbell Cc: "" Content-Type: multipart/alternative; boundary="000000000000f67c07056c09aaa7" Archived-At: Subject: [OAUTH-WG] review of draft-ietf-oauth-mtls-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 22:21:05 -0000 --000000000000f67c07056c09aaa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thanks for a great document. I have some minor comments. in Abstract =E2=80=9C...based on either single certificates...=E2=80=9D Why not write self-signed certificates, to me that is easier to understand, and is the term that is used later in the document. What is the rational behind writing =E2=80=9COAuth protected resources=E2= =80=9D or just =E2=80=9Ca protected resource=E2=80=9D instead of resource server? The term resource s= erver is user later in the document. 4.1. Authorization Server Is it not mandatory for the AS to not do PKI validation of self signed certificates i.e. the following sentence, =E2=80=9Cit should configure the = TLS stack in a way=E2=80=9D, should be changed to =E2=80=9Cit must configure th= e TLS stack in a way=E2=80=9D? Finally it might make sense to mention the relation of this document to RFC7521, RFC7522 and RFC7523. RFC7521 defines a client credentials framework and the other two are examples of profiles. It also mentions proof-of-possession. Maybe as an appendix similar to "Relationship to Token Binding" Best regards //Samuel --000000000000f67c07056c09aaa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

Thanks for a great doc= ument. I have some minor comments.

in Abstract
=E2=80=9C...based = on either single certificates...=E2=80=9D
Why not write self-signed cert= ificates, to me that is easier to understand, and is the term that is used = later in the document.

What is the rational behind writing =E2=80=9C= OAuth protected resources=E2=80=9D or just =E2=80=9Ca protected resource=E2= =80=9D instead of resource server? The term resource server is user later i= n the document.

4.1.=C2=A0 Authorization Server
Is it not mandato= ry for the AS to not do PKI validation of self signed certificates i.e. the= following sentence, =E2=80=9Cit should configure the TLS stack in a way=E2= =80=9D, should be changed to =E2=80=9Cit must configure the TLS stack in a = way=E2=80=9D?

Finally it might make sense to mention the relat= ion of this document to RFC7521, RFC7522 and RFC7523. RFC7521 defines a cli= ent credentials framework and the other two are examples of profiles. It al= so mentions proof-of-possession. Maybe as an appendix similar to "Rela= tionship to Token Binding"

Best regards
//Samuel=

--000000000000f67c07056c09aaa7-- From nobody Mon May 14 05:46: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 24919124239 for ; Mon, 14 May 2018 05:46:58 -0700 (PDT) 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, FREEMAIL_FROM=0.001, 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 b6EKSVjfXYwP for ; Mon, 14 May 2018 05:46:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0207512DB6B for ; Mon, 14 May 2018 05:46:55 -0700 (PDT) Received: from [141.58.59.198] ([141.58.59.198]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M96Jd-1f84O13vQL-00CVGQ for ; Mon, 14 May 2018 14:46:53 +0200 To: oauth@ietf.org From: pedram.h@gmx.de Message-ID: Date: Mon, 14 May 2018 14:46:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7501F0E4A4881930DD4FDF5F" Content-Language: en-US X-Provags-ID: V03:K1:UYQhQo6v7byUrKT5yRFWjzlc6LTL5oRQT7osicQ77wUipGdz7th Qsf/WCqA7evzlr/gOCam/49K7g+X7rz/zbFUhOFT2rvxevYaqFMKhzSJy3lPaNhnCYW2EIe T/evBtZCYj26k7GoCBjMrQJrp8Y75TsGqPkMuZyfW9dnksUMr1RwAB20wZdegE4kNElcZSJ Vjdhuagc6VEgeCiWTE+6g== X-UI-Out-Filterresults: notjunk:1;V01:K0:7WGvYPt9X/U=:wRVA6yxxiePtnow4OwzfT2 jYbuDqBtyytnJuk48+D0f5TxKeG9KtkK6KQxx6Ap4l3yCQS+rSF7Pg74NDrxsQZZnzE0c1o0p J3CnAR6qWUxvZKtYpHPQVOX0hTU2sU5EvQkXlJ5LvJN5dfvPBQF/JEq7sx1zKCaVlHNE9iz7G aWuLru+4Z7u6eYxFE8pd3QZIbspuPIcWhpx34s/gmvsPUqYAXjb/DFUhD5gx2X7z6F8hrxS9n l0nzFzxkjUbl+/+j4kgCqwLrG1f8zSXTTuGyHKCD+39z+toZ8a6D2iZZZOm/uDVJ5RkK1laS/ fYVtXoE8RyFWDQiSIHu92/aFNO6Ry1pXswOd+BNh1BPVgKvaDP+nqy8XoABvlCPH4mhWpMX2M 6QOZKksZ4YC2NHkAvs4Awarmp9aGyM8lz6DKpABugCSFRne/tE0mT/2BLGBQaYBXoQOhkjUhc u/Qf+YSNPe/HIVKoILvojpNWXo9HxiACcyLC7vh1KAgYiH5DZOVa5ADpqpo8ABey2TnvDEE9c 9Kx728Kdsbvb7dHWbkJ020JUQDKd6CjUaW9DR9btb7wjX9AA6UKqCBDXN4nJhp12oiYpIfyPM K8kM7QBrubH83xuLGYaFYj1LrC5VX6SOTP1pILNBR+fN+9ROajn5OsnrkExfdCPJBak8/bqqQ H7oFmRRSguXD6W0T696yNLUeBPrMNQASPeuQf7MGkDXXJZRK8l37iLPBG9EprDYHM4bNvv65G +Vf/15TgO4kOH95Jrl2lgBX2atqeoYvCFLEeg3gWqMD1g++XGP4FYl31cb1pjW3xTBttFJ2Zw UFjk36M Archived-At: Subject: [OAUTH-WG] OAUTB for Access Token in Implicit Grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 12:46:58 -0000 This is a multi-part message in MIME format. --------------7501F0E4A4881930DD4FDF5F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, We are currently modeling part 1 and part 2 of the OpenID Financial API in the FKS Web Model and have a few questions regarding the OAuth 2.0 Token Binding. In section 3.1. of draft-ietf-oauth-token-binding-06, it is not very clear how an Access Token issued from the Authorization Endpoint is Token Bound. Is this intended to be the same as an AC issued for a web server client? It seems that the user-agent sends both the Provided and Referred Token Bindings to the AS, which means that the AS can bind the Access Token to the Referred Token Binding, which is the Token Binding between the user-agent and the client. However, the Access Token is not used by the user-agent, which means that the client can only send the Token Binding ID used by the user-agent (which essentially is the public key) to the Resource Server. Is this the intended flow of the Token Binding? Because the first paragraph of 3.1 says that the "Token Binding ID of the client's TLS channel to the protected resource is sent with the authorization request as the Referred Token Binding ID", but we assume that the user-agent reveals the TB-ID of its own channel to the client. Best regards, Pedram Hosseyni --------------7501F0E4A4881930DD4FDF5F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,
 
We are currently modeling part 1 and part 2 of the OpenID Financial API in the FKS Web Model and have a few questions regarding the OAuth 2.0 Token Binding.
 
In section 3.1. of draft-ietf-oauth-token-binding-06, it is not very clear how an Access Token issued from the Authorization Endpoint is Token Bound. Is this intended to be the same as an AC issued for a web server client? It seems that the user-agent sends both the Provided and Referred Token Bindings to the AS, which means that the AS can bind the Access Token to the Referred Token Binding, which is the Token Binding between the user-agent and the client.
However, the Access Token is not used by the user-agent, which means that the client can only send the Token Binding ID used by the user-agent (which essentially is the public key) to the Resource Server.
 
Is this the intended flow of the Token Binding? Because the first paragraph of 3.1 says that the "Token Binding ID of the client's TLS channel to the protected resource is sent with the authorization request as the Referred Token Binding ID", but we assume that the user-agent reveals the TB-ID of its own channel to the client.
 
Best regards,
Pedram Hosseyni
--------------7501F0E4A4881930DD4FDF5F-- From nobody Mon May 14 14:45: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 ED7FA12E8CE for ; Mon, 14 May 2018 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 qFeZX2xM425M for ; Mon, 14 May 2018 14:44:57 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 597F612D969 for ; Mon, 14 May 2018 14:44:57 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e20-v6so14886858itc.1 for ; Mon, 14 May 2018 14:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+2bS32jRQHXreV+NcyPtac02NHtB+XbAaWCZV4A6W6I=; b=gu/WIKOMLWoLGM05l0i/5kaKZ9rr0XIxtn5kErQFU+V+uSiDIJ/fZOdqO8B/3BqIrA NnZH4Jv0X6lk3PcVwhWU5Hyq5dV5O9F9cUBhN/jYcaDyOscy3B3OBRNBydhiyPerWxQo g504vYaLHcabEDrtUXGG+HCbKjEKKwIam5ccs= 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=+2bS32jRQHXreV+NcyPtac02NHtB+XbAaWCZV4A6W6I=; b=pTbsVM++N2Q9jMAnJnR5e98rwXbZ5S64YPNzoA9l3ig45nVomH22vbGishGm5zhYE1 KZQdAb4ZSyjevOmmo/84A1zRc8EILbhxW2NDJfV0OYaAIn0A9BSPzBIh5z5AX87ToRFr uAyaeVJ0VaCV5bGJXI/uALSxQpasPuGVBdGbi2lpBtzU+l5QbtY0ylWnR8CwopIOijSW GzS+ET3Q4vFG5vwjo3TsDwHYH6CzR+J1iGTHYJ7QQjENcW5kPtIz49hizuJmDFsEIW0K N+AxyuO7VS/dLloCZvUVeYCdNag1Qx1tERDWFrleYx3KPQkrURS5DlY+fJ0Ll09MYvmX 79OQ== X-Gm-Message-State: ALKqPwdYP4fkk5tJDpz6bntd8s5C5klIOhntSs33K5sgUUmW2p85SXup Wjm4WXulDohbkF8H/BlRm7zZRe/5uwGNK8emUxcpjOyYGui3PWLF8ELgpQ2XqVtfIYu3blmqbl4 xxFFfdzF3oBJJAg3e X-Google-Smtp-Source: AB8JxZovqKuwm5xFWKK0/y7J08JSeaQRg1ipOl6GUTTlNxBK+ovJpuZu1GO0LvunhUQi12SUYlBnfJhW+6RdExjHsnI= X-Received: by 2002:a6b:8361:: with SMTP id f94-v6mr11764429iod.17.1526334296427; Mon, 14 May 2018 14:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 14 May 2018 14:44:25 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 14 May 2018 15:44:25 -0600 Message-ID: To: Samuel Erdtman Cc: "" Content-Type: multipart/alternative; boundary="0000000000008c2c40056c3165ad" Archived-At: Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-mtls-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 21:45:00 -0000 --0000000000008c2c40056c3165ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Samuel (even though this doc already went through WGLC!). I'll attempt to address your comments/questions inline below. On Sat, May 12, 2018 at 4:21 PM, Samuel Erdtman wrote: > Hi > > Thanks for a great document. > And thank you too! I have some minor comments. > > in Abstract > =E2=80=9C...based on either single certificates...=E2=80=9D > Why not write self-signed certificates, to me that is easier to > understand, and is the term that is used later in the document. > The reason why is that it was the term that Justin used in text he proposed for the Abstract that was overall and otherwise much better than the text I'd previously had. But I agree that "self-signed certificates" there would be easier to understand and more inline with the content of the document. I'll make that change in the document source so it'll be in the next draft. > What is the rational behind writing =E2=80=9COAuth protected resources=E2= =80=9D or just =E2=80=9Ca > protected resource=E2=80=9D instead of resource server? The term resource= server is > user later in the document. > At some point many people and documents in this WG started using the protected resource terminology rather than resource server. I don't recall the reason why. Maybe someone on the list here can chime in? As far as I know, they are largely interchangeable. I wrote much of the initial text of this doc using protected resource to try be like the rest of the group. I think Torsten added some text a bit later using resource server. That's the extent of the rational. But I think it's probably okay with both. > > 4.1. Authorization Server > Is it not mandatory for the AS to not do PKI validation of self signed > certificates i.e. the following sentence, =E2=80=9Cit should configure th= e TLS > stack in a way=E2=80=9D, should be changed to =E2=80=9Cit must configure = the TLS stack in a > way=E2=80=9D? > There are different ways one could implement it and this text shouldn't be overly prescriptive. As one example, the TLS layer might do regular PKI validation except for on a specific set of self-signed certificates certs configured for clients using that authn method. > > Finally it might make sense to mention the relation of this document to > RFC7521, RFC7522 and RFC7523. RFC7521 defines a client credentials > framework and the other two are examples of profiles. It also mentions > proof-of-possession. Maybe as an appendix similar to "Relationship to Tok= en > Binding" > RFC7521 defines a framework for using assertions as a client authentication mechanism via the client_assertion_type and client_assertion parameters, which this doc doesn't use. But RFC7521 is not a general client credentials framework. So there's really not much of a relationship to this document. And I wouldn't know what to say in a ""Relationship to ..." section other than that there's not much of a relationship. --=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._ --0000000000008c2c40056c3165ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Samuel (even though this doc already went thro= ugh WGLC!). I'll attempt to address your comments/questions inline belo= w.=C2=A0

On Sat, May 12, 2018 at 4:21 PM, Samuel Erdtman <samuel@erdtman.se&= gt; wrote:
Hi

Thanks for a great documen= t.

And thank you to= o!
=C2=A0

I have some minor comme= nts.

in Abstract
=E2=80=9C...based on either single certificates.= ..=E2=80=9D
Why not write self-signed certificates, to me that is easier= to understand, and is the term that is used later in the document.

The reason why is that= it was the term that Justin used in text he proposed for the Abstract that= was overall and otherwise much better than the text I'd previously had= .

But I agree that "self-signed certific= ates" there would be easier to understand and more inline with the con= tent of the document. I'll make that change in the document source so i= t'll be in the next draft.



What is the rational behind writing =E2=80=9COAuth protected resourc= es=E2=80=9D or just =E2=80=9Ca protected resource=E2=80=9D instead of resou= rce server? The term resource server is user later in the document.

At some point many peo= ple and documents in this WG started using the protected resource terminolo= gy rather than resource server. I don't recall the reason why. Maybe so= meone on the list here can chime in? As far as I know, they are largely int= erchangeable. I wrote much of the initial text of this doc using protected = resource to try be like the rest of the group. I think Torsten added some t= ext a bit later using resource server. That's the extent of the=C2=A0ra= tional. But I think it's probably okay with both.

=C2=A0

4.1.=C2=A0 Authorization Server
Is it not= mandatory for the AS to not do PKI validation of self signed certificates = i.e. the following sentence, =E2=80=9Cit should configure the TLS stack in = a way=E2=80=9D, should be changed to =E2=80=9Cit must configure the TLS sta= ck in a way=E2=80=9D?

There are different ways one could implement it and this text should= n't be overly prescriptive. As one example, the TLS layer might do regu= lar PKI validation except for on a specific set of self-signed=C2=A0certifi= cates certs configured for=C2=A0 clients using that authn method.

=C2=A0

Finally it might make sen= se to mention the relation of this document to RFC7521, RFC7522 and RFC7523= . RFC7521 defines a client credentials framework and the other two are exam= ples of profiles. It also mentions proof-of-possession. Maybe as an appendi= x similar to "Relationship to Token Binding"

RFC7521 defines a framework for using ass= ertions as a client authentication mechanism via the client_assertion_type = and client_assertion parameters, which this doc doesn't use. But RFC752= 1 is not a general client credentials framework. So there's really not = much of a relationship to this document. And I wouldn't know what to sa= y in a ""Relationship to ..." section other than that there&= #39;s not much of a relationship.

=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. --0000000000008c2c40056c3165ad-- From nobody Mon May 14 15:23: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 C87BE12E8D9 for ; Mon, 14 May 2018 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 ba5rgffaZBQL for ; Mon, 14 May 2018 15:23:26 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 4C29112E8D8 for ; Mon, 14 May 2018 15:23:26 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id q72-v6so15142577itc.0 for ; Mon, 14 May 2018 15:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zmzeeYFy2Ow0rs/R9vpqNZTPhXDfwEHSZwvm0EVAY8A=; b=jWRiM02wif/CDGBJ59T/PC2wLtQ/IX574TSQRK/CzPGXpkrAMEdELqv33NXsgkhelY D3Edmci9gE2NhOj+CpBpa3gd3rt+WBugXPoEXAdTru17Exl+bnbf8kpZ3y6Q/XMb6nS9 vncFMbY2vluksQiFU/Yu1dxzYGylNmycKbb6Y= 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=zmzeeYFy2Ow0rs/R9vpqNZTPhXDfwEHSZwvm0EVAY8A=; b=adspO1xwGmlAk/ntQdjuGpWrcaxqQ/szn+eh2yYRbOq6VAwuJafdBYpOCJ/+HANBSB TySo+6TM0kMjZ3BCBed1+SILvFcG3iPor8h+a8OP8GxTiCLA3jFhjtJZTm6NOayQd4G6 I2OOUSSvaAg94y78X07zuHIQ4mYVDTWmi1SJ4vWFdUWVHkyUhX1djShNp4jVzgoiDqP4 xC6jxzsqGaNhUkOL0UVMP1SiGEjzSZ099KIxj9wX0wTx5SQyJawMm976oHqx8torKuH1 6W3DwePpdE3ZlxzkDNGmXyWmevoeDgHHU8vHhPiaWRH5fmdx5wuL1YqSQ1TkvAFyhw0X iT7w== X-Gm-Message-State: ALKqPwcBsaiDiVwz2SR2vIYRwdKgSCN43RKFa9jU3JD7WDHsGoD/P4uN +2JBigRhxEnDCWNeMQcLF9H3FpKqCONK98kROPAOlRnkPcxPAoYyiIcdvCF/UEZ5okpqC80Yoqq 1zCiWUx7owywnEw== X-Google-Smtp-Source: AB8JxZpXvw7gMOib3EBo5wmg3xuvVAXFk1Hr3u66ifC4PnpZOZdTkkBVXPqK0PUh5w4SQi+mdxMX3Ud/MgWpzde1dvs= X-Received: by 2002:a6b:8361:: with SMTP id f94-v6mr11863385iod.17.1526336605400; Mon, 14 May 2018 15:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 14 May 2018 15:22:54 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 14 May 2018 16:22:54 -0600 Message-ID: To: pedram.h@gmx.de Cc: oauth Content-Type: multipart/alternative; boundary="0000000000002c45ee056c31ef0e" Archived-At: Subject: Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 22:23:29 -0000 --0000000000002c45ee056c31ef0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Typically when an access token is issued via the implicit grant directly from the authorization endpoint, it is for a client that is running as script in the user-agent. The AS binds the access token to the referred token binding, which would be the token binding between the user-agent (where the client is) and the protected resource. It does mean that a hybrid style client couldn't pass the access token from its script front-end in the user-agent to its server backed (well, it could pass it but the server side couldn't use it because of the binding). On Mon, May 14, 2018 at 6:46 AM, wrote: > Dear all, > > We are currently modeling part 1 and part 2 of the OpenID Financial API i= n > the FKS Web Model and have a few questions regarding the OAuth 2.0 Token > Binding. > > In section 3.1. of draft-ietf-oauth-token-binding-06, it is not very > clear how an Access Token issued from the Authorization Endpoint is Token > Bound. Is this intended to be the same as an AC issued for a web server > client? It seems that the user-agent sends both the Provided and Referred > Token Bindings to the AS, which means that the AS can bind the Access Tok= en > to the Referred Token Binding, which is the Token Binding between the > user-agent and the client. > However, the Access Token is not used by the user-agent, which means that > the client can only send the Token Binding ID used by the user-agent (whi= ch > essentially is the public key) to the Resource Server. > > Is this the intended flow of the Token Binding? Because the first > paragraph of 3.1 says that the "Token Binding ID of the client's TLS > channel to the protected resource is sent with the authorization request = as > the Referred Token Binding ID", but we assume that the user-agent reveals > the TB-ID of its own channel to the client. > > Best regards, > Pedram Hosseyni > > _______________________________________________ > 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._ --0000000000002c45ee056c31ef0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Typically when an access token is issued via the impl= icit grant directly from the authorization endpoint, it is for a client tha= t is running as script in the user-agent. The AS binds the access token to = the referred token binding, which would be the token binding between the us= er-agent (where the client is) and the protected resource.
<= br>
It does mean that a hybrid style client couldn't pass the= access token from its script front-end in the user-agent to its server bac= ked (well, it could pass it but the=C2=A0server side couldn't use it be= cause of the binding).

On Mon, May 14, 2018 at 6:46 AM, &= lt;pedram.h@gmx.de= > wrote:
=20 =20 =20
Dear all,
=C2=A0
We are currently modeling part 1 and part 2 of the OpenID Financial API in the FKS Web Model and have a few questions regarding the OAuth 2.0 Token Binding.
=C2=A0
In section 3.1. of draft-ietf-oauth-token-binding-06, it = is not very clear how an Access Token issued from the Authorization Endpoint is Token Bound. Is this intended to be the same as an AC issued for a web server client? It seems that the user-agent sends both the Provided and Referred Token Bindings to the AS, which means that the AS can bind the Access Token to the Referred Token Binding, which is the Token Binding between the user-agent and the client.
However, the Access Token is not used by the user-agent, which means that the client can only send the Token Binding ID used by the user-agent (which essentially is the public key) to the Resource Server.
=C2=A0
Is this the intended flow of the Token Binding? Because the first paragraph of 3.1 says that the "Token Binding ID of th= e client's TLS channel to the protected resource is sent with the authorization request as the Referred Token Binding ID", but we assume that the user-agent reveals the TB-ID of its own channel to the client.
=C2=A0
Best regards,
Pedram Hosseyni

_______________________________________________
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. --0000000000002c45ee056c31ef0e-- From nobody Wed May 16 10:39: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 747C61201F2 for ; Wed, 16 May 2018 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 mf8bAn03429G for ; Wed, 16 May 2018 10:39:11 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00079.outbound.protection.outlook.com [40.107.0.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979A912DA06 for ; Wed, 16 May 2018 10:39:02 -0700 (PDT) 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=/q8Doz420A0ZThw7squdd2wZA2Dr8iC7CtYTEwAkXIw=; b=aq+tv7CeUFxnBmIQ2U/0zrX/anUNPEL9thbGMSVzwLQBXS9wJkt1tQP4S/bApH7IHgbyIqvvxWmTntvBHWFgMPJuR/1KO6PBpWado5j7WjKUi/MeHDa0DkUGX8oigdEFgsMC0ixN2WdXy3zMULAVEv3f6ZneEWIeDnVPf4Yj6hc= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1840.eurprd08.prod.outlook.com (10.168.68.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Wed, 16 May 2018 17:39:00 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Wed, 16 May 2018 17:39:00 +0000 From: Hannes Tschofenig To: "" Thread-Topic: Meeting Invite for the OAuth WG Virtual Office Hours Thread-Index: AdPtPHCaHL5IGsSwSyidRnL+pJRcMA== Date: Wed, 16 May 2018 17:38:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1840; 7:fPWsP2aZ1Sqfe7LBnMEp2SXna7hMQey07g3HB6+JEdimh7zl9cCfuOGYhQQjV+UMgQ8UQCp7hCnbFaGJWFqxrJckq8oX5hHczHG1btfqSlMvJR/YzoxU8swaW3K/gmPNuwJnE7b6gh0Ll/wgge6jiSYr42nxbAKjlUYVQ6sGd1eyx2YL60hta8nPTgFhlpGHzthhUYVYSLU4phQ+aND+0CKv4TRkJ7BDvMgcp+9J7vYHjaJzyuz2U7DzuWZ+IEH1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0801MB1840; x-ms-traffictypediagnostic: VI1PR0801MB1840: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1840; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1840; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(39380400002)(376002)(346002)(40434004)(53754006)(189003)(199004)(5250100002)(5890100001)(316002)(6306002)(54896002)(9686003)(4326008)(2900100001)(55016002)(106356001)(53936002)(5660300001)(105586002)(86362001)(6506007)(102836004)(8676002)(26005)(99936001)(81166006)(8936002)(81156014)(68736007)(74316002)(7736002)(186003)(59450400001)(66066001)(3280700002)(3660700001)(2906002)(97736004)(33656002)(25786009)(99286004)(39060400002)(14454004)(72206003)(478600001)(476003)(6436002)(3846002)(790700001)(486006)(7696005)(6116002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1840; 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: 9Hq/kBP+BAe5e7lg+e7dmYPL9xX7uQ6Y5x5HmqUo/JXHlOySNPR8ztUBo8XsjYxoAJIgRY413WkyxnQ0SFrBs+NFfnW/cLInn+xz6+SQgELWbtg3Rmw2aE82mFIwEbMo3+LTiHF05sZI6/s1m7QawQKilwyZwjlEof4c03zQ+LCkgFKM1tuwkmh8eEwl7wr3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1f412d5a-f021-4df3-59eb-08d5bb53e889 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f412d5a-f021-4df3-59eb-08d5bb53e889 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 17:38:59.9850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1840 Archived-At: Subject: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 17:39:14 -0000 --_004_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_ Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_" --_000_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Rifaat and I will again dial into the Webex next Monday to hear whether som= eone of you has anything to discuss/report/suggest/.... 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_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Rifaat and I will again dial into the Webex next Mon= day to hear whether someone of you has anything to discuss/report/suggest/&= #8230;.

 

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_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_-- --_004_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_ Content-Type: text/calendar; name="OAuthWG_Virtual_Office_Hours.ics" Content-Description: OAuthWG_Virtual_Office_Hours.ics Content-Disposition: attachment; filename="OAuthWG_Virtual_Office_Hours.ics"; size=3280; creation-date="Wed, 16 May 2018 17:33:46 GMT"; modification-date="Wed, 16 May 2018 17:34:57 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTYxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE2MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApDTEFTUzpQVUJMSUMKREVTQ1JJUFRJT046 XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bWM1NzdjZWNjYjNjNWQzY2RkYTUyNGU3NjllYzFmY2NjXG5NZWV0aW5nIG51bWJlciAo YWNjZXNzIGNvZGUpOiAzMTkgNzg5IDY5NFxuTWVldGluZyBwYXNzd29yZDogbjJYdVk0elhcblxu XG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSlcblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBo ZXJlOlxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElD RTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBv dGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwg d2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gWW91IHNob3VsZCBp bmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9yIHRvIHJlY29yZGluZyBpZiB5b3UgaW50 ZW5kIHRvIHJlY29yZCB0aGUgbWVldGluZy5cbgpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9odG1s Ogk8Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwi PgkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWM1Nzdj ZWNjYjNjNWQzY2RkYTUyNGU3NjllYzFmY2NjIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzAwQUZG OSIgRkFDRT0iQXJpYWwiPkpvaW4gV2ViRXggbWVldGluZzwvRk9OVD48L2E+CQkJPHRhYmxlPgkJ CQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAzMTkgNzg5IDY5NDwvRk9OVD4J CQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4J CQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjwvRk9OVD4J CQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05U PjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPm4y WHVZNHpYPC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPgkJPC9GT05UPjxicj48Rk9OVCBzaXplPSIy IiBDT0xPUj0iI0ZGMDAwMCI+PC9GT05UPjxicj48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+ Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxG T05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwv Rk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJS Pgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBq b2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250 YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0i I0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBu b3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3Jt YXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBi ZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBt ZWV0aW5nIGF0dGVuZGVlcyBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNv cmQgdGhlIG1lZXRpbmcuPC9GT05UPjwvRk9OVD4KQVRURU5ERUU7Q049IldlYiBBdXRob3JpemF0 aW9uIFByb3RvY29sIFdvcmtpbmcgR3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJV RTpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnCkRUU1RBTVA6MjAxODA1MjFUMTUzMDAwWgpV SUQ6Y2ZlMThlZTEtNmU2MC00NmMxLWE4ODgtZjAxMTFmZTE1Yjk1ClBSSU9SSVRZOjUKRFRTVEFS VDtUWklEPSJFdXJvcGUgVGltZSI6MjAxODA1MjFUMTczMDAwCkRURU5EO1RaSUQ9IkV1cm9wZSBU aW1lIjoyMDE4MDUyMVQxODMwMDAKUlJVTEU6RlJFUT1XRUVLTFk7SU5URVJWQUw9MjtCWURBWT1N TwpTRVFVRU5DRToxNTI2NDkyMDQ5ClNVTU1BUlk6T0F1dGggV0cgVmlydHVhbCBPZmZpY2UgSG91 cnMKVFJBTlNQOk9QQVFVRQpPUkdBTklaRVI7Q049IndlYmV4IjpNQUlMVE86bWVzc2VuZ2VyQHdl YmV4LmNvbQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYKQkVHSU46VkFMQVJN ClRSSUdHRVI6LVBUMTVNCkFDVElPTjpESVNQTEFZCkRFU0NSSVBUSU9OOlJlbWluZGVyCkVORDpW QUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== --_004_VI1PR0801MB2112B8DD11B66E31517FEDA2FA920VI1PR0801MB2112_-- From nobody Wed May 16 15: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 5280212DA40 for ; Wed, 16 May 2018 15:11:48 -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 mTqN3YWaJjJ2 for ; Wed, 16 May 2018 15:11:45 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935BD126D05 for ; Wed, 16 May 2018 15:11:44 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id z6-v6so5982921iti.4 for ; Wed, 16 May 2018 15:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yxJLkbey7H4LM8Jdgmj6Wj6G9ZFCuwmg2WU8TFM8/D0=; b=HdonXuxYUO7+8BQ1ZciGIGgT2n1+N4GinkjO7d1EyVOFRXiKvJHSz2X7AgXMDZex6m suDPp803bE586PaKbTN2wPyCWeL2vA82LUXEcduKCJdm5oi/Dbus3PwgUpDqIdv4QkCF Jb0fnuuKNL1mYeRYGQKnXGwapX//CsHI7Zyx4= 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=yxJLkbey7H4LM8Jdgmj6Wj6G9ZFCuwmg2WU8TFM8/D0=; b=ssOfrtpOxfdDvCheXEszaVFDUzC7K3V2nRUCdjjqTjPTPFZwld4c9dRx7mXyALEcCm EEwVnmjSm1beIQ0cy9hQqio7elwoQIZf8u2S5aIum0/I9+CHeZkr8JsOL4xykwDefNd3 jLzbTFQZVlNcP2QMEwONBHHbIsNqhfQqQtL40MwODg77DwzWOJnWkz7Tul+mDGUu9yL1 6noB7WdL2r3Sgy+aFXjQG1vreZZurIe3ZErWtv6xAAn5ufxGGz/I+NeuOKie4fBNa/VT 0HSAlQns7vkQDPV3ilPof6ouy3EKTT7LC/mntuWyyge0P0f8fHztLz3Wlw3jFFRWyeX3 APMg== X-Gm-Message-State: ALKqPwcR7PsUYYN1uiPT7ao1IKdGbo5qbuf0QpEXMBzA7aNM7+7akt72 Z55kwpZ08IiCCFD7Kno6kV/r7G1Iichvq9Ebri4AcI9u5BW2IcusGM4u0s/0nBYdrHjGa6Napzv os5yCzJxuvG+TEA== X-Google-Smtp-Source: AB8JxZrZI1rJ9GUQOzthpKXCtIDzRgTYDUMUY2zGVhnuKlxJAZyD4dk0L+9ip9Sl9l9rK2InBOOmkxmvKcaIbctNhgA= X-Received: by 2002:a24:1f4a:: with SMTP id d71-v6mr153034itd.53.1526508703678; Wed, 16 May 2018 15:11:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 16 May 2018 15:11:13 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 16 May 2018 16:11:13 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary="000000000000079a12056c5a0170" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 22:11:48 -0000 --000000000000079a12056c5a0170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, it's already called the "actor claim" so the claimed part is kind of implied. And "claimed actor claim" is a rather awkward. Really, all JWT claims are "claimed something" but they don't include the "claimed" bit in the name. RFC 7519, for example, defines the subject claim but not the claimed subject claim. On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: > Brian, > > Eric said: "what is the RP supposed to do when they encounter it? This > seems kind of under specified". > > After reading your explanations below, it looks like the RP can do > anything he wants with the "actor". > It is a "claimed actor" and, if we keep the concept, it should be called > as such. Such a claim cannot be verified. > A RP could copy and paste that claim in an audit log. No standard action > related to the content of such a claim > can be specified in the spec. If the content of a "claimed actor" is used > by the RP, it should be only used as an hint > and thus be subject to other verifications which are not specified in thi= s > specification. > > Denis > > Eric, I realize you weren't particularly impressed by my prior statements > about the actor claim but, for lack of knowing what else to say, I'm goin= g > to kind of repeat what I said about it over in the Phabricator tool > and add a > little color. > > The actor claim is intended as a way to express that delegation has > happened and identify the entities involved. Access control or other > decisions based on it are at the discretion of the consumer of the token > based on whatever policy might be in place. > > There are JWT claims that have concise processing rules with respect to > whether or not the JWT can be accepted as valid. Some examples are "aud" > (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519= . > E.g. if the token is expired or was intended for someone or something els= e, > reject it. > > And there are JWT claims that appropriately don't specify such processing > rules and are solely statements of fact or circumstance. Also from RFC > 7519, the "sub" (Subject) and "iat" (Issued At) claims are good examples = of > such. There might be application or policy specific rules applied to the > content of those kinds of claims (e.g. only subjects from a particular > organization are able to access tenant specific data or, less realistic b= ut > still possible, disallow access for tokens issued outside of regular > business hours) but that's all outside the scope of a specification's > definition of the claim. > > The actor claim falls into the latter category. It's a way for the issuer > of the token to tell the consumer of the token what is going on. But any > action to take (or not) based on that information is at the discretion of > the token consumer. I honestly don't know it could be anything more. And > don't think it should be. > > There are two main expected uses of the actor claim (that I'm aware of > anyway) that describing here might help. Maybe. One is a human to human > delegation case like a customer service rep doing something on behalf of = an > end user. The subject would be that user and the actor would be the > customer service rep. And there wouldn't be any chaining or nesting of th= e > actor. The other case is so called service chaining where a system might > exchange a token it receives for a new token that it can use to call a > downstream service. And that service in turn might do another exchange to > get a new token suitable to call yet another downstream service. And agai= n > and so on and turtles all the way. I'm not necessarily endorsing that lev= el > of granularity in chaining but it's bound to happen somewhere/sometime. T= he > nested actor claim is able to express that all that has happened with the > top level or outermost one being the system currently using the token and > prior systems being nested.. What actually gets done with that informatio= n > is up to the respective systems involved. There might be policy about wha= t > system is allowed to call what other system that is enforced. Or maybe th= e > info is just written to an audit log somewhere. Or something else. I don'= t > know. But whatever it is application/deployment/policy dependent and not > specifiable by a spec. > > > > > > > On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: > >> Hi folks, >> >> I've gone over draft-ietf-oauth-token-exchange-12 and things seem >> generally OK. I do still have one remaining concern, which is about >> the actor claim. Specifically, what is the RP supposed to do when they >> encounter it? This seems kind of underspecified. >> >> In particular: >> >> 1. What facts am I supposed to know here? Merely that everyone in >> the chain signed off on the next person in the chain acting as them? >> >> 2. Am I just supposed to pretend that the person presenting the token >> is the identity at the top of the chain? Say I have the >> delegation A -> B -> C, and there is some resource which >> B can access but A and C cannot, should I give access? >> >> I think the first question definitely needs an answer. The second >> question I guess we could make not answer, but it's pretty hard >> to know how to make a system with this left open.. >> >> -Ekr >> >> >> _______________________________________________ >> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000079a12056c5a0170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, it's already called the "actor claim" = so the claimed part is kind of implied. And "claimed actor claim"= is a rather awkward. Really, all JWT claims are "claimed something&qu= ot; but they don't include the "claimed" bit in the name. RFC= 7519, for example, defines the subject claim but not the claimed=C2=A0subj= ect claim.

On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr>= wrote:
=20 =20 =20
Brian,

Eric said: "what is the RP supposed to do when they encounter it= ? This seems kind of under specified".

After reading your explanations below, it looks like the RP can do anything he wants with the "actor".
It is a "claimed actor" and, if we keep the concept, it sho= uld be called as such. Such a claim cannot be verified.
A RP could copy and paste that claim in an audit log. No standard action related to the content of such a claim
can be specified in the spec. If the content of a "claimed actor= " is used by the RP, it should be only used as an hint
and thus be subject to other verifications which are not specified in this specification.

Denis

Eric, I realize you weren't particularly impressed b= y my prior statements about the actor claim but, for lack of knowing what else to say, I'm going to kind of repea= t what I said about it over in the Phabricator tool and add a little color.

The actor claim is intended as a way to express that delegation has happened and identify the entities involved. Access control or other decisions based on it are at the discretion of the consumer of the token based on whatever policy might be in place.

There are JWT claims that have concise processing rules with respect to whether or not the JWT can be accepted as valid. Some examples are "aud" (Audience), "ex= p" (Expiration Time), and "nbf" (Not Before) from RFC = 7519. E.g. if the token is expired or was intended for someone or something else, reject it.

And there are JWT claims that appropriately don't specify such processing rules and are solely statements of fact or circumstance. Also from RFC 7519, the "sub" (Subject)= and "iat" (Issued At) claims are good examples of such. T= here might be application or policy specific rules applied to the content of those kinds of claims (e.g. only subjects from a particular organization are able to access tenant specific data or, less realistic but still possible, disallow access for tokens issued outside of regular business hours) but that's all outside the scope of a specification's defin= ition of the claim.

The actor claim falls into the latter category. It's a way fo= r the issuer of the token to tell the consumer of the token what is going on. But any action to take (or not) based on that information is at the discretion of the token consumer. I honestly don't know it could be anything more. And don't = think it should be.

 There are two main expected uses of the actor claim (that I'm aware of anyway) that describing here might help. Maybe. One is a human to human delegation case like a customer service rep doing something on behalf of an end user. The subject would be that user and the actor would be the customer service rep. And there wouldn't be any chaining or nesting of the actor. The other case is so called service chaining where a system might exchange a token it receives for a new token that it can use to call a downstream service. And that service in turn might do another exchange to get a new token suitable to call yet another downstream service. And again and so on and turtles all the way. I'm not necessarily endorsing that level of granularity in chaining but it's bound to happen somewhere/sometime. The neste= d actor claim is able to express that all that has happened with the top level or outermost one being the system currently using the token and prior systems being nested.. What actually gets done with that information is up to the respective systems involved. There might be policy about what system is allowed to call what other system that is enforced. Or maybe the info is just written to an audit log somewhere. Or something else. I don't know. But whatever it is application/deployment/policy dependent and not specifiable by a spec.






On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

I've gone over draft-ietf-oauth-token-exchange-12 an= d things seem
generally OK. I do still have one remaining concern, which is about
the actor claim. Specifically, what is the RP supposed to do when they
encounter it? This seems kind of underspecified.

In particular:

1. What facts am I supposed to know here? Merely that everyone in
=C2=A0=C2=A0 the chain signed off on the next person in the c= hain acting as them?

2. Am I just supposed to pretend that the person presenting the token
=C2=A0=C2=A0 is the identity at the top of the chain? Say I h= ave the
=C2=A0=C2=A0 delegation A -> B -> C, and there is some resource which
=C2=A0=C2=A0 B can access but A and C cannot, should I give a= ccess?

I think the first question definitely needs an answer. The second
question I guess we could make not answer, but it's prett= y hard
to know how to make a system with this left open..

-Ekr


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



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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/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. --000000000000079a12056c5a0170-- From nobody Thu May 17 05:10: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 1F5C512D88D for ; Thu, 17 May 2018 05:10:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 3cFW5JFtRIi9 for ; Thu, 17 May 2018 05:10:37 -0700 (PDT) Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D3B12D878 for ; Thu, 17 May 2018 05:10:36 -0700 (PDT) Received: by mail-vk0-f47.google.com with SMTP id n134-v6so2513067vke.12 for ; Thu, 17 May 2018 05:10:36 -0700 (PDT) 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=DrGOnGkjrdIbspwUm6/1N26/yKj8PfJTKNYXYqnDqcA=; b=NsDi2j5e77YoRXZLaGsV0MhUvpYN7047u1J+SSCH1zGVkaUAPIc0QlszV1JqSzqDCH riIR0NhJgClQ6PWvaxLz3v6u5+kiDkxTJppmR98EjMVts1JMu7jmr3+C3G1SFQsJpqb3 veV04jH9660DCZMkr3b/ydpu+XfEAxrvi+H+oAsynLITqqdHuk0XiMM2Y/g8iVUDmm0L pPOQrMm88mvXiExwgj7DEp9nwpvbS55anxNPP+ymltSDIUNS4j7Nf3BDYkO2+K8FkoGJ gESiJYoOFoHnJJ1IgoFLCQifcUwkuIhEZr9v9btFJixSiUNNGuGUJPwfF3XQa7VEnCMW p1uw== X-Gm-Message-State: ALKqPwdIq/sPupwHaTxpAIcB5xDh3GA1HJCAVBlQv6DY0GcTxlxvGv8p ic6zIjBYW9oy+aokjJ1arRg1UjnN891ckeDOndBA9A== X-Google-Smtp-Source: AB8JxZpKszfZZ9vWNEuC1X5WvYEIOxu6U0ikGp94tlEhrA3bze1izooOUh5uamKC1pjOe4EBUityqCEx0BnEPGNjlKQ= X-Received: by 2002:a1f:c155:: with SMTP id r82-v6mr3828856vkf.76.1526559035398; Thu, 17 May 2018 05:10:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.192.11 with HTTP; Thu, 17 May 2018 05:10:34 -0700 (PDT) In-Reply-To: References: From: Bill Burke Date: Thu, 17 May 2018 08:10:34 -0400 Message-ID: To: Brian Campbell Cc: Denis , oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 12:10:40 -0000 My personal opinion is that I'm glad this actor stuff is optional. For one, none of our users have asked for it and really only do simple exchanges. Secondly, the rules for who can exchange what for what is controlled and defined within our AS. Makes things a lot simpler on the client. I kind of wish the actor stuff would be defined in a separate specification. I don't see us implementing it unless users start asking us to. On Wed, May 16, 2018 at 6:11 PM, Brian Campbell wrote: > Well, it's already called the "actor claim" so the claimed part is kind of > implied. And "claimed actor claim" is a rather awkward. Really, all JWT > claims are "claimed something" but they don't include the "claimed" bit in > the name. RFC 7519, for example, defines the subject claim but not the > claimed subject claim. > > On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: >> >> Brian, >> >> Eric said: "what is the RP supposed to do when they encounter it? This >> seems kind of under specified". >> >> After reading your explanations below, it looks like the RP can do >> anything he wants with the "actor". >> It is a "claimed actor" and, if we keep the concept, it should be called >> as such. Such a claim cannot be verified. >> A RP could copy and paste that claim in an audit log. No standard action >> related to the content of such a claim >> can be specified in the spec. If the content of a "claimed actor" is used >> by the RP, it should be only used as an hint >> and thus be subject to other verifications which are not specified in this >> specification. >> >> Denis >> >> Eric, I realize you weren't particularly impressed by my prior statements >> about the actor claim but, for lack of knowing what else to say, I'm going >> to kind of repeat what I said about it over in the Phabricator tool and add >> a little color. >> >> The actor claim is intended as a way to express that delegation has >> happened and identify the entities involved. Access control or other >> decisions based on it are at the discretion of the consumer of the token >> based on whatever policy might be in place. >> >> There are JWT claims that have concise processing rules with respect to >> whether or not the JWT can be accepted as valid. Some examples are "aud" >> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519. >> E.g. if the token is expired or was intended for someone or something else, >> reject it. >> >> And there are JWT claims that appropriately don't specify such processing >> rules and are solely statements of fact or circumstance. Also from RFC 7519, >> the "sub" (Subject) and "iat" (Issued At) claims are good examples of such. >> There might be application or policy specific rules applied to the content >> of those kinds of claims (e.g. only subjects from a particular organization >> are able to access tenant specific data or, less realistic but still >> possible, disallow access for tokens issued outside of regular business >> hours) but that's all outside the scope of a specification's definition of >> the claim. >> >> The actor claim falls into the latter category. It's a way for the issuer >> of the token to tell the consumer of the token what is going on. But any >> action to take (or not) based on that information is at the discretion of >> the token consumer. I honestly don't know it could be anything more. And >> don't think it should be. >> >> There are two main expected uses of the actor claim (that I'm aware of >> anyway) that describing here might help. Maybe. One is a human to human >> delegation case like a customer service rep doing something on behalf of an >> end user. The subject would be that user and the actor would be the customer >> service rep. And there wouldn't be any chaining or nesting of the actor. The >> other case is so called service chaining where a system might exchange a >> token it receives for a new token that it can use to call a downstream >> service. And that service in turn might do another exchange to get a new >> token suitable to call yet another downstream service. And again and so on >> and turtles all the way. I'm not necessarily endorsing that level of >> granularity in chaining but it's bound to happen somewhere/sometime. The >> nested actor claim is able to express that all that has happened with the >> top level or outermost one being the system currently using the token and >> prior systems being nested.. What actually gets done with that information >> is up to the respective systems involved. There might be policy about what >> system is allowed to call what other system that is enforced. Or maybe the >> info is just written to an audit log somewhere. Or something else. I don't >> know. But whatever it is application/deployment/policy dependent and not >> specifiable by a spec. >> >> >> >> >> >> >> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: >>> >>> Hi folks, >>> >>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem >>> generally OK. I do still have one remaining concern, which is about >>> the actor claim. Specifically, what is the RP supposed to do when they >>> encounter it? This seems kind of underspecified. >>> >>> In particular: >>> >>> 1. What facts am I supposed to know here? Merely that everyone in >>> the chain signed off on the next person in the chain acting as them? >>> >>> 2. Am I just supposed to pretend that the person presenting the token >>> is the identity at the top of the chain? Say I have the >>> delegation A -> B -> C, and there is some resource which >>> B can access but A and C cannot, should I give access? >>> >>> I think the first question definitely needs an answer. The second >>> question I guess we could make not answer, but it's pretty hard >>> to know how to make a system with this left open.. >>> >>> -Ekr >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 > -- Bill Burke Red Hat From robertotto@pingidentity.com Thu May 17 05:16: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 360CA12D88E for ; Thu, 17 May 2018 05:16: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 BvYpRl_UwJ-o for ; Thu, 17 May 2018 05:16:22 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 9B16612D874 for ; Thu, 17 May 2018 05:16:22 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id a22-v6so2016151pfn.6 for ; Thu, 17 May 2018 05:16:22 -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=FglYiXzS4rncdyw0Axk88KxG/fQ32Qz/bg1LNOxppjQ=; b=jLpNBNMno5NHITM2b36ziYI/mRDESvcTRIkbT240BiU7mcrjr0/ONYc49Yuds9ZYzr bYQD6pOR4zlzjeFCb7C+D//wmV6Lu2MGIMqiBfNljrHLFyUaYyBJW7WSlyr0bFoLK2jX GT98qFDHn5XcnLHzf180B5Vc3HDp/5M3+kcn0= 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=FglYiXzS4rncdyw0Axk88KxG/fQ32Qz/bg1LNOxppjQ=; b=dhhoZ5UaaNc4Pa06p4z2clWg2xUcNkpzf94BEGCyizQTFfkXiIXp77bly4R0Dz8lWm w3Y7ktKj142gWwwbtKTcDOY7QwXcvCOXAT0jxwfNVXez5Nt8/nAHuHof5//+yWTUAUK2 NtqWiAUiGdMi2kwPq1Ro6WChIIPC0foPpY2UIaxdYHgZHVmVtNkoK0UkC61AmeGfnb3h ++0uVYsMcYDirLCis5+0jqX75XBS5k44sJ7fSuMa8QySXAdebFmJdmrTpYyf3JI68KWN UwqkF87aCNeBEKSQhM6kv0h28u1XeAAIaqOnPErgV62CaC5I2LCp1Y81kGlQGopl/IG0 jC9w== X-Gm-Message-State: ALKqPwfStJsoExdFew80PoFlicg1uJzX0QmOjKAW80rwCA82ka9VNMQ1 dLmq4u0RwO2veTNaP2yKzCb7krdSuBBjUTAqhDHBLBD1iU/Aeca6qiJ0aQBh9kCsvK6ACvqJRC7 DiEl01MzWnnEQ3Q== X-Google-Smtp-Source: AB8JxZrEMfExBah/ktOUgopvjwGjml5LFtyMXfDO87geMuxW8vWXprDQ1AnDva8gkQKUJjbl9c/ZzIyNS7GUGb7JZQw= X-Received: by 2002:a63:6110:: with SMTP id v16-v6mr3920692pgb.292.1526559382007; Thu, 17 May 2018 05:16:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Otto Date: Thu, 17 May 2018 13:16:04 +0100 Message-ID: To: Bill Burke Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="000000000000b19a71056c65cdc2" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 12:23:28 -0000 --000000000000b19a71056c65cdc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to this. Rob On Thu, 17 May 2018 at 13:10, Bill Burke wrote: > My personal opinion is that I'm glad this actor stuff is optional. > For one, none of our users have asked for it and really only do simple > exchanges. Secondly, the rules for who can exchange what for what is > controlled and defined within our AS. Makes things a lot simpler on > the client. I kind of wish the actor stuff would be defined in a > separate specification. I don't see us implementing it unless users > start asking us to. > > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell > wrote: > > Well, it's already called the "actor claim" so the claimed part is kind > of > > implied. And "claimed actor claim" is a rather awkward. Really, all JWT > > claims are "claimed something" but they don't include the "claimed" bit > in > > the name. RFC 7519, for example, defines the subject claim but not the > > claimed subject claim. > > > > On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: > >> > >> Brian, > >> > >> Eric said: "what is the RP supposed to do when they encounter it? This > >> seems kind of under specified". > >> > >> After reading your explanations below, it looks like the RP can do > >> anything he wants with the "actor". > >> It is a "claimed actor" and, if we keep the concept, it should be call= ed > >> as such. Such a claim cannot be verified. > >> A RP could copy and paste that claim in an audit log. No standard acti= on > >> related to the content of such a claim > >> can be specified in the spec. If the content of a "claimed actor" is > used > >> by the RP, it should be only used as an hint > >> and thus be subject to other verifications which are not specified in > this > >> specification. > >> > >> Denis > >> > >> Eric, I realize you weren't particularly impressed by my prior > statements > >> about the actor claim but, for lack of knowing what else to say, I'm > going > >> to kind of repeat what I said about it over in the Phabricator tool an= d > add > >> a little color. > >> > >> The actor claim is intended as a way to express that delegation has > >> happened and identify the entities involved. Access control or other > >> decisions based on it are at the discretion of the consumer of the tok= en > >> based on whatever policy might be in place. > >> > >> There are JWT claims that have concise processing rules with respect t= o > >> whether or not the JWT can be accepted as valid. Some examples are "au= d" > >> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC > 7519. > >> E.g. if the token is expired or was intended for someone or something > else, > >> reject it. > >> > >> And there are JWT claims that appropriately don't specify such > processing > >> rules and are solely statements of fact or circumstance. Also from RFC > 7519, > >> the "sub" (Subject) and "iat" (Issued At) claims are good examples of > such. > >> There might be application or policy specific rules applied to the > content > >> of those kinds of claims (e.g. only subjects from a particular > organization > >> are able to access tenant specific data or, less realistic but still > >> possible, disallow access for tokens issued outside of regular busines= s > >> hours) but that's all outside the scope of a specification's definitio= n > of > >> the claim. > >> > >> The actor claim falls into the latter category. It's a way for the > issuer > >> of the token to tell the consumer of the token what is going on. But a= ny > >> action to take (or not) based on that information is at the discretion > of > >> the token consumer. I honestly don't know it could be anything more. A= nd > >> don't think it should be. > >> > >> There are two main expected uses of the actor claim (that I'm aware of > >> anyway) that describing here might help. Maybe. One is a human to huma= n > >> delegation case like a customer service rep doing something on behalf > of an > >> end user. The subject would be that user and the actor would be the > customer > >> service rep. And there wouldn't be any chaining or nesting of the > actor. The > >> other case is so called service chaining where a system might exchange= a > >> token it receives for a new token that it can use to call a downstream > >> service. And that service in turn might do another exchange to get a n= ew > >> token suitable to call yet another downstream service. And again and s= o > on > >> and turtles all the way. I'm not necessarily endorsing that level of > >> granularity in chaining but it's bound to happen somewhere/sometime. T= he > >> nested actor claim is able to express that all that has happened with > the > >> top level or outermost one being the system currently using the token > and > >> prior systems being nested.. What actually gets done with that > information > >> is up to the respective systems involved. There might be policy about > what > >> system is allowed to call what other system that is enforced. Or maybe > the > >> info is just written to an audit log somewhere. Or something else. I > don't > >> know. But whatever it is application/deployment/policy dependent and n= ot > >> specifiable by a spec. > >> > >> > >> > >> > >> > >> > >> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: > >>> > >>> Hi folks, > >>> > >>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem > >>> generally OK. I do still have one remaining concern, which is about > >>> the actor claim. Specifically, what is the RP supposed to do when the= y > >>> encounter it? This seems kind of underspecified. > >>> > >>> In particular: > >>> > >>> 1. What facts am I supposed to know here? Merely that everyone in > >>> the chain signed off on the next person in the chain acting as the= m? > >>> > >>> 2. Am I just supposed to pretend that the person presenting the token > >>> is the identity at the top of the chain? Say I have the > >>> delegation A -> B -> C, and there is some resource which > >>> B can access but A and C cannot, should I give access? > >>> > >>> I think the first question definitely needs an answer. The second > >>> question I guess we could make not answer, but it's pretty hard > >>> to know how to make a system with this left open.. > >>> > >>> -Ekr > >>> > >>> > >>> _______________________________________________ > >>> 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, us= e, > >> 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 > >> > > > > > > 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 > > > > > > -- > Bill Burke > Red Hat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 --=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._ --000000000000b19a71056c65cdc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to this.=C2=A0

<= div dir=3D"auto">Rob


On Thu, 17 May 2018 at 13:10, Bill Burke <bburke@redhat.com> wrote:
My personal opinion is that I'm glad this actor stu= ff is optional.
For one, none of our users have asked for it and really only do simple
exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is<= br> controlled and defined within our AS.=C2=A0 Makes things a lot simpler on the client.=C2=A0 I kind of wish the actor stuff would be defined in a
separate specification.=C2=A0 I don't see us implementing it unless use= rs
start asking us to.

On Wed, May 16, 2018 at 6:11 PM, Brian Campbell
<bcampbe= ll@pingidentity.com> wrote:
> Well, it's already called the "actor claim" so the claim= ed part is kind of
> implied. And "claimed actor claim" is a rather awkward. Real= ly, all JWT
> claims are "claimed something" but they don't include th= e "claimed" bit in
> the name. RFC 7519, for example, defines the subject claim but not the=
> claimed subject claim.
>
> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>
>> Brian,
>>
>> Eric said: "what is the RP supposed to do when they encounter= it? This
>> seems kind of under specified".
>>
>> After reading your explanations below, it looks like the RP can do=
>> anything he wants with the "actor".
>> It is a "claimed actor" and, if we keep the concept, it = should be called
>> as such. Such a claim cannot be verified.
>> A RP could copy and paste that claim in an audit log. No standard = action
>> related to the content of such a claim
>> can be specified in the spec. If the content of a "claimed ac= tor" is used
>> by the RP, it should be only used as an hint
>> and thus be subject to other verifications which are not specified= in this
>> specification.
>>
>> Denis
>>
>> Eric, I realize you weren't particularly impressed by my prior= statements
>> about the actor claim but, for lack of knowing what else to say, I= 'm going
>> to kind of repeat what I said about it over in the Phabricator too= l and add
>> a little color.
>>
>> The actor claim is intended as a way to express that delegation ha= s
>> happened and identify the entities involved. Access control or oth= er
>> decisions based on it are at the discretion of the consumer of the= token
>> based on whatever policy might be in place.
>>
>> There are JWT claims that have concise processing rules with respe= ct to
>> whether or not the JWT can be accepted as valid. Some examples are= "aud"
>> (Audience), "exp" (Expiration Time), and "nbf"= (Not Before) from RFC 7519.
>> E.g. if the token is expired or was intended for someone or someth= ing else,
>> reject it.
>>
>> And there are JWT claims that appropriately don't specify such= processing
>> rules and are solely statements of fact or circumstance. Also from= RFC 7519,
>> the "sub" (Subject) and "iat" (Issued At) clai= ms are good examples of such.
>> There might be application or policy specific rules applied to the= content
>> of those kinds of claims (e.g. only subjects from a particular org= anization
>> are able to access tenant specific data or, less realistic but sti= ll
>> possible, disallow access for tokens issued outside of regular bus= iness
>> hours) but that's all outside the scope of a specification'= ;s definition of
>> the claim.
>>
>> The actor claim falls into the latter category. It's a way for= the issuer
>> of the token to tell the consumer of the token what is going on. B= ut any
>> action to take (or not) based on that information is at the discre= tion of
>> the token consumer. I honestly don't know it could be anything= more. And
>> don't think it should be.
>>
>> There are two main expected uses of the actor claim (that I'm = aware of
>> anyway) that describing here might help. Maybe. One is a human to = human
>> delegation case like a customer service rep doing something on beh= alf of an
>> end user. The subject would be that user and the actor would be th= e customer
>> service rep. And there wouldn't be any chaining or nesting of = the actor. The
>> other case is so called service chaining where a system might exch= ange a
>> token it receives for a new token that it can use to call a downst= ream
>> service. And that service in turn might do another exchange to get= a new
>> token suitable to call yet another downstream service. And again a= nd so on
>> and turtles all the way. I'm not necessarily endorsing that le= vel of
>> granularity in chaining but it's bound to happen somewhere/som= etime. The
>> nested actor claim is able to express that all that has happened w= ith the
>> top level or outermost one being the system currently using the to= ken and
>> prior systems being nested.. What actually gets done with that inf= ormation
>> is up to the respective systems involved. There might be policy ab= out what
>> system is allowed to call what other system that is enforced. Or m= aybe the
>> info is just written to an audit log somewhere. Or something else.= I don't
>> know. But whatever it is application/deployment/policy dependent a= nd not
>> specifiable by a spec.
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> Hi folks,
>>>
>>> I've gone over draft-ietf-oauth-token-exchange-12 and thin= gs seem
>>> generally OK. I do still have one remaining concern, which is = about
>>> the actor claim. Specifically, what is the RP supposed to do w= hen they
>>> encounter it? This seems kind of underspecified.
>>>
>>> In particular:
>>>
>>> 1. What facts am I supposed to know here? Merely that everyone= in
>>>=C2=A0 =C2=A0 the chain signed off on the next person in the ch= ain acting as them?
>>>
>>> 2. Am I just supposed to pretend that the person presenting th= e token
>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say I ha= ve the
>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is some r= esource which
>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I give ac= cess?
>>>
>>> I think the first question definitely needs an answer. The sec= ond
>>> question I guess we could make not answer, but it's pretty= hard
>>> to know how to make a system with this left open..
>>>
>>> -Ekr
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged
>> material for the sole use of the intended recipient(s). Any review= , use,
>> distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have
>> received this communication in error, please notify the sender imm= ediately
>> by e-mail and delete the message and any file attachments from you= r
>> computer. Thank you.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= 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= you have
> received this communication in error, please notify the sender immedia= tely
> 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
>



--
Bill Burke
Red Hat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Rob Otto
EMEA Field CTO - Ping Identi= ty
+44 777 135 6092

<= 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. --000000000000b19a71056c65cdc2-- From nobody Thu May 17 05:57: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 0B1C412DA0A for ; Thu, 17 May 2018 05:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 eB9hZ3o1zLJR for ; Thu, 17 May 2018 05:57:01 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 F2C2012D94D for ; Thu, 17 May 2018 05:57:00 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id r28-v6so1193887qkk.4 for ; Thu, 17 May 2018 05:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:user-agent; bh=AN4GjnOXZic34XS8cTJMFKX+S9U8lk7Z0kcz71QXXNE=; b=ZkJCckl9cGwJmLdI7ISLE+MR8wfsHFbq0s2vOeMX5fsWL1TkyoKGsD6Co2n+sQx14T c9T5nuLjg27uQLRV8FUIAqomVb4nXI2w7BlYOVeTEPWF8PZF1gHhKwhEOBWFpZon9g0F +CUEuIm2L8nTRm6NuFcnodFyV8Jtp899Kvn+ayUGfMusFNgBy1Bzc8ZnsCDksUGpeJXd SwO6sNRKOPs8LKUlEOrHQxpx7xh6ISrefqjcKPPWUb+kdJMDt47MC7qj1QJlgH9lUqp3 caxp5psixtKnk0MwX4LRtigF+Io/KXDXBY0iRyH6tT1vd3ZuK7T2m3CvGf5LDJh0pYi5 WjUg== 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 :user-agent; bh=AN4GjnOXZic34XS8cTJMFKX+S9U8lk7Z0kcz71QXXNE=; b=VbXujIrhX90+qF1zJTbFIkdH0310ase75a3deUKnViA3L1MG6F/8kItajg/ThqYpOT NFmpSAeU6JYRgi7UwI17PCDiUHuyDussrlu4rfXT70iFOhSEDXXovRBNWs1ZImhE3ZJ0 eCXdAC3H1rRPLYvD6o/Lpj0+OgkFB2ZaEad5JiMaeFn+ekmbryyohHqXJNBa1trW+o5j QRvCe4O6TOC6BjikYL7x4z0ZlRm7ALASh4iNv+KvqtOWiJMhCdQJoNpKyShDZSwKRAJ6 8YZS/Gl7/23VXrCQ4gqRnmkiJ+46aTePCdIMkLOp9MelSHou5VyP9L8Tffbx10ekUaMK pOaw== X-Gm-Message-State: ALKqPwe/h2AlAKAaI1qZB7WaZyBfU48GCKcojNhF2/Vx+h552lFiCJOj tWivOqPiWMlol3/XF4zP7UtV01YR X-Google-Smtp-Source: AB8JxZrpIRZ5R48OBLLAZ98i7fBLETC4DH+XO+zmcA24Hcvxrl/GdhlDSZjOJCOhauOdgB8RgDjt2g== X-Received: by 2002:a37:1fc2:: with SMTP id n63-v6mr4632630qkh.8.1526561819114; Thu, 17 May 2018 05:56:59 -0700 (PDT) Received: from [192.168.0.205] ([66.194.212.163]) by smtp.gmail.com with ESMTPSA id k46-v6sm3872130qta.65.2018.05.17.05.56.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 05:56:57 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_55672916.149041615614" MIME-Version: 1.0 Date: Thu, 17 May 2018 08:56:52 -0400 Message-ID: From: "Brock Allen" To: "" User-Agent: Mailbird/2.5.8.0 X-Mailbird-ID: ab42d84a-5f08-4600-aa36-92e73944cf6c@getmailbird.com Archived-At: Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 12:57:03 -0000 ------=_NextPart_55672916.149041615614 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens But this requires: * AS/OP to support PKCE *=C2=A0AS/OP to support=C2=A0CORS=C2=A0 * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens=C2=A0 * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout Any use in discussing this? -Brock ------=_NextPart_55672916.149041615614 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Much like updated guidance was provided with t= he "OAuth2 for native apps" RFC, should there be one for "browser-based cli= ent-side JS apps"? I ask because google is actively discouraging the use of= implicit flow:

https://github.com/openid/AppAuth-JS/iss= ues/59#issuecomment-389639290

From what I can tell= , the complaints with implicit are:
* access token in URL
* access token in browser history
* iframe complexity when usi= ng prompt=3Dnone to "refresh" access tokens

But th= is requires:
* AS/OP to support PKCE
* AS/OP to support CORS 
= * user-agent must support = CORS
* AS= /OP to maintain short-lived refresh tokens 
* AS/OP must aggressively revoke re= fresh tokens at user signout (which is not something OAuth2 "knows" about)<= /span>
* if the = above point can't work, then client must proactively use revocation endpoin= t if/when user triggers logout

Any use in discussing this?

-Brock=

------=_NextPart_55672916.149041615614-- From nobody Thu May 17 06:26:17 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 0A7B912EAF6 for ; Thu, 17 May 2018 06:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-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=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 iqFfah18IiXe for ; Thu, 17 May 2018 06:26:11 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0132.outbound.protection.outlook.com [104.47.34.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BA012DB6D for ; Thu, 17 May 2018 06:26:10 -0700 (PDT) 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=VyoYNCinopP1GZTia8Flqup4l1K+AzjKBFKxkWd+h4s=; b=YJKIaaMSdLiXrqQ6u2GeF0lOHopBFNp6pKeyhCpshi8Ic7H5R2hOin/Q1IgGzoNQmq//eJZeY22kLaN1HO+eK7pa3AWRcdfCfMO6O7vypDZ239yXang9ujXFcH3UswdA0incuPj/0yOTmIyAHGR/D6JOEvi17ibIRcHSdPy59gY= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0415.namprd00.prod.outlook.com (52.132.118.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.814.0; Thu, 17 May 2018 13:26:05 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::e982:2d7:adba:3cf6]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::e982:2d7:adba:3cf6%2]) with mapi id 15.20.0820.000; Thu, 17 May 2018 13:26:05 +0000 From: Mike Jones To: Bill Burke , Brian Campbell CC: oauth Thread-Topic: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt Thread-Index: AQHT04kMYSOXZXkjckeL5mvf+b6Pp6QHHXqAgALYHoCAKSjwgIAA6oMAgAAT9vA= Date: Thu, 17 May 2018 13:26:04 +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: [2001:1b18:a3:300:f151:33fc:5438:4b81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0415; 7:E8hKpShGrX9AzmCwG3WhQaFmEy8/5EYmBnr0lcNbkL4aaM7jvmOZSxCBrAy/BQ+YNIrcmpMAcb7WWwO/IPQspgrukOMoBmQHuHJ7f5yAAL1vfrFy1L0amQa1GO54k/7P+jCKhZY9f3N0fZm4Cztx/jxnsTncWCj/FVo6r1INYVIX1j4nY9Bq/mn0LrmiGEPdBIEwV3lvjPapwBUS+lx3Mqdssc+lEMBsEmdD4dtvYSQxfkLV4WiV7p54JFJiGybb; 20:ffMoqBSZHN/MpyQueO1Ob1pDxwVFmM5T6pqXQQoH8m8nPe1zqMrpJkW4XnGM7eVKU+HJq/tUjXMi3BFp+weCXxKddA/JzCA9cIKkue5DvMHtazw5ZceLqCwpKT4c4WQk+3MrTHk6VLy9cosdrInLiDXE2LGwTzpe4Pc0JoRqL1I= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0415; x-ms-traffictypediagnostic: SN6PR00MB0415: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(191636701735510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(10201501046)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0415; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0415; x-forefront-prvs: 067553F396 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(396003)(39380400002)(366004)(199004)(189003)(13464003)(102836004)(59450400001)(46003)(6506007)(53546011)(68736007)(8936002)(76176011)(93886005)(97736004)(3660700001)(99286004)(8676002)(3280700002)(81166006)(81156014)(7696005)(186003)(74316002)(86612001)(2906002)(305945005)(476003)(5660300001)(7736002)(22452003)(86362001)(110136005)(5890100001)(446003)(11346002)(5250100002)(316002)(486006)(72206003)(33656002)(25786009)(6116002)(10290500003)(966005)(14454004)(478600001)(4326008)(9686003)(6246003)(53936002)(229853002)(10090500001)(6306002)(55016002)(6436002)(2900100001)(8990500004)(105586002)(106356001)(15866825006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0415; H:SN6PR00MB0301.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: kQtqJBu5y5BGdIpXvbqAVEQDQSSMGS6UW0H5kdrbJ2VbNYlj128Z38uM18W/yUFNxG1lzX1cvXn5kii7UvhzeHUgl/huJAo7qAUboySdUX/Af+x5R+RDpBs5C3RagGg6hOxn9MKOUk45FIClSCCENB5Be4JUB1RiLgt4Q8ICCFZ/UJ38guQQdBC5ItMLpzBY spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 03f6c7c5-43c7-432e-e8ed-08d5bbf9bdeb X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03f6c7c5-43c7-432e-e8ed-08d5bbf9bdeb X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2018 13:26:04.9077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0415 Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:26:15 -0000 Moving the actor claim to a separate specification would only make things m= ore complicated for developers. There already plenty of OAuth specs. Need= lessly adding another one will only make related things harder to find. Just like in the JWT [RFC 7519] spec itself in which use of all the claims = is optional, use of the actor claim in this spec. If you don't need it, do= n't use it. Just because some won't use it is no better an argument for mo= ving it to a different spec than the argument that JWT should have defined = each of its claims in different specs. That would have made things harder,= not easier. -- Mike -----Original Message----- From: OAuth On Behalf Of Bill Burke Sent: Thursday, May 17, 2018 2:11 PM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt My personal opinion is that I'm glad this actor stuff is optional. For one, none of our users have asked for it and really only do simple exch= anges. Secondly, the rules for who can exchange what for what is controlle= d and defined within our AS. Makes things a lot simpler on the client. I = kind of wish the actor stuff would be defined in a separate specification. = I don't see us implementing it unless users start asking us to. On Wed, May 16, 2018 at 6:11 PM, Brian Campbell wrote: > Well, it's already called the "actor claim" so the claimed part is=20 > kind of implied. And "claimed actor claim" is a rather awkward.=20 > Really, all JWT claims are "claimed something" but they don't include=20 > the "claimed" bit in the name. RFC 7519, for example, defines the=20 > subject claim but not the claimed subject claim. > > On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: >> >> Brian, >> >> Eric said: "what is the RP supposed to do when they encounter it?=20 >> This seems kind of under specified". >> >> After reading your explanations below, it looks like the RP can do=20 >> anything he wants with the "actor". >> It is a "claimed actor" and, if we keep the concept, it should be=20 >> called as such. Such a claim cannot be verified. >> A RP could copy and paste that claim in an audit log. No standard=20 >> action related to the content of such a claim can be specified in the=20 >> spec. If the content of a "claimed actor" is used by the RP, it=20 >> should be only used as an hint and thus be subject to other=20 >> verifications which are not specified in this specification. >> >> Denis >> >> Eric, I realize you weren't particularly impressed by my prior=20 >> statements about the actor claim but, for lack of knowing what else=20 >> to say, I'm going to kind of repeat what I said about it over in the=20 >> Phabricator tool and add a little color. >> >> The actor claim is intended as a way to express that delegation has=20 >> happened and identify the entities involved. Access control or other=20 >> decisions based on it are at the discretion of the consumer of the=20 >> token based on whatever policy might be in place. >> >> There are JWT claims that have concise processing rules with respect=20 >> to whether or not the JWT can be accepted as valid. Some examples are "a= ud" >> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 751= 9. >> E.g. if the token is expired or was intended for someone or something=20 >> else, reject it. >> >> And there are JWT claims that appropriately don't specify such=20 >> processing rules and are solely statements of fact or circumstance.=20 >> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims are= good examples of such. >> There might be application or policy specific rules applied to the=20 >> content of those kinds of claims (e.g. only subjects from a=20 >> particular organization are able to access tenant specific data or,=20 >> less realistic but still possible, disallow access for tokens issued=20 >> outside of regular business >> hours) but that's all outside the scope of a specification's=20 >> definition of the claim. >> >> The actor claim falls into the latter category. It's a way for the=20 >> issuer of the token to tell the consumer of the token what is going=20 >> on. But any action to take (or not) based on that information is at=20 >> the discretion of the token consumer. I honestly don't know it could=20 >> be anything more. And don't think it should be. >> >> There are two main expected uses of the actor claim (that I'm aware=20 >> of >> anyway) that describing here might help. Maybe. One is a human to=20 >> human delegation case like a customer service rep doing something on=20 >> behalf of an end user. The subject would be that user and the actor=20 >> would be the customer service rep. And there wouldn't be any chaining=20 >> or nesting of the actor. The other case is so called service chaining=20 >> where a system might exchange a token it receives for a new token=20 >> that it can use to call a downstream service. And that service in=20 >> turn might do another exchange to get a new token suitable to call=20 >> yet another downstream service. And again and so on and turtles all=20 >> the way. I'm not necessarily endorsing that level of granularity in=20 >> chaining but it's bound to happen somewhere/sometime. The nested=20 >> actor claim is able to express that all that has happened with the=20 >> top level or outermost one being the system currently using the token=20 >> and prior systems being nested.. What actually gets done with that=20 >> information is up to the respective systems involved. There might be=20 >> policy about what system is allowed to call what other system that is=20 >> enforced. Or maybe the info is just written to an audit log=20 >> somewhere. Or something else. I don't know. But whatever it is applicati= on/deployment/policy dependent and not specifiable by a spec. >> >> >> >> >> >> >> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: >>> >>> Hi folks, >>> >>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem=20 >>> generally OK. I do still have one remaining concern, which is about=20 >>> the actor claim. Specifically, what is the RP supposed to do when=20 >>> they encounter it? This seems kind of underspecified. >>> >>> In particular: >>> >>> 1. What facts am I supposed to know here? Merely that everyone in >>> the chain signed off on the next person in the chain acting as them? >>> >>> 2. Am I just supposed to pretend that the person presenting the token >>> is the identity at the top of the chain? Say I have the >>> delegation A -> B -> C, and there is some resource which >>> B can access but A and C cannot, should I give access? >>> >>> I think the first question definitely needs an answer. The second=20 >>> question I guess we could make not answer, but it's pretty hard to=20 >>> know how to make a system with this left open.. >>> >>> -Ekr >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> CONFIDENTIALITY NOTICE: This email may contain confidential and=20 >> privileged material for the sole use of the intended recipient(s).=20 >> Any review, use, distribution or disclosure by others is strictly=20 >> prohibited.. If you have received this communication in error,=20 >> please notify the sender immediately by e-mail and delete the message=20 >> 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 >> > > > CONFIDENTIALITY NOTICE: This email may contain confidential and=20 > privileged material for the sole use of the intended recipient(s). Any=20 > review, use, distribution or disclosure by others is strictly=20 > prohibited.. If you have received this communication in error, please=20 > notify the sender immediately by e-mail and delete the message and any=20 > file attachments from your computer. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke Red Hat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu May 17 07:03:17 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 4971312EAF3 for ; Thu, 17 May 2018 07:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FNnH04Hifc7b for ; Thu, 17 May 2018 07:03:13 -0700 (PDT) Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BD2126D0C for ; Thu, 17 May 2018 07:03:13 -0700 (PDT) Received: by mail-vk0-f45.google.com with SMTP id t63-v6so2766556vkb.1 for ; Thu, 17 May 2018 07:03:13 -0700 (PDT) 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:content-transfer-encoding; bh=3vklw4Hp0K+fIoJggCgtRD2lKAtIcxkAoMzpXZqvWzk=; b=s1C5MFdYMk8pDpCBYJJG/ZM8gcp/kGmE6lMoDD6R80cCYN9VGDKJDEMB5YKkVa6peA f24x7uZogrishu+NbOt6RPQfDfEVzUe29kVTsIKP/Mrlawr1Z7iTzHgidiLQhxxbmXFj UAltg4mp4itOMDxlhmkgLQyUtbh76360FQ1XZKdwBXegSW07Z0Zw/PRM3MrKjdObV4Jo q0JF7uzDYcrv8qrDgpoO8lU8+lD6WB6yg6Yj3cBDnPhyKMPixqQSWr5IS7D8vkDzcAcz 3otvkubUnyQ8EH+m6A7RLLbG1Kjslv3g0UTxpB9IDoh5nh1WHUZqrAfAnmWmSUs2XgEt jEjA== X-Gm-Message-State: ALKqPweqZougthutjfP9iET4ni38eCEOanljD4/sy0pqd3zJIT1FhVSS ZHtmqARXwEOBMmwn3IMCC4V2R581fLpSQO48w2vvxQ== X-Google-Smtp-Source: AB8JxZp43Pa31EQP67sz6PiedoWWmCEPWqDXXkYFv1bVM43GN6w6h8mVDqFbAkDGK9XexCkq1/V1WFwIitZ1zzUz1/Y= X-Received: by 2002:a1f:a6cf:: with SMTP id p198-v6mr4095960vke.107.1526565792085; Thu, 17 May 2018 07:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.192.11 with HTTP; Thu, 17 May 2018 07:03:11 -0700 (PDT) In-Reply-To: References: From: Bill Burke Date: Thu, 17 May 2018 10:03:11 -0400 Message-ID: To: Mike Jones Cc: Brian Campbell , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 14:03:16 -0000 This is an honest question: How important is the actor stuff to the players involved? Are people going to use it? IMO, its an edge case and I think more important areas, like external token exchange (realm to realm, domain to domain) are being neglected. I'm quite unfamiliar how consensus is reached in this WG or the IETF, so I hope I'm not sounding rude. Just trying to provide some constructive feedback. On Thu, May 17, 2018 at 9:26 AM, Mike Jones w= rote: > Moving the actor claim to a separate specification would only make things= more complicated for developers. There already plenty of OAuth specs. Ne= edlessly adding another one will only make related things harder to find. > > Just like in the JWT [RFC 7519] spec itself in which use of all the claim= s is optional, use of the actor claim in this spec. If you don't need it, = don't use it. Just because some won't use it is no better an argument for = moving it to a different spec than the argument that JWT should have define= d each of its claims in different specs. That would have made things harde= r, not easier. > > -- Mike > > -----Original Message----- > From: OAuth On Behalf Of Bill Burke > Sent: Thursday, May 17, 2018 2:11 PM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.tx= t > > My personal opinion is that I'm glad this actor stuff is optional. > For one, none of our users have asked for it and really only do simple ex= changes. Secondly, the rules for who can exchange what for what is control= led and defined within our AS. Makes things a lot simpler on the client. = I kind of wish the actor stuff would be defined in a separate specification= . I don't see us implementing it unless users start asking us to. > > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell wrote: >> Well, it's already called the "actor claim" so the claimed part is >> kind of implied. And "claimed actor claim" is a rather awkward. >> Really, all JWT claims are "claimed something" but they don't include >> the "claimed" bit in the name. RFC 7519, for example, defines the >> subject claim but not the claimed subject claim. >> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: >>> >>> Brian, >>> >>> Eric said: "what is the RP supposed to do when they encounter it? >>> This seems kind of under specified". >>> >>> After reading your explanations below, it looks like the RP can do >>> anything he wants with the "actor". >>> It is a "claimed actor" and, if we keep the concept, it should be >>> called as such. Such a claim cannot be verified. >>> A RP could copy and paste that claim in an audit log. No standard >>> action related to the content of such a claim can be specified in the >>> spec. If the content of a "claimed actor" is used by the RP, it >>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>> >>> Denis >>> >>> Eric, I realize you weren't particularly impressed by my prior >>> statements about the actor claim but, for lack of knowing what else >>> to say, I'm going to kind of repeat what I said about it over in the >>> Phabricator tool and add a little color. >>> >>> The actor claim is intended as a way to express that delegation has >>> happened and identify the entities involved. Access control or other >>> decisions based on it are at the discretion of the consumer of the >>> token based on whatever policy might be in place. >>> >>> There are JWT claims that have concise processing rules with respect >>> to whether or not the JWT can be accepted as valid. Some examples are "= aud" >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 75= 19. >>> E.g. if the token is expired or was intended for someone or something >>> else, reject it. >>> >>> And there are JWT claims that appropriately don't specify such >>> processing rules and are solely statements of fact or circumstance. >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims ar= e good examples of such. >>> There might be application or policy specific rules applied to the >>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific data or, >>> less realistic but still possible, disallow access for tokens issued >>> outside of regular business >>> hours) but that's all outside the scope of a specification's >>> definition of the claim. >>> >>> The actor claim falls into the latter category. It's a way for the >>> issuer of the token to tell the consumer of the token what is going >>> on. But any action to take (or not) based on that information is at >>> the discretion of the token consumer. I honestly don't know it could >>> be anything more. And don't think it should be. >>> >>> There are two main expected uses of the actor claim (that I'm aware >>> of >>> anyway) that describing here might help. Maybe. One is a human to >>> human delegation case like a customer service rep doing something on >>> behalf of an end user. The subject would be that user and the actor >>> would be the customer service rep. And there wouldn't be any chaining >>> or nesting of the actor. The other case is so called service chaining >>> where a system might exchange a token it receives for a new token >>> that it can use to call a downstream service. And that service in >>> turn might do another exchange to get a new token suitable to call >>> yet another downstream service. And again and so on and turtles all >>> the way. I'm not necessarily endorsing that level of granularity in >>> chaining but it's bound to happen somewhere/sometime. The nested >>> actor claim is able to express that all that has happened with the >>> top level or outermost one being the system currently using the token >>> and prior systems being nested.. What actually gets done with that >>> information is up to the respective systems involved. There might be >>> policy about what system is allowed to call what other system that is >>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever it is applicat= ion/deployment/policy dependent and not specifiable by a spec. >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: >>>> >>>> Hi folks, >>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem >>>> generally OK. I do still have one remaining concern, which is about >>>> the actor claim. Specifically, what is the RP supposed to do when >>>> they encounter it? This seems kind of underspecified. >>>> >>>> In particular: >>>> >>>> 1. What facts am I supposed to know here? Merely that everyone in >>>> the chain signed off on the next person in the chain acting as them= ? >>>> >>>> 2. Am I just supposed to pretend that the person presenting the token >>>> is the identity at the top of the chain? Say I have the >>>> delegation A -> B -> C, and there is some resource which >>>> B can access but A and C cannot, should I give access? >>>> >>>> I think the first question definitely needs an answer. The second >>>> question I guess we could make not answer, but it's pretty hard to >>>> know how to make a system with this left open.. >>>> >>>> -Ekr >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Bill Burke > Red Hat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Bill Burke Red Hat From nobody Thu May 17 09:23:29 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 BDF73120725 for ; Thu, 17 May 2018 09:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=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 za2xC57G6KzW for ; Thu, 17 May 2018 09:23:23 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10060.outbound.protection.outlook.com [40.107.1.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7813F1242F5 for ; Thu, 17 May 2018 09:23:22 -0700 (PDT) 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=MYZW2FxJDWS1dsdHeGuRnIRxHPntcWrlNhx8VqOq8/Q=; b=pmdzPirorT6jgZEUKUpGx0TMbEQbrF0+MggegFxkuj47EIWuV47dsU5zzgy341KD9bJENlHsjv+Y8nr4CnzQ75pnMDkhNjdTldMwodg0rBs4GWOXS/ZSPkJ9NC67VZMwhqWq/z/5/ActlJm473xkJbbgp+f7XhS8IQstkY/1xlo= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1806.eurprd08.prod.outlook.com (10.168.67.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Thu, 17 May 2018 16:23:19 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Thu, 17 May 2018 16:23:19 +0000 From: Hannes Tschofenig To: Brock Allen , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] is updated guidance needed for JS/SPA apps? Thread-Index: AQHT7d6TKnUPm2MfgEWeZp6kt5T8v6Q0Gp5g Date: Thu, 17 May 2018 16:23:19 +0000 Message-ID: References: In-Reply-To: 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: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1806; 7:T75WybIAIlhGaS9HH1K7y738fPs47zmZ4A/kLIiTwhg9inEL7TSwl8X1//13/D6ugftEtQJ8hRAr54qm9WsNSBhKkETWrQB5BbtghWuA9d9Lf3LNn8n96f977sTnamc15Q9cxygxaucMPlefIJbLe9gzdPn6NZeY/tioQBn2U4k/E+nsPdBGP5mM4MnZOz+U5yHOq1QmagSrYnnrtyx/wbC6iU5a1GKGs9NsxFs6VGze3YTifpc7JzagzaNvPPkL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1806; x-ms-traffictypediagnostic: VI1PR0801MB1806: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1806; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1806; x-forefront-prvs: 067553F396 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39380400002)(396003)(366004)(39860400002)(40434004)(199004)(189003)(97736004)(55016002)(6246003)(11346002)(446003)(7110500001)(10710500007)(86362001)(236005)(53936002)(2906002)(3660700001)(105586002)(110136005)(3280700002)(186003)(7736002)(5660300001)(68736007)(476003)(39060400002)(486006)(229853002)(25786009)(6436002)(15650500001)(6306002)(5250100002)(2420400007)(54896002)(9686003)(5890100001)(2501003)(2900100001)(76176011)(7696005)(59450400001)(74316002)(6506007)(53546011)(26005)(99286004)(606006)(72206003)(33656002)(966005)(14454004)(9326002)(790700001)(6116002)(3846002)(106356001)(478600001)(66066001)(8936002)(81156014)(316002)(81166006)(8676002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1806; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fFuYhwk15VfDu1M56u6rtg6e4cQWB9Qoj0qEU+4YIyNbVQphKQszdgA6q/ew+O3GBzyDDsd8RBEYzfhvDolAFTljrm6OAdxb1plFfBft0gUG+cKr/2DWtIGjQdk3isQxg1bc6Hlmzf+ue7kzhu+aO3LQcfK2ta9T3HUbWNYlb0QNOZWTC6O+Ev+bzbB62hR3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112A6F8B47939F8748DEA43FA910VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 346255f0-df21-4472-c63a-08d5bc128076 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 346255f0-df21-4472-c63a-08d5bc128076 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2018 16:23:19.2556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1806 Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 16:23:26 -0000 --_000_VI1PR0801MB2112A6F8B47939F8748DEA43FA910VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJvY2ssDQoNCnRoZXJlIGhhdmUgYmVlbiBzZXZlcmFsIGF0dGVtcHRzIHRvIHN0YXJ0IHdy aXRpbmcgc29tZSBndWlkYW5jZSBidXQgc28gZmFyIHdlIGhhdmVu4oCZdCBnb3R0ZW4gdG9vIGZh ci4NCklNSE8gaXQgd291bGQgYmUgZ3JlYXQgdG8gaGF2ZSBhIGRvY3VtZW50Lg0KDQpDaWFvDQpI YW5uZXMNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQnJvY2sgQWxsZW4NClNlbnQ6IDE3IE1heSAyMDE4IDE0OjU3DQpUbzogb2F1dGhA aWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gaXMgdXBkYXRlZCBndWlkYW5jZSBuZWVkZWQg Zm9yIEpTL1NQQSBhcHBzPw0KDQpNdWNoIGxpa2UgdXBkYXRlZCBndWlkYW5jZSB3YXMgcHJvdmlk ZWQgd2l0aCB0aGUgIk9BdXRoMiBmb3IgbmF0aXZlIGFwcHMiIFJGQywgc2hvdWxkIHRoZXJlIGJl IG9uZSBmb3IgImJyb3dzZXItYmFzZWQgY2xpZW50LXNpZGUgSlMgYXBwcyI/IEkgYXNrIGJlY2F1 c2UgZ29vZ2xlIGlzIGFjdGl2ZWx5IGRpc2NvdXJhZ2luZyB0aGUgdXNlIG9mIGltcGxpY2l0IGZs b3c6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuaWQvQXBwQXV0aC1KUy9pc3N1ZXMvNTkjaXNz dWVjb21tZW50LTM4OTYzOTI5MA0KDQpGcm9tIHdoYXQgSSBjYW4gdGVsbCwgdGhlIGNvbXBsYWlu dHMgd2l0aCBpbXBsaWNpdCBhcmU6DQoqIGFjY2VzcyB0b2tlbiBpbiBVUkwNCiogYWNjZXNzIHRv a2VuIGluIGJyb3dzZXIgaGlzdG9yeQ0KKiBpZnJhbWUgY29tcGxleGl0eSB3aGVuIHVzaW5nIHBy b21wdD1ub25lIHRvICJyZWZyZXNoIiBhY2Nlc3MgdG9rZW5zDQoNCkJ1dCB0aGlzIHJlcXVpcmVz Og0KKiBBUy9PUCB0byBzdXBwb3J0IFBLQ0UNCiogQVMvT1AgdG8gc3VwcG9ydCBDT1JTDQoqIHVz ZXItYWdlbnQgbXVzdCBzdXBwb3J0IENPUlMNCiogQVMvT1AgdG8gbWFpbnRhaW4gc2hvcnQtbGl2 ZWQgcmVmcmVzaCB0b2tlbnMNCiogQVMvT1AgbXVzdCBhZ2dyZXNzaXZlbHkgcmV2b2tlIHJlZnJl c2ggdG9rZW5zIGF0IHVzZXIgc2lnbm91dCAod2hpY2ggaXMgbm90IHNvbWV0aGluZyBPQXV0aDIg Imtub3dzIiBhYm91dCkNCiogaWYgdGhlIGFib3ZlIHBvaW50IGNhbid0IHdvcmssIHRoZW4gY2xp ZW50IG11c3QgcHJvYWN0aXZlbHkgdXNlIHJldm9jYXRpb24gZW5kcG9pbnQgaWYvd2hlbiB1c2Vy IHRyaWdnZXJzIGxvZ291dA0KDQpBbnkgdXNlIGluIGRpc2N1c3NpbmcgdGhpcz8NCg0KLUJyb2Nr DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB2112A6F8B47939F8748DEA43FA910VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29sZSI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNCA1IDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBCcm9jaywNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+dGhlcmUgaGF2ZSBiZWVuIHNldmVyYWwgYXR0ZW1wdHMgdG8gc3RhcnQgd3JpdGlu ZyBzb21lIGd1aWRhbmNlIGJ1dCBzbyBmYXIgd2UgaGF2ZW7igJl0IGdvdHRlbiB0b28gZmFyLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklNSE8gaXQgd291bGQgYmUgZ3JlYXQgdG8g aGF2ZSBhIGRvY3VtZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaWFvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyb2NrIEFsbGVuPGJyPg0KPGI+U2VudDo8L2I+ IDE3IE1heSAyMDE4IDE0OjU3PGJyPg0KPGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIGlzIHVwZGF0ZWQgZ3VpZGFuY2UgbmVlZGVkIGZvciBK Uy9TUEEgYXBwcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9Il9fTWFpbGJpcmRTdHlsZUNvbnRlbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPk11Y2ggbGlrZSB1 cGRhdGVkIGd1aWRhbmNlIHdhcyBwcm92aWRlZCB3aXRoIHRoZSAmcXVvdDtPQXV0aDIgZm9yIG5h dGl2ZSBhcHBzJnF1b3Q7IFJGQywgc2hvdWxkIHRoZXJlIGJlIG9uZSBmb3IgJnF1b3Q7YnJvd3Nl ci1iYXNlZCBjbGllbnQtc2lkZSBKUyBhcHBzJnF1b3Q7PyBJIGFzayBiZWNhdXNlIGdvb2dsZSBp cw0KIGFjdGl2ZWx5IGRpc2NvdXJhZ2luZyB0aGUgdXNlIG9mIGltcGxpY2l0IGZsb3c6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL29wZW5pZC9BcHBBdXRoLUpTL2lzc3Vlcy81OSNpc3N1ZWNvbW1l bnQtMzg5NjM5MjkwIj5odHRwczovL2dpdGh1Yi5jb20vb3BlbmlkL0FwcEF1dGgtSlMvaXNzdWVz LzU5I2lzc3VlY29tbWVudC0zODk2MzkyOTA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tIHdoYXQgSSBjYW4gdGVsbCwg dGhlIGNvbXBsYWludHMgd2l0aCBpbXBsaWNpdCBhcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6Ymxh Y2siPiogYWNjZXNzIHRva2VuIGluIFVSTDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj4qIGFj Y2VzcyB0b2tlbiBpbiBicm93c2VyIGhpc3Rvcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+ KiBpZnJhbWUgY29tcGxleGl0eSB3aGVuIHVzaW5nIHByb21wdD1ub25lIHRvICZxdW90O3JlZnJl c2gmcXVvdDsgYWNjZXNzIHRva2VuczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEg Q29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+QnV0IHRoaXMgcmVxdWlyZXM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVv dDs7Y29sb3I6YmxhY2siPiogQVMvT1AgdG8gc3VwcG9ydCBQS0NFPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29s b3I6YmxhY2siPiombmJzcDtBUy9PUCB0byBzdXBwb3J0Jm5ic3A7Q09SUyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xl JnF1b3Q7O2NvbG9yOmJsYWNrIj4qIHVzZXItYWdlbnQgbXVzdCBzdXBwb3J0IENPUlM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29s ZSZxdW90Oztjb2xvcjpibGFjayI+KiBBUy9PUCB0byBtYWludGFpbiBzaG9ydC1saXZlZCByZWZy ZXNoIHRva2VucyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj4qIEFTL09QIG11c3Qg YWdncmVzc2l2ZWx5IHJldm9rZSByZWZyZXNoIHRva2VucyBhdCB1c2VyIHNpZ25vdXQgKHdoaWNo IGlzIG5vdCBzb21ldGhpbmcgT0F1dGgyICZxdW90O2tub3dzJnF1b3Q7IGFib3V0KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xl JnF1b3Q7O2NvbG9yOmJsYWNrIj4qIGlmIHRoZSBhYm92ZSBwb2ludCBjYW4ndCB3b3JrLCB0aGVu IGNsaWVudCBtdXN0IHByb2FjdGl2ZWx5IHVzZSByZXZvY2F0aW9uIGVuZHBvaW50IGlmL3doZW4g dXNlciB0cmlnZ2VycyBsb2dvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENv bnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPkFueSB1c2UgaW4gZGlzY3Vzc2luZyB0aGlzPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNp ZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6 YmxhY2siPi1Ccm9jazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtM dWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB2112A6F8B47939F8748DEA43FA910VI1PR0801MB2112_-- From nobody Thu May 17 11:07: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 58BC112D95E for ; Thu, 17 May 2018 11:07:25 -0700 (PDT) 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=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 k_2V5qLIAbJW for ; Thu, 17 May 2018 11:07:21 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 3033D12D95C for ; Thu, 17 May 2018 11:07:21 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id p124-v6so3097765iod.1 for ; Thu, 17 May 2018 11:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EHjUQ2xOU2tTXM6xEgIToJJFP+Gon0o7n2yWKcHdBoc=; b=lbsyWNSUxvjjnSuymXWc6u3FvQab6GhUnF6sk643XMvqahdsHKJDbY9XzK9p9S7urS nq4LFe0fE0VLDs8aEfuxPaO9Y5zkH78rHKsHW2lZB12HjjxM9yEjl5AT21mCWEd+zwAv zC39dlLlxkzBQynC9pHeFi5qTphViwRT8Zbec= 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=EHjUQ2xOU2tTXM6xEgIToJJFP+Gon0o7n2yWKcHdBoc=; b=lrwdR3w8CANRGtZvGDfysiU/kldBbty2Cq0kCaMCsvr3lynjQHpUPrEDoDFF4tTpp1 +vJTfpM/DvDDjKeUgexVqeMgug6QPDllq2qbWVTmOfWnb/5o46qA7QilEt5e/oHiNf6Q A4CqJIydQ9dvBbKIzKbBLs/ag95RgtZBf9JCZx56h1q7/9w/XoeOdrTMFPDNK3p++DYb W4btwc3JJbNizi5a66rsbwZIrliSRAJfEPmqKXKXbyZk6hvhB+Ez7k0hPFHpjtWTfiIt G462exIVga8UQ0uMGJSpNgEoaAejuBY38RcLodINZFxtdrHZuQxSpEoRUKZny5H5BHLb WmsQ== X-Gm-Message-State: ALKqPwdo4mUzl90ZtjEd+6qfkFwWtNlSV1VMEzXmFsLe+aL4sxF45Hie 9rPSC6skVa1Pxqb2VTiA/W6FcnV639D0r1f4VuQHFB4btXPeWaaiD+fiGzg8CFsjulBmKO5PieP W4XbE72jAbmqaiQ== X-Google-Smtp-Source: AB8JxZp/3pFbTeAe/+8swrCFooAyqgxccKEoU9tUGTGfflaMR41haIil/rHj9cqZt9WejRSQGTptTd6NUbRGXnzGTRY= X-Received: by 2002:a6b:1456:: with SMTP id 83-v6mr6697326iou.218.1526580440221; Thu, 17 May 2018 11:07:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 17 May 2018 11:06:49 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 17 May 2018 12:06:49 -0600 Message-ID: To: Bill Burke , Eric Rescorla Cc: Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000dc6523056c6ab426" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 18:07:26 -0000 --000000000000dc6523056c6ab426 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Delegation has been in the document since its inception and throughout the three and a half years as a working group document. >From a process point of view, the document is now in AD Evaluation. I worked through a number of questions and clarifications with Eric (said AD), however he raised the particular questions that started this thread on the WG list. And I responded with an attempt at addressing those questions. That was about a month ago. Eric, was my explanation helpful in clarify anything for you? Is there some text that you'd like to see added? Something else? I'm unsure how to proceed but would like to move things forward. On Thu, May 17, 2018 at 8:03 AM, Bill Burke wrote: > This is an honest question: How important is the actor stuff to the > players involved? Are people going to use it? IMO, its an edge case > and I think more important areas, like external token exchange (realm > to realm, domain to domain) are being neglected. I'm quite unfamiliar > how consensus is reached in this WG or the IETF, so I hope I'm not > sounding rude. Just trying to provide some constructive feedback. > > > > On Thu, May 17, 2018 at 9:26 AM, Mike Jones > wrote: > > Moving the actor claim to a separate specification would only make > things more complicated for developers. There already plenty of OAuth > specs. Needlessly adding another one will only make related things harde= r > to find. > > > > Just like in the JWT [RFC 7519] spec itself in which use of all the > claims is optional, use of the actor claim in this spec. If you don't ne= ed > it, don't use it. Just because some won't use it is no better an argumen= t > for moving it to a different spec than the argument that JWT should have > defined each of its claims in different specs. That would have made thin= gs > harder, not easier. > > > > -- Mike > > > > -----Original Message----- > > From: OAuth On Behalf Of Bill Burke > > Sent: Thursday, May 17, 2018 2:11 PM > > To: Brian Campbell > > Cc: oauth > > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang > e-12.txt > > > > My personal opinion is that I'm glad this actor stuff is optional. > > For one, none of our users have asked for it and really only do simple > exchanges. Secondly, the rules for who can exchange what for what is > controlled and defined within our AS. Makes things a lot simpler on the > client. I kind of wish the actor stuff would be defined in a separate > specification. I don't see us implementing it unless users start asking = us > to. > > > > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Well, it's already called the "actor claim" so the claimed part is > >> kind of implied. And "claimed actor claim" is a rather awkward. > >> Really, all JWT claims are "claimed something" but they don't include > >> the "claimed" bit in the name. RFC 7519, for example, defines the > >> subject claim but not the claimed subject claim. > >> > >> On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: > >>> > >>> Brian, > >>> > >>> Eric said: "what is the RP supposed to do when they encounter it? > >>> This seems kind of under specified". > >>> > >>> After reading your explanations below, it looks like the RP can do > >>> anything he wants with the "actor". > >>> It is a "claimed actor" and, if we keep the concept, it should be > >>> called as such. Such a claim cannot be verified. > >>> A RP could copy and paste that claim in an audit log. No standard > >>> action related to the content of such a claim can be specified in the > >>> spec. If the content of a "claimed actor" is used by the RP, it > >>> should be only used as an hint and thus be subject to other > >>> verifications which are not specified in this specification. > >>> > >>> Denis > >>> > >>> Eric, I realize you weren't particularly impressed by my prior > >>> statements about the actor claim but, for lack of knowing what else > >>> to say, I'm going to kind of repeat what I said about it over in the > >>> Phabricator tool and add a little color. > >>> > >>> The actor claim is intended as a way to express that delegation has > >>> happened and identify the entities involved. Access control or other > >>> decisions based on it are at the discretion of the consumer of the > >>> token based on whatever policy might be in place. > >>> > >>> There are JWT claims that have concise processing rules with respect > >>> to whether or not the JWT can be accepted as valid. Some examples are > "aud" > >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC > 7519. > >>> E.g. if the token is expired or was intended for someone or something > >>> else, reject it. > >>> > >>> And there are JWT claims that appropriately don't specify such > >>> processing rules and are solely statements of fact or circumstance. > >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims > are good examples of such. > >>> There might be application or policy specific rules applied to the > >>> content of those kinds of claims (e.g. only subjects from a > >>> particular organization are able to access tenant specific data or, > >>> less realistic but still possible, disallow access for tokens issued > >>> outside of regular business > >>> hours) but that's all outside the scope of a specification's > >>> definition of the claim. > >>> > >>> The actor claim falls into the latter category. It's a way for the > >>> issuer of the token to tell the consumer of the token what is going > >>> on. But any action to take (or not) based on that information is at > >>> the discretion of the token consumer. I honestly don't know it could > >>> be anything more. And don't think it should be. > >>> > >>> There are two main expected uses of the actor claim (that I'm aware > >>> of > >>> anyway) that describing here might help. Maybe. One is a human to > >>> human delegation case like a customer service rep doing something on > >>> behalf of an end user. The subject would be that user and the actor > >>> would be the customer service rep. And there wouldn't be any chaining > >>> or nesting of the actor. The other case is so called service chaining > >>> where a system might exchange a token it receives for a new token > >>> that it can use to call a downstream service. And that service in > >>> turn might do another exchange to get a new token suitable to call > >>> yet another downstream service. And again and so on and turtles all > >>> the way. I'm not necessarily endorsing that level of granularity in > >>> chaining but it's bound to happen somewhere/sometime. The nested > >>> actor claim is able to express that all that has happened with the > >>> top level or outermost one being the system currently using the token > >>> and prior systems being nested.. What actually gets done with that > >>> information is up to the respective systems involved. There might be > >>> policy about what system is allowed to call what other system that is > >>> enforced. Or maybe the info is just written to an audit log > >>> somewhere. Or something else. I don't know. But whatever it is > application/deployment/policy dependent and not specifiable by a spec. > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: > >>>> > >>>> Hi folks, > >>>> > >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem > >>>> generally OK. I do still have one remaining concern, which is about > >>>> the actor claim. Specifically, what is the RP supposed to do when > >>>> they encounter it? This seems kind of underspecified. > >>>> > >>>> In particular: > >>>> > >>>> 1. What facts am I supposed to know here? Merely that everyone in > >>>> the chain signed off on the next person in the chain acting as > them? > >>>> > >>>> 2. Am I just supposed to pretend that the person presenting the toke= n > >>>> is the identity at the top of the chain? Say I have the > >>>> delegation A -> B -> C, and there is some resource which > >>>> B can access but A and C cannot, should I give access? > >>>> > >>>> I think the first question definitely needs an answer. The second > >>>> question I guess we could make not answer, but it's pretty hard to > >>>> know how to make a system with this left open.. > >>>> > >>>> -Ekr > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > > > -- > > Bill Burke > > Red Hat > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Bill Burke > Red Hat > --=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._ --000000000000dc6523056c6ab426 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Delegation has been in the document since its incepti= on and throughout the three and a half years as a working group document. <= br>

From a process point of view, the document is = now in=C2=A0AD Evaluation. I worked through a number of questions and clari= fications with Eric (said AD), however he raised the particular questions t= hat started this thread on the WG list. And I responded with an attempt at = addressing those questions. That was about a month ago.

=
Eric, was my explanation helpful in clarify anything for you? Is= there some text that you'd like to see added? Something else? I'm = unsure how to proceed but would like to move things forward.

<= div class=3D"gmail_extra">
On Thu, May 17, 20= 18 at 8:03 AM, Bill Burke <bburke@redhat.com> wrote:
This is an honest question: How important is the= actor stuff to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> prohibited..=C2=A0 If you have received this communication in = error,
>>> please notify the sender immediately by e-mail and delete the = message
>>> and any file attachments from your computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s).= Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..=C2=A0 If you have received this communication in erro= r, please
>> notify the sender immediately by e-mail and delete the message and= any
>> file attachments from your computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


<= 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. --000000000000dc6523056c6ab426-- From nobody Thu May 17 11:47: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 428F8126CF6 for ; Thu, 17 May 2018 11:47:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 XFYDzoS1UiXq for ; Thu, 17 May 2018 11:47:18 -0700 (PDT) Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EC012EB8A for ; Thu, 17 May 2018 11:47:17 -0700 (PDT) Received: by mail-ua0-f173.google.com with SMTP id y8-v6so3678177ual.5 for ; Thu, 17 May 2018 11:47:17 -0700 (PDT) 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=rFFcwQI4e978M7AAw0NSEZUCJGdtS4u1kEyasK9YtDc=; b=nuwV0GOWzORErfdede7OCMvtS+6nNPR7+fSYUdH6hSpQ3tVvKCn/ZqK1B0q3Smg3Pd /urAu+FPO6IDs2APSR/tZ4HPz8SW+ydFgSGUKt/GDcUFUUr6HLkVwSgjd23ocp2r81UM Bnu+exoEWj7fbZ+z784RmW3StN8z8DQ7NZwfuOV+JwLEXd+XOUK4+IfLtX/gb+CyYawo WCZUwrtWHCTA3rU1cMrMPnWlBZs8tAHkJnhfNMXgctHCPtSdruMFhBNlR8jgoiFfXH7A 46TAZM1Xui5Abb9ZJH05cexWjRR2QdgFhUfzH66b0TieK4UvAYo6KKcfcjQN6hjhfAp3 aJJQ== X-Gm-Message-State: ALKqPwfQ5ARFFwEFOH2jepOk4RktpvmuKEV2MQgRWGsmyJifyFrFRAqb TTp7k+e3xsim57WfuXxR+BMscKmexVvmXvd26njTsg== X-Google-Smtp-Source: AB8JxZoQUb0ni3Z5oMTT9scqMW4pDylWymTrT+QldAGzgQ8/X3ai6s/CGhPkSkcXMP5TiGmrbK8lJm266QWZ7A5rR1Q= X-Received: by 2002:a9f:3c9d:: with SMTP id s29-v6mr5241151uai.64.1526582836800; Thu, 17 May 2018 11:47:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.192.11 with HTTP; Thu, 17 May 2018 11:47:16 -0700 (PDT) In-Reply-To: References: From: Bill Burke Date: Thu, 17 May 2018 14:47:16 -0400 Message-ID: To: Brian Campbell Cc: Eric Rescorla , Mike Jones , oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 18:47:21 -0000 On Thu, May 17, 2018 at 2:06 PM, Brian Campbell wrote: > Delegation has been in the document since its inception and throughout the > three and a half years as a working group document. > No worries! All good. And apologies. From nobody Thu May 17 13:51: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 6CB2F126BF3 for ; Thu, 17 May 2018 13:51:33 -0700 (PDT) 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=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 3P74rjWQIYTz for ; Thu, 17 May 2018 13:51:31 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 9A7371272E1 for ; Thu, 17 May 2018 13:51:31 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 144-v6so10522711iti.5 for ; Thu, 17 May 2018 13:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rC8Iwzt3UtMvUvTwRf1brAbnmiCrSn0bkABPyeEnAhA=; b=gSKOUovd+RVQ5sE9vesgwZm2/fSEg9lyac56zycemm0DxxkehVcuR/idOdwApffMew Y6uffWT0MzhhtAe8AyT1rfY9scSWePYriFIsFJyrJTU3bU/895rf+np4lxcOB0U8Vgpe RdXS/9s0x01XsJD18UG3G1r5khg9LLgdVSsZ0= 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=rC8Iwzt3UtMvUvTwRf1brAbnmiCrSn0bkABPyeEnAhA=; b=k5s2eQktsAkygdWceeocMexK8LVX551yJH4Bf18WgOs9i1pYm9LcV4qOyY9te2Dtfv I23AMj914C6TX5T1CCxHztGYBeRcQIEtVBgzBA5k/e5KXYdT1+sgdDq26yBjz9uo3NaV G11F1yJrAEm5i6bccTr3Cr4eK4oQkqmslyhIgBHA8OKYBvJwUWchKavBniFA1yKldm3u EY/8glWTL2qoBTpdjHlpLhk42/ylTRxaFYdNJPX6Kadq5dQrJ2V85jf1UzbUr7jhmrNr 09s6xL9BDz3QoM9HQxcuKSuPVwxwBaUb4/G++o4jXzS1pyfd44FsJ9rV2FWpkCXHXbQ/ C9bw== X-Gm-Message-State: ALKqPwfKGjl7kG96tC7DSbfeJ3dFkyBSpYg0bPDyeVDnXODpHUdrtzwW 0BKy4yUDbUrdPObpWdekk4VzGy9tecjAi4aZaqbzFwNHiM+m/0Xf8+DZ9EIpaBuQFeOlmDsA20Q PAsDwZDs9o5nmdg== X-Google-Smtp-Source: AB8JxZqSjuUw7CgLBy8J03FkVgear89OLuGAnPH7jCkxpyrbzu/a8RREeUH1nrkw0wQVbozalzoBBTPcq1R531k56Uo= X-Received: by 2002:a24:38b:: with SMTP id e133-v6mr4462606ite.76.1526590290615; Thu, 17 May 2018 13:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 17 May 2018 13:50:59 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 17 May 2018 14:50:59 -0600 Message-ID: To: Bill Burke Cc: Eric Rescorla , Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000fd81b6056c6cffa1" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 20:51:34 -0000 --000000000000fd81b6056c6cffa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No apologies needed. Gauging consensus isn't straightforward (to me anyway) but the long history there seemed relevant. On Thu, May 17, 2018 at 12:47 PM, Bill Burke wrote: > On Thu, May 17, 2018 at 2:06 PM, Brian Campbell > wrote: > > Delegation has been in the document since its inception and throughout > the > > three and a half years as a working group document. > > > > No worries! All good. And apologies. > --=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._ --000000000000fd81b6056c6cffa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No apologies needed. Gauging consensus isn't stra= ightforward (to me anyway) but the long history there seemed relevant.
=



On Thu, May 17, 2018 at 12:47 PM, Bill Burke <bbu= rke@redhat.com> wrote:
On Thu, May 17, 2018 at 2:06 PM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> Delegation has been in the document since its inception and throughout= the
> three and a half years as a working group document.
>

No worries!=C2=A0 All good.=C2=A0 And apologies.


<= 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. --000000000000fd81b6056c6cffa1-- From nobody Fri May 18 03:04: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 DB0DE129C6C for ; Fri, 18 May 2018 03:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-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 V_gZWd7E9Gcf for ; Fri, 18 May 2018 03:04:47 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 1720C127873 for ; Fri, 18 May 2018 03:04:46 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:89f1:9f32:cd33:f67c] (unknown [IPv6:2601:282:202:b210:89f1:9f32:cd33:f67c]) by alkaline-solutions.com (Postfix) with ESMTPSA id CF1A831544; Fri, 18 May 2018 10:04:45 +0000 (UTC) From: David Waite Message-Id: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_701D3F8F-1A06-4744-AD29-4A826590726A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 18 May 2018 04:04:44 -0600 In-Reply-To: Cc: Brock Allen , "oauth@ietf.org" To: Hannes Tschofenig References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 10:04:50 -0000 --Apple-Mail=_701D3F8F-1A06-4744-AD29-4A826590726A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have written some guidance already (in non-RFC format) on preferring = code for single page apps, and other security practices (CORS, CSP). = =46rom the AS point of view, it aligns well with the native apps BCP. = There are benefits of thinking about native and SPA apps just as = =E2=80=98public clients=E2=80=99 from a policy/properties point of view. = It also greatly simplifies OAuth/OIDC support on both the AS = administrator and client developer side when converting web properties = into native apps using technologies like Electron or Cordova. For the later requirements in the list around token policy, I am not = sure these are requirements for single page apps per se. I don=E2=80=99t = believe the need for a policy using short-lived refresh tokens, revoking = at signout, or use of the revocation endpoint are different from browser = and native applications. Rather they seem to be a function of usage = patterns that an AS may need to support, and we happen to sometimes = associate those usage patterns with typical usage of native apps vs of = browser apps. For example, browser login on a borrowed device can easily = leak over to being app authorization - the authentication/authorization = are web-based processes to achieve SSO. I have been working on some guidance here around token lifetimes and = policies, but I don=E2=80=99t know whether that brings in too much AS/OP = business logic (and, likely implied product/deployment features) to be = industry practices. -DW > On May 17, 2018, at 10:23 AM, Hannes Tschofenig = wrote: >=20 > Hi Brock, > =20 > there have been several attempts to start writing some guidance but so = far we haven=E2=80=99t gotten too far. > IMHO it would be great to have a document. > =20 > Ciao > Hannes > =20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Brock Allen > Sent: 17 May 2018 14:57 > To: oauth@ietf.org > Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > =20 > Much like updated guidance was provided with the "OAuth2 for native = apps" RFC, should there be one for "browser-based client-side JS apps"? = I ask because google is actively discouraging the use of implicit flow: > =20 > https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 = > =20 > =46rom what I can tell, the complaints with implicit are: > * access token in URL > * access token in browser history > * iframe complexity when using prompt=3Dnone to "refresh" access = tokens > =20 > But this requires: > * AS/OP to support PKCE > * AS/OP to support CORS=20 > * user-agent must support CORS > * AS/OP to maintain short-lived refresh tokens=20 > * AS/OP must aggressively revoke refresh tokens at user signout (which = is not something OAuth2 "knows" about) > * if the above point can't work, then client must proactively use = revocation endpoint if/when user triggers logout > =20 > Any use in discussing this? > =20 > -Brock > =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=_701D3F8F-1A06-4744-AD29-4A826590726A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have written some guidance already (in non-RFC format) on = preferring code for single page apps, and other security practices = (CORS, CSP). =46rom the AS point of view, it aligns well with the native = apps BCP. There are benefits of thinking about native and SPA apps just = as =E2=80=98public clients=E2=80=99 from a policy/properties point of = view. It also greatly simplifies OAuth/OIDC support on both the AS = administrator and client developer side when converting web properties = into native apps using technologies like Electron or Cordova.

For the later requirements in the list around token policy, I = am not sure these are requirements for single page apps per se. I = don=E2=80=99t believe the need for a policy using short-lived refresh = tokens, revoking at signout, or use of the revocation endpoint are = different from browser and native applications. Rather they seem to be a = function of usage patterns that an AS may need to support, and we happen = to sometimes associate those usage patterns with typical usage of native = apps vs of browser apps. For example, browser login on a borrowed device = can easily leak over to being app authorization - the = authentication/authorization are web-based processes to achieve = SSO.

I have = been working on some guidance here around token lifetimes and policies, = but I don=E2=80=99t know whether that brings in too much AS/OP business = logic (and, likely implied product/deployment features) to be industry = practices.

-DW

On May 17, 2018, at 10:23 AM, = Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Brock,
 
there have been several = attempts to start writing some guidance but so far we haven=E2=80=99t = gotten too far.
IMHO it would be great to have a document.
 
Ciao
Hannes
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org
Subject: [OAUTH-WG] is updated = guidance needed for JS/SPA apps?
 
Much like updated guidance was provided with the "OAuth2 for = native apps" RFC, should there be one for "browser-based client-side JS = apps"? I ask because google is actively discouraging the use of implicit = flow:
 
https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389= 639290
 
=46rom what I = can tell, the complaints with implicit are:
* access token in = URL
* access = token in browser history
* iframe complexity when using prompt=3Dnone to "refresh" = access tokens
 
But this = requires:
* AS/OP to = support PKCE
* AS/OP = to support CORS 
* user-agent must support CORS
* AS/OP to maintain = short-lived refresh tokens 
* AS/OP must = aggressively revoke refresh tokens at user signout (which is not = something OAuth2 "knows" about)
* if the above = point can't work, then client must proactively use revocation endpoint = if/when user triggers logout
 
Any use in discussing this?
 
-Brock
 
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=_701D3F8F-1A06-4744-AD29-4A826590726A-- From nobody Fri May 18 05:46: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 81C4412D887 for ; Fri, 18 May 2018 05:46:28 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 C9ukVJ-h3NNZ for ; Fri, 18 May 2018 05:46:25 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 55F3A12D88B for ; Fri, 18 May 2018 05:46:24 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v132-v6so2354004ywc.6 for ; Fri, 18 May 2018 05:46:24 -0700 (PDT) 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=y5noYjXnaXJqUdiK2/xhULkq7W3BRDCIH2YIVDMRFao=; b=NJAxwIIuJuMqTfTxEKP27faRhn7fxP4YCDIxcKd1IDrpybxkQxgu7iXT0INhU9fCs7 PhMGbQTaheqenGzcGjzdanoKEd6hrp7m4xwd5aptNC3IfCL0CDYYCPIoQsybR4noDIPW y1DEN6ddhUfiCFBDWg1v1u1toTy9Rc8AFfn1YGiNJcI3w8yWBrotKbK2MQtTMeodPuwT TbHgKRnUpY2M3UtF1i/NVaXa2JlqL9tUMG5/29W3upsVLgJOFuXDzDAe9eI0+zIuqL/Q Ovr+xBefiPeGa/adWgWO8DIYTu3NVSfaP86Ugh3OFQguim5QxHjWgnwXhSTRHYJrx8xh 6r4Q== 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=y5noYjXnaXJqUdiK2/xhULkq7W3BRDCIH2YIVDMRFao=; b=iWd5ZFEVnsRMHhkRy1jAFhCnR+0NinFAZrjyNIx6aDgvZ9FZ/KxS0Rwfegqq5+wJBF hteXbAIQp7peuJeM/UVo970JtAOCTZNI6V7dvdo3FCp9IeB+nUVU4fYDWInpEwbM3zKF 0TM39OaJA+GMEymU5WKcCzcfMhZw9OJiHd6/Qga6tRt8UEV5GmkMW/fMulNihSphXTyT laL4BWVIhDSFePBagr7JHwZOFrKq5Xr8q66kgt1ZnxBmB8L/T7qxcpezD4yXYi4IDG3x CkVb5VqvQfH09KrMzJHShspdnuJYU4qyvKcvospE7ThppgJhpdysPcvJ/Vf8vB2I8jTh whuQ== X-Gm-Message-State: ALKqPwdfrdnnkVHXvcI3IyPhxkglayNKIr2JXwFZnZ5gDlKI6mI3CGBA tJsKKS+/eZsyIPzzdaM35zM= X-Google-Smtp-Source: AB8JxZq/E96cPprFFbUuzEtFyy81ABPrKHgw9RBoW69WNVIRmeBQivhIQnfC1RR/EyoVJXQ3LArEdg== X-Received: by 2002:a0d:f3c7:: with SMTP id c190-v6mr4480473ywf.353.1526647583279; Fri, 18 May 2018 05:46:23 -0700 (PDT) Received: from [172.20.10.3] ([172.58.153.135]) by smtp.gmail.com with ESMTPSA id 205-v6sm2950527ywv.79.2018.05.18.05.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 05:46:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_16116096.568679140624" MIME-Version: 1.0 Date: Fri, 18 May 2018 08:46:14 -0400 Message-ID: <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> From: "Brock Allen" To: "David Waite" , "Hannes Tschofenig" Cc: "" In-Reply-To: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> User-Agent: Mailbird/2.5.8.0 X-Mailbird-ID: 895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 12:46:28 -0000 ------=_NextPart_16116096.568679140624 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow. What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit= of protection for the end user built into that design by virtue of being t= ied to the user's cookie at the AS/OP. Just throwing that out as an additional discussion point. -Brock On 5/18/2018 6:04:47 AM, David Waite wrote: I have written some guidance already (in non-RFC format)=C2=A0on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =E2=80=98public client= s=E2=80=99 from a policy/properties point of view. It also greatly simplifi= es OAuth/OIDC support on both the AS administrator and client developer sid= e when converting web properties into native apps using technologies like E= lectron or Cordova. For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe = the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS= may need to support, and we happen to sometimes associate those usage patt= erns with typical usage of native apps vs of browser apps. For example, bro= wser login on a borrowed device can easily leak over to being app authoriza= tion - the authentication/authorization are web-based processes to achieve = SSO. I have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry pra= ctices. -DW On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: Hi Brock, =C2=A0 there have been several attempts to start writing some guidance but so far = we haven=E2=80=99t gotten too far. IMHO it would be great to have a document. =C2=A0 Ciao Hannes =C2=A0 From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.= org]]=C2=A0On Behalf Of=C2=A0Brock Allen Sent:=C2=A017 May 2018 14:57 To:=C2=A0oauth@ietf.org [mailto:oauth@ietf.org] Subject:=C2=A0[OAUTH-WG] is updated guidance needed for JS/SPA apps? =C2=A0 Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: =C2=A0 https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 [http= s://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290] =C2=A0 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens =C2=A0 But this requires: * AS/OP to support PKCE *=C2=A0AS/OP to support=C2=A0CORS=C2=A0 * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens=C2=A0 * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout =C2=A0 Any use in discussing this? =C2=A0 -Brock =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.=C2=A0_______________________________________________ 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] ------=_NextPart_16116096.568679140624 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A One thing= I maybe should have listed in the pros/cons in my original email is sessio= n management and token lifetime considerations, keeping in mind the origina= l intent of the implicit flow.

What I mean is that with = implicit grant type, the client's ability to get new access tokens is limit= ed to the user's session at the AS/OP. Obviously other flows make more sens= e to obtain longer lived access (via refresh tokens), but I don't know abou= t a browser-based JS app. In a sense there's a bit of protection for the en= d user built into that design by virtue of being tied to the user's cookie = at the AS/OP.

Just throwing that out as an additional di= scussion point.

-Brock

=0A =

On 5/18/2= 018 6:04:47 AM, David Waite <david@alkaline-solutions.com> wrote:

= I have written some guidance already (in non-RFC format) on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =E2=80=98public client= s=E2=80=99 from a policy/properties point of view. It also greatly simplifi= es OAuth/OIDC support on both the AS administrator and client developer sid= e when converting web properties into native apps using technologies like E= lectron or Cordova.

For the later requirements in the list around = token policy, I am not sure these are requirements for single page apps per= se. I don=E2=80=99t believe the need for a policy using short-lived refres= h tokens, revoking at signout, or use of the revocation endpoint are differ= ent from browser and native applications. Rather they seem to be a function= of usage patterns that an AS may need to support, and we happen to sometim= es associate those usage patterns with typical usage of native apps vs of b= rowser apps. For example, browser login on a borrowed device can easily lea= k over to being app authorization - the authentication/authorization are we= b-based processes to achieve SSO.

I have been working on some guidance here around token lif= etimes and policies, but I don=E2=80=99t know whether that brings in too mu= ch AS/OP business logic (and, likely implied product/deployment features) t= o be industry practices.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofe= nig <Hannes.Tsch= ofenig@arm.com> wrote:

=
Hi Brock,
 
there have been seve= ral attempts to start writing some guidance but so far we haven=E2=80=99t g= otten too far.
IMHO it would be great to have a doc= ument.
 
Ciao
Hannes
 =
From: OAuth [mailto:oauth-bounces@ie= tf.org] On Behalf Of Brock A= llen
Sent: 17 May 2018 14:57
To: oauth= @ietf.org
Subject: [OAUTH-WG] is updated guidance needed for JS/= SPA apps?
 
Much like upd= ated guidance was provided with the "OAuth2 for native apps" RFC, should th= ere be one for "browser-based client-side JS apps"? I ask because google is= actively discouraging the use of implicit flow:
 
https://github.com/openid/AppAuth-JS/issues/59= #issuecomment-389639290
&n= bsp;
From what I can tell, the complaints with implicit are:
* access token in URL
* access token in browser history
<= /div>
* ifra= me complexity when using prompt=3Dnone to "refresh" access tokens
 
But this requires:<= o:p class=3D"">
* AS/OP to support PKCE<= /span>
<= span style=3D"font-size: 10pt;font-family: "Lucida Console"" clas= s=3D"">* AS/OP to support CORS =
* user-agent must support CORS
* AS/OP to mai= ntain short-lived refresh tokens 
* AS/OP= must aggressively revoke refresh tokens at user signout (which is not some= thing OAuth2 "knows" about)
* if the above poi= nt can't work, then client must proactively use revocation endpoint if/when= user triggers logout
 
Any use in discussing this?
 
-Brock
 
IMPORTA= NT NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, please n= otify 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 med= ium. Thank you. ___________= ____________________________________
OAuth mailing li= st
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth

=0A =
=0A = =0A
------=_NextPart_16116096.568679140624-- From nobody Fri May 18 06:46: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 DD56112D95F for ; Fri, 18 May 2018 06:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-stuttgart.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 G-uh6Wrp0TdT for ; Fri, 18 May 2018 06:46:07 -0700 (PDT) Received: from mxex1.tik.uni-stuttgart.de (mxex1.tik.uni-stuttgart.de [IPv6:2001:7c0:2041:24::a:1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9146B12D7F8 for ; Fri, 18 May 2018 06:46:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxex1.tik.uni-stuttgart.de (Postfix) with ESMTP id C64DB7CD56 for ; Fri, 18 May 2018 15:46:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from :received:received; s=dkim; i=@sec.uni-stuttgart.de; t= 1526651163; x=1528389964; bh=TpslNmvx4lajsadwp3sJjOIYHOmOWqUNDEV G0ANJDB8=; b=J+KkwgV8lEBgATcnG5zMfZRyYd2g/xG2P7S0hjhA9rayrPpkmb9 vbhn1Du/GiM2Wlw4pJITgm+jt8AMWwLNPGhGbX2OYO7qztl41cbiTGDJ6fDNcu2k s9E19OFOxqhm+hSpkdtmvg+n/egeIRiXo9XjJgUwuFSnsIoqOZa06HvK47T74Luw 3KfaIlPb2bLEzMh4d9fDFWl6m3aZy9ObcbLIrRL27gVEcA/jX8hQq4RZsEOOtmTn 9WitqypyiaoAR8BCPklCcjNjo5bTacAUqVmkN3KIAILtUoLALTek/+BBIG5jdExD fbCjY0oHVZBaVI+nrOJ0IxSeey/yswJ/fTA== X-Virus-Scanned: USTUTT mailrelay AV services at mxex1.tik.uni-stuttgart.de Received: from mxex1.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex1.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id zBPyjyn4xDiV for ; Fri, 18 May 2018 15:46:03 +0200 (CEST) Received: from [IPv6:2001:7c0:2015:182::1:32] (unknown [IPv6:2001:7c0:2015:182::1:32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mxex1.tik.uni-stuttgart.de (Postfix) with ESMTPSA for ; Fri, 18 May 2018 15:46:02 +0200 (CEST) To: oauth@ietf.org From: Daniel Fett Openpgp: preference=signencrypt Autocrypt: addr=daniel.fett@sec.uni-stuttgart.de; prefer-encrypt=mutual; keydata= xsFNBFbu2RUBEAC3F5+IMjFcXSj46xS8QQe6d/FAb+7IkkOdFKrINhgCialH4enWB2V3ykOX xESdrchRBCLoePyNmoJdFTijGxBMGNqSKU9rrppF5uvPFv/qIvCaBDAjFXR+qshsHjsMxTNH 67kuhkFQczKQHs4KVICG/gnssC3iejrk6Mav0MIJKXXdz6bUQPDyUTD+LsyHJ7vNfkfitnO4 rbD+kEZ0n14dQqp+c91b7X5KZVTt1c3d/N1kbruS29SlIDUJSHV0AdDZmP6wuH5a9XUIlDkP mM2bncIry3xiXWolYf3BJigxYg1XwVMYBdsrVg4kID5WY1RCHns07cDGluERcurjj3QHjToL T7VemcnFVzSphjjisi9a1QfRYCPf5xw5L8IjsAuNTBLv2DXKtL6Mf5Tv9BAZPD2em0rNS5n/ M7S6D2AAxIt9BQQ4aS16faI0gfUspj09RLdHANwOcLUPu+OE+O2IdgglBQLkadwLj9aY0ncE 8GhqFWcQ9xbtvHAljYaz5VmsOnjsadfGD8xW+QtWeFc8mfq7PncRjrc0Ywtb8TKeXkLHUQoT 4v2ilXisfOhryVj6/GuQvDjKKyUBW1tQPxei4n/W0zBC4LWehmwCH+WrFt+mTh3uHSyy9VbR FYmY6MBBMUpHHVQ3AVLgxoldu/yX/ery+fdE8MeScAWg+WE5rQARAQABzSBEYW5pZWwgRmV0 dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPsLBgAQTAQgAKgIbAwUJC0c1AAULCQgHAwUVCgkICwUW AgMBAAIeAQIXgAUCVu7cmAIZAQAKCRBYD1kOlZ2qqXCPD/wLpgL6j51OUlGzLaA+Xt+QzX/v qUiHJsvv1mEnyofk/3pGr7ce/1UNp7e8/W2JnnHvz4RBaNkn07DFyOvrVNXiMyU6mKWvG6xw Ri5Qc2t1Cup+mXlNc5fxlZGnwOYXZJErYVTPodkFlbb6LKUMyg6v2P7ZEvw4YyPh7WpV5ujF VVkYBSLviNCjVwKr8WlJJlVI4uvHZshnX85lVpRNcF+Hqf7IhnJzCQ5bUNnV7aKc4WPNw7L6 EquuCAl6JGKdeV2M+S5UVN9Eaa/CQxJf8X9I3SVgWCGQ/gLt0x1oKt6oFMECJcH2LDFOJyWv 61AUIzqCdRiTUagdc+7sn2OFbbjhKin9x+Qq6pyoXa6ZcpEuyBoAy+hNU8RAXcPgvEBy4Bwx BYQ9S3uQmBx/TcYgSUbBwBhvIYRVM5DfBefolj3HyUlvHx8JO8scbdcVl+v1+f9d5x4YS16t bWNe7awE6UWM2I02+uv7SI2ieJ2zQsOulDTEYVYjWcu0hBH24K53wniyh3JHzu6RVCgewx4P 6H2WHOSVf2p9ppuIrbWh7J6pp9nFdDXESKxH3GO5LooLamGugSlRwdgsqxY0O4BbCpKIpfe8 31peA+7qbh1f4TXHo/ZQE8fZ2s4VN5XR5J5/yjfqY2pWDy1XocixzXboLAcuzGmZNutS46eH Azjo2CxTa87BTQRW7tkVARAA1cAIBWNxYj/QE7RcOHGgr8xXcKWk/wwTWgLvjEbp5tqMl3Jk EwD1Iajz1s+Qp7U+U4UqyI+ZSfm03bYFYlTyKaS2esiM+Incutg18N943xwGNc6csyNoW5/f xbDQ4hoMKsod9zjfvxpA8xLg8gjuPKi5Y698K7qDCCfGvo6e67qwFWIvrB7cv/NAoaVd1OPI 79nt2H5yWo0PE2Kd2yAMnWJ/3clLR6X4jqkmpoc2uEPE6aM7iQ6SCx7rMFP9W9OvovnzVksS dh65JRkiA3DTUWBxZM6h/oEERBTr9Q/JYXXugO300loterwBVu0ymBHdAjIlxpetFwZu/Wlb nymC4VSxGPS/+mJ9Lnh3WWjVEcP5F9WgqmfJ49BNqOjmgZ9u9VYV8R9fOaYvtPFTdGTYT9iw JYic/0xt9NcW/hRkff0UHdiN/BrTxbHVI7Qf4MLBK/+VtqVi0MLs7U80/2fPRebTq4yQ6aoY 7hErExrJ7TgTmZghsBJTd2cmau26Kb7stLJ4ySADcyrsADl03MNoj8QqVuO8HXx2InM18sHP xldjovv8dhmj7uiKmMPAqq5f8pA5bcA/EQ6S+ItjjohSLiYQtq6UgDPlt4tIA9nCfx+cGi6f o4sJE0InaQLinm0USp0zE+slpqXGwjzeFSTioL81cDGhN3dcCK94VsntblsAEQEAAcLBZQQY AQgADwUCVu7ZFQIbDAUJC0c1AAAKCRBYD1kOlZ2qqdnTD/9fOyWwdhOv4ehtR8ShfhM1FAc8 bWMfCrxTpI4baPM4fqIFgMAJ9iQ0FF6cB0zQjDwsWNC+3t+2JdiNeM8FB7s4bbJlhjaavzKK 77Kbf4WpVs7ge0+Zghc2qHRg/SQeC1G26GzSZDDWzDHFZX0va8H0KmT/tHJYD263CIcff/E9 WXT/22rrgYvuQXPIOBzON9WqUkCAvPA19xuBsDQSbXkXwiPsZRqmyktjc8GQn1iemQ/dzlU/ e6ORNrPcK15kUyPyJMaZf+6QJ8EivUyg+pTXicEcghWNYHXxop4k0y+bsay0cBN2lmNu7UEF qhO8HQmp2jrwZXFZD/fbZukXFHNWvNsvQ55flUfajPZhUokXHskkerbq6ZCS58HkWl0tqSIb 5TxNfP0zjcrlDBc8sF6UHXgNR1oUXypGOAq4iHeJNVpI4aQm/PufmeGExx6lPtJxJ9jOs5gD rYRuBfa1cJznEPNbIe0/eCv5qDpf95csdGJhM418x2xeg58PbmBByS9MXOGFtli0K9sxIej/ YdA94hlk/R9ViIPDuqDxz0PP+IRFVVOQhOprSnG8cV31oOe00e1bIBH3ttdsgp3AHqz/zlfF kZt27s1VH+aRF4STntrU97dNmxrgjq8zUZ7VgYjq8KqLg0BsDRIy4b/AnptYh6E4oE74gKCo Qoim4V9DGw== Message-ID: Date: Fri, 18 May 2018 15:46:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D30F3DCDAC229642B48BE32B" Content-Language: de-DE Archived-At: Subject: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 13:46:11 -0000 This is a multi-part message in MIME format. --------------D30F3DCDAC229642B48BE32B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Looking at draft-bradley-oauth-jwt-encoded-state-08, I see in Section 2 (https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-08#sec= tion-2) that all contents of the JWT that would bind the specific state value to the AS are optional. This means that the following attack is possible (we described this attack in our OAuth paper [0], Section 5.1, albeit very briefly): Precondition: A client that supports multiple AS (with one being an attacker-controlled AS, let's call it A-AS). 1. An honest user tries to authorize using A-AS, the attacker receives the value of "state" which is bound to the honest user's session with the client. 2. A-AS aborts the authorization (e.g., by redirecting the user back to the client's web site without any parameters). 3. The user starts a new authorization flow with an honest AS (H-AS). Since the state JWT is not bound to the AS selected by the user, the state value generated in (1.) will likely be valid for the login flow started in (3.). The attacker therefore knows a valid state value and can mount a CSRF attack (which was supposed to be prevented by using stat= e). Solution: Always bind state to the chosen AS, i.e., make the "as" part of the JWT mandatory -or- use some other mechanism on the client (if the client is stateful) to invalidate the old state value. If we agree that this is problematic, I think this should be changed in draft-bradley-oauth-jwt-encoded-state and should at least briefly be discussed in the security topics document (I will be happy to write a section for the latter). - Daniel [0] https://sec.uni-stuttgart.de/_media/publications/FettKuestersSchmitz-TR-O= Auth-2016.pdf --=20 SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universit=C3=A4tsstra=C3=9Fe 38 - 70569 Stuttgart - Room 2.434 --------------D30F3DCDAC229642B48BE32B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

Looking at draft-bradley-oauth-jwt-encoded-state-08, I see in Section 2 (https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-08#section-2) that all contents of the JWT that would bind the specific state value to the AS are optional. This means that the following attack is possible (we described this attack in our OAuth paper [0], Section 5.1, albeit very briefly):

Precondition: A client that supports multiple AS (with one being an attacker-controlled AS, let's call it A-AS).

1. An honest user tries to authorize using A-AS, the attacker receives the value of "state" which is bound to the honest user's session with the client.

2. A-AS aborts the authorization (e.g., by redirecting the user back to the client's web site without any parameters).

3. The user starts a new authorization flow with an honest AS (H-AS).

Since the state JWT is not bound to the AS selected by the user, the state value generated in (1.) will likely be valid for the login flow started in (3.). The attacker therefore knows a valid state value and can mount a CSRF attack (which was supposed to be prevented by using state).

Solution: Always bind state to the chosen AS, i.e., make the "as" part of the JWT mandatory

-or- use some other mechanism on the client (if the client is stateful) to invalidate the old state value.


If we agree that this is problematic, I think this should be changed in draft-bradley-oauth-jwt-encoded-state and should at least briefly be discussed in the security topics document (I will be happy to write a section for the latter).

- Daniel

[0] https://sec.uni-stuttgart.de/_media/publications/FettKuestersSchmitz-TR-OAuth-2016.pdf

-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434
--------------D30F3DCDAC229642B48BE32B-- From nobody Fri May 18 09:20: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 C0BA212D864 for ; Fri, 18 May 2018 09:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 T16b6sZ-BzgP for ; Fri, 18 May 2018 09:20:24 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEE212D7F6 for ; Fri, 18 May 2018 09:20:24 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id v7-v6so3551989pgs.0 for ; Fri, 18 May 2018 09:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=Pn+XuVoIIud0BhSumEbSjN7jATiK0H10AyBqxtv9c2I=; b=rmMToy9DuAV7gPRUOVcu3RHp10CAZzOPQeUzdJybExrnF38AFp5g6BNpbgwQfg9kbr vTIsKqtMYazl0s3w5grHV6Rr31rSlWN/w7+GW3HhUQeHGowLKtZha/F+DQaLRrWy6QMx VOjPtf0Dna2vgFOxmPJ6TPg5209e0n3/kQVojU7ap/LHv4+93AYvBdN6t/Syl2nkHLi9 E1zhvHNTtwm3/Z70EuJLgCpm4jAzbEkBGCXAnGiEQpE5xLvzP+NDLnziVLsHlh4k3G/i 9XhVY3jwOcFVONNZDVXTQuSk2bkhktLWy8s59m61C3X76wMk7rAeGuNM73UOYZ/NCzlJ mGtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=Pn+XuVoIIud0BhSumEbSjN7jATiK0H10AyBqxtv9c2I=; b=MkDPAbyTXIhEjE4S173/YEBrOkTlM6EC05oCAxF0Th2H2tiHjdnBHVazWu3Fsa4Dkz B/sF4qV1uApTa0wqEnm4tZBJLt9Qw4YbXmMDiv4hiqbMUdsYUCSNmfRH3nU/LHcl7i3n e/8jfO6yP2OPJm1Xt5Mx4Kpv4Z7g/MgRGgZEjZLDNHXSk9g6HhlBLYvTi22DjSvfTBNV 7SE+MgEQO5KKGCluHTBxzx5uenH7t1ZeQ+qHz7J1k/ZbEZ2CgDVBJtRLoH6OjF1wlqAo JlHNkGcBW0HhFrOHY9fCXTUA6+LVcwPmnZVyy4ZY9ZwG6nI6TbDqu/DPKbJYoOKc6aBE CCcQ== X-Gm-Message-State: ALKqPwcaMwC6MX5AOLtbFTwrd27mYhl6l6Mqh1APastXsPB2HviIxHc2 HyZGHC9kQltqE3l9sUbsjOmNYTwd2ZU= X-Google-Smtp-Source: AB8JxZrEU58h3op6csfKxhBKA/njhmhT7QwaimbVOwsFVrCzUc16ZIpE2RtFHSV3w3tG6BYQUubmLw== X-Received: by 2002:a63:43c6:: with SMTP id q189-v6mr8238188pga.123.1526660423255; Fri, 18 May 2018 09:20:23 -0700 (PDT) Received: from MWHPR19MB1085.namprd19.prod.outlook.com ([40.97.141.109]) by smtp.gmail.com with ESMTPSA id i1-v6sm15612310pfi.133.2018.05.18.09.20.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 May 2018 09:20:21 -0700 (PDT) From: John Bradley To: "oauth@ietf.org" , Daniel Fett Thread-Topic: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08 Thread-Index: ATNjMGYzEqlKiuPa7h8Olv132yqWfMEXJ2/Z X-MS-Exchange-MessageSentRepresentingType: 2 Date: Fri, 18 May 2018 16:20:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, 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: multipart/alternative; boundary="_000_MWHPR19MB108579B64C94803C25D96CAAFA900MWHPR19MB1085namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:20:27 -0000 --_000_MWHPR19MB108579B64C94803C25D96CAAFA900MWHPR19MB1085namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not against having "as" as REQUIRED. While we are at it should we recommend that rfp be single use? This draft hangs around as a ID and probably is not read by most people. We may also want to mention it in security topics if we haven't. I need to update this in the next couple of weeks to keep it from expiring = anyway. John B. From: Daniel Fett Sent: Friday, May 18, 3:46 PM Subject: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-o= auth-jwt-encoded-state-08 To: oauth@ietf.org Hi all, Looking at draft-bradley-oauth-jwt-encoded-state-08, I see in Section 2 (ht= tps://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-08#section-= 2) that all contents of the JWT that would bind the specific state value to= the AS are optional. This means that the following attack is possible (we = described this attack in our OAuth paper [0], Section 5.1, albeit very brie= fly): Precondition: A client that supports multiple AS (with one being an attacke= r-controlled AS, let's call it A-AS). 1. An honest user tries to authorize using A-AS, the attacker receives the = value of "state" which is bound to the honest user's session with the clien= t. 2. A-AS aborts the authorization (e.g., by redirecting the user back to the= client's web site without any parameters). 3. The user starts a new authorization flow with an honest AS (H-AS). Since the state JWT is not bound to the AS selected by the user, the state = value generated in (1.) will likely be valid for the login flow started in = (3.). The attacker therefore knows a valid state value and can mount a CSRF= attack (which was supposed to be prevented by using state). Solution: Always bind state to the chosen AS, i.e., make the "as" part of t= he JWT mandatory -or- use some other mechanism on the client (if the client is stateful) to = invalidate the old state value. If we agree that this is problematic, I think this should be changed in dra= ft-bradley-oauth-jwt-encoded-state and should at least briefly be discussed= in the security topics document (I will be happy to write a section for th= e latter). - Daniel [0] https://sec.uni-stuttgart.de/_media/publications/FettKuestersSchmitz-TR= -OAuth-2016.pdf -- SEC - Institute of Information Security University of Stuttgart Phone +4= 9 711 685 88468 Universit=E4tsstra=DFe 38 - 70569 Stuttgart - Room 2.434 --_000_MWHPR19MB108579B64C94803C25D96CAAFA900MWHPR19MB1085namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am not against having "as" as REQUIRED.

While we are at it should we recommend that rfp be single use? 

This draft hangs around as a ID and probably is not read by most people.&nb= sp; 

We may also want to mention it in security topics if we haven't. 

I need to update this in the next couple of weeks to keep it from expiring = anyway. 

John B. 

From: Daniel Fett
Sent: Friday, May 18, 3:46 PM
Subject: [OAUTH-WG] Reuse of "state" across different AS in draft= -bradley-oauth-jwt-encoded-state-08
To: oauth@ietf.org


Hi all,
Looking at draft-bradley-oauth-jwt-encoded-state-08, I see in Section 2 (https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-s= tate-08#section-2) that all contents of the JWT that would bind the specific state value to the AS are optional= . This means that the following attack is possible (we described this attac= k in our OAuth paper [0], Section 5.1, albeit very briefly):
Precondition: A client that supports multiple AS (with one being an attacke= r-controlled AS, let's call it A-AS).
1. An honest user tries to authorize using A-AS, the attacker receives the = value of "state" which is bound to the honest user's session with= the client.
2. A-AS aborts the authorization (e.g., by redirecting the user back to the= client's web site without any parameters).
3. The user starts a new authorization flow with an honest AS (H-AS).
Since the state JWT is not bound to the AS selected by the user, the state = value generated in (1.) will likely be valid for the login flow started in = (3.). The attacker therefore knows a valid state value and can mount a CSRF= attack (which was supposed to be prevented by using state).
Solution: Always bind state to the chosen AS, i.e., make the "as"= part of the JWT mandatory
-or- use some other mechanism on the client (if the client is stateful) to = invalidate the old state value.

If we agree that this is problematic, I think this should be changed in dra= ft-bradley-oauth-jwt-encoded-state and should at least briefly be discussed= in the security topics document (I will be happy to write a section for th= e latter).
- Daniel
-- SEC - Institute of Information Security University of Stuttgart Phone &#= 43;49 711 685 88468 Universit=E4tsstra=DFe 38 - 70569 Stuttgart - Room 2.43= 4

--_000_MWHPR19MB108579B64C94803C25D96CAAFA900MWHPR19MB1085namp_-- From nobody Fri May 18 09:27: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 0DD7412DA24 for ; Fri, 18 May 2018 09:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 iFxMUJ55gqD5 for ; Fri, 18 May 2018 09:27:49 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 E3CFC12D7F6 for ; Fri, 18 May 2018 09:27:48 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id az12-v6so4870213plb.8 for ; Fri, 18 May 2018 09:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-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 :mime-version; bh=z7xGdxgQKklG4YpJxjismejjQd+a6QzaaMH5jHRip+U=; b=kgnmNXA20BbM1H6UpPmQKsvBuS54b3GE7WrQe80/WM0qB3Y7TdJlzeVLYBKSezeIiu pMumL4PNQOdphPi55EkOoopZKVi9R41rS5yAktfHUVBj69PuOXYMzWMAnIlAWGT0/BvB ByQMHr7Pm9a1kfhVFgw6jXV4/3ijvxC5MCvRr+H/WQpe0i8nSWlkPScVnhUi4EqGeHEV EO4XzP0zSK1KI8Q/Bku+JQ96gctxVYvCGtCb5thAmtiePnaHMaKSNiXcktrrt/13BW2B dDALBpkYhfsaeM/+2akrlK4Wvx+ltWN0I3Ow4vvh/Y5UVR7CBu805NuHZHfJ32xBMuPw /fnA== 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:mime-version; bh=z7xGdxgQKklG4YpJxjismejjQd+a6QzaaMH5jHRip+U=; b=Mxsv7HiHWvdMgDsMIZOygeIRhBWYNJXKBqyMPRcv/pJemWVlhiJcthuelrL4r1flc3 0SkCUgmaomX/j33eBIfz/gD824VXyXOxtuOhi8X0mcu9cUOWBGy3sRIrC6XiBU08gEG+ Hb+m1o/n2/b5W4oAG4U70eqLFR8goXE4ifPtMA/vdUMI23gUMdm1iC9exYu2GYWEvm15 8cj5xFQfeq6LqR81HsWIUdoVS6tPKDF4ZP+sneOBMzCf9/OS6TuKm3oT7vSENjz568Cy Hh4kR4EVHjZc2tStE/VMUm6qExJeXp4uTCOto1Kf8+j1DTc0WAywAc7DRNbi+KT5axG+ 0Dwg== X-Gm-Message-State: ALKqPwcIQKljLyZGygkZcWYf+qxnU0pbwfaL7yzQVTTeVpEDc+cO+vvX N7A2tucTsrfVCsq6V97OALdDgJjsEuc= X-Google-Smtp-Source: AB8JxZrmA75OiQvax7cXv+jk/yeAzSF8LrqIDf03OPRJYQkYVAvh0E9E4XX1roOu9u2pVkqxgX9PrQ== X-Received: by 2002:a17:902:f83:: with SMTP id 3-v6mr10100710plz.336.1526660867330; Fri, 18 May 2018 09:27:47 -0700 (PDT) Received: from MWHPR19MB1085.namprd19.prod.outlook.com ([40.97.141.109]) by smtp.gmail.com with ESMTPSA id a11-v6sm11650001pgn.64.2018.05.18.09.27.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 May 2018 09:27:46 -0700 (PDT) From: John Bradley To: David Waite , Hannes Tschofenig , Brock Allen CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] is updated guidance needed for JS/SPA apps? Thread-Index: AWMzMzRhARJ9niN08bKlsluLh7fMazBFM0EwQjA2NDEyNjI0OdxRxv++ X-MS-Exchange-MessageSentRepresentingType: 2 Date: Fri, 18 May 2018 16:27:38 +0000 Message-ID: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com>, <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> In-Reply-To: <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> Accept-Language: en-GB, 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: multipart/alternative; boundary="_000_MWHPR19MB1085FC4579E0A656BB78A8ABFA900MWHPR19MB1085namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:27:52 -0000 --_000_MWHPR19MB1085FC4579E0A656BB78A8ABFA900MWHPR19MB1085namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes that was the original intent to have the AT be short lived and refresh = the AT via the authorization endpoint based on the session cookie. The session cookie should also be flagged as http only to protect it. Having a refresh token in local storrage may introduce new security issues = unless it is token bound. Understanding the security issues of the code flow in the browser is import= ant, before any new recommendation. John B. From: Brock Allen Sent: Friday, May 18, 2:46 PM Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? To: David Waite, Hannes Tschofenig Cc: oauth@ietf.org One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow. What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit= of protection for the end user built into that design by virtue of being t= ied to the user's cookie at the AS/OP. Just throwing that out as an additional discussion point. -Brock On 5/18/2018 6:04:47 AM, David Waite wrote: I have written some guidance already (in non-RFC format) on preferring code= for single page apps, and other security practices (CORS, CSP). From the A= S point of view, it aligns well with the native apps BCP. There are benefit= s of thinking about native and SPA apps just as =91public clients=92 from a= policy/properties point of view. It also greatly simplifies OAuth/OIDC sup= port on both the AS administrator and client developer side when converting= web properties into native apps using technologies like Electron or Cordov= a. For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=92t believe the ne= ed for a policy using short-lived refresh tokens, revoking at signout, or u= se of the revocation endpoint are different from browser and native applica= tions. Rather they seem to be a function of usage patterns that an AS may n= eed to support, and we happen to sometimes associate those usage patterns w= ith typical usage of native apps vs of browser apps. For example, browser l= ogin on a borrowed device can easily leak over to being app authorization -= the authentication/authorization are web-based processes to achieve SSO. I have been working on some guidance here around token lifetimes and polici= es, but I don=92t know whether that brings in too much AS/OP business logic= (and, likely implied product/deployment features) to be industry practices= . -DW On May 17, 2018, at 10:23 AM, Hannes Tschofenig > wrote: Hi Brock, there have been several attempts to start writing some guidance but so far = we haven=92t gotten too far. IMHO it would be great to have a document. Ciao Hannes From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen Sent: 17 May 2018 14:57 To: oauth@ietf.org Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens But this requires: * AS/OP to support PKCE * AS/OP to support CORS * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout Any use in discussing this? -Brock 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_MWHPR19MB1085FC4579E0A656BB78A8ABFA900MWHPR19MB1085namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes that was the original intent to have the AT be short lived and refresh = the AT via the authorization endpoint based on the session cookie. 

The session cookie should also be flagged as http only to protect it. =

Having a refresh token in local storrage may introduce new security issues = unless it is token bound. 

Understanding the security issues of the code flow in the browser is import= ant, before any new recommendation. 

John B.

From: Brock Allen
Sent: Friday, May 18, 2:46 PM
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
To: David Waite, Hannes Tschofenig
Cc: oauth@ietf.org


One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow.

What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit of protection for the end user built into= that design by virtue of being tied to the user's cookie at the AS/OP.

Just throwing that out as an additional discussion point.

-Brock

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> w= rote:
I have written some guidance already (in non-RFC format) on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =91public clients=92 from a policy/properties point of view. = It also greatly simplifies OAuth/OIDC support on both the AS administrator = and client developer side when converting web properties into native apps u= sing technologies like Electron or Cordova.

For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=92t believe the ne= ed for a policy using short-lived refresh tokens, revoking at signout, or u= se of the revocation endpoint are different from browser and native applications. Rather they seem to be a f= unction of usage patterns that an AS may need to support, and we happen to = sometimes associate those usage patterns with typical usage of native apps = vs of browser apps. For example, browser login on a borrowed device can easily leak over to being app autho= rization - the authentication/authorization are web-based processes to achi= eve SSO.

I have been working on some guidance here around token lifetimes and polici= es, but I don=92t know whether that brings in too much AS/OP business logic= (and, likely implied product/deployment features) to be industry practices= .

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Brock,
 
there have been several attempts to start writing some guidance but so far = we haven=92t gotten too far.
IMHO it would be great to have a document.
 
Ciao
Hannes
 
From: OAuth [mailto:o= auth-bounces@ietf.org] On Behalf Of Brock Allen
Sent: 17 May 2018 14:57
Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?=
 
Much like updated guidance was provided with the "OAuth2 for native ap= ps" RFC, should there be one for "browser-based client-side JS ap= ps"? I ask because google is actively discouraging the use of implicit= flow:
 
 
>From what I can tell, the complaints with implicit are:
* access token in URL
* access token in browser history
* iframe complexity when using prompt=3Dnone to "refresh" access = tokens
 
But this requires:
* AS/OP to support PKCE
* AS/OP to support CORS 
* user-agent must support CORS
* AS/OP to maintain short-lived refresh tokens 
* AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about)
* if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout
 
Any use in discussing this?
 
-Brock
 
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



--_000_MWHPR19MB1085FC4579E0A656BB78A8ABFA900MWHPR19MB1085namp_-- From nobody Fri May 18 09:37: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 B52E112DA12 for ; Fri, 18 May 2018 09:36:58 -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=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 WA9G-T6CtCc3 for ; Fri, 18 May 2018 09:36:56 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 613D512D7F6 for ; Fri, 18 May 2018 09:36:56 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m5-v6so11057503qti.1 for ; Fri, 18 May 2018 09:36:56 -0700 (PDT) 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=0ekb07eto9HzE9LWQGEwVO1TrTk+nf8D/op+/0jqnvs=; b=HqP2Z0opfEU70aR2eNocw+/CE6x/Oyv2eynNEfBTvIEIPql5YSYHy/KmeyS29vR+6p Y23JmLfH7Dj0yW4sHP5Wf8/MbP3FDEPvY+FOLHE6U2m+D4w3v5Uw+MmW0vMel77aSnhl c4hvQ+4P0UUW6j0e8XK3uPqYIFE9yaFouIbSQL7xadizJyu5y4cfHIzkuYkWFnle9vyS 7OShr/2yoEn1T+yb3SmkPB9DFKfcPqSabiJjRKIcF+9NBxgupuP3dUab7CiMEsl6fAXp NfZ739EcZDYdo/kUR5+sr7tBi5l43hn/qbzYyYFB6JuMwtxGq6XsSwe6oVR2eC+i1+Zk CT/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=0ekb07eto9HzE9LWQGEwVO1TrTk+nf8D/op+/0jqnvs=; b=bwfxlo2pDXH080ZKGoj9J7yKmjYwIGTWMi2Q0Hnxm5Sm72nzOQCnk0LaoQ8ZYdNFAJ AzLn4sllZFTNao+KAM1jWUTpP6aGdtfiBRtRUKc2P9pn4yxstt3ZwptDbsgC1UfpPZfa ByWJZSOz0wcQJzSJ7eCtCiM5TcPDD/6r6w3Wd+9qPCX6CDFqHAy7QL37tIOXmJtmuQun RZenPL4a9yscAXvBqauI/ZZsxMzmoTGvFkhftCCwqdXiwaXRsEyW9oJOpjy4+a0wDnYp faGAjvQbc08CvccvKvywuKs5uXWC8VQye0IBrm+XSX6h7od0pTeKHNyZ/zuEMU8rUQ5c pKRg== X-Gm-Message-State: ALKqPwdEqzCbxZdVy8oWxm4jAOtGBlWp/zG7BAbgmK2KzFs2Pkd6nFU8 OOIZYKgoE6L8kI7e3t3VNGY= X-Google-Smtp-Source: AB8JxZohE3qrT0EAAJkKOFlYiqEkDM+nivnHApc3VkouiipB9tZC+mJthvxOkE3W+Sn+oAR7uswijw== X-Received: by 2002:aed:29c2:: with SMTP id o60-v6mr10018225qtd.2.1526661415335; Fri, 18 May 2018 09:36:55 -0700 (PDT) Received: from [172.20.10.3] ([172.58.233.201]) by smtp.gmail.com with ESMTPSA id 42-v6sm5690835qte.41.2018.05.18.09.36.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 09:36:54 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_43595952.111462569907" MIME-Version: 1.0 Date: Fri, 18 May 2018 12:36:48 -0400 Message-ID: <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> From: "Brock Allen" To: "John Bradley" , "David Waite" , "Hannes Tschofenig" Cc: "" In-Reply-To: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> User-Agent: Mailbird/2.5.8.0 X-Mailbird-ID: 22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:36:59 -0000 ------=_NextPart_43595952.111462569907 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It sounds to me as if you're hesitant to recommend code flow (at least for = now) then for browser-based JS apps. -Brock On 5/18/2018 12:27:48 PM, John Bradley wrote: Yes that was the original intent to have the AT be short lived and refresh = the AT via the authorization endpoint based on the session cookie.=C2=A0 The session cookie should also be flagged as http only to protect it.=C2=A0 Having a refresh token in local storrage may introduce new security issues = unless it is token bound.=C2=A0 Understanding the security issues of the code flow in the browser is import= ant, before any new recommendation.=C2=A0 John B. From: Brock Allen Sent: Friday, May 18, 2:46 PM Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? To: David Waite, Hannes Tschofenig Cc: oauth@ietf.org One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow. What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit= of protection for the end user built into that design by virtue of being t= ied to the user's cookie at the AS/OP. Just throwing that out as an additional discussion point. -Brock On 5/18/2018 6:04:47 AM, David Waite wrote: I have written some guidance already (in non-RFC format)=C2=A0on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =E2=80=98public client= s=E2=80=99 from a policy/properties point of view. It also greatly simplifi= es OAuth/OIDC support on both the AS administrator and client developer sid= e when converting web properties into native apps using technologies like E= lectron or Cordova. For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe = the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS= may need to support, and we happen to sometimes associate those usage patt= erns with typical usage of native apps vs of browser apps. For example, bro= wser login on a borrowed device can easily leak over to being app authoriza= tion - the authentication/authorization are web-based processes to achieve = SSO. I have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry pra= ctices. -DW On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: Hi Brock, =C2=A0 there have been several attempts to start writing some guidance but so far = we haven=E2=80=99t gotten too far. IMHO it would be great to have a document. =C2=A0 Ciao Hannes =C2=A0 From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.= org]]=C2=A0On Behalf Of=C2=A0Brock Allen Sent:=C2=A017 May 2018 14:57 To:=C2=A0oauth@ietf.org [mailto:oauth@ietf.org] Subject:=C2=A0[OAUTH-WG] is updated guidance needed for JS/SPA apps? =C2=A0 Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: =C2=A0 https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 [http= s://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290] =C2=A0 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens =C2=A0 But this requires: * AS/OP to support PKCE *=C2=A0AS/OP to support=C2=A0CORS=C2=A0 * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens=C2=A0 * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout =C2=A0 Any use in discussing this? =C2=A0 -Brock =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.=C2=A0_______________________________________________ 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] ------=_NextPart_43595952.111462569907 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A It sounds= to me as if you're hesitant to recommend code flow (at least for now) then= for browser-based JS apps.

-Brock

= =0A

O= n 5/18/2018 12:27:48 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

= =0A
=0AYes that was the original i= ntent to have the AT be short lived and refresh the AT via the authorizatio= n endpoint based on the session cookie. =0A
=0A
=0A
=0A=0AThe session cookie should also be = flagged as http only to protect it. 
=0A
=0A
=0A
=0AHaving a refresh token in local storra= ge may introduce new security issues unless it is token bound. =0A
= =0A
=0A
=0A
=0AUnderstandi= ng the security issues of the code flow in the browser is important, before= any new recommendation. =0A
=0A
=0A
=0A
=0AJohn B.
=0A
=0A
=0A
=0AFrom: Brock Allen
=0A
=0A
=0ASent: Friday, May 18, 2:46 PM
=0A
=0A=
=0ASubject: Re: [OAUTH-WG] is upd= ated guidance needed for JS/SPA apps?
=0A
=0A
=0ATo: David Waite, Hannes Tschofenig
=0A
=0A=0ACc: oauth@ietf.org
=0A
=0A=
=0A
=0A
=0AOne thing I ma= ybe should have listed in the pros/cons in my original email is session man= agement and token lifetime considerations, keeping in mind the original int= ent of the implicit flow.=0A
=0A
=0A
=0A
=0AWhat I mean is that with implicit grant type, the cli= ent's ability to get new access tokens is limited to the user's session at = the AS/OP. Obviously other flows make more sense to obtain longer lived acc= ess (via refresh tokens), but I don't know about a browser-based=0A JS app.= In a sense there's a bit of protection for the end user built into that de= sign by virtue of being tied to the user's cookie at the AS/OP.=0A
=0A=0A
=0A
=0AJust throwing th= at out as an additional discussion point.
=0A
=0A
=0A
=0A-Brock
=0A
=0A
=0A=0A
=0AOn 5/18/2018= 6:04:47 AM, David Waite <david@alkaline-solutions.com> wrote:
=0A=
=0A
=0AI have written some g= uidance already (in non-RFC format) on preferring code for single page= apps, and other security practices (CORS, CSP). From the AS point of view,= it aligns well with the native apps BCP. There are benefits of thinking ab= out native and SPA=0A apps just as =E2=80=98public clients=E2=80=99 from a = policy/properties point of view. It also greatly simplifies OAuth/OIDC supp= ort on both the AS administrator and client developer side when converting = web properties into native apps using technologies like Electron or Cordova= .=0A
=0A
=0A
=0A
=0AFor= the later requirements in the list around token policy, I am not sure thes= e are requirements for single page apps per se. I don=E2=80=99t believe the= need for a policy using short-lived refresh tokens, revoking at signout, o= r use of the revocation endpoint are=0A different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS= may need to support, and we happen to sometimes associate those usage patt= erns with typical usage of native apps vs of browser apps. For example,=0A = browser login on a borrowed device can easily leak over to being app author= ization - the authentication/authorization are web-based processes to achie= ve SSO.
=0A
=0A
=0A
=0A= I have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry pra= ctices.
=0A
=0A
=0A
=0A= -DW
=0A
=0A
=0A=0A
=0A=0A
=0AOn Ma= y 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
=0A
=0A=0A
=0AHi Brock,
=0A
=0A=
=0A 
=0A
=0A
=0Athere have been several attempts to st= art writing some guidance but so far we haven=E2=80=99t gotten too far.
= =0A
=0A
=0AIMHO it would be g= reat to have a document.
=0A
=0A
=0A 
=0A
=0A
= =0ACiao
=0A
=0A
=0AHannes<= br>=0A
=0A
=0A 
=0A=0A=0A
=0ASent: 17 May 2018 14:57
=0A=0A=0A
=0ASubject: [OAUTH-WG] is updated g= uidance needed for JS/SPA apps?
=0A
=0A
=0A 
=0A
=0A
=0AMuch like updated guidance was provided with the "OAuth2 for nativ= e apps" RFC, should there be one for "browser-based client-side JS apps"? I= ask because google is actively discouraging the use of implicit flow:
= =0A
=0A
=0A 
=0A=0A=0A
=0A 
=0A
=0A
=0AFrom what I can tell, the complaints with i= mplicit are:
=0A
=0A
=0A* = access token in URL
=0A
=0A
=0A* iframe complexity when using prompt=3Dnone to "re= fresh" access tokens
=0A
=0A
=0A 
=0A
=0A
=0ABu= t this requires:
=0A
=0A
= =0A* AS/OP to support PKCE
=0A
=0A
=0A* AS/OP to support CORS 
=0A
=0A
=0A* user-agent must support CORS
=0A<= /div>=0A
=0A* AS/OP to maintain sh= ort-lived refresh tokens 
=0A
=0A
=0A* AS/OP must aggressively revoke refresh tokens at user sig= nout (which is not something OAuth2 "knows" about)
=0A
=0A
=0A* if the above point can't work, then = client must proactively use revocation endpoint if/when user triggers logou= t
=0A
=0A
=0A 
=0A=
=0A
=0AAny use in discussing= this?
=0A
=0A
=0A =0A
=0A
=0A-Brock
=0A=0A
=0A 
=0A
=0A=0AIMPORTANT NOTICE: The contents o= f this email and any attachments are confidential and may also be privilege= d. If you are not the intended recipient, please notify the sender immediat= ely and do not disclose the contents to any other person, use it for any pu= rpose,=0A or store or copy the information in any medium. Thank you. _= ______________________________________________
=0A
=0A
=0AOAuth mailing list
=0A
=0A=0A=0A
=0A= =0A
=0A
=0A
=0A
=0A
= =0A=0A =0A = =0A
------=_NextPart_43595952.111462569907-- From nobody Fri May 18 09:37:29 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 A8DF712E053 for ; Fri, 18 May 2018 09:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 mGimfn2m-FmQ for ; Fri, 18 May 2018 09:37:24 -0700 (PDT) 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 773C112E049 for ; Fri, 18 May 2018 09:37:24 -0700 (PDT) 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 w4IGaTnc142772; Fri, 18 May 2018 16:37:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=07KVree2Nx5J7brQ3V9uf0hKE/n//FnqdcZnCUmDiAo=; b=Pi3AT8OIUUeHmbjhbsbGaqgVVv1dcgaeB8j8p34/XPQPwDYhRZw9hZtEPWXalvMdwAtK /FJHGc147eo0EyxwWyRx5Ke43yMe5re0S358fuEc3zRtUY8WSKlXOMjmHGj63BFgPnaw NqPHXd4QYjE5Oj6N4FjzsusT+3/YF9oyJLGVyT8UyZouM7k7IL5hnPsZAPQcw3y95zt1 jQQR/ruXvywocxOBbB3I9QWZmeELeSXyqEt9iuoCiRX96u0d+Ay10FqqdCZtz2Z4lbIh q/td/yYJ3fhjk0K4D3TU1JqsK6POIaIUK3F1y7GeOdwD1OVLRkeq76l9cZ0X1zL0AWhV BA== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2hx29we75n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 May 2018 16:37:17 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4IGbH09017241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 May 2018 16:37:17 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4IGbGsb014829; Fri, 18 May 2018 16:37:16 GMT Received: from [10.0.1.20] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 May 2018 09:37:16 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-79BB4203-297B-4B01-896E-80E66DFC8ADB Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Fri, 18 May 2018 09:37:10 -0700 Cc: Brock Allen , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Hannes Tschofenig X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8897 signatures=668699 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-1711220000 definitions=main-1805180180 Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:37:27 -0000 --Apple-Mail-79BB4203-297B-4B01-896E-80E66DFC8ADB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. I think this would be good to have.=20 Phil > On May 17, 2018, at 9:23 AM, Hannes Tschofenig = wrote: >=20 > Hi Brock, > =20 > there have been several attempts to start writing some guidance but so far= we haven=E2=80=99t gotten too far. > IMHO it would be great to have a document. > =20 > Ciao > Hannes > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen > Sent: 17 May 2018 14:57 > To: oauth@ietf.org > Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > =20 > Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask becau= se google is actively discouraging the use of implicit flow: > =20 > https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 > =20 > =46rom what I can tell, the complaints with implicit are: > * access token in URL > * access token in browser history > * iframe complexity when using prompt=3Dnone to "refresh" access tokens > =20 > But this requires: > * AS/OP to support PKCE > * AS/OP to support CORS=20 > * user-agent must support CORS > * AS/OP to maintain short-lived refresh tokens=20 > * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) > * if the above point can't work, then client must proactively use revocati= on endpoint if/when user triggers logout > =20 > Any use in discussing this? > =20 > -Brock > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential 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 o= ther 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-79BB4203-297B-4B01-896E-80E66DFC8ADB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. I think this would be good to have.&nbs= p;

Phil

On May 17, 2018,= at 9:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Brock,

 

there have been several att= empts to start writing some guidance but so far we haven=E2=80=99t gotten to= o far.

IMHO it would be great to h= ave a document.

 

Ciao

Hannes

 

From: OAuth [mailto:o= auth-bounces@ietf.org] On Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org
Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?<= /o:p>

 

Much like updated guidance was provided with t= he "OAuth2 for native apps" RFC, should there be one for "browser-based clie= nt-side JS apps"? I ask because google is actively discouraging the use of implicit flow:

 

 

=46rom what I can tell, the complaints with i= mplicit are:

* access token in URL

* access token in browser history<= /span>

* iframe complexity when using prompt=3Dnone t= o "refresh" access tokens

 

But this requires:

* AS/OP to support PKCE

=

* AS/OP to support CORS <= /o:p>

* user-agent must support CORS

* AS/OP to maintain short-lived refresh token= s 

* AS/OP must aggressively revoke refresh toke= ns at user signout (which is not something OAuth2 "knows" about)<= /span>

* if the above point can't work, then client m= ust proactively use revocation endpoint if/when user triggers logout

 

Any use in discussing this?=

 

-Brock

 

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 medium. Thank you.
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-79BB4203-297B-4B01-896E-80E66DFC8ADB-- From nobody Fri May 18 09:43: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 5918112DA1D for ; Fri, 18 May 2018 09:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 viX72VRdZfSk for ; Fri, 18 May 2018 09:43:34 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1051212D7F6 for ; Fri, 18 May 2018 09:43:34 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id j186-v6so13875774ita.5 for ; Fri, 18 May 2018 09:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UeWdRfpKKqopD2aJk8RYTpNNXulOioxJIW+GVrpX4/Y=; b=stHewtFklEhDuDtDL5AfYxvcI/f+1PzdKXte/Damn6GHHKjxF3lq1reoCaiRsf2hkf 23HPHKXX0k8jLk8zMPCU+uLMnCPrPOkRfTVQt3vQrtI1nlYCxMij5vDHO9lrDF0y8WrB 4OEiI1YZZvqXZlxR8IOPy6FIoitQSzTl9+P3+rStvSbcpxGYEZn78cnPO2uLbe8gTNSF NMLCHW04PnVpWm+FPAaOgBs+DiW3sxe4pWovVI8rLuZBLHqlJWdK/RaiSXlg8NlyVOcc jhQ4eDd4Dk2sqKzTZwBiJ8t66IjhH4HGXxcTcv7FR3kRIwylcIoFjOq5q6ZbxBHG2IxP E9kg== 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=UeWdRfpKKqopD2aJk8RYTpNNXulOioxJIW+GVrpX4/Y=; b=FWH+yyQquIwv2NZN2sskHod+Lp64AFHFtd1FIOoa2UyinprHjXoG5r7zlhWwwos5g3 NUmVikKYiLQS5er9SwIyKqdH7NbM5IEiiSxaS3Qcd2SMDyxiiakkL3qpZXucGPNRtxyj MScgNK+DkQbiKjOSqzxX2/xu4DwcY3uLSskNprl0uq0nIBelwnWZ7AWq04vuruvrZrWm LU3Hv3wb/RsxuxZCHKDKb6LdIqp1EAWoEBgADaxhcTyJAtReuaNYl8Un6as9DrvhZa67 eSdqUA+DQxkdmFvR6YhVNhNl8KsfSd/BtUdT2EPETSyAjrR3grLm57sHqyGQM0Oow9R3 cDlQ== X-Gm-Message-State: ALKqPwdSHsa7hdkyvPdyTeIQmDjuLmE+UX/c+8Z9LsIcjcaVdKHGLq0j M6RiPrCGDFfS0gLh2j6bvtU2i/qZOx4= X-Google-Smtp-Source: AB8JxZoUXy27ZhGHCpXHouS0ZZOhqEVz4yBRj1HOoNcag0OFU+66nbVWjHI8Io7OBnHjxlkC2ioLyA== X-Received: by 2002:a24:d38d:: with SMTP id n135-v6mr8313443itg.75.1526661811774; Fri, 18 May 2018 09:43:31 -0700 (PDT) Received: from [10.102.248.12] (mobile-166-176-251-17.mycingular.net. [166.176.251.17]) by smtp.gmail.com with ESMTPSA id t7-v6sm4433169ite.35.2018.05.18.09.43.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 09:43:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-4C984B08-B5C5-4170-A8D0-C74980C00004 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Fri, 18 May 2018 12:43:29 -0400 Cc: David Waite , Hannes Tschofenig , Brock Allen , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> To: John Bradley Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:43:38 -0000 --Apple-Mail-4C984B08-B5C5-4170-A8D0-C74980C00004 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A few notes: > The session cookie should also be flagged as http only to protect it. =20 This provides no real protection. If I get XSS into your site I don=E2=80=99= t need to steal the cookie. I can just force requests that will automaticall= y send it (client side or stored request forgery). So while it=E2=80=99s a s= tandard suggestion, it helps little.=20 > Having a refresh token in local storrage may introduce new security issues= unless it is token bound. =20 Token binding is not live yet, right? If you need to store a token in a brow= ser please note there is no safe place to store it. LocalStorage can be harv= ested by XSS and even the strongest cookies can be replayed as discussed abo= ve. I can=E2=80=99t wait for browser based token binding! But it will likely= take years for this to be avail in the majority of browsers. > Understanding the security issues of the code flow in the browser is impor= tant, before any new recommendation. =20 Well said. It looks to be the only secure workflow for browser based apps. L= ove it how passwords are kept away from RP=E2=80=99s and high powered tokens= are not stored in the browser. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 12:27 PM, John Bradley wrote: >=20 > Yes that was the original intent to have the AT be short lived and refresh= the AT via the authorization endpoint based on the session cookie. =20 >=20 > The session cookie should also be flagged as http only to protect it. =20 >=20 > Having a refresh token in local storrage may introduce new security issues= unless it is token bound. =20 >=20 > Understanding the security issues of the code flow in the browser is impor= tant, before any new recommendation. =20 >=20 > John B.=20 >=20 > From: Brock Allen > Sent: Friday, May 18, 2:46 PM > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > To: David Waite, Hannes Tschofenig > Cc: oauth@ietf.org >=20 >=20 > One thing I maybe should have listed in the pros/cons in my original email= is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow.=20 >=20 > What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously ot= her flows make more sense to obtain longer lived access (via refresh tokens)= , but I don't know about a browser-based JS app. In a sense there's a bit of= protection for the end user built into that design by virtue of being tied t= o the user's cookie at the AS/OP.=20 >=20 > Just throwing that out as an additional discussion point. >=20 > -Brock=20 >=20 >> On 5/18/2018 6:04:47 AM, David Waite wrote= : >> I have written some guidance already (in non-RFC format) on preferring co= de for single page apps, and other security practices (CORS, CSP). =46rom th= e AS point of view, it aligns well with the native apps BCP. There are benef= its of thinking about native and SPA apps just as =E2=80=98public clients=E2= =80=99 from a policy/properties point of view. It also greatly simplifies OA= uth/OIDC support on both the AS administrator and client developer side when= converting web properties into native apps using technologies like Electron= or Cordova.=20 >>=20 >> For the later requirements in the list around token policy, I am not sure= these are requirements for single page apps per se. I don=E2=80=99t believe= the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native ap= plications. Rather they seem to be a function of usage patterns that an AS m= ay need to support, and we happen to sometimes associate those usage pattern= s with typical usage of native apps vs of browser apps. For example, browser= login on a borrowed device can easily leak over to being app authorization -= the authentication/authorization are web-based processes to achieve SSO. >>=20 >> I have been working on some guidance here around token lifetimes and poli= cies, but I don=E2=80=99t know whether that brings in too much AS/OP busines= s logic (and, likely implied product/deployment features) to be industry pra= ctices. >>=20 >> -DW >>=20 >>> On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: >>>=20 >>> Hi Brock, >>> =20 >>> there have been several attempts to start writing some guidance but so f= ar we haven=E2=80=99t gotten too far. >>> IMHO it would be great to have a document. >>> =20 >>> Ciao >>> Hannes >>> =20 >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen >>> Sent: 17 May 2018 14:57 >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>> =20 >>> Much like updated guidance was provided with the "OAuth2 for native apps= " RFC, should there be one for "browser-based client-side JS apps"? I ask be= cause google is actively discouraging the use of implicit flow: >>> =20 >>> https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >>> =20 >>> >=46rom what I can tell, the complaints with implicit are: >>> * access token in URL >>> * access token in browser history >>> * iframe complexity when using prompt=3Dnone to "refresh" access tokens >>> =20 >>> But this requires: >>> * AS/OP to support PKCE >>> * AS/OP to support CORS=20 >>> * user-agent must support CORS >>> * AS/OP to maintain short-lived refresh tokens=20 >>> * AS/OP must aggressively revoke refresh tokens at user signout (which i= s not something OAuth2 "knows" about) >>> * if the above point can't work, then client must proactively use revoca= tion endpoint if/when user triggers logout >>> =20 >>> Any use in discussing this? >>> =20 >>> -Brock >>> =20 >>> 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 an= y other person, use it for any purpose, or store or copy the information in a= ny medium. Thank you. _______________________________________________ >>> OAuth mailing list >>> 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 --Apple-Mail-4C984B08-B5C5-4170-A8D0-C74980C00004 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable A few notes:

> The session cookie should also b= e flagged as http only to protect it.  

= This provides no real protection. If I get XSS into your site I don=E2=80=99= t need to steal the cookie. I can just force requests that will automaticall= y send it (client side or stored request forgery). So while it=E2=80=99s a s= tandard suggestion, it helps little. 

>&nbs= p;Having a refresh= token in local storrage may introduce new security issues unless it is toke= n bound.  

Token binding is not li= ve yet, right? If you need to store a token in a browser please note there i= s no safe place to store it. LocalStorage can be harvested by XSS and even t= he strongest cookies can be replayed as discussed above. I can=E2=80=99t wai= t for browser based token binding! But it will likely take years for this to= be avail in the majority of browsers.

> Understanding the se= curity issues of the code flow in the browser is important, before any new r= ecommendation.  

Well said. It loo= ks to be the only secure workflow for browser based apps. Love it how passwo= rds are kept away from RP=E2=80=99s and high powered tokens are not stored i= n the browser.

Aloha,
--
Jim Manico
@Manicode
Secure Codin= g Education
+1 (808) 652-3805

On May 18, 2018,= at 12:27 PM, John Bradley <ve7jtb@v= e7jtb.com> wrote:

Yes that was the original intent to have the AT be short lived and refresh t= he AT via the authorization endpoint based on the session cookie. 

The session cookie should also be flagged as http only to protect it.  <= br>
Having a refresh token in local storrage may introduce new security issues u= nless it is token bound. 

Understanding the security issues of the code flow in the browser is importa= nt, before any new recommendation. 

John B.

From: Brock Allen
Sent: Friday, May 18, 2:46 PM
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
To: David Waite, Hannes Tschofenig
One thing I maybe should have listed in the pros/cons in my original email i= s session management and token lifetime considerations, keeping in mind the o= riginal intent of the implicit flow.

What I mean is that with implicit grant type, the client's ability to get ne= w access tokens is limited to the user's session at the AS/OP. Obviously oth= er flows make more sense to obtain longer lived access (via refresh tokens),= but I don't know about a browser-based JS app. In a sense there's a bit of protection for the end user built into t= hat design by virtue of being tied to the user's cookie at the AS/OP.

Just throwing that out as an additional discussion point.

-Brock

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> wrote:
I have written some guidance already (in non-RFC format) on preferring c= ode for single page apps, and other security practices (CORS, CSP). =46rom t= he AS point of view, it aligns well with the native apps BCP. There are bene= fits of thinking about native and SPA apps just as =E2=80=98public clients=E2=80=99 from a policy/properties poin= t of view. It also greatly simplifies OAuth/OIDC support on both the AS admi= nistrator and client developer side when converting web properties into nati= ve apps using technologies like Electron or Cordova.

For the later requirements in the list around token policy, I am not sure th= ese are requirements for single page apps per se. I don=E2=80=99t believe th= e need for a policy using short-lived refresh tokens, revoking at signout, o= r use of the revocation endpoint are different from browser and native applications. Rather they seem to be a fu= nction of usage patterns that an AS may need to support, and we happen to so= metimes associate those usage patterns with typical usage of native apps vs o= f browser apps. For example, browser login on a borrowed device can easily leak over to being app author= ization - the authentication/authorization are web-based processes to achiev= e SSO.

I have been working on some guidance here around token lifetimes and policie= s, but I don=E2=80=99t know whether that brings in too much AS/OP business l= ogic (and, likely implied product/deployment features) to be industry practi= ces.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Brock,
 
there have been several attempts to start writing some guidance but so far w= e haven=E2=80=99t gotten too far.
IMHO it would be great to have a document.
 
Ciao
Hannes
 
From: OAuth [mailto:oa= uth-bounces@ietf.org] On Behalf Of Brock Allen
Sent: 17 May 2018 14:57
Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?<= br>
 
Much like updated guidance was provided with the "OAuth2 for native apps" RFC= , should there be one for "browser-based client-side JS apps"? I ask because= google is actively discouraging the use of implicit flow:
 
 
>=46rom what I can tell, the complaints with implicit are:
* access token in URL
* access token in browser history
* iframe complexity when using prompt=3Dnone to "refresh" access tokens
 
But this requires:
* AS/OP to support PKCE
* AS/OP to support CORS 
* user-agent must support CORS
* AS/OP to maintain short-lived refresh tokens 
* AS/OP must aggressively revoke refresh tokens at user signout (which is no= t something OAuth2 "knows" about)
* if the above point can't work, then client must proactively use revocation= endpoint if/when user triggers logout
 
Any use in discussing this?
 
-Brock
 
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 medium. Thank you. ___________= ____________________________________
OAuth mailing list



____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-4C984B08-B5C5-4170-A8D0-C74980C00004-- From nobody Fri May 18 09:47: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 7268712D86B for ; Fri, 18 May 2018 09:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 18Iynn4G43jq for ; Fri, 18 May 2018 09:47:51 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909ED12D7F6 for ; Fri, 18 May 2018 09:47:50 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id w194-v6so15098354wmf.2 for ; Fri, 18 May 2018 09:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=iEOhxOeuoizHLBg9pxsyS11u5E1+0AMgX/rqXK2I4ic=; b=fu47PQucM/bvpENZjEUmfLEF1RRR0bJYP9IRn8W5Qti3ewy+zMWm8UjTyEWvxxD/0n xfQuEMbSs7JOvZJVxIAk+lQ3B4y8Apg6Fv8E1+KYICPA1PB0InQQkSHL5HGHDXGTEBsR XdFdg+/Uxz4p+xrGhL+/13IbUVUAaGWVeQHgHHfo7J7FDgUsYHae6IT4lSa6lqI+KeSj CpD48uCZdizThMkAv1MtqnaZAICyGt/eyd04UNYMBYUhoclPoLf4Xk+Cz3sjR0Dsjouk B6E8giF7RHNfd0xME7ohvn3+WVoyYLZYZvgOVbOkp2f2r0P0MEbv6rKvcMH4IIUAa4Xw ejPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=iEOhxOeuoizHLBg9pxsyS11u5E1+0AMgX/rqXK2I4ic=; b=cir6X4MUyjYLE6VvdmlL/vrOuHpnI1leulX7Lk1Gz8dpH4q7ffT4vliZ+VAI0C7Nng osNT6Gwqzf+BXSBBxnFlRfwUgw+9geT5WNpv29C8pO/kzfWDKcgbSSRybPyMRT10kHsZ L4XSdCbNLJPyifK0CkvheH9qSA89e3yfcCxasKAxUtrugUa8a2uRtSxpYP5Bh3swJGD5 suDP8O1b/6gxlrEynpQp3wFqVx5T71JjXXC3JsvrUQQhA8x4T3Fz7uwtRrmE8acxPICU I3UHm0jXtASgECmTpZKSIH2wkfJqpzA8BZAm3bOclCGC95KetoTJMVjjLsiGfeiHkxxo ieQw== X-Gm-Message-State: ALKqPwd00yKOfKYsbWdfywJRltza4AdZ1vKbU0ZwuFP4XO/NarVNmraU Jxi7WZyoNG3BG/TzNcyZsDEv+A== X-Google-Smtp-Source: AB8JxZr2x5+HpReFQLCij+EEzHgDa5sSkZY5zSr0XMwAj4w9eTdmhZlwCMgX9Q74iIxVkEUvhDXJgQ== X-Received: by 2002:a1c:700d:: with SMTP id l13-v6mr4730311wmc.81.1526662068581; Fri, 18 May 2018 09:47:48 -0700 (PDT) Received: from ?IPv6:2001:1b18:a3:300:9cdb:2d14:3eec:54a3? ([2001:1b18:a3:300:9cdb:2d14:3eec:54a3]) by smtp.gmail.com with ESMTPSA id 12-v6sm13147879wmn.27.2018.05.18.09.47.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 09:47:47 -0700 (PDT) Message-ID: <5aff03b3.1c69fb81.a01df.2946@mx.google.com> MIME-Version: 1.0 To: Brock Allen , David Waite , Hannes Tschofenig Cc: "oauth@ietf.org" From: John Bradley Date: Fri, 18 May 2018 18:47:48 +0200 Importance: normal X-Priority: 3 In-Reply-To: <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> Content-Type: multipart/alternative; boundary="_35C3E3DF-A302-453C-A94A-97BDBBB39283_" Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:47:55 -0000 --_35C3E3DF-A302-453C-A94A-97BDBBB39283_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" There are lots of issues with the current implicit flow around fragment enc= oding as well. However moving the token used for refresh from being a HTTP only cookie to = a refresh token available in the DOM makes me uncomfortable without having = sufficient mitigations against XSS. The current flow is vulnerable to XSS for the AT, however if that is short= lived it restricts the damage. The better solution is token binding the AT and perhaps a RT. =20 We need to start talking about it. There are issues around potentially usi= ng service workers etc as well. So we should start but I am not sure of what the correct answer is yet. John B. Sent from Mail for Windows 10 From: Brock Allen Sent: Friday, May 18, 2018 6:36 PM To: John Bradley; David Waite; Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? It sounds to me as if you're hesitant to recommend code flow (at least for = now) then for browser-based JS apps. -Brock On 5/18/2018 12:27:48 PM, John Bradley wrote: Yes that was the original intent to have the AT be short lived and refresh = the AT via the authorization endpoint based on the session cookie.=C2=A0=20 The session cookie should also be flagged as http only to protect it.=C2=A0= =20 Having a refresh token in local storrage may introduce new security issues = unless it is token bound.=C2=A0=20 Understanding the security issues of the code flow in the browser is import= ant, before any new recommendation.=C2=A0=20 John B.=20 From: Brock Allen Sent: Friday, May 18, 2:46 PM Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? To: David Waite, Hannes Tschofenig Cc: oauth@ietf.org One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow.=20 What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit= of protection for the end user built into that design by virtue of being t= ied to the user's cookie at the AS/OP.=20 Just throwing that out as an additional discussion point. -Brock=20 On 5/18/2018 6:04:47 AM, David Waite wrote: I have written some guidance already (in non-RFC format)=C2=A0on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =E2=80=98public client= s=E2=80=99 from a policy/properties point of view. It also greatly simplifi= es OAuth/OIDC support on both the AS administrator and client developer sid= e when converting web properties into native apps using technologies like E= lectron or Cordova.=20 For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe = the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS= may need to support, and we happen to sometimes associate those usage patt= erns with typical usage of native apps vs of browser apps. For example, bro= wser login on a borrowed device can easily leak over to being app authoriza= tion - the authentication/authorization are web-based processes to achieve = SSO. I have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry pra= ctices. -DW On May 17, 2018, at 10:23 AM, Hannes Tschofenig = wrote: Hi Brock, =C2=A0 there have been several attempts to start writing some guidance but so far = we haven=E2=80=99t gotten too far. IMHO it would be great to have a document. =C2=A0 Ciao Hannes =C2=A0 From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Bro= ck Allen Sent:=C2=A017 May 2018 14:57 To:=C2=A0oauth@ietf.org Subject:=C2=A0[OAUTH-WG] is updated guidance needed for JS/SPA apps? =C2=A0 Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: =C2=A0 https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 =C2=A0 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens =C2=A0 But this requires: * AS/OP to support PKCE *=C2=A0AS/OP to support=C2=A0CORS=C2=A0 * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens=C2=A0 * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout =C2=A0 Any use in discussing this? =C2=A0 -Brock =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.=C2=A0_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_35C3E3DF-A302-453C-A94A-97BDBBB39283_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

There are lots of issues with the cu= rrent implicit flow around fragment encoding as well.

 

However moving the token used = for refresh from being a HTTP only cookie to a refresh token available in t= he DOM makes me uncomfortable without having sufficient mitigations against= XSS.

 

The= current flow is vulnerable to =C2=A0XSS for the AT, however if that is sho= rt lived it restricts the damage.

 =

The better solution is token binding the AT and pe= rhaps a RT.=C2=A0

 

We need to start talking about it.=C2=A0 There are issues around = potentially using service workers etc as well.

 

So we should start but I am not sure = of what the correct answer is yet.

 

John B.

 =

Sent from Mail for Windows 10

&= nbsp;

From: Brock Allen
Sent: Friday, May 18, 2018 6:36 PM
<= b>To: John Bradley; David Waite; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] is= updated guidance needed for JS/SPA apps?

 

<= span style=3D'font-size:10.0pt;font-family:"Lucida Console";color:black'>It= sounds to me as if you're hesitant to recommend code flow (at least for no= w) then for browser-based JS apps.

 

-Brock=

 

On 5/18/2018 12:27:48 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:

Yes that was the original intent to have the AT be sho= rt lived and refresh the AT via the authorization endpoint based on the ses= sion cookie. 

The session cookie should also be flagged as http only to prot= ect it. 

Having a refresh token in local storrage may introduce new securi= ty issues unless it is token bound. 

=

Understanding the security issues of th= e code flow in the browser is important, before any new recommendation.&nbs= p;

Joh= n B.

From: Brock Allen

Sent: Friday, May 18, 2:46 PM

<= /div>

Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SP= A apps?

To: David Waite, Hannes Tschof= enig

Cc= : oauth@ietf.org

One thing I maybe should have listed in the pros/cons in = my original email is session management and token lifetime considerations, = keeping in mind the original intent of the implicit flow.

What I mean is that wit= h implicit grant type, the client's ability to get new access tokens is lim= ited to the user's session at the AS/OP. Obviously other flows make more se= nse to obtain longer lived access (via refresh tokens), but I don't know ab= out a browser-based JS app. In a sense there's a bit of protection for the = end user built into that design by virtue of being tied to the user's cooki= e at the AS/OP.

Just throwing that out as an additional discussion point.

-Brock

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solu= tions.com> wrote:

I have written some guidance already (in non-RFC format) = ;on preferring code for single page apps, and other security practices (COR= S, CSP). From the AS point of view, it aligns well with the native apps BCP= . There are benefits of thinking about native and SPA apps just as =E2=80= =98public clients=E2=80=99 from a policy/properties point of view. It also = greatly simplifies OAuth/OIDC support on both the AS administrator and clie= nt developer side when converting web properties into native apps using tec= hnologies like Electron or Cordova.

For the later requirements in the list around= token policy, I am not sure these are requirements for single page apps pe= r se. I don=E2=80=99t believe the need for a policy using short-lived refre= sh tokens, revoking at signout, or use of the revocation endpoint are diffe= rent from browser and native applications. Rather they seem to be a functio= n of usage patterns that an AS may need to support, and we happen to someti= mes associate those usage patterns with typical usage of native apps vs of = browser apps. For example, browser login on a borrowed device can easily le= ak over to being app authorization - the authentication/authorization are w= eb-based processes to achieve SSO.

I have been working on some guidance here aroun= d token lifetimes and policies, but I don=E2=80=99t know whether that bring= s in too much AS/OP business logic (and, likely implied product/deployment = features) to be industry practices.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Brock,

 

there have been several = attempts to start writing some guidance but so far we haven=E2=80=99t gotte= n too far.

IMHO it would be great to h= ave a document.

 

Ciao

Hannes=

 

From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Brock Allen

Sent: 17 May 2018 14:57

Subject: [OAUTH-WG] is updated guidan= ce needed for JS/SPA apps?

 =

Much like updated guidance was provided wi= th the "OAuth2 for native apps" RFC, should there be one for &quo= t;browser-based client-side JS apps"? I ask because google is actively= discouraging the use of implicit flow:

 

 

From what I can= tell, the complaints with implicit are:

* access token in URL

* access toke= n in browser history

<= span style=3D'font-family:"Arial",sans-serif;color:black'>* iframe complexi= ty when using prompt=3Dnone to "refresh" access tokens=

 

But= this requires:

* AS/OP to support PKC= E

* AS/OP to support CORS&nb= sp;

* user-agent must support CORS

* AS/OP to maintain short-lived refresh t= okens 

* AS/OP must aggressively = revoke refresh tokens at user signout (which is not something OAuth2 "= knows" about)

* if the above poin= t can't work, then client must proactively use revocation endpoint if/when = user triggers logout

<= span style=3D'font-family:"Arial",sans-serif;color:black'> =

Any use in discussing this?

 

-Brock

 

I= MPORTANT NOTICE: The contents of this email and any attachments are confide= ntial and may also be privileged. If you are not the intended recipient, pl= ease 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 a= ny medium. Thank you. _______________________________________________<= o:p>

OAuth mailing list



 = ;

= --_35C3E3DF-A302-453C-A94A-97BDBBB39283_-- From nobody Fri May 18 09:53: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 5926D12E057 for ; Fri, 18 May 2018 09:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 deXuS1moPbLZ for ; Fri, 18 May 2018 09:53:32 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6A112E052 for ; Fri, 18 May 2018 09:53:29 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id l1-v6so16412891wmb.2 for ; Fri, 18 May 2018 09:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=6BpC2HkS7Mdrr2oT14ridVKIIqp4MkOzYRx7sAb3MOM=; b=LAqtUnwAS0T6/fcnaFIKN4CWMi2eAvVTBB6QHyUgWCgZmjPUWNSExx3a+gooJJJyIP qDX/uW4lk21x9AGo/6eoBoQBaR774mD7/xxSohFZSPPCMcV5a9lzuBTf1IKyQzlfOwe9 najcgiZgoWHZC2YAAed+qYEFF29yOuckOSVgIb5L2q+U8r+pO/yR4PQ+egCKOs4Vo3PL 6to1BSWvHpTRA7a4umrBn+eyWnaG8iiNTm65AbXEGnKwj/WTFFXufvp1GnLPjK3ZGFUW uYn7tHqeE+RQnxLqwxfn0Smtb01SAe9Dt3Tj38tsQrDjjzjo5GUPW0OM2uB6eH/IbuuQ F1Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=6BpC2HkS7Mdrr2oT14ridVKIIqp4MkOzYRx7sAb3MOM=; b=Sw81VmVt9Ae/omCVIO2zGz0m+KILxe9w4EbTv6Gx4UpeZ6w7UZYCtrO3ayqt0QaYgV IeNIg0xbN3+1yn2ffyyhn38dJJ8rqDujwwQEpjooBPL3BL+BwRlRzDdG2eb90fAO07js 5PtcPe809o9zHAzJgsAQiiPzd6DLAbEC+Dr2xqN4biIvkqKBl6hjFKnQ+8kzBzum39j6 ofkM0m0MPsyo0+EykrMn1FfYHNxO1wWQQeL2P8/B51kL0yY54KngWWzyJB2S2sCvex3x huX4p6X8bn2p8xbFuuAldTCsKYiHkMX99RMX52Vc2YT+NdvcCmidzAmH9Th36C4m6dLn uOSQ== X-Gm-Message-State: ALKqPwfBD3poIn8ZQAmjhO8/RdV7PV/sSS3FnYKvxyiDN1OpsNRlq1M8 6f/2tn1sMuGVhrotc+VtsoNJ9tj9iuE= X-Google-Smtp-Source: AB8JxZr8yUmexM0/180M5tgUXHrKDOt08MQvO3VmIUJ2GGoHnZGy9Jmq0yBRr1ga73FNPET2eRYKJw== X-Received: by 2002:a1c:690f:: with SMTP id e15-v6mr4838946wmc.34.1526662407401; Fri, 18 May 2018 09:53:27 -0700 (PDT) Received: from ?IPv6:2001:1b18:a3:300:9cdb:2d14:3eec:54a3? ([2001:1b18:a3:300:9cdb:2d14:3eec:54a3]) by smtp.gmail.com with ESMTPSA id p189-v6sm8236918wmg.18.2018.05.18.09.53.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 09:53:26 -0700 (PDT) Message-ID: <5aff0506.1c69fb81.2bfe1.51aa@mx.google.com> MIME-Version: 1.0 To: Jim Manico Cc: David Waite , Hannes Tschofenig , Brock Allen , "oauth@ietf.org" From: John Bradley Date: Fri, 18 May 2018 18:53:27 +0200 Importance: normal X-Priority: 3 In-Reply-To: <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> Content-Type: multipart/alternative; boundary="_A8F95807-2504-4210-A265-8A71061A2C83_" Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:53:45 -0000 --_A8F95807-2504-4210-A265-8A71061A2C83_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Token binding was just approved by the IESG (one more editorial pass to inc= lude some non normative input then on to the RFC editor) . It is enabled by default for Edge and IE on win 10. It is configurable on = Chrome but currently defaulted to off. I expect that to change in the near future. =20 Mozilla could use more resources so they can prioritize it. =20 Safari is of course anyone=E2=80=99s guess.=20 I don=E2=80=99t expect it to be years before it deployed widely enough to s= upport. =20 John B. Sent from Mail for Windows 10 From: Jim Manico Sent: Friday, May 18, 2018 6:43 PM To: John Bradley Cc: David Waite; Hannes Tschofenig; Brock Allen; oauth@ietf.org Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? A few notes: >=C2=A0The session cookie should also be flagged as http only to protect it= .=C2=A0=C2=A0 This provides no real protection. If I get XSS into your site I don=E2=80= =99t need to steal the cookie. I can just force requests that will automati= cally send it (client side or stored request forgery). So while it=E2=80=99= s a standard suggestion, it helps little.=C2=A0 >=C2=A0Having a refresh token in local storrage may introduce new security = issues unless it is token bound.=C2=A0=C2=A0 Token binding is not live yet, right? If you need to store a token in a bro= wser please note there is no safe place to store it. LocalStorage can be ha= rvested by XSS and even the strongest cookies can be replayed as discussed = above. I can=E2=80=99t wait for browser based token binding! But it will li= kely take years for this to be avail in the majority of browsers. >=C2=A0Understanding the security issues of the code flow in the browser is= important, before any new recommendation.=C2=A0=C2=A0 Well said. It looks to be the only secure workflow for browser based apps. = Love it how passwords are kept away from RP=E2=80=99s and high powered toke= ns are not stored in the browser. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 On May 18, 2018, at 12:27 PM, John Bradley wrote: Yes that was the original intent to have the AT be short lived and refresh = the AT via the authorization endpoint based on the session cookie.=C2=A0=20 The session cookie should also be flagged as http only to protect it.=C2=A0= =20 Having a refresh token in local storrage may introduce new security issues = unless it is token bound.=C2=A0=20 Understanding the security issues of the code flow in the browser is import= ant, before any new recommendation.=C2=A0=20 John B.=20 From: Brock Allen Sent: Friday, May 18, 2:46 PM Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? To: David Waite, Hannes Tschofenig Cc: oauth@ietf.org One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow.=20 What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit= of protection for the end user built into that design by virtue of being t= ied to the user's cookie at the AS/OP.=20 Just throwing that out as an additional discussion point. -Brock=20 On 5/18/2018 6:04:47 AM, David Waite wrote: I have written some guidance already (in non-RFC format)=C2=A0on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =E2=80=98public client= s=E2=80=99 from a policy/properties point of view. It also greatly simplifi= es OAuth/OIDC support on both the AS administrator and client developer sid= e when converting web properties into native apps using technologies like E= lectron or Cordova.=20 For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe = the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS= may need to support, and we happen to sometimes associate those usage patt= erns with typical usage of native apps vs of browser apps. For example, bro= wser login on a borrowed device can easily leak over to being app authoriza= tion - the authentication/authorization are web-based processes to achieve = SSO. I have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry pra= ctices. -DW On May 17, 2018, at 10:23 AM, Hannes Tschofenig = wrote: Hi Brock, =C2=A0 there have been several attempts to start writing some guidance but so far = we haven=E2=80=99t gotten too far. IMHO it would be great to have a document. =C2=A0 Ciao Hannes =C2=A0 From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Bro= ck Allen Sent:=C2=A017 May 2018 14:57 To:=C2=A0oauth@ietf.org Subject:=C2=A0[OAUTH-WG] is updated guidance needed for JS/SPA apps? =C2=A0 Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: =C2=A0 https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 =C2=A0 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens =C2=A0 But this requires: * AS/OP to support PKCE *=C2=A0AS/OP to support=C2=A0CORS=C2=A0 * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens=C2=A0 * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout =C2=A0 Any use in discussing this? =C2=A0 -Brock =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.=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 --_A8F95807-2504-4210-A265-8A71061A2C83_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Token binding was just approved by t= he IESG (one more editorial pass to include some non normative input then o= n to the RFC editor) .

 

It is enabled by default for Edge and IE on win 10.=C2=A0 It = is configurable on Chrome but currently defaulted to off.

I expect that to change in the near future.=C2=A0=C2=A0

 

Mozilla could use mo= re resources so they can prioritize it.=C2=A0


= Safari is of course anyone=E2=80=99s guess.

&= nbsp;

I don=E2=80=99t expect it to be years b= efore it deployed widely enough to support.=C2=A0

=  

John B.

<= o:p> 

Sent from Mail for Windows 10

 

From: Jim Manico
Sent: Friday, May 18, 2018 6= :43 PM
To: John Bradley<= br>Cc: David Waite; Hannes Tschofenig; Brock Allen; oauth@ietf.org
Subject: Re: [OAUTH-WG] is update= d guidance needed for JS/SPA apps?

 = ;

A few notes:

> The session c= ookie should also be flagged as http only to protect it.  

 

This provides no real protection. If I get XSS into your site = I don=E2=80=99t need to steal the cookie. I can just force requests that wi= ll automatically send it (client side or stored request forgery). So while = it=E2=80=99s a standard suggestion, it helps little. 

 

> Having a refresh token in local storrage may introduce ne= w security issues unless it is token bound.  

 

Token binding is not live yet, right? If you need to store a token in = a browser please note there is no safe place to store it. LocalStorage can = be harvested by XSS and even the strongest cookies can be replayed as discu= ssed above. I can=E2=80=99t wait for browser based token binding! But it wi= ll likely take years for this to be avail in the majority of browsers.=

 

<= p class=3DMsoNormal>> Understanding the security issues of the code= flow in the browser is important, before any new recommendation. &nbs= p;

 

Well said. It looks to be the only secure workfl= ow for browser based apps. Love it how passwords are kept away from RP=E2= =80=99s and high powered tokens are not stored in the browser.

 

Aloha,

--

Jim Manico

@Manicode

=

Secure Coding Education

=

+1 (808) 652-3805


On May 18, 2018, at 12:2= 7 PM, John Bradley <ve7jtb@ve7jtb.c= om> wrote:

Yes tha= t was the original intent to have the AT be short lived and refresh the AT = via the authorization endpoint based on the session cookie. 

The session coo= kie should also be flagged as http only to protect it. 

Having a refresh tok= en in local storrage may introduce new security issues unless it is token b= ound. 

Understanding the security issues of the code flow in the browser is = important, before any new recommendation. 

John B.

From: Brock Allen

Sent: F= riday, May 18, 2:46 PM

Subject: Re: [O= AUTH-WG] is updated guidance needed for JS/SPA apps?

<= /div>

To: David Waite, Hannes Tschofenig

One thing I maybe should have listed in the pro= s/cons in my original email is session management and token lifetime consid= erations, keeping in mind the original intent of the implicit flow.

What I mean i= s that with implicit grant type, the client's ability to get new access tok= ens is limited to the user's session at the AS/OP. Obviously other flows ma= ke more sense to obtain longer lived access (via refresh tokens), but I don= 't know about a browser-based JS app. In a sense there's a bit of protectio= n for the end user built into that design by virtue of being tied to the us= er's cookie at the AS/OP.

Just throwing that out as an additional discussion poin= t.

-Bro= ck

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com&g= t; wrote:

I have written some guidance already (in non-RFC format) on preferr= ing code for single page apps, and other security practices (CORS, CSP). Fr= om the AS point of view, it aligns well with the native apps BCP. There are= benefits of thinking about native and SPA apps just as =E2=80=98public cli= ents=E2=80=99 from a policy/properties point of view. It also greatly simpl= ifies OAuth/OIDC support on both the AS administrator and client developer = side when converting web properties into native apps using technologies lik= e Electron or Cordova.

For the later requirements in the list around token policy= , I am not sure these are requirements for single page apps per se. I don= =E2=80=99t believe the need for a policy using short-lived refresh tokens, = revoking at signout, or use of the revocation endpoint are different from b= rowser and native applications. Rather they seem to be a function of usage = patterns that an AS may need to support, and we happen to sometimes associa= te those usage patterns with typical usage of native apps vs of browser app= s. For example, browser login on a borrowed device can easily leak over to = being app authorization - the authentication/authorization are web-based pr= ocesses to achieve SSO.

I have been working on some guidance here around token lif= etimes and policies, but I don=E2=80=99t know whether that brings in too mu= ch AS/OP business logic (and, likely implied product/deployment features) t= o be industry practices.

-DW

On M= ay 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Brock,

 <= o:p>

there have been several attempts to st= art writing some guidance but so far we haven=E2=80=99t gotten too far.

IMHO it would be great to have a document= .

 

Ciao

Hannes<= /p>

 

From: OAu= th [mailto:oauth-bounces@ietf.org= ] On Behalf Of Brock Allen

=

Sent: 17 May 2018 14:57

Subject: [OAUTH-WG] is updated guidance needed for = JS/SPA apps?

 <= /p>

Much like updated guidance was provided with the "O= Auth2 for native apps" RFC, should there be one for "browser-base= d client-side JS apps"? I ask because google is actively discouraging = the use of implicit flow:

 <= /o:p>

=  

>From what I can tell, the c= omplaints with implicit are:

* access = token in URL

* access token in browser= history

* iframe complexity when us= ing prompt=3Dnone to "refresh" access tokens

 

But this requi= res:

* AS/OP to support PKCE

* AS/OP to support CORS 

* user-agent must support CORS

* AS/OP to maintain short-lived refresh tokens =

* AS/OP must aggressively revoke refr= esh tokens at user signout (which is not something OAuth2 "knows"= about)

* if the above point can't wor= k, then client must proactively use revocation endpoint if/when user trigge= rs logout

 

Any use in discussing this?

 

-Brock=

 

IMPORTANT N= OTICE: The contents of this email and any attachments are confidential and = may also be privileged. If you are not the intended recipient, please notif= y the sender immediately and do not disclose the contents to any other pers= on, use it for any purpose, or store or copy the information in any medium.= Thank you. _______________________________________________=

OAuth mailing list

OAuth@ietf.org


=

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

 

= --_A8F95807-2504-4210-A265-8A71061A2C83_-- From nobody Fri May 18 09:54: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 893EB12DDD0 for ; Fri, 18 May 2018 09:53:44 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JfJsvHXryOSu for ; Fri, 18 May 2018 09:53:41 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 C2D0812E03A for ; Fri, 18 May 2018 09:53:40 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id z75-v6so6946932qkb.6 for ; Fri, 18 May 2018 09:53:40 -0700 (PDT) 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=1UsMDLTtAs6NgejkSf0lcbcgUTlViTrdWTZIIeivPmI=; b=MlnIhnqu2AvTHV7bLu/U4E4ZNYCJW2DYYguoo+p72oCmEKnP6BrPRstqav1fISEbub sKcNY2tqALT63GSQN7Tpf3XctzYyo9SWzslX19GE/4U6QWS3hNRjP3wYeNnSPpxHAhyA tAvoBaytMxf7P27o09Za6m/1IDB0E/Sbq9bgMRY1q3/GkjBBBbioEKKOQ6ocXBkyCFyQ gshrDfbaIK7Bta3xoWsRPkvq/S1xjb9X5+KL7duSPlBdgZVCmG/+PzlImvCs9J42LXMs nTGV4jLnisFV3kmuUs7GBNmFH4xSwxm8swxm6lB1+nGCXg4bq7Sf6nLGB+lpKv61DbSn QUsg== 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=1UsMDLTtAs6NgejkSf0lcbcgUTlViTrdWTZIIeivPmI=; b=Cy9bwV0wvxLEILfKkiM4iFmW8VBIAMJPXvZAnFZvRijx44E+xBxNbPDz8ZMfIWharW 0ugyaAGIplRBAUEcjQPbGDSh/6qs9PVOy2gBPn6b+phJtqoZl2JLo1fvSan4AAyBMF1Q KR59o4YIN4azvskiu2X/pRZuco8esLnRTxIm6im4dp5AVHVR5wqMoU4w2Okp6rLKs7qy wv2H9OEI0T8Wnl3fmFDfQO5J2SZZ+u+KHXRmNGnjTtORDwFcUrBOETikV67ZEChb/KfH hb0ieq2rl2FexgQ4V6zns1MCIvk2DdOxtvJakqOentJ4b6IeSV3OltUTkWG0IEJ8oJq/ tRbw== X-Gm-Message-State: ALKqPwcTmMeEg/qSMKy2boMKSXAVrcbASJvAAzXTWA/uFpHCidqHLv9G YH8WFkCOwS5NG4cPThoUUV8= X-Google-Smtp-Source: AB8JxZr7SBWaLm7gozQpLd6r33pnPCOjzb6uJobQdRIznB9Dvzu5ZxTxx+tqKzJdaom0BUX5QUWAQQ== X-Received: by 2002:a37:6c9:: with SMTP id 192-v6mr9861290qkg.365.1526662419756; Fri, 18 May 2018 09:53:39 -0700 (PDT) Received: from [172.20.10.3] ([172.58.233.201]) by smtp.gmail.com with ESMTPSA id s64-v6sm6110199qkl.85.2018.05.18.09.53.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 09:53:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_6800333.934340776764" MIME-Version: 1.0 Date: Fri, 18 May 2018 12:53:36 -0400 Message-ID: From: "Brock Allen" To: "John Bradley" , "David Waite" , "Hannes Tschofenig" Cc: "" In-Reply-To: <5aff03b3.1c69fb81.a01df.2946@mx.google.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> User-Agent: Mailbird/2.5.8.0 X-Mailbird-ID: c56c669d-24f3-4099-83b2-51942a2bce61@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:53:51 -0000 ------=_NextPart_6800333.934340776764 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Fair enough, and I'm happy that this discussion has started.=C2=A0 For now, IMO, CSP is a big help in protecting these types of apps. Token bi= nding will of course help too, once it's available/practical. -Brock On 5/18/2018 12:47:49 PM, John Bradley wrote: There are lots of issues with the current implicit flow around fragment enc= oding as well. =C2=A0 However moving the token used for refresh from being a HTTP only cookie to = a refresh token available in the DOM makes me uncomfortable without having = sufficient mitigations against XSS. =C2=A0 The current flow is vulnerable to =C2=A0XSS for the AT, however if that is = short lived it restricts the damage. =C2=A0 The better solution is token binding the AT and perhaps a RT.=C2=A0 =C2=A0 We need to start talking about it.=C2=A0 There are issues around potentiall= y using service workers etc as well. =C2=A0 So we should start but I am not sure of what the correct answer is yet. =C2=A0 John B. =C2=A0 Sent from Mail [https://go.microsoft.com/fwlink/?LinkId=3D550986] for Windo= ws 10 =C2=A0 From: Brock Allen [mailto:brockallen@gmail.com] Sent: Friday, May 18, 2018 6:36 PM To: John Bradley [mailto:ve7jtb@ve7jtb.com]; David Waite [mailto:david@alka= line-solutions.com]; Hannes Tschofenig [mailto:hannes.tschofenig@arm.com] Cc: oauth@ietf.org [mailto:oauth@ietf.org] Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? =C2=A0 It sounds to me as if you're hesitant to recommend code flow (at least for = now) then for browser-based JS apps. =C2=A0 -Brock =C2=A0 On 5/18/2018 12:27:48 PM, John Bradley wrote: Yes that was the original intent to have the AT be short lived and refresh = the AT via the authorization endpoint based on the session cookie.=C2=A0 The session cookie should also be flagged as http only to protect it.=C2=A0 Having a refresh token in local storrage may introduce new security issues = unless it is token bound.=C2=A0 Understanding the security issues of the code flow in the browser is import= ant, before any new recommendation.=C2=A0 John B. From: Brock Allen Sent: Friday, May 18, 2:46 PM Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? To: David Waite, Hannes Tschofenig Cc: oauth@ietf.org One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow. What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit= of protection for the end user built into that design by virtue of being t= ied to the user's cookie at the AS/OP. Just throwing that out as an additional discussion point. -Brock On 5/18/2018 6:04:47 AM, David Waite wrote: I have written some guidance already (in non-RFC format)=C2=A0on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =E2=80=98public client= s=E2=80=99 from a policy/properties point of view. It also greatly simplifi= es OAuth/OIDC support on both the AS administrator and client developer sid= e when converting web properties into native apps using technologies like E= lectron or Cordova. For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe = the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS= may need to support, and we happen to sometimes associate those usage patt= erns with typical usage of native apps vs of browser apps. For example, bro= wser login on a borrowed device can easily leak over to being app authoriza= tion - the authentication/authorization are web-based processes to achieve = SSO. I have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry pra= ctices. -DW On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: Hi Brock, =C2=A0 there have been several attempts to start writing some guidance but so far = we haven=E2=80=99t gotten too far. IMHO it would be great to have a document. =C2=A0 Ciao Hannes =C2=A0 From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.= org]]=C2=A0On Behalf Of=C2=A0Brock Allen Sent:=C2=A017 May 2018 14:57 To:=C2=A0oauth@ietf.org [mailto:oauth@ietf.org] Subject:=C2=A0[OAUTH-WG] is updated guidance needed for JS/SPA apps? =C2=A0 Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: =C2=A0 https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 [http= s://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290] =C2=A0 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens =C2=A0 But this requires: * AS/OP to support PKCE *=C2=A0AS/OP to support=C2=A0CORS=C2=A0 * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens=C2=A0 * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout =C2=A0 Any use in discussing this? =C2=A0 -Brock =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.=C2=A0_______________________________________________ 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] =C2=A0 ------=_NextPart_6800333.934340776764 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A Fair enou= gh, and I'm happy that this discussion has started. 

For now, IMO, CSP is a big help in protecting these types of apps. Token = binding will of course help too, once it's available/practical.
<= br>
-Brock

=0A <= p style=3D"color: #AAAAAA; margin-top: 10px;">On 5/18/2018 12:47:49 PM, Joh= n Bradley <ve7jtb@ve7jtb.com> wrote:

<= p class=3D"MsoNormal">There are lots of issues with the current implicit fl= ow around fragment encoding as well.

 <= /o:p>

However moving the token used for refresh f= rom being a HTTP only cookie to a refresh token available in the DOM makes = me uncomfortable without having sufficient mitigations against XSS.

 

The current = flow is vulnerable to  XSS for the AT, however if that is short lived = it restricts the damage.

 

The better solution is token binding the AT and perhaps= a RT. 

 

We need to start talking about it.  There are issues around p= otentially using service workers etc as well.

 

So we should start but I am not su= re of what the correct answer is yet.

 =

John B.

&nb= sp;

Sent from Mail for Windows 10

 

From: Brock Allen
Sent: Friday, May 18, = 2018 6:36 PM
To: John Bradle= y; David Waite; Hannes Tschofenig
Cc: <= /b>oauth@ietf.org
Subject: = Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

 

It sounds to me as if you're hesitant to re= commend code flow (at least for now) then for browser-based JS apps.

 

-Brock

 

<= /div>

On 5/18/2018 12:27:48= PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes that was the original= intent to have the AT be short lived and refresh the AT via the authorizat= ion endpoint based on the session cookie. 

The session cookie sh= ould also be flagged as http only to protect it. 

Having a refre= sh token in local storrage may introduce new security issues unless it is t= oken bound. 

Understanding the security issues of the code flow = in the browser is important, before any new recommendation. 

Joh= n B.

From: Brock Allen

Sent: Friday, May 18, 2:46 P= M

Subject: Re: [OAUTH-WG] = is updated guidance needed for JS/SPA apps?

To: David Waite, Hannes Tschofenig

<= /div>

Cc: oauth@ietf.or= g

One thing I maybe should have listed in the pros/cons in my = original email is session management and token lifetime considerations, kee= ping in mind the original intent of the implicit flow.

What I mean is= that with implicit grant type, the client's ability to get new access toke= ns is limited to the user's session at the AS/OP. Obviously other flows mak= e more sense to obtain longer lived access (via refresh tokens), but I don'= t know about a browser-based JS app. In a sense there's a bit of protection= for the end user built into that design by virtue of being tied to the use= r's cookie at the AS/OP.

Just throwing that out as an additional disc= ussion point.

-Brock

On 5/18/2018 6= :04:47 AM, David Waite <david@alkaline-solutions.com> wrote:

I h= ave written some guidance already (in non-RFC format) on preferring co= de for single page apps, and other security practices (CORS, CSP). From the= AS point of view, it aligns well with the native apps BCP. There are benef= its of thinking about native and SPA apps just as =E2=80=98public clients= =E2=80=99 from a policy/properties point of view. It also greatly simplifie= s OAuth/OIDC support on both the AS administrator and client developer side= when converting web properties into native apps using technologies like El= ectron or Cordova.

For the later requirements in the list around toke= n policy, I am not sure these are requirements for single page apps per se.= I don=E2=80=99t believe the need for a policy using short-lived refresh to= kens, revoking at signout, or use of the revocation endpoint are different = from browser and native applications. Rather they seem to be a function of = usage patterns that an AS may need to support, and we happen to sometimes a= ssociate those usage patterns with typical usage of native apps vs of brows= er apps. For example, browser login on a borrowed device can easily leak ov= er to being app authorization - the authentication/authorization are web-ba= sed processes to achieve SSO.

I have been working on some guidance her= e around token lifetimes and policies, but I don=E2=80=99t know whether tha= t brings in too much AS/OP business logic (and, likely implied product/depl= oyment features) to be industry practices.

=

-DW

On May 17, 2018, at 10:23 AM, Hanne= s Tschofenig <Hannes.Tschof= enig@arm.com> wrote:

Hi Brock,

 

there have been several attempts = to start writing some guidance but so far we haven=E2=80=99t gotten too far= .

IMHO it would be great t= o have a document.

<= span style=3D"font-family:"Arial",sans-serif;color:black"> <= o:p>

Ciao

=

Hannes

 

<= span style=3D"font-family:"Arial",sans-serif;color:black">From: OAuth [mailto:oauth-boun= ces@ietf.org] On Behalf Of Brock Allen

Sent: 17 May 2018 14:57=

<= p class=3D"MsoNormal">Subject: [OAUTH-WG] is updated guidance needed= for JS/SPA apps?

 

Much like updated guidance = was provided with the "OAuth2 for native apps" RFC, should there be one for= "browser-based client-side JS apps"? I ask because google is actively disc= ouraging the use of implicit flow:

 

 

From what I can tell, the complaints with implici= t are:

* access token in= URL

* access token in bro= wser history

* iframe comp= lexity when using prompt=3Dnone to "refresh" access tokens

 

But this requires:

* AS/OP to support PKCE

* AS/OP to support CORS 

* user-agent must support CORS

=

* AS/OP to maintain short-lived refresh tokens&= nbsp;

* AS/OP must aggress= ively revoke refresh tokens at user signout (which is not something OAuth2 = "knows" about)

* if the ab= ove point can't work, then client must proactively use revocation endpoint = if/when user triggers logout

 

Any use in discu= ssing this?

 

-Brock

 

IMPORTANT NOTICE: The contents of this email and any attachments are co= nfidential and may also be privileged. If you are not the intended recipien= t, 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

<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth



=

 

=0A=
=0A = =0A
------=_NextPart_6800333.934340776764-- From nobody Fri May 18 10:03: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 24FFE12DA06 for ; Fri, 18 May 2018 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 1rSJ-MM_EnCH for ; Fri, 18 May 2018 10:03:45 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 0076112D7F6 for ; Fri, 18 May 2018 10:03:44 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 70-v6so13998932ity.2 for ; Fri, 18 May 2018 10:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=35/GHtReyEFgzRmpVwZzbrA3X0fWrOZSZC7+6qPVV74=; b=qMkk0Y+8nleB+X6fFRGmfPBLjFjCCGahKvRBcwQx8NKaWpa2wC2TWRHluZKkqqxEPv kCmGhKzH2ed9KkruQKHYBNv4buKAeaQ0mTBZQkmIdsBqlinvul1RXM+RQ15OWyv+fvWi eKeYy5XXQBvgSDpfnpoctw3BYFB2TCatCRg7zZWMniHyfWsldtBTh0nU5ezYz4fNudXB yTUFtb0NxDUQxw0h3D/kQ+rnStNTX1OK7B+NB9vZDmT/vjazT3XgvpcrXlC7dm87GFS0 YMA81ov4hxllzC4qznoMqMpgxKtXsmbsG4jrLx33DwOVDKiPcLTcr6zlEODiCnfv6hI1 XvtQ== 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=35/GHtReyEFgzRmpVwZzbrA3X0fWrOZSZC7+6qPVV74=; b=JZamlA8SbnvW3QVBkmYCk5Ecd2W27EJhu0B2mLe+qymu2CZP+O4fz4ZitmrnBeU/tI CsJus3bUIQomZRbYZx+pZGmji1Yu9TYswCIKuPIoRq69nUTqugN70FvriQhznh+Ly1vu vuZNjAyrjnFFD06cOF4WdYgzYPXYLV+NpxVhiXYC6qRU/dfFvy4rdD+nrL1qWcZOsXli m9B7koH0LdUVlK/Vq46OpRVXXxEH4tqP6wAyA+1E2RSPCCq+2pJmVH3ftGrL5HysAujx jgBYVkgZM8e3p3IweMuT79ZP6Pw+8CFWGma4KUCAkBZd+JpSTLMOPvsO8kHxRFBkYu6s l+Nw== X-Gm-Message-State: ALKqPweXKIn5ykoxy3MmsQjnAQ9thVMGKtfwxP1Ll348fuopv065xDSq nV5+FD9HHLLy7fbx1r1/zjUo6A== X-Google-Smtp-Source: AB8JxZqvbcElTKzr0sIPSwYTJ6kI/cqhyNUhlRNx7XfNacE3BrEQX5gIF1Bzn5gFFetlOQO9ZZIwLg== X-Received: by 2002:a24:d589:: with SMTP id a131-v6mr7901469itg.85.1526663024085; Fri, 18 May 2018 10:03:44 -0700 (PDT) Received: from [10.102.248.12] (mobile-166-176-251-17.mycingular.net. [166.176.251.17]) by smtp.gmail.com with ESMTPSA id e78-v6sm5236233ite.30.2018.05.18.10.03.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 10:03:43 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-DAB08E38-03CB-4236-98F3-D2FDCCD40ED1 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (15E302) In-Reply-To: <5aff0506.1c69fb81.2bfe1.51aa@mx.google.com> Date: Fri, 18 May 2018 13:03:41 -0400 Cc: David Waite , Hannes Tschofenig , Brock Allen , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <1B736F14-D444-42E3-85EF-43AB6FD37302@manicode.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> <5aff0506.1c69fb81.2bfe1.51aa@mx.google.com> To: John Bradley Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:03:49 -0000 --Apple-Mail-DAB08E38-03CB-4236-98F3-D2FDCCD40ED1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is really fantastic news. Thank you for sharing that John. I=E2=80=99m a= lot more optimistic about timely adoption. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 12:53 PM, John Bradley wrote: >=20 > Token binding was just approved by the IESG (one more editorial pass to in= clude some non normative input then on to the RFC editor) . > =20 > It is enabled by default for Edge and IE on win 10. It is configurable on= Chrome but currently defaulted to off. > I expect that to change in the near future. =20 > =20 > Mozilla could use more resources so they can prioritize it.=20 >=20 > Safari is of course anyone=E2=80=99s guess. > =20 > I don=E2=80=99t expect it to be years before it deployed widely enough to s= upport.=20 > =20 > John B. > =20 > Sent from Mail for Windows 10 > =20 > From: Jim Manico > Sent: Friday, May 18, 2018 6:43 PM > To: John Bradley > Cc: David Waite; Hannes Tschofenig; Brock Allen; oauth@ietf.org > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > =20 > A few notes: >=20 > > The session cookie should also be flagged as http only to protect it. =20= > =20 > This provides no real protection. If I get XSS into your site I don=E2=80=99= t need to steal the cookie. I can just force requests that will automaticall= y send it (client side or stored request forgery). So while it=E2=80=99s a s= tandard suggestion, it helps little.=20 > =20 > > Having a refresh token in local storrage may introduce new security issu= es unless it is token bound. =20 > =20 > Token binding is not live yet, right? If you need to store a token in a br= owser please note there is no safe place to store it. LocalStorage can be ha= rvested by XSS and even the strongest cookies can be replayed as discussed a= bove. I can=E2=80=99t wait for browser based token binding! But it will like= ly take years for this to be avail in the majority of browsers. > =20 > > Understanding the security issues of the code flow in the browser is imp= ortant, before any new recommendation. =20 > =20 > Well said. It looks to be the only secure workflow for browser based apps.= Love it how passwords are kept away from RP=E2=80=99s and high powered toke= ns are not stored in the browser. > =20 > Aloha, > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 >=20 > On May 18, 2018, at 12:27 PM, John Bradley wrote: >=20 > Yes that was the original intent to have the AT be short lived and refresh= the AT via the authorization endpoint based on the session cookie.=20 >=20 > The session cookie should also be flagged as http only to protect it.=20 >=20 > Having a refresh token in local storrage may introduce new security issues= unless it is token bound.=20 >=20 > Understanding the security issues of the code flow in the browser is impor= tant, before any new recommendation.=20 >=20 > John B. >=20 > From: Brock Allen > Sent: Friday, May 18, 2:46 PM > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > To: David Waite, Hannes Tschofenig > Cc: oauth@ietf.org >=20 >=20 > One thing I maybe should have listed in the pros/cons in my original email= is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow. >=20 > What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously ot= her flows make more sense to obtain longer lived access (via refresh tokens)= , but I don't know about a browser-based JS app. In a sense there's a bit of= protection for the end user built into that design by virtue of being tied t= o the user's cookie at the AS/OP. >=20 > Just throwing that out as an additional discussion point. >=20 > -Brock >=20 > On 5/18/2018 6:04:47 AM, David Waite wrote:= > I have written some guidance already (in non-RFC format) on preferring cod= e for single page apps, and other security practices (CORS, CSP). =46rom the= AS point of view, it aligns well with the native apps BCP. There are benefi= ts of thinking about native and SPA apps just as =E2=80=98public clients=E2=80= =99 from a policy/properties point of view. It also greatly simplifies OAuth= /OIDC support on both the AS administrator and client developer side when co= nverting web properties into native apps using technologies like Electron or= Cordova. >=20 > For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe t= he need for a policy using short-lived refresh tokens, revoking at signout, o= r use of the revocation endpoint are different from browser and native appli= cations. Rather they seem to be a function of usage patterns that an AS may n= eed to support, and we happen to sometimes associate those usage patterns wi= th typical usage of native apps vs of browser apps. For example, browser log= in on a borrowed device can easily leak over to being app authorization - th= e authentication/authorization are web-based processes to achieve SSO. >=20 > I have been working on some guidance here around token lifetimes and polic= ies, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry prac= tices. >=20 > -DW >=20 > On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: >=20 > Hi Brock, > =20 > there have been several attempts to start writing some guidance but so far= we haven=E2=80=99t gotten too far. > IMHO it would be great to have a document. > =20 > Ciao > Hannes > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen > Sent: 17 May 2018 14:57 > To: oauth@ietf.org > Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > =20 > Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask becau= se google is actively discouraging the use of implicit flow: > =20 > https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 > =20 > >=46rom what I can tell, the complaints with implicit are: > * access token in URL > * access token in browser history > * iframe complexity when using prompt=3Dnone to "refresh" access tokens > =20 > But this requires: > * AS/OP to support PKCE > * AS/OP to support CORS=20 > * user-agent must support CORS > * AS/OP to maintain short-lived refresh tokens=20 > * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) > * if the above point can't work, then client must proactively use revocati= on endpoint if/when user triggers logout > =20 > Any use in discussing this? > =20 > -Brock > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential 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 o= ther 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-DAB08E38-03CB-4236-98F3-D2FDCCD40ED1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is really fantastic news. Thank you fo= r sharing that John. I=E2=80=99m a lot more optimistic about timely adoption= .

Aloha,
--
<= div>Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On May 18, 2018, at 12:53 PM, John B= radley <ve7jtb@ve7jtb.com> wr= ote:

Token binding w= as just approved by the IESG (one more editorial pass to include some non no= rmative input then on to the RFC editor) .

&n= bsp;

It is enabled by default for Edge and I= E on win 10.  It is configurable on Chrome but currently defaulted to o= ff.

I expect that to change in the near future.&nb= sp; 

 

Mozilla could use more resources so they can prioritize it. 

<= p class=3D"MsoNormal">
Safari is of course anyone=E2=80=99s guess.

 

I don=E2=80= =99t expect it to be years before it deployed widely enough to support. = ;

 

Joh= n B.

 

S= ent from Mail for Windows 10

 

From: Jim Manico
Se= nt: Friday, May 18, 2018 6:43 PM
To: John Bradley
Cc: David Waite; Hannes Tschofenig; Brock Allen<= /a>; oauth@ietf.org
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

 

A few notes:
=
> The session cookie should also be flagged as http only to prot= ect it.  

 

This provides no real protection. I= f I get XSS into your site I don=E2=80=99t need to steal the cookie. I can j= ust force requests that will automatically send it (client side or stored re= quest forgery). So while it=E2=80=99s a standard suggestion, it helps little= . 

 

> Having a refresh token in local= storrage may introduce new security issues unless it is token bound. &= nbsp;

 

<= /div>

Token binding is not live yet, right? If yo= u need to store a token in a browser please note there is no safe place to s= tore it. LocalStorage can be harvested by XSS and even the strongest cookies= can be replayed as discussed above. I can=E2=80=99t wait for browser based t= oken binding! But it will likely take years for this to be avail in the majo= rity of browsers.

 = ;

> Understanding the sec= urity issues of the code flow in the browser is important, before any new re= commendation.  

 

Well said. It looks to b= e the only secure workflow for browser based apps. Love it how passwords are= kept away from RP=E2=80=99s and high powered tokens are not stored in the b= rowser.

 

Aloha,

--

Jim Manico

@Mani= code

Secure Coding Education=

+1 (808) 652-3805

=
On May 18, 2018, at 12:27 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes that was the original intent to have the AT= be short lived and refresh the AT via the authorization endpoint based on t= he session cookie. 

The session cookie should also be flagged as ht= tp only to protect it. 

Having a refresh token in local storrage ma= y introduce new security issues unless it is token bound.  <= /span>

<= span style=3D"font-family:"Arial",sans-serif;color:black">Understa= nding the security issues of the code flow in the browser is important, befo= re any new recommendation. 

John B.

From: Brock Allen

Sent: Friday, May 18, 2:46 PM

Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

To: David Waite, Hannes Tschofe= nig

O= ne thing I maybe should have listed in the pros/cons in my original email is= session management and token lifetime considerations, keeping in mind the o= riginal intent of the implicit flow.

What I mean is that with implicit g= rant type, the client's ability to get new access tokens is limited to the u= ser's session at the AS/OP. Obviously other flows make more sense to obtain l= onger lived access (via refresh tokens), but I don't know about a browser-ba= sed JS app. In a sense there's a bit of protection for the end user built in= to that design by virtue of being tied to the user's cookie at the AS/OP.

Just throwing that out as an additional discussion point.

-Brock

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> w= rote:

I have written some guidance already (in non-RFC format) on pr= eferring code for single page apps, and other security practices (CORS, CSP)= . =46rom the AS point of view, it aligns well with the native apps BCP. Ther= e are benefits of thinking about native and SPA apps just as =E2=80=98public= clients=E2=80=99 from a policy/properties point of view. It also greatly si= mplifies OAuth/OIDC support on both the AS administrator and client develope= r side when converting web properties into native apps using technologies li= ke Electron or Cordova.

For the later requirements in the list around to= ken policy, I am not sure these are requirements for single page apps per se= . I don=E2=80=99t believe the need for a policy using short-lived refresh to= kens, revoking at signout, or use of the revocation endpoint are different f= rom browser and native applications. Rather they seem to be a function of us= age patterns that an AS may need to support, and we happen to sometimes asso= ciate those usage patterns with typical usage of native apps vs of browser a= pps. For example, browser login on a borrowed device can easily leak over to= being app authorization - the authentication/authorization are web-based pr= ocesses to achieve SSO.

I have been working on some guidance here around t= oken lifetimes and policies, but I don=E2=80=99t know whether that brings in= too much AS/OP business logic (and, likely implied product/deployment featu= res) to be industry practices.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> w= rote:

Hi Brock,

 

<= p class=3D"MsoNormal">there have been several attempts to start writing some guidan= ce but so far we haven=E2=80=99t gotten too far.

=

IMHO it would be great to have a document.

 

<= p class=3D"MsoNormal">Ciao

<= span style=3D"font-family:"Arial",sans-serif;color:black">Hannes

 

<= /div>

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of&nbs= p;Brock Allen

= Sent: 17 May 2018 14:57

Subject: [OAUTH-WG] is up= dated guidance needed for JS/SPA apps?

 

Much like u= pdated guidance was provided with the "OAuth2 for native apps" RFC, should t= here be one for "browser-based client-side JS apps"? I ask because google is= actively discouraging the use of implicit flow:

=

 



___________________________________________= ____
OAuth mailing list
OAuth@ietf.o= rg
https://ww= w.ietf.org/mailman/listinfo/oauth

<= o:p> 

= --Apple-Mail-DAB08E38-03CB-4236-98F3-D2FDCCD40ED1-- From nobody Fri May 18 10:18: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 4157512D86B for ; Fri, 18 May 2018 10:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 kRb0gJEZOpKx for ; Fri, 18 May 2018 10:18:15 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 41825126BF3 for ; Fri, 18 May 2018 10:18:15 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id z4-v6so7046704iof.5 for ; Fri, 18 May 2018 10:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K01t0W9dDeaVEhbHVXYJoerIQaCGuYXgL9n65ofTLPI=; b=fG3dQ0ky66TI/eS75mSMV7PNqTSNITlVOUKJHms2g404DRhON4sVLRpqtgXwh+kVlJ jzwpQpMU62j5ZwetEHB6X1RpD0z7pUdm2SLUJ6ldK0LggNbiNxIxOv/p6lIdx3HudgYA iH+T6SNazRKtRBd+BeMS+Rkl+jY2y0N6DMlomXc8VoJP6JqFbPckckSe5PlHrmdFGf18 TV45HrHzpj3r6XHYWFGpF88xKhNAPDXz8oM/ZlwuDTgE/uZjCKVjfXgKq53pI6kfO6uE 3JMA2CeMv8IyYnlDLn7Jt4vNHDTlqnExXnobUk1gS9VD0eozVIQon9Q4SzgdKPYTahfc wzjg== 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=K01t0W9dDeaVEhbHVXYJoerIQaCGuYXgL9n65ofTLPI=; b=Er+/FICIBf+Bc1xn6Apx7aB9jB66xieCSIIQzScptNxwLqKyIf23u3m4ZK1E0rVj1h Yum7xrhQzKarEL+GXkR2q3sAPHhHQFzgl92uwo86sDF/Cr7T/f+sb7DACg7+f4jJr6Q2 aReRY3BVXn4lZH80IKUCKSvCA0L7a43CJ8f0SOeckBUDSiqxVwxyfdMvMPG1+0HGO/ep h1MB/WB2rHKX3HazABqXj4kM4MQ5zWQBpvU6Gce4k9qU5EFs0F7E95g2Rrr3gfx+fyN0 3Z/gu8RyXNJCBm6TGfd/0oe4hobe9wFxQYw11EAxSxZiyZ4UMTEdUMhn0lsbfBHiqk8z hxGA== X-Gm-Message-State: ALKqPwfKK2Q6lg/k0wb3lsvZPt00UgWoEq1s//la1c3Z5lNK8XnBhvsh Rw19mozCVB1JkIUWvZXa0gpU9Q== X-Google-Smtp-Source: AB8JxZofGzm8gpxpn9SHuqfuDkD3UmM+BbSLJohNHcG/zT6OYyPZv+07psMrmyHUjAKh2hzH9Voy8A== X-Received: by 2002:a6b:f00d:: with SMTP id w13-v6mr11091781ioc.296.1526663894521; Fri, 18 May 2018 10:18:14 -0700 (PDT) Received: from [10.102.248.12] (mobile-166-176-251-17.mycingular.net. [166.176.251.17]) by smtp.gmail.com with ESMTPSA id v62-v6sm4801662itd.16.2018.05.18.10.18.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 10:18:13 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-5B1D551A-1BC8-4263-BA55-450F53EED19A Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Fri, 18 May 2018 13:18:12 -0400 Cc: John Bradley , David Waite , Hannes Tschofenig , oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <, 895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> To: Brock Allen Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:18:18 -0000 --Apple-Mail-5B1D551A-1BC8-4263-BA55-450F53EED19A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > However moving the token used for refresh from being a HTTP only cookie to= a refresh token available in the DOM makes me uncomfortable without having s= ufficient mitigations against XSS. My conjecture is that it does not matter >>at all<< where you store tokens i= n relation to XSS. There is no secure place to store data in a browser in wa= ys that cannot be abused by XSS. One XSS is complete compromise of the clien= t. I=E2=80=99m happy to discuss in detail with POC=E2=80=99s offline if you l= ike. HTTPOnly cookies do absolutely nothing to stop an attacker from leverag= ing XSS to forge requests through a victims browser, a much more common red t= eam attack than trying to steal a cookie. And XSS resistant apps are illusive. For example .NET is missing core contro= ls around XSS defense like a well maintained HTML sanitizer for HTML input.=20= -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 12:53 PM, Brock Allen wrote: >=20 > Fair enough, and I'm happy that this discussion has started.=20 >=20 > For now, IMO, CSP is a big help in protecting these types of apps. Token b= inding will of course help too, once it's available/practical. >=20 > -Brock >=20 >> On 5/18/2018 12:47:49 PM, John Bradley wrote: >>=20 >> There are lots of issues with the current implicit flow around fragment e= ncoding as well. >>=20 >> =20 >>=20 >> However moving the token used for refresh from being a HTTP only cookie t= o a refresh token available in the DOM makes me uncomfortable without having= sufficient mitigations against XSS. >>=20 >> =20 >>=20 >> The current flow is vulnerable to XSS for the AT, however if that is sho= rt lived it restricts the damage. >>=20 >> =20 >>=20 >> The better solution is token binding the AT and perhaps a RT.=20 >>=20 >> =20 >>=20 >> We need to start talking about it. There are issues around potentially u= sing service workers etc as well. >>=20 >> =20 >>=20 >> So we should start but I am not sure of what the correct answer is yet. >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> Sent from Mail for Windows 10 >>=20 >> =20 >>=20 >> From: Brock Allen >> Sent: Friday, May 18, 2018 6:36 PM >> To: John Bradley; David Waite; Hannes Tschofenig >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>=20 >> =20 >>=20 >> It sounds to me as if you're hesitant to recommend code flow (at least fo= r now) then for browser-based JS apps. >>=20 >> =20 >>=20 >> -Brock >>=20 >> =20 >>=20 >> On 5/18/2018 12:27:48 PM, John Bradley wrote: >>=20 >> Yes that was the original intent to have the AT be short lived and refres= h the AT via the authorization endpoint based on the session cookie.=20 >>=20 >> The session cookie should also be flagged as http only to protect it.=20 >>=20 >> Having a refresh token in local storrage may introduce new security issue= s unless it is token bound.=20 >>=20 >> Understanding the security issues of the code flow in the browser is impo= rtant, before any new recommendation.=20 >>=20 >> John B. >>=20 >> From: Brock Allen >>=20 >> Sent: Friday, May 18, 2:46 PM >>=20 >> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>=20 >> To: David Waite, Hannes Tschofenig >>=20 >> Cc: oauth@ietf.org >>=20 >>=20 >> One thing I maybe should have listed in the pros/cons in my original emai= l is session management and token lifetime considerations, keeping in mind t= he original intent of the implicit flow. >>=20 >> What I mean is that with implicit grant type, the client's ability to get= new access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh tokens= ), but I don't know about a browser-based JS app. In a sense there's a bit o= f protection for the end user built into that design by virtue of being tied= to the user's cookie at the AS/OP. >>=20 >> Just throwing that out as an additional discussion point. >>=20 >> -Brock >>=20 >> On 5/18/2018 6:04:47 AM, David Waite wrote= : >>=20 >> I have written some guidance already (in non-RFC format) on preferring co= de for single page apps, and other security practices (CORS, CSP). =46rom th= e AS point of view, it aligns well with the native apps BCP. There are benef= its of thinking about native and SPA apps just as =E2=80=98public clients=E2= =80=99 from a policy/properties point of view. It also greatly simplifies OA= uth/OIDC support on both the AS administrator and client developer side when= converting web properties into native apps using technologies like Electron= or Cordova. >>=20 >> For the later requirements in the list around token policy, I am not sure= these are requirements for single page apps per se. I don=E2=80=99t believe= the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native ap= plications. Rather they seem to be a function of usage patterns that an AS m= ay need to support, and we happen to sometimes associate those usage pattern= s with typical usage of native apps vs of browser apps. For example, browser= login on a borrowed device can easily leak over to being app authorization -= the authentication/authorization are web-based processes to achieve SSO. >>=20 >> I have been working on some guidance here around token lifetimes and poli= cies, but I don=E2=80=99t know whether that brings in too much AS/OP busines= s logic (and, likely implied product/deployment features) to be industry pra= ctices. >>=20 >> -DW >>=20 >> On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: >>=20 >> Hi Brock, >>=20 >> =20 >>=20 >> there have been several attempts to start writing some guidance but so fa= r we haven=E2=80=99t gotten too far.. >>=20 >> IMHO it would be great to have a document. >>=20 >> =20 >>=20 >> Ciao >>=20 >> Hannes >>=20 >> =20 >>=20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen >>=20 >> Sent: 17 May 2018 14:57 >>=20 >> To: oauth@ietf.org >>=20 >> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>=20 >> =20 >>=20 >> Much like updated guidance was provided with the "OAuth2 for native apps"= RFC, should there be one for "browser-based client-side JS apps"? I ask bec= ause google is actively discouraging the use of implicit flow: >>=20 >> =20 >>=20 >> https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >>=20 >> =20 >>=20 >> =46rom what I can tell, the complaints with implicit are: >>=20 >> * access token in URL >>=20 >> * access token in browser history >>=20 >> * iframe complexity when using prompt=3Dnone to "refresh" access tokens >>=20 >> =20 >>=20 >> But this requires: >>=20 >> * AS/OP to support PKCE >>=20 >> * AS/OP to support CORS=20 >>=20 >> * user-agent must support CORS >>=20 >> * AS/OP to maintain short-lived refresh tokens=20 >>=20 >> * AS/OP must aggressively revoke refresh tokens at user signout (which is= not something OAuth2 "knows" about) >>=20 >> * if the above point can't work, then client must proactively use revocat= ion endpoint if/when user triggers logout >>=20 >> =20 >>=20 >> Any use in discussing this? >>=20 >> =20 >>=20 >> -Brock >>=20 >> =20 >>=20 >> 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, p= lease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> =20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-5B1D551A-1BC8-4263-BA55-450F53EED19A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable > However moving the token used for refresh from being= a HTTP only cookie to a refresh token available in the DOM makes me uncomfo= rtable without having sufficient mitigations against XSS.

My conjecture is that it does not matter >>at all<< wher= e you store tokens in relation to XSS. There is no secure place to store dat= a in a browser in ways that cannot be abused by XSS. One XSS is complete com= promise of the client. I=E2=80=99m happy to discuss in detail with POC=E2=80= =99s offline if you like. HTTPOnly cookies do absolutely nothing to stop an a= ttacker from leveraging XSS to forge requests through a victims browser, a m= uch more common red team attack than trying to steal a cookie.
And XSS resistant apps are illusive. For example .NET is missing= core controls around XSS defense like a well maintained HTML sanitizer for H= TML input. 

--
<= div>Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On May 18, 2018, at 12:53 PM, Brock= Allen <brockallen@gmail.com&= gt; wrote:

=20 =20 =20 =20 =20 Fair enough, and I'm happy that this= discussion has started. 

For now, IMO, CSP is a big= help in protecting these types of apps. Token binding will of course help t= oo, once it's available/practical.

-Brock

On 5/= 18/2018 12:47:49 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:

There are lots of issues with the current implicit flow around fra= gment encoding as well.

 

However moving the token used for refresh from being a HTT= P only cookie to a refresh token available in the DOM makes me uncomfortable= without having sufficient mitigations against XSS.

 

The current flow is vulnerable= to  XSS for the AT, however if that is short lived it restricts the da= mage.

 

= The better solution is token binding the AT and perhaps a RT. 

 

We need to st= art talking about it.  There are issues around potentially using servic= e workers etc as well.

 

So we should start but I am not sure of what the correct an= swer is yet.

 

John B.

 

Sent from Mail for Windows 10

 

<= div style=3D"mso-element:para-border-div;border:none;border-top:solid #E1E1E= 1 1.0pt;padding:3.0pt 0in 0in 0in">

From: Brock A= llen
Sent: Friday, May 18, 2018 6:36 PM
To: John Bradley; David Waite; Hannes Tschofenig
Cc: oau= th@ietf.org
Subject: Re: [OAUTH-WG] is updated guidance needed= for JS/SPA apps?

 

It sounds to m= e as if you're hesitant to recommend code flow (at least for now) then for b= rowser-based JS apps.

 

&n= bsp;

On 5= /18/2018 12:27:48 PM, John Bradley <= ve7jtb@ve7jtb.com> wrote:

Yes that was the original intent to have the A= T be short lived and refresh the AT via the authorization endpoint based on t= he session cookie. 

The session cookie should also be flagged as ht= tp only to protect it. 

Having a refresh token in local storrage ma= y introduce new security issues unless it is token bound.  <= /span>

<= span style=3D"font-family:"Arial",sans-serif;color:black">Understa= nding the security issues of the code flow in the browser is important, befo= re any new recommendation. 

John B.

From: Brock Allen

Sent: Friday, May 18, 2:46 PM

Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

To: David Waite, Hannes Tschofe= nig

O= ne thing I maybe should have listed in the pros/cons in my original email is= session management and token lifetime considerations, keeping in mind the o= riginal intent of the implicit flow.

What I mean is that with implicit g= rant type, the client's ability to get new access tokens is limited to the u= ser's session at the AS/OP. Obviously other flows make more sense to obtain l= onger lived access (via refresh tokens), but I don't know about a browser-ba= sed JS app. In a sense there's a bit of protection for the end user built in= to that design by virtue of being tied to the user's cookie at the AS/OP.

Just throwing that out as an additional discussion point.

-Brock

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> w= rote:

I have written some guidance already (in non-RFC format) on pr= eferring code for single page apps, and other security practices (CORS, CSP)= . =46rom the AS point of view, it aligns well with the native apps BCP. Ther= e are benefits of thinking about native and SPA apps just as =E2=80=98public= clients=E2=80=99 from a policy/properties point of view. It also greatly si= mplifies OAuth/OIDC support on both the AS administrator and client develope= r side when converting web properties into native apps using technologies li= ke Electron or Cordova.

For the later requirements in the list around to= ken policy, I am not sure these are requirements for single page apps per se= . I don=E2=80=99t believe the need for a policy using short-lived refresh to= kens, revoking at signout, or use of the revocation endpoint are different f= rom browser and native applications. Rather they seem to be a function of us= age patterns that an AS may need to support, and we happen to sometimes asso= ciate those usage patterns with typical usage of native apps vs of browser a= pps. For example, browser login on a borrowed device can easily leak over to= being app authorization - the authentication/authorization are web-based pr= ocesses to achieve SSO.

I have been working on some guidance here around t= oken lifetimes and policies, but I don=E2=80=99t know whether that brings in= too much AS/OP business logic (and, likely implied product/deployment featu= res) to be industry practices.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> w= rote:

Hi Brock,

 

<= p class=3D"MsoNormal">there have been several attempts to start writing some guidan= ce but so far we haven=E2=80=99t gotten too far..

IMHO it would be great to have a document.<= /span>

 

=

Ciao

= Hannes<= o:p>

 

=

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of&nb= sp;Brock Allen

Sent:<= /span> 17 May 2018 14:57

Subject: [OAUTH-WG] is u= pdated guidance needed for JS/SPA apps?

 

Much like= updated guidance was provided with the "OAuth2 for native apps" RFC, should= there be one for "browser-based client-side JS apps"? I ask because google i= s actively discouraging the use of implicit flow:

 

 

=46rom what I can tell, the complaints with i= mplicit are:

* access token i= n URL

* access token in brow= ser history

* iframe complex= ity when using prompt=3Dnone to "refresh" access tokens

 

But this requires:

* AS= /OP to support PKCE

<= span style=3D"font-family:"Arial",sans-serif;color:black">* A= S/OP to support CORS 

* user-agent must support CORS

* AS/OP to maintain short-lived refresh tokens <= /p>

* AS/OP must aggressively revoke refresh token= s at user signout (which is not something OAuth2 "knows" about)

* if the above point can't work, then cl= ient must proactively use revocation endpoint if/when user triggers logout

 

<= /div>

Any use in discussing this?

<= /div>

 

-Brock

 

IMPORTANT NOTICE: The contents of thi= s email and any attachments are confidential and may also be privileged. If y= ou are not the intended recipient, please notify the sender immediately and d= o not disclose the contents to any other person, use it for any purpose, or s= tore or copy the information in any medium. Thank you. ________________= _______________________________

OAuth mailing list

= =



 

=20
____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /span>
= --Apple-Mail-5B1D551A-1BC8-4263-BA55-450F53EED19A-- From nobody Fri May 18 10:21: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 1181C126BF3 for ; Fri, 18 May 2018 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 UhXHsag5Hs_6 for ; Fri, 18 May 2018 10:21:32 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 58EEF12D86B for ; Fri, 18 May 2018 10:21:32 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id t23-v6so7058260ioc.10 for ; Fri, 18 May 2018 10:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RlIv3fPcSZrnJsrisZuCfHHzvaax+1ZPJv3RcbW15Bo=; b=ZQU0sYF6hra/1m6OjiuPb5eMdP2sd1vxg8HqH+Shc01RQs+v4gThRun+Mk2ll5zGLL ZkDSLJ7h4oDsTVsSFzS4Ds5UR2VwNOT6NEuIcDbXDhlf2UCLFc4RUQk2sr07lW+6+S3h mKnQudW532etKVwOm/ZP1cswZ8GbbSImuU+3V7xsr5fy5fA3cghJdC6cNuZKZj1qGbJC pvkV54Xn0OwJFPfvguFtxc2s92JM7Qtu05C0Y5jgxfvv18N1Ij5KRlUiF8xg8kXvrcMF gOAYjPp78Gj8VojZRjSairrE7HJWz3WZYaXBqsEgugv4AYk5VMUb/VztpmdKUkmQyJC3 xmjA== 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=RlIv3fPcSZrnJsrisZuCfHHzvaax+1ZPJv3RcbW15Bo=; b=no6mqYVwhqLTzYEZA3h145MTImyOh+qmedfAryDeI9OTNrqk+4Xz+9QqvQYevRv75W xQ0A34S+lKsRlCsKGVIkwZ1bmrsqnC+778WEbKv2PekphnE5URObaoW9VGsR35xOA7GU ddcvUomUEylXsTXouzGE7BpdBNW9JwXMQHZ68ooydXFe7XWrYVfCPBKBdrYQ8l33ycQW rcoJiSJ8BozF4/VDrKM7btSG5y0b/v0p0yDPpXSAV5ExSaK1vildk/9Pa/Y+Z/pMsQ6H kglibYH01Yw63Q3YehgJXnUKX9K1JLmebrhrXagZrErKXr31DltGhTulu+t5RHbirnoh q2Ww== X-Gm-Message-State: ALKqPwcfXlL8k7HJvyYk3CseYULYWstGWFpAoMMSrKiQB9tcM157n/u0 9cPWstbzC7/rI7o7p6+DAoKNfg== X-Google-Smtp-Source: AB8JxZpe+V9xDhfDI5yX3ejObkTxgXO0+MmDWMXI+Z3rX7cEuJfif+7vA3AFou/tf8vWrR9Yn+Kn+Q== X-Received: by 2002:a6b:bf03:: with SMTP id p3-v6mr11355169iof.6.1526664091665; Fri, 18 May 2018 10:21:31 -0700 (PDT) Received: from [10.102.248.12] (mobile-166-176-251-17.mycingular.net. [166.176.251.17]) by smtp.gmail.com with ESMTPSA id f4-v6sm5228823itf.22.2018.05.18.10.21.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 10:21:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C614C988-77DE-4300-BB9F-94EED7AF9572 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Fri, 18 May 2018 13:21:29 -0400 Cc: John Bradley , David Waite , Hannes Tschofenig , oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <, 895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> To: Brock Allen Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:21:36 -0000 --Apple-Mail-C614C988-77DE-4300-BB9F-94EED7AF9572 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable And I agree, Brock. CSP-3 policies that use strict-dynamic and nonces are fa= irly straight forward to deploy and provide backwards compatibility down to C= SP 2 and 1. I yearn for a world where token binding and CSP are commonplace s= o I can sleep again! Until then, these solutions are fragile at best in the f= ace of XSS. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 12:53 PM, Brock Allen wrote: >=20 > Fair enough, and I'm happy that this discussion has started.=20 >=20 > For now, IMO, CSP is a big help in protecting these types of apps. Token b= inding will of course help too, once it's available/practical. >=20 > -Brock >=20 >> On 5/18/2018 12:47:49 PM, John Bradley wrote: >>=20 >> There are lots of issues with the current implicit flow around fragment e= ncoding as well. >>=20 >> =20 >>=20 >> However moving the token used for refresh from being a HTTP only cookie t= o a refresh token available in the DOM makes me uncomfortable without having= sufficient mitigations against XSS. >>=20 >> =20 >>=20 >> The current flow is vulnerable to XSS for the AT, however if that is sho= rt lived it restricts the damage. >>=20 >> =20 >>=20 >> The better solution is token binding the AT and perhaps a RT.=20 >>=20 >> =20 >>=20 >> We need to start talking about it. There are issues around potentially u= sing service workers etc as well. >>=20 >> =20 >>=20 >> So we should start but I am not sure of what the correct answer is yet. >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> Sent from Mail for Windows 10 >>=20 >> =20 >>=20 >> From: Brock Allen >> Sent: Friday, May 18, 2018 6:36 PM >> To: John Bradley; David Waite; Hannes Tschofenig >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>=20 >> =20 >>=20 >> It sounds to me as if you're hesitant to recommend code flow (at least fo= r now) then for browser-based JS apps. >>=20 >> =20 >>=20 >> -Brock >>=20 >> =20 >>=20 >> On 5/18/2018 12:27:48 PM, John Bradley wrote: >>=20 >> Yes that was the original intent to have the AT be short lived and refres= h the AT via the authorization endpoint based on the session cookie.=20 >>=20 >> The session cookie should also be flagged as http only to protect it.=20 >>=20 >> Having a refresh token in local storrage may introduce new security issue= s unless it is token bound.=20 >>=20 >> Understanding the security issues of the code flow in the browser is impo= rtant, before any new recommendation.=20 >>=20 >> John B. >>=20 >> From: Brock Allen >>=20 >> Sent: Friday, May 18, 2:46 PM >>=20 >> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>=20 >> To: David Waite, Hannes Tschofenig >>=20 >> Cc: oauth@ietf.org >>=20 >>=20 >> One thing I maybe should have listed in the pros/cons in my original emai= l is session management and token lifetime considerations, keeping in mind t= he original intent of the implicit flow. >>=20 >> What I mean is that with implicit grant type, the client's ability to get= new access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh tokens= ), but I don't know about a browser-based JS app. In a sense there's a bit o= f protection for the end user built into that design by virtue of being tied= to the user's cookie at the AS/OP. >>=20 >> Just throwing that out as an additional discussion point. >>=20 >> -Brock >>=20 >> On 5/18/2018 6:04:47 AM, David Waite wrote= : >>=20 >> I have written some guidance already (in non-RFC format) on preferring co= de for single page apps, and other security practices (CORS, CSP). =46rom th= e AS point of view, it aligns well with the native apps BCP. There are benef= its of thinking about native and SPA apps just as =E2=80=98public clients=E2= =80=99 from a policy/properties point of view. It also greatly simplifies OA= uth/OIDC support on both the AS administrator and client developer side when= converting web properties into native apps using technologies like Electron= or Cordova. >>=20 >> For the later requirements in the list around token policy, I am not sure= these are requirements for single page apps per se. I don=E2=80=99t believe= the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native ap= plications. Rather they seem to be a function of usage patterns that an AS m= ay need to support, and we happen to sometimes associate those usage pattern= s with typical usage of native apps vs of browser apps. For example, browser= login on a borrowed device can easily leak over to being app authorization -= the authentication/authorization are web-based processes to achieve SSO. >>=20 >> I have been working on some guidance here around token lifetimes and poli= cies, but I don=E2=80=99t know whether that brings in too much AS/OP busines= s logic (and, likely implied product/deployment features) to be industry pra= ctices. >>=20 >> -DW >>=20 >> On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: >>=20 >> Hi Brock, >>=20 >> =20 >>=20 >> there have been several attempts to start writing some guidance but so fa= r we haven=E2=80=99t gotten too far.. >>=20 >> IMHO it would be great to have a document. >>=20 >> =20 >>=20 >> Ciao >>=20 >> Hannes >>=20 >> =20 >>=20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen >>=20 >> Sent: 17 May 2018 14:57 >>=20 >> To: oauth@ietf.org >>=20 >> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>=20 >> =20 >>=20 >> Much like updated guidance was provided with the "OAuth2 for native apps"= RFC, should there be one for "browser-based client-side JS apps"? I ask bec= ause google is actively discouraging the use of implicit flow: >>=20 >> =20 >>=20 >> https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >>=20 >> =20 >>=20 >> =46rom what I can tell, the complaints with implicit are: >>=20 >> * access token in URL >>=20 >> * access token in browser history >>=20 >> * iframe complexity when using prompt=3Dnone to "refresh" access tokens >>=20 >> =20 >>=20 >> But this requires: >>=20 >> * AS/OP to support PKCE >>=20 >> * AS/OP to support CORS=20 >>=20 >> * user-agent must support CORS >>=20 >> * AS/OP to maintain short-lived refresh tokens=20 >>=20 >> * AS/OP must aggressively revoke refresh tokens at user signout (which is= not something OAuth2 "knows" about) >>=20 >> * if the above point can't work, then client must proactively use revocat= ion endpoint if/when user triggers logout >>=20 >> =20 >>=20 >> Any use in discussing this? >>=20 >> =20 >>=20 >> -Brock >>=20 >> =20 >>=20 >> 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, p= lease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> =20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C614C988-77DE-4300-BB9F-94EED7AF9572 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable And I agree, Brock. CSP-3 policies that use= strict-dynamic and nonces are fairly straight forward to deploy and provide= backwards compatibility down to CSP 2 and 1. I yearn for a world where toke= n binding and CSP are commonplace so I can sleep again! Until then, these so= lutions are fragile at best in the face of XSS.

Aloha,
--
Jim Manico
@Mani= code
Secure Coding Education
+1 (808) 652-3805

On May 18, 2018, at 12:53 PM, Brock Allen <brockallen@gmail.com> wrote:

=20 =20 =20 =20 =20 Fair enough, and I'm happy that this= discussion has started. 

For now, IMO, CSP is a big= help in protecting these types of apps. Token binding will of course help t= oo, once it's available/practical.

-Brock

On 5/= 18/2018 12:47:49 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:

There are lots of issues with the current implicit flow around fra= gment encoding as well.

 

However moving the token used for refresh from being a HTT= P only cookie to a refresh token available in the DOM makes me uncomfortable= without having sufficient mitigations against XSS.

 

The current flow is vulnerable= to  XSS for the AT, however if that is short lived it restricts the da= mage.

 

= The better solution is token binding the AT and perhaps a RT. 

 

We need to st= art talking about it.  There are issues around potentially using servic= e workers etc as well.

 

So we should start but I am not sure of what the correct an= swer is yet.

 

John B.

 

Sent from Mail for Windows 10

 

<= div style=3D"mso-element:para-border-div;border:none;border-top:solid #E1E1E= 1 1.0pt;padding:3.0pt 0in 0in 0in">

From: Brock A= llen
Sent: Friday, May 18, 2018 6:36 PM
To: John Bradley; David Waite; Hannes Tschofenig
Cc: oau= th@ietf.org
Subject: Re: [OAUTH-WG] is updated guidance needed= for JS/SPA apps?

 

It sounds to m= e as if you're hesitant to recommend code flow (at least for now) then for b= rowser-based JS apps.

 

&n= bsp;

On 5= /18/2018 12:27:48 PM, John Bradley <= ve7jtb@ve7jtb.com> wrote:

Yes that was the original intent to have the A= T be short lived and refresh the AT via the authorization endpoint based on t= he session cookie. 

The session cookie should also be flagged as ht= tp only to protect it. 

Having a refresh token in local storrage ma= y introduce new security issues unless it is token bound.  <= /span>

<= span style=3D"font-family:"Arial",sans-serif;color:black">Understa= nding the security issues of the code flow in the browser is important, befo= re any new recommendation. 

John B.

From: Brock Allen

Sent: Friday, May 18, 2:46 PM

Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

To: David Waite, Hannes Tschofe= nig

O= ne thing I maybe should have listed in the pros/cons in my original email is= session management and token lifetime considerations, keeping in mind the o= riginal intent of the implicit flow.

What I mean is that with implicit g= rant type, the client's ability to get new access tokens is limited to the u= ser's session at the AS/OP. Obviously other flows make more sense to obtain l= onger lived access (via refresh tokens), but I don't know about a browser-ba= sed JS app. In a sense there's a bit of protection for the end user built in= to that design by virtue of being tied to the user's cookie at the AS/OP.

Just throwing that out as an additional discussion point.

-Brock

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> w= rote:

I have written some guidance already (in non-RFC format) on pr= eferring code for single page apps, and other security practices (CORS, CSP)= . =46rom the AS point of view, it aligns well with the native apps BCP. Ther= e are benefits of thinking about native and SPA apps just as =E2=80=98public= clients=E2=80=99 from a policy/properties point of view. It also greatly si= mplifies OAuth/OIDC support on both the AS administrator and client develope= r side when converting web properties into native apps using technologies li= ke Electron or Cordova.

For the later requirements in the list around to= ken policy, I am not sure these are requirements for single page apps per se= . I don=E2=80=99t believe the need for a policy using short-lived refresh to= kens, revoking at signout, or use of the revocation endpoint are different f= rom browser and native applications. Rather they seem to be a function of us= age patterns that an AS may need to support, and we happen to sometimes asso= ciate those usage patterns with typical usage of native apps vs of browser a= pps. For example, browser login on a borrowed device can easily leak over to= being app authorization - the authentication/authorization are web-based pr= ocesses to achieve SSO.

I have been working on some guidance here around t= oken lifetimes and policies, but I don=E2=80=99t know whether that brings in= too much AS/OP business logic (and, likely implied product/deployment featu= res) to be industry practices.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> w= rote:

Hi Brock,

 

<= p class=3D"MsoNormal">there have been several attempts to start writing some guidan= ce but so far we haven=E2=80=99t gotten too far..

IMHO it would be great to have a document.<= /span>

 

=

Ciao

= Hannes<= o:p>

 

=

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of&nb= sp;Brock Allen

Sent:<= /span> 17 May 2018 14:57

Subject: [OAUTH-WG] is u= pdated guidance needed for JS/SPA apps?

 

Much like= updated guidance was provided with the "OAuth2 for native apps" RFC, should= there be one for "browser-based client-side JS apps"? I ask because google i= s actively discouraging the use of implicit flow:

 

 

=46rom what I can tell, the complaints with i= mplicit are:

* access token i= n URL

* access token in brow= ser history

* iframe complex= ity when using prompt=3Dnone to "refresh" access tokens

 

But this requires:

* AS= /OP to support PKCE

<= span style=3D"font-family:"Arial",sans-serif;color:black">* A= S/OP to support CORS 

* user-agent must support CORS

* AS/OP to maintain short-lived refresh tokens <= /p>

* AS/OP must aggressively revoke refresh token= s at user signout (which is not something OAuth2 "knows" about)

* if the above point can't work, then cl= ient must proactively use revocation endpoint if/when user triggers logout

 

<= /div>

Any use in discussing this?

<= /div>

 

-Brock

 

IMPORTANT NOTICE: The contents of thi= s email and any attachments are confidential and may also be privileged. If y= ou are not the intended recipient, please notify the sender immediately and d= o not disclose the contents to any other person, use it for any purpose, or s= tore or copy the information in any medium. Thank you. ________________= _______________________________

OAuth mailing list

= =



 

=20
____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /span>
= --Apple-Mail-C614C988-77DE-4300-BB9F-94EED7AF9572-- From nobody Fri May 18 10: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 32E1212D886 for ; Fri, 18 May 2018 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 J147x3vsLlMg for ; Fri, 18 May 2018 10:38:16 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829BD12D86B for ; Fri, 18 May 2018 10:38:15 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id l1-v6so16632350wmb.2 for ; Fri, 18 May 2018 10:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=exK5R0j0oVZlEagalMcqxCE9SdgW85DQRIcwG+e0IRY=; b=O9FVYSJrX/BPPRK8hdQcyDGqf+GFLVgMa5g22AhiqhS6sCvjomHzXRRwOZTFapmmfx DYQ06QMYYrp373LxHqs0zzm2Lx8gKQiOuuaBCj75hQOAeh7wxavAgwNfQDnA6JjiOI9b XuSWRH3QhdT1pfqpPuiewB0JsZQLsDVhOVYWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=exK5R0j0oVZlEagalMcqxCE9SdgW85DQRIcwG+e0IRY=; b=bDLebs+sIXSu1uUboawZSr3Y6QKex4nH3J+vF/j+kfbo9UmlhUDh3pKwBegCYZgSra vkU1xpoNc2zaopEEn/Mw+bYh1tSHWHEeIryNJr/cwKug1DWZ17mXKuPLF8vDQWYP4BBE Ytz7mADL7Gzb9VBmZVBNWOe70WD7SfuQKO8VQmy/NDM3+Kz3myNK8vhEZCyCCLyr2yvJ wf5pA4gotpFITS82tblQ2d88zDlcMyyNaZ3hllGDPfQTu94z0tuyTTRUEjPQI91ZLPMo UkalXRgdbg6nDY0xuXmUVY9UiRlWEDPeXRrITP9yNd2/AhODgWojU7hdWd4ckOWEHD3e LIyg== X-Gm-Message-State: ALKqPwfLyQWrKk62RFl3Vj4SoiLT3Cao4d+u2/ym0zze7r6L3sbyU8Ps hSO5H32bxfmQ6CSbtSI2+7mZ8oynAXM= X-Google-Smtp-Source: AB8JxZpWm0kCSn2YDocoPmN1EVQShkZNcZUPae7BoYTI2HBevCCeh0UjC5EHo1sLXyrl2NbkxjTrpA== X-Received: by 2002:a1c:a84d:: with SMTP id r74-v6mr5535295wme.114.1526665093902; Fri, 18 May 2018 10:38:13 -0700 (PDT) Received: from [192.168.1.81] (8.150.32.217.dyn.plus.net. [217.32.150.8]) by smtp.gmail.com with ESMTPSA id x130-v6sm10683744wme.24.2018.05.18.10.38.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 10:38:13 -0700 (PDT) Date: Fri, 18 May 2018 18:38:11 +0100 From: Neil Madden To: John Bradley , Jim Manico Cc: "=?utf-8?Q?oauth=40ietf.org?=" Message-ID: In-Reply-To: <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="5aff0f84_327b23c6_6e7"; protocol="application/pgp-signature" Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:38:19 -0000 --5aff0f84_327b23c6_6e7 Content-Type: multipart/alternative; boundary="5aff0f83_6b8b4567_6e7" --5aff0f83_6b8b4567_6e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I might be missing something here, but aren=E2=80=99t bound tokens exactl= y as vulnerable to the XSS attacks you describe as http-only cookies are=3F= =E2=80=94 Neil > On =46riday, May 18, 2018 at 5:43 pm, Jim Manico wrote: > A few notes: > > > The session cookie should also be flagged as http only to protect it.= > > This provides no real protection. If I get XSS into your site I don=E2=80= =99t need to steal the cookie. I can just force requests that will automa= tically send it (client side or stored request forgery). So while it=E2=80= =99s a standard suggestion, it helps little. > > > Having a refresh token in local storrage may introduce new security i= ssues unless it is token bound. > > Token binding is not live yet, right=3F If you need to store a token in= a browser please note there is no safe place to store it. LocalStorage c= an be harvested by XSS and even the strongest cookies can be replayed as = discussed above. I can=E2=80=99t wait for browser based token binding=21 = But it will likely take years for this to be avail in the majority of bro= wsers. > > > Understanding the security issues of the code flow in the browser is = important, before any new recommendation. > > Well said. It looks to be the only secure workflow for browser based ap= ps. Love it how passwords are kept away from RP=E2=80=99s and high powere= d tokens are not stored in the browser. > > Aloha, > -- > Jim Manico > =40Manicode > Secure Coding Education > +1 (808) 652-3805 > > > On May 18, 2018, at 12:27 PM, John Bradley wrote: > > > Yes that was the original intent to have the AT be short lived and re= fresh the AT via the authorization endpoint based on the session cookie. > > > > The session cookie should also be flagged as http only to protect it.= > > > > Having a refresh token in local storrage may introduce new security i= ssues unless it is token bound. > > > > Understanding the security issues of the code flow in the browser is = important, before any new recommendation. > > > > John B. > > > > =46rom: Brock Allen > > Sent: =46riday, May 18, 2:46 PM > > Subject: Re: =5BOAUTH-WG=5D is updated guidance needed for JS/SPA app= s=3F > > To: David Waite, Hannes Tschofenig > > Cc: oauth=40ietf.org (mailto:oauth=40ietf.org) > > > > > > One thing I maybe should have listed in the pros/cons in my original = email is session management and token lifetime considerations, keeping in= mind the original intent of the implicit flow. > > > > What I mean is that with implicit grant type, the client's ability to= get new access tokens is limited to the user's session at the AS/OP. Obv= iously other flows make more sense to obtain longer lived access (via ref= resh tokens), but I don't know about a browser-based JS app. In a sense t= here's a bit of protection for the end user built into that design by vir= tue of being tied to the user's cookie at the AS/OP. > > > > Just throwing that out as an additional discussion point. > > > > -Brock > > > > > On 5/18/2018 6:04:47 AM, David Waite wrote: > > > I have written some guidance already (in non-R=46C format) on prefe= rring code for single page apps, and other security practices (CORS, CSP)= . =46rom the AS point of view, it aligns well with the native apps BCP. T= here are benefits of thinking about native and SPA apps just as =E2=80=98= public clients=E2=80=99 from a policy/properties point of view. It also g= reatly simplifies OAuth/OIDC support on both the AS administrator and cli= ent developer side when converting web properties into native apps using = technologies like Electron or Cordova. > > > > > > =46or the later requirements in the list around token policy, I am = not sure these are requirements for single page apps per se. I don=E2=80=99= t believe the need for a policy using short-lived refresh tokens, revokin= g at signout, or use of the revocation endpoint are different from browse= r and native applications. Rather they seem to be a function of usage pat= terns that an AS may need to support, and we happen to sometimes associat= e those usage patterns with typical usage of native apps vs of browser ap= ps. =46or example, browser login on a borrowed device can easily leak ove= r to being app authorization - the authentication/authorization are web-b= ased processes to achieve SSO. > > > > > > I have been working on some guidance here around token lifetimes an= d policies, but I don=E2=80=99t know whether that brings in too much AS/O= P business logic (and, likely implied product/deployment features) to be = industry practices. > > > > > > -DW > > > > > > > On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: > > > > > > > > Hi Brock, > > > > > > > > there have been several attempts to start writing some guidance b= ut so far we haven=E2=80=99t gotten too far. > > > > IMHO it would be great to have a document. > > > > > > > > Ciao > > > > Hannes > > > > > > > > =46rom: OAuth =5Bmailto:oauth-bounces=40ietf.org=5D On Behalf Of = Brock Allen > > > > Sent: 17 May 2018 14:57 > > > > To: oauth=40ietf.org (mailto:oauth=40ietf.org) > > > > Subject: =5BOAUTH-WG=5D is updated guidance needed for JS/SPA app= s=3F > > > > > > > > Much like updated guidance was provided with the =22OAuth2 for na= tive apps=22 R=46C, should there be one for =22browser-based client-side = JS apps=22=3F I ask because google is actively discouraging the use of im= plicit flow: > > > > > > > > https://github.com/openid/AppAuth-JS/issues/59=23issuecomment-389= 639290 > > > > > > > > >=46rom what I can tell, the complaints with implicit are: > > > > * access token in URL > > > > * access token in browser history > > > > * iframe complexity when using prompt=3Dnone to =22refresh=22 acc= ess tokens > > > > > > > > But this requires: > > > > * AS/OP to support PKCE > > > > * AS/OP to support CORS > > > > * user-agent must support CORS > > > > * AS/OP to maintain short-lived refresh tokens > > > > * AS/OP must aggressively revoke refresh tokens at user signout (= which is not something OAuth2 =22knows=22 about) > > > > * if the above point can't work, then client must proactively use= revocation endpoint if/when user triggers logout > > > > > > > > Any use in discussing this=3F > > > > > > > > -Brock > > > > > > > > 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 c= ontents to any other person, use it for any purpose, or store or copy the= information in any medium. Thank you. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > > OAuth mailing list > > > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > OAuth mailing list > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > https://www.ietf.org/mailman/listinfo/oauth > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OAuth mailing list > OAuth=40ietf.org > https://www.ietf.org/mailman/listinfo/oauth --5aff0f83_6b8b4567_6e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22>
= I might be missing something here, but aren=E2=80=99t bound tokens exactl= y as vulnerable to the XSS attacks you describe as http-only cookies are=3F= =C2=A0

=E2=80=94 Neil

=
On =46riday, May 18, 2018 at 5:43 pm, Jim Manico= <jim=40manicode.com>= wrote:
A few notes:

>=C2=A0The session co= okie should also be flagged as http only to protect it.=C2=A0=C2=A0

This provides no real protection. If I get XSS into = your site I don=E2=80=99t need to steal the cookie. I can just force requ= ests that will automatically send it (client side or stored request forge= ry). So while it=E2=80=99s a standard suggestion, it helps little.=C2=A0<= /div>

>=C2=A0Having a refresh token in local storrage may intr= oduce new security issues unless it is token bound.=C2=A0=C2=A0

Token binding is not live yet, right=3F If you nee= d to store a token in a browser please note there is no safe place to sto= re it. LocalStorage can be harvested by XSS and even the strongest cookie= s can be replayed as discussed above. I can=E2=80=99t wait for browser ba= sed token binding=21 But it will likely take years for this to be avail i= n the majority of browsers.

>=C2=A0Understanding the sec= urity issues of the code flow in the browser is important, before any new= recommendation.=C2=A0=C2=A0

Well said. I= t looks to be the only secure workflow for browser based apps. Love it ho= w passwords are kept away from RP=E2=80=99s and high powered tokens are n= ot stored in the browser.

Aloha,
--
Jim Manico
=40Manicode<= /div>
Secure Coding Education
+1 (808) 652-3805
=

On May 18, 2018, at 12:27 PM, John Bradley <ve7jtb=40ve7jtb.com> wrote:

Yes that was the original intent t= o have the AT be short lived and refresh the AT via the authorization end= point based on the session cookie.=C2=A0

The session cookie should al= so be flagged as http only to protect it.=C2=A0

Having a refresh toke= n in local storrage may introduce new security issues unless it is token = bound.=C2=A0

Understanding the security issues of the code flow in th= e browser is important, before any new recommendation.=C2=A0

John B. =

=46rom: Brock Allen
Sent: =46riday, May 18, 2:46 PM
Subject: Re: =5BOAUTH-WG= =5D is updated guidance needed for JS/SPA apps=3F
To: David Waite, Hannes Tsc= hofenig
One thing I maybe should have listed in the pros/cons in my origina= l email is session management and token lifetime considerations, keeping = in mind the original intent of the implicit flow.

What I mean is that= with implicit grant type, the client's ability to get new access tokens = is limited to the user's session at the AS/OP. Obviously other flows make= more sense to obtain longer lived access (via refresh tokens), but I don= 't know about a browser-based JS app. In a sense there's a bit of protect= ion for the end user built into that design by virtue of being tied to th= e user's cookie at the AS/OP.

Just throwing that out as an additional= discussion point.

-Brock

On 5/18/201= 8 6:04:47 AM, David Waite <david=40alkaline-solutions.com> wrote:
I have written som= e guidance already (in non-R=46C format)=C2=A0on preferring code for sing= le page apps, and other security practices (CORS, CSP). =46rom the AS poi= nt of view, it aligns well with the native apps BCP. There are benefits o= f thinking about native and SPA apps just as =E2=80=98public clients=E2=80= =99 from a policy/properties point of view. It also greatly simplifies OA= uth/OIDC support on both the AS administrator and client developer side w= hen converting web properties into native apps using technologies like El= ectron or Cordova.

=46or the later requirements in the list around to= ken policy, I am not sure these are requirements for single page apps per= se. I don=E2=80=99t believe the need for a policy using short-lived refr= esh tokens, revoking at signout, or use of the revocation endpoint are di= fferent from browser and native applications. Rather they seem to be a fu= nction of usage patterns that an AS may need to support, and we happen to= sometimes associate those usage patterns with typical usage of native ap= ps vs of browser apps. =46or example, browser login on a borrowed device = can easily leak over to being app authorization - the authentication/auth= orization are web-based processes to achieve SSO.

I have been working = on some guidance here around token lifetimes and policies, but I don=E2=80= =99t know whether that brings in too much AS/OP business logic (and, like= ly implied product/deployment features) to be industry practices.
-DW<= br>
On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig=40arm.com> = wrote:

Hi Brock,
=C2=A0
there have been several attempts to start writing = some guidance but so far we haven=E2=80=99t gotten too far.
IMHO it would b= e great to have a document.
=C2=A0
Ciao
Hannes
=C2=A0
=46rom:=C2=A0OAuth =5B<= a href=3D=22mailto:oauth-bounces=40ietf.org=22>mailto:oauth-bounces=40iet= f.org=5D=C2=A0On Behalf Of=C2=A0Brock Allen
Sent:=C2=A017= May 2018 14:57
Subject:=C2=A0=5BOAUTH-WG=5D is updated guidance n= eeded for JS/SPA apps=3F
=C2=A0
Much like updated guidance was provided with t= he =22OAuth2 for native apps=22 R=46C, should there be one for =22browser= -based client-side JS apps=22=3F I ask because google is actively discour= aging the use of implicit flow:
=C2=A0
=C2=A0
>=46rom what I c= an tell, the complaints with implicit are:
* access token in URL
<= div dir=3D=22auto=22 style=3D=22direction: ltr; margin: 0; padding: 0; fo= nt-family: sans-serif; font-size: 11pt; color: black; =22> * access token= in browser history
* iframe complexity when using prompt=3Dnone to =22refr= esh=22 access tokens
=C2=A0
But this requires:
* AS/OP to support PKCE
=
*=C2=A0AS/OP= to support=C2=A0CORS=C2=A0
* user-agent must support CORS
* AS/OP to maintai= n short-lived refresh tokens=C2=A0
* AS/OP must aggressively revoke refresh= tokens at user signout (which is not something OAuth2 =22knows=22 about)=
*= if the above point can't work, then client must proactively use revocati= on endpoint if/when user triggers logout
=C2=A0
Any use in discussing this=3F=
=C2= =A0
-Brock
=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 inten= ded 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.=C2=A0=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
= OAuth=40ietf.org=
htt= ps://www.ietf.org/mailman/listinfo/oauth
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
--5aff0f83_6b8b4567_6e7-- --5aff0f84_327b23c6_6e7 Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary Comment: https://www.canarymail.io Charset: UTF-8 wsFcBAABCgAGBQJa/w+DAAoJEJD4Q99O3axdaIkP/idMX3Yeydsdjc/U0hulZ2SN6NWlUNDh7fFg srP1aX0l2He+bw5ax+ZOv9bH/NpfPEQq/A9AJsd/bmIbulKH0X799V0Vw8THZGWs4YjUDp4z7JGC +6gyWhavpnQ/AVcZLRjBk0ucEB6dtXnSS9biZzjEPBbgU8TYIhGVnbNZJfCqs6YIz2qwwZABldt6 ogZilH/LFh0Y27EdRvxDli1dETb7qI4GjjAqxGtUcYyPwgDSsJ4lUP3EA39hlW9rBf9o36PJ9xBn toAiMGcOf2mrHnECw0fTS4XOaSqHS7yVYJqejrcn7/JFMQ2WoHjAGku4Pct/ACXPJsK5Ahcx25PI WRQqKi2TQm3WVYEetZOcrs4jqs+R6MYKbCd+jPxL5qMDHFJuq4eOYlM0AybdKukoy5SxPhUtUOrj Dw/CbGrnxEvw2mre/YpIQWLRJn3oc6JDP4cHa0c9H5qGVV0urelqBj/pdPCOo11JbWuQ9cu3zoIA b/4K+3hzdlFYJ+4AEAfOQZ1nXpkWCsxuLPEULu17F1QDfXwOheVAEGJ9lH5D2YQF9Zdp5nPSMnbn vOWTTeDyZmlITCBGfp9JbwtldhvWlyJZZ+qjdIVp3f8t9kuTyIt001akV8VMVQYRqSHxPRrkuUIZ UTWVgWXRjY/tmFs4NA4rAAnIOsUhAUb/QazOBVH7 =g2q/ -----END PGP SIGNATURE----- --5aff0f84_327b23c6_6e7-- From nobody Fri May 18 10:42: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 D61F712DA25 for ; Fri, 18 May 2018 10:42:41 -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, 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 uKR_IU8oToiL for ; Fri, 18 May 2018 10:42:38 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id A78E512DA06 for ; Fri, 18 May 2018 10:42:38 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403] (unknown [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403]) by alkaline-solutions.com (Postfix) with ESMTPSA id C1F2131544; Fri, 18 May 2018 17:42:37 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_DBDAF004-E118-4D0F-B1AF-17EF94248013" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: David Waite X-Priority: 3 In-Reply-To: <5aff03b3.1c69fb81.a01df.2946@mx.google.com> Date: Fri, 18 May 2018 11:42:36 -0600 Cc: Brock Allen , Hannes Tschofenig , "oauth@ietf.org" Message-Id: <0075D910-35DA-4B8B-A739-D57CF7A8765E@alkaline-solutions.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> To: John Bradley X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:42:42 -0000 --Apple-Mail=_DBDAF004-E118-4D0F-B1AF-17EF94248013 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t believe code flow today with an equivalent token policy = as you have with implicit causes any new security issues, and it does = correct _some_ problems. The problem is that you immediately want to = change token policy to get around hidden iframes and special parameters. Once you start trying to alter token policy (such as adding refresh = tokens), you start to have new security considerations because of the = execution environment of javascript in the browser. Specifically token = exfiltration from the browser origin, which can be mitigated via token = binding or service workers. You don=E2=80=99t need to exfiltrate a token for a third party to use a = the associated access; they can inject behavior onto the page via XSS or = a browser extension. This is not related to token lifetime policy, or = the use of implicit vs code. This is the more immediate area where I see = guidance being important - especially considering that token = exfiltration becomes closer to a theoretical attack if the behavior of = my app is controlled. -DW On May 18, 2018, at 10:47 AM, John Bradley wrote: >=20 > There are lots of issues with the current implicit flow around = fragment encoding as well. > =20 > However moving the token used for refresh from being a HTTP only = cookie to a refresh token available in the DOM makes me uncomfortable = without having sufficient mitigations against XSS. > =20 > The current flow is vulnerable to XSS for the AT, however if that is = short lived it restricts the damage. > =20 > The better solution is token binding the AT and perhaps a RT.=20 > =20 > We need to start talking about it. There are issues around = potentially using service workers etc as well. > =20 > So we should start but I am not sure of what the correct answer is = yet. > =20 > John B. > =20 > Sent from Mail for = Windows 10 > =20 > From: Brock Allen > Sent: Friday, May 18, 2018 6:36 PM > To: John Bradley ; David Waite = ; Hannes Tschofenig = > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > =20 > It sounds to me as if you're hesitant to recommend code flow (at least = for now) then for browser-based JS apps. > =20 > -Brock > =20 --Apple-Mail=_DBDAF004-E118-4D0F-B1AF-17EF94248013 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I don=E2=80=99t believe code flow today with an equivalent = token policy as you have with implicit causes any new security issues, = and it does correct _some_ problems. The problem is that you immediately = want to change token policy to get around hidden iframes and special = parameters.

Once= you start trying to alter token policy (such as adding refresh tokens), = you start to have new security considerations because of the execution = environment of javascript in the browser. Specifically token = exfiltration from the browser origin, which can be mitigated via token = binding or service workers.

You don=E2=80=99t need to exfiltrate a token for a third = party to use a the associated access; they can inject behavior onto the = page via XSS or a browser extension. This is not related to token = lifetime policy, or the use of implicit vs code. This is the more = immediate area where I see guidance being important - especially = considering that token exfiltration becomes closer to a theoretical = attack if the behavior of my app is controlled.

-DW

On May 18, 2018, at 10:47 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

There are = lots of issues with the current implicit flow around fragment encoding = as well.
 
However = moving the token used for refresh from being a HTTP only cookie to a = refresh token available in the DOM makes me uncomfortable without having = sufficient mitigations against XSS.
 
The current flow is vulnerable to  XSS for the AT, = however if that is short lived it restricts the = damage.
 
The = better solution is token binding the AT and perhaps a = RT. 
 
We need = to start talking about it.  There are issues around potentially = using service workers etc as well.
 
So we should start but I am not sure of what the correct = answer is yet.
 
John = B.
 
Sent = from Mail for Windows 10
 
From: Brock Allen
Sent: Friday, May 18, 2018 = 6:36 PM
To: John Bradley; David Waite; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] is = updated guidance needed for JS/SPA apps?
 
It sounds to me as if you're hesitant to = recommend code flow (at least for now) then for browser-based JS = apps.
 
-Brock
 
= --Apple-Mail=_DBDAF004-E118-4D0F-B1AF-17EF94248013-- From nobody Fri May 18 10:46: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 2C2B912DA06 for ; Fri, 18 May 2018 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 v9p-tbJ2-6Hp for ; Fri, 18 May 2018 10:46:22 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5D712D942 for ; Fri, 18 May 2018 10:46:21 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id m129-v6so16560172wmb.3 for ; Fri, 18 May 2018 10:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=DSbqQceAxxPo7RMMI/MW8uuo8i6qOtvcr9F87LAWJ2s=; b=FTs1iSijh0+Q2zDd6ixUHth5bFURli4vRumDcaFxFABqHMRC4VaMbVN6vxvJHvIQrV 5xz7uLdMvu42jyoqTF6kkaXyGvnOVPeTuApX5dv0UDYt1XoUtb9+b/11TSzilAa7CFu4 CRa0+8SVkZ/EpA4VNMAKzixCVL8PM1qM9MV96EwgsI9aXrUfHoVqQv0SsfULGH2uoHbH gLwc5gm4Fl3uf6af9gDHz9HB9ibASlXTh4ZiDxEIirGU5RCI9S5PzVBgELHS2XDBsGpA 7uwA7RHWfy/J4XKPNeL2Jp1s/JHgIygZW00b4FAtlohzwIEG0FOKlbXh3reJLeWVzm+a 6DJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=DSbqQceAxxPo7RMMI/MW8uuo8i6qOtvcr9F87LAWJ2s=; b=aA31C/w4mvMsm+kvd4ujov2F2BNrglUBqnMhJ6AvUfpQsrAEEHfsk2e56kVSbeae9E +WiyWDOY53KhFNFlD3vO59h8WXvHuJRgYKcIuOKBxGoQut4qGkkzrq4rqdzXOFq2po41 sG41yQL86SjuOCPSOmiU4e4anbrYRC68iTV+UGsjW+j3iSchey5cffdChmWanbbWbNXv /+ubrQ8mxUQUzLGnh6rrA5Ve7W/ey6yWqWZVfKfKobR5i6785OdXgELCLxfeachhBPXG Ol89YoTy8+K/Oie8Adiwb4YvD/+ZSsd4ewt3zYc/tYsxCMnAHWaQGwD93XkXuBltOPnI fbbw== X-Gm-Message-State: ALKqPwdHXdZZHnqvyrJkwu3PXeCEdXo2jQHsplt3GeiPHLz2XP/Uci8j uo/WJ5fWwYCMbhwaonXiEO5GKg== X-Google-Smtp-Source: AB8JxZrOhaRVsJnl1xciCUDoBLsGGNcrgNl32wsGob9AHV6sj5AJmvvB+s/hJ/jDUW6nLXSJ8WBQEQ== X-Received: by 2002:a1c:4792:: with SMTP id m18-v6mr4921404wmi.144.1526665579977; Fri, 18 May 2018 10:46:19 -0700 (PDT) Received: from ?IPv6:2001:1b18:a3:300:9cdb:2d14:3eec:54a3? ([2001:1b18:a3:300:9cdb:2d14:3eec:54a3]) by smtp.gmail.com with ESMTPSA id u36-v6sm9587382wrf.87.2018.05.18.10.46.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 10:46:19 -0700 (PDT) Message-ID: <5aff116b.1c69fb81.e47d3.d1f0@mx.google.com> MIME-Version: 1.0 To: Neil Madden , Jim Manico Cc: "oauth@ietf.org" From: John Bradley Date: Fri, 18 May 2018 19:46:20 +0200 Importance: normal X-Priority: 3 In-Reply-To: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> Content-Type: multipart/alternative; boundary="_84DC7DB3-204F-4436-BED7-80FA245FD654_" Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:46:25 -0000 --_84DC7DB3-204F-4436-BED7-80FA245FD654_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" You cant extract a token bound cookie or AT and use it in a different user = agent. You could still force the user agent to use a token bound cookie itself. =20 For the AT and refresh they are not cookies so they need to sent by the JS = so may be harder to trigger? I thought I was the pessimistic one=F0=9F=98=8A SPA may turn out to be impossible to completely secure. However that wont = stop people from creating them. We can try to put together the best advice, and limit the damage. John B. Sent from Mail for Windows 10 From: Neil Madden Sent: Friday, May 18, 2018 7:38 PM To: John Bradley; Jim Manico Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? I might be missing something here, but aren=E2=80=99t bound tokens exactly = as vulnerable to the XSS attacks you describe as http-only cookies are?=C2= =A0 =E2=80=94 Neil On Friday, May 18, 2018 at 5:43 pm, Jim Manico wrote: A few notes: >=C2=A0The session cookie should also be flagged as http only to protect it= .=C2=A0=C2=A0 This provides no real protection. If I get XSS into your site I don=E2=80= =99t need to steal the cookie. I can just force requests that will automati= cally send it (client side or stored request forgery). So while it=E2=80=99= s a standard suggestion, it helps little.=C2=A0 >=C2=A0Having a refresh token in local storrage may introduce new security = issues unless it is token bound.=C2=A0=C2=A0 Token binding is not live yet, right? If you need to store a token in a bro= wser please note there is no safe place to store it. LocalStorage can be ha= rvested by XSS and even the strongest cookies can be replayed as discussed = above. I can=E2=80=99t wait for browser based token binding! But it will li= kely take years for this to be avail in the majority of browsers. >=C2=A0Understanding the security issues of the code flow in the browser is= important, before any new recommendation.=C2=A0=C2=A0 Well said. It looks to be the only secure workflow for browser based apps. = Love it how passwords are kept away from RP=E2=80=99s and high powered toke= ns are not stored in the browser. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 On May 18, 2018, at 12:27 PM, John Bradley wrote: Yes that was the original intent to have the AT be short lived and refresh = the AT via the authorization endpoint based on the session cookie.=C2=A0=20 The session cookie should also be flagged as http only to protect it.=C2=A0= =20 Having a refresh token in local storrage may introduce new security issues = unless it is token bound.=C2=A0=20 Understanding the security issues of the code flow in the browser is import= ant, before any new recommendation.=C2=A0=20 John B.=20 From: Brock Allen Sent: Friday, May 18, 2:46 PM Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? To: David Waite, Hannes Tschofenig Cc: oauth@ietf.org One thing I maybe should have listed in the pros/cons in my original email = is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow.=20 What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh token= s), but I don't know about a browser-based JS app. In a sense there's a bit= of protection for the end user built into that design by virtue of being t= ied to the user's cookie at the AS/OP.=20 Just throwing that out as an additional discussion point. -Brock=20 On 5/18/2018 6:04:47 AM, David Waite wrote: I have written some guidance already (in non-RFC format)=C2=A0on preferring= code for single page apps, and other security practices (CORS, CSP). From = the AS point of view, it aligns well with the native apps BCP. There are be= nefits of thinking about native and SPA apps just as =E2=80=98public client= s=E2=80=99 from a policy/properties point of view. It also greatly simplifi= es OAuth/OIDC support on both the AS administrator and client developer sid= e when converting web properties into native apps using technologies like E= lectron or Cordova.=20 For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe = the need for a policy using short-lived refresh tokens, revoking at signout= , or use of the revocation endpoint are different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS= may need to support, and we happen to sometimes associate those usage patt= erns with typical usage of native apps vs of browser apps. For example, bro= wser login on a borrowed device can easily leak over to being app authoriza= tion - the authentication/authorization are web-based processes to achieve = SSO. I have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry pra= ctices. -DW On May 17, 2018, at 10:23 AM, Hannes Tschofenig = wrote: Hi Brock, =C2=A0 there have been several attempts to start writing some guidance but so far = we haven=E2=80=99t gotten too far. IMHO it would be great to have a document. =C2=A0 Ciao Hannes =C2=A0 From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Bro= ck Allen Sent:=C2=A017 May 2018 14:57 To:=C2=A0oauth@ietf.org Subject:=C2=A0[OAUTH-WG] is updated guidance needed for JS/SPA apps? =C2=A0 Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask beca= use google is actively discouraging the use of implicit flow: =C2=A0 https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 =C2=A0 >From what I can tell, the complaints with implicit are: * access token in URL * access token in browser history * iframe complexity when using prompt=3Dnone to "refresh" access tokens =C2=A0 But this requires: * AS/OP to support PKCE *=C2=A0AS/OP to support=C2=A0CORS=C2=A0 * user-agent must support CORS * AS/OP to maintain short-lived refresh tokens=C2=A0 * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) * if the above point can't work, then client must proactively use revocatio= n endpoint if/when user triggers logout =C2=A0 Any use in discussing this? =C2=A0 -Brock =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.=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 _______________________________________________=20 OAuth mailing list=20 OAuth@ietf.org=20 https://www.ietf.org/mailman/listinfo/oauth=20 --_84DC7DB3-204F-4436-BED7-80FA245FD654_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

You cant extract a token bound cooki= e or AT and use it in a different user agent.

=  

You could still force the user agent t= o use a token bound cookie itself.=C2=A0

&nbs= p;

For the AT and refresh they are not cookie= s so they need to sent by the JS so may be harder to trigger?

 

I thought I was the = pessimistic one = 8522;

 

SPA may turn out to be impossible to completely secure.=C2=A0 However t= hat wont stop people from creating them.

 = ;

We can try to put together the best advice,= and limit the damage.

 

John B.

 

Sent from Mail for Windows 10

 

From: Neil Madden
Sent: Friday, May 18, 2018 7:38 PM
To:= John Bradley; Jim Manico
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] is updated gu= idance needed for JS/SPA apps?

 

I might be missing something here, but are= n=E2=80=99t bound tokens exactly as vulnerable to the XSS attacks you descr= ibe as http-only cookies are? 

 

=E2=80=94 Neil

=  

On Friday, May 18, 2018 at 5:43 pm, Jim Manico <jim@manicode.com> wrote:

A few notes:

> The session cook= ie should also be flagged as http only to protect it.  

 

This provides no real protection. If I get= XSS into your site I don=E2=80=99t need to steal the cookie. I can just fo= rce requests that will automatically send it (client side or stored request= forgery). So while it=E2=80=99s a standard suggestion, it helps little.&nb= sp;

 

> Having a refr= esh token in local storrage may introduce new security issues unless it is = token bound.  

 

To= ken binding is not live yet, right? If you need to store a token in a brows= er please note there is no safe place to store it. LocalStorage can be harv= ested by XSS and even the strongest cookies can be replayed as discussed ab= ove. I can=E2=80=99t wait for browser based token binding! But it will like= ly take years for this to be avail in the majority of browsers.<= /span>

 

=

> Understanding the security i= ssues of the code flow in the browser is important, before any new recommen= dation.  

 

Well s= aid. It looks to be the only secure workflow for browser based apps. Love i= t how passwords are kept away from RP=E2=80=99s and high powered tokens are= not stored in the browser.

 

Aloha,

--

= Jim Manico

@Manic= ode

Secure Coding= Education

+1 (80= 8) 652-3805


On May 18, 2018, at 12:27 PM, John Brad= ley <ve7jtb@ve7jtb.com> wrot= e:

Yes that was th= e original intent to have the AT be short lived and refresh the AT via the = authorization endpoint based on the session cookie. 

The session cookie shou= ld also be flagged as http only to protect it. 

=

Having a refresh token in l= ocal storrage may introduce new security issues unless it is token bound.&n= bsp;

U= nderstanding the security issues of the code flow in the browser is importa= nt, before any new recommendation. 

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>John B.

From: Brock Allen

Sent: Friday, = May 18, 2:46 PM

Subject: Re: [OAUTH-WG= ] is updated guidance needed for JS/SPA apps?

To: David Waite, Hannes Tschofenig

One thing I maybe should have listed in the pros/cons in= my original email is session management and token lifetime considerations,= keeping in mind the original intent of the implicit flow.

What I mean is that wi= th implicit grant type, the client's ability to get new access tokens is li= mited to the user's session at the AS/OP. Obviously other flows make more s= ense to obtain longer lived access (via refresh tokens), but I don't know a= bout a browser-based JS app. In a sense there's a bit of protection for the= end user built into that design by virtue of being tied to the user's cook= ie at the AS/OP.

Just throwing that out as an additional discussion point.

-Brock <= /o:p>

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> wrote:

I have w= ritten some guidance already (in non-RFC format) on preferring code fo= r single page apps, and other security practices (CORS, CSP). From the AS p= oint of view, it aligns well with the native apps BCP. There are benefits o= f thinking about native and SPA apps just as =E2=80=98public clients=E2=80= =99 from a policy/properties point of view. It also greatly simplifies OAut= h/OIDC support on both the AS administrator and client developer side when = converting web properties into native apps using technologies like Electron= or Cordova.

For the later requirements in the list around token policy, I am not= sure these are requirements for single page apps per se. I don=E2=80=99t b= elieve the need for a policy using short-lived refresh tokens, revoking at = signout, or use of the revocation endpoint are different from browser and n= ative applications. Rather they seem to be a function of usage patterns tha= t an AS may need to support, and we happen to sometimes associate those usa= ge patterns with typical usage of native apps vs of browser apps. For examp= le, browser login on a borrowed device can easily leak over to being app au= thorization - the authentication/authorization are web-based processes to a= chieve SSO.

I have been working on some guidance here around token lifetimes and p= olicies, but I don=E2=80=99t know whether that brings in too much AS/OP bus= iness logic (and, likely implied product/deployment features) to be industr= y practices.

-DW

= On May 17, 2018,= at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

=

Hi Brock,

 <= /span>

there have been several attempts to start writing= some guidance but so far we haven=E2=80=99t gotten too far.

IMHO it would be great to have a document.

 

Cia= o

Hannes

 

From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Brock Allen

Sent: 17 May 2018 14:57

=

Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps= ?

 

Much like updated guidance was provided with the "OAuth2 for n= ative apps" RFC, should there be one for "browser-based client-si= de JS apps"? I ask because google is actively discouraging the use of = implicit flow:

 

 =

>From what I can tell, the complaints w= ith implicit are:

* access token in UR= L

* access token in browser history

* iframe complexity when using prompt=3D= none to "refresh" access tokens

<= p class=3DMsoNormal> 

But this requires:

* AS/OP to support PKCE

<= /div>

* AS/OP to support CORS 

* user-agent must support CORS

=

* AS/OP to maintain short-lived refresh tokens 

* AS/OP must aggressively revoke refresh tokens at= user signout (which is not something OAuth2 "knows" about)<= /o:p>

* if the above point can't work, then clien= t must proactively use revocation endpoint if/when user triggers logout

 

Any use in discussing this?

 <= o:p>

-Brock

 

IMPORTANT NOTICE: The con= tents of this email and any attachments are confidential and may also be pr= ivileged. If you are not the intended recipient, please notify the sender i= mmediately 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.&nb= sp;_______________________________________________

OAuth mailing list

<= div>

https://ww= w.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

 <= /o:p>

= --_84DC7DB3-204F-4436-BED7-80FA245FD654_-- From nobody Fri May 18 10:55: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 E335412D95D for ; Fri, 18 May 2018 10:55:51 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kqAwX_m15Yjq for ; Fri, 18 May 2018 10:55:50 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 50D1412D942 for ; Fri, 18 May 2018 10:55:50 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id b22-v6so7095806qkj.9 for ; Fri, 18 May 2018 10:55:50 -0700 (PDT) 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=Jw3N2yrbgQ0XUf1GNQDCrc+RwLDv5yMSxhA1h2y0/Zw=; b=HbzPQeIk0+eG9l1sOc98tc9DYFKTm3XPAN2sMDbKK1wuUYAWBhCSjEpp0QIN8cPMp7 CDWtWxQLkqgotbMnO9g97MsB4VJ7YTWOVsLcZ6pGZh5QmLsAFU/PqjdURR9RPzplcwhS AnLOWxIiPmY6gAZWsFw/zOlfri8sBIfJqnyboIVxCe4KexI0TLXObTSV5UDHzwMXoEcH u74JZH4lPhry4sRUoDGQswu9c0w6tEpniIEI0l808ZZjzzK/LXwXyPu0iUCf0DOm+Adv OKzHhWg/w9lvKmjnrXT+wnIUo/Z0GleCpN1Cc6sK0kAKkm93ihIcOkbx1UCnJcKiQn1C iT5Q== 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=Jw3N2yrbgQ0XUf1GNQDCrc+RwLDv5yMSxhA1h2y0/Zw=; b=sJwz+C8DgVN0IuD5srkhpfeC+e7G3/N9vsXA3S7XFl2sAZTW8e7xto3TuZsOMsZcDc IsfRnpzXaiGxuHMqzVEl5t7awDPwp4P1kxAYBMQGLqdqz8zBfeeJR9u/Jl6Q6AndrLiF sNS+kbyYNJSCjJ3ja1cxhYu54DTzGKSKHlVGoPjVPMe+KMxAjhIYz6RCSVFj5A/Etmbk ffpatJtZFCTCZqhkAOKf548U6//C8pRP/F2rRuFC/luHcB37hvQnTzbNdpIZq4D2spHs Z4BV+zv/f83+6rP6gDinEC6krm5r3Bo8tjgAJFoPPavoLreHcBM9u0rWP28WV7o1lGVD FXKw== X-Gm-Message-State: ALKqPwcNSNwL+sWf8fcJKupAjcJoz+8DKNUC3lhpyOabG0S3coi7ia3L Fogy6/z/3tPamF8YRWjzt/w= X-Google-Smtp-Source: AB8JxZqvMyQfsKZeKPRLG2QOc27JRtj4jAI/CsdKd2VW+xGFYaMrArGzKzQVYEHntT01TnvORIozxA== X-Received: by 2002:a37:5ac5:: with SMTP id o188-v6mr9340870qkb.295.1526666149052; Fri, 18 May 2018 10:55:49 -0700 (PDT) Received: from [172.20.10.3] ([172.58.233.201]) by smtp.gmail.com with ESMTPSA id q8-v6sm5967398qtb.13.2018.05.18.10.55.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 10:55:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_12625737.623923963556" MIME-Version: 1.0 Date: Fri, 18 May 2018 13:55:42 -0400 Message-ID: <5076c4e6-ae3f-4632-b133-146a04db7ec9@getmailbird.com> From: "Brock Allen" To: "David Waite" , "John Bradley" Cc: "Hannes Tschofenig" , "" In-Reply-To: <0075D910-35DA-4B8B-A739-D57CF7A8765E@alkaline-solutions.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> <0075D910-35DA-4B8B-A739-D57CF7A8765E@alkaline-solutions.com> User-Agent: Mailbird/2.5.8.0 X-Mailbird-ID: 5076c4e6-ae3f-4632-b133-146a04db7ec9@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:55:52 -0000 ------=_NextPart_12625737.623923963556 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0I don=E2=80=99t believe code flow today with an equivalent token pol= icy as you have with implicit causes any new security issues, and it does c= orrect _some_ problems. The problem is that you immediately want to change = token policy to get around hidden iframes and special parameters. Hidden frames and special params -- are those really the main concerns with= implicit? Those are just different mechanics to do the same thing.=C2=A0IM= O, iframes are just another way to "do" HTTP, albeit more clumsy and effort= than XMLHttpRequest. And in my experience, prompt=3Dnone is easily done an= d well supported. Perhaps my perspective is skewed. I thought the access token being sent in the URL is a bigger concern, and t= hat's why code+PKCE is a better approach. -Brock ------=_NextPart_12625737.623923963556 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;I don=E2=80=99t believe code flow today wi= th an equivalent token policy as you have with implicit causes any new secu= rity issues, and it does correct _some_ problems. The problem is that you i= mmediately want to change token policy to get around hidden iframes and spe= cial parameters.

Hidden frames and special pa= rams -- are those really the main concerns with implicit? Those are just di= fferent mechanics to do the same thing. IMO, iframes are just another way to "do" HTTP, al= beit more clumsy and effort than XMLHttpRequest. And in my experience, prom= pt=3Dnone is easily done and well supported. Perhaps my perspective is skew= ed.

I thought the access token being sent i= n the URL is a bigger concern, and that's why code+PKCE is a better approac= h.

-Brock
=0A =0A =0A =
------=_NextPart_12625737.623923963556-- From nobody Fri May 18 11:21: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 2C94B12D810 for ; Fri, 18 May 2018 11:21:08 -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, 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 buqLiWMCTFLY for ; Fri, 18 May 2018 11:21:06 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 975A312D80E for ; Fri, 18 May 2018 11:21:06 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403] (unknown [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403]) by alkaline-solutions.com (Postfix) with ESMTPSA id A43C931544; Fri, 18 May 2018 18:21:05 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A6FD39A7-5BA8-442C-8C02-54144559921F" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 18 May 2018 12:21:03 -0600 In-Reply-To: <5076c4e6-ae3f-4632-b133-146a04db7ec9@getmailbird.com> Cc: John Bradley , Hannes Tschofenig , oauth@ietf.org To: Brock Allen References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> <0075D910-35DA-4B8B-A739-D57CF7A8765E@alkaline-solutions.com> <5076c4e6-ae3f-4632-b133-146a04db7ec9@getmailbird.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 18:21:08 -0000 --Apple-Mail=_A6FD39A7-5BA8-442C-8C02-54144559921F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 18, 2018, at 11:55 AM, Brock Allen = wrote: >=20 > > I don=E2=80=99t believe code flow today with an equivalent token = policy as you have with implicit causes any new security issues, and it = does correct _some_ problems. The problem is that you immediately want = to change token policy to get around hidden iframes and special = parameters. >=20 > Hidden frames and special params -- are those really the main concerns = with implicit? They aren=E2=80=99t the only issues, no. The point was that you can use = code flow instead of implicit, keep a 10 minute access token lifetime = and no refresh token, and it doesn=E2=80=99t add new security concerns. = The security concerns are around changing token policy once you are = doing code flow, due to the execution environment of the browser. The main initial motivation around implicit was client simplicity (plus = it was rather early for CORS). Once you are implementing a second = iframe-based approach to discretely retrieve updated access tokens, the = simplicity argument doesn=E2=80=99t hold. It is also an additional security consideration for the AS - ideally I = want to reject my user authentication/consent content from being loaded = in frames as a static policy, but now I need to allow it when = prompt=3Dnone is set. This isn=E2=80=99t a policy recommended anyplace, = just something the developers may have to argue with against the = security people so that their app can have a halfway decent experience. -DW > I thought the access token being sent in the URL is a bigger concern, = and that's why code+PKCE is a better approach. >=20 > -Brock --Apple-Mail=_A6FD39A7-5BA8-442C-8C02-54144559921F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 18, 2018, at 11:55 AM, Brock Allen <brockallen@gmail.com> wrote:

=20 =20 =20 =20 =20 > I don=E2=80=99t believe code flow = today with an equivalent token policy as you have with implicit causes = any new security issues, and it does correct _some_ problems. The = problem is that you immediately want to change token policy to get = around hidden iframes and special parameters.

Hidden frames and = special params -- are those really the main concerns with = implicit?

They = aren=E2=80=99t the only issues, no. The point was that you can use code = flow instead of implicit, keep a 10 minute access token lifetime and no = refresh token, and it doesn=E2=80=99t add new security concerns. The = security concerns are around changing token policy once you are doing = code flow, due to the execution environment of the = browser.

The main initial motivation = around implicit was client simplicity (plus it was rather early for = CORS). Once you are implementing a second iframe-based approach to = discretely retrieve updated access tokens, the simplicity argument = doesn=E2=80=99t hold.

It is also an = additional security consideration for the AS - ideally I want to reject = my user authentication/consent content from being loaded in frames as a = static policy, but now I need to allow it when prompt=3Dnone is set. = This isn=E2=80=99t a policy recommended anyplace, just something the = developers may have to argue with against the security people so that = their app can have a halfway decent experience.

-DW

I thought the = access token being sent in the URL is a bigger concern, and that's why = code+PKCE is a better approach.


-Brock
=20 =

= --Apple-Mail=_A6FD39A7-5BA8-442C-8C02-54144559921F-- From nobody Fri May 18 11:51: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 E1A4012DA21 for ; Fri, 18 May 2018 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 LAwGUCwgXx_g for ; Fri, 18 May 2018 11:51:20 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 98C3912D80E for ; Fri, 18 May 2018 11:51:19 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id x12-v6so4473975wmc.0 for ; Fri, 18 May 2018 11:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=gbnCPOqvanlnuqw+xmhNBwnPg2PBKmTKuQzCCrlu9Ow=; b=kU8JhFtXwXci0zT8Af6AS3LJzVcTWx8bFHzClXzRw171AajRQIXKVam2QHB/Q52avM X05GNVNQ+GMyrNabZ78wiw6YYomolfqXClNrMqgN/iJQIpAoergeWHkGc9XDYYlodZyP R7qF4faD3N6igVuddQcmflNLKQJm4CJqn6Dy8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=gbnCPOqvanlnuqw+xmhNBwnPg2PBKmTKuQzCCrlu9Ow=; b=XzEeSSAwvHLUq/1Kv9epTTnIrXGg0c5p1V0PR9hJb81sjB9i32RJOXvNgTZOinqm5A /SBvQPtjnYxepefG7JrGjd7REwz7QazWriRoSyPdj78D+xG2yASIpkyz9e9BCtrZbU6P WBd+gg7xmoy+2mHtTNZFYOoC/YI4dLXieMPI+L+3jWBWQHIFuGPFhjDdgess0Fm1eMxy lvek8HqpY/s9UVauKFPoSnaZoxnh+DkFOfSLQ2rhfxNSRTJmorfuOYLdNgwxpj2hLYyC /iQldtyaMoFBrD/5s7Glg+10H7hz6Q7ZlyJaGPbNRNbZwmvVNVI+JfRzEUWQypzTP/0f BQsw== X-Gm-Message-State: ALKqPwemb4dAD3pTZ3EXjBTL0gbdBfWnSENePIozxl/OPPag4EhtEFz3 cRix+WoYXn9/4FCxnKyb5sS1mHnExZk= X-Google-Smtp-Source: AB8JxZpu8KBPSHGhzax6wddNSozOSld0tPcs0eSTlGYajgOvSAfZ+Ne+1DOt8x0AVMRpnkrjZEMuUQ== X-Received: by 2002:a1c:d0c2:: with SMTP id h185-v6mr4918517wmg.59.1526669477752; Fri, 18 May 2018 11:51:17 -0700 (PDT) Received: from [192.168.1.81] (8.150.32.217.dyn.plus.net. [217.32.150.8]) by smtp.gmail.com with ESMTPSA id 38-v6sm15699153wry.61.2018.05.18.11.51.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 11:51:16 -0700 (PDT) Date: Fri, 18 May 2018 19:51:14 +0100 From: Neil Madden To: Jim Manico , John Bradley Cc: "=?utf-8?Q?oauth=40ietf.org?=" Message-ID: <9f849caf-1f78-48b2-8cc9-9e0ad0299ce2@Canary> In-Reply-To: <5aff116b.1c69fb81.e47d3.d1f0@mx.google.com> References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> <5aff116b.1c69fb81.e47d3.d1f0@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="5aff20a3_66334873_6e7"; protocol="application/pgp-signature" Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 18:51:24 -0000 --5aff20a3_66334873_6e7 Content-Type: multipart/alternative; boundary="5aff20a3_643c9869_6e7" --5aff20a3_643c9869_6e7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ha=21 Well it was Jim Manico=E2=80=99s pessimism about http-only cookies = that started it=21 :-) I agree with Jim about http-only, and I agree with you that token binding= has lots of other good advantages. But pretty much all security is lost = if XSS is a possibility. Even storing secrets on the server does not help= much as if I can forge requests from the same origin then I can probably= trick the server into performing actions on my behalf too. Preventing/mi= tigating XSS is crucial (CSP is a big help), but that is not specific to = OAuth. =E2=80=94 Neil > On =46riday, May 18, 2018 at 6:46 pm, John Bradley wrote: > > You cant extract a token bound cookie or AT and use it in a different u= ser agent. > > > > > > You could still force the user agent to use a token bound cookie itself= . > > > > > > =46or the AT and refresh they are not cookies so they need to sent by t= he JS so may be harder to trigger=3F > > > > > > I thought I was the pessimistic one=F0=9F=98=8A > > > > > > SPA may turn out to be impossible to completely secure. However that wo= nt stop people from creating them. > > > > > > We can try to put together the best advice, and limit the damage. > > > > > > John B. > > > > > > Sent from Mail (https://go.microsoft.com/fwlink/=3FLinkId=3D550986) for= Windows 10 > > > > > > =46rom: Neil Madden (mailto:neil.madden=40forgerock.com) > Sent: =46riday, May 18, 2018 7:38 PM > To: John Bradley (mailto:ve7jtb=40ve7jtb.com); Jim Manico (mailto:jim=40= manicode.com) > Cc: oauth=40ietf.org (mailto:oauth=40ietf.org) > Subject: Re: =5BOAUTH-WG=5D is updated guidance needed for JS/SPA apps=3F= > > > > > > > I might be missing something here, but aren=E2=80=99t bound tokens exac= tly as vulnerable to the XSS attacks you describe as http-only cookies ar= e=3F > > > > > > > =E2=80=94 Neil > > > > > > > > > > On =46riday, May 18, 2018 at 5:43 pm, Jim Manico wrote: > > > > > > > > A few notes: > > > > > The session cookie should also be flagged as http only to protect i= t. > > > > > > > > > > > > > > This provides no real protection. If I get XSS into your site I don=E2= =80=99t need to steal the cookie. I can just force requests that will aut= omatically send it (client side or stored request forgery). So while it=E2= =80=99s a standard suggestion, it helps little. > > > > > > > > > > > > > > > > > Having a refresh token in local storrage may introduce new security= issues unless it is token bound. > > > > > > > > > > > > > > > > Token binding is not live yet, right=3F If you need to store a token = in a browser please note there is no safe place to store it. LocalStorage= can be harvested by XSS and even the strongest cookies can be replayed a= s discussed above. I can=E2=80=99t wait for browser based token binding=21= But it will likely take years for this to be avail in the majority of br= owsers. > > > > > > > > > > > > > > > > > Understanding the security issues of the code flow in the browser i= s important, before any new recommendation. > > > > > > > > > > > > > > > > Well said. It looks to be the only secure workflow for browser based = apps. Love it how passwords are kept away from RP=E2=80=99s and high powe= red tokens are not stored in the browser. > > > > > > > > > > > > > > > > Aloha, > > > > > > -- > > > > > > > > Jim Manico > > > > > > > > =40Manicode > > > > > > > > Secure Coding Education > > > > > > > > +1 (808) 652-3805 > > > > > > > > > > > > On May 18, 2018, at 12:27 PM, John Bradley wrote: > > > > > > > > > > Yes that was the original intent to have the AT be short lived and = refresh the AT via the authorization endpoint based on the session cookie= . > > > > > > > > > > > > The session cookie should also be flagged as http only to protect i= t. > > > > > > > > > > > > Having a refresh token in local storrage may introduce new security= issues unless it is token bound. > > > > > > > > > > > > Understanding the security issues of the code flow in the browser i= s important, before any new recommendation. > > > > > > > > > > > > John B. > > > > > > > > > > > > =46rom: Brock Allen > > > > > > > > > > > > Sent: =46riday, May 18, 2:46 PM > > > > > > > > > > > > Subject: Re: =5BOAUTH-WG=5D is updated guidance needed for JS/SPA a= pps=3F > > > > > > > > > > > > To: David Waite, Hannes Tschofenig > > > > > > > > > > > > Cc: oauth=40ietf.org (mailto:oauth=40ietf.org) > > > > > > > > > > > > > > > > > > One thing I maybe should have listed in the pros/cons in my origina= l email is session management and token lifetime considerations, keeping = in mind the original intent of the implicit flow. > > > > > > > > > > > > What I mean is that with implicit grant type, the client's ability = to get new access tokens is limited to the user's session at the AS/OP. O= bviously other flows make more sense to obtain longer lived access (via r= efresh tokens), but I don't know about a browser-based JS app. In a sense= there's a bit of protection for the end user built into that design by v= irtue of being tied to the user's cookie at the AS/OP. > > > > > > > > > > > > Just throwing that out as an additional discussion point. > > > > > > > > > > > > -Brock > > > > > > > > > > > > > > On 5/18/2018 6:04:47 AM, David Waite wrote: > > > > > > > > > > > > > > > > I have written some guidance already (in non-R=46C format) on pre= ferring code for single page apps, and other security practices (CORS, CS= P). =46rom the AS point of view, it aligns well with the native apps BCP.= There are benefits of thinking about native and SPA apps just as =E2=80=98= public clients=E2=80=99 from a policy/properties point of view. It also g= reatly simplifies OAuth/OIDC support on both the AS administrator and cli= ent developer side when converting web properties into native apps using = technologies like Electron or Cordova. > > > > > > > > > > > > > > > > =46or the later requirements in the list around token policy, I a= m not sure these are requirements for single page apps per se. I don=E2=80= =99t believe the need for a policy using short-lived refresh tokens, revo= king at signout, or use of the revocation endpoint are different from bro= wser and native applications. Rather they seem to be a function of usage = patterns that an AS may need to support, and we happen to sometimes assoc= iate those usage patterns with typical usage of native apps vs of browser= apps. =46or example, browser login on a borrowed device can easily leak = over to being app authorization - the authentication/authorization are we= b-based processes to achieve SSO. > > > > > > > > > > > > > > > > I have been working on some guidance here around token lifetimes = and policies, but I don=E2=80=99t know whether that brings in too much AS= /OP business logic (and, likely implied product/deployment features) to b= e industry practices. > > > > > > > > > > > > > > > > -DW > > > > > > > > > > > > > > > > > > > > > On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: > > > > > > > > > > > > > > > > > > > > Hi Brock, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > there have been several attempts to start writing some guidance= but so far we haven=E2=80=99t gotten too far. > > > > > > > > > > > > > > > > > > > > IMHO it would be great to have a document. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > > > > > > > > > > > > > > > Hannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: OAuth =5Bmailto:oauth-bounces=40ietf.org=5D On Behalf O= f Brock Allen > > > > > > > > > > > > > > > > > > > > Sent: 17 May 2018 14:57 > > > > > > > > > > > > > > > > > > > > To: oauth=40ietf.org (mailto:oauth=40ietf.org) > > > > > > > > > > > > > > > > > > > > Subject: =5BOAUTH-WG=5D is updated guidance needed for JS/SPA a= pps=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Much like updated guidance was provided with the =22OAuth2 for = native apps=22 R=46C, should there be one for =22browser-based client-sid= e JS apps=22=3F I ask because google is actively discouraging the use of = implicit flow: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/openid/AppAuth-JS/issues/59=23issuecomment-3= 89639290 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=46rom what I can tell, the complaints with implicit are: > > > > > > > > > > > > > > > > > > > > * access token in URL > > > > > > > > > > > > > > > > > > > > * access token in browser history > > > > > > > > > > > > > > > > > > > > * iframe complexity when using prompt=3Dnone to =22refresh=22 a= ccess tokens > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But this requires: > > > > > > > > > > > > > > > > > > > > * AS/OP to support PKCE > > > > > > > > > > > > > > > > > > > > * AS/OP to support CORS > > > > > > > > > > > > > > > > > > > > * user-agent must support CORS > > > > > > > > > > > > > > > > > > > > * AS/OP to maintain short-lived refresh tokens > > > > > > > > > > > > > > > > > > > > * AS/OP must aggressively revoke refresh tokens at user signout= (which is not something OAuth2 =22knows=22 about) > > > > > > > > > > > > > > > > > > > > * if the above point can't work, then client must proactively u= se revocation endpoint if/when user triggers logout > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any use in discussing this=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Brock > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 t= he information in any medium. Thank you. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > > > > > > > > > > > > > > > > > > OAuth mailing list > > > > > > > > > > > > > > > > > > > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > OAuth mailing list > > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OAuth mailing list > OAuth=40ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > --5aff20a3_643c9869_6e7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22>
= Ha=21 Well it was Jim Manico=E2=80=99s pessimism about http-only cookies = that started it=21 :-)

I agree with Jim about ht= tp-only, and I agree with you that token binding has lots of other good a= dvantages. But pretty much all security is lost if XSS is a possibility. = Even storing secrets on the server does not help much as if I can forge r= equests from the same origin then I can probably trick the server into pe= rforming actions on my behalf too. Preventing/mitigating XSS is crucial (= CSP is a big help), but that is not specific to OAuth.=C2=A0
=E2=80=94 Neil

<= div>On =46riday, May 18, 2018 at 6:46 pm, John Bradley <ve7jtb=40ve7jtb.com> wrote:
=

You cant extract a= token bound cookie or AT and use it in a different user agent.

=C2=A0

You = could still force the user agent to use a token bound cookie itself.=C2=A0=

=C2=A0

=46or the AT and refresh they are not cookies so they need to sent= by the JS so may be harder to trigger=3F

<= o:p>=C2=A0

I thought I was the pessim= istic one=F0=9F=98=8A

=C2=A0=

SPA may turn out to be impossible to compl= etely secure.=C2=A0 However that wont stop people from creating them.

=

=C2=A0

We can try to put together the best advice, and limit the damage.

=C2=A0

J= ohn B.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

=46rom: Neil Madden
Sent= : =46riday, May 18, 2018 7:38 PM
To: John Bradley; Jim Manico
Cc: oauth=40ietf.org
Subject: Re: =5BOAUTH-WG=5D is updated= guidance needed for JS/SPA apps=3F

<= o:p>=C2=A0

I mig= ht be missing something here, but aren=E2=80=99t bound tokens exactly as = vulnerable to the XSS attacks you describe as http-only cookies are=3F=C2= =A0

=C2=A0

=E2=80=94 Neil

=C2=A0

On =46riday, M= ay 18, 2018 at 5:43 pm, Jim Manico <jim=40manicode.com> wrote:

A few notes:

>= =C2=A0The session cookie should also be flagged as http only to protect i= t.=C2=A0=C2=A0

=C2=A0

This provides no real protection. If I get = XSS into your site I don=E2=80=99t need to steal the cookie. I can just f= orce requests that will automatically send it (client side or stored requ= est forgery). So while it=E2=80=99s a standard suggestion, it helps littl= e.=C2=A0

=C2=A0

>=C2=A0Having a refresh token in local s= torrage may introduce new security issues unless it is token bound.=C2=A0= =C2=A0

=C2=A0

Token binding is not live yet, right=3F If yo= u need to store a token in a browser please note there is no safe place t= o store it. LocalStorage can be harvested by XSS and even the strongest c= ookies can be replayed as discussed above. I can=E2=80=99t wait for brows= er based token binding=21 But it will likely take years for this to be av= ail in the majority of browsers.

=C2=A0

>=C2=A0Understan= ding the security issues of the code flow in the browser is important, be= fore any new recommendation.=C2=A0=C2=A0

=

=C2=A0<= /p>

Well said. = It looks to be the only secure workflow for browser based apps. Love it h= ow passwords are kept away from RP=E2=80=99s and high powered tokens are = not stored in the browser.

=C2=A0

=

Aloha,<= /p>

--

Jim Manico

=40Manicode

Secure C= oding Education

+1 (808) 652-3805

=


On May 18, 2018, at 12:27 PM, John Bradley <ve7jtb=40ve7jtb.com> wrote:

Yes that was the original intent to have the AT be short li= ved and refresh the AT via the authorization endpoint based on the sessio= n cookie.=C2=A0

The session cookie should also be fla= gged as http only to protect it.=C2=A0

<= p class=3D=22MsoNormal=22 style=3D=22margin-bottom:12.0pt=22>Having a refre= sh token in local storrage may introduce new security issues unless it is= token bound.=C2=A0

Understanding the security issu= es of the code flow in the browser is important, before any new recommend= ation.=C2=A0

John B.

=46rom: Brock Allen

Sent: =46riday, May 18, 2:46 PM<= /o:p>

Subject: Re: =5BOAU= TH-WG=5D is updated guidance needed for JS/SPA apps=3F<= /p>

To: David Waite, Hannes Tschofen= ig

One thing I maybe should hav= e listed in the pros/cons in my original email is session management and = token lifetime considerations, keeping in mind the original intent of the= implicit flow.

What I mean is that with implicit gra= nt type, the client's ability to get new access tokens is limited to the = user's session at the AS/OP. Obviously other flows make more sense to obt= ain longer lived access (via refresh tokens), but I don't know about a br= owser-based JS app. In a sense there's a bit of protection for the end us= er built into that design by virtue of being tied to the user's cookie at= the AS/OP.

Just throwing that out as an additional= discussion point.

-Brock

On 5/18/2018 6:04:47 AM, David Waite <david=40alkaline-solutions.co= m> wrote:

I have written some guidance already = (in non-R=46C format)=C2=A0on preferring code for single page apps, and o= ther security practices (CORS, CSP). =46rom the AS point of view, it alig= ns well with the native apps BCP. There are benefits of thinking about na= tive and SPA apps just as =E2=80=98public clients=E2=80=99 from a policy/= properties point of view. It also greatly simplifies OAuth/OIDC support o= n both the AS administrator and client developer side when converting web= properties into native apps using technologies like Electron or Cordova.=

=46or the later requirements in the list around to= ken policy, I am not sure these are requirements for single page apps per= se. I don=E2=80=99t believe the need for a policy using short-lived refr= esh tokens, revoking at signout, or use of the revocation endpoint are di= fferent from browser and native applications. Rather they seem to be a fu= nction of usage patterns that an AS may need to support, and we happen to= sometimes associate those usage patterns with typical usage of native ap= ps vs of browser apps. =46or example, browser login on a borrowed device = can easily leak over to being app authorization - the authentication/auth= orization are web-based processes to achieve SSO.

I = have been working on some guidance here around token lifetimes and polici= es, but I don=E2=80=99t know whether that brings in too much AS/OP busine= ss logic (and, likely implied product/deployment features) to be industry= practices.

-DW

On May 17, 2018, at 10= :23 AM, Hannes Tschofenig <Hannes.Tschofenig=40arm.com> wrote:

=

Hi Brock,

=C2=A0

=

there have been several attempts to start writ= ing some guidance but so far we haven=E2=80=99t gotten too far.

IMHO it would be great = to have a document.

=C2=A0

<= span style=3D=22font-family:"Arial",sans-serif;color:black=22>C= iao

Hannes

=C2=A0=

=46rom:=C2= =A0OAuth =5Bmailto:oauth-= bounces=40ietf.org=5D=C2=A0On Behalf Of=C2=A0Brock Allen<= /o:p>

Sent:<= span style=3D=22font-family:"Arial",sans-serif;color:black=22>=C2= =A017 May 2018 14:57

Subject:=C2=A0=5BOAUTH-WG=5D is updated guidance needed= for JS/SPA apps=3F

=C2=A0

<= span style=3D=22font-family:"Arial",sans-serif;color:black=22>M= uch like updated guidance was provided with the =22OAuth2 for native apps= =22 R=46C, should there be one for =22browser-based client-side JS apps=22= =3F I ask because google is actively discouraging the use of implicit flo= w:

=C2=A0=

=C2=A0

>=46rom what I can= tell, the complaints with implicit are:

=

* access token in URL

* access token in browser history=

* iframe complexit= y when using prompt=3Dnone to =22refresh=22 access tokens

=C2=A0

<= /div>

But this requires:=

* AS/OP to support PKCE

*=C2=A0AS/OP to suppo= rt=C2=A0CORS=C2=A0

* user-agent must support CORS

* AS/OP to maintain short-lived refresh tokens=C2=A0=

* AS/OP must a= ggressively revoke refresh tokens at user signout (which is not something= OAuth2 =22knows=22 about)

* if the above point can't work, then client must proactivel= y use revocation endpoint if/when user triggers logout<= /p>

=C2=A0

Any use in discussing this=3F

=C2=A0

-Brock

=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 disclose the contents to any other person, use it for any purpose,= or store or copy the information in any medium. Thank you.=C2=A0=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

OAuth mailing list=



=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing listOAuth=40ietf.org
https://www.ietf.org/ma= ilman/listinfo/oauth

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40i= etf.org
https://www.ietf.org/mailman/listinfo/oauth

=C2=A0

=
--5aff20a3_643c9869_6e7-- --5aff20a3_66334873_6e7 Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary Comment: https://www.canarymail.io Charset: UTF-8 wsFcBAABCgAGBQJa/yCjAAoJEJD4Q99O3axdIF8P/iJPhjW+PL99l2mqMJ8+WmCCspUcmdHd81kA zOt4YGICBS6oZGHA86eSHRdlfttYzEY4ItHqA6eRIHkQ9gy6sHk7mGAyr1M59zHFkxWfzzqOYy+y /RYYv/zpQoQQIzGfPbMB9+g3WQ0KOiait5LDfEKftrd98WM1bmc5MXk9FEtG83/C+ln5QSxg9ezD IN7YM22ypdHHnMo0JsodqmxS+pfdMOFCRqUjv83nGTLFMyPYy3O4k+IzSVJUk+py3rr60+DCIrBl gaMvy14thS4HLU7C1SZxHoLzdZjrwFCT4CiDgztUDpVW4LQnlNZgB1Hqll+enacC0Ln7ukDQ3lRP 83C0OQA28OOy3M5wQSidk+19pcZrPA7kqlFxEJEwSM21V+EzyB88KbGykgqtnolwt3BGmLk4RWn2 vwyFq7cPLJFUNWu+0woRYoCJG8X0kj0WkMrMwOYsgAU8aR45091HS9g9IvfIySgimzK1ATbsAKPy KMlrOFo+I2Vnxkuv3e7xSVNeRRleQInz8K8p2r5xSwk49TfymWcNg8H2iYwSOMpiupckvQAQnfbd iFsFHU7wdkr69T85w5L+eaVsG5CXEcVx9LwSeHd9tCIJbsMkRIUiNeApF9nKoWFuIud6iJAoytSg WZJjtX0T+LCTZDviMZcV2uuanC4fOv9V3FUtEQZu =1hco -----END PGP SIGNATURE----- --5aff20a3_66334873_6e7-- From nobody Fri May 18 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 70EF612DB6C for ; Fri, 18 May 2018 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 sYuBFzhO3FpL for ; Fri, 18 May 2018 12:56:32 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EA212D882 for ; Fri, 18 May 2018 12:56:31 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id o80-v6so3107295ybc.7 for ; Fri, 18 May 2018 12:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZNyVRJl3ogjC6aExbI+WswnTJQ27Fe09oNsfKLmCBl4=; b=gcvDA42FGS/lV2T2sY92AsnwHXOKoq9qiTSgSeFzVxgz2sMH101zZEQjzc0uLZJeUw 75LtVjSAZulYjAuaYoe7Uinnb+s/bOKdkVpT3OBNXubpG1Pvf1H8+f4B5wAe4w5uA9gM uil1hstbaFw8E3e6CcViPNhyFSc/zQ1d+h+TuDjsla+QRvUVbSjRHb5Uldw2gXYd6yvt g+UUwgG3pze/AWp1CrmC4PhX1Avhi/67KaYL8AYK42l3/v6OVQwLuaRpJVXmO2/muPt7 Zb9EMqMeoUOpkZ2Mf15G8mfhg1EUtlWUxqV8vYJC2bwe9XIgfwS/x2dXFXNnujN3J67Q 4WJA== 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=ZNyVRJl3ogjC6aExbI+WswnTJQ27Fe09oNsfKLmCBl4=; b=LH7S+p8GMuSGleJx4yxYAfCwaZCr0qtu3bbZmAzr4i3O6RXZoEHexqC/dik4xxPHbR Aza/3msVlyWAhkVNaM6C1qrupeRAmno86LI0BoZfT9R7C/a7luAo08So0/iwQh34Mx9j xdpSwM3xwFB3z+tqsIvhms7zLJLKOJ0bJyFgRT+59hYwueKstAJPdnMqjo5Vw4ycudMt eVNbzPYHkXEkwI8JwEBx8/surwIe8Bk9dYIbsRm9D0+JqGX1rMjEhwAmvjWCveqQbP9K caIlrW+DrYkhXbo9oe5DqL7OpUMmVOBqouHyMUXzfuRaDbgIAmXVAdg1P3umlY34DG0C JUjQ== X-Gm-Message-State: ALKqPwdFdXei+95bbBiNeo0fIITU+i+Mbrg70xoFST6qKy4ysxud/nkl j6s0LIBVVs8QNB7FJ/blBi7MXw== X-Google-Smtp-Source: AB8JxZqBhQwI7lKvr9t8nIKRF9rtDd6cobZnQHWQMUrfdj8ZahhHjGceHb6TTcgXYZ3Rc74ssFujFQ== X-Received: by 2002:a25:7807:: with SMTP id t7-v6mr638478ybc.435.1526673390821; Fri, 18 May 2018 12:56:30 -0700 (PDT) Received: from [10.242.17.219] (mobile-166-172-59-55.mycingular.net. [166.172.59.55]) by smtp.gmail.com with ESMTPSA id o184-v6sm3495334ywb.81.2018.05.18.12.56.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 12:56:29 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6D0464A1-3D80-4D66-B665-DE500713E997 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Fri, 18 May 2018 15:56:29 -0400 Cc: John Bradley , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> To: Neil Madden Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 19:56:36 -0000 --Apple-Mail-6D0464A1-3D80-4D66-B665-DE500713E997 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 100% and that=E2=80=99s a good point. Stolen tokens will no longer work unde= r token binding but XSS that does =E2=80=9Cstored request forgery=E2=80=9D i= s still the bane of all web based apps. No web app with XSS vulnerabilities is safe from =E2=80=9Cstored forged requ= ests=E2=80=9D, which means you really need to be bulletproof from XSS if you= want secure web software. Token binding does not stop this at all. So escape! Sanitize HTML input! Use safe JS sinks! Handle client side JSON c= orrectly! CSP that app. These are critical defenses if you want security on t= he web. Token binding helps if a token is stolen. It should no longer be effective o= r active when used in a different client. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 1:38 PM, Neil Madden wrote= : >=20 > I might be missing something here, but aren=E2=80=99t bound tokens exactly= as vulnerable to the XSS attacks you describe as http-only cookies are?=20 >=20 > =E2=80=94 Neil >=20 > On Friday, May 18, 2018 at 5:43 pm, Jim Manico wrote: > A few notes: >=20 > > The session cookie should also be flagged as http only to protect it. =20= >=20 > This provides no real protection. If I get XSS into your site I don=E2=80=99= t need to steal the cookie. I can just force requests that will automaticall= y send it (client side or stored request forgery). So while it=E2=80=99s a s= tandard suggestion, it helps little.=20 >=20 > > Having a refresh token in local storrage may introduce new security issu= es unless it is token bound. =20 >=20 > Token binding is not live yet, right? If you need to store a token in a br= owser please note there is no safe place to store it. LocalStorage can be ha= rvested by XSS and even the strongest cookies can be replayed as discussed a= bove. I can=E2=80=99t wait for browser based token binding! But it will like= ly take years for this to be avail in the majority of browsers. >=20 > > Understanding the security issues of the code flow in the browser is imp= ortant, before any new recommendation. =20 >=20 > Well said. It looks to be the only secure workflow for browser based apps.= Love it how passwords are kept away from RP=E2=80=99s and high powered toke= ns are not stored in the browser. >=20 > Aloha, > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 >=20 >> On May 18, 2018, at 12:27 PM, John Bradley wrote: >>=20 >> Yes that was the original intent to have the AT be short lived and refres= h the AT via the authorization endpoint based on the session cookie. =20 >>=20 >> The session cookie should also be flagged as http only to protect it. =20= >>=20 >> Having a refresh token in local storrage may introduce new security issue= s unless it is token bound. =20 >>=20 >> Understanding the security issues of the code flow in the browser is impo= rtant, before any new recommendation. =20 >>=20 >> John B.=20 >>=20 >> From: Brock Allen >> Sent: Friday, May 18, 2:46 PM >> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >> To: David Waite, Hannes Tschofenig >> Cc: oauth@ietf.org >>=20 >>=20 >> One thing I maybe should have listed in the pros/cons in my original emai= l is session management and token lifetime considerations, keeping in mind t= he original intent of the implicit flow.=20 >>=20 >> What I mean is that with implicit grant type, the client's ability to get= new access tokens is limited to the user's session at the AS/OP. Obviously o= ther flows make more sense to obtain longer lived access (via refresh tokens= ), but I don't know about a browser-based JS app. In a sense there's a bit o= f protection for the end user built into that design by virtue of being tied= to the user's cookie at the AS/OP.=20 >>=20 >> Just throwing that out as an additional discussion point. >>=20 >> -Brock=20 >>=20 >>> On 5/18/2018 6:04:47 AM, David Waite wrot= e: >>> I have written some guidance already (in non-RFC format) on preferring c= ode for single page apps, and other security practices (CORS, CSP). =46rom t= he AS point of view, it aligns well with the native apps BCP. There are bene= fits of thinking about native and SPA apps just as =E2=80=98public clients=E2= =80=99 from a policy/properties point of view. It also greatly simplifies OA= uth/OIDC support on both the AS administrator and client developer side when= converting web properties into native apps using technologies like Electron= or Cordova.=20 >>>=20 >>> For the later requirements in the list around token policy, I am not sur= e these are requirements for single page apps per se. I don=E2=80=99t believ= e the need for a policy using short-lived refresh tokens, revoking at signou= t, or use of the revocation endpoint are different from browser and native a= pplications. Rather they seem to be a function of usage patterns that an AS m= ay need to support, and we happen to sometimes associate those usage pattern= s with typical usage of native apps vs of browser apps. For example, browser= login on a borrowed device can easily leak over to being app authorization -= the authentication/authorization are web-based processes to achieve SSO. >>>=20 >>> I have been working on some guidance here around token lifetimes and pol= icies, but I don=E2=80=99t know whether that brings in too much AS/OP busine= ss logic (and, likely implied product/deployment features) to be industry pr= actices. >>>=20 >>> -DW >>>=20 >>>> On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: >>>>=20 >>>> Hi Brock, >>>> =20 >>>> there have been several attempts to start writing some guidance but so f= ar we haven=E2=80=99t gotten too far. >>>> IMHO it would be great to have a document. >>>> =20 >>>> Ciao >>>> Hannes >>>> =20 >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen >>>> Sent: 17 May 2018 14:57 >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >>>> =20 >>>> Much like updated guidance was provided with the "OAuth2 for native app= s" RFC, should there be one for "browser-based client-side JS apps"? I ask b= ecause google is actively discouraging the use of implicit flow: >>>> =20 >>>> https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >>>> =20 >>>> >=46rom what I can tell, the complaints with implicit are: >>>> * access token in URL >>>> * access token in browser history >>>> * iframe complexity when using prompt=3Dnone to "refresh" access tokens= >>>> =20 >>>> But this requires: >>>> * AS/OP to support PKCE >>>> * AS/OP to support CORS=20 >>>> * user-agent must support CORS >>>> * AS/OP to maintain short-lived refresh tokens=20 >>>> * AS/OP must aggressively revoke refresh tokens at user signout (which i= s not something OAuth2 "knows" about) >>>> * if the above point can't work, then client must proactively use revoc= ation endpoint if/when user triggers logout >>>> =20 >>>> Any use in discussing this? >>>> =20 >>>> -Brock >>>> =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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________=20 > OAuth mailing list=20 > OAuth@ietf.org=20 > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6D0464A1-3D80-4D66-B665-DE500713E997 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 100% and that=E2=80=99s a good point. Stole= n tokens will no longer work under token binding but XSS that does =E2=80=9C= stored request forgery=E2=80=9D is still the bane of all web based apps.
No web app with XSS vulnerabilities is safe from =E2=80=9Cst= ored forged requests=E2=80=9D, which means you really need to be bulletproof= from XSS if you want secure web software. Token binding does not stop this a= t all.

So escape! Sanitize HTML input! Use safe JS sinks! Handle clie= nt side JSON correctly! CSP that app. These are critical defenses if you wan= t security on the web.

Token binding helps if a tok= en is stolen. It should no longer be effective or active when used in a diff= erent client.
--
Jim Manico=
@Manicode
Secure Coding Education
+1 (808) 65= 2-3805

On May 18, 2018, at 1:38 PM, Neil Madden <neil.madden@forgerock.com> w= rote:

I might be missing something here, but aren=E2= =80=99t bound tokens exactly as vulnerable to the XSS attacks you describe a= s http-only cookies are? 

=E2=80=94 Neil
<= div>
On Friday, May 18, 2018 at 5:43 pm, Jim M= anico <jim@manicode.com> wrote= :
A few notes:

> The session cookie should also be f= lagged as http only to protect it.  

Thi= s provides no real protection. If I get XSS into your site I don=E2=80=99t n= eed to steal the cookie. I can just force requests that will automatically s= end it (client side or stored request forgery). So while it=E2=80=99s a stan= dard suggestion, it helps little. 

> <= span style=3D"background-color: rgba(255, 255, 255, 0);">Having a refresh to= ken in local storrage may introduce new security issues unless it is token b= ound.  

Token binding is not live y= et, right? If you need to store a token in a browser please note there is no= safe place to store it. LocalStorage can be harvested by XSS and even the s= trongest cookies can be replayed as discussed above. I can=E2=80=99t wait fo= r browser based token binding! But it will likely take years for this to be a= vail in the majority of browsers.

> Understanding the securit= y issues of the code flow in the browser is important, before any new recomm= endation.  

Well said. It looks to= be the only secure workflow for browser based apps. Love it how passwords a= re kept away from RP=E2=80=99s and high powered tokens are not stored in the= browser.

Aloha,
=
--
Jim Manico
@Manicode
Secure Coding Edu= cation
+1 (808) 652-3805

On May 18, 2018, at 1= 2:27 PM, John Bradley <ve7jtb@ve7jtb= .com> wrote:

Yes that was the original intent t= o have the AT be short lived and refresh the AT via the authorization endpoi= nt based on the session cookie. 

The session cookie should also be flagged as htt= p only to protect it. 

Having a refresh token in local storrage may introduce new= security issues unless it is token bound. 

Understanding the security issues of t= he code flow in the browser is important, before any new recommendation.&nbs= p;

John B.=

From: Bro= ck Allen
Sent: Fri= day, May 18, 2:46 PM
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
=
To: David Waite, Ha= nnes Tschofenig
=
One thing I maybe should h= ave listed in the pros/cons in my original email is session management and t= oken lifetime considerations, keeping in mind the original intent of the imp= licit flow.

What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously ot= her flows make more sense to obtain longer lived access (via refresh tokens)= , but I don't know about a browser-based JS app. In a sense there's a bit of= protection for the end user built into that design by virtue of being tied t= o the user's cookie at the AS/OP.

Just throwing that out as an additional discussion poi= nt.

-Brock <= br>
On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> wrote:
=
I have written some= guidance already (in non-RFC format) on preferring code for single pag= e apps, and other security practices (CORS, CSP). =46rom the AS point of vie= w, it aligns well with the native apps BCP. There are benefits of thinking a= bout native and SPA apps just as =E2=80=98public clients=E2=80=99 from a pol= icy/properties point of view. It also greatly simplifies OAuth/OIDC support o= n both the AS administrator and client developer side when converting web pr= operties into native apps using technologies like Electron or Cordova.
<= br>
For the later re= quirements in the list around token policy, I am not sure these are requirem= ents for single page apps per se. I don=E2=80=99t believe the need for a pol= icy using short-lived refresh tokens, revoking at signout, or use of the rev= ocation endpoint are different from browser and native applications. Rather t= hey seem to be a function of usage patterns that an AS may need to support, a= nd we happen to sometimes associate those usage patterns with typical usage o= f native apps vs of browser apps. For example, browser login on a borrowed d= evice can easily leak over to being app authorization - the authentication/a= uthorization are web-based processes to achieve SSO.

I have been working on some guidan= ce here around token lifetimes and policies, but I don=E2=80=99t know whethe= r that brings in too much AS/OP business logic (and, likely implied product/= deployment features) to be industry practices.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> w= rote:

Hi Bro= ck,
 
<= /div>
there have been sever= al attempts to start writing some guidance but so far we haven=E2=80=99t got= ten too far.
IMH= O it would be great to have a document.
 
Ciao
Hannes
 <= br>
From:&nbs= p;OAuth [mailto:oauth-bounces@ietf= .org] On Behalf Of Brock Allen
Sent: 17 May 2018 14:57
<= /div>
Subject: [OAUTH-WG] is updated g= uidance needed for JS/SPA apps?
 
Much like updated guidance was provided with the "OAuth2 for native a= pps" RFC, should there be one for "browser-based client-side JS apps"? I ask= because google is actively discouraging the use of implicit flow:
 
 
>=46rom what I can tell, the complaints with implici= t are:
* access t= oken in URL
* ac= cess token in browser history
* iframe complexity when using prompt=3Dnone to "refresh" acce= ss tokens
 =
But this requir= es:
* AS/OP to s= upport PKCE
*&nb= sp;AS/OP to support CORS 
* user-agent must support CORS
* AS/OP to maintain short-lived refresh t= okens 
* AS= /OP must aggressively revoke refresh tokens at user signout (which is not so= mething OAuth2 "knows" about)
* if the above point can't work, then client must proactively u= se revocation endpoint if/when user triggers logout
 
Any use in discussing this?
 
-Brock
 
IMPORTANT NOTICE: The contents of this email and any attachments ar= e confidential and may also be privileged. If you are not the intended recip= ient, 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 mailin= g list


=
_______= ________________________________________
OAuth mailing list<= /span>
OAuth@ietf.org<= br>https://www= .ietf.org/mailman/listinfo/oauth
____= ___________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>
= --Apple-Mail-6D0464A1-3D80-4D66-B665-DE500713E997-- From nobody Fri May 18 13:12:06 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 9276012E03C for ; Fri, 18 May 2018 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 Hk98TBlzKIWg for ; Fri, 18 May 2018 13:11:59 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC37012DB72 for ; Fri, 18 May 2018 13:11:58 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id q7-v6so2777310ywd.9 for ; Fri, 18 May 2018 13:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aJPtxq2XvcuLh1NyhR0D7Dyh3UcCiH96SrH9z6uqJcI=; b=bPbndytPiz69S+3M3rJnpzwO8MxEqCf7jrnUHKktG1cL7xWMH2+CZ7r4/w4hhVrVJl toB6HzvvI8fnfIMf+16v6E07lXaEl0U2GzG6mM7AHkJKt50MkM3stYoHSgg5f0vww0o3 0XymQdUAo+dDnclBbiRnRHrAKCTO6abm8pu7esTOTKDMHuy4WXIm2azSKFJxVwfcw+7m muvVE/omf2UnzLmhTkZ0XbJfqEd9gPsqrJlmlEZK+sOz/sqgNBjrmLKSqVM5BvGOF7uW 9H2QZZfNwuuE8S1K4WZu8et2QrJWXtIb3K9wNQOTQHBSi7Joh6kU3Lf1WFYmU8yQyNoo bgKg== 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=aJPtxq2XvcuLh1NyhR0D7Dyh3UcCiH96SrH9z6uqJcI=; b=A6S+d2yX92oKWsJG/4o0sPMYNnr4dxEBMpTa0J2FMgmXjOHV6J56NwdnUkGjTSSJ4e uvNxbQR3p+lVZ6UKMT5Vd2QbR8tYA7iV3PPL3LrtQvdwrGxPK6x5lHKENljI/oJzKND/ xTowJhR9ae+L8P7lcqqxs6uOCSDqgmlZGthj8iBq4Qz3em7fwlSTCLkLMvuOjQVuV+p9 u07Orho5V1uoKQ0pa9f72AK4+pycOJYMN1dqh2XtbjwOGEkkqRCarpMqBMRzVX/V1zaX 2c+YYetW7dVMT1xSqcoECh87HuYcQnm8L5TeC4Z7+o3f8inydUKBixMJJNamj0wff0Kl l4Lw== X-Gm-Message-State: ALKqPwca9igH4D/swhvL2dMllWZkvGjqRxPfLjXF8mpXpZELfbMJvLsx YP0rjvybtjE6TDLqvlxI/e9UlA== X-Google-Smtp-Source: AB8JxZpwW00IWLfCGcjsBGXIlwR49xECunQ4CKI4JGVuExf5NOqawrl5sB/MtFNkbqIuLBPTpMeLHQ== X-Received: by 2002:a0d:e208:: with SMTP id l8-v6mr5678962ywe.193.1526674317742; Fri, 18 May 2018 13:11:57 -0700 (PDT) Received: from [10.242.17.219] (mobile-166-172-59-55.mycingular.net. [166.172.59.55]) by smtp.gmail.com with ESMTPSA id z11-v6sm3405883ywb.3.2018.05.18.13.11.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 13:11:56 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9760D730-2A9C-496A-ACB0-4AD7B67F0924 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (15E302) In-Reply-To: <9f849caf-1f78-48b2-8cc9-9e0ad0299ce2@Canary> Date: Fri, 18 May 2018 16:11:55 -0400 Cc: John Bradley , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> <5aff116b.1c69fb81.e47d3.d1f0@mx.google.com> <9f849caf-1f78-48b2-8cc9-9e0ad0299ce2@Canary> To: Neil Madden Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 20:12:03 -0000 --Apple-Mail-9760D730-2A9C-496A-ACB0-4AD7B67F0924 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What you call pessimism I call stating fact! =F0=9F=98=8E=20 This has nothing to do with SPA apps. Like Neil says any XSS in play and tok= en binding, HTTPOnly and similar do nothing to protect you. This is any web a= pp.=20 And XSS defense in a complex app is rough. Take the time to study it! I=E2=80= =99m happy to present on XSS defense in-depth to the Oath standard body comm= unity if you wish. It=E2=80=99s a lot more difficult to get right than most t= hink. Once you have XSS, dang. Might as well just stick unsigned AT=E2=80=99s in U= RL=E2=80=99s. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 2:51 PM, Neil Madden wrote= : >=20 > Ha! Well it was Jim Manico=E2=80=99s pessimism about http-only cookies tha= t started it! :-) >=20 > I agree with Jim about http-only, and I agree with you that token binding h= as lots of other good advantages. But pretty much all security is lost if XS= S is a possibility. Even storing secrets on the server does not help much as= if I can forge requests from the same origin then I can probably trick the s= erver into performing actions on my behalf too. Preventing/mitigating XSS is= crucial (CSP is a big help), but that is not specific to OAuth.=20 >=20 > =E2=80=94 Neil >=20 > On Friday, May 18, 2018 at 6:46 pm, John Bradley wrote= : > You cant extract a token bound cookie or AT and use it in a different user= agent. >=20 > =20 >=20 > You could still force the user agent to use a token bound cookie itself.=20= >=20 > =20 >=20 > For the AT and refresh they are not cookies so they need to sent by the JS= so may be harder to trigger? >=20 > =20 >=20 > I thought I was the pessimistic one=F0=9F=98=8A >=20 > =20 >=20 > SPA may turn out to be impossible to completely secure. However that wont= stop people from creating them. >=20 > =20 >=20 > We can try to put together the best advice, and limit the damage. >=20 > =20 >=20 > John B. >=20 > =20 >=20 > Sent from Mail for Windows 10 >=20 > =20 >=20 > From: Neil Madden > Sent: Friday, May 18, 2018 7:38 PM > To: John Bradley; Jim Manico > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >=20 > =20 >=20 > I might be missing something here, but aren=E2=80=99t bound tokens exactly= as vulnerable to the XSS attacks you describe as http-only cookies are?=20 >=20 > =20 >=20 > =E2=80=94 Neil >=20 > =20 >=20 > On Friday, May 18, 2018 at 5:43 pm, Jim Manico wrote: >=20 > A few notes: >=20 > > The session cookie should also be flagged as http only to protect it. =20= >=20 > =20 >=20 > This provides no real protection. If I get XSS into your site I don=E2=80=99= t need to steal the cookie. I can just force requests that will automaticall= y send it (client side or stored request forgery). So while it=E2=80=99s a s= tandard suggestion, it helps little.=20 >=20 > =20 >=20 > > Having a refresh token in local storrage may introduce new security issu= es unless it is token bound. =20 >=20 > =20 >=20 > Token binding is not live yet, right? If you need to store a token in a br= owser please note there is no safe place to store it. LocalStorage can be ha= rvested by XSS and even the strongest cookies can be replayed as discussed a= bove. I can=E2=80=99t wait for browser based token binding! But it will like= ly take years for this to be avail in the majority of browsers. >=20 > =20 >=20 > > Understanding the security issues of the code flow in the browser is imp= ortant, before any new recommendation. =20 >=20 > =20 >=20 > Well said. It looks to be the only secure workflow for browser based apps.= Love it how passwords are kept away from RP=E2=80=99s and high powered toke= ns are not stored in the browser. >=20 > =20 >=20 > Aloha, >=20 > -- >=20 > Jim Manico >=20 > @Manicode >=20 > Secure Coding Education >=20 > +1 (808) 652-3805 >=20 >=20 > On May 18, 2018, at 12:27 PM, John Bradley wrote: >=20 > Yes that was the original intent to have the AT be short lived and refresh= the AT via the authorization endpoint based on the session cookie.=20 >=20 > The session cookie should also be flagged as http only to protect it.=20 >=20 > Having a refresh token in local storrage may introduce new security issues= unless it is token bound.=20 >=20 > Understanding the security issues of the code flow in the browser is impor= tant, before any new recommendation.=20 >=20 > John B. >=20 > From: Brock Allen >=20 > Sent: Friday, May 18, 2:46 PM >=20 > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >=20 > To: David Waite, Hannes Tschofenig >=20 > Cc: oauth@ietf.org >=20 >=20 > One thing I maybe should have listed in the pros/cons in my original email= is session management and token lifetime considerations, keeping in mind th= e original intent of the implicit flow. >=20 > What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously ot= her flows make more sense to obtain longer lived access (via refresh tokens)= , but I don't know about a browser-based JS app. In a sense there's a bit of= protection for the end user built into that design by virtue of being tied t= o the user's cookie at the AS/OP. >=20 > Just throwing that out as an additional discussion point. >=20 > -Brock >=20 > On 5/18/2018 6:04:47 AM, David Waite wrote:= >=20 > I have written some guidance already (in non-RFC format) on preferring cod= e for single page apps, and other security practices (CORS, CSP). =46rom the= AS point of view, it aligns well with the native apps BCP. There are benefi= ts of thinking about native and SPA apps just as =E2=80=98public clients=E2=80= =99 from a policy/properties point of view. It also greatly simplifies OAuth= /OIDC support on both the AS administrator and client developer side when co= nverting web properties into native apps using technologies like Electron or= Cordova. >=20 > For the later requirements in the list around token policy, I am not sure t= hese are requirements for single page apps per se. I don=E2=80=99t believe t= he need for a policy using short-lived refresh tokens, revoking at signout, o= r use of the revocation endpoint are different from browser and native appli= cations. Rather they seem to be a function of usage patterns that an AS may n= eed to support, and we happen to sometimes associate those usage patterns wi= th typical usage of native apps vs of browser apps. For example, browser log= in on a borrowed device can easily leak over to being app authorization - th= e authentication/authorization are web-based processes to achieve SSO. >=20 > I have been working on some guidance here around token lifetimes and polic= ies, but I don=E2=80=99t know whether that brings in too much AS/OP business= logic (and, likely implied product/deployment features) to be industry prac= tices. >=20 > -DW >=20 > On May 17, 2018, at 10:23 AM, Hannes Tschofenig wrote: >=20 > Hi Brock, >=20 > =20 >=20 > there have been several attempts to start writing some guidance but so far= we haven=E2=80=99t gotten too far. >=20 > IMHO it would be great to have a document. >=20 > =20 >=20 > Ciao >=20 > Hannes >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen >=20 > Sent: 17 May 2018 14:57 >=20 > To: oauth@ietf.org >=20 > Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >=20 > =20 >=20 > Much like updated guidance was provided with the "OAuth2 for native apps" R= FC, should there be one for "browser-based client-side JS apps"? I ask becau= se google is actively discouraging the use of implicit flow: >=20 > =20 >=20 > https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >=20 > =20 >=20 > >=46rom what I can tell, the complaints with implicit are: >=20 > * access token in URL >=20 > * access token in browser history >=20 > * iframe complexity when using prompt=3Dnone to "refresh" access tokens >=20 > =20 >=20 > But this requires: >=20 > * AS/OP to support PKCE >=20 > * AS/OP to support CORS=20 >=20 > * user-agent must support CORS >=20 > * AS/OP to maintain short-lived refresh tokens=20 >=20 > * AS/OP must aggressively revoke refresh tokens at user signout (which is n= ot something OAuth2 "knows" about) >=20 > * if the above point can't work, then client must proactively use revocati= on endpoint if/when user triggers logout >=20 > =20 >=20 > Any use in discussing this? >=20 > =20 >=20 > -Brock >=20 > =20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential 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 o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. _______________________________________________ >=20 > OAuth mailing list >=20 > OAuth@ietf.org >=20 > 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=20 > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-9760D730-2A9C-496A-ACB0-4AD7B67F0924 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable What you call pessimism I call stating fact= ! =F0=9F=98=8E 

This has nothing to do with SPA apps= . Like Neil says any XSS in play and token binding, HTTPOnly and similar do n= othing to protect you. This is any web app. 

A= nd XSS defense in a complex app is rough. Take the time to study it! I=E2=80= =99m happy to present on XSS defense in-depth to the Oath standard body comm= unity if you wish. It=E2=80=99s a lot more difficult to get right than most t= hink.

Once you have XSS, dang. Might as well just s= tick unsigned AT=E2=80=99s in URL=E2=80=99s.

Aloha,
--
Jim Manico
@Manicode
= Secure Coding Education
+1 (808) 652-3805
Ha= ! Well it was Jim Manico=E2=80=99s pessimism about http-only cookies that st= arted it! :-)

I agree with Jim about http-only, and= I agree with you that token binding has lots of other good advantages. But p= retty much all security is lost if XSS is a possibility. Even storing secret= s on the server does not help much as if I can forge requests from the same o= rigin then I can probably trick the server into performing actions on my beh= alf too. Preventing/mitigating XSS is crucial (CSP is a big help), but that i= s not specific to OAuth. 

=E2=80=94 Neil
<= div>
On Friday, May 18, 2018 at 6:46 pm, John B= radley <ve7jtb@ve7jtb.com> wr= ote:

You cant extract a token bound coo= kie or AT and use it in a different user agent.

 

You could still force the user age= nt to use a token bound cookie itself. 

 

For the AT and refresh they are not c= ookies so they need to sent by the JS so may be harder to trigger?

 

I thought I was= the pessimistic one=F0=9F=98=8A

 

SPA may turn out to be impossible to completely secu= re.  However that wont stop people from creating them.

 

We can try to put toge= ther the best advice, and limit the damage.

&= nbsp;

John B.

 

Sent from Mail for Windows 10

 

From: Neil Madden
Sent: Friday, May 18, 2= 018 7:38 PM
To: John Bradley<= /a>; Jim Manico
Cc: oauth@ietf.org
Subject: Re: [OAUTH= -WG] is updated guidance needed for JS/SPA apps?

 

I might be mi= ssing something here, but aren=E2=80=99t bound tokens exactly as vulnerable t= o the XSS attacks you describe as http-only cookies are? 

 

=E2=80=94 Neil<= /span>

 =

On Friday, May 18, 201= 8 at 5:43 pm, Jim Manico <jim@manicod= e.com> wrote:

= A few notes:

> The session cookie should also b= e flagged as http only to protect it.  

=

 

=

This provides no real protection. If I g= et XSS into your site I don=E2=80=99t need to steal the cookie. I can just f= orce requests that will automatically send it (client side or stored request= forgery). So while it=E2=80=99s a standard suggestion, it helps little.&nbs= p;

 

>=  Having a refresh token in local storrage may introduce new security is= sues unless it is token bound.  

<= p class=3D"MsoNormal"> 

<= p class=3D"MsoNormal">Token binding is not live yet, right? If= you need to store a token in a browser please note there is no safe place t= o store it. LocalStorage can be harvested by XSS and even the strongest cook= ies can be replayed as discussed above. I can=E2=80=99t wait for browser bas= ed token binding! But it will likely take years for this to be avail in the m= ajority of browsers.

=  

= > Understanding the security issues of the code flow i= n the browser is important, before any new recommendation.  <= /o:p>

 <= /o:p>

Well said. I= t looks to be the only secure workflow for browser based apps. Love it how p= asswords are kept away from RP=E2=80=99s and high powered tokens are not sto= red in the browser.

<= span style=3D"font-size:10.0pt;font-family:"Helvetica",sans-serif;= color:black"> 

<= span style=3D"font-size:10.0pt;font-family:"Helvetica",sans-serif;= color:black">Aloha,

--

Jim Manico

=

@Manicode

Secure Coding Education

+1 (808) 652-3805


On May 18, 2018, at 12:27 PM, John Bradley &= lt;ve7jtb@ve7jtb.com> wrote:

Yes that was= the original intent to have the AT be short lived and refresh the AT via th= e authorization endpoint based on the session cookie. 

The session c= ookie should also be flagged as http only to protect it. 

Having a r= efresh token in local storrage may introduce new security issues unless it i= s token bound. 

Understanding the security issues of the code flow i= n the browser is important, before any new recommendation.  =

= John B.=

From: Brock Allen

Sent: Friday, May 18, 2:46 PM

Subject: Re: [OAUTH-WG] is updated= guidance needed for JS/SPA apps?

To: David Waite, Hannes Tschofenig

One thing I maybe should have listed in t= he pros/cons in my original email is session management and token lifetime c= onsiderations, keeping in mind the original intent of the implicit flow.

What I mean is that with implicit grant type, the client's ability to get n= ew access tokens is limited to the user's session at the AS/OP. Obviously ot= her flows make more sense to obtain longer lived access (via refresh tokens)= , but I don't know about a browser-based JS app. In a sense there's a bit of= protection for the end user built into that design by virtue of being tied t= o the user's cookie at the AS/OP.

Just throwing that out as an additional d= iscussion point.

-Brock

On 5/18/2018 6:04= :47 AM, David Waite <davi= d@alkaline-solutions.com> wrote:

I have written some guidance alre= ady (in non-RFC format) on preferring code for single page apps, and ot= her security practices (CORS, CSP). =46rom the AS point of view, it aligns w= ell with the native apps BCP. There are benefits of thinking about native an= d SPA apps just as =E2=80=98public clients=E2=80=99 from a policy/properties= point of view. It also greatly simplifies OAuth/OIDC support on both the AS= administrator and client developer side when converting web properties into= native apps using technologies like Electron or Cordova. =

For the later r= equirements in the list around token policy, I am not sure these are require= ments for single page apps per se. I don=E2=80=99t believe the need for a po= licy using short-lived refresh tokens, revoking at signout, or use of the re= vocation endpoint are different from browser and native applications. Rather= they seem to be a function of usage patterns that an AS may need to support= , and we happen to sometimes associate those usage patterns with typical usa= ge of native apps vs of browser apps. For example, browser login on a borrow= ed device can easily leak over to being app authorization - the authenticati= on/authorization are web-based processes to achieve SSO.

I have been work= ing on some guidance here around token lifetimes and policies, but I don=E2=80= =99t know whether that brings in too much AS/OP business logic (and, likely i= mplied product/deployment features) to be industry practices.

-DW

<= div>

On May 17, 2018, at 10:23= AM, Hannes Tschofenig <Han= nes.Tschofenig@arm.com> wrote:

Hi Brock,

<= span style=3D"font-family:"Arial",sans-serif;color:black"> 

there have been several attem= pts to start writing some guidance but so far we haven=E2=80=99t gotten too f= ar.

IMHO it would be great t= o have a document.

 

Ciao

Hannes

 

From:=  O= Auth [mailto:oauth-bounces@ietf.or= g] On Behalf Of Brock Allen

=

Sent: 17 May 2018 14:57

Sub= ject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

 

=

Much like updated guidance was provided with the "OAuth= 2 for native apps" RFC, should there be one for "browser-based client-side J= S apps"? I ask because google is actively discouraging the use of implicit f= low:

 

 

>=46rom wha= t I can tell, the complaints with implicit are:

<= div>

* access token in URL

* access token in browser history

<= div>

* iframe complexity when using prompt=3Dnone to "refresh= " access tokens

 <= /o:p>

But this requires:

* AS/OP to support PKCE<= /p>

* AS/OP to support CORS 

* user-agent must support CORS

* AS/OP to maintain short-lived= refresh tokens 

* AS/O= P must aggressively revoke refresh tokens at user signout (which is not some= thing OAuth2 "knows" about)

= * if the above point can't work, then client must proactively use revocation= endpoint if/when user triggers logout

 

Any use in= discussing this?

 

-Brock

 

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, p= lease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. _______________________________________________

OAuth mailing list



______________________________= _________________
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

 

= = --Apple-Mail-9760D730-2A9C-496A-ACB0-4AD7B67F0924-- From nobody Fri May 18 13:43: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 F182712E03C for ; Fri, 18 May 2018 13:43:22 -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=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 2cWl-JCbtv7M for ; Fri, 18 May 2018 13:43:21 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B0E12DFDB for ; Fri, 18 May 2018 13:43:20 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id f5-v6so12004155qth.2 for ; Fri, 18 May 2018 13:43:20 -0700 (PDT) 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=gyoDBEFbGpBLD5qNcWh4San+UL5glOsYzhfUCmx4OlE=; b=Mw2WNP6jt6oAKEJb/2MKpmg5ucmIhTjcryPGgXlH25xXSINyvT9wpz7cV+dUyqugK/ 9ocpi1Tzxcio2uCLPKdM5gIa8CGF46IDqq70csvJ16Xpmqc01UQmIrLeynkhvTi49fUR XT3rVf42GTM6oO1v87PoeLsF4lOWK8Fq5mO/tFhCanrxEWj+Twv0YrYVR7KpREIKsrxB FQ03OrGp151E1oWuBuGgTKcsegoF5Lu5jXyMrNW43AlvKlI3H4FPImnblMfSAyXI70lw 8Zl/Y82UPcIEDw0n5jlWxVuyl2tyTyXYzoL8pz4b2v/svaoINqCrj5vi2ox+plSXx6KW fkRg== 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=gyoDBEFbGpBLD5qNcWh4San+UL5glOsYzhfUCmx4OlE=; b=UdpfrGXtLzb2qEBTTx7MfUx7LMGx6JKAsnamc7ZVRlFhYIutzkMbc0vcYgrxoZdDoq qi8UJDHZfRLCZtTf6Qq/If4IQq83DmKzMe9o9L2/WRf6NoSOqJYkMxj4qBDiZ0cEvAl+ 075k0GHNih56/Hq35m0MRt+LEX78OC68i1YkAFy3Je3fuYXBIEDhtcF2zlMOeqvZvqUj V9uyuW55cR9lKxSyFrNdc5tpfNZ3Lk7z0tV9kXpE0CNDG10rH+3B+dNBm8bA/m77ARMh GfBRUbzKJcvCvfBKjtW6bocKV0FcuHwuBh4+zdXjHY768AqP6xWa8pBgkuOZIIpBYwcd gHWg== X-Gm-Message-State: ALKqPwcdDX9BhAvCdEAn/OZApxU6/vtxnLqj3AD/Sd2IBtYbfkqSFbMV 6W0tg/s2uMGLGROsk7NuDP8vD0xx X-Google-Smtp-Source: AB8JxZqpW4axcRGTC3ZDhmQWrquElMB+WUADyITQlS820MxQk1w0cTY20ZChoWXCvjPC4b2uCfo8Zw== X-Received: by 2002:ac8:303d:: with SMTP id f58-v6mr10549507qte.140.1526676199850; Fri, 18 May 2018 13:43:19 -0700 (PDT) Received: from [10.0.1.2] ([24.38.185.147]) by smtp.gmail.com with ESMTPSA id f67-v6sm5854121qkb.77.2018.05.18.13.43.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 13:43:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_8441201.228505881278" MIME-Version: 1.0 Date: Fri, 18 May 2018 16:43:17 -0400 Message-ID: From: "Brock Allen" To: "David Waite" Cc: "John Bradley" , "Hannes Tschofenig" , "" In-Reply-To: References: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> <0075D910-35DA-4B8B-A739-D57CF7A8765E@alkaline-solutions.com> <5076c4e6-ae3f-4632-b133-146a04db7ec9@getmailbird.com> User-Agent: Mailbird/2.5.8.0 X-Mailbird-ID: bbf44eca-7d78-4080-a803-367165fb7d1c@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 20:43:23 -0000 ------=_NextPart_8441201.228505881278 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable We're basically on the same page, I think.=C2=A0 I Was just coming from the perspective that once you've solved the iframe p= roblem (say via a library), then it's six and one, or half a dozen and anot= her, so to speak. Of course if the spec were redone today, it would look di= fferent and able to take into consideration what we have available today. But you mention a 10-minute only access token. Without a refresh token, the= n you do have to resort back to the iframe, and then we're back at square o= ne. But again, I'm still agreeing with you :) As for prompt=3Dnone and the OP/AS wanting to set static policy to prevent = iframes (presumably you mean with XFO/CSP), I don't see that as a problem. = In my experience, those response headers don't apply when the response is j= ust a 302 back to the redirect uri. They only are take effect when the resp= onse is rendering HTML. So you can set those globally in your OP/AS and it = can still handle prompt=3Dnone properly. Unless I'm misunderstanding your l= ast point. -Brock On 5/18/2018 2:21:06 PM, David Waite wrote: On May 18, 2018, at 11:55 AM, Brock Allen wrote: >=C2=A0I don=E2=80=99t believe code flow today with an equivalent token pol= icy as you have with implicit causes any new security issues, and it does c= orrect _some_ problems. The problem is that you immediately want to change = token policy to get around hidden iframes and special parameters. Hidden frames and special params -- are those really the main concerns with= implicit? They aren=E2=80=99t the only issues, no. The point was that you can use cod= e flow instead of implicit, keep a 10 minute access token lifetime and no r= efresh token, and it doesn=E2=80=99t add new security concerns. The securit= y concerns are around changing token policy once you are doing code flow, d= ue to the execution environment of the browser. The main initial motivation around implicit was client simplicity (plus it = was rather early for CORS). Once you are implementing a second iframe-based= approach to discretely retrieve updated access tokens, the simplicity argu= ment doesn=E2=80=99t hold. It is also an additional security consideration for the AS - ideally I want= to reject my user authentication/consent content from being loaded in fram= es as a static policy, but now I need to allow it when prompt=3Dnone is set= . This isn=E2=80=99t a policy recommended anyplace, just something the deve= lopers may have to argue with against the security people so that their app= can have a halfway decent experience. -DW I thought the access token being sent in the URL is a bigger concern, and t= hat's why code+PKCE is a better approach. -Brock ------=_NextPart_8441201.228505881278 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A We're bas= ically on the same page, I think. 

I Was just comin= g from the perspective that once you've solved the iframe problem (say via = a library), then it's six and one, or half a dozen and another, so to speak= . Of course if the spec were redone today, it would look different and able= to take into consideration what we have available today.

But you mention a 10-minute only access token. Without a refresh to= ken, then you do have to resort back to the iframe, and then we're back at = square one. But again, I'm still agreeing with you :)

<= div>As for prompt=3Dnone and the OP/AS wanting to set static policy to prev= ent iframes (presuma= bly you mean with XFO/CSP), I don't see that as a problem. In my experience, those response he= aders don't apply when the response is just a 302 back to the redirect uri.= They only are take effect when the response is rendering HTML. So you can = set those globally in your OP/AS and it can still handle prompt=3Dnone prop= erly. Unless I'm misunderstanding your last point.
-= Brock

=0A = =0A
On 5/18/2018 2:21:06 PM, David Waite <david@alkaline-solutions.com> = wrote:



On May 18, 2018, at 11:55= AM, Brock Allen <bro= ckallen@gmail.com> wrote:

=0A = =0A =0A = =0A = =0A =0A = > I do= n=E2=80=99t believe code flow today with an equivalent token policy as you = have with implicit causes any new security issues, and it does correct _som= e_ problems. The problem is that you immediately want to change token polic= y to get around hidden iframes and special parameters.

Hidden frames and spe= cial params -- are those really the main concerns with implicit?

They aren=E2=80=99t the only = issues, no. The point was that you can use code flow instead of implicit, k= eep a 10 minute access token lifetime and no refresh token, and it doesn=E2= =80=99t add new security concerns. The security concerns are around changin= g token policy once you are doing code flow, due to the execution environme= nt of the browser.

The main initial mot= ivation around implicit was client simplicity (plus it was rather early for= CORS). Once you are implementing a second iframe-based approach to discret= ely retrieve updated access tokens, the simplicity argument doesn=E2=80=99t= hold.

It is also an additional securit= y consideration for the AS - ideally I want to reject my user authenticatio= n/consent content from being loaded in frames as a static policy, but now I= need to allow it when prompt=3Dnone is set. This isn=E2=80=99t a policy re= commended anyplace, just something the developers may have to argue with ag= ainst the security people so that their app can have a halfway decent exper= ience.

-DW

I thought= the access token being sent in the URL is a bigger concern, and that's why= code+PKCE is a better approach.


-Brock
=0A =
=0A =0A =

=0A ------=_NextPart_8441201.228505881278-- From nobody Sat May 19 06:10: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 052D712D87D for ; Sat, 19 May 2018 06:10:03 -0700 (PDT) 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, 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=uni-stuttgart.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 NmFTDSFVkCLX for ; Sat, 19 May 2018 06:10:00 -0700 (PDT) Received: from mxex2.tik.uni-stuttgart.de (mxex2.tik.uni-stuttgart.de [IPv6:2001:7c0:2041:24::a:2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CD512D87B for ; Sat, 19 May 2018 06:09:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTP id 40AF27CE3C; Sat, 19 May 2018 15:09:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=dkim; i= @sec.uni-stuttgart.de; t=1526735395; x=1528474196; bh=xXxSxmh4e3 d4/uNNLfFH81BLesisSYfV1RnAWfwb9pE=; b=P09CWx07J6qMMZH1/7aMohfQYz /khwAMMYLAhcsOdUDc8pK+8npzeXACcP55yzyGh/3PfhocKfY81s0V9ZBywTe5G+ qdy0/Ekwv/Pu2+PPl/CSEKKkqP+F6ivLHMVkjSL84zDRPKRy4XM4Awx4CEy1jFBY NELXN31BlSuxZ1/TDJt0EbVrruf7QSUE/jSuI0UBwde4U/QD9nrOjoZvG+Lhb6xX qu3fx0AdyApS4U0UuhPKtEqsQPjoUvRy8moHAsn3tp5JSDBxEEA73Dzf20p5yJcp oH1lqQ/p9IdiFNczQxQuj8Ro1WT63fd3QuNB1ZU6xODq1K6PVJLtbpbfCt3Q== X-Virus-Scanned: USTUTT mailrelay AV services at mxex2.tik.uni-stuttgart.de Received: from mxex2.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex2.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id jS4EOghxzcFL; Sat, 19 May 2018 15:09:55 +0200 (CEST) Received: from [IPv6:2001:16b8:2262:9000:d4d:9d5d:9dd2:fbae] (200116B8226290000D4d9d5D9DD2fbAe.dip.versatel-1u1.de [IPv6:2001:16b8:2262:9000:d4d:9d5d:9dd2:fbae]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTPSA; Sat, 19 May 2018 15:09:54 +0200 (CEST) To: John Bradley , "oauth@ietf.org" References: From: Daniel Fett Openpgp: preference=signencrypt Message-ID: Date: Sat, 19 May 2018 15:09:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3334613BB36D2E069AE73BF6" Content-Language: de-LU Archived-At: Subject: Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 13:10:03 -0000 This is a multi-part message in MIME format. --------------3334613BB36D2E069AE73BF6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Am 18.05.2018 um 18:20 schrieb John Bradley: > I am not against having "as" as REQUIRED. > > While we are at it should we recommend that rfp be single use? If the state JWT is *not* signed and the client has no other means to check the integrity of the JWT (e.g., by storing a copy in the browser's session), rfp MUST be single use, where single use means that once a new authorization request has been sent, all old "rfp" values (for that browser session) become invalid. (Rationale: The state reuse attack across AS would still be possible, since an attacker could just replace the "as" value in an unsigned JWT.) If the state JWT is signed and "as" is contained in the JWT, rfp does not need to be single use in this sense. To prevent defense-in-depth against the usage of leaked of state values, in both cases, a state value that has once been accepted at the redirection endpoint SHOULD be invalidated for future uses. In the the case of an unsigned JWT, this means that a specific rfp value SHOULD only be accepted once. If the JWT is signed, it would be sufficient to memorize the hashes of used JWTs or their jti values, and decline JWTs with the same hash/jti. (SHOULD since this is impossible for stateless clients.) (Overall, it seems like not signing state JWTs is not a good idea.) > > This draft hangs around as a ID and probably is not read by most > people. > > We may also want to mention it in security topics if we haven't. I will check the status there. > > I need to update this in the next couple of weeks to keep it from > expiring anyway. I took a cursory look at the draft and I see two more issues: (1) > The "as" claim if present MUST correspond to the URI endpoint registered as the "redirect_uri" for that AS. This wording is not sufficient: - The AS must be the expected AS (if there are means to check that, for example the browser session). - The redirection URI on which the authorization response was actually received matches the "as" value. (2) > The client parses it as a JWT. It then verifies the signature of the JWT (if signed) The client should check the signature if it expects the JWT to be signed, not only if the received JWT is signed. I may be nitpicking here, but developers should not be lead to believe that "if signed(received_jwt): check_sig(received_jwt)" would be a good implementation choice. - Daniel -- SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universittsstrae 38 - 70569 Stuttgart - Room 2.434 --------------3334613BB36D2E069AE73BF6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Am 18.05.2018 um 18:20 schrieb John Bradley:
I am not against having "as" as REQUIRED.

While we are at it should we recommend that rfp be single use?
If the state JWT is *not* signed and the client has no other means to check the integrity of the JWT (e.g., by storing a copy in the browser's session), rfp MUST be single use, where single use means that once a new authorization request has been sent, all old "rfp" values (for that browser session) become invalid.
(Rationale: The state reuse attack across AS would still be possible, since an attacker could just replace the "as" value in an unsigned JWT.)

If the state JWT is signed and "as" is contained in the JWT, rfp does not need to be single use in this sense.

To prevent defense-in-depth against the usage of leaked of state values, in both cases, a state value that has once been accepted at the redirection endpoint SHOULD be invalidated for future uses. In the the case of an unsigned JWT, this means that a specific rfp value SHOULD only be accepted once. If the JWT is signed, it would be sufficient to memorize the hashes of used JWTs or their jti values, and decline JWTs with the same hash/jti. (SHOULD since this is impossible for stateless clients.)

(Overall, it seems like not signing state JWTs is not a good idea.)


This draft hangs around as a ID and probably is not read by most people.

We may also want to mention it in security topics if we haven't.
I will check the status there.

I need to update this in the next couple of weeks to keep it from expiring anyway.
I took a cursory look at the draft and I see two more issues:

(1)

> The "as" claim if present MUST correspond to the URI endpoint registered as the "redirect_uri" for that AS.

This wording is not sufficient:
- The AS must be the expected AS (if there are means to check that, for example the browser session).
- The redirection URI on which the authorization response was actually received matches the "as" value.

(2)

> The client parses it as a JWT. It then verifies the signature of the JWT (if signed)

The client should check the signature if it expects the JWT to be signed, not only if the received JWT is signed. I may be nitpicking here, but developers should not be lead to believe that "if signed(received_jwt): check_sig(received_jwt)" would be a good implementation choice.

- Daniel

-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universittsstrae 38 - 70569 Stuttgart - Room 2.434
--------------3334613BB36D2E069AE73BF6-- From nobody Sat May 19 06:12:29 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 C7E5612D876 for ; Sat, 19 May 2018 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 j8-_zQkNiJqh for ; Sat, 19 May 2018 06:12:24 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 CF95312778E for ; Sat, 19 May 2018 06:12:23 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id x9-v6so8891832wrl.13 for ; Sat, 19 May 2018 06:12:23 -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=jfsKUygfs03AisnWTI1ErclJk7T9LO42xE02eSit6qY=; b=wENxj4Y+70loaoh7b1uIa8QpL/1YfQ2OefKMk2hyQdynBEds4c5SP6PeL6eQttrdwq rjonTsdmtggIL8Tk5JpW7k1Ss5/ZmNIUUBT1vnaBMLTZb1KAesoruJsYzWgqQ/MMNmW7 kj7RJ+ylDPnyh83IbBX1gMhmfLHgqhYxq0zpKys7E/aKo5FtEE+Ba9SK5y2rVeNcPO0F KL0FY28b/VWJWf45NH/6naXdqWSY1aYqJiTerwsPWrrKX0goOfmzu/qcQwV6fnHDZwEG YQfakz+7JQuLN/Vb9JCQwTdVRxrzfrSsKhwZ+IKZNUvOKDgxjaqP7UMl7Sn7fNEd9H3E 2mGA== 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=jfsKUygfs03AisnWTI1ErclJk7T9LO42xE02eSit6qY=; b=k4VPtDWx5LHvK3fPh/TSel8iDT7hIoFyoDTOm7HWaqeVSM0p3yBHb+GnXBqGKBqS4u jrav4SUVhBfa2DDCDjsTquuRh4mJiogKX040d5g7U2HB6N/xi2jOp+0ZvO0ehFJt2HVk LgnXxlR9AqHDilGKsAS1m9eJ7krrmMhYJw5+ADFrlLzb2V21h1iXK6ADbmax/zrCeKgj 0/4ZnnPt15PLE3jC3kP6QwgKWSJ9Po+5tRrU7mTmRbDQQ0FXlkrcoANFiZYZDguopFx6 y7Qx70HgEU/PziUYlNJssAWEQOoS1/rnHzcy6tL8K8DkJAvOykjfnxi8BcDAVmU1y9Y/ 8w9Q== X-Gm-Message-State: ALKqPwf0D+zJDuOSriYvP1+RZujHcTaHnMkrDbAsRMB8UtX0NukAHUKj 8//ySFRRfJM57M+ZMh5bK4VYBRkCoiaV0N1NRs5VhQ== X-Google-Smtp-Source: AB8JxZqVE6rNj2RDmws8ncrEDds/0FH45t8w6RZA3EfaybF/u34SUErb07xqRIk5lNubBx2VzKqj9eRMJ6l8sTxQWq8= X-Received: by 2002:adf:9a8e:: with SMTP id a14-v6mr11465307wrc.50.1526735541834; Sat, 19 May 2018 06:12:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Bradley Date: Sat, 19 May 2018 15:12:10 +0200 Message-ID: To: Daniel Fett Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a32929056c8ed1f9" Archived-At: Subject: Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 13:12:27 -0000 --000000000000a32929056c8ed1f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks On Sat, May 19, 2018, 3:09 PM Daniel Fett wrote: > Am 18.05.2018 um 18:20 schrieb John Bradley: > > I am not against having "as" as REQUIRED. > > While we are at it should we recommend that rfp be single use? > > If the state JWT is *not* signed and the client has no other means to > check the integrity of the JWT (e.g., by storing a copy in the browser's > session), rfp MUST be single use, where single use means that once a new > authorization request has been sent, all old "rfp" values (for that brows= er > session) become invalid. > (Rationale: The state reuse attack across AS would still be possible, > since an attacker could just replace the "as" value in an unsigned JWT.) > > If the state JWT is signed and "as" is contained in the JWT, rfp does not > need to be single use in this sense. > > To prevent defense-in-depth against the usage of leaked of state values, > in both cases, a state value that has once been accepted at the redirecti= on > endpoint SHOULD be invalidated for future uses. In the the case of an > unsigned JWT, this means that a specific rfp value SHOULD only be accepte= d > once. If the JWT is signed, it would be sufficient to memorize the hashes > of used JWTs or their jti values, and decline JWTs with the same hash/jti= . > (SHOULD since this is impossible for stateless clients.) > > (Overall, it seems like not signing state JWTs is not a good idea.) > > > This draft hangs around as a ID and probably is not read by most people. > > We may also want to mention it in security topics if we haven't. > > I will check the status there. > > > I need to update this in the next couple of weeks to keep it from expirin= g > anyway. > > I took a cursory look at the draft and I see two more issues: > > (1) > > > The "as" claim if present MUST correspond to the URI endpoint registere= d > as the "redirect_uri" for that AS. > > This wording is not sufficient: > - The AS must be the expected AS (if there are means to check that, for > example the browser session). > - The redirection URI on which the authorization response was actually > received matches the "as" value. > > (2) > > > The client parses it as a JWT. It then verifies the signature of the > JWT (if signed) > > The client should check the signature if it expects the JWT to be signed, > not only if the received JWT is signed. I may be nitpicking here, but > developers should not be lead to believe that "if signed(received_jwt): > check_sig(received_jwt)" would be a good implementation choice. > > - Daniel > > -- > SEC - Institute of Information Security > University of Stuttgart > Phone +49 711 685 88468 > Universit=C3=A4tsstra=C3=9Fe 38 - 70569 Stuttgart - Room 2.434 > > --000000000000a32929056c8ed1f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0

On Sat, May 19, 2018, 3:09 PM Daniel Fett <daniel.fett@sec.uni-stuttgart.de> wr= ote:
=20 =20 =20
Am 18.05.2018 um 1= 8:20 schrieb John Bradley:
=20
I am not against having "as" as REQUIRED.

While we are at it should we recommend that rfp be single use?=C2= =A0=C2=A0
If the state JWT is *not* signed and the client has no other means to check the integrity of the JWT (e.g., by storing a copy in the browser's session), rfp MUST be single use, where single use means that once a new authorization request has been sent, all old "rfp&= quot; values (for that browser session) become invalid.
(Rationale: The state reuse attack across AS would still be possible, since an attacker could just replace the "as" value= in an unsigned JWT.)

If the state JWT is signed and "as" is contained in the JWT, = rfp does not need to be single use in this sense.

To prevent defense-in-depth against the usage of leaked of state values, in both cases, a state value that has once been accepted at the redirection endpoint SHOULD be invalidated for future uses. In the the case of an unsigned JWT, this means that a specific rfp value SHOULD only be accepted once. If the JWT is signed, it would be sufficient to memorize the hashes of used JWTs or their jti values, and decline JWTs with the same hash/jti. (SHOULD since this is impossible for stateless clients.)

(Overall, it seems like not signing state JWTs is not a good idea.)


This draft hangs around as a ID and probably is not read by most people.=C2=A0=C2=A0

We may also want to mention it in security topics if we haven't.=C2=A0
I will check the status there.

I need to update this in the next couple of weeks to keep it from expiring anyway.=C2=A0
I took a cursory look at the draft and I see two more issues:

(1)

> The "as" claim if present MUST correspond to the URI end= point registered as the "redirect_uri" for that AS.

This wording is not sufficient:
- The AS must be the expected AS (if there are means to check that, for example the browser session).
- The redirection URI on which the authorization response was actually received matches the "as" value.

(2)

> The client parses it as a JWT.=C2=A0 It then verifies the signatur= e of the JWT (if signed)

The client should check the signature if it expects the JWT to be signed, not only if the received JWT is signed. I may be nitpicking here, but developers should not be lead to believe that "if signed(received_jwt): check_sig(received_jwt)" would be a good implementation choice.

- Daniel

--=20
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universit=C3=A4tsstra=C3=9Fe 38 - 70569 Stuttgart - Room 2.434
--000000000000a32929056c8ed1f9-- From nobody Sat May 19 14:42:06 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 AF48A12EB01 for ; Sat, 19 May 2018 14:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 tBfCJ72JFQIF for ; Sat, 19 May 2018 14:42:02 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 C135112E041 for ; Sat, 19 May 2018 14:42:01 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id t1-v6so12996960oth.8 for ; Sat, 19 May 2018 14:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SCwiPZlo+/PcxjAfh4ktsHdoPptphpaT9VcNA6T6UQ0=; b=gz5j9iU9By1e7he1RTH1RJkoyDONejyY5XeK5f2Hzdhe6dPG/5mPvhdoLIGo3d+Mos 7wLtPbgzoYZ8yXAHTH76uMu8/Gs3sKPMu4Fd90Qv+8E4te+SSSvSHRr9nKrzK1atg1uR da6WQGOHjnOLu9lIlOlBCQMOBZd3FZyVBb8bcgxkhXO/mpR2aYrMdRzVrREXwOk3ahBM //zk5KucsuKTfjUlBv5eLqusDb4zVXwS4MZ1T6zseCYKQE3Kg6DRelJi+46rQ9Ai5j3z hG7TE7w0fDDWVZ5Vj3qSmmVlcJrQ4LD2MW/A5oZJMavwWzzJYWzzMfiomeDk9J/1GMHG SX1Q== 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=SCwiPZlo+/PcxjAfh4ktsHdoPptphpaT9VcNA6T6UQ0=; b=BtBsZibuBu/y8TrwO4I/Bg1EoU47omUnHG4KcrPMhkb5p/FxyYpQ42hIx0DfXl4BiH o9Jre28yNJlzDRltyQR4wV0fK3KLCxuiB+4zLR5hN4wIuO391q9+IzvAU4auLW9RV93K 1EXOdF9RPnDXOouGJj4bMDXE7DDIhl9yv0zJXvXgrR38+3eZ6PIUpOZjLdcyFMBocfZv lYvJde1o+kEnywjRE1RfE4bQ4X7rmNGl1YoJqc41petpqKvvCbNIx8wD6YLgO7GFTY9C Bi2XMtjV2OT7aHmbbmr0NEwf1+fbJCtkKq0iW4zZzISYgdB5y1g22WaNPHXMB6dfC5vw 9WCg== X-Gm-Message-State: ALKqPweKRFvPlKCqtPq76hh4WsHbRgrWoQACQ52ywdn3FwW442yC+qFm 7vAEiK50chAECYUibBXivHZoSKgu/UCYhEAufydttXaT X-Google-Smtp-Source: AB8JxZqt8QmXFiUg8iYsVfV2GJ7+0FBjXr9UjeniBRP26LNY1wscziqYI97ODKlXteCHFHJdaxrWQKexFv4ObrJ4g8g= X-Received: by 2002:a9d:7259:: with SMTP id a25-v6mr10260803otk.267.1526766121003; Sat, 19 May 2018 14:42:01 -0700 (PDT) MIME-Version: 1.0 From: Sergey Ponomarev Date: Sun, 20 May 2018 00:41:24 +0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000004c2dbf056c95f08b" Archived-At: Subject: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 21:42:05 -0000 --0000000000004c2dbf056c95f08b Content-Type: text/plain; charset="UTF-8" Hi, I developing an implementation of back channel token revocation endpoint. And I think we should reconsider and probably change the specification to improve error handling. Here we see several situations of error state: 1. token wasn't sent in request. 2. token is invalid by format i.e. not JWT or JWT with invalid signature 3. token is expired or token is even unknown 4. token was already revoked 5. token type is unsupported According to RFC7009 OAuth 2.0 Token Revocation section 2.2 Revocation Response: The authorization server responds with HTTP status code 200 if the token > has been revoked successfully or if the client submitted an invalid token. > Note: invalid tokens do not cause an error response since the client > cannot handle such an error in a reasonable way. Moreover, the purpose of > the revocation request, invalidating the particular token, is already > achieved. As you may see this section covers only case 3 and case 4 but it's very unclear: calling token as "invalid" is very broad definition. I think we should take a look on each case separately: 1. token wasn't sent in request. Most implementations returns 400 status code, error: "invalid_request", error_description": "Missing required parameter: token". Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified. 2. token is invalid by format i.e. not JWT or JWT with invalid signature This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long). Goolge OAuth returns 400 code with "error": "invalid_token" and I think this is correct behavior. The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status. 3. token is expired or even unknown Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB. So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it was revoked while it wasn't. For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired". 4. token was already revoked The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token. 5. token type is unsupported For this case specification introduces a new error code for case 5 in section 2.2.1. Error Response : > unsupported_token_type: The authorization server does not support the > revocation of the presented token type. That is, the client tried to > revoke an access token on a server not supporting this feature. But it would be better to mention that revocation of ID token (which can be is considered as "public" and not used to auth) definitely should cause this error. It would be great if we discuss this cases and improve specification. P.S. Also it may be worse to mention that specification says that content of successful response is empty but status code is 200 instead of 201 "No Content". Regards, Sergey Ponomarev --0000000000004c2dbf056c95f08b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I developing an implemen= tation of back channel token revocation endpoint. And I think we should rec= onsider and probably change the specification to improve error handling.

Here we see several= situations of error state:
1. token = wasn't sent in request.
2. token = is invalid by format i.e. not JWT or JWT with invalid=C2=A0signature
3. token is expir= ed or token is even=C2=A0unknown
4. token was already revoked
5. token type is unsupported=C2=A0

According to=C2=A0 R= FC7009 OAuth 2.0 Token Revocation=C2=A0 section 2.2 Revocation Response= :

The= authorization server responds with HTTP status code 200 if the token has b= een revoked successfully or if the client submitted an invalid token.
No= te: invalid tokens do not cause an error response since the client cannot h= andle such an error in a reasonable way.=C2=A0 Moreover, the purpose of the= revocation request, invalidating the particular token, is already achieved= .

As you may see this section covers only c= ase 3 and case 4 but it's very unclear: calling token as "invalid&= quot; is very broad definition.
I think we should take a look on each cas= e separately:

1. token wasn'= ;t sent in request.=C2=A0
Most implementations retur= ns 400 status code,=C2=A0error:=C2= =A0"invalid_reques= t",=C2=A0error_description": "Miss= ing required parameter: token".
Note that returned error is not &q= uot;invalid_token" but "invalid_request" and I think this sh= ould be correct behavior and should be clearly specified.

2. token is invalid by f= ormat i.e. not JWT or JWT with invalid=C2=A0signature
This error is mostly related to JWT but for reference (opaque) to= kens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 co= de with=C2=A0=C2=A0"error": "invalid_token" and I think= this is correct behavior.
The client can have a bug and sends invalid tokens = so we should return an error response instead of 200 status.
3. token is expired or even unknown
S= pec says that IdP should return 200 in this case but in case of unknown tok= en this may be a symptom of a bug on client side. Even if IdP can clearly d= etermine that token is expired (in case of JWT) this is hard to determine i= n case of reference token that was removed from DB.
So personally I think that= from security perspective it's better to response with 400 status beca= use client can have a bug when it's sends some unknown token and think = that it was revoked while it wasn't.

For example Google OAuth revocation= endpoint implementation do not follow the spec and returns 400 Bad Request= with error message "Token is revoked or expired".

4. token was already= revoked
The same as a= bove: this can be a bug in a client and we should return 400 status. In cas= e of reference token which was removed from DB we can't distinguish tha= t the token was revoked or even existed so this situation is the same as un= known token.

5. token type is unsup= ported=C2=A0
For this case specification introduces a = new error code for case 5 in section 2.2.1. Error Response=C2=A0:
=
unsupported_token_type:= =C2=A0 The authorization server does not support the revocation of the pres= ented token type.=C2=A0 That is, the client tried to revoke an access token= on a server not=C2=A0 =C2=A0supporting this feature.=C2=A0
But it would be better to mention that revocation of ID token (which can = be is considered as "public" and not used to auth) definitely sho= uld cause this error.

It would be great if we disc= uss this cases and improve specification.

P.S. Als= o it may be worse to mention that specification says that content of succes= sful response is empty but status code is 200 instead of 201 "No Conte= nt".

Regards,
Sergey=C2=A0Ponomarev
--0000000000004c2dbf056c95f08b-- From nobody Sun May 20 04:38:24 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 3D0F2127076; Sun, 20 May 2018 04:38:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152681629717.2793.15028642368623108299@ietfa.amsl.com> Date: Sun, 20 May 2018 04:38:17 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2018 11:38:18 -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-06.txt Pages : 31 Date : 2018-05-20 Abstract: This document describes best current security practices 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 20 04:43: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 1E6061270A7 for ; Sun, 20 May 2018 04:43:08 -0700 (PDT) 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 I8l7B-iCNT1E for ; Sun, 20 May 2018 04:43:06 -0700 (PDT) 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 F286C127076 for ; Sun, 20 May 2018 04:43:05 -0700 (PDT) Received: from [84.158.233.58] (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 1fKMjv-0006cQ-GD for oauth@ietf.org; Sun, 20 May 2018 13:43:03 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_CF0E3A76-0547-4222-A1FA-BE4B3C3D2C5D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 20 May 2018 13:42:55 +0200 References: <152681629717.2793.15028642368623108299@ietfa.amsl.com> To: oauth In-Reply-To: <152681629717.2793.15028642368623108299@ietfa.amsl.com> Message-Id: <34B9FBE9-788E-4B1C-B2A4-08FD14EC2BD5@lodderstedt.net> X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2018 11:43:08 -0000 --Apple-Mail=_CF0E3A76-0547-4222-A1FA-BE4B3C3D2C5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, the new revision contains the following changes:=20 =E2=80=A2 reworked section 3.8.1 =E2=80=A2 incorporated Phil Hunt's feedback =E2=80=A2 reworked section on mix-up =E2=80=A2 extended section on code leakage via referrer header = to also cover state leakage =E2=80=A2 added Daniel Fett as author =E2=80=A2 replaced text intended to inform WG discussion by = recommendations to implementors =E2=80=A2 modified example URLs to conform to RFC 2606 Please join me in welcoming Daniel Fett (one of the researches who = discovered the mix up attack) as another co-author of the draft! best regards, Torsten.=20 > Am 20.05.2018 um 13:38 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-06.txt > Pages : 31 > Date : 2018-05-20 >=20 > Abstract: > This document describes best current security practices 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-06 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-06 >=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=_CF0E3A76-0547-4222-A1FA-BE4B3C3D2C5D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNTIwMTE0MjU2WjAjBgkqhkiG9w0BCQQxFgQUJ0FtyAoV53uh xXxPzNsSFGeiJxYwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAEE+jiCbmhjZ14+cF8GfIGj6uMFRynY0sIScbPQ80Ll+bHwNyGh6 5FWii0PqbYdy2xfb+7q29B3h43rZEWmo3zw3Giv+T9b8fNOanpWyYppfwwcF2QjVNsCVdTsh7P1z 2VhMxBE3sr05UnuVGmhlqgjagJJ2Yw66IBeHQPBQwrkTbwCjyopcUz3frnjp2e5jsGlWgX/h+iFU w6ow1l/17jKwDeYNkcgVkPpP+lYq41Q97AMKkhIF8T04m442TbXxucraigyZP81exTSe/PFALuPq 6vfgpa1oUnOzGz83ijXCV3g60cKygJ5YWibTS22X1nKfeTmuiKIzNgw+thUdiH0AAAAAAAA= --Apple-Mail=_CF0E3A76-0547-4222-A1FA-BE4B3C3D2C5D-- From nobody Mon May 21 03:49: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 1AD39126DEE for ; Mon, 21 May 2018 03:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 GcedEwGN8zji for ; Mon, 21 May 2018 03:48:58 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0059.outbound.protection.outlook.com [104.47.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703D6126CE8 for ; Mon, 21 May 2018 03:48:57 -0700 (PDT) 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=d+LiL00vPXW1uQK9lC/79ex13z7p2X7Zlunw4TdJH5c=; b=k+QwMRpNFysVv9zn6qFd+cgopxmybqJ5n4ROI85D5R7oouk4JWI/RmZDmqS3y3EBhXiUB9orFxriUhEg5wkfBhZfrI5+SiwaX/ZrFA4vhQ+9M7mew2tZhas3ORlCk963BQEf9aOQOlQ4ygeY87JdKqndgHzWwjXK2S6Bd0rR8TU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2061.eurprd08.prod.outlook.com (10.173.74.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Mon, 21 May 2018 10:48:53 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4%17]) with mapi id 15.20.0776.015; Mon, 21 May 2018 10:48:53 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: Skipping today's virtual office hours Thread-Index: AdPw8PYZJQcts3SERGi7UvfAuJuxhQ== Date: Mon, 21 May 2018 10:48:52 +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: [156.67.194.94] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2061; 7:4dQ28cJg9uIPer4oqpU+k90/TsnbzNyJNCoiUeRIdanoLRSRyJ42hByVyp859qN/vsxq+qI1Tiv8BsBY2DjB7T83mh6h0vbdU/pNc0qnY0Tteb3gJxI2XQ8CPWUief1a7Hh1Cq/h5dAZlF0hZZlkE+fzMICQdC4/kaHMBg+U/xJK5zcaQSdgC3M0uyUd4M9U6C7u87trh6oeAxDSNm7swg/K3eS9FooedLp7vIKcTV83zfZZFMTdKMcXK8JIVdqA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2061; x-ms-traffictypediagnostic: VI1PR0801MB2061: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2061; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2061; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(39380400002)(396003)(376002)(366004)(53754006)(40434004)(189003)(199004)(3660700001)(6506007)(26005)(486006)(54896002)(6306002)(2501003)(5250100002)(5890100001)(59450400001)(53936002)(6916009)(3846002)(6116002)(790700001)(33656002)(3280700002)(99286004)(55016002)(86362001)(9686003)(2351001)(7696005)(2906002)(102836004)(2900100001)(476003)(81166006)(1730700003)(81156014)(8676002)(316002)(186003)(8936002)(68736007)(25786009)(5630700001)(74316002)(7736002)(5640700003)(72206003)(14454004)(478600001)(5660300001)(97736004)(6436002)(106356001)(105586002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2061; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gUIvFd1zggbT5hE80/iEBz4sliMBGTYgvEy1sn3bHJMtf1cTZChWIQDbgz0WkBFf22prizoTLRzfTLldbzSe0pzXw9wsXRVD36msfFehibkRDdUdc37w4/ynB05Zcs+xUDx/Rlwixdvo8IBFBd3eXfGvTSNmL2xMIpM4ceu6sypDC7M6r+iHPpiIza93gs1h spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112C15778F542C6644B6693FA950VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0ec3911b-0b2e-479b-00f9-08d5bf0871ae X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ec3911b-0b2e-479b-00f9-08d5bf0871ae X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2018 10:48:52.9415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2061 Archived-At: Subject: [OAUTH-WG] Skipping today's virtual office hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 10:49:00 -0000 --_000_VI1PR0801MB2112C15778F542C6644B6693FA950VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Today is a public holiday in Canada and also in Austria. Hence, we have to = skip today's call. The next one is in 2 weeks. For anything urgent, please drop us an email. 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_VI1PR0801MB2112C15778F542C6644B6693FA950VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Today is a public holiday in Canada and also in Aust= ria. Hence, we have to skip today’s call. The next one is in 2 weeks.

 

For anything urgent, please drop us an email. <= /o:p>

 

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_VI1PR0801MB2112C15778F542C6644B6693FA950VI1PR0801MB2112_-- From nobody Mon May 21 14:09: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 3EE231289B0 for ; Mon, 21 May 2018 14:09:03 -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=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 NAcSA4YTIPGx for ; Mon, 21 May 2018 14:09:00 -0700 (PDT) Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.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 3EFE6128896 for ; Mon, 21 May 2018 14:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1526936939; bh=/3+l8hMF6EPCA74CSRNnBjOB4eIO5SX4Z/ubGNYMaBM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ABNkRwGpyNvF6ONgPK/7a8yPNggOlIqMNmeIuynJ+tGp9nC2iSV2CD6fVFVFPkRsQSVRtz/IbtshKlOCMmomhPQUVoWHSA+tz1K5tSaj08nCibrbBzGfhR6kzroidE1sVZ4yJK85a8Xp0RdpEAPHzLDXJkWG/p0myO5QFvUwLrl/09ca+5zc3BBlsjeQ1M2KTz8/KCM68TglPuxc7qbsC12NMPvAUBmBHSaEsMN0rsHtmeny2DBBxwsBtS9O7PxlfKTK08n34gKoI9jyQ2Aop3bbGS84f6AR1kUzYwx/YjN5afyc22QXwTnctr7bNeXtMoM8uZftJOEPV7KJGzVNYA== X-YMail-OSG: F0LoGj8VM1mf6ZszhOdyGJPyF0GTvJr6kLeDumOh4cTpD7Ac7VFnvFQwdd3R3sE .T72swRbHkSf2tsJDy6_XkfgM5xCXqdu7fFol5iAnVSirqpJQ7CP7nouvkQNhhaaQfvfdeZoBk8n DFx3v6VRIL9UNHKO21pnKUTvng8B7KjuTsqatT4.88D9hyzbq.Z3JMxzRO9vBBG1lcJoBtAkkus1 Of.eqI_b_kr9RqNrK5V9hExCGC3q.eQwbFqUsDH7mszIQtAx4bDqxEBXaAulMcv.seM4iGDSh8ZN iF4Wu2wWJCrpH_TrQ8LAW0C1ugcs5kDrKbsLxNHLLBUViJ43APcL1z.SKZsIN4wdLmT.5GrBp3iv F7ln0NET.HXSAoRcUaaAvZ40NsO894IBxKvhHvOgXnvUJ2Z7x5AFbakXUizqRYpV6ceWsQh7k3fq FTxfBdB9.yRdFcqK_KdKcjwtYnDyneIGCBVdH3.8EWBJYNJ2VG2p_JstuFNNDn4sEqByl6XQrCb7 craXjqeMvb9gI__pb7DDaYt0UEyJ21pwPlR7XXaOyLD9e8up9azpJnwuZQIlQvLAV6yqay3kA9I8 FaTuFCBxTr_9JZjz0GSgDgbqKvg1uAqKYjzztUgrFIdYVcDFg4b_VXrMa8yFM3vx0IuUJO6.s4OD OTzt_213J Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 21 May 2018 21:08:59 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 44129339f78e547e3547304483393148; Mon, 21 May 2018 21:08:56 +0000 (UTC) To: Sergey Ponomarev , oauth@ietf.org References: From: George Fletcher Organization: AOL LLC Message-ID: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> Date: Mon, 21 May 2018 17:08:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4C15641529AD713F172C421F" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 21:09:03 -0000 This is a multi-part message in MIME format. --------------4C15641529AD713F172C421F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm not understanding how these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective. Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the token is already not valid. So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more detailed error responses? Thanks, George On 5/19/18 5:41 PM, Sergey Ponomarev wrote: > Hi, > > I developing an implementation of back channel token revocation > endpoint. And I think we should reconsider and probably change the > specification to improve error handling. > > Here we see several situations of error state: > 1. token wasn't sent in request. > 2. token is invalid by format i.e. not JWT or JWT with invalid signature > 3. token is expired or token is evenunknown > 4. token was already revoked > 5. token type is unsupported > > According to RFC7009 OAuth 2.0 Token Revocation > section 2.2 Revocation Response: > > The authorization server responds with HTTP status code 200 if the > token has been revoked successfully or if the client submitted an > invalid token. > Note: invalid tokens do not cause an error response since the > client cannot handle such an error in a reasonable way. Moreover, > the purpose of the revocation request, invalidating the particular > token, is already achieved.. > > > As you may see this section covers only case 3 and case 4 but it's > very unclear: calling token as "invalid" is very broad definition. > I think we should take a look on each case separately: > > 1. token wasn't sent in request. > Most implementations returns 400 status code,error: > "invalid_request", error_description": "Missing required parameter: > token". > Note that returned error is not "invalid_token" but "invalid_request" > and I think this should be correct behavior and should be clearly > specified. > > 2. token is invalid by format i.e. not JWT or JWT with invalid signature > This error is mostly related to JWT but for reference (opaque) tokens > can be also applied (e.g. token is too long). > Goolge OAuth returns 400 code with  "error": "invalid_token" and I > think this is correct behavior. > The client can have a bug and sends invalid tokens so we should return > an error response instead of 200 status. > > 3. token is expired or even unknown > Spec says that IdP should return 200 in this case but in case of > unknown token this may be a symptom of a bug on client side. Even if > IdP can clearly determine that token is expired (in case of JWT) this > is hard to determine in case of reference token that was removed from DB. > So personally I think that from security perspective it's better to > response with 400 status because client can have a bug when it's sends > some unknown token and think that it was revoked while it wasn't. > > For example Google OAuth revocation endpoint implementation do not > follow the spec and returns 400 Bad Request with error message "Token > is revoked or expired". > > 4. token was already revoked > The same as above: this can be a bug in a client and we should return > 400 status. In case of reference token which was removed from DB we > can't distinguish that the token was revoked or even existed so this > situation is the same as unknown token. > > 5. token type is unsupported > For this case specification introduces a new error code for case 5 in > section 2.2.1. Error Response : > > unsupported_token_type: The authorization server does not support > the revocation of the presented token type.  That is, the client > tried to revoke an access token on a server not   supporting this > feature. > > But it would be better to mention that revocation of ID token (which > can be is considered as "public" and not used to auth) definitely > should cause this error. > > It would be great if we discuss this cases and improve specification. > > P.S. Also it may be worse to mention that specification says that > content of successful response is empty but status code is 200 instead > of 201 "No Content". > > Regards, > Sergey Ponomarev > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------4C15641529AD713F172C421F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'm not understanding how these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.

Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more detailed error responses?

Thanks,
George

On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel token revocation endpoint. And I think we should reconsider and probably change the specification to improve error handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with invalid signature
3. token is expired or token is even unknown
4. token was already revoked
5. token type is unsupported 

According to  RFC7009 OAuth 2.0 Token Revocation  section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.  Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 and case 4 but it's very unclear: calling token as "invalid" is very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request. 
Most implementations returns 400 status code, error: "invalid_request", error_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with  "error": "invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it was revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported 
For this case specification introduces a new error code for case 5 in section 2.2.1. Error Response :
unsupported_token_type:  The authorization server does not support the revocation of the presented token type.  That is, the client tried to revoke an access token on a server not   supporting this feature. 
But it would be better to mention that revocation of ID token (which can be is considered as "public" and not used to auth) definitely should cause this error.

It would be great if we discuss this cases and improve specification.

P.S. Also it may be worse to mention that specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey Ponomarev


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

--------------4C15641529AD713F172C421F-- From nobody Mon May 21 14:14: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 E5FAC12D88B for ; Mon, 21 May 2018 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 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, FROM_EXCESS_BASE64=0.979, 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=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBjeUOssd6Ws for ; Mon, 21 May 2018 14:14:35 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-oln040092069108.outbound.protection.outlook.com [40.92.69.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEA912D86C for ; Mon, 21 May 2018 14:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fuFu0x8ukyE9XLn2zjsspkL6+YpoHHjzI7mLyBRtahg=; b=H/UoIuXuHTjme6GHJ6GlhYN/x1ru1qERW5oLB8MBtdqE6hH8gvnkUN9D5IbNlud/V/0xYcd+xc7AAvRcij26YHDVhdACYkqZ6gSXqhP3p58sGKW14sz7DdDoBFhx8uQSz1qPfpU32/4o2AFblUjYj06DRQ78n59/WC8/I780hUOLjJtHLpWobknyGHBXUgimJ7+YbD7CmEqXrnF0/XyvFCJ0gBe/umNjXQIW0mkC6TiNWD5UkAjXCBSJjjlHgOAUrZPZ6mL7OajTPcKqEHKR3HxRDHWw2sPFKAcVwzcgO9Bsu7jnEOUfJi39FAEW4fHMvHAwOpGmzLGlIhn0vq6otg== Received: from HE1EUR02FT052.eop-EUR02.prod.protection.outlook.com (10.152.10.54) by HE1EUR02HT110.eop-EUR02.prod.protection.outlook.com (10.152.11.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.735.16; Mon, 21 May 2018 21:14:33 +0000 Received: from DB6PR0701MB2822.eurprd07.prod.outlook.com (10.152.10.56) by HE1EUR02FT052.mail.protection.outlook.com (10.152.11.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.776.18 via Frontend Transport; Mon, 21 May 2018 21:14:32 +0000 Received: from DB6PR0701MB2822.eurprd07.prod.outlook.com ([fe80::2c8b:e6e0:14f6:625d]) by DB6PR0701MB2822.eurprd07.prod.outlook.com ([fe80::2c8b:e6e0:14f6:625d%8]) with mapi id 15.20.0797.005; Mon, 21 May 2018 21:14:32 +0000 From: =?koi8-r?B?8MXU0s/XIODSyco=?= To: "oauth@ietf.org" Thread-Index: AQHT8UiyT0iAKX3JDEWGsACHNE4LHg== Date: Mon, 21 May 2018 21:14:32 +0000 Message-ID: Accept-Language: ru-RU, en-US Content-Language: ru-RU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:B21FC53B5B0793290AFA7B36F2E1ED067B69BB7A44AE712909865CBD0DCAB1BE; UpperCasedChecksum:DA601420D504129C1DD7EB95B65D70596160D4487EF4078A0EAB437C4CD8F708; SizeAsReceived:6791; Count:43 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [LP/O2NjUzBLuvx/D9/3oWcoGrAZaiH5J] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR02HT110; 7:pl0tJEqVUmIlDEtTFKSiENkuDSS1cZuloM6p9Xt9xswtfVCWCIijTju6QcuhlqsCD781qElE2000Kl10L0VH66lPtlX/74J9MuJohk4xfhR4QHyPSFE1dYnRFuWtQmikDbkQl9RZZHfzjozYgfB/jFJufR6EFCQU7zMgY17HWRWUkM4JW3rTWghrbgAejoslnubIJHwGEu4FNFemXxX9RilLiDY9577KppCAAqeWzBMS3jg4gtfHZ6J5KEC5aTcG x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:HE1EUR02HT110; x-ms-traffictypediagnostic: HE1EUR02HT110: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR02HT110; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR02HT110; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(72206003)(106356001)(25636003)(2351001)(6306002)(33656002)(104016004)(105586002)(5660300001)(588024002)(5640700003)(74316002)(55016002)(20460500001)(2900100001)(236005)(82202002)(6916009)(14454004)(5406001)(54896002)(6436002)(558084003)(3280700002)(25786009)(3660700001)(8936002)(1730700003)(81156014)(97736004)(606006)(68736007)(5250100002)(99286004)(486006)(426003)(85182001)(86362001)(5416005)(476003)(102836004)(6346003)(26005)(7696005)(2501003)(87572001)(57042004)(110126008); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR02HT110; H:DB6PR0701MB2822.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: outlook.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Petroff0480@outlook.com; x-microsoft-antispam-message-info: owRY9RIJos5Fi6b6g037SnQGl+CdrbN0O/BhR85nwDxMOkEgvYx7paegiBbDiQday9js6LNiR1fjN1aGeUNax9fW4P3faouix2DGjgTAcGD67CWwYvVpdLs099Nb0XyjMNUYH3t0aQ/0a7HaUtYovczBJmfACvDjIaAIb+L5oWxLfT7CqDpLaAShlFtOfiTD Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB28226C9621E1EC254A1F6363AC950DB6PR0701MB2822_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a1ea2c5d-0b29-4896-d2d5-08d5bf5fd92b X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-Network-Message-Id: a1ea2c5d-0b29-4896-d2d5-08d5bf5fd92b X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2018 21:14:32.8408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR02HT110 Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 21:14:37 -0000 --_000_DB6PR0701MB28226C9621E1EC254A1F6363AC950DB6PR0701MB2822_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable =EF=D4=D0=D2=C1=D7=CC=C5=CE=CF =C9=DA =F0=CF=DE=D4=C1 =C4=CC=D1 Windows 10 --_000_DB6PR0701MB28226C9621E1EC254A1F6363AC950DB6PR0701MB2822_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

 

 

=EF=D4=D0=D2=C1=D7=CC=C5=CE=CF =C9=DA =F0=CF=DE=D4=C1 =C4=CC=D1 Windows 10

 

--_000_DB6PR0701MB28226C9621E1EC254A1F6363AC950DB6PR0701MB2822_-- From nobody Mon May 21 14:29: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 072E112D864 for ; Mon, 21 May 2018 14:29:32 -0700 (PDT) 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 7XGYJld19PxT for ; Mon, 21 May 2018 14:29:30 -0700 (PDT) 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 BC9F2128896 for ; Mon, 21 May 2018 14:29:29 -0700 (PDT) X-AuditID: 1209190c-3efff70000007ed3-7e-5b033a37d217 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 47.6A.32467.73A330B5; Mon, 21 May 2018 17:29:28 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w4LLTNOn004014; Mon, 21 May 2018 17:29:24 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4LLTKV9001785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 May 2018 17:29:21 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EA747E4A-B214-46C0-987B-4BBD67F6BE5A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 21 May 2018 17:29:19 -0400 In-Reply-To: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> Cc: Sergey Ponomarev , "" To: George Fletcher References: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixG6nrmthxRxtMHOGvMXX/mqLk29fsVls +d3H7sDscWLZFVaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugStj/b0FbAXXO5kqjrRsZGxg bH/G2MXIySEhYCKxp/s/WxcjF4eQwGImia4XD1ghnI2MEpfajzFBONeZJKa9m8wK0sImoCox fU0LE4jNK2Al8WHBRzYQm1kgSWLHweNsEHETiR1X2thBbGEgu3HCMiCbg4MFqHfxMROQMKeA tcSeK6uYIVp9JfbM/wE2UkTAXKLlwDmoixoZJfovdDFDnKok8X/XEeYJjPyzkKybhWQdRFxb YtnC18wQtqbE/u7lLJjiGhKd3yayLmBkW8Uom5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKX mlK6iREU8JySPDsYz7zxOsQowMGoxMP74AJTtBBrYllxZe4hRkkOJiVR3n+FQCG+pPyUyozE 4oz4otKc1OJDjBIczEoivJ8uAeV4UxIrq1KL8mFS0hwsSuK82YsYo4UE0hNLUrNTUwtSi2Cy MhwcShK8uZbM0UKCRanpqRVpmTklCGkmDk6Q4TxAw/tAaniLCxJzizPTIfKnGO05lj3p72Hm OPR+CpA8BybvHJjawyzEkpeflyolzrvLAqhNAKQtozQPbjIombmvs7N4xSgO9Kgwbz3IcB5g IoSb/QpoLRPQ2o5D/6OA1pYkIqSkGhg5H9s6Jl67fKU0Nkxgtr70RZUTuVq3fv6d0OW75/La uyppGSEHNIuywtPncTLrTN+5z8M1UGwpo5mv0Ymin++avghttShZK6nz1/SXQBP7kR+OOnbu JetKa37PL3CZFjLpjckelZsXJyy7F/2tRf3HnEr788+vrlzhGLRR0n+ryArm9Jtb2qcosRRn JBpqMRcVJwIAg9W2mUEDAAA= Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 21:29:32 -0000 --Apple-Mail=_EA747E4A-B214-46C0-987B-4BBD67F6BE5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m with George here: revocation is almost a best-effort request = from the client=E2=80=99s perspective. It sends a message to the server = saying =E2=80=9Chey I=E2=80=99m done with this token, you can throw it = out too=E2=80=9D. If the server does revoke the token, the client throws = it out. If the server doesn=E2=80=99t revoke the token? Then the client = still throws it out. Either way the results from the client=E2=80=99s = perspective are the same: it=E2=80=99s already decided that it=E2=80=99s = done with the token before it talks to the server. It=E2=80=99s an = optional cleanup step in most OAuth systems. =E2=80=94 Justin > On May 21, 2018, at 5:08 PM, George Fletcher = wrote: >=20 > I'm not understanding how these different cases matter to the client? = I doubt that the running code will be able to dynamically handle the = error. So it seems this information is only relevant to the developers = and not relevant from an end user and the client perspective. >=20 > Also, for the 5 states you define, the effect of calling revocation is = still that the token is "revoked" because the token is already not = valid. >=20 > So from an implementation perspective, where is the concern that = developer will do the "wrong thing" without these more detailed error = responses? >=20 > Thanks, > George >=20 > On 5/19/18 5:41 PM, Sergey Ponomarev wrote: >> Hi, >>=20 >> I developing an implementation of back channel token revocation = endpoint. And I think we should reconsider and probably change the = specification to improve error handling. >>=20 >> Here we see several situations of error state: >> 1. token wasn't sent in request. >> 2. token is invalid by format i.e. not JWT or JWT with invalid = signature >> 3. token is expired or token is even unknown >> 4. token was already revoked >> 5. token type is unsupported=20 >>=20 >> According to RFC7009 OAuth 2.0 Token Revocation = section 2.2 Revocation Response: >>=20 >> The authorization server responds with HTTP status code 200 if the = token has been revoked successfully or if the client submitted an = invalid token. >> Note: invalid tokens do not cause an error response since the client = cannot handle such an error in a reasonable way. Moreover, the purpose = of the revocation request, invalidating the particular token, is already = achieved.. >>=20 >> As you may see this section covers only case 3 and case 4 but it's = very unclear: calling token as "invalid" is very broad definition. >> I think we should take a look on each case separately: >>=20 >> 1. token wasn't sent in request.=20 >> Most implementations returns 400 status code, error: = "invalid_request", error_description": "Missing required parameter: = token". >> Note that returned error is not "invalid_token" but "invalid_request" = and I think this should be correct behavior and should be clearly = specified. >>=20 >> 2. token is invalid by format i.e. not JWT or JWT with invalid = signature >> This error is mostly related to JWT but for reference (opaque) tokens = can be also applied (e.g. token is too long). >> Goolge OAuth returns 400 code with "error": "invalid_token" and I = think this is correct behavior. >> The client can have a bug and sends invalid tokens so we should = return an error response instead of 200 status. >>=20 >> 3. token is expired or even unknown >> Spec says that IdP should return 200 in this case but in case of = unknown token this may be a symptom of a bug on client side. Even if IdP = can clearly determine that token is expired (in case of JWT) this is = hard to determine in case of reference token that was removed from DB. >> So personally I think that from security perspective it's better to = response with 400 status because client can have a bug when it's sends = some unknown token and think that it was revoked while it wasn't. >>=20 >> For example Google OAuth revocation endpoint implementation do not = follow the spec and returns 400 Bad Request with error message "Token is = revoked or expired". >>=20 >> 4. token was already revoked >> The same as above: this can be a bug in a client and we should return = 400 status. In case of reference token which was removed from DB we = can't distinguish that the token was revoked or even existed so this = situation is the same as unknown token. >>=20 >> 5. token type is unsupported=20 >> For this case specification introduces a new error code for case 5 in = section 2.2.1. Error Response : >> unsupported_token_type: The authorization server does not support = the revocation of the presented token type. That is, the client tried = to revoke an access token on a server not supporting this feature.=20 >> But it would be better to mention that revocation of ID token (which = can be is considered as "public" and not used to auth) definitely should = cause this error. >>=20 >> It would be great if we discuss this cases and improve specification. >>=20 >> P.S. Also it may be worse to mention that specification says that = content of successful response is empty but status code is 200 instead = of 201 "No Content". >>=20 >> Regards, >> Sergey=C2=A0Ponomarev >>=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=_EA747E4A-B214-46C0-987B-4BBD67F6BE5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m with George here: revocation is almost a best-effort request from = the client=E2=80=99s perspective. It sends a message to the server = saying =E2=80=9Chey I=E2=80=99m done with this token, you can throw it = out too=E2=80=9D. If the server does revoke the token, the client throws = it out. If the server doesn=E2=80=99t revoke the token? Then the client = still throws it out. Either way the results from the client=E2=80=99s = perspective are the same: it=E2=80=99s already decided that it=E2=80=99s = done with the token before it talks to the server. It=E2=80=99s an = optional cleanup step in most  OAuth systems.

 =E2=80=94 Justin

On May 21, 2018, at 5:08 PM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20
I'm not = understanding how these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.
=
Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more detailed error responses?

Thanks,
George

On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel = token revocation endpoint. And I think we should reconsider and probably change the specification to improve error = handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with = invalid signature
3. token is expired or token is even unknown
4. token was already revoked
5. token type is unsupported 

According to  RFC7009 OAuth 2.0 Token Revocation  section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.  Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 = and case 4 but it's very unclear: calling token as "invalid" is very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request. 
Most implementations returns 400 status code, error: "invalid_request", error_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with  "error": = "invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it was revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported 
For this case specification introduces a new = error code for case 5 in section 2.2.1. Error Response :
unsupported_token_type:  The authorization server does not support the revocation of the presented token type.  That is, the client tried to = revoke an access token on a server not   supporting this = feature. 
But it would be better to mention that = revocation of ID token (which can be is considered as "public" and not used to auth) definitely should cause this error.

It would be great if we discuss this cases and = improve specification.

P.S. Also it may be worse to mention that = specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey Ponomarev


_______________________________________________
OAuth mailing 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=_EA747E4A-B214-46C0-987B-4BBD67F6BE5A-- From nobody Tue May 22 02:27: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 8E61E12E868 for ; Tue, 22 May 2018 02:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 w44SNn_jU2A4 for ; Tue, 22 May 2018 02:27:53 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA75C12E866 for ; Tue, 22 May 2018 02:27:52 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id t16-v6so15676365wrm.9 for ; Tue, 22 May 2018 02:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=pmS48rauhq8SrBa01d/R3CUY9ipQ8eelFXT3ZpnN9SY=; b=kCJkUqo1uX5Y+nk7yflFaSG5YjwY5eQcec2zKkHAeTAQs1JnnubjJGLCH8kYfAuA17 nrXqQADUNPTNKK+4r1cwjwuhGBsgC1gk3GIEf5+hQefzbJb9D9nueoF1rnMprUJLG6+6 8zTQ6T4wmR8C5BZx7GMBTlTMfNjn2Wo7SaPt7J7ahs6V/T6Y8DxOzbDYrUdHGqtuYCEn Y5gQiBr1Fe5MdhsnkOFO2Mvns4VODQf1QrMLP/4v2Ny2bE4lBwgwknR9tOuvLWjvc1Qr 62OE+CmF7orV1v2hpN7xoulhq2D9F4X8R+/Nl7Pqb0fqtk0Pf5lYUb9hxKcFyFypHkav O8pQ== 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=pmS48rauhq8SrBa01d/R3CUY9ipQ8eelFXT3ZpnN9SY=; b=f8RV0v/eb81lHb9m2NoAwLihxHdfut92otxQ62kqshRm+zlMYp7Cxaa08n6KrCijl+ wb7YlXwrn/UX+lXCG+Ju/8KHzVI58Y1nz0fwb+QEUVrfj1vOIm9tfbJMBRGtum3CIj6n JtW6iEsLOEDyM6Z2NckiCnzoN9HhI87FXHHKEqA/ghU0MXqULveXusb//h7Gh3T6UKgb jpwMm/1T/wAsIqej4OiO+8cIVDxSt00P30Ex/abM0UlOQMESKN6R72mwEpvvSESPk55V CXWvkaf1A/tlY8bCxRpgDaF2OujiaN9PzYpfIDOTXC9vHt0Vbu/Rp3l/qvxJcNcnjjls 6/0g== X-Gm-Message-State: ALKqPwdRezutv2gUwGm97RImDBSwqQReEniaXKTxS8eNGWbtiSQIMi6z sCdhgcpYdej6tkRgsEv9BYWdN0U3svA= X-Google-Smtp-Source: AB8JxZrBc6Mli/76pN16UWN04r0/8nrs/sF3jOvHnrBmqfTJficffqmZ7hPODJwAPfAkNfb/2WhVtw== X-Received: by 2002:a5d:4143:: with SMTP id c3-v6mr860870wrq.129.1526981271019; Tue, 22 May 2018 02:27:51 -0700 (PDT) Received: from dhcp127.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id b16-v6sm16194281wrm.89.2018.05.22.02.27.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 May 2018 02:27:50 -0700 (PDT) From: Joseph Heenan Content-Type: multipart/alternative; boundary="Apple-Mail=_A9169FF2-39B7-46ED-966B-5DEEB47E94E2" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 22 May 2018 10:27:48 +0100 References: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> To: "" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 09:27:57 -0000 --Apple-Mail=_A9169FF2-39B7-46ED-966B-5DEEB47E94E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think one important point Sergey raised was that the response to the = client from submitting the wrong token is the same 200 response as = submitting a valid token, and that hugely increases the chance that the = developer of the client app might submit the wrong token and never = realise. Making it easier for the developer of the client app to see = that they've done something wrong and need to fix their implementation = seems like a worthwhile goal to me, and that would appear to explain = what google are thinking with their responses. An example of an easy to make error that would get a 200 response is = getting the values the wrong way around, i.e. a body of: token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz (as token_type_hint may be ignored by the server.) The example Sergey gave of the developer accidentally sending the id = token instead of the intended token seems quite likely to happen in the = real world too, and a 200 response in that case does seem wrong to me. Joseph > On 21 May 2018, at 22:29, Justin Richer wrote: >=20 > I=E2=80=99m with George here: revocation is almost a best-effort = request from the client=E2=80=99s perspective. It sends a message to the = server saying =E2=80=9Chey I=E2=80=99m done with this token, you can = throw it out too=E2=80=9D. If the server does revoke the token, the = client throws it out. If the server doesn=E2=80=99t revoke the token? = Then the client still throws it out. Either way the results from the = client=E2=80=99s perspective are the same: it=E2=80=99s already decided = that it=E2=80=99s done with the token before it talks to the server. = It=E2=80=99s an optional cleanup step in most OAuth systems. >=20 > =E2=80=94 Justin >=20 >> On May 21, 2018, at 5:08 PM, George Fletcher = > wrote: >>=20 >> I'm not understanding how these different cases matter to the client? = I doubt that the running code will be able to dynamically handle the = error. So it seems this information is only relevant to the developers = and not relevant from an end user and the client perspective. >>=20 >> Also, for the 5 states you define, the effect of calling revocation = is still that the token is "revoked" because the token is already not = valid. >>=20 >> So from an implementation perspective, where is the concern that = developer will do the "wrong thing" without these more detailed error = responses? >>=20 >> Thanks, >> George >>=20 >> On 5/19/18 5:41 PM, Sergey Ponomarev wrote: >>> Hi, >>>=20 >>> I developing an implementation of back channel token revocation = endpoint. And I think we should reconsider and probably change the = specification to improve error handling. >>>=20 >>> Here we see several situations of error state: >>> 1. token wasn't sent in request. >>> 2. token is invalid by format i.e. not JWT or JWT with invalid = signature >>> 3. token is expired or token is even unknown >>> 4. token was already revoked >>> 5. token type is unsupported=20 >>>=20 >>> According to RFC7009 OAuth 2.0 Token Revocation = section 2.2 Revocation Response: >>>=20 >>> The authorization server responds with HTTP status code 200 if the = token has been revoked successfully or if the client submitted an = invalid token. >>> Note: invalid tokens do not cause an error response since the client = cannot handle such an error in a reasonable way. Moreover, the purpose = of the revocation request, invalidating the particular token, is already = achieved.. >>>=20 >>> As you may see this section covers only case 3 and case 4 but it's = very unclear: calling token as "invalid" is very broad definition. >>> I think we should take a look on each case separately: >>>=20 >>> 1. token wasn't sent in request.=20 >>> Most implementations returns 400 status code, error: = "invalid_request", error_description": "Missing required parameter: = token". >>> Note that returned error is not "invalid_token" but = "invalid_request" and I think this should be correct behavior and should = be clearly specified. >>>=20 >>> 2. token is invalid by format i.e. not JWT or JWT with invalid = signature >>> This error is mostly related to JWT but for reference (opaque) = tokens can be also applied (e.g. token is too long). >>> Goolge OAuth returns 400 code with "error": "invalid_token" and I = think this is correct behavior. >>> The client can have a bug and sends invalid tokens so we should = return an error response instead of 200 status. >>>=20 >>> 3. token is expired or even unknown >>> Spec says that IdP should return 200 in this case but in case of = unknown token this may be a symptom of a bug on client side. Even if IdP = can clearly determine that token is expired (in case of JWT) this is = hard to determine in case of reference token that was removed from DB. >>> So personally I think that from security perspective it's better to = response with 400 status because client can have a bug when it's sends = some unknown token and think that it was revoked while it wasn't. >>>=20 >>> For example Google OAuth revocation endpoint implementation do not = follow the spec and returns 400 Bad Request with error message "Token is = revoked or expired". >>>=20 >>> 4. token was already revoked >>> The same as above: this can be a bug in a client and we should = return 400 status. In case of reference token which was removed from DB = we can't distinguish that the token was revoked or even existed so this = situation is the same as unknown token. >>>=20 >>> 5. token type is unsupported=20 >>> For this case specification introduces a new error code for case 5 = in section 2.2.1. Error Response : >>> unsupported_token_type: The authorization server does not support = the revocation of the presented token type. That is, the client tried = to revoke an access token on a server not supporting this feature.=20 >>> But it would be better to mention that revocation of ID token (which = can be is considered as "public" and not used to auth) definitely should = cause this error. >>>=20 >>> It would be great if we discuss this cases and improve = specification. >>>=20 >>> P.S. Also it may be worse to mention that specification says that = content of successful response is empty but status code is 200 instead = of 201 "No Content". >>>=20 >>> Regards, >>> Sergey=C2=A0Ponomarev >>>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A9169FF2-39B7-46ED-966B-5DEEB47E94E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I think one important point Sergey raised was that the = response to the client from submitting the wrong token is the same 200 = response as submitting a valid token, and that hugely increases the = chance that the developer of the client app might submit the wrong token = and never realise. Making it easier for the developer of the client app = to see that they've done something wrong and need to fix their = implementation seems like a worthwhile goal to me, and that would appear = to explain what google are thinking with their responses.

An example of an easy to make error that would get = a 200 response is getting the values the wrong way around, i.e. a body = of:

    =  token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz
(as token_type_hint may be ignored by the = server.)

The example Sergey gave of = the developer accidentally sending the id token instead of the intended = token seems quite likely to happen in the real world too, and a 200 = response in that case does seem wrong to me.


Joseph


On 21 May 2018, at 22:29, Justin Richer = <jricher@mit.edu> = wrote:

I=E2=80=99m with = George here: revocation is almost a best-effort request from the = client=E2=80=99s perspective. It sends a message to the server saying = =E2=80=9Chey I=E2=80=99m done with this token, you can throw it out = too=E2=80=9D. If the server does revoke the token, the client throws it = out. If the server doesn=E2=80=99t revoke the token? Then the client = still throws it out. Either way the results from the client=E2=80=99s = perspective are the same: it=E2=80=99s already decided that it=E2=80=99s = done with the token before it talks to the server. It=E2=80=99s an = optional cleanup step in most  OAuth systems.

 =E2=80=94 Justin

On May 21, 2018, at 5:08 PM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20
I'm not = understanding how these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.
=
Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more detailed error responses?

Thanks,
George

On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel = token revocation endpoint. And I think we should reconsider and probably change the specification to improve error = handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with = invalid signature
3. token is expired or token is even unknown
4. token was already revoked
5. token type is unsupported 

According to  RFC7009 OAuth 2.0 Token Revocation  section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.  Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 = and case 4 but it's very unclear: calling token as "invalid" is very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request. 
Most implementations returns 400 status code, error: "invalid_request", error_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with  "error": = "invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it was revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported 
For this case specification introduces a new = error code for case 5 in section 2.2.1. Error Response :
unsupported_token_type:  The authorization server does not support the revocation of the presented token type.  That is, the client tried to = revoke an access token on a server not   supporting this = feature. 
But it would be better to mention that = revocation of ID token (which can be is considered as "public" and not used to auth) definitely should cause this error.

It would be great if we discuss this cases and = improve specification.

P.S. Also it may be worse to mention that = specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey Ponomarev


_______________________________________________
OAuth mailing 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=_A9169FF2-39B7-46ED-966B-5DEEB47E94E2-- From nobody Tue May 22 03:05: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 0314412EAD0 for ; Tue, 22 May 2018 03:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 FLPeXBXRBPks for ; Tue, 22 May 2018 03:05:08 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 3BAAC126B72 for ; Tue, 22 May 2018 03:05:08 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id p62-v6so15666573oie.10 for ; Tue, 22 May 2018 03:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oA8NkUC3ZVEg5HlKIQALfzDrqY/Ldrm8QJpKksNu2n0=; b=d4c++6zpaY8+vNOpuBU55gAT5xcE9O2lyRIwf+4X8f12XiiNkqEiMVDn7hlH/Bq/ZM Mv/x5Tbu32m6jPAYlQ686438RAsBYANKGyrzlzUAJw+ST3oE8fd+UzBHSoSko41wAxE8 uTAPlrDdvLkhWvTwCt4nHG/Wdb2rCDghZlLWXrdJ/DZcDApPa3L8SERC+SrPUCaWA//Q vkl+rBRMQqqlFRG7gKk/WJst0k09F2v9bjGuFxCkefgt4Z4M9OC/fkyXYxArpIrahc5f Pz1vwIbsKuaUSQ2ruEBRM8+Hd9WO/++hmqH40v16YGIKNTF2ctStTdMVmZdjdSGQE6ha KHQg== 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=oA8NkUC3ZVEg5HlKIQALfzDrqY/Ldrm8QJpKksNu2n0=; b=YUCUioK4MdTxVrfzfkdovAfZXyITRyEkaq9kLj12mQ8QBoLkz7L0XIyDxvFsfVoauX 4Spj6cjzQ0c27CyAEQL1hAYvr9yVP7pSxO+wiQWqQ2ibmD741KO+7ljrPeWelUL+zo3E HKcYNHYUspSB1eJmh/SRB0ZYRr21k/Wu1SxNXPq28k+NjrsSGg3GOXiRmip8TWSKidsQ 9PZfyEsIuAbTrn+HA/Ymh0M7rub/XH/wN6MgJhTqovnUNwR5L6sF6jzjfzr4v1OXTVrc eZG9FbE+B3owz2FiiFlwa1mPWk74bfPbg+QVHE3CTzQyxs+0bNbCWh3I3jn4uTvc/qh4 yOcQ== X-Gm-Message-State: ALKqPwfJ6t6ye+blohsn+75R/MrEeJkh4HqJhSCXvNgTbjSPlRWNvfbA JeeOJ43G3W7wBUjWwYqmcqLhF8DEVa3B4yvFPTU= X-Google-Smtp-Source: AB8JxZoFJ0Z4wNuRNbi9CNLyZv8wWlDygHX/sfXmvkMyCLtdILhGaq2zNhmcxSOm5eQWyQ7wSCUAGhgezqeSx7rUE+I= X-Received: by 2002:aca:5a09:: with SMTP id o9-v6mr14141160oib.127.1526983507431; Tue, 22 May 2018 03:05:07 -0700 (PDT) MIME-Version: 1.0 References: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> In-Reply-To: From: Sergey Ponomarev Date: Tue, 22 May 2018 13:04:31 +0300 Message-ID: To: joseph@authlete.com Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000089d7a4056cc88deb" Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 10:05:12 -0000 --00000000000089d7a4056cc88deb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Joseph, thank you for your details, that's exactly what I meant. On my full time job I developing a platform where we have a lot of connected small sites. And most of them are just another brands for different markets of the same company. So their developers mostly just copy source code from one site to another and changing desing and localization. Usually they are low skilled freelancers who using PHP and doesn't have security mindset. And it's very often situation when they just forgots to change a client_id. So from time to time I see in production logs that site1 is trying to logout a user from site2. If we'll respond always with 200 OK status then they'll never know that something went wrong. Also having a clear error responces make it easier to write functional tests. Also my point about revocation of ID token is real worl vulnarebilty which I found in Keycloak. I don't think is critical but anyway we can prevent this kind of errors by notice in specification. On Tue, 22 May 2018 at 12:28, Joseph Heenan wrote: > > I think one important point Sergey raised was that the response to the > client from submitting the wrong token is the same 200 response as > submitting a valid token, and that hugely increases the chance that the > developer of the client app might submit the wrong token and never realis= e. > Making it easier for the developer of the client app to see that they've > done something wrong and need to fix their implementation seems like a > worthwhile goal to me, and that would appear to explain what google are > thinking with their responses. > > An example of an easy to make error that would get a 200 response is > getting the values the wrong way around, i.e. a body of: > > token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz > > (as token_type_hint may be ignored by the server.) > > The example Sergey gave of the developer accidentally sending the id toke= n > instead of the intended token seems quite likely to happen in the real > world too, and a 200 response in that case does seem wrong to me. > > > Joseph > > > On 21 May 2018, at 22:29, Justin Richer wrote: > > I=E2=80=99m with George here: revocation is almost a best-effort request = from the > client=E2=80=99s perspective. It sends a message to the server saying =E2= =80=9Chey I=E2=80=99m done > with this token, you can throw it out too=E2=80=9D. If the server does re= voke the > token, the client throws it out. If the server doesn=E2=80=99t revoke the= token? > Then the client still throws it out. Either way the results from the > client=E2=80=99s perspective are the same: it=E2=80=99s already decided t= hat it=E2=80=99s done with > the token before it talks to the server. It=E2=80=99s an optional cleanup= step in > most OAuth systems. > > =E2=80=94 Justin > > On May 21, 2018, at 5:08 PM, George Fletcher < > gffletch=3D40aol.com@dmarc.ietf.org> wrote: > > I'm not understanding how these different cases matter to the client? I > doubt that the running code will be able to dynamically handle the error. > So it seems this information is only relevant to the developers and not > relevant from an end user and the client perspective. > > Also, for the 5 states you define, the effect of calling revocation is > still that the token is "revoked" because the token is already not valid. > > So from an implementation perspective, where is the concern that develope= r > will do the "wrong thing" without these more detailed error responses? > > Thanks, > George > > On 5/19/18 5:41 PM, Sergey Ponomarev wrote: > > Hi, > > I developing an implementation of back channel token revocation endpoint. > And I think we should reconsider and probably change the specification to > improve error handling. > > Here we see several situations of error state: > 1. token wasn't sent in request. > 2. token is invalid by format i.e. not JWT or JWT with invalid signature > 3. token is expired or token is even unknown > 4. token was already revoked > 5. token type is unsupported > > According to RFC7009 OAuth 2.0 Token Revocation > section 2.2 Revocation Response: > > The authorization server responds with HTTP status code 200 if the token >> has been revoked successfully or if the client submitted an invalid toke= n. >> Note: invalid tokens do not cause an error response since the client >> cannot handle such an error in a reasonable way. Moreover, the purpose = of >> the revocation request, invalidating the particular token, is already >> achieved.. > > > As you may see this section covers only case 3 and case 4 but it's very > unclear: calling token as "invalid" is very broad definition. > I think we should take a look on each case separately: > > 1. token wasn't sent in request. > Most implementations returns 400 status code, error: "invalid_request", e= rror_description": > "Missing required parameter: token". > Note that returned error is not "invalid_token" but "invalid_request" and > I think this should be correct behavior and should be clearly specified. > > 2. token is invalid by format i.e. not JWT or JWT with invalid signature > This error is mostly related to JWT but for reference (opaque) tokens can > be also applied (e.g. token is too long). > Goolge OAuth returns 400 code with "error": "invalid_token" and I think > this is correct behavior. > The client can have a bug and sends invalid tokens so we should return an > error response instead of 200 status. > > 3. token is expired or even unknown > Spec says that IdP should return 200 in this case but in case of unknown > token this may be a symptom of a bug on client side. Even if IdP can > clearly determine that token is expired (in case of JWT) this is hard to > determine in case of reference token that was removed from DB. > So personally I think that from security perspective it's better to > response with 400 status because client can have a bug when it's sends so= me > unknown token and think that it was revoked while it wasn't. > > For example Google OAuth revocation endpoint implementation do not follow > the spec and returns 400 Bad Request with error message "Token is revoked > or expired". > > 4. token was already revoked > The same as above: this can be a bug in a client and we should return 400 > status. In case of reference token which was removed from DB we can't > distinguish that the token was revoked or even existed so this situation = is > the same as unknown token. > > 5. token type is unsupported > For this case specification introduces a new error code for case 5 in > section 2.2.1. Error Response : > >> unsupported_token_type: The authorization server does not support the >> revocation of the presented token type. That is, the client tried to >> revoke an access token on a server not supporting this feature. > > But it would be better to mention that revocation of ID token (which can > be is considered as "public" and not used to auth) definitely should caus= e > this error. > > It would be great if we discuss this cases and improve specification. > > P.S. Also it may be worse to mention that specification says that content > of successful response is empty but status code is 200 instead of 201 "No > Content". > > Regards, > Sergey Ponomarev > > > _______________________________________________ > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Sergey Ponomarev , skype:stokito --00000000000089d7a4056cc88deb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Joseph, thank you for your details,= that's exactly what I meant.=C2=A0
On my full time job I dev= eloping a platform where we have a lot of connected small sites. And most o= f them are just another brands for different markets of the same company. S= o their developers mostly just copy source code from one site to another an= d changing desing and localization. Usually they are low skilled freelancer= s who using PHP and doesn't have security mindset. And it's very of= ten situation when they just forgots to change a client_id.
So fr= om time to time I see in production logs that site1 is trying to logout a u= ser from site2. If we'll respond always with 200 OK status then they= 9;ll never know that something went wrong.
Also having a clear er= ror responces make it easier to write functional tests.

Also my point about revocation of ID token is real worl vulnarebilty = which I found in Keycloak. I don't think is critical but anyway we can = prevent this kind of errors by notice in specification.

On Tue, 22 May 2018 at 12:28, Josep= h Heenan <joseph@authlete.com= > wrote:

I think one important po= int Sergey raised was that the response to the client from submitting the w= rong token is the same 200 response as submitting a valid token, and that h= ugely increases the chance that the developer of the client app might submi= t the wrong token and never realise. Making it easier for the developer of = the client app to see that they've done something wrong and need to fix= their implementation seems like a worthwhile goal to me, and that would ap= pear to explain what google are thinking with their responses.
An example of an easy to make error that would get a 200 respo= nse is getting the values the wrong way around, i.e. a body of:
<= br>
=C2=A0 =C2=A0 =C2=A0token=3Drefresh_token&token_type= _hint=3D45ghiukldjahdnhzdauz

(as token_type_hint may be= ignored by the server.)

The example Sergey gave o= f the developer accidentally sending the id token instead of the intended t= oken seems quite likely to happen in the real world too, and a 200 response= in that case does seem wrong to me.


Joseph


On 21 = May 2018, at 22:29, Justin Richer <jricher@mit.edu> wrote:

I=E2=80=99m with George here: revocation i= s almost a best-effort request from the client=E2=80=99s perspective. It se= nds a message to the server saying =E2=80=9Chey I=E2=80=99m done with this = token, you can throw it out too=E2=80=9D. If the server does revoke the tok= en, the client throws it out. If the server doesn=E2=80=99t revoke the toke= n? Then the client still throws it out. Either way the results from the cli= ent=E2=80=99s perspective are the same: it=E2=80=99s already decided that i= t=E2=80=99s done with the token before it talks to the server. It=E2=80=99s= an optional cleanup step in most =C2=A0OAuth systems.

= =C2=A0=E2=80=94 Justin

On May 21= , 2018, at 5:08 PM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20
I'm not understanding h= ow these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.

Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the= token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more deta= iled error responses?

Thanks,
George

On 5/19/18 5:41 PM,= Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel token revocation endpoint. And I think we should reconsider and probably change the specification to improve error handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with invalid=C2= =A0signature
3. token is expired or token is even=C2= =A0unknown
4. token was already revoked
5. token type is unsupported=C2=A0

According to=C2=A0 RFC7009 OAuth 2.0 Token Revocation=C2=A0 section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.=C2=A0 Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 and case 4 but it's very unclear: calling token as "invalid" i= s very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request.=C2=A0
Most implementations returns 400 status code,=C2=A0error:=C2=A0"= invalid_request",=C2=A0er= ror_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid=C2=A0signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with=C2=A0=C2=A0"error": "= ;invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it wa= s revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported=C2=A0
For this case specification introduces a new error code for case 5 in section 2.2.1. Error Response=C2=A0:
unsupported_token= _type:=C2=A0 The authorization server does not support the revocation of the presented token type.=C2=A0 That is, the client tried to revo= ke an access token on a server not=C2=A0 =C2=A0supporting this featu= re.=C2=A0
But it would be better to mention that revocation of ID token (which can be is considered as "public" and not u= sed to auth) definitely should cause this error.

It would be great if we discuss this cases and improve specification.

P.S. Also it may be worse to mention that specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey=C2=A0P= onomarev


_______________________________________________
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 maili= ng list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth

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


--
--00000000000089d7a4056cc88deb-- From nobody Tue May 22 06:06: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 80A9212EB32 for ; Tue, 22 May 2018 06:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 lskmRhwZTJO0 for ; Tue, 22 May 2018 06:05:56 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8070212EB31 for ; Tue, 22 May 2018 06:05:56 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 497B57803C8 for ; Tue, 22 May 2018 15:05:54 +0200 (CEST) To: oauth@ietf.org References: <152681629717.2793.15028642368623108299@ietfa.amsl.com> <34B9FBE9-788E-4B1C-B2A4-08FD14EC2BD5@lodderstedt.net> From: Denis Message-ID: <1fe04f5e-b968-5a6d-efe8-b47da5e28592@free.fr> Date: Tue, 22 May 2018 15:05:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <34B9FBE9-788E-4B1C-B2A4-08FD14EC2BD5@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------96BEB17147E3C74C7C3E1AD3" Content-Language: en-US Archived-At: Subject: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 13:06:00 -0000 This is a multi-part message in MIME format. --------------96BEB17147E3C74C7C3E1AD3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Comments on OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-06 The text is scaring ! It is quite hard to understand under which /context(s) /and conditions OAuth 2.0 could be safely used. 1° A "Privacy considerations" section should be added. It is important to place the AS at the center of the picture and to observe whether it would be able to act as Big brother (or not). Several counter-measures are not 'privacy friendly'. As an example, in section 3.7.1.3 the text states: The audience can basically be expressed using logical names or physical addresses (like URLs). Since this URL will be known to the AS, the AS will be able to act as Big Brother. There are cases where this will not be important but there are cases where it will be. The text states later on:      Instead of the URL, it is also possible to utilize the fingerprint of the resource server’s X.509 certificate as audience value. This is obviously better, but it is not a panacea. The AS will know how often a particular user accesses a particular server. The AS would have also plenty of time to try various URLs and to check whether they match with the fingerprint and hence might be able to discover the URL. As another example, in section 3.7.1.1, the text states: An authorization server could provide the client with additional information about the location where it is safe     to use its access tokens. In the simplest form, this would require the AS to publish a list of its known resource servers,     illustrated in the following example using a metadata parameter "resource_servers". This is not "privacy friendly" since relying parties will know with which resource servers the AS has made an agreement and the AS will know at the minimum where the access tokens it issues can be used. 2° There is one important threat that was not discussed in the OAuth 2.0 "Threat Model and Security Considerations from 2013" [RFC6819]: collusion between users. In particular, when a user got an access token that does not allow to fully identify him and where he would allow another user to use it. A typical case would be an access token only stating that the user is over 18. This case should be mentioned. My current belief is that OAuth 2.0 is unable to counter this kind of attack, even when private ore secret keys are protected by a secure element. In section 3.5.1. Token Binding is mentioned "as a secure and convenient mechanism (due to its browser integration)". However, it should also be mentioned that this mechanism is inefficient in case of a collusion attack. 3° Section2 describes the set of security mechanisms the OAuth working group recommended to OAuth implementers. However, the text that follows uses the verb" shall", hence it is no more a recommendation but a requirement. The use of the verb "should" should be considered instead. In particular, the text states: "Clients shall use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts         to inject (replay) authorization codes into the authorization response". This is incorrect, since RFC7636 should be used when the authorization code is returned from the authorization endpoint within a communication path that is _not protected_ by Transport Layer Security (TLS). Instead of placing requirements one after another, the document should be restructured to highlight the contexts where these recommendations are being done, in particular for:    - static relationships between client, authorization server and resource servers, and - dynamic establishment relationships between clients on one side and authorization servers and resource servers on the other side. Denis --------------96BEB17147E3C74C7C3E1AD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Comments on OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-06

The text is scaring ! It is quite hard to understand under which context(s) and conditions OAuth 2.0 could be safely used.

1° A "Privacy considerations" section should be added. It is important to place the AS at the center of the picture
and to observe whether it would be able to act as Big brother (or not). Several counter-measures are not 'privacy friendly'.

As an example, in section 3.7.1.3 the text states:

     The audience can basically be expressed using logical names or physical addresses (like URLs).

Since this URL will be known to the AS, the AS will be able to act as Big Brother. There are cases where this will not be important
but there are cases where it will be. The text states later on:

     Instead of the URL, it is also possible to utilize the fingerprint of the resource server’s X.509 certificate as audience value.

This is obviously better, but it is not a panacea. The AS will know how often a particular user accesses a particular server.
The AS would have also plenty of time to try various URLs and to check whether they match with the fingerprint and hence
might be able to discover the URL.

 As another example, in section 3.7.1.1, the text states:

    An authorization server could provide the client with additional information about the location where it is safe
    to use its access tokens. In the simplest form, this would require the AS to publish a list of its known resource servers,
    illustrated in the following example using a metadata parameter "resource_servers".

This is not "privacy friendly" since relying parties will know with which resource servers the AS has made an agreement
and the AS will know at the minimum where the access tokens it issues can be used.


2° There is one important threat that was not discussed in the OAuth 2.0 "Threat Model and Security Considerations from 2013" [RFC6819]:
collusion between users. In particular, when a user got an access token that does not allow to fully identify him and where he would allow
another user to use it. A typical case would be an access token only stating that the user is over 18. This case should be mentioned.
My current belief is that OAuth 2.0 is unable to counter this kind of attack, even when private ore secret keys are protected by a secure element.

In section 3.5.1. Token Binding is mentioned "as a secure and convenient mechanism (due to its browser integration)".
However, it should also be mentioned that this mechanism is inefficient in case of a collusion attack.

3° Section 2 describes the set of security mechanisms the OAuth working group recommended to OAuth implementers.
However, the text that follows uses the verb" shall", hence it is no more a recommendation but a requirement.
The use of the verb "should" should be considered instead.

In particular, the text states:

       "Clients shall use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts
        to inject (replay) authorization codes into the authorization response".

This is incorrect, since RFC7636 should be used when the authorization code is returned from the authorization endpoint
within a communication path that is not protected by Transport Layer Security (TLS).

Instead of placing requirements one after another, the document should be restructured to highlight the contexts
where these recommendations are being done, in particular for:

     - static relationships between client, authorization server and resource servers, and
     - dynamic establishment relationships between clients on one side and authorization servers and resource servers on the other side.

Denis

--------------96BEB17147E3C74C7C3E1AD3-- From nobody Tue May 22 07:33: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 EAAED12EB46 for ; Tue, 22 May 2018 07:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oSpkqJVov7nB for ; Tue, 22 May 2018 07:33:31 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.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 7D26912DA06 for ; Tue, 22 May 2018 07:33:31 -0700 (PDT) X-AuditID: 1209190d-419ff70000001a14-eb-5b042a39e377 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 14.A0.06676.93A240B5; Tue, 22 May 2018 10:33:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w4MEXPQB029083; Tue, 22 May 2018 10:33:26 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4MEXNt2001821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 May 2018 10:33:24 -0400 From: Justin Richer Message-Id: <1241C308-15BA-4235-85B8-5B12E1E4B248@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_C064A021-58FD-46F7-91EC-C61C62E0C06D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 22 May 2018 10:33:22 -0400 In-Reply-To: Cc: "" To: Joseph Heenan References: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixG6nomulxRJtcPWQmMWDU2UWJ9++YnNg 8mhdNYfdY8mSn0wBTFFcNimpOZllqUX6dglcGU923GUs2LqJqeLUrwnsDYyrO5m6GDk5JARM JJZfO8fcxcjFISSwmEni1YU2VghnI6PEsp0PoDLXmSS+9K1gA2lhE1CVmL6mBaydV8BK4uz1 iawgNrNAkkTvvHuMEHETiR1X2thBbGEgu3HCMjCbBaj3xcdOMJtTwEHi28xeoAUcQL3qEu0n XUDCIkBm68qpLBB7XzBKTGl+xg5xqpLE/11HmCcw8s9Csm4WknUQcW2JZQtfM0PYmhL7u5ez YIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6RXm5miV5qSukmRlBwc0ry7mD8 d9frEKMAB6MSD+8KMZZoIdbEsuLK3EOMkhxMSqK8YU+Zo4X4kvJTKjMSizPii0pzUosPMUpw MCuJ8H66xBQtxJuSWFmVWpQPk5LmYFES581exBgtJJCeWJKanZpakFoEk5Xh4FCS4A3XBNoj WJSanlqRlplTgpBm4uAEGc4DNHyvBlANb3FBYm5xZjpE/hSjK8eyJ/09zByH3k8BkufA5J0D U4HkscvTepiFWPLy81KlxHn7QZoFQJozSvPg5oOSmPs6O4tXjOJA7wrzbgCp4gEmQLgNr4CW MwEtv7icGWR5SSJCSqqB8fSBtUdU9Tf6/TitZXn6X0wkz4J3/RNUrrxLNpquYmy3OXDLtd0Z xmrN5at+rHu3ouvjMhUua81XB7hOLTiu2izLLHy5ddGEzkUVnwvEP2yfxOY55VFnxF45FxNu h0dLnv9YLB9ib1CeL+k2dc8j09tGUxNUkyy1Zh2qEN7OyqVkbXNu1/z/6kosxRmJhlrMRcWJ AKWejPE9AwAA Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 14:33:35 -0000 --Apple-Mail=_C064A021-58FD-46F7-91EC-C61C62E0C06D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In that specific case, the token_type_hint value is invalid and can be = rejected as an invalid_request. =E2=80=94 Justin > On May 22, 2018, at 5:27 AM, Joseph Heenan = wrote: >=20 >=20 > I think one important point Sergey raised was that the response to the = client from submitting the wrong token is the same 200 response as = submitting a valid token, and that hugely increases the chance that the = developer of the client app might submit the wrong token and never = realise. Making it easier for the developer of the client app to see = that they've done something wrong and need to fix their implementation = seems like a worthwhile goal to me, and that would appear to explain = what google are thinking with their responses. >=20 > An example of an easy to make error that would get a 200 response is = getting the values the wrong way around, i.e. a body of: >=20 > token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz >=20 > (as token_type_hint may be ignored by the server.) >=20 > The example Sergey gave of the developer accidentally sending the id = token instead of the intended token seems quite likely to happen in the = real world too, and a 200 response in that case does seem wrong to me. >=20 >=20 > Joseph >=20 >=20 >> On 21 May 2018, at 22:29, Justin Richer > wrote: >>=20 >> I=E2=80=99m with George here: revocation is almost a best-effort = request from the client=E2=80=99s perspective. It sends a message to the = server saying =E2=80=9Chey I=E2=80=99m done with this token, you can = throw it out too=E2=80=9D. If the server does revoke the token, the = client throws it out. If the server doesn=E2=80=99t revoke the token? = Then the client still throws it out. Either way the results from the = client=E2=80=99s perspective are the same: it=E2=80=99s already decided = that it=E2=80=99s done with the token before it talks to the server. = It=E2=80=99s an optional cleanup step in most OAuth systems. >>=20 >> =E2=80=94 Justin >>=20 >>> On May 21, 2018, at 5:08 PM, George Fletcher = > wrote: >>>=20 >>> I'm not understanding how these different cases matter to the = client? I doubt that the running code will be able to dynamically handle = the error. So it seems this information is only relevant to the = developers and not relevant from an end user and the client perspective. >>>=20 >>> Also, for the 5 states you define, the effect of calling revocation = is still that the token is "revoked" because the token is already not = valid. >>>=20 >>> So from an implementation perspective, where is the concern that = developer will do the "wrong thing" without these more detailed error = responses? >>>=20 >>> Thanks, >>> George >>>=20 >>> On 5/19/18 5:41 PM, Sergey Ponomarev wrote: >>>> Hi, >>>>=20 >>>> I developing an implementation of back channel token revocation = endpoint. And I think we should reconsider and probably change the = specification to improve error handling. >>>>=20 >>>> Here we see several situations of error state: >>>> 1. token wasn't sent in request. >>>> 2. token is invalid by format i.e. not JWT or JWT with invalid = signature >>>> 3. token is expired or token is even unknown >>>> 4. token was already revoked >>>> 5. token type is unsupported=20 >>>>=20 >>>> According to RFC7009 OAuth 2.0 Token Revocation = section 2.2 Revocation Response: >>>>=20 >>>> The authorization server responds with HTTP status code 200 if the = token has been revoked successfully or if the client submitted an = invalid token. >>>> Note: invalid tokens do not cause an error response since the = client cannot handle such an error in a reasonable way. Moreover, the = purpose of the revocation request, invalidating the particular token, is = already achieved.. >>>>=20 >>>> As you may see this section covers only case 3 and case 4 but it's = very unclear: calling token as "invalid" is very broad definition. >>>> I think we should take a look on each case separately: >>>>=20 >>>> 1. token wasn't sent in request.=20 >>>> Most implementations returns 400 status code, error: = "invalid_request", error_description": "Missing required parameter: = token". >>>> Note that returned error is not "invalid_token" but = "invalid_request" and I think this should be correct behavior and should = be clearly specified. >>>>=20 >>>> 2. token is invalid by format i.e. not JWT or JWT with invalid = signature >>>> This error is mostly related to JWT but for reference (opaque) = tokens can be also applied (e.g. token is too long). >>>> Goolge OAuth returns 400 code with "error": "invalid_token" and I = think this is correct behavior. >>>> The client can have a bug and sends invalid tokens so we should = return an error response instead of 200 status. >>>>=20 >>>> 3. token is expired or even unknown >>>> Spec says that IdP should return 200 in this case but in case of = unknown token this may be a symptom of a bug on client side. Even if IdP = can clearly determine that token is expired (in case of JWT) this is = hard to determine in case of reference token that was removed from DB. >>>> So personally I think that from security perspective it's better to = response with 400 status because client can have a bug when it's sends = some unknown token and think that it was revoked while it wasn't. >>>>=20 >>>> For example Google OAuth revocation endpoint implementation do not = follow the spec and returns 400 Bad Request with error message "Token is = revoked or expired". >>>>=20 >>>> 4. token was already revoked >>>> The same as above: this can be a bug in a client and we should = return 400 status. In case of reference token which was removed from DB = we can't distinguish that the token was revoked or even existed so this = situation is the same as unknown token. >>>>=20 >>>> 5. token type is unsupported=20 >>>> For this case specification introduces a new error code for case 5 = in section 2.2.1. Error Response : >>>> unsupported_token_type: The authorization server does not support = the revocation of the presented token type. That is, the client tried = to revoke an access token on a server not supporting this feature.=20 >>>> But it would be better to mention that revocation of ID token = (which can be is considered as "public" and not used to auth) definitely = should cause this error. >>>>=20 >>>> It would be great if we discuss this cases and improve = specification. >>>>=20 >>>> P.S. Also it may be worse to mention that specification says that = content of successful response is empty but status code is 200 instead = of 201 "No Content". >>>>=20 >>>> Regards, >>>> Sergey=C2=A0Ponomarev >>>>=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 >> _______________________________________________ >> 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=_C064A021-58FD-46F7-91EC-C61C62E0C06D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = that specific case, the token_type_hint value is invalid and can be = rejected as an invalid_request.

 =E2=80=94 Justin

On May = 22, 2018, at 5:27 AM, Joseph Heenan <joseph@authlete.com>= wrote:


I think one important point Sergey raised was that the = response to the client from submitting the wrong token is the same 200 = response as submitting a valid token, and that hugely increases the = chance that the developer of the client app might submit the wrong token = and never realise. Making it easier for the developer of the client app = to see that they've done something wrong and need to fix their = implementation seems like a worthwhile goal to me, and that would appear = to explain what google are thinking with their responses.

An example of an easy to = make error that would get a 200 response is getting the values the wrong = way around, i.e. a body of:

    =  token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz
(as token_type_hint may be = ignored by the server.)

The example Sergey gave of the developer accidentally sending = the id token instead of the intended token seems quite likely to happen = in the real world too, and a 200 response in that case does seem wrong = to me.


Joseph


On 21 May 2018, at 22:29, Justin Richer = <jricher@mit.edu> = wrote:

I=E2=80=99m with George here: revocation = is almost a best-effort request from the client=E2=80=99s perspective. = It sends a message to the server saying =E2=80=9Chey I=E2=80=99m done = with this token, you can throw it out too=E2=80=9D. If the server does = revoke the token, the client throws it out. If the server doesn=E2=80=99t = revoke the token? Then the client still throws it out. Either way the = results from the client=E2=80=99s perspective are the same: it=E2=80=99s = already decided that it=E2=80=99s done with the token before it talks to = the server. It=E2=80=99s an optional cleanup step in most  OAuth = systems.

 =E2=80=94= Justin

On May 21, 2018, at 5:08 PM, = George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20
I'm not = understanding how these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.
=
Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more detailed error responses?

Thanks,
George

On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel = token revocation endpoint. And I think we should reconsider and probably change the specification to improve error = handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with = invalid signature
3. token is expired or token is even unknown
4. token was already revoked
5. token type is unsupported 

According to  RFC7009 OAuth 2.0 Token Revocation  section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.  Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 = and case 4 but it's very unclear: calling token as "invalid" is very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request. 
Most implementations returns 400 status code, error: "invalid_request", error_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with  "error": = "invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it was revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported 
For this case specification introduces a new = error code for case 5 in section 2.2.1. Error Response :
unsupported_token_type:  The authorization server does not support the revocation of the presented token type.  That is, the client tried to = revoke an access token on a server not   supporting this = feature. 
But it would be better to mention that = revocation of ID token (which can be is considered as "public" and not used to auth) definitely should cause this error.

It would be great if we discuss this cases and = improve specification.

P.S. Also it may be worse to mention that = specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey Ponomarev


_______________________________________________
OAuth mailing 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=_C064A021-58FD-46F7-91EC-C61C62E0C06D-- From nobody Tue May 22 07:50: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 6C2ED12EB56 for ; Tue, 22 May 2018 07:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 O1fKegUK_e_4 for ; Tue, 22 May 2018 07:50:50 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 4F8401270AC for ; Tue, 22 May 2018 07:50:50 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id k17-v6so16455763oih.5 for ; Tue, 22 May 2018 07:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9jkVhshoQcPikj7sUjvMS8eFKgujtEwygNkHpwP5PGs=; b=g47rmeiEjqSINYT5wQRphHjCdxOEr+mQingXDG8VjPhX02uscoegfsBEOouWx6LM3x O9ILn1nifBYLQvAJYpL/NroT7X86IWnJ//uXXhLxD4heWlB4Q4y3aBTp3qvv5JfrfP/9 zCREJFIttyAJ7ncJjtr6qsruX7aEIHArAiFiZnNVwa1MjpeffH0A4WBAQG2hBCLuoTjW rATvn9AVeUiU27UpzApc1RJFPYdpv0Ri5UTSLQTXQi+AiS5BOfi4MDbgPJUHOvCdHD5c M5Jnr8u5SXim9hRZaPYXKeRI+XXquJsOtDNfe2Jdhx7o+t/CLbBAU2DdQgMUH8tU02gq oGCQ== 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=9jkVhshoQcPikj7sUjvMS8eFKgujtEwygNkHpwP5PGs=; b=NUPO6kKrU78vJzW/fbIGss4vmQc++aq2bHv4EsrnHSju8toV+866NAoH7U0gKJ4VOS Hgrzqf0TlYMHq2T/TlfMU1ABpJMb+qlw0ZNWMHVgoYtxmQbS+lxx3ffZ/lNWH9Ftj1OU ngvS0PRCW0uB5Uk8lx0pYKQMyT2gjvCIfGz2pZ2E9tePAdPYqmLJ4C+FM2GPYwRcGhPX GSCvKoA+qyMKo++Js/dBNMSFJVuZnEysJcfCXzr9q0sAYfyyLc5Ii+ZnFHVcsQSkNkHD TpYNlxO0sHQsG4AatUpN3XqDh+3v506sUT3sLX8bzIzIOojxmWrVvE3pSW+KoewGghWx laLw== X-Gm-Message-State: ALKqPwcfjvoU+OcdKdhvmbDa8hZzWegSuC573gibDtmPJnHQDUWRzEXj wfKgoKId3FwJuQmNbnioiV58HhymTL48FZHZ+bk= X-Google-Smtp-Source: AB8JxZrF8T7Xsqymqtr2z6LIMiurxguPw2vGHelkGmAXl0HrMaI+tEVeKVHMA5zpaPLEVAluzKvqIgMQGEa172lfYzg= X-Received: by 2002:aca:2c3:: with SMTP id 186-v6mr13358700oic.340.1527000649620; Tue, 22 May 2018 07:50:49 -0700 (PDT) MIME-Version: 1.0 References: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> <1241C308-15BA-4235-85B8-5B12E1E4B248@mit.edu> In-Reply-To: <1241C308-15BA-4235-85B8-5B12E1E4B248@mit.edu> From: Thomas Broyer Date: Tue, 22 May 2018 16:50:38 +0200 Message-ID: To: Justin Richer Cc: Joseph Heenan , "" Content-Type: multipart/alternative; boundary="0000000000004ae149056ccc8b72" Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 14:50:54 -0000 --0000000000004ae149056ccc8b72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IFF the server processes it! RFC 7009 says =E2=80=9CAn authorization server MAY ignore this parameter, particularly if it is able to detect the token type automatically.=E2=80=9D= which BTW is exactly my case. For months, my AS received requests with token=3DArray, and now receives requests with token=3Dnull. Those are clearly bugs in the client code, and because I return a 200 OK, the developers aren't aware of it. If tokens have an expected "structure", I think AS should probably return an error when the token value clearly is not a token (at one point I may change my implementation to do just that). As soon as it looks like a potential token though, then 200 OK sounds good to me. On Tue, May 22, 2018 at 4:34 PM Justin Richer wrote: > In that specific case, the token_type_hint value is invalid and can be > rejected as an invalid_request. > > =E2=80=94 Justin > > > On May 22, 2018, at 5:27 AM, Joseph Heenan wrote: > > > I think one important point Sergey raised was that the response to the > client from submitting the wrong token is the same 200 response as > submitting a valid token, and that hugely increases the chance that the > developer of the client app might submit the wrong token and never realis= e. > Making it easier for the developer of the client app to see that they've > done something wrong and need to fix their implementation seems like a > worthwhile goal to me, and that would appear to explain what google are > thinking with their responses. > > An example of an easy to make error that would get a 200 response is > getting the values the wrong way around, i.e. a body of: > > token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz > > (as token_type_hint may be ignored by the server.) > > The example Sergey gave of the developer accidentally sending the id toke= n > instead of the intended token seems quite likely to happen in the real > world too, and a 200 response in that case does seem wrong to me. > > > Joseph > > > On 21 May 2018, at 22:29, Justin Richer wrote: > > I=E2=80=99m with George here: revocation is almost a best-effort request = from the > client=E2=80=99s perspective. It sends a message to the server saying =E2= =80=9Chey I=E2=80=99m done > with this token, you can throw it out too=E2=80=9D. If the server does re= voke the > token, the client throws it out. If the server doesn=E2=80=99t revoke the= token? > Then the client still throws it out. Either way the results from the > client=E2=80=99s perspective are the same: it=E2=80=99s already decided t= hat it=E2=80=99s done with > the token before it talks to the server. It=E2=80=99s an optional cleanup= step in > most OAuth systems. > > =E2=80=94 Justin > > On May 21, 2018, at 5:08 PM, George Fletcher < > gffletch=3D40aol.com@dmarc.ietf.org> wrote: > > I'm not understanding how these different cases matter to the client? I > doubt that the running code will be able to dynamically handle the error. > So it seems this information is only relevant to the developers and not > relevant from an end user and the client perspective. > > Also, for the 5 states you define, the effect of calling revocation is > still that the token is "revoked" because the token is already not valid. > > So from an implementation perspective, where is the concern that develope= r > will do the "wrong thing" without these more detailed error responses? > > Thanks, > George > > On 5/19/18 5:41 PM, Sergey Ponomarev wrote: > > Hi, > > I developing an implementation of back channel token revocation endpoint. > And I think we should reconsider and probably change the specification to > improve error handling. > > Here we see several situations of error state: > 1. token wasn't sent in request. > 2. token is invalid by format i.e. not JWT or JWT with invalid signature > 3. token is expired or token is even unknown > 4. token was already revoked > 5. token type is unsupported > > According to RFC7009 OAuth 2.0 Token Revocation > section 2.2 Revocation Response: > > The authorization server responds with HTTP status code 200 if the token >> has been revoked successfully or if the client submitted an invalid toke= n. >> Note: invalid tokens do not cause an error response since the client >> cannot handle such an error in a reasonable way. Moreover, the purpose = of >> the revocation request, invalidating the particular token, is already >> achieved.. > > > As you may see this section covers only case 3 and case 4 but it's very > unclear: calling token as "invalid" is very broad definition. > I think we should take a look on each case separately: > > 1. token wasn't sent in request. > Most implementations returns 400 status code, error: "invalid_request", e= rror_description": > "Missing required parameter: token". > Note that returned error is not "invalid_token" but "invalid_request" and > I think this should be correct behavior and should be clearly specified. > > 2. token is invalid by format i.e. not JWT or JWT with invalid signature > This error is mostly related to JWT but for reference (opaque) tokens can > be also applied (e.g. token is too long). > Goolge OAuth returns 400 code with "error": "invalid_token" and I think > this is correct behavior. > The client can have a bug and sends invalid tokens so we should return an > error response instead of 200 status. > > 3. token is expired or even unknown > Spec says that IdP should return 200 in this case but in case of unknown > token this may be a symptom of a bug on client side. Even if IdP can > clearly determine that token is expired (in case of JWT) this is hard to > determine in case of reference token that was removed from DB. > So personally I think that from security perspective it's better to > response with 400 status because client can have a bug when it's sends so= me > unknown token and think that it was revoked while it wasn't. > > For example Google OAuth revocation endpoint implementation do not follow > the spec and returns 400 Bad Request with error message "Token is revoked > or expired". > > 4. token was already revoked > The same as above: this can be a bug in a client and we should return 400 > status. In case of reference token which was removed from DB we can't > distinguish that the token was revoked or even existed so this situation = is > the same as unknown token. > > 5. token type is unsupported > For this case specification introduces a new error code for case 5 in > section 2.2.1. Error Response : > >> unsupported_token_type: The authorization server does not support the >> revocation of the presented token type. That is, the client tried to >> revoke an access token on a server not supporting this feature. > > But it would be better to mention that revocation of ID token (which can > be is considered as "public" and not used to auth) definitely should caus= e > this error. > > It would be great if we discuss this cases and improve specification. > > P.S. Also it may be worse to mention that specification says that content > of successful response is empty but status code is 200 instead of 201 "No > Content". > > Regards, > Sergey Ponomarev > > > _______________________________________________ > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000004ae149056ccc8b72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IFF the server processes it!
RFC 7009 says =E2=80=9CAn= authorization server MAY ignore this parameter, particularly if it is able= to detect the token type automatically.=E2=80=9D which BTW is exactly my c= ase.

For months, my AS received requests with toke= n=3DArray, and now receives requests with token=3Dnull. Those are clearly b= ugs in the client code, and because I return a 200 OK, the developers aren&= #39;t aware of it.

If tokens have an expected &quo= t;structure", I think AS should probably return an error when the toke= n value clearly is not a token (at one point I may change my implementation= to do just that). As soon as it looks like a potential token though, then = 200 OK sounds good to me.

On Tue, May 22, 2018 at 4:34 PM Justin Richer <jricher@mit.edu> wrote:
In that specific case, the token_type_hint value is invalid and can b= e rejected as an invalid_request.

=C2=A0=E2=80=94= Justin


On May 22, 2018, = at 5:27 AM, Joseph Heenan <joseph@authlete.com> wrote:


I= think one important point Sergey raised was that the response to the clien= t from submitting the wrong token is the same 200 response as submitting a = valid token, and that hugely increases the chance that the developer of the= client app might submit the wrong token and never realise. Making it easie= r for the developer of the client app to see that they've done somethin= g wrong and need to fix their implementation seems like a worthwhile goal t= o me, and that would appear to explain what google are thinking with their = responses.

An example of an easy to make error tha= t would get a 200 response is getting the values the wrong way around, i.e.= a body of:

=C2=A0 =C2=A0 =C2=A0token=3Drefre= sh_token&token_type_hint=3D45ghiukldjahdnhzdauz

(as= token_type_hint may be ignored by the server.)

Th= e example Sergey gave of the developer accidentally sending the id token in= stead of the intended token seems quite likely to happen in the real world = too, and a 200 response in that case does seem wrong to me.

<= /div>

Joseph


On 21 May 2018, at 22:29, Justin Richer <jricher@mit.edu> wrote:
=
I=E2=80=99m with Ge= orge here: revocation is almost a best-effort request from the client=E2=80= =99s perspective. It sends a message to the server saying =E2=80=9Chey I=E2= =80=99m done with this token, you can throw it out too=E2=80=9D. If the ser= ver does revoke the token, the client throws it out. If the server doesn=E2= =80=99t revoke the token? Then the client still throws it out. Either way t= he results from the client=E2=80=99s perspective are the same: it=E2=80=99s= already decided that it=E2=80=99s done with the token before it talks to t= he server. It=E2=80=99s an optional cleanup step in most =C2=A0OAuth system= s.

=C2=A0=E2=80=94 Justin

On May 21, 2018, at 5:08 PM, George Fletcher <gffletch=3D40= aol.com@dmarc.ietf.org> wrote:

=20
I'm not understanding h= ow these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.

Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the= token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more deta= iled error responses?

Thanks,
George

On 5/19/18 5:41 PM,= Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel token revocation endpoint. And I think we should reconsider and probably change the specification to improve error handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with invalid=C2= =A0signature
3. token is expired or token is even=C2= =A0unknown
4. token was already revoked
5. token type is unsupported=C2=A0

According to=C2=A0 RFC7009 OAuth 2.0 Token Revocation=C2=A0 section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.=C2=A0 Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 and case 4 but it's very unclear: calling token as "invalid" i= s very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request.=C2=A0
Most implementations returns 400 status code,=C2=A0error:=C2=A0"= invalid_request",=C2=A0er= ror_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid=C2=A0signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with=C2=A0=C2=A0"error": "= ;invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it wa= s revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported=C2=A0
For this case specification introduces a new error code for case 5 in section 2.2.1. Error Response=C2=A0:
unsupported_token= _type:=C2=A0 The authorization server does not support the revocation of the presented token type.=C2=A0 That is, the client tried to revo= ke an access token on a server not=C2=A0 =C2=A0supporting this featu= re.=C2=A0
But it would be better to mention that revocation of ID token (which can be is considered as "public" and not u= sed to auth) definitely should cause this error.

It would be great if we discuss this cases and improve specification.

P.S. Also it may be worse to mention that specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey=C2=A0P= onomarev


_______________________________________________
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 maili= ng list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth

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

__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000004ae149056ccc8b72-- From nobody Tue May 22 08:19: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 EEEF212711D for ; Tue, 22 May 2018 08:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 aYlAtsGox77P for ; Tue, 22 May 2018 08:19:24 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 5374412762F for ; Tue, 22 May 2018 08:19:23 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id t1-v6so21367810ott.13 for ; Tue, 22 May 2018 08:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QbA3ZhVw+YmL1QgMT2DigsgNnJzpqTGwN7gLmGvfRBs=; b=TtERmdjCGG4VBfk2BFcs4J2TtUshqQUf8BgxAHymx4moFkXzL4kkche7/ni8U3yzZN 0QZDiHIsNdi0+EAZ+THOkHIRvWtJV9StShOVYoVw6Tt54yECutjJ6mO2aaOMecy5mu1Y /eWg/1wwwqKfv8FOS6YFk5kkMIsr5DKXRYqh2wHK7atCNsMaGho0g1QTacQClwig9thz PnT3nqLqpuUNbDgO91chKkuxPNOVXjPgLd0jTRm/AoJVTqwaUOarX+ik+JmMeC3ckd9x cvOZ9ooNp0kGVCPRmmhieFNfAZQKwNklQDue1pgrgG6C9xjcaz7W1JvuG6nPnrSiJLiQ WeWw== 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=QbA3ZhVw+YmL1QgMT2DigsgNnJzpqTGwN7gLmGvfRBs=; b=PU5i8okW3Li09VJbtXz0N21Q4KJbDMRB1CMChlnRk3dcT6z6cVbURQLkgaQNhfSeMS oXCQyfCFcV0W3xfbDqRFG68luvAzT2kF8dG/OWIYpEkFZLOFla5tJxX16hz43lxqJsoa pTperYx3r5UXShng2J89oRccIndCxAsZb/EZEuormSHanriGcrVvh6+dCVyM/s28wY7f pqr1LI/XqCgpY15xnTrT163rZDcWizuIaF3wkKgHjaFg3Pa0Qh0pXuZFlTh0mkjulp9S 7xFKVrUAdLsrHhZ5sWC4K/aFQsLUc2USkP8P6Ay+K/wJ3q5y67HK3SSOdUlfLABHmydq vySw== X-Gm-Message-State: ALKqPweOcJ5qmeaxwwE5JgVEM8c2TmEdTq0prhgNGANCFV0+uQdRKK9E S2voNHBgMMKJmQbSHFViVgxt3O15Pjrtm9wkeLQ= X-Google-Smtp-Source: AB8JxZrgIw74JwdKJhU9q5ErGRr5YH9VIJM+O/QHhfaDKBoZ7dJuKlxRQBPpBe3HOS/DENEhonnYt1N5xwooBQwt6p8= X-Received: by 2002:a9d:cc8:: with SMTP id o8-v6mr16830008otd.86.1527002362484; Tue, 22 May 2018 08:19:22 -0700 (PDT) MIME-Version: 1.0 References: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> <1241C308-15BA-4235-85B8-5B12E1E4B248@mit.edu> In-Reply-To: From: Sergey Ponomarev Date: Tue, 22 May 2018 18:18:46 +0300 Message-ID: To: t.broyer@gmail.com Cc: jricher@mit.edu, oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000631d04056cccf1ea" Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 15:19:28 -0000 --000000000000631d04056cccf1ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From OAuth perspective we can't say that the token should have some structure: they can be any random value in case of reference (opaque) tokens. But the Google's OAuth Server responds in this case with 400 error "invalid_token". The same can be used for JWTs with invalid sign or issuer. So it would be better if specification allow OAuth servers to respond with this error code if it clearly know that token was invalid by format. On Tue, 22 May 2018 at 17:51, Thomas Broyer wrote: > IFF the server processes it! > RFC 7009 says =E2=80=9CAn authorization server MAY ignore this parameter, > particularly if it is able to detect the token type automatically.=E2=80= =9D which > BTW is exactly my case. > > For months, my AS received requests with token=3DArray, and now receives > requests with token=3Dnull. Those are clearly bugs in the client code, an= d > because I return a 200 OK, the developers aren't aware of it. > > If tokens have an expected "structure", I think AS should probably return > an error when the token value clearly is not a token (at one point I may > change my implementation to do just that). As soon as it looks like a > potential token though, then 200 OK sounds good to me. > > On Tue, May 22, 2018 at 4:34 PM Justin Richer wrote: > >> In that specific case, the token_type_hint value is invalid and can be >> rejected as an invalid_request. >> >> =E2=80=94 Justin >> >> >> On May 22, 2018, at 5:27 AM, Joseph Heenan wrote: >> >> >> I think one important point Sergey raised was that the response to the >> client from submitting the wrong token is the same 200 response as >> submitting a valid token, and that hugely increases the chance that the >> developer of the client app might submit the wrong token and never reali= se. >> Making it easier for the developer of the client app to see that they've >> done something wrong and need to fix their implementation seems like a >> worthwhile goal to me, and that would appear to explain what google are >> thinking with their responses. >> >> An example of an easy to make error that would get a 200 response is >> getting the values the wrong way around, i.e. a body of: >> >> token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz >> >> (as token_type_hint may be ignored by the server.) >> >> The example Sergey gave of the developer accidentally sending the id >> token instead of the intended token seems quite likely to happen in the >> real world too, and a 200 response in that case does seem wrong to me. >> >> >> Joseph >> >> >> On 21 May 2018, at 22:29, Justin Richer wrote: >> >> I=E2=80=99m with George here: revocation is almost a best-effort request= from the >> client=E2=80=99s perspective. It sends a message to the server saying = =E2=80=9Chey I=E2=80=99m done >> with this token, you can throw it out too=E2=80=9D. If the server does r= evoke the >> token, the client throws it out. If the server doesn=E2=80=99t revoke th= e token? >> Then the client still throws it out. Either way the results from the >> client=E2=80=99s perspective are the same: it=E2=80=99s already decided = that it=E2=80=99s done with >> the token before it talks to the server. It=E2=80=99s an optional cleanu= p step in >> most OAuth systems. >> >> =E2=80=94 Justin >> >> On May 21, 2018, at 5:08 PM, George Fletcher < >> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >> >> I'm not understanding how these different cases matter to the client? I >> doubt that the running code will be able to dynamically handle the error= . >> So it seems this information is only relevant to the developers and not >> relevant from an end user and the client perspective. >> >> Also, for the 5 states you define, the effect of calling revocation is >> still that the token is "revoked" because the token is already not valid= . >> >> So from an implementation perspective, where is the concern that >> developer will do the "wrong thing" without these more detailed error >> responses? >> >> Thanks, >> George >> >> On 5/19/18 5:41 PM, Sergey Ponomarev wrote: >> >> Hi, >> >> I developing an implementation of back channel token revocation endpoint= . >> And I think we should reconsider and probably change the specification t= o >> improve error handling. >> >> Here we see several situations of error state: >> 1. token wasn't sent in request. >> 2. token is invalid by format i.e. not JWT or JWT with invalid signature >> 3. token is expired or token is even unknown >> 4. token was already revoked >> 5. token type is unsupported >> >> According to RFC7009 OAuth 2.0 Token Revocation >> section 2.2 Revocation Response: >> >> The authorization server responds with HTTP status code 200 if the token >>> has been revoked successfully or if the client submitted an invalid tok= en. >>> Note: invalid tokens do not cause an error response since the client >>> cannot handle such an error in a reasonable way. Moreover, the purpose= of >>> the revocation request, invalidating the particular token, is already >>> achieved.. >> >> >> As you may see this section covers only case 3 and case 4 but it's very >> unclear: calling token as "invalid" is very broad definition. >> I think we should take a look on each case separately: >> >> 1. token wasn't sent in request. >> Most implementations returns 400 status code, error: "invalid_request", = error_description": >> "Missing required parameter: token". >> Note that returned error is not "invalid_token" but "invalid_request" an= d >> I think this should be correct behavior and should be clearly specified. >> >> 2. token is invalid by format i.e. not JWT or JWT with invalid signature >> This error is mostly related to JWT but for reference (opaque) tokens ca= n >> be also applied (e.g. token is too long). >> Goolge OAuth returns 400 code with "error": "invalid_token" and I think >> this is correct behavior. >> The client can have a bug and sends invalid tokens so we should return a= n >> error response instead of 200 status. >> >> 3. token is expired or even unknown >> Spec says that IdP should return 200 in this case but in case of unknown >> token this may be a symptom of a bug on client side. Even if IdP can >> clearly determine that token is expired (in case of JWT) this is hard to >> determine in case of reference token that was removed from DB. >> So personally I think that from security perspective it's better to >> response with 400 status because client can have a bug when it's sends s= ome >> unknown token and think that it was revoked while it wasn't. >> >> For example Google OAuth revocation endpoint implementation do not follo= w >> the spec and returns 400 Bad Request with error message "Token is revoke= d >> or expired". >> >> 4. token was already revoked >> The same as above: this can be a bug in a client and we should return 40= 0 >> status. In case of reference token which was removed from DB we can't >> distinguish that the token was revoked or even existed so this situation= is >> the same as unknown token. >> >> 5. token type is unsupported >> For this case specification introduces a new error code for case 5 in >> section 2.2.1. Error Response : >> >>> unsupported_token_type: The authorization server does not support the >>> revocation of the presented token type. That is, the client tried to >>> revoke an access token on a server not supporting this feature. >> >> But it would be better to mention that revocation of ID token (which can >> be is considered as "public" and not used to auth) definitely should cau= se >> this error. >> >> It would be great if we discuss this cases and improve specification. >> >> P.S. Also it may be worse to mention that specification says that conten= t >> of successful response is empty but status code is 200 instead of 201 "N= o >> Content". >> >> Regards, >> Sergey Ponomarev >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing 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 Sergey Ponomarev , skype:stokito --000000000000631d04056cccf1ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From OAuth perspective we can't say that the token sho= uld have some structure: they can be any random value in case of reference = (opaque) tokens. But the Google's OAuth Server responds in this case wi= th 400 error "invalid_token".
The same can be used for JWTs w= ith invalid sign or issuer.
So it would be better if specification = allow OAuth servers to respond with this error code if it clearly know that= token was invalid by format.

On Tue, 22 May 2018 at 17:51, Thomas Broyer <t.broyer@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
IFF the server processes it!=
RFC 7009 says =E2=80=9CAn authorization server MAY ignore this paramet= er, particularly if it is able to detect the token type automatically.=E2= =80=9D which BTW is exactly my case.

For months, m= y AS received requests with token=3DArray, and now receives requests with t= oken=3Dnull. Those are clearly bugs in the client code, and because I retur= n a 200 OK, the developers aren't aware of it.

If tokens have an expected "structure", I think AS should probab= ly return an error when the token value clearly is not a token (at one poin= t I may change my implementation to do just that). As soon as it looks like= a potential token though, then 200 OK sounds good to me.

On Tue, May 22, 2018 at 4:34 PM J= ustin Richer <jrich= er@mit.edu> wrote:
In that specific c= ase, the token_type_hint value is invalid and can be rejected as an invalid= _request.

=C2=A0=E2=80=94 Justin

<= br>
On May 22, 2018, at 5:27 AM, Joseph Heena= n <joseph@authl= ete.com> wrote:


I= think one important point Sergey raised was that the response to the clien= t from submitting the wrong token is the same 200 response as submitting a = valid token, and that hugely increases the chance that the developer of the= client app might submit the wrong token and never realise. Making it easie= r for the developer of the client app to see that they've done somethin= g wrong and need to fix their implementation seems like a worthwhile goal t= o me, and that would appear to explain what google are thinking with their = responses.

An example of an easy to make error tha= t would get a 200 response is getting the values the wrong way around, i.e.= a body of:

=C2=A0 =C2=A0 =C2=A0token=3Drefre= sh_token&token_type_hint=3D45ghiukldjahdnhzdauz

(as= token_type_hint may be ignored by the server.)

Th= e example Sergey gave of the developer accidentally sending the id token in= stead of the intended token seems quite likely to happen in the real world = too, and a 200 response in that case does seem wrong to me.

<= /div>

Joseph


On 21 May 2018, at 22:29, Justin Richer <jricher@mit.edu> wrote:
=
I=E2=80=99m with George here: revocation is almost a best-effort request= from the client=E2=80=99s perspective. It sends a message to the server sa= ying =E2=80=9Chey I=E2=80=99m done with this token, you can throw it out to= o=E2=80=9D. If the server does revoke the token, the client throws it out. = If the server doesn=E2=80=99t revoke the token? Then the client still throw= s it out. Either way the results from the client=E2=80=99s perspective are = the same: it=E2=80=99s already decided that it=E2=80=99s done with the toke= n before it talks to the server. It=E2=80=99s an optional cleanup step in m= ost =C2=A0OAuth systems.

=C2=A0=E2=80=94 Justin
=
On May 21, 2018, at 5:08 PM, George Flet= cher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20
I'm not understanding h= ow these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.

Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the= token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more deta= iled error responses?

Thanks,
George

On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel token revocation endpoint. And I think we should reconsider and probably change the specification to improve error handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with invalid=C2= =A0signature
3. token is expired or token is even=C2= =A0unknown
4. token was already revoked
5. token type is unsupported=C2=A0

According to=C2=A0 RFC7009 OAuth 2.0 Token Revocation=C2=A0 section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.=C2=A0 Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 and case 4 but it's very unclear: calling token as "invalid" i= s very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request.=C2=A0
Most implementations returns 400 status code,=C2=A0error:=C2=A0"= invalid_request",=C2=A0er= ror_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid=C2=A0signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with=C2=A0=C2=A0"error": "= ;invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it wa= s revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported=C2=A0
For this case specification introduces a new error code for case 5 in section 2.2.1. Error Response=C2=A0:
unsupported_token= _type:=C2=A0 The authorization server does not support the revocation of the presented token type.=C2=A0 That is, the client tried to revo= ke an access token on a server not=C2=A0 =C2=A0supporting this featu= re.=C2=A0
But it would be better to mention that revocation of ID token (which can be is considered as "public" and not u= sed to auth) definitely should cause this error.

It would be great if we discuss this cases and improve specification.

P.S. Also it may be worse to mention that specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey=C2=A0Ponomarev


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth maili= ng list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAut= h mailing 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


--
--000000000000631d04056cccf1ea-- From nobody Tue May 22 10:30: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 F291212D7F6 for ; Tue, 22 May 2018 10:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 l-VVAQBFTw_j for ; Tue, 22 May 2018 10:30:30 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 18FB312E8CE for ; Tue, 22 May 2018 10:30:30 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id l12-v6so21924946oth.6 for ; Tue, 22 May 2018 10:30:30 -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=x1CG0V8gnJ9cSLGhuQRW393BUbxPPrMRPS7wVl6q8+g=; b=jKhHObyBxctXIZj0pfHkZM890oqlBk5wnYIdgPRyziIqdeRw+wkVQeLzUQ1q6oJQ6J T1An7qNHeBNSIpcxtW4K7RgYVQ2Q4b1UlO9mgd4+AJiQp5+t8o1Z/upE8hcF3iS3HUBR GIefaHwRoMP3oEQ6tGHcUC6F2ojMhOpM5CzruzFPuDoQwhYEZpuey2eW1jyBWuHEsZc8 Xyd7b7jP6TqIckwrr6HDYFD8oBPsDxmzMsB0a2OGi8KBKGLwf9h6C0DM3eRlpNL2wPGi hE7+nIdMj3iP9Lw7ACZ1ggTidC+VfcmQE3e0S89EH/Es14/OrZWkNyuH4kGySvlxTCvO y7sA== 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=x1CG0V8gnJ9cSLGhuQRW393BUbxPPrMRPS7wVl6q8+g=; b=FXMbkOw5Gtkt9JRoTagjeF4BqUTScPhzWpF7aMNE2vQ9CkyPGX0369yPfLtVAktbib 5TNhzYxzYxj56ZnHp4rx7z50W1xFuqr2Ni0dYu+NKOMxHAYdNpgSW8fgfkXaz11clZma mBuMYyyl4WTydOtQ1lrkDs81LBUTxu7afdMyyOoQjswP0wrClsmQcsNOaVqFXhtX3bio sfAFBe8ZYqZr1gY/VBQ9Ae4mGFPFVZVSGqwHdwr2dg598T2lBQ4QXlxKr8bPq1nxVVVi PcFCHTwXK/BkYUr06oDSw2tCgfArlr1NZgMY28Pzd+2sI/PsmNCNo209VUE52M3z8fv4 b5Wg== X-Gm-Message-State: ALKqPwcoHg3kXaXB3caWyg0DZHXXuXEquoC67cJettWKQRVz5grMe4WQ riqKPyA5/rMROfAFxYlIlpuSOHHAkHBN/54AjSI= X-Google-Smtp-Source: AB8JxZroE11XbsK4ED4ao/SPtLiAq+2drnUd5hZfAyaxffdo5oGsS4lDzo1+bi0X3QjmV8z8f/xNO1PlqtMRjQy21ZA= X-Received: by 2002:a9d:16d0:: with SMTP id s16-v6mr17537439ots.294.1527010229229; Tue, 22 May 2018 10:30:29 -0700 (PDT) MIME-Version: 1.0 References: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> <1241C308-15BA-4235-85B8-5B12E1E4B248@mit.edu> In-Reply-To: From: Sergey Ponomarev Date: Tue, 22 May 2018 20:29:52 +0300 Message-ID: To: Thomas Broyer Cc: Justin Richer , oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000481dfb056ccec621" Archived-At: Subject: Re: [OAUTH-WG] Token Revocation error codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 17:30:42 -0000 --000000000000481dfb056ccec621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is also should be discussed and specified is revoking of expired token. For example in Keycloak you can invalidate a session by expired token: > It should be possible to logout a session with a token that is expired. > This is to make sure that a user can invalidate a session if there's a > suspicion that the refresh/offline token has been leaked. In such a case = it > could be that the real user has an expired refresh token while an attacke= r > has been able to refresh the token and obtain a new not expired refresh > token. KEYCLOAK-3302 Think this is doubtful but makes sense. To summarize: we have to create some threat model with description of possible use cases. On Tue, 22 May 2018 at 18:18, Sergey Ponomarev wrote: > From OAuth perspective we can't say that the token should have some > structure: they can be any random value in case of reference (opaque) > tokens. But the Google's OAuth Server responds in this case with 400 erro= r > "invalid_token". > The same can be used for JWTs with invalid sign or issuer. > So it would be better if specification allow OAuth servers to respond wit= h > this error code if it clearly know that token was invalid by format. > > On Tue, 22 May 2018 at 17:51, Thomas Broyer wrote: > >> IFF the server processes it! >> RFC 7009 says =E2=80=9CAn authorization server MAY ignore this parameter= , >> particularly if it is able to detect the token type automatically.=E2=80= =9D which >> BTW is exactly my case. >> >> For months, my AS received requests with token=3DArray, and now receives >> requests with token=3Dnull. Those are clearly bugs in the client code, a= nd >> because I return a 200 OK, the developers aren't aware of it. >> >> If tokens have an expected "structure", I think AS should probably retur= n >> an error when the token value clearly is not a token (at one point I may >> change my implementation to do just that). As soon as it looks like a >> potential token though, then 200 OK sounds good to me. >> >> On Tue, May 22, 2018 at 4:34 PM Justin Richer wrote: >> >>> In that specific case, the token_type_hint value is invalid and can be >>> rejected as an invalid_request. >>> >>> =E2=80=94 Justin >>> >>> >>> On May 22, 2018, at 5:27 AM, Joseph Heenan wrote: >>> >>> >>> I think one important point Sergey raised was that the response to the >>> client from submitting the wrong token is the same 200 response as >>> submitting a valid token, and that hugely increases the chance that the >>> developer of the client app might submit the wrong token and never real= ise. >>> Making it easier for the developer of the client app to see that they'v= e >>> done something wrong and need to fix their implementation seems like a >>> worthwhile goal to me, and that would appear to explain what google are >>> thinking with their responses. >>> >>> An example of an easy to make error that would get a 200 response is >>> getting the values the wrong way around, i.e. a body of: >>> >>> token=3Drefresh_token&token_type_hint=3D45ghiukldjahdnhzdauz >>> >>> (as token_type_hint may be ignored by the server.) >>> >>> The example Sergey gave of the developer accidentally sending the id >>> token instead of the intended token seems quite likely to happen in the >>> real world too, and a 200 response in that case does seem wrong to me. >>> >>> >>> Joseph >>> >>> >>> On 21 May 2018, at 22:29, Justin Richer wrote: >>> >>> I=E2=80=99m with George here: revocation is almost a best-effort reques= t from >>> the client=E2=80=99s perspective. It sends a message to the server sayi= ng =E2=80=9Chey I=E2=80=99m >>> done with this token, you can throw it out too=E2=80=9D. If the server = does revoke >>> the token, the client throws it out. If the server doesn=E2=80=99t revo= ke the >>> token? Then the client still throws it out. Either way the results from= the >>> client=E2=80=99s perspective are the same: it=E2=80=99s already decided= that it=E2=80=99s done with >>> the token before it talks to the server. It=E2=80=99s an optional clean= up step in >>> most OAuth systems. >>> >>> =E2=80=94 Justin >>> >>> On May 21, 2018, at 5:08 PM, George Fletcher < >>> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >>> >>> I'm not understanding how these different cases matter to the client? I >>> doubt that the running code will be able to dynamically handle the erro= r. >>> So it seems this information is only relevant to the developers and not >>> relevant from an end user and the client perspective. >>> >>> Also, for the 5 states you define, the effect of calling revocation is >>> still that the token is "revoked" because the token is already not vali= d. >>> >>> So from an implementation perspective, where is the concern that >>> developer will do the "wrong thing" without these more detailed error >>> responses? >>> >>> Thanks, >>> George >>> >>> On 5/19/18 5:41 PM, Sergey Ponomarev wrote: >>> >>> Hi, >>> >>> I developing an implementation of back channel token revocation >>> endpoint. And I think we should reconsider and probably change the >>> specification to improve error handling. >>> >>> Here we see several situations of error state: >>> 1. token wasn't sent in request. >>> 2. token is invalid by format i.e. not JWT or JWT with invalid signatur= e >>> 3. token is expired or token is even unknown >>> 4. token was already revoked >>> 5. token type is unsupported >>> >>> According to RFC7009 OAuth 2.0 Token Revocation >>> section 2.2 Revocation Response: >>> >>> The authorization server responds with HTTP status code 200 if the toke= n >>>> has been revoked successfully or if the client submitted an invalid to= ken. >>>> Note: invalid tokens do not cause an error response since the client >>>> cannot handle such an error in a reasonable way. Moreover, the purpos= e of >>>> the revocation request, invalidating the particular token, is already >>>> achieved.. >>> >>> >>> As you may see this section covers only case 3 and case 4 but it's very >>> unclear: calling token as "invalid" is very broad definition. >>> I think we should take a look on each case separately: >>> >>> 1. token wasn't sent in request. >>> Most implementations returns 400 status code, error: "invalid_request",= error_description": >>> "Missing required parameter: token". >>> Note that returned error is not "invalid_token" but "invalid_request" >>> and I think this should be correct behavior and should be clearly speci= fied. >>> >>> 2. token is invalid by format i.e. not JWT or JWT with invalid signatur= e >>> This error is mostly related to JWT but for reference (opaque) tokens >>> can be also applied (e.g. token is too long). >>> Goolge OAuth returns 400 code with "error": "invalid_token" and I thin= k >>> this is correct behavior. >>> The client can have a bug and sends invalid tokens so we should return >>> an error response instead of 200 status. >>> >>> 3. token is expired or even unknown >>> Spec says that IdP should return 200 in this case but in case of unknow= n >>> token this may be a symptom of a bug on client side. Even if IdP can >>> clearly determine that token is expired (in case of JWT) this is hard t= o >>> determine in case of reference token that was removed from DB. >>> So personally I think that from security perspective it's better to >>> response with 400 status because client can have a bug when it's sends = some >>> unknown token and think that it was revoked while it wasn't. >>> >>> For example Google OAuth revocation endpoint implementation do not >>> follow the spec and returns 400 Bad Request with error message "Token i= s >>> revoked or expired". >>> >>> 4. token was already revoked >>> The same as above: this can be a bug in a client and we should return >>> 400 status. In case of reference token which was removed from DB we can= 't >>> distinguish that the token was revoked or even existed so this situatio= n is >>> the same as unknown token. >>> >>> 5. token type is unsupported >>> For this case specification introduces a new error code for case 5 in >>> section 2.2.1. Error Response : >>> >>>> unsupported_token_type: The authorization server does not support the >>>> revocation of the presented token type. That is, the client tried to >>>> revoke an access token on a server not supporting this feature. >>> >>> But it would be better to mention that revocation of ID token (which ca= n >>> be is considered as "public" and not used to auth) definitely should ca= use >>> this error. >>> >>> It would be great if we discuss this cases and improve specification. >>> >>> P.S. Also it may be worse to mention that specification says that >>> content of successful response is empty but status code is 200 instead = of >>> 201 "No Content". >>> >>> Regards, >>> Sergey Ponomarev >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Sergey Ponomarev , skype:stokito > --=20 Sergey Ponomarev , skype:stokito --000000000000481dfb056ccec621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is also should be discussed and specified is revoking= of expired token. For example in Keycloak you can invalidate a session by = expired token:
It should be possible to logout a session with a token t= hat is expired. This is to make sure that a user can invalidate a session i= f there's a suspicion that the refresh/offline token has been leaked. I= n such a case it could be that the real user has an expired refresh token w= hile an attacker has been able to refresh the token and obtain a new not ex= pired refresh token.

Think this is=C2=A0doubtful but makes sense.

To summarize: we have to create some threat model with= description of possible use cases.

On Tue, 22 May 2018 at 18:18, = Sergey Ponomarev <stokito@gmail.com= > wrote:
Fr= om OAuth perspective we can't say that the token should have some struc= ture: they can be any random value in case of reference (opaque) tokens. Bu= t the Google's OAuth Server responds in this case with 400 error "= invalid_token".
The same can be used for JWTs with invalid sign or= issuer.
So it would be better if specification allow OAuth servers= to respond with this error code if it clearly know that token was invalid = by format.

On Tue, 22 May 2018 at 17:51, Thomas Broyer <t.broyer@gmail.com> wrote:
IFF the server processes it!<= div>RFC 7009 says =E2=80=9CAn authorization server MAY ignore this paramete= r, particularly if it is able to detect the token type automatically.=E2=80= =9D which BTW is exactly my case.

For months, my A= S received requests with token=3DArray, and now receives requests with toke= n=3Dnull. Those are clearly bugs in the client code, and because I return a= 200 OK, the developers aren't aware of it.

If= tokens have an expected "structure", I think AS should probably = return an error when the token value clearly is not a token (at one point I= may change my implementation to do just that). As soon as it looks like a = potential token though, then 200 OK sounds good to me.

On Tue, May 22, 2018 at 4:34 PM Just= in Richer <jricher@= mit.edu> wrote:
In that specific cas= e, the token_type_hint value is invalid and can be rejected as an invalid_r= equest.

=C2=A0=E2=80=94 Justin

On May 22, 2018, at 5:27 AM, Joseph Heenan = <joseph@authlet= e.com> wrote:


I= think one important point Sergey raised was that the response to the clien= t from submitting the wrong token is the same 200 response as submitting a = valid token, and that hugely increases the chance that the developer of the= client app might submit the wrong token and never realise. Making it easie= r for the developer of the client app to see that they've done somethin= g wrong and need to fix their implementation seems like a worthwhile goal t= o me, and that would appear to explain what google are thinking with their = responses.

An example of an easy to make error tha= t would get a 200 response is getting the values the wrong way around, i.e.= a body of:

=C2=A0 =C2=A0 =C2=A0token=3Drefre= sh_token&token_type_hint=3D45ghiukldjahdnhzdauz

(as= token_type_hint may be ignored by the server.)

Th= e example Sergey gave of the developer accidentally sending the id token in= stead of the intended token seems quite likely to happen in the real world = too, and a 200 response in that case does seem wrong to me.

<= /div>

Joseph


On 21 May 2018, at 22:29, Justin Richer <jricher@mit.edu> wrote:
=
I=E2=80=99m with George here: revocation is almost = a best-effort request from the client=E2=80=99s perspective. It sends a mes= sage to the server saying =E2=80=9Chey I=E2=80=99m done with this token, yo= u can throw it out too=E2=80=9D. If the server does revoke the token, the c= lient throws it out. If the server doesn=E2=80=99t revoke the token? Then t= he client still throws it out. Either way the results from the client=E2=80= =99s perspective are the same: it=E2=80=99s already decided that it=E2=80= =99s done with the token before it talks to the server. It=E2=80=99s an opt= ional cleanup step in most =C2=A0OAuth systems.

=C2=A0= =E2=80=94 Justin

On May 21, 2018= , at 5:08 PM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>= wrote:

=20
I'm not understanding h= ow these different cases matter to the client? I doubt that the running code will be able to dynamically handle the error. So it seems this information is only relevant to the developers and not relevant from an end user and the client perspective.

Also, for the 5 states you define, the effect of calling revocation is still that the token is "revoked" because the= token is already not valid.

So from an implementation perspective, where is the concern that developer will do the "wrong thing" without these more deta= iled error responses?

Thanks,
George

On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
Hi,

I developing an implementation of back channel token revocation endpoint. And I think we should reconsider and probably change the specification to improve error handling.

Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with invalid=C2= =A0signature
3. token is expired or token is even=C2= =A0unknown
4. token was already revoked
5. token type is unsupported=C2=A0

According to=C2=A0 RFC7009 OAuth 2.0 Token Revocation=C2=A0 section 2.2 Revocation Response:

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way.=C2=A0 Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved..

As you may see this section covers only case 3 and case 4 but it's very unclear: calling token as "invalid" i= s very broad definition.
I think we should take a look on each case separately:

1. token wasn't sent in request.=C2=A0
Most implementations returns 400 status code,=C2=A0error:=C2=A0"= invalid_request",=C2=A0er= ror_description": "Missing required parameter: token".
Note that returned error is not "invalid_token" but "invalid_request" and I think this should be correct behavior and should be clearly specified.

2. token is invalid by format i.e. not JWT or JWT with invalid=C2=A0signature
This error is mostly related to JWT but for reference (opaque) tokens can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with=C2=A0=C2=A0"error": "= ;invalid_token" and I think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return an error response instead of 200 status.

3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of unknown token this may be a symptom of a bug on client side. Even if IdP can clearly determine that token is expired (in case of JWT) this is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to response with 400 status because client can have a bug when it's sends some unknown token and think that it wa= s revoked while it wasn't.

For example Google OAuth revocation endpoint implementation do not follow the spec and returns 400 Bad Request with error message "Token is revoked or expired".

4. token was already revoked
The same as above: this can be a bug in a client and we should return 400 status. In case of reference token which was removed from DB we can't distinguish that the token was revoked or even existed so this situation is the same as unknown token.

5. token type is unsupported=C2=A0
For this case specification introduces a new error code for case 5 in section 2.2.1. Error Response=C2=A0:
unsupported_token= _type:=C2=A0 The authorization server does not support the revocation of the presented token type.=C2=A0 That is, the client tried to revo= ke an access token on a server not=C2=A0 =C2=A0supporting this featu= re.=C2=A0
But it would be better to mention that revocation of ID token (which can be is considered as "public" and not u= sed to auth) definitely should cause this error.

It would be great if we discuss this cases and improve specification.

P.S. Also it may be worse to mention that specification says that content of successful response is empty but status code is 200 instead of 201 "No Content".

Regards,
Sergey=C2=A0Ponomarev


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth maili= ng list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAut= h mailing 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


--


--
--000000000000481dfb056ccec621-- From nobody Tue May 22 11:20: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 2547B129C6C for ; Tue, 22 May 2018 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 EdUr5o3lB5dk for ; Tue, 22 May 2018 11:20:51 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 329981201F8 for ; Tue, 22 May 2018 11:20:51 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id w3-v6so14150929wrl.12 for ; Tue, 22 May 2018 11:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KxgNtCoTf70rBF6Y8DnOnzKyNgYlbe2GKniPQLvckVk=; b=HO5vDufLHkj+smc+0qXuFZ9Qc0mAyclHT2RQSzNbfN+4LQcziuk/BhS29uK6PNS+av p5vq9taueA623fAVbHj4sy9KiocdU7KXQzh2KlioUlrRTakXesrZyysTBc8MjwPqdvm2 cRcwPFHn1D3QDQyanqDADxVBNb6ZRrfYdnevl55xWXLZtFq4uzP2KT+Njtqarr2EN5zg OPHVPIQx/KbH8N61kDj0vusioho2wEPF0qIeBJlDJZu3LKaytpbO1P6fVtHs4TVIsKE5 Qm7tt6XB2ouLhol35woOlSToFqrKI8ayJ4R0aPXRe6keh754Z+SInnBAvS0tFAlgme74 fe3w== 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=KxgNtCoTf70rBF6Y8DnOnzKyNgYlbe2GKniPQLvckVk=; b=gNTdE8GAD06ojSSjG1Ixhq51OdlB9X5DB4sqmJfMYt+y2OmjCsu4+za3r4Y95+Iyvd 9vz0GtNvzK5a9ArYGnLES8AcPDVVLc+sPI5Xw4W4FyBL9bR450mza785+RxYlMRmZhCN O2auK7/nkwLuCeKywbKIgnOKbM/gptjgKch/afO/CBIQKhPFDVfkhRNY805BrChBBnqO 3Y+z2z8dLLD9c6hW5Mr8NOFOVKRJmKPW+bCLKWND0tQoIyPDbTAKrSfGhIrqBpDlPNvO U5EQibGhu6L2iPRYjva7BpYFqIpLKdNMWYpshWpB97zFGe7rl5VTUI65gHMtCVTzZlJq uyvg== X-Gm-Message-State: ALKqPwcnQMfqm2C/5DVm3oPukaSn14x9AOdUlIZ3zM27w5LI/nZabhKz hu+9iKuov3V+w+kgmwduMS2XpQ== X-Google-Smtp-Source: AB8JxZp97eAaLQdFqiV1DAykdSq6vz9H5uPv5AVB9/DwrkRLiU3tzjTBbltM4YsjTMW9zsU4IZSbhA== X-Received: by 2002:adf:9561:: with SMTP id 88-v6mr9931209wrs.264.1527013249551; Tue, 22 May 2018 11:20:49 -0700 (PDT) Received: from dhcp127.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id g192-v6sm624732wmd.36.2018.05.22.11.20.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 May 2018 11:20:48 -0700 (PDT) From: Joseph Heenan Message-Id: <689F7720-B5D8-4686-A8E1-79E2ABEBEDF1@authlete.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1BCDAFBE-FD18-43AE-9DC6-B3B2DC0FF51F" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 22 May 2018 19:20:47 +0100 In-Reply-To: <1fe04f5e-b968-5a6d-efe8-b47da5e28592@free.fr> Cc: "" To: Denis References: <152681629717.2793.15028642368623108299@ietfa.amsl.com> <34B9FBE9-788E-4B1C-B2A4-08FD14EC2BD5@lodderstedt.net> <1fe04f5e-b968-5a6d-efe8-b47da5e28592@free.fr> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 18:20:53 -0000 --Apple-Mail=_1BCDAFBE-FD18-43AE-9DC6-B3B2DC0FF51F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Denis, > On 22 May 2018, at 14:05, Denis wrote: > In particular, the text states: >=20 > "Clients shall use PKCE [RFC7636] in order to (with the help of = the authorization server) detect and prevent attempts=20 > to inject (replay) authorization codes into the authorization = response". >=20 > This is incorrect, since RFC7636 should be used when the authorization = code is returned from the authorization endpoint > within a communication path that is not protected by Transport Layer = Security (TLS). >=20 That is not really the full story as we've seen attacks where URLs that = you would expect to be protected by TLS are vulnerable; one example is: = https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS= -With-Unholy-PAC.pdf IMHO it would be sane to use PKCE anywhere where a code is returned in = the URL and there isn't another proof of possession / token binding = mechanism in play. Joseph --Apple-Mail=_1BCDAFBE-FD18-43AE-9DC6-B3B2DC0FF51F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Denis,

On 22 May 2018, at 14:05, Denis <denis.ietf@free.fr> wrote:

In particular, the text states:

       "Clients shall use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts
        to inject (replay) authorization codes into the authorization response".

This is incorrect, since RFC7636 should be used when the authorization code is returned from the authorization endpoint
within a communication path that is not protected by Transport Layer Security (TLS).

That is not really the full story as we've seen attacks where URLs that you would expect to be protected by TLS are vulnerable; one example is:


IMHO it would be sane to use PKCE anywhere where a code is returned in the URL and there isn't another proof of possession / token binding mechanism in play.

Joseph

--Apple-Mail=_1BCDAFBE-FD18-43AE-9DC6-B3B2DC0FF51F-- From nobody Wed May 23 04:58: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 4D88012DA69 for ; Wed, 23 May 2018 04:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] 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 FT0MOZ0g8kbg for ; Wed, 23 May 2018 04:58:46 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::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 09F85126D45 for ; Wed, 23 May 2018 04:58:46 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id DA508780331 for ; Wed, 23 May 2018 13:58:43 +0200 (CEST) Cc: "" References: <152681629717.2793.15028642368623108299@ietfa.amsl.com> <34B9FBE9-788E-4B1C-B2A4-08FD14EC2BD5@lodderstedt.net> <1fe04f5e-b968-5a6d-efe8-b47da5e28592@free.fr> <689F7720-B5D8-4686-A8E1-79E2ABEBEDF1@authlete.com> From: Denis Message-ID: Date: Wed, 23 May 2018 13:58:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <689F7720-B5D8-4686-A8E1-79E2ABEBEDF1@authlete.com> Content-Type: multipart/alternative; boundary="------------6D160DDAA5F81616877E4663" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 11:58:48 -0000 This is a multi-part message in MIME format. --------------6D160DDAA5F81616877E4663 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Joseph, Among these 39 slides, to which attack(s) are you referring ? I wrote:"It is quite hard to understand under which /context(s) /and conditions OAuth 2.0 could be safely used". For each counter-measure, it would be useful to explain under which context(s) or under which assumptions it should be used. Denis > Hi Denis, > >> On 22 May 2018, at 14:05, Denis > > wrote: >> >> In particular, the text states: >> >> "Clients shall use PKCE [RFC7636] in order to (with the help >> of the authorization server) detect and prevent attempts >> to inject (replay) authorization codes into the authorization >> response". >> >> This is incorrect, since RFC7636 should be used when the >> authorization code is returned from the authorization endpoint >> within a communication path that is _not protected_ by Transport >> Layer Security (TLS). >> > That is not really the full story as we've seen attacks where URLs > that you would expect to be protected by TLS are vulnerable; one > example is: > > https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf > > IMHO it would be sane to use PKCE anywhere where a code is returned in > the URL and there isn't another proof of possession / token binding > mechanism in play. > > Joseph > --------------6D160DDAA5F81616877E4663 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Joseph,

Among these 39 slides, to which attack(s) are you referring ?

I wrote:"It is quite hard to understand under which context(s) and conditions OAuth 2.0 could be safely used".

For each counter-measure, it would be useful to explain under which context(s) or under which assumptions
it should be used.

Denis

Hi Denis,

On 22 May 2018, at 14:05, Denis <denis.ietf@free.fr> wrote:

In particular, the text states:

"Clients shall use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts
to inject (replay) authorization codes into the authorization response".

This is incorrect, since RFC7636 should be used when the authorization code is returned from the authorization endpoint
within a communication path that is not protected by Transport Layer Security (TLS).

That is not really the full story as we've seen attacks where URLs that you would expect to be protected by TLS are vulnerable; one example is:


IMHO it would be sane to use PKCE anywhere where a code is returned in the URL and there isn't another proof of possession / token binding mechanism in play.

Joseph


--------------6D160DDAA5F81616877E4663-- From nobody Wed May 23 09:27: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 31B0F1275AB for ; Wed, 23 May 2018 09:27:12 -0700 (PDT) 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, 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=uni-stuttgart.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 zMXpT0KGcez3 for ; Wed, 23 May 2018 09:27:09 -0700 (PDT) Received: from mxex2.tik.uni-stuttgart.de (mxex2.tik.uni-stuttgart.de [IPv6:2001:7c0:2041:24::a:2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC4B127286 for ; Wed, 23 May 2018 09:27:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTP id 3D729793CD; Wed, 23 May 2018 18:27:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=dkim; i= @sec.uni-stuttgart.de; t=1527092824; x=1528831625; bh=C/nXQ62cHb 36YgDa5xZZSs+TPQ8gt05tiwgNZjClxxQ=; b=sx3z51gHiZ+LJGdtDyoakn1mNL CYAI5SDsL0b/T8+VZ/obq0kF5nfxN34yJGBE8HiZUYpUTeM9Nxgx4Giq3WkhQ4qH +MaV/SKBlDF6qAmjpXqcrdntERmncYb8CUqBREiBtO26/Kb3YcFANAjPCiolXPj8 sw8yxbAWG0QRODzBiaSASRagxUodCT6A9XBF2sZoJbAJhHxxWTD4yeVQP+GLRP64 bfQbgp9Eu/uBH9hWtOpG3T0TRHDvl9zhSh3qzlU/qsPhJAaLOXP8j4hNIz+j6GWr 5REagpdCAKCmzoYmIaLmJ6M4Mgym9QLr9QvjbUzLjpSj56TUCK3JoRR3fNaA== X-Virus-Scanned: USTUTT mailrelay AV services at mxex2.tik.uni-stuttgart.de Received: from mxex2.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex2.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id bmKJmLSlxyG9; Wed, 23 May 2018 18:27:04 +0200 (CEST) Received: from [IPv6:2001:7c0:2015:182::1:32] (unknown [IPv6:2001:7c0:2015:182::1:32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTPSA; Wed, 23 May 2018 18:27:03 +0200 (CEST) To: oauth@ietf.org References: From: Daniel Fett Openpgp: preference=signencrypt Autocrypt: addr=daniel.fett@sec.uni-stuttgart.de; prefer-encrypt=mutual; keydata= xsFNBFbu2RUBEAC3F5+IMjFcXSj46xS8QQe6d/FAb+7IkkOdFKrINhgCialH4enWB2V3ykOX xESdrchRBCLoePyNmoJdFTijGxBMGNqSKU9rrppF5uvPFv/qIvCaBDAjFXR+qshsHjsMxTNH 67kuhkFQczKQHs4KVICG/gnssC3iejrk6Mav0MIJKXXdz6bUQPDyUTD+LsyHJ7vNfkfitnO4 rbD+kEZ0n14dQqp+c91b7X5KZVTt1c3d/N1kbruS29SlIDUJSHV0AdDZmP6wuH5a9XUIlDkP mM2bncIry3xiXWolYf3BJigxYg1XwVMYBdsrVg4kID5WY1RCHns07cDGluERcurjj3QHjToL T7VemcnFVzSphjjisi9a1QfRYCPf5xw5L8IjsAuNTBLv2DXKtL6Mf5Tv9BAZPD2em0rNS5n/ M7S6D2AAxIt9BQQ4aS16faI0gfUspj09RLdHANwOcLUPu+OE+O2IdgglBQLkadwLj9aY0ncE 8GhqFWcQ9xbtvHAljYaz5VmsOnjsadfGD8xW+QtWeFc8mfq7PncRjrc0Ywtb8TKeXkLHUQoT 4v2ilXisfOhryVj6/GuQvDjKKyUBW1tQPxei4n/W0zBC4LWehmwCH+WrFt+mTh3uHSyy9VbR FYmY6MBBMUpHHVQ3AVLgxoldu/yX/ery+fdE8MeScAWg+WE5rQARAQABzSBEYW5pZWwgRmV0 dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPsLBgAQTAQgAKgIbAwUJC0c1AAULCQgHAwUVCgkICwUW AgMBAAIeAQIXgAUCVu7cmAIZAQAKCRBYD1kOlZ2qqXCPD/wLpgL6j51OUlGzLaA+Xt+QzX/v qUiHJsvv1mEnyofk/3pGr7ce/1UNp7e8/W2JnnHvz4RBaNkn07DFyOvrVNXiMyU6mKWvG6xw Ri5Qc2t1Cup+mXlNc5fxlZGnwOYXZJErYVTPodkFlbb6LKUMyg6v2P7ZEvw4YyPh7WpV5ujF VVkYBSLviNCjVwKr8WlJJlVI4uvHZshnX85lVpRNcF+Hqf7IhnJzCQ5bUNnV7aKc4WPNw7L6 EquuCAl6JGKdeV2M+S5UVN9Eaa/CQxJf8X9I3SVgWCGQ/gLt0x1oKt6oFMECJcH2LDFOJyWv 61AUIzqCdRiTUagdc+7sn2OFbbjhKin9x+Qq6pyoXa6ZcpEuyBoAy+hNU8RAXcPgvEBy4Bwx BYQ9S3uQmBx/TcYgSUbBwBhvIYRVM5DfBefolj3HyUlvHx8JO8scbdcVl+v1+f9d5x4YS16t bWNe7awE6UWM2I02+uv7SI2ieJ2zQsOulDTEYVYjWcu0hBH24K53wniyh3JHzu6RVCgewx4P 6H2WHOSVf2p9ppuIrbWh7J6pp9nFdDXESKxH3GO5LooLamGugSlRwdgsqxY0O4BbCpKIpfe8 31peA+7qbh1f4TXHo/ZQE8fZ2s4VN5XR5J5/yjfqY2pWDy1XocixzXboLAcuzGmZNutS46eH Azjo2CxTa87BTQRW7tkVARAA1cAIBWNxYj/QE7RcOHGgr8xXcKWk/wwTWgLvjEbp5tqMl3Jk EwD1Iajz1s+Qp7U+U4UqyI+ZSfm03bYFYlTyKaS2esiM+Incutg18N943xwGNc6csyNoW5/f xbDQ4hoMKsod9zjfvxpA8xLg8gjuPKi5Y698K7qDCCfGvo6e67qwFWIvrB7cv/NAoaVd1OPI 79nt2H5yWo0PE2Kd2yAMnWJ/3clLR6X4jqkmpoc2uEPE6aM7iQ6SCx7rMFP9W9OvovnzVksS dh65JRkiA3DTUWBxZM6h/oEERBTr9Q/JYXXugO300loterwBVu0ymBHdAjIlxpetFwZu/Wlb nymC4VSxGPS/+mJ9Lnh3WWjVEcP5F9WgqmfJ49BNqOjmgZ9u9VYV8R9fOaYvtPFTdGTYT9iw JYic/0xt9NcW/hRkff0UHdiN/BrTxbHVI7Qf4MLBK/+VtqVi0MLs7U80/2fPRebTq4yQ6aoY 7hErExrJ7TgTmZghsBJTd2cmau26Kb7stLJ4ySADcyrsADl03MNoj8QqVuO8HXx2InM18sHP xldjovv8dhmj7uiKmMPAqq5f8pA5bcA/EQ6S+ItjjohSLiYQtq6UgDPlt4tIA9nCfx+cGi6f o4sJE0InaQLinm0USp0zE+slpqXGwjzeFSTioL81cDGhN3dcCK94VsntblsAEQEAAcLBZQQY AQgADwUCVu7ZFQIbDAUJC0c1AAAKCRBYD1kOlZ2qqdnTD/9fOyWwdhOv4ehtR8ShfhM1FAc8 bWMfCrxTpI4baPM4fqIFgMAJ9iQ0FF6cB0zQjDwsWNC+3t+2JdiNeM8FB7s4bbJlhjaavzKK 77Kbf4WpVs7ge0+Zghc2qHRg/SQeC1G26GzSZDDWzDHFZX0va8H0KmT/tHJYD263CIcff/E9 WXT/22rrgYvuQXPIOBzON9WqUkCAvPA19xuBsDQSbXkXwiPsZRqmyktjc8GQn1iemQ/dzlU/ e6ORNrPcK15kUyPyJMaZf+6QJ8EivUyg+pTXicEcghWNYHXxop4k0y+bsay0cBN2lmNu7UEF qhO8HQmp2jrwZXFZD/fbZukXFHNWvNsvQ55flUfajPZhUokXHskkerbq6ZCS58HkWl0tqSIb 5TxNfP0zjcrlDBc8sF6UHXgNR1oUXypGOAq4iHeJNVpI4aQm/PufmeGExx6lPtJxJ9jOs5gD rYRuBfa1cJznEPNbIe0/eCv5qDpf95csdGJhM418x2xeg58PbmBByS9MXOGFtli0K9sxIej/ YdA94hlk/R9ViIPDuqDxz0PP+IRFVVOQhOprSnG8cV31oOe00e1bIBH3ttdsgp3AHqz/zlfF kZt27s1VH+aRF4STntrU97dNmxrgjq8zUZ7VgYjq8KqLg0BsDRIy4b/AnptYh6E4oE74gKCo Qoim4V9DGw== Message-ID: Date: Wed, 23 May 2018 18:27:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1387D533FC31477A3C23913F" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 16:27:12 -0000 This is a multi-part message in MIME format. --------------1387D533FC31477A3C23913F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Brian! Pedram and I are still not completely sure whether we fully understand the setting here... Am 15.05.18 um 00:22 schrieb Brian Campbell: > Typically when an access token is issued via the implicit grant > directly from the authorization endpoint, it is for a client that is > running as script in the user-agent. The AS binds the access token to > the referred token binding, which would be the token binding between > the user-agent (where the client is) and the protected resource.=C2=A0 > > It does mean that a hybrid style client couldn't pass the access token > from its script front-end in the user-agent to its server backed > (well, it could pass it but the=C2=A0server side couldn't use it becaus= e of > the binding). Section 3.1 says "For access tokens returned directly from the authorization endpoint, =C2=A0=C2=A0 such as with the implicit grant defined in Section 4.2 of OA= uth 2.0 =C2=A0=C2=A0 [RFC6749], the Token Binding ID of the client's TLS channel = to the =C2=A0=C2=A0 protected resource is sent with the authorization request as= the =C2=A0=C2=A0 Referred Token Binding ID in the "Sec-Token-Binding" header,= and is =C2=A0=C2=A0 used to Token Bind the access token." Just to clarify: This implies that there must be an HTTP(S) request from the browser to the protected resource which then gets redirected to the authorization endpoint. Is that correct? - Daniel --=20 SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universit=C3=A4tsstra=C3=9Fe 38 - 70569 Stuttgart - Room 2.434 --------------1387D533FC31477A3C23913F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks Brian! Pedram and I are still not completely sure whether we fully understand the setting here...

Am 15.05.18 um 00:22 schrieb Brian Campbell:
Typically when an access token is issued via the implicit grant directly from the authorization endpoint, it is for a client that is running as script in the user-agent. The AS binds the access token to the referred token binding, which would be the token binding between the user-agent (where the client is) and the protected resource. 

It does mean that a hybrid style client couldn't pass the access token from its script front-end in the user-agent to its server backed (well, it could pass it but the server side couldn't use it because of the binding).

Section 3.1 says "For access tokens returned directly from the authorization endpoint,
   such as with the implicit grant defined in Section 4.2 of OAuth 2.0
   [RFC6749], the Token Binding ID of the client's TLS channel to the
   protected resource is sent with the authorization request as the
   Referred Token Binding ID in the "Sec-Token-Binding" header, and is
   used to Token Bind the access token."


Just to clarify: This implies that there must be an HTTP(S) request from the browser to the protected resource which then gets redirected to the authorization endpoint. Is that correct?

- Daniel


-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434
--------------1387D533FC31477A3C23913F-- From nobody Thu May 24 00:18: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 6B9651242F7 for ; Thu, 24 May 2018 00:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 4hukshWTR440 for ; Thu, 24 May 2018 00:17:59 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 03F18124B0A for ; Thu, 24 May 2018 00:17:58 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id e80-v6so543431oig.11 for ; Thu, 24 May 2018 00:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5IZ9n1t+G01RZw6QCBwaZcn4AhfxOFeCHUfSINuaCj0=; b=LqAk1i4oWHpNW6Bzx8rNtO3dsnz+meLQmFafPufX8QwSDiGBDq1B57ccJUyjAMvrR/ shmVp+ypc3JtzYYSuEI33ZaRX+2BSZNQpPMJVyT+Lcq/8/XM87w8I/vGWMX5RNpo2KqB 82Zqt8z/yyduIHeDSlMaXXMSgO6w5qMql/bAHQusL28L+QpR3vd5D3C7m1XGoI1BYEHL gdLcRfxxH5dfCL80lXImaI8OvvhXV2ATYwVsYKwhQb0Yfr30vene3Kj/vmmA4jbZhTmM srK4cdYOKvR+k8WrdtNwsf3zcm8mVpoDMGRSRJ7hwAp8MHZMguNsFx8i1NBKGBstOTU/ cfrQ== 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=5IZ9n1t+G01RZw6QCBwaZcn4AhfxOFeCHUfSINuaCj0=; b=Yv6EoL2dH2r9TSEUKpVsdx0FB/toG1YGLnQs9/y+ZeoDCpvoN3Te405SnaKDd6G6XH YLnDVIcBbdIU2QkP36wacJsSo9I5ENoxWBa/6u9lpfq3ah2EtFxx4kzdqHvgRM4rTJG6 dCKvn1caYOjUcrFPmRBJV3pgl6AiAzuesM1L1Fejg1fOdTgoKcwz0cZzrTq+Im96kLhc rkn0A64y1DDUklEduiygqdD6tMd9tXugl6WczGOir3OcA66ujWazGQhfNGZxfulmUd3p rlHqbgIu5rXSpsR85eteOl61HnMsjxtrLkJJtkHHoh1CziM7rBHbEXcMsRTmu3KgvHXV GvNw== X-Gm-Message-State: ALKqPwd2nHKnQqsX9zX8DKYWDwV6OJTK+6D5eqJkfb5TPHNSKuw/uqaG WeMZjvwrX5+fSQpCTYXEenq/jz7xqWFBIN+xVRGwLhlM X-Google-Smtp-Source: AB8JxZopXcyFkDawVQKooPoDVUxGI4gdnI4RJM99V9DkGQI/DAWvWfrfN9IFn60SBLRqhBlu4OgrEKS9ucgCPNuheiA= X-Received: by 2002:aca:e889:: with SMTP id f131-v6mr3432360oih.324.1527146277094; Thu, 24 May 2018 00:17:57 -0700 (PDT) MIME-Version: 1.0 From: Sergey Ponomarev Date: Thu, 24 May 2018 10:17:20 +0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005dcaad056cee73fd" Archived-At: Subject: [OAUTH-WG] Grant flow for delegated auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 07:18:03 -0000 --0000000000005dcaad056cee73fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, My Auth Server (AS) implementation has a client (server of another platform) which makes authorization on it's side but it needs to populate user info to my AS and receive an access token to work with my my platform. What I mean that they need just login user to my platform but without user's credentials. So user's credentials are on client side but session management (login, logout) on my platform's side. As I understood, this is something similar to federation. We can't use a Password Grant Flow in this case because the client will not send a user's password. Also my AS needs some basic use info and instead of pulling a user info from AS the client push it. I going to introduce and implement a new grant flow, let's call it "delegated" and it looks similar to Password grant flow but without user's password and it receives id_token with user's info. POST request to Token Endpoint with form params: grant_type=3Ddelegated, client_id,client_secret,username,scope and id_token: curl -X POST \ https://authserver/oauth/token \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'grant_type=3Ddelegated&client_id=3Dacme&client_secret=3Dacmesecret&usernam= e=3Duser&scope=3Dopenid&id_token=3DeyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYi= fQ.ewogImlz%0AcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4%= 0AMjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi%0Abi0wUzZfV3= pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz%0AMTEyODA5NzAsCiAibmFtZS= I6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6%0AICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6IC= JEb2UiLAogImdlbmRlciI6ICJm%0AZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIi= wKICJlbWFpbCI6%0AICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly= 9l%0AeGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn%0AspA10Qq= l2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip%0AR2iAjzLvDNAReF97zoJ= qq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac%0AAAgNCUwtik6SjoSUZRcf-O5lygIyLEN= x882p6MtmwaL1hd6qn5RZOQ0TLrOY%0Au0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6D= H5K6o33TcxkIjNrCD%0A4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDa= QzUHl%0A6cQQWNiDpWOl_lxXjQEvQ' And response contains access_token. So my question is: maybe something similar already exists in specification? If no, then what usually used in this case? Regards, Sergey Ponomarev --0000000000005dcaad056cee73fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

My Auth Server (AS)=C2= =A0 implementation has a client (server of another platform) which makes au= thorization on it's side but it needs to populate user info to my AS an= d receive an access token to work with my my platform.
What I= mean that they need just login user to my platform but without user's = credentials.
So user's credentials are on client side but ses= sion management (login, logout) on my platform's side. As I understood,= this is something similar to federation.

We can&#= 39;t use a Password Grant Flow in this case because the client will not sen= d a user's password. Also my AS needs some basic use info and instead o= f pulling a user info from AS the client push it.
I going to intr= oduce and implement a new grant flow, let's call it "delegated&quo= t; and it looks similar to Password grant flow but without user's passw= ord and it receives id_token with user's info.
POST request t= o Token Endpoint with form params:=C2=A0grant_type=3Ddelegated,client_id,client_secret,username,scope = and=C2=A0id_token:

curl -X POST \
=C2=A0 https://authserver/oauth/token \
=C2=A0 -H 'Content-Type: application/x-www-form-urlencoded'= \
=C2=A0 -d 'grant_type=3Ddelegated&client_id=3Dacme&= ;client_secret=3Dacmesecret&username=3Duser&scope=3Dopenid&id_t= oken=3DeyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz%0AcyI6ICJodHRwOi= 8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4%0AMjg5NzYxMDAxIiwKICJhdWQiOi= AiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi%0Abi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMj= gxOTcwLAogImlhdCI6IDEz%0AMTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW= 5fbmFtZSI6%0AICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm%0= AZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6%0AICJqYW5lZG9= lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l%0AeGFtcGxlLmNvbS9qYW5lZG9= lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn%0AspA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKs= Djn_wMkHxcp6CilPcoKrWHcip%0AR2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B= 0w3K-E7yM2mac%0AAAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrO= Y%0Au0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD%0A4XB1CKKu= mZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl%0A6cQQWNiDpWOl_lxXjQEv= Q'

And response contains access_token.

So my question is: maybe something similar already = exists in specification?
If no, then what usually used in this ca= se?

Regards,
--0000000000005dcaad056cee73fd-- From nobody Thu May 24 09:55: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 ED67412DA2C for ; Thu, 24 May 2018 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 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, HTML_OBFUSCATE_10_20=0.093, 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 (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 8ysvfVoXs1V1 for ; Thu, 24 May 2018 09:54:58 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF0F12E6D7 for ; Thu, 24 May 2018 09:54:57 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id o185-v6so3130743iod.0 for ; Thu, 24 May 2018 09:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NtixEvU5uz1WD38fT1nqLEHjm7zZUoG488LHFBGpLWw=; b=mxhDCnuSzFUxh0jEdlhA3x6QOgg1+G9TC2qhEnT2sxjQ+ZsXlMI6hXDU1qYNY3su2F nzTAJHwz2lLBMGLkwHtgnO6Vj5lnFGDz/rxO6GeptsHAOrtejCivQWRx2U4hClXk81xF Ndl3DswfsHH8Qv4sX1U6MXgwU/TJJvWfQncbw= 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=NtixEvU5uz1WD38fT1nqLEHjm7zZUoG488LHFBGpLWw=; b=uRMevCT9P4O0mlh/qecqpS9FnrAOB7LoNUFbj0Hznh5/H7DUq9JKAfvfsK4nswKijh 92W4MGCFGfh6tPjmFC5IAGp8AqlANoqdklDaSwDqtibP8ZE1Qvx9B9Zr+dYdlU5Dv1zT FTJdnB/jzTqxm43WkJ2kFORRaiFfOrs4tsAXICJVC5iOhb5gV58VPLeq67xH71EKNQ94 7HYPWKQ+8xfCFOXXm+1uopyeHQU9YMDCs2s9EdnJnKcTNvA79P9WkZvzfy11UPa3t5Do C/D6OV5xmoIDDX4WQsq8vhNAKg8gcfI8PVm1QpFroUnb90OO/043BQ6d4Cg678nc4RyY HBeA== X-Gm-Message-State: ALKqPwf978PVCEhroIEk9tMMWYcaw3xr6gEPeJ/SYoWpJ+f7ITJzgQaV LoGX5VF3WsrZc8GnZXiaolDl2rWDGOoi8gI1dSd+RUEki0/cNm2MAt4lHU9ZD5r2PH1gNUmyzIp C90JDaEyz0UtTNA== X-Google-Smtp-Source: AB8JxZpqoXGdWvH0nNBiz+64ti1aje4OxXkMtCFh3ItjGAxRune3ktQrT0BJ42zZAeeY0PBK2jcuJLeTbQnVT13ywtk= X-Received: by 2002:a6b:630d:: with SMTP id p13-v6mr5524849iog.17.1527180896994; Thu, 24 May 2018 09:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 24 May 2018 09:54:26 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 24 May 2018 10:54:26 -0600 Message-ID: To: Sergey Ponomarev Cc: oauth Content-Type: multipart/alternative; boundary="000000000000dfcbb2056cf682d7" Archived-At: Subject: Re: [OAUTH-WG] Grant flow for delegated auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 16:55:00 -0000 --000000000000dfcbb2056cf682d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Take a look at RFC 7523 's JWT Authorization Grant. On Thu, May 24, 2018 at 1:17 AM, Sergey Ponomarev wrote= : > Hi, > > My Auth Server (AS) implementation has a client (server of another > platform) which makes authorization on it's side but it needs to populate > user info to my AS and receive an access token to work with my my platfor= m. > What I mean that they need just login user to my platform but without > user's credentials. > So user's credentials are on client side but session management (login, > logout) on my platform's side. As I understood, this is something similar > to federation. > > We can't use a Password Grant Flow in this case because the client will > not send a user's password. Also my AS needs some basic use info and > instead of pulling a user info from AS the client push it. > I going to introduce and implement a new grant flow, let's call it > "delegated" and it looks similar to Password grant flow but without user'= s > password and it receives id_token with user's info. > POST request to Token Endpoint with form params: grant_type=3Ddelegated,c > lient_id,client_secret,username,scope and id_token: > > curl -X POST \ > https://authserver/oauth/token \ > -H 'Content-Type: application/x-www-form-urlencoded' \ > -d 'grant_type=3Ddelegated&client_id=3Dacme&client_secret=3D > acmesecret&username=3Duser&scope=3Dopenid&id_token=3D > eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz% > 0AcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4% > 0AMjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi% > 0Abi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz% > 0AMTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6% > 0AICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm% > 0AZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6% > 0AICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l% > 0AeGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn% > 0AspA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip% > 0AR2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac% > 0AAAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5R > ZOQ0TLrOY%0Au0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD% > 0A4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs- > rDaQzUHl%0A6cQQWNiDpWOl_lxXjQEvQ' > > And response contains access_token. > > So my question is: maybe something similar already exists in specificatio= n? > If no, then what usually used in this case? > > Regards, > Sergey Ponomarev > > _______________________________________________ > 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._ --000000000000dfcbb2056cf682d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Take a look at RFC 7523's JWT Authorization Grant.

On Thu, May 24, 2018 at 1:17 AM, = Sergey Ponomarev <stokito@gmail.com> wrote:
Hi,

My Aut= h Server (AS)=C2=A0 implementation has a client (server of another platform= ) which makes authorization on it's side but it needs to populate user = info to my AS and receive an access token to work with my my platform.
<= /div>
What I mean that they need just login user to my platform but wit= hout user's credentials.
So user's credentials are on cli= ent side but session management (login, logout) on my platform's side. = As I understood, this is something similar to federation.

We can't use a Password Grant Flow in this case because the cli= ent will not send a user's password. Also my AS needs some basic use in= fo and instead of pulling a user info from AS the client push it.
I going to introduce and implement a new grant flow, let's call it &qu= ot;delegated" and it looks similar to Password grant flow but without = user's password and it receives id_token with user's info.
POST request to Token Endpoint with form params:=C2=A0= grant_type=3Ddelegated,cl= ient_id,client_secret,username,<= span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;fon= t-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-= weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tran= sform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255= ,255);text-decoration-style:initial;text-decoration-color:initial;float:non= e;display:inline">scope and=C2=A0id_token:=

curl -X POST \
=C2=A0 -H 'Content-Typ= e: application/x-www-form-urlencoded' \
=C2=A0 -d 'g= rant_type=3Ddelegated&client_id=3Dacme&client_secret=3Dac= mesecret&username=3Duser&scope=3Dopenid&id_token=3Dey= JraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz%0AcyI6ICJodHRwO= i8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4%0AMjg5NzYxMD= AxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi%0Abi0wUzZ= fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz%0AMTEy= ODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6%0AI= CJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm%= 0AZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6%0AICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l= %0AeGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLyk= YNn%0AspA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoK= rWHcip%0AR2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac%0AAAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY%0Au0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33= TcxkIjNrCD%0A4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-= rDaQzUHl%0A6cQQWNiDpWOl_lxXjQEvQ'

<= div>And response contains access_token.

So my ques= tion is: maybe something similar already exists in specification?
If no, then what usually used in this case?

Regards,

_______________________________________________
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. --000000000000dfcbb2056cf682d7-- From nobody Thu May 24 11:52: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 A30D91276AF for ; Thu, 24 May 2018 11:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zghS0vCh296n for ; Thu, 24 May 2018 11:52:48 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0C612E8E4 for ; Thu, 24 May 2018 11:52:47 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id j4-v6so7939240wme.1 for ; Thu, 24 May 2018 11:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nZfNCwu4PV9HHRtx0asdwY3bPH5RuiMhs0P2fsMMnYU=; b=ckWp/+FjDISJp/h/Wu1V6Ptz/XxRGbeLXPdgAtRlY95CYZ4IPVqXPzYiizwowlhP5g 3n07zKLb03sLsqTI62Vz9E0wfRysRoQY8p5tojUXFndVJ1r72NJOdLdjl/419bAceFuj uFQFi8dcTIE9CE6TUWh0g8NphIJPnD+0rtc9+c9Ve3u6/WKOWbSboAdeDSbjMJYA/5Pf lyABeUbmNbCx+dpECvf2Q1Vx6IzBzVUsft6A9ru8MvgUVhRjQrjPxGlXMeKDI7RR/UVy 0tSRBg7VSJm1/JEvLY4/77mh/Y1i7gbUl8Aq7ss7KadE2YPixpUIzfG8pYw/dcyHv3Um qF7A== 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=nZfNCwu4PV9HHRtx0asdwY3bPH5RuiMhs0P2fsMMnYU=; b=q+F/vkg3/6J2Ecydp8eFI/XL4edrxB6oErl8heHfrcG29KfI95pBn0Td12gQi5hqr7 /q3qkhqr2NPMLeHGTSAy2RauAdli23z/77Y9OFTNUftwPw8hfor87kHyNHeGbeJPoQPV FSTJ9SVhQOinoehkeVa9G/d4WnNcKieeMQWSdDjVW/j6jHKWT3oShdqZzrJQ5Amx0+73 irLXFYRewKapqhAWQA3g6ghiP3s1Im31CKY4PJxx0SZ6npfYCtEs4JIvZTuYXcwtDBp3 IFZRecfnFmD7Z0CQ5tbG9sOPH/AnAg9M+ADTlZP8aer1wiIjoCxyPcAsAOIio8ti8Rfe MfIQ== X-Gm-Message-State: ALKqPwdC7+vADVxXFoVP0LdQ8ySoJDJzz1O29+dcHFArCz5LAAhalCyD LPhCcOuRUWrZfVWPNxAbgEd+AQ== X-Google-Smtp-Source: AB8JxZrEgillEDiwxDLloSI4kJYdrB2N4PP/icpDSLtUgtGGNYWEXmS7Tm8bYp83yuYZGWC+DmvX7A== X-Received: by 2002:a1c:7f0a:: with SMTP id a10-v6mr9524686wmd.97.1527187966339; Thu, 24 May 2018 11:52:46 -0700 (PDT) Received: from dhcp127.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id p17-v6sm4330843wmc.17.2018.05.24.11.52.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 May 2018 11:52:45 -0700 (PDT) From: Joseph Heenan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0BC99E8C-8843-439E-B709-91010EABFC06" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 24 May 2018 19:52:44 +0100 In-Reply-To: Cc: "" To: Denis References: <152681629717.2793.15028642368623108299@ietfa.amsl.com> <34B9FBE9-788E-4B1C-B2A4-08FD14EC2BD5@lodderstedt.net> <1fe04f5e-b968-5a6d-efe8-b47da5e28592@free.fr> <689F7720-B5D8-4686-A8E1-79E2ABEBEDF1@authlete.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 18:52:51 -0000 --Apple-Mail=_0BC99E8C-8843-439E-B709-91010EABFC06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Denis, This presentation is only describing one attack. Page 12 summarises it. = The attack is not a full attack targeted against oauth, but it shows how = a malicious network can steal any codes returned to the browser in the = URL, even if the codes are always sent over TLS. I was only responding to your assertion that PKCE is not required when = TLS is in use. I believe that assertion was not right, as the above = attack is against TLS enabled servers and PKCE would have made any = stolen auth code useless, so PKCE still has value even when using TLS. Thanks Joseph > On 23 May 2018, at 12:58, Denis wrote: >=20 > Hi Joseph, >=20 > Among these 39 slides, to which attack(s) are you referring ? >=20 > I wrote:"It is quite hard to understand under which context(s) and = conditions OAuth 2.0 could be safely used". >=20 > For each counter-measure, it would be useful to explain under which = context(s) or under which assumptions=20 > it should be used.=20 >=20 > Denis >=20 >> Hi Denis, >>=20 >>> On 22 May 2018, at 14:05, Denis > wrote: >>> In particular, the text states: >>>=20 >>> "Clients shall use PKCE [RFC7636] in order to (with the help = of the authorization server) detect and prevent attempts=20 >>> to inject (replay) authorization codes into the = authorization response". >>>=20 >>> This is incorrect, since RFC7636 should be used when the = authorization code is returned from the authorization endpoint >>> within a communication path that is not protected by Transport Layer = Security (TLS). >>>=20 >> That is not really the full story as we've seen attacks where URLs = that you would expect to be protected by TLS are vulnerable; one example = is: >>=20 >> = https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS= -With-Unholy-PAC.pdf = >>=20 >> IMHO it would be sane to use PKCE anywhere where a code is returned = in the URL and there isn't another proof of possession / token binding = mechanism in play. >>=20 >> Joseph >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_0BC99E8C-8843-439E-B709-91010EABFC06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Denis,

This = presentation is only describing one attack. Page 12 summarises it. The = attack is not a full attack targeted against oauth, but it shows how a = malicious network can steal any codes returned to the browser in the = URL, even if the codes are always sent over TLS.

I was only responding to your assertion = that PKCE is not required when TLS is in use. I believe that assertion = was not right, as the above attack is against TLS enabled servers and = PKCE would have made any stolen auth code useless, so PKCE still has = value even when using TLS.

Thanks

Joseph


On 23 = May 2018, at 12:58, Denis <denis.ietf@free.fr> wrote:

=20 =20
Hi = Joseph,

Among these 39 slides, to which attack(s) are you referring ?

I wrote:"It is quite hard to understand under which context(s) and conditions OAuth 2.0 could be safely used".
=
For each counter-measure, it would be useful to explain under which context(s) or under which assumptions
it should be used.

Denis

= Hi Denis,

On 22 May 2018, at 14:05, Denis <denis.ietf@free.fr> wrote:

In particular, the text states:

       "Clients shall = use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts
        to inject = (replay) authorization codes into the authorization response".

This is incorrect, since RFC7636 should be used when the authorization code is returned from the authorization endpoint
within a communication path that is not protected by Transport Layer Security (TLS).

That is not really the full story as we've seen = attacks where URLs that you would expect to be protected by TLS are vulnerable; one example is:

https://www.blackhat.com/docs/us-16/materials/us-= 16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf

IMHO it would be sane to use PKCE anywhere where = a code is returned in the URL and there isn't another proof of possession / token binding mechanism in play.

Joseph


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

= --Apple-Mail=_0BC99E8C-8843-439E-B709-91010EABFC06-- From nobody Thu May 24 13:28:26 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 8607412EB2E; Thu, 24 May 2018 13:28:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152719369843.5001.6781345939306593672@ietfa.amsl.com> Date: Thu, 24 May 2018 13:28:18 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 20:28:19 -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 : Reciprocal OAuth Author : Dick Hardt Filename : draft-ietf-oauth-reciprocal-00.txt Pages : 4 Date : 2018-05-24 Abstract: There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seamless experience for the user to grant access to a pair of protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00 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 May 24 14:58: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 9FBD712E899 for ; Thu, 24 May 2018 14:58:17 -0700 (PDT) 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=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 J3eidgOqn4Se for ; Thu, 24 May 2018 14:58:15 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 4DEDC124E15 for ; Thu, 24 May 2018 14:58:15 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id p124-v6so4159478iod.1 for ; Thu, 24 May 2018 14:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zu8nfqHmf9vCCyYWROYdOG8hLQtKo3WY5VkEopg83bs=; b=T1A9JhPSYoHaBUWRHjug5RwD0ZAaq5O6JycnS5Kck0PsLFTpf1xjNLVOM/KTu/3htL 1+PlQNWV7RhLmSKy7FvxUrs6Yv79pdhbIAbl+Bo1BO+JqJGFzlZxy/hH6Ovs7/hz4MJl 3USIF7WPNbHIrp5tvLWv+XPi94uM00ENINbuY= 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=zu8nfqHmf9vCCyYWROYdOG8hLQtKo3WY5VkEopg83bs=; b=ZfLHTzFneK4P8Or/4FC+N5Cjvac3C5mcy4rTFmwqIaxVP7eCCkigshoNMhFOinn1ZE 4f6X1VnBUxYzHdM2oPx5bFUFzGpP5wZxLpqTXIHP2IRu1Q9wVA+PbOcbMBumyuZwHM04 GSRXFuBnLHwsFsnEndRKR0RsXZE56672Zez3N3ps+neg/5N3vD57oH3TsLSVE2JfzHKW P2Sx4cQBBWzn73EWXrKKjrfGYKVtK1j0SOHg8QARRy/4/+eAyZw8eFGNu5xVcOr3p0RC hSELsYTVS8cIgtV0m7l+tnsqOBghgDpwN9LVmFqzGPsDYVA63cIVZ1Xlp1rErIy8z3Al kJhw== X-Gm-Message-State: ALKqPwc2Je4jTNSU6lTcu4oTAaS2ftA84HVQTP8EkNZxnyMMvold/x5n CDsxfpJr4vuho1fIwXAgXUyrB/rkNAkzLuM6wIRWRebGuNY1u2M61ckr47cCh4B4f2lECVtAQNL EcCacgdbMgc0onfwZ X-Google-Smtp-Source: AB8JxZpy9DU7MO9rmDSMAo5VlxBlYvAg7Z+73eyp9qApDu5Xx5Hw1tmm2BetaFtW1o3YXNDFcVsmplgQ3KjpI5eV+B4= X-Received: by 2002:a6b:1456:: with SMTP id 83-v6mr8301535iou.218.1527199094413; Thu, 24 May 2018 14:58:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 24 May 2018 14:57:43 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 24 May 2018 15:57:43 -0600 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="00000000000086398a056cfabf92" Archived-At: Subject: Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 21:58:18 -0000 --00000000000086398a056cfabf92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, that's what is implied. At least given the way that https://tools.ietf.org/html/draft-ietf-tokbind-https provides to signal to the client to reveal the Referred Token Binding. I've heard that there's some potential for the Fetch spec to provide some APIs or controls around Token Binding, which might facilitate other ways of getting the Referred Token Binding into a request. But I don't know the details or likelihood or timeline. And whatever form that takes may or may not facilitate other options for 'front-channel' requests to the authorization endpoint. On Wed, May 23, 2018 at 10:27 AM, Daniel Fett wrote: > > Just to clarify: This implies that there must be an HTTP(S) request from > the browser to the protected resource which then gets redirected to the > authorization endpoint. Is that correct? > --=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._ --00000000000086398a056cfabf92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, that's what is implied. At least given the = way that h= ttps://tools.ietf.org/html/draft-ietf-tokbind-https provides to signal = to the client to reveal the Referred Token Binding.

I've heard that there's some potential for the Fetch spec to= provide some APIs or controls around Token Binding, which might facilitate= other ways of getting the Referred Token Binding into a request. But I don= 't know the details or likelihood or timeline. And whatever form that t= akes may or may not facilitate other options for 'front-channel' re= quests to the authorization endpoint.

On Wed, = May 23, 2018 at 10:27 AM, Daniel Fett <daniel.fett@sec.uni-= stuttgart.de> wrote:
=20 =20 =20

Just to clarify: This implies that there = must be an HTTP(S) request from the browser to the protected resource which then gets redirected to the authorization endpoint. Is that correct?


=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. --00000000000086398a056cfabf92-- From nobody Fri May 25 02:35: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 E1B0A12DA16 for ; Fri, 25 May 2018 02:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7Xa7Z4t8wVPn for ; Fri, 25 May 2018 02:35:26 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (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 1A93E12D956 for ; Fri, 25 May 2018 02:35:25 -0700 (PDT) Received: from [84.158.233.58] (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 1fM987-0000Qh-2g; Fri, 25 May 2018 11:35:23 +0200 From: Torsten Lodderstedt Message-Id: <90B044A3-14E2-4125-9A81-F49BEA144EF3@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_5263440B-49E3-4F72-A0D4-B84E5F02E745"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 25 May 2018 11:35:20 +0200 In-Reply-To: <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> Cc: oauth To: Neil Madden References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 09:35:40 -0000 --Apple-Mail=_5263440B-49E3-4F72-A0D4-B84E5F02E745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Neil, > Am 28.03.2018 um 17:41 schrieb Neil Madden = : >=20 > I like this draft, but I want to clarify if it is intended that the = response JWT could be interpreted as an OpenID Connect ID Token? As the = set of claims can overlap (in particular, all required ID token claims = are valid token introspection response fields) and it seems highly = likely that an AS will use the same keys for signing both (and it = definitely will when the client_secret is used for signing), the signed = response JWT could well be indistinguishable from an ID token (for the = resource owner) with some additional claims. Conceptually, the introspection response, an ID Token and even = structured access tokens are quite the same if they carry user = identifiers or claims. They identify the respective user account towards = RP or RS and provide additional attributes, which, for example, can be = used to meet access control decisions. And if JWT is the representation, = they are also syntactically (nearly) equivalent. The main difference I = see that an ID Token may contain a nonce, which is not required in = access tokens.=20 >=20 > If this is not the case, then maybe consider adding a =E2=80=9Ccrit=E2=80= =9D: [=E2=80=9Cscope=E2=80=9D] claim to the response = (https://tools.ietf.org/html/rfc7515#section-4.1.11) to indicate that = the scope claim must be understood. What do you want to achieve/prevent?=20 >=20 > I can think of one potential use-case (I=E2=80=99ll let you decide the = merits of it) where it might actually be useful to explicitly allow the = response to be an ID Token. Consider an application (RS) that uses a = traditional authorization model: it authenticates a user, sets a cookie, = and then based on who that user is makes dynamic access control = decisions to see what they are allowed to do (e.g., ACLs, RBAC, = whatever). An easy way to upgrade this app to modern standards would be = to replace the home-spun authentication system with OIDC, but leave the = rest in place. Now the system uses OIDC to authenticate the user, sets = the ID token as the cookie, and then still applies the same access = control decisions that it always has done. >=20 > Now imagine that a new requirement comes in to support OAuth 2.0 = access tokens to allow delegation to third-party apps. A really simple = way to achieve that would be to put a filter/reverse proxy in front of = the RS that extracts access tokens coming in, performs signed JWT token = introspection against the AS to validate the token and then checks the = the scopes are appropriate for the request. It can then simply replace = the access token in the original request with the signed token = introspection response (as ID token) and forward it on to the original = RS server. As the introspection response is a valid ID token for the = resource owner, the RS will then apply all its normal access control = checks to ensure that the resource owner actually has the permissions = that they have delegated to the client. >=20 > I think potentially that is quite an interesting application of this = draft, but I don=E2=80=99t think it was intended! I think probably a = decision should be made as to whether that kind of usage should be = allowed and explicitly adjust the draft to either allow or deny it. If = it is allowed, then possibly there should be a way for the caller to = hint that they want the response to be a valid ID token. I don=E2=80=99t currently see a way the introspection response could be = abused as ID Token other than the recipient of the response (or an = attacker able to obtain the response object) sets up a fake IDP and = provides the response as an ID token to a RP. The RP should be able to = detect this (as other ways to replay ID tokens) by utilizing the nonce. kind regards, Torsten. =20 >=20 > Kind regards, >=20 > Neil >=20 >> On 18 Mar 2018, at 19:33, Torsten Lodderstedt = wrote: >>=20 >> Hi all, >>=20 >> I just submitted a new draft that Vladimir Dzhuvinov and I have = written. It proposes a JWT-based response type for Token Introspection. = The objective is to provide resource servers with signed tokens in case = they need cryptographic evidence that the AS created the token (e.g. for = liability).=20 >>=20 >> I will present the new draft in the session on Wednesday. >>=20 >> kind regards, >> Torsten.=20 >>=20 >>> Anfang der weitergeleiteten Nachricht: >>>=20 >>> Von: internet-drafts@ietf.org >>> Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >>> Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ >>> An: "Vladimir Dzhuvinov" , "Torsten = Lodderstedt" >>>=20 >>>=20 >>> A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >>> has been successfully submitted by Torsten Lodderstedt and posted to = the >>> IETF repository. >>>=20 >>> Name: = draft-lodderstedt-oauth-jwt-introspection-response >>> Revision: 00 >>> Title: JWT Response for OAuth Token Introspection >>> Document date: 2018-03-15 >>> Group: Individual Submission >>> Pages: 5 >>> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt >>> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ >>> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response >>>=20 >>>=20 >>> Abstract: >>> This draft proposes an additional JSON Web Token (JWT) based = response >>> for OAuth 2.0 Token Introspection. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_5263440B-49E3-4F72-A0D4-B84E5F02E745 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNTI1MDkzNTIxWjAjBgkqhkiG9w0BCQQxFgQUuOAbffDqWyQa 7Ob3YSdFFLmlmrEwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAFkbJYomK5aR59x2X5ix8ZjpJOZbxBiyozvoOkeOjGQt3tZ5tH04 Udv/JpPw7jwH34hN743e+oIh2GYpPnix3/jw9qCPKxx5Z4pYR4XnGeH+t6FtEoW8CPFob5SJ6eqV xvjlgbu562jdHJRR3MrQ12tHzSI4sc0LYDi8C22PcdrZLQCSPhTum32vDkUURF3JBk68r6NywIcM jeikXAhxQ0RYG4y0ItCpoCUoyz6ixwjwIWHkdtjXaLa9qq1zX8kwGMqyzhB6oBXvPAQzE8FQ5yWF PULrwtqED7v5kyo/T/+pGCEVfKXJx/zxkcHzvXjcHTmfQCO5ktSwpx9r/FREpbkAAAAAAAA= --Apple-Mail=_5263440B-49E3-4F72-A0D4-B84E5F02E745-- From nobody Fri May 25 03:24: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 6F7E4126C0F for ; Fri, 25 May 2018 03:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ot0ci5jtrjNT for ; Fri, 25 May 2018 03:24:45 -0700 (PDT) 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 A172D124D68 for ; Fri, 25 May 2018 03:24:45 -0700 (PDT) Received: from [84.158.233.58] (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 1fM9tn-0007m0-M0; Fri, 25 May 2018 12:24:39 +0200 From: Torsten Lodderstedt Message-Id: <885F5820-1A64-4D68-A16F-31E24F450A04@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_B08D6154-0EE1-4481-BE37-7B507D1F0A1E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 25 May 2018 12:24:36 +0200 In-Reply-To: Cc: oauth To: Petteri Stenius References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:24:49 -0000 --Apple-Mail=_B08D6154-0EE1-4481-BE37-7B507D1F0A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HI Petteri, thanks for your feedback. I incorporated it in the upcoming revision.=20 kind regards, Torsten.=20 > Am 26.03.2018 um 11:02 schrieb Petteri Stenius = : >=20 > Hi all, > =20 > I want to show my support for this proposal > =20 > =20 > I believe the two use cases presented at the IETF meeting [1] are = important: > =20 > 1. implementing application level end-to-end integrity protection of = the introspection response > 2. simple conversion of by-reference access tokens into by-value JWT = encoded tokens > =20 > =20 > This proposal adds three fields to the client metadata. I think there = are two issues that should be addressed: > =20 > 1. Remove double "response" from field names. Replace = "introspection_response_signed_response_alg" with = "introspection_signed_response_alg". Also address two other fields > 2. Add corresponding fields to provider metadata. For client metadata = field "introspection_signed_response_alg" there should exist = "introspection_signing_alg_values_supported" in provider metadata. The = two other fields need corresponding fields as well. > =20 > =20 > Relationship with OpenID Connect > =20 > In OpenID Connect the userinfo endpoint is very similar to = introspection endpoint of OAuth. Userinfo supports JWT signing and = encryption. Adding JWT signing and encryption to introspection endpoint = fills the gap between the two specifications. > =20 > =20 > Best regards, > Petteri Stenius > =20 > [1] = https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessb-= jwt-introspection-response-01 > =20 > =20 > =20 > From: OAuth On Behalf Of Torsten Lodderstedt > Sent: sunnuntai 18. maaliskuuta 2018 21.33 > To: oauth > Subject: [OAUTH-WG] Fwd: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > =20 > Hi all, > =20 > I just submitted a new draft that Vladimir Dzhuvinov and I have = written. It proposes a JWT-based response type for Token Introspection. = The objective is to provide resource servers with signed tokens in case = they need cryptographic evidence that the AS created the token (e.g. for = liability).=20 > =20 > I will present the new draft in the session on Wednesday. > =20 > kind regards, > Torsten.=20 >=20 >=20 > Anfang der weitergeleiteten Nachricht: > =20 > Von: internet-drafts@ietf.org > Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ > An: "Vladimir Dzhuvinov" , "Torsten = Lodderstedt" > =20 >=20 > A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to = the > IETF repository. >=20 > Name: = draft-lodderstedt-oauth-jwt-introspection-response > Revision: 00 > Title: JWT Response for OAuth Token = Introspection > Document date: 2018-03-15 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt > Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ > Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response >=20 >=20 > Abstract: > This draft proposes an additional JSON Web Token (JWT) based = response > for OAuth 2.0 Token Introspection. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_B08D6154-0EE1-4481-BE37-7B507D1F0A1E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNTI1MTAyNDM3WjAjBgkqhkiG9w0BCQQxFgQU2fWvzwbOlpRD EGUTJJ426zPuEfUwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAGRD/k3+/nlgICqJG19bC5PWS/kW+CLye9ei2Bq5ei4Di/3Swk4l APN1X2f0pc3O7mGYQ1VRnfxZk3CbLiDUHNfmkJMnXhQTgtJAVIS3EASTnQ5q3SziwqIWYHhmxRxe DEdyTACdEaTg9nlI9HONot2/ZlCphgQ5stN14sT950z+FrB4CMBN9Ml8ylbXSgdeHek2If3t7X10 1pRcSVRqxPC6Ouq3Y33OxyMCr2Ety0+PM6+Jppok5M/cV3Z0pItEJ4A1fy/fEsAwvktcxe0haXZ5 jKt0ofKxLBC6biTCcve/cGsgD1l2GGTTWCJvJggLuxAQ36HwrBygqscaIw7Nj1UAAAAAAAA= --Apple-Mail=_B08D6154-0EE1-4481-BE37-7B507D1F0A1E-- From nobody Fri May 25 03:49: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 A5990126DC2 for ; Fri, 25 May 2018 03:49:49 -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 (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 nkwbPdMPi8kD for ; Fri, 25 May 2018 03:49:46 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 A0E02126D85 for ; Fri, 25 May 2018 03:49:46 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id x9-v6so8432157wrl.13 for ; Fri, 25 May 2018 03:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mxuz63i8lZKDGG6JEmdUrkcEoFxRlCQdix3pMSi+Lx4=; b=DEQlmFP8HGLSYMf/nFutIIyqN0yVXEBgubyMpjg+dSii2MMDw6RdRkNtPZtGHQhLos QDSIV2SvpJZZSkE6Vr5xMDX3TSVAn3WzEq9ZxDWTmqaCZNBPbQ8CCDvARA0Vm4zxkUc9 HIUuzk1gEn3lo0RfGCpkBJdM39KweumkTaqkQ= 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=mxuz63i8lZKDGG6JEmdUrkcEoFxRlCQdix3pMSi+Lx4=; b=Rz322uY9d/5BT+ApfmQXJ4P1M3h3mf8ZkGJCm1RH553kymZ09eabxsRVjZXv/E+06G PFO3uyUESjvgbKnf+eKfUgBZehUvxqJ4NXLGybZBG5W1CbXhGf/Dpjbaqfiu3m1nQDW1 GZe8OIGesKpqB7Oz4vHLHnz6cSufI7xGlZVLFlezyk97WFXytjwj0T8NG2BUHC2lXRfR ROk+kGUC8IkxFluwUY2xf4YPWG5u4J871peIwEnsWH8dU17ioQ/f96+uWBuv+eT8/a5C B/nTWa/jiABJ/Vrj9vMFM5HW9vXFiEiyXocCP5T8eKKdbGNImhrQr4vfWxFuZ4jg083Z EULg== X-Gm-Message-State: ALKqPwf3vRUtTZL210Ic12neVLD15SMFs8McsF0EiHSgvhb39U7wnzsL SFMSlZkkg0cySis2w7Ke9T+RnpZLY8g= X-Google-Smtp-Source: AB8JxZrki1Yj3OnkxA1DJPG53tiqMyYtkBee50O+/6GerY49Y7CBaFtcCCXP+urhLM35fqLn8FXuRQ== X-Received: by 2002:adf:b722:: with SMTP id l34-v6mr1848455wre.85.1527245384675; Fri, 25 May 2018 03:49:44 -0700 (PDT) Received: from guest2s-mbp.lan (235.91.125.91.dyn.plus.net. [91.125.91.235]) by smtp.gmail.com with ESMTPSA id u8-v6sm5829819wmc.40.2018.05.25.03.49.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 May 2018 03:49:43 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_96FA6BD7-D847-45CA-B22C-BB80D839940B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 25 May 2018 11:49:41 +0100 In-Reply-To: <90B044A3-14E2-4125-9A81-F49BEA144EF3@lodderstedt.net> Cc: oauth To: Torsten Lodderstedt References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> <90B044A3-14E2-4125-9A81-F49BEA144EF3@lodderstedt.net> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:49:50 -0000 --Apple-Mail=_96FA6BD7-D847-45CA-B22C-BB80D839940B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Torsten, > On 25 May 2018, at 10:35, Torsten Lodderstedt = wrote: >=20 > Hi Neil, >=20 >> Am 28.03.2018 um 17:41 schrieb Neil Madden = : >>=20 >> I like this draft, but I want to clarify if it is intended that the = response JWT could be interpreted as an OpenID Connect ID Token? As the = set of claims can overlap (in particular, all required ID token claims = are valid token introspection response fields) and it seems highly = likely that an AS will use the same keys for signing both (and it = definitely will when the client_secret is used for signing), the signed = response JWT could well be indistinguishable from an ID token (for the = resource owner) with some additional claims. >=20 > Conceptually, the introspection response, an ID Token and even = structured access tokens are quite the same if they carry user = identifiers or claims. They identify the respective user account towards = RP or RS and provide additional attributes, which, for example, can be = used to meet access control decisions. And if JWT is the representation, = they are also syntactically (nearly) equivalent. The main difference I = see that an ID Token may contain a nonce, which is not required in = access tokens. Are they the same? An ID token authenticates (claims about) a user to = the RP. I don=E2=80=99t think that is the intended interpretation of a = token introspection response, and it=E2=80=99s not the purpose of an = access token. My point is that as specified they can be syntactically = identical and yet intended for different purposes. >=20 >>=20 >> If this is not the case, then maybe consider adding a =E2=80=9Ccrit=E2=80= =9D: [=E2=80=9Cscope=E2=80=9D] claim to the response = (https://tools.ietf.org/html/rfc7515#section-4.1.11) to indicate that = the scope claim must be understood. >=20 > What do you want to achieve/prevent? The sorts of issues discussed in = https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-2.7 As I said in a follow-up email, =E2=80=9Ccrit=E2=80=9D does not actually = work here as it only applies to headers. If we wanted to distinguish = them, we could use explicit typing as recommended in the BCP: = https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-3.11 and = have a type of =E2=80=9Cintrospection+jwt=E2=80=9D or something like = that (with an appropriate media type registration). >=20 >>=20 >> I can think of one potential use-case (I=E2=80=99ll let you decide = the merits of it) where it might actually be useful to explicitly allow = the response to be an ID Token. Consider an application (RS) that uses a = traditional authorization model: it authenticates a user, sets a cookie, = and then based on who that user is makes dynamic access control = decisions to see what they are allowed to do (e.g., ACLs, RBAC, = whatever). An easy way to upgrade this app to modern standards would be = to replace the home-spun authentication system with OIDC, but leave the = rest in place. Now the system uses OIDC to authenticate the user, sets = the ID token as the cookie, and then still applies the same access = control decisions that it always has done. >>=20 >> Now imagine that a new requirement comes in to support OAuth 2.0 = access tokens to allow delegation to third-party apps. A really simple = way to achieve that would be to put a filter/reverse proxy in front of = the RS that extracts access tokens coming in, performs signed JWT token = introspection against the AS to validate the token and then checks the = the scopes are appropriate for the request. It can then simply replace = the access token in the original request with the signed token = introspection response (as ID token) and forward it on to the original = RS server. As the introspection response is a valid ID token for the = resource owner, the RS will then apply all its normal access control = checks to ensure that the resource owner actually has the permissions = that they have delegated to the client. >>=20 >> I think potentially that is quite an interesting application of this = draft, but I don=E2=80=99t think it was intended! I think probably a = decision should be made as to whether that kind of usage should be = allowed and explicitly adjust the draft to either allow or deny it. If = it is allowed, then possibly there should be a way for the caller to = hint that they want the response to be a valid ID token. >=20 > I don=E2=80=99t currently see a way the introspection response could = be abused as ID Token other than the recipient of the response (or an = attacker able to obtain the response object) sets up a fake IDP and = provides the response as an ID token to a RP. The RP should be able to = detect this (as other ways to replay ID tokens) by utilizing the nonce. As a client I can go and get an access token with some scope =E2=80=9Ca=E2= =80=9D. I now hit the token introspection endpoint and get back a signed = JWT. That signed JWT happens to be syntactically identical to an OIDC ID = Token and the AS happens to use the same key to sign both. So now I = effectively have an ID Token for that user, although I never requested = the =E2=80=9Copenid=E2=80=9D scope. OK, so I don=E2=80=99t have an = access token with the right scopes to hit the UserInfo endpoint, and I = learn nothing that I could not get from a normal introspection response, = but still it feels a bit surprising to me. Furthermore, as the =E2=80=9Caud=E2=80=9D claim in the token = introspection response is optional, and it has no nonce, I *might* be = able to replay this JWT in other situations to other parties. For = instance, if I can find an OIDC RP that does not use or validate nonces = correctly (they are optional), then I may be able to use it to log in as = the user at that other RP. I don=E2=80=99t think these are huge issues as they depend on RPs = already being careless about validation (e.g., ignoring a missing = audience claim), but they are the sort of non-obvious interactions = between components where security issues often crop up, so I want to = ensure the possibility has been considered by the WG and an informed = decision made either way. I would be happy if we just made the =E2=80=9Caud=E2=80=9D and =E2=80=9Cis= s=E2=80=9D claims mandatory in this spec (they are optional in RFC = 7662), and require that the protected resource is in the audience. =E2=80=94 Neil --Apple-Mail=_96FA6BD7-D847-45CA-B22C-BB80D839940B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy9aOUQwiH2bf8TjhkPhD307drF0FAlsH6kYACgkQkPhD307d rF1rxQ//UlWYOM6EegadtGENywrSI7qJWTozbXTffkTDp8HAqsIak+iWSlydiT8j 9AiEufMbnoxnKosoUwYUTKmPxCdAR0pzJSprAG0Jx54Qxj+hj2zbLAgrCfrftJs3 KbHzrI7hitIBJiTAFPh3fE1Fa2kdvyNuOkfgs3dqkgZoAfK6+wardjdgh1j7zik9 tlqf6HKPrfE4I8ErwxOF+gSXxgSgLV8XYfvV6lRDI3NYsi7vt/KqBIAGhqOPo9O+ 2HqBcyFT0Gr4c1y/2GZHyXdhimrGXeoFJ/7ypWinJTqLZyb0hTo5Z8VCkIhx4n+2 C8eqRACGOOUebshMzVO4ghGkKg+Ogqe+RYc80qPwAuW65T+nXyEOB/7vutNjLMml gviY8PdWPoVCTG9TsbGuPsekJN1j++VWJ6oOhlkjeLPQJfYf51RbVjYgelSaTV2L LRr5r7ARMkXRwdgUFUu7CQsp6U23Fgvc7FkLVZQJYbra99qE+6lPFIRVU0CDRLT4 WLH6oLucCPkV8vcE+B01VWiVLaD1Ikj6NbALo9kmdDnkuFM+F2Y0EHLq75szh5fL t5cTsFBOsmDl9aUBAIZIae+PR7DvJqIDfMpqsHAHmexJUFVwZORSseUsTojCN6Wt 9/E0CDU8v8mOqpUwbKKlVUhQC5mzBuVhNme68Hr/ssk58BpBR1Q= =wUZO -----END PGP SIGNATURE----- --Apple-Mail=_96FA6BD7-D847-45CA-B22C-BB80D839940B-- From nobody Fri May 25 08: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 89D8D12DB71 for ; Fri, 25 May 2018 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-stuttgart.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 Oumsm0FmLfqn for ; Fri, 25 May 2018 08:56:21 -0700 (PDT) Received: from mxex1.tik.uni-stuttgart.de (mxex1.tik.uni-stuttgart.de [129.69.192.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD8612E042 for ; Fri, 25 May 2018 08:56:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxex1.tik.uni-stuttgart.de (Postfix) with ESMTP id BAB3B7D078; Fri, 25 May 2018 17:56:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=dkim; i= @sec.uni-stuttgart.de; t=1527263777; x=1529002578; bh=hNP/WBIFUz G+U0TO+wQ1q/9kfhV2Bd5ZWCVafJEow3U=; b=Wuw88aVtsFaEeMJt0C20DIQ8E5 ny4eVtNm/gN7skrxyJk0WbRgMDYfrXQikPKKSxmfxz66YHPtzKuJ9d4d8QgP8L+G lWAV1d8Z1hBjIvHYP8mwUaadjjQvBSKLrXhjzMX9LuQI0NpmXemmn7SGziEIeaVY 7/EmJ7mMvVs6nSL8O6ZvmNyajg85PJEwgtvVZ7OW1AAzCjw8coeK2LS88rlGo9MZ wsejVlJs5/swPq7tHLZNM4Y4sq5k48k4rnVSFt7EAVIi1SaK2SzcM1UDBn2ALulD AJODV4jcCBNjLyROPAyiwmjzrOARjpRrZFbFFen9Lw6e97SKFA6KynbYArxA== X-Virus-Scanned: USTUTT mailrelay AV services at mxex1.tik.uni-stuttgart.de Received: from mxex1.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex1.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id r9gNa3FUq4Ls; Fri, 25 May 2018 17:56:17 +0200 (CEST) Received: from [IPv6:2001:7c0:2015:182::1:32] (unknown [IPv6:2001:7c0:2015:182::1:32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mxex1.tik.uni-stuttgart.de (Postfix) with ESMTPSA; Fri, 25 May 2018 17:56:15 +0200 (CEST) To: Brian Campbell Cc: oauth References: From: Daniel Fett Openpgp: preference=signencrypt Autocrypt: addr=daniel.fett@sec.uni-stuttgart.de; prefer-encrypt=mutual; keydata= xsFNBFbu2RUBEAC3F5+IMjFcXSj46xS8QQe6d/FAb+7IkkOdFKrINhgCialH4enWB2V3ykOX xESdrchRBCLoePyNmoJdFTijGxBMGNqSKU9rrppF5uvPFv/qIvCaBDAjFXR+qshsHjsMxTNH 67kuhkFQczKQHs4KVICG/gnssC3iejrk6Mav0MIJKXXdz6bUQPDyUTD+LsyHJ7vNfkfitnO4 rbD+kEZ0n14dQqp+c91b7X5KZVTt1c3d/N1kbruS29SlIDUJSHV0AdDZmP6wuH5a9XUIlDkP mM2bncIry3xiXWolYf3BJigxYg1XwVMYBdsrVg4kID5WY1RCHns07cDGluERcurjj3QHjToL T7VemcnFVzSphjjisi9a1QfRYCPf5xw5L8IjsAuNTBLv2DXKtL6Mf5Tv9BAZPD2em0rNS5n/ M7S6D2AAxIt9BQQ4aS16faI0gfUspj09RLdHANwOcLUPu+OE+O2IdgglBQLkadwLj9aY0ncE 8GhqFWcQ9xbtvHAljYaz5VmsOnjsadfGD8xW+QtWeFc8mfq7PncRjrc0Ywtb8TKeXkLHUQoT 4v2ilXisfOhryVj6/GuQvDjKKyUBW1tQPxei4n/W0zBC4LWehmwCH+WrFt+mTh3uHSyy9VbR FYmY6MBBMUpHHVQ3AVLgxoldu/yX/ery+fdE8MeScAWg+WE5rQARAQABzSBEYW5pZWwgRmV0 dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPsLBgAQTAQgAKgIbAwUJC0c1AAULCQgHAwUVCgkICwUW AgMBAAIeAQIXgAUCVu7cmAIZAQAKCRBYD1kOlZ2qqXCPD/wLpgL6j51OUlGzLaA+Xt+QzX/v qUiHJsvv1mEnyofk/3pGr7ce/1UNp7e8/W2JnnHvz4RBaNkn07DFyOvrVNXiMyU6mKWvG6xw Ri5Qc2t1Cup+mXlNc5fxlZGnwOYXZJErYVTPodkFlbb6LKUMyg6v2P7ZEvw4YyPh7WpV5ujF VVkYBSLviNCjVwKr8WlJJlVI4uvHZshnX85lVpRNcF+Hqf7IhnJzCQ5bUNnV7aKc4WPNw7L6 EquuCAl6JGKdeV2M+S5UVN9Eaa/CQxJf8X9I3SVgWCGQ/gLt0x1oKt6oFMECJcH2LDFOJyWv 61AUIzqCdRiTUagdc+7sn2OFbbjhKin9x+Qq6pyoXa6ZcpEuyBoAy+hNU8RAXcPgvEBy4Bwx BYQ9S3uQmBx/TcYgSUbBwBhvIYRVM5DfBefolj3HyUlvHx8JO8scbdcVl+v1+f9d5x4YS16t bWNe7awE6UWM2I02+uv7SI2ieJ2zQsOulDTEYVYjWcu0hBH24K53wniyh3JHzu6RVCgewx4P 6H2WHOSVf2p9ppuIrbWh7J6pp9nFdDXESKxH3GO5LooLamGugSlRwdgsqxY0O4BbCpKIpfe8 31peA+7qbh1f4TXHo/ZQE8fZ2s4VN5XR5J5/yjfqY2pWDy1XocixzXboLAcuzGmZNutS46eH Azjo2CxTa87BTQRW7tkVARAA1cAIBWNxYj/QE7RcOHGgr8xXcKWk/wwTWgLvjEbp5tqMl3Jk EwD1Iajz1s+Qp7U+U4UqyI+ZSfm03bYFYlTyKaS2esiM+Incutg18N943xwGNc6csyNoW5/f xbDQ4hoMKsod9zjfvxpA8xLg8gjuPKi5Y698K7qDCCfGvo6e67qwFWIvrB7cv/NAoaVd1OPI 79nt2H5yWo0PE2Kd2yAMnWJ/3clLR6X4jqkmpoc2uEPE6aM7iQ6SCx7rMFP9W9OvovnzVksS dh65JRkiA3DTUWBxZM6h/oEERBTr9Q/JYXXugO300loterwBVu0ymBHdAjIlxpetFwZu/Wlb nymC4VSxGPS/+mJ9Lnh3WWjVEcP5F9WgqmfJ49BNqOjmgZ9u9VYV8R9fOaYvtPFTdGTYT9iw JYic/0xt9NcW/hRkff0UHdiN/BrTxbHVI7Qf4MLBK/+VtqVi0MLs7U80/2fPRebTq4yQ6aoY 7hErExrJ7TgTmZghsBJTd2cmau26Kb7stLJ4ySADcyrsADl03MNoj8QqVuO8HXx2InM18sHP xldjovv8dhmj7uiKmMPAqq5f8pA5bcA/EQ6S+ItjjohSLiYQtq6UgDPlt4tIA9nCfx+cGi6f o4sJE0InaQLinm0USp0zE+slpqXGwjzeFSTioL81cDGhN3dcCK94VsntblsAEQEAAcLBZQQY AQgADwUCVu7ZFQIbDAUJC0c1AAAKCRBYD1kOlZ2qqdnTD/9fOyWwdhOv4ehtR8ShfhM1FAc8 bWMfCrxTpI4baPM4fqIFgMAJ9iQ0FF6cB0zQjDwsWNC+3t+2JdiNeM8FB7s4bbJlhjaavzKK 77Kbf4WpVs7ge0+Zghc2qHRg/SQeC1G26GzSZDDWzDHFZX0va8H0KmT/tHJYD263CIcff/E9 WXT/22rrgYvuQXPIOBzON9WqUkCAvPA19xuBsDQSbXkXwiPsZRqmyktjc8GQn1iemQ/dzlU/ e6ORNrPcK15kUyPyJMaZf+6QJ8EivUyg+pTXicEcghWNYHXxop4k0y+bsay0cBN2lmNu7UEF qhO8HQmp2jrwZXFZD/fbZukXFHNWvNsvQ55flUfajPZhUokXHskkerbq6ZCS58HkWl0tqSIb 5TxNfP0zjcrlDBc8sF6UHXgNR1oUXypGOAq4iHeJNVpI4aQm/PufmeGExx6lPtJxJ9jOs5gD rYRuBfa1cJznEPNbIe0/eCv5qDpf95csdGJhM418x2xeg58PbmBByS9MXOGFtli0K9sxIej/ YdA94hlk/R9ViIPDuqDxz0PP+IRFVVOQhOprSnG8cV31oOe00e1bIBH3ttdsgp3AHqz/zlfF kZt27s1VH+aRF4STntrU97dNmxrgjq8zUZ7VgYjq8KqLg0BsDRIy4b/AnptYh6E4oE74gKCo Qoim4V9DGw== Message-ID: <0a442cab-1d14-f592-7eed-c6ab52e8f7ca@sec.uni-stuttgart.de> Date: Fri, 25 May 2018 17:56:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------788E5209E17F39749CEC8474" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 15:56:25 -0000 This is a multi-part message in MIME format. --------------788E5209E17F39749CEC8474 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Ok, thanks! - Daniel Am 24.05.18 um 23:57 schrieb Brian Campbell: > Yeah, that's what is implied. At least given the way that > https://tools.ietf.org/html/draft-ietf-tokbind-https provides to > signal to the client to reveal the Referred Token Binding. > > I've heard that there's some potential for the Fetch spec to provide > some APIs or controls around Token Binding, which might facilitate > other ways of getting the Referred Token Binding into a request. But I > don't know the details or likelihood or timeline. And whatever form > that takes may or may not facilitate other options for 'front-channel' > requests to the authorization endpoint. > > > On Wed, May 23, 2018 at 10:27 AM, Daniel Fett > > wrote: > > > Just to clarify: This implies that there must be an HTTP(S) > request from the browser to the protected resource which then gets > redirected to the authorization endpoint. Is that correct? > > >   > > /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./ -- SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universitätsstraße 38 - 70569 Stuttgart - Room 2.434 --------------788E5209E17F39749CEC8474 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Ok, thanks!

- Daniel

Am 24.05.18 um 23:57 schrieb Brian Campbell:
Yeah, that's what is implied. At least given the way that https://tools.ietf.org/html/draft-ietf-tokbind-https provides to signal to the client to reveal the Referred Token Binding.

I've heard that there's some potential for the Fetch spec to provide some APIs or controls around Token Binding, which might facilitate other ways of getting the Referred Token Binding into a request. But I don't know the details or likelihood or timeline. And whatever form that takes may or may not facilitate other options for 'front-channel' requests to the authorization endpoint.


On Wed, May 23, 2018 at 10:27 AM, Daniel Fett <daniel.fett@sec.uni-stuttgart.de> wrote:

Just to clarify: This implies that there must be an HTTP(S) request from the browser to the protected resource which then gets redirected to the authorization endpoint. Is that correct?


 

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. 


-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434
--------------788E5209E17F39749CEC8474-- From nobody Sun May 27 08:25: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 500FE12EBC8 for ; Sun, 27 May 2018 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9sdFivKMjuHH for ; Sun, 27 May 2018 08:25:21 -0700 (PDT) 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 86B9812EB1B for ; Sun, 27 May 2018 08:25:21 -0700 (PDT) Received: from [84.158.233.58] (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 1fMxXq-0000n2-He; Sun, 27 May 2018 17:25:18 +0200 From: Torsten Lodderstedt Message-Id: <3E42FB35-E25B-44F1-8C57-04AF73D7DEF9@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_C63055C7-A910-4B41-AD87-649748BE370D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 27 May 2018 17:25:16 +0200 In-Reply-To: Cc: oauth To: Neil Madden References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> <90B044A3-14E2-4125-9A81-F49BEA144EF3@lodderstedt.net> X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 15:25:26 -0000 --Apple-Mail=_C63055C7-A910-4B41-AD87-649748BE370D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Neil, > Am 25.05.2018 um 12:49 schrieb Neil Madden = : >=20 > Hi Torsten, >=20 >> On 25 May 2018, at 10:35, Torsten Lodderstedt = wrote: >>=20 >> Hi Neil, >>=20 >>> Am 28.03.2018 um 17:41 schrieb Neil Madden = : >>>=20 >>> I like this draft, but I want to clarify if it is intended that the = response JWT could be interpreted as an OpenID Connect ID Token? As the = set of claims can overlap (in particular, all required ID token claims = are valid token introspection response fields) and it seems highly = likely that an AS will use the same keys for signing both (and it = definitely will when the client_secret is used for signing), the signed = response JWT could well be indistinguishable from an ID token (for the = resource owner) with some additional claims. >>=20 >> Conceptually, the introspection response, an ID Token and even = structured access tokens are quite the same if they carry user = identifiers or claims. They identify the respective user account towards = RP or RS and provide additional attributes, which, for example, can be = used to meet access control decisions. And if JWT is the representation, = they are also syntactically (nearly) equivalent. The main difference I = see that an ID Token may contain a nonce, which is not required in = access tokens. >=20 > Are they the same? An ID token authenticates (claims about) a user to = the RP. The same definition holds true for access tokens towards RSs. > I don=E2=80=99t think that is the intended interpretation of a token = introspection response, and it=E2=80=99s not the purpose of an access = token. My point is that as specified they can be syntactically identical = and yet intended for different purposes. The difference is just the role the party is taking in the overall = protocol flow. In my experience, contents of access tokens and contents = of ID tokens tend to be rather similar, at least in the consumer = identity space.=20 >=20 >>=20 >>>=20 >>> If this is not the case, then maybe consider adding a =E2=80=9Ccrit=E2= =80=9D: [=E2=80=9Cscope=E2=80=9D] claim to the response = (https://tools.ietf.org/html/rfc7515#section-4.1.11) to indicate that = the scope claim must be understood. >>=20 >> What do you want to achieve/prevent? >=20 > The sorts of issues discussed in = https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-2.7 >=20 > As I said in a follow-up email, =E2=80=9Ccrit=E2=80=9D does not = actually work here as it only applies to headers. If we wanted to = distinguish them, we could use explicit typing as recommended in the = BCP: = https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03#section-3.11 and = have a type of =E2=80=9Cintrospection+jwt=E2=80=9D or something like = that (with an appropriate media type registration). The text also states "Note that this is a specific type of substitution = attack.=E2=80=9C and I fully agree with this assessment. In my opinion, = the consequence is that all the countermeasures available for token = substitution can and must be used to detect such misuse. In the = particular case of an an attacker wanting to use a token introspection = response JWT as ID token in a different flow, all security checks = defined by OpenId Connect = (http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) = must be performed. This means the RP must, for example, validate issuer, = audience and nonce. This should be sufficient to prevent any kind of = abuse. >=20 >>=20 >>>=20 >>> I can think of one potential use-case (I=E2=80=99ll let you decide = the merits of it) where it might actually be useful to explicitly allow = the response to be an ID Token. Consider an application (RS) that uses a = traditional authorization model: it authenticates a user, sets a cookie, = and then based on who that user is makes dynamic access control = decisions to see what they are allowed to do (e.g., ACLs, RBAC, = whatever). An easy way to upgrade this app to modern standards would be = to replace the home-spun authentication system with OIDC, but leave the = rest in place. Now the system uses OIDC to authenticate the user, sets = the ID token as the cookie, and then still applies the same access = control decisions that it always has done. >>>=20 >>> Now imagine that a new requirement comes in to support OAuth 2.0 = access tokens to allow delegation to third-party apps. A really simple = way to achieve that would be to put a filter/reverse proxy in front of = the RS that extracts access tokens coming in, performs signed JWT token = introspection against the AS to validate the token and then checks the = the scopes are appropriate for the request. It can then simply replace = the access token in the original request with the signed token = introspection response (as ID token) and forward it on to the original = RS server. As the introspection response is a valid ID token for the = resource owner, the RS will then apply all its normal access control = checks to ensure that the resource owner actually has the permissions = that they have delegated to the client. >>>=20 >>> I think potentially that is quite an interesting application of this = draft, but I don=E2=80=99t think it was intended! I think probably a = decision should be made as to whether that kind of usage should be = allowed and explicitly adjust the draft to either allow or deny it. If = it is allowed, then possibly there should be a way for the caller to = hint that they want the response to be a valid ID token. >>=20 >> I don=E2=80=99t currently see a way the introspection response could = be abused as ID Token other than the recipient of the response (or an = attacker able to obtain the response object) sets up a fake IDP and = provides the response as an ID token to a RP. The RP should be able to = detect this (as other ways to replay ID tokens) by utilizing the nonce. >=20 > As a client I can go and get an access token with some scope =E2=80=9Ca=E2= =80=9D. I now hit the token introspection endpoint and get back a signed = JWT. That signed JWT happens to be syntactically identical to an OIDC ID = Token and the AS happens to use the same key to sign both. So now I = effectively have an ID Token for that user, although I never requested = the =E2=80=9Copenid=E2=80=9D scope. OK, so I don=E2=80=99t have an = access token with the right scopes to hit the UserInfo endpoint, and I = learn nothing that I could not get from a normal introspection response, = but still it feels a bit surprising to me. >=20 > Furthermore, as the =E2=80=9Caud=E2=80=9D claim in the token = introspection response is optional, and it has no nonce, I *might* be = able to replay this JWT in other situations to other parties. For = instance, if I can find an OIDC RP that does not use or validate nonces = correctly (they are optional), then I may be able to use it to log in as = the user at that other RP. Good point. I think that would work for an RP using the id_token (or a = hybrid) response type. But the RP MUST validate the aud claim. >=20 > I don=E2=80=99t think these are huge issues as they depend on RPs = already being careless about validation (e.g., ignoring a missing = audience claim), but they are the sort of non-obvious interactions = between components where security issues often crop up, so I want to = ensure the possibility has been considered by the WG and an informed = decision made either way. I fully agree. I would like to prevent a situation where somebody = believes we need to adopt a different syntax in order to prevent such = "Cross-JWT Confusion=E2=80=9C attacks.=20 >=20 > I would be happy if we just made the =E2=80=9Caud=E2=80=9D and = =E2=80=9Ciss=E2=80=9D claims mandatory in this spec (they are optional = in RFC 7662), and require that the protected resource is in the = audience. Makes sense. I will add this to the draft.=20 thanks, Torsten. >=20 > =E2=80=94 Neil >=20 --Apple-Mail=_C63055C7-A910-4B41-AD87-649748BE370D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNTI3MTUyNTE2WjAjBgkqhkiG9w0BCQQxFgQUr0Affv+s71E2 damh3zlJN1yV89Ywgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAEA9weuKQ++krIbjcAE5dEpm+1jnLFmaZ7te/pmKfx9MHl/mkGY5 s5WtPO34j2yUA4m8zaMjwquzU3xGbmHsn0GZW8sMf319L4UDXShcIK0uv9vP0Z46ElNhrL/7JvgU Ts9PQkKDe+gJWhiRMexoosRkU/4t4LgwZ3sayiHznyA/Q+16sJnBpv8yZAFrQOlEcTO/AjGR8wN0 7etNdQP0XJXoPjxUTgc1jQp7hwvdzeuknjt5m+H8ERX2GEnQT99GMOkxWK0JkXahpa+bYzROmOdG V1WRt2CTKIwMugwNPPscSIbuNI3/bKDHGO5dY31nJ/metHtglD6mVSMyQpy2dPkAAAAAAAA= --Apple-Mail=_C63055C7-A910-4B41-AD87-649748BE370D-- From nobody Mon May 28 09:59:06 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 E71AF12D948 for ; Mon, 28 May 2018 09:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dzwmNEFjs3Kd for ; Mon, 28 May 2018 09:59:01 -0700 (PDT) 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 4145212D775 for ; Mon, 28 May 2018 09:59:01 -0700 (PDT) Received: from [84.158.233.58] (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 1fNLU2-0004WB-FC for oauth@ietf.org; Mon, 28 May 2018 18:58:58 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_25579D68-0221-44B5-913B-86178DB425B0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <4D24E05B-EDC1-458C-A106-662345090399@lodderstedt.net> References: <152752608213.4961.1659822390005305046.idtracker@ietfa.amsl.com> To: oauth Date: Mon, 28 May 2018 18:58:55 +0200 X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 16:59:05 -0000 --Apple-Mail=_25579D68-0221-44B5-913B-86178DB425B0 Content-Type: multipart/alternative; boundary="Apple-Mail=_E000214C-BE9B-41E9-8EFF-341BEE30A60D" --Apple-Mail=_E000214C-BE9B-41E9-8EFF-341BEE30A60D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 I just published a new revision of the JWT Introspection response draft. = Based on the feedback in London, the draft entirely focuses on use cases = where the RS requires stronger assurance that the respective AS issued = the token, including cases where the AS assumes liability for the = token=E2=80=99s content.=20 We incorporated the following changes: =E2=80=A2 fixed typos in client meta data field names (thanks = Petteri!) =E2=80=A2 added OAuth Server Metadata parameters to publish = algorithms supported for signing and encrypting the introspection = response =E2=80=A2 added registration of new parameters for OAuth Server = Metadata and Client Registration =E2=80=A2 added explicit request for JWT introspection response =E2=80=A2 made iss and aud claims mandatory in introspection = response (thanks Neil!) =E2=80=A2 Stylistic and clarifying edits, updates references Thanks to all reviewers! Vladimir and I are on the fence whether the Introspection Response = format should be determined by the AS based on its policy and/or = RS-related registration metadata or whether the RS should explicitly = request a JWT response by including an Accept header = =E2=80=9Eapplication/jwt=E2=80=9C in the respective request.=20 What do you think? kind regards, Torsten. > Anfang der weitergeleiteten Nachricht: >=20 > Von: internet-drafts@ietf.org > Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-01.txt > Datum: 28. Mai 2018 um 18:48:02 MESZ > An: "Vladimir Dzhuvinov" , "Torsten = Lodderstedt" >=20 >=20 > A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-01.txt > has been successfully submitted by Torsten Lodderstedt and posted to = the > IETF repository. >=20 > Name: draft-lodderstedt-oauth-jwt-introspection-response > Revision: 01 > Title: JWT Response for OAuth Token Introspection > Document date: 2018-05-28 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-01.txt > Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ > Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-jwt-introspect= ion-response-01 >=20 > Abstract: > This draft proposes an additional JSON Web Token (JWT) based = response > for OAuth 2.0 Token Introspection. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_E000214C-BE9B-41E9-8EFF-341BEE30A60D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all, 

I just = published a new revision of the JWT Introspection response draft. Based = on the feedback in London, the draft entirely focuses on use cases where = the RS requires stronger assurance that the respective AS issued the = token, including cases where the AS assumes liability for the token=E2=80=99= s content. 

We incorporated the following changes:
=E2=80=A2 fixed typos in client = meta data field names (thanks Petteri!)
= =E2=80=A2 added OAuth Server Metadata parameters to publish = algorithms supported for signing and encrypting the introspection = response
=E2=80=A2 = added registration of new parameters for OAuth Server Metadata and = Client Registration
=E2=80=A2 = added explicit request for JWT introspection response
=E2=80=A2 made iss and aud claims = mandatory in introspection response (thanks Neil!)
=E2=80=A2 Stylistic and = clarifying edits, updates references

Thanks to all reviewers!

Vladimir and I are on the fence whether the = Introspection Response format should be determined by the AS based on = its policy and/or RS-related registration metadata or whether the RS = should explicitly request a JWT response by including an Accept header = =E2=80=9Eapplication/jwt=E2=80=9C in the respective = request. 

What do you = think?

kind = regards,
Torsten.

Anfang der weitergeleiteten = Nachricht:

Von: = internet-drafts@ietf.org
Betreff: = New Version = Notification for = draft-lodderstedt-oauth-jwt-introspection-response-01.txt
Datum: = 28. Mai 2018 um 18:48:02 = MESZ
An: = "Vladimir Dzhuvinov" <vladimir@connect2id.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>


A new version = of I-D, draft-lodderstedt-oauth-jwt-introspection-response-01.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name: = = draft-lodderstedt-oauth-jwt-introspection-response
Revision: 01
Title: JWT = Response for OAuth Token Introspection
Document date: = 2018-05-28
Group: Individual Submission
Pages:= = 10
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jw= t-introspection-response-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-in= trospection-response/
Htmlized: =       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introsp= ection-response-01
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-j= wt-introspection-response
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-jwt= -introspection-response-01

Abstract:
  This draft proposes an additional JSON Web Token = (JWT) based response
  for OAuth 2.0 Token = Introspection.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_E000214C-BE9B-41E9-8EFF-341BEE30A60D-- --Apple-Mail=_25579D68-0221-44B5-913B-86178DB425B0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNTI4MTY1ODU2WjAjBgkqhkiG9w0BCQQxFgQUHu8oJRUDKUP/ ro/9eNI3+cFsohQwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAH6XippFR7k7LBbTIT/9TW0PJRJsIJwxbem3M3KoNILYGtLro++0 qguXCt+xTsnUYmX/pmen9BS9KmwvACGnJugHKApEl0UmUOitdj7/r82RteowELMIFXuJYvexDQzO xmorwCQlo67xisFYEKKg4194hmGy9lyMNxdTUePwL4vK2OhYMGlEFAvlQg0c9+9B4q4Yy1ojHZZm 6Wx+FLo92jPiKmvI2+eO2D7UCzaGL036AVU3YY7FA/lChVk0OFgeqNx3fkIMgZswM2BFESfgYbFM Ap0Nke3EHrw3Ytvt+lTj6AD76N/sJIEV+7YTLJpzG8kPdVYxHscKdeHaV9fjYpkAAAAAAAA= --Apple-Mail=_25579D68-0221-44B5-913B-86178DB425B0-- From nobody Tue May 29 15:13: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 A7D23127871 for ; Tue, 29 May 2018 15:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 fzy3-l9QEwzV for ; Tue, 29 May 2018 15:13:14 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 27CF8127909 for ; Tue, 29 May 2018 15:13:14 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id t27-v6so14545265oij.9 for ; Tue, 29 May 2018 15:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CVeWq6m4X31QiQs93hFu1uR0lfbUeY1yKQ/ZMDnBkp8=; b=nzYsJxU8aZF/kS7/BRGyITNgWMl2Q8xRW/9cxFoQUO3J0ktKS5LbkrZn87s8EEd5Lo PbVSxayKmmpHsTMSgYb70bPb3fxBYHR1cp47se7zc4EOiNCkYFR1cM7jsUQRwTUyp17L WfY6hG1TZn3qNYrDOyAYDn7SFBxiOdxlRJpRAnQzhrokZnfAyFkkM0/tV7Ld54EKstan /jzirCRUEx+kw5b5fM5nKxumE+ZkoxN2uzwENdhRA9r1A2b6ehm5H0A+Rxwm326luZe1 8LYJf4/Uy4ut6ptPt5/BRuHkruUCAliv3sqM1/mJtu8VwKvO832sg4+Vj9DiaFWHfngt TmwQ== 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=CVeWq6m4X31QiQs93hFu1uR0lfbUeY1yKQ/ZMDnBkp8=; b=WO2xqajhvu0lspuFUgfCBYBuHQCdczuCmfS6vhbbYeccnuXyCXZEjvLTVjwpZrML5G Ij46Te4HcFiX/WQK8uef8okFk4YRV09KrAKh+yt2Ca+8RfPBRHIUmnD4tnITUMqmWVD4 XqSK/PJFfREP7G3W+77WmLZhQL0elizu3jyl9dANAXc37d0hGViq0V9Qa9q3fx/tjEE9 SxGqSNWHR51flBAkb7z+RVm3Hbiz4x2tlHRLO9bQDNg/lqBYwXuZqXc9eptcnOsUh6aR t6jnqPuc8Yqq4KnVA4hgJevv6MlxYJl2wj9DxYg9rHGWWOeHGyQZ4dFPG7f+9JNLT4ta dZaA== X-Gm-Message-State: APt69E2e5NFIOWj8v6plfk0bkWhn0PVQVRBGC6i+REyDC3mWIN1aXcRY TG0OMFK/H7ER+vaa9oaJ0os5VyDPZegO8u1xiR/4xA== X-Google-Smtp-Source: ADUXVKKztKU64GzV+bInHHGrAWutU4coQNaBX+/OEu11RXLqjRPy25866YZQUYifb04XEDVbJrXftoewzMvGwDQToV8= X-Received: by 2002:aca:3c8b:: with SMTP id j133-v6mr144513oia.91.1527631993530; Tue, 29 May 2018 15:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Tue, 29 May 2018 15:12:33 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 29 May 2018 15:12:33 -0700 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000052767a056d5f8ae6" Archived-At: Subject: Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 22:13:17 -0000 --00000000000052767a056d5f8ae6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable LGTM. Issuing LC. On Mon, Apr 23, 2018 at 12:20 PM, Mike Jones wrote: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09 Sections 5.2 > and 5.3 contain the confused deputy attack updates described in John=E2= =80=99s > response during London. > > > > -- Mike > > > > *From:* Eric Rescorla > *Sent:* Friday, April 13, 2018 7:37 PM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 > > > > Thanks for the quick followup. I will take a look at the next version > > > > -Ekr > > > > > > On Fri, Apr 13, 2018 at 6:06 PM, Mike Jones > wrote: > > We still need to add the text addressing the points described in John > Bradley=E2=80=99s reply to you sent while in London. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *Eric Rescorla > *Sent:* Friday, April 13, 2018 6:00 PM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 > > > > Hi folks, > > > > I just looked at the -08 diffs and I see a new section on brute forcing > the token > > but not describing the confused deputy attack. Did I miss something, or > were you > > still planning to add more text? > > > > Thanks > > -Ekr > > > > > > > --00000000000052767a056d5f8ae6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM. Issuing LC.

On Mon, Apr 23, 2018 at 12:20 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

https:/= /tools.ietf.org/html/draft-ietf-oauth-device-flow-09 =C2=A0Section= s 5.2 and 5.3 contain the confused deputy attack updates described in John=E2=80=99s response during London.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mik= e

=C2=A0

From: Eric Rescorla <ekr@rtfm.com>
Sent: Friday, April 13, 2018 7:37 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-0<= wbr>8

=C2=A0

Thanks for the quick followup. I will take a look at= the next version

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Fri, Apr 13, 2018 at 6:06 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

We still need to add t= he text addressing the points described in John Bradley=E2=80=99s reply to = you sent while in London.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=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 Eric Rescorla
Sent: Friday, April 13, 2018 6:00 PM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-0= 8

=C2=A0

Hi folks,

=C2=A0

I just looked at the -08 diffs and I see a new secti= on on brute forcing the token

but not describing the confused deputy attack. Did I= miss something, or were you

still planning to add more text?

=C2=A0

Thanks

-Ekr

=C2=A0

=C2=A0

=C2=A0


--00000000000052767a056d5f8ae6-- From nobody Tue May 29 15:20: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 5AE4E12EC8A for ; Tue, 29 May 2018 15:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 aD3Jejrmhoyt for ; Tue, 29 May 2018 15:19:58 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 32C8912FA7A for ; Tue, 29 May 2018 15:19:58 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id f79-v6so606189oib.7 for ; Tue, 29 May 2018 15:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZPTzh+xOOQ5F3jlHrZ9tkQ/9PQDTE0zpSzBPrqpSoVA=; b=yCscYQa4Ns5lb+68Z6Lwq9VDTSXToC10wTzHzfoNPvpqxh7ki+zG5ldtYa5vYZr7wR qhqaHGpLSYgk3E9m4cxu2aHaZ55u+elrYLkS0HDbzVFn44hUu13QGeuD/IRk05/5Qgab ja9WUhsTZTzMGhSK7Fg6LT9t2A8Lbrv2q40492HJnQY0/iSadZPSKBWvQA/Wh5mkz+O9 ldm2F8PFAMTwV6Z9wH+gbar0bIfTJyvRjJvuvz3IeLRSz8keDjYN+ECsGQ4YX7eOluAJ 4G2VoIQ+qrDPhZhtvht4VtHb0vr22+RuVq39V6Tx63pjuVJDGAg450K60hm5LcVCjNn6 SVvg== 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=ZPTzh+xOOQ5F3jlHrZ9tkQ/9PQDTE0zpSzBPrqpSoVA=; b=NYu2f81A3A8Mk9qbsM6EuFg3SMaIcH+PAUjrbk1bADQDNFNsy2KZqsegiTm4r2KTbl FHgVZvzbnIjnnZVoy/q+q62lsJkZ9ifwMEytqAMniMam57Gwx9zBDHtKaasU1gtX43kp TWiRWzt9Ss3ta1wjbB3cOUtAzupXG829PjK0QSicf7WeYYGJf3krN/Vy1KqKWtpXlJpS T2ozxc67svR9SI1QJa4JmyaFN3X1Gbxn9eLB8baiwgmninChFb98eR9LEqsZLw8c8/9G liTRA12Xvqvfs+1khgnFOY6NbnLlKm+dZzvHXRuZmHzj+dvX31B5QjfkhpcmoOS7hVec /D1w== X-Gm-Message-State: APt69E2pmKBGij7f3RjYnwfPKr1CDUjLeXM0++AgcOK4a1BZ1sboZ2/9 blJoPBHLPhReeUVdF6/WF38IX4pCS57ZinG/mF2ZYw== X-Google-Smtp-Source: ADUXVKJx1UDN5gOIQKCZcuzr0hiW8GZUfUXXGurBzkQAFP0lv3Apfwe/TzGME5XtIBkstQbjqRPQ4i68g+M46wfENQc= X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr168844oin.108.1527632397564; Tue, 29 May 2018 15:19:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Tue, 29 May 2018 15:19:17 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 29 May 2018 15:19:17 -0700 Message-ID: To: Brian Campbell Cc: Bill Burke , Mike Jones , oauth Content-Type: multipart/alternative; boundary="00000000000067935b056d5fa234" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 22:20:03 -0000 --00000000000067935b056d5fa234 Content-Type: text/plain; charset="UTF-8" Hi Brian, To be clear, I'm not opposing Delegation. My concern here is that we have a chain of signed assertions and I'm trying to understand how I as a consumer of those assertions am supposed to evaluate it. I don't think it's sufficient to just say that that the access control rules are local policy, because then the entity generating the signature has no way of knowing how its signature will be used. To go back to the case I gave in my initial e-mail, say we have a chain A->B->C and a resource that A and C could ordinarily not access, but B can. If C has this delegation, can C access the resource? I.e., is B giving C his authority or just passing on A's authority? It seems pretty important for B to know that before he gives the token to C. -Ekr On Thu, May 17, 2018 at 11:06 AM, Brian Campbell wrote: > Delegation has been in the document since its inception and throughout the > three and a half years as a working group document. > > From a process point of view, the document is now in AD Evaluation. I > worked through a number of questions and clarifications with Eric (said > AD), however he raised the particular questions that started this thread on > the WG list. And I responded with an attempt at addressing those questions. > That was about a month ago. > > Eric, was my explanation helpful in clarify anything for you? Is there > some text that you'd like to see added? Something else? I'm unsure how to > proceed but would like to move things forward. > > > On Thu, May 17, 2018 at 8:03 AM, Bill Burke wrote: > >> This is an honest question: How important is the actor stuff to the >> players involved? Are people going to use it? IMO, its an edge case >> and I think more important areas, like external token exchange (realm >> to realm, domain to domain) are being neglected. I'm quite unfamiliar >> how consensus is reached in this WG or the IETF, so I hope I'm not >> sounding rude. Just trying to provide some constructive feedback. >> >> >> >> On Thu, May 17, 2018 at 9:26 AM, Mike Jones >> wrote: >> > Moving the actor claim to a separate specification would only make >> things more complicated for developers. There already plenty of OAuth >> specs. Needlessly adding another one will only make related things harder >> to find. >> > >> > Just like in the JWT [RFC 7519] spec itself in which use of all the >> claims is optional, use of the actor claim in this spec. If you don't need >> it, don't use it. Just because some won't use it is no better an argument >> for moving it to a different spec than the argument that JWT should have >> defined each of its claims in different specs. That would have made things >> harder, not easier. >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: OAuth On Behalf Of Bill Burke >> > Sent: Thursday, May 17, 2018 2:11 PM >> > To: Brian Campbell >> > Cc: oauth >> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang >> e-12.txt >> > >> > My personal opinion is that I'm glad this actor stuff is optional. >> > For one, none of our users have asked for it and really only do simple >> exchanges. Secondly, the rules for who can exchange what for what is >> controlled and defined within our AS. Makes things a lot simpler on the >> client. I kind of wish the actor stuff would be defined in a separate >> specification. I don't see us implementing it unless users start asking us >> to. >> > >> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Well, it's already called the "actor claim" so the claimed part is >> >> kind of implied. And "claimed actor claim" is a rather awkward. >> >> Really, all JWT claims are "claimed something" but they don't include >> >> the "claimed" bit in the name. RFC 7519, for example, defines the >> >> subject claim but not the claimed subject claim. >> >> >> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: >> >>> >> >>> Brian, >> >>> >> >>> Eric said: "what is the RP supposed to do when they encounter it? >> >>> This seems kind of under specified". >> >>> >> >>> After reading your explanations below, it looks like the RP can do >> >>> anything he wants with the "actor". >> >>> It is a "claimed actor" and, if we keep the concept, it should be >> >>> called as such. Such a claim cannot be verified. >> >>> A RP could copy and paste that claim in an audit log. No standard >> >>> action related to the content of such a claim can be specified in the >> >>> spec. If the content of a "claimed actor" is used by the RP, it >> >>> should be only used as an hint and thus be subject to other >> >>> verifications which are not specified in this specification. >> >>> >> >>> Denis >> >>> >> >>> Eric, I realize you weren't particularly impressed by my prior >> >>> statements about the actor claim but, for lack of knowing what else >> >>> to say, I'm going to kind of repeat what I said about it over in the >> >>> Phabricator tool and add a little color. >> >>> >> >>> The actor claim is intended as a way to express that delegation has >> >>> happened and identify the entities involved. Access control or other >> >>> decisions based on it are at the discretion of the consumer of the >> >>> token based on whatever policy might be in place. >> >>> >> >>> There are JWT claims that have concise processing rules with respect >> >>> to whether or not the JWT can be accepted as valid. Some examples are >> "aud" >> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC >> 7519. >> >>> E.g. if the token is expired or was intended for someone or something >> >>> else, reject it. >> >>> >> >>> And there are JWT claims that appropriately don't specify such >> >>> processing rules and are solely statements of fact or circumstance. >> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims >> are good examples of such. >> >>> There might be application or policy specific rules applied to the >> >>> content of those kinds of claims (e.g. only subjects from a >> >>> particular organization are able to access tenant specific data or, >> >>> less realistic but still possible, disallow access for tokens issued >> >>> outside of regular business >> >>> hours) but that's all outside the scope of a specification's >> >>> definition of the claim. >> >>> >> >>> The actor claim falls into the latter category. It's a way for the >> >>> issuer of the token to tell the consumer of the token what is going >> >>> on. But any action to take (or not) based on that information is at >> >>> the discretion of the token consumer. I honestly don't know it could >> >>> be anything more. And don't think it should be. >> >>> >> >>> There are two main expected uses of the actor claim (that I'm aware >> >>> of >> >>> anyway) that describing here might help. Maybe. One is a human to >> >>> human delegation case like a customer service rep doing something on >> >>> behalf of an end user. The subject would be that user and the actor >> >>> would be the customer service rep. And there wouldn't be any chaining >> >>> or nesting of the actor. The other case is so called service chaining >> >>> where a system might exchange a token it receives for a new token >> >>> that it can use to call a downstream service. And that service in >> >>> turn might do another exchange to get a new token suitable to call >> >>> yet another downstream service. And again and so on and turtles all >> >>> the way. I'm not necessarily endorsing that level of granularity in >> >>> chaining but it's bound to happen somewhere/sometime. The nested >> >>> actor claim is able to express that all that has happened with the >> >>> top level or outermost one being the system currently using the token >> >>> and prior systems being nested.. What actually gets done with that >> >>> information is up to the respective systems involved. There might be >> >>> policy about what system is allowed to call what other system that is >> >>> enforced. Or maybe the info is just written to an audit log >> >>> somewhere. Or something else. I don't know. But whatever it is >> application/deployment/policy dependent and not specifiable by a spec. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: >> >>>> >> >>>> Hi folks, >> >>>> >> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem >> >>>> generally OK. I do still have one remaining concern, which is about >> >>>> the actor claim. Specifically, what is the RP supposed to do when >> >>>> they encounter it? This seems kind of underspecified. >> >>>> >> >>>> In particular: >> >>>> >> >>>> 1. What facts am I supposed to know here? Merely that everyone in >> >>>> the chain signed off on the next person in the chain acting as >> them? >> >>>> >> >>>> 2. Am I just supposed to pretend that the person presenting the token >> >>>> is the identity at the top of the chain? Say I have the >> >>>> delegation A -> B -> C, and there is some resource which >> >>>> B can access but A and C cannot, should I give access? >> >>>> >> >>>> I think the first question definitely needs an answer. The second >> >>>> question I guess we could make not answer, but it's pretty hard to >> >>>> know how to make a system with this left open.. >> >>>> >> >>>> -Ekr >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> Bill Burke >> Red Hat >> > > > *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.* --00000000000067935b056d5fa234 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

To be clear, I'= ;m not opposing Delegation. My concern here is that we have a chain of sign= ed assertions and I'm trying to understand how I as a consumer of those= assertions am supposed to evaluate it.

I don'= t think it's sufficient to just say that that the access control rules = are local policy, because then the entity generating the signature has no w= ay of knowing how its signature will be used.

To g= o back to the case I gave in my initial e-mail, say we have a chain A->B= ->C and a resource that A and C could ordinarily not access, but B can. = If C has this delegation, can C access the resource? I.e., is B giving C hi= s authority or just passing on A's authority? It seems pretty important= for B to know that before he gives the token to C.

-Ekr


On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Delegation has been in the document sin= ce its inception and throughout the three and a half years as a working gro= up document.

From a process point of view, th= e document is now in=C2=A0AD Evaluation. I worked through a number of quest= ions and clarifications with Eric (said AD), however he raised the particul= ar questions that started this thread on the WG list. And I responded with = an attempt at addressing those questions. That was about a month ago.
<= /div>

Eric, was my explanation helpful in clarify anythi= ng for you? Is there some text that you'd like to see added? Something = else? I'm unsure how to proceed but would like to move things forward.<= br>


On Thu, May 17, 2018 at 8:03 AM, Bill Burke <bburke@red= hat.com> wrote:
This is an = honest question: How important is the actor stuff to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> prohibited..=C2=A0 If you have received this communication in = error,
>>> please notify the sender immediately by e-mail and delete the = message
>>> and any file attachments from your computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s).= Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..=C2=A0 If you have received this communication in erro= r, please
>> notify the sender immediately by e-mail and delete the message and= any
>> file attachments from your computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


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

<= /div> --00000000000067935b056d5fa234-- From nobody Tue May 29 15:20:41 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 E20E412FAC5; Tue, 29 May 2018 15:20:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, draft-ietf-oauth-device-flow@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2018 15:20:30 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 22:20:39 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for Browserless and Input Constrained Devices' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This OAuth 2.0 authorization flow for browserless and input constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream) draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile (None - ) rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF stream) From nobody Wed May 30 08:48: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 145E412DA22 for ; Wed, 30 May 2018 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 gcEV9B01y2kD for ; Wed, 30 May 2018 08:48:53 -0700 (PDT) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CC412E872 for ; Wed, 30 May 2018 08:48:53 -0700 (PDT) Received: by mail-lf0-x242.google.com with SMTP id v135-v6so5053802lfa.9 for ; Wed, 30 May 2018 08:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=drZpu14Inq/MTa6J+Nr/AbDxTHRpi8ZlqLdfxj7kjZM=; b=DvjHYlAyw5NdZ2fEyQ7rU652bYzDkAxADDL3oEYd2PH2ZIlsZpa6ABw6G3mHSHlSut RI34H76ed0oS84SFobK4bpxLvkb7hm7NzEpDP4OtLMyqTFOO3O71GbQ7nYIxDD99GK9E ARNVvhiWRkFB3IYc8Lqzm1tqk8FajaSfCP3Jw= 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=drZpu14Inq/MTa6J+Nr/AbDxTHRpi8ZlqLdfxj7kjZM=; b=ilJVXIZLcaklBO8oUzqF3XfRSQc+FoV7bT08OgognWtWI5f6kR85XOK+z1hFTLG+JC Ek7/XiQfqIje7KFZHF3oQSt4AGbYQJvvqztby75avFq8gCofShHLONWGxvF6ytbiT1a9 M11bIKgZoJAkvgiQVIDp9ggqoUHoP0BMBBxSeVSMSFUs6LwNQnNv0DJs/fNe7Qew6Gzw Oirel3TddhjHjwPX/akMnuKitSNLQkVF/sXsWIhPhdFP79Qmozlqp5V/JF/1u5xpLVfk LPhdp+RxRZe8dbOBGj5JrAmHYbm5c//UR00wTsS1YsgxjKxr0mKhInZzY3LOZOZbnFqq SBcQ== X-Gm-Message-State: ALKqPwcmmCGINKLbNH/jIDhjgeAAzMDda9FVAh3A0wTYaeB3ohJSuudr wbhTKx4s2ixQEPHVsBkxma0HItiTUO9a1rlmiSD0puFrelZitPYxdwIh+PwWvhHIF8zc6JCgjvE 2iyOrZ0WYf9rK7A== X-Google-Smtp-Source: ADUXVKIQX08jYhrgfIxm/O8Yvjpg/7syNyla0J0zNxu+CefuhsfrVXDiwbhORwhhP14lr0hS1S/V7Y2SHaNz0d0T3FM= X-Received: by 2002:a19:c7c8:: with SMTP id x191-v6mr1983744lff.122.1527695331183; Wed, 30 May 2018 08:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:4e19:0:0:0:0:0 with HTTP; Wed, 30 May 2018 08:48:50 -0700 (PDT) In-Reply-To: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: Eric Fazendin Date: Wed, 30 May 2018 09:48:50 -0600 Message-ID: To: draft-ietf-oauth-device-flow@ietf.org Cc: oauth@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a976f056d6e49fe" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 15:48:56 -0000 --0000000000008a976f056d6e49fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, just found a minor typo: Section 6.1: *through* their length needs to be longer to maintain a high entropy. Should be: *though* their length needs to be longer to maintain a high entropy. On Tue, May 29, 2018 at 4:20 PM, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for > Browserless and Input Constrained Devices' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > the Subject line to allow automated sorting. > > Abstract > > > This OAuth 2.0 authorization flow for browserless and input > constrained devices, often referred to as the device flow, enables > OAuth clients to request user authorization from devices that have an > Internet connection, but don't have an easy input method (such as a > smart TV, media console, picture frame, or printer), or lack a > suitable browser for a more traditional OAuth flow. This > authorization flow instructs the user to perform the authorization > request on a secondary device, such as a smartphone. There is no > requirement for communication between the constrained device and the > user's secondary device. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc6819: OAuth 2.0 Threat Model and Security Considerations > (Informational - IETF stream) > draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile > (None - ) > rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF > stream) > > > > _______________________________________________ > 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._ --0000000000008a976f056d6e49fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, just found a minor typo:

Secti= on 6.1:

through their length needs to =
be longer to maintain a high
   entropy.


Should be:

though their length needs to be longer to maintain a high entropy.


On Tue, May 29, 2018 at 4:20 PM, The IESG= <iesg-secretary@ietf.= org> wrote:

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



_______________________________________________
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. --0000000000008a976f056d6e49fe-- From nobody Wed May 30 12:57: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 96C1012EBA8 for ; Wed, 30 May 2018 12:57:13 -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=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 12paUeQl_zWR for ; Wed, 30 May 2018 12:57:11 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E0412EB53 for ; Wed, 30 May 2018 12:57:06 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id t5-v6so10496310ioa.8 for ; Wed, 30 May 2018 12:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=92x3L1zwMYXxCrf2uV1D2cUM/MUjk3zcdSsP6OiRZJw=; b=Di5XGVgVvKcTW9uv3Vhf9wdX5/lqqigRI+LRxiNYV5gMvWT1rSeesEirRJ+fp2N1gK ASGAd5QXYW6Zb/GQJNTImBxT5oadmeILJ9n0wIHIcvGbsqJlcMfDUMhrJt5sfvr3GrS7 +gqarffZEttkPBH3yur33E89hnFC8HOPoM038= 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=92x3L1zwMYXxCrf2uV1D2cUM/MUjk3zcdSsP6OiRZJw=; b=taORVO4y1giRBxaQpSitY5p8fksdH9Ak2lr1a+jLd89zpqS7YPtyamrk8sF4zvSZsD SwQJ4Oo4Lv5E0YM2OoettZQg/BHFD5XiF0qQawUss2DE6R1kVcQM4y63000GX/yDzP3Y c1+H3azgV5C2Ileet89whCkmVTV6ASMsl3Njs2lKR5poyt944a2iKs0K3HfOvVHCzpGh VctVoT52DwtbT1bIS8TW57Vfjmbe7FZA04QIfdgT/0Q93DwO5UNvACEd8WKqiecZQUd0 lxdN1oSWl6nNT6l7DWg36T0W0e1arNHwiqEG67hE5dwmU6j//CaSru4+HBJN8q4SQfZj rOvA== X-Gm-Message-State: APt69E3r3Zcb8myM5dFcUBjYZQNsAmrA6klcfw5y6lvstrPh9eBZpCqC b0Na3qVjcosuItc3FQZAc5zdgiVT/Gox/GPX7sy/N3Ocgo4aa9zE/43tZmsQ1UqnqUYkIKSw1zM wWctewIREtP3NEQ== X-Google-Smtp-Source: ADUXVKLqEjHkUwAQXJBfV+xa/3AaEIOOpb9gbPlVff1zYJ21ynV6UbPZ9S13nJpPRznbNj+FGU5eHf4id9IdNxiy9nI= X-Received: by 2002:a6b:591:: with SMTP id 139-v6mr3248260iof.282.1527710225130; Wed, 30 May 2018 12:57:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 30 May 2018 12:56:34 -0700 (PDT) In-Reply-To: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 30 May 2018 13:56:34 -0600 Message-ID: To: ietf@ietf.org Cc: IETF-Announce , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a2900056d71c1b1" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 19:57:21 -0000 --0000000000004a2900056d71c1b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In reading the draft (again) I noticed a couple of things that, while maybe not substantive, seemed like they were worth raising here in last call: 1: In Section 3.5 a new 'expired_token' error code is defined for when the 'device_code' has expired and the client will need to start the flow over. Shortly after the new error code definition there is text in that section that says 'If the verification codes have expired, the server SHOULD respond with the standard OAuth error "invalid_grant". Clients MAY then choose to start a new device authorization session.' This reads to me like: here's a new error for expired device code but this other code SHOULD be used for expired device code. Am I confused or otherwise missing something? I kinda suspect that the intent is that expired_token can be returned for codes that are known to be expired while invalid_grant is more of a catch all for codes that may have expired long enough ago that they have been purged from server memory/persistence or are otherwise unknown. That's my guess anyway. But the current text seems somewhat contradictory, which I think could be clarified/fixed. 2: In section 5 about security considerations for Non-confidential Clients there's a pointer to recommendations from Section 8.9 of [RFC8252] , which is about using the "state" parameter in the authorization request to protect against cross-app request forgery. That doesn't seem right or relevant to the device flow, does it? Was it intended to point to section 8.5 in RFC8252 ? Or something else? On Tue, May 29, 2018 at 4:20 PM, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for > Browserless and Input Constrained Devices' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > the Subject line to allow automated sorting. > > Abstract > > > This OAuth 2.0 authorization flow for browserless and input > constrained devices, often referred to as the device flow, enables > OAuth clients to request user authorization from devices that have an > Internet connection, but don't have an easy input method (such as a > smart TV, media console, picture frame, or printer), or lack a > suitable browser for a more traditional OAuth flow. This > authorization flow instructs the user to perform the authorization > request on a secondary device, such as a smartphone. There is no > requirement for communication between the constrained device and the > user's secondary device. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc6819: OAuth 2.0 Threat Model and Security Considerations > (Informational - IETF stream) > draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile > (None - ) > rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF > stream) > > > > _______________________________________________ > 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._ --0000000000004a2900056d71c1b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In reading the draft (again) I noticed a couple of th= ings that, while maybe not substantive, seemed like they were worth raising= here in last call:


1:
In Section 3.5 a new 'expired_toke= n' error code is defined for when the 'device_code' has expired= and the client will need to start the flow over. Shortly after the new err= or code definition there is text in that section that says 'If the veri= fication codes have expired, the server SHOULD respond with the standard OA= uth error "invalid_grant".=C2=A0 Clients MAY then choose to start= a new device authorization session.'

This rea= ds to me like: here's a new error for expired device code but this othe= r code SHOULD be used for expired device code. Am I confused or otherwise m= issing something?

I kinda suspect that the in= tent is that expired_token can be returned for codes that are known to be e= xpired while invalid_grant is more of a catch all for codes that may have e= xpired long enough ago that they have been purged from server memory/persis= tence or are otherwise unknown. That's my guess anyway. But the current= text seems somewhat contradictory, which I think could be clarified/fixed.=


2:
In sect= ion 5 about security considerations for Non-confidential Clients there&= #39;s a pointer to recommendations from Section 8.9 of [RFC8252], which is about using= the "state" parameter in the authorization request to protect ag= ainst cross-app request forgery.=C2=A0 That doesn't seem right or relev= ant to the device flow, does it? Was it intended to point to section 8.5 in RFC8252? O= r something else?





On Tue, = May 29, 2018 at 4:20 PM, The IESG <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



_______________________________________________
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. --0000000000004a2900056d71c1b1-- From nobody Wed May 30 14:36: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 D004212EB19 for ; Wed, 30 May 2018 14:36:04 -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 xu-OXBZw-Etf for ; Wed, 30 May 2018 14:36:02 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1532612EB08 for ; Wed, 30 May 2018 14:36:02 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id 18-v6so44755857wml.2 for ; Wed, 30 May 2018 14:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e/odCEwSx8NejxfFWIa2zZ6w9SiHuUtv0Wy0tWjL79k=; b=PAJGhuInbHiWyr3Wm3ZMptCCXZzex+v5TLp/vpyV56wNlrCf7c/NKG+ovcr1M5Y5ra N3MWY40gDmajsbcxUhMx7Iq1YhXcPy6abnjlooNoIpV6FoIE4mn+uAMtHO/oqAXB0Ggd ucHuxPPfcqdT7/ittTICdbccv4RLpb/E8nP5E= 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=e/odCEwSx8NejxfFWIa2zZ6w9SiHuUtv0Wy0tWjL79k=; b=FIkaeXyPI8o9oIK73b8exL+1CyUqGjOMTj63LeNY9sh7l4fKGpTfqwl2BSq/ld2edb 3Xg0565N46Y+ZbyL48yqLORGQexmkALpI7SjBMO4voRN2BRZ2IBQogrJgdLlwJ0RwCZg 9lQRrRDdlWReN7f9Hjrzlp14HVRbUEJ9DvaNWykXEMOey9HH8wWLnVroD3+mhQAYDNNn DGN3YVbwkvRIgrAOC0TPPLYJm6OtmY5XEHjJlKVdIJRWBLjQ7TM3FpSRZYI2hyqhGpSp NoUl43zqRNj65qroX4Dqf/SINd/IkVR8SjwsUKWOff0OlXBsmSiC64LtgwrWbqrm8PjK dbLg== X-Gm-Message-State: ALKqPwf+XuAYvJbSY1XaXrzEuOQ+OvLjhADo6yWKd+glkUfRNrieCChD YhtsGRFyBoaP8G5rpJ/BZIsgmH6au9GGLgTBcRuzvTLrth3jWK5Tl9rW/EgLXhiX/VALUoFx8Vn g8X6z0bJ9LK7rBw== X-Google-Smtp-Source: ADUXVKKrftYaH3iiPjCJJAt2XWv2vJyLybU+wnWCROSZ0H6QNrEitZ845WuKjcKtg2NA72yr8HsKXI5cZdDEDMmEQss= X-Received: by 2002:a1c:2cc2:: with SMTP id s185-v6mr2390459wms.62.1527716160493; Wed, 30 May 2018 14:36:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:e308:0:0:0:0:0 with HTTP; Wed, 30 May 2018 14:35:39 -0700 (PDT) In-Reply-To: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: Andrew Sciberras Date: Thu, 31 May 2018 07:35:39 +1000 Message-ID: To: ietf@ietf.org Cc: IETF-Announce , oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="000000000000107eee056d73238d" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 21:36:05 -0000 --000000000000107eee056d73238d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Do we feel that the document should be more specific in addressing how the authorization service should respond to a device access token request when the user has refused to grant access to the device? The document currently indicates in section 3.5 that a success response defined in section 5.1 of RFC6749, an error as defined in section 5.2 of RFC6749 (this includes invalid_request, invalid_client, invalid_grant, unauthorized_client, unsupported_grant_type, and invalid_scope), or a new device flow error code (authorization_pending, slow_down, and expired_token) may be returned in a response to a device token request. It doesn=E2=80=99t seem that any of these options are appropriate to convey= that a user has refused to grant access to the device. The Google implementation appears to be using the access_denied error code from section 4.1.2.1 of RFC6749. While this would seem to be the most suitable error code, the document does not explicitly indicate it as a permitted response. I believe that clarifying the response error code in the condition where a user has refused access to the client would be beneficial, remove ambiguity, and promote greater consistency across implementations. Regards Andrew Sciberras On Wed, May 30, 2018 at 8:20 AM, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for > Browserless and Input Constrained Devices' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > the Subject line to allow automated sorting. > > Abstract > > > This OAuth 2.0 authorization flow for browserless and input > constrained devices, often referred to as the device flow, enables > OAuth clients to request user authorization from devices that have an > Internet connection, but don't have an easy input method (such as a > smart TV, media console, picture frame, or printer), or lack a > suitable browser for a more traditional OAuth flow. This > authorization flow instructs the user to perform the authorization > request on a secondary device, such as a smartphone. There is no > requirement for communication between the constrained device and the > user's secondary device. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc6819: OAuth 2.0 Threat Model and Security Considerations > (Informational - IETF stream) > draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile > (None - ) > rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF > stream) > > > > _______________________________________________ > 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._ --000000000000107eee056d73238d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello


Do we feel that the document should be more speci= fic in addressing how the authorization service should respond to a device = access token request when the user has refused to grant access to the devic= e?=C2=A0


The document currently indicates in section 3.5 t= hat a success response defined in section 5.1 of RFC6749, an error as defin= ed in section 5.2 of RFC6749 (this includes invalid_request, invalid_client= , invalid_grant, unauthorized_client, unsupported_grant_type, and invalid_s= cope), or a new device flow error code (authorization_pending, slow_down, a= nd expired_token) may be returned in a response to a device token request.<= span class=3D"gmail-Apple-converted-space">=C2=A0


It doesn=E2=80=99t seem that any of these options= are appropriate to convey that a user has refused to grant access to the d= evice.=C2=A0


The Google implementation appears to be using the= access_denied error code from section 4.1.2.1 of RFC6749. While this would= seem to be the most suitable error code, the document does not explicitly = indicate it as a permitted response.=C2=A0


I believe that clarifying the response error code= in the condition where a user has refused access to the client would be be= neficial, remove ambiguity, and promote greater consistency across implemen= tations.=C2=A0


Regards

Andrew Sciberras=C2=A0



On Wed, May 30, 2018 at 8:20 AM, The IESG <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



_______________________________________________
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. --000000000000107eee056d73238d-- From nobody Wed May 30 15: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 AB25A12EAD6 for ; Wed, 30 May 2018 15:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 WkdQfVnNUIfo for ; Wed, 30 May 2018 15:06:43 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B327412EAE1 for ; Wed, 30 May 2018 15:06:40 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id q135-v6so9614313vkh.1 for ; Wed, 30 May 2018 15:06:40 -0700 (PDT) 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=Z7CNzLkmjHhx4Q4nVrsP6UfVDHfXSuxz9fZoYXw19q0=; b=ZTcHnZ9xg4g/bQsog4Jj9Zf97/NXO3UjfErqgWomsJaJIdE1XXNDKtlgOWDJsKbdR9 BYkqvw9BZNYNzvC3k/cjjB3LsqoyzNFkyr+GuJUiX8epoBBv5VsJGoVCEO/BZkDa5hIJ bkScrEfDNGF8N/g3CFWJzR5Ph9r5A4CoVLSupl2pzw2zZR+vAONIqp8zFb24suVdEmsZ KFLikH2ztrGenHropQ48s2aTuWOgaTi/9hw8t9FUVBp9MbhB0rOOXjeZQSMmRByVRu8i LYGR62Qjp+L65I6uAdMZ8c+rPbbs+nAvV9KTB9zgn2zjHbYX8V89PXWIJpy/OWncFMLY v/sw== 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=Z7CNzLkmjHhx4Q4nVrsP6UfVDHfXSuxz9fZoYXw19q0=; b=NPP5ZYBEDu4RzHNk9Xgvng5e2SpF/c4iqnvUS1FitMigzsJ6BOXOaWklW5uaRfc245 vj6/2/ACmRejy7Ad0wz2EA0RCQJCq8av7vcHXyWl8eQ5M/n2j+QDcGAxHL4j760TjpCS TPwwAp4R5fEN6YrAsu0Fyy/XKPFVwOn3XF/msUpMM30Dtl6do/vy9QFsD99XFJ1eXh/r TutyOWDND4PHoh+vlHCei1IWuNUzEsv8/icmxqoM21j5y7D9jhvPpsmqeQpWzm/Z1qTG 5JlOdtkWtSf6wUCZNT7UyF1w29bX+vpWNXLVvVtp88nrDD/udAzOCIpD1S0Wkl2sg5Zo BnQg== X-Gm-Message-State: ALKqPwdkVlkzmP/sXJNuPriJ5tFUIdTePF1EjczRLgscChuafnOpAKrL f9sOqIMTPqmBxb0qgBwRwZ7LaCegQVB063m+ynqTqQ== X-Google-Smtp-Source: ADUXVKK0vEKvFypcEtn1eqxQZDy9N08ryYNgdKJz1AEKnfWMzqcMN9UfMxHc+rqUkSzSnjCOuUCW5l3CbVyxhwOqalY= X-Received: by 2002:a1f:990a:: with SMTP id b10-v6mr2697001vke.56.1527717999166; Wed, 30 May 2018 15:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:2110:0:0:0:0:0 with HTTP; Wed, 30 May 2018 15:06:18 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: William Denniss Date: Wed, 30 May 2018 15:06:18 -0700 Message-ID: To: Andrew Sciberras Cc: ietf@ietf.org, IETF-Announce , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="000000000000a90752056d7390c6" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 22:06:46 -0000 --000000000000a90752056d7390c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras wrote: Hello > > > Do we feel that the document should be more specific in addressing how th= e > authorization service should respond to a device access token request whe= n > the user has refused to grant access to the device? > > > The document currently indicates in section 3.5 that a success response > defined in section 5.1 of RFC6749, an error as defined in section 5.2 of > RFC6749 (this includes invalid_request, invalid_client, invalid_grant, > unauthorized_client, unsupported_grant_type, and invalid_scope), or a new > device flow error code (authorization_pending, slow_down, and > expired_token) may be returned in a response to a device token request. > > > It doesn=E2=80=99t seem that any of these options are appropriate to conv= ey that a > user has refused to grant access to the device. > > > The Google implementation appears to be using the access_denied error cod= e > from section 4.1.2.1 of RFC6749. While this would seem to be the most > suitable error code, the document does not explicitly indicate it as a > permitted response. > Actually, this is indicated explicitly I believe: If the user has approved the grant, the token endpoint responds with a success response defined in Section 5.1 of [RFC6749]; *otherwise it responds with an error, as defined in Section 5.2 of [RFC6749].* In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specific for the device flow: > > I believe that clarifying the response error code in the condition where = a > user has refused access to the client would be beneficial, remove > ambiguity, and promote greater consistency across implementations. > > > Regards > > Andrew Sciberras > > > On Wed, May 30, 2018 at 8:20 AM, The IESG wrote= : > >> >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for >> Browserless and Input Constrained Devices' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This OAuth 2.0 authorization flow for browserless and input >> constrained devices, often referred to as the device flow, enables >> OAuth clients to request user authorization from devices that have an >> Internet connection, but don't have an easy input method (such as a >> smart TV, media console, picture frame, or printer), or lack a >> suitable browser for a more traditional OAuth flow. This >> authorization flow instructs the user to perform the authorization >> request on a secondary device, such as a smartphone. There is no >> requirement for communication between the constrained device and the >> user's secondary device. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> The document contains these normative downward references. >> See RFC 3967 for additional information: >> rfc6819: OAuth 2.0 Threat Model and Security Considerations >> (Informational - IETF stream) >> draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile >> (None - ) >> rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF >> stream) >> >> >> >> _______________________________________________ >> 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.* > --000000000000a90752056d7390c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,
On Wed, May 30, 2018 at 2:35 PM, =
Andrew Sciberras <andrewsciberras@pingidentity.com> wrote:<=
br>

Hello=


Do we= feel that the document should be more specific in addressing how the autho= rization service should respond to a device access token request when the u= ser has refused to grant access to the device?=C2=A0


The d= ocument currently indicates in section 3.5 that a success response defined = in section 5.1 of RFC6749, an error as defined in section 5.2 of RFC6749 (t= his includes invalid_request, invalid_client, invalid_grant, unauthorized_c= lient, unsupported_grant_type, and invalid_scope), or a new device flow err= or code (authorization_pending, slow_down, and expired_token) may be return= ed in a response to a device token request.=C2=A0


It do= esn=E2=80=99t seem that any of these options are appropriate to convey that= a user has refused to grant access to the device.=C2=A0


The G= oogle implementation appears to be using the access_denied error code from = section 4.1.2.1 of RFC6749. While this would seem to be the most suitable e= rror code, the document does not explicitly indicate it as a permitted resp= onse.=C2=A0


=
Actually, this is indicated explicitly I believe:

othe= rwise it responds with an error, as defined in Section 5.2 of [RFC6749]. In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specific for the device flow:
=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">


I bel= ieve that clarifying the response error code in the condition where a user = has refused access to the client would be beneficial, remove ambiguity, and= promote greater consistency across implementations.=C2=A0


Regar= ds

Andre= w Sciberras=C2=A0



On Wed, May 30, 2018 at 8:20 AM, The IESG = <iesg-secre= tary@ietf.org> wrote:

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/d<= wbr>oc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



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

--000000000000a90752056d7390c6-- From nobody Wed May 30 15:19: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 F282B12D86F for ; Wed, 30 May 2018 15:19:23 -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=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 S2_7sWHJCwBK for ; Wed, 30 May 2018 15:19:21 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3401275FD for ; Wed, 30 May 2018 15:19:17 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id l41-v6so31069198wre.7 for ; Wed, 30 May 2018 15:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BBfK1YCPTJdH8MHZBkc+cCdgCGg4sCuMZQJCl1jhdxI=; b=dVVwvEYnPqcYtKgFwRQMoxFB4cXeNdc9LFIhfudGD0tsM5zFgbodNTQLcwbmLOqTdf oilbY0qjzj5QMmLicoJaoq8BiRdGQW4qREiV/2AR2pCWcsTAHpHTSQMbNHPpUJvBT5fV d7dPMjqDAtKiJdXl1xwpEi8qaBrtmoGrBP7Kk= 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=BBfK1YCPTJdH8MHZBkc+cCdgCGg4sCuMZQJCl1jhdxI=; b=cnXHugJqofjQ8YsvP8cVwwdrQtf6Ekv9h039cqmTW6WQiLF1E0TGbqKipgftqtUVqm 4GDZdoSNN3JM9lEUxqsW/FprJeZG4dZ0ZTvoxDdBr/iRoaB0dGnA9CUzJxFcXEnSyKUn OqnDemZGM1bGJ4wBgaTP5tcrb7ql/IYg4W/MiDS4GaDdLuE6VGN1FKUjQ9j2IioCkjFW d/F6gHcaZ+ChDTSBWw/PKVyHsrnDrwPZzam91imBzclZ3xyzIn9F5Zc2mSxzSqVuOlsp QbtZ1UOrGNEihKSoMYh0CikLIHk33IN5iFum2II8JMkEISn0eKSevFk3omotlDotQwyx CF/A== X-Gm-Message-State: ALKqPwc05rMDSxa8TsRC6VuSxOU9SJSqOh/j23qUj4TqHaxxeQD6oqGI LHSaClY9EUTWDgzjj/W9rgkNy24AzJKFNiH13vn7e7PWbWdWgVmfhtBc5apB8a0Cp3ZiB4an3Vq ZuWAAzn6RWYQAHw== X-Google-Smtp-Source: ADUXVKLY/OwW6HkaZD77qzl2aDg3Ngwvi1VnlHHP203tqrMGOXwzPW6PAqk6feprH7QhSTsN/VjFKfPL/jdU+IWC4Oo= X-Received: by 2002:adf:9663:: with SMTP id c32-v6mr3639000wra.89.1527718755491; Wed, 30 May 2018 15:19:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:e308:0:0:0:0:0 with HTTP; Wed, 30 May 2018 15:18:54 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: Andrew Sciberras Date: Thu, 31 May 2018 08:18:54 +1000 Message-ID: To: William Denniss Cc: ietf@ietf.org, IETF-Announce , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="000000000000bcfe7e056d73bdf7" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 22:19:24 -0000 --000000000000bcfe7e056d73bdf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi William You are right that the document explicitly indicates which error codes may be returned. However I think it's ambiguous as to which error within Section 5.2 of RFC6749 would apply in the scenario of a user not granting access. I think that this ambiguity is highlighted further by the Google implementation (https://developers.google.com/identity/protocols/OAuth2ForD= e vices#step-6-handle-responses-to-polling-requests) not adhering to the explicit statement of the document and electing to use a (more appropriate) error code that exists outside of section 5.2. Andrew On Thu, May 31, 2018 at 8:06 AM, William Denniss wrote: > Hi Andrew, > > On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras wrote: > > Hello >> >> >> Do we feel that the document should be more specific in addressing how >> the authorization service should respond to a device access token reques= t >> when the user has refused to grant access to the device? >> >> >> The document currently indicates in section 3.5 that a success response >> defined in section 5.1 of RFC6749, an error as defined in section 5.2 of >> RFC6749 (this includes invalid_request, invalid_client, invalid_grant, >> unauthorized_client, unsupported_grant_type, and invalid_scope), or a ne= w >> device flow error code (authorization_pending, slow_down, and >> expired_token) may be returned in a response to a device token request. >> >> >> It doesn=E2=80=99t seem that any of these options are appropriate to con= vey that >> a user has refused to grant access to the device. >> >> >> The Google implementation appears to be using the access_denied error >> code from section 4.1.2.1 of RFC6749. While this would seem to be the mo= st >> suitable error code, the document does not explicitly indicate it as a >> permitted response. >> > > Actually, this is indicated explicitly I believe: > > If the user has approved the grant, the token endpoint responds with a > success response defined in Section 5.1 of [RFC6749]; *otherwise it > responds with an error, as defined in Section 5.2 of [RFC6749].* > In addition to the error codes defined in Section 5.2 of [RFC6749], the > following error codes are specific for the device flow: > > >> >> I believe that clarifying the response error code in the condition where >> a user has refused access to the client would be beneficial, remove >> ambiguity, and promote greater consistency across implementations. >> >> >> Regards >> >> Andrew Sciberras >> >> >> On Wed, May 30, 2018 at 8:20 AM, The IESG >> wrote: >> >>> >>> The IESG has received a request from the Web Authorization Protocol WG >>> (oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r >>> Browserless and Input Constrained Devices' >>> as Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final >>> comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may >>> be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of >>> the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This OAuth 2.0 authorization flow for browserless and input >>> constrained devices, often referred to as the device flow, enables >>> OAuth clients to request user authorization from devices that have a= n >>> Internet connection, but don't have an easy input method (such as a >>> smart TV, media console, picture frame, or printer), or lack a >>> suitable browser for a more traditional OAuth flow. This >>> authorization flow instructs the user to perform the authorization >>> request on a secondary device, such as a smartphone. There is no >>> requirement for communication between the constrained device and the >>> user's secondary device. >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> The document contains these normative downward references. >>> See RFC 3967 for additional information: >>> rfc6819: OAuth 2.0 Threat Model and Security Considerations >>> (Informational - IETF stream) >>> draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile >>> (None - ) >>> rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF >>> stream) >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000bcfe7e056d73bdf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi William

You are right that the docu= ment explicitly indicates which error codes may be returned. However I thin= k it's ambiguous as to which error within Section 5.2 of RFC6749 would = apply in the scenario of a user not granting access.=C2=A0

<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma= ll;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal= ;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;tex= t-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(2= 55,255,255);text-decoration-style:initial;text-decoration-color:initial">I = think that this ambiguity is highlighted further by the Google implementati= on (https://developers.google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests) not adhering t= o the explicit statement of the document and electing to use a (more approp= riate) error code that exists outside of section 5.2.=C2=A0=C2=A0
=C2= =A0
Andrew


On Thu, May 31, 2018 at 8:06 AM, William Den= niss <wdenniss@google.com> wrote:
Hi Andrew,
On Wed=
, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciberras@pingidentity.<=
wbr>com> wrote:

Hello


Do we feel that the document should be more specific in add= ressing how the authorization service should respond to a device access tok= en request when the user has refused to grant access to the device?=C2=A0


The document currently indicates in section 3.5 that a succ= ess response defined in section 5.1 of RFC6749, an error as defined in sect= ion 5.2 of RFC6749 (this includes invalid_request, invalid_client, invalid_= grant, unauthorized_client, unsupported_grant_type, and invalid_scope), or = a new device flow error code (authorization_pending, slow_down, and expired= _token) may be returned in a response to a device token request.=C2=A0


It doesn=E2=80=99t seem that any of these options are appro= priate to convey that a user has refused to grant access to the device.=C2=A0


The Google implementation appears to be using the access_de= nied error code from section 4.1.2.1 of RFC6749. While this would seem to b= e the most suitable error code, the document does not explicitly indicate i= t as a permitted response.=C2=A0


Actually, this is ind= icated explicitly I believe:

I= f the user has approved the grant, the token endpoint responds with a success response defined in Section 5.1 of [RFC6749]; othe= rwise it responds with an error, as defined in Section 5.2 of [RFC6749].
In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specific for the device flow:
=C2=A0
=


I believe that clarifying the response error code in the co= ndition where a user has refused access to the client would be beneficial, = remove ambiguity, and promote greater consistency across implementations.=C2=A0


Regards

Andrew Sciberras=C2=A0



On Wed, May 30, 2018 at 8:20 AM, The IE= SG <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/d<= wbr>oc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



_______________________________________________
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. --000000000000bcfe7e056d73bdf7-- From nobody Wed May 30 15:27: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 9C5C712D93E for ; Wed, 30 May 2018 15:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 tXVZhMKc1_0L for ; Wed, 30 May 2018 15:27:42 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EB512E044 for ; Wed, 30 May 2018 15:27:42 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id g72-v6so12131140vke.2 for ; Wed, 30 May 2018 15:27:42 -0700 (PDT) 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=AY3ORyYNF8NHoiNbAw8WL5s8/aQE3RozcRgJa8Xw/qw=; b=Ha+AH1GSroj4sp9esiy6JCgANOBkyRW2DVgTEMltRA8mwMrGt6enkzLHTE0QcvMgU6 9H/1bJOlp5LXHoROSwZmTdASJV1GognpD25S+ehI65N3iVg+h1edWr/0Y/mX9qyQoCwE 4yDMSE7zabH1AA+KgS4kXuayHx83UKXa4tLT/xxBpGNCXwJuKaAXIhGQLUfgGfR3+nW3 1i2hb38n6fJfSa52svy3nE6l6Z7J1eD+8i/ea6COoJ1ZczzqgQrY6akWbHo4HjkobU0t Cgi7lcad6pCZO1+VOH4MWQZw4T9qoMqdT+oEN00J2EKzavY0TkPWtvAKCZeBJkSvqGDb +L+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AY3ORyYNF8NHoiNbAw8WL5s8/aQE3RozcRgJa8Xw/qw=; b=JyV/8RudkmX52xtri/migqwiZ0gx34jSSUOwkFbKl7EVpy2E84vE8UUi3f5sHwPZER jjmjPgc5mGfhWpBB3ZCE7eKxNHzXY2FMcJzsqWdipJphEA/70LWjEZU6cnwBCyDss+MQ QuwjHb8tx33K6syy+gGZyXRrfVQd4xa5PrAN1PVv5lewu2f+d8XGgORRok0fvcPgiosg ofD4p28pvo0orbIgylX3XTiZ8Nai2DSTRdztcnyH9GFcYmQ+uDi22D9hTBEk+pUfTM/k BQVqky+xaGv2Ugd1d5SfkhMQV6vyFt89Q4hdoJayBLvfmdT4uP8qv/TA06X16VtPKNUa gphw== X-Gm-Message-State: ALKqPweWVldqTs4MMMLy8uoZ217LtgMbmz87yNS2V8sYSP0M2usg9Dg5 bG6/ZBWDTjW4Bp4ykV33PSJ58RrxIbZptWjuCcJ5iQ== X-Google-Smtp-Source: ADUXVKJzbpueRPQCOPP0A4J4Scl2hJJxMaQIHOpu36O79T5JhgRSKnI23BBJ5EZnE/pXBnLP4ZH7PgeDEHTUhRFJOM8= X-Received: by 2002:a1f:d906:: with SMTP id q6-v6mr2721108vkg.197.1527719260442; Wed, 30 May 2018 15:27:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:2110:0:0:0:0:0 with HTTP; Wed, 30 May 2018 15:27:19 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: William Denniss Date: Wed, 30 May 2018 15:27:19 -0700 Message-ID: To: Andrew Sciberras Cc: ietf@ietf.org, IETF-Announce , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="000000000000d67cce056d73db57" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 22:27:46 -0000 --000000000000d67cce056d73db57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < andrewsciberras@pingidentity.com> wrote: > Hi William > > You are right that the document explicitly indicates which error codes ma= y > be returned. However I think it's ambiguous as to which error within > Section 5.2 of RFC6749 would apply in the scenario of a user not granting > access. > > I think that this ambiguity is highlighted further by the Google > implementation (https://developers.google.com/identity/protocols/ > OAuth2ForDevices#step-6-handle-responses-to-polling-requests) not > adhering to the explicit statement of the document and electing to use a > (more appropriate) error code that exists outside of section 5.2. > > Oh, I see what you mean now. Yes, given this is an authorization request, not a token request, the errors from Section 4.1.2.1 are more relevant. I believe it was the authors intention to reference that set of errors, so I will plan to update the doc to reference 4.1.2.1 instead. Good catch! Thank you. > > On Thu, May 31, 2018 at 8:06 AM, William Denniss > wrote: > >> Hi Andrew, >> >> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras wrote: >> >> Hello >>> >>> >>> Do we feel that the document should be more specific in addressing how >>> the authorization service should respond to a device access token reque= st >>> when the user has refused to grant access to the device? >>> >>> >>> The document currently indicates in section 3.5 that a success response >>> defined in section 5.1 of RFC6749, an error as defined in section 5.2 o= f >>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant, >>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a n= ew >>> device flow error code (authorization_pending, slow_down, and >>> expired_token) may be returned in a response to a device token request. >>> >>> >>> It doesn=E2=80=99t seem that any of these options are appropriate to co= nvey that >>> a user has refused to grant access to the device. >>> >>> >>> The Google implementation appears to be using the access_denied error >>> code from section 4.1.2.1 of RFC6749. While this would seem to be the m= ost >>> suitable error code, the document does not explicitly indicate it as a >>> permitted response. >>> >> >> Actually, this is indicated explicitly I believe: >> >> If the user has approved the grant, the token endpoint responds with a >> success response defined in Section 5.1 of [RFC6749]; *otherwise it >> responds with an error, as defined in Section 5.2 of [RFC6749].* >> > In addition to the error codes defined in Section 5.2 of [RFC6749], the >> following error codes are specific for the device flow: >> >> >>> >>> I believe that clarifying the response error code in the condition wher= e >>> a user has refused access to the client would be beneficial, remove >>> ambiguity, and promote greater consistency across implementations. >>> >>> >>> Regards >>> >>> Andrew Sciberras >>> >>> >>> On Wed, May 30, 2018 at 8:20 AM, The IESG >>> wrote: >>> >>>> >>>> The IESG has received a request from the Web Authorization Protocol WG >>>> (oauth) to consider the following document: - 'OAuth 2.0 Device Flow f= or >>>> Browserless and Input Constrained Devices' >>>> as Proposed Standard >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final >>>> comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may >>>> be >>>> sent to iesg@ietf.org instead. In either case, please retain the >>>> beginning of >>>> the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> >>>> This OAuth 2.0 authorization flow for browserless and input >>>> constrained devices, often referred to as the device flow, enables >>>> OAuth clients to request user authorization from devices that have = an >>>> Internet connection, but don't have an easy input method (such as a >>>> smart TV, media console, picture frame, or printer), or lack a >>>> suitable browser for a more traditional OAuth flow. This >>>> authorization flow instructs the user to perform the authorization >>>> request on a secondary device, such as a smartphone. There is no >>>> requirement for communication between the constrained device and th= e >>>> user's secondary device. >>>> >>>> >>>> >>>> >>>> The file can be obtained via >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >>>> >>>> IESG discussion can be tracked via >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>>> >>>> >>>> The document contains these normative downward references. >>>> See RFC 3967 for additional information: >>>> rfc6819: OAuth 2.0 Threat Model and Security Considerations >>>> (Informational - IETF stream) >>>> draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile >>>> (None - ) >>>> rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF >>>> stream) >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 prohibite= d. >>> 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.* >>> >> >> > > *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.* > --000000000000d67cce056d73db57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <andrewsciberras@pingidentity.com> wrote:
Hi William

You are right that the document explicitly indicates which = error codes may be returned. However I think it's ambiguous as to which= error within Section 5.2 of RFC6749 would apply in the scenario of a user = not granting access.=C2=A0

I think that this ambiguity is high= lighted further by the Google implementation (https://developers.google.com/identity/protocols/OAuth2ForDevices#step-6-handle-response= s-to-polling-requests) not adhering to the explicit statement of t= he document and electing to use a (more appropriate) error code that exists= outside of section 5.2.=C2=A0=C2=A0
=C2=A0
<= div>
Oh, I see what you mean now. Yes, given this is an autho= rization request, not a token request, the errors from Section 4.1.2.1 are more rele= vant.

I believe it was the authors intention to re= ference that set of errors, so I will plan to update the doc to reference 4= .1.2.1 instead.=C2=A0 Good catch! Thank you.



On Thu, May 31, 2018 at 8:06 AM, William Den= niss <wdenniss@google.com> wrote:
Hi Andrew,
On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciberras@pingid=
entity.com> wrote:

Hello


Do we feel that the document sho= uld be more specific in addressing how the authorization service should res= pond to a device access token request when the user has refused to grant ac= cess to the device?=C2=A0


The document currently indicates= in section 3.5 that a success response defined in section 5.1 of RFC6749, = an error as defined in section 5.2 of RFC6749 (this includes invalid_reques= t, invalid_client, invalid_grant, unauthorized_client, unsupported_grant_ty= pe, and invalid_scope), or a new device flow error code (authorization_pend= ing, slow_down, and expired_token) may be returned in a response to a devic= e token request.

It doesn=E2=80=99t seem that any= of these options are appropriate to convey that a user has refused to gran= t access to the device.=C2=A0


The Google implementation appear= s to be using the access_denied error code from section 4.1.2.1 of RFC6749.= While this would seem to be the most suitable error code, the document doe= s not explicitly indicate it as a permitted response.=C2=A0


Actually, this is indicated explicitly I b= elieve:

othe= rwise it responds with an error, as defined in Section 5.2 of [RFC6749].
In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specific for the device flow:
=C2=A0


I believe that clarifying the re= sponse error code in the condition where a user has refused access to the c= lient would be beneficial, remove ambiguity, and promote greater consistenc= y across implementations.=C2=A0


Regards

Andrew Sciberras=C2=A0



On Wed, May = 30, 2018 at 8:20 AM, The IESG <iesg-secretary@ietf.org> wrote:
<= div>

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/d<= wbr>oc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



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

--000000000000d67cce056d73db57-- From nobody Wed May 30 15:32: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 142FD12D7EF for ; Wed, 30 May 2018 15:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 0_FJyMPHiQEl for ; Wed, 30 May 2018 15:32:03 -0700 (PDT) Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C21112E03A for ; Wed, 30 May 2018 15:32:03 -0700 (PDT) Received: by mail-ua0-x241.google.com with SMTP id i2-v6so13663271uah.0 for ; Wed, 30 May 2018 15:32:02 -0700 (PDT) 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=D1+I0MXg+bO+65uHCWCEqqdm8iB4RNyoeP3t+gDd35M=; b=q/WR1xdY4gJxbuy1AQ9d+cYG/iWJIXmQvfzjR3BfC9LXfwU9QC5kQ0v0VqVegl24n4 C2eLsWiLJ+NBfz4p7XeCBEA78QTyJHku6f1els3Sf+U8nbgkSZNk4mieEtdHRLqRdMCL uXMXTOMrlLPT3zhzozUru1ZnaY0s7GIutDW6Vr5HZYWTu2xuPvIkDd/Y/2uER8DW9yau hP+OOxsKCEnBqRS4eQIwRtia3TzEFFEUmowmu6j/0lIb13Hkh64q4xWmMimPtmR5cBjE ai8f7/vwIvyF8+3X5d9pny/5vi5XNs3Xo3MZ3UGa6LjLJ6hI42mPvJVkUL12KBO4JBBH mVCg== 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=D1+I0MXg+bO+65uHCWCEqqdm8iB4RNyoeP3t+gDd35M=; b=CSadwwx9gq4Y22yJ38VzZkQJn4IXKSN1XBzY6SySSP1YUTBDsBgSfjxdn5AGdHeGNo 9+ifN0sdsyHJ6HjsEHUZ4a2/7nFKdDaZ6o1UeJYEzgxX+ep4KDERdLawncRlc3kRNQPT FhGpQgeD+A3SgizSadtXEm15RG4rWB1LloOMu2GKxSDCBqAR7ShAYMDv+gIqiVm+qMlB YlJFRaLaBJfN0nQTXeDjESd/zbLCm2ZaEkk83TllLd8v1myi+w4Spa6lYyCPKQUTwIUS V+7QsXMl6Z6mM13fcwwW+iH/T0Cvt6+gQ++ExD58h5zW7HafGchAMbf8eEEMX25bnfh6 Tv+w== X-Gm-Message-State: ALKqPweCV67rLiOMt+5V+9s3POE6RYcakeWqHoiKDZFfxxtSpPOeVd3Q CiAn/qPegdmGgBO4Vmvs2elM73mfMMDeCtAiWsGOeg== X-Google-Smtp-Source: ADUXVKL+ocBqoRW9Zj0vDuJo1Ut3PPFwW4ZH5Y7ZCVZ38VsCFWgEUlFa1xYz2C2/uhgsNerWIQdvXcSC9I6P3APymnM= X-Received: by 2002:a9f:2e0f:: with SMTP id t15-v6mr3246218uaj.114.1527719521545; Wed, 30 May 2018 15:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:2110:0:0:0:0:0 with HTTP; Wed, 30 May 2018 15:31:41 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: William Denniss Date: Wed, 30 May 2018 15:31:41 -0700 Message-ID: To: Brian Campbell Cc: ietf@ietf.org, IETF-Announce , oauth , oauth-chairs@ietf.org, draft-ietf-oauth-device-flow@ietf.org Content-Type: multipart/alternative; boundary="000000000000669f53056d73ebe7" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 22:32:06 -0000 --000000000000669f53056d73ebe7 Content-Type: text/plain; charset="UTF-8" Hi Brian, On Wed, May 30, 2018 at 12:56 PM, Brian Campbell wrote: > In reading the draft (again) I noticed a couple of things that, while > maybe not substantive, seemed like they were worth raising here in last > call: > > > 1: > In Section 3.5 > > a new 'expired_token' error code is defined for when the 'device_code' has > expired and the client will need to start the flow over. Shortly after the > new error code definition there is text in that section that says 'If the > verification codes have expired, the server SHOULD respond with the > standard OAuth error "invalid_grant". Clients MAY then choose to start a > new device authorization session.' > > This reads to me like: here's a new error for expired device code but this > other code SHOULD be used for expired device code. Am I confused or > otherwise missing something? > > I kinda suspect that the intent is that expired_token can be returned for > codes that are known to be expired while invalid_grant is more of a catch > all for codes that may have expired long enough ago that they have been > purged from server memory/persistence or are otherwise unknown. That's my > guess anyway. But the current text seems somewhat contradictory, which I > think could be clarified/fixed. > I agree that the way it's documented "expired_token" would be for when you know it's expired, whereas "invalid_grant" is a more generic catch all. I think this section needs to be revisited to clear up this ambiguity. Before proposing a solution, I want to investigate a little what the existing implementations are doing around this case. 2: > In section 5 > > about security considerations for Non-confidential Clients there's a > pointer to recommendations from Section 8.9 of [RFC8252] > , which is about using > the "state" parameter in the authorization request to protect against > cross-app request forgery. That doesn't seem right or relevant to the > device flow, does it? Was it intended to point to section 8.5 in RFC8252 > ? Or something else? > > Good catch. That text was introduced in 04, https://tools.ietf.org/html/ draft-ietf-oauth-device-flow-04#section-5.4 and Section 8.9 of the 07 draft version of native apps at the time was "Client Authentication ", which is now Section 8.5 of RFC8252. I will update this draft to point to Section 8.5, per the original intent. > On Tue, May 29, 2018 at 4:20 PM, The IESG wrote: > >> >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for >> Browserless and Input Constrained Devices' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This OAuth 2.0 authorization flow for browserless and input >> constrained devices, often referred to as the device flow, enables >> OAuth clients to request user authorization from devices that have an >> Internet connection, but don't have an easy input method (such as a >> smart TV, media console, picture frame, or printer), or lack a >> suitable browser for a more traditional OAuth flow. This >> authorization flow instructs the user to perform the authorization >> request on a secondary device, such as a smartphone. There is no >> requirement for communication between the constrained device and the >> user's secondary device. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> The document contains these normative downward references. >> See RFC 3967 for additional information: >> rfc6819: OAuth 2.0 Threat Model and Security Considerations >> (Informational - IETF stream) >> draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile >> (None - ) >> rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF >> stream) >> >> >> >> _______________________________________________ >> 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.* > --000000000000669f53056d73ebe7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

On Wed, May 30, 2018 at 12:56 PM, Brian Campbell <bc= ampbell@pingidentity.com> wrote:




2:
= In section 5 about security considerations f= or Non-confidential Clients there's a pointer to recommendations from <= a href=3D"https://tools.ietf.org/html/rfc8252#section-8.9" target=3D"_blank= ">Section 8.9 of [RFC8252], which is about using the "state" = parameter in the authorization request to protect against cross-app request= forgery.=C2=A0 That doesn't seem right or relevant to the device flow,= does it? Was it intended to point to section 8.5 in RFC8252? Or som= ething else?


Good catch.

That text was introduced in 04, https://tools.ietf.org/html/draft-ietf-oauth-de= vice-flow-04#section-5.4 and Section 8.9 of the 07 draft version o= f native apps at the time was "Client Authe= ntication", which is now Section 8.5 of RFC8252.=C2=A0 I will upda= te this draft to point to Section 8.5, per the original intent.
<= br>

On Tue, May 29, 2018 at 4:20 PM, The IESG <= iesg-secretary= @ietf.org> wrote:

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/d<= wbr>oc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



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

--000000000000669f53056d73ebe7-- From nobody Wed May 30 15:49: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 DC77612D875 for ; Wed, 30 May 2018 15:49:01 -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=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 8MLiwHno_hi5 for ; Wed, 30 May 2018 15:48:59 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F381127286 for ; Wed, 30 May 2018 15:48:54 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id e15-v6so15201910iog.1 for ; Wed, 30 May 2018 15:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vqrAMVH8SyUF7keRndeLVwkCqQX5PKEcmlMimJc4UAY=; b=WvsTRA88IrTJhBM/QZ20P+1f+AWe0lx0KZLoXCQEKGqMw4M4gSb+LY3QaOLW5ii6CP vevBTJqR8i4yOAX4H1as5nsQWFkE0rsgqH3BM9lEp/XZIIptjTojMFoZL3YP8KxjXlT/ 3uSywhfzOVHy6i6uOq8kahJWu5e9Xto27g4oQ= 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=vqrAMVH8SyUF7keRndeLVwkCqQX5PKEcmlMimJc4UAY=; b=TU4XR8amuTQBtIUn6x1ebn9q00KCEN9toRlOQyv0HM/8WM4be+upjDVMXhwc2pBWkV HgT9psVogk88x0UdqXI5xlr0oOVMb0UocF0kaJSJmCz1O/R5foFQh0fkQNx6uhsdwx45 3W/wITjdmKeyeFgOUxUblG62sYz1pq11Ti1T66mTf2hHE+4H8CfZCOyF6JmJUZSnuxvv rg2GeWq7+r8tXEh/OqbNFU3Zzctodh7U9TxttJ7ITFaoWN3KDO+7ZQSqsj6P49n7jaKD yzMkus1XhFxGAyggSZArTF1ZJ9/U5kWDUWBCkLK5eNySKTjK129CO6ZHKBiRwPtXLJf2 0A4g== X-Gm-Message-State: ALKqPwdkw/b87qemc/fkZO+aHe8nIhoVxKITuz8XdepopYy1NLB4TgFz UaEr5sHL0YGBvz0eT1zlqRKZHzkAHhwwIiO61Xv3WvhoTql9qJBF97RKr9A9GXh5mHHprk7So/U xUHWW0Gh1PK2eAg== X-Google-Smtp-Source: ADUXVKIkMUewLlWNSF06tuj2AQRiYW2FwMmo3ySQwxrE5XwwUU5BARDcbDWLn3vRxxfo2bBXDHlqMIfP6NcgkSj9ka0= X-Received: by 2002:a6b:630d:: with SMTP id p13-v6mr3850482iog.17.1527720533583; Wed, 30 May 2018 15:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 30 May 2018 15:48:22 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 30 May 2018 16:48:22 -0600 Message-ID: To: William Denniss Cc: Andrew Sciberras , draft-ietf-oauth-device-flow@ietf.org, oauth-chairs@ietf.org, ietf@ietf.org, IETF-Announce , oauth Content-Type: multipart/alternative; boundary="000000000000b8872f056d742716" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 22:49:02 -0000 --000000000000b8872f056d742716 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I realize this is somewhat pedantic but I don't think referencing 4.1.2.1 works given how RFC 6749 set things up. Rather I believe that the device flow needs to define and register "access_denied" as a valid token endpoint response error code (it's not a token endpoint response error per RFC 6749 sec 5.2 nor has it been registered https://www.iana.org/assignmen ts/oauth-parameters/oauth-parameters.xhtml#extensions-error). Also invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1 defines errors returned from the authorization endpoint. But the device flow errors are from the token endpoint. On Wed, May 30, 2018 at 4:27 PM, William Denniss < wdenniss=3D40google.com@dmarc.ietf.org> wrote: > Hi Andrew, > > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > andrewsciberras@pingidentity.com> wrote: > >> Hi William >> >> You are right that the document explicitly indicates which error codes >> may be returned. However I think it's ambiguous as to which error within >> Section 5.2 of RFC6749 would apply in the scenario of a user not grantin= g >> access. >> >> I think that this ambiguity is highlighted further by the Google >> implementation (https://developers.google.com >> /identity/protocols/OAuth2ForDevices#step-6-handle- >> responses-to-polling-requests >> ) >> not adhering to the explicit statement of the document and electing to u= se >> a (more appropriate) error code that exists outside of section 5.2. >> >> > > Oh, I see what you mean now. Yes, given this is an authorization request, > not a token request, the errors from Section 4.1.2.1 > are more relevant. > > I believe it was the authors intention to reference that set of errors, s= o > I will plan to update the doc to reference 4..1.2.1 instead. Good catch! > Thank you. > > >> >> On Thu, May 31, 2018 at 8:06 AM, William Denniss >> wrote: >> >>> Hi Andrew, >>> >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras wrote: >>> >>> Hello >>>> >>>> >>>> Do we feel that the document should be more specific in addressing how >>>> the authorization service should respond to a device access token requ= est >>>> when the user has refused to grant access to the device? >>>> >>>> >>>> The document currently indicates in section 3.5 that a success respons= e >>>> defined in section 5.1 of RFC6749, an error as defined in section 5.2 = of >>>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant, >>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a = new >>>> device flow error code (authorization_pending, slow_down, and >>>> expired_token) may be returned in a response to a device token request= . >>>> >>>> >>>> >>>> It doesn=E2=80=99t seem that any of these options are appropriate to c= onvey >>>> that a user has refused to grant access to the device. >>>> >>>> >>>> The Google implementation appears to be using the access_denied error >>>> code from section 4.1.2.1 of RFC6749. While this would seem to be the = most >>>> suitable error code, the document does not explicitly indicate it as a >>>> permitted response. >>>> >>> >>> Actually, this is indicated explicitly I believe: >>> >>> If the user has approved the grant, the token endpoint responds with a >>> success response defined in Section 5.1 of [RFC6749]; *otherwise it >>> responds with an error, as defined in Section 5.2 of [RFC6749].* >>> >> In addition to the error codes defined in Section 5.2 of [RFC6749], the >>> following error codes are specific for the device flow: >>> >>> >>>> >>>> I believe that clarifying the response error code in the condition >>>> where a user has refused access to the client would be beneficial, rem= ove >>>> ambiguity, and promote greater consistency across implementations. >>>> >>>> >>>> Regards >>>> >>>> Andrew Sciberras >>>> >>>> >>>> On Wed, May 30, 2018 at 8:20 AM, The IESG >>>> wrote: >>>> >>>>> >>>>> The IESG has received a request from the Web Authorization Protocol W= G >>>>> (oauth) to consider the following document: - 'OAuth 2.0 Device Flow >>>>> for >>>>> Browserless and Input Constrained Devices' >>>>> as Proposed Standard >>>>> >>>>> The IESG plans to make a decision in the next few weeks, and solicits >>>>> final >>>>> comments on this action. Please send substantive comments to the >>>>> ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments >>>>> may be >>>>> sent to iesg@ietf.org instead. In either case, please retain the >>>>> beginning of >>>>> the Subject line to allow automated sorting. >>>>> >>>>> Abstract >>>>> >>>>> >>>>> This OAuth 2.0 authorization flow for browserless and input >>>>> constrained devices, often referred to as the device flow, enables >>>>> OAuth clients to request user authorization from devices that have >>>>> an >>>>> Internet connection, but don't have an easy input method (such as = a >>>>> smart TV, media console, picture frame, or printer), or lack a >>>>> suitable browser for a more traditional OAuth flow. This >>>>> authorization flow instructs the user to perform the authorization >>>>> request on a secondary device, such as a smartphone. There is no >>>>> requirement for communication between the constrained device and t= he >>>>> user's secondary device. >>>>> >>>>> >>>>> >>>>> >>>>> The file can be obtained via >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >>>>> >>>>> IESG discussion can be tracked via >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/ >>>>> >>>>> >>>>> No IPR declarations have been submitted directly on this I-D. >>>>> >>>>> >>>>> The document contains these normative downward references. >>>>> See RFC 3967 for additional information: >>>>> rfc6819: OAuth 2.0 Threat Model and Security Considerations >>>>> (Informational - IETF stream) >>>>> draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile >>>>> (None - ) >>>>> rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IET= F >>>>> stream) >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> 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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=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._ --000000000000b8872f056d742716 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I realize this is somewhat pedantic but I don't t= hink referencing 4.1.2.1 works given how RFC 6749 set things up. Rather I b= elieve that the device flow needs to define and register "access_denie= d" as a valid token endpoint response error code (it's not a token= endpoint response error per RFC 6749 sec 5.2 nor has it been registered https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error).= =C2=A0 Also invalid_grant is a a token endpoint response error from RFC 674= 9 sec 5.2 so that reference is needed and appropriate. RFC 6749 Sec 4.= 1.2.1 defines errors returned from the authorization endpoint. But the = device flow errors are from the token endpoint.






On Wed, May 30, 2018 at 4:2= 7 PM, William Denniss <wdenniss=3D40google.com@dmarc.= ietf.org> wrote:
Hi Andrew,

On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <andrewsciberras@pingidentity.com> wrote:<= br>
Hi William

=
You are right that the document explicitly indica= tes which error codes may be returned. However I think it's ambiguous a= s to which error within Section 5.2 of RFC6749 would apply in the scenario = of a user not granting access.=C2=A0

I think that this ambigui= ty is highlighted further by the Google implementation (https://developer= s.google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests) not adhering to the explicit statemen= t of the document and electing to use a (more appropriate) error code that = exists outside of section 5.2.=C2=A0=C2=A0
=C2=A0
<= /div>

Oh, I see what you mean = now. Yes, given this is an authorization request, not a token request, the = errors from Section 4.1.2.1 are more relevant.

I believe it was the authors intention to reference that set of error= s, so I will plan to update the doc to reference 4..1.2.1 instead.=C2=A0 Go= od catch! Thank you.



On Thu, May 31, 2018 at 8:06 AM, William Den= niss <wdenniss@google.com> wrote:
Hi Andrew,
On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciberras@pingid=
entity.com> wrote:

Hello


Do we feel th= at the document should be more specific in addressing how the authorization= service should respond to a device access token request when the user has = refused to grant access to the device?=C2=A0


The document = currently indicates in section 3.5 that a success response defined in secti= on 5.1 of RFC6749, an error as defined in section 5.2 of RFC6749 (this incl= udes invalid_request, invalid_client, invalid_grant, unauthorized_client, u= nsupported_grant_type, and invalid_scope), or a new device flow error code = (authorization_pending, slow_down, and expired_token) may be returned in a = response to a device token request.=C2=A0


It doesn=E2= =80=99t seem that any of these options are appropriate to convey that a use= r has refused to grant access to the device.=C2=A0


The Google im= plementation appears to be using the access_denied error code from section = 4.1.2.1 of RFC6749. While this would seem to be the most suitable error cod= e, the document does not explicitly indicate it as a permitted response. If the user h= as approved the grant, the token endpoint responds with a success response defined in Section 5.1 of [RFC6749]; othe= rwise it responds with an error, as defined in Section 5.2 of [RFC6749].

In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specific for the device flow:
=C2=A0


I believe tha= t clarifying the response error code in the condition where a user has refu= sed access to the client would be beneficial, remove ambiguity, and promote= greater consistency across implementations.=C2=A0


Regards

Andrew Sciber= ras=C2=A0



On Wed, May 30, 2018 at 8:20 AM, The IESG <iesg-secretary@iet= f.org> wrote:

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow fo= r
Browserless and Input Constrained Devices'
=C2=A0 <draft-ietf-oauth-device-flow-09.txt> as Proposed Standar= d

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

Abstract


=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.




The file can be obtained via
https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/d<= wbr>oc/draft-ietf-oauth-device-flow/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc6819: OAuth 2.0 Threat Model and Security Considerations (= Informational - IETF stream)
=C2=A0 =C2=A0 draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile=
=C2=A0(None - )
=C2=A0 =C2=A0 rfc6755: An IETF URN Sub-Namespace for OAuth (Informational -= IETF stream)



_______________________________________________
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



<= 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. --000000000000b8872f056d742716-- From nobody Wed May 30 17:06: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 30E2A12EBD5 for ; Wed, 30 May 2018 17:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.25 X-Spam-Level: X-Spam-Status: No, score=-17.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 gPIh3tR-8cnc for ; Wed, 30 May 2018 17:06:51 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 B5D8512EBC5 for ; Wed, 30 May 2018 17:06:50 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id n134-v6so12244145vke.12 for ; Wed, 30 May 2018 17:06:50 -0700 (PDT) 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=zhvObqCM4eGIrjUTUA33F3rutCiwW3t/LO2twMSxDk0=; b=bv/A+zjIdjfD4PthMpNM3FBPtxw2MvX9QBDOP7EYq5e4xwkJ1ejjeD88zHgnjbIqTC dwkBf0lEdVa6980+J5QhZc5Y6sbV5Vm+346skAC2v67iNtUFTorupcT9SCIvw3M+MYor BQGY9CQmo25zK46vmwe2d68I0yJMI85s5Lwyoix6FEUj6NY6q1rIitjwgC0R915TxtCW xhO9HCTcbTcyfe+69ym7c6qVnLmJh5ogNMkCWnIPGerybKzyXIMH8jqPtxcNxGmWeMWm hl1Gj1sdUThK87IyfF+gLaFjIfffKEcvLyD+HrLCXMBSJslK7IBU1N2HZmtD4y+wmyA9 Esaw== 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=zhvObqCM4eGIrjUTUA33F3rutCiwW3t/LO2twMSxDk0=; b=MR4eHgMNhXAFh2tGzBXCLCShHunq9bMPzmelDZrN4smg1df/H3Qu0jYBeIPIu1+9z0 uWKy1hezz7Ch0EAR713rvqlKXO82tNHLO3v3voZkPWpzMEVJUMy/NdaF4CXQAYlaxT80 mUVFiTOv3Hr6axrWFZUS2PFP3SVThHkjesvRG7vll5sAGffB/xbHuWX71HfrqkW7smX9 1kd6Kf5AnOxq5mnx7p7irXNVUYdBFgpbUSqV7x8FcKINTB/x6HYNKug3EEgDMqMpGitB tq9px9vsIVHewdymNqwH8fa1i+wDgem+rNrGMoAl4CAI3+ufOvDQakqH6Ok0F3/ajlXe /7gw== X-Gm-Message-State: ALKqPwcwanQl8/PSRLZ43kiE/GN8hwN0QkfXksaSBNw/ockXoxzLM5M/ HhqVRTRtaICJmGQQIrqrc/BP1tonGGqb0xMgd97RoQ== X-Google-Smtp-Source: ADUXVKJmbB/mFjiHbnx+4fakWwfwnQxVJQH5yuV5YJVx8RLrvjkm/A9i7sWbOlca+b61mVZVmOBfwGqqP/QdaCZ/7Qg= X-Received: by 2002:a1f:830b:: with SMTP id f11-v6mr2844505vkd.152.1527725209107; Wed, 30 May 2018 17:06:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:2110:0:0:0:0:0 with HTTP; Wed, 30 May 2018 17:06:28 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: William Denniss Date: Wed, 30 May 2018 17:06:28 -0700 Message-ID: To: Brian Campbell Cc: William Denniss , Andrew Sciberras , draft-ietf-oauth-device-flow@ietf.org, oauth-chairs@ietf.org, ietf@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000067e6fb056d753e94" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 00:06:54 -0000 --00000000000067e6fb056d753e94 Content-Type: text/plain; charset="UTF-8" On Wed, May 30, 2018 at 3:48 PM, Brian Campbell wrote: > I realize this is somewhat pedantic but I don't think referencing 4.1.2.1 > works given how RFC 6749 set things up. Rather I believe that the device > flow needs to define and register "access_denied" as a valid token endpoint > response error code (it's not a token endpoint response error per RFC 6749 > sec 5.2 nor has it been registered https://www.iana.org/assignmen > ts/oauth-parameters/oauth-parameters.xhtml#extensions-error > > ). Also > invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so > that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1 > defines errors > returned > from the authorization endpoint. But the device flow errors are from the > token endpoint. > > Yes, that's true. It's still the token endpoint, so 5.2 does in fact apply, it's just we're mixing in authorization-style actions which were not previously considered/used for that endpoint. Do you have any proposed text to resolve this? > > On Wed, May 30, 2018 at 4:27 PM, William Denniss < > wdenniss=40google.com@dmarc.ietf.org> wrote: > > > Hi Andrew, > > > > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > > andrewsciberras@pingidentity.com> wrote: > > > >> Hi William > >> > >> You are right that the document explicitly indicates which error codes > >> may be returned. However I think it's ambiguous as to which error within > >> Section 5.2 of RFC6749 would apply in the scenario of a user not > granting > >> access. > >> > >> I think that this ambiguity is highlighted further by the Google > >> implementation (https://developers.google.com > >> /identity/protocols/OAuth2ForDevices#step-6-handle- > >> responses-to-polling-requests > >> Devices#step-6-handle-responses-to-polling-requests>) > >> not adhering to the explicit statement of the document and electing to > use > >> a (more appropriate) error code that exists outside of section 5.2. > >> > >> > > > > Oh, I see what you mean now. Yes, given this is an authorization request, > > not a token request, the errors from Section 4.1.2.1 > > are more relevant. > > > > I believe it was the authors intention to reference that set of errors, > so > > I will plan to update the doc to reference 4..1.2.1 instead. Good catch! > > Thank you. > > > > > >> > >> On Thu, May 31, 2018 at 8:06 AM, William Denniss > >> wrote: > >> > >>> Hi Andrew, > >>> > >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras < > andrewsciberras@pingidentity.com> wrote: > >>> > >>> Hello > >>>> > >>>> > >>>> Do we feel that the document should be more specific in addressing how > >>>> the authorization service should respond to a device access token > request > >>>> when the user has refused to grant access to the device? > >>>> > >>>> > >>>> The document currently indicates in section 3.5 that a success > response > >>>> defined in section 5.1 of RFC6749, an error as defined in section 5.2 > of > >>>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant, > >>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a > new > >>>> device flow error code (authorization_pending, slow_down, and > >>>> expired_token) may be returned in a response to a device token request > --00000000000067e6fb056d753e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:
I realiz= e this is somewhat pedantic but I don't think referencing 4.1.2.1
works given how RFC 6749 set things up. Rather I believe that the device flow needs to define and register "access_denied" as a valid toke= n endpoint
response error code (it's not a token endpoint response error per RFC 6= 749
sec 5.2 nor has it been registered https://www.iana.org/assignmen
ts/oauth-parameters/oauth-parameters.xhtml#extensions-error).= =C2=A0 Also
invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so=
that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
<https://tools.ietf.org/html/rfc6749#sectio= n-4.1.2> defines errors returned
from the authorization endpoint. But the device flow errors are from the token endpoint.


Yes, t= hat's true. It's still the token endpoint, so 5.2 does in fact appl= y, it's just we're mixing in authorization-style actions which were= not previously considered/used for that endpoint.

Do you have any proposed text to resolve this?
=C2=A0

On Wed, May 30, 2018 at 4:27 PM, William Denniss <
wdenniss=3D40google.com@dmarc.ietf.org> wrote:

> Hi Andrew,
>
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > = andrewsciberras@pingidentity.com> wrote:
>
>> Hi William
>>
>> You are right that the document explicitly indicates which error c= odes
>> may be returned. However I think it's ambiguous as to which er= ror within
>> Section 5.2 of RFC6749 would apply in the scenario of a user not g= ranting
>> access.
>>
>> I think that this ambiguity is highlighted further by the Google >> implementation (https://developers.google.com
>> /identity/protocols/OAuth2ForDevices#step-6-handle-
>> responses-to-polling-requests
>> <https://developers..google.com/identity/protocols/OAuth= 2ForDevices#step-6-handle-responses-to-polling-requests>)
>> not adhering to the explicit statement of the document and e= lecting to use
>> a (more appropriate) error code that exists outside of section 5.2= .
>>
>>
>
> Oh, I see what you mean now. Yes, given this is an authorization reque= st,
> not a token request, the errors from Section 4.1.2.1
> <https://tools.ietf.org/html/rf= c6749#section-4.1.2> are more relevant.
>
> I believe it was the authors intention to reference that set of errors= , so
> I will plan to update the doc to reference 4..1.2.1 instead.=C2= =A0 Good catch!
> Thank you.
>
>
>>
>> On Thu, May 31, 2018 at 8:06 AM, William Denniss <wdenniss@google.com>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciber= ras@pingidentity.com> wrote:
>>>
>>> Hello
>>>>
>>>>
>>>> Do we feel that the document should be more specific in ad= dressing how
>>>> the authorization service should respond to a device acces= s token request
>>>> when the user has refused to grant access to the device? >>>>
>>>>
>>>> The document currently indicates in section 3.5 that a suc= cess response
>>>> defined in section 5.1 of RFC6749, an error as defined in = section 5.2 of
>>>> RFC6749 (this includes invalid_request, invalid_client, in= valid_grant,
>>>> unauthorized_client, unsupported_grant_type, and invalid_s= cope), or a new
>>>> device flow error code (authorization_pending, slow_down, = and
>>>> expired_token) may be returned in a response to a device t= oken request

--00000000000067e6fb056d753e94-- From nobody Thu May 31 00:39:06 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 E524B126CF9; Thu, 31 May 2018 00:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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=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 1uNVZ_H7aWd1; Thu, 31 May 2018 00:39:02 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 D0789126579; Thu, 31 May 2018 00:39:01 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id j15-v6so739926wme.0; Thu, 31 May 2018 00:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Wrv15/lU/pM3Ev41iv/guX2IrXNBvSbX+8QZ49Bxcvk=; b=Ype1LDxdpa0mjzIIHrRpXJJniQAAJKBjFIXDCex8imyOI5UeQ9K5MFJATkDrh9u7hk AMjo6GyYMVp/4J2b6hjoSXiScG313RgFnC7SUQXyhXUGKjwVpRlPIBlNRhgautiF6tUt wRhaBkpRMtQ7Ol6k07FcbYt51apZyiR5UbBUQX3ztMen2wj6YEiWkNzJ0pHREh+fOmW5 PSeXmkU7e7Kmr4zp+3Gz/bj/7P3k+aTNStS9QyT6oRwiidBStxjQONvcc5vZORyRLrEl whqGg/HdtK+UL9n9eO3cF5yOJOEzfSWJmLY9vJ/D1q2M5qjqSAIp/KbvOc/XU68wj7H9 0xCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Wrv15/lU/pM3Ev41iv/guX2IrXNBvSbX+8QZ49Bxcvk=; b=OL0+IF+yx6KlAPLqMWMmvnIEJT1X7jlyiEtFSK+n+4XfzOoy9jKGgjI8CUAZezMsKV pBfpbtamuCxU9eqUj0L2muK3s936rElMTzovJgA9MjDVIoeCPNPe5HKfCR9fk28FGE84 RIJbtAZiZKa8lEBkJHVSatADH8rSX+5mmuvz4HBbodtAkMwmmSAcCmJulWIkPPBAFXRi mvLjvsiZ3yK+R5PMKVcexV3xZ2+FvDobmx7gQIKmCP/D6PnSIk0+KWSNIHpk+O7i4XC4 VScucO/cwrWRqw5n5oPj6gQGnlibfwH3qcn8cBqco2STceOyX0gb/p37EaOwGkP1Bd04 e0Hw== X-Gm-Message-State: ALKqPweqDShU351cGRhoeAmJeGDmJlupDoJLGfDXaDvUinivJ44ttsn1 JoIAcqdBHE6GSd4eupxhvrmIXKMWNSPoKgMuIwLrwQ== X-Google-Smtp-Source: ADUXVKLL1u+P4zCuGsRIyOh5y6EzebUpARE6Ryca+sJMzu2GvNpimYn9C+CzlH5gjxdrjKWNVbcSr/o6XTHMoM76HDU= X-Received: by 2002:a1c:7e87:: with SMTP id z129-v6mr3615822wmc.131.1527752339867; Thu, 31 May 2018 00:38:59 -0700 (PDT) MIME-Version: 1.0 Sender: nvnagr@gmail.com Received: by 2002:a1c:e712:0:0:0:0:0 with HTTP; Thu, 31 May 2018 00:38:59 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: Naveen Agarwal Date: Thu, 31 May 2018 00:38:59 -0700 X-Google-Sender-Auth: oACW6G0ArlD-gtgtbbnLTp9-RAw Message-ID: To: William Denniss Cc: Brian Campbell , ietf@ietf.org, draft-ietf-oauth-device-flow@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000085d183056d7b8f89" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 07:39:05 -0000 --00000000000085d183056d7b8f89 Content-Type: text/plain; charset="UTF-8" I have a general concern on making the device flow a standard as this suffers from a number of issues that are quite fatal. At Google we have limited this flow to be used for very basic/limited scopes as phishing concerns are very real. Also the protocol suffers from clients polling (overloading the servers) and server having to keep a large amount of state. I think this protocol is close to its useful end of life (at Google) and we are working on alternatives with stronger client attestation that also mitigate other issues. Separately, we have seen a lot more abusers/hackers use OAuth in various forms to attack users. I don't know how many IDPs have implemented this flow but by making it a standard, a lot more people will implement it and I'm sure they will not be able to avoid the issues that are highlighted. Sorry, I know it has taken a lot of work to get the document to his stage so my comments may feel too harsh and I apologize. Please do know that I have been quite involved in this protocol from the beginning and we have gone through a lot of pain and have been discussing shutting this down fairly regularly. So this is to start the conversation if we think this protocol is for the future or just something from our past that we want to see it documented as a standard. Thanks Naveen On Wed, May 30, 2018 at 5:06 PM, William Denniss < wdenniss=40google.com@dmarc.ietf.org> wrote: > > On Wed, May 30, 2018 at 3:48 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1 >> works given how RFC 6749 set things up. Rather I believe that the device >> flow needs to define and register "access_denied" as a valid token >> endpoint >> response error code (it's not a token endpoint response error per RFC 6749 >> sec 5.2 nor has it been registered https://www.iana.org/assignmen >> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error >> >> ). Also >> invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 >> so >> that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1 >> defines errors >> returned >> from the authorization endpoint. But the device flow errors are from the >> token endpoint. >> >> > Yes, that's true. It's still the token endpoint, so 5.2 does in fact > apply, it's just we're mixing in authorization-style actions which were not > previously considered/used for that endpoint. > > Do you have any proposed text to resolve this? > > >> >> On Wed, May 30, 2018 at 4:27 PM, William Denniss < >> wdenniss=40google.com@dmarc.ietf.org> wrote: >> >> > Hi Andrew, >> > >> > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < >> > andrewsciberras@pingidentity.com> wrote: >> > >> >> Hi William >> >> >> >> You are right that the document explicitly indicates which error codes >> >> may be returned. However I think it's ambiguous as to which error >> within >> >> Section 5.2 of RFC6749 would apply in the scenario of a user not >> granting >> >> access. >> >> >> >> I think that this ambiguity is highlighted further by the Google >> >> implementation (https://developers.google.com >> >> /identity/protocols/OAuth2ForDevices#step-6-handle- >> >> responses-to-polling-requests >> >> > Devices#step-6-handle-responses-to-polling-requests>) >> >> not adhering to the explicit statement of the document and electing to >> use >> >> a (more appropriate) error code that exists outside of section 5.2.. >> >> >> >> >> > >> > Oh, I see what you mean now. Yes, given this is an authorization >> request, >> > not a token request, the errors from Section 4.1.2.1 >> > are more relevant. >> > >> > I believe it was the authors intention to reference that set of errors, >> so >> > I will plan to update the doc to reference 4..1.2.1 instead. Good >> catch! >> > Thank you. >> > >> > >> >> >> >> On Thu, May 31, 2018 at 8:06 AM, William Denniss >> >> wrote: >> >> >> >>> Hi Andrew, >> >>> >> >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras < >> andrewsciberras@pingidentity.com> wrote: >> >>> >> >>> Hello >> >>>> >> >>>> >> >>>> Do we feel that the document should be more specific in addressing >> how >> >>>> the authorization service should respond to a device access token >> request >> >>>> when the user has refused to grant access to the device? >> >>>> >> >>>> >> >>>> The document currently indicates in section 3.5 that a success >> response >> >>>> defined in section 5.1 of RFC6749, an error as defined in section >> 5.2 of >> >>>> RFC6749 (this includes invalid_request, invalid_client, >> invalid_grant, >> >>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or >> a new >> >>>> device flow error code (authorization_pending, slow_down, and >> >>>> expired_token) may be returned in a response to a device token >> request >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000085d183056d7b8f89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


I have a general concern on making= the device flow a standard as this suffers from a number of issues that ar= e quite fatal. At Google we have limited this flow to be used for very basi= c/limited scopes as phishing concerns are very real. Also the protocol suff= ers from clients polling (overloading the servers) and server having to kee= p a large amount of state. I think this protocol is close to its useful end= of life (at Google) and we are working on alternatives with stronger clien= t attestation that also mitigate other issues. Separately, we have seen a l= ot more abusers/hackers use OAuth in various forms to attack users.

I don't know how many IDPs have implemented this flow= but by making it a standard, a lot more people will implement it and I'= ;m sure they will not be able to avoid the issues that are highlighted.

Sorry, I know it has taken a lot of work to get the d= ocument to his stage so my comments may feel too harsh and I apologize. Ple= ase do know that I have been quite involved in this protocol from the begin= ning and we have gone through a lot of pain and have been discussing shutti= ng this down fairly regularly. So this is to start the conversation if we t= hink this protocol is for the future or just something from our past that w= e want to see it documented as a standard.

Thanks<= /div>

Naveen


On Wed, May 30, 2018 at 5:06 PM, W= illiam Denniss <wdenniss=3D40google.com@dmarc.ietf.or= g> wrote:
=

= On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:
<= span class=3D"">I realize this is somewhat pedantic but I don't think r= eferencing 4.1.2.1
works given how RFC 6749 set things up. Rather I believe that the device flow needs to define and register "access_denied" as a valid toke= n endpoint
response error code (it's not a token endpoint response error per RFC 6= 749
sec 5.2 nor has it been registered https://www.iana.org/assignmen
ts/oauth-parameters/oauth-parameters.xhtml#extensions-error).= =C2=A0 Also
invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so=
that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
<https://tools.ietf.org/html/rfc6749#sectio= n-4.1.2> defines errors returned
from the authorization endpoint. But the device flow errors are from the token endpoint.


Yes, that's true. It's still the token endpoint, so 5.2 does in fa= ct apply, it's just we're mixing in authorization-style actions whi= ch were not previously considered/used for that endpoint.

Do you have any proposed text to resolve this?
=C2=A0

On Wed, May 30, 2018 at 4:27 PM, William Denniss <
wdenniss=3D40google.com@dmarc.ietf.org> wrote:

> Hi Andrew,
>
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > = andrewsciberras@pingidentity.com> wrote:
>
>> Hi William
>>
>> You are right that the document explicitly indicates which error c= odes
>> may be returned. However I think it's ambiguous as to which er= ror within
>> Section 5.2 of RFC6749 would apply in the scenario of a user not g= ranting
>> access.
>>
>> I think that this ambiguity is highlighted further by the Google >> implementation (https://developers.google.com
>> /identity/protocols/OAuth2ForDevices#step-6-handle-
>> responses-to-polling-requests
>> <https://developers..google.com/identity/protocol= s/OAuth2ForDevices#step-6-handle-responses-to-polling-requests>)
>> not adhering to the explicit statement of t= he document and electing to use
 >> a (more appropriate) error code that exists outside of section 5.2= ..
>>
>>
>
> Oh, I see what you mean now. Yes, given this is an authorization reque= st,
> not a token request, the errors from Section 4.1.2.1
> <https://tools.ietf.org/html/= rfc6749#section-4.1.2> are more relevant.
>
> I believe it was the authors intention to reference that set of errors= , so
> I will plan to update the doc to reference 4..1.2.1 instead.=C2= =A0 Good catch!
> Thank you.
>
>
>>
>> On Thu, May 31, 2018 at 8:06 AM, William Denniss <wdenniss@google.com>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciber= ras@pingidentity.com> wrote:
>>>
>>> Hello
>>>>
>>>>
>>>> Do we feel that the document should be more specific in ad= dressing how
>>>> the authorization service should respond to a device acces= s token request
>>>> when the user has refused to grant access to the device? >>>>
>>>>
>>>> The document currently indicates in section 3.5 that a suc= cess response
>>>> defined in section 5.1 of RFC6749, an error as defined in = section 5.2 of
>>>> RFC6749 (this includes invalid_request, invalid_client, in= valid_grant,
>>>> unauthorized_client, unsupported_grant_type, and invalid_s= cope), or a new
>>>> device flow error code (authorization_pending, slow_down, = and
>>>> expired_token) may be returned in a response to a device t= oken request


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


--00000000000085d183056d7b8f89-- From nobody Thu May 31 08:37:25 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 889A41271DF; Thu, 31 May 2018 08:37:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ekr@rtfm.com, Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152778103651.22616.10291180354535377248.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2018 08:37:16 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 102 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:37:24 -0000 A new meeting session request has just been submitted by Hannes Tschofenig, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: secevent teep suit core tls ace sipcore acme tokbind People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu May 31 09:50: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 40F3212EB12 for ; Thu, 31 May 2018 09:50:20 -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=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 TaXBY8LjIkJU for ; Thu, 31 May 2018 09:50:18 -0700 (PDT) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D47F12E8DC for ; Thu, 31 May 2018 09:50:07 -0700 (PDT) Received: by mail-qt0-x241.google.com with SMTP id q6-v6so28657300qtn.3 for ; Thu, 31 May 2018 09:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ahsGHJ1QWdO4abM498bbFD+dGLFBrKqAx9QNyG41x+g=; b=TInNo+yWpmIrTQvIJKVGpaja84VUWOS3iFnnz3vn1j7WThsmn+GMe81ZCEKo8kR9gX CZqh+CIqBaUKznDni16QxD7LYPQmVn9LkO6cUfosniVxxEWZo8sr0omO5HH65qZMdzhX LF9lXWb9YCUm5cKZJEmCXJwjhYqrLgb4g1mtI= 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=ahsGHJ1QWdO4abM498bbFD+dGLFBrKqAx9QNyG41x+g=; b=IyIrprtzToWvw9MigMDWqIrZXVyG15NbAH7wup+wKpZXkNPGsiiNYU6r/LJtr5jaET ppJ199yH+MXxpgKjUqTXi6N2egpOdaEM7S8XrUnJNyXa1F32Zwu/DM3K+4eAw0/lsqKn Aw0OUTTJotMylI28C4eLZmr3uMDA/Rrc7Ifqt1lc+p5YFyo+UZL1UyNuCk44oa7AUysC pC485Cz4UOpZ0p8ju9VghBsbt3emxhGO11nJi8+u9bFwBptWV7jEOcy1E9zL+j4JTsSR Rgv4aF1/3ua1tEduNs4g7v/711wlX+fcFCCDyU6sjALcNxk7oj3SHgMDxOaRAWRP8JXA 1UvQ== X-Gm-Message-State: APt69E3J28uaMe0lU3XIXn0NqpPbJV32eL4RCEMTrmWSI1ASxFiptq+b L87zR2n6gZGY0tpyz3tDUi2gYFjCdBUlIkRz/ZBJjMcj7wHtGXa7lFVRYwRoE5Miq+jPwR78PYG mzy1UrY3GAMTzIw== X-Google-Smtp-Source: ADUXVKLyG7Uu5aVBZ+FfN9RiVoeEVoRTdur/QeM8t8YrafYaVCishzf8+Sxitge7jHRIb/XfZpMEggIJA40mPIyBx0I= X-Received: by 2002:ac8:1ca:: with SMTP id b10-v6mr7372750qtg.360.1527785406051; Thu, 31 May 2018 09:50:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:22e1:0:0:0:0:0 with HTTP; Thu, 31 May 2018 09:49:35 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 31 May 2018 10:49:35 -0600 Message-ID: To: William Denniss Cc: William Denniss , Andrew Sciberras , draft-ietf-oauth-device-flow@ietf.org, oauth-chairs@ietf.org, ietf@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000006bd1c2056d834205" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 16:50:28 -0000 --0000000000006bd1c2056d834205 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2018 at 6:06 PM, William Denniss wrote: > > On Wed, May 30, 2018 at 3:48 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> I realize this is somewhat pedantic but I don't think referencing 4.1.2.= 1 >> works given how RFC 6749 set things up. Rather I believe that the device >> flow needs to define and register "access_denied" as a valid token >> endpoint >> response error code (it's not a token endpoint response error per RFC 67= 49 >> sec 5.2 nor has it been registered https://www.iana.org/assignmen >> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error >> >> ). Also >> invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 >> so >> that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1 >> defines errors >> returned >> from the authorization endpoint. But the device flow errors are from the >> token endpoint. >> >> > Yes, that's true. It's still the token endpoint, so 5.2 does in fact > apply, it's just we're mixing in authorization-style actions which were n= ot > previously considered/used for that endpoint. > > Do you have any proposed text to resolve this? > > Sure, here's a crack at some text/changes: Add this to the list of error codes in section 3.5.: "access_denied The end-user denied the authorization request." And add this to section 7.2.1.: "o Error name: access_denied o Error usage location: Token endpoint response o Related protocol extension: [[ this specification ]] o Change controller: IETF o Specification Document: Section 3.5 of [[ this specification ]]" I might also slightly change this text in section 3.5: "In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specific for the device flow:" to "In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specified by the device flow:" so that the wording doesn't read as prohibiting the error codes from being used outside the device flow (access_denied from the token endpoint might well be useful for other grant types). And add "Andrew Sciberras" to the Acknowledgements. --=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._ --0000000000006bd1c2056d834205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 30, 2018 at 6:06 PM, William Denniss <= wdenniss@google.co= m> wrote:

On Wed, May 30, 2018 a= t 3:48 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I realize this is somewhat p= edantic but I don't think referencing 4.1.2.1
works given how RFC 6749 set things up. Rather I believe that the device flow needs to define and register "access_denied" as a valid toke= n endpoint
response error code (it's not a token endpoint response error per RFC 6= 749
sec 5.2 nor has it been registered https://www.iana.org/assignmen
ts/oauth-parameters/oauth-parameters.xhtml#extensions-error).= =C2=A0 Also
invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so=
that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
<https://tools.ietf.org/html/rfc6749#sectio= n-4.1.2> defines errors returned
from the authorization endpoint. But the device flow errors are from the token endpoint.


Yes, that's true. It's still the token endpoint, so 5.2 does in fa= ct apply, it's just we're mixing in authorization-style actions whi= ch were not previously considered/used for that endpoint.

Do you have any proposed text to resolve this?
=C2=A0

Sure, here's a crack at some text/changes:


Add this to the list of error codes in section 3.5.:

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "access_denied
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The e= nd-user denied the authorization request."


And add this to section 7.2= .1.:

=C2=A0 "o=C2=A0 Error name: access_denied
=C2=A0=C2=A0 o=C2= =A0 Error usage location: Token endpoint response
=C2=A0=C2=A0 o=C2=A0 R= elated protocol extension: [[ this specification ]]
=C2=A0=C2=A0 o=C2=A0= Change controller: IETF
=C2=A0=C2=A0 o=C2=A0 Specification Document: Se= ction 3.5 of [[ this specification ]]"


= I might also slightly change this text in section 3.5:

"In addition to = the error codes defined in Section 5.2 of [RFC6749],
=C2=A0=C2=A0 the fo= llowing error codes are specific for the device flow:"

to

"In addition to the= error codes defined in Section 5.2 of [RFC6749],
=C2=A0=C2=A0 the follo= wing error codes are specified by the device flow:"

so that the wording does= n't read as prohibiting the error codes from being used outside the dev= ice flow (access_denied from the token endpoint might well be useful for ot= her grant types).


And add "Andrew = Sciberras" to the Acknowledgements.



<= 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. --0000000000006bd1c2056d834205-- From nobody Thu May 31 11: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 C0D6F12E89D; Thu, 31 May 2018 11:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Jowfdj9s5ixS; Thu, 31 May 2018 11:20:16 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E99512E871; Thu, 31 May 2018 11:20:16 -0700 (PDT) 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=9Fgd1/1wFel1uGrAOseiZGq4lZ2x+jF8uSjRWfdhwk4=; b=YedCqN92xs6rgaVBqpN/lnVwbqRP6qWnxkGjn21pFVl2t0KaoNi2ri6kQmmc2z6V6efjuPTVToKwCk8exoHpWa+8Dhqil4glEWYpHr3eacz4HdRJ9sQxjySxGseJbtm1jrirUIEBqbk0rSRY4EAc64TvdEg6+A7ZnnADct1cFvk= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0413.namprd00.prod.outlook.com (52.132.118.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.861.0; Thu, 31 May 2018 18:20:14 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::7012:7d9f:583b:e000]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::7012:7d9f:583b:e000%2]) with mapi id 15.20.0862.000; Thu, 31 May 2018 18:20:14 +0000 From: Mike Jones To: Naveen Agarwal , William Denniss CC: Brian Campbell , "ietf@ietf.org" , "draft-ietf-oauth-device-flow@ietf.org" , oauth , "oauth-chairs@ietf.org" Thread-Topic: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard Thread-Index: AQHT95tS5UMH1jK7vEObnbqXfPO8UaRIzReAgAAIkACAAAOFAIAAAlqAgAAF4gCAABXSAIAAfm+AgACyD3A= Date: Thu, 31 May 2018 18:20:14 +0000 Message-ID: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> 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-05-31T18:20:11.4981054Z; 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:a:c8b7:10f0:56aa:22ce] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0413; 7:uivY9Oh42c5wlah8yXHKe558sV/+9TFezgjTeffNOFSlG6nJthPMgItHL7x5AATbIVo4366Ybt2BW4JFKJAJwcMzrsPro7AL4YpLcHLrmsHz1BYlGhFatGkNAjnxBe6uCERf7KUSjdWsF6Oae63l2HM5+LuLBlyL/gKt5xDWrFkkAwjq9hLbk8Kge2hWczo77K2kn9JNRtbmHPRkFWDz+8RTWBs0+5262fvTBzw7WDfLsAOBOII8YwMZJi1dMCec; 20:vevqokW4Q7OmQuIaVpMPk91GdokTgHjGz+INrmHn9ueoGHqFy/pRAi0nSL9y/iGhS6IloeuIVrvlV2juDQgmIoIXsE9J57Nt+oO7fJOV2l63CTYteQVfH0BcgRo1ltPt5YlNzhGYsjvK8y2yq7rsPebhcjx85tBjhSHxKHELQiE= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:SN6PR00MB0413; x-ms-traffictypediagnostic: SN6PR00MB0413: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(85827821059158)(211936372134217)(153496737603132)(21748063052155)(1591387915157)(168375693250761); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0413; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0413; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(39380400002)(376002)(396003)(51444003)(199004)(189003)(46003)(476003)(22452003)(966005)(2900100001)(14454004)(316002)(54906003)(11346002)(110136005)(446003)(229853002)(6436002)(72206003)(478600001)(10290500003)(33656002)(606006)(93886005)(106356001)(55016002)(486006)(7696005)(3280700002)(59450400001)(76176011)(2906002)(53546011)(3660700001)(7736002)(8990500004)(4326008)(5250100002)(10090500001)(25786009)(81156014)(8676002)(81166006)(8936002)(99286004)(6506007)(105586002)(19609705001)(74316002)(186003)(102836004)(68736007)(53936002)(6246003)(86362001)(5660300001)(54896002)(6306002)(236005)(97736004)(9686003)(53376002)(6116002)(790700001)(86612001)(16940595002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0413; H:SN6PR00MB0301.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: XNIWfGqQmWGlzOrSJcMcT9l9jvIMuyIOkaoXKtsHwoxAFWU1ydOix1PGNaOf6fS6pQp+eN+PJNcdwWxXA87iUpE54pbb83Rz4jiPUG4b0QLgcz6AoaVO2+F3s0FrzYr4bVeDXp49fsVllSQ/l5fxPLAX4MleWrVecVm3FXouCuMnlTa+vL3/UhtD1vfrKPrT spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0301BA58FEB996D8BA88373DF5630SN6PR00MB0301namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: df023d0d-ff00-40b0-5466-08d5c723276d X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: df023d0d-ff00-40b0-5466-08d5c723276d X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 18:20:14.0891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0413 Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 18:20:21 -0000 --_000_SN6PR00MB0301BA58FEB996D8BA88373DF5630SN6PR00MB0301namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmF2ZWVuLCBJIGhhdmUgdG8gZGlzYWdyZWUgd2l0aCB5b3VyIHJlY29tbWVuZGF0aW9uIHRoYXQg d2Ugbm90IGZpbmlzaCB0aGlzIHdvcmsuICBQZW9wbGUgaGF2ZSBiZWVuIHVzaW5nIHZhcmlhbnRz IG9mIHRoZSBkZXZpY2UgZmxvdyBmb3IgeWVhcnMuICBTdGFuZGFyZGl6aW5nIGl0IHdpbGwgaW1w cm92ZSBpbnRlcm9wZXJhYmlsaXR5LiAgQWxzbywgc3RhbmRhcmRpemluZyBpdCB3aWxsIG1ha2Ug dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB1c2luZyBpdCBjb21tb25seSBhdmFpbGFi bGUgdG8gaW1wbGVtZW50ZXJzIOKAkyB3aGVyZWFzIGN1cnJlbnRseSBwZW9wbGUgYXJlIG1vc3Rs eSBvcGVyYXRpbmcgaW4gdGhlIGRhcmsgb3IgYmFzZWQgb24gdGhlaXIgb3duIGludHVpdGlvbnMg b2Ygd2hhdOKAmXMgc2FmZSBhbmQgd2hhdOKAmXMgbm90Lg0KDQpJZiB5b3UgYmVsaWV2ZSB0aGF0 IHRoZXJlIGFyZSBzcGVjaWZpYyB0aGluZ3Mgd2Ugc2hvdWxkIGFkZCB0byB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMsIHBsZWFzZSBzYXkgd2hhdCB0aGV5IGFyZSwgYW5kIHdlIGNhbiBkbyBz by4gIEJ1dCBzYXlpbmcg4oCcc3RvcCBhbmQgd2FpdCBmb3Igc29tZXRoaW5nIGVsc2UgdGhhdCBp c27igJl0IGRlZmluZWQgeWV04oCdIGlzbuKAmXQgYSBoZWxwZnVsIG9yIHJlYWxpc3RpYyBwb3Np dGlvbiB0byB0YWtlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBudm5hZ3JAZ21haWwuY29t IDxudm5hZ3JAZ21haWwuY29tPiBPbiBCZWhhbGYgT2YgTmF2ZWVuIEFnYXJ3YWwNClNlbnQ6IFRo dXJzZGF5LCBNYXkgMzEsIDIwMTggMTI6MzkgQU0NClRvOiBXaWxsaWFtIERlbm5pc3MgPHdkZW5u aXNzPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBCcmlhbiBDYW1wYmVsbCA8YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20+OyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRo LWRldmljZS1mbG93QGlldGYub3JnOyBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+OyBvYXV0aC1jaGFp cnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtb2F1dGgtZGV2aWNlLWZsb3ctMDkudHh0PiAoT0F1dGggMi4wIERldmljZSBGbG93IGZvciBC cm93c2VybGVzcyBhbmQgSW5wdXQgQ29uc3RyYWluZWQgRGV2aWNlcykgdG8gUHJvcG9zZWQgU3Rh bmRhcmQNCg0KDQoNCkkgaGF2ZSBhIGdlbmVyYWwgY29uY2VybiBvbiBtYWtpbmcgdGhlIGRldmlj ZSBmbG93IGEgc3RhbmRhcmQgYXMgdGhpcyBzdWZmZXJzIGZyb20gYSBudW1iZXIgb2YgaXNzdWVz IHRoYXQgYXJlIHF1aXRlIGZhdGFsLiBBdCBHb29nbGUgd2UgaGF2ZSBsaW1pdGVkIHRoaXMgZmxv dyB0byBiZSB1c2VkIGZvciB2ZXJ5IGJhc2ljL2xpbWl0ZWQgc2NvcGVzIGFzIHBoaXNoaW5nIGNv bmNlcm5zIGFyZSB2ZXJ5IHJlYWwuIEFsc28gdGhlIHByb3RvY29sIHN1ZmZlcnMgZnJvbSBjbGll bnRzIHBvbGxpbmcgKG92ZXJsb2FkaW5nIHRoZSBzZXJ2ZXJzKSBhbmQgc2VydmVyIGhhdmluZyB0 byBrZWVwIGEgbGFyZ2UgYW1vdW50IG9mIHN0YXRlLiBJIHRoaW5rIHRoaXMgcHJvdG9jb2wgaXMg Y2xvc2UgdG8gaXRzIHVzZWZ1bCBlbmQgb2YgbGlmZSAoYXQgR29vZ2xlKSBhbmQgd2UgYXJlIHdv cmtpbmcgb24gYWx0ZXJuYXRpdmVzIHdpdGggc3Ryb25nZXIgY2xpZW50IGF0dGVzdGF0aW9uIHRo YXQgYWxzbyBtaXRpZ2F0ZSBvdGhlciBpc3N1ZXMuIFNlcGFyYXRlbHksIHdlIGhhdmUgc2VlbiBh IGxvdCBtb3JlIGFidXNlcnMvaGFja2VycyB1c2UgT0F1dGggaW4gdmFyaW91cyBmb3JtcyB0byBh dHRhY2sgdXNlcnMuDQoNCkkgZG9uJ3Qga25vdyBob3cgbWFueSBJRFBzIGhhdmUgaW1wbGVtZW50 ZWQgdGhpcyBmbG93IGJ1dCBieSBtYWtpbmcgaXQgYSBzdGFuZGFyZCwgYSBsb3QgbW9yZSBwZW9w bGUgd2lsbCBpbXBsZW1lbnQgaXQgYW5kIEknbSBzdXJlIHRoZXkgd2lsbCBub3QgYmUgYWJsZSB0 byBhdm9pZCB0aGUgaXNzdWVzIHRoYXQgYXJlIGhpZ2hsaWdodGVkLg0KDQpTb3JyeSwgSSBrbm93 IGl0IGhhcyB0YWtlbiBhIGxvdCBvZiB3b3JrIHRvIGdldCB0aGUgZG9jdW1lbnQgdG8gaGlzIHN0 YWdlIHNvIG15IGNvbW1lbnRzIG1heSBmZWVsIHRvbyBoYXJzaCBhbmQgSSBhcG9sb2dpemUuIFBs ZWFzZSBkbyBrbm93IHRoYXQgSSBoYXZlIGJlZW4gcXVpdGUgaW52b2x2ZWQgaW4gdGhpcyBwcm90 b2NvbCBmcm9tIHRoZSBiZWdpbm5pbmcgYW5kIHdlIGhhdmUgZ29uZSB0aHJvdWdoIGEgbG90IG9m IHBhaW4gYW5kIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHNodXR0aW5nIHRoaXMgZG93biBmYWlybHkg cmVndWxhcmx5LiBTbyB0aGlzIGlzIHRvIHN0YXJ0IHRoZSBjb252ZXJzYXRpb24gaWYgd2UgdGhp bmsgdGhpcyBwcm90b2NvbCBpcyBmb3IgdGhlIGZ1dHVyZSBvciBqdXN0IHNvbWV0aGluZyBmcm9t IG91ciBwYXN0IHRoYXQgd2Ugd2FudCB0byBzZWUgaXQgZG9jdW1lbnRlZCBhcyBhIHN0YW5kYXJk Lg0KDQpUaGFua3MNCg0KTmF2ZWVuDQoNCg0KT24gV2VkLCBNYXkgMzAsIDIwMTggYXQgNTowNiBQ TSwgV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzcz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOndkZW5uaXNzPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpP biBXZWQsIE1heSAzMCwgMjAxOCBhdCAzOjQ4IFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3Jv dGU6DQpJIHJlYWxpemUgdGhpcyBpcyBzb21ld2hhdCBwZWRhbnRpYyBidXQgSSBkb24ndCB0aGlu ayByZWZlcmVuY2luZyA0LjEuMi4xDQp3b3JrcyBnaXZlbiBob3cgUkZDIDY3NDkgc2V0IHRoaW5n cyB1cC4gUmF0aGVyIEkgYmVsaWV2ZSB0aGF0IHRoZSBkZXZpY2UNCmZsb3cgbmVlZHMgdG8gZGVm aW5lIGFuZCByZWdpc3RlciAiYWNjZXNzX2RlbmllZCIgYXMgYSB2YWxpZCB0b2tlbiBlbmRwb2lu dA0KcmVzcG9uc2UgZXJyb3IgY29kZSAoaXQncyBub3QgYSB0b2tlbiBlbmRwb2ludCByZXNwb25z ZSBlcnJvciBwZXIgUkZDIDY3NDkNCnNlYyA1LjIgbm9yIGhhcyBpdCBiZWVuIHJlZ2lzdGVyZWQg aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVuDQp0cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRo LXBhcmFtZXRlcnMueGh0bWwjZXh0ZW5zaW9ucy1lcnJvcikuICBBbHNvDQppbnZhbGlkX2dyYW50 IGlzIGEgYSB0b2tlbiBlbmRwb2ludCByZXNwb25zZSBlcnJvciBmcm9tIFJGQyA2NzQ5IHNlYyA1 LjIgc28NCnRoYXQgcmVmZXJlbmNlIGlzIG5lZWRlZCBhbmQgYXBwcm9wcmlhdGUuIFJGQyA2NzQ5 IFNlYyA0LjEuMi4xDQo8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlv bi00LjEuMj4gZGVmaW5lcyBlcnJvcnMgcmV0dXJuZWQNCmZyb20gdGhlIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQuIEJ1dCB0aGUgZGV2aWNlIGZsb3cgZXJyb3JzIGFyZSBmcm9tIHRoZQ0KdG9rZW4g ZW5kcG9pbnQuDQoNClllcywgdGhhdCdzIHRydWUuIEl0J3Mgc3RpbGwgdGhlIHRva2VuIGVuZHBv aW50LCBzbyA1LjIgZG9lcyBpbiBmYWN0IGFwcGx5LCBpdCdzIGp1c3Qgd2UncmUgbWl4aW5nIGlu IGF1dGhvcml6YXRpb24tc3R5bGUgYWN0aW9ucyB3aGljaCB3ZXJlIG5vdCBwcmV2aW91c2x5IGNv bnNpZGVyZWQvdXNlZCBmb3IgdGhhdCBlbmRwb2ludC4NCg0KRG8geW91IGhhdmUgYW55IHByb3Bv c2VkIHRleHQgdG8gcmVzb2x2ZSB0aGlzPw0KDQoNCk9uIFdlZCwgTWF5IDMwLCAyMDE4IGF0IDQ6 MjcgUE0sIFdpbGxpYW0gRGVubmlzcyA8DQp3ZGVubmlzcz00MGdvb2dsZS5jb21AZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQo+IEhp IEFuZHJldywNCj4NCj4gT24gV2VkLCBNYXkgMzAsIDIwMTggYXQgMzoxOCBQTSwgQW5kcmV3IFNj aWJlcnJhcyA8DQo+IGFuZHJld3NjaWJlcnJhc0BwaW5naWRlbnRpdHkuY29tPG1haWx0bzphbmRy ZXdzY2liZXJyYXNAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KPg0KPj4gSGkgV2lsbGlhbQ0K Pj4NCj4+IFlvdSBhcmUgcmlnaHQgdGhhdCB0aGUgZG9jdW1lbnQgZXhwbGljaXRseSBpbmRpY2F0 ZXMgd2hpY2ggZXJyb3IgY29kZXMNCj4+IG1heSBiZSByZXR1cm5lZC4gSG93ZXZlciBJIHRoaW5r IGl0J3MgYW1iaWd1b3VzIGFzIHRvIHdoaWNoIGVycm9yIHdpdGhpbg0KPj4gU2VjdGlvbiA1LjIg b2YgUkZDNjc0OSB3b3VsZCBhcHBseSBpbiB0aGUgc2NlbmFyaW8gb2YgYSB1c2VyIG5vdCBncmFu dGluZw0KPj4gYWNjZXNzLg0KPj4NCj4+IEkgdGhpbmsgdGhhdCB0aGlzIGFtYmlndWl0eSBpcyBo aWdobGlnaHRlZCBmdXJ0aGVyIGJ5IHRoZSBHb29nbGUNCj4+IGltcGxlbWVudGF0aW9uIChodHRw czovL2RldmVsb3BlcnMuZ29vZ2xlLmNvbQ0KPj4gL2lkZW50aXR5L3Byb3RvY29scy9PQXV0aDJG b3JEZXZpY2VzI3N0ZXAtNi1oYW5kbGUtDQo+PiByZXNwb25zZXMtdG8tcG9sbGluZy1yZXF1ZXN0 cw0KPj4gPGh0dHBzOi8vZGV2ZWxvcGVycy4uZ29vZ2xlLmNvbS9pZGVudGl0eS9wcm90b2NvbHMv T0F1dGgyRm9yRGV2aWNlcyNzdGVwLTYtaGFuZGxlLXJlc3BvbnNlcy10by1wb2xsaW5nLXJlcXVl c3RzPGh0dHA6Ly9nb29nbGUuY29tL2lkZW50aXR5L3Byb3RvY29scy9PQXV0aDJGb3JEZXZpY2Vz I3N0ZXAtNi1oYW5kbGUtcmVzcG9uc2VzLXRvLXBvbGxpbmctcmVxdWVzdHM+PikNCj4+IG5vdCBh ZGhlcmluZyB0byB0aGUgZXhwbGljaXQgc3RhdGVtZW50IG9mIHRoZSBkb2N1bWVudCBhbmQgZWxl Y3RpbmcgdG8gdXNlDQo+PiBhIChtb3JlIGFwcHJvcHJpYXRlKSBlcnJvciBjb2RlIHRoYXQgZXhp c3RzIG91dHNpZGUgb2Ygc2VjdGlvbiA1LjIuLg0KPj4NCj4+DQo+DQo+IE9oLCBJIHNlZSB3aGF0 IHlvdSBtZWFuIG5vdy4gWWVzLCBnaXZlbiB0aGlzIGlzIGFuIGF1dGhvcml6YXRpb24gcmVxdWVz dCwNCj4gbm90IGEgdG9rZW4gcmVxdWVzdCwgdGhlIGVycm9ycyBmcm9tIFNlY3Rpb24gNC4xLjIu MQ0KPiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjEuMj4g YXJlIG1vcmUgcmVsZXZhbnQuDQo+DQo+IEkgYmVsaWV2ZSBpdCB3YXMgdGhlIGF1dGhvcnMgaW50 ZW50aW9uIHRvIHJlZmVyZW5jZSB0aGF0IHNldCBvZiBlcnJvcnMsIHNvDQo+IEkgd2lsbCBwbGFu IHRvIHVwZGF0ZSB0aGUgZG9jIHRvIHJlZmVyZW5jZSA0Li4xLjIuMSBpbnN0ZWFkLiAgR29vZCBj YXRjaCENCj4gVGhhbmsgeW91Lg0KPg0KPg0KPj4NCj4+IE9uIFRodSwgTWF5IDMxLCAyMDE4IGF0 IDg6MDYgQU0sIFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NAZ29vZ2xlLmNvbTxtYWlsdG86d2Rl bm5pc3NAZ29vZ2xlLmNvbT4+DQo+PiB3cm90ZToNCj4+DQo+Pj4gSGkgQW5kcmV3LA0KPj4+DQo+ Pj4gT24gV2VkLCBNYXkgMzAsIDIwMTggYXQgMjozNSBQTSwgQW5kcmV3IFNjaWJlcnJhcyA8YW5k cmV3c2NpYmVycmFzQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmFuZHJld3NjaWJlcnJhc0BwaW5n aWRlbnRpdHkuY29tPj4gd3JvdGU6DQo+Pj4NCj4+PiBIZWxsbw0KPj4+Pg0KPj4+Pg0KPj4+PiBE byB3ZSBmZWVsIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBiZSBtb3JlIHNwZWNpZmljIGluIGFk ZHJlc3NpbmcgaG93DQo+Pj4+IHRoZSBhdXRob3JpemF0aW9uIHNlcnZpY2Ugc2hvdWxkIHJlc3Bv bmQgdG8gYSBkZXZpY2UgYWNjZXNzIHRva2VuIHJlcXVlc3QNCj4+Pj4gd2hlbiB0aGUgdXNlciBo YXMgcmVmdXNlZCB0byBncmFudCBhY2Nlc3MgdG8gdGhlIGRldmljZT8NCj4+Pj4NCj4+Pj4NCj4+ Pj4gVGhlIGRvY3VtZW50IGN1cnJlbnRseSBpbmRpY2F0ZXMgaW4gc2VjdGlvbiAzLjUgdGhhdCBh IHN1Y2Nlc3MgcmVzcG9uc2UNCj4+Pj4gZGVmaW5lZCBpbiBzZWN0aW9uIDUuMSBvZiBSRkM2NzQ5 LCBhbiBlcnJvciBhcyBkZWZpbmVkIGluIHNlY3Rpb24gNS4yIG9mDQo+Pj4+IFJGQzY3NDkgKHRo aXMgaW5jbHVkZXMgaW52YWxpZF9yZXF1ZXN0LCBpbnZhbGlkX2NsaWVudCwgaW52YWxpZF9ncmFu dCwNCj4+Pj4gdW5hdXRob3JpemVkX2NsaWVudCwgdW5zdXBwb3J0ZWRfZ3JhbnRfdHlwZSwgYW5k IGludmFsaWRfc2NvcGUpLCBvciBhIG5ldw0KPj4+PiBkZXZpY2UgZmxvdyBlcnJvciBjb2RlIChh dXRob3JpemF0aW9uX3BlbmRpbmcsIHNsb3dfZG93biwgYW5kDQo+Pj4+IGV4cGlyZWRfdG9rZW4p IG1heSBiZSByZXR1cm5lZCBpbiBhIHJlc3BvbnNlIHRvIGEgZGV2aWNlIHRva2VuIHJlcXVlc3QN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_SN6PR00MB0301BA58FEB996D8BA88373DF5630SN6PR00MB0301namp_ 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+TmF2ZWVuLCBJIGhhdmUgdG8gZGlzYWdyZWUgd2l0aCB5 b3VyIHJlY29tbWVuZGF0aW9uIHRoYXQgd2Ugbm90IGZpbmlzaCB0aGlzIHdvcmsuJm5ic3A7IFBl b3BsZSBoYXZlIGJlZW4gdXNpbmcgdmFyaWFudHMgb2YgdGhlIGRldmljZSBmbG93IGZvciB5ZWFy cy4mbmJzcDsgU3RhbmRhcmRpemluZyBpdCB3aWxsIGltcHJvdmUgaW50ZXJvcGVyYWJpbGl0eS4m bmJzcDsgQWxzbywgc3RhbmRhcmRpemluZw0KIGl0IHdpbGwgbWFrZSB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgZm9yIHVzaW5nIGl0IGNvbW1vbmx5IGF2YWlsYWJsZSB0byBpbXBsZW1lbnRl cnMg4oCTIHdoZXJlYXMgY3VycmVudGx5IHBlb3BsZSBhcmUgbW9zdGx5IG9wZXJhdGluZyBpbiB0 aGUgZGFyayBvciBiYXNlZCBvbiB0aGVpciBvd24gaW50dWl0aW9ucyBvZiB3aGF04oCZcyBzYWZl IGFuZCB3aGF04oCZcyBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J ZiB5b3UgYmVsaWV2ZSB0aGF0IHRoZXJlIGFyZSBzcGVjaWZpYyB0aGluZ3Mgd2Ugc2hvdWxkIGFk ZCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHBsZWFzZSBzYXkgd2hhdCB0aGV5IGFy ZSwgYW5kIHdlIGNhbiBkbyBzby4mbmJzcDsgQnV0IHNheWluZyDigJxzdG9wIGFuZCB3YWl0IGZv ciBzb21ldGhpbmcgZWxzZSB0aGF0IGlzbuKAmXQgZGVmaW5lZCB5ZXTigJ0gaXNu4oCZdA0KIGEg aGVscGZ1bCBvciByZWFsaXN0aWMgcG9zaXRpb24gdG8gdGFrZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBudm5hZ3JAZ21haWwuY29tICZsdDtudm5hZ3JA Z21haWwuY29tJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5OYXZlZW4gQWdhcndhbDxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDMxLCAyMDE4IDEyOjM5IEFNPGJyPg0KPGI+VG86PC9i PiBXaWxsaWFtIERlbm5pc3MgJmx0O3dkZW5uaXNzPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9y ZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbSZndDs7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZs b3dAaWV0Zi5vcmc7IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs7IG9hdXRoLWNoYWlyc0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBMYXN0IENhbGw6ICZs dDtkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA5LnR4dCZndDsgKE9BdXRoIDIuMCBEZXZp Y2UgRmxvdyBmb3IgQnJvd3Nlcmxlc3MgYW5kIElucHV0IENvbnN0cmFpbmVkIERldmljZXMpIHRv IFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGdl bmVyYWwgY29uY2VybiBvbiBtYWtpbmcgdGhlIGRldmljZSBmbG93IGEgc3RhbmRhcmQgYXMgdGhp cyBzdWZmZXJzIGZyb20gYSBudW1iZXIgb2YgaXNzdWVzIHRoYXQgYXJlIHF1aXRlIGZhdGFsLiBB dCBHb29nbGUgd2UgaGF2ZSBsaW1pdGVkIHRoaXMgZmxvdyB0byBiZSB1c2VkIGZvciB2ZXJ5IGJh c2ljL2xpbWl0ZWQgc2NvcGVzIGFzIHBoaXNoaW5nIGNvbmNlcm5zIGFyZSB2ZXJ5IHJlYWwuDQog QWxzbyB0aGUgcHJvdG9jb2wgc3VmZmVycyBmcm9tIGNsaWVudHMgcG9sbGluZyAob3ZlcmxvYWRp bmcgdGhlIHNlcnZlcnMpIGFuZCBzZXJ2ZXIgaGF2aW5nIHRvIGtlZXAgYSBsYXJnZSBhbW91bnQg b2Ygc3RhdGUuIEkgdGhpbmsgdGhpcyBwcm90b2NvbCBpcyBjbG9zZSB0byBpdHMgdXNlZnVsIGVu ZCBvZiBsaWZlIChhdCBHb29nbGUpIGFuZCB3ZSBhcmUgd29ya2luZyBvbiBhbHRlcm5hdGl2ZXMg d2l0aCBzdHJvbmdlciBjbGllbnQgYXR0ZXN0YXRpb24NCiB0aGF0IGFsc28gbWl0aWdhdGUgb3Ro ZXIgaXNzdWVzLiBTZXBhcmF0ZWx5LCB3ZSBoYXZlIHNlZW4gYSBsb3QgbW9yZSBhYnVzZXJzL2hh Y2tlcnMgdXNlIE9BdXRoIGluIHZhcmlvdXMgZm9ybXMgdG8gYXR0YWNrIHVzZXJzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IGtu b3cgaG93IG1hbnkgSURQcyBoYXZlIGltcGxlbWVudGVkIHRoaXMgZmxvdyBidXQgYnkgbWFraW5n IGl0IGEgc3RhbmRhcmQsIGEgbG90IG1vcmUgcGVvcGxlIHdpbGwgaW1wbGVtZW50IGl0IGFuZCBJ J20gc3VyZSB0aGV5IHdpbGwgbm90IGJlIGFibGUgdG8gYXZvaWQgdGhlIGlzc3VlcyB0aGF0IGFy ZSBoaWdobGlnaHRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U29ycnksIEkga25vdyBpdCBoYXMgdGFrZW4gYSBsb3Qgb2Ygd29yayB0byBn ZXQgdGhlIGRvY3VtZW50IHRvIGhpcyBzdGFnZSBzbyBteSBjb21tZW50cyBtYXkgZmVlbCB0b28g aGFyc2ggYW5kIEkgYXBvbG9naXplLiBQbGVhc2UgZG8ga25vdyB0aGF0IEkgaGF2ZSBiZWVuIHF1 aXRlIGludm9sdmVkIGluIHRoaXMgcHJvdG9jb2wgZnJvbSB0aGUgYmVnaW5uaW5nIGFuZCB3ZSBo YXZlIGdvbmUgdGhyb3VnaCBhIGxvdA0KIG9mIHBhaW4gYW5kIGhhdmUgYmVlbiBkaXNjdXNzaW5n IHNodXR0aW5nIHRoaXMgZG93biBmYWlybHkgcmVndWxhcmx5LiBTbyB0aGlzIGlzIHRvIHN0YXJ0 IHRoZSBjb252ZXJzYXRpb24gaWYgd2UgdGhpbmsgdGhpcyBwcm90b2NvbCBpcyBmb3IgdGhlIGZ1 dHVyZSBvciBqdXN0IHNvbWV0aGluZyBmcm9tIG91ciBwYXN0IHRoYXQgd2Ugd2FudCB0byBzZWUg aXQgZG9jdW1lbnRlZCBhcyBhIHN0YW5kYXJkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF2ZWVuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgMzAsIDIwMTgg YXQgNTowNiBQTSwgV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3M9 NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc3M9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1heSAzMCwg MjAxOCBhdCAzOjQ4IFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgcmVhbGl6ZSB0 aGlzIGlzIHNvbWV3aGF0IHBlZGFudGljIGJ1dCBJIGRvbid0IHRoaW5rIHJlZmVyZW5jaW5nIDQu MS4yLjE8YnI+DQp3b3JrcyBnaXZlbiBob3cgUkZDIDY3NDkgc2V0IHRoaW5ncyB1cC4gUmF0aGVy IEkgYmVsaWV2ZSB0aGF0IHRoZSBkZXZpY2U8YnI+DQpmbG93IG5lZWRzIHRvIGRlZmluZSBhbmQg cmVnaXN0ZXIgJnF1b3Q7YWNjZXNzX2RlbmllZCZxdW90OyBhcyBhIHZhbGlkIHRva2VuIGVuZHBv aW50PGJyPg0KcmVzcG9uc2UgZXJyb3IgY29kZSAoaXQncyBub3QgYSB0b2tlbiBlbmRwb2ludCBy ZXNwb25zZSBlcnJvciBwZXIgUkZDIDY3NDk8YnI+DQpzZWMgNS4yIG5vciBoYXMgaXQgYmVlbiBy ZWdpc3RlcmVkIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRo LXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54aHRtbCNleHRlbnNpb25zLWVycm9yIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW48YnI+DQp0cy9vYXV0 aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjZXh0ZW5zaW9ucy1lcnJvcjwvYT4p LiZuYnNwOyBBbHNvPGJyPg0KaW52YWxpZF9ncmFudCBpcyBhIGEgdG9rZW4gZW5kcG9pbnQgcmVz cG9uc2UgZXJyb3IgZnJvbSBSRkMgNjc0OSBzZWMgNS4yIHNvPGJyPg0KdGhhdCByZWZlcmVuY2Ug aXMgbmVlZGVkIGFuZCBhcHByb3ByaWF0ZS4gUkZDIDY3NDkgU2VjIDQuMS4yLjE8YnI+DQombHQ7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjEu MiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3Nl Y3Rpb24tNC4xLjI8L2E+Jmd0OyBkZWZpbmVzIGVycm9ycyByZXR1cm5lZDxicj4NCmZyb20gdGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIEJ1dCB0aGUgZGV2aWNlIGZsb3cgZXJyb3JzIGFyZSBm cm9tIHRoZTxicj4NCnRva2VuIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGF0J3MgdHJ1ZS4gSXQncyBz dGlsbCB0aGUgdG9rZW4gZW5kcG9pbnQsIHNvIDUuMiBkb2VzIGluIGZhY3QgYXBwbHksIGl0J3Mg anVzdCB3ZSdyZSBtaXhpbmcgaW4gYXV0aG9yaXphdGlvbi1zdHlsZSBhY3Rpb25zIHdoaWNoIHdl cmUgbm90IHByZXZpb3VzbHkgY29uc2lkZXJlZC91c2VkIGZvciB0aGF0IGVuZHBvaW50LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3Ug aGF2ZSBhbnkgcHJvcG9zZWQgdGV4dCB0byByZXNvbHZlIHRoaXM/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIFdlZCwg TWF5IDMwLCAyMDE4IGF0IDQ6MjcgUE0sIFdpbGxpYW0gRGVubmlzcyAmbHQ7PGJyPg0Kd2Rlbm5p c3M9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxi cj4NCiZndDsgSGkgQW5kcmV3LDxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFdlZCwgTWF5IDMwLCAy MDE4IGF0IDM6MTggUE0sIEFuZHJldyBTY2liZXJyYXMgJmx0Ozxicj4NCiZndDsgPGEgaHJlZj0i bWFpbHRvOmFuZHJld3NjaWJlcnJhc0BwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YW5kcmV3c2NpYmVycmFzQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZndDsgSGkgV2lsbGlhbTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWW91 IGFyZSByaWdodCB0aGF0IHRoZSBkb2N1bWVudCBleHBsaWNpdGx5IGluZGljYXRlcyB3aGljaCBl cnJvciBjb2Rlczxicj4NCiZndDsmZ3Q7IG1heSBiZSByZXR1cm5lZC4gSG93ZXZlciBJIHRoaW5r IGl0J3MgYW1iaWd1b3VzIGFzIHRvIHdoaWNoIGVycm9yIHdpdGhpbjxicj4NCiZndDsmZ3Q7IFNl Y3Rpb24gNS4yIG9mIFJGQzY3NDkgd291bGQgYXBwbHkgaW4gdGhlIHNjZW5hcmlvIG9mIGEgdXNl ciBub3QgZ3JhbnRpbmc8YnI+DQomZ3Q7Jmd0OyBhY2Nlc3MuPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBJIHRoaW5rIHRoYXQgdGhpcyBhbWJpZ3VpdHkgaXMgaGlnaGxpZ2h0ZWQgZnVydGhl ciBieSB0aGUgR29vZ2xlPGJyPg0KJmd0OyZndDsgaW1wbGVtZW50YXRpb24gKDxhIGhyZWY9Imh0 dHBzOi8vZGV2ZWxvcGVycy5nb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kZXZl bG9wZXJzLmdvb2dsZS5jb208L2E+PGJyPg0KJmd0OyZndDsgL2lkZW50aXR5L3Byb3RvY29scy9P QXV0aDJGb3JEZXZpY2VzI3N0ZXAtNi1oYW5kbGUtPGJyPg0KJmd0OyZndDsgcmVzcG9uc2VzLXRv LXBvbGxpbmctcmVxdWVzdHM8YnI+DQomZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kZXZl bG9wZXJzLiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGV2ZWxvcGVycy48L2E+LjxhIGhyZWY9 Imh0dHA6Ly9nb29nbGUuY29tL2lkZW50aXR5L3Byb3RvY29scy9PQXV0aDJGb3JEZXZpY2VzI3N0 ZXAtNi1oYW5kbGUtcmVzcG9uc2VzLXRvLXBvbGxpbmctcmVxdWVzdHMiIHRhcmdldD0iX2JsYW5r Ij5nb29nbGUuY29tL2lkZW50aXR5L3Byb3RvY29scy9PQXV0aDJGb3JEZXZpY2VzI3N0ZXAtNi1o YW5kbGUtcmVzcG9uc2VzLXRvLXBvbGxpbmctcmVxdWVzdHM8L2E+Jmd0Oyk8YnI+DQomZ3Q7Jmd0 OyBub3QgYWRoZXJpbmcgdG8gdGhlIGV4cGxpY2l0IHN0YXRlbWVudCBvZiB0aGUgZG9jdW1lbnQg YW5kIGVsZWN0aW5nIHRvIHVzZTxicj4NCiZndDsmZ3Q7IGEgKG1vcmUgYXBwcm9wcmlhdGUpIGVy cm9yIGNvZGUgdGhhdCBleGlzdHMgb3V0c2lkZSBvZiBzZWN0aW9uIDUuMi4uPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9oLCBJIHNlZSB3aGF0IHlvdSBt ZWFuIG5vdy4gWWVzLCBnaXZlbiB0aGlzIGlzIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCw8YnI+ DQomZ3Q7IG5vdCBhIHRva2VuIHJlcXVlc3QsIHRoZSBlcnJvcnMgZnJvbSBTZWN0aW9uIDQuMS4y LjE8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Njc0OSNzZWN0aW9uLTQuMS4yIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjEuMjwvYT4mZ3Q7IGFyZSBtb3JlIHJlbGV2YW50Ljxi cj4NCiZndDs8YnI+DQomZ3Q7IEkgYmVsaWV2ZSBpdCB3YXMgdGhlIGF1dGhvcnMgaW50ZW50aW9u IHRvIHJlZmVyZW5jZSB0aGF0IHNldCBvZiBlcnJvcnMsIHNvPGJyPg0KJmd0OyBJIHdpbGwgcGxh biB0byB1cGRhdGUgdGhlIGRvYyB0byByZWZlcmVuY2UgNC4uMS4yLjEgaW5zdGVhZC4mbmJzcDsg R29vZCBjYXRjaCE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyBUaGFuayB5b3UuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IE9uIFRodSwgTWF5IDMxLCAyMDE4IGF0IDg6MDYgQU0sIFdpbGxpYW0gRGVu bmlzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj53ZGVubmlzc0Bnb29nbGUuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBIaSBBbmRyZXcsPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIFdlZCwgTWF5IDMwLCAyMDE4IGF0IDI6MzUgUE0sIEFuZHJl dyBTY2liZXJyYXMgJmx0OzxhIGhyZWY9Im1haWx0bzphbmRyZXdzY2liZXJyYXNAcGluZ2lkZW50 aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHJld3NjaWJlcnJhc0BwaW5naWRlbnRpdHkuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhlbGxv PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IERvIHdlIGZlZWwgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlIG1vcmUgc3Bl Y2lmaWMgaW4gYWRkcmVzc2luZyBob3c8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBhdXRob3Jp emF0aW9uIHNlcnZpY2Ugc2hvdWxkIHJlc3BvbmQgdG8gYSBkZXZpY2UgYWNjZXNzIHRva2VuIHJl cXVlc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdoZW4gdGhlIHVzZXIgaGFzIHJlZnVzZWQgdG8g Z3JhbnQgYWNjZXNzIHRvIHRoZSBkZXZpY2U/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBkb2N1bWVudCBjdXJyZW50 bHkgaW5kaWNhdGVzIGluIHNlY3Rpb24gMy41IHRoYXQgYSBzdWNjZXNzIHJlc3BvbnNlPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyBkZWZpbmVkIGluIHNlY3Rpb24gNS4xIG9mIFJGQzY3NDksIGFuIGVy cm9yIGFzIGRlZmluZWQgaW4gc2VjdGlvbiA1LjIgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFJG QzY3NDkgKHRoaXMgaW5jbHVkZXMgaW52YWxpZF9yZXF1ZXN0LCBpbnZhbGlkX2NsaWVudCwgaW52 YWxpZF9ncmFudCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHVuYXV0aG9yaXplZF9jbGllbnQsIHVu c3VwcG9ydGVkX2dyYW50X3R5cGUsIGFuZCBpbnZhbGlkX3Njb3BlKSwgb3IgYSBuZXc8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IGRldmljZSBmbG93IGVycm9yIGNvZGUgKGF1dGhvcml6YXRpb25fcGVu ZGluZywgc2xvd19kb3duLCBhbmQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGV4cGlyZWRfdG9rZW4p IG1heSBiZSByZXR1cm5lZCBpbiBhIHJlc3BvbnNlIHRvIGEgZGV2aWNlIHRva2VuIHJlcXVlc3Q8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN6PR00MB0301BA58FEB996D8BA88373DF5630SN6PR00MB0301namp_-- From nobody Thu May 31 12:11: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 3E51C131585 for ; Thu, 31 May 2018 12:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 rF32sDmI5NfJ for ; Thu, 31 May 2018 12:11:15 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.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 DEB44131581 for ; Thu, 31 May 2018 12:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527793873; bh=AVbRB/Uckvyne/bO5mhbFP2TgSI4ZEpCqWzMTv6GFM8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=KyuDa67P3icwSrsDnV03UJ+/nPwLXCF/B23XBPmYTJyGnfQ7ujMDq10dTy0bH3pDUx6G8mucdu8gJCpA+9Bm+Adrz5qivSjLqEUb8em6pTQQGl/RCLKHoUpQosjdhyDNQxQwHqFw27DsKtpR+hrQLxaiV6wIpkizwCBgCzffRMzFiuZ5BN0h6Hq61nNr/NoKhyGXW5YTxF1M0Zc+f0QwqwScSESb3XL5/Iv3UigaVmUx1c0ZWOrLAVcuRpOYuWQtQJYbSCCGlCCdHE5XxPBjMv2igWXni9AYkJS9dSLLl3HxkrTwyVWbiLwpLcvULRIRphtixyH00/a7/Nte7qb5xA== X-YMail-OSG: vx96jZwVM1nZBJw4_pZK_BJ.dAYNf.9mX.8ivC9Jpk7YGsecQIBRCw4z3R7_iNN qSQrWL0qaKwBkc_pjy6bBbc9COFRtqNl6lW41aClHzYFZGexIBsGn5WCLbBYI0feAwEuYheqLSAq u2DdMR84Ae9hgJ0cnhZ3_80EmVTU4OTYIpvGcYneuIHeOIflw8NIS9A17EGCBxN9BEWdscxNeWyF R.sOx8fkK6VU3RXPVVnwGe.GFDalgswsQvixU26r_6rBBCVCC0FuwGJRtA.sW1zPQLaZeo1IP1pn PgzOXF8MtduEKEqBCFtbTv5MxkzTcWoGM.w5XhvOjtLmq.rwo86jQowJNfiggGTqKAj4zfj2pjSQ FswJJqD3zNU.KNwJwAS4N_LuBOHQxxYcW_z4T9WkVE8HDkoT2FZJlzC4SWT6oWbTriY8WkPU9LRw CpaF472f12L_IZmMg5itSx5E162tjGwE2HwAsxsPs02Pnsx1gEa4XmqLWSo5fD6n7kgENVfDKM9j hjjz19ez_vVxLycO3cQG.CmH6VfJ6dJCxcv_GH8NdPKXHJ8Q3HHE.q51MgnJ0QI7C8xcVD4jy79K RrkfdmVlpDLHC2_RweRbsnsggLxlMNg1KszA1KsKyii6U8qyR_IoiTK.ZanlcWSfMlKo0HIGaDZH x6Yg8GTnY0z87cPlEx16HETmEdJhSd5RVCqkl Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Thu, 31 May 2018 19:11:13 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e903c7e8a040f35db4f2b74cbb6d2c12; Thu, 31 May 2018 19:01:10 +0000 (UTC) To: Mike Jones , Naveen Agarwal , William Denniss Cc: "oauth-chairs@ietf.org" , oauth , "ietf@ietf.org" , "draft-ietf-oauth-device-flow@ietf.org" References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 31 May 2018 15:01:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7B595F595053802EA1A23BAB" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 19:11:19 -0000 This is a multi-part message in MIME format. --------------7B595F595053802EA1A23BAB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I second the request to enhance the security considerations section to address any known issues identified with the flow (e.g. phishing, client impersonation, etc). The polling/state issues are likely not at the same scale for other providers, as they are for Google, so I think this flow still has future value. Thanks, George On 5/31/18 2:20 PM, Mike Jones wrote: > > Naveen, I have to disagree with your recommendation that we not finish > this work.  People have been using variants of the device flow for > years.  Standardizing it will improve interoperability. Also, > standardizing it will make the security considerations for using it > commonly available to implementers – whereas currently people are > mostly operating in the dark or based on their own intuitions of > what’s safe and what’s not. > > If you believe that there are specific things we should add to the > security considerations, please say what they are, and we can do so. > But saying “stop and wait for something else that isn’t defined yet” > isn’t a helpful or realistic position to take. > > -- Mike > > *From:* nvnagr@gmail.com *On Behalf Of *Naveen Agarwal > *Sent:* Thursday, May 31, 2018 12:39 AM > *To:* William Denniss > *Cc:* Brian Campbell ; ietf@ietf.org; > draft-ietf-oauth-device-flow@ietf.org; oauth ; > oauth-chairs@ietf.org > *Subject:* Re: [OAUTH-WG] Last Call: > (OAuth 2.0 Device Flow for > Browserless and Input Constrained Devices) to Proposed Standard > > I have a general concern on making the device flow a standard as this > suffers from a number of issues that are quite fatal. At Google we > have limited this flow to be used for very basic/limited scopes as > phishing concerns are very real. Also the protocol suffers from > clients polling (overloading the servers) and server having to keep a > large amount of state. I think this protocol is close to its useful > end of life (at Google) and we are working on alternatives with > stronger client attestation that also mitigate other issues. > Separately, we have seen a lot more abusers/hackers use OAuth in > various forms to attack users. > > I don't know how many IDPs have implemented this flow but by making it > a standard, a lot more people will implement it and I'm sure they will > not be able to avoid the issues that are highlighted. > > Sorry, I know it has taken a lot of work to get the document to his > stage so my comments may feel too harsh and I apologize. Please do > know that I have been quite involved in this protocol from the > beginning and we have gone through a lot of pain and have been > discussing shutting this down fairly regularly. So this is to start > the conversation if we think this protocol is for the future or just > something from our past that we want to see it documented as a standard. > > Thanks > > Naveen > > On Wed, May 30, 2018 at 5:06 PM, William Denniss > > wrote: > > On Wed, May 30, 2018 at 3:48 PM, Brian Campbell > > > wrote: > > I realize this is somewhat pedantic but I don't think > referencing 4.1.2.1 > works given how RFC 6749 set things up. Rather I believe that > the device > flow needs to define and register "access_denied" as a valid > token endpoint > response error code (it's not a token endpoint response error > per RFC 6749 > sec 5.2 nor has it been registered https://www.iana.org/assignmen > ts/oauth-parameters/oauth-parameters.xhtml#extensions-error > ).  > Also > invalid_grant is a a token endpoint response error from RFC > 6749 sec 5.2 so > that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1 > defines > errors returned > from the authorization endpoint. But the device flow errors > are from the > token endpoint. > > Yes, that's true. It's still the token endpoint, so 5.2 does in > fact apply, it's just we're mixing in authorization-style actions > which were not previously considered/used for that endpoint. > > Do you have any proposed text to resolve this? > > > On Wed, May 30, 2018 at 4:27 PM, William Denniss < > wdenniss=40google.com@dmarc.ietf.org > > wrote: > > > Hi Andrew, > > > > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > > andrewsciberras@pingidentity.com > > wrote: > > > >> Hi William > >> > >> You are right that the document explicitly indicates which > error codes > >> may be returned. However I think it's ambiguous as to which > error within > >> Section 5.2 of RFC6749 would apply in the scenario of a > user not granting > >> access. > >> > >> I think that this ambiguity is highlighted further by the > Google > >> implementation (https://developers.google.com > >> /identity/protocols/OAuth2ForDevices#step-6-handle- > >> responses-to-polling-requests > >> > >) > >> not adhering to the explicit statement of the document and > electing to use > >> a (more appropriate) error code that exists outside of > section 5.2.. > >> > >> > > > > Oh, I see what you mean now. Yes, given this is an > authorization request, > > not a token request, the errors from Section 4.1.2.1 > > are more > relevant. > > > > I believe it was the authors intention to reference that set > of errors, so > > I will plan to update the doc to reference 4..1.2.1 > instead.  Good catch! > > > Thank you. > > > > > >> > >> On Thu, May 31, 2018 at 8:06 AM, William Denniss > > > >> wrote: > >> > >>> Hi Andrew, > >>> > >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras > > wrote: > >>> > >>> Hello > >>>> > >>>> > >>>> Do we feel that the document should be more specific in > addressing how > >>>> the authorization service should respond to a device > access token request > >>>> when the user has refused to grant access to the device? > >>>> > >>>> > >>>> The document currently indicates in section 3.5 that a > success response > >>>> defined in section 5.1 of RFC6749, an error as defined in > section 5.2 of > >>>> RFC6749 (this includes invalid_request, invalid_client, > invalid_grant, > >>>> unauthorized_client, unsupported_grant_type, and > invalid_scope), or a new > >>>> device flow error code (authorization_pending, slow_down, and > >>>> expired_token) may be returned in a response to a device > token request > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------7B595F595053802EA1A23BAB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I second the request to enhance the security considerations section to address any known issues identified with the flow (e.g. phishing, client impersonation, etc). The polling/state issues are likely not at the same scale for other providers, as they are for Google, so I think this flow still has future value.

Thanks,
George

On 5/31/18 2:20 PM, Mike Jones wrote:

Naveen, I have to disagree with your recommendation that we not finish this work.  People have been using variants of the device flow for years.  Standardizing it will improve interoperability.  Also, standardizing it will make the security considerations for using it commonly available to implementers – whereas currently people are mostly operating in the dark or based on their own intuitions of what’s safe and what’s not.

 

If you believe that there are specific things we should add to the security considerations, please say what they are, and we can do so.  But saying “stop and wait for something else that isn’t defined yet” isn’t a helpful or realistic position to take.

 

                                                                -- Mike

 

From: nvnagr@gmail.com <nvnagr@gmail.com> On Behalf Of Naveen Agarwal
Sent: Thursday, May 31, 2018 12:39 AM
To: William Denniss <wdenniss=40google.com@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell@pingidentity.com>; ietf@ietf.org; draft-ietf-oauth-device-flow@ietf.org; oauth <oauth@ietf.org>; oauth-chairs@ietf.org
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

 

 

 

I have a general concern on making the device flow a standard as this suffers from a number of issues that are quite fatal. At Google we have limited this flow to be used for very basic/limited scopes as phishing concerns are very real. Also the protocol suffers from clients polling (overloading the servers) and server having to keep a large amount of state. I think this protocol is close to its useful end of life (at Google) and we are working on alternatives with stronger client attestation that also mitigate other issues. Separately, we have seen a lot more abusers/hackers use OAuth in various forms to attack users.

 

I don't know how many IDPs have implemented this flow but by making it a standard, a lot more people will implement it and I'm sure they will not be able to avoid the issues that are highlighted.

 

Sorry, I know it has taken a lot of work to get the document to his stage so my comments may feel too harsh and I apologize. Please do know that I have been quite involved in this protocol from the beginning and we have gone through a lot of pain and have been discussing shutting this down fairly regularly. So this is to start the conversation if we think this protocol is for the future or just something from our past that we want to see it documented as a standard.

 

Thanks

 

Naveen

 

 

On Wed, May 30, 2018 at 5:06 PM, William Denniss <wdenniss=40google.com@dmarc.ietf.org> wrote:

 

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I realize this is somewhat pedantic but I don't think referencing 4.1.2.1
works given how RFC 6749 set things up. Rather I believe that the device
flow needs to define and register "access_denied" as a valid token endpoint
response error code (it's not a token endpoint response error per RFC 6749
sec 5.2 nor has it been registered https://www.iana.org/assignmen
ts/oauth-parameters/oauth-parameters.xhtml#extensions-error).  Also
invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so
that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
<https://tools.ietf.org/html/rfc6749#section-4.1.2> defines errors returned
from the authorization endpoint. But the device flow errors are from the
token endpoint.

 

Yes, that's true. It's still the token endpoint, so 5.2 does in fact apply, it's just we're mixing in authorization-style actions which were not previously considered/used for that endpoint.

 

Do you have any proposed text to resolve this?

 


On Wed, May 30, 2018 at 4:27 PM, William Denniss <
wdenniss=40google.com@dmarc.ietf.org> wrote:

> Hi Andrew,
>
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> andrewsciberras@pingidentity.com> wrote:
>
>> Hi William
>>
>> You are right that the document explicitly indicates which error codes
>> may be returned. However I think it's ambiguous as to which error within
>> Section 5.2 of RFC6749 would apply in the scenario of a user not granting
>> access.
>>
>> I think that this ambiguity is highlighted further by the Google
>> implementation (https://developers.google.com
>> /identity/protocols/OAuth2ForDevices#step-6-handle-
>> responses-to-polling-requests
>> <https://developers..google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests>)
>> not adhering to the explicit statement of the document and electing to use
>> a (more appropriate) error code that exists outside of section 5.2..
>>
>>
>
> Oh, I see what you mean now. Yes, given this is an authorization request,
> not a token request, the errors from Section 4.1.2.1
> <https://tools.ietf.org/html/rfc6749#section-4.1.2> are more relevant.
>
> I believe it was the authors intention to reference that set of errors, so
> I will plan to update the doc to reference 4..1.2.1 instead.  Good catch!

> Thank you.
>
>
>>
>> On Thu, May 31, 2018 at 8:06 AM, William Denniss <wdenniss@google.com>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciberras@pingidentity.com> wrote:
>>>
>>> Hello
>>>>
>>>>
>>>> Do we feel that the document should be more specific in addressing how
>>>> the authorization service should respond to a device access token request
>>>> when the user has refused to grant access to the device?
>>>>
>>>>
>>>> The document currently indicates in section 3.5 that a success response
>>>> defined in section 5.1 of RFC6749, an error as defined in section 5.2 of
>>>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant,
>>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a new
>>>> device flow error code (authorization_pending, slow_down, and
>>>> expired_token) may be returned in a response to a device token request

 


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

 



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

--------------7B595F595053802EA1A23BAB--