From nobody Mon Feb 10 10:14:25 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB7D120019; Mon, 10 Feb 2020 10:14:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158135846124.3970.5036541129625161720@ietfa.amsl.com> Date: Mon, 10 Feb 2020 10:14:21 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 18:14:21 -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-14.txt Pages : 46 Date : 2020-02-10 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-14 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 Feb 11 10:43:51 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BD4120A14 for ; Tue, 11 Feb 2020 10:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 hT84tvWCw-HS for ; Tue, 11 Feb 2020 10:43:47 -0800 (PST) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) (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 E1D64120A17 for ; Tue, 11 Feb 2020 10:43:46 -0800 (PST) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id 1aVcjR4LMiljc1aVdjv2rF; Tue, 11 Feb 2020 11:43:45 -0700 To: oauth@ietf.org References: <158135846124.3970.5036541129625161720@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <0f312b87-7721-e8c1-30ef-b6cb7416248b@connect2id.com> Date: Tue, 11 Feb 2020 20:43:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158135846124.3970.5036541129625161720@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060107070207070700070100" X-CMAE-Envelope: MS4wfHKxWwyukdGOSg5cHhpdhS1KMZLmUd8kJUv0/j7z3e1KGkkjdmfP3hMBzjUW0bnrz1o0BhNjAZxSJQEbm3nORaQoOtmhCsZ4EAf0EToiJXgvRtB3sdSl ssrYbim/+0dA5sKqhIS13JfHUh6ATW1AhIYDNEJbXVfSxUrPCOWCpAqd Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 18:43:50 -0000 This is a cryptographically signed message in MIME format. --------------ms060107070207070700070100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Fantastic, we now have "code_challenge_methods_supported" defined for AS metadata and it's a MUST. Long overdue. Vladimir On 10/02/2020 20:14, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Web Authorization Protocol WG of the I= ETF. > > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-14.txt > Pages : 46 > Date : 2020-02-10 > > Abstract: > This document describes best current security practice for OAuth 2.0= =2E > 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-14 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-= 14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-14= > > > Please note that it may take a couple of minutes from the time of submi= ssion > 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/ > > _______________________________________________ > --------------ms060107070207070700070100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMTExODQzNDRaMC8G CSqGSIb3DQEJBDEiBCCAZFCyJJtycHy5JmjuQvjsG75df6MBnNRyakyfZrSniTBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAKxlq5DNsrWKBNr7hP9agVbfOfU0shM7pdkucXxKy9Ts/rf+ 4VW04MWWAqw91t1MvFh6G3ZpYK8rqByljJtvXyAQwUmKYpl3NIYRq9Uj3ljodtLleDE6Auu1 XHCH8jh2UBoY0gLvL+S+T/oHZV7Ft1fnNHsG34Oto/anURBUWF0A/Cg9ZjwLyVGnJHlGuWVT ydQ/BU3nhYPU7/qH6w+1kgJzinsKV6z2I7ek8x+R8lwCroBoNVYPBUQbW1YKkwCxsXCtHT5Z Jfpi4CKqtRGkHxw77+tJ6sNsYuJ6lw8wyoL+cLNPQV0CMmV2U2vuVUv85Q2mxAG3Uzbub4sK ID4K4pwAAAAAAAA= --------------ms060107070207070700070100-- From nobody Tue Feb 11 15:20:30 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEC1120837 for ; Tue, 11 Feb 2020 15:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Z-KSPmaCw308 for ; Tue, 11 Feb 2020 15:20:24 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A5412004C for ; Tue, 11 Feb 2020 15:20:23 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id d10so92581ljl.9 for ; Tue, 11 Feb 2020 15:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=biIgEBzGr14yFiR9F1Yqa8J7OrgDYLLN7qxtRz/gMEw=; b=F1P7V1cny9fHaF06ELepD9HrMgAG8POYthHYR0oxuWLKp8kVJ9O8l/u5kgIBUZC/nv ys6DDJ09d1mC1CVGhRxFncmcA6R+rXk2+iQa7Kj0pF/7PGyRLTuMXvbZOx+sG+fg07Aq D9fqexipXKbLvJ3X5zDSkzj7xx2/l3HXASwVbeUN2yujHKSddlh5mdim9/uuiTD+ZnZk Pxr01lUzaS+cCsV4qLrM6eGdEHJ0qpWEZjigTMQqluz+v4E135QGGMkpJWN/+eU5xw9u LQAeI11ovMLB2q1MvUYQIYY/GIfsNN/3dIe5YE1OZf3WmeRwdL1b3x+Kh4KWnRQbnCa8 F3ig== 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=biIgEBzGr14yFiR9F1Yqa8J7OrgDYLLN7qxtRz/gMEw=; b=rL/hj8zphNcC/5WonhVVbe4Hgsqw8WpDF+E+67afBUYP9RyD8pBdsAnpCoje3OwLOk YRKg1mO5NjANC7ZoSOV4bGfW0sCvoVzC17zjQSxeXgQv+Z/YpQm9N62p2vmnisSFBTtt 5UNvSWuHHu3D9TUxLRcKdkpxYoxncL9QN/LA3oILaN3ePJvfD2HvPIOgFRokmD0LdQM7 NHbdnX7CZJYmUKU6e9Jdber0yB9Dv53qpv3StzK2TUsxhCw14InezoikMWxMHjntD4ad 9joJEibNfthmnOqQh1KbIJ+f+ZH9hQ8lUPEDdhvdvQT/lsSqlr+fSNlhhjuS0Wo2n11O Ytfw== X-Gm-Message-State: APjAAAUtqDv4zCBW3bu1gOT15emT6uPyR2q9lfmfEqea4gNqmIgH9jrd hhNHejJMjUig+OQeaVxwFBCzqYWdtl8z+vCCC9C1UEwJFsPferVATIIjNN0Let0zzj2feaWp8Xq 5qZafrmWSH9hFRNAYMgg= X-Google-Smtp-Source: APXvYqwElrNbjSC/teuEZf/X1/HRd7Wr5/Dtfj1NbkvavwZCOf6/0ktgLKxyNd9U3TqE6HhU1SyUur5fS329UwVEE9Y= X-Received: by 2002:a2e:9a01:: with SMTP id o1mr5926064lji.247.1581463220768; Tue, 11 Feb 2020 15:20:20 -0800 (PST) MIME-Version: 1.0 References: <158135846124.3970.5036541129625161720@ietfa.amsl.com> <0f312b87-7721-e8c1-30ef-b6cb7416248b@connect2id.com> In-Reply-To: <0f312b87-7721-e8c1-30ef-b6cb7416248b@connect2id.com> From: Brian Campbell Date: Tue, 11 Feb 2020 16:19:54 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="0000000000007fe886059e55192d" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 23:20:27 -0000 --0000000000007fe886059e55192d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable code_challenge_methods_supported is/was already defined in RFC 8414, it's just kinda easy to miss that it's there as you'd typically expect to find that sort of thing in the doc that defines PKCE itself. But PKCE (RFC 7636) predates AS metadata (RFC 8414) so things are different in that case. I notice too that draft-ietf-oauth-security-topics-14 still erroneously has RFC 8418 as the reference next to code_challenge_methods_supported where it should be RFC 8414. On Tue, Feb 11, 2020 at 11:43 AM Vladimir Dzhuvinov wrote: > Fantastic, we now have "code_challenge_methods_supported" defined for AS > metadata and it's a MUST. Long overdue. > > Vladimir > > On 10/02/2020 20:14, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol WG of the > IETF. > > > > Title : OAuth 2.0 Security Best Current Practice > > Authors : Torsten Lodderstedt > > John Bradley > > Andrey Labunets > > Daniel Fett > > Filename : draft-ietf-oauth-security-topics-14.txt > > Pages : 46 > > Date : 2020-02-10 > > > > Abstract: > > This document describes best current security practice for OAuth 2.0= . > > It updates and extends the OAuth 2.0 Security Threat Model to > > incorporate practical experiences gathered since OAuth 2.0 was > > published and covers new threats relevant due to the broader > > application of OAuth 2.0. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-14 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-14 > > > > > > 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._ --0000000000007fe886059e55192d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
code_challenge_methods_supported is/was already defin= ed in RFC 8414, it's just kinda easy to miss that it's there as you= 'd typically expect to find that sort of thing in the doc that defines = PKCE itself. But PKCE (RFC 7636) predates AS metadata (RFC 8414) so things = are different in that case.

I notice too that= draft-ietf-oauth-security-topics-14 still erroneously has RFC 8418 as the = reference next to code_challenge_methods_supported where it should be RFC 8= 414.=C2=A0

On Tue, Feb 11, 2020 at 11:43 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wro= te:
Fantastic, w= e now have "code_challenge_methods_supported" defined for AS
metadata and it's a MUST. Long overdue.

Vladimir

On 10/02/2020 20:14, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol WG of the = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: OAuth 2.0 Security Best Current Practice
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Torsten Lodderstedt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0John Bradley
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Andrey Labunets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Daniel Fett
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-security-topics-14.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 46
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-02-10
>
> Abstract:
>=C2=A0 =C2=A0 This document describes best current security practice fo= r OAuth 2.0.
>=C2=A0 =C2=A0 It updates and extends the OAuth 2.0 Security Threat Mode= l to
>=C2=A0 =C2=A0 incorporate practical experiences gathered since OAuth 2.= 0 was
>=C2=A0 =C2=A0 published and covers new threats relevant due to the broa= der
>=C2=A0 =C2=A0 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/draf= t-ietf-oauth-security-topics-14
> https://datatracker.ie= tf.org/doc/html/draft-ietf-oauth-security-topics-14
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-oauth-security-topics-14
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
>


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

<= 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. --0000000000007fe886059e55192d-- From nobody Wed Feb 12 10:36:39 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881C0120A28 for ; Wed, 12 Feb 2020 10:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok7OeXlILUha for ; Wed, 12 Feb 2020 10:36:36 -0800 (PST) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09522120A1D for ; Wed, 12 Feb 2020 10:36:35 -0800 (PST) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id 1wsDjjzrtshfx1wsEjv6M1; Wed, 12 Feb 2020 11:36:35 -0700 X-CMAE-Analysis: v=2.3 cv=Rty70xuK c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=DCeuyAmqCDnMODE0U_oA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=esGgMcD7aKpODhBHuI0A:9 a=TRcCxHA2z9OZbpZW:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: vladimir@connect2id.com Cc: oauth References: <158135846124.3970.5036541129625161720@ietfa.amsl.com> <0f312b87-7721-e8c1-30ef-b6cb7416248b@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <9eac3c6f-ec5a-25ce-1ef7-b9883aa52224@connect2id.com> Date: Wed, 12 Feb 2020 20:36:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060300020403090905030409" X-CMAE-Envelope: MS4wfP1OSs/QTCETOfNSvq2JcikZC95PgtcNDbWIz+bVLp8tGFqGn61nLFiiEXMKBloUbP7iBjtQCNsnMqzY4V4uNcrbDPncPvhwsk+HakHk3Wazz8J7QtJF +/VibTSsg43+edkXnUO+NVs3XCKXj3n0xF0pqRL5wz/d9tjFT8b65bkU Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 18:36:38 -0000 This is a cryptographically signed message in MIME format. --------------ms060300020403090905030409 Content-Type: multipart/alternative; boundary="------------921CE25195A8AEEDF2181496" Content-Language: en-US This is a multi-part message in MIME format. --------------921CE25195A8AEEDF2181496 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Brian, we missed that entirely. Have there been any thoughts on specifying a matching client reg parameter for PKCE? Vladimir On 12/02/2020 01:19, Brian Campbell wrote: > code_challenge_methods_supported is/was already defined in RFC 8414, > it's just kinda easy to miss that it's there as you'd typically expect > to find that sort of thing in the doc that defines PKCE itself. But > PKCE (RFC 7636) predates AS metadata (RFC 8414) so things are > different in that case. > > I notice too that draft-ietf-oauth-security-topics-14 still > erroneously has RFC 8418 as the reference next to > code_challenge_methods_supported where it should be RFC 8414.=C2=A0 > > On Tue, Feb 11, 2020 at 11:43 AM Vladimir Dzhuvinov > > wrote: > > Fantastic, we now have "code_challenge_methods_supported" defined > for AS > metadata and it's a MUST. Long overdue. > > Vladimir > > On 10/02/2020 20:14, internet-drafts@ietf.org > wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the Web Authorization Protocol WG > of the IETF. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: OAuth 2.0 Security Best Current Practice > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: Torsten Lodderstedt > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0John Bradley > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Andrey Labunets > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Daniel Fett > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-ietf-oauth-security-topics-14.txt > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 46 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2020-02-10 > > > > Abstract: > >=C2=A0 =C2=A0 This document describes best current security practi= ce for > OAuth 2.0. > >=C2=A0 =C2=A0 It updates and extends the OAuth 2.0 Security Threat= Model to > >=C2=A0 =C2=A0 incorporate practical experiences gathered since OAu= th 2.0 was > >=C2=A0 =C2=A0 published and covers new threats relevant due to the= broader > >=C2=A0 =C2=A0 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-14 > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-top= ics-14 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topic= s-14 > > > > > > 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 > --------------921CE25195A8AEEDF2181496 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks Brian, we missed that entirely.

Have there been any thoughts on specifying a matching client reg parameter for PKCE?

Vladimir

On 12/02/2020 01:19, Brian Campbell wrote:
code_challenge_methods_supported is/was already defined in RFC 8414, it's just kinda easy to miss that it's there as you'd typically expect to find that sort of thing in the doc that defines PKCE itself. But PKCE (RFC 7636) predates AS metadata (RFC 8414) so things are different in that case.

I notice too that draft-ietf-oauth-security-topics-14 still erroneously has RFC 8418 as the reference next to code_challenge_methods_supported where it should be RFC 8414.=C2= =A0

On Tue, Feb 11, 2020 at 11:= 43 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
= Fantastic, we now have "code_challenge_methods_supported" defined for AS metadata and it's a MUST. Long overdue.

Vladimir

On 10/02/2020 20:14, internet-drafts@ietf.org wrote:<= br> > 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.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: OAuth 2.0 Security Best Current Practice
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: Torsten Lodderstedt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0John Bradley
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Andrey Labunets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Daniel Fett
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-oauth-security-topics-14.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: 46
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2020-02-10
>
> Abstract:
>=C2=A0 =C2=A0 This document describes best current security= practice for OAuth 2.0.
>=C2=A0 =C2=A0 It updates and extends the OAuth 2.0 Security= Threat Model to
>=C2=A0 =C2=A0 incorporate practical experiences gathered si= nce OAuth 2.0 was
>=C2=A0 =C2=A0 published and covers new threats relevant due= to the broader
>=C2=A0 =C2=A0 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-14
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-1= 4
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-14<= /a>
>
>
> 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= =2E
>
> 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

--------------921CE25195A8AEEDF2181496-- --------------ms060300020403090905030409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMTIxODM2MzJaMC8G CSqGSIb3DQEJBDEiBCDcn3SmD2a0rYmKu3EbRVExIvodKQFVp36qWXa3DTrmUzBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAGwIrr5KvtArRhdkmyYaaZWfm7atiS4xi64JL93EdGXJOfvH Lmci2SOSR6L3W6Ee8gm7IYlPmFBnt0AUAeKB9ENHlmZoXUYmjeBZujLLJ5rk4gKy6QvhOiNt dYgbXtdibssEdUbyVNNG+FY7gxEaKi3MSaCRacquP4YR1w7LLCQpFjHi8jV7I1emA4UepeZE 22cPcnpmRjoRov+wUiHZS0GU2scxBzhVbfklLDw4qhIDQN3XlnieS9f8KFFUdc/kY+N/qMst 5fwYm6pNaJ9iYLg3IjXZQ/iVkFvf3NXpGddkvZYx5SOgfZTTbZkre5ybpjuxDhqNor2MrnQe 4PG/5RcAAAAAAAA= --------------ms060300020403090905030409-- From nobody Wed Feb 12 15:29:19 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6AD12001A; Wed, 12 Feb 2020 15:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=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 ElZ-JZ2AMTYr; Wed, 12 Feb 2020 15:29:13 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640107.outbound.protection.outlook.com [40.107.64.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF32120019; Wed, 12 Feb 2020 15:29:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TZBLERURD3KRnmFioMfe+v2z6ckz+2dbd1W9y3eGxnfaqVIt2HxitM3Dj3ezKoLuFDwwBuRENHKyetyd9gORXeDGlqZ+mpSESlIGR/gztXQG/+VEdgo/SlAdjun8d1sgJbnpYcmZHLcDf34sYSpJYq/LJem0Swm0U9qU/MHeVAiWD2/57o5NwjwOOG2tXdlgfu1Ku0nTGi+JrIoaJl41PeyZZpwUN7gqqRZHcrvJvYfDzKTLpHN5YDVT7O8XKPBz4oYaJ+k3R1tPTSCQX45Hao8LgbFNJx37nnNncWyBM3m/V8eSNbLzXp0BLx5oDwrWXOvvoUTLmewZdwA7awaABQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sR4SCY2wwgIoFd/hAOHNbGpBtdIE/FSiZNyaPJVaHXY=; b=YpU6UY3NIuMQuDRe+zt/EviGiNqAgnsjZ58K7QD2/kcUxIMSffKN9KujUz0OBR91T/B+DXZ8T+mLHaFrB6wUMHthsvjc2d9yPnrnmfjrJHQLdGIcFnWrhIXal4ayFmKGcnzeIlqdVsHvzVPVeUyQnOONPYNzLDOXh7iGUPTW3TipL5TuxmzCOX4tCGA8PSYcRxS2gyKX8zK8cRrZunhEHn+NXbwyCAvRcUvGBGxyJ/570Ko0sNq0kDOh10IyAC4qNfMUAhDkyxwl5PZ2b6/ytpHAHysyDNvKK5APeuyVrF1556Z+z9sRfLy4RGNDQ4JGJ48gVFkGlGash6OSDJDUqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sR4SCY2wwgIoFd/hAOHNbGpBtdIE/FSiZNyaPJVaHXY=; b=KD1nzlcoJ1eWXGB0ITT53GL7O+yYFaQgk0tfQiXgOGZ+tYPen/uU0JHzAcw6XPNgSQfnTUqd6i48m97jhcS3h7e5FTiomYcUpPZS3uEYelLIMKwQ2jGKMrKB9k8rQZikutKMmy5Oi9y4rQw7oOYboBvPESXgRE9yJ+eM55ozOKw= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (10.255.125.23) by BL0PR00MB0403.namprd00.prod.outlook.com (52.132.20.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2761.0; Wed, 12 Feb 2020 23:29:11 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::393e:e323:9372:f755]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::393e:e323:9372:f755%3]) with mapi id 15.20.2769.000; Wed, 12 Feb 2020 23:29:11 +0000 From: Mike Jones To: "jose@ietf.org" , "oauth@ietf.org" CC: "nat@sakimura.org" , "ve7jtb@ve7jtb.com" , Sean Turner Thread-Topic: JWTs helping combat fraudulent and unwanted telephone calls Thread-Index: AdXh4vPXv93YS6C6SYO9au6ntF8OZA== Date: Wed, 12 Feb 2020 23:29:10 +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_ActionId=81fae285-1728-4d31-9a00-0000c8f4669e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-12T20:26:57Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.1.75.136] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9eb3b2cd-6124-4788-c474-08d7b0135d38 x-ms-traffictypediagnostic: BL0PR00MB0403: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(366004)(189003)(199004)(7696005)(81166006)(66946007)(52536014)(110136005)(9686003)(54906003)(26005)(81156014)(86362001)(966005)(8676002)(5660300002)(76116006)(186003)(8936002)(66476007)(6506007)(64756008)(55016002)(498600001)(71200400001)(66446008)(2906002)(33656002)(15650500001)(66556008)(4326008)(8990500004)(10290500003)(26123001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0403; H:MN2PR00MB0688.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qFPagCSYDmyZLP4/tQXnmRLROF5uKXmezPCGV4I+8fTUYdEPwTFvBy5Lwl0+XDahMIqX12ROQIwCTm9QMqBZYon9uH1rkNUEbi6krxxp+KizOUOI3uLHusN56xIJPmZ+Dn+jADY3BbYSbApvuS8Io4C5pVAMl43EHpoh0Fl6PbIA6+r4FQpYqe0patu99fct6aApds0UYeCiZy/JJQQFwWC6L5oBQpdFJSb6uhtldck/5bcnynY9zsOy152k8N/ozrKrM1klPJCWCs/tN3d5SvtUwP8x8GIv0FED2QGLkmzPEG9TuI3Drsev9ZPteQUrrMLVmYwIOTpr9gPfPK/ceRyXOaAGZn618L/+t8HOW2C9nie76TDoQpSYi+VqVG76S//KWyhe7PUtwkjqaLqO7kbQTPoRxdEIMZh6q2vtcYpdHVVpKLMxtqZ1Mzrs0KR6akzAnqIOi3cydqQQkiEa6ipiUx9WxFL2gzm5LBw93xwWXzER89qHM7vNM4VVrW1plXCcCwPwHS/p4jYYMpsw6XVtLGV9v81AJqtKY2lppkk6WbzPB6DwXX4B5NBKTf4B5WjRMpdig9hdvLiMwaDQtp17PHkKVD6gnnWkjPFxIKq9Il0enhu6Zgd9y4x6aww0AWcx2KoMknQ6bA6K29Ijz7n6F2HDjQxk89XxY/bZAEk= x-ms-exchange-antispam-messagedata: wQRWVqdHO5nKdVxx2OzT2S+2T5XEkEAlvUzGWr/+OoxgReIM5uMQK3NbUHCOkXQj0eiEoJyBQOrT+XdjhmlzV6uWagis9Bm485hiOlBkn1pKwnaWjafVG3I818WXY77inZ0Ai9qb+ZxhYvLE10kWqw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06881F2AB81562E8989E8887F51B0MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9eb3b2cd-6124-4788-c474-08d7b0135d38 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 23:29:10.9490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: M2thqzRu2NrAvvZqw1P/hxLVHthFrIB6Fv465s7zu2QJqBBXqS7U8DIjrk6klSuiFxQU+nks9HmYh+UHYlJ4AA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0403 Archived-At: Subject: [OAUTH-WG] JWTs helping combat fraudulent and unwanted telephone calls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 23:29:16 -0000 --_000_MN2PR00MB06881F2AB81562E8989E8887F51B0MN2PR00MB0688namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wanted to bring two excellent articles by the IETF on work by the STIR wo= rking group to combat fraudule= nt and unwanted telephone calls to your attention: * STIR into Action, January 202= 0: Abstract: Providers of voice over IP in the United States will be required= to implement the IETF's Secure Telephony Identity Revisited (STIR) protoco= l as a result of recently enacted legislation to address some of the root c= auses of illegal robocalling on the telephone network. * Causing a STIR, August 2019: Abstract: Recently, the output of the IETF Secure Telephony Identity Revis= ited (STIR) working group has received considerable attention from service = providers, regulators, and the press because it addresses some of the root = causes of the illegal robocalling which has crippled the telephone network. I love this work for two reasons. First, like the rest of you, I receive a= huge volume of unwanted and often fraudulent phone calls. I love that eng= ineers and regulators are partnering to take concrete steps to reduce the v= olume of these illegal and annoying calls. Second, I love it that the STIR protocols are using JSON Web Tokens (JWTs)<= https://tools.ietf.org/html/rfc7519> under the covers as the format to repr= esent verifiable statements about legitimate uses of telephone numbers, ena= bling verifiable Caller ID. It's often said that one sign of a standard ha= ving succeeded is that it's used for things that the inventors never imagin= ed. This is certainly such a case! I'm proud that the JSON Web Token, whi= ch we originally designed with digital identity use cases in mind, is now b= eing used in a completely different context to solve a real problem experie= nced by people every day. -- Mike P.S. This note was also posted at https://self-issued.info/?p=3D2045 and a= s @selfissued. --_000_MN2PR00MB06881F2AB81562E8989E8887F51B0MN2PR00MB0688namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wanted to bring two excellent articles by the IETF= on work by the STIR working group<= /a> to combat fraudulent and unwanted telephone calls to your attention:

 

Abstract:  Provi= ders of voice over IP in the United States will be required to implement th= e IETF’s Secure Telephony Identity Revisited (STIR) protocol as a res= ult of recently enacted legislation to address some of the root causes of illegal robocalling on the telephone network.

 

Abstract:  Recen= tly, the output of the IETF Secure Telephony Identity Revisited (STIR) work= ing group has received considerable attention from service providers, regul= ators, and the press because it addresses some of the root causes of the illegal robocalling which has crippled the = telephone network.

 

I love this work for two reasons.  First, like = the rest of you, I receive a huge volume of unwanted and often fraudulent p= hone calls.  I love that engineers and regulators are partnering to ta= ke concrete steps to reduce the volume of these illegal and annoying calls.

 

Second, I love it that the STIR protocols are using = JSON Web Tokens (JWTs) under the covers as the format to represent veri= fiable statements about legitimate uses of telephone numbers, enabling veri= fiable Caller ID.  It’s often said that one sign of a standard having succeeded is= that it’s used for things that the inventors never imagined.=   This is certainly such a case!  I’m proud that the JSON W= eb Token, which we originally designed with digital identity use cases in mind, is now being used in a completely different context to = solve a real problem experienced by people every day.

 

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

 

P.S.  This note was also posted at https://self-issued.info/?p=3D2045 and as @selfissued.

 

--_000_MN2PR00MB06881F2AB81562E8989E8887F51B0MN2PR00MB0688namp_-- From nobody Wed Feb 12 15:43:46 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6C112002F for ; Wed, 12 Feb 2020 15:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alT-ubE_Q03K for ; Wed, 12 Feb 2020 15:43:43 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A49120019 for ; Wed, 12 Feb 2020 15:43:43 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id i7so3348135ilr.7 for ; Wed, 12 Feb 2020 15:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8GdUtLGvdFQfUt/e8Ub4THBEAXhpoj7IbBMeH3A8bG0=; b=d7JoDA16zjJQw9mii+0iYGKI/TnLPWSA0/HjSNUevf5mO/gIxQ2VtggiHhwtdNlamy HATKJNCLmWl43beyiHnBWok2rPGDwiuRdO7RJcsjJEWkB39owVbzmCC7tnvA2zxX1OD9 9Yl7WV49vrA1Hf4w+hsOy6HYlJI/19XLGXU4O87JLcn0RcYZs0TIhUMtPeIkL772JoB5 RFz79TefFvhq0etqZPuZJ+GfLwjSs+BM9+8Tod9R3KkX9WrH/+ex3UwPdxhhfa9Vr9Sw LKUps6H9XjqfdxLqGs42h6pYBYXygRKJO/UEkiBIGr0qVhAQKvesrAdP59ThGjwBizLe ACXw== 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=8GdUtLGvdFQfUt/e8Ub4THBEAXhpoj7IbBMeH3A8bG0=; b=FMVAcrknoC1kBlD/LFOqCTCqLJPdeT+WfNXQ/QI/XD5tdr23tskmJQJLUrDKTjJrKc 6avazuG57tygiBJq7KNLfjHM2myrgs0HpZqU15nWSaIF9e9sZpeVzE+oakf5CayzsE0G Nw+hS2YOgt6EGlB1nir0u5ARIBC6+0BGV8ii9TzXzvkHbU11IEY8zaYkmqr1g19g5CCv Og6QuMCNQSHb3PVKgfXD0vqHtnEkiHccx8e6AH2KqSG+b1iGv4Mg3J/3FI48OHwqmTek ZwZUBDXQv1JPVaRALNh0sJ7Vj3G5QM5/BBcGifjW9JGvTqqHDdjRZZCr1wsXcHSO8dLE SoiA== X-Gm-Message-State: APjAAAWolBSD9iy8xIOGaTpHQAcMtnHNu7v1rGv8KEuQ1Wl/Ai1eb3mT mvO3ZZZI3DzY7AMqltQA4NOwwfAJ1xE= X-Google-Smtp-Source: APXvYqzlP/w/YieerKJhjG1Qt20qDqu4E19GSfKkTZ6FmolAiX90O/TGksInTfUqGZtNtLiMZcmNyQ== X-Received: by 2002:a92:b506:: with SMTP id f6mr13847563ile.103.1581551022539; Wed, 12 Feb 2020 15:43:42 -0800 (PST) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. [209.85.166.50]) by smtp.gmail.com with ESMTPSA id v18sm184332ilm.85.2020.02.12.15.43.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Feb 2020 15:43:41 -0800 (PST) Received: by mail-io1-f50.google.com with SMTP id h8so4372253iob.2 for ; Wed, 12 Feb 2020 15:43:41 -0800 (PST) X-Received: by 2002:a6b:3b10:: with SMTP id i16mr20888323ioa.46.1581551021540; Wed, 12 Feb 2020 15:43:41 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Wed, 12 Feb 2020 15:43:30 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] Implicit flow in the Security BCP draft -14 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 23:43:45 -0000 Hi all, I'm reading through the latest draft of the Security BCP, and noticed something I was hoping to get some clarification on. From the latest draft -14 section 2.1.2: > In order to avoid these issues, clients SHOULD NOT use the implicit > grant (response type "token") or other response types issuing access > tokens in the authorization response, unless access token injection > in the authorization response is prevented and the aforementioned > token leakage vectors are mitigated. My understanding is that there is no way to prevent access token injection in the authorization response with just OAuth. It's only once you introduce OpenID Connect that it becomes possible to prevent ID token injection. If my understanding is correct, then it seems like it would be more appropriate for the security BCP to say something like "access tokens MUST NOT be issued via the implicit grant." That would technically still leave open the possibility of using the hybrid response types in OIDC as long as the access token is delivered via the authorization code exchange, but clarifies that there is no way to protect the delivering access tokens via the implicit grant. So my question for the list is am I forgetting about some way to prevent this attack in OAuth? If not, can we rephrase this section of the Security BCP to better clarify the intent here? ---- Aaron Parecki aaronparecki.com From nobody Tue Feb 18 12:32:22 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56D5120815 for ; Tue, 18 Feb 2020 12:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyHvJyOd3TIF for ; Tue, 18 Feb 2020 12:32:19 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07348120813 for ; Tue, 18 Feb 2020 12:32:19 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id h23so24545882ljc.8 for ; Tue, 18 Feb 2020 12:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gPilq39T6nOhfGWoMrbL01DTSt1aJgtEfP+h1zGHKLo=; b=fOAgggWh7XrNymofI9x4CDIFB7AAZ3qqMdNLalC+bgCzrxek0Q1w2fkgh+s8vewFb2 NbnE8bxvNZEkkmQs2RkwReNf82+L94/wp3zSYwqCmK5WutRBAl8Vt785hTR6uskG8T9d HPGSqoV9NY56BXHZEucgLHtd+gSCKJZp6FMDkldapf+UkN0C6ovU5VitaJiGwMq22sls uSty1Y5NWEG6q60EDwLE3yKZnPR3aduJiMsOHicK5Wdv4ABryIlklDIGFtihcRw2eEv6 WfgydG774NX9zX66hLftNJ6gPbc4GIsCP90nlR6a04uTh3ZvmjGaZe0eSu5/BEq0sJEc Srgw== 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=gPilq39T6nOhfGWoMrbL01DTSt1aJgtEfP+h1zGHKLo=; b=m/5OrsKI8KHF00eOh6w7wnMn/udUIh7nnKfORCD6XfQFkzyy1ALrQKgVsWbhRpv5U8 D2A+jb/LsZu9R1JPEA9BHIr22Z8JH3QfYlJ6yuSCEhwn2TDZuGt3fttJFKBGAqwwliwl +H3FSmqOyIWYbVR29bL3Gsg2VZCFGj4V3k8Kzs3VQfuf0mg67BvcCdFNTznqrX1v+o/M GyjODQnABI7K9VBzYhZk044V5ti1ojnmtYSIIY7xORnROvW2o2Gds2xy/lsRfJZiCTK5 ySN9PduEE5GvaJD3NLAvkBFw7rb7PEMb1MQpb6H6QvHq3ht0t/ayexFTtEvvWHSvKNN/ Gq4Q== X-Gm-Message-State: APjAAAWH8jkpCpByCIdtzDoQ2VBEeDs/BgxfB1NTQ8/VrstsBlQJIWo4 j0+iQYz0vLGn56axpp5hVW0JHokI8fT4x8Ojcn4Ahx/I4+U= X-Google-Smtp-Source: APXvYqxJ01QMptGPMSsiAIknUPPRnb6YkALR49DbEVQTxWVK9p+Tm1L/jh6Zw4wEs1fszVNqZ54zwfXYdjEDh6DUAY4= X-Received: by 2002:a2e:580c:: with SMTP id m12mr13988988ljb.150.1582057936760; Tue, 18 Feb 2020 12:32:16 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Tue, 18 Feb 2020 12:31:50 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000055b8a5059edf9184" Archived-At: Subject: [OAUTH-WG] OAuth 2.1 - drop implicit flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 20:32:21 -0000 --00000000000055b8a5059edf9184 Content-Type: text/plain; charset="UTF-8" Hey List (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on) Given the points Aaron brought up in https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it? /Dick --00000000000055b8a5059edf9184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey List=C2=A0

=
(I'm using the OAuth 2.1 name as a placeholder f= or the doc that Aaron, Torsten, and I are working on)

Given the points Aaron brought up in



Does anyone ha= ve concerns with dropping the implicit flow from the OAuth 2.1 document so = that developers don't use it?

/Dick
--00000000000055b8a5059edf9184-- From nobody Tue Feb 18 12:37:57 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9DB120816 for ; Tue, 18 Feb 2020 12:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRacTyJ6SB6q for ; Tue, 18 Feb 2020 12:37:54 -0800 (PST) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::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 302A6120813 for ; Tue, 18 Feb 2020 12:37:54 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id q23so8464916ljm.4 for ; Tue, 18 Feb 2020 12:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Epbx8M7UJ6qH8wVEpyuQMFNBQCLazr4VW1npPesgGKc=; b=BK9QMogLqV7sJPvJoAKJfmQOFrsirSGRTedHQJX/fZ2QIKFs143X43Kpi5V9VD7kcW ZJeTeiUovMKlhjMl9X40DLTICuLCJ566BBP8sjOGDC6n185oiOCx+XT2DJVuakYQr45U z6vhLU1a/Mku+tGD9VqF7Frc66OerGy2eGFJmwn510CzqWlyPfFwAdqtOHjsjy4izcDP LEaVeAoiPXB2OyCfd7S31sVC8qoyeZeiT+h9+xKdQQ9c0qEh0V5JOzxKy95BDyaceMTz b7PeP50+ad5MvMrkCiO3nmNOmP6nhMknbovS1ds+QkHe9iF/FrIOTC855InT726947d8 6wBQ== 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=Epbx8M7UJ6qH8wVEpyuQMFNBQCLazr4VW1npPesgGKc=; b=b2rQgB8TFGUtd/QZofqZiE0gEzSAWLb0mvg0W3eJTtoOCqanNkAb+EvIbLIHN401BO +DMQUeWYjF+MQMwuKfqLqb4xIKyiFbUurdjCCIE+SOs8EGgUNgfT2SpGEQ//iTEBoZDo jjAIJSI2qhgCaTqb0F62X7BdBfDV36/jLgGhfNQrDt+q4XJQD+KofkUyjsdq6T8hAdO7 XqqJDxMdNzaeFp1lC2a7ORTqmtna9TIXO4oNbGgrJvK6C26TavI9dE7y3YWTtds4gFJp ZnN7LmSFpSEhlciiBEqifQLx91pLMNJ0Aljnmv98P5NufTgGXEHOXoFbN0AJIDL5Q/y7 E/cA== X-Gm-Message-State: APjAAAU7w2BbCAEUyRJaiDBxH6wNCXd1QhIfJg/v/exKXw6X1trrJWaz qQJpeR0nvoY1mDiVnAvDpLJExLKXeSUnyQe90GRIQqIADsc= X-Google-Smtp-Source: APXvYqyPYQ0iVILU5BPtK7giLt1MJFLc3pFr2OvLSYVAAQ318qzm7PR0zxJZaWkh1HT5WZSkLuMvdwwax/zopRS5E6Y= X-Received: by 2002:a2e:b5b4:: with SMTP id f20mr14301588ljn.112.1582058272007; Tue, 18 Feb 2020 12:37:52 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Tue, 18 Feb 2020 12:37:26 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000512bcd059edfa5d4" Archived-At: Subject: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 20:37:56 -0000 --000000000000512bcd059edfa5d4 Content-Type: text/plain; charset="UTF-8" Hey List (Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on) In the security topics doc https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4 The password grant MUST not be used. Some background for those interested. I added this grant into OAuth 2.0 to allow applications that had been provided password to migrate. Even with the caveats in OAuth 2.0, implementors decide they want to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate. Does anyone have concerns with dropping the password grant from the OAuth 2.1 document so that developers don't use it? /Dick --000000000000512bcd059edfa5d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Lis= t=C2=A0

(Once again using = the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I = are working on)

In the security topics doc


The password= grant MUST not be used.

Some background for those= interested. I added this grant into OAuth 2.0 to allow applications that h= ad been provided password to migrate. Even with the caveats in OAuth 2.0, i= mplementors decide they want to prompt the user to enter their credentials,= the anti-pattern OAuth was created to eliminate.=C2=A0


Does anyone have concerns with dropping the password g= rant from the OAuth 2.1 document so that developers don't use it?
=

/Dick
--000000000000512bcd059edfa5d4-- From nobody Tue Feb 18 12:54:20 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04121120145 for ; Tue, 18 Feb 2020 12:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 AHuxGk6j-PRd for ; Tue, 18 Feb 2020 12:54:16 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650093.outbound.protection.outlook.com [40.107.65.93]) (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 AE843120020 for ; Tue, 18 Feb 2020 12:54:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W75U2XBCDdndNieF7j4knL61SOZ9F8Y5isk6uVVw3BDGBSprctJanPN9JaDYBIMTTvToA52D5es0h01QlJJCVoZAVQtRbBn8Zo/KuKUgqj5HjwyqEckzBuzfXWfKjWaw3Mv0/h5jYIdo1b1x6F7J25YWBzSV0InE7HUEgrtGiOEd2NmKOXBrRMWBC6bVDLBgQS8O7IPuilb5zigZOso13SClvICf12wqXTGJvO6RaKe2S2l3Kp6GIGzrX+nlDbhvsgBtYaJX8in63sWD1o1e65cZrpnL4l4ZWksj0FEQcERYz94r+iWsOPnRyOSQnrzWk21209z/J9EmTIbF4EWE3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k0qs6Lsn8yC+dUx2mGBRHwtxhhF3wLgfChrUvSyyqzs=; b=m708cE4O6omQe+Cy6VG03nonCZo7MuNDNaInyBGQB7RBUtYiA0fSK9X9UPDciu5y3cLLaFwmSEUs+bA8UPwlyb0RQj4n1fZsUW+5cNr6tJCtTXizw+XRv1sb55dYqGnJf2u5xAlVz3rbOruKxTrq+ZzApjYZwU+NCwXhZqYblbJHpj51RxgeyicH2DwX9rdGBWpv8nZtvCLNc3m9AugtPf5mIoQ8/Eai9CxzEzxFPL4RS5bXK03xokacgBR1DEcBAKZBeDnduVldduWynBJhS+q2pW/3VJ4Q2BPcp0bOpvxTXSn3H00n9S8RWSlDrfhHSXwF24SCzWZyzDrav4J9NA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k0qs6Lsn8yC+dUx2mGBRHwtxhhF3wLgfChrUvSyyqzs=; b=gn9T1QqIzSnVLhyCbpXQ6Qsv5UxOZ5FHxF6UWQe/TJvt6o2XVOG4K5M81+X6PJ62i1CJgqQqe4fwkF3dem7G5Xo7zEJqFV5NrKh/xw82IdgPmm/FPviud74aG1/ZzTDd4OP3k3N3fUotmo4i+vB7gKrUzs8wHnkzSMze8XGuVfg= Received: from DM6PR00MB0634.namprd00.prod.outlook.com (20.179.49.147) by DM6PR00MB0553.namprd00.prod.outlook.com (20.179.49.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2773.0; Tue, 18 Feb 2020 20:54:14 +0000 Received: from DM6PR00MB0634.namprd00.prod.outlook.com ([fe80::4434:9fb6:686:c6c7]) by DM6PR00MB0634.namprd00.prod.outlook.com ([fe80::4434:9fb6:686:c6c7%7]) with mapi id 15.20.2778.000; Tue, 18 Feb 2020 20:54:14 +0000 From: Anthony Nadalin To: Dick Hardt , "oauth@ietf.org" Thread-Topic: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant Thread-Index: AQHV5ptWJHq6vVwudUipZRYjhEN6XKghbKQA Date: Tue, 18 Feb 2020 20:54:14 +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_ActionId=51b0d70b-20ed-44d7-a4b2-0000f98f3d06; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-18T20:49:35Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [167.220.2.106] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: abcdf466-621b-4f39-6eef-08d7b4b4b68d x-ms-traffictypediagnostic: DM6PR00MB0553: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 031763BCAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39860400002)(136003)(396003)(366004)(376002)(199004)(189003)(81156014)(71200400001)(76116006)(966005)(33656002)(478600001)(10290500003)(8676002)(52536014)(64756008)(26005)(86362001)(5660300002)(66946007)(9686003)(66556008)(66476007)(7696005)(8936002)(66446008)(55016002)(53546011)(316002)(8990500004)(186003)(2906002)(110136005)(6506007)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0553; H:DM6PR00MB0634.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tYjItNafU68vW8pSKbqNF05R676w+0BLOrUgQat4O7u6s0EnAnPOWPe6DBWEdDXA0slkeLSGMPNA6ceM38h6WIsl8ryMstSWhUlP++fkqdwjknvFYu8gCEEdEqmxMis6DsL+TPaSY97xi7nWAEX+XRKfoKLWDDd6xNn+S1pt72dzQC3VW4o0SNQCIVXcwssFV46M2kQWE7J0QG5V9DyWhF6YRP6YHLryabuedMpte22Gs7bKC5Guey0+JI9RVAP0ZAlGGA2uIM5QGlVb1QIWnzz+b3mw3pGapUyz1rfSHgIj5Vb/B149kymrHGNvrSyGnweiH76ergUgyEA+D7nlrzOXZ8edVwi99qtfH0oVdTKbHVC91/2HhLusj48UJXxYll5zRLyXn6wdwaWs0+sCxPuNTAI7pnsL4hjbaAoY8OyT3FiIXiHbXWzWWH86d76j5u7JRqc8s84v1xlbmimkCrKI5ir3bSZwWjreb/CxaUqGaaiLrQmCjTH7IaVEf2ei1O3VZ8RlszRAOMpFrVbTog== x-ms-exchange-antispam-messagedata: 2ZfNepJZvWM1atG9X1Yk17jkw8BOu1kG7Y4k4iyLRlmnqRGWvBClaK588pJM3q9iNCLj+/zMMHKMK9tFh6xhu0pPdFX95SVpTOfTPX8hDyo81wEJJNbdKV/1D/GELjTiQf6SvifMXAyz+lNrPd19WQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0634A176941D1078F3C655EEA6110DM6PR00MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: abcdf466-621b-4f39-6eef-08d7b4b4b68d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 20:54:14.5070 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cGr8R9G5xOEid27HU9XT/fWOi1jCgz+5dUvrHKS6iHSBSm0GrDCvxLXNl4POUUsg24evHIbOlQoVSUA2WQFdng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0553 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 20:54:19 -0000 --_000_DM6PR00MB0634A176941D1078F3C655EEA6110DM6PR00MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBzdWdnZXN0IGEgU0hPVUxEIE5PVCBpbnN0ZWFkIG9mIE1VU1QsIHRoZXJlIGFyZSBz dGlsbCBzaXRlcyB1c2luZyB0aGlzIGFuZCBhIGdyYWNlIHBlcmlvZCBzaG91bGQgYmUgcHJvdmlk ZWQgYmVmb3JlIGEgTVVTVCBpcyBwdXNoZWQgb3V0IGFzIHRoZXJlIGFyZSB2YWxpZCB1c2UgY2Fz ZXMgb3V0IHRoZXJlIHN0aWxsLg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE4LCAy MDIwIDEyOjM3IFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRFUk5BTF0gW09B VVRILVdHXSBPQXV0aCAyLjE6IGRyb3BwaW5nIHBhc3N3b3JkIGdyYW50DQoNCkhleSBMaXN0DQoN CihPbmNlIGFnYWluIHVzaW5nIHRoZSBPQXV0aCAyLjEgbmFtZSBhcyBhIHBsYWNlaG9sZGVyIGZv ciB0aGUgZG9jIHRoYXQgQWFyb24sIFRvcnN0ZW4sIGFuZCBJIGFyZSB3b3JraW5nIG9uKQ0KDQpJ biB0aGUgc2VjdXJpdHkgdG9waWNzIGRvYw0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTQjc2VjdGlvbi0yLjQ8aHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3Mt MTQlMjNzZWN0aW9uLTIuNCZkYXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3 QzQ3YmI1OTdlZWY1ODRjOTViYTQxMDhkN2I0YjI3NGIyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3NjU1MDkwNTMzMzI4MyZzZGF0YT1uQTFTN1RCZlpn NmNTd1kyaEk4aHBSWGhJQTJqb2FhSkZtTlhyQVRncjJZJTNEJnJlc2VydmVkPTA+DQoNClRoZSBw YXNzd29yZCBncmFudCBNVVNUIG5vdCBiZSB1c2VkLg0KDQpTb21lIGJhY2tncm91bmQgZm9yIHRo b3NlIGludGVyZXN0ZWQuIEkgYWRkZWQgdGhpcyBncmFudCBpbnRvIE9BdXRoIDIuMCB0byBhbGxv dyBhcHBsaWNhdGlvbnMgdGhhdCBoYWQgYmVlbiBwcm92aWRlZCBwYXNzd29yZCB0byBtaWdyYXRl LiBFdmVuIHdpdGggdGhlIGNhdmVhdHMgaW4gT0F1dGggMi4wLCBpbXBsZW1lbnRvcnMgZGVjaWRl IHRoZXkgd2FudCB0byBwcm9tcHQgdGhlIHVzZXIgdG8gZW50ZXIgdGhlaXIgY3JlZGVudGlhbHMs IHRoZSBhbnRpLXBhdHRlcm4gT0F1dGggd2FzIGNyZWF0ZWQgdG8gZWxpbWluYXRlLg0KDQoNCkRv ZXMgYW55b25lIGhhdmUgY29uY2VybnMgd2l0aCBkcm9wcGluZyB0aGUgcGFzc3dvcmQgZ3JhbnQg ZnJvbSB0aGUgT0F1dGggMi4xIGRvY3VtZW50IHNvIHRoYXQgZGV2ZWxvcGVycyBkb24ndCB1c2Ug aXQ/DQoNCi9EaWNrDQo= --_000_DM6PR00MB0634A176941D1078F3C655EEA6110DM6PR00MB0634namp_ 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 cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgd291bGQgc3VnZ2VzdCBhIFNIT1VMRCBOT1QgaW5zdGVhZCBvZiBNVVNULCB0aGVyZSBh cmUgc3RpbGwgc2l0ZXMgdXNpbmcgdGhpcyBhbmQgYSBncmFjZSBwZXJpb2Qgc2hvdWxkIGJlIHBy b3ZpZGVkIGJlZm9yZSBhIE1VU1QgaXMgcHVzaGVkIG91dCBhcyB0aGVyZSBhcmUgdmFsaWQgdXNl IGNhc2VzIG91dCB0aGVyZSBzdGlsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2Yg PC9iPg0KRGljayBIYXJkdDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxOCwg MjAyMCAxMjozNyBQTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW0VYVEVSTkFMXSBbT0FVVEgtV0ddIE9BdXRoIDIuMTogZHJvcHBpbmcgcGFzc3dv cmQgZ3JhbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhleSBMaXN0Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPihPbmNlIGFnYWluIHVzaW5nIHRoZSBPQXV0aCAyLjEgbmFtZSBhcyBh IHBsYWNlaG9sZGVyIGZvciB0aGUgZG9jIHRoYXQgQWFyb24sIFRvcnN0ZW4sIGFuZCBJIGFyZSB3 b3JraW5nIG9uKTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gdGhlIHNlY3VyaXR5IHRvcGljcyBkb2M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTQlMjNzZWN0aW9uLTIu NCZhbXA7ZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0M0N2JiNTk3ZWVm NTg0Yzk1YmE0MTA4ZDdiNGIyNzRiMiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdDMSU3QzAlN0M2MzcxNzY1NTA5MDUzMzMyODMmYW1wO3NkYXRhPW5BMVM3VEJmWmc2Y1N3WTJo SThocFJYaElBMmpvYWFKRm1OWHJBVGdyMlklM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNCNzZWN0 aW9uLTIuNDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIHBhc3N3b3JkIGdyYW50IE1VU1Qgbm90IGJlIHVzZWQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgYmFja2dyb3Vu ZCBmb3IgdGhvc2UgaW50ZXJlc3RlZC4gSSBhZGRlZCB0aGlzIGdyYW50IGludG8gT0F1dGggMi4w IHRvIGFsbG93IGFwcGxpY2F0aW9ucyB0aGF0IGhhZCBiZWVuIHByb3ZpZGVkIHBhc3N3b3JkIHRv IG1pZ3JhdGUuIEV2ZW4gd2l0aCB0aGUgY2F2ZWF0cyBpbiBPQXV0aCAyLjAsIGltcGxlbWVudG9y cyBkZWNpZGUgdGhleSB3YW50IHRvIHByb21wdCB0aGUgdXNlciB0byBlbnRlciB0aGVpcg0KIGNy ZWRlbnRpYWxzLCB0aGUgYW50aS1wYXR0ZXJuIE9BdXRoIHdhcyBjcmVhdGVkIHRvIGVsaW1pbmF0 ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Eb2VzIGFueW9uZSBoYXZlIGNvbmNlcm5zIHdpdGggZHJvcHBpbmcgdGhlIHBhc3N3 b3JkIGdyYW50IGZyb20gdGhlIE9BdXRoIDIuMSBkb2N1bWVudCBzbyB0aGF0IGRldmVsb3BlcnMg ZG9uJ3QgdXNlIGl0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR00MB0634A176941D1078F3C655EEA6110DM6PR00MB0634namp_-- From nobody Tue Feb 18 12:57:51 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB76120819 for ; Tue, 18 Feb 2020 12:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Ul3afYpXoULH for ; Tue, 18 Feb 2020 12:57:48 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BF7120145 for ; Tue, 18 Feb 2020 12:57:47 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id z5so510443lfd.12 for ; Tue, 18 Feb 2020 12:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nht3Qo4XwmthlaCkbTJwIEfcf4Kt+tzpryMh2DlSkJo=; b=QY2qAeAQsyUhf3Vvq2okK6ycDm1kOFZfDL9RSCtP+VipHymmTVkOePK9wO1cB8Y/ub tUr3nJI2M8ONa/t+XdhSMY4dIek+p6y7K8BMdzImCHykVwLQJ09fI2C/69QlKrWYcj+v FMBt2hKXfqZf3qDBBC89AnM5DVqX2V9RzTdUliwGjqmgltbw/z3rS0nGRjG6N5IOEyoa C4SI1ZZsg9kuXLzbEOiB5oLKfbnHwkcUbrLlaSC9BbpbbVQdxf6eqgum7SQR9aug8EtO nxIzXtyqhV/RZ5vLUz8oK3De8ex3GqAXQWVJ8+psqUi/fVx2Um4QfvccZwr+rfK45DqT 6rIA== 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=nht3Qo4XwmthlaCkbTJwIEfcf4Kt+tzpryMh2DlSkJo=; b=hYXYzI+t108H/kSMvrtUPRW1gnocupyf0LLVbP6NeCwtUm4/xVMu+dusINmElvc+Ir 6VeMdPGVsSSMLaX7rR/KChUHpi80ChneuaU6YXijZ8ZJ5QrJFpiEo9z5xJLGwUmJxuSs nKcHfsVtpJpxjogmISHv9I5HMc/5uxDsOW1F2vMb7VoDYRilJ/K4HSQAdiUIO/IawNeH kIpsJullrP3wNMthPj9tT/Gxi5zl22umvFAOYeQgVSOb1tEvC9xQbVNK6rvk1g9asS8V aIYkrB6weoows5ZrIMNZgwGOCWdNOvguK6UF8OvlF/nQRoUrCDgUJtohApsfViTELU1H gVLQ== X-Gm-Message-State: APjAAAXVR0oO9YlUfijgCmPqqkWMlmkq9sPE7pZdez10NzGtOVRatomm 5nPMoi7th60hbjZPbuDT9P7tlcsScqH/bSIp1rWEUpOO X-Google-Smtp-Source: APXvYqwacEq4I7K9LaeqWjQQ6rttybo0EhByjKe1Pwcdm04hdPWYfmoeK5ri3wgbB6q9XAn6lixXbLtDtszcjw7K3NU= X-Received: by 2002:ac2:5f65:: with SMTP id c5mr9907874lfc.207.1582059465969; Tue, 18 Feb 2020 12:57:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 18 Feb 2020 12:57:19 -0800 Message-ID: To: Anthony Nadalin Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007b94de059edfec26" Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 20:57:50 -0000 --0000000000007b94de059edfec26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The security topics says MUST. If you want to change that, then that is a different discussion. :) In the OAuth 2.1 document, it would just not be included. Applications can continue to be OAuth 2.0 compliant. BUT ... if there are valid, new use cases. Please describe them! Perhaps it should not be dropped. On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin wrote: > I would suggest a SHOULD NOT instead of MUST, there are still sites using > this and a grace period should be provided before a MUST is pushed out as > there are valid use cases out there still. > > > > *From:* OAuth *On Behalf Of * Dick Hardt > *Sent:* Tuesday, February 18, 2020 12:37 PM > *To:* oauth@ietf.org > *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > > > > Hey List > > > > (Once again using the OAuth 2.1 name as a placeholder for the doc that > Aaron, Torsten, and I are working on) > > > > In the security topics doc > > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > > > > > The password grant MUST not be used. > > > > Some background for those interested. I added this grant into OAuth 2.0 t= o > allow applications that had been provided password to migrate. Even with > the caveats in OAuth 2.0, implementors decide they want to prompt the use= r > to enter their credentials, the anti-pattern OAuth was created to > eliminate. > > > > > > Does anyone have concerns with dropping the password grant from the OAuth > 2.1 document so that developers don't use it? > > > > /Dick > --0000000000007b94de059edfec26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The security topics says MUST. If you want to change that,= then that is a different discussion. :)

In the OAuth 2.= 1 document, it would just not be included. Applications can continue to be = OAuth 2.0 compliant.

BUT ... if there are valid, n= ew use cases. Please describe them! Perhaps it should not be dropped.
=


On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin <tonynad@microsoft.com> wrote:
=

I would suggest a SHOULD NOT instead of MUST, there = are still sites using this and a grace period should be provided before a M= UST is pushed out as there are valid use cases out there still.

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: oauth@ietf.o= rg
Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant=

=C2=A0

Hey List=C2=A0

=C2=A0

(Once again using the OAuth 2.1 name as a placeholde= r for the doc that Aaron, Torsten, and I are working on)

=C2=A0

In the security topics doc

=C2=A0

=C2=A0

The password grant MUST not be used.

=C2=A0

Some background for those interested. I added this g= rant into OAuth 2.0 to allow applications that had been provided password t= o migrate. Even with the caveats in OAuth 2.0, implementors decide they wan= t to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate.=C2=A0=

=C2=A0

=C2=A0

Does anyone have concerns with dropping the password= grant from the OAuth 2.1 document so that developers don't use it?<= /u>

=C2=A0

/Dick

--0000000000007b94de059edfec26-- From nobody Tue Feb 18 13:15:51 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4670A120145 for ; Tue, 18 Feb 2020 13:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz2FHhozYx8k for ; Tue, 18 Feb 2020 13:15:48 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FF51200C7 for ; Tue, 18 Feb 2020 13:15:48 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01ILFanc018514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Feb 2020 16:15:38 -0500 From: Justin Richer Message-Id: <13A86ACE-3D9E-4FDF-9892-7A040DE5F4C6@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_15576141-2948-46E7-8BE3-DD16BFEBA0B6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 18 Feb 2020 16:15:36 -0500 In-Reply-To: Cc: Dick Hardt , "oauth@ietf.org" To: Anthony Nadalin References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 21:15:50 -0000 --Apple-Mail=_15576141-2948-46E7-8BE3-DD16BFEBA0B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is no need for a grace period. People using OAuth 2.0 can still do = OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 =E2=80=94 Justin > On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >=20 > I would suggest a SHOULD NOT instead of MUST, there are still sites = using this and a grace period should be provided before a MUST is pushed = out as there are valid use cases out there still. > =20 > From: OAuth On Behalf Of Dick Hardt > Sent: Tuesday, February 18, 2020 12:37 PM > To: oauth@ietf.org > Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > =20 > Hey List=20 > =20 > (Once again using the OAuth 2.1 name as a placeholder for the doc that = Aaron, Torsten, and I are working on) > =20 > In the security topics doc > =20 > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 = > =20 > The password grant MUST not be used. > =20 > Some background for those interested. I added this grant into OAuth = 2.0 to allow applications that had been provided password to migrate. = Even with the caveats in OAuth 2.0, implementors decide they want to = prompt the user to enter their credentials, the anti-pattern OAuth was = created to eliminate.=20 > =20 > =20 > Does anyone have concerns with dropping the password grant from the = OAuth 2.1 document so that developers don't use it? > =20 > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_15576141-2948-46E7-8BE3-DD16BFEBA0B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There= is no need for a grace period. People using OAuth 2.0 can still do = OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. 

 =E2=80=94 = Justin

On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = <tonynad=3D40microsoft.com@dmarc.ietf.org> = wrote:

I would = suggest a SHOULD NOT instead of MUST, there are still sites using this = and a grace period should be provided before a MUST is pushed out as = there are valid use cases out there still.
 
From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Tuesday, February 18, 2020 = 12:37 PM
To: oauth@ietf.org
Subject: [EXTERNAL] [OAUTH-WG] OAuth = 2.1: dropping password grant
 
Hey List 
 
(Once again using the OAuth 2.1 name as = a placeholder for the doc that Aaron, Torsten, and I are working on)
 
In the security topics doc
 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14= #section-2.4
 
The password grant MUST not be used.
 
Some background for those interested. I = added this grant into OAuth 2.0 to allow applications that had been = provided password to migrate. Even with the caveats in OAuth 2.0, = implementors decide they want to prompt the user to enter their = credentials, the anti-pattern OAuth was created to eliminate. 
 
 
Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it?
 
/Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_15576141-2948-46E7-8BE3-DD16BFEBA0B6-- From nobody Tue Feb 18 13:28:22 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6F512081A for ; Tue, 18 Feb 2020 13:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=independentid-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 izD5vpJhTIp7 for ; Tue, 18 Feb 2020 13:28:18 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660F51200C7 for ; Tue, 18 Feb 2020 13:28:18 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id v23so8177676pgk.2 for ; Tue, 18 Feb 2020 13:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=UjB5v0lbks9GToXtLkAKFUG9j7ETBUKXQNp4xBqkZyU=; b=k7o0S9TkxNe5Rxh6CQDYy3gaxVl71s6MOxvrCt4/FgkPnLSqn41Br/BwHwAZTG+BGe gQeGDUEhyENiOynKavmx2EbQZHPfUumBKWC+s9NApGMc+ggGQw3GJQf0VlaIJAScrKjE U9yLtmqkFdTMEzLYd2VmDkOIS5JVzSt6R7/DFYXPCcP3O45mbB0TBBOI4VDxtYa8mECN DZTT5/srTif57ANXz29o+0+0jp9vh4ZSimLKG87ewGSkrX+wAWGOcKC1WHQenFuqPrLP 6tRoEklQa19If4ifluz6kuRBikZWCpvY164QIFQ94ztrAhM1AcWzN13PqQCCsIZkgSaK I7GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=UjB5v0lbks9GToXtLkAKFUG9j7ETBUKXQNp4xBqkZyU=; b=WSon+MR2wUIbxfbOtm2+qgf5Lphx8tNkd+kyHXckkJE/dKkNsUmjK47LBO++wIO+Nb L9uuwWci5ZD3pFEpkPR8MxVmXXel39D5MMjHVOEYOBkqtBZdYqsqoZOFS5M7wzYItWDg kteWv9j/9lqxbhP91XNJ4STyYLpzKYJxiiolK0RmsTTmNl/bSLSalNd7THo4rTDg+bFA k2u4hWwAivE7aTKSLefoj0VR4x6blBb38b61laUn1bwTWcVubBLpMPanH2Hsdgw+YI7o Qh6vMnq+wemDoODhHjyLRYWFISvI9irOBAZfoUb3fb2wS+DCV3hTfriqvAmSQaJxz/Kv VARQ== X-Gm-Message-State: APjAAAUMSuiQKxbg5kr7o8JV+1T5w9OCySa9lKbPGv1svfT1j6S/esfF fTtmXUR/Br5T8QGClbpk4ybdXg== X-Google-Smtp-Source: APXvYqyx78dUrln1C6XpdUFuBGcH4TEo/yQAO+3cHLqHKCp+InYqG7Q2Jwxwm2hKnASAe7V9xXHkNg== X-Received: by 2002:a63:3dc1:: with SMTP id k184mr24971964pga.103.1582061297568; Tue, 18 Feb 2020 13:28:17 -0800 (PST) Received: from [10.229.71.220] ([24.244.23.42]) by smtp.gmail.com with ESMTPSA id 13sm5207209pfj.68.2020.02.18.13.28.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Feb 2020 13:28:16 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-F4CA26FB-E803-4925-9677-FAD8C6523EB4 Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Tue, 18 Feb 2020 13:28:16 -0800 Message-Id: <666A031D-72D9-4AAF-8D43-811C2E749733@independentid.com> References: <13A86ACE-3D9E-4FDF-9892-7A040DE5F4C6@mit.edu> Cc: Anthony Nadalin , "oauth@ietf.org" In-Reply-To: <13A86ACE-3D9E-4FDF-9892-7A040DE5F4C6@mit.edu> To: Justin Richer X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 21:28:21 -0000 --Apple-Mail-F4CA26FB-E803-4925-9677-FAD8C6523EB4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I do recall password flow was only in 6749 to facilitate transition to oauth= . Maybe it is reasonable to consider ending it now. Phil > On Feb 18, 2020, at 1:15 PM, Justin Richer wrote: >=20 > =EF=BB=BFThere is no need for a grace period. People using OAuth 2.0 can s= till do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >=20 > =E2=80=94 Justin >=20 >> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin wrote: >>=20 >> I would suggest a SHOULD NOT instead of MUST, there are still sites using= this and a grace period should be provided before a MUST is pushed out as t= here are valid use cases out there still. >> =20 >> From: OAuth On Behalf Of Dick Hardt >> Sent: Tuesday, February 18, 2020 12:37 PM >> To: oauth@ietf.org >> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >> =20 >> Hey List=20 >> =20 >> (Once again using the OAuth 2.1 name as a placeholder for the doc that Aa= ron, Torsten, and I are working on) >> =20 >> In the security topics doc >> =20 >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 >> =20 >> The password grant MUST not be used. >> =20 >> Some background for those interested. I added this grant into OAuth 2.0 t= o allow applications that had been provided password to migrate. Even with t= he caveats in OAuth 2.0, implementors decide they want to prompt the user to= enter their credentials, the anti-pattern OAuth was created to eliminate.=20= >> =20 >> =20 >> Does anyone have concerns with dropping the password grant from the OAuth= 2.1 document so that developers don't use it? >> =20 >> /Dick >> _______________________________________________ >> 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-F4CA26FB-E803-4925-9677-FAD8C6523EB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I do recall password flow was only in 6749 t= o facilitate transition to oauth. Maybe it is reasonable to consider ending i= t now.

Phil

On Feb 18, 2020, at 1:15 PM, Justin Richer <jricher@mit.edu&g= t; wrote:

=EF=BB=BFThere is no need for a grace period. People using OAuth 2.0 can still= do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. 

 =E2=80=94 Justin
=

On = Feb 18, 2020, at 3:54 PM, Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.iet= f.org> wrote:

I would suggest a SHOULD NOT instead of MUST, there a= re still sites using this and a grace period should be provided before a MUS= T is pushed out as there are valid use cases out there still.
 
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 P= M
To:&= nbsp;oauth@ietf.org<= br class=3D"">Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant
 
Hey List 
 
=
(Once again using the OAuth 2.1 n= ame as a placeholder for the doc that Aaron, Torsten, and I are working on)<= o:p class=3D"">
 
= In the security topics doc
=
 
 
The password grant MUST not be used.
 
Some ba= ckground for those interested. I added this grant into OAuth 2.0 to allow ap= plications that had been provided password to migrate. Even with the caveats= in OAuth 2.0, implementors decide they want to prompt the user to enter the= ir credentials, the anti-pattern OAuth was created to eliminate. 
 
=  
Does anyone have concerns with dropping the password grant from the O= Auth 2.1 document so that developers don't use it?
 
/Dick
________________________= _______________________
OAuth mai= ling list
OAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /div>= --Apple-Mail-F4CA26FB-E803-4925-9677-FAD8C6523EB4-- From nobody Tue Feb 18 13:43:53 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEDC1200C7 for ; Tue, 18 Feb 2020 13:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2l99mQV4sIi for ; Tue, 18 Feb 2020 13:43:50 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A55712081B for ; Tue, 18 Feb 2020 13:43:50 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id f10so18676938ils.8 for ; Tue, 18 Feb 2020 13:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GVRC9pvlR1k3rKFtt+wMfaM24Kk3FasfH2mgoNeAvW0=; b=kkCWM8TO5rwX9ewLnn3o0XVajVyY/vx7Mjue+kmz2h6KHK6jBGCEs7q80CQKZv7nmA AIJvqPzbJPnSXXRcecKMATg1dU88QuTX5vXxhNNtIRFPoEUTmiDuvvXdHqbcdNuizhGK 6VA00EfEHTjP6YYwb5/jwEd2kVRa3fb7YDVNqdGz2RLZM9P5BhbOnkSYQj5RHY+v+xIA 4yjxCEhCiBaq6XfJMRfsXzMZyj/mJ0DYTmejccWCpZqd2mxSHvpZr+L57Y7UP4AkYThP uC+PafapRRXH0RHGFiUr8c//KAosjbGseTfNXuD9n/Qlvab+YW16uZ+WWluH0XZS+c/A Lxlw== 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=GVRC9pvlR1k3rKFtt+wMfaM24Kk3FasfH2mgoNeAvW0=; b=F6MAtt5iQwBtksJDWCP5e/164ugUeviRY8MIUb5yfLy3ZIG1mIZeMh1HnRnv+CUcJY 2v2dwDL0i6yx6qDLKDgq9xNyPjvyV6X0RFEi0HPxDt6A+wWq17LoZ6IW2qyW0qZMFXJB RV7WL6yS7G2TbbdrddkfjrTjKunr4b94eWG/CqlD/jvQd8bNNMgmjHpCkTzgIvMKOWA5 V8Wc04hbN84VezaVfZwbEKgj3FiPOn4nl5P7sOywQY6DSozMbCZ/7nnBZ5TVPyz0iC4I UNFRvnBellhiJhLEPWRXIRGq/jYDruQsTt1uIFcBOPdn+Ai6C78ExiPFo2G1fJyHntrf lF5g== X-Gm-Message-State: APjAAAX6RuDJIn7OgSId6k0rfD4zAjxbtdMh/jEojeqyVPYkVYy8KNeb 0w4QQhDW5zgAyWM9WW8Zt8hLjZbcO2I= X-Google-Smtp-Source: APXvYqz0R8cuTUvvklAiMTmrax9Tz1qdDvzxAwoPEEANzgfmDsG62TAC6p4CydwYO0KynqwDa6cUPw== X-Received: by 2002:a92:cc04:: with SMTP id s4mr1029804ilp.193.1582062229215; Tue, 18 Feb 2020 13:43:49 -0800 (PST) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com. [209.85.166.181]) by smtp.gmail.com with ESMTPSA id n5sm26282ila.7.2020.02.18.13.43.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Feb 2020 13:43:48 -0800 (PST) Received: by mail-il1-f181.google.com with SMTP id t17so18639212ilm.13 for ; Tue, 18 Feb 2020 13:43:48 -0800 (PST) X-Received: by 2002:a05:6e02:8e2:: with SMTP id n2mr22169324ilt.167.1582062228168; Tue, 18 Feb 2020 13:43:48 -0800 (PST) MIME-Version: 1.0 References: <13A86ACE-3D9E-4FDF-9892-7A040DE5F4C6@mit.edu> In-Reply-To: <13A86ACE-3D9E-4FDF-9892-7A040DE5F4C6@mit.edu> From: Aaron Parecki Date: Tue, 18 Feb 2020 13:43:37 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: Anthony Nadalin , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001f67e5059ee09126" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 21:43:53 -0000 --0000000000001f67e5059ee09126 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed. Plus, the Security BCP is already effectively acting as a grace period since it currently says the password grant MUST NOT be used, so in the OAuth 2.0 world that's already a pretty strong signal. Aaron On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: > There is no need for a grace period. People using OAuth 2.0 can still do > OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. > > =E2=80=94 Justin > > On Feb 18, 2020, at 3:54 PM, Anthony Nadalin < > tonynad=3D40microsoft.com@dmarc.ietf.org> wrote: > > I would suggest a SHOULD NOT instead of MUST, there are still sites using > this and a grace period should be provided before a MUST is pushed out as > there are valid use cases out there still. > > *From:* OAuth *On Behalf Of *Dick Hardt > *Sent:* Tuesday, February 18, 2020 12:37 PM > *To:* oauth@ietf.org > *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > > Hey List > > (Once again using the OAuth 2.1 name as a placeholder for the doc that > Aaron, Torsten, and I are working on) > > In the security topics doc > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > > > The password grant MUST not be used. > > Some background for those interested. I added this grant into OAuth 2.0 t= o > allow applications that had been provided password to migrate. Even with > the caveats in OAuth 2.0, implementors decide they want to prompt the use= r > to enter their credentials, the anti-pattern OAuth was created to > eliminate. > > > Does anyone have concerns with dropping the password grant from the OAuth > 2.1 document so that developers don't use it? > > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 ---- Aaron Parecki aaronparecki.com @aaronpk --0000000000001f67e5059ee09126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed. Plus, the Security BCP is already effectivel= y acting as a grace period since it currently says the password grant MUST = NOT be used, so in the OAuth 2.0 world that's already a pretty strong s= ignal.

Aaron
=



On Tue, Feb 18, 2020= at 4:16 PM Justin Richer <jricher@mi= t.edu> wrote:
There is no need for a g= race period. People using OAuth 2.0 can still do OAuth 2.0. People using OA= uth 2.1 will do OAuth 2.1.=C2=A0

=C2=A0=E2=80=94 Justin
<= div>
On Feb 18, 2020, at 3:54 PM, Anthony= Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:
I would suggest a SHOULD NOT inst= ead of MUST, there are still sites using this and a grace period should be = provided before a MUST is pushed out as there are valid use cases out there= still.
=C2=A0
= From:=C2=A0OAuth <oauth-bounces@ietf.org>=C2=A0= On Behalf Of=C2=A0Dick Hardt
Sent:=C2= =A0Tuesday, February 18, 2020 12:37 PM
To:=C2=A0oauth@ietf.orgSubject:=C2=A0[EXTERNAL] [OAUTH-WG] OAuth 2.1: droppi= ng password grant
=C2=A0
Hey List=C2=A0
=C2=A0
(Once again using th= e OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I ar= e working on)
=C2=A0
<= /div>
In the security topics doc
=C2=A0
=C2=A0
The passwo= rd grant MUST not be used.
= =C2=A0
Some background for those intereste= d. I added this grant into OAuth 2.0 to allow applications that had been pr= ovided password to migrate. Even with the caveats in OAuth 2.0, implementor= s decide they want to prompt the user to enter their credentials, the anti-= pattern OAuth was created to eliminate.=C2=A0
=C2=A0
=C2=A0<= /u>
Does anyone have concerns with dropping the p= assword grant from the OAuth 2.1 document so that developers don't use = it?
=C2=A0
/Dick
_______________= ________________________________
OAuth mailing list
OAuth@ietf.org= h= ttps://www.ietf.org/mailman/listinfo/oauth

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

--0000000000001f67e5059ee09126-- From nobody Tue Feb 18 13:57:48 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20439120823 for ; Tue, 18 Feb 2020 13:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfnL2JXZQq8u for ; Tue, 18 Feb 2020 13:57:45 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28A8120819 for ; Tue, 18 Feb 2020 13:57:44 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id b7so21106493qkl.7 for ; Tue, 18 Feb 2020 13:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hPe1Pcm1fy/czOBX5glj3GEoSFuLenxiGALx5jzehsA=; b=bJPVgFGJRUXemrM0EQKpIF+/WgxnfCXd7zRd73JTSvUjU4+W8z/4Dosg81hfIN5r+E uqIYeLS3Xf7YYZ/SzG0JBWcdRlEvYB/X0Gf2RWBWoeawMaUQQJOvFTTGvs0y2qILlaWe +MDU6+g0hB8IWQSlsX3jZ4NeiwRGsMcYyzWcKzX6WfeYfzmwYYBU0g+SfNRhI+F/t5hR n/i/u5P8E5z2pKD2bCabA2WoAIB2RHja3vKy5DDZDNfIi5prCDb1HP60gn2bja2SP9nA cI2hrXA5B1LvMcXjHaHPFsM/xUeddq/W9frmVbHURUDdJ32yt2PYuRkWIfnndnVquzK6 JvuQ== 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=hPe1Pcm1fy/czOBX5glj3GEoSFuLenxiGALx5jzehsA=; b=hvb3bVBPZ1KAMl85Ss9iwxExNP1+IKl8wpMXMAlxR/Iwk9X2FuKl17AMZNuEELhCbB GTD28lfurqWTrGfsveDs8YJ5nARIkIGD0XggWdJeZzanw8PkdYtp15De4axxnIW6GjWV e5u9vSzB9eVhnM2lhqDktLrnuOVxGrtbAZLzEaG7ypNaVeeZ32gLU1H9bzWmFiG2nG2f lgfvXKnfq+He1hY4l8cgxKGKv8MElst7GljjcumcqVR2jDZA4ZS/7kFEAcBB+CSTNizU mz7eH1qp/CYpBL1XVrQBwx0xVxyIIidWfanSaFDFZ42XPMW7DJB6aAzimtTqptsFWUCt VjeA== X-Gm-Message-State: APjAAAWF4a9v/BZ5rwNImoyIeYJwvJ5OXKjCJwYJrDY0LGlR3OhG/mQZ l9URuw2c6Edu/sdckqKHxNVhVDCp1O04Ec9n+bAIsA== X-Google-Smtp-Source: APXvYqzEYocaFn8lcl3XmeiJzXeheSbkv1NqrX5+xEorjyD8nYz4+dcgcOOav71aHB6+j0R84joUYjCA+9QQkLWnPOY= X-Received: by 2002:a05:620a:569:: with SMTP id p9mr21045989qkp.104.1582063063878; Tue, 18 Feb 2020 13:57:43 -0800 (PST) MIME-Version: 1.0 References: <13A86ACE-3D9E-4FDF-9892-7A040DE5F4C6@mit.edu> In-Reply-To: From: Hans Zandbelt Date: Tue, 18 Feb 2020 22:57:33 +0100 Message-ID: To: Aaron Parecki Cc: Justin Richer , Anthony Nadalin , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ef6149059ee0c287" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 21:57:47 -0000 --000000000000ef6149059ee0c287 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would also seriously look at the original motivation behind ROPC: I know it has been deployed and is used in quite a lot of places but I have never actually come across a use case where it is used for migration purposes and the migration is actually executed (I know that is statistically not a very strong argument but I challenge others to come up with one...) In reality it turned out just to be a one off that people used as an easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. Hans. On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote: > Agreed. Plus, the Security BCP is already effectively acting as a grace > period since it currently says the password grant MUST NOT be used, so in > the OAuth 2.0 world that's already a pretty strong signal. > > Aaron > > > > On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: > >> There is no need for a grace period. People using OAuth 2.0 can still do >> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. >> >> =E2=80=94 Justin >> >> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin < >> tonynad=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I would suggest a SHOULD NOT instead of MUST, there are still sites usin= g >> this and a grace period should be provided before a MUST is pushed out a= s >> there are valid use cases out there still. >> >> *From:* OAuth *On Behalf Of *Dick Hardt >> *Sent:* Tuesday, February 18, 2020 12:37 PM >> *To:* oauth@ietf.org >> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >> >> Hey List >> >> (Once again using the OAuth 2.1 name as a placeholder for the doc that >> Aaron, Torsten, and I are working on) >> >> In the security topics doc >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-= 2.4 >> >> >> The password grant MUST not be used. >> >> Some background for those interested. I added this grant into OAuth 2.0 >> to allow applications that had been provided password to migrate. Even w= ith >> the caveats in OAuth 2.0, implementors decide they want to prompt the us= er >> to enter their credentials, the anti-pattern OAuth was created to >> eliminate. >> >> >> Does anyone have concerns with dropping the password grant from the OAut= h >> 2.1 document so that developers don't use it? >> >> /Dick >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000ef6149059ee0c287 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would also seriously look at the original motivation beh= ind ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for migra= tion=C2=A0purposes and the migration is actually executed (I know that is s= tatistically not a very strong argument but I challenge others to come up w= ith one...)
In reality it turned out just to be a one off that people u= sed as an easy way out to stick to an anti-pattern and still claim to do OA= uth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.

Hans.

On Tue, Feb 18, 2020 at 10:44 PM Aaron P= arecki <aaron@parecki.com> w= rote:
Agreed. Plus, the Security BCP is already effectively acting a= s a grace period since it currently says the password grant MUST NOT be use= d, so in the OAuth 2.0 world that's already a pretty strong signal.

Aaron



On Tue, Feb 18, 2020 at 4:16= PM Justin Richer <= jricher@mit.edu> wrote:
There is no need f= or a grace period. People using OAuth 2.0 can still do OAuth 2.0. People us= ing OAuth 2.1 will do OAuth 2.1.=C2=A0

=C2=A0=E2=80=94 Justin

On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <t= onynad=3D40microsoft.com@dmarc.ietf.org> wrote:

I would suggest a SHOULD NOT instead of MUST, ther= e are still sites using this and a grace period should be provided before a= MUST is pushed out as there are valid use cases out there still.=
=C2=A0
From:= =C2=A0OAuth <oauth-bounces@ietf.org>=C2=A0On Behalf Of=C2=A0Dick Hardt
Sent:=C2=A0Tuesday, F= ebruary 18, 2020 12:37 PM
To:=C2=A0oauth@ietf.org
Subject:=C2=A0[EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant=
=C2=A0
Hey List=C2=A0
=C2= =A0
(Once again using the OAuth 2.1 name as a p= laceholder for the doc that Aaron, Torsten, and I are working on)=
=C2=A0
In = the security topics doc
=C2= =A0
<= /u>=C2=A0
The password grant MUST not be u= sed.
=C2=A0
Some background for those interested. I added this grant i= nto OAuth 2.0 to allow applications that had been provided password to migr= ate. Even with the caveats in OAuth 2.0, implementors decide they want to p= rompt the user to enter their credentials, the anti-pattern OAuth was creat= ed to eliminate.=C2=A0
=C2= =A0
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">Does anyone have concerns with dropping the password grant from th= e OAuth 2.1 document so that developers don't use it?
=C2=A0
/Dick=
______________________________________________= _
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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


--
--000000000000ef6149059ee0c287-- From nobody Tue Feb 18 14:03:56 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DAF120099; Tue, 18 Feb 2020 14:03:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158206343467.14002.3368462920447223459@ietfa.amsl.com> Date: Tue, 18 Feb 2020 14:03:54 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 22:03:55 -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 Pushed Authorization Requests Authors : Torsten Lodderstedt Brian Campbell Nat Sakimura Dave Tonge Filip Skokan Filename : draft-ietf-oauth-par-01.txt Pages : 14 Date : 2020-02-18 Abstract: This document defines the pushed authorization request endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-par-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-01 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 Feb 18 16:49:48 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14A312084F for ; Tue, 18 Feb 2020 16:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9tbm8lVtmSIM for ; Tue, 18 Feb 2020 16:49:40 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC7112083A for ; Tue, 18 Feb 2020 16:49:39 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id b15so15968282lfc.4 for ; Tue, 18 Feb 2020 16:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YOcTh8/uJfelQj7flXZVjwmA4JzeRrax11+PMbnglCo=; b=Hj1MybPSj0zMNSPkXZgi07TmcD88HTOj8Pzs87OByt+490YQK2ponPIJp9Pvfd6/LA F/Z0gL8u+TtSGRkKE5/Eph5plHI8SkH+LNx4Jwp4RvGKeyp6sWubhCbc/S3yympZWbw3 8GTofvLjGJnqaKy4pHmiqcduhocBByiew6gPRZOtJ3ozcYzysn2c1QQVFt4AsxZZCNdc Hg5ONVdeeRDnJjGddAZiO2jyEkXCJDQdmNOvsuaBNxwo1jAKqWJOybOOj/nm4fUzm5GA 1vqXxhzB4Juzg6B9dhksIoVeM+hyxrzjcnHPRUcuqTZYKpv8tk5E1BUcp0SfptKc37nr i0Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YOcTh8/uJfelQj7flXZVjwmA4JzeRrax11+PMbnglCo=; b=Net9A+Jc7pIWP2fpkKotM+SzFyuYzz1Lxyhe3V6DdXroPvEap2W0Dpj5LrErgieeB1 R0D2fA1HQeh4meO5UQ40LiT1rZNB4YN5/F7bTX1fgR+M95UxknOzSkzrxfZfde1Bt+xd AEzChiEwnK1qLgp+lI52hWxYkUPgjqhCLYjfPQ65qJ4Uh4ICEI5JjCTqY/w51+AnLI4D NnymhXlPd91edQd/D1QOUhPqJW8Rh+7YxAfqXIO3roQqDRrbT5wS4qMdrho5uIJRsdOj uT5p0DzqzNhvf1z6e1rXcJ4eAdbHn8KR00tNZ2mj5kEHj5KjnKnDLjgWohCSjR2GCaVW h9zQ== X-Gm-Message-State: APjAAAW3riffYoLYcIwJIMgjzzQoFGLaAm9/KpzZympyEQ/JbdYb6uAB o8WJN3EY7WdNkcmI4000/b1WuS7SMSlq7MItGCbxMsdk X-Google-Smtp-Source: APXvYqyYtH9t0agDRsmPTMW6vZYhm4IpEPwlvJIeLPjgG6wiGYukS8dOJqvkb4dabJ9mZVSC3evi0QjbgM8Uq3y/ABI= X-Received: by 2002:ac2:52a3:: with SMTP id r3mr11828873lfm.189.1582073377445; Tue, 18 Feb 2020 16:49:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bruno Brito Date: Tue, 18 Feb 2020 21:49:27 -0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000abdc30059ee329c5" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 00:49:45 -0000 --000000000000abdc30059ee329c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Guys, I really understand the security and motivations behind ROPC and I'm not against the decision it is deprecated. Actually I see many devs and teams using ROPC to deliver a better UI experience in Mobile apps and easy integration. They try to follow specs of RFC 8252 and AppAuth isn't easy to use. Many bugs shows up in the way, and it's not a good user experience at all. At the end of the day, they became to use ROPC as an alternative. Tremendous easy to implement compared against AppAuth. My question is, we are really prepared to go away from ROPC? In one hand the best practice says: Use AppAuth for Native apps. But in this case the time and efforts the teams need to implement it in a good manner is substantially high if we compare against a SPA Frontend using javascript oidc. So my point is, isn't better for us before remove oidc, try something to improve a better and easy integration with native apps? /Bruno On Tue, Feb 18, 2020 at 6:57 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: OAuth 2.1: dropping password grant (Aaron Parecki) > 2. Re: OAuth 2.1: dropping password grant (Hans Zandbelt) > > > > ---------- Forwarded message ---------- > From: Aaron Parecki > To: Justin Richer > Cc: Anthony Nadalin , " > oauth@ietf.org" > Bcc: > Date: Tue, 18 Feb 2020 13:43:37 -0800 > Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant > Agreed. Plus, the Security BCP is already effectively acting as a grace > period since it currently says the password grant MUST NOT be used, so in > the OAuth 2.0 world that's already a pretty strong signal. > > Aaron > > > > On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: > >> There is no need for a grace period. People using OAuth 2.0 can still do >> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. >> >> =E2=80=94 Justin >> >> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin < >> tonynad=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I would suggest a SHOULD NOT instead of MUST, there are still sites usin= g >> this and a grace period should be provided before a MUST is pushed out a= s >> there are valid use cases out there still. >> >> *From:* OAuth *On Behalf Of *Dick Hardt >> *Sent:* Tuesday, February 18, 2020 12:37 PM >> *To:* oauth@ietf.org >> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >> >> Hey List >> >> (Once again using the OAuth 2.1 name as a placeholder for the doc that >> Aaron, Torsten, and I are working on) >> >> In the security topics doc >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-= 2.4 >> >> >> The password grant MUST not be used. >> >> Some background for those interested. I added this grant into OAuth 2.0 >> to allow applications that had been provided password to migrate. Even w= ith >> the caveats in OAuth 2.0, implementors decide they want to prompt the us= er >> to enter their credentials, the anti-pattern OAuth was created to >> eliminate. >> >> >> Does anyone have concerns with dropping the password grant from the OAut= h >> 2.1 document so that developers don't use it? >> >> /Dick >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > > ---------- Forwarded message ---------- > From: Hans Zandbelt > To: Aaron Parecki > Cc: Justin Richer , Anthony Nadalin 40microsoft.com@dmarc.ietf.org>, "oauth@ietf.org" > Bcc: > Date: Tue, 18 Feb 2020 22:57:33 +0100 > Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant > I would also seriously look at the original motivation behind ROPC: I kno= w > it has been deployed and is used in quite a lot of places but I have neve= r > actually come across a use case where it is used for migration purposes a= nd > the migration is actually executed (I know that is statistically not a ve= ry > strong argument but I challenge others to come up with one...) > In reality it turned out just to be a one off that people used as an easy > way out to stick to an anti-pattern and still claim to do OAuth 2.0. It i= s > plain wrong, it is not OAuth and we need to get rid of it. > > Hans. > > On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote: > >> Agreed. Plus, the Security BCP is already effectively acting as a grace >> period since it currently says the password grant MUST NOT be used, so i= n >> the OAuth 2.0 world that's already a pretty strong signal. >> >> Aaron >> >> >> >> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: >> >>> There is no need for a grace period. People using OAuth 2.0 can still d= o >>> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. >>> >>> =E2=80=94 Justin >>> >>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin < >>> tonynad=3D40microsoft.com@dmarc.ietf.org> wrote: >>> >>> I would suggest a SHOULD NOT instead of MUST, there are still sites >>> using this and a grace period should be provided before a MUST is pushe= d >>> out as there are valid use cases out there still. >>> >>> *From:* OAuth *On Behalf Of *Dick Hardt >>> *Sent:* Tuesday, February 18, 2020 12:37 PM >>> *To:* oauth@ietf.org >>> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >>> >>> Hey List >>> >>> (Once again using the OAuth 2.1 name as a placeholder for the doc that >>> Aaron, Torsten, and I are working on) >>> >>> In the security topics doc >>> >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section= -2.4 >>> >>> >>> The password grant MUST not be used. >>> >>> Some background for those interested. I added this grant into OAuth 2.0 >>> to allow applications that had been provided password to migrate. Even = with >>> the caveats in OAuth 2.0, implementors decide they want to prompt the u= ser >>> to enter their credentials, the anti-pattern OAuth was created to >>> eliminate. >>> >>> >>> Does anyone have concerns with dropping the password grant from the >>> OAuth 2.1 document so that developers don't use it? >>> >>> /Dick >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000abdc30059ee329c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Guys,

I really understand the securi= ty and motivations behind=C2=A0ROPC and I'm not against the decision it= is deprecated. Actually=C2=A0I see many devs and teams using ROPC to deliv= er a better UI experience in Mobile apps and easy integration.=C2=A0
<= div>They try to follow specs of RFC 8252 and AppAuth isn't easy to use.= Many bugs shows up in the way, and it's not a good user experience at = all. At the end of the day, they became to use ROPC as an alternative. Trem= endous easy to implement compared against AppAuth.

My question is, we are really prepared to go away from ROPC? In one hand t= he best practice says: Use AppAuth for Native apps. But in this case the ti= me and efforts the teams need to implement it in a good manner is substanti= ally high if we compare against a SPA Frontend using javascript oidc. So my= point is, isn't better for us before remove oidc, try something to imp= rove a better and easy integration with native apps?

/Bruno
On Tue, Feb 18, 2020 at 6:57 PM <oauth-request@ietf.org> wrote:
Send OAuth mailing list submission= s to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

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

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

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

=C2=A0 =C2=A01. Re: OAuth 2.1: dropping password grant (Aaron Parecki)
=C2=A0 =C2=A02. Re: OAuth 2.1: dropping password grant (Hans Zandbelt)



---------- Forwarded message ----------
From:=C2=A0Aaron Par= ecki <aaron@parec= ki.com>
To:=C2=A0Justin Richer <jricher@mit.edu>
Cc:=C2=A0Anthony Nadalin = <tonynad=3D40microsoft.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Bcc:=C2=A0Date:=C2=A0Tue, 18 Feb 2020 13:43:37 -0800
Subject:=C2=A0Re: [OAUTH-WG]= OAuth 2.1: dropping password grant
Agreed. Plus,= the Security BCP is already effectively acting as a grace period since it = currently says the password grant MUST NOT be used, so in the OAuth 2.0 wor= ld that's already a pretty strong signal.
=
Aaron



On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrot= e:
There is no need for a grace period. People us= ing OAuth 2.0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth = 2.1.=C2=A0

=C2=A0=E2=80=94 Justin

On Feb= 18, 2020, at 3:54 PM, Anthony Nadalin <tonynad=3D40microsoft.com@dma= rc.ietf.org> wrote:

I w= ould suggest a SHOULD NOT instead of MUST, there are still sites using this= and a grace period should be provided before a MUST is pushed out as there= are valid use cases out there still.
= =C2=A0
From:=C2=A0OAuth <oauth-bounces@ietf.o= rg>=C2=A0On Behalf Of=C2=A0Dick Har= dt
Sent:=C2=A0Tuesday, February 18, 2020 12:37 PMTo:=C2=A0oauth@ietf.org
Subject:=C2=A0[EXTERNAL] [= OAUTH-WG] OAuth 2.1: dropping password grant
= =C2=A0
Hey List=C2=A0
=C2=A0
(Once again using the OAuth 2.1 name as a placeholder for the doc that A= aron, Torsten, and I are working on)
<= /u>=C2=A0
In the security topics doc
=C2=A0
=C2=A0
The password grant MUST not be used.
=
=C2=A0
Some backgrou= nd for those interested. I added this grant into OAuth 2.0 to allow applica= tions that had been provided password to migrate. Even with the caveats in = OAuth 2.0, implementors decide they want to prompt the user to enter their = credentials, the anti-pattern OAuth was created to eliminate.=C2=A0<= u>
=C2=A0
=C2=A0
Does anyone have concer= ns with dropping the password grant from the OAuth 2.1 document so that dev= elopers don't use it?
= =C2=A0
/Dick
_= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth

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




---------- Forwarded message ----------
From:=C2=A0Hans Zand= belt <ha= ns.zandbelt@zmartzone.eu>
To:=C2=A0Aaron Parecki <aaron@parecki.com>
Cc:= =C2=A0Justin Richer <jricher@mit.edu>, Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.iet= f.org>, "oa= uth@ietf.org" <oauth@ietf.org>
Bcc:=C2=A0
Date:=C2=A0Tue, 18 Feb 2020 22:= 57:33 +0100
Subject:=C2=A0Re: [OAUTH-WG] OAuth 2.1: dropping password gr= ant
I would also seriously look at the original motivat= ion behind ROPC: I know it has been deployed and is used in quite a lot of = places but I have never actually come across a use case where it is used fo= r migration=C2=A0purposes and the migration is actually executed (I know th= at is statistically not a very strong argument but I challenge others to co= me up with one...)
In reality it turned out just to be a one off that p= eople used as an easy way out to stick to an anti-pattern and still claim t= o do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid o= f it.

Hans.

On Tue, Feb 18, 2020 at 10:44 PM = Aaron Parecki <aa= ron@parecki.com> wrote:
Agreed. Plus, the Security BCP is alr= eady effectively acting as a grace period since it currently says the passw= ord grant MUST NOT be used, so in the OAuth 2.0 world that's already a = pretty strong signal.

Aaron



On Tu= e, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrote:
There is no need for a grace per= iod. People using OAuth 2.0 can still do OAuth 2.0. People using OAuth 2.1 = will do OAuth 2.1.=C2=A0

=C2=A0=E2=80=94 Just= in

On Feb 18, 2020, at 3:54 PM, = Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org> wro= te:

I would suggest a SHOULD N= OT instead of MUST, there are still sites using this and a grace period sho= uld be provided before a MUST is pushed out as there are valid use cases ou= t there still.
=C2=A0
From:=C2=A0OAuth <oauth-bounces@ietf.org>=C2=A0On Behalf Of=C2=A0Dick Hardt
Sent:= =C2=A0Tuesday, February 18, 2020 12:37 PM
To:=C2=A0<= /span>oauth@ietf.org
Subject:=C2=A0[EXTERNAL] [OAUTH-WG] OAuth 2.1: dro= pping password grant
=C2=A0
Hey List=C2=A0
=C2=A0
(Once again using the = OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are = working on)
=C2=A0
In the security topics doc
=
=C2=A0
=C2=A0
The password= grant MUST not be used.
=C2= =A0
Some background for those interested. = I added this grant into OAuth 2.0 to allow applications that had been provi= ded password to migrate. Even with the caveats in OAuth 2.0, implementors d= ecide they want to prompt the user to enter their credentials, the anti-pat= tern OAuth was created to eliminate.=C2=A0
=C2=A0
=C2=A0=
Does anyone have concerns with dropping the pass= word grant from the OAuth 2.1 document so that developers don't use it?=
=C2=A0
/Dick
<= span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v= ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star= t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;t= ext-decoration:none;float:none;display:inline">____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>

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

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


--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000abdc30059ee329c5-- From nobody Tue Feb 18 22:49:11 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41D01208A3 for ; Tue, 18 Feb 2020 22:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 gTCXDv_btPKh for ; Tue, 18 Feb 2020 22:49:07 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7321200D5 for ; Tue, 18 Feb 2020 22:49:07 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id a2so22022262qko.12 for ; Tue, 18 Feb 2020 22:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=KZQbjZntqDTcgDDWuyE8kHeXolkRST7bFBGp60T8AaM=; b=MsOTdH2CsgwE5T6HVCFdgumDxnlQLJdK5fvGB9G2BHdq+eq6EUwu0y4SoLMPwaQVPh Vm+5N+Hf5S1WR6rNLaNnfX+h4oSuEHHK9ucv3sOQquONVgQ24+hMV/Ok1fg2oY3t+877 ubND+d0Q9G8yE7PkkySuqri4asS2o1hGEReO3UDpuI1t4QNfQIDmmBKsccrjVd+9vhPK o9nU76Ee3/M/ALLfS0DF3VQihJjyWFqGlFfo5X24ieiR0TN6Q5u4kQoySJLPJo+fWvb0 HTluelawjbIW6X/r3onYxJddVVgQRjFNuoJ8jWjrdTCfS1c5bhwWMtsxbn8d5jCvo2Ac M5jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=KZQbjZntqDTcgDDWuyE8kHeXolkRST7bFBGp60T8AaM=; b=jcgSJm7pXrQpADFj+9qWX9EkuwaE6h056dgZl0FmiGk39mkd0HMy3gsb7sqMP8R1o6 Ux2XZWLPwK0i3dGuwApPbgpk6znP36+ymLYQJL4NEt2ZuJ8cvZO4bRaHgRbOWCcsgDCo c0aalHrjbUxNMggzbj0/rUjwgGOq+l83nzdeZiQlURZzL0iTeppLBy6p1vpNhZ4V2Z0g YoHK/xcbcCivsCd/ABm0M1duBoOuFguTjXJpqkjw6a2htYMGybZmjPdsPxp4WV2tj7BZ Imj8ZAwj3dmVBFcqy+SJ8CuxZuQkZR0t4k7hOg3Ui3/gIsWwlATj1kXc3KhBr2ZQ4GXE rMgA== X-Gm-Message-State: APjAAAUGfpiYzEke/wub1UHBGFORgHrSKRJMPy/Jm5Cs11zOMI4q9Tuh FX5uvM/3Gq7K6tU16XlLN+0wOXSO67zr5akmb45w X-Google-Smtp-Source: APXvYqxZA1PFVe9FTvUTvECAtBLuhAqQnIACZ+Jon2SURoKmyIXoyDPGM+W7co4pKzeoawR9kiXSc8tnGKFX+C4x/gA= X-Received: by 2002:ae9:f009:: with SMTP id l9mr22387112qkg.259.1582094946525; Tue, 18 Feb 2020 22:49:06 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 18 Feb 2020 22:49:05 -0800 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 18 Feb 2020 22:49:05 -0800 Message-ID: To: Dick Hardt , oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a02ec059ee82f22" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 06:49:10 -0000 --0000000000004a02ec059ee82f22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No - please get rid of it. =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 18. February 2020 at 21:32:31, Dick Hardt (dick.hardt@gmail.com) wrote: Hey List (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on) Given the points Aaron brought up in https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it? /Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0000000000004a02ec059ee82f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
No -= please get rid of it.

=E2=80=94= =E2=80=94=E2=80=94
Dominick Baier

On 18. February 2020 at 21:32:31, Dick Hardt (dick.hardt@gmail.com) wrote:

Hey List=C2=A0

(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)

Given the points Aaron brought up in



Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it?

/Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--0000000000004a02ec059ee82f22-- From nobody Tue Feb 18 23:25:27 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5563120024 for ; Tue, 18 Feb 2020 23:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tirhAhFGXag9 for ; Tue, 18 Feb 2020 23:25:24 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B678812001A for ; Tue, 18 Feb 2020 23:25:23 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id t14so5536862wmi.5 for ; Tue, 18 Feb 2020 23:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:date:subject:message-id :cc:to; bh=qkpl7rv+Wp8rYAMDm1oITB07MZh9CGhkEntx8dLGJi8=; b=fAZ1R8GGR9WudUiDta1kKgIWQPUOutVs6xSmqub1JZT59pBp7SfoJ2LQQQ7TjvouvT jK2QxFLQurRHx0S23oDhHvtiCNAl1agyXWTG/3YxpuHxFYFxv5eDk0p+yIbQ5anGF2nx sTnQsxPO+jbu0ILVLa7xC0m4B1IAQD/KF7/xtz/DkDAA+k4iOgzPuDhNLgSYRNHvho0t BJ14FvJq40huUSlfjmbomutWiO2cKZOx0qFPfGcC3BuEfYcI1a2l+0c8ijM2psrh5ceQ zsrhl1oy0a6j/fMwgG1+CQ8PbNXL4H8uLre3CHbSjyrKFfvM+7idtobNqZiiDZNz8HkG nQNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:cc:to; bh=qkpl7rv+Wp8rYAMDm1oITB07MZh9CGhkEntx8dLGJi8=; b=WZJdfv6yq782v90navKxaykCO1QdhiO2Zf0R3jeapiAZodLlVSjzXrnFurrn5cFSeY WGj7u0EdiLugq37S7JOp0wdALCgjEwnVzp3tlptRhm2f1BkKgHkW7AaGlRMUQDgcob8E ipSTjPqln6M+1mnWEwG+noOyzNn3qXPrZXz0bDCGpUmRpBktaOrVkmIS/YHsKsKqlw4w 0B1Xu+WhtuEV6Rm0Io8r5bvleEnUdnfl+LK5+Yfr2mi9vxhF/OQUsIi650lJxizqj8f0 NTtiM4ks+ASkfUhhHV40fZP/3gkvQowZrT6Zxn6x6I/BpMA+HGe3VooS6Etbww40GSh4 rc+w== X-Gm-Message-State: APjAAAXJRvMypIAg5uyXWjz/4NEwcLXLFx+ZpoNnDlCbvXsojwSeioei RWmq4Xc+68o1N+dIkNuIklfPS3ctUZ9vnqek X-Google-Smtp-Source: APXvYqwfVrfxgf7rQSgXo6ztRhfDriAlDWow3Tr/u+SX9T1T+vFsePsRu8Da4/lHo65sMOqqcBZ2Hw== X-Received: by 2002:a7b:c847:: with SMTP id c7mr7818609wml.3.1582097122041; Tue, 18 Feb 2020 23:25:22 -0800 (PST) Received: from [192.168.71.107] (p5B0D992E.dip0.t-ipconnect.de. [91.13.153.46]) by smtp.gmail.com with ESMTPSA id x21sm1687228wmi.30.2020.02.18.23.25.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Feb 2020 23:25:21 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-CD6DEDE7-AAF6-4207-8610-02B511BD9941; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 19 Feb 2020 08:25:19 +0100 Message-Id: <3FB0EFA8-318A-4CB0-957B-CDCCE9C267B0@lodderstedt.net> Cc: oauth@ietf.org To: Bruno Brito X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 07:25:26 -0000 --Apple-Mail-CD6DEDE7-AAF6-4207-8610-02B511BD9941 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Bruno, thanks for your insights. The recommendation is not only based on security considerations but just uti= lity. As soon as one wants to integrate federated login or multi factor auth= entication, ROPG reaches its limits. Moreover, how do those teams implement user registration and user account re= covery? In my experience, implementing this in a native experience will sign= ificantly increase cost of the implementation. Two reasons to go with the code flow. best regards, Torsten. > Am 19.02.2020 um 01:49 schrieb Bruno Brito : >=20 --Apple-Mail-CD6DEDE7-AAF6-4207-8610-02B511BD9941 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMjE5MDcyNTE5WjAv BgkqhkiG9w0BCQQxIgQgyFBR18Qch4awh8uD0sYfZe29tCDsBkcf2kw2kUR4Ar8wgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQBFfD6k PL1LYxY9iLSBMUtGI84ygmb9A8AB/Lh1Vep2CYxFBy9DLf9MJmH61CWm2egaYYiFVmr1lp0mKonL ZQ3dz1f1WyegUI+da8T12xy8w2797xbGjhtPmxV2K3w95eL4wPz81tklOzsltI7Pz5IrYcqI47TZ iGDV4BmHHzYRF1OWJ+yqeyGBVQEob6qKglKefzwbfCXgxaxAhrTmXs265mG8gHaFTTy5aSH/CGg0 4o6WDNCLNGI/uWvw65+RGR7NVsV1S9xJprKLBhEfwsSjHZNvYZIA+jTfSm/fXT2cr3+xHD01vHiA w6F94ZBDdUUHPhib62m4E7ZwFnek713iAAAAAAAA --Apple-Mail-CD6DEDE7-AAF6-4207-8610-02B511BD9941-- From nobody Wed Feb 19 11:35:35 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41871120018 for ; Wed, 19 Feb 2020 11:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 P_rH6TTpZodu for ; Wed, 19 Feb 2020 11:35:32 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851D5120112 for ; Wed, 19 Feb 2020 11:35:31 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id q8so1589438ljj.11 for ; Wed, 19 Feb 2020 11:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YFVtBkd9jHrn8SAxDypp3/Fk6kifAu8opamvBiE3JvE=; b=FGWBkbFcHiaGS6yk+2UI7ZLoXy+VXjIqf06FCsLIGxPZIruP/JmZmLq2M8Y2UlFE12 bnQrSIigijNMANeCzJREqz64Qq/Aqn+jgjIdlur01bZQYMOiAs/noq55qCoFKWQ64dUz 2fu9YR9TeQsWQ52dXzZiqwxNXsEPHO/NIYv8mAE5NqiAiCuQA1/zCIj18eME4UT2yCvC JMtDakb2pSEvpMc01tcZT5i9ZYNvOQMGERjV1gIJR2OlsgoQwx4deU/o4uUOmQB0kLdD DfC/3lSRpQvtIw0MpS9D7I6yvrQ5J9dYMpNgmYIgvZGUmriYoxpOekoRi5XbtPoEpUUq u6wA== 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=YFVtBkd9jHrn8SAxDypp3/Fk6kifAu8opamvBiE3JvE=; b=YbueIGbpq71QP3voTveJfu1Xi5a0bExawRFgpGDD7TiG64zldsV3sHWF+zzC7X0FAH lhjW8zCQEQqN4P6tjXLZ7sIyZrkEkB/3xUDd0JqZkTKGgdsWLEbXaSeERgV3dwjMAJv+ 4+tUzp1cVi2+27YRQ5C6+cHxIHU9mHOUsgDPmCz3mAM6w4FPc0mxyrj+/eA30utS4fLG O3EeWB4EEhW831vtLBmP/YoVYbJ1RTkRdJxnd4nht5FkwgE77QtZTJU+mtzpJirMnYvi lsyMmLmxWPcUTpEERGQXu4QU8zldvGmf3/NnMr6uyisi4/tdcK7ZJZS2I9/45wSJmtrf aC3Q== X-Gm-Message-State: APjAAAUQ/Buo7EpHmYyMQQWX7rnodDRDhWVZugwF1paE6777O6loqNEg 88b445mSi8OVqM7BDRpr5bNJcAf/q4W95TLKd0c= X-Google-Smtp-Source: APXvYqxIr/7wicuY0zpDR3+1HCrp3065W9D/9IaGLHeRKsnt09ZdZG8yc5fiPeFHplMvjMnIeBaiMjlMaQ4I9nH5/uE= X-Received: by 2002:a2e:865a:: with SMTP id i26mr17055136ljj.236.1582140929546; Wed, 19 Feb 2020 11:35:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 19 Feb 2020 11:35:03 -0800 Message-ID: To: Anthony Nadalin Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000172057059ef2e40f" Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 19:35:34 -0000 --000000000000172057059ef2e40f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tony: are you ok with dropping password grant? You reference valid use cases. If you think it should continue, would you provide the use cases? =E1=90=A7 On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt wrote: > The security topics says MUST. If you want to change that, then that is a > different discussion. :) > > In the OAuth 2.1 document, it would just not be included. Applications ca= n > continue to be OAuth 2.0 compliant. > > BUT ... if there are valid, new use cases. Please describe them! Perhaps > it should not be dropped. > > > On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin > wrote: > >> I would suggest a SHOULD NOT instead of MUST, there are still sites usin= g >> this and a grace period should be provided before a MUST is pushed out a= s >> there are valid use cases out there still. >> >> >> >> *From:* OAuth *On Behalf Of * Dick Hardt >> *Sent:* Tuesday, February 18, 2020 12:37 PM >> *To:* oauth@ietf.org >> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >> >> >> >> Hey List >> >> >> >> (Once again using the OAuth 2.1 name as a placeholder for the doc that >> Aaron, Torsten, and I are working on) >> >> >> >> In the security topics doc >> >> >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-= 2.4 >> >> >> >> >> The password grant MUST not be used. >> >> >> >> Some background for those interested. I added this grant into OAuth 2.0 >> to allow applications that had been provided password to migrate. Even w= ith >> the caveats in OAuth 2.0, implementors decide they want to prompt the us= er >> to enter their credentials, the anti-pattern OAuth was created to >> eliminate. >> >> >> >> >> >> Does anyone have concerns with dropping the password grant from the OAut= h >> 2.1 document so that developers don't use it? >> >> >> >> /Dick >> > --000000000000172057059ef2e40f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony: are you ok with dropping password grant?

You reference valid use cases. If you think it should continue, wou= ld you provide the use cases?

3D""=E1=90= =A7

On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The security to= pics says MUST. If you want to change that, then that is a different discus= sion. :)

In the OAuth 2.1 document, it would just not be= included. Applications can continue to be OAuth 2.0 compliant.
<= br>
BUT ... if there are valid, new use cases. Please describe th= em! Perhaps it should not be dropped.


On Tue, Feb 18, 2= 020 at 12:54 PM Anthony Nadalin <tonynad@microsoft.com> wrote:

I would suggest a SHOULD NOT instead of MUST, there = are still sites using this and a grace period should be provided before a M= UST is pushed out as there are valid use cases out there still.

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: oauth@ietf.o= rg
Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant=

=C2=A0

Hey List=C2=A0

=C2=A0

(Once again using the OAuth 2.1 name as a placeholde= r for the doc that Aaron, Torsten, and I are working on)

=C2=A0

In the security topics doc

=C2=A0

=C2=A0

The password grant MUST not be used.

=C2=A0

Some background for those interested. I added this g= rant into OAuth 2.0 to allow applications that had been provided password t= o migrate. Even with the caveats in OAuth 2.0, implementors decide they wan= t to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate.=C2=A0=

=C2=A0

=C2=A0

Does anyone have concerns with dropping the password= grant from the OAuth 2.1 document so that developers don't use it?<= /u>

=C2=A0

/Dick

--000000000000172057059ef2e40f-- From nobody Wed Feb 19 12:21:11 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09CC120810 for ; Wed, 19 Feb 2020 12:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 RgBja2rVnfK0 for ; Wed, 19 Feb 2020 12:21:03 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEA9120639 for ; Wed, 19 Feb 2020 12:21:03 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id e18so1711806ljn.12 for ; Wed, 19 Feb 2020 12:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HPfMGGkUgrnLWvhESFHMqTpBnft6fxTE4vIGMHLIK70=; b=Q9whwj4hVZ7lVwIJzzflkbXXRUIKFsyu4WfRUayA3JtdIhyW2SBW266k/rpUgZxibl cMGgplFYft6LxiTbJTdSVHo+dWmmDf9EKDhiJ4rSJ2A5M9gCi+xaFWoyLJEgGblI8Ei2 rXP3JuZQJT0GMNr4WxDWNtJVGotERHCuUBUXd7zdHsjiN4lxlU5oDTY3MkGNF1wKyMq6 8i5KG7jzf3HAefreRoyK2jpLT6WdWhzBc6JGc5I05fLtzMTt5eM5CNOut70YAyhOnT+4 QBtIWcK+qg+7RiRWhnRup16On7bfMHGOdcz2SAWbTFvBS+IKMZ3wy9R8t/IwBfeFncvL MHXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HPfMGGkUgrnLWvhESFHMqTpBnft6fxTE4vIGMHLIK70=; b=Kg9tQon9amGcSXC4rjF/uT7c/GxDkhZfzVV6L1Qj4VqZKXapJyV37RwTeRPZNSjaKZ KRzjihcliaSwwyJw5bXmNCdrfH6KmJ9p7N8XQ/dHOaANwk8Dyb4gzHJK6ivRiMw5l3L7 xpaDOSGrvT7UmW7kB3L8ABzvIqq0z13SqufqnOAggO/0Ig/KSNI6RfRqPGxR2JuQkwI8 MLj34JCRCmWxpAfYuoV6vJrVpCizYWryKAhPbH4vvw0sJwEnQ0xf9TO2OVHGDnM6Jpdb arnwXlAe9pO5XClHFlfKPsQgQWYqrryxp3EVYdXaA72pUr7F3P2gRqlquKfpXacoQ3ZN /B0Q== X-Gm-Message-State: APjAAAVY2Bdnj7V6G69IuLzeHfV4zvDKghC3STgkKGAOzrUravfUZCJC gjdG//t7d5djsGpDHaP6QEvzHDZHeU3bsZBhMoAZ8NRL X-Google-Smtp-Source: APXvYqxr6v+NNAagYcjc0tz1OjTskydZFq1LxVqxXXdot32L6NpNM+mhU9+fDSvx3K1WBwo7u9KNHcOd+FKRRARgRtc= X-Received: by 2002:a2e:a490:: with SMTP id h16mr17027453lji.115.1582143660899; Wed, 19 Feb 2020 12:21:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bruno Brito Date: Wed, 19 Feb 2020 17:20:50 -0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e4459b059ef3868b" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 20:21:09 -0000 --000000000000e4459b059ef3868b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, I cannot see any use case where authorization code cannot replace implicit. Go ahead and remove it! Bruno On Wed, Feb 19, 2020 at 5:01 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: OAuth 2.1 - drop implicit flow? (Dominick Baier) > 2. Re: OAuth Digest, Vol 136, Issue 7 (Torsten Lodderstedt) > 3. Re: [EXTERNAL] OAuth 2.1: dropping password grant (Dick Hardt) > > > > ---------- Forwarded message ---------- > From: Dominick Baier > To: Dick Hardt , oauth@ietf.org > Cc: > Bcc: > Date: Tue, 18 Feb 2020 22:49:05 -0800 > Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow? > No - please get rid of it. > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 18. February 2020 at 21:32:31, Dick Hardt (dick.hardt@gmail.com) wrote= : > > Hey List > > (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, > Torsten, and I are working on) > > Given the points Aaron brought up in > > https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU > > > Does anyone have concerns with dropping the implicit flow from the OAuth > 2.1 document so that developers don't use it? > > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > ---------- Forwarded message ---------- > From: Torsten Lodderstedt > To: Bruno Brito > Cc: oauth@ietf.org > Bcc: > Date: Wed, 19 Feb 2020 08:25:19 +0100 > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7 > Hi Bruno, > > thanks for your insights. > > The recommendation is not only based on security considerations but just > utility. As soon as one wants to integrate federated login or multi facto= r > authentication, ROPG reaches its limits. > > Moreover, how do those teams implement user registration and user account > recovery? In my experience, implementing this in a native experience will > significantly increase cost of the implementation. > > Two reasons to go with the code flow. > > best regards, > Torsten. > > > Am 19.02.2020 um 01:49 schrieb Bruno Brito : > > > > > > ---------- Forwarded message ---------- > From: Dick Hardt > To: Anthony Nadalin > Cc: "oauth@ietf.org" > Bcc: > Date: Wed, 19 Feb 2020 11:35:03 -0800 > Subject: Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant > Tony: are you ok with dropping password grant? > > You reference valid use cases. If you think it should continue, would you > provide the use cases? > > =E1=90=A7 > > On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt wrote: > >> The security topics says MUST. If you want to change that, then that is = a >> different discussion. :) >> >> In the OAuth 2.1 document, it would just not be included. Applications >> can continue to be OAuth 2.0 compliant. >> >> BUT ... if there are valid, new use cases. Please describe them! Perhaps >> it should not be dropped. >> >> >> On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin >> wrote: >> >>> I would suggest a SHOULD NOT instead of MUST, there are still sites >>> using this and a grace period should be provided before a MUST is pushe= d >>> out as there are valid use cases out there still. >>> >>> >>> >>> *From:* OAuth *On Behalf Of * Dick Hardt >>> *Sent:* Tuesday, February 18, 2020 12:37 PM >>> *To:* oauth@ietf.org >>> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >>> >>> >>> >>> Hey List >>> >>> >>> >>> (Once again using the OAuth 2.1 name as a placeholder for the doc that >>> Aaron, Torsten, and I are working on) >>> >>> >>> >>> In the security topics doc >>> >>> >>> >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section= -2.4 >>> >>> >>> >>> >>> The password grant MUST not be used. >>> >>> >>> >>> Some background for those interested. I added this grant into OAuth 2.0 >>> to allow applications that had been provided password to migrate. Even = with >>> the caveats in OAuth 2.0, implementors decide they want to prompt the u= ser >>> to enter their credentials, the anti-pattern OAuth was created to >>> eliminate. >>> >>> >>> >>> >>> >>> Does anyone have concerns with dropping the password grant from the >>> OAuth 2.1 document so that developers don't use it? >>> >>> >>> >>> /Dick >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000e4459b059ef3868b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, I cannot see an= y use case where authorization code cannot replace implicit. Go ahead and r= emove it!
B= runo

On Wed, Feb 19, 2020 at 5:01= PM <oauth-request@ietf.org> wrote:
Sen= d OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

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

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

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

=C2=A0 =C2=A01. Re: OAuth 2.1 - drop implicit flow? (Dominick Baier)
=C2=A0 =C2=A02. Re: OAuth Digest, Vol 136, Issue 7 (Torsten Lodderstedt) =C2=A0 =C2=A03. Re: [EXTERNAL]=C2=A0 OAuth 2.1: dropping password grant (Di= ck Hardt)



---------- Forwarded message ----------
From:=C2=A0Dominick = Baier <db= aier@leastprivilege.com>
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>, oauth@ietf.org
Cc:= =C2=A0
Bcc:=C2=A0
Date:=C2=A0Tue, 18 Feb 2020 22:49:05 -0800
Subje= ct:=C2=A0Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?
No - please get rid of it.<= /div>
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier
=

On 18. February 2020 at 21:32:31, Dick Hardt (dick.hardt@gmail.com) wrote:

Hey List=C2=A0

(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)

Given the points Aaron brought up in



Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it?

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



---------- Forwarded message ----------
From:=C2=A0Torsten L= odderstedt <torsten@lodderstedt.net>
To:=C2=A0Bruno Brito <bhdebrito@gmail.com>
C= c:=C2=A0oauth@ietf.org<= /a>
Bcc:=C2=A0
Date:=C2=A0Wed, 19 Feb 2020 08:25:19 +0100
Subject:= =C2=A0Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7
Hi Bruno,

thanks for your insights.

The recommendation is not only based on security considerations but just ut= ility. As soon as one wants to integrate federated login or multi factor au= thentication,=C2=A0 ROPG reaches its limits.

Moreover, how do those teams implement user registration and user account r= ecovery? In my experience, implementing this in a native experience will si= gnificantly increase cost of the implementation.

Two reasons to go with the code flow.

best regards,
Torsten.

> Am 19.02.2020 um 01:49 schrieb Bruno Brito <bhdebrito@gmail.com>:
>



---------- Forwarded message ----------
From:=C2=A0Dick Hard= t <dick.hardt@= gmail.com>
To:=C2=A0Anthony Nadalin <tonynad@microsoft.com>
Cc:=C2= =A0"oauth@ietf.org= " <oauth@ie= tf.org>
Bcc:=C2=A0
Date:=C2=A0Wed, 19 Feb 2020 11:35:03 -0800<= br>Subject:=C2=A0Re: [OAUTH-WG] [EXTERNAL]=C2=A0 OAuth 2.1: dropping passwo= rd grant
Tony: are you ok with dropping password grant?=

You reference valid use cases. If you think it should c= ontinue, would you provide the use cases?

3D""=E1=90=A7

On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt <dick.hardt@gmail.com= > wrote:
=
The security topics says MUST. If you want to change that,= then that is a different discussion. :)

In the OAuth 2.= 1 document, it would just not be included. Applications can continue to be = OAuth 2.0 compliant.

BUT ... if there are valid, n= ew use cases. Please describe them! Perhaps it should not be dropped.
=


On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin <tonynad@microsoft.com<= /a>> wrote:

I would suggest a SHOULD NOT instead of MUST, there = are still sites using this and a grace period should be provided before a M= UST is pushed out as there are valid use cases out there still.

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: oauth@ietf.o= rg
Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant=

=C2=A0

Hey List=C2=A0

=C2=A0

(Once again using the OAuth 2.1 name as a placeholde= r for the doc that Aaron, Torsten, and I are working on)

=C2=A0

In the security topics doc

=C2=A0

=C2=A0

The password grant MUST not be used.

=C2=A0

Some background for those interested. I added this g= rant into OAuth 2.0 to allow applications that had been provided password t= o migrate. Even with the caveats in OAuth 2.0, implementors decide they wan= t to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate.=C2=A0=

=C2=A0

=C2=A0

Does anyone have concerns with dropping the password= grant from the OAuth 2.1 document so that developers don't use it?<= /u>

=C2=A0

/Dick

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e4459b059ef3868b-- From nobody Wed Feb 19 13:03:13 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93E4120818 for ; Wed, 19 Feb 2020 13:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8-RL-N5zCMaH for ; Wed, 19 Feb 2020 13:03:08 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6480120810 for ; Wed, 19 Feb 2020 13:03:07 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id p17so2214103wma.1 for ; Wed, 19 Feb 2020 13:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yHux7NbJUZEssyqsLIHdprVKnINPcPQ7Z2B5RGv/tk8=; b=J0V5dBsr/+/FXeGf/GdY0GA3jMJVL8QnbrLhrSpwqUsGVz0BENivgKwNP1ACTdTDMc MsakYXjC92Vx656DpGNOrjlndX2XX6a9n1pltktaVEcU7ol9HBfIyQrwpSU1zuxAJdSN 775bc0H5uSoW74NxADvgu/uPDhKQbWxK9xyx4= 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=yHux7NbJUZEssyqsLIHdprVKnINPcPQ7Z2B5RGv/tk8=; b=ccMRD4esP5YDWEKElnWHwm75VVX6FOAkVvo+62RUil4NYzmM29AZ7NMMBfpQDRI7cL U6IK0b5uXjPtt/lzG1WLE/lxWwmkOoNWa6PKnh5BJe6kmf/sKj8767bkAttOkP8KwI6u DiKsVHdvOPq0kbyKEFoH3W5aQlxiTUm/Zq6KYzI5dqAkON1nLneyqk1BP8wxp0z0kWBu NrUukITRi2J2QF9KlF9c7TMJIkcNjIruJAsFuvilsuaeLrgWh249p91giUDNV1bDBD8h 50F46Mvao0LcOxzQngcdzb0nQCTM7uUwAWLAbCiw1trrl4Pc1hRpsfc1v2wNVIRRSHFz n2Dw== X-Gm-Message-State: APjAAAV9Yqs3MIsfMt+4b77VPHM1Xr+WWYpv0vX9TDdExdAuPKu2iSFO w9/kVSeuua6UpJ1Ik9EJn5eLvHHn67M2vA== X-Google-Smtp-Source: APXvYqwVzUiSigAAsFh3Qe/6/DbblowPgTNOV891V8CRcgsidtYr5B3mi3nZAmBXrrwOFl8LHjWu4A== X-Received: by 2002:a7b:c407:: with SMTP id k7mr12364722wmi.46.1582146185997; Wed, 19 Feb 2020 13:03:05 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id y185sm1470081wmg.2.2020.02.19.13.03.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2020 13:03:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: Date: Wed, 19 Feb 2020 21:03:03 +0000 Cc: Aaron Parecki , Anthony Nadalin , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> References: <13A86ACE-3D9E-4FDF-9892-7A040DE5F4C6@mit.edu> To: Hans Zandbelt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 21:03:11 -0000 I very much agree with this with regards to real users.=20 The one legitimate use-case for ROPC I=E2=80=99ve seen is for service = accounts - where you essentially want something like client_credentials = but for whatever reason you need the RO to be a service user rather than = an OAuth2 client (typically so that some lower layer of the system can = still perform its required permission checks). There are better grant types for this - e.g. JWT bearer - but they are a = bit harder to implement. Having recently converted some code from ROPC = to JWT bearer for exactly this use-case, it went from a couple of lines = of code to two screens of code. For service to service API calls within = a datacenter I=E2=80=99m not convinced this resulted in a material = increase in security for the added complexity. =E2=80=94 Neil > On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >=20 > I would also seriously look at the original motivation behind ROPC: I = know it has been deployed and is used in quite a lot of places but I = have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) > In reality it turned out just to be a one off that people used as an = easy way out to stick to an anti-pattern and still claim to do OAuth = 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. >=20 > Hans. >=20 > On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: > Agreed. Plus, the Security BCP is already effectively acting as a = grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal. >=20 > Aaron >=20 >=20 >=20 > On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: > There is no need for a grace period. People using OAuth 2.0 can still = do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >=20 > =E2=80=94 Justin >=20 >> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>=20 >> I would suggest a SHOULD NOT instead of MUST, there are still sites = using this and a grace period should be provided before a MUST is pushed = out as there are valid use cases out there still. >> =20 >> From: OAuth On Behalf Of Dick Hardt >> Sent: Tuesday, February 18, 2020 12:37 PM >> To: oauth@ietf.org >> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >> =20 >> Hey List=20 >> =20 >> (Once again using the OAuth 2.1 name as a placeholder for the doc = that Aaron, Torsten, and I are working on) >> =20 >> In the security topics doc >> =20 >> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >> =20 >> The password grant MUST not be used. >> =20 >> Some background for those interested. I added this grant into OAuth = 2.0 to allow applications that had been provided password to migrate. = Even with the caveats in OAuth 2.0, implementors decide they want to = prompt the user to enter their credentials, the anti-pattern OAuth was = created to eliminate.=20 >> =20 >> =20 >> Does anyone have concerns with dropping the password grant from the = OAuth 2.1 document so that developers don't use it? >> =20 >> /Dick >> _______________________________________________ >> 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 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Feb 19 13:20:41 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1847120128; Wed, 19 Feb 2020 13:20:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158214723877.17788.3564958036917641999@ietfa.amsl.com> Date: Wed, 19 Feb 2020 13:20:38 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 21:20: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 : OAuth 2.0 Rich Authorization Requests Authors : Torsten Lodderstedt Justin Richer Brian Campbell Filename : draft-ietf-oauth-rar-01.txt Pages : 30 Date : 2020-02-19 Abstract: This document specifies a new parameter "authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-rar-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-01 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 Feb 19 13:35:34 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2F120816 for ; Wed, 19 Feb 2020 13:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMLYBYy-BQ1Q for ; Wed, 19 Feb 2020 13:35:21 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23849120859 for ; Wed, 19 Feb 2020 13:35:21 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id g3so2239382wrs.12 for ; Wed, 19 Feb 2020 13:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=8DkU+UtO7rqiiENqM0SIKx77TeYEZXCBsVPLdpL3aro=; b=VFwW+onEkSKMlmszE0HlixdqBTopZHyJZM7HI7olctanxCGyZ5/33CKFzKizTu2sTr FGuHYj4Sk80EnSxl9QRAjQfXQ8JdzGd35yuNip/43PwNP0A/UAzBtWQeD4xRbU/lNaiv y3glaUA6Rqk7WL5rjXrnsWz+wqnPQh62Efz9P7ebdRtMBnFaRGMDcJK7qAs1OjxYt/NR +JjtWuJSpv6vKwtJ2oE0OPxbLvZrW86w0xgoftwFTUltAcFSrPWnp391fYTCBNzBl2wV HE1INoT6hMbpv9NCYfVjfcYNK0KkGKwHTXmU3SnRZvb0T7hMYp4QvAxtzfCV0GJcAvJQ WM4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=8DkU+UtO7rqiiENqM0SIKx77TeYEZXCBsVPLdpL3aro=; b=t760XGoNlX6gTYCQKSW9nLgMG/aOS131+vd+it1Zd/eZBju9wkH8m3TRYrJJbR22qN golk83mtZDDjSLG9KaBJOkChiiITTzqaqAEjMjlDqnBID5DnMjcqG45Sy8Abv929syRC 3eAMQL5vD/j7j/WeZNnm+6B2zpM7VuaFoK15os2LQ++admwyfGTewS/qBlivKmKt5xSq pf7NQxQNK5H1VUG5D3vmPbW4ufrHYPM4v2dsg89BLQ/lVhwLiDTpDHIxSlwu2INXKRdt 51I9zbDdkw7uJz1ygA3avYMzLbXYK6vGdq09rYk4XPMr8TOSM2oEt1qeSB/EVZLjyhxA UAlw== X-Gm-Message-State: APjAAAXw3Ma2km/GfSmN+g5epQE1ZUfZMmWBPuHwz6Vv7mzXTsDjTeRJ /0yYFh8GI0WD6XZvXbq66dqMa87sww3QMQ== X-Google-Smtp-Source: APXvYqxW6P6XKGFg35CmuIjntx+Qz/JW9MDwgMPtGez64OqRKk5eHVEfPiyQJj42alba+VHf0umHRw== X-Received: by 2002:adf:b605:: with SMTP id f5mr36196487wre.383.1582148119327; Wed, 19 Feb 2020 13:35:19 -0800 (PST) Received: from ?IPv6:2003:eb:8f11:fd23:f898:e0c8:d900:c3ec? (p200300EB8F11FD23F898E0C8D900C3EC.dip0.t-ipconnect.de. [2003:eb:8f11:fd23:f898:e0c8:d900:c3ec]) by smtp.gmail.com with ESMTPSA id h10sm1445833wml.18.2020.02.19.13.35.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2020 13:35:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 19 Feb 2020 22:35:17 +0100 Message-Id: <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> Cc: Hans Zandbelt , Anthony Nadalin , "oauth@ietf.org" In-Reply-To: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> To: Neil Madden X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 21:35:32 -0000 Can you explain more in detail why the client credentials grant type isn=E2=80= =99t applicable for the kind of use cases you mentioned? > Am 19.02.2020 um 22:03 schrieb Neil Madden : >=20 > =EF=BB=BFI very much agree with this with regards to real users.=20 >=20 > The one legitimate use-case for ROPC I=E2=80=99ve seen is for service acco= unts - where you essentially want something like client_credentials but for w= hatever reason you need the RO to be a service user rather than an OAuth2 cl= ient (typically so that some lower layer of the system can still perform its= required permission checks). >=20 > There are better grant types for this - e.g. JWT bearer - but they are a b= it harder to implement. Having recently converted some code from ROPC to JWT= bearer for exactly this use-case, it went from a couple of lines of code to= two screens of code. For service to service API calls within a datacenter I= =E2=80=99m not convinced this resulted in a material increase in security fo= r the added complexity. >=20 > =E2=80=94 Neil >=20 >> On 18 Feb 2020, at 21:57, Hans Zandbelt wrot= e: >>=20 >> I would also seriously look at the original motivation behind ROPC: I kno= w it has been deployed and is used in quite a lot of places but I have never= actually come across a use case where it is used for migration purposes and= the migration is actually executed (I know that is statistically not a very= strong argument but I challenge others to come up with one...) >> In reality it turned out just to be a one off that people used as an easy= way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is p= lain wrong, it is not OAuth and we need to get rid of it. >>=20 >> Hans. >>=20 >> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote:= >> Agreed. Plus, the Security BCP is already effectively acting as a grace p= eriod since it currently says the password grant MUST NOT be used, so in the= OAuth 2.0 world that's already a pretty strong signal. >>=20 >> Aaron >>=20 >>=20 >>=20 >> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: >> There is no need for a grace period. People using OAuth 2.0 can still do O= Auth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>=20 >> =E2=80=94 Justin >>=20 >>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin wrote: >>>=20 >>> I would suggest a SHOULD NOT instead of MUST, there are still sites usin= g this and a grace period should be provided before a MUST is pushed out as t= here are valid use cases out there still. >>>=20 >>> From: OAuth On Behalf Of Dick Hardt >>> Sent: Tuesday, February 18, 2020 12:37 PM >>> To: oauth@ietf.org >>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >>>=20 >>> Hey List=20 >>>=20 >>> (Once again using the OAuth 2.1 name as a placeholder for the doc that A= aron, Torsten, and I are working on) >>>=20 >>> In the security topics doc >>>=20 >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-= 2.4 >>>=20 >>> The password grant MUST not be used. >>>=20 >>> Some background for those interested. I added this grant into OAuth 2.0 t= o allow applications that had been provided password to migrate. Even with t= he caveats in OAuth 2.0, implementors decide they want to prompt the user to= enter their credentials, the anti-pattern OAuth was created to eliminate.=20= >>>=20 >>>=20 >>> Does anyone have concerns with dropping the password grant from the OAut= h 2.1 document so that developers don't use it? >>>=20 >>> /Dick >>> _______________________________________________ >>> 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 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> --=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Feb 19 13:43:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20F4120289 for ; Wed, 19 Feb 2020 13:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDhESLXKflvK for ; Wed, 19 Feb 2020 13:43:21 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8CE120128 for ; Wed, 19 Feb 2020 13:43:21 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id l21so1384439qtr.8 for ; Wed, 19 Feb 2020 13:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=G5Zs8TS0ltL9l8FHpptNSnxxBnw7aTO9dUMCAK/yvH4=; b=CYUCorwd1QeT/lIQRl0tB4n9LOW0YG5KoHEwc6hk+YziiOcT7jDvYylZoUh97+IEFw LF8V5opxqZmhs6zm70hR7xZcTFBjQYMFjaUon73LFu3viauonJwJAu45fnR5UY3ShHyS Eo7V/Vhd2Ceg+bJNnRb7JQAV0H7z264vK9QfWOGO2VJlD34FkB11ZQr2MTAJE6H3Skod DKb4gu5R4uz0ZC7Nklder2TXEq3VENxYwgjjTP3smli6kCdh+26b9qazsScl2hKAdJCf mEHsO8K4BYvzwgdr/ZA1azua9YjHSoMAeqY80g03cSh26SUR8op5ulwAmUd4RN0IiRah nrkA== 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=G5Zs8TS0ltL9l8FHpptNSnxxBnw7aTO9dUMCAK/yvH4=; b=BBx8v00nbiO2FZJT4GlZ047CFprK2ryPTda8Pd+mhXBE3z9IFHND2sjibRI2ueR4z7 QtOj6HdkOKkocM7E5/63XnnAeByvrRrPQNX5dk91ntDdweYXIbVOygbX2TsqLJG6Unrd NcWUAeEG0EjMFKNZwC/v0V0NE4yjtLaI4rfi+IhrBVA0Q0DmBN3jqBTsGhM0Z+99uSY/ XLNS5G4XukEEoy02bHB2+bntRRS8CwYTK6/tCHDWpjXSmeJ1ek326Qt2WwQrL8FEnqrT +CKYUvcoBgXgx3jlZUCMnwoMgFkpNaD7WxXX0EsOB3zCS6ui4u06junynVSkiQZFICO/ tidA== X-Gm-Message-State: APjAAAVuBgPrqA2cAMIrAwShHrwVLMH9pm1l42XvvHmGXnwh8e0DEGRp LM4bi5T6g4qd8VYhpnFNPBw= X-Google-Smtp-Source: APXvYqxs3dX9jf4CSq13fdYW/R3ZjSZ74hd7lHDeEmp+XUdTkPG7qOXfIqOcmLn1ORzhhxJr+MzOZQ== X-Received: by 2002:ac8:a06:: with SMTP id b6mr24697803qti.264.1582148599870; Wed, 19 Feb 2020 13:43:19 -0800 (PST) Received: from [10.0.1.2] (pool-74-103-207-160.prvdri.ftas.verizon.net. [74.103.207.160]) by smtp.gmail.com with ESMTPSA id l19sm516755qkl.3.2020.02.19.13.43.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2020 13:43:19 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_39244167.964375144273" MIME-Version: 1.0 Date: Wed, 19 Feb 2020 16:43:18 -0500 Message-ID: From: "Brock Allen" To: "Torsten Lodderstedt" , "Neil Madden" Cc: "Anthony Nadalin" , "" In-Reply-To: <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> User-Agent: Mailbird/2.7.14.0 X-Mailbird-ID: Mailbird-db7f7ccb-1ce0-4d20-83c2-3b817dfa652f@gmail.com Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 21:43:24 -0000 ------=_NextPart_39244167.964375144273 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've seen the same. People have user-centric authorization systems where th= ey have a "service user" that they attach permissions to. In client credent= ials they don't want to have to special case a client credentials caller (v= s. a code flow client) and instead just use the calling "user" to look up p= ermissions. -Brock On 2/19/2020 4:35:43 PM, Torsten Lodderstedt wrote: Can you explain more in detail why the client credentials grant type isn=E2= =80=99t applicable for the kind of use cases you mentioned? > Am 19.02.2020 um 22:03 schrieb Neil Madden : > > =EF=BB=BFI very much agree with this with regards to real users. > > The one legitimate use-case for ROPC I=E2=80=99ve seen is for service acc= ounts - where you essentially want something like client_credentials but fo= r whatever reason you need the RO to be a service user rather than an OAuth= 2 client (typically so that some lower layer of the system can still perfor= m its required permission checks). > > There are better grant types for this - e.g. JWT bearer - but they are a = bit harder to implement. Having recently converted some code from ROPC to J= WT bearer for exactly this use-case, it went from a couple of lines of code= to two screens of code. For service to service API calls within a datacent= er I=E2=80=99m not convinced this resulted in a material increase in securi= ty for the added complexity. > > =E2=80=94 Neil > >> On 18 Feb 2020, at 21:57, Hans Zandbelt wrote: >> >> I would also seriously look at the original motivation behind ROPC: I kn= ow it has been deployed and is used in quite a lot of places but I have nev= er actually come across a use case where it is used for migration purposes = and the migration is actually executed (I know that is statistically not a = very strong argument but I challenge others to come up with one...) >> In reality it turned out just to be a one off that people used as an eas= y way out to stick to an anti-pattern and still claim to do OAuth 2.0. It i= s plain wrong, it is not OAuth and we need to get rid of it. >> >> Hans. >> >> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote: >> Agreed. Plus, the Security BCP is already effectively acting as a grace = period since it currently says the password grant MUST NOT be used, so in t= he OAuth 2.0 world that's already a pretty strong signal. >> >> Aaron >> >> >> >> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: >> There is no need for a grace period. People using OAuth 2.0 can still do= OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. >> >> =E2=80=94 Justin >> >>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin wrote: >>> >>> I would suggest a SHOULD NOT instead of MUST, there are still sites usi= ng this and a grace period should be provided before a MUST is pushed out a= s there are valid use cases out there still. >>> >>> From: OAuth On Behalf Of Dick Hardt >>> Sent: Tuesday, February 18, 2020 12:37 PM >>> To: oauth@ietf.org >>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >>> >>> Hey List >>> >>> (Once again using the OAuth 2.1 name as a placeholder for the doc that = Aaron, Torsten, and I are working on) >>> >>> In the security topics doc >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section= -2.4 >>> >>> The password grant MUST not be used. >>> >>> Some background for those interested. I added this grant into OAuth 2.0= to allow applications that had been provided password to migrate. Even wit= h the caveats in OAuth 2.0, implementors decide they want to prompt the use= r to enter their credentials, the anti-pattern OAuth was created to elimina= te. >>> >>> >>> Does anyone have concerns with dropping the password grant from the OAu= th 2.1 document so that developers don't use it? >>> >>> /Dick >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_39244167.964375144273 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A I've seen= the same. People have user-centric authorization systems where they have a= "service user" that they attach permissions to. In client credentials they= don't want to have to special case a client credentials caller (vs. a code= flow client) and instead just use the calling "user" to look up permission= s.

-Brock

=0A

Can you explain more in detail why the client credentials grant= type isn=E2=80=99t applicable for the kind of use cases you mentioned?
=
> Am 19.02.2020 um 22:03 schrieb Neil Madden :
>
> =EF=BB=BFI very much agree with this with regards to= real users.
>
> The one legitimate use-case for ROPC I=E2=80= =99ve seen is for service accounts - where you essentially want something l= ike client_credentials but for whatever reason you need the RO to be a serv= ice user rather than an OAuth2 client (typically so that some lower layer o= f the system can still perform its required permission checks).
> > There are better grant types for this - e.g. JWT bearer - but they ar= e a bit harder to implement. Having recently converted some code from ROPC = to JWT bearer for exactly this use-case, it went from a couple of lines of = code to two screens of code. For service to service API calls within a data= center I=E2=80=99m not convinced this resulted in a material increase in se= curity for the added complexity.
>
> =E2=80=94 Neil
> >> On 18 Feb 2020, at 21:57, Hans Zandbelt wrote:
>>
>> I would also seriously look at the ori= ginal motivation behind ROPC: I know it has been deployed and is used in qu= ite a lot of places but I have never actually come across a use case where = it is used for migration purposes and the migration is actually executed (I= know that is statistically not a very strong argument but I challenge othe= rs to come up with one...)
>> In reality it turned out just to be = a one off that people used as an easy way out to stick to an anti-pattern a= nd still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we n= eed to get rid of it.
>>
>> Hans.
>>
>&g= t; On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote= :
>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be us= ed, so in the OAuth 2.0 world that's already a pretty strong signal.
>= ;>
>> Aaron
>>
>>
>>
>>= On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote:
= >> There is no need for a grace period. People using OAuth 2.0 can st= ill do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>> >> =E2=80=94 Justin
>>
>>>> On Feb 18, 202= 0, at 3:54 PM, Anthony Nadalin w= rote:
>>>
>>> I would suggest a SHOULD NOT instead= of MUST, there are still sites using this and a grace period should be pro= vided before a MUST is pushed out as there are valid use cases out there st= ill.
>>>
>>> From: OAuth = On Behalf Of Dick Hardt
>>> Sent: Tuesday, February 18, 2020 12= :37 PM
>>> To: oauth@ietf.org
>>> Subject: [EXTERNA= L] [OAUTH-WG] OAuth 2.1: dropping password grant
>>>
>&g= t;> Hey List
>>>
>>> (Once again using the OAu= th 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are wor= king on)
>>>
>>> In the security topics doc
>= ;>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-sec= urity-topics-14#section-2.4
>>>
>>> The password g= rant MUST not be used.
>>>
>>> Some background for= those interested. I added this grant into OAuth 2.0 to allow applications = that had been provided password to migrate. Even with the caveats in OAuth = 2.0, implementors decide they want to prompt the user to enter their creden= tials, the anti-pattern OAuth was created to eliminate.
>>> >>>
>>> Does anyone have concerns with dropping the= password grant from the OAuth 2.1 document so that developers don't use it= ?
>>>
>>> /Dick
>>> __________________= _____________________________
>>> OAuth mailing list
>>= ;> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/= oauth
>>
>> ____________________________________________= ___
>> OAuth mailing list
>> OAuth@ietf.org
>> h= ttps://www.ietf.org/mailman/listinfo/oauth
>> --
>> ----=
>> Aaron Parecki
>> aaronparecki.com
>> @aaronp= k
>>
>> _______________________________________________<= br>>> OAuth mailing list
>> OAuth@ietf.org
>> https= ://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>= ; --
>> hans.zandbelt@zmartzone.eu
>> ZmartZone IAM - ww= w.zmartzone.eu
>> _______________________________________________<= br>>> 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

=0A =0A = ------=_NextPart_39244167.964375144273-- From nobody Wed Feb 19 13:52:53 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBF7120837 for ; Wed, 19 Feb 2020 13:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Ag4LQQcFFMZo for ; Wed, 19 Feb 2020 13:52:48 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2FA120289 for ; Wed, 19 Feb 2020 13:52:48 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id w15so2339997wru.4 for ; Wed, 19 Feb 2020 13:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JEMrW6AGkN704hXUnMp2lr1872a0kE8znDffUIiBDrM=; b=CV3s8UVIpTVvzevcTdShIn/E9KEebo9+/oGvV+xS1v32b+dcMgYIk3SMEYPrS6hOHv XtdpSyfQTgd2yu2zENQycflbgwic1cwXTUiZwP9ELqzae8rnWmlIW9zHykmnqkUsgzbr d/Zo6Cjoq+KlruWxb/EdmGVPJxsgKA2Qp3HL0= 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=JEMrW6AGkN704hXUnMp2lr1872a0kE8znDffUIiBDrM=; b=aiv87kpQbLclZPAfg/13O3qIgefMf4v0aFBwRBvcGEt07zfqBGC0QDGOOrcv1bTC1m 984IpLf4h4UkgIQmJDX4BGeWmJcWqwtvEx0FUl5Ixl310BUNX+5EEgwikaW6Qh1Q4+8Z SgielcTfgA7cgu3xRvCP2NVZcCNk6ogRWuUYdcljxtWZ7po3PwQcuVfy+eGs9a5QM5k1 CVCDsR2iRzvIw0S9NbdpymOFOSk4RH7/BAoPhquaN1uEYHSO5iXAjoIpmQQk+PEV+aZ7 1sZsPhIF9VbFSf+Tw0v/eqBNGtOxxmxDl6+nT75nfV7kbHDRXqhnXZ6i4jUXAL+PSqYQ nojw== X-Gm-Message-State: APjAAAU6kJimfyqtJkFZ/qVOsZvsm/rF3w7mklHSB+MxqvIJCb6VsZgy HPOThYvDIHLvVcOnSnZqKjW3vg== X-Google-Smtp-Source: APXvYqxZ5TpcLIn4Md1zZjqroMOvVtPBppdc4UJZ2vGzWowQRZ0cfYgVhkSgKZatqn0uCJzR0fMFbw== X-Received: by 2002:adf:f491:: with SMTP id l17mr40838683wro.149.1582149166510; Wed, 19 Feb 2020 13:52:46 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id f62sm1558407wmf.36.2020.02.19.13.52.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2020 13:52:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> Date: Wed, 19 Feb 2020 21:52:45 +0000 Cc: Hans Zandbelt , Anthony Nadalin , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 21:52:52 -0000 OAuth2 clients are often private to the AS - they live in a database = that only the AS can access, have attributes specific to their use in = OAuth2, and so on. Many existing systems have access controls based on = users, roles, permissions and so on and expect all users accessing the = system to exist in some user repository, e.g. LDAP, where they can be = looked up and appropriate permissions determined. A service account can = be created inside such a system as if it was a regular user, managed = through the normal account provisioning tools, assigned permissions, = roles, etc. Another reason is that sometimes OAuth is just one authentication option = out of many, and so permissions assigned to service accounts are = preferred over scopes because they are consistently applied no matter = how a request is authenticated. This is often the case when OAuth has = been retrofitted to an existing system and they need to preserve = compatibility with already deployed clients. See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount They use the JWT bearer grant type for service account authentication = and assign permissions to those service accounts and typically have very = broad scopes. For service-to-service API calls you typically get an = access token with a single scope that is effectively =E2=80=9Call of = GCP=E2=80=9D and everything is managed at the level of permissions on = the RO service account itself. They only break down fine-grained scopes = when you are dealing with user data and will be getting an access token = approved by a real user (through a normal auth code flow). =E2=80=94 Neil > On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >=20 > Can you explain more in detail why the client credentials grant type = isn=E2=80=99t applicable for the kind of use cases you mentioned? >=20 >> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>=20 >> =EF=BB=BFI very much agree with this with regards to real users.=20 >>=20 >> The one legitimate use-case for ROPC I=E2=80=99ve seen is for service = accounts - where you essentially want something like client_credentials = but for whatever reason you need the RO to be a service user rather than = an OAuth2 client (typically so that some lower layer of the system can = still perform its required permission checks). >>=20 >> There are better grant types for this - e.g. JWT bearer - but they = are a bit harder to implement. Having recently converted some code from = ROPC to JWT bearer for exactly this use-case, it went from a couple of = lines of code to two screens of code. For service to service API calls = within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>=20 >> =E2=80=94 Neil >>=20 >>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>=20 >>> I would also seriously look at the original motivation behind ROPC: = I know it has been deployed and is used in quite a lot of places but I = have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>> In reality it turned out just to be a one off that people used as an = easy way out to stick to an anti-pattern and still claim to do OAuth = 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. >>>=20 >>> Hans. >>>=20 >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>> Agreed. Plus, the Security BCP is already effectively acting as a = grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal. >>>=20 >>> Aaron >>>=20 >>>=20 >>>=20 >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>> There is no need for a grace period. People using OAuth 2.0 can = still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>=20 >>>> I would suggest a SHOULD NOT instead of MUST, there are still sites = using this and a grace period should be provided before a MUST is pushed = out as there are valid use cases out there still. >>>>=20 >>>> From: OAuth On Behalf Of Dick Hardt >>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>> To: oauth@ietf.org >>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >>>>=20 >>>> Hey List=20 >>>>=20 >>>> (Once again using the OAuth 2.1 name as a placeholder for the doc = that Aaron, Torsten, and I are working on) >>>>=20 >>>> In the security topics doc >>>>=20 >>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>=20 >>>> The password grant MUST not be used. >>>>=20 >>>> Some background for those interested. I added this grant into OAuth = 2.0 to allow applications that had been provided password to migrate. = Even with the caveats in OAuth 2.0, implementors decide they want to = prompt the user to enter their credentials, the anti-pattern OAuth was = created to eliminate.=20 >>>>=20 >>>>=20 >>>> Does anyone have concerns with dropping the password grant from the = OAuth 2.1 document so that developers don't use it? >>>>=20 >>>> /Dick >>>> _______________________________________________ >>>> 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 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> --=20 >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Feb 19 14:01:02 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5F2120851 for ; Wed, 19 Feb 2020 14:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P5tUOfo1svB for ; Wed, 19 Feb 2020 14:00:57 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (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 5BD5912083D for ; Wed, 19 Feb 2020 14:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1582149657; x=1613685657; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9u0vtMH2fJG2qfZ1Lwry5nydcs8A4fv75hWlzo7/i+k=; b=e3S5DxX+sSYcw5PHRcsE245TYKwTWKVRAON6Fn708SuOL3UnLwMXJXBt XSodbkbsr3BedFlTiEKS8jAqi1ev+763ORXCM/V8Q5wwItvoDOH8Ucb/W lkmj7ZEJapdHHtK/NI9kTrFNTV4K4TUmAhtHlHRR9qjvfKLunn06zSWbV Y=; IronPort-SDR: GoUaETAz/v+nvU9ldW091ZjZc0btvYal85HiqiCK9TcjjaMPiT8ln1io1gj1eWxuNUUzJA0H/d 17P9byRVZbwA== X-IronPort-AV: E=Sophos;i="5.70,462,1574121600"; d="scan'208";a="17818198" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 19 Feb 2020 22:00:54 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id 5F236A2507; Wed, 19 Feb 2020 22:00:53 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 19 Feb 2020 22:00:52 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 19 Feb 2020 22:00:52 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 19 Feb 2020 22:00:52 +0000 From: "Richard Backman, Annabelle" To: Neil Madden , Torsten Lodderstedt CC: Anthony Nadalin , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.1: dropping password grant Thread-Index: AQHV5qSUgKi8Wj4ZTk68d/Qg5rtTLaghf4+AgAGDGoCAAAkCgIAABOGA//98KAA= Date: Wed, 19 Feb 2020 22:00:52 +0000 Message-ID: <4202C770-5A02-4B60-9E13-0419367310A7@amazon.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.8] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 22:01:00 -0000 QW4gQVMgY2FuIGRlZmluZSBjbGllbnQgSURzIHRoYXQgYXJlIHNwZWNpZmljIHRvIGEgc2Vydmlj ZSBhY2NvdW50LiBJLmUuLCBTZXJ2aWNlIEFjY291bnQgQSBoYXMgY2xpZW50IElEIDEyMzQuLi4s IFNlcnZpY2UgQWNjb3VudCBCIGhhcyBjbGllbnQgSUQgNTY3OC4uLi4gVGhpcyBhcHBlYXJzIHRv IGJlIHdoYXQgR29vZ2xlIGlzIGRvaW5nLiBGcm9tIHRoZXJlLCB0aGUgQVMgY291bGQgaW1wbGVt ZW50IHdoYXRldmVyIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gaXQgd2FudHMgdG86 IGNsaWVudCBzZWNyZXQsIG1UTFMsIEpXVCBiZWFyZXIsIGV0Yy4NCg0K4oCTDQpBbm5hYmVsbGUg QmFja21hbiAoc2hlL2hlcikNCkFXUyBJZGVudGl0eQ0KaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9p ZGVudGl0eS8NCiANCg0K77u/T24gMi8xOS8yMCwgMTo1NCBQTSwgIk9BdXRoIG9uIGJlaGFsZiBv ZiBOZWlsIE1hZGRlbiIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG5laWwu bWFkZGVuQGZvcmdlcm9jay5jb20+IHdyb3RlOg0KDQogICAgT0F1dGgyIGNsaWVudHMgYXJlIG9m dGVuIHByaXZhdGUgdG8gdGhlIEFTIC0gdGhleSBsaXZlIGluIGEgZGF0YWJhc2UgdGhhdCBvbmx5 IHRoZSBBUyBjYW4gYWNjZXNzLCBoYXZlIGF0dHJpYnV0ZXMgc3BlY2lmaWMgdG8gdGhlaXIgdXNl IGluIE9BdXRoMiwgYW5kIHNvIG9uLiBNYW55IGV4aXN0aW5nIHN5c3RlbXMgaGF2ZSBhY2Nlc3Mg Y29udHJvbHMgYmFzZWQgb24gdXNlcnMsIHJvbGVzLCBwZXJtaXNzaW9ucyBhbmQgc28gb24gYW5k IGV4cGVjdCBhbGwgdXNlcnMgYWNjZXNzaW5nIHRoZSBzeXN0ZW0gdG8gZXhpc3QgaW4gc29tZSB1 c2VyIHJlcG9zaXRvcnksIGUuZy4gTERBUCwgd2hlcmUgdGhleSBjYW4gYmUgbG9va2VkIHVwIGFu ZCBhcHByb3ByaWF0ZSBwZXJtaXNzaW9ucyBkZXRlcm1pbmVkLiBBIHNlcnZpY2UgYWNjb3VudCBj YW4gYmUgY3JlYXRlZCBpbnNpZGUgc3VjaCBhIHN5c3RlbSBhcyBpZiBpdCB3YXMgYSByZWd1bGFy IHVzZXIsIG1hbmFnZWQgdGhyb3VnaCB0aGUgbm9ybWFsIGFjY291bnQgcHJvdmlzaW9uaW5nIHRv b2xzLCBhc3NpZ25lZCBwZXJtaXNzaW9ucywgcm9sZXMsIGV0Yy4NCiAgICANCiAgICBBbm90aGVy IHJlYXNvbiBpcyB0aGF0IHNvbWV0aW1lcyBPQXV0aCBpcyBqdXN0IG9uZSBhdXRoZW50aWNhdGlv biBvcHRpb24gb3V0IG9mIG1hbnksIGFuZCBzbyBwZXJtaXNzaW9ucyBhc3NpZ25lZCB0byBzZXJ2 aWNlIGFjY291bnRzIGFyZSBwcmVmZXJyZWQgb3ZlciBzY29wZXMgYmVjYXVzZSB0aGV5IGFyZSBj b25zaXN0ZW50bHkgYXBwbGllZCBubyBtYXR0ZXIgaG93IGEgcmVxdWVzdCBpcyBhdXRoZW50aWNh dGVkLiBUaGlzIGlzIG9mdGVuIHRoZSBjYXNlIHdoZW4gT0F1dGggaGFzIGJlZW4gcmV0cm9maXR0 ZWQgdG8gYW4gZXhpc3Rpbmcgc3lzdGVtIGFuZCB0aGV5IG5lZWQgdG8gcHJlc2VydmUgY29tcGF0 aWJpbGl0eSB3aXRoIGFscmVhZHkgZGVwbG95ZWQgY2xpZW50cy4NCiAgICANCiAgICBTZWUgZS5n LiBHb29nbGUgY2xvdWQgcGxhdGZvcm0gKEdDUCk6IGh0dHBzOi8vZGV2ZWxvcGVycy5nb29nbGUu Y29tL2lkZW50aXR5L3Byb3RvY29scy9PQXV0aDJTZXJ2aWNlQWNjb3VudA0KICAgIFRoZXkgdXNl IHRoZSBKV1QgYmVhcmVyIGdyYW50IHR5cGUgZm9yIHNlcnZpY2UgYWNjb3VudCBhdXRoZW50aWNh dGlvbiBhbmQgYXNzaWduIHBlcm1pc3Npb25zIHRvIHRob3NlIHNlcnZpY2UgYWNjb3VudHMgYW5k IHR5cGljYWxseSBoYXZlIHZlcnkgYnJvYWQgc2NvcGVzLiBGb3Igc2VydmljZS10by1zZXJ2aWNl IEFQSSBjYWxscyB5b3UgdHlwaWNhbGx5IGdldCBhbiBhY2Nlc3MgdG9rZW4gd2l0aCBhIHNpbmds ZSBzY29wZSB0aGF0IGlzIGVmZmVjdGl2ZWx5IOKAnGFsbCBvZiBHQ1DigJ0gYW5kIGV2ZXJ5dGhp bmcgaXMgbWFuYWdlZCBhdCB0aGUgbGV2ZWwgb2YgcGVybWlzc2lvbnMgb24gdGhlIFJPIHNlcnZp Y2UgYWNjb3VudCBpdHNlbGYuIFRoZXkgb25seSBicmVhayBkb3duIGZpbmUtZ3JhaW5lZCBzY29w ZXMgd2hlbiB5b3UgYXJlIGRlYWxpbmcgd2l0aCB1c2VyIGRhdGEgYW5kIHdpbGwgYmUgZ2V0dGlu ZyBhbiBhY2Nlc3MgdG9rZW4gYXBwcm92ZWQgYnkgYSByZWFsIHVzZXIgKHRocm91Z2ggYSBub3Jt YWwgYXV0aCBjb2RlIGZsb3cpLg0KICAgIA0KICAgIOKAlCBOZWlsDQogICAgDQogICAgPiBPbiAx OSBGZWIgMjAyMCwgYXQgMjE6MzUsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0PiB3cm90ZToNCiAgICA+IA0KICAgID4gQ2FuIHlvdSBleHBsYWluIG1vcmUgaW4g ZGV0YWlsIHdoeSB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IHR5cGUgaXNu4oCZdCBhcHBs aWNhYmxlIGZvciB0aGUga2luZCBvZiB1c2UgY2FzZXMgeW91IG1lbnRpb25lZD8NCiAgICA+IA0K ICAgID4+IEFtIDE5LjAyLjIwMjAgdW0gMjI6MDMgc2NocmllYiBOZWlsIE1hZGRlbiA8bmVpbC5t YWRkZW5AZm9yZ2Vyb2NrLmNvbT46DQogICAgPj4gDQogICAgPj4gSSB2ZXJ5IG11Y2ggYWdyZWUg d2l0aCB0aGlzIHdpdGggcmVnYXJkcyB0byByZWFsIHVzZXJzLiANCiAgICA+PiANCiAgICA+PiBU aGUgb25lIGxlZ2l0aW1hdGUgdXNlLWNhc2UgZm9yIFJPUEMgSeKAmXZlIHNlZW4gaXMgZm9yIHNl cnZpY2UgYWNjb3VudHMgLSB3aGVyZSB5b3UgZXNzZW50aWFsbHkgd2FudCBzb21ldGhpbmcgbGlr ZSBjbGllbnRfY3JlZGVudGlhbHMgYnV0IGZvciB3aGF0ZXZlciByZWFzb24geW91IG5lZWQgdGhl IFJPIHRvIGJlIGEgc2VydmljZSB1c2VyIHJhdGhlciB0aGFuIGFuIE9BdXRoMiBjbGllbnQgKHR5 cGljYWxseSBzbyB0aGF0IHNvbWUgbG93ZXIgbGF5ZXIgb2YgdGhlIHN5c3RlbSBjYW4gc3RpbGwg cGVyZm9ybSBpdHMgcmVxdWlyZWQgcGVybWlzc2lvbiBjaGVja3MpLg0KICAgID4+IA0KICAgID4+ IFRoZXJlIGFyZSBiZXR0ZXIgZ3JhbnQgdHlwZXMgZm9yIHRoaXMgLSBlLmcuIEpXVCBiZWFyZXIg LSBidXQgdGhleSBhcmUgYSBiaXQgaGFyZGVyIHRvIGltcGxlbWVudC4gSGF2aW5nIHJlY2VudGx5 IGNvbnZlcnRlZCBzb21lIGNvZGUgZnJvbSBST1BDIHRvIEpXVCBiZWFyZXIgZm9yIGV4YWN0bHkg dGhpcyB1c2UtY2FzZSwgaXQgd2VudCBmcm9tIGEgY291cGxlIG9mIGxpbmVzIG9mIGNvZGUgdG8g dHdvIHNjcmVlbnMgb2YgY29kZS4gRm9yIHNlcnZpY2UgdG8gc2VydmljZSBBUEkgY2FsbHMgd2l0 aGluIGEgZGF0YWNlbnRlciBJ4oCZbSBub3QgY29udmluY2VkIHRoaXMgcmVzdWx0ZWQgaW4gYSBt YXRlcmlhbCBpbmNyZWFzZSBpbiBzZWN1cml0eSBmb3IgdGhlIGFkZGVkIGNvbXBsZXhpdHkuDQog ICAgPj4gDQogICAgPj4g4oCUIE5laWwNCiAgICA+PiANCiAgICA+Pj4gT24gMTggRmViIDIwMjAs IGF0IDIxOjU3LCBIYW5zIFphbmRiZWx0IDxoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4gd3Jv dGU6DQogICAgPj4+IA0KICAgID4+PiBJIHdvdWxkIGFsc28gc2VyaW91c2x5IGxvb2sgYXQgdGhl IG9yaWdpbmFsIG1vdGl2YXRpb24gYmVoaW5kIFJPUEM6IEkga25vdyBpdCBoYXMgYmVlbiBkZXBs b3llZCBhbmQgaXMgdXNlZCBpbiBxdWl0ZSBhIGxvdCBvZiBwbGFjZXMgYnV0IEkgaGF2ZSBuZXZl ciBhY3R1YWxseSBjb21lIGFjcm9zcyBhIHVzZSBjYXNlIHdoZXJlIGl0IGlzIHVzZWQgZm9yIG1p Z3JhdGlvbiBwdXJwb3NlcyBhbmQgdGhlIG1pZ3JhdGlvbiBpcyBhY3R1YWxseSBleGVjdXRlZCAo SSBrbm93IHRoYXQgaXMgc3RhdGlzdGljYWxseSBub3QgYSB2ZXJ5IHN0cm9uZyBhcmd1bWVudCBi dXQgSSBjaGFsbGVuZ2Ugb3RoZXJzIHRvIGNvbWUgdXAgd2l0aCBvbmUuLi4pDQogICAgPj4+IElu IHJlYWxpdHkgaXQgdHVybmVkIG91dCBqdXN0IHRvIGJlIGEgb25lIG9mZiB0aGF0IHBlb3BsZSB1 c2VkIGFzIGFuIGVhc3kgd2F5IG91dCB0byBzdGljayB0byBhbiBhbnRpLXBhdHRlcm4gYW5kIHN0 aWxsIGNsYWltIHRvIGRvIE9BdXRoIDIuMC4gSXQgaXMgcGxhaW4gd3JvbmcsIGl0IGlzIG5vdCBP QXV0aCBhbmQgd2UgbmVlZCB0byBnZXQgcmlkIG9mIGl0Lg0KICAgID4+PiANCiAgICA+Pj4gSGFu cy4NCiAgICA+Pj4gDQogICAgPj4+IE9uIFR1ZSwgRmViIDE4LCAyMDIwIGF0IDEwOjQ0IFBNIEFh cm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPiB3cm90ZToNCiAgICA+Pj4gQWdyZWVkLiBQ bHVzLCB0aGUgU2VjdXJpdHkgQkNQIGlzIGFscmVhZHkgZWZmZWN0aXZlbHkgYWN0aW5nIGFzIGEg Z3JhY2UgcGVyaW9kIHNpbmNlIGl0IGN1cnJlbnRseSBzYXlzIHRoZSBwYXNzd29yZCBncmFudCBN VVNUIE5PVCBiZSB1c2VkLCBzbyBpbiB0aGUgT0F1dGggMi4wIHdvcmxkIHRoYXQncyBhbHJlYWR5 IGEgcHJldHR5IHN0cm9uZyBzaWduYWwuDQogICAgPj4+IA0KICAgID4+PiBBYXJvbg0KICAgID4+ PiANCiAgICA+Pj4gDQogICAgPj4+IA0KICAgID4+PiBPbiBUdWUsIEZlYiAxOCwgMjAyMCBhdCA0 OjE2IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4gd3JvdGU6DQogICAgPj4+IFRo ZXJlIGlzIG5vIG5lZWQgZm9yIGEgZ3JhY2UgcGVyaW9kLiBQZW9wbGUgdXNpbmcgT0F1dGggMi4w IGNhbiBzdGlsbCBkbyBPQXV0aCAyLjAuIFBlb3BsZSB1c2luZyBPQXV0aCAyLjEgd2lsbCBkbyBP QXV0aCAyLjEuIA0KICAgID4+PiANCiAgICA+Pj4g4oCUIEp1c3Rpbg0KICAgID4+PiANCiAgICA+ Pj4+PiBPbiBGZWIgMTgsIDIwMjAsIGF0IDM6NTQgUE0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5h ZD00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4+Pj4gDQogICAg Pj4+PiBJIHdvdWxkIHN1Z2dlc3QgYSBTSE9VTEQgTk9UIGluc3RlYWQgb2YgTVVTVCwgdGhlcmUg YXJlIHN0aWxsIHNpdGVzIHVzaW5nIHRoaXMgYW5kIGEgZ3JhY2UgcGVyaW9kIHNob3VsZCBiZSBw cm92aWRlZCBiZWZvcmUgYSBNVVNUIGlzIHB1c2hlZCBvdXQgYXMgdGhlcmUgYXJlIHZhbGlkIHVz ZSBjYXNlcyBvdXQgdGhlcmUgc3RpbGwuDQogICAgPj4+PiANCiAgICA+Pj4+IEZyb206IE9BdXRo IDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGljayBIYXJkdA0KICAgID4+ Pj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTgsIDIwMjAgMTI6MzcgUE0NCiAgICA+Pj4+IFRv OiBvYXV0aEBpZXRmLm9yZw0KICAgID4+Pj4gU3ViamVjdDogW0VYVEVSTkFMXSBbT0FVVEgtV0dd IE9BdXRoIDIuMTogZHJvcHBpbmcgcGFzc3dvcmQgZ3JhbnQNCiAgICA+Pj4+IA0KICAgID4+Pj4g SGV5IExpc3QgDQogICAgPj4+PiANCiAgICA+Pj4+IChPbmNlIGFnYWluIHVzaW5nIHRoZSBPQXV0 aCAyLjEgbmFtZSBhcyBhIHBsYWNlaG9sZGVyIGZvciB0aGUgZG9jIHRoYXQgQWFyb24sIFRvcnN0 ZW4sIGFuZCBJIGFyZSB3b3JraW5nIG9uKQ0KICAgID4+Pj4gDQogICAgPj4+PiBJbiB0aGUgc2Vj dXJpdHkgdG9waWNzIGRvYw0KICAgID4+Pj4gDQogICAgPj4+PiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTQjc2VjdGlvbi0yLjQN CiAgICA+Pj4+IA0KICAgID4+Pj4gVGhlIHBhc3N3b3JkIGdyYW50IE1VU1Qgbm90IGJlIHVzZWQu DQogICAgPj4+PiANCiAgICA+Pj4+IFNvbWUgYmFja2dyb3VuZCBmb3IgdGhvc2UgaW50ZXJlc3Rl ZC4gSSBhZGRlZCB0aGlzIGdyYW50IGludG8gT0F1dGggMi4wIHRvIGFsbG93IGFwcGxpY2F0aW9u cyB0aGF0IGhhZCBiZWVuIHByb3ZpZGVkIHBhc3N3b3JkIHRvIG1pZ3JhdGUuIEV2ZW4gd2l0aCB0 aGUgY2F2ZWF0cyBpbiBPQXV0aCAyLjAsIGltcGxlbWVudG9ycyBkZWNpZGUgdGhleSB3YW50IHRv IHByb21wdCB0aGUgdXNlciB0byBlbnRlciB0aGVpciBjcmVkZW50aWFscywgdGhlIGFudGktcGF0 dGVybiBPQXV0aCB3YXMgY3JlYXRlZCB0byBlbGltaW5hdGUuIA0KICAgID4+Pj4gDQogICAgPj4+ PiANCiAgICA+Pj4+IERvZXMgYW55b25lIGhhdmUgY29uY2VybnMgd2l0aCBkcm9wcGluZyB0aGUg cGFzc3dvcmQgZ3JhbnQgZnJvbSB0aGUgT0F1dGggMi4xIGRvY3VtZW50IHNvIHRoYXQgZGV2ZWxv cGVycyBkb24ndCB1c2UgaXQ/DQogICAgPj4+PiANCiAgICA+Pj4+IC9EaWNrDQogICAgPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4g T0F1dGggbWFpbGluZyBsaXN0DQogICAgPj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4+PiANCiAgICA+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ Pj4gT0F1dGggbWFpbGluZyBsaXN0DQogICAgPj4+IE9BdXRoQGlldGYub3JnDQogICAgPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICA+Pj4gLS0gDQog ICAgPj4+IC0tLS0NCiAgICA+Pj4gQWFyb24gUGFyZWNraQ0KICAgID4+PiBhYXJvbnBhcmVja2ku Y29tDQogICAgPj4+IEBhYXJvbnBrDQogICAgPj4+IA0KICAgID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+PiBPQXV0aCBtYWlsaW5nIGxp c3QNCiAgICA+Pj4gT0F1dGhAaWV0Zi5vcmcNCiAgICA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4+PiANCiAgICA+Pj4gDQogICAgPj4+IC0tIA0K ICAgID4+PiBoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldQ0KICAgID4+PiBabWFydFpvbmUgSUFN IC0gd3d3LnptYXJ0em9uZS5ldQ0KICAgID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgID4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICA+Pj4g T0F1dGhAaWV0Zi5vcmcNCiAgICA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KICAgID4+IA0KICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgPj4gT0F1dGggbWFpbGluZyBsaXN0DQogICAgPj4gT0F1 dGhAaWV0Zi5vcmcNCiAgICA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICBPQXV0aEBpZXRmLm9yZw0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICANCg0K From nobody Wed Feb 19 14:02:28 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFDB120860 for ; Wed, 19 Feb 2020 14:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 3gl5URRNv3VQ for ; Wed, 19 Feb 2020 14:02:22 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C5512083D for ; Wed, 19 Feb 2020 14:02:21 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q23so2042117ljm.4 for ; Wed, 19 Feb 2020 14:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A5pMpFscL2GG6xySwD8uR2x3LBbx7lXQfcyjBxws8uU=; b=o3AGDkUnH8+6B5q3EmmW/eHeic1hTek++arv3jTA7Ewh2Aq65khYSt06brKbQXmYBw lqFU3FxSVjLZBEGPVhisRPUsN+JBCls0mol+ZTrQKGZlg+NjjEnXKpxgJhQU04R5PlJY d1JLX0K07uhfiPLfO2xljL+td6R7jan2GmcaObiS2KiMP6+RXM7Bz2APDyZdZC+ZmzWJ mxHYv7vBSD5Lv1SZ5b2UnEfVAlhBYdB01xKlFz4Z8rXQTPnOd2gwQyVfrsEpQUpBEwlc udmeLYFSI/5gtAMltxis26YCvrhdVVLd0LmNlvisEBHNUfoEi6IH8MM3kKy6dr432mWP pV8A== 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=A5pMpFscL2GG6xySwD8uR2x3LBbx7lXQfcyjBxws8uU=; b=fO6w6KBoDEApepi51TRI6YGC5oQbrGoQYV19VUP90EzS4Hx92a9ysL3DV/hja24uBZ lR0zQp0245Y4YzLRLlevJApfsWmppRkFwkI//q93XrrEaA6LvWDpp4J197IeGJ+Ssw6S OWdcbKIo6/2/t8A00I90A7WXRo/wlCXU1vpheDoLLiD95Xx5cl5zAq4snuzfRdKO86Ez sa+hFjQTqhXMwS2JPj/nz0GFPz+f59fcSAMk73xG4vAemwFUv7rzskrB/pk/3bCPnffF csd/do3yyit1ppHer+orane1aGQHFP1JDwVHsBatsj+EnqFuHyKAQnwFknZpG2ly8CtU vV9g== X-Gm-Message-State: APjAAAVZAi+gA44u0nbxwYM4uHNJiKwy8fmPMQIUbPMMgy71Gv6i18Wg 94juSu83wB1N7mmfFKxPPnpEQ0Q5htwHntz/PVF2yej8 X-Google-Smtp-Source: APXvYqwAksb/cHZ18HbVGiM6S3IvFaeUQJFaTSDFNgNw+HilgUNh7jC3kUejUhiDBeNX+5plFSDnZNXrvqg9QKLnEz0= X-Received: by 2002:a2e:808a:: with SMTP id i10mr16868651ljg.151.1582149739974; Wed, 19 Feb 2020 14:02:19 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> In-Reply-To: From: Dick Hardt Date: Wed, 19 Feb 2020 14:01:53 -0800 Message-ID: To: Neil Madden Cc: Torsten Lodderstedt , Anthony Nadalin , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003b981d059ef4f1c4" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 22:02:26 -0000 --0000000000003b981d059ef4f1c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Neil: are you advocating that password grant be preserved in 2.1? Or do you think that service account developers know enough about what they are doing to follow what is in 6749? =E1=90=A7 On Wed, Feb 19, 2020 at 1:52 PM Neil Madden wrote: > OAuth2 clients are often private to the AS - they live in a database that > only the AS can access, have attributes specific to their use in OAuth2, > and so on. Many existing systems have access controls based on users, > roles, permissions and so on and expect all users accessing the system to > exist in some user repository, e.g. LDAP, where they can be looked up and > appropriate permissions determined. A service account can be created insi= de > such a system as if it was a regular user, managed through the normal > account provisioning tools, assigned permissions, roles, etc. > > Another reason is that sometimes OAuth is just one authentication option > out of many, and so permissions assigned to service accounts are preferre= d > over scopes because they are consistently applied no matter how a request > is authenticated. This is often the case when OAuth has been retrofitted = to > an existing system and they need to preserve compatibility with already > deployed clients. > > See e.g. Google cloud platform (GCP): > https://developers.google.com/identity/protocols/OAuth2ServiceAccount > They use the JWT bearer grant type for service account authentication and > assign permissions to those service accounts and typically have very broa= d > scopes. For service-to-service API calls you typically get an access toke= n > with a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D and = everything is > managed at the level of permissions on the RO service account itself. The= y > only break down fine-grained scopes when you are dealing with user data a= nd > will be getting an access token approved by a real user (through a normal > auth code flow). > > =E2=80=94 Neil > > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt > wrote: > > > > Can you explain more in detail why the client credentials grant type > isn=E2=80=99t applicable for the kind of use cases you mentioned? > > > >> Am 19.02.2020 um 22:03 schrieb Neil Madden = : > >> > >> =EF=BB=BFI very much agree with this with regards to real users. > >> > >> The one legitimate use-case for ROPC I=E2=80=99ve seen is for service = accounts > - where you essentially want something like client_credentials but for > whatever reason you need the RO to be a service user rather than an OAuth= 2 > client (typically so that some lower layer of the system can still perfor= m > its required permission checks). > >> > >> There are better grant types for this - e.g. JWT bearer - but they are > a bit harder to implement. Having recently converted some code from ROPC = to > JWT bearer for exactly this use-case, it went from a couple of lines of > code to two screens of code. For service to service API calls within a > datacenter I=E2=80=99m not convinced this resulted in a material increase= in > security for the added complexity. > >> > >> =E2=80=94 Neil > >> > >>> On 18 Feb 2020, at 21:57, Hans Zandbelt > wrote: > >>> > >>> I would also seriously look at the original motivation behind ROPC: I > know it has been deployed and is used in quite a lot of places but I have > never actually come across a use case where it is used for migration > purposes and the migration is actually executed (I know that is > statistically not a very strong argument but I challenge others to come u= p > with one...) > >>> In reality it turned out just to be a one off that people used as an > easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. > It is plain wrong, it is not OAuth and we need to get rid of it. > >>> > >>> Hans. > >>> > >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki > wrote: > >>> Agreed. Plus, the Security BCP is already effectively acting as a > grace period since it currently says the password grant MUST NOT be used, > so in the OAuth 2.0 world that's already a pretty strong signal. > >>> > >>> Aaron > >>> > >>> > >>> > >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote= : > >>> There is no need for a grace period. People using OAuth 2.0 can still > do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. > >>> > >>> =E2=80=94 Justin > >>> > >>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote: > >>>> > >>>> I would suggest a SHOULD NOT instead of MUST, there are still sites > using this and a grace period should be provided before a MUST is pushed > out as there are valid use cases out there still. > >>>> > >>>> From: OAuth On Behalf Of Dick Hardt > >>>> Sent: Tuesday, February 18, 2020 12:37 PM > >>>> To: oauth@ietf.org > >>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > >>>> > >>>> Hey List > >>>> > >>>> (Once again using the OAuth 2.1 name as a placeholder for the doc > that Aaron, Torsten, and I are working on) > >>>> > >>>> In the security topics doc > >>>> > >>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > >>>> > >>>> The password grant MUST not be used. > >>>> > >>>> Some background for those interested. I added this grant into OAuth > 2.0 to allow applications that had been provided password to migrate. Eve= n > with the caveats in OAuth 2.0, implementors decide they want to prompt th= e > user to enter their credentials, the anti-pattern OAuth was created to > eliminate. > >>>> > >>>> > >>>> Does anyone have concerns with dropping the password grant from the > OAuth 2.1 document so that developers don't use it? > >>>> > >>>> /Dick > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> -- > >>> ---- > >>> Aaron Parecki > >>> aaronparecki.com > >>> @aaronpk > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> -- > >>> hans.zandbelt@zmartzone.eu > >>> ZmartZone IAM - www.zmartzone.eu > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003b981d059ef4f1c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Neil: are you advocating that password grant be preserved = in 2.1? Or do you think that service account developers know enough about w= hat they are doing to follow what is in 6749?
3D""=E1=90=A7

On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@forgerock.com> wrote:
OAuth2 clients are often privat= e to the AS - they live in a database that only the AS can access, have att= ributes specific to their use in OAuth2, and so on. Many existing systems h= ave access controls based on users, roles, permissions and so on and expect= all users accessing the system to exist in some user repository, e.g. LDAP= , where they can be looked up and appropriate permissions determined. A ser= vice account can be created inside such a system as if it was a regular use= r, managed through the normal account provisioning tools, assigned permissi= ons, roles, etc.

Another reason is that sometimes OAuth is just one authentication option ou= t of many, and so permissions assigned to service accounts are preferred ov= er scopes because they are consistently applied no matter how a request is = authenticated. This is often the case when OAuth has been retrofitted to an= existing system and they need to preserve compatibility with already deplo= yed clients.

See e.g. Google cloud platform (GCP): https://developers.google.com/identity/protocols/OAuth2ServiceAccoun= t
They use the JWT bearer grant type for service account authentication and a= ssign permissions to those service accounts and typically have very broad s= copes. For service-to-service API calls you typically get an access token w= ith a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D and eve= rything is managed at the level of permissions on the RO service account it= self. They only break down fine-grained scopes when you are dealing with us= er data and will be getting an access token approved by a real user (throug= h a normal auth code flow).

=E2=80=94 Neil

> On 19 Feb 2020, at 21:35, Torsten Lodderstedt <torsten@lodderstedt.net> wr= ote:
>
> Can you explain more in detail why the client credentials grant type i= sn=E2=80=99t applicable for the kind of use cases you mentioned?
>
>> Am 19.02.2020 um 22:03 schrieb Neil Madden <neil.madden@forgerock.com&g= t;:
>>
>> =EF=BB=BFI very much agree with this with regards to real users. <= br> >>
>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for serv= ice accounts - where you essentially want something like client_credentials= but for whatever reason you need the RO to be a service user rather than a= n OAuth2 client (typically so that some lower layer of the system can still= perform its required permission checks).
>>
>> There are better grant types for this - e.g. JWT bearer - but they= are a bit harder to implement. Having recently converted some code from RO= PC to JWT bearer for exactly this use-case, it went from a couple of lines = of code to two screens of code. For service to service API calls within a d= atacenter I=E2=80=99m not convinced this resulted in a material increase in= security for the added complexity.
>>
>> =E2=80=94 Neil
>>
>>> On 18 Feb 2020, at 21:57, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
>>>
>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places but = I have never actually come across a use case where it is used for migration= purposes and the migration is actually executed (I know that is statistica= lly not a very strong argument but I challenge others to come up with one..= .)
>>> In reality it turned out just to be a one off that people used= as an easy way out to stick to an anti-pattern and still claim to do OAuth= 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
>>>
>>> Hans.
>>>
>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <aaron@parecki.com> wrote= :
>>> Agreed. Plus, the Security BCP is already effectively acting a= s a grace period since it currently says the password grant MUST NOT be use= d, so in the OAuth 2.0 world that's already a pretty strong signal.
>>>
>>> Aaron
>>>
>>>
>>>
>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrote:
>>> There is no need for a grace period. People using OAuth 2.0 ca= n still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>>>
>>> =E2=80=94 Justin
>>>
>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <tonyn= ad=3D40= microsoft.com@dmarc.ietf.org> wrote:
>>>>
>>>> I would suggest a SHOULD NOT instead of MUST, there are st= ill sites using this and a grace period should be provided before a MUST is= pushed out as there are valid use cases out there still.
>>>>
>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt >>>> Sent: Tuesday, February 18, 2020 12:37 PM
>>>> To: oa= uth@ietf.org
>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping passwor= d grant
>>>>
>>>> Hey List
>>>>
>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on)
>>>>
>>>> In the security topics doc
>>>>
>>>> https://= tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
>>>>
>>>> The password grant MUST not be used.
>>>>
>>>> Some background for those interested. I added this grant i= nto OAuth 2.0 to allow applications that had been provided password to migr= ate. Even with the caveats in OAuth 2.0, implementors decide they want to p= rompt the user to enter their credentials, the anti-pattern OAuth was creat= ed to eliminate.
>>>>
>>>>
>>>> Does anyone have concerns with dropping the password grant= from the OAuth 2.1 document so that developers don't use it?
>>>>
>>>> /Dick
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>> --
>>> ----
>>> Aaron Parecki
>>> aaronparecki.com
>>> @aaronpk
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>>
>>>
>>> --
>>> hans.zandbelt@zmartzone.eu
>>> ZmartZone IAM - www.zmartzone.eu
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>
>> _______________________________________________
>> 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
--0000000000003b981d059ef4f1c4-- From nobody Wed Feb 19 14:42:01 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AC7120824 for ; Wed, 19 Feb 2020 14:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0_DP2amraDqz for ; Wed, 19 Feb 2020 14:41:55 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5786120821 for ; Wed, 19 Feb 2020 14:41:55 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id t3so2436686wru.7 for ; Wed, 19 Feb 2020 14:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Dggm7vZgh7hGuFK/nKNrfJcRoPO+SvNn6GO2rMy1FuY=; b=QyaF9pobQQXZ8E8ODkroA0D/MpomCy06bSJa6pr//lg+LyEwlSwBBIK4vi98Q1moPg oK2ryVARrNJ1i/uBxh81hpnlYSllHQQKrAoj7d/6sl04+LilEgcVApueplAEbyV6nsoR t2jrR1O8z897gz5o8Gx5b7UIHyMH9n52XoC7E= 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=Dggm7vZgh7hGuFK/nKNrfJcRoPO+SvNn6GO2rMy1FuY=; b=FxcdDoleKNOkVZPRMN/57OKyP9VlZ6KO8PrNLcUgPvDYEyVBhrI/0ZwhYGLOqd016s 4QyK3JADL9GJxpTTTxD9lCghdn8HYLWiKWnh9oHlu1FcTyUmT/sEuIap+RnZvHD6/654 nuYuEXVNR7P+ZKRRko+dZ9juFE0Ms7dy54KcMoKLeUJoq/sDtXAIm8N/CKJGHEtUQIQW GVGWw6u+E8/jIFD3K1QIL21zrbLhBQq6Y2RxambbL0jbHbAV7ncIBgOLbmYFxQy7FB/H LSt6wOqIXNHRjPY4gIbD3lsYyJU9y5j2lpW+kdP0EFUm1rTgPjxB6VP++xzCaZsp4pL3 sIHw== X-Gm-Message-State: APjAAAU1z8ZSY/K4VkgNJS/aeFYBnM0j7zVo71Xt3YlNsdE0m8rhO6VF jJPn3yIUdaSNOy7QU50SS5dpaQ== X-Google-Smtp-Source: APXvYqzK0261bV9THl88YhxcQA29OxTng/yvOJUkExFog92v6Mu0CzesUmoKfMWzCUuGReFHugFQdg== X-Received: by 2002:adf:a453:: with SMTP id e19mr37284434wra.305.1582152113787; Wed, 19 Feb 2020 14:41:53 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id f12sm1692033wmj.10.2020.02.19.14.41.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2020 14:41:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: Date: Wed, 19 Feb 2020 22:41:52 +0000 Cc: Torsten Lodderstedt , Anthony Nadalin , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> To: Dick Hardt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 22:41:59 -0000 I have a feeling that if we had more concise JWT libraries and command = line tools, where using the JWT Bearer grant became a one-liner again = then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. > On 19 Feb 2020, at 22:01, Dick Hardt wrote: >=20 > Neil: are you advocating that password grant be preserved in 2.1? Or = do you think that service account developers know enough about what they = are doing to follow what is in 6749? > =E1=90=A7 >=20 > On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: > OAuth2 clients are often private to the AS - they live in a database = that only the AS can access, have attributes specific to their use in = OAuth2, and so on. Many existing systems have access controls based on = users, roles, permissions and so on and expect all users accessing the = system to exist in some user repository, e.g. LDAP, where they can be = looked up and appropriate permissions determined. A service account can = be created inside such a system as if it was a regular user, managed = through the normal account provisioning tools, assigned permissions, = roles, etc. >=20 > Another reason is that sometimes OAuth is just one authentication = option out of many, and so permissions assigned to service accounts are = preferred over scopes because they are consistently applied no matter = how a request is authenticated. This is often the case when OAuth has = been retrofitted to an existing system and they need to preserve = compatibility with already deployed clients. >=20 > See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount > They use the JWT bearer grant type for service account authentication = and assign permissions to those service accounts and typically have very = broad scopes. For service-to-service API calls you typically get an = access token with a single scope that is effectively =E2=80=9Call of = GCP=E2=80=9D and everything is managed at the level of permissions on = the RO service account itself. They only break down fine-grained scopes = when you are dealing with user data and will be getting an access token = approved by a real user (through a normal auth code flow). >=20 > =E2=80=94 Neil >=20 > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: > >=20 > > Can you explain more in detail why the client credentials grant type = isn=E2=80=99t applicable for the kind of use cases you mentioned? > >=20 > >> Am 19.02.2020 um 22:03 schrieb Neil Madden = : > >>=20 > >> =EF=BB=BFI very much agree with this with regards to real users.=20 > >>=20 > >> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). > >>=20 > >> There are better grant types for this - e.g. JWT bearer - but they = are a bit harder to implement. Having recently converted some code from = ROPC to JWT bearer for exactly this use-case, it went from a couple of = lines of code to two screens of code. For service to service API calls = within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. > >>=20 > >> =E2=80=94 Neil > >>=20 > >>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: > >>>=20 > >>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) > >>> In reality it turned out just to be a one off that people used as = an easy way out to stick to an anti-pattern and still claim to do OAuth = 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. > >>>=20 > >>> Hans. > >>>=20 > >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: > >>> Agreed. Plus, the Security BCP is already effectively acting as a = grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal. > >>>=20 > >>> Aaron > >>>=20 > >>>=20 > >>>=20 > >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: > >>> There is no need for a grace period. People using OAuth 2.0 can = still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 > >>>=20 > >>> =E2=80=94 Justin > >>>=20 > >>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: > >>>>=20 > >>>> I would suggest a SHOULD NOT instead of MUST, there are still = sites using this and a grace period should be provided before a MUST is = pushed out as there are valid use cases out there still. > >>>>=20 > >>>> From: OAuth On Behalf Of Dick Hardt > >>>> Sent: Tuesday, February 18, 2020 12:37 PM > >>>> To: oauth@ietf.org > >>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > >>>>=20 > >>>> Hey List=20 > >>>>=20 > >>>> (Once again using the OAuth 2.1 name as a placeholder for the doc = that Aaron, Torsten, and I are working on) > >>>>=20 > >>>> In the security topics doc > >>>>=20 > >>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 > >>>>=20 > >>>> The password grant MUST not be used. > >>>>=20 > >>>> Some background for those interested. I added this grant into = OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 > >>>>=20 > >>>>=20 > >>>> Does anyone have concerns with dropping the password grant from = the OAuth 2.1 document so that developers don't use it? > >>>>=20 > >>>> /Dick > >>>> _______________________________________________ > >>>> 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 > >>> ---- > >>> Aaron Parecki > >>> aaronparecki.com > >>> @aaronpk > >>>=20 > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>>=20 > >>>=20 > >>> --=20 > >>> hans.zandbelt@zmartzone.eu > >>> ZmartZone IAM - www.zmartzone.eu > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Feb 19 14:57:16 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BBE120825; Wed, 19 Feb 2020 14:57:12 -0800 (PST) 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 5fenaWSH7gKx; Wed, 19 Feb 2020 14:57:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E370120820; Wed, 19 Feb 2020 14:57:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E7187F40713; Wed, 19 Feb 2020 14:57:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200219225705.E7187F40713@rfc-editor.org> Date: Wed, 19 Feb 2020 14:57:05 -0800 (PST) Archived-At: Subject: [OAUTH-WG] =?utf-8?q?BCP_225=2C_RFC_8725_on_JSON_Web_Token_Best_?= =?utf-8?q?Current_Practices?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 22:57:13 -0000 A new Request for Comments is now available in online RFC libraries. BCP 225 RFC 8725 Title: JSON Web Token Best Current Practices Author: Y. Sheffer, D. Hardt, M. Jones Status: Best Current Practice Stream: IETF Date: February 2020 Mailbox: yaronf.ietf@gmail.com, dick.hardt@gmail.com, mbj@microsoft.com Pages: 13 Updates: RFC 7519 See Also: BCP 225 I-D Tag: draft-ietf-oauth-jwt-bcp-07.txt URL: https://www.rfc-editor.org/info/rfc8725 DOI: 10.17487/RFC8725 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. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This document is a product of the Web Authorization Protocol Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Feb 19 15:07:29 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F1E120145 for ; Wed, 19 Feb 2020 15:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDk9V7j2gabt for ; Wed, 19 Feb 2020 15:07:24 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650126.outbound.protection.outlook.com [40.107.65.126]) (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 A8DB5120052 for ; Wed, 19 Feb 2020 15:07:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f3rEg9IIWKSICfj8eDrPfjiLeSIp5Wlv5mmzoSGpPPHLKXNU8MjCICKyFnp3ry+ULwg1u1t8idvgVHOVMnsIYdrxBq/rtY0dgiVpDeYSiweKaoroVZZhLOJaY8xaiQDvPMzol/5O/daUrLPCQEjhnawvf3qw6dJGTXdSGyktVZYtlYQwaMd1i4RB45UNnmb/aVOIgvi/oqrpu/hikVBSusDLqvv8Pg88Zi0ZsExyXX6zBac0DlyAFz8SgE6PaeIgbd8O1+kALV5vsE58tug4V4z1pg16GXL/EGc9ngHtAQtYHhr3yjF3cZimu9bxr2A/+QmmXt4k5113ukiyO0NefA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ShxaeR1DMmRhoHE/bljJ8tF7RsBsenmCuEpHy0v5rh0=; b=k8GeBMXs7v3WLQdW8cqnIgpLKxHRPSBgGSSkLvtR8BJVEO8SfQfIuKBRMV1iG6uFpSiezbQ/wNLYNmNYNeAo0AQrNCn5Kn1uG7VKkXjPcs7XeyjbzwkmXQMdb7U5lBbLl42p8z67yalYfeMOZ10pZUIiG6Pge4qgrDN7qYIDm/EjkpZkn754YOMU75zKSVm7hHrTKadxe31T2CPsqAXrclp+ck1eA/S2luM5Z/duOgXKvtsTwKDJLgO6jF3SHHRx1IlMWBc4LlLj9L5kgKt7yZdgnkKGxmKse9FU27kl364VVyafMs5Z8ul/pH/TsafnS1uVLQoxi+5Gac2x9HuA4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ShxaeR1DMmRhoHE/bljJ8tF7RsBsenmCuEpHy0v5rh0=; b=BwdFlmiLMouhYblGRh+bBwo04X1SthSoMmU4kwHlq/FwTZlGnDwGlk7tsOduY5vdtJzen7obASCpL7kaXuHYshhRMv8N0e08KIIb/e9LwQm86Y1eC1S1Qwy7yBcG9oYkFZLtm/GXJo7mAAw/mFk/QBGBpnVfqzlrDLerz7MvaMM= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (20.180.16.71) by CH2PR00MB0794.namprd00.prod.outlook.com (10.186.139.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2787.0; Wed, 19 Feb 2020 23:07:15 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::d59d:b91e:2881:7949]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::d59d:b91e:2881:7949%9]) with mapi id 15.20.2791.000; Wed, 19 Feb 2020 23:07:15 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JSON Web Token Best Current Practices is now RFC 8725 and BCP 225 Thread-Index: AdXh3kerUbblBe/NT3OcwcZBoSQuOw== Date: Wed, 19 Feb 2020 23:07:15 +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_ActionId=536dcd2c-24da-4de2-80d1-00004d332cee; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-12T19:51:45Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.83.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2e96cea2-68eb-42b5-5335-08d7b590762c x-ms-traffictypediagnostic: CH2PR00MB0794: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0318501FAE x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(199004)(189003)(81156014)(8936002)(81166006)(8676002)(71200400001)(33656002)(7696005)(6916009)(86362001)(316002)(966005)(478600001)(21615005)(10290500003)(8990500004)(55016002)(9686003)(5660300002)(52536014)(64756008)(66446008)(26005)(186003)(2906002)(76116006)(66946007)(6506007)(66476007)(66556008)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0794; H:CH2PR00MB0679.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ylQOdqNuYyMcmO5lmJlwNnXMaxVPrle2pAmRPpgUWBJqf1AkpBP0+nNpVxJxikzqii9muIEDVm9SbcE8mDSGgR1U3DMd3a9sTm+XCNXFgS3PH671B1Ts4LS635YL+G03XWel42gzxuzCI6qk0EVBy4luftZzx1mSCnMtxMNQOW8QxrM1WvbR4UDRKxjh35bDYE3rFlsUP55K3S2TMQooa0aQ+5MpteTd+nydL8ZG+Ki4JkB7pfVkIIns+kRFo3PiJgArcswb9EkNssNPZ1Zogl7QwpdtK/1NK2LEYtEO0htRmtqZnI1VFPyy1OYuoUFewl/gREMAe8L8knoin2r/ojWoOG/NNh5oe70rL9oyIYdrlDl05ZE6G0Ll6eXaRgcPRtMMjuXcv0G+Kd1kpo1LDGD7dWOHebyuNcBtH9aKBL+kjg8r9nHX3JAijYeZanCjuq1zlAVDK/5zJy0Ivn9JavdCnKLka72VcyB+FRylHOJIi5bU3kfEeDgBdVuO7+5vODVrB8nqLhekmBeTR15y5I4hqFxaInvVYs5eMz6DpVEu+x+hHdB8r0vkjZEtzQ4buPjoQdfPzIc/c39CFuPVryFIsB8ZdMXRCu9dihWTihcPedxd67Zog1uTiR992OZ5VUZwlA6GvCpmCgF1MNCzKw== x-ms-exchange-antispam-messagedata: j6kl9S1/TNspYecbfWVOQCXzsTB+3k/nbJiPjXfIX3jNWHicLLaL7+BFE7WU92a1KKeHHsTpX5ci1RQNRhRNv4ZIDH80H7Oy1+dcYwcTAEgMT4n9NQrH9PVbspznhEDlHXXOF3zS2CAxhtcDl0CNnw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679CAD5DE171630CDFA8AEEF5100CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e96cea2-68eb-42b5-5335-08d7b590762c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 23:07:15.8330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EeyLRCstDSGdOkabqgxQ6BSWsSlOW268quf02eJsOujJGOeg7eC7iAQzgpJaIelwE+Xj+dz40VEmvVTxgFkuvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0794 Archived-At: Subject: [OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 23:07:27 -0000 --_000_CH2PR00MB0679CAD5DE171630CDFA8AEEF5100CH2PR00MB0679namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth 2.0 Token Exchange specification is now RFC 8725 and BCP 225. The abstract of the specification is: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security token= s that contain a set of claims that can be signed and/or encrypted. JWTs ar= e being widely used and deployed as a simple security token format in numer= ous protocols and applications, both in the area of digital identity and in= other application areas. This Best Current Practices document updates RFC = 7519 to provide actionable guidance leading to secure implementation and de= ployment of JWTs. The JSON Web Token (JWT) specification [RFC 7519] was approved in May 2015, a= lmost five years ago, and has been in production use since at least 2013. = This Best Current Practices specificat= ion contains a compendium of lessons learned from real JWT deployments and = implementations over that period. It describes pitfalls and how to avoid t= hem as well as new recommended practices that enable proactively avoiding p= roblems that could otherwise arise. Importantly, the BCP introduces no bre= aking changes to the JWT specification and does not require changes to exis= ting deployments. The BCP came about as JWTs were starting to be used in new families of prot= ocols and applications, both in the IETF and by others. For instance, JWTs= are being used by the IETF STIR working group to enable verification of th= e calling party's authorization to use a particular telephone number for an= incoming call, providing verified Caller ID to help combat fraudulent and unwanted telephone calls. The advice i= n the BCP can be used by new JWT profiles and applications to take advantag= e of what's been learned since we created the JSON Web Token (JWT) specific= ation over a half decade ago. -- Mike P.S. This notice was also posted at https://self-issued.info/?p=3D2052 and= as @selfissued. --_000_CH2PR00MB0679CAD5DE171630CDFA8AEEF5100CH2PR00MB0679namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth 2.0 Token Exchange specification  is = now RFC 8725 and BCP 225= .  The abstract of the specification is:

 

JSON Web Tokens, also kno= wn as JWTs, are URL-safe JSON-based security tokens that contain a set of c= laims that can be signed and/or encrypted. JWTs are being widely used and d= eployed as a simple security token format in numerous protocols and applications, both in the area of digital identi= ty and in other application areas. This Best Current Practices document upd= ates RFC 7519 to provide actionable guidance leading to secure implementati= on and deployment of JWTs.

 

The JSON Web Token (JWT) specification [RFC 7519] was approved in May 2015, al= most five years ago, and has been in production use since at least 2013.&nb= sp; This Best Current Practices = specification contains a compendium of lessons learned from real JWT deploy= ments and implementations over that period.  It describes pitfalls and= how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise a= rise.  Importantly, the BCP introduces no breaking changes to the JWT = specification and does not require changes to existing deployments.

 

The BCP came about as JWTs were starting to be used = in new families of protocols and applications, both in the IETF and by othe= rs.  For instance, JWTs are being used by the IETF STIR working group = to enable verification of the calling party's authorization to use a particular telephone number for an incoming call, p= roviding verified Caller ID to he= lp combat fraudulent and unwanted telephone calls.  The advice in the = BCP can be used by new JWT profiles and applications to take advantage of w= hat’s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

 

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

 

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

 

--_000_CH2PR00MB0679CAD5DE171630CDFA8AEEF5100CH2PR00MB0679namp_-- From nobody Wed Feb 19 16:44:00 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C446D1200F5 for ; Wed, 19 Feb 2020 16:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9SxF9v_R0Wz for ; Wed, 19 Feb 2020 16:43:55 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2F61200C1 for ; Wed, 19 Feb 2020 16:43:54 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id n25so1658820lfl.0 for ; Wed, 19 Feb 2020 16:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AkDsfh654FBDUDvAZ1Pt0uOqKISQR3/IIHKnk9qLCY=; b=LEltm/0OOTOViFx3jW0/yun/U6w087jBoq9zkhc7IWSgnQq64Lm3kDmSzG93o4O8ZD Wi+Ihb9GEUJCRTWsuyf5GFFp6USYc0L1C49c1d+8c5cFgKTDnD5N+BRMBkEERDHNLBbM g7AWpvPGErhIICShdZgyc4CKoDJtl9cn5YiDyXn9ZeyJUYGTBsCNufzqNjX7wkOGzLU6 Mp+drJ/db/lfF/KsXWzOl1CUSCeJVNe6wSRClkhXXlO1679p9Y2lD5yCvAKTf1un9PkO MmpmVcg4Mbz1Cq9/omqZl72FH6uOgqJIQyFpXSmC/1IYmH0qp7K3BG+Zzdw7N7VxAPnw R7ug== 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=7AkDsfh654FBDUDvAZ1Pt0uOqKISQR3/IIHKnk9qLCY=; b=iz36hRsUhwEtidvoiDrnK8L36q1OvVLQacuipDtHo+xDbx1i56rQJYcWAt4bDxMvY8 3cXSo/fsmv+Q4JHi/XMcxPPj5w+O3nOSieXn1+U9t4INXIqsYWe78Ppc9NacDaUOgBUs rNgoKv+azrxENFJMeLAEsSgKENujirTLOEFzTobz1qIQ8IxWVPs3fWdK+wFUe2S5ZvB4 2S1j7QMoH+KjS+24uoxzFLQueaqiNOVuWmXqoSNfsC7u53a+4M7rEGIlZFIFy52XlunX 2ehSaFsb1EtGB3R3AQX2vrewIOJu+2f0xZwdQUTFEpbl2ZXoVqaeTnJmN2BsVYg49w0V r7QA== X-Gm-Message-State: APjAAAXrlSBBIAP2ZLdNjhJi86SzVcXUPzZ08L3vOWqsQiwvvGz2Ys25 Z/uFOzvIMr1v3YfPk0Hj4FA3h1coDsLcfwa4w5RYCLifuWk= X-Google-Smtp-Source: APXvYqzYCJ/zvJFLiN8q4lmkAVHnSxHFEwR4SkVVsY1ZshSfmjxf4ToCZ7vrCGOo2QBQBXkqk1MmJ0YjeF7ugccSfqo= X-Received: by 2002:ac2:531b:: with SMTP id c27mr14999107lfh.91.1582159432780; Wed, 19 Feb 2020 16:43:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 19 Feb 2020 16:43:26 -0800 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f80f20059ef7327d" Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 00:43:58 -0000 --000000000000f80f20059ef7327d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Mike meant to write "JSON Web Token Best Current Practices" rather than "The OAuth 2.0 Token Exchange specification" On Wed, Feb 19, 2020 at 3:07 PM Mike Jones wrote: > The OAuth 2.0 Token Exchange specification is now RFC 8725 > and BCP 225 > . The abstract of the > specification is: > > > > 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. This Best Current Practices > document updates RFC 7519 to provide actionable guidance leading to secur= e > implementation and deployment of JWTs. > > > > The JSON Web Token (JWT) specification [RFC 7519 > ] was approved in May 2015 > , almost five years ago, and has been > in production use since at least 2013. This Best Current Practices > specification contains a compendium > of lessons learned from real JWT deployments and implementations over tha= t > period. It describes pitfalls and how to avoid them as well as new > recommended practices that enable proactively avoiding problems that coul= d > otherwise arise. Importantly, the BCP introduces no breaking changes to > the JWT specification and does not require changes to existing deployment= s. > > > > The BCP came about as JWTs were starting to be used in new families of > protocols and applications, both in the IETF and by others. For instance= , > JWTs are being used by the IETF STIR working group to enable verification > of the calling party's authorization to use a particular telephone number > for an incoming call, providing verified Caller ID > to help combat fraudulent and unwant= ed > telephone calls. The advice in the BCP can be used by new JWT profiles a= nd > applications to take advantage of what=E2=80=99s been learned since we cr= eated the > JSON Web Token (JWT) specification over a half decade ago. > > > > -- Mike > > > > P.S. This notice was also posted at https://self-issued.info/?p=3D2052 a= nd > as @selfissued . > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000f80f20059ef7327d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Mike meant to write "JSON Web Token Best Curr= ent Practices" rather than "The OAuth 2.0 Token Exchange specific= ation"

 --000000000000f80f20059ef7327d-- From nobody Wed Feb 19 16:49:38 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078B9120113 for ; Wed, 19 Feb 2020 16:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NO_WWW_INFO_CGI=1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsU7E7vtCXKJ for ; Wed, 19 Feb 2020 16:49:31 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640101.outbound.protection.outlook.com [40.107.64.101]) (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 6AE601200C1 for ; Wed, 19 Feb 2020 16:49:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zp6a60kHBksL1RKnTkJCZIK7cQrC1PVBqDu3VZwk3EolVpIqwEBZKpS4vBzUhiaFgvF7hogLr8qkNiTtYjBJI/DCOzCgVpNftD/VYBMm9FAoNogDMM+siIJIFIsWoqlhRYd+zs6Hevf6Qt8vFH5GlbJ3fTrmTFnv49T2JaGsbP2oYSDCuIgeVrROempnviUsDs8IHmrzocdjuQD2yuJx5ooP8YEr0UQT2TAy4vKuUim0D1iZl+FQnW0Rq6eR8ug3O/r+QS3o/rRqwYaNvaxMT6hWwTvCYC1e+ezO1LdO3PbGKgfia9QcuTGRoyrOcHKnowMOAJiWw8OVgwIJvVFDAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3+7XjJ4pfsuHHVjuNYbSfy7J/hq5d0xbyQ7HOdxXp8s=; b=NqRHzPtU4YRRfXGPhw0o2AtTpR30up3JGHmvDhO5/hRNvTvt9fVd46wuNTl5PFV1XmIv1i9B01fX+G671o73uM8o1n+DMdSkm/AdxjmmrlJstmp42RZp1rLvVWlt1h/tugbftAEsG2Zp53VlPlvF2XWJ/kjUzyiRbi196DJId6/cn52NBIjF7W+Tq3GIucUg1fb8mq41b8dr7FK4Nf9xws/UgjJ1IguJWaT+o07yGYd8P5oKJTHtr3p6sQMD0CUodTy051PVNGOrFbVDZ5lUVWgb2EbhiUuN7TXZBOIkSZ+19h9eCfK3D/nItKbcDGOwRChNwOKuSJnN1h54hEtW4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3+7XjJ4pfsuHHVjuNYbSfy7J/hq5d0xbyQ7HOdxXp8s=; b=RAraW7zZTLukF3KTmIGN7NssfK9OWYudZdsg115NPQKByO9XLZJMQQ11ko2qHHSNqpys32CmrLyaqMK0LLtNfcGwoUIu2w6MOjqDcWXksOlBl3YOaAjkdeCkgOUlY3FT9223in9CrBMojJKitnLLE4rqFeWXfI3UHdnWp90HwRo= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (20.180.16.71) by CH2PR00MB0793.namprd00.prod.outlook.com (10.186.139.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2787.0; Thu, 20 Feb 2020 00:49:23 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::d59d:b91e:2881:7949]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::d59d:b91e:2881:7949%9]) with mapi id 15.20.2791.000; Thu, 20 Feb 2020 00:49:22 +0000 From: Mike Jones To: Dick Hardt CC: "oauth@ietf.org" Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225 Thread-Index: AdXh3kerUbblBe/NT3OcwcZBoSQuOwFqHtMAAAAM46A= Date: Thu, 20 Feb 2020 00:49:22 +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_ActionId=a40da359-aea1-4282-9edf-00003ea953e3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-20T00:44:54Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.83.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 21dba997-8e0a-4b97-f5c0-08d7b59eba21 x-ms-traffictypediagnostic: CH2PR00MB0793: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 031996B7EF x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(366004)(136003)(376002)(39860400002)(346002)(396003)(199004)(189003)(81156014)(8936002)(81166006)(8676002)(71200400001)(33656002)(7696005)(6916009)(86362001)(316002)(478600001)(966005)(10290500003)(8990500004)(9686003)(55016002)(5660300002)(52536014)(64756008)(66446008)(186003)(26005)(76116006)(2906002)(66946007)(66476007)(66556008)(53546011)(6506007)(4326008)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0793; H:CH2PR00MB0679.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pr7+r9zYgOuYP8tVrEgCStqItCTWP9c+XIvLXfiD8tH9BqD11pWe1qF/8oMwhCkP7N1GKp/0ryOJws8KFmBGXum2m2L8Y5HrO911u1tIAUAMDW3gtZPWbN3UDgTWIb2/43b3Q6m+Rc+lZl61gLT+/cKlzKGTyHhGQLbPjCqW/hIJFTmarvVBCzesXyxNpBOfAoop4aHgESkt4owtRGNFT6pZj/tke25sX7tTH51CPpn+mcqAP9BBcjTvaZ80fqqpEH0tlSy9bniUYi3zQFwub7Qi/v05ZoffDfQcm1/LYjEYrPnXo5YXGE/1lHeCqSaD//SKtDDdKIaEOht1d6IFBeleBGvEccJfhpcWt/m4ZqAQzMOJpZt6esLgg5AwWh9lciC/Wn3Vt5uxVMjkBEqjvjH8yp7BE0gdwNyI6Fdl9D2mEMRx3V6mMN3UMvoqYagCM1k0g98muj07RYvoTdT9wNLDahTmeHD153C2GLH1EhdBrdGzuibx1Y5fbyvK5nvYtmLLfaDKn/5LReNpiinadYDYaScNbDlu73xZA1RHOJGAmcK/zsA+ZOho0VUAWHKrmzSQ0U7SbFrR8hg30hT6h0BL1FpqhYp4GnfM4SF63N2Dc67WMrHJ0T3JaGewO5fvfLMHm8A9UBgsJGok5Ba4VQ== x-ms-exchange-antispam-messagedata: RcbCRnjh9i/JdbtOqqLmbWc+4zmnmBqoSQLIZ/Na0u2H5fHO22W9RkA7OEfKlcldY6hvwTB3/MnkQnUorrxERuwTH8fMrFTAbwtlzpSdVyAuR+dlx48nCw3SSwTuakd1fVtEz7ua3RAgv9tJWWq8/Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679D53568C3BFC491A28F0EF5130CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21dba997-8e0a-4b97-f5c0-08d7b59eba21 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 00:49:22.7307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sCsxxa5Nhm46NHm7GWRH7Xf4ysV+2S0vWejmxRQQawD1FJDYgQWUniq+/yF3Juiydne0j+WPGHZsalqx4Txk3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0793 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JSON Web Token Best Current Practices is now RFC 8725 and BCP 225 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 00:49:34 -0000 --_000_CH2PR00MB0679D53568C3BFC491A28F0EF5130CH2PR00MB0679namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T29wcyDigJMgY3V0IGFuZCBwYXN0ZSBlcnJvciEgIEnigJl2ZSBmaXhlZCB0aGlzIGluIHRoZSBi bG9nIHBvc3QgYXQgaHR0cHM6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTIwNTIuDQoNCkZyb206IERp Y2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAxOSwgMjAyMCA0OjQzIFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbT0FV VEgtV0ddIEpTT04gV2ViIFRva2VuIEJlc3QgQ3VycmVudCBQcmFjdGljZXMgaXMgbm93IFJGQyA4 NzI1IGFuZCBCQ1AgMjI1DQoNCkkgdGhpbmsgTWlrZSBtZWFudCB0byB3cml0ZSAiSlNPTiBXZWIg VG9rZW4gQmVzdCBDdXJyZW50IFByYWN0aWNlcyIgcmF0aGVyIHRoYW4gIlRoZSBPQXV0aCAyLjAg VG9rZW4gRXhjaGFuZ2Ugc3BlY2lmaWNhdGlvbiINCg0KT24gV2VkLCBGZWIgMTksIDIwMjAgYXQg MzowNyBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy4u aWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K VGhlIE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZSBzcGVjaWZpY2F0aW9uICBpcyBub3cgUkZDIDg3 MjU8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGd3d3LnJmYy1lZGl0b3Iub3JnJTJGcmZjJTJGcmZjODcyNS5odG1sJmRhdGE9 MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDOWY4MGNhMjE3NzY1NGY4 ZDA2NTEwOGQ3YjU5ZGZhNGElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM3MTc3NTYyNDI3MDY4MTg3JnNkYXRhPVNEWHpFRUx6QUF5VDhMallNSE16JTJCU3hC anEyZzNkUU56dmZFWVVwaWFqUSUzRCZyZXNlcnZlZD0wPiBhbmQgQkNQIDIyNTxodHRwczovL25h bTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3 d3cucmZjLWVkaXRvci5vcmclMkZpbmZvJTJGYmNwMjI1JmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwu Sm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDOWY4MGNhMjE3NzY1NGY4ZDA2NTEwOGQ3YjU5ZGZhNGEl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTc3NTYyNDI3 MDY4MTg3JnNkYXRhPVFvNnIlMkIwcXZLUVolMkJoc1I4b3NGdmZ3bGlITXhwMlpQTUxURkdCVmUy eFdVJTNEJnJlc2VydmVkPTA+LiAgVGhlIGFic3RyYWN0IG9mIHRoZSBzcGVjaWZpY2F0aW9uIGlz Og0KDQpKU09OIFdlYiBUb2tlbnMsIGFsc28ga25vd24gYXMgSldUcywgYXJlIFVSTC1zYWZlIEpT T04tYmFzZWQgc2VjdXJpdHkgdG9rZW5zIHRoYXQgY29udGFpbiBhIHNldCBvZiBjbGFpbXMgdGhh dCBjYW4gYmUgc2lnbmVkIGFuZC9vciBlbmNyeXB0ZWQuIEpXVHMgYXJlIGJlaW5nIHdpZGVseSB1 c2VkIGFuZCBkZXBsb3llZCBhcyBhIHNpbXBsZSBzZWN1cml0eSB0b2tlbiBmb3JtYXQgaW4gbnVt ZXJvdXMgcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMsIGJvdGggaW4gdGhlIGFyZWEgb2YgZGln aXRhbCBpZGVudGl0eSBhbmQgaW4gb3RoZXIgYXBwbGljYXRpb24gYXJlYXMuIFRoaXMgQmVzdCBD dXJyZW50IFByYWN0aWNlcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA3NTE5IHRvIHByb3ZpZGUgYWN0 aW9uYWJsZSBndWlkYW5jZSBsZWFkaW5nIHRvIHNlY3VyZSBpbXBsZW1lbnRhdGlvbiBhbmQgZGVw bG95bWVudCBvZiBKV1RzLg0KDQpUaGUgSlNPTiBXZWIgVG9rZW4gKEpXVCkgc3BlY2lmaWNhdGlv biBbUkZDIDc1MTk8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjNzUxOSZkYXRh PTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmODBjYTIxNzc2NTRm OGQwNjUxMDhkN2I1OWRmYTRhJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNzE3NzU2MjQyNzA3ODE4NSZzZGF0YT1oalhJQWU1NWtUNlI2V3paY0F2N2RTUUdl Nk5jdzdYbFlGZjZ4aHglMkJxbVUlM0QmcmVzZXJ2ZWQ9MD5dIHdhcyBhcHByb3ZlZCBpbiBNYXkg MjAxNTxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZzZWxmLWlzc3VlZC5pbmZvJTJGJTNGcCUzRDEzODcmZGF0YT0wMiU3QzAx JTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M5ZjgwY2EyMTc3NjU0ZjhkMDY1MTA4 ZDdiNTlkZmE0YSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzcxNzc1NjI0MjcwNzgxODUmc2RhdGE9S1hxTTBKUXBsUHpKNkZLd016MjlOM1YwUEF6ajhXbWlM MWVhMW1EVERONCUzRCZyZXNlcnZlZD0wPiwgYWxtb3N0IGZpdmUgeWVhcnMgYWdvLCBhbmQgaGFz IGJlZW4gaW4gcHJvZHVjdGlvbiB1c2Ugc2luY2UgYXQgbGVhc3QgMjAxMy4gIFRoaXMgQmVzdCBD dXJyZW50IFByYWN0aWNlczxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmMxODE4 JmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDOWY4MGNhMjE3 NzY1NGY4ZDA2NTEwOGQ3YjU5ZGZhNGElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM3MTc3NTYyNDI3MDg4MTc5JnNkYXRhPXF6NFhvWU9POFk3Z1QwNyUyRlF6 cnUlMkJMcFdvTzRYSjZyeUtzc0ZQM08yODRrJTNEJnJlc2VydmVkPTA+IHNwZWNpZmljYXRpb24g Y29udGFpbnMgYSBjb21wZW5kaXVtIG9mIGxlc3NvbnMgbGVhcm5lZCBmcm9tIHJlYWwgSldUIGRl cGxveW1lbnRzIGFuZCBpbXBsZW1lbnRhdGlvbnMgb3ZlciB0aGF0IHBlcmlvZC4gIEl0IGRlc2Ny aWJlcyBwaXRmYWxscyBhbmQgaG93IHRvIGF2b2lkIHRoZW0gYXMgd2VsbCBhcyBuZXcgcmVjb21t ZW5kZWQgcHJhY3RpY2VzIHRoYXQgZW5hYmxlIHByb2FjdGl2ZWx5IGF2b2lkaW5nIHByb2JsZW1z IHRoYXQgY291bGQgb3RoZXJ3aXNlIGFyaXNlLiAgSW1wb3J0YW50bHksIHRoZSBCQ1AgaW50cm9k dWNlcyBubyBicmVha2luZyBjaGFuZ2VzIHRvIHRoZSBKV1Qgc3BlY2lmaWNhdGlvbiBhbmQgZG9l cyBub3QgcmVxdWlyZSBjaGFuZ2VzIHRvIGV4aXN0aW5nIGRlcGxveW1lbnRzLg0KDQpUaGUgQkNQ IGNhbWUgYWJvdXQgYXMgSldUcyB3ZXJlIHN0YXJ0aW5nIHRvIGJlIHVzZWQgaW4gbmV3IGZhbWls aWVzIG9mIHByb3RvY29scyBhbmQgYXBwbGljYXRpb25zLCBib3RoIGluIHRoZSBJRVRGIGFuZCBi eSBvdGhlcnMuICBGb3IgaW5zdGFuY2UsIEpXVHMgYXJlIGJlaW5nIHVzZWQgYnkgdGhlIElFVEYg U1RJUiB3b3JraW5nIGdyb3VwIHRvIGVuYWJsZSB2ZXJpZmljYXRpb24gb2YgdGhlIGNhbGxpbmcg cGFydHkncyBhdXRob3JpemF0aW9uIHRvIHVzZSBhIHBhcnRpY3VsYXIgdGVsZXBob25lIG51bWJl ciBmb3IgYW4gaW5jb21pbmcgY2FsbCwgcHJvdmlkaW5nIHZlcmlmaWVkIENhbGxlciBJRDxodHRw czovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZzZWxmLWlzc3VlZC5pbmZvJTJGJTNGcCUzRDIwNDUmZGF0YT0wMiU3QzAxJTdDTWljaGFl bC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M5ZjgwY2EyMTc3NjU0ZjhkMDY1MTA4ZDdiNTlkZmE0 YSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNzc1NjI0 MjcwODgxNzkmc2RhdGE9SSUyRnNmZXhlNTdtU0tvUFdBTWE1ZmQxNDB3aHM0R2w0WVZWNU9kbXBx THdJJTNEJnJlc2VydmVkPTA+IHRvIGhlbHAgY29tYmF0IGZyYXVkdWxlbnQgYW5kIHVud2FudGVk IHRlbGVwaG9uZSBjYWxscy4gIFRoZSBhZHZpY2UgaW4gdGhlIEJDUCBjYW4gYmUgdXNlZCBieSBu ZXcgSldUIHByb2ZpbGVzIGFuZCBhcHBsaWNhdGlvbnMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Ygd2hh dOKAmXMgYmVlbiBsZWFybmVkIHNpbmNlIHdlIGNyZWF0ZWQgdGhlIEpTT04gV2ViIFRva2VuIChK V1QpIHNwZWNpZmljYXRpb24gb3ZlciBhIGhhbGYgZGVjYWRlIGFnby4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5T LiAgVGhpcyBub3RpY2Ugd2FzIGFsc28gcG9zdGVkIGF0IGh0dHBzOi8vc2VsZi1pc3N1ZWQuaW5m by8/cD0yMDUyPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnNlbGYtaXNzdWVkLmluZm8lMkYlM0ZwJTNEMjA1MiZkYXRhPTAy JTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmODBjYTIxNzc2NTRmOGQw NjUxMDhkN2I1OWRmYTRhJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNzE3NzU2MjQyNzA5ODE3NSZzZGF0YT0yZE1scGhBY0ZRcGdCYVJ5V2xHc2wlMkI3RkEl MkZFUmIzS295ZndsYyUyRkhJczdBJTNEJnJlc2VydmVkPTA+IGFuZCBhcyBAc2VsZmlzc3VlZDxo dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ0d2l0dGVyLmNvbSUyRnNlbGZpc3N1ZWQmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5K b25lcyU0MG1pY3Jvc29mdC5jb20lN0M5ZjgwY2EyMTc3NjU0ZjhkMDY1MTA4ZDdiNTlkZmE0YSU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNzc1NjI0Mjcw OTgxNzUmc2RhdGE9VVZpTE1HcDdGSFVjMUJDR2ZKUTlaWDUwT0xZSFhQNkF2NThhbFpQU2FqTSUz RCZyZXNlcnZlZD0wPi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxo dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZkYXRhPTAy JTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmODBjYTIxNzc2NTRmOGQw NjUxMDhkN2I1OWRmYTRhJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNzE3NzU2MjQyNzA5ODE3NSZzZGF0YT1XWEZGcGRoVHdwOUl1aG9JQ2hzbWE3c2tvc0p5 JTJGRXl5SUF0QlFBOUZlYXMlM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_CH2PR00MB0679D53568C3BFC491A28F0EF5130CH2PR00MB0679namp_ 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 cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Pb3BzIOKAkyBjdXQgYW5kIHBhc3RlIGVycm9y ISZuYnNwOyBJ4oCZdmUgZml4ZWQgdGhpcyBpbiB0aGUgYmxvZyBwb3N0IGF0DQo8YSBocmVmPSJo dHRwczovL3NlbGYtaXNzdWVkLmluZm8vP3A9MjA1MiI+aHR0cHM6Ly9zZWxmLWlzc3VlZC5pbmZv Lz9wPTIwNTI8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRGljayBIYXJkdCAmbHQ7ZGljay5o YXJkdEBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDE5LCAyMDIwIDQ6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gSlNPTiBXZWIgVG9r ZW4gQmVzdCBDdXJyZW50IFByYWN0aWNlcyBpcyBub3cgUkZDIDg3MjUgYW5kIEJDUCAyMjU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgTWlrZSBtZWFudCB0byB3cml0ZSAm cXVvdDtKU09OIFdlYiBUb2tlbiBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzJnF1b3Q7IHJhdGhlciB0 aGFuICZxdW90O1RoZSBPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2Ugc3BlY2lmaWNhdGlvbiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBG ZWIgMTksIDIwMjAgYXQgMzowNyBQTSBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzPTxhIGhy ZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPjQwbWljcm9zb2Z0LmNv bUBkbWFyYy4uaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgT0F1 dGggMi4wIFRva2VuIEV4Y2hhbmdlIHNwZWNpZmljYXRpb24mbmJzcDsgaXMgbm93DQo8YSBocmVm PSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZyZmMlMkZyZmM4NzI1Lmh0bWwmYW1wO2Rh dGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDOWY4MGNhMjE3NzY1 NGY4ZDA2NTEwOGQ3YjU5ZGZhNGElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM3MTc3NTYyNDI3MDY4MTg3JmFtcDtzZGF0YT1TRFh6RUVMekFBeVQ4TGpZTUhN eiUyQlN4QmpxMmczZFFOenZmRVlVcGlhalElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2Js YW5rIj4NClJGQyA4NzI1PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LnJmYy1lZGl0b3Iu b3JnJTJGaW5mbyUyRmJjcDIyNSZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1p Y3Jvc29mdC5jb20lN0M5ZjgwY2EyMTc3NjU0ZjhkMDY1MTA4ZDdiNTlkZmE0YSU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNzc1NjI0MjcwNjgxODcmYW1w O3NkYXRhPVFvNnIlMkIwcXZLUVolMkJoc1I4b3NGdmZ3bGlITXhwMlpQTUxURkdCVmUyeFdVJTNE JmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpCQ1AgMjI1PC9hPi4mbmJzcDsgVGhl IGFic3RyYWN0IG9mIHRoZSBzcGVjaWZpY2F0aW9uIGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkpTT04gV2ViIFRva2VucywgYWxzbyBrbm93biBhcyBK V1RzLCBhcmUgVVJMLXNhZmUgSlNPTi1iYXNlZCBzZWN1cml0eSB0b2tlbnMgdGhhdCBjb250YWlu IGEgc2V0IG9mIGNsYWltcyB0aGF0IGNhbiBiZSBzaWduZWQgYW5kL29yIGVuY3J5cHRlZC4gSldU cyBhcmUgYmVpbmcgd2lkZWx5IHVzZWQgYW5kIGRlcGxveWVkIGFzIGEgc2ltcGxlIHNlY3VyaXR5 IHRva2VuIGZvcm1hdCBpbiBudW1lcm91cyBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucywNCiBi b3RoIGluIHRoZSBhcmVhIG9mIGRpZ2l0YWwgaWRlbnRpdHkgYW5kIGluIG90aGVyIGFwcGxpY2F0 aW9uIGFyZWFzLiBUaGlzIEJlc3QgQ3VycmVudCBQcmFjdGljZXMgZG9jdW1lbnQgdXBkYXRlcyBS RkMgNzUxOSB0byBwcm92aWRlIGFjdGlvbmFibGUgZ3VpZGFuY2UgbGVhZGluZyB0byBzZWN1cmUg aW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgSldUcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBKU09OIFdlYiBUb2tlbiAoSldUKSBzcGVjaWZpY2F0aW9uIFs8YSBocmVm PSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM3NTE5JmFtcDtkYXRhPTAyJTdD MDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmODBjYTIxNzc2NTRmOGQwNjUx MDhkN2I1OWRmYTRhJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNzE3NzU2MjQyNzA3ODE4NSZhbXA7c2RhdGE9aGpYSUFlNTVrVDZSNld6WmNBdjdkU1FHZTZO Y3c3WGxZRmY2eGh4JTJCcW1VJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+UkZD DQogNzUxOTwvYT5dIHdhcyA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZzZWxmLWlzc3VlZC5pbmZvJTJGJTNG cCUzRDEzODcmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29t JTdDOWY4MGNhMjE3NzY1NGY4ZDA2NTEwOGQ3YjU5ZGZhNGElN0M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTc3NTYyNDI3MDc4MTg1JmFtcDtzZGF0YT1LWHFN MEpRcGxQeko2Rkt3TXoyOU4zVjBQQXpqOFdtaUwxZWExbURURE40JTNEJmFtcDtyZXNlcnZlZD0w IiB0YXJnZXQ9Il9ibGFuayI+DQphcHByb3ZlZCBpbiBNYXkgMjAxNTwvYT4sIGFsbW9zdCBmaXZl IHllYXJzIGFnbywgYW5kIGhhcyBiZWVuIGluIHByb2R1Y3Rpb24gdXNlIHNpbmNlIGF0IGxlYXN0 IDIwMTMuJm5ic3A7IFRoaXMNCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRt bCUyRnJmYzE4MTgmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQu Y29tJTdDOWY4MGNhMjE3NzY1NGY4ZDA2NTEwOGQ3YjU5ZGZhNGElN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTc3NTYyNDI3MDg4MTc5JmFtcDtzZGF0YT1x ejRYb1lPTzhZN2dUMDclMkZRenJ1JTJCTHBXb080WEo2cnlLc3NGUDNPMjg0ayUzRCZhbXA7cmVz ZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KQmVzdCBDdXJyZW50IFByYWN0aWNlczwvYT4gc3Bl Y2lmaWNhdGlvbiBjb250YWlucyBhIGNvbXBlbmRpdW0gb2YgbGVzc29ucyBsZWFybmVkIGZyb20g cmVhbCBKV1QgZGVwbG95bWVudHMgYW5kIGltcGxlbWVudGF0aW9ucyBvdmVyIHRoYXQgcGVyaW9k LiZuYnNwOyBJdCBkZXNjcmliZXMgcGl0ZmFsbHMgYW5kIGhvdyB0byBhdm9pZCB0aGVtIGFzIHdl bGwgYXMgbmV3IHJlY29tbWVuZGVkIHByYWN0aWNlcyB0aGF0IGVuYWJsZSBwcm9hY3RpdmVseSBh dm9pZGluZw0KIHByb2JsZW1zIHRoYXQgY291bGQgb3RoZXJ3aXNlIGFyaXNlLiZuYnNwOyBJbXBv cnRhbnRseSwgdGhlIEJDUCBpbnRyb2R1Y2VzIG5vIGJyZWFraW5nIGNoYW5nZXMgdG8gdGhlIEpX VCBzcGVjaWZpY2F0aW9uIGFuZCBkb2VzIG5vdCByZXF1aXJlIGNoYW5nZXMgdG8gZXhpc3Rpbmcg ZGVwbG95bWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgQkNQIGNhbWUgYWJv dXQgYXMgSldUcyB3ZXJlIHN0YXJ0aW5nIHRvIGJlIHVzZWQgaW4gbmV3IGZhbWlsaWVzIG9mIHBy b3RvY29scyBhbmQgYXBwbGljYXRpb25zLCBib3RoIGluIHRoZSBJRVRGIGFuZCBieSBvdGhlcnMu Jm5ic3A7IEZvciBpbnN0YW5jZSwgSldUcyBhcmUgYmVpbmcgdXNlZCBieSB0aGUgSUVURg0KIFNU SVIgd29ya2luZyBncm91cCB0byBlbmFibGUgdmVyaWZpY2F0aW9uIG9mIHRoZSBjYWxsaW5nIHBh cnR5J3MgYXV0aG9yaXphdGlvbiB0byB1c2UgYSBwYXJ0aWN1bGFyIHRlbGVwaG9uZSBudW1iZXIg Zm9yIGFuIGluY29taW5nIGNhbGwsIHByb3ZpZGluZw0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGc2VsZi1p c3N1ZWQuaW5mbyUyRiUzRnAlM0QyMDQ1JmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVz JTQwbWljcm9zb2Z0LmNvbSU3QzlmODBjYTIxNzc2NTRmOGQwNjUxMDhkN2I1OWRmYTRhJTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3NzU2MjQyNzA4ODE3 OSZhbXA7c2RhdGE9SSUyRnNmZXhlNTdtU0tvUFdBTWE1ZmQxNDB3aHM0R2w0WVZWNU9kbXBxTHdJ JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQp2ZXJpZmllZCBDYWxsZXIgSUQ8 L2E+IHRvIGhlbHAgY29tYmF0IGZyYXVkdWxlbnQgYW5kIHVud2FudGVkIHRlbGVwaG9uZSBjYWxs cy4mbmJzcDsgVGhlIGFkdmljZSBpbiB0aGUgQkNQIGNhbiBiZSB1c2VkIGJ5IG5ldyBKV1QgcHJv ZmlsZXMgYW5kIGFwcGxpY2F0aW9ucyB0byB0YWtlIGFkdmFudGFnZSBvZiB3aGF04oCZcyBiZWVu IGxlYXJuZWQgc2luY2Ugd2UgY3JlYXRlZCB0aGUgSlNPTiBXZWIgVG9rZW4gKEpXVCkgc3BlY2lm aWNhdGlvbiBvdmVyIGEgaGFsZg0KIGRlY2FkZSBhZ28uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UC5TLiZuYnNwOyBUaGlzIG5vdGljZSB3YXMgYWxzbyBw b3N0ZWQgYXQNCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnNlbGYtaXNzdWVkLmluZm8lMkYlM0ZwJTNEMjA1 MiZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M5Zjgw Y2EyMTc3NjU0ZjhkMDY1MTA4ZDdiNTlkZmE0YSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzcxNzc1NjI0MjcwOTgxNzUmYW1wO3NkYXRhPTJkTWxwaEFjRlFw Z0JhUnlXbEdzbCUyQjdGQSUyRkVSYjNLb3lmd2xjJTJGSElzN0ElM0QmYW1wO3Jlc2VydmVkPTAi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0yMDUyPC9hPiBh bmQgYXMgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdHdpdHRlci5jb20lMkZzZWxmaXNzdWVkJmFtcDtkYXRh PTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmODBjYTIxNzc2NTRm OGQwNjUxMDhkN2I1OWRmYTRhJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNzE3NzU2MjQyNzA5ODE3NSZhbXA7c2RhdGE9VVZpTE1HcDdGSFVjMUJDR2ZKUTla WDUwT0xZSFhQNkF2NThhbFpQU2FqTSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsi Pg0KQHNlbGZpc3N1ZWQ8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v bmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTAyJTdD MDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzlmODBjYTIxNzc2NTRmOGQwNjUx MDhkN2I1OWRmYTRhJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNzE3NzU2MjQyNzA5ODE3NSZhbXA7c2RhdGE9V1hGRnBkaFR3cDlJdWhvSUNoc21hN3Nrb3NK eSUyRkV5eUlBdEJRQTlGZWFzJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB0679D53568C3BFC491A28F0EF5130CH2PR00MB0679namp_-- From nobody Thu Feb 20 03:39:44 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66071200F7 for ; Thu, 20 Feb 2020 03:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=openitio.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 abU7b8VxX4_5 for ; Thu, 20 Feb 2020 03:39:39 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110065.outbound.protection.outlook.com [40.107.11.65]) (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 83A2812001A for ; Thu, 20 Feb 2020 03:39:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MSnm6aJnRW1XpgCfgTWYLXrIK2w6lu/wStqMDQR2b/n6gOHIB4awNT1AeBPTUM/eQAg1/nnzdEL/oFhGPug1lM8VnDs+keoJGV8+9eDt8/fpezAQs4J3/SxrRp4o6zN8dDG8uf6udTyYrhqlPnYJE61ho125SrU9fPrXhnIIs2O0CQLoLRc9jFhBJPb88PWgNGeE/O0s4CbDg77srF7XSQfoEObWzzefs/q/hfemI+bSoqi9zR1wVA4j0BIhZoM554mU/8okh9wFn7naes3NCMSnLg/IVCW72U9SCj7u2fqczM2BZQaeC77rVwCY5jvli3+8d2i7DhmihHc9oyMKEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Np6+V2RljeT9FZ11wszcdlq8mZ1fBUOnLJIznzM1bFw=; b=P3Jn6SXiFfjMFSCFaxDzvQZ7fkRBCbhdcqbM7FeYY+/QOtUuYLjcOVmeDPYX6BO1K3FCsT//HsLKHjlwCOpqGyTrGVvzbunmi/kMebPrLo2IuyrCztNvTs4RndG1UmwqYr0MkmeNxtTQYhwcxTfb39/Fl5C2TDiS6beO/jv/lbYpCjZqhJGtLZElIWaOOb8/DjKpnhFpQM5BzErYyuQW6kMXEoL1hG/tEaVLc261JDl3aUWjVFDiX9oVCsFxPjpAmjsVXa/LfuDGpXETRmatcd1vTCT/MVSrzkmHO1Y4qxQSJy5mtuUc4iAgjU/0s1CNzmZ9dr2R3QW2W5z+XD9oCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=openitio.com; dmarc=pass action=none header.from=openitio.com; dkim=pass header.d=openitio.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openitio.onmicrosoft.com; s=selector1-openitio-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Np6+V2RljeT9FZ11wszcdlq8mZ1fBUOnLJIznzM1bFw=; b=egtMmTPuO0/1hXNPG3ESPWpi4+NGQiyNP4BiHHoQ6Zxp3ozzNJliqNEd5gtQY/wlfu8V+F+DKRUW+DB4dqaZbnO/3wCegjq1VykVG2tTwJX7xvH2PWOSs3vcDx8hfVqxanACP2iXoZU/TuarlvaC5ATI+8Ltgx0PIDO/KC0ys5k= Received: from LO2P265MB0544.GBRP265.PROD.OUTLOOK.COM (10.166.103.15) by LO2P265MB1104.GBRP265.PROD.OUTLOOK.COM (20.176.145.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.29; Thu, 20 Feb 2020 11:39:36 +0000 Received: from LO2P265MB0544.GBRP265.PROD.OUTLOOK.COM ([fe80::912b:d131:ea66:3f07]) by LO2P265MB0544.GBRP265.PROD.OUTLOOK.COM ([fe80::912b:d131:ea66:3f07%5]) with mapi id 15.20.2729.032; Thu, 20 Feb 2020 11:39:36 +0000 From: Bhupinder Saini To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9 Thread-Index: AQHV52InUOk7IBSkmESEfNh7rxWutKgj9hWA Date: Thu, 20 Feb 2020 11:39:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bhupinder@openitio.com; x-originating-ip: [82.211.74.240] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 39b9b19c-5063-495e-7359-08d7b5f98fcf x-ms-traffictypediagnostic: LO2P265MB1104: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 031996B7EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(39830400003)(34096005)(346002)(396003)(189003)(199004)(6486002)(6916009)(316002)(508600001)(86362001)(6506007)(53546011)(5660300002)(966005)(186003)(45080400002)(36756003)(66946007)(6512007)(81166006)(71200400001)(8676002)(8936002)(2906002)(2616005)(76116006)(66556008)(81156014)(26005)(66476007)(33656002)(64756008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1104; H:LO2P265MB0544.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: openitio.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mYkdF+Eiz2v4B7UONs086EZJNtwNh8EoQpeVb3FAACT4VoM1Bt+TTcXZZcXzsbcd13H9W10C66T2GvWYASkMXBjZl8mo+7I9YGQ0P2CcJp97ZyyJqcsl5PX+jxrLJGE4QxKciWvieYgYaswvJabxlLoAYK7bHuMHw/jp4ZEZCLO+njQ87lvsPTN+7qR2LIVnYtnY3X95jU6x4yDgiptXlmmc9ot/JtS5RKWbq4w8Wi7ksK9QKh+xlWdSW/Zk9uMnLE7u17KkUlPnKDpKtWQxDuSKZk7DMD2PNLPBzPTCIU2G7XLmYXSL1HEgIBCeKAZMsP4pYadFKlOjrT0th07YoMFNtPvPtxJWOnGniYUSvEhErhOYcjjqsI807L8Tph+oJe/m8EuPwbd+hI8rP56lW6j0Qd5TQF4iGUeLVdR+8GGnMY6h/bxfSmQI/mtOyuuEhIWqVfWmwbxRcvPk+Fr9erBUR+WXyqes8grk5909KGIlbTyp3ApK5RJHIkUjXUNo0hIqjbKv96ue0JbED/G4gg== x-ms-exchange-antispam-messagedata: x4huOclqBnIBMg1cVtMzVUF+DgxtCeeZYWW0GbmnLL7k5m5ZBVXoTFQtGmiFac8KgL9F3K+cNn9DWCiRGCktwRmb9ZdbY3c1PzLROLUwzdoI18/GGa1+uYJzyThQgyfZ3DcAiuTheWNoGhSsu/kE7g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DDF7FE7CC17B4AE492E5998E1AC7DE8Dopenitiocom_" MIME-Version: 1.0 X-OriginatorOrg: openitio.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39b9b19c-5063-495e-7359-08d7b5f98fcf X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 11:39:35.9358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 73136153-a822-4a60-9bd3-a945eed0054a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x2BRmxrpm+2T+nICWUpwFZbqKiZfKHWnGIDd9ZLMFjEASrX9PLBDuMz57FJ/Z205h6bFRXOa8OXlUsb1tkaOpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1104 Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 11:39:42 -0000 --_000_DDF7FE7CC17B4AE492E5998E1AC7DE8Dopenitiocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxsDQoNCkkgaGF2ZSByZWNlbnRseSBqb2luZWQgdGhpcyB3b3JraW5nIGdyb3VwIGJ1 dCBoYXZlIEkgaGF2ZSBiZWVuIElBTSBjb25zdWx0YW50IGZvciAxNSsgeWVhcnMuDQpNeSBvcGlu aW9uIGFuZCBleHBlcmllbmNlIG9uIGZvbGxvd2luZzoNCg0KICAqICAgSW1wbGljaXQgR3JhbnQg 4oCTIERlZmluaXRlbHkgRHJvcHBlZA0KICAqICAgUGFzc3dvcmQgR3JhbnQg4oCTIERlZmluaXRl bHkgRHJvcHBlZA0KDQpJIGhhZCBzbyBtYW55IGNvbnZlcnNhdGlvbiB3aXRoIEFwcCAoV0VCL01P QklMRSkgZGV2ZWxvcGVycyBvbiBOT1QgdXNpbmcgdGhlbSBpbiBsYXN0IGZldyB5ZWFycywgbm93 IHdpdGggcmV2aXNlZCAyLjEgd2UgY2FuIGF2b2lkIHRob3NlIGNvbnZlcnNhdGlvbnMuIEFsdGhv dWdoIHRoZXNlIGdyYW50cyBtYWRlIGl0IGxvb2sgbGVzcyBjb21wbGV4IGJ1dCBuZXZlciByZWFs bHkgYWxpZ25lZCB0byB1dGlsaXNlIHRoZSBmdWxsIHNlY3VyaXR5IG9mIE9BVVRIMi4NCg0KSSBm YXZvdXIgdGhlIHZvdGUgdG8gZHJvcCB0aGVtIGZvciBnb29kIGFuZCBtYWtlIE9hdXRoIDIuMSBj bGVhbiBhcyBmb2xsb3dpbmc6DQoNCiAgKiAgIEF1dGhvcmlzYXRpb24gQ29kZSBHcmFudHMNCiAg KiAgIENsaWVudCBDcmVkZW50aWFscw0KDQpUaGFua3MNCkJodXBpbmRlciBTaW5naA0KDQpGcm9t OiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEJydW5vIEJyaXRv IDxiaGRlYnJpdG9AZ21haWwuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCAxOSBGZWJydWFyeSAyMDIw IGF0IDIwOjIxDQpUbzogIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBPQXV0aCBEaWdlc3QsIFZvbCAxMzYsIElzc3VlIDkNCg0KTm8sIEkg Y2Fubm90IHNlZSBhbnkgdXNlIGNhc2Ugd2hlcmUgYXV0aG9yaXphdGlvbiBjb2RlIGNhbm5vdCBy ZXBsYWNlIGltcGxpY2l0LiBHbyBhaGVhZCBhbmQgcmVtb3ZlIGl0IQ0KDQpCcnVubw0KDQpPbiBX ZWQsIEZlYiAxOSwgMjAyMCBhdCA1OjAxIFBNIDxvYXV0aC1yZXF1ZXN0QGlldGYub3JnPG1haWx0 bzpvYXV0aC1yZXF1ZXN0QGlldGYub3JnPj4gd3JvdGU6DQpTZW5kIE9BdXRoIG1haWxpbmcgbGlz dCBzdWJtaXNzaW9ucyB0bw0KICAgICAgICBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+DQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUg V2ViLCB2aXNpdA0KICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9k eSAnaGVscCcgdG8NCiAgICAgICAgb2F1dGgtcmVxdWVzdEBpZXRmLm9yZzxtYWlsdG86b2F1dGgt cmVxdWVzdEBpZXRmLm9yZz4NCg0KWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRo ZSBsaXN0IGF0DQogICAgICAgIG9hdXRoLW93bmVyQGlldGYub3JnPG1haWx0bzpvYXV0aC1vd25l ckBpZXRmLm9yZz4NCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxp bmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIE9BdXRoIGRp Z2VzdC4uLiINClRvZGF5J3MgVG9waWNzOg0KDQogICAxLiBSZTogT0F1dGggMi4xIC0gZHJvcCBp bXBsaWNpdCBmbG93PyAoRG9taW5pY2sgQmFpZXIpDQogICAyLiBSZTogT0F1dGggRGlnZXN0LCBW b2wgMTM2LCBJc3N1ZSA3IChUb3JzdGVuIExvZGRlcnN0ZWR0KQ0KICAgMy4gUmU6IFtFWFRFUk5B TF0gIE9BdXRoIDIuMTogZHJvcHBpbmcgcGFzc3dvcmQgZ3JhbnQgKERpY2sgSGFyZHQpDQoNCg0K DQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IERvbWluaWNr IEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2 aWxlZ2UuY29tPj4NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20+Piwgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPg0KQ2M6DQpCY2M6DQpEYXRlOiBUdWUsIDE4IEZlYiAyMDIwIDIyOjQ5OjA1IC0wODAwDQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSBkcm9wIGltcGxpY2l0IGZsb3c/DQpO byAtIHBsZWFzZSBnZXQgcmlkIG9mIGl0Lg0KDQrigJTigJTigJQNCkRvbWluaWNrIEJhaWVyDQoN Cg0KT24gMTguIEZlYnJ1YXJ5IDIwMjAgYXQgMjE6MzI6MzEsIERpY2sgSGFyZHQgKGRpY2suaGFy ZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLi5oYXJkdEBnbWFpbC5jb20+KSB3cm90ZToNCkhleSBM aXN0DQoNCihJJ20gdXNpbmcgdGhlIE9BdXRoIDIuMSBuYW1lIGFzIGEgcGxhY2Vob2xkZXIgZm9y IHRoZSBkb2MgdGhhdCBBYXJvbiwgVG9yc3RlbiwgYW5kIEkgYXJlIHdvcmtpbmcgb24pDQoNCkdp dmVuIHRoZSBwb2ludHMgQWFyb24gYnJvdWdodCB1cCBpbg0KDQpodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL29hdXRoL2hYRWZMWGdFcXJVUVZpN1F5OFhfMjc5RENOVQ0KDQoN CkRvZXMgYW55b25lIGhhdmUgY29uY2VybnMgd2l0aCBkcm9wcGluZyB0aGUgaW1wbGljaXQgZmxv dyBmcm9tIHRoZSBPQXV0aCAyLjEgZG9jdW1lbnQgc28gdGhhdCBkZXZlbG9wZXJzIGRvbid0IHVz ZSBpdD8NCg0KL0RpY2sNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K DQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogVG9yc3Rl biBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0Pj4NClRvOiBCcnVubyBCcml0byA8YmhkZWJyaXRvQGdtYWlsLmNvbTxtYWls dG86YmhkZWJyaXRvQGdtYWlsLmNvbT4+DQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo QGlldGYub3JnPg0KQmNjOg0KRGF0ZTogV2VkLCAxOSBGZWIgMjAyMCAwODoyNToxOSArMDEwMA0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggRGlnZXN0LCBWb2wgMTM2LCBJc3N1ZSA3DQpI aSBCcnVubywNCg0KdGhhbmtzIGZvciB5b3VyIGluc2lnaHRzLg0KDQpUaGUgcmVjb21tZW5kYXRp b24gaXMgbm90IG9ubHkgYmFzZWQgb24gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYnV0IGp1c3Qg dXRpbGl0eS4gQXMgc29vbiBhcyBvbmUgd2FudHMgdG8gaW50ZWdyYXRlIGZlZGVyYXRlZCBsb2dp biBvciBtdWx0aSBmYWN0b3IgYXV0aGVudGljYXRpb24sICBST1BHIHJlYWNoZXMgaXRzIGxpbWl0 cy4NCg0KTW9yZW92ZXIsIGhvdyBkbyB0aG9zZSB0ZWFtcyBpbXBsZW1lbnQgdXNlciByZWdpc3Ry YXRpb24gYW5kIHVzZXIgYWNjb3VudCByZWNvdmVyeT8gSW4gbXkgZXhwZXJpZW5jZSwgaW1wbGVt ZW50aW5nIHRoaXMgaW4gYSBuYXRpdmUgZXhwZXJpZW5jZSB3aWxsIHNpZ25pZmljYW50bHkgaW5j cmVhc2UgY29zdCBvZiB0aGUgaW1wbGVtZW50YXRpb24uDQoNClR3byByZWFzb25zIHRvIGdvIHdp dGggdGhlIGNvZGUgZmxvdy4NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KPiBBbSAxOS4w Mi4yMDIwIHVtIDAxOjQ5IHNjaHJpZWIgQnJ1bm8gQnJpdG8gPGJoZGVicml0b0BnbWFpbC5jb208 bWFpbHRvOmJoZGVicml0b0BnbWFpbC5jb20+PjoNCj4NCg0KDQoNCi0tLS0tLS0tLS0gRm9yd2Fy ZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFp bC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NClRvOiBBbnRob255IE5hZGFsaW4g PHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkNj OiAib2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpCY2M6DQpEYXRlOiBXZWQsIDE5IEZlYiAyMDIwIDEx OjM1OjAzIC0wODAwDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbRVhURVJOQUxdICBPQXV0aCAy LjE6IGRyb3BwaW5nIHBhc3N3b3JkIGdyYW50DQpUb255OiBhcmUgeW91IG9rIHdpdGggZHJvcHBp bmcgcGFzc3dvcmQgZ3JhbnQ/DQoNCllvdSByZWZlcmVuY2UgdmFsaWQgdXNlIGNhc2VzLiBJZiB5 b3UgdGhpbmsgaXQgc2hvdWxkIGNvbnRpbnVlLCB3b3VsZCB5b3UgcHJvdmlkZSB0aGUgdXNlIGNh c2VzPw0KDQpbSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuXeGQpw0KDQpPbiBUdWUsIEZlYiAxOCwg MjAyMCBhdCAxMjo1NyBQTSBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNClRoZSBzZWN1cml0eSB0b3BpY3Mgc2F5cyBN VVNULiBJZiB5b3Ugd2FudCB0byBjaGFuZ2UgdGhhdCwgdGhlbiB0aGF0IGlzIGEgZGlmZmVyZW50 IGRpc2N1c3Npb24uIDopDQoNCkluIHRoZSBPQXV0aCAyLjEgZG9jdW1lbnQsIGl0IHdvdWxkIGp1 c3Qgbm90IGJlIGluY2x1ZGVkLiBBcHBsaWNhdGlvbnMgY2FuIGNvbnRpbnVlIHRvIGJlIE9BdXRo IDIuMCBjb21wbGlhbnQuDQoNCkJVVCAuLi4gaWYgdGhlcmUgYXJlIHZhbGlkLCBuZXcgdXNlIGNh c2VzLiBQbGVhc2UgZGVzY3JpYmUgdGhlbSEgUGVyaGFwcyBpdCBzaG91bGQgbm90IGJlIGRyb3Bw ZWQuDQoNCg0KT24gVHVlLCBGZWIgMTgsIDIwMjAgYXQgMTI6NTQgUE0gQW50aG9ueSBOYWRhbGlu IDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KSSB3b3VsZCBzdWdnZXN0IGEgU0hPVUxEIE5PVCBpbnN0ZWFkIG9mIE1VU1QsIHRoZXJl IGFyZSBzdGlsbCBzaXRlcyB1c2luZyB0aGlzIGFuZCBhIGdyYWNlIHBlcmlvZCBzaG91bGQgYmUg cHJvdmlkZWQgYmVmb3JlIGEgTVVTVCBpcyBwdXNoZWQgb3V0IGFzIHRoZXJlIGFyZSB2YWxpZCB1 c2UgY2FzZXMgb3V0IHRoZXJlIHN0aWxsLg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBEaWNr IEhhcmR0DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAyMCAxMjozNyBQTQ0KVG86IG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtFWFRFUk5BTF0g W09BVVRILVdHXSBPQXV0aCAyLjE6IGRyb3BwaW5nIHBhc3N3b3JkIGdyYW50DQoNCkhleSBMaXN0 DQoNCihPbmNlIGFnYWluIHVzaW5nIHRoZSBPQXV0aCAyLjEgbmFtZSBhcyBhIHBsYWNlaG9sZGVy IGZvciB0aGUgZG9jIHRoYXQgQWFyb24sIFRvcnN0ZW4sIGFuZCBJIGFyZSB3b3JraW5nIG9uKQ0K DQpJbiB0aGUgc2VjdXJpdHkgdG9waWNzIGRvYw0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTQjc2VjdGlvbi0yLjQ8aHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3Bp Y3MtMTQlMjNzZWN0aW9uLTIuNCZkYXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNv bSU3QzQ3YmI1OTdlZWY1ODRjOTViYTQxMDhkN2I0YjI3NGIyJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3NjU1MDkwNTMzMzI4MyZzZGF0YT1uQTFTN1RC ZlpnNmNTd1kyaEk4aHBSWGhJQTJqb2FhSkZtTlhyQVRncjJZJTNEJnJlc2VydmVkPTA+DQoNClRo ZSBwYXNzd29yZCBncmFudCBNVVNUIG5vdCBiZSB1c2VkLg0KDQpTb21lIGJhY2tncm91bmQgZm9y IHRob3NlIGludGVyZXN0ZWQuIEkgYWRkZWQgdGhpcyBncmFudCBpbnRvIE9BdXRoIDIuMCB0byBh bGxvdyBhcHBsaWNhdGlvbnMgdGhhdCBoYWQgYmVlbiBwcm92aWRlZCBwYXNzd29yZCB0byBtaWdy YXRlLiBFdmVuIHdpdGggdGhlIGNhdmVhdHMgaW4gT0F1dGggMi4wLCBpbXBsZW1lbnRvcnMgZGVj aWRlIHRoZXkgd2FudCB0byBwcm9tcHQgdGhlIHVzZXIgdG8gZW50ZXIgdGhlaXIgY3JlZGVudGlh bHMsIHRoZSBhbnRpLXBhdHRlcm4gT0F1dGggd2FzIGNyZWF0ZWQgdG8gZWxpbWluYXRlLg0KDQoN CkRvZXMgYW55b25lIGhhdmUgY29uY2VybnMgd2l0aCBkcm9wcGluZyB0aGUgcGFzc3dvcmQgZ3Jh bnQgZnJvbSB0aGUgT0F1dGggMi4xIGRvY3VtZW50IHNvIHRoYXQgZGV2ZWxvcGVycyBkb24ndCB1 c2UgaXQ/DQoNCi9EaWNrDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_DDF7FE7CC17B4AE492E5998E1AC7DE8Dopenitiocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C2E6E3084F4AC42AABBD7D7C8831C68@GBRP265.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkdhZHVnaTsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIg Mzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxMzMxNTYxODI1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTYzNzE3MTkwOCA5MDM1MDI4ODYgMTM0ODA3NTU1IDEzNDgwNzU1 NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgw NzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhlbGxvIEFsbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGhhdmUgcmVj ZW50bHkgam9pbmVkIHRoaXMgd29ya2luZyBncm91cCBidXQgaGF2ZSBJIGhhdmUgYmVlbiBJQU0g Y29uc3VsdGFudCBmb3IgMTUmIzQzOyB5ZWFycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pk15IG9waW5pb24gYW5kIGV4cGVyaWVuY2Ugb24gZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkltcGxp Y2l0IEdyYW50IOKAkyBEZWZpbml0ZWx5IERyb3BwZWQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlBhc3N3b3JkIEdyYW50IOKAkyBEZWZpbml0ZWx5IERyb3BwZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBo YWQgc28gbWFueSBjb252ZXJzYXRpb24gd2l0aCBBcHAgKFdFQi9NT0JJTEUpIGRldmVsb3BlcnMg b24gTk9UIHVzaW5nIHRoZW0gaW4gbGFzdCBmZXcgeWVhcnMsIG5vdyB3aXRoIHJldmlzZWQgMi4x IHdlIGNhbiBhdm9pZCB0aG9zZSBjb252ZXJzYXRpb25zLiBBbHRob3VnaCB0aGVzZSBncmFudHMg bWFkZSBpdCBsb29rIGxlc3MgY29tcGxleA0KIGJ1dCBuZXZlciByZWFsbHkgYWxpZ25lZCB0byB1 dGlsaXNlIHRoZSBmdWxsIHNlY3VyaXR5IG9mIE9BVVRIMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBmYXZvdXIgdGhlIHZv dGUgdG8gZHJvcCB0aGVtIGZvciBnb29kIGFuZCBtYWtlIE9hdXRoIDIuMSBjbGVhbiBhcyBmb2xs b3dpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+QXV0aG9yaXNhdGlvbiBDb2RlIEdyYW50czxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkNsaWVudCBDcmVkZW50aWFsczxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJodXBpbmRlciBTaW5naDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0 OyBvbiBiZWhhbGYgb2YgQnJ1bm8gQnJpdG8gJmx0O2JoZGVicml0b0BnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgMTkgRmVicnVhcnkgMjAyMCBhdCAyMDoyMTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBPQXV0aCBEaWdlc3QsIFZv bCAxMzYsIElzc3VlIDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMzMzMzMzMiPk5vLCBJIGNhbm5vdCBzZWUgYW55IHVzZSBjYXNlIHdoZXJlIGF1dGhv cml6YXRpb24gY29kZSBjYW5ub3QgcmVwbGFjZSBpbXBsaWNpdC4gR28gYWhlYWQgYW5kIHJlbW92 ZSBpdCE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMzMzMzMzMiPkJydW5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTksIDIwMjAgYXQgNTowMSBQTSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmciPm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmc8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlbmQgT0F1dGggbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxicj4NClRvIHN1 YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQpvciwgdmlhIGVtYWlsLCBzZW5k IGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG88YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aC1yZXF1ZXN0QGlldGYub3JnPC9hPjxicj4NCjxicj4NCllv dSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86b2F1dGgtb3duZXJAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aC1vd25lckBpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQpXaGVu IHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNw ZWNpZmljPGJyPg0KdGhhbiAmcXVvdDtSZTogQ29udGVudHMgb2YgT0F1dGggZGlnZXN0Li4uJnF1 b3Q7PGJyPg0KVG9kYXkncyBUb3BpY3M6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOzEuIFJlOiBP QXV0aCAyLjEgLSBkcm9wIGltcGxpY2l0IGZsb3c/IChEb21pbmljayBCYWllcik8YnI+DQombmJz cDsgJm5ic3A7Mi4gUmU6IE9BdXRoIERpZ2VzdCwgVm9sIDEzNiwgSXNzdWUgNyAoVG9yc3RlbiBM b2RkZXJzdGVkdCk8YnI+DQombmJzcDsgJm5ic3A7My4gUmU6IFtFWFRFUk5BTF0mbmJzcDsgT0F1 dGggMi4xOiBkcm9wcGluZyBwYXNzd29yZCBncmFudCAoRGljayBIYXJkdCk8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpG cm9tOiZuYnNwO0RvbWluaWNrIEJhaWVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGJhaWVyQGxlYXN0 cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiYWllckBsZWFzdHByaXZpbGVnZS5jb208 L2E+Jmd0Ozxicj4NClRvOiZuYnNwO0RpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h PiZndDssDQo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5v YXV0aEBpZXRmLm9yZzwvYT48YnI+DQpDYzombmJzcDs8YnI+DQpCY2M6Jm5ic3A7PGJyPg0KRGF0 ZTombmJzcDtUdWUsIDE4IEZlYiAyMDIwIDIyOjQ5OjA1IC0wODAwPGJyPg0KU3ViamVjdDombmJz cDtSZTogW09BVVRILVdHXSBPQXV0aCAyLjEgLSBkcm9wIGltcGxpY2l0IGZsb3c/PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Tm8gLSBwbGVhc2UgZ2V0IHJp ZCBvZiBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKA lOKAlOKAlCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb21p bmljayBCYWllcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+T24gMTguIEZlYnJ1YXJ5IDIwMjAgYXQg MjE6MzI6MzEsIERpY2sgSGFyZHQgKDxhIGhyZWY9Im1haWx0bzpkaWNrLi5oYXJkdEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4pIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGV5IExpc3QmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KEknbSB1c2luZyB0aGUgT0F1dGggMi4xIG5hbWUgYXMgYSBwbGFj ZWhvbGRlciBmb3IgdGhlIGRvYyB0aGF0IEFhcm9uLCBUb3JzdGVuLCBhbmQgSSBhcmUgd29ya2lu ZyBvbik8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVu IHRoZSBwb2ludHMgQWFyb24gYnJvdWdodCB1cCBpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL29hdXRoL2hYRWZMWGdFcXJVUVZpN1F5OFhfMjc5RENOVSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgv aFhFZkxYZ0VxclVRVmk3UXk4WF8yNzlEQ05VPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgYW55b25lIGhhdmUgY29uY2VybnMg d2l0aCBkcm9wcGluZyB0aGUgaW1wbGljaXQgZmxvdyBmcm9tIHRoZSBPQXV0aCAyLjEgZG9jdW1l bnQgc28gdGhhdCBkZXZlbG9wZXJzIGRvbid0IHVzZSBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L0RpY2s8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIDxicj4NCk9BdXRoIG1haWxpbmcgbGlz dCA8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxicj4NCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZy b206Jm5ic3A7VG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8 L2E+Jmd0Ozxicj4NClRvOiZuYnNwO0JydW5vIEJyaXRvICZsdDs8YSBocmVmPSJtYWlsdG86Ymhk ZWJyaXRvQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJoZGVicml0b0BnbWFpbC5jb208L2E+ Jmd0Ozxicj4NCkNjOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCkJjYzombmJzcDs8YnI+DQpEYXRlOiZu YnNwO1dlZCwgMTkgRmViIDIwMjAgMDg6MjU6MTkgJiM0MzswMTAwPGJyPg0KU3ViamVjdDombmJz cDtSZTogW09BVVRILVdHXSBPQXV0aCBEaWdlc3QsIFZvbCAxMzYsIElzc3VlIDc8YnI+DQpIaSBC cnVubyw8YnI+DQo8YnI+DQp0aGFua3MgZm9yIHlvdXIgaW5zaWdodHMuPGJyPg0KPGJyPg0KVGhl IHJlY29tbWVuZGF0aW9uIGlzIG5vdCBvbmx5IGJhc2VkIG9uIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGJ1dCBqdXN0IHV0aWxpdHkuIEFzIHNvb24gYXMgb25lIHdhbnRzIHRvIGludGVncmF0ZSBm ZWRlcmF0ZWQgbG9naW4gb3IgbXVsdGkgZmFjdG9yIGF1dGhlbnRpY2F0aW9uLCZuYnNwOyBST1BH IHJlYWNoZXMgaXRzIGxpbWl0cy48YnI+DQo8YnI+DQpNb3Jlb3ZlciwgaG93IGRvIHRob3NlIHRl YW1zIGltcGxlbWVudCB1c2VyIHJlZ2lzdHJhdGlvbiBhbmQgdXNlciBhY2NvdW50IHJlY292ZXJ5 PyBJbiBteSBleHBlcmllbmNlLCBpbXBsZW1lbnRpbmcgdGhpcyBpbiBhIG5hdGl2ZSBleHBlcmll bmNlIHdpbGwgc2lnbmlmaWNhbnRseSBpbmNyZWFzZSBjb3N0IG9mIHRoZSBpbXBsZW1lbnRhdGlv bi48YnI+DQo8YnI+DQpUd28gcmVhc29ucyB0byBnbyB3aXRoIHRoZSBjb2RlIGZsb3cuPGJyPg0K PGJyPg0KYmVzdCByZWdhcmRzLDxicj4NClRvcnN0ZW4uPGJyPg0KPGJyPg0KJmd0OyBBbSAxOS4w Mi4yMDIwIHVtIDAxOjQ5IHNjaHJpZWIgQnJ1bm8gQnJpdG8gJmx0OzxhIGhyZWY9Im1haWx0bzpi aGRlYnJpdG9AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmhkZWJyaXRvQGdtYWlsLmNvbTwv YT4mZ3Q7Ojxicj4NCiZndDsgPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtEaWNrIEhhcmR0ICZsdDs8 YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNr LmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KVG86Jm5ic3A7QW50aG9ueSBOYWRhbGluICZs dDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQpDYzombmJzcDsmcXVvdDs8YSBocmVm PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQpCY2M6Jm5ic3A7PGJyPg0KRGF0ZTombmJz cDtXZWQsIDE5IEZlYiAyMDIwIDExOjM1OjAzIC0wODAwPGJyPg0KU3ViamVjdDombmJzcDtSZTog W09BVVRILVdHXSBbRVhURVJOQUxdJm5ic3A7IE9BdXRoIDIuMTogZHJvcHBpbmcgcGFzc3dvcmQg Z3JhbnQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub255OiBh cmUgeW91IG9rIHdpdGggZHJvcHBpbmcgcGFzc3dvcmQgZ3JhbnQ/IDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IHJlZmVyZW5jZSB2YWxpZCB1c2UgY2Fz ZXMuIElmIHlvdSB0aGluayBpdCBzaG91bGQgY29udGludWUsIHdvdWxkIHlvdSBwcm92aWRlIHRo ZSB1c2UgY2FzZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MGNtIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMyIiBoZWlnaHQ9IjMyIiBz dHlsZT0id2lkdGg6LjMzMzNpbjtoZWlnaHQ6LjMzMzNpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3Jj PSJjaWQ6fldSRDAwMDEuanBnIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiI+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDE4LCAyMDIwIGF0IDEyOjU3 IFBNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIHNlY3VyaXR5IHRvcGljcyBzYXlzIE1VU1QuIElmIHlvdSB3YW50IHRvIGNoYW5nZSB0 aGF0LCB0aGVuIHRoYXQgaXMgYSBkaWZmZXJlbnQgZGlzY3Vzc2lvbi4gOikNCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIE9BdXRoIDIuMSBkb2N1 bWVudCwgaXQgd291bGQganVzdCBub3QgYmUgaW5jbHVkZWQuIEFwcGxpY2F0aW9ucyBjYW4gY29u dGludWUgdG8gYmUgT0F1dGggMi4wIGNvbXBsaWFudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlVUIC4uLiBpZiB0aGVyZSBhcmUgdmFsaWQs IG5ldyB1c2UgY2FzZXMuIFBsZWFzZSBkZXNjcmliZSB0aGVtISBQZXJoYXBzIGl0IHNob3VsZCBu b3QgYmUgZHJvcHBlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxOCwgMjAyMCBhdCAxMjo1NCBQTSBBbnRob255IE5h ZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3b3VsZCBzdWdnZXN0IGEgU0hPVUxEIE5PVCBpbnN0 ZWFkIG9mIE1VU1QsIHRoZXJlIGFyZSBzdGlsbCBzaXRlcyB1c2luZyB0aGlzIGFuZCBhIGdyYWNl IHBlcmlvZCBzaG91bGQgYmUgcHJvdmlkZWQgYmVmb3JlIGEgTVVTVCBpcyBwdXNoZWQgb3V0IGFz IHRoZXJlIGFyZQ0KIHZhbGlkIHVzZSBjYXNlcyBvdXQgdGhlcmUgc3RpbGwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gT0F1dGgg Jmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRp Y2sgSGFyZHQ8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMTgsIDIwMjAgMTI6 MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhU RVJOQUxdIFtPQVVUSC1XR10gT0F1dGggMi4xOiBkcm9wcGluZyBwYXNzd29yZCBncmFudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IZXkgTGlzdCZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PihPbmNlIGFnYWluIHVzaW5nIHRoZSBPQXV0aCAyLjEgbmFtZSBhcyBhIHBsYWNlaG9sZGVyIGZv ciB0aGUgZG9jIHRoYXQgQWFyb24sIFRvcnN0ZW4sIGFuZCBJIGFyZSB3b3JraW5nIG9uKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiB0aGUgc2VjdXJpdHkg dG9waWNzIGRvYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWll dGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE0JTIzc2VjdGlvbi0yLjQmYW1wO2RhdGE9MDIlN0Mw MSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDNDdiYjU5N2VlZjU4NGM5NWJhNDEwOGQ3YjRi Mjc0YjIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTc2 NTUwOTA1MzMzMjgzJmFtcDtzZGF0YT1uQTFTN1RCZlpnNmNTd1kyaEk4aHBSWGhJQTJqb2FhSkZt TlhyQVRncjJZJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE0I3NlY3Rp b24tMi40PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoZSBwYXNzd29yZCBncmFudCBNVVNUIG5vdCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvbWUgYmFja2dyb3VuZCBm b3IgdGhvc2UgaW50ZXJlc3RlZC4gSSBhZGRlZCB0aGlzIGdyYW50IGludG8gT0F1dGggMi4wIHRv IGFsbG93IGFwcGxpY2F0aW9ucyB0aGF0IGhhZCBiZWVuIHByb3ZpZGVkIHBhc3N3b3JkIHRvIG1p Z3JhdGUuIEV2ZW4gd2l0aCB0aGUgY2F2ZWF0cw0KIGluIE9BdXRoIDIuMCwgaW1wbGVtZW50b3Jz IGRlY2lkZSB0aGV5IHdhbnQgdG8gcHJvbXB0IHRoZSB1c2VyIHRvIGVudGVyIHRoZWlyIGNyZWRl bnRpYWxzLCB0aGUgYW50aS1wYXR0ZXJuIE9BdXRoIHdhcyBjcmVhdGVkIHRvIGVsaW1pbmF0ZS4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Eb2VzIGFueW9uZSBoYXZlIGNvbmNlcm5z IHdpdGggZHJvcHBpbmcgdGhlIHBhc3N3b3JkIGdyYW50IGZyb20gdGhlIE9BdXRoIDIuMSBkb2N1 bWVudCBzbyB0aGF0IGRldmVsb3BlcnMgZG9uJ3QgdXNlIGl0PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi9EaWNrPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_DDF7FE7CC17B4AE492E5998E1AC7DE8Dopenitiocom_-- From nobody Fri Feb 21 05:41:59 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF821200E7 for ; Fri, 21 Feb 2020 05:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coil.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D17cJAkFPp4S for ; Fri, 21 Feb 2020 05:41:53 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B7D12081A for ; Fri, 21 Feb 2020 05:41:53 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id g19so2348666eds.11 for ; Fri, 21 Feb 2020 05:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=e8o4ehQRxjtHeIpmXld8imyIfX5Un7vbOJRis9jo4BA=; b=EDPAIten2OP7gNsSBwT+u/UFcHKZzu0onK99pwOk3JOTvjJjHRlHVzqbAz1sR3oi3p Hv5Mvz2ErubBC3DPMpKTYcHMs4wV4EnFpYhoV4lQ7OJWy49pjNg4qJ6ERmlbrJi1lBoQ g+4llwPF3pwLJjJn5HWxYbL7zNmP6w+ZCH28fPrGxOfH61yKQUz61VS52QO1Es6Wl2Ui +rBMv/0r7xtqx+tfj32pkwGjckZ+micC/5VMJgtZiy937+r4yL+hrxRUbQuNmEA3d0mq +izl0YV7/16yx/EnOriyutbq5xBHI3+YdSpQ3r+jD2Of2R76oOvcYw4Jw083qor5FsdR H5Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=e8o4ehQRxjtHeIpmXld8imyIfX5Un7vbOJRis9jo4BA=; b=k/u3x+/tp1vi95jvmgAKE1atvdiUxXtG2mOe/k5c6nS4pq+LL7a8L0w9CtHvPNzU4d Zp9TeoIpGThU3Ou5Gw9z7XM8LCVNFX6uzw7wxa5V5l8r8zlPQbIuM9q54dxDwThld1B5 X34/da3FF+Xr5UJ2dl5bZWPVBXrXXzYhQ1mXlPbQJt1G5U86tCeOxlg5nrDuHT1W8YkR 001Ve8+sh3svKK6kvPkuFs9uXIXJoBth48/97Eze2JpJnjtOqX8pqp3h6OlA23zHIfwy Ja2XN05ozQ4zvaRONB77UOdbPu5OWDHdUmLNGYZwCMaGHDvF9pKccYe/gQN3pLVm5tmH vzyQ== X-Gm-Message-State: APjAAAXXoHuamol6PrWs/D6PmIoX+dzntYzlWpqub0594jrHwZxEyKv9 ISWUSFh3+C7oq5NC6NP0hcpPufeVEhkDA/dHbVoqoQzgU3Y= X-Google-Smtp-Source: APXvYqzSXuh8bylscRHPP5F5GPBgPZ/mAKHsdD1HgTIe34cMMZaILSAiWGgXB+0FFujvZaoE2QhwazFCG7eGcEyNE1o= X-Received: by 2002:a17:906:3798:: with SMTP id n24mr35560023ejc.15.1582292511378; Fri, 21 Feb 2020 05:41:51 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> In-Reply-To: <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> From: Matthew De Haast Date: Fri, 21 Feb 2020 15:41:36 +0200 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000125ff4059f162f61" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 13:41:57 -0000 --000000000000125ff4059f162f61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again the= n > we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s an > incentive to make that happen. > Neil could you elaborate more on this please. What failures are you currently experiencing/seeing with the JWT Bearer grant? Matt On Thu, Feb 20, 2020 at 12:42 AM Neil Madden wrote: > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again the= n > we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s an > incentive to make that happen. > > > > On 19 Feb 2020, at 22:01, Dick Hardt wrote: > > > > Neil: are you advocating that password grant be preserved in 2.1? Or do > you think that service account developers know enough about what they are > doing to follow what is in 6749? > > =E1=90=A7 > > > > On Wed, Feb 19, 2020 at 1:52 PM Neil Madden > wrote: > > OAuth2 clients are often private to the AS - they live in a database > that only the AS can access, have attributes specific to their use in > OAuth2, and so on. Many existing systems have access controls based on > users, roles, permissions and so on and expect all users accessing the > system to exist in some user repository, e.g. LDAP, where they can be > looked up and appropriate permissions determined. A service account can b= e > created inside such a system as if it was a regular user, managed through > the normal account provisioning tools, assigned permissions, roles, etc. > > > > Another reason is that sometimes OAuth is just one authentication optio= n > out of many, and so permissions assigned to service accounts are preferre= d > over scopes because they are consistently applied no matter how a request > is authenticated. This is often the case when OAuth has been retrofitted = to > an existing system and they need to preserve compatibility with already > deployed clients. > > > > See e.g. Google cloud platform (GCP): > https://developers.google.com/identity/protocols/OAuth2ServiceAccount > > They use the JWT bearer grant type for service account authentication > and assign permissions to those service accounts and typically have very > broad scopes. For service-to-service API calls you typically get an acces= s > token with a single scope that is effectively =E2=80=9Call of GCP=E2=80= =9D and everything > is managed at the level of permissions on the RO service account itself. > They only break down fine-grained scopes when you are dealing with user > data and will be getting an access token approved by a real user (through= a > normal auth code flow). > > > > =E2=80=94 Neil > > > > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt > wrote: > > > > > > Can you explain more in detail why the client credentials grant type > isn=E2=80=99t applicable for the kind of use cases you mentioned? > > > > > >> Am 19.02.2020 um 22:03 schrieb Neil Madden >: > > >> > > >> =EF=BB=BFI very much agree with this with regards to real users. > > >> > > >> The one legitimate use-case for ROPC I=E2=80=99ve seen is for servic= e > accounts - where you essentially want something like client_credentials b= ut > for whatever reason you need the RO to be a service user rather than an > OAuth2 client (typically so that some lower layer of the system can still > perform its required permission checks). > > >> > > >> There are better grant types for this - e.g. JWT bearer - but they > are a bit harder to implement. Having recently converted some code from > ROPC to JWT bearer for exactly this use-case, it went from a couple of > lines of code to two screens of code. For service to service API calls > within a datacenter I=E2=80=99m not convinced this resulted in a material= increase > in security for the added complexity. > > >> > > >> =E2=80=94 Neil > > >> > > >>> On 18 Feb 2020, at 21:57, Hans Zandbelt > wrote: > > >>> > > >>> I would also seriously look at the original motivation behind ROPC: > I know it has been deployed and is used in quite a lot of places but I ha= ve > never actually come across a use case where it is used for migration > purposes and the migration is actually executed (I know that is > statistically not a very strong argument but I challenge others to come u= p > with one...) > > >>> In reality it turned out just to be a one off that people used as a= n > easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. > It is plain wrong, it is not OAuth and we need to get rid of it. > > >>> > > >>> Hans. > > >>> > > >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki > wrote: > > >>> Agreed. Plus, the Security BCP is already effectively acting as a > grace period since it currently says the password grant MUST NOT be used, > so in the OAuth 2.0 world that's already a pretty strong signal. > > >>> > > >>> Aaron > > >>> > > >>> > > >>> > > >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer > wrote: > > >>> There is no need for a grace period. People using OAuth 2.0 can > still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. > > >>> > > >>> =E2=80=94 Justin > > >>> > > >>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote: > > >>>> > > >>>> I would suggest a SHOULD NOT instead of MUST, there are still site= s > using this and a grace period should be provided before a MUST is pushed > out as there are valid use cases out there still. > > >>>> > > >>>> From: OAuth On Behalf Of Dick Hardt > > >>>> Sent: Tuesday, February 18, 2020 12:37 PM > > >>>> To: oauth@ietf.org > > >>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > > >>>> > > >>>> Hey List > > >>>> > > >>>> (Once again using the OAuth 2.1 name as a placeholder for the doc > that Aaron, Torsten, and I are working on) > > >>>> > > >>>> In the security topics doc > > >>>> > > >>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > > >>>> > > >>>> The password grant MUST not be used. > > >>>> > > >>>> Some background for those interested. I added this grant into OAut= h > 2.0 to allow applications that had been provided password to migrate. Eve= n > with the caveats in OAuth 2.0, implementors decide they want to prompt th= e > user to enter their credentials, the anti-pattern OAuth was created to > eliminate. > > >>>> > > >>>> > > >>>> Does anyone have concerns with dropping the password grant from th= e > OAuth 2.1 document so that developers don't use it? > > >>>> > > >>>> /Dick > > >>>> _______________________________________________ > > >>>> OAuth mailing list > > >>>> OAuth@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/oauth > > >>> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>> -- > > >>> ---- > > >>> Aaron Parecki > > >>> aaronparecki.com > > >>> @aaronpk > > >>> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>> > > >>> > > >>> -- > > >>> hans.zandbelt@zmartzone.eu > > >>> ZmartZone IAM - www.zmartzone.eu > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > 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 > --000000000000125ff4059f162f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a= feeling that if we had more concise JWT libraries and command=20 line tools, where using the JWT Bearer grant became a one-liner again=20 then we wouldn=E2=80=99t be having this conversation. So perhaps removing i= t is=20 an incentive to make that happen.

Neil could you elaborate more on this please. Wh= at failures are you currently experiencing/seeing with the JWT Bearer grant= ?

Matt

On Thu, Feb 20, 2020 at 12:42= AM Neil Madden <neil.madde= n@forgerock.com> wrote:
I have a feeling that if we had more concise JWT libraries a= nd command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps remo= ving it is an incentive to make that happen.


> On 19 Feb 2020, at 22:01, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Neil: are you advocating that password grant be preserved in 2.1? Or d= o you think that service account developers know enough about what they are= doing to follow what is in 6749?
> =E1=90=A7
>
> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@forgerock.com> = wrote:
> OAuth2 clients are often private to the AS - they live in a database t= hat only the AS can access, have attributes specific to their use in OAuth2= , and so on. Many existing systems have access controls based on users, rol= es, permissions and so on and expect all users accessing the system to exis= t in some user repository, e.g. LDAP, where they can be looked up and appro= priate permissions determined. A service account can be created inside such= a system as if it was a regular user, managed through the normal account p= rovisioning tools, assigned permissions, roles, etc.
>
> Another reason is that sometimes OAuth is just one authentication opti= on out of many, and so permissions assigned to service accounts are preferr= ed over scopes because they are consistently applied no matter how a reques= t is authenticated. This is often the case when OAuth has been retrofitted = to an existing system and they need to preserve compatibility with already = deployed clients.
>
> See e.g. Google cloud platform (GCP): https://developers.google.com/identity/protocols/OAuth2ServiceA= ccount
> They use the JWT bearer grant type for service account authentication = and assign permissions to those service accounts and typically have very br= oad scopes. For service-to-service API calls you typically get an access to= ken with a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D an= d everything is managed at the level of permissions on the RO service accou= nt itself. They only break down fine-grained scopes when you are dealing wi= th user data and will be getting an access token approved by a real user (t= hrough a normal auth code flow).
>
> =E2=80=94 Neil
>
> > On 19 Feb 2020, at 21:35, Torsten Lodderstedt <torsten@lodderstedt.net&g= t; wrote:
> >
> > Can you explain more in detail why the client credentials grant t= ype isn=E2=80=99t applicable for the kind of use cases you mentioned?
> >
> >> Am 19.02.2020 um 22:03 schrieb Neil Madden <neil.madden@forgerock.com<= /a>>:
> >>
> >> =EF=BB=BFI very much agree with this with regards to real use= rs.
> >>
> >> The one legitimate use-case for ROPC I=E2=80=99ve seen is for= service accounts - where you essentially want something like client_creden= tials but for whatever reason you need the RO to be a service user rather t= han an OAuth2 client (typically so that some lower layer of the system can = still perform its required permission checks).
> >>
> >> There are better grant types for this - e.g. JWT bearer - but= they are a bit harder to implement. Having recently converted some code fr= om ROPC to JWT bearer for exactly this use-case, it went from a couple of l= ines of code to two screens of code. For service to service API calls withi= n a datacenter I=E2=80=99m not convinced this resulted in a material increa= se in security for the added complexity.
> >>
> >> =E2=80=94 Neil
> >>
> >>> On 18 Feb 2020, at 21:57, Hans Zandbelt <hans.zandbelt@zmartzone.= eu> wrote:
> >>>
> >>> I would also seriously look at the original motivation be= hind ROPC: I know it has been deployed and is used in quite a lot of places= but I have never actually come across a use case where it is used for migr= ation purposes and the migration is actually executed (I know that is stati= stically not a very strong argument but I challenge others to come up with = one...)
> >>> In reality it turned out just to be a one off that people= used as an easy way out to stick to an anti-pattern and still claim to do = OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.=
> >>>
> >>> Hans.
> >>>
> >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <aaron@parecki.com> = wrote:
> >>> Agreed. Plus, the Security BCP is already effectively act= ing as a grace period since it currently says the password grant MUST NOT b= e used, so in the OAuth 2.0 world that's already a pretty strong signal= .
> >>>
> >>> Aaron
> >>>
> >>>
> >>>
> >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrote= :
> >>> There is no need for a grace period. People using OAuth 2= .0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
> >>>
> >>> =E2=80=94 Justin
> >>>
> >>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <= tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:
> >>>>
> >>>> I would suggest a SHOULD NOT instead of MUST, there a= re still sites using this and a grace period should be provided before a MU= ST is pushed out as there are valid use cases out there still.
> >>>>
> >>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Har= dt
> >>>> Sent: Tuesday, February 18, 2020 12:37 PM
> >>>> To: oauth@ietf.org
> >>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping pa= ssword grant
> >>>>
> >>>> Hey List
> >>>>
> >>>> (Once again using the OAuth 2.1 name as a placeholder= for the doc that Aaron, Torsten, and I are working on)
> >>>>
> >>>> In the security topics doc
> >>>>
> >>>> htt= ps://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
> >>>>
> >>>> The password grant MUST not be used.
> >>>>
> >>>> Some background for those interested. I added this gr= ant into OAuth 2.0 to allow applications that had been provided password to= migrate. Even with the caveats in OAuth 2.0, implementors decide they want= to prompt the user to enter their credentials, the anti-pattern OAuth was = created to eliminate.
> >>>>
> >>>>
> >>>> Does anyone have concerns with dropping the password = grant from the OAuth 2.1 document so that developers don't use it?
> >>>>
> >>>> /Dick
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> O= Auth@ietf.org
> >>>> https://www.ietf.org/mailman/listin= fo/oauth
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth= @ietf.org
> >>> https://www.ietf.org/mailman/listinfo/o= auth
> >>> --
> >>> ----
> >>> Aaron Parecki
> >>> aaronparecki.com
> >>> @aaronpk
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth= @ietf.org
> >>> https://www.ietf.org/mailman/listinfo/o= auth
> >>>
> >>>
> >>> --
> >>> hans.zandbelt@zmartzone.eu
> >>> ZmartZone IAM - www.zmartzone.eu
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth= @ietf.org
> >>> https://www.ietf.org/mailman/listinfo/o= auth
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/oau= th
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000125ff4059f162f61-- From nobody Fri Feb 21 06:12:27 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FEB1200F9 for ; Fri, 21 Feb 2020 06:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 nxyTLyPM4GYb for ; Fri, 21 Feb 2020 06:12:10 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F37120844 for ; Fri, 21 Feb 2020 06:12:10 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id m10so5277896wmc.0 for ; Fri, 21 Feb 2020 06:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QUUcs0eKPwOA5jiKE5lIhIiKA8f6ui83rGavEteFjrQ=; b=LD+jjycaEftKCtkWVgo0hIX98TheROoUUXvX8umV5t/VDTdzXkUSVsvrb3Q+Ps/YyB tQFa7RIUxTmolJAmEE53x4IAYbB24ywMvqsf9C45lWf9cbJhGTuVNtVlvCDKjW1cmK/5 M3MpmR9wSHLCHyjqQ7UtUVzt5vv2ih8VIVxLw= 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=QUUcs0eKPwOA5jiKE5lIhIiKA8f6ui83rGavEteFjrQ=; b=PnEOgJ6EkH1IPBqVCwGl5kkR/pVAM8wRNpzn0Kb0ip81yaxPRFwvPatG/34zzhH8Jz ITg/cXN8CvgRCtzsYXL/cftPSqQ1sMlYMEAGc+Wn5tUGIFBoiu0cmV/FsPbJOdA+0wwl B+WmtS9QaZD3h0tNKqhpzvbVZN1GPdTza03qmTKmQiXPh9+WcPLRIt5clNK2L5ZXKesA SWjBMfFw1zjZVFm10iPkh5jKV8rdBm167xJgSSsNX1Vg3AjWMgLzW0lp3bOw5HgASWWr NSVBtpuZdaxck2AqNcuS93R50OPxQjZALVSKJbz339GIjqJva5snVJmdIssIB/88IvSs 9VxQ== X-Gm-Message-State: APjAAAUlvNk494UozrY9K6GMjjc1RD+VlJxK7Aclwnq9eHr90dQdWgcB YOx58cIu94AXtJS9D331gFt9uzSDr74UqA== X-Google-Smtp-Source: APXvYqwCyPmg60scm+ofYVUa96SEA0eH4vViQYVT4OFUVYsJrAXuZcoX0mGxUQIUSGYeKMLs79ty1A== X-Received: by 2002:a05:600c:204f:: with SMTP id p15mr4308985wmg.6.1582294328427; Fri, 21 Feb 2020 06:12:08 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id b67sm4313276wmc.38.2020.02.21.06.12.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 06:12:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: Date: Fri, 21 Feb 2020 14:12:06 +0000 Cc: "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> To: Matthew De Haast X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:12:26 -0000 No failures, but it is a much more complex grant type to set up, when = you consider everything you have to do: * work out if the AS even supports JWT bearer and how to turn it on * work out how to configure the AS to trust my public key(s) - do I have to create a new HTTPS endpoint to publish a JWK Set? * determine the correct settings for issuer, audience, subject, etc. = Does the AS impose non-standard requirements? e.g. RFC 7523 says that = the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, = plain OAuth ones might not) If I do, can I reuse the JWT or must it be = freshly signed for every call? * locate and evaluate a JWT library for my language of choice. Monitor = that new dependency for security advisories. * choose a suitable signature algorithm (=E2=80=98ere be dragons) * figure out how to distribute the private key to my service Compared to =E2=80=9Ccreate a service account and POST the username and = password to the token endpoint=E2=80=9D it adds a little friction. (It = also adds a lot of advantages, but it is undeniably more complex). =E2=80=94 Neil > On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >=20 > I have a feeling that if we had more concise JWT libraries and command = line tools, where using the JWT Bearer grant became a one-liner again = then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >=20 > Neil could you elaborate more on this please. What failures are you = currently experiencing/seeing with the JWT Bearer grant?=20 >=20 > Matt >=20 > On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: > I have a feeling that if we had more concise JWT libraries and command = line tools, where using the JWT Bearer grant became a one-liner again = then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >=20 >=20 > > On 19 Feb 2020, at 22:01, Dick Hardt wrote: > >=20 > > Neil: are you advocating that password grant be preserved in 2.1? Or = do you think that service account developers know enough about what they = are doing to follow what is in 6749? > > =E1=90=A7 > >=20 > > On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: > > OAuth2 clients are often private to the AS - they live in a database = that only the AS can access, have attributes specific to their use in = OAuth2, and so on. Many existing systems have access controls based on = users, roles, permissions and so on and expect all users accessing the = system to exist in some user repository, e.g. LDAP, where they can be = looked up and appropriate permissions determined. A service account can = be created inside such a system as if it was a regular user, managed = through the normal account provisioning tools, assigned permissions, = roles, etc. > >=20 > > Another reason is that sometimes OAuth is just one authentication = option out of many, and so permissions assigned to service accounts are = preferred over scopes because they are consistently applied no matter = how a request is authenticated. This is often the case when OAuth has = been retrofitted to an existing system and they need to preserve = compatibility with already deployed clients. > >=20 > > See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount > > They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). > >=20 > > =E2=80=94 Neil > >=20 > > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: > > >=20 > > > Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? > > >=20 > > >> Am 19.02.2020 um 22:03 schrieb Neil Madden = : > > >>=20 > > >> =EF=BB=BFI very much agree with this with regards to real users.=20= > > >>=20 > > >> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). > > >>=20 > > >> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. > > >>=20 > > >> =E2=80=94 Neil > > >>=20 > > >>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: > > >>>=20 > > >>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) > > >>> In reality it turned out just to be a one off that people used = as an easy way out to stick to an anti-pattern and still claim to do = OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of = it. > > >>>=20 > > >>> Hans. > > >>>=20 > > >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: > > >>> Agreed. Plus, the Security BCP is already effectively acting as = a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. > > >>>=20 > > >>> Aaron > > >>>=20 > > >>>=20 > > >>>=20 > > >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: > > >>> There is no need for a grace period. People using OAuth 2..0 can = still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 > > >>>=20 > > >>> =E2=80=94 Justin > > >>>=20 > > >>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: > > >>>>=20 > > >>>> I would suggest a SHOULD NOT instead of MUST, there are still = sites using this and a grace period should be provided before a MUST is = pushed out as there are valid use cases out there still. > > >>>>=20 > > >>>> From: OAuth On Behalf Of Dick Hardt > > >>>> Sent: Tuesday, February 18, 2020 12:37 PM > > >>>> To: oauth@ietf.org > > >>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant > > >>>>=20 > > >>>> Hey List=20 > > >>>>=20 > > >>>> (Once again using the OAuth 2.1 name as a placeholder for the = doc that Aaron, Torsten, and I are working on) > > >>>>=20 > > >>>> In the security topics doc > > >>>>=20 > > >>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 > > >>>>=20 > > >>>> The password grant MUST not be used. > > >>>>=20 > > >>>> Some background for those interested. I added this grant into = OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 > > >>>>=20 > > >>>>=20 > > >>>> Does anyone have concerns with dropping the password grant from = the OAuth 2.1 document so that developers don't use it? > > >>>>=20 > > >>>> /Dick > > >>>> _______________________________________________ > > >>>> 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 > > >>> ---- > > >>> Aaron Parecki > > >>> aaronparecki.com > > >>> @aaronpk > > >>>=20 > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>>=20 > > >>>=20 > > >>> --=20 > > >>> hans.zandbelt@zmartzone.eu > > >>> ZmartZone IAM - www.zmartzone.eu > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Feb 21 06:20:57 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79B9120825 for ; Fri, 21 Feb 2020 06:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ubity0HMXNvy for ; Fri, 21 Feb 2020 06:20:51 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84917120033 for ; Fri, 21 Feb 2020 06:20:51 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id r11so2261369wrq.10 for ; Fri, 21 Feb 2020 06:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PgxlOng8EFBICOOL56NKYe9LtYTG3aH8iVxgxBKkkqU=; b=6XLEOH/0wOUSh90GIBaYD2vzb+93MVJ721PW0Ynj9ZZuQ+/zqCPjSDwDPse6IWpDmK IzJ21NW+ywfhZMvLXEUJe8anjx+Aj3WLXBGOhxlsYkuvjLV9mSMCe843AvRy4LBfnz/B RtVOzEdEelDvPF20SGZ9m+OuxYtCD5N3oXmPgKMoQAXS1h05zkYUNUr9jCs/b5bpt5Rh PQbS6AlwGwmS/qJ/UdvO9z1vE8hjJBFe1yhh7HXqX/gkAJS/ZgRjAh8M/NCEUG24fbBC FFWkjpiJ7FZkDNd4GJ0gRGSNikNjTTkDCaDg7RmbrDdCBiBLFkT48c1M0RrJu0kYtRjK IgGA== 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=PgxlOng8EFBICOOL56NKYe9LtYTG3aH8iVxgxBKkkqU=; b=LRIu2Yk+iozFWoLA54b9MFwxu5o6EnK4kdWKg/Rvd/8r7rB1WDezQkWc/MeGbJlAxW 32yic1N2/KweMWseJYdRIDbNuqJdX+QKNonlgAYKGK74RU+ovJ5sdtq5oQ/T5tSIw9Tk jLU+7m/UODNRSp6ZcxfSB8nobRbU2MmVSwmT5Jy50Jh13tEFeDdSgs1hcfBujWbl1BXj 8zTdH0aw8ssPjYaADgX/p7zGvjLk/iSqoMjQa7bDXmga0sJWpnCg/snILFiAC4e3Aazm q1BHm3zK/8DZ7hAKOPtPb2b85RpF19HIJchv8QR+DsPyOLXWBQguOnwL816bsZ5lqh4+ mlAg== X-Gm-Message-State: APjAAAWWiRBb/WVm+wuZrQHgIkE9e+hthFxg1vwGv4lJURl4XijPoAcR bwfl2ppvMu05czRAmFLnJLiWZA== X-Google-Smtp-Source: APXvYqz1ooZ9DAvA8p9RTnwIW3Zglvc/LmzCGaYVXx3QguEOoAvmTkDz1+C+HfqiTEacUXm7+KehTg== X-Received: by 2002:adf:806c:: with SMTP id 99mr46986765wrk.328.1582294849858; Fri, 21 Feb 2020 06:20:49 -0800 (PST) Received: from [192.168.71.111] (p5B0D94B9.dip0.t-ipconnect.de. [91.13.148.185]) by smtp.gmail.com with ESMTPSA id q130sm4371573wme.19.2020.02.21.06.20.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 06:20:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> Date: Fri, 21 Feb 2020 15:20:42 +0100 Cc: Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> To: Neil Madden X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:20:56 -0000 Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. * work out if the AS even supports mTLS * work out how to configure the AS to trust my cert(s) * Create key pair and cert using openssl * Register your (self-signed) cert along with your client_id * Configure the HTTP client to use your key pair for TLS Client = Authentication Works very well for us.=20 > On 21. Feb 2020, at 15:12, Neil Madden = wrote: >=20 > No failures, but it is a much more complex grant type to set up, when = you consider everything you have to do: >=20 > * work out if the AS even supports JWT bearer and how to turn it on > * work out how to configure the AS to trust my public key(s) > - do I have to create a new HTTPS endpoint to publish a JWK Set? > * determine the correct settings for issuer, audience, subject, etc. = Does the AS impose non-standard requirements? e.g. RFC 7523 says that = the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). > * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, = plain OAuth ones might not) If I do, can I reuse the JWT or must it be = freshly signed for every call? > * locate and evaluate a JWT library for my language of choice. Monitor = that new dependency for security advisories. > * choose a suitable signature algorithm (=E2=80=98ere be dragons) > * figure out how to distribute the private key to my service >=20 > Compared to =E2=80=9Ccreate a service account and POST the username = and password to the token endpoint=E2=80=9D it adds a little friction. = (It also adds a lot of advantages, but it is undeniably more complex). >=20 > =E2=80=94 Neil >=20 >=20 >> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>=20 >> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>=20 >> Neil could you elaborate more on this please. What failures are you = currently experiencing/seeing with the JWT Bearer grant?=20 >>=20 >> Matt >>=20 >> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>=20 >>=20 >>> On 19 Feb 2020, at 22:01, Dick Hardt wrote: >>>=20 >>> Neil: are you advocating that password grant be preserved in 2.1? Or = do you think that service account developers know enough about what they = are doing to follow what is in 6749? >>> =E1=90=A7 >>>=20 >>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>> OAuth2 clients are often private to the AS - they live in a database = that only the AS can access, have attributes specific to their use in = OAuth2, and so on. Many existing systems have access controls based on = users, roles, permissions and so on and expect all users accessing the = system to exist in some user repository, e.g. LDAP, where they can be = looked up and appropriate permissions determined. A service account can = be created inside such a system as if it was a regular user, managed = through the normal account provisioning tools, assigned permissions, = roles, etc. >>>=20 >>> Another reason is that sometimes OAuth is just one authentication = option out of many, and so permissions assigned to service accounts are = preferred over scopes because they are consistently applied no matter = how a request is authenticated. This is often the case when OAuth has = been retrofitted to an existing system and they need to preserve = compatibility with already deployed clients. >>>=20 >>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>=20 >>> =E2=80=94 Neil >>>=20 >>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>=20 >>>> Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>=20 >>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>=20 >>>>> =EF=BB=BFI very much agree with this with regards to real users.=20= >>>>>=20 >>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>=20 >>>>> There are better grant types for this - e.g. JWT bearer - but they = are a bit harder to implement. Having recently converted some code from = ROPC to JWT bearer for exactly this use-case, it went from a couple of = lines of code to two screens of code. For service to service API calls = within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>=20 >>>>> =E2=80=94 Neil >>>>>=20 >>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>=20 >>>>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>>>>> In reality it turned out just to be a one off that people used as = an easy way out to stick to an anti-pattern and still claim to do OAuth = 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>> Agreed. Plus, the Security BCP is already effectively acting as a = grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>=20 >>>>>> Aaron >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>> There is no need for a grace period. People using OAuth 2..0 can = still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>=20 >>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still = sites using this and a grace period should be provided before a MUST is = pushed out as there are valid use cases out there still. >>>>>>>=20 >>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>> To: oauth@ietf.org >>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>=20 >>>>>>> Hey List=20 >>>>>>>=20 >>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the = doc that Aaron, Torsten, and I are working on) >>>>>>>=20 >>>>>>> In the security topics doc >>>>>>>=20 >>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>=20 >>>>>>> The password grant MUST not be used. >>>>>>>=20 >>>>>>> Some background for those interested. I added this grant into = OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Does anyone have concerns with dropping the password grant from = the OAuth 2.1 document so that developers don't use it? >>>>>>>=20 >>>>>>> /Dick >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> ---- >>>>>> Aaron Parecki >>>>>> aaronparecki.com >>>>>> @aaronpk >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> hans.zandbelt@zmartzone.eu >>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Feb 21 06:31:59 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D92A120838 for ; Fri, 21 Feb 2020 06:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIILZGEO_pS7 for ; Fri, 21 Feb 2020 06:31:40 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2F512085C for ; Fri, 21 Feb 2020 06:31:40 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id k11so2299174wrd.9 for ; Fri, 21 Feb 2020 06:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XTZXd+GmKqss5kktTzG+tw28dCdsSbq678DViEfXAZE=; b=IqGPyYPpT8HgujSu0zQdGoKPoYKs8jJL7C4PeyOPXzhTVrP0ktas9lczDu0JHl269E EFOw11hB0D8hjydilr/qlBlVPe65zr+WG/ziARs2OvOCqS88tWrc1ItuR17QhbbyvreM ejTjdqljjkz0tXQYh/PlmtPtAs0QKn/Y6c0EE= 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=XTZXd+GmKqss5kktTzG+tw28dCdsSbq678DViEfXAZE=; b=hW02B6QzWz6B7/koldnAttbBoQ1rdjFip0ZR8vZ/7RCakKrGoyfolfhys1XE2WAxm0 9ARcKswFI7eoYbFPfhkuxFNzEAM7r38aytwrvfuhAkfItw5NYBPCbg66HNcr7X8/L2JP XapGq/JFwxC0V3kZ6s3Lf/ciyjb9h6hJAcozlUAbHAC5OgwcQr6sO6gjpH6oVOxzJBm7 TmsIO+phRBDCXMlNTQ/VA+L/YmPYm16ktVglwQj+t/L+169eogPwxKzaoBzNnKObD1Jo 8jbaicps/VaX5K8U0op8+YMIAqLe7G0h1O9i/yhjm+bq+ATaGrOuGreZF6Bx0/dXt9HM GVeg== X-Gm-Message-State: APjAAAV9bDIs/EPUToTR/2EliKT4DvozVX3ltbx29e2IuOSFNokhsHxK ODB/gefzTKI9/jx7+ISTNwtw4J9lYmu+HA== X-Google-Smtp-Source: APXvYqzsgeizvb39vqe20miuxShchJPP5l09hWy6ADnx/yHUu6BsRwhOQLXXy4BMJxkDlSlt0e8Hxw== X-Received: by 2002:adf:d0c1:: with SMTP id z1mr52098449wrh.371.1582295498457; Fri, 21 Feb 2020 06:31:38 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id x132sm7588376wmg.0.2020.02.21.06.31.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 06:31:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> Date: Fri, 21 Feb 2020 14:31:34 +0000 Cc: Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:31:57 -0000 Yes, that is great. But mTLS doesn=E2=80=99t support service accounts = (!=3D clients). Maybe it should? Should there be a mTLS *grant type*? =E2=80=94 Neil > On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >=20 > Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >=20 > * work out if the AS even supports mTLS > * work out how to configure the AS to trust my cert(s) > * Create key pair and cert using openssl > * Register your (self-signed) cert along with your client_id > * Configure the HTTP client to use your key pair for TLS Client = Authentication >=20 > Works very well for us.=20 >=20 >> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>=20 >> No failures, but it is a much more complex grant type to set up, when = you consider everything you have to do: >>=20 >> * work out if the AS even supports JWT bearer and how to turn it on >> * work out how to configure the AS to trust my public key(s) >> - do I have to create a new HTTPS endpoint to publish a JWK Set? >> * determine the correct settings for issuer, audience, subject, etc. = Does the AS impose non-standard requirements? e.g. RFC 7523 says that = the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, = plain OAuth ones might not) If I do, can I reuse the JWT or must it be = freshly signed for every call? >> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >> * figure out how to distribute the private key to my service >>=20 >> Compared to =E2=80=9Ccreate a service account and POST the username = and password to the token endpoint=E2=80=9D it adds a little friction. = (It also adds a lot of advantages, but it is undeniably more complex). >>=20 >> =E2=80=94 Neil >>=20 >>=20 >>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>=20 >>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>=20 >>> Neil could you elaborate more on this please. What failures are you = currently experiencing/seeing with the JWT Bearer grant?=20 >>>=20 >>> Matt >>>=20 >>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>=20 >>>=20 >>>> On 19 Feb 2020, at 22:01, Dick Hardt wrote: >>>>=20 >>>> Neil: are you advocating that password grant be preserved in 2.1? = Or do you think that service account developers know enough about what = they are doing to follow what is in 6749? >>>> =E1=90=A7 >>>>=20 >>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>=20 >>>> Another reason is that sometimes OAuth is just one authentication = option out of many, and so permissions assigned to service accounts are = preferred over scopes because they are consistently applied no matter = how a request is authenticated. This is often the case when OAuth has = been retrofitted to an existing system and they need to preserve = compatibility with already deployed clients. >>>>=20 >>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>=20 >>>>> Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>>=20 >>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>=20 >>>>>> =EF=BB=BFI very much agree with this with regards to real users.=20= >>>>>>=20 >>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>=20 >>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>=20 >>>>>> =E2=80=94 Neil >>>>>>=20 >>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>=20 >>>>>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>>>>>> In reality it turned out just to be a one off that people used = as an easy way out to stick to an anti-pattern and still claim to do = OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of = it. >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>> Agreed. Plus, the Security BCP is already effectively acting as = a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>=20 >>>>>>> Aaron >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>> There is no need for a grace period. People using OAuth 2..0 can = still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>=20 >>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still = sites using this and a grace period should be provided before a MUST is = pushed out as there are valid use cases out there still. >>>>>>>>=20 >>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>> To: oauth@ietf.org >>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>=20 >>>>>>>> Hey List=20 >>>>>>>>=20 >>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the = doc that Aaron, Torsten, and I are working on) >>>>>>>>=20 >>>>>>>> In the security topics doc >>>>>>>>=20 >>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>=20 >>>>>>>> The password grant MUST not be used. >>>>>>>>=20 >>>>>>>> Some background for those interested. I added this grant into = OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Does anyone have concerns with dropping the password grant from = the OAuth 2.1 document so that developers don't use it? >>>>>>>>=20 >>>>>>>> /Dick >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> ---- >>>>>>> Aaron Parecki >>>>>>> aaronparecki.com >>>>>>> @aaronpk >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> hans.zandbelt@zmartzone.eu >>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=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 >>> _______________________________________________ >>> 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 From nobody Fri Feb 21 06:34:58 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA712085C for ; Fri, 21 Feb 2020 06:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1b_KNezvqAN for ; Fri, 21 Feb 2020 06:34:40 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72AC12086F for ; Fri, 21 Feb 2020 06:34:39 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id n3so2020569wmk.4 for ; Fri, 21 Feb 2020 06:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jumhbzy8ARetiSFJna6a7X6IRydJOd/EsZZkEYnMBoA=; b=bH4bzE1Qb+GZzUfUu7G2jdlV3GbrldmB1CL3OxNZLKX4lh+8ZBSV9bXCnbbFtRCxAJ sDX4xrnWXhm2I1inkEph3LqmTxXfKr10SKItMG1EGNlcbtw7SYxhV+5lCqU781wmUGRg c7gTFM759AbJCMOCNjwek3RepvzOYASXwU+N8OdkFVQro0CxGZZdO/cVVN8w++oAT/ix GrynU3mBmUuyTyE3HrElTqufpJKc/pVkVjWwf7EeubjLSQd88UhMRBXthGs4wOZ2QUxL qoJFWf+/01YfWp5VMb73PWcsW0Bewja7GjYJlyxq1CgvqEJAXWn413JjN1L4gPWjuSaF 7zAg== 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=Jumhbzy8ARetiSFJna6a7X6IRydJOd/EsZZkEYnMBoA=; b=WD0WPGUnt3QhRpCZQ52m9xtB3hRf+2g66mL/UhdWPJDx1oadBCyaAgLvKNPgKfahLf 5bnh6Y4N6nWt2sMYvhy2UQA9/756qcWL7cRVJa13JV+tgEp/phnxslkbMsvj8fG/xHTf gJbc3vCZirTjousVbmE6s4HEnJTIlV1FvWmdKZJz2XOsQYkDPnVdJoSnfIuF9WCkVcm8 eUv2b/P8wTFCrzt2OZTnb4vBYRgyXjl2gRrNNjODPGe5shjyfD8LJwLb57Qf0hkgw/qT 54PNgYOQEqYwBT2rZqhrxAFzTAzcDa6OFckJdnBFeHpACQD1bRG1hm9dSEgwlsH1fda+ UbsQ== X-Gm-Message-State: APjAAAUF+Em+H/cPjpOwcaAqAqOiTxGIC8R7Ak/zV9Jex7U56pcJn5Ov 8ArUET+Mg4I04nhIXk8m+PTLZw== X-Google-Smtp-Source: APXvYqw2D/PjoZrRbSRX2f+AjX035ZCxDL/Q+7zhqOKwx7XGev6C5NVKDK6CM2SyAK9rAqomahOTsw== X-Received: by 2002:a05:600c:4105:: with SMTP id j5mr4390181wmi.28.1582295678322; Fri, 21 Feb 2020 06:34:38 -0800 (PST) Received: from [192.168.71.111] (p5B0D94B9.dip0.t-ipconnect.de. [91.13.148.185]) by smtp.gmail.com with ESMTPSA id a26sm4044806wmm.18.2020.02.21.06.34.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 06:34:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> Date: Fri, 21 Feb 2020 15:34:36 +0100 Cc: Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> To: Neil Madden X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:34:56 -0000 I see - we have gone full cycle :-)=20 Annabelle=E2=80=99s proposal would solve that. Relate a client id to a = service account and obtain the token data from there.=20 > On 21. Feb 2020, at 15:31, Neil Madden = wrote: >=20 > Yes, that is great. But mTLS doesn=E2=80=99t support service accounts = (!=3D clients). Maybe it should? Should there be a mTLS *grant type*? >=20 > =E2=80=94 Neil >=20 >> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>=20 >> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>=20 >> * work out if the AS even supports mTLS >> * work out how to configure the AS to trust my cert(s) >> * Create key pair and cert using openssl >> * Register your (self-signed) cert along with your client_id >> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>=20 >> Works very well for us.=20 >>=20 >>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>=20 >>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>=20 >>> * work out if the AS even supports JWT bearer and how to turn it on >>> * work out how to configure the AS to trust my public key(s) >>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>> * determine the correct settings for issuer, audience, subject, etc. = Does the AS impose non-standard requirements? e.g. RFC 7523 says that = the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, = plain OAuth ones might not) If I do, can I reuse the JWT or must it be = freshly signed for every call? >>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>> * figure out how to distribute the private key to my service >>>=20 >>> Compared to =E2=80=9Ccreate a service account and POST the username = and password to the token endpoint=E2=80=9D it adds a little friction. = (It also adds a lot of advantages, but it is undeniably more complex). >>>=20 >>> =E2=80=94 Neil >>>=20 >>>=20 >>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>=20 >>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>=20 >>>> Neil could you elaborate more on this please. What failures are you = currently experiencing/seeing with the JWT Bearer grant?=20 >>>>=20 >>>> Matt >>>>=20 >>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>=20 >>>>=20 >>>>> On 19 Feb 2020, at 22:01, Dick Hardt wrote: >>>>>=20 >>>>> Neil: are you advocating that password grant be preserved in 2.1? = Or do you think that service account developers know enough about what = they are doing to follow what is in 6749? >>>>> =E1=90=A7 >>>>>=20 >>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>=20 >>>>> Another reason is that sometimes OAuth is just one authentication = option out of many, and so permissions assigned to service accounts are = preferred over scopes because they are consistently applied no matter = how a request is authenticated. This is often the case when OAuth has = been retrofitted to an existing system and they need to preserve = compatibility with already deployed clients. >>>>>=20 >>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>=20 >>>>> =E2=80=94 Neil >>>>>=20 >>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>=20 >>>>>> Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>>>=20 >>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>=20 >>>>>>> =EF=BB=BFI very much agree with this with regards to real users.=20= >>>>>>>=20 >>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>=20 >>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>=20 >>>>>>> =E2=80=94 Neil >>>>>>>=20 >>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>=20 >>>>>>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>>>>>>> In reality it turned out just to be a one off that people used = as an easy way out to stick to an anti-pattern and still claim to do = OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of = it. >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>> Agreed. Plus, the Security BCP is already effectively acting as = a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>=20 >>>>>>>> Aaron >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>=20 >>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still = sites using this and a grace period should be provided before a MUST is = pushed out as there are valid use cases out there still. >>>>>>>>>=20 >>>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>> To: oauth@ietf.org >>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>=20 >>>>>>>>> Hey List=20 >>>>>>>>>=20 >>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the = doc that Aaron, Torsten, and I are working on) >>>>>>>>>=20 >>>>>>>>> In the security topics doc >>>>>>>>>=20 >>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>=20 >>>>>>>>> The password grant MUST not be used. >>>>>>>>>=20 >>>>>>>>> Some background for those interested. I added this grant into = OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>=20 >>>>>>>>> /Dick >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> ---- >>>>>>>> Aaron Parecki >>>>>>>> aaronparecki.com >>>>>>>> @aaronpk >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=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 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From nobody Fri Feb 21 06:47:32 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318EC120831 for ; Fri, 21 Feb 2020 06:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 jnNtQLpsRitw for ; Fri, 21 Feb 2020 06:47:27 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0DD12080D for ; Fri, 21 Feb 2020 06:47:26 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id w15so2366760wru.4 for ; Fri, 21 Feb 2020 06:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8vRj74lrhcjxZpdNttpbjtawOUjxAVNX8UOHaoJGnl4=; b=K4n3i+Cvbr2nswB0qPZx3mXuIQ4wuqhVXztHhkEOLBKufhCe3tfFfPRs6qCqNQO+sV DGd9qzXJtGfD8a/R9HpJoSM23w+bSVa6v8cgxjCOO3NhL1l3YC+tct7JJBnMXTTm2XSA SjZWZwQrIA5ZOen8+tDJPZewz9EqV3VJTvOgI= 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=8vRj74lrhcjxZpdNttpbjtawOUjxAVNX8UOHaoJGnl4=; b=CZt1hOovs2POz7TdNKL1i9t1Y5vFi8Th304Rh86PifiB/e7O6FFKQDRk5HTu5GVWEO tXiWUBkZlxok86dcyOMxg9uXjTeKVE29z44pqJFnW9ayNaw5s30qtF5FqDIAnEd1m28N ysJQdm1qZ7AC2NnJweghxSEt/UaLnGiQv+KlxRZ6H7a8Z4gAlur9C84Y0enXcqZuDpJD f0wSuOlGjkxKwB3MewAO461sY86eORDVNL9SrQe5IKQL+WGL9is7Lnp+27gKIYcDyGRV erAmN9MJfZ/MGromaMph51cHpbczV9O1ar76JRuvOwxsbeX5+YWya6oZjiY8irjIqLjT 1jIQ== X-Gm-Message-State: APjAAAXC6I2bAtISIKjeOEcwRrXafUEZJkAiB3jKO3NadvnbYxJhgFlF KqzIRrqV8ljvHZhBhy8MBgMU4dV278Se2g== X-Google-Smtp-Source: APXvYqzhO0tKV216QRcNygeWiBk9iGZ6j2ELDWm6L9CJ+PSX5p0qMH1N5XKOL7KfYrkwG6X2b3BUhw== X-Received: by 2002:a5d:4d04:: with SMTP id z4mr52896656wrt.157.1582296445064; Fri, 21 Feb 2020 06:47:25 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id y7sm4040697wrr.56.2020.02.21.06.47.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 06:47:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> Date: Fri, 21 Feb 2020 14:47:22 +0000 Cc: Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:47:30 -0000 Sorry, I missed that message.=20 While this may be a solution in specific circumstances, I don=E2=80=99t = think it=E2=80=99s a general solution. e.g. an AS may not allow manually = choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. =E2=80=94 Neil > On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >=20 > I see - we have gone full cycle :-)=20 >=20 > Annabelle=E2=80=99s proposal would solve that. Relate a client id to a = service account and obtain the token data from there.=20 >=20 >> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>=20 >> Yes, that is great. But mTLS doesn=E2=80=99t support service accounts = (!=3D clients). Maybe it should? Should there be a mTLS *grant type*? >>=20 >> =E2=80=94 Neil >>=20 >>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>=20 >>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>=20 >>> * work out if the AS even supports mTLS >>> * work out how to configure the AS to trust my cert(s) >>> * Create key pair and cert using openssl >>> * Register your (self-signed) cert along with your client_id >>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>=20 >>> Works very well for us.=20 >>>=20 >>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>=20 >>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>=20 >>>> * work out if the AS even supports JWT bearer and how to turn it on >>>> * work out how to configure the AS to trust my public key(s) >>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, = plain OAuth ones might not) If I do, can I reuse the JWT or must it be = freshly signed for every call? >>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>> * figure out how to distribute the private key to my service >>>>=20 >>>> Compared to =E2=80=9Ccreate a service account and POST the username = and password to the token endpoint=E2=80=9D it adds a little friction. = (It also adds a lot of advantages, but it is undeniably more complex). >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>>=20 >>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>=20 >>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>=20 >>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>=20 >>>>> Matt >>>>>=20 >>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>=20 >>>>>=20 >>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>=20 >>>>>> Neil: are you advocating that password grant be preserved in 2.1? = Or do you think that service account developers know enough about what = they are doing to follow what is in 6749? >>>>>> =E1=90=A7 >>>>>>=20 >>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>=20 >>>>>> Another reason is that sometimes OAuth is just one authentication = option out of many, and so permissions assigned to service accounts are = preferred over scopes because they are consistently applied no matter = how a request is authenticated. This is often the case when OAuth has = been retrofitted to an existing system and they need to preserve = compatibility with already deployed clients. >>>>>>=20 >>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>=20 >>>>>> =E2=80=94 Neil >>>>>>=20 >>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>=20 >>>>>>> Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>>>>=20 >>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>=20 >>>>>>>> =EF=BB=BFI very much agree with this with regards to real = users.=20 >>>>>>>>=20 >>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>=20 >>>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>>=20 >>>>>>>> =E2=80=94 Neil >>>>>>>>=20 >>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>=20 >>>>>>>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>>>>>>>> In reality it turned out just to be a one off that people used = as an easy way out to stick to an anti-pattern and still claim to do = OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of = it. >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>=20 >>>>>>>>> Aaron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>=20 >>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still = sites using this and a grace period should be provided before a MUST is = pushed out as there are valid use cases out there still. >>>>>>>>>>=20 >>>>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>> To: oauth@ietf.org >>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>>=20 >>>>>>>>>> Hey List=20 >>>>>>>>>>=20 >>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the = doc that Aaron, Torsten, and I are working on) >>>>>>>>>>=20 >>>>>>>>>> In the security topics doc >>>>>>>>>>=20 >>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>=20 >>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>=20 >>>>>>>>>> Some background for those interested. I added this grant into = OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>=20 >>>>>>>>>> /Dick >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> ---- >>>>>>>>> Aaron Parecki >>>>>>>>> aaronparecki.com >>>>>>>>> @aaronpk >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=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 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 From nobody Fri Feb 21 06:50:34 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4EE120895 for ; Fri, 21 Feb 2020 06:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbeU3cC1btcv for ; Fri, 21 Feb 2020 06:50:17 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99169120879 for ; Fri, 21 Feb 2020 06:50:17 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id b7so2016078qkl.7 for ; Fri, 21 Feb 2020 06:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7RgttRCF/1jWODR81FQSn2UZ/RIwyf4PJ1xK4fLNkBc=; b=QUINVRKTX29rB2CKBEJutpQ96fx2iZFExY/Po7g45BillmVSfOx5Z3vc00U0es9HmM gPOG48taaVR5+PecPNQvCckJ8V+LhgIyBegl0pePRiFR5OHxdFhOUszFXgNth812D1nF TXo+JFO/PG/wVSha585UNPB2M9jAhlxJrEjNSzgRKCM/+f3WSteg973MVAr8UjGnzTIg h/klYRbCT+EwKDuiy1BfvsvO/yWwSROntB0Y6fDJcLijy3q6PvYcVwn4pAvd2gGeUR4G E7wiZJc6v6wNOD4mFbaZ3qcjKg1TQrV2VBtkLe6OkUOVXSPeg/xcHF1EBG3Zw80vOasn OFZA== 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=7RgttRCF/1jWODR81FQSn2UZ/RIwyf4PJ1xK4fLNkBc=; b=ewvJ+3S3vAnnGJl5ty0Z9dEzI40TvX10g6TlKAptngLHiauOzkkTjQhSlndrYOd45P y4bMoKVVknTlGy1HnOc9xAzNfbED7PmlRoP+GhZ1UZgKmL6Z825MgqOvq4yA6vmZxJ8H ADiZA6w0NJMQHQ0SpHGB+gNKDU4YRsgGv/GV7Bf1datT8qouQ2LYa5PCI6FYsZVrFykI wmVnSXqBnyk8VStTsjDlAuPI8W2MgA04WyQnjyol7CJdVlNF9tN//z1eZyFov+9qmq+p kRmnkgS+ayZ9iTeai79+Sxn4Dvtc19onWz+zTS0xxCoPgrZqQyoheYw/++Vnw5ODFJI1 ZzaQ== X-Gm-Message-State: APjAAAXVrVL+V6GNARzVnhR0E2ft1yCAclfQC+amkAbwiDVpk34CtKwh gjh8OF0YbQ+3V3Klhd9omXdP8lB41SYlXhLgI68= X-Google-Smtp-Source: APXvYqxFsQtmr8IYH6yH/4gB6bhtFvyEnhsTBsX68hByQ68GVMfirUH0xBCtwZVHwO3u6thBKfmBLw8dcGKT/6uD0uk= X-Received: by 2002:a37:9647:: with SMTP id y68mr33160730qkd.300.1582296616677; Fri, 21 Feb 2020 06:50:16 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> In-Reply-To: From: Levi Schuck Date: Fri, 21 Feb 2020 08:50:05 -0600 Message-ID: To: Neil Madden Cc: Matthew De Haast , Torsten Lodderstedt , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c434bb059f1723a0" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:50:33 -0000 --000000000000c434bb059f1723a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I am new to the mailing list. I support a mTLS grant type. Client certificate and additional credentials in the request seems redundant. While using GCP, the flow seems to be signing a JWT with a private key known to google, which is then exchanged for a google signed JWT. Beyond the service account name being included in the JWT, there are no other credentials exchanged. This flow matches what I read in 7523. However, the GCP service account JWT exchange also carries the declared scopes the service account may use. The AS seems to validate these scopes before issuing a google signed JWT. Perhaps a mTLS grant exchange can use alg: none as a JWT for a client assertion, as JWTs already have conventions to include scopes. Or have another assertion type altogether. -Levi On Fri, Feb 21, 2020 at 8:47 AM Neil Madden wrote: > Sorry, I missed that message. > > While this may be a solution in specific circumstances, I don=E2=80=99t t= hink it=E2=80=99s > a general solution. e.g. an AS may not allow manually choosing the > client_id to avoid things like > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4= .13 > or may return different introspection results for client credentials toke= ns > (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds ev= en more steps for > somebody to migrate from existing ROPC usage. > > This is asking people to make fundamental changes to their identity > architecture rather than simply switching to a new grant type. > > =E2=80=94 Neil > > > On 21 Feb 2020, at 14:34, Torsten Lodderstedt > wrote: > > > > I see - we have gone full cycle :-) > > > > Annabelle=E2=80=99s proposal would solve that. Relate a client id to a = service > account and obtain the token data from there. > > > >> On 21. Feb 2020, at 15:31, Neil Madden > wrote: > >> > >> Yes, that is great. But mTLS doesn=E2=80=99t support service accounts = (!=3D > clients). Maybe it should? Should there be a mTLS *grant type*? > >> > >> =E2=80=94 Neil > >> > >>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt > wrote: > >>> > >>> Have you ever tried the client credentials grant with mTLS? After > reading your description it seems to be simpler than JWT Bearer. > >>> > >>> * work out if the AS even supports mTLS > >>> * work out how to configure the AS to trust my cert(s) > >>> * Create key pair and cert using openssl > >>> * Register your (self-signed) cert along with your client_id > >>> * Configure the HTTP client to use your key pair for TLS Client > Authentication > >>> > >>> Works very well for us. > >>> > >>>> On 21. Feb 2020, at 15:12, Neil Madden > wrote: > >>>> > >>>> No failures, but it is a much more complex grant type to set up, whe= n > you consider everything you have to do: > >>>> > >>>> * work out if the AS even supports JWT bearer and how to turn it on > >>>> * work out how to configure the AS to trust my public key(s) > >>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? > >>>> * determine the correct settings for issuer, audience, subject, etc. > Does the AS impose non-standard requirements? e.g. RFC 7523 says that the > JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only allows th= is to be present > if your client is doing impersonation of an end-user (which requires > additional permissions). > >>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, = plain OAuth ones > might not) If I do, can I reuse the JWT or must it be freshly signed for > every call? > >>>> * locate and evaluate a JWT library for my language of choice. > Monitor that new dependency for security advisories. > >>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) > >>>> * figure out how to distribute the private key to my service > >>>> > >>>> Compared to =E2=80=9Ccreate a service account and POST the username = and > password to the token endpoint=E2=80=9D it adds a little friction. (It al= so adds a > lot of advantages, but it is undeniably more complex). > >>>> > >>>> =E2=80=94 Neil > >>>> > >>>> > >>>>> On 21 Feb 2020, at 13:41, Matthew De Haast 40coil.com@dmarc.ietf.org> wrote: > >>>>> > >>>>> I have a feeling that if we had more concise JWT libraries and > command line tools, where using the JWT Bearer grant became a one-liner > again then we wouldn=E2=80=99t be having this conversation. So perhaps re= moving it > is an incentive to make that happen. > >>>>> > >>>>> Neil could you elaborate more on this please. What failures are you > currently experiencing/seeing with the JWT Bearer grant? > >>>>> > >>>>> Matt > >>>>> > >>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>> I have a feeling that if we had more concise JWT libraries and > command line tools, where using the JWT Bearer grant became a one-liner > again then we wouldn=E2=80=99t be having this conversation. So perhaps re= moving it > is an incentive to make that happen. > >>>>> > >>>>> > >>>>>> On 19 Feb 2020, at 22:01, Dick Hardt wrote: > >>>>>> > >>>>>> Neil: are you advocating that password grant be preserved in 2.1? > Or do you think that service account developers know enough about what th= ey > are doing to follow what is in 6749? > >>>>>> =E1=90=A7 > >>>>>> > >>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>>> OAuth2 clients are often private to the AS - they live in a > database that only the AS can access, have attributes specific to their u= se > in OAuth2, and so on. Many existing systems have access controls based on > users, roles, permissions and so on and expect all users accessing the > system to exist in some user repository, e.g. LDAP, where they can be > looked up and appropriate permissions determined. A service account can b= e > created inside such a system as if it was a regular user, managed through > the normal account provisioning tools, assigned permissions, roles, etc. > >>>>>> > >>>>>> Another reason is that sometimes OAuth is just one authentication > option out of many, and so permissions assigned to service accounts are > preferred over scopes because they are consistently applied no matter how= a > request is authenticated. This is often the case when OAuth has been > retrofitted to an existing system and they need to preserve compatibility > with already deployed clients. > >>>>>> > >>>>>> See e.g. Google cloud platform (GCP): > https://developers.google.com/identity/protocols/OAuth2ServiceAccount > >>>>>> They use the JWT bearer grant type for service account > authentication and assign permissions to those service accounts and > typically have very broad scopes. For service-to-service API calls you > typically get an access token with a single scope that is effectively =E2= =80=9Call > of GCP=E2=80=9D and everything is managed at the level of permissions on = the RO > service account itself. They only break down fine-grained scopes when you > are dealing with user data and will be getting an access token approved b= y > a real user (through a normal auth code flow). > >>>>>> > >>>>>> =E2=80=94 Neil > >>>>>> > >>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>>>>> > >>>>>>> Can you explain more in detail why the client credentials grant > type isn=E2=80=99t applicable for the kind of use cases you mentioned? > >>>>>>> > >>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden < > neil.madden@forgerock.com>: > >>>>>>>> > >>>>>>>> =EF=BB=BFI very much agree with this with regards to real users. > >>>>>>>> > >>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for se= rvice > accounts - where you essentially want something like client_credentials b= ut > for whatever reason you need the RO to be a service user rather than an > OAuth2 client (typically so that some lower layer of the system can still > perform its required permission checks). > >>>>>>>> > >>>>>>>> There are better grant types for this - e.g. JWT bearer - but > they are a bit harder to implement. Having recently converted some code > from ROPC to JWT bearer for exactly this use-case, it went from a couple = of > lines of code to two screens of code. For service to service API calls > within a datacenter I=E2=80=99m not convinced this resulted in a material= increase > in security for the added complexity. > >>>>>>>> > >>>>>>>> =E2=80=94 Neil > >>>>>>>> > >>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt < > hans.zandbelt@zmartzone.eu> wrote: > >>>>>>>>> > >>>>>>>>> I would also seriously look at the original motivation behind > ROPC: I know it has been deployed and is used in quite a lot of places bu= t > I have never actually come across a use case where it is used for migrati= on > purposes and the migration is actually executed (I know that is > statistically not a very strong argument but I challenge others to come u= p > with one...) > >>>>>>>>> In reality it turned out just to be a one off that people used > as an easy way out to stick to an anti-pattern and still claim to do OAut= h > 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. > >>>>>>>>> > >>>>>>>>> Hans. > >>>>>>>>> > >>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki < > aaron@parecki.com> wrote: > >>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting as > a grace period since it currently says the password grant MUST NOT be use= d, > so in the OAuth 2.0 world that's already a pretty strong signal.. > >>>>>>>>> > >>>>>>>>> Aaron > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer > wrote: > >>>>>>>>> There is no need for a grace period. People using OAuth 2..0 ca= n > still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. > >>>>>>>>> > >>>>>>>>> =E2=80=94 Justin > >>>>>>>>> > >>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote: > >>>>>>>>>> > >>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still > sites using this and a grace period should be provided before a MUST is > pushed out as there are valid use cases out there still. > >>>>>>>>>> > >>>>>>>>>> From: OAuth On Behalf Of Dick Hardt > >>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM > >>>>>>>>>> To: oauth@ietf.org > >>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password > grant > >>>>>>>>>> > >>>>>>>>>> Hey List > >>>>>>>>>> > >>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the > doc that Aaron, Torsten, and I are working on) > >>>>>>>>>> > >>>>>>>>>> In the security topics doc > >>>>>>>>>> > >>>>>>>>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > >>>>>>>>>> > >>>>>>>>>> The password grant MUST not be used. > >>>>>>>>>> > >>>>>>>>>> Some background for those interested. I added this grant into > OAuth 2.0 to allow applications that had been provided password to migrat= e. > Even with the caveats in OAuth 2.0, implementors decide they want to prom= pt > the user to enter their credentials, the anti-pattern OAuth was created t= o > eliminate. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Does anyone have concerns with dropping the password grant fro= m > the OAuth 2.1 document so that developers don't use it? > >>>>>>>>>> > >>>>>>>>>> /Dick > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> OAuth mailing list > >>>>>>>>>> OAuth@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> OAuth mailing list > >>>>>>>>> OAuth@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>> -- > >>>>>>>>> ---- > >>>>>>>>> Aaron Parecki > >>>>>>>>> aaronparecki.com > >>>>>>>>> @aaronpk > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> OAuth mailing list > >>>>>>>>> OAuth@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> hans.zandbelt@zmartzone.eu > >>>>>>>>> ZmartZone IAM - www.zmartzone.eu > >>>>>>>>> _______________________________________________ > >>>>>>>>> OAuth mailing list > >>>>>>>>> OAuth@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> OAuth@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > --000000000000c434bb059f1723a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I am new to the mailing lis= t.
I support a mTLS grant type.=C2=A0

Client certificate and additional cre= dentials in the request seems redundant.

<= div dir=3D"auto">While using GCP, the flow seems to be signing a JWT with a= private key known to google, which is then exchanged for a google signed J= WT. Beyond the service account name being included in the JWT, there are no= other credentials exchanged. This flow matches what I read in 7523.=C2=A0<= /div>

However, the GCP service= account JWT exchange also carries the declared scopes the service account = may use. The AS seems to validate these scopes before issuing a google sign= ed JWT.

Perhaps a mTLS g= rant exchange can use alg: none as a JWT for a client assertion, as JWTs al= ready have conventions to include scopes. Or have another assertion type al= together.

-Levi

On Fri, Feb 21, 2020 at 8:47 AM Neil Madden <neil.madden@forgerock.com> wrote:
Sorry, I missed that message.

While this may be a solution in specific circumstances, I don=E2=80=99t thi= nk it=E2=80=99s a general solution. e.g. an AS may not allow manually choos= ing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-oauth-security-topics= -14#section-4.13 or may return different introspection results for clie= nt credentials tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In pr= actice, this adds even more steps for somebody to migrate from existing ROP= C usage.

This is asking people to make fundamental changes to their identity archite= cture rather than simply switching to a new grant type.

=E2=80=94 Neil

> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <torsten@lodderstedt.net> wr= ote:
>
> I see - we have gone full cycle :-)
>
> Annabelle=E2=80=99s proposal would solve that. Relate a client id to a= service account and obtain the token data from there.
>
>> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forgerock.com> w= rote:
>>
>> Yes, that is great. But mTLS doesn=E2=80=99t support service accou= nts (!=3D clients). Maybe it should? Should there be a mTLS *grant type*? >>
>> =E2=80=94 Neil
>>
>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>
>>> Have you ever tried the client credentials grant with mTLS? Af= ter reading your description it seems to be simpler than JWT Bearer.
>>>
>>> * work out if the AS even supports mTLS
>>> * work out how to configure the AS to trust my cert(s)
>>> * Create key pair and cert using openssl
>>> * Register your (self-signed) cert along with your client_id >>> * Configure the HTTP client to use your key pair for TLS Clien= t Authentication
>>>
>>> Works very well for us.
>>>
>>>> On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>
>>>> No failures, but it is a much more complex grant type to s= et up, when you consider everything you have to do:
>>>>
>>>> * work out if the AS even supports JWT bearer and how to t= urn it on
>>>> * work out how to configure the AS to trust my public key(= s)
>>>> - do I have to create a new HTTPS endpoint to publish a JW= K Set?
>>>> * determine the correct settings for issuer, audience, sub= ject, etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says= that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only a= llows this to be present if your client is doing impersonation of an end-us= er (which requires additional permissions).
>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC se= rvers do, plain OAuth ones might not) If I do, can I reuse the JWT or must = it be freshly signed for every call?
>>>> * locate and evaluate a JWT library for my language of cho= ice. Monitor that new dependency for security advisories.
>>>> * choose a suitable signature algorithm (=E2=80=98ere be d= ragons)
>>>> * figure out how to distribute the private key to my servi= ce
>>>>
>>>> Compared to =E2=80=9Ccreate a service account and POST the= username and password to the token endpoint=E2=80=9D it adds a little fric= tion. (It also adds a lot of advantages, but it is undeniably more complex)= .
>>>>
>>>> =E2=80=94 Neil
>>>>
>>>>
>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast <matt=3D= 40coil.com@d= marc.ietf.org> wrote:
>>>>>
>>>>> I have a feeling that if we had more concise JWT libra= ries and command line tools, where using the JWT Bearer grant became a one-= liner again then we wouldn=E2=80=99t be having this conversation. So perhap= s removing it is an incentive to make that happen.
>>>>>
>>>>> Neil could you elaborate more on this please. What fai= lures are you currently experiencing/seeing with the JWT Bearer grant?
>>>>>
>>>>> Matt
>>>>>
>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <neil.madden@forge= rock.com> wrote:
>>>>> I have a feeling that if we had more concise JWT libra= ries and command line tools, where using the JWT Bearer grant became a one-= liner again then we wouldn=E2=80=99t be having this conversation. So perhap= s removing it is an incentive to make that happen.
>>>>>
>>>>>
>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <dick.hardt@gmail.com= > wrote:
>>>>>>
>>>>>> Neil: are you advocating that password grant be pr= eserved in 2.1? Or do you think that service account developers know enough= about what they are doing to follow what is in 6749?
>>>>>> =E1=90=A7
>>>>>>
>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@fo= rgerock.com> wrote:
>>>>>> OAuth2 clients are often private to the AS - they = live in a database that only the AS can access, have attributes specific to= their use in OAuth2, and so on. Many existing systems have access controls= based on users, roles, permissions and so on and expect all users accessin= g the system to exist in some user repository, e.g. LDAP, where they can be= looked up and appropriate permissions determined. A service account can be= created inside such a system as if it was a regular user, managed through = the normal account provisioning tools, assigned permissions, roles, etc. >>>>>>
>>>>>> Another reason is that sometimes OAuth is just one= authentication option out of many, and so permissions assigned to service = accounts are preferred over scopes because they are consistently applied no= matter how a request is authenticated. This is often the case when OAuth h= as been retrofitted to an existing system and they need to preserve compati= bility with already deployed clients.
>>>>>>
>>>>>> See e.g. Google cloud platform (GCP): https://developers.google.com/identity/pr= otocols/OAuth2ServiceAccount
>>>>>> They use the JWT bearer grant type for service acc= ount authentication and assign permissions to those service accounts and ty= pically have very broad scopes. For service-to-service API calls you typica= lly get an access token with a single scope that is effectively =E2=80=9Cal= l of GCP=E2=80=9D and everything is managed at the level of permissions on = the RO service account itself. They only break down fine-grained scopes whe= n you are dealing with user data and will be getting an access token approv= ed by a real user (through a normal auth code flow).
>>>>>>
>>>>>> =E2=80=94 Neil
>>>>>>
>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:
>>>>>>>
>>>>>>> Can you explain more in detail why the client = credentials grant type isn=E2=80=99t applicable for the kind of use cases y= ou mentioned?
>>>>>>>
>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden= <neil.ma= dden@forgerock.com>:
>>>>>>>>
>>>>>>>> =EF=BB=BFI very much agree with this with = regards to real users.
>>>>>>>>
>>>>>>>> The one legitimate use-case for ROPC I=E2= =80=99ve seen is for service accounts - where you essentially want somethin= g like client_credentials but for whatever reason you need the RO to be a s= ervice user rather than an OAuth2 client (typically so that some lower laye= r of the system can still perform its required permission checks).
>>>>>>>>
>>>>>>>> There are better grant types for this - e.= g. JWT bearer - but they are a bit harder to implement. Having recently con= verted some code from ROPC to JWT bearer for exactly this use-case, it went= from a couple of lines of code to two screens of code. For service to serv= ice API calls within a datacenter I=E2=80=99m not convinced this resulted i= n a material increase in security for the added complexity.
>>>>>>>>
>>>>>>>> =E2=80=94 Neil
>>>>>>>>
>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbel= t <hans.= zandbelt@zmartzone.eu> wrote:
>>>>>>>>>
>>>>>>>>> I would also seriously look at the ori= ginal motivation behind ROPC: I know it has been deployed and is used in qu= ite a lot of places but I have never actually come across a use case where = it is used for migration purposes and the migration is actually executed (I= know that is statistically not a very strong argument but I challenge othe= rs to come up with one...)
>>>>>>>>> In reality it turned out just to be a = one off that people used as an easy way out to stick to an anti-pattern and= still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we nee= d to get rid of it.
>>>>>>>>>
>>>>>>>>> Hans.
>>>>>>>>>
>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron= Parecki <aaron@p= arecki.com> wrote:
>>>>>>>>> Agreed. Plus, the Security BCP is alre= ady effectively acting as a grace period since it currently says the passwo= rd grant MUST NOT be used, so in the OAuth 2.0 world that's already a p= retty strong signal..
>>>>>>>>>
>>>>>>>>> Aaron
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin= Richer <jricher@mi= t.edu> wrote:
>>>>>>>>> There is no need for a grace period. P= eople using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2.1 will = do OAuth 2.1.
>>>>>>>>>
>>>>>>>>> =E2=80=94 Justin
>>>>>>>>>
>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, A= nthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:
>>>>>>>>>>
>>>>>>>>>> I would suggest a SHOULD NOT inste= ad of MUST, there are still sites using this and a grace period should be p= rovided before a MUST is pushed out as there are valid use cases out there = still.
>>>>>>>>>>
>>>>>>>>>> From: OAuth <oauth-bounces@ietf.org> On= Behalf Of Dick Hardt
>>>>>>>>>> Sent: Tuesday, February 18, 2020 1= 2:37 PM
>>>>>>>>>> To: oauth@ietf.org
>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAu= th 2.1: dropping password grant
>>>>>>>>>>
>>>>>>>>>> Hey List
>>>>>>>>>>
>>>>>>>>>> (Once again using the OAuth 2.1 na= me as a placeholder for the doc that Aaron, Torsten, and I are working on)<= br> >>>>>>>>>>
>>>>>>>>>> In the security topics doc
>>>>>>>>>>
>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topic= s-14#section-2.4
>>>>>>>>>>
>>>>>>>>>> The password grant MUST not be use= d.
>>>>>>>>>>
>>>>>>>>>> Some background for those interest= ed. I added this grant into OAuth 2.0 to allow applications that had been p= rovided password to migrate. Even with the caveats in OAuth 2.0, implemento= rs decide they want to prompt the user to enter their credentials, the anti= -pattern OAuth was created to eliminate.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Does anyone have concerns with dro= pping the password grant from the OAuth 2.1 document so that developers don= 't use it?
>>>>>>>>>>
>>>>>>>>>> /Dick
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf= .org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org= /mailman/listinfo/oauth
>>>>>>>>> --
>>>>>>>>> ----
>>>>>>>>> Aaron Parecki
>>>>>>>>> aaronparecki.com
>>>>>>>>> @aaronpk
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org= /mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>>>> ______________________________________= _________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org= /mailman/listinfo/oauth
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mai= lman/listinfo/oauth
>>>>>>
>>>>>> _______________________________________________ >>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>
>>
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c434bb059f1723a0-- From nobody Fri Feb 21 06:55:03 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19885120829 for ; Fri, 21 Feb 2020 06:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-ck4_Rd4GMD for ; Fri, 21 Feb 2020 06:54:58 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A081D120804 for ; Fri, 21 Feb 2020 06:54:57 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id a9so2208106wmj.3 for ; Fri, 21 Feb 2020 06:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yHzPkVzPrUFM13OPBgDjnjT3s62FHMY1gAgfAI5dLJg=; b=rZUG+kk/RQPUaZTHK/zl/yWpNS242RpkXK8LJYKooARxIwU3xyRCrZsTz+hhbTrwg/ afqVHGaFpJHmJTbc9+nEYbZj7Bc+K+1N/V5XolNlv89Xi767aj7uxuaW3biulpiU9lmC vbLWdB2p8mUs8du+BdiUICF/NuJEuzcj3H4PvEpizxnImEhmG/ZQRcS5MEqfTJyUb5Yn 1pdBF/jpg/LpaZu0Y7JHpXkyERS5MyAMRlSGn7B6Q5JzIeEf+K7vePwCUCwwPJB0PL4P ejvYMSjG/bNwp+wHjNPtHkvjTx4++iad4uk5RPCSD7vasov5edaRtzfARImCYSK0bqVp jAKg== 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=yHzPkVzPrUFM13OPBgDjnjT3s62FHMY1gAgfAI5dLJg=; b=kUL/2TPtq8co/Nzg+pxBf0CTGwnwah2a95xRWHKTafkcGfKfbU/Bl5F43pXrowC19Q X/gfd4DjKO0CCNmpeP7neFzNxTl3QXMi2KdxJrUwyprRZMWcjQE3cZSpMyBbWNRQMgy6 XEPw/BJlU0HEjxKSnvqJG0PNVZYBHenAi2syIpwtJTDKfSvEgAWBfjEDtxOge9Gxf5i2 5iNBpYmVA6GY8pY6OLw5ex/IkIPPmciyH/DCg8XGHA4gOh/Sbvgx+ITzKPCf1fBwcRLM xX5X55aokKKkvWkHyQmyf44KpC+pF3eNyyzAzfFDu3wIvybvTXCHo1vKez1PocoRlErL bzFA== X-Gm-Message-State: APjAAAUkrQixkzn+1etLrVjt/0f7nl737MkeS4NrlClZ1+1P8hatOCbj kd1dU7vjUOOK8uoKErE7Ik1GEnLi5Zg= X-Google-Smtp-Source: APXvYqwiUBvjvST+8/sc+QMoMh0eurWAGw3aw7Ug910EYuWhsmaIGNlY7IPrVQtfkvHUO4DQsMUE+Q== X-Received: by 2002:a1c:a4c3:: with SMTP id n186mr4319182wme.25.1582296895920; Fri, 21 Feb 2020 06:54:55 -0800 (PST) Received: from [192.168.71.111] (p5B0D94B9.dip0.t-ipconnect.de. [91.13.148.185]) by smtp.gmail.com with ESMTPSA id f11sm4050019wml.3.2020.02.21.06.54.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 06:54:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Fri, 21 Feb 2020 15:54:53 +0100 Cc: Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1094FB21-0466-4212-9310-CB2A7755F683@lodderstedt.net> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> To: Neil Madden X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:55:01 -0000 > On 21. Feb 2020, at 15:47, Neil Madden = wrote: >=20 > Sorry, I missed that message.=20 >=20 > While this may be a solution in specific circumstances, I don=E2=80=99t = think it=E2=80=99s a general solution. e.g. an AS may not allow manually = choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. >=20 > This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. I don=E2=80=99t see this as a fundamental change, it adds another = claim/permission source to a client id. > = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 This can be solved by either using the id of the service account as sub = or even put the service identity into a dedicated realm. We implemented = the later strategy at Deutsche Telekom couple of yrs ago. >=20 > =E2=80=94 Neil >=20 >> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>=20 >> I see - we have gone full cycle :-)=20 >>=20 >> Annabelle=E2=80=99s proposal would solve that. Relate a client id to = a service account and obtain the token data from there.=20 >>=20 >>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>>=20 >>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? >>>=20 >>> =E2=80=94 Neil >>>=20 >>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>>=20 >>>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>>=20 >>>> * work out if the AS even supports mTLS >>>> * work out how to configure the AS to trust my cert(s) >>>> * Create key pair and cert using openssl >>>> * Register your (self-signed) cert along with your client_id >>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>>=20 >>>> Works very well for us.=20 >>>>=20 >>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>>=20 >>>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>>=20 >>>>> * work out if the AS even supports JWT bearer and how to turn it = on >>>>> * work out how to configure the AS to trust my public key(s) >>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? >>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>>> * figure out how to distribute the private key to my service >>>>>=20 >>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). >>>>>=20 >>>>> =E2=80=94 Neil >>>>>=20 >>>>>=20 >>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>>=20 >>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>=20 >>>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>=20 >>>>>> Matt >>>>>>=20 >>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>=20 >>>>>>=20 >>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>>=20 >>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? >>>>>>> =E1=90=A7 >>>>>>>=20 >>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>>=20 >>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. >>>>>>>=20 >>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>>=20 >>>>>>> =E2=80=94 Neil >>>>>>>=20 >>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>>=20 >>>>>>>> Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>>>>>=20 >>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>>=20 >>>>>>>>> =EF=BB=BFI very much agree with this with regards to real = users.=20 >>>>>>>>>=20 >>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>>=20 >>>>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Neil >>>>>>>>>=20 >>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>>=20 >>>>>>>>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>=20 >>>>>>>>>> Aaron >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>=20 >>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>=20 >>>>>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>>>=20 >>>>>>>>>>> Hey List=20 >>>>>>>>>>>=20 >>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>=20 >>>>>>>>>>> In the security topics doc >>>>>>>>>>>=20 >>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>>=20 >>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>=20 >>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>=20 >>>>>>>>>>> /Dick >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> ---- >>>>>>>>>> Aaron Parecki >>>>>>>>>> aaronparecki.com >>>>>>>>>> @aaronpk >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=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 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 From nobody Fri Feb 21 07:03:02 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5281112083B for ; Fri, 21 Feb 2020 07:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8lQjMDPR6dz1 for ; Fri, 21 Feb 2020 07:02:56 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12103120832 for ; Fri, 21 Feb 2020 07:02:56 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id s10so2120121wmh.3 for ; Fri, 21 Feb 2020 07:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tXTc2n3UJoU67In1kaRw/rTKw2sgV5zNsnra6PkkJkU=; b=awNbbISlsjujtAfCQcTD2BP8seeIdCwgyVGi+LozVCcKUVsPzHtedWsJQ6Z99epKSS zkBWb/Bw2qb3HAVPj1ol2cd22Xs3bN78SLop5q+4Rz/g9wCG2WEEa00/QHObNgnaURWf hwoZN030n08byrfdjRSSqTtTrE6dAAufjSeEE= 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=tXTc2n3UJoU67In1kaRw/rTKw2sgV5zNsnra6PkkJkU=; b=ClaOQuoAyiUeXAJBMqis/W01VdICeBwZzR68jJXRLbrYHPH+19SbFq8XN+sHzy67qU wWd5JkkhyKDi+MXX/euJumWXUGEhlWZDg93EmhOWzQhNaX3GfImF92wZXphAm0qqZuG5 Ds3+na+/zBvoa0pm3kyV++XRMRcR0fWeb34UP3W8IY5ME9wCUFD7t3hpuJRaU4qos8yb YGNfWj/KVm/lxEQHS2JR/Y9GJQC9d53CP+i/NFqskuV/TZQl/+HunqsvClJv994FBslw 2cePfvh1kersBI6TTjyEMplfA8DD+qIoA/H+q57iSN8tiNxQiQr57FyEAgpNv7gUpT27 oOag== X-Gm-Message-State: APjAAAXX7PrYJenFvd9UvZJhnaN0TD6KL+9Ae9r1uWFlYEe1/YSAVvF0 cACxOROW5CsLnqVe24/dMmjDRw== X-Google-Smtp-Source: APXvYqx/cePQxGjXjttKMB6mOP8q3KIR5hcmlXTzcugiYgMXVkQOsmnN2kjUhAbILGN5S0e9BpMlOg== X-Received: by 2002:a7b:c5d9:: with SMTP id n25mr4556681wmk.65.1582297374289; Fri, 21 Feb 2020 07:02:54 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id 2sm3962393wrq.31.2020.02.21.07.02.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 07:02:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: <1094FB21-0466-4212-9310-CB2A7755F683@lodderstedt.net> Date: Fri, 21 Feb 2020 15:02:52 +0000 Cc: Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <13BE5936-399A-49CE-B4F5-4F72508112BF@forgerock.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <1094FB21-0466-4212-9310-CB2A7755F683@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 15:03:00 -0000 But we=E2=80=99re talking about existing deployments. Are you suggesting = that people should bulk rename all of their clients to match the service = accounts (or vice-versa)?=20 =E2=80=94 Neil > On 21 Feb 2020, at 14:54, Torsten Lodderstedt = wrote: >=20 >=20 >=20 >> On 21. Feb 2020, at 15:47, Neil Madden = wrote: >>=20 >> Sorry, I missed that message.=20 >>=20 >> While this may be a solution in specific circumstances, I don=E2=80=99t= think it=E2=80=99s a general solution. e.g. an AS may not allow = manually choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. >>=20 >> This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. >=20 > I don=E2=80=99t see this as a fundamental change, it adds another = claim/permission source to a client id. >=20 >> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 >=20 > This can be solved by either using the id of the service account as = sub or even put the service identity into a dedicated realm. We = implemented the later strategy at Deutsche Telekom couple of yrs ago. >=20 >>=20 >> =E2=80=94 Neil >>=20 >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>>=20 >>> I see - we have gone full cycle :-)=20 >>>=20 >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id to = a service account and obtain the token data from there.=20 >>>=20 >>>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>>>=20 >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>>>=20 >>>>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>>>=20 >>>>> * work out if the AS even supports mTLS >>>>> * work out how to configure the AS to trust my cert(s) >>>>> * Create key pair and cert using openssl >>>>> * Register your (self-signed) cert along with your client_id >>>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>>>=20 >>>>> Works very well for us.=20 >>>>>=20 >>>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>>>=20 >>>>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>>>=20 >>>>>> * work out if the AS even supports JWT bearer and how to turn it = on >>>>>> * work out how to configure the AS to trust my public key(s) >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? >>>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>>>> * figure out how to distribute the private key to my service >>>>>>=20 >>>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). >>>>>>=20 >>>>>> =E2=80=94 Neil >>>>>>=20 >>>>>>=20 >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>>>=20 >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>=20 >>>>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>>=20 >>>>>>> Matt >>>>>>>=20 >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>>>=20 >>>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? >>>>>>>> =E1=90=A7 >>>>>>>>=20 >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>>>=20 >>>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. >>>>>>>>=20 >>>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>>>=20 >>>>>>>> =E2=80=94 Neil >>>>>>>>=20 >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>>>=20 >>>>>>>>> Can you explain more in detail why the client credentials = grant type isn=E2=80=99t applicable for the kind of use cases you = mentioned? >>>>>>>>>=20 >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>>>=20 >>>>>>>>>> =EF=BB=BFI very much agree with this with regards to real = users.=20 >>>>>>>>>>=20 >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>>>=20 >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Neil >>>>>>>>>>=20 >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would also seriously look at the original motivation = behind ROPC: I know it has been deployed and is used in quite a lot of = places but I have never actually come across a use case where it is used = for migration purposes and the migration is actually executed (I know = that is statistically not a very strong argument but I challenge others = to come up with one...) >>>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>>=20 >>>>>>>>>>> Aaron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>>=20 >>>>>>>>>>>> From: OAuth On Behalf Of Dick = Hardt >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>>>>=20 >>>>>>>>>>>> Hey List=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>>=20 >>>>>>>>>>>> In the security topics doc >>>>>>>>>>>>=20 >>>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>>>=20 >>>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>>=20 >>>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>>=20 >>>>>>>>>>>> /Dick >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> ---- >>>>>>>>>>> Aaron Parecki >>>>>>>>>>> aaronparecki.com >>>>>>>>>>> @aaronpk >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=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 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Fri Feb 21 07:25:18 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE99120840 for ; Fri, 21 Feb 2020 07:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zqm1FL0lQmS for ; Fri, 21 Feb 2020 07:25:11 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4296112083E for ; Fri, 21 Feb 2020 07:25:11 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id u6so2525067wrt.0 for ; Fri, 21 Feb 2020 07:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bVrks8MT5wscA6RCKyyZq7fls16NWnRC8YDZKKH4tbg=; b=ks2MH5IevWEuS/fFKF252OE3+VNR119h63Iu9D108M3aZnczKU3fgkMAPM3NL5RDFu XTCATwS5uVFXR5DaQd/9QeAKUZg+lJFWP8cFowlJbYAYWRsrRBDPpPChlikUYOcLHL7u PhdwYGREHmcbsobpz2crl0isBljvaiTJPP+Bz0jAGsph5Fm8OeOuspysEYMeo+9W5e9z U3cOkw0b17zt10unQ7sC7uJr37mTesZ/5KJajvHKiQhCeCT4I+FQMEIkNaUTVpd11Xqd 2aoXc5JE9zx+eAV2k1PgTpPyGYa2hche2x6n0aQGhjtvA1Z7HnG3pr8YwxIK18D0iqbf IUcQ== 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=bVrks8MT5wscA6RCKyyZq7fls16NWnRC8YDZKKH4tbg=; b=gMpfuSU25zTShWx7KoB3jgvlGMt6YzSy/li71ZO6oBGKbRiF+1c17DRVOf0FWj9H63 E8sWSXogyvFFo7FJUFh06XSig7HEYOPUtMJVz2Mqob/zyXqZKaNyevBn48alftUXb+rV xxQY+Kx/weFO9B83jc2qsvEcH9biyXc1UUjz62vlh0yx+6pMPl4AiKZLRv9OuG8MVuZx nBxvDI8JQfzUEd6RLvfFGG2nLUX5h4hUSrBQcEOewL5/o8TVDAB74O8Xg9TuZ1R5eaQC DgvmWmJXUwgaC0fCZLTS9qXFHmWREM61yBC1jo5T8Jx5+73i4lva+hChtx1wN+mw5Yg/ LpsQ== X-Gm-Message-State: APjAAAVFsyjKReC6cfYt53zwGAY3fhjT+863A4O8RwCKce6cVj8I0t4v Z2AfHcKvFuqUtn+p1XhHuCXLzA== X-Google-Smtp-Source: APXvYqy+yRkHzYCDoO17w6qdHFWc3MpJRqTquETsIuoLCQ41EVdCuCxlrhq5KF9NrwqQsBdT52P8qA== X-Received: by 2002:adf:fac7:: with SMTP id a7mr21594443wrs.299.1582298709436; Fri, 21 Feb 2020 07:25:09 -0800 (PST) Received: from [192.168.71.111] (p5B0D94B9.dip0.t-ipconnect.de. [91.13.148.185]) by smtp.gmail.com with ESMTPSA id c9sm4429287wrq.44.2020.02.21.07.25.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 07:25:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <13BE5936-399A-49CE-B4F5-4F72508112BF@forgerock.com> Date: Fri, 21 Feb 2020 16:25:07 +0100 Cc: Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0888934B-D011-41FC-9701-60D4B1C7FE53@lodderstedt.net> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <1094FB21-0466-4212-9310-CB2A7755F683@lodderstedt.net> <13BE5936-399A-49CE-B4F5-4F72508112BF@forgerock.com> To: Neil Madden X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 15:25:15 -0000 It=E2=80=99s difficult to give advise without lot of detailed = information. I nevertheless give it a try. Mechanically, the application would need to use a different grant, = credential instead of ROPC. If such an application today already uses a = distinct client_id, the AS must be set up to relate this client_id and = the service account the same app used before directly. With that the = respective deployment is able to leverage all client authentication = methods, including mTLS. > On 21. Feb 2020, at 16:02, Neil Madden = wrote: >=20 > But we=E2=80=99re talking about existing deployments. Are you = suggesting that people should bulk rename all of their clients to match = the service accounts (or vice-versa)?=20 >=20 > =E2=80=94 Neil >=20 >> On 21 Feb 2020, at 14:54, Torsten Lodderstedt = wrote: >>=20 >>=20 >>=20 >>> On 21. Feb 2020, at 15:47, Neil Madden = wrote: >>>=20 >>> Sorry, I missed that message.=20 >>>=20 >>> While this may be a solution in specific circumstances, I don=E2=80=99= t think it=E2=80=99s a general solution. e.g. an AS may not allow = manually choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. >>>=20 >>> This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. >>=20 >> I don=E2=80=99t see this as a fundamental change, it adds another = claim/permission source to a client id. >>=20 >>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 >>=20 >> This can be solved by either using the id of the service account as = sub or even put the service identity into a dedicated realm. We = implemented the later strategy at Deutsche Telekom couple of yrs ago. >>=20 >>>=20 >>> =E2=80=94 Neil >>>=20 >>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>>>=20 >>>> I see - we have gone full cycle :-)=20 >>>>=20 >>>> Annabelle=E2=80=99s proposal would solve that. Relate a client id = to a service account and obtain the token data from there.=20 >>>>=20 >>>>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>>>>=20 >>>>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? >>>>>=20 >>>>> =E2=80=94 Neil >>>>>=20 >>>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>>>>=20 >>>>>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>>>>=20 >>>>>> * work out if the AS even supports mTLS >>>>>> * work out how to configure the AS to trust my cert(s) >>>>>> * Create key pair and cert using openssl >>>>>> * Register your (self-signed) cert along with your client_id >>>>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>>>>=20 >>>>>> Works very well for us.=20 >>>>>>=20 >>>>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>>>>=20 >>>>>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>>>>=20 >>>>>>> * work out if the AS even supports JWT bearer and how to turn it = on >>>>>>> * work out how to configure the AS to trust my public key(s) >>>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? >>>>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>>>>> * choose a suitable signature algorithm (=E2=80=98ere be = dragons) >>>>>>> * figure out how to distribute the private key to my service >>>>>>>=20 >>>>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). >>>>>>>=20 >>>>>>> =E2=80=94 Neil >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>>>>=20 >>>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>>=20 >>>>>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>>>=20 >>>>>>>> Matt >>>>>>>>=20 >>>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>>>>=20 >>>>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? >>>>>>>>> =E1=90=A7 >>>>>>>>>=20 >>>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>>>>=20 >>>>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. >>>>>>>>>=20 >>>>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Neil >>>>>>>>>=20 >>>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>>>>=20 >>>>>>>>>> Can you explain more in detail why the client credentials = grant type isn=E2=80=99t applicable for the kind of use cases you = mentioned? >>>>>>>>>>=20 >>>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>>>>=20 >>>>>>>>>>> =EF=BB=BFI very much agree with this with regards to real = users.=20 >>>>>>>>>>>=20 >>>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is = for service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>>>>=20 >>>>>>>>>>> There are better grant types for this - e.g. JWT bearer - = but they are a bit harder to implement. Having recently converted some = code from ROPC to JWT bearer for exactly this use-case, it went from a = couple of lines of code to two screens of code. For service to service = API calls within a datacenter I=E2=80=99m not convinced this resulted in = a material increase in security for the added complexity. >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Neil >>>>>>>>>>>=20 >>>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I would also seriously look at the original motivation = behind ROPC: I know it has been deployed and is used in quite a lot of = places but I have never actually come across a use case where it is used = for migration purposes and the migration is actually executed (I know = that is statistically not a very strong argument but I challenge others = to come up with one...) >>>>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hans. >>>>>>>>>>>>=20 >>>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively = acting as a grace period since it currently says the password grant MUST = NOT be used, so in the OAuth 2.0 world that's already a pretty strong = signal.. >>>>>>>>>>>>=20 >>>>>>>>>>>> Aaron >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>>>>> There is no need for a grace period. People using OAuth = 2..0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20= >>>>>>>>>>>>=20 >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> From: OAuth On Behalf Of Dick = Hardt >>>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping = password grant >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hey List=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In the security topics doc >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> /Dick >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>>> ---- >>>>>>>>>>>> Aaron Parecki >>>>>>>>>>>> aaronparecki.com >>>>>>>>>>>> @aaronpk >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> --=20 >>>>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=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 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Fri Feb 21 12:29:10 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A111D1200E5 for ; Fri, 21 Feb 2020 12:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M__lG4WBtXSL for ; Fri, 21 Feb 2020 12:28:50 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219C01200B8 for ; Fri, 21 Feb 2020 12:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1582316930; x=1613852930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jmnDmfAhy42G/x8JPieoagFLemVJHYHgez0o1eYkKL4=; b=W7ocFgBZD9wLRvjP16dnp8WnNIuvGtZlOp/Zg5mtkPIg2ZZKTtqLGZ/i +RWd8s9TBCvdomq98KWc26hpZ4R0nMw0jnWPj9silKsnRTXF8Ad3OEgRt hqzLnXyKxWNKIiZv5Wobo+jYjbv7IXvLBnSjc1LV66CIve/cvJ5STp0cv 4=; IronPort-SDR: a/D51b0VqUBDd5DScSe8clufWykXafClGnR/HcstQGa+ZIpzeam3gzp6vXfRW4Z9pG/qUNv5Ws mbMaTy5ZtQeA== X-IronPort-AV: E=Sophos;i="5.70,469,1574121600"; d="scan'208";a="26780107" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 21 Feb 2020 20:28:48 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com (Postfix) with ESMTPS id 55FB1A0660; Fri, 21 Feb 2020 20:28:47 +0000 (UTC) Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 21 Feb 2020 20:28:46 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 21 Feb 2020 20:28:46 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.000; Fri, 21 Feb 2020 20:28:46 +0000 From: "Richard Backman, Annabelle" To: Neil Madden , Torsten Lodderstedt CC: Matthew De Haast , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.1: dropping password grant Thread-Index: AQHV5qSUgKi8Wj4ZTk68d/Qg5rtTLaghf4+AgAGDGoCAAAkCgIAABOGAgAACjYCAAAssAIACjbcAgAAIhQCAAAJoAIAAAwkAgAAA2QCAAAORAP//2UYA Date: Fri, 21 Feb 2020 20:28:46 +0000 Message-ID: <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.53] Content-Type: text/plain; charset="utf-8" Content-ID: <45D7E5B687BA324FAA1B8CB541A46795@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 20:29:09 -0000 VGhlIGNsaWVudCBJRHMgY2FuIHN0aWxsIGJlIG9wYXF1ZSBpZGVudGlmaWVycyBwcm92aWRlZCBi eSB0aGUgQVMsIHRoZXkganVzdCBoYXBwZW4gdG8gYmUgYXNzb2NpYXRlZCB3aXRoIHNwZWNpZmlj IHNlcnZpY2UgYWNjb3VudHMuIE9yIHRoZXkgY291bGQgYmUgdGhlIG9wYXF1ZSBJRHMgdGhhdCB0 aGUgQVMgYWxyZWFkeSBpc3N1ZWQgZm9yIHRoZSBzZXJ2aWNlIGFjY291bnQuIEVpdGhlciB3YXks IHRoZSBBUyBjb3VsZCBpc3N1ZSBhIHRva2VuIHdpdGggdGhlIGFwcHJvcHJpYXRlIHN1YmplY3Qg YW5kIG90aGVyIGNsYWltcyBmb3IgdGhlIHNlcnZpY2UgYWNjb3VudC4NCg0KSWYgeW91ciBjbGll bnQgaWRlbnRpdHkgaXMgYm91bmQgdG8gYSBzcGVjaWZpYyBzZXJ2aWNlIGFjY291bnQgaWRlbnRp dHkgKGkuZS4sIHRoZSByZXNvdXJjZSBvd25lciksIHRoZW4gUk9QQyByZWR1Y2VzIGRvd24gdG8g Q2xpZW50IENyZWRlbnRpYWxzLiBXaGF0J3MgdGhlIHBvaW50IGluIHBhc3NpbmcgdHdvIGlkZW50 aWZpZXJzIGFuZCB0d28gY3JlZGVudGlhbHMgZm9yIHRoZSBzYW1lIGlkZW50aXR5Pw0KDQrigJMN CkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5h bWF6b24uY29tL2lkZW50aXR5Lw0KIA0KDQrvu79PbiAyLzIxLzIwLCA2OjQ4IEFNLCAiT0F1dGgg b24gYmVoYWxmIG9mIE5laWwgTWFkZGVuIiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgbmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQoNCiAgICBTb3JyeSwgSSBt aXNzZWQgdGhhdCBtZXNzYWdlLiANCiAgICANCiAgICBXaGlsZSB0aGlzIG1heSBiZSBhIHNvbHV0 aW9uIGluIHNwZWNpZmljIGNpcmN1bXN0YW5jZXMsIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgYSBn ZW5lcmFsIHNvbHV0aW9uLiBlLmcuIGFuIEFTIG1heSBub3QgYWxsb3cgbWFudWFsbHkgY2hvb3Np bmcgdGhlIGNsaWVudF9pZCB0byBhdm9pZCB0aGluZ3MgbGlrZSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTQjc2VjdGlvbi00LjEz IG9yIG1heSByZXR1cm4gZGlmZmVyZW50IGludHJvc3BlY3Rpb24gcmVzdWx0cyBmb3IgY2xpZW50 IGNyZWRlbnRpYWxzIHRva2VucyAoZS5nLiB3aXRoIG5vIOKAnHN1YuKAnSkgYW5kIHNvIG9uLiBJ biBwcmFjdGljZSwgdGhpcyBhZGRzIGV2ZW4gbW9yZSBzdGVwcyBmb3Igc29tZWJvZHkgdG8gbWln cmF0ZSBmcm9tIGV4aXN0aW5nIFJPUEMgdXNhZ2UuDQogICAgDQogICAgVGhpcyBpcyBhc2tpbmcg cGVvcGxlIHRvIG1ha2UgZnVuZGFtZW50YWwgY2hhbmdlcyB0byB0aGVpciBpZGVudGl0eSBhcmNo aXRlY3R1cmUgcmF0aGVyIHRoYW4gc2ltcGx5IHN3aXRjaGluZyB0byBhIG5ldyBncmFudCB0eXBl Lg0KICAgIA0KICAgIOKAlCBOZWlsDQogICAgDQogICAgPiBPbiAyMSBGZWIgMjAyMCwgYXQgMTQ6 MzQsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToN CiAgICA+IA0KICAgID4gSSBzZWUgLSB3ZSBoYXZlIGdvbmUgZnVsbCBjeWNsZSA6LSkgDQogICAg PiANCiAgICA+IEFubmFiZWxsZeKAmXMgcHJvcG9zYWwgd291bGQgc29sdmUgdGhhdC4gUmVsYXRl IGEgY2xpZW50IGlkIHRvIGEgc2VydmljZSBhY2NvdW50IGFuZCBvYnRhaW4gdGhlIHRva2VuIGRh dGEgZnJvbSB0aGVyZS4gDQogICAgPiANCiAgICA+PiBPbiAyMS4gRmViIDIwMjAsIGF0IDE1OjMx LCBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQogICAgPj4g DQogICAgPj4gWWVzLCB0aGF0IGlzIGdyZWF0LiBCdXQgbVRMUyBkb2VzbuKAmXQgc3VwcG9ydCBz ZXJ2aWNlIGFjY291bnRzICghPSBjbGllbnRzKS4gTWF5YmUgaXQgc2hvdWxkPyBTaG91bGQgdGhl cmUgYmUgYSBtVExTICpncmFudCB0eXBlKj8NCiAgICA+PiANCiAgICA+PiDigJQgTmVpbA0KICAg ID4+IA0KICAgID4+PiBPbiAyMSBGZWIgMjAyMCwgYXQgMTQ6MjAsIFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToNCiAgICA+Pj4gDQogICAgPj4+IEhh dmUgeW91IGV2ZXIgdHJpZWQgdGhlIGNsaWVudCBjcmVkZW50aWFscyBncmFudCB3aXRoIG1UTFM/ IEFmdGVyIHJlYWRpbmcgeW91ciBkZXNjcmlwdGlvbiBpdCBzZWVtcyB0byBiZSBzaW1wbGVyIHRo YW4gSldUIEJlYXJlci4NCiAgICA+Pj4gDQogICAgPj4+ICogd29yayBvdXQgaWYgdGhlIEFTIGV2 ZW4gc3VwcG9ydHMgbVRMUw0KICAgID4+PiAqIHdvcmsgb3V0IGhvdyB0byBjb25maWd1cmUgdGhl IEFTIHRvIHRydXN0IG15IGNlcnQocykNCiAgICA+Pj4gKiBDcmVhdGUga2V5IHBhaXIgYW5kIGNl cnQgdXNpbmcgb3BlbnNzbA0KICAgID4+PiAqIFJlZ2lzdGVyIHlvdXIgKHNlbGYtc2lnbmVkKSBj ZXJ0IGFsb25nIHdpdGggeW91ciBjbGllbnRfaWQNCiAgICA+Pj4gKiBDb25maWd1cmUgdGhlIEhU VFAgY2xpZW50IHRvIHVzZSB5b3VyIGtleSBwYWlyIGZvciBUTFMgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uDQogICAgPj4+IA0KICAgID4+PiBXb3JrcyB2ZXJ5IHdlbGwgZm9yIHVzLiANCiAgICA+Pj4g DQogICAgPj4+PiBPbiAyMS4gRmViIDIwMjAsIGF0IDE1OjEyLCBOZWlsIE1hZGRlbiA8bmVpbC5t YWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQogICAgPj4+PiANCiAgICA+Pj4+IE5vIGZhaWx1 cmVzLCBidXQgaXQgaXMgYSBtdWNoIG1vcmUgY29tcGxleCBncmFudCB0eXBlIHRvIHNldCB1cCwg d2hlbiB5b3UgY29uc2lkZXIgZXZlcnl0aGluZyB5b3UgaGF2ZSB0byBkbzoNCiAgICA+Pj4+IA0K ICAgID4+Pj4gKiB3b3JrIG91dCBpZiB0aGUgQVMgZXZlbiBzdXBwb3J0cyBKV1QgYmVhcmVyIGFu ZCBob3cgdG8gdHVybiBpdCBvbg0KICAgID4+Pj4gKiB3b3JrIG91dCBob3cgdG8gY29uZmlndXJl IHRoZSBBUyB0byB0cnVzdCBteSBwdWJsaWMga2V5KHMpDQogICAgPj4+PiAtIGRvIEkgaGF2ZSB0 byBjcmVhdGUgYSBuZXcgSFRUUFMgZW5kcG9pbnQgdG8gcHVibGlzaCBhIEpXSyBTZXQ/DQogICAg Pj4+PiAqIGRldGVybWluZSB0aGUgY29ycmVjdCBzZXR0aW5ncyBmb3IgaXNzdWVyLCBhdWRpZW5j ZSwgc3ViamVjdCwgZXRjLiBEb2VzIHRoZSBBUyBpbXBvc2Ugbm9uLXN0YW5kYXJkIHJlcXVpcmVt ZW50cz8gZS5nLiBSRkMgNzUyMyBzYXlzIHRoYXQgdGhlIEpXVCBNVVNUIGNvbnRhaW4gYSDigJxz dWLigJ0gY2xhaW0sIGJ1dCBHb29nbGUgb25seSBhbGxvd3MgdGhpcyB0byBiZSBwcmVzZW50IGlm IHlvdXIgY2xpZW50IGlzIGRvaW5nIGltcGVyc29uYXRpb24gb2YgYW4gZW5kLXVzZXIgKHdoaWNo IHJlcXVpcmVzIGFkZGl0aW9uYWwgcGVybWlzc2lvbnMpLg0KICAgID4+Pj4gKiBkbyBJIG5lZWQg YSB1bmlxdWUg4oCcanRp4oCdIGNsYWltPyAoT0lEQyBzZXJ2ZXJzIGRvLCBwbGFpbiBPQXV0aCBv bmVzIG1pZ2h0IG5vdCkgSWYgSSBkbywgY2FuIEkgcmV1c2UgdGhlIEpXVCBvciBtdXN0IGl0IGJl IGZyZXNobHkgc2lnbmVkIGZvciBldmVyeSBjYWxsPw0KICAgID4+Pj4gKiBsb2NhdGUgYW5kIGV2 YWx1YXRlIGEgSldUIGxpYnJhcnkgZm9yIG15IGxhbmd1YWdlIG9mIGNob2ljZS4gTW9uaXRvciB0 aGF0IG5ldyBkZXBlbmRlbmN5IGZvciBzZWN1cml0eSBhZHZpc29yaWVzLg0KICAgID4+Pj4gKiBj aG9vc2UgYSBzdWl0YWJsZSBzaWduYXR1cmUgYWxnb3JpdGhtICjigJhlcmUgYmUgZHJhZ29ucykN CiAgICA+Pj4+ICogZmlndXJlIG91dCBob3cgdG8gZGlzdHJpYnV0ZSB0aGUgcHJpdmF0ZSBrZXkg dG8gbXkgc2VydmljZQ0KICAgID4+Pj4gDQogICAgPj4+PiBDb21wYXJlZCB0byDigJxjcmVhdGUg YSBzZXJ2aWNlIGFjY291bnQgYW5kIFBPU1QgdGhlIHVzZXJuYW1lIGFuZCBwYXNzd29yZCB0byB0 aGUgdG9rZW4gZW5kcG9pbnTigJ0gaXQgYWRkcyBhIGxpdHRsZSBmcmljdGlvbi4gKEl0IGFsc28g YWRkcyBhIGxvdCBvZiBhZHZhbnRhZ2VzLCBidXQgaXQgaXMgdW5kZW5pYWJseSBtb3JlIGNvbXBs ZXgpLg0KICAgID4+Pj4gDQogICAgPj4+PiDigJQgTmVpbA0KICAgID4+Pj4gDQogICAgPj4+PiAN CiAgICA+Pj4+PiBPbiAyMSBGZWIgMjAyMCwgYXQgMTM6NDEsIE1hdHRoZXcgRGUgSGFhc3QgPG1h dHQ9NDBjb2lsLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPj4+Pj4gDQogICAgPj4+ Pj4gSSBoYXZlIGEgZmVlbGluZyB0aGF0IGlmIHdlIGhhZCBtb3JlIGNvbmNpc2UgSldUIGxpYnJh cmllcyBhbmQgY29tbWFuZCBsaW5lIHRvb2xzLCB3aGVyZSB1c2luZyB0aGUgSldUIEJlYXJlciBn cmFudCBiZWNhbWUgYSBvbmUtbGluZXIgYWdhaW4gdGhlbiB3ZSB3b3VsZG7igJl0IGJlIGhhdmlu ZyB0aGlzIGNvbnZlcnNhdGlvbi4gU28gcGVyaGFwcyByZW1vdmluZyBpdCBpcyBhbiBpbmNlbnRp dmUgdG8gbWFrZSB0aGF0IGhhcHBlbi4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBOZWlsIGNvdWxk IHlvdSBlbGFib3JhdGUgbW9yZSBvbiB0aGlzIHBsZWFzZS4gV2hhdCBmYWlsdXJlcyBhcmUgeW91 IGN1cnJlbnRseSBleHBlcmllbmNpbmcvc2VlaW5nIHdpdGggdGhlIEpXVCBCZWFyZXIgZ3JhbnQ/ IA0KICAgID4+Pj4+IA0KICAgID4+Pj4+IE1hdHQNCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBPbiBU aHUsIEZlYiAyMCwgMjAyMCBhdCAxMjo0MiBBTSBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9y Z2Vyb2NrLmNvbT4gd3JvdGU6DQogICAgPj4+Pj4gSSBoYXZlIGEgZmVlbGluZyB0aGF0IGlmIHdl IGhhZCBtb3JlIGNvbmNpc2UgSldUIGxpYnJhcmllcyBhbmQgY29tbWFuZCBsaW5lIHRvb2xzLCB3 aGVyZSB1c2luZyB0aGUgSldUIEJlYXJlciBncmFudCBiZWNhbWUgYSBvbmUtbGluZXIgYWdhaW4g dGhlbiB3ZSB3b3VsZG7igJl0IGJlIGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbi4gU28gcGVyaGFw cyByZW1vdmluZyBpdCBpcyBhbiBpbmNlbnRpdmUgdG8gbWFrZSB0aGF0IGhhcHBlbi4NCiAgICA+ Pj4+PiANCiAgICA+Pj4+PiANCiAgICA+Pj4+Pj4gT24gMTkgRmViIDIwMjAsIGF0IDIyOjAxLCBE aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPj4+Pj4+IA0KICAg ID4+Pj4+PiBOZWlsOiBhcmUgeW91IGFkdm9jYXRpbmcgdGhhdCBwYXNzd29yZCBncmFudCBiZSBw cmVzZXJ2ZWQgaW4gMi4xPyBPciBkbyB5b3UgdGhpbmsgdGhhdCBzZXJ2aWNlIGFjY291bnQgZGV2 ZWxvcGVycyBrbm93IGVub3VnaCBhYm91dCB3aGF0IHRoZXkgYXJlIGRvaW5nIHRvIGZvbGxvdyB3 aGF0IGlzIGluIDY3NDk/DQogICAgPj4+Pj4+IOGQpw0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4g T24gV2VkLCBGZWIgMTksIDIwMjAgYXQgMTo1MiBQTSBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5A Zm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQogICAgPj4+Pj4+IE9BdXRoMiBjbGllbnRzIGFyZSBvZnRl biBwcml2YXRlIHRvIHRoZSBBUyAtIHRoZXkgbGl2ZSBpbiBhIGRhdGFiYXNlIHRoYXQgb25seSB0 aGUgQVMgY2FuIGFjY2VzcywgaGF2ZSBhdHRyaWJ1dGVzIHNwZWNpZmljIHRvIHRoZWlyIHVzZSBp biBPQXV0aDIsIGFuZCBzbyBvbi4gTWFueSBleGlzdGluZyBzeXN0ZW1zIGhhdmUgYWNjZXNzIGNv bnRyb2xzIGJhc2VkIG9uIHVzZXJzLCByb2xlcywgcGVybWlzc2lvbnMgYW5kIHNvIG9uIGFuZCBl eHBlY3QgYWxsIHVzZXJzIGFjY2Vzc2luZyB0aGUgc3lzdGVtIHRvIGV4aXN0IGluIHNvbWUgdXNl ciByZXBvc2l0b3J5LCBlLmcuIExEQVAsIHdoZXJlIHRoZXkgY2FuIGJlIGxvb2tlZCB1cCBhbmQg YXBwcm9wcmlhdGUgcGVybWlzc2lvbnMgZGV0ZXJtaW5lZC4gQSBzZXJ2aWNlIGFjY291bnQgY2Fu IGJlIGNyZWF0ZWQgaW5zaWRlIHN1Y2ggYSBzeXN0ZW0gYXMgaWYgaXQgd2FzIGEgcmVndWxhciB1 c2VyLCBtYW5hZ2VkIHRocm91Z2ggdGhlIG5vcm1hbCBhY2NvdW50IHByb3Zpc2lvbmluZyB0b29s cywgYXNzaWduZWQgcGVybWlzc2lvbnMsIHJvbGVzLCBldGMuDQogICAgPj4+Pj4+IA0KICAgID4+ Pj4+PiBBbm90aGVyIHJlYXNvbiBpcyB0aGF0IHNvbWV0aW1lcyBPQXV0aCBpcyBqdXN0IG9uZSBh dXRoZW50aWNhdGlvbiBvcHRpb24gb3V0IG9mIG1hbnksIGFuZCBzbyBwZXJtaXNzaW9ucyBhc3Np Z25lZCB0byBzZXJ2aWNlIGFjY291bnRzIGFyZSBwcmVmZXJyZWQgb3ZlciBzY29wZXMgYmVjYXVz ZSB0aGV5IGFyZSBjb25zaXN0ZW50bHkgYXBwbGllZCBubyBtYXR0ZXIgaG93IGEgcmVxdWVzdCBp cyBhdXRoZW50aWNhdGVkLiBUaGlzIGlzIG9mdGVuIHRoZSBjYXNlIHdoZW4gT0F1dGggaGFzIGJl ZW4gcmV0cm9maXR0ZWQgdG8gYW4gZXhpc3Rpbmcgc3lzdGVtIGFuZCB0aGV5IG5lZWQgdG8gcHJl c2VydmUgY29tcGF0aWJpbGl0eSB3aXRoIGFscmVhZHkgZGVwbG95ZWQgY2xpZW50cy4NCiAgICA+ Pj4+Pj4gDQogICAgPj4+Pj4+IFNlZSBlLmcuIEdvb2dsZSBjbG91ZCBwbGF0Zm9ybSAoR0NQKTog aHR0cHM6Ly9kZXZlbG9wZXJzLmdvb2dsZS5jb20vaWRlbnRpdHkvcHJvdG9jb2xzL09BdXRoMlNl cnZpY2VBY2NvdW50DQogICAgPj4+Pj4+IFRoZXkgdXNlIHRoZSBKV1QgYmVhcmVyIGdyYW50IHR5 cGUgZm9yIHNlcnZpY2UgYWNjb3VudCBhdXRoZW50aWNhdGlvbiBhbmQgYXNzaWduIHBlcm1pc3Np b25zIHRvIHRob3NlIHNlcnZpY2UgYWNjb3VudHMgYW5kIHR5cGljYWxseSBoYXZlIHZlcnkgYnJv YWQgc2NvcGVzLiBGb3Igc2VydmljZS10by1zZXJ2aWNlIEFQSSBjYWxscyB5b3UgdHlwaWNhbGx5 IGdldCBhbiBhY2Nlc3MgdG9rZW4gd2l0aCBhIHNpbmdsZSBzY29wZSB0aGF0IGlzIGVmZmVjdGl2 ZWx5IOKAnGFsbCBvZiBHQ1DigJ0gYW5kIGV2ZXJ5dGhpbmcgaXMgbWFuYWdlZCBhdCB0aGUgbGV2 ZWwgb2YgcGVybWlzc2lvbnMgb24gdGhlIFJPIHNlcnZpY2UgYWNjb3VudCBpdHNlbGYuIFRoZXkg b25seSBicmVhayBkb3duIGZpbmUtZ3JhaW5lZCBzY29wZXMgd2hlbiB5b3UgYXJlIGRlYWxpbmcg d2l0aCB1c2VyIGRhdGEgYW5kIHdpbGwgYmUgZ2V0dGluZyBhbiBhY2Nlc3MgdG9rZW4gYXBwcm92 ZWQgYnkgYSByZWFsIHVzZXIgKHRocm91Z2ggYSBub3JtYWwgYXV0aCBjb2RlIGZsb3cpLg0KICAg ID4+Pj4+PiANCiAgICA+Pj4+Pj4g4oCUIE5laWwNCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+PiBP biAxOSBGZWIgMjAyMCwgYXQgMjE6MzUsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PiB3cm90ZToNCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gQ2FuIHlvdSBl eHBsYWluIG1vcmUgaW4gZGV0YWlsIHdoeSB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IHR5 cGUgaXNu4oCZdCBhcHBsaWNhYmxlIGZvciB0aGUga2luZCBvZiB1c2UgY2FzZXMgeW91IG1lbnRp b25lZD8NCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+IEFtIDE5LjAyLjIwMjAgdW0gMjI6MDMg c2NocmllYiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT46DQogICAgPj4+ Pj4+Pj4gDQogICAgPj4+Pj4+Pj4gSSB2ZXJ5IG11Y2ggYWdyZWUgd2l0aCB0aGlzIHdpdGggcmVn YXJkcyB0byByZWFsIHVzZXJzLiANCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiBUaGUgb25l IGxlZ2l0aW1hdGUgdXNlLWNhc2UgZm9yIFJPUEMgSeKAmXZlIHNlZW4gaXMgZm9yIHNlcnZpY2Ug YWNjb3VudHMgLSB3aGVyZSB5b3UgZXNzZW50aWFsbHkgd2FudCBzb21ldGhpbmcgbGlrZSBjbGll bnRfY3JlZGVudGlhbHMgYnV0IGZvciB3aGF0ZXZlciByZWFzb24geW91IG5lZWQgdGhlIFJPIHRv IGJlIGEgc2VydmljZSB1c2VyIHJhdGhlciB0aGFuIGFuIE9BdXRoMiBjbGllbnQgKHR5cGljYWxs eSBzbyB0aGF0IHNvbWUgbG93ZXIgbGF5ZXIgb2YgdGhlIHN5c3RlbSBjYW4gc3RpbGwgcGVyZm9y bSBpdHMgcmVxdWlyZWQgcGVybWlzc2lvbiBjaGVja3MpLg0KICAgID4+Pj4+Pj4+IA0KICAgID4+ Pj4+Pj4+IFRoZXJlIGFyZSBiZXR0ZXIgZ3JhbnQgdHlwZXMgZm9yIHRoaXMgLSBlLmcuIEpXVCBi ZWFyZXIgLSBidXQgdGhleSBhcmUgYSBiaXQgaGFyZGVyIHRvIGltcGxlbWVudC4gSGF2aW5nIHJl Y2VudGx5IGNvbnZlcnRlZCBzb21lIGNvZGUgZnJvbSBST1BDIHRvIEpXVCBiZWFyZXIgZm9yIGV4 YWN0bHkgdGhpcyB1c2UtY2FzZSwgaXQgd2VudCBmcm9tIGEgY291cGxlIG9mIGxpbmVzIG9mIGNv ZGUgdG8gdHdvIHNjcmVlbnMgb2YgY29kZS4gRm9yIHNlcnZpY2UgdG8gc2VydmljZSBBUEkgY2Fs bHMgd2l0aGluIGEgZGF0YWNlbnRlciBJ4oCZbSBub3QgY29udmluY2VkIHRoaXMgcmVzdWx0ZWQg aW4gYSBtYXRlcmlhbCBpbmNyZWFzZSBpbiBzZWN1cml0eSBmb3IgdGhlIGFkZGVkIGNvbXBsZXhp dHkuDQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4g4oCUIE5laWwNCiAgICA+Pj4+Pj4+PiAN CiAgICA+Pj4+Pj4+Pj4gT24gMTggRmViIDIwMjAsIGF0IDIxOjU3LCBIYW5zIFphbmRiZWx0IDxo YW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4gd3JvdGU6DQogICAgPj4+Pj4+Pj4+IA0KICAgID4+ Pj4+Pj4+PiBJIHdvdWxkIGFsc28gc2VyaW91c2x5IGxvb2sgYXQgdGhlIG9yaWdpbmFsIG1vdGl2 YXRpb24gYmVoaW5kIFJPUEM6IEkga25vdyBpdCBoYXMgYmVlbiBkZXBsb3llZCBhbmQgaXMgdXNl ZCBpbiBxdWl0ZSBhIGxvdCBvZiBwbGFjZXMgYnV0IEkgaGF2ZSBuZXZlciBhY3R1YWxseSBjb21l IGFjcm9zcyBhIHVzZSBjYXNlIHdoZXJlIGl0IGlzIHVzZWQgZm9yIG1pZ3JhdGlvbiBwdXJwb3Nl cyBhbmQgdGhlIG1pZ3JhdGlvbiBpcyBhY3R1YWxseSBleGVjdXRlZCAoSSBrbm93IHRoYXQgaXMg c3RhdGlzdGljYWxseSBub3QgYSB2ZXJ5IHN0cm9uZyBhcmd1bWVudCBidXQgSSBjaGFsbGVuZ2Ug b3RoZXJzIHRvIGNvbWUgdXAgd2l0aCBvbmUuLi4pDQogICAgPj4+Pj4+Pj4+IEluIHJlYWxpdHkg aXQgdHVybmVkIG91dCBqdXN0IHRvIGJlIGEgb25lIG9mZiB0aGF0IHBlb3BsZSB1c2VkIGFzIGFu IGVhc3kgd2F5IG91dCB0byBzdGljayB0byBhbiBhbnRpLXBhdHRlcm4gYW5kIHN0aWxsIGNsYWlt IHRvIGRvIE9BdXRoIDIuMC4gSXQgaXMgcGxhaW4gd3JvbmcsIGl0IGlzIG5vdCBPQXV0aCBhbmQg d2UgbmVlZCB0byBnZXQgcmlkIG9mIGl0Lg0KICAgID4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4g SGFucy4NCiAgICA+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+IE9uIFR1ZSwgRmViIDE4LCAyMDIw IGF0IDEwOjQ0IFBNIEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPiB3cm90ZToNCiAg ICA+Pj4+Pj4+Pj4gQWdyZWVkLiBQbHVzLCB0aGUgU2VjdXJpdHkgQkNQIGlzIGFscmVhZHkgZWZm ZWN0aXZlbHkgYWN0aW5nIGFzIGEgZ3JhY2UgcGVyaW9kIHNpbmNlIGl0IGN1cnJlbnRseSBzYXlz IHRoZSBwYXNzd29yZCBncmFudCBNVVNUIE5PVCBiZSB1c2VkLCBzbyBpbiB0aGUgT0F1dGggMi4w IHdvcmxkIHRoYXQncyBhbHJlYWR5IGEgcHJldHR5IHN0cm9uZyBzaWduYWwuLg0KICAgID4+Pj4+ Pj4+PiANCiAgICA+Pj4+Pj4+Pj4gQWFyb24NCiAgICA+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+ IA0KICAgID4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4gT24gVHVlLCBGZWIgMTgsIDIwMjAgYXQg NDoxNiBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOg0KICAgID4+Pj4+ Pj4+PiBUaGVyZSBpcyBubyBuZWVkIGZvciBhIGdyYWNlIHBlcmlvZC4gUGVvcGxlIHVzaW5nIE9B dXRoIDIuLjAgY2FuIHN0aWxsIGRvIE9BdXRoIDIuMC4gUGVvcGxlIHVzaW5nIE9BdXRoIDIuMSB3 aWxsIGRvIE9BdXRoIDIuMS4gDQogICAgPj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+PiDigJQgSnVz dGluDQogICAgPj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4+IE9uIEZlYiAxOCwgMjAyMCwgYXQg Mzo1NCBQTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p ZXRmLm9yZz4gd3JvdGU6DQogICAgPj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+IEkgd291bGQg c3VnZ2VzdCBhIFNIT1VMRCBOT1QgaW5zdGVhZCBvZiBNVVNULCB0aGVyZSBhcmUgc3RpbGwgc2l0 ZXMgdXNpbmcgdGhpcyBhbmQgYSBncmFjZSBwZXJpb2Qgc2hvdWxkIGJlIHByb3ZpZGVkIGJlZm9y ZSBhIE1VU1QgaXMgcHVzaGVkIG91dCBhcyB0aGVyZSBhcmUgdmFsaWQgdXNlIGNhc2VzIG91dCB0 aGVyZSBzdGlsbC4NCiAgICA+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4gRnJvbTogT0F1dGgg PG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBEaWNrIEhhcmR0DQogICAgPj4+ Pj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAyMCAxMjozNyBQTQ0KICAgID4+ Pj4+Pj4+Pj4gVG86IG9hdXRoQGlldGYub3JnDQogICAgPj4+Pj4+Pj4+PiBTdWJqZWN0OiBbRVhU RVJOQUxdIFtPQVVUSC1XR10gT0F1dGggMi4xOiBkcm9wcGluZyBwYXNzd29yZCBncmFudA0KICAg ID4+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+PiBIZXkgTGlzdCANCiAgICA+Pj4+Pj4+Pj4+IA0K ICAgID4+Pj4+Pj4+Pj4gKE9uY2UgYWdhaW4gdXNpbmcgdGhlIE9BdXRoIDIuMSBuYW1lIGFzIGEg cGxhY2Vob2xkZXIgZm9yIHRoZSBkb2MgdGhhdCBBYXJvbiwgVG9yc3RlbiwgYW5kIEkgYXJlIHdv cmtpbmcgb24pDQogICAgPj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+IEluIHRoZSBzZWN1cml0 eSB0b3BpY3MgZG9jDQogICAgPj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNCNzZWN0 aW9uLTIuNA0KICAgID4+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+PiBUaGUgcGFzc3dvcmQgZ3Jh bnQgTVVTVCBub3QgYmUgdXNlZC4NCiAgICA+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4gU29t ZSBiYWNrZ3JvdW5kIGZvciB0aG9zZSBpbnRlcmVzdGVkLiBJIGFkZGVkIHRoaXMgZ3JhbnQgaW50 byBPQXV0aCAyLjAgdG8gYWxsb3cgYXBwbGljYXRpb25zIHRoYXQgaGFkIGJlZW4gcHJvdmlkZWQg cGFzc3dvcmQgdG8gbWlncmF0ZS4gRXZlbiB3aXRoIHRoZSBjYXZlYXRzIGluIE9BdXRoIDIuMCwg aW1wbGVtZW50b3JzIGRlY2lkZSB0aGV5IHdhbnQgdG8gcHJvbXB0IHRoZSB1c2VyIHRvIGVudGVy IHRoZWlyIGNyZWRlbnRpYWxzLCB0aGUgYW50aS1wYXR0ZXJuIE9BdXRoIHdhcyBjcmVhdGVkIHRv IGVsaW1pbmF0ZS4gDQogICAgPj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+ Pj4+Pj4gRG9lcyBhbnlvbmUgaGF2ZSBjb25jZXJucyB3aXRoIGRyb3BwaW5nIHRoZSBwYXNzd29y ZCBncmFudCBmcm9tIHRoZSBPQXV0aCAyLjEgZG9jdW1lbnQgc28gdGhhdCBkZXZlbG9wZXJzIGRv bid0IHVzZSBpdD8NCiAgICA+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4gL0RpY2sNCiAgICA+ Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgPj4+Pj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+Pj4+Pj4+IE9BdXRo QGlldGYub3JnDQogICAgPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQogICAgPj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4+Pj4+PiBPQXV0aCBt YWlsaW5nIGxpc3QNCiAgICA+Pj4+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcNCiAgICA+Pj4+Pj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4+Pj4+Pj4+ PiAtLSANCiAgICA+Pj4+Pj4+Pj4gLS0tLQ0KICAgID4+Pj4+Pj4+PiBBYXJvbiBQYXJlY2tpDQog ICAgPj4+Pj4+Pj4+IGFhcm9ucGFyZWNraS5jb20NCiAgICA+Pj4+Pj4+Pj4gQGFhcm9ucGsNCiAg ICA+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgPj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAg ID4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgPj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+ PiANCiAgICA+Pj4+Pj4+Pj4gLS0gDQogICAgPj4+Pj4+Pj4+IGhhbnMuemFuZGJlbHRAem1hcnR6 b25lLmV1DQogICAgPj4+Pj4+Pj4+IFptYXJ0Wm9uZSBJQU0gLSB3d3cuem1hcnR6b25lLmV1DQog ICAgPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgPj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4+Pj4+Pj4+PiBPQXV0 aEBpZXRmLm9yZw0KICAgID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+Pj4+PiBPQXV0aCBtYWls aW5nIGxpc3QNCiAgICA+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICA+Pj4+Pj4gDQogICAg Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgPj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0K ICAgID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQog ICAgPj4+Pj4gDQogICAgPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICA+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+PiBPQXV0 aEBpZXRmLm9yZw0KICAgID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCiAgICA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgID4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4+Pj4+IE9BdXRo QGlldGYub3JnDQogICAgPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KICAgID4+Pj4gDQogICAgPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQogICAgPj4+ PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KICAgID4+PiANCiAgICA+PiANCiAgICA+IA0KICAgIA0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgT0F1dGggbWFp bGluZyBsaXN0DQogICAgT0F1dGhAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgDQoNCg== From nobody Fri Feb 21 13:04:34 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35812009C for ; Fri, 21 Feb 2020 13:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i2891xAQHui for ; Fri, 21 Feb 2020 13:04:30 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DF9120089 for ; Fri, 21 Feb 2020 13:04:29 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01LL4OW7030554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 16:04:25 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> Date: Fri, 21 Feb 2020 16:04:23 -0500 Cc: Neil Madden , Torsten Lodderstedt , Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:04:33 -0000 +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, and = it=E2=80=99s time to get rid of it and send people toward what they = really ought to be doing. Another thing I=E2=80=99ve seen is using different service accounts to = get different sets of access for one client =E2=80=94 if you=E2=80=99re = doing that, you=E2=80=99ve got a client pretending to do two different = things, or your APIs should be using scopes to differentiate access = instead of client/user identity.=20 =E2=80=94 Justin > On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle = wrote: >=20 > The client IDs can still be opaque identifiers provided by the AS, = they just happen to be associated with specific service accounts. Or = they could be the opaque IDs that the AS already issued for the service = account. Either way, the AS could issue a token with the appropriate = subject and other claims for the service account. >=20 > If your client identity is bound to a specific service account = identity (i.e., the resource owner), then ROPC reduces down to Client = Credentials. What's the point in passing two identifiers and two = credentials for the same identity? >=20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ >=20 >=20 > =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" = wrote: >=20 > Sorry, I missed that message.=20 >=20 > While this may be a solution in specific circumstances, I don=E2=80=99= t think it=E2=80=99s a general solution. e.g. an AS may not allow = manually choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. >=20 > This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. >=20 > =E2=80=94 Neil >=20 >> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>=20 >> I see - we have gone full cycle :-)=20 >>=20 >> Annabelle=E2=80=99s proposal would solve that. Relate a client id to = a service account and obtain the token data from there.=20 >>=20 >>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>>=20 >>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? >>>=20 >>> =E2=80=94 Neil >>>=20 >>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>>=20 >>>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>>=20 >>>> * work out if the AS even supports mTLS >>>> * work out how to configure the AS to trust my cert(s) >>>> * Create key pair and cert using openssl >>>> * Register your (self-signed) cert along with your client_id >>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>>=20 >>>> Works very well for us.=20 >>>>=20 >>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>>=20 >>>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>>=20 >>>>> * work out if the AS even supports JWT bearer and how to turn it = on >>>>> * work out how to configure the AS to trust my public key(s) >>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? >>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>>> * figure out how to distribute the private key to my service >>>>>=20 >>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). >>>>>=20 >>>>> =E2=80=94 Neil >>>>>=20 >>>>>=20 >>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>>=20 >>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>=20 >>>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>=20 >>>>>> Matt >>>>>>=20 >>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>=20 >>>>>>=20 >>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>>=20 >>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? >>>>>>> =E1=90=A7 >>>>>>>=20 >>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>>=20 >>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. >>>>>>>=20 >>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>>=20 >>>>>>> =E2=80=94 Neil >>>>>>>=20 >>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>>=20 >>>>>>>> Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>>>>>=20 >>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>>=20 >>>>>>>>> I very much agree with this with regards to real users.=20 >>>>>>>>>=20 >>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>>=20 >>>>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Neil >>>>>>>>>=20 >>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>>=20 >>>>>>>>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>=20 >>>>>>>>>> Aaron >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>=20 >>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>=20 >>>>>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>>>=20 >>>>>>>>>>> Hey List=20 >>>>>>>>>>>=20 >>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>=20 >>>>>>>>>>> In the security topics doc >>>>>>>>>>>=20 >>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>>=20 >>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>=20 >>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>=20 >>>>>>>>>>> /Dick >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> ---- >>>>>>>>>> Aaron Parecki >>>>>>>>>> aaronparecki.com >>>>>>>>>> @aaronpk >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=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 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Feb 21 13:53:13 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B63C120123 for ; Fri, 21 Feb 2020 13:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 iFEpFV8xecak for ; Fri, 21 Feb 2020 13:53:00 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238261200C5 for ; Fri, 21 Feb 2020 13:53:00 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id z12so65095wmi.4 for ; Fri, 21 Feb 2020 13:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yXcY+DwKXDViBVWk0pwPkSZPvpMmCisnzHdBhjLBL+o=; b=bJPVW8rqIKy7S7zMo4MbUbQL47GSRpL3prjxcWQexL9YUCRth1JSVHiBJ5wLtTfDxh f2heBFa9NJkIf+pi3uE6xOXQ09IiJDRbXEsan8aL86w4+khwbjMMBJjJCIEYpbAyMev+ O7YggHF00Yo7RlvS0BtyCzbcqFTLzzRKpfEkE= 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=yXcY+DwKXDViBVWk0pwPkSZPvpMmCisnzHdBhjLBL+o=; b=VEz8CE31yISeCLusHtleN+YRgZ4YpgfeLluMk3DsO88KM5S6QRqGGVfFSDo4C3xbe4 4k1MXibXoe1vjBgjTedLQLLpm81p9R3811lRqSsUH5owa5b+UNaQ99MucP/uH2AAclZd iLmr5n9JsFCM0gcO2wfgGiXJglwCRy8V7WGbbqyPq8MD8lWpS1tMNIkU4OrqoZ2ChZSf 033Au3qH+LckKbYiI/VJ13gHtW4atuGq/jLVKAZ4cw2jyPpoY97yn58SM3gyfgW7z3xj npZrSZrTCr8Rz9RTgLWk7NvyUqQ9PWh8ho9jYA+n2mqGPYL/DyYnYYv1MpeXFKd00hMK g4rQ== X-Gm-Message-State: APjAAAVxpXUA/w1Ck93+1OzM8xD9rvZdi3J5RcsOmcjwFp+/hGv1APDP gXmHp36Z8yji8hatCM1Cq2k4YA== X-Google-Smtp-Source: APXvYqw82wvFf+U7Y2Qka/mj3Q1brs0GTbPJmcPG0OtLjh5ioWGl4HbqoK7MASFdSc/8ZWZG6UvpNQ== X-Received: by 2002:a1c:9c87:: with SMTP id f129mr6119507wme.26.1582321978351; Fri, 21 Feb 2020 13:52:58 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id r3sm5755873wrn.34.2020.02.21.13.52.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 13:52:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> Date: Fri, 21 Feb 2020 21:52:56 +0000 Cc: Torsten Lodderstedt , Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:53:10 -0000 The AS doesn=E2=80=99t issue the service account IDs, that=E2=80=99s the = whole point - integration with existing systems. Lot=E2=80=99s of people = don=E2=80=99t have the luxury of rebuilding systems from scratch to fit = in with the preferences of the OAuth WG. ROPC doesn=E2=80=99t require client authentication, or even a client = identifier. If you=E2=80=99re using a service account you indeed don=E2=80= =99t need to bother issuing client credentials. The same is true when = using the JWT bearer grant. If you want to increase security you can use = cert-bound access tokens. > On 21 Feb 2020, at 20:28, Richard Backman, Annabelle = wrote: >=20 > The client IDs can still be opaque identifiers provided by the AS, = they just happen to be associated with specific service accounts. Or = they could be the opaque IDs that the AS already issued for the service = account. Either way, the AS could issue a token with the appropriate = subject and other claims for the service account. >=20 > If your client identity is bound to a specific service account = identity (i.e., the resource owner), then ROPC reduces down to Client = Credentials. What's the point in passing two identifiers and two = credentials for the same identity? >=20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ >=20 >=20 > =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" = wrote: >=20 > Sorry, I missed that message.=20 >=20 > While this may be a solution in specific circumstances, I don=E2=80=99= t think it=E2=80=99s a general solution. e.g. an AS may not allow = manually choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. >=20 > This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. >=20 > =E2=80=94 Neil >=20 >> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>=20 >> I see - we have gone full cycle :-)=20 >>=20 >> Annabelle=E2=80=99s proposal would solve that. Relate a client id to = a service account and obtain the token data from there.=20 >>=20 >>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>>=20 >>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? >>>=20 >>> =E2=80=94 Neil >>>=20 >>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>>=20 >>>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>>=20 >>>> * work out if the AS even supports mTLS >>>> * work out how to configure the AS to trust my cert(s) >>>> * Create key pair and cert using openssl >>>> * Register your (self-signed) cert along with your client_id >>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>>=20 >>>> Works very well for us.=20 >>>>=20 >>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>>=20 >>>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>>=20 >>>>> * work out if the AS even supports JWT bearer and how to turn it = on >>>>> * work out how to configure the AS to trust my public key(s) >>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? >>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>>> * figure out how to distribute the private key to my service >>>>>=20 >>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). >>>>>=20 >>>>> =E2=80=94 Neil >>>>>=20 >>>>>=20 >>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>>=20 >>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>=20 >>>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>=20 >>>>>> Matt >>>>>>=20 >>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>=20 >>>>>>=20 >>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>>=20 >>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? >>>>>>> =E1=90=A7 >>>>>>>=20 >>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>>=20 >>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. >>>>>>>=20 >>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>>=20 >>>>>>> =E2=80=94 Neil >>>>>>>=20 >>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>>=20 >>>>>>>> Can you explain more in detail why the client credentials grant = type isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>>>>>=20 >>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>>=20 >>>>>>>>> I very much agree with this with regards to real users.=20 >>>>>>>>>=20 >>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>>=20 >>>>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Neil >>>>>>>>>=20 >>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>>=20 >>>>>>>>>> I would also seriously look at the original motivation behind = ROPC: I know it has been deployed and is used in quite a lot of places = but I have never actually come across a use case where it is used for = migration purposes and the migration is actually executed (I know that = is statistically not a very strong argument but I challenge others to = come up with one...) >>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>=20 >>>>>>>>>> Aaron >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>=20 >>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>=20 >>>>>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>>>=20 >>>>>>>>>>> Hey List=20 >>>>>>>>>>>=20 >>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>=20 >>>>>>>>>>> In the security topics doc >>>>>>>>>>>=20 >>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>>=20 >>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>=20 >>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>=20 >>>>>>>>>>> /Dick >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> ---- >>>>>>>>>> Aaron Parecki >>>>>>>>>> aaronparecki.com >>>>>>>>>> @aaronpk >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=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 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From nobody Fri Feb 21 14:31:52 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7CC1200E0 for ; Fri, 21 Feb 2020 14:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1qaNHMekNWH for ; Fri, 21 Feb 2020 14:31:44 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEAD1200C1 for ; Fri, 21 Feb 2020 14:31:43 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id t14so3492057wmi.5 for ; Fri, 21 Feb 2020 14:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lnHSvSlA5TrgXGodtety2L2/dwYSICsMJpMy+WcHUFM=; b=gPyvp6AsNYVk/TCa1EdurjYnIGIp6k+OhhjjeWvlTmOdHyn5TaWwBtTGErFXF5xhGE 3PUMpsuDAAE2zOaGyeTGqXZxdmRNJUs1PAHLmN+Qb7nuqGvmHs0wK/UaSOMZFZ6DLOsM 8te/TyJeY1OfER6vY0KFviX1+xTCHj9HiXiws= 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=lnHSvSlA5TrgXGodtety2L2/dwYSICsMJpMy+WcHUFM=; b=bVpCohtJC5y67cZ1N337R8QFu7ljFHsodrZAdZWv7G9xJ8YMAkCrSHag3lSHeo1Q32 WmS66+9/Cr7/tDFFhprObFqmVbxIIaDYF0KygPtugpCsQmReDcbGshVX9xVVT0vAjcGp nNjCKKqyuKaAjCXESlug0/+qlYb3CeUBiz8QcHOS16Mci/X5ceJTmzcqFJDd4zfTfGe1 TxooHdZIl3ixbugVOqL0TyWkq21nTt5gZMZW7m1D82GGRvDddUx8RG2irbECFL+YrYkZ oXSqOGs1GuMRW/wXRLuFxw1GYSBywMIYHa/2b3zmp8YDszFE46/oxbQavIOTqlgo2XHe BZxA== X-Gm-Message-State: APjAAAV5hK2ZiDU0SDC7rFIAdeYOyzQuM7Ovgw5VFuPsKHrj0mwldxuH wL8OU1awqfp8oj5xAYxuah+vVw== X-Google-Smtp-Source: APXvYqyggvSjX9xHulJHzl+IobTaJ5H0oaYoFmTQzC2TMWlEkxa1G7E+1Yc0nQQqb1FYuyZHGMZh7A== X-Received: by 2002:a1c:6389:: with SMTP id x131mr6159795wmb.155.1582324302066; Fri, 21 Feb 2020 14:31:42 -0800 (PST) Received: from zaphod.lan (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id o4sm5655589wrx.25.2020.02.21.14.31.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 14:31:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> Date: Fri, 21 Feb 2020 22:31:40 +0000 Cc: "Richard Backman, Annabelle" , Torsten Lodderstedt , Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 22:31:50 -0000 I=E2=80=99m not really sure the WG should be telling people what they = =E2=80=9Cought to be doing=E2=80=9D unless we have concrete security or = interoperability reasons for doing so. I also don=E2=80=99t agree that people doing this are doing anything = wrong. I don=E2=80=99t always agree with what our customers do, but = I=E2=80=99ve learnt over the years not to second-guess their reasons for = doing it. Are Google wrong for using the JWT bearer grant (not client credentials) = and service accounts? They even go so far as to say =E2=80=9Cscopes are = not a security mechanism=E2=80=9D [1] and tell people to use service = account roles instead. (Precisely because they also support non-OAuth = auth methods, which bypass any scopes). Are we really going to tell them to rewrite it all to use the client = credentials grant? [1]: = https://cloud.google.com/compute/docs/access/service-accounts#accesscopesi= am > On 21 Feb 2020, at 21:04, Justin Richer wrote: >=20 > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, = and it=E2=80=99s time to get rid of it and send people toward what they = really ought to be doing. >=20 > Another thing I=E2=80=99ve seen is using different service accounts to = get different sets of access for one client =E2=80=94 if you=E2=80=99re = doing that, you=E2=80=99ve got a client pretending to do two different = things, or your APIs should be using scopes to differentiate access = instead of client/user identity.=20 >=20 > =E2=80=94 Justin >=20 >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle = wrote: >>=20 >> The client IDs can still be opaque identifiers provided by the AS, = they just happen to be associated with specific service accounts. Or = they could be the opaque IDs that the AS already issued for the service = account. Either way, the AS could issue a token with the appropriate = subject and other claims for the service account. >>=20 >> If your client identity is bound to a specific service account = identity (i.e., the resource owner), then ROPC reduces down to Client = Credentials. What's the point in passing two identifiers and two = credentials for the same identity? >>=20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >>=20 >>=20 >> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" = wrote: >>=20 >> Sorry, I missed that message.=20 >>=20 >> While this may be a solution in specific circumstances, I don=E2=80=99= t think it=E2=80=99s a general solution. e.g. an AS may not allow = manually choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. >>=20 >> This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. >>=20 >> =E2=80=94 Neil >>=20 >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>>=20 >>> I see - we have gone full cycle :-)=20 >>>=20 >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id to = a service account and obtain the token data from there.=20 >>>=20 >>>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>>>=20 >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>>>=20 >>>>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>>>=20 >>>>> * work out if the AS even supports mTLS >>>>> * work out how to configure the AS to trust my cert(s) >>>>> * Create key pair and cert using openssl >>>>> * Register your (self-signed) cert along with your client_id >>>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>>>=20 >>>>> Works very well for us.=20 >>>>>=20 >>>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>>>=20 >>>>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>>>=20 >>>>>> * work out if the AS even supports JWT bearer and how to turn it = on >>>>>> * work out how to configure the AS to trust my public key(s) >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? >>>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>>>> * figure out how to distribute the private key to my service >>>>>>=20 >>>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). >>>>>>=20 >>>>>> =E2=80=94 Neil >>>>>>=20 >>>>>>=20 >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>>>=20 >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>=20 >>>>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>>=20 >>>>>>> Matt >>>>>>>=20 >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>>>=20 >>>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? >>>>>>>> =E1=90=A7 >>>>>>>>=20 >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>>>=20 >>>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. >>>>>>>>=20 >>>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>>>=20 >>>>>>>> =E2=80=94 Neil >>>>>>>>=20 >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>>>=20 >>>>>>>>> Can you explain more in detail why the client credentials = grant type isn=E2=80=99t applicable for the kind of use cases you = mentioned? >>>>>>>>>=20 >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>>>=20 >>>>>>>>>> I very much agree with this with regards to real users.=20 >>>>>>>>>>=20 >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>>>=20 >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Neil >>>>>>>>>>=20 >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would also seriously look at the original motivation = behind ROPC: I know it has been deployed and is used in quite a lot of = places but I have never actually come across a use case where it is used = for migration purposes and the migration is actually executed (I know = that is statistically not a very strong argument but I challenge others = to come up with one...) >>>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>>=20 >>>>>>>>>>> Aaron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>>=20 >>>>>>>>>>>> From: OAuth On Behalf Of Dick = Hardt >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>>>>=20 >>>>>>>>>>>> Hey List=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>>=20 >>>>>>>>>>>> In the security topics doc >>>>>>>>>>>>=20 >>>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>>>=20 >>>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>>=20 >>>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>>=20 >>>>>>>>>>>> /Dick >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> ---- >>>>>>>>>>> Aaron Parecki >>>>>>>>>>> aaronparecki.com >>>>>>>>>>> @aaronpk >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=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 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Fri Feb 21 16:48:32 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BA81200E5 for ; Fri, 21 Feb 2020 16:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 RWKlTlYxaWOM for ; Fri, 21 Feb 2020 16:48:27 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650090.outbound.protection.outlook.com [40.107.65.90]) (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 D92C912006B for ; Fri, 21 Feb 2020 16:48:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b8X3cHYHY8ZaRaMkE9JzQQ7Ew24s2ZRB1xcsYAkkH3WGChmLrmjlVc7SLOMC1TkLfE5p79rSFpE28wZHWa0+N8SE3q0u5bnix64aKbwwqAnHOStSjUhwOPGE9AQhitAiP2zKo84qlwmy4aZfBFcv8G1j1VYDHa9FNwAOnrD8s8ccJhaskFUMRg9lZXK6LiJZVtrftyZt+0RVJIZdajFrdoVd5qBLBaC+l2RBJUjgYcEInusa3rjuP5AaZUEMMWaGkfhdeZTdkteSKmjbIfKyLZOTkk4CBJb6dnvceTcMQwm6Drm6z0A3reNkE4F6fC6fvsuL/y/H8FlLJJz/H6pGCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jrgiLXQBbvGMfR63jBtGeEn9X5pLdiCQqql0ZfL0c18=; b=HjeL4vvlhG42CJnf2d/FgFCpIrsVCuSgZX1h3mgHRa98fK+vFnXfgJyYuMRXA29/Z14ivbEKaw0aVq3k504xBO+aNooQvj1LExOMU4nnkCIfI7dVAYubnMNByhowUJICw6g7FvTzE8UBxZfs4P9xo+p8tz8azFycBCtEmZOaEl9hn+HY83ljFGR9+9KTi7nGN5nQ0CtS/4oIMVkZLPd8cWdge+ptmpP2MgXNnNtjQLAj/SxOxGXIzY0i27S4c4dZxXEf2qMmYKNba/HzSItNPT7tlKkAnhQ+mbQUxSAiPhIfC11GhJySXoV/hyt9Ux4Fki+7cQq4aSNyWSarT3wtfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jrgiLXQBbvGMfR63jBtGeEn9X5pLdiCQqql0ZfL0c18=; b=d2rh+Mi6NtPOfDLP/rgvELhPmIAWJ2hZxUoQB7rhT8WyKXXDO6M6mm+oy3Df8DhOCnvdjaANBZLVaBg82y3yq1s1IOJSh0i35KLrkOBKxbX2wKOTscMQ2eMvUsFi11YK2ecXdlxsVqR7LhMQGgDde8yy4tKSQs9mbzcwcXdTrn4= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0559.namprd00.prod.outlook.com (2603:10b6:208:fd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.0; Sat, 22 Feb 2020 00:48:24 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2522:39b3:eb98:cc8c]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2522:39b3:eb98:cc8c%8]) with mapi id 15.20.2798.000; Sat, 22 Feb 2020 00:48:24 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Review of OAuth 2.0 for Browser-Based Apps Thread-Index: AdXpGM+nGzW/fwd2T9Cfwtta/NQoZg== Date: Sat, 22 Feb 2020 00:48:24 +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_ActionId=88131d1e-6535-418d-a91e-000059587b56; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-22T00:40:39Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:0:b0d0:4afa:31da:9bf7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ce96bddd-3fa7-4204-e354-08d7b730ec0a x-ms-traffictypediagnostic: MN2PR00MB0559: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03218BFD9F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(346002)(376002)(39860400002)(136003)(366004)(189003)(199004)(30864003)(52536014)(5660300002)(186003)(8676002)(33656002)(66946007)(6916009)(6506007)(66446008)(64756008)(66556008)(66476007)(81166006)(76116006)(8936002)(4326008)(81156014)(54906003)(316002)(10290500003)(7696005)(478600001)(9686003)(8990500004)(2906002)(86362001)(71200400001)(66574012)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0559; H:MN2PR00MB0686.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0PiRiz0X2sw5wujEsvq3eV3K7lJ6gDCJFjrkHVdmMgx94RZ1BJnssxlqZ/76MDdq/brsn21WBuO/wRqOuXIejDesYNBIo3Yk5qeCPsG778OZRRSQ+VmFvZVWy9COgbDVf0IovopwoS3Qo/zP7nOdRb53Ms8n389tXn8e826iI865OI9OkARfFCTpfbXVxezRPIlvaSc5zagedK0zES0W8zZlgdivEKX4RQzggPN6VMX5GNyVXSPQuPn86hFehks7ElzJNIOFndW0QSakcHDIboGKomh9PLIwNC/pRex9bVutqYDRf+dOTuRdVBL+cpgb+MdmnpgMzaGeM+djzg2eF4X8Ddd6o8/elLwpOD4U/rRXIPAIEpOoAS3+XmhYbhAfE8fJHgMmngYsoMZ5as9u8Xr6J3TkiBhfFnDQPovXXZlIuU27/1Mo/PKUKxVTXZFKf5hEizxwxy8Zxw9Dj0Ixk0xsQYBVPAm4/r2PqmNmZRZSAB6E39RI4Lptsn8PFAcnp/y7hjtE//ngvljRnWdFUQ== x-ms-exchange-antispam-messagedata: crmOGICAfW+pvxKtO9PIvjPmUdahnozisiA3YWu+Y7zGVMoEJa4IjaKYTijHDl3FPkLgQ8lBkmAkBtHfOr9ekYJgsUrlVu9QrSz1gik6/YWVp1srjue0a2Up7TXTzJeMA3BlMg8rz8ilJKgxq9hrDUzVmgV5MLadnMO791p1ze/0k/wA59AUAhudEaUZdIY1VXTRPwYuj/ijhgTG6CRS4Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0686B2736AFC453F5794F099F5EE0MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce96bddd-3fa7-4204-e354-08d7b730ec0a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2020 00:48:24.1499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dbs9mUGZWaHWZnPrrDVRTOY2HrS5bzne1FEkI38tVs91txxVlLTocmO/opLPgXGvTQgmx94jFi1oGOWF1m1xdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0559 Archived-At: Subject: [OAUTH-WG] Review of OAuth 2.0 for Browser-Based Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 00:48:31 -0000 --_000_MN2PR00MB0686B2736AFC453F5794F099F5EE0MN2PR00MB0686namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did a cover-to-cover read of draft-ietf-oauth-browser-based-apps-04. My review = comments follow in three sections: substantive comments on the text, subst= antive overall issues to consider (provided by Microsoft product engineers)= , and editorial issues. SUBSTANTIVE 1. Introduction - The first sentence says that this spec is about applicati= ons running entirely in a browser. Many browser-based applications also us= e helper services. Please broaden the scope to encompass both patterns. 2. Overview - Change "This was the principal motivation" to "This was one = of the motivations". 3. Terminology - In the "OAuth" definition, also reference RFC 6750. 4. Overview - Change "the current best practice for browser-based applicat= ions is to use OAuth 2.0 authorization code flow with PKCE" to "the current= best practice for browser-based applications is to use either OAuth 2.0 au= thorization code flow with PKCE or OpenID Connect ". This parallels the same recommendation in the forthcoming OAuth Se= curity BCP specification. 4. Overview - Change "Use the OAuth 2.0 authorization code flow with the P= KCE extension" to "Use either the OAuth 2.0 authorization code flow with t= he PKCE extension or OpenID Connect". 4. Overview - Change "Protect themselves against CSRF attacks by using the= OAuth 2.0 state parameter to carry one-time use CSRF tokens, or by ensurin= g the authorization server supports PKCE" to "Protect themselves against CS= RF attacks by using the OAuth 2.0 state parameter or the OpenID Connect non= ce parameter to carry one-time use CSRF tokens or by ensuring the authoriza= tion server supports PKCE". 4. Overview - The intended meaning of this text isn't clear: "Register one= or more redirect URIs, and not vary the redirect URI per authorization req= uest". Do you mean to include a registered redirect_uri value in each auth= orization request? This needs to be clarified. 4. Overview - Change "Support the PKCE extension" to "Support the PKCE ext= ension or OpenID Connect". 5. First-Party Applications - The third paragraph says that "first-party a= pplications using OAuth or OpenID Connect MUST use the authorization code f= low". OpenID Connect can be safely used with other response_type values th= an simply "code". For instance, the "code id_token" value is just as safe.= Please generalize this language when describing the use of OpenID Connect= to recognize that other response_type value may continue to be safely used= . 6.2. JavaScript Applications with a Backend - The sentence "The Applicatio= n Server utilizes own session with the browser to store the access token" r= aises a question with no obvious answer: Where is the specification recomm= ending or suggesting that the access token be stored in this case? Please = clarify. 6.2. JavaScript Applications with a Backend - The last paragraph talks abo= ut exposing the access token to the end user but fails to describe the perc= eived risk or threat. If there are such risks or threats, please be explic= it about what they are and their mitigations. 6.3. JavaScript Applications without a Backend - This sentence tells a fal= se and incomplete story "The application then runs in the browser, and is c= onsidered a public client since it has no ability to be issued a client sec= ret." Public clients can definitely be issued Client ID/Client Secret pair= s using OAuth Dynamic Client Registration [RFC 7591]. Please revise this d= escription accordingly. (Likewise, the following paragraph says that "The = JavaScript app is then responsible for storing the access token securely us= ing appropriate browser APIs. If this is safe, then storing the dynamicall= y issued Client ID/Client Secret pair should be safe to do so in the same m= anner.) 7.1. Initiating the Authorization Request from a Browser-Based Application= - As in other places where the text says that PKCE must be used, please re= vise this instance to say that either PKCE or OpenID Connect must be used -= just as is done in the forthcoming Security BCP. 7.1. Initiating the Authorization Request from a Browser-Based Application= - As in other places where the spec says that the "state" parameter must b= e used, revise this instance to say that either the OAuth "state" parameter= or the OpenID Connect "nonce" parameter must be used to prevent the applic= able attacks. 9.2. Client Authentication - The second paragraph talks about secrets that= are statically included and warns against them, which is good. But please= also add text describing how OAuth Dynamic Client Registration [RFC 7591] = can be used to safely statically create these secrets. 9.3. Client Impersonation - Add text to the first paragraph describing how= the use of the OpenID Connect "id_token_hint" parameter can be used to sat= isfy the requirement that the identity of the client can be assured. 9.3. Client Impersonation - The wording of this phrase is ambiguous: "If = authorization servers restrict redirect URIs to a fixed set of absolute HTT= PS URIs without wildcard domains, paths, or query string components..." It= could be interpreted with the "without" applying to "paths or query string= components", meaning that no path or query string components may be presen= t at all. (I think you meant only that wildcard values not be present, but= that's not the meaning of the phrase, as written.) 9.4. Cross-Site Request Forgery Protections - As in other places where the= spec says that the "state" parameter must be used, revise this instance to= say that either the OAuth "state" parameter or the OpenID Connect "nonce" = parameter must be used to prevent the applicable attacks. 9.8. OAuth Implicit Grant Authorization Flow - The paragraph ends with "no= t all of which have sufficient mitigation strategies". It would be useful = to be more specific here, saying which attacks do not have sufficient mitig= ation strategies. 9.8.5. Countermeasures - The phrase "using the authorization code with PKC= E avoids these attacks" doesn't say what attacks are being referred to. Pl= ease revise so that the attacks in question are unambiguously referenced. Appendix A. Server Support Checklist - In bullet 3, revise to say that eit= her PKCE or OpenID Connect is required, as per other locations in the speci= fication. ADDITIONAL OVERALL ISSUES FROM MICROSOFT ENGINEERS These issues should be considered in the context of this document. For the= se, I'm requesting working group discussions - not specific resolutions at = this time. 1. There seems to be a lot of focus on exact redirect URI validation for= addressing the biggest risk (open redirect), but while certainly absolutel= y critical, it frankly ignores the reality of how apps integrate with autho= rization servers these days a bit. The pattern we are seeing is that a lot = of applications have simply shifted to including their own redirect URIs in= 'state' parameters. Even our own services use this pattern as cookie space= is quite limited. We are seeing a lot of security issues and there are no = real solutions in any of the BCP documents or RFCs. 2. In Section 4, the spec requires exact matching of redirect URIs. The = OAuth Security BCP mentions that there are alternatives to exact redirect U= RI matching "As an alternative to exact redirect URI matching, the AS could= also authenticate clients, e.g., using [I-D.ietf-oauth-jwsreq]." While I d= on't think client authentication is suitable for browser based apps, accept= ing signed requests via OpenID Connect's "request_uri" parameter would be a suitabl= e alternative pattern to exact redirect URI checking. For consistency, I th= ink both docs should have the same recommendation for redirect URI matching= . 3. Considering the above, we probably don't have many more good options = for fragment flows. That's one of the reasons why I still think hybrid patt= erns have a place, but we need mechanisms to protect against code injection= . Unfortunately, the security-topics document dismisses solutions that we c= ould make work (code-bound state, nonce) in favor of solutions that don't h= elp (PKCE). This might be outside of this immediate discussion about the im= plicit flow, but standards need to evolve to better mitigate that risk. 4. The big problem with giving SPAs refresh tokens is that refresh token= s provide offline access - they live on after the user signs out - includin= g when an attacker steals them. For JavaScript SPAs, where XSS is a big con= cern, and where access is only intended to be provided for an online user, = these refresh tokens represent an unnecessary security liability. Disabling= CORS on /token forces an implementation pattern without refresh tokens for= web apps. So today, we have a tradeoff between using the implicit flow and= accepting attacks around browser history and generically injected scripts = with limited impact duration OR using the two legged flow and accept attack= s with specifically injected scripts with unlimited duration, plus a little= perf/cogs hit. EDITORIAL 1. Introduction - Change "native apps as well as browser-based apps" to "n= ative apps and browser-based apps". 4. Overview - Change "OAuth 2.0 RFC 6749" to "OAuth 2.0 ". 4. Overview - Change "the flow assures that" to "the flow ensures that". 5. First-Party Applications - The first sentence of the second paragraph h= as no verb. 5. First-Party Applications - The fifth paragraph starts with "By using th= e Authorization Code flow and redirecting the user to the authorization ser= ver". I believe that this is continuing the message in the (single-sentenc= e) fourth paragraph. The exposition will be less confusing if these paragr= aphs are merged. 6. Application Architecture Patterns - The bulleted list is not in the sam= e order as the corresponding subsections. Please reorder them to make them= parallel. 6.2. JavaScript Applications with a Backend - This section references the = OWASP Foundation as an organization. It would be far more useful to instea= d list the documents containing the specific applicable recommendations. P= lease revise accordingly. 9.5. Authorization Server Mix-Up Mitigation - Please also reference draft-= ietf-oauth-mix-up-mitigation here. 9.8.3. Threat: Manipulation of Scripts - Please change "is far greater" to= "may be amplified" to avoid an overreaching statement. Likewise, delete t= he word "very" later in the paragraph. 9.9. Additional Security Considerations - This section references the OWAS= P Foundation as an organization. It would be far more useful to instead li= st the documents containing the specific applicable recommendations. Pleas= e revise accordingly. 11.1. Normative References - These references are missing URLs: CSP2, Fet= ch, oauth-security-topics. 11.1. Informative References - This reference is missing a URL: HTML. -- Mike --_000_MN2PR00MB0686B2736AFC453F5794F099F5EE0MN2PR00MB0686namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did a cover-to-cover read of draft-ietf-oauth-browser-based-apps-04.  My review comments follow= in three sections:  substantive comments on the text, substantive ove= rall issues to consider (provided by Microsoft product engineers), and edit= orial issues.

 

SUBSTANTIVE

 

1. Introduction – The first sentence says that= this spec is about applications running entirely in a browser.  Many = browser-based applications also use helper services.  Please broaden t= he scope to encompass both patterns.

 

2.  Overview – Change “This was the= principal motivation” to “This was one of the motivations̶= 1;.

 

3.  Terminology – In the “OAuthR= 21; definition, also reference RFC 6750.

 

4.  Overview – Change “the current = best practice for browser-based applications is to use OAuth 2.0 authorizat= ion code flow with PKCE” to “the current best practice for brow= ser-based applications is to use either OAuth 2.0 authorization code flow with PKCE or OpenID Connect <xref target=3D"OpenID.Core&= quot;/>”.  This parallels the same recommendation in the fort= hcoming OAuth Security BCP specification.

 

4.  Overview – Change “Use the OAut= h 2.0 authorization code flow with the PKCE extension” to  ̶= 0;Use either the OAuth 2.0 authorization code flow with the PKCE extension = or OpenID Connect”.

 

4.  Overview – Change “Protect them= selves against CSRF attacks by using the OAuth 2.0 state parameter to carry= one-time use CSRF tokens, or by ensuring the authorization server supports= PKCE” to “Protect themselves against CSRF attacks by using the OAuth 2.0 state parameter or the OpenID Connect nonce paramet= er to carry one-time use CSRF tokens or by ensuring the authorization serve= r supports PKCE”.

 

4.  Overview – The intended meaning of th= is text isn’t clear: “Register one or more redirect URIs, and n= ot vary the redirect URI per authorization request”.  Do you mea= n to include a registered redirect_uri value in each authorization request?=   This needs to be clarified.

 

4.  Overview – Change “Support the = PKCE extension” to “Support the PKCE extension or OpenID Connec= t”.

 

5.  First-Party Applications – The third = paragraph says that “first-party applications using OAuth or OpenID C= onnect MUST use the authorization code flow”.  OpenID Connect ca= n be safely used with other response_type values than simply “code= 221;.  For instance, the “code id_token” value is just as safe. = Please generalize this language when describing the use of OpenID Connect = to recognize that other response_type value may continue to be safely used.=

 

6.2.  JavaScript Applications with a Backend &#= 8211; The sentence “The Application Server utilizes own session with = the browser to store the access token” raises a question with no obvi= ous answer:  Where is the specification recommending or suggesting that the access token be stored in this case?  Please clarify.

 

6.2.  JavaScript Applications with a Backend &#= 8211; The last paragraph talks about exposing the access token to the end u= ser but fails to describe the perceived risk or threat.  If there are = such risks or threats, please be explicit about what they are and their mitigations.

 

6.3.  JavaScript Applications without a Backend= – This sentence tells a false and incomplete story “The applic= ation then runs in the browser, and is considered a public client since it = has no ability to be issued a client secret.”  Public clients can definitely be issued Client ID/Client Secret pairs using OAuth= Dynamic Client Registration [RFC 7591].  Please revise this descripti= on accordingly.  (Likewise, the following paragraph says that “T= he JavaScript app is then responsible for storing the access token securely using appropriate browser APIs.  If this is= safe, then storing the dynamically issued Client ID/Client Secret pair sho= uld be safe to do so in the same manner.)

 

7.1.  Initiating the Authorization Request from= a Browser-Based Application – As in other places where the text says= that PKCE must be used, please revise this instance to say that either PKC= E or OpenID Connect must be used – just as is done in the forthcoming Security BCP.

 

7.1.  Initiating the Authorization Request from= a Browser-Based Application – As in other places where the spec says= that the “state” parameter must be used, revise this instance = to say that either the OAuth “state” parameter or the OpenID Connect “nonce” parameter must be used to prevent the applicab= le attacks.

 

9.2.  Client Authentication – The second = paragraph talks about secrets that are statically included and warns agains= t them, which is good.  But please also add text describing how OAuth = Dynamic Client Registration [RFC 7591] can be used to safely statically create these secrets.

 

9.3.  Client Impersonation – Add text to = the first paragraph describing how the use of the OpenID Connect “id_= token_hint” parameter can be used to satisfy the requirement that the= identity of the client can be assured.

 

9.3.  Client Impersonation – The wording = of this phrase is ambiguous:  “If authorization servers restrict= redirect URIs to a fixed set of absolute HTTPS URIs without wildcard domai= ns, paths, or query string components…”  It could be inter= preted with the “without” applying to “paths or query string co= mponents”, meaning that no path or query string components may be pre= sent at all.  (I think you meant only that wildcard values not be pres= ent, but that’s not the meaning of the phrase, as written.)

 

9.4.  Cross-Site Request Forgery Protections &#= 8211; As in other places where the spec says that the “state” p= arameter must be used, revise this instance to say that either the OAuth &#= 8220;state” parameter or the OpenID Connect “nonce” param= eter must be used to prevent the applicable attacks.

 

9.8.  OAuth Implicit Grant Authorization Flow &= #8211; The paragraph ends with “not all of which have sufficient miti= gation strategies”.  It would be useful to be more specific here= , saying which attacks do not have sufficient mitigation strategies.

 

9.8.5.  Countermeasures – The phrase R= 20;using the authorization code with PKCE avoids these attacks” doesn= ’t say what attacks are being referred to.  Please revise so tha= t the attacks in question are unambiguously referenced.

 

Appendix A.  Server Support Checklist – I= n bullet 3, revise to say that either PKCE or OpenID Connect is required, a= s per other locations in the specification.

 

ADDITIONAL OVERALL ISSUES FROM MICROSOFT ENGINEERS

 

These issues should be considered in the context of = this document.  For these, I’m requesting working group discussi= ons – not specific resolutions at this time.

  1. There seems to be a lot of focus on exact = redirect URI validation for addressing the biggest risk (open redirect), bu= t while certainly absolutely critical, it frankly ignores the reality of ho= w apps integrate with authorization servers these days a bit. The pattern we are seeing is that a lot of appli= cations have simply shifted to including their own redirect URIs in 'state'= parameters. Even our own services use this pattern as cookie space is quit= e limited. We are seeing a lot of security issues and there are no real solutions in any of the BCP document= s or RFCs.
  2. In Section 4, the spec requires exact matc= hing of redirect URIs. The OAuth Security BCP mentions that there are alter= natives to exact redirect URI matching “As an alternative to exact re= direct URI matching, the AS could also authenticate clients, e.g., using [I-D.ietf-oauth-jwsreq].” While I don’t t= hink client authentication is suitable for browser based apps, accepting si= gned requests via OpenID Connect’s “request_uri” parameter would be = a suitable alternative pattern to exact redirect URI checking. For consiste= ncy, I think both docs should have the same recommendation for redirect URI matching.
  3. Considering the above, we probably don't h= ave many more good options for fragment flows. That's one of the reasons wh= y I still think hybrid patterns have a place, but we need mechanisms to pro= tect against code injection. Unfortunately, the security-topics document dismisses solutions that we could make work (= code-bound state, nonce) in favor of solutions that don't help (PKCE). This= might be outside of this immediate discussion about the implicit flow, but= standards need to evolve to better mitigate that risk.
  4. The big problem with givin= g SPAs refresh tokens is that refresh tokens provide offline access –= they live on after the user signs out – including when an attacker s= teals them. For JavaScript SPAs, where XSS is a big concern, and where access is only inte= nded to be provided for an online user, these refresh tokens represent an u= nnecessary security liability. Disabling CORS on /token forces an implement= ation pattern without refresh tokens for web apps. So today, we have a tradeoff between using the implicit flow= and accepting attacks around browser history and generically injected scri= pts with limited impact duration OR using the two legged flow and accept at= tacks with specifically injected scripts with unlimited duration, plus a little perf/cogs hit. <= /li>

 

EDITORIAL

 

1.  Introduction – Change “native a= pps as well as browser-based apps” to “native apps and browser-= based apps”.

 

4.  Overview – Change “OAuth 2.0 RF= C 6749” to “OAuth 2.0 <xref target=3D"RFC6749"/>= ; <xref target=3D"RFC6750"/>”.

 

4.  Overview – Change “the flow ass= ures that” to “the flow ensures that”.

 

5.  First-Party Applications – The first = sentence of the second paragraph has no verb.

 

5.  First-Party Applications – The fifth = paragraph starts with “By using the Authorization Code flow and redir= ecting the user to the authorization server”.  I believe that th= is is continuing the message in the (single-sentence) fourth paragraph.&nbs= p; The exposition will be less confusing if these paragraphs are merged.=

 

6.  Application Architecture Patterns – T= he bulleted list is not in the same order as the corresponding subsections.=   Please reorder them to make them parallel.

 

6.2.  JavaScript Applications with a Backend &#= 8211; This section references the OWASP Foundation as an organization. = ; It would be far more useful to instead list the documents containing the = specific applicable recommendations.  Please revise accordingly.

 

9.5.  Authorization Server Mix-Up Mitigation &#= 8211; Please also reference draft-ietf-oauth-mix-up-mitigation here.

 

9.8.3.  Threat: Manipulation of Scripts –= Please change “is far greater” to “may be amplified̶= 1; to avoid an overreaching statement.  Likewise, delete the word R= 20;very” later in the paragraph.

 

9.9.  Additional Security Considerations –= ; This section references the OWASP Foundation as an organization.  It= would be far more useful to instead list the documents containing the spec= ific applicable recommendations.  Please revise accordingly.

 

11.1.  Normative References – These refer= ences are missing URLs:  CSP2, Fetch, oauth-security-topics.

 

11.1.  Informative References – This refe= rence is missing a URL:  HTML.

 

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

 

--_000_MN2PR00MB0686B2736AFC453F5794F099F5EE0MN2PR00MB0686namp_-- From nobody Fri Feb 21 17:02:28 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A39A1200F4 for ; Fri, 21 Feb 2020 17:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 CrFbTDw8Fa-n for ; Fri, 21 Feb 2020 17:02:24 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640135.outbound.protection.outlook.com [40.107.64.135]) (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 1FCCB1200F3 for ; Fri, 21 Feb 2020 17:02:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BabeXAmZucufBrLziGBpSNR9Ct/8qI7mTV4qgX479KO2t1yXAAwvRTkVCav8XIZiUVO1Qd06+ZUudf4jVQPWqvfwGOAK/67dGp32+W1Z08iFVN+b2LFVeDD9w5b70azjVCtF7NAWJTM07v+cEKy3jUCw48z7q1jjxKhuZX5ENIl05mB6imR04aLtwuVkRsBhdGmhjUIdgCpJzUcvsgTP21QVsRuvFbQUJ1qE1EPVb+VvIPb8GYqB411QHz7fVOEE2qMst2b+fZRqQELTjRfDaMn6VKzap2fql8n7omHPQZ6B3+Q2rXkKF71Xon+wc6UHb4+Lg2wu50eP7UcS4eaaIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kZVZv3G6lMxzY8tGYrMSqpAltrdBvAeHrCkL0y2b5Ko=; b=VmiNMSgzvpgn88vfrc7StaKyyGq46DWMhGfyjyneQ7w3zQHOQker7XF1rpgMgb2N8nb0kbu8YJXUWlB2UQoU9AGuTH06Yj1JfB1SYjo+YH7vZJBmH3CKCkGD0cB9DZrjaF5ecPyRNn9a7ajO7Vh8skGklLBhbgYhbluEb9OildV8ERB4t0RDMzFmGPwDG28Wvwg2u+keSHxr7YFzq0VdhVXgbSD59JeC146Ae8YlDtH4B5rWlalneMewohPWcW4VHVBxbvH80hkxCNspaEDMZl8TUfuO46eJ1Webk5AMUCR9g2AvU947dqlvyxVRteCc+HAIoih232Sk1W92XIJgLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kZVZv3G6lMxzY8tGYrMSqpAltrdBvAeHrCkL0y2b5Ko=; b=Et3mfIjf13TVeVhavpwcJ60wb9Xwfdz+V19g7I9u6kzlUNx5xVWUcH10xlmIF4U0+jENKK7yv4rC371HP7mIYJ7kbrGU12kujwd5HC8CBn3nMmdtcoE6iADiDe8D3PDaf3mgy61IzUrJTpzNBKkVODl9Jpbqd79e9tWEUAZVyiU= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by BL0PR00MB0770.namprd00.prod.outlook.com (2603:10b6:208:1c1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2798.0; Sat, 22 Feb 2020 01:02:01 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2522:39b3:eb98:cc8c]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2522:39b3:eb98:cc8c%8]) with mapi id 15.20.2798.000; Sat, 22 Feb 2020 01:02:01 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: More product group review comments on the OAuth 2.0 for Browser-Based Apps spec Thread-Index: AdXpG3f2cDgEaH8QQ167PwNe4TzB+g== Date: Sat, 22 Feb 2020 01:02:01 +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_ActionId=422a613d-a42d-4319-ae51-0000e3ce3c95; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-22T00:59:36Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:0:b0d0:4afa:31da:9bf7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 35a205cf-2481-46ae-558d-08d7b732d35b x-ms-traffictypediagnostic: BL0PR00MB0770: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03218BFD9F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(396003)(39860400002)(366004)(376002)(189003)(199004)(55016002)(6916009)(5660300002)(81156014)(478600001)(66946007)(966005)(8936002)(81166006)(4326008)(8676002)(33656002)(76116006)(8990500004)(10290500003)(66574012)(54906003)(7696005)(6506007)(71200400001)(2906002)(86362001)(66446008)(186003)(52536014)(64756008)(66556008)(66476007)(9686003)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0770; H:MN2PR00MB0686.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hp9YxzQpBexanrGyJobpoFdHR1IaUgpH3p0WqBKhUUaYW3O+KiN2dmYihGrpQNuwqPxU/+bHzSl7Qx5l/xjGpY24NQyC6/25UWLMMINlKlkWhrI+v81enDi3Uo6YxIN8VTFKcEmDzRIvJrmgy/qeo+26/IRfENMbf2g8Cx7z042Yeb0GcMV5TFA+8UYcKgiUKQdjCCNkKmKrq/ypAkHQXUvArXllq4cC0LYR6XfQZykbxrJsIbDOmAN01Y8bTICj7lyXotKWn0IrxktFZcfoFe2J2mO3Yf6yLq0B/8Xow4WktYM2lHaBPySs0gRS5RnaWC6jzCUus/mlsHyc78WiOGlHU9QHYOV+dqWunDDj1Z3NpnlOrkCGYRKjRzz4mvi/ZrsYXHvnXhyIRD+BwTh7UApjLfafmfJcMJZgrWAdhbmJSpCVK5JSGH/OX8P8fetMCNoosIgX2oPYciXCzylsbLLPdiBF5kYo/5096vp8r2Jt/GEuTNxnKYeHxcIZ3lhZIJibPX8Ov1FIuai2t8JkUw== x-ms-exchange-antispam-messagedata: U8Tln1l2UAerdYAS+W6Th6JRnd6UalE3n+q8JP7MJAlvk9zd/CHm7544rbU4SsLYyWZsnwTz/hIyAwJTvprpYfug9kpcL/PJLfGLHGksRnxjqr6GmD7Ak08FYqabnTiHQJ8UW/V5iqC9vydM5hUL95EquHogl65MsQmO/9ZVfqmV34BKj4qCNutXuRfXFAChhU/a8cXZC+TtSTgNbQMHjw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06861DECA92E8CDA95610699F5EE0MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35a205cf-2481-46ae-558d-08d7b732d35b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2020 01:02:01.7514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0uR7Uk2+EZJSIn4I6tR9LmuSWUwUrsbobIpiItDeGc1IWY5Y0cuxk7/IHpFUrMp6UtBGSNS0ITNora5PxrouYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0770 Archived-At: Subject: [OAUTH-WG] More product group review comments on the OAuth 2.0 for Browser-Based Apps spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 01:02:27 -0000 --_000_MN2PR00MB06861DECA92E8CDA95610699F5EE0MN2PR00MB0686namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable More comments hot off the presses from a Microsoft product architect... https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-= 6.2 Applications with BE If I read this correctly, the prescribed pattern is to have browser JS call= into its own BE only and have the BE call into 3P WebAPIs: When the JavaScript application in the browser wants to make a request to the Resource Server, it MUST instead make the request to the Application Server, and the Application Server will make the request with the access token to the Resource Server (C), and forward the response (D) back to the browser. Many of our application services give the access tokens to browser instead = and have JS call the resource server directly. If we enforce the prescribed pattern, then app server becomes proxy to all = resource servers. This may not scale of our services SPO, for example, has a pattern that is a mix b/n application with and with= out BE. It can behave as public or conf client depending on the redirect UR= I as we allow URI to be marked as 'SPA'. https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-= 9.3 9.3. Client Impersonation It is implied that consent granted to public client should not be recorded: Even when the user has previously approved an authorization request for a given client_id, the request SHOULD be processed as if no previous request had been approved, unless the identity of the client can be proven. Do we agree with this? If implemented, it will add significant number of co= nsent prompts. tx --_000_MN2PR00MB06861DECA92E8CDA95610699F5EE0MN2PR00MB0686namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

More comments hot off the presses from a Microsoft p= roduct architect…

 

https://tools.ietf.or= g/html/draft-ietf-oauth-browser-based-apps-04#section-6.2

Applications with BE

 

If I read this correctly, the prescribed pattern is = to have browser JS call into its own BE only and have the BE call into 3P W= ebAPIs:

When the JavaScript application in the bro=
wser wants to make a

   request to the Resource Server, i= t MUST instead make the request to

   the Application Server, and the A= pplication Server will make the

   request with the access token to = the Resource Server (C), and forward

   the response (D) back to the brow= ser.

 

Many of our application services give the access tok= ens to browser instead and have JS call the resource server directly.<= /o:p>

If we enforce the prescribed pattern, then app serve= r becomes proxy to all resource servers. This may not scale of our services=

 

SPO, for example, has a pattern that is a mix b/n ap= plication with and without BE. It can behave as public or conf client depen= ding on the redirect URI as we allow URI to be marked as ‘SPA’.=

 

https://tools.ietf.org/= html/draft-ietf-oauth-browser-based-apps-04#section-9.3

9.3.  Client Impersonation

It is implied that consent granted to public client = should not be recorded:

Even when the user has previously approved=
 an
   authorization request for a g=
iven client_id, the request SHOULD be
   processed as if no previous r=
equest had been approved, unless the
   identity of the client can be=
 proven.

 

Do we agree with this? If implemented, it will add s= ignificant number of consent prompts.

 

tx

 

--_000_MN2PR00MB06861DECA92E8CDA95610699F5EE0MN2PR00MB0686namp_-- From nobody Fri Feb 21 17:05:30 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920C712006B for ; Fri, 21 Feb 2020 17:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QshKAdEN-d-3 for ; Fri, 21 Feb 2020 17:05:23 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0FD1200F3 for ; Fri, 21 Feb 2020 17:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1582333523; x=1613869523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=f/4T7KWhEiilCEuK9VEBrkV0qD01qvkirTCb8vQ8XUc=; b=XvqSe3152zlOgMoF6QEDkhKfRbUpMoBbJYCFJ9y4Pa8bMsqzaJXHtXcS hFm1mzoMKKQfJCBf8cuyKUgFc/8jRRiCKF5sVkZRFGd9JPJJxhzWYKv+V QT+/O8dQTnjdksF/oP4DbBKYNShHDz0NOSLucgocdZAXSbU05gLhEeHcY 8=; IronPort-SDR: 7DR801TD99azlBzIoRtD+EXkd++2GWSchi+JtWSxBbd/imvrDzF26vemgJBeygRsQ2pJCtrePw DAjR627JoCAg== X-IronPort-AV: E=Sophos;i="5.70,470,1574121600"; d="scan'208";a="26813424" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-397e131e.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 22 Feb 2020 01:05:21 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-397e131e.us-west-2.amazon.com (Postfix) with ESMTPS id 1193DA415C; Sat, 22 Feb 2020 01:05:21 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 22 Feb 2020 01:05:20 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 22 Feb 2020 01:05:20 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.000; Sat, 22 Feb 2020 01:05:20 +0000 From: "Richard Backman, Annabelle" To: Neil Madden CC: Torsten Lodderstedt , Matthew De Haast , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.1: dropping password grant Thread-Index: AQHV5qSUgKi8Wj4ZTk68d/Qg5rtTLaghf4+AgAGDGoCAAAkCgIAABOGAgAACjYCAAAssAIACjbcAgAAIhQCAAAJoAIAAAwkAgAAA2QCAAAORAP//2UYAgACdoQD//6+lAA== Date: Sat, 22 Feb 2020 01:05:20 +0000 Message-ID: <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> In-Reply-To: <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.50] Content-Type: text/plain; charset="utf-8" Content-ID: <6F6E15F3D132394593BE5A2D2AA5D5DD@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 01:05:30 -0000 Uk9QQyB3aXRob3V0IGEgY2xpZW50IElEIG9yIGF1dGhlbnRpY2F0aW9uIGlzIGZ1bmN0aW9uYWxs eSBlcXVpdmFsZW50IHRvIENsaWVudCBDcmVkZW50aWFscyBncmFudCB3aXRoIGNsaWVudCBzZWNy ZXQgYXV0aGVudGljYXRpb24gaW4gdGhlIHJlcXVlc3QgYm9keS4gWW91J3ZlIGp1c3QgcmVuYW1l ZCAiY2xpZW50X2lkIiB0byAidXNlcm5hbWUiIGFuZCAiY2xpZW50X3NlY3JldCIgdG8gInBhc3N3 b3JkIi4NCg0KVGhlIEFTIHNpbXBseSBuZWVkcyB0byBiZSBhYmxlIHRvIHJlc29sdmUgdGhlIGNs aWVudCBJRCB0byB0aGUgc2VydmljZSBhY2NvdW50LiBZb3UgY291bGQgdXNlIGFueSBvZiB0aGUg Zm9sbG93aW5nIHN0cmF0ZWdpZXMsIGRlcGVuZGluZyBvbiB0aGUgZW52aXJvbm1lbnQ6DQoqIFVz ZSBzZXJ2aWNlIGFjY291bnQgaWRlbnRpZmllcnMgYXMgY2xpZW50IElEcw0KKiBVc2UgZW5jcnlw dGVkIGJsb2JzIGNvbnRhaW5pbmcgc2VydmljZSBhY2NvdW50IGlkZW50aWZpZXJzIGFzIGNsaWVu dCBJRHMsIHNvIHNvbWVvbmUgY2FuJ3QgY2hvb3NlIGEgY2xpZW50IElEIGJ5IGNyZWF0aW5nIGEg c2VydmljZSBhY2NvdW50IHdpdGggYSBzcGVjaWZpYyBpZGVudGlmaWVyDQoqIFVzZSBvcGFxdWUg dmFsdWVzIHRoYXQgdGhlIEFTIGNhbiByZXNvbHZlIHRvIHNlcnZpY2UgYWNjb3VudCBpZGVudGlm aWVycywgZS5nLiwgdmlhIGEgZGF0YWJhc2UgbG9va3VwDQoNCklmIHRoZSBBUyBuZWVkcyB0aGUg c2VydmljZSBhY2NvdW50J3MgcGFzc3dvcmQgYmVjYXVzZSBpdCdzIGF1dGhlbnRpY2F0aW5nIGFn YWluc3QgYSBsZWdhY3kgc3lzdGVtLCB0aGVuIHVzZSB0aGUgc2VydmljZSBhY2NvdW50IHBhc3N3 b3JkIGFzIHRoZSBjbGllbnQgc2VjcmV0LiBTdGFjayBtVExTIG9uIHRvcCwgaWYgeW91IHdhbnQu IElmIHRoZSBBUyBqdXN0IG5lZWRzIHRvIHJlc29sdmUgdGhlIGFjY291bnQgc28gaXQgY2FuIHB1 dCBpdCBpbiB0b2tlbnMgdGhhdCBSU2VzIHdpbGwgbG9vayBhdCwgdGhlbiB5b3UgY2FuIHVzZSB3 aGF0ZXZlciBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIHlvdSB3YW50Lg0KDQpJcyB0 aGVyZSBhIHNjZW5hcmlvIEknbSBtaXNzaW5nIGhlcmU/DQoNCuKAkw0KQW5uYWJlbGxlIEJhY2tt YW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRp dHkvDQogDQoNCu+7v09uIDIvMjEvMjAsIDE6NTMgUE0sICJOZWlsIE1hZGRlbiIgPG5laWwubWFk ZGVuQGZvcmdlcm9jay5jb20+IHdyb3RlOg0KDQogICAgVGhlIEFTIGRvZXNu4oCZdCBpc3N1ZSB0 aGUgc2VydmljZSBhY2NvdW50IElEcywgdGhhdOKAmXMgdGhlIHdob2xlIHBvaW50IC0gaW50ZWdy YXRpb24gd2l0aCBleGlzdGluZyBzeXN0ZW1zLiBMb3TigJlzIG9mIHBlb3BsZSBkb27igJl0IGhh dmUgdGhlIGx1eHVyeSBvZiByZWJ1aWxkaW5nIHN5c3RlbXMgZnJvbSBzY3JhdGNoIHRvIGZpdCBp biB3aXRoIHRoZSBwcmVmZXJlbmNlcyBvZiB0aGUgT0F1dGggV0cuDQogICAgDQogICAgUk9QQyBk b2VzbuKAmXQgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24sIG9yIGV2ZW4gYSBjbGllbnQg aWRlbnRpZmllci4gSWYgeW914oCZcmUgdXNpbmcgYSBzZXJ2aWNlIGFjY291bnQgeW91IGluZGVl ZCBkb27igJl0IG5lZWQgdG8gYm90aGVyIGlzc3VpbmcgY2xpZW50IGNyZWRlbnRpYWxzLiBUaGUg c2FtZSBpcyB0cnVlIHdoZW4gdXNpbmcgdGhlIEpXVCBiZWFyZXIgZ3JhbnQuIElmIHlvdSB3YW50 IHRvIGluY3JlYXNlIHNlY3VyaXR5IHlvdSBjYW4gdXNlIGNlcnQtYm91bmQgYWNjZXNzIHRva2Vu cy4NCiAgICANCiAgICA+IE9uIDIxIEZlYiAyMDIwLCBhdCAyMDoyOCwgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiBU aGUgY2xpZW50IElEcyBjYW4gc3RpbGwgYmUgb3BhcXVlIGlkZW50aWZpZXJzIHByb3ZpZGVkIGJ5 IHRoZSBBUywgdGhleSBqdXN0IGhhcHBlbiB0byBiZSBhc3NvY2lhdGVkIHdpdGggc3BlY2lmaWMg c2VydmljZSBhY2NvdW50cy4gT3IgdGhleSBjb3VsZCBiZSB0aGUgb3BhcXVlIElEcyB0aGF0IHRo ZSBBUyBhbHJlYWR5IGlzc3VlZCBmb3IgdGhlIHNlcnZpY2UgYWNjb3VudC4gRWl0aGVyIHdheSwg dGhlIEFTIGNvdWxkIGlzc3VlIGEgdG9rZW4gd2l0aCB0aGUgYXBwcm9wcmlhdGUgc3ViamVjdCBh bmQgb3RoZXIgY2xhaW1zIGZvciB0aGUgc2VydmljZSBhY2NvdW50Lg0KICAgID4gDQogICAgPiBJ ZiB5b3VyIGNsaWVudCBpZGVudGl0eSBpcyBib3VuZCB0byBhIHNwZWNpZmljIHNlcnZpY2UgYWNj b3VudCBpZGVudGl0eSAoaS5lLiwgdGhlIHJlc291cmNlIG93bmVyKSwgdGhlbiBST1BDIHJlZHVj ZXMgZG93biB0byBDbGllbnQgQ3JlZGVudGlhbHMuIFdoYXQncyB0aGUgcG9pbnQgaW4gcGFzc2lu ZyB0d28gaWRlbnRpZmllcnMgYW5kIHR3byBjcmVkZW50aWFscyBmb3IgdGhlIHNhbWUgaWRlbnRp dHk/DQogICAgPiANCiAgICA+IOKAkw0KICAgID4gQW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIp DQogICAgPiBBV1MgSWRlbnRpdHkNCiAgICA+IGh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRp dHkvDQogICAgPiANCiAgICA+IA0KICAgID4gT24gMi8yMS8yMCwgNjo0OCBBTSwgIk9BdXRoIG9u IGJlaGFsZiBvZiBOZWlsIE1hZGRlbiIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIG5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICBT b3JyeSwgSSBtaXNzZWQgdGhhdCBtZXNzYWdlLiANCiAgICA+IA0KICAgID4gICAgV2hpbGUgdGhp cyBtYXkgYmUgYSBzb2x1dGlvbiBpbiBzcGVjaWZpYyBjaXJjdW1zdGFuY2VzLCBJIGRvbuKAmXQg dGhpbmsgaXTigJlzIGEgZ2VuZXJhbCBzb2x1dGlvbi4gZS5nLiBhbiBBUyBtYXkgbm90IGFsbG93 IG1hbnVhbGx5IGNob29zaW5nIHRoZSBjbGllbnRfaWQgdG8gYXZvaWQgdGhpbmdzIGxpa2UgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNz LTE0I3NlY3Rpb24tNC4xMyBvciBtYXkgcmV0dXJuIGRpZmZlcmVudCBpbnRyb3NwZWN0aW9uIHJl c3VsdHMgZm9yIGNsaWVudCBjcmVkZW50aWFscyB0b2tlbnMgKGUuZy4gd2l0aCBubyDigJxzdWLi gJ0pIGFuZCBzbyBvbi4gSW4gcHJhY3RpY2UsIHRoaXMgYWRkcyBldmVuIG1vcmUgc3RlcHMgZm9y IHNvbWVib2R5IHRvIG1pZ3JhdGUgZnJvbSBleGlzdGluZyBST1BDIHVzYWdlLg0KICAgID4gDQog ICAgPiAgICBUaGlzIGlzIGFza2luZyBwZW9wbGUgdG8gbWFrZSBmdW5kYW1lbnRhbCBjaGFuZ2Vz IHRvIHRoZWlyIGlkZW50aXR5IGFyY2hpdGVjdHVyZSByYXRoZXIgdGhhbiBzaW1wbHkgc3dpdGNo aW5nIHRvIGEgbmV3IGdyYW50IHR5cGUuDQogICAgPiANCiAgICA+ICAgIOKAlCBOZWlsDQogICAg PiANCiAgICA+PiBPbiAyMSBGZWIgMjAyMCwgYXQgMTQ6MzQsIFRvcnN0ZW4gTG9kZGVyc3RlZHQg PHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToNCiAgICA+PiANCiAgICA+PiBJIHNlZSAt IHdlIGhhdmUgZ29uZSBmdWxsIGN5Y2xlIDotKSANCiAgICA+PiANCiAgICA+PiBBbm5hYmVsbGXi gJlzIHByb3Bvc2FsIHdvdWxkIHNvbHZlIHRoYXQuIFJlbGF0ZSBhIGNsaWVudCBpZCB0byBhIHNl cnZpY2UgYWNjb3VudCBhbmQgb2J0YWluIHRoZSB0b2tlbiBkYXRhIGZyb20gdGhlcmUuIA0KICAg ID4+IA0KICAgID4+PiBPbiAyMS4gRmViIDIwMjAsIGF0IDE1OjMxLCBOZWlsIE1hZGRlbiA8bmVp bC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQogICAgPj4+IA0KICAgID4+PiBZZXMsIHRo YXQgaXMgZ3JlYXQuIEJ1dCBtVExTIGRvZXNu4oCZdCBzdXBwb3J0IHNlcnZpY2UgYWNjb3VudHMg KCE9IGNsaWVudHMpLiBNYXliZSBpdCBzaG91bGQ/IFNob3VsZCB0aGVyZSBiZSBhIG1UTFMgKmdy YW50IHR5cGUqPw0KICAgID4+PiANCiAgICA+Pj4g4oCUIE5laWwNCiAgICA+Pj4gDQogICAgPj4+ PiBPbiAyMSBGZWIgMjAyMCwgYXQgMTQ6MjAsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0PiB3cm90ZToNCiAgICA+Pj4+IA0KICAgID4+Pj4gSGF2ZSB5b3UgZXZl ciB0cmllZCB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IHdpdGggbVRMUz8gQWZ0ZXIgcmVh ZGluZyB5b3VyIGRlc2NyaXB0aW9uIGl0IHNlZW1zIHRvIGJlIHNpbXBsZXIgdGhhbiBKV1QgQmVh cmVyLg0KICAgID4+Pj4gDQogICAgPj4+PiAqIHdvcmsgb3V0IGlmIHRoZSBBUyBldmVuIHN1cHBv cnRzIG1UTFMNCiAgICA+Pj4+ICogd29yayBvdXQgaG93IHRvIGNvbmZpZ3VyZSB0aGUgQVMgdG8g dHJ1c3QgbXkgY2VydChzKQ0KICAgID4+Pj4gKiBDcmVhdGUga2V5IHBhaXIgYW5kIGNlcnQgdXNp bmcgb3BlbnNzbA0KICAgID4+Pj4gKiBSZWdpc3RlciB5b3VyIChzZWxmLXNpZ25lZCkgY2VydCBh bG9uZyB3aXRoIHlvdXIgY2xpZW50X2lkDQogICAgPj4+PiAqIENvbmZpZ3VyZSB0aGUgSFRUUCBj bGllbnQgdG8gdXNlIHlvdXIga2V5IHBhaXIgZm9yIFRMUyBDbGllbnQgQXV0aGVudGljYXRpb24N CiAgICA+Pj4+IA0KICAgID4+Pj4gV29ya3MgdmVyeSB3ZWxsIGZvciB1cy4gDQogICAgPj4+PiAN CiAgICA+Pj4+PiBPbiAyMS4gRmViIDIwMjAsIGF0IDE1OjEyLCBOZWlsIE1hZGRlbiA8bmVpbC5t YWRkZW5AZm9yZ2Vyb2NrLmNvbT4gd3JvdGU6DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gTm8gZmFp bHVyZXMsIGJ1dCBpdCBpcyBhIG11Y2ggbW9yZSBjb21wbGV4IGdyYW50IHR5cGUgdG8gc2V0IHVw LCB3aGVuIHlvdSBjb25zaWRlciBldmVyeXRoaW5nIHlvdSBoYXZlIHRvIGRvOg0KICAgID4+Pj4+ IA0KICAgID4+Pj4+ICogd29yayBvdXQgaWYgdGhlIEFTIGV2ZW4gc3VwcG9ydHMgSldUIGJlYXJl ciBhbmQgaG93IHRvIHR1cm4gaXQgb24NCiAgICA+Pj4+PiAqIHdvcmsgb3V0IGhvdyB0byBjb25m aWd1cmUgdGhlIEFTIHRvIHRydXN0IG15IHB1YmxpYyBrZXkocykNCiAgICA+Pj4+PiAtIGRvIEkg aGF2ZSB0byBjcmVhdGUgYSBuZXcgSFRUUFMgZW5kcG9pbnQgdG8gcHVibGlzaCBhIEpXSyBTZXQ/ DQogICAgPj4+Pj4gKiBkZXRlcm1pbmUgdGhlIGNvcnJlY3Qgc2V0dGluZ3MgZm9yIGlzc3Vlciwg YXVkaWVuY2UsIHN1YmplY3QsIGV0Yy4gRG9lcyB0aGUgQVMgaW1wb3NlIG5vbi1zdGFuZGFyZCBy ZXF1aXJlbWVudHM/IGUuZy4gUkZDIDc1MjMgc2F5cyB0aGF0IHRoZSBKV1QgTVVTVCBjb250YWlu IGEg4oCcc3Vi4oCdIGNsYWltLCBidXQgR29vZ2xlIG9ubHkgYWxsb3dzIHRoaXMgdG8gYmUgcHJl c2VudCBpZiB5b3VyIGNsaWVudCBpcyBkb2luZyBpbXBlcnNvbmF0aW9uIG9mIGFuIGVuZC11c2Vy ICh3aGljaCByZXF1aXJlcyBhZGRpdGlvbmFsIHBlcm1pc3Npb25zKS4NCiAgICA+Pj4+PiAqIGRv IEkgbmVlZCBhIHVuaXF1ZSDigJxqdGnigJ0gY2xhaW0/IChPSURDIHNlcnZlcnMgZG8sIHBsYWlu IE9BdXRoIG9uZXMgbWlnaHQgbm90KSBJZiBJIGRvLCBjYW4gSSByZXVzZSB0aGUgSldUIG9yIG11 c3QgaXQgYmUgZnJlc2hseSBzaWduZWQgZm9yIGV2ZXJ5IGNhbGw/DQogICAgPj4+Pj4gKiBsb2Nh dGUgYW5kIGV2YWx1YXRlIGEgSldUIGxpYnJhcnkgZm9yIG15IGxhbmd1YWdlIG9mIGNob2ljZS4g TW9uaXRvciB0aGF0IG5ldyBkZXBlbmRlbmN5IGZvciBzZWN1cml0eSBhZHZpc29yaWVzLg0KICAg ID4+Pj4+ICogY2hvb3NlIGEgc3VpdGFibGUgc2lnbmF0dXJlIGFsZ29yaXRobSAo4oCYZXJlIGJl IGRyYWdvbnMpDQogICAgPj4+Pj4gKiBmaWd1cmUgb3V0IGhvdyB0byBkaXN0cmlidXRlIHRoZSBw cml2YXRlIGtleSB0byBteSBzZXJ2aWNlDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gQ29tcGFyZWQg dG8g4oCcY3JlYXRlIGEgc2VydmljZSBhY2NvdW50IGFuZCBQT1NUIHRoZSB1c2VybmFtZSBhbmQg cGFzc3dvcmQgdG8gdGhlIHRva2VuIGVuZHBvaW504oCdIGl0IGFkZHMgYSBsaXR0bGUgZnJpY3Rp b24uIChJdCBhbHNvIGFkZHMgYSBsb3Qgb2YgYWR2YW50YWdlcywgYnV0IGl0IGlzIHVuZGVuaWFi bHkgbW9yZSBjb21wbGV4KS4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiDigJQgTmVpbA0KICAgID4+ Pj4+IA0KICAgID4+Pj4+IA0KICAgID4+Pj4+PiBPbiAyMSBGZWIgMjAyMCwgYXQgMTM6NDEsIE1h dHRoZXcgRGUgSGFhc3QgPG1hdHQ9NDBjb2lsLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQog ICAgPj4+Pj4+IA0KICAgID4+Pj4+PiBJIGhhdmUgYSBmZWVsaW5nIHRoYXQgaWYgd2UgaGFkIG1v cmUgY29uY2lzZSBKV1QgbGlicmFyaWVzIGFuZCBjb21tYW5kIGxpbmUgdG9vbHMsIHdoZXJlIHVz aW5nIHRoZSBKV1QgQmVhcmVyIGdyYW50IGJlY2FtZSBhIG9uZS1saW5lciBhZ2FpbiB0aGVuIHdl IHdvdWxkbuKAmXQgYmUgaGF2aW5nIHRoaXMgY29udmVyc2F0aW9uLiBTbyBwZXJoYXBzIHJlbW92 aW5nIGl0IGlzIGFuIGluY2VudGl2ZSB0byBtYWtlIHRoYXQgaGFwcGVuLg0KICAgID4+Pj4+PiAN CiAgICA+Pj4+Pj4gTmVpbCBjb3VsZCB5b3UgZWxhYm9yYXRlIG1vcmUgb24gdGhpcyBwbGVhc2Uu IFdoYXQgZmFpbHVyZXMgYXJlIHlvdSBjdXJyZW50bHkgZXhwZXJpZW5jaW5nL3NlZWluZyB3aXRo IHRoZSBKV1QgQmVhcmVyIGdyYW50PyANCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+IE1hdHQNCiAg ICA+Pj4+Pj4gDQogICAgPj4+Pj4+IE9uIFRodSwgRmViIDIwLCAyMDIwIGF0IDEyOjQyIEFNIE5l aWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPiB3cm90ZToNCiAgICA+Pj4+Pj4g SSBoYXZlIGEgZmVlbGluZyB0aGF0IGlmIHdlIGhhZCBtb3JlIGNvbmNpc2UgSldUIGxpYnJhcmll cyBhbmQgY29tbWFuZCBsaW5lIHRvb2xzLCB3aGVyZSB1c2luZyB0aGUgSldUIEJlYXJlciBncmFu dCBiZWNhbWUgYSBvbmUtbGluZXIgYWdhaW4gdGhlbiB3ZSB3b3VsZG7igJl0IGJlIGhhdmluZyB0 aGlzIGNvbnZlcnNhdGlvbi4gU28gcGVyaGFwcyByZW1vdmluZyBpdCBpcyBhbiBpbmNlbnRpdmUg dG8gbWFrZSB0aGF0IGhhcHBlbi4NCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+ Pj4gT24gMTkgRmViIDIwMjAsIGF0IDIyOjAxLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls LmNvbT4gd3JvdGU6DQogICAgPj4+Pj4+PiANCiAgICA+Pj4+Pj4+IE5laWw6IGFyZSB5b3UgYWR2 b2NhdGluZyB0aGF0IHBhc3N3b3JkIGdyYW50IGJlIHByZXNlcnZlZCBpbiAyLjE/IE9yIGRvIHlv dSB0aGluayB0aGF0IHNlcnZpY2UgYWNjb3VudCBkZXZlbG9wZXJzIGtub3cgZW5vdWdoIGFib3V0 IHdoYXQgdGhleSBhcmUgZG9pbmcgdG8gZm9sbG93IHdoYXQgaXMgaW4gNjc0OT8NCiAgICA+Pj4+ Pj4+IOGQpw0KICAgID4+Pj4+Pj4gDQogICAgPj4+Pj4+PiBPbiBXZWQsIEZlYiAxOSwgMjAyMCBh dCAxOjUyIFBNIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPiB3cm90ZToN CiAgICA+Pj4+Pj4+IE9BdXRoMiBjbGllbnRzIGFyZSBvZnRlbiBwcml2YXRlIHRvIHRoZSBBUyAt IHRoZXkgbGl2ZSBpbiBhIGRhdGFiYXNlIHRoYXQgb25seSB0aGUgQVMgY2FuIGFjY2VzcywgaGF2 ZSBhdHRyaWJ1dGVzIHNwZWNpZmljIHRvIHRoZWlyIHVzZSBpbiBPQXV0aDIsIGFuZCBzbyBvbi4g TWFueSBleGlzdGluZyBzeXN0ZW1zIGhhdmUgYWNjZXNzIGNvbnRyb2xzIGJhc2VkIG9uIHVzZXJz LCByb2xlcywgcGVybWlzc2lvbnMgYW5kIHNvIG9uIGFuZCBleHBlY3QgYWxsIHVzZXJzIGFjY2Vz c2luZyB0aGUgc3lzdGVtIHRvIGV4aXN0IGluIHNvbWUgdXNlciByZXBvc2l0b3J5LCBlLmcuIExE QVAsIHdoZXJlIHRoZXkgY2FuIGJlIGxvb2tlZCB1cCBhbmQgYXBwcm9wcmlhdGUgcGVybWlzc2lv bnMgZGV0ZXJtaW5lZC4gQSBzZXJ2aWNlIGFjY291bnQgY2FuIGJlIGNyZWF0ZWQgaW5zaWRlIHN1 Y2ggYSBzeXN0ZW0gYXMgaWYgaXQgd2FzIGEgcmVndWxhciB1c2VyLCBtYW5hZ2VkIHRocm91Z2gg dGhlIG5vcm1hbCBhY2NvdW50IHByb3Zpc2lvbmluZyB0b29scywgYXNzaWduZWQgcGVybWlzc2lv bnMsIHJvbGVzLCBldGMuDQogICAgPj4+Pj4+PiANCiAgICA+Pj4+Pj4+IEFub3RoZXIgcmVhc29u IGlzIHRoYXQgc29tZXRpbWVzIE9BdXRoIGlzIGp1c3Qgb25lIGF1dGhlbnRpY2F0aW9uIG9wdGlv biBvdXQgb2YgbWFueSwgYW5kIHNvIHBlcm1pc3Npb25zIGFzc2lnbmVkIHRvIHNlcnZpY2UgYWNj b3VudHMgYXJlIHByZWZlcnJlZCBvdmVyIHNjb3BlcyBiZWNhdXNlIHRoZXkgYXJlIGNvbnNpc3Rl bnRseSBhcHBsaWVkIG5vIG1hdHRlciBob3cgYSByZXF1ZXN0IGlzIGF1dGhlbnRpY2F0ZWQuIFRo aXMgaXMgb2Z0ZW4gdGhlIGNhc2Ugd2hlbiBPQXV0aCBoYXMgYmVlbiByZXRyb2ZpdHRlZCB0byBh biBleGlzdGluZyBzeXN0ZW0gYW5kIHRoZXkgbmVlZCB0byBwcmVzZXJ2ZSBjb21wYXRpYmlsaXR5 IHdpdGggYWxyZWFkeSBkZXBsb3llZCBjbGllbnRzLg0KICAgID4+Pj4+Pj4gDQogICAgPj4+Pj4+ PiBTZWUgZS5nLiBHb29nbGUgY2xvdWQgcGxhdGZvcm0gKEdDUCk6IGh0dHBzOi8vZGV2ZWxvcGVy cy5nb29nbGUuY29tL2lkZW50aXR5L3Byb3RvY29scy9PQXV0aDJTZXJ2aWNlQWNjb3VudA0KICAg ID4+Pj4+Pj4gVGhleSB1c2UgdGhlIEpXVCBiZWFyZXIgZ3JhbnQgdHlwZSBmb3Igc2VydmljZSBh Y2NvdW50IGF1dGhlbnRpY2F0aW9uIGFuZCBhc3NpZ24gcGVybWlzc2lvbnMgdG8gdGhvc2Ugc2Vy dmljZSBhY2NvdW50cyBhbmQgdHlwaWNhbGx5IGhhdmUgdmVyeSBicm9hZCBzY29wZXMuIEZvciBz ZXJ2aWNlLXRvLXNlcnZpY2UgQVBJIGNhbGxzIHlvdSB0eXBpY2FsbHkgZ2V0IGFuIGFjY2VzcyB0 b2tlbiB3aXRoIGEgc2luZ2xlIHNjb3BlIHRoYXQgaXMgZWZmZWN0aXZlbHkg4oCcYWxsIG9mIEdD UOKAnSBhbmQgZXZlcnl0aGluZyBpcyBtYW5hZ2VkIGF0IHRoZSBsZXZlbCBvZiBwZXJtaXNzaW9u cyBvbiB0aGUgUk8gc2VydmljZSBhY2NvdW50IGl0c2VsZi4gVGhleSBvbmx5IGJyZWFrIGRvd24g ZmluZS1ncmFpbmVkIHNjb3BlcyB3aGVuIHlvdSBhcmUgZGVhbGluZyB3aXRoIHVzZXIgZGF0YSBh bmQgd2lsbCBiZSBnZXR0aW5nIGFuIGFjY2VzcyB0b2tlbiBhcHByb3ZlZCBieSBhIHJlYWwgdXNl ciAodGhyb3VnaCBhIG5vcm1hbCBhdXRoIGNvZGUgZmxvdykuDQogICAgPj4+Pj4+PiANCiAgICA+ Pj4+Pj4+IOKAlCBOZWlsDQogICAgPj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiBPbiAxOSBGZWIgMjAy MCwgYXQgMjE6MzUsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 PiB3cm90ZToNCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiBDYW4geW91IGV4cGxhaW4gbW9y ZSBpbiBkZXRhaWwgd2h5IHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBpc27igJl0 IGFwcGxpY2FibGUgZm9yIHRoZSBraW5kIG9mIHVzZSBjYXNlcyB5b3UgbWVudGlvbmVkPw0KICAg ID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+PiBBbSAxOS4wMi4yMDIwIHVtIDIyOjAzIHNjaHJpZWIg TmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+Og0KICAgID4+Pj4+Pj4+PiAN CiAgICA+Pj4+Pj4+Pj4gSSB2ZXJ5IG11Y2ggYWdyZWUgd2l0aCB0aGlzIHdpdGggcmVnYXJkcyB0 byByZWFsIHVzZXJzLiANCiAgICA+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+IFRoZSBvbmUgbGVn aXRpbWF0ZSB1c2UtY2FzZSBmb3IgUk9QQyBJ4oCZdmUgc2VlbiBpcyBmb3Igc2VydmljZSBhY2Nv dW50cyAtIHdoZXJlIHlvdSBlc3NlbnRpYWxseSB3YW50IHNvbWV0aGluZyBsaWtlIGNsaWVudF9j cmVkZW50aWFscyBidXQgZm9yIHdoYXRldmVyIHJlYXNvbiB5b3UgbmVlZCB0aGUgUk8gdG8gYmUg YSBzZXJ2aWNlIHVzZXIgcmF0aGVyIHRoYW4gYW4gT0F1dGgyIGNsaWVudCAodHlwaWNhbGx5IHNv IHRoYXQgc29tZSBsb3dlciBsYXllciBvZiB0aGUgc3lzdGVtIGNhbiBzdGlsbCBwZXJmb3JtIGl0 cyByZXF1aXJlZCBwZXJtaXNzaW9uIGNoZWNrcykuDQogICAgPj4+Pj4+Pj4+IA0KICAgID4+Pj4+ Pj4+PiBUaGVyZSBhcmUgYmV0dGVyIGdyYW50IHR5cGVzIGZvciB0aGlzIC0gZS5nLiBKV1QgYmVh cmVyIC0gYnV0IHRoZXkgYXJlIGEgYml0IGhhcmRlciB0byBpbXBsZW1lbnQuIEhhdmluZyByZWNl bnRseSBjb252ZXJ0ZWQgc29tZSBjb2RlIGZyb20gUk9QQyB0byBKV1QgYmVhcmVyIGZvciBleGFj dGx5IHRoaXMgdXNlLWNhc2UsIGl0IHdlbnQgZnJvbSBhIGNvdXBsZSBvZiBsaW5lcyBvZiBjb2Rl IHRvIHR3byBzY3JlZW5zIG9mIGNvZGUuIEZvciBzZXJ2aWNlIHRvIHNlcnZpY2UgQVBJIGNhbGxz IHdpdGhpbiBhIGRhdGFjZW50ZXIgSeKAmW0gbm90IGNvbnZpbmNlZCB0aGlzIHJlc3VsdGVkIGlu IGEgbWF0ZXJpYWwgaW5jcmVhc2UgaW4gc2VjdXJpdHkgZm9yIHRoZSBhZGRlZCBjb21wbGV4aXR5 Lg0KICAgID4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4g4oCUIE5laWwNCiAgICA+Pj4+Pj4+Pj4g DQogICAgPj4+Pj4+Pj4+PiBPbiAxOCBGZWIgMjAyMCwgYXQgMjE6NTcsIEhhbnMgWmFuZGJlbHQg PGhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PiB3cm90ZToNCiAgICA+Pj4+Pj4+Pj4+IA0KICAg ID4+Pj4+Pj4+Pj4gSSB3b3VsZCBhbHNvIHNlcmlvdXNseSBsb29rIGF0IHRoZSBvcmlnaW5hbCBt b3RpdmF0aW9uIGJlaGluZCBST1BDOiBJIGtub3cgaXQgaGFzIGJlZW4gZGVwbG95ZWQgYW5kIGlz IHVzZWQgaW4gcXVpdGUgYSBsb3Qgb2YgcGxhY2VzIGJ1dCBJIGhhdmUgbmV2ZXIgYWN0dWFsbHkg Y29tZSBhY3Jvc3MgYSB1c2UgY2FzZSB3aGVyZSBpdCBpcyB1c2VkIGZvciBtaWdyYXRpb24gcHVy cG9zZXMgYW5kIHRoZSBtaWdyYXRpb24gaXMgYWN0dWFsbHkgZXhlY3V0ZWQgKEkga25vdyB0aGF0 IGlzIHN0YXRpc3RpY2FsbHkgbm90IGEgdmVyeSBzdHJvbmcgYXJndW1lbnQgYnV0IEkgY2hhbGxl bmdlIG90aGVycyB0byBjb21lIHVwIHdpdGggb25lLi4uKQ0KICAgID4+Pj4+Pj4+Pj4gSW4gcmVh bGl0eSBpdCB0dXJuZWQgb3V0IGp1c3QgdG8gYmUgYSBvbmUgb2ZmIHRoYXQgcGVvcGxlIHVzZWQg YXMgYW4gZWFzeSB3YXkgb3V0IHRvIHN0aWNrIHRvIGFuIGFudGktcGF0dGVybiBhbmQgc3RpbGwg Y2xhaW0gdG8gZG8gT0F1dGggMi4wLiBJdCBpcyBwbGFpbiB3cm9uZywgaXQgaXMgbm90IE9BdXRo IGFuZCB3ZSBuZWVkIHRvIGdldCByaWQgb2YgaXQuDQogICAgPj4+Pj4+Pj4+PiANCiAgICA+Pj4+ Pj4+Pj4+IEhhbnMuDQogICAgPj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+IE9uIFR1ZSwgRmVi IDE4LCAyMDIwIGF0IDEwOjQ0IFBNIEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPiB3 cm90ZToNCiAgICA+Pj4+Pj4+Pj4+IEFncmVlZC4gUGx1cywgdGhlIFNlY3VyaXR5IEJDUCBpcyBh bHJlYWR5IGVmZmVjdGl2ZWx5IGFjdGluZyBhcyBhIGdyYWNlIHBlcmlvZCBzaW5jZSBpdCBjdXJy ZW50bHkgc2F5cyB0aGUgcGFzc3dvcmQgZ3JhbnQgTVVTVCBOT1QgYmUgdXNlZCwgc28gaW4gdGhl IE9BdXRoIDIuMCB3b3JsZCB0aGF0J3MgYWxyZWFkeSBhIHByZXR0eSBzdHJvbmcgc2lnbmFsLi4N CiAgICA+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4gQWFyb24NCiAgICA+Pj4+Pj4+Pj4+IA0K ICAgID4+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+IE9uIFR1ZSwg RmViIDE4LCAyMDIwIGF0IDQ6MTYgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3 cm90ZToNCiAgICA+Pj4+Pj4+Pj4+IFRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgZ3JhY2UgcGVyaW9k LiBQZW9wbGUgdXNpbmcgT0F1dGggMi4uMCBjYW4gc3RpbGwgZG8gT0F1dGggMi4wLiBQZW9wbGUg dXNpbmcgT0F1dGggMi4xIHdpbGwgZG8gT0F1dGggMi4xLiANCiAgICA+Pj4+Pj4+Pj4+IA0KICAg ID4+Pj4+Pj4+Pj4g4oCUIEp1c3Rpbg0KICAgID4+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+Pj4+ IE9uIEZlYiAxOCwgMjAyMCwgYXQgMzo1NCBQTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPj4+Pj4+Pj4+Pj4gDQog ICAgPj4+Pj4+Pj4+Pj4gSSB3b3VsZCBzdWdnZXN0IGEgU0hPVUxEIE5PVCBpbnN0ZWFkIG9mIE1V U1QsIHRoZXJlIGFyZSBzdGlsbCBzaXRlcyB1c2luZyB0aGlzIGFuZCBhIGdyYWNlIHBlcmlvZCBz aG91bGQgYmUgcHJvdmlkZWQgYmVmb3JlIGEgTVVTVCBpcyBwdXNoZWQgb3V0IGFzIHRoZXJlIGFy ZSB2YWxpZCB1c2UgY2FzZXMgb3V0IHRoZXJlIHN0aWxsLg0KICAgID4+Pj4+Pj4+Pj4+IA0KICAg ID4+Pj4+Pj4+Pj4+IEZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgRGljayBIYXJkdA0KICAgID4+Pj4+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5 IDE4LCAyMDIwIDEyOjM3IFBNDQogICAgPj4+Pj4+Pj4+Pj4gVG86IG9hdXRoQGlldGYub3JnDQog ICAgPj4+Pj4+Pj4+Pj4gU3ViamVjdDogW0VYVEVSTkFMXSBbT0FVVEgtV0ddIE9BdXRoIDIuMTog ZHJvcHBpbmcgcGFzc3dvcmQgZ3JhbnQNCiAgICA+Pj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+ PiBIZXkgTGlzdCANCiAgICA+Pj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+PiAoT25jZSBhZ2Fp biB1c2luZyB0aGUgT0F1dGggMi4xIG5hbWUgYXMgYSBwbGFjZWhvbGRlciBmb3IgdGhlIGRvYyB0 aGF0IEFhcm9uLCBUb3JzdGVuLCBhbmQgSSBhcmUgd29ya2luZyBvbikNCiAgICA+Pj4+Pj4+Pj4+ PiANCiAgICA+Pj4+Pj4+Pj4+PiBJbiB0aGUgc2VjdXJpdHkgdG9waWNzIGRvYw0KICAgID4+Pj4+ Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNCNzZWN0aW9uLTIuNA0KICAgID4+Pj4+Pj4+ Pj4+IA0KICAgID4+Pj4+Pj4+Pj4+IFRoZSBwYXNzd29yZCBncmFudCBNVVNUIG5vdCBiZSB1c2Vk Lg0KICAgID4+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4+IFNvbWUgYmFja2dyb3VuZCBmb3Ig dGhvc2UgaW50ZXJlc3RlZC4gSSBhZGRlZCB0aGlzIGdyYW50IGludG8gT0F1dGggMi4wIHRvIGFs bG93IGFwcGxpY2F0aW9ucyB0aGF0IGhhZCBiZWVuIHByb3ZpZGVkIHBhc3N3b3JkIHRvIG1pZ3Jh dGUuIEV2ZW4gd2l0aCB0aGUgY2F2ZWF0cyBpbiBPQXV0aCAyLjAsIGltcGxlbWVudG9ycyBkZWNp ZGUgdGhleSB3YW50IHRvIHByb21wdCB0aGUgdXNlciB0byBlbnRlciB0aGVpciBjcmVkZW50aWFs cywgdGhlIGFudGktcGF0dGVybiBPQXV0aCB3YXMgY3JlYXRlZCB0byBlbGltaW5hdGUuIA0KICAg ID4+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+Pj4+IERvZXMgYW55 b25lIGhhdmUgY29uY2VybnMgd2l0aCBkcm9wcGluZyB0aGUgcGFzc3dvcmQgZ3JhbnQgZnJvbSB0 aGUgT0F1dGggMi4xIGRvY3VtZW50IHNvIHRoYXQgZGV2ZWxvcGVycyBkb24ndCB1c2UgaXQ/DQog ICAgPj4+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+Pj4gL0RpY2sNCiAgICA+Pj4+Pj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4+ Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4+Pj4+Pj4+Pj4+IE9BdXRoQGlldGYub3Jn DQogICAgPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KICAgID4+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4+Pj4+Pj4gT0F1dGggbWFpbGlu ZyBsaXN0DQogICAgPj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4+Pj4+Pj4+Pj4g LS0gDQogICAgPj4+Pj4+Pj4+PiAtLS0tDQogICAgPj4+Pj4+Pj4+PiBBYXJvbiBQYXJlY2tpDQog ICAgPj4+Pj4+Pj4+PiBhYXJvbnBhcmVja2kuY29tDQogICAgPj4+Pj4+Pj4+PiBAYWFyb25waw0K ICAgID4+Pj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0 DQogICAgPj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4+Pj4+Pj4+Pj4gDQogICAg Pj4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+Pj4+IC0tIA0KICAgID4+Pj4+Pj4+Pj4gaGFucy56YW5k YmVsdEB6bWFydHpvbmUuZXUNCiAgICA+Pj4+Pj4+Pj4+IFptYXJ0Wm9uZSBJQU0gLSB3d3cuem1h cnR6b25lLmV1DQogICAgPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4+Pj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQogICAg Pj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KICAgID4+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ Pj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQogICAgPj4+Pj4+Pj4+IE9BdXRoQGlldGYub3Jn DQogICAgPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAg ID4+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcNCiAgICA+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4+Pj4+IE9BdXRo IG1haWxpbmcgbGlzdA0KICAgID4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgPj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4+Pj4+IE9B dXRoIG1haWxpbmcgbGlzdA0KICAgID4+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KICAgID4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgPj4+Pj4gDQog ICAgPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICA+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+PiBPQXV0aEBpZXRmLm9yZw0K ICAgID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAg ICA+Pj4+IA0KICAgID4+PiANCiAgICA+PiANCiAgICA+IA0KICAgID4gICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgIE9BdXRoIG1haWxp bmcgbGlzdA0KICAgID4gICAgT0F1dGhAaWV0Zi5vcmcNCiAgICA+ICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICA+IA0KICAgID4gDQogICAgDQogICAg DQoNCg== From nobody Fri Feb 21 17:42:08 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAEF1200F8 for ; Fri, 21 Feb 2020 17:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 uGiqCIoyOAA0 for ; Fri, 21 Feb 2020 17:42:02 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3033B12006B for ; Fri, 21 Feb 2020 17:42:02 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id e18so4101219ljn.12 for ; Fri, 21 Feb 2020 17:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r/7sU6/2KU+nOxdK1Jy4yByDNK/YQsDzmgKxVfj7ToM=; b=Sn+6kAhY6QMBMm5+n9V1UHuh5/pvj0Sv278eFjH6vw/bsHov1lC5JiuT1OVpxeXIcf /OQEdfzd3Wf1ZDHShy8Sn33tQywLx6T4wk6AUex8yie3gozMKxib2Q0OVsBw75PEpmgw isVsCQF2/NqBaFL1AqZ0xbIIT3mtOC7BHNLDNI9tEi6pq228EEfGzmcfroMRSTzn+9w0 TU91x1RuJmwe3DDECnI+VzRbtQ9jP13CXm/EO97wQ8TQ1TSjyufL1pgUeM2g6IvOYP8H vG8JJrZOtZmkc4J/mIMhZu0px3pMfBHwwaLkGxdOSPxo+pMdmX6vh1p0I9+Ij0ctv0jH V96w== 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=r/7sU6/2KU+nOxdK1Jy4yByDNK/YQsDzmgKxVfj7ToM=; b=Yj52CiHYdkPo8tkRZiPUtH2+Px6gXiifzdxi5FIX0XwctyMEotxCkaWrMcr1QN77B9 ysr04vzMEA24r5SOi5Cwhp4U71FEhawIu0G9gJNoK1w9BT2uxen8ynSbf1jBIi6hWDnN TWnGgQQmBSl7cjlCtNUNMgsIe4EEmUzrzri3cj/h9oseh1vs3TZDR5N8N3+RFGuMIku8 T3M8LVVG1K8L3BqFHNDA1oRz6mPjpWcW3605EB2c1ezWXYj0lRFoqnkuHKpfOKXErEab caF2t/pAU9ggQ+rkdlB2XEE4upA1pmrjz2PgJ0l8dB7OGRIuOPLcXm3VTkIb1X0j3pcN 6OZQ== X-Gm-Message-State: APjAAAWO/nMv1QypEEu6wrCH9GqX+9nXk47qgpJZo3ZFNLcCqwcnRezP m6IJhl3pUYpTHSFE9UDByROn/ApmJQ2sL0v/sc8= X-Google-Smtp-Source: APXvYqzXVnrkJZtvWMsv5lUBHma1d+3Dq4MBtjlsd4Wfxtqkai8K/RMASqVPAL5avym1r9Q3sdanzZd+ptHIfkibmzk= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr24043235ljh.138.1582335720251; Fri, 21 Feb 2020 17:42:00 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> In-Reply-To: <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> From: Dick Hardt Date: Fri, 21 Feb 2020 17:41:21 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Neil Madden , Matthew De Haast , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000856461059f203e10" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 01:42:08 -0000 --000000000000856461059f203e10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm a little confused on where this thread is going. If we take ROPC out of OAuth 2.1 then: 1) Existing deployments can keep using ROPC - why break it if it is working= . 2) New deployments can use ROPC and be OAuth 2.0 compliant. 3) New deployments that don't need ROPC can be OAuth 2.1 compliant =E1=90=A7 On Fri, Feb 21, 2020 at 5:05 PM Richard Backman, Annabelle wrote: > ROPC without a client ID or authentication is functionally equivalent to > Client Credentials grant with client secret authentication in the request > body. You've just renamed "client_id" to "username" and "client_secret" t= o > "password". > > The AS simply needs to be able to resolve the client ID to the service > account. You could use any of the following strategies, depending on the > environment: > * Use service account identifiers as client IDs > * Use encrypted blobs containing service account identifiers as client > IDs, so someone can't choose a client ID by creating a service account wi= th > a specific identifier > * Use opaque values that the AS can resolve to service account > identifiers, e.g., via a database lookup > > If the AS needs the service account's password because it's authenticatin= g > against a legacy system, then use the service account password as the > client secret. Stack mTLS on top, if you want. If the AS just needs to > resolve the account so it can put it in tokens that RSes will look at, th= en > you can use whatever client authentication mechanism you want. > > Is there a scenario I'm missing here? > > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > =EF=BB=BFOn 2/21/20, 1:53 PM, "Neil Madden" w= rote: > > The AS doesn=E2=80=99t issue the service account IDs, that=E2=80=99s = the whole point - > integration with existing systems. Lot=E2=80=99s of people don=E2=80=99t = have the luxury of > rebuilding systems from scratch to fit in with the preferences of the OAu= th > WG. > > ROPC doesn=E2=80=99t require client authentication, or even a client > identifier. If you=E2=80=99re using a service account you indeed don=E2= =80=99t need to > bother issuing client credentials. The same is true when using the JWT > bearer grant. If you want to increase security you can use cert-bound > access tokens. > > > On 21 Feb 2020, at 20:28, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > The client IDs can still be opaque identifiers provided by the AS, > they just happen to be associated with specific service accounts. Or they > could be the opaque IDs that the AS already issued for the service accoun= t. > Either way, the AS could issue a token with the appropriate subject and > other claims for the service account. > > > > If your client identity is bound to a specific service account > identity (i.e., the resource owner), then ROPC reduces down to Client > Credentials. What's the point in passing two identifiers and two > credentials for the same identity? > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < > oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote: > > > > Sorry, I missed that message. > > > > While this may be a solution in specific circumstances, I don=E2= =80=99t > think it=E2=80=99s a general solution. e.g. an AS may not allow manually = choosing > the client_id to avoid things like > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4= .13 > or may return different introspection results for client credentials toke= ns > (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds ev= en more steps for > somebody to migrate from existing ROPC usage. > > > > This is asking people to make fundamental changes to their > identity architecture rather than simply switching to a new grant type. > > > > =E2=80=94 Neil > > > >> On 21 Feb 2020, at 14:34, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> > >> I see - we have gone full cycle :-) > >> > >> Annabelle=E2=80=99s proposal would solve that. Relate a client id = to a > service account and obtain the token data from there. > >> > >>> On 21. Feb 2020, at 15:31, Neil Madden > wrote: > >>> > >>> Yes, that is great. But mTLS doesn=E2=80=99t support service acco= unts (!=3D > clients). Maybe it should? Should there be a mTLS *grant type*? > >>> > >>> =E2=80=94 Neil > >>> > >>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>> > >>>> Have you ever tried the client credentials grant with mTLS? Afte= r > reading your description it seems to be simpler than JWT Bearer. > >>>> > >>>> * work out if the AS even supports mTLS > >>>> * work out how to configure the AS to trust my cert(s) > >>>> * Create key pair and cert using openssl > >>>> * Register your (self-signed) cert along with your client_id > >>>> * Configure the HTTP client to use your key pair for TLS Client > Authentication > >>>> > >>>> Works very well for us. > >>>> > >>>>> On 21. Feb 2020, at 15:12, Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>> > >>>>> No failures, but it is a much more complex grant type to set up= , > when you consider everything you have to do: > >>>>> > >>>>> * work out if the AS even supports JWT bearer and how to turn i= t > on > >>>>> * work out how to configure the AS to trust my public key(s) > >>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set= ? > >>>>> * determine the correct settings for issuer, audience, subject, > etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says tha= t > the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only allow= s this to be > present if your client is doing impersonation of an end-user (which > requires additional permissions). > >>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers= do, plain OAuth > ones might not) If I do, can I reuse the JWT or must it be freshly signed > for every call? > >>>>> * locate and evaluate a JWT library for my language of choice. > Monitor that new dependency for security advisories. > >>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragon= s) > >>>>> * figure out how to distribute the private key to my service > >>>>> > >>>>> Compared to =E2=80=9Ccreate a service account and POST the user= name and > password to the token endpoint=E2=80=9D it adds a little friction. (It al= so adds a > lot of advantages, but it is undeniably more complex). > >>>>> > >>>>> =E2=80=94 Neil > >>>>> > >>>>> > >>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast 40coil.com@dmarc.ietf.org> wrote: > >>>>>> > >>>>>> I have a feeling that if we had more concise JWT libraries and > command line tools, where using the JWT Bearer grant became a one-liner > again then we wouldn=E2=80=99t be having this conversation. So perhaps re= moving it > is an incentive to make that happen. > >>>>>> > >>>>>> Neil could you elaborate more on this please. What failures ar= e > you currently experiencing/seeing with the JWT Bearer grant? > >>>>>> > >>>>>> Matt > >>>>>> > >>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>>> I have a feeling that if we had more concise JWT libraries and > command line tools, where using the JWT Bearer grant became a one-liner > again then we wouldn=E2=80=99t be having this conversation. So perhaps re= moving it > is an incentive to make that happen. > >>>>>> > >>>>>> > >>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt > wrote: > >>>>>>> > >>>>>>> Neil: are you advocating that password grant be preserved in > 2.1? Or do you think that service account developers know enough about wh= at > they are doing to follow what is in 6749? > >>>>>>> =E1=90=A7 > >>>>>>> > >>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>>>> OAuth2 clients are often private to the AS - they live in a > database that only the AS can access, have attributes specific to their u= se > in OAuth2, and so on. Many existing systems have access controls based on > users, roles, permissions and so on and expect all users accessing the > system to exist in some user repository, e.g. LDAP, where they can be > looked up and appropriate permissions determined. A service account can b= e > created inside such a system as if it was a regular user, managed through > the normal account provisioning tools, assigned permissions, roles, etc. > >>>>>>> > >>>>>>> Another reason is that sometimes OAuth is just one > authentication option out of many, and so permissions assigned to service > accounts are preferred over scopes because they are consistently applied = no > matter how a request is authenticated. This is often the case when OAuth > has been retrofitted to an existing system and they need to preserve > compatibility with already deployed clients. > >>>>>>> > >>>>>>> See e.g. Google cloud platform (GCP): > https://developers.google.com/identity/protocols/OAuth2ServiceAccount > >>>>>>> They use the JWT bearer grant type for service account > authentication and assign permissions to those service accounts and > typically have very broad scopes. For service-to-service API calls you > typically get an access token with a single scope that is effectively =E2= =80=9Call > of GCP=E2=80=9D and everything is managed at the level of permissions on = the RO > service account itself. They only break down fine-grained scopes when you > are dealing with user data and will be getting an access token approved b= y > a real user (through a normal auth code flow). > >>>>>>> > >>>>>>> =E2=80=94 Neil > >>>>>>> > >>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>>>>>> > >>>>>>>> Can you explain more in detail why the client credentials > grant type isn=E2=80=99t applicable for the kind of use cases you mention= ed? > >>>>>>>> > >>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden < > neil.madden@forgerock.com>: > >>>>>>>>> > >>>>>>>>> I very much agree with this with regards to real users. > >>>>>>>>> > >>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is f= or > service accounts - where you essentially want something like > client_credentials but for whatever reason you need the RO to be a servic= e > user rather than an OAuth2 client (typically so that some lower layer of > the system can still perform its required permission checks). > >>>>>>>>> > >>>>>>>>> There are better grant types for this - e.g. JWT bearer - > but they are a bit harder to implement. Having recently converted some co= de > from ROPC to JWT bearer for exactly this use-case, it went from a couple = of > lines of code to two screens of code. For service to service API calls > within a datacenter I=E2=80=99m not convinced this resulted in a material= increase > in security for the added complexity. > >>>>>>>>> > >>>>>>>>> =E2=80=94 Neil > >>>>>>>>> > >>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt < > hans.zandbelt@zmartzone.eu> wrote: > >>>>>>>>>> > >>>>>>>>>> I would also seriously look at the original motivation > behind ROPC: I know it has been deployed and is used in quite a lot of > places but I have never actually come across a use case where it is used > for migration purposes and the migration is actually executed (I know tha= t > is statistically not a very strong argument but I challenge others to com= e > up with one...) > >>>>>>>>>> In reality it turned out just to be a one off that people > used as an easy way out to stick to an anti-pattern and still claim to do > OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of i= t. > >>>>>>>>>> > >>>>>>>>>> Hans. > >>>>>>>>>> > >>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki < > aaron@parecki.com> wrote: > >>>>>>>>>> Agreed. Plus, the Security BCP is already effectively > acting as a grace period since it currently says the password grant MUST > NOT be used, so in the OAuth 2.0 world that's already a pretty strong > signal.. > >>>>>>>>>> > >>>>>>>>>> Aaron > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer < > jricher@mit.edu> wrote: > >>>>>>>>>> There is no need for a grace period. People using OAuth > 2..0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. > >>>>>>>>>> > >>>>>>>>>> =E2=80=94 Justin > >>>>>>>>>> > >>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote: > >>>>>>>>>>> > >>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are > still sites using this and a grace period should be provided before a MUS= T > is pushed out as there are valid use cases out there still. > >>>>>>>>>>> > >>>>>>>>>>> From: OAuth On Behalf Of Dick > Hardt > >>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM > >>>>>>>>>>> To: oauth@ietf.org > >>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping > password grant > >>>>>>>>>>> > >>>>>>>>>>> Hey List > >>>>>>>>>>> > >>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for > the doc that Aaron, Torsten, and I are working on) > >>>>>>>>>>> > >>>>>>>>>>> In the security topics doc > >>>>>>>>>>> > >>>>>>>>>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > >>>>>>>>>>> > >>>>>>>>>>> The password grant MUST not be used. > >>>>>>>>>>> > >>>>>>>>>>> Some background for those interested. I added this grant > into OAuth 2.0 to allow applications that had been provided password to > migrate. Even with the caveats in OAuth 2.0, implementors decide they wan= t > to prompt the user to enter their credentials, the anti-pattern OAuth was > created to eliminate. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Does anyone have concerns with dropping the password gran= t > from the OAuth 2.1 document so that developers don't use it? > >>>>>>>>>>> > >>>>>>>>>>> /Dick > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> OAuth mailing list > >>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> OAuth mailing list > >>>>>>>>>> OAuth@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>> -- > >>>>>>>>>> ---- > >>>>>>>>>> Aaron Parecki > >>>>>>>>>> aaronparecki.com > >>>>>>>>>> @aaronpk > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> OAuth mailing list > >>>>>>>>>> OAuth@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> hans.zandbelt@zmartzone.eu > >>>>>>>>>> ZmartZone IAM - www.zmartzone.eu > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> OAuth mailing list > >>>>>>>>>> OAuth@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> OAuth mailing list > >>>>>>>>> OAuth@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000856461059f203e10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm a little confused on where this thread is goi= ng. If we take ROPC out of OAuth 2.1 then:

1) Exis= ting deployments can keep using ROPC - why break it if it is working.
=

2) New deployments can use ROPC and be OAuth 2.0 compli= ant.

3) New deployments that don't need ROPC c= an be OAuth 2.1 compliant

3D""=E1=90=A7

On Fri, Feb 21, 2020 at 5:05 PM Richard Backman, Annabelle <richanna= =3D40amazon.com@dmarc.ietf.o= rg> wrote:
https://aws.amazon.com/identity/


=EF=BB=BFOn 2/21/20, 1:53 PM, "Neil Madden" <neil.madden@forgerock.com= > wrote:

=C2=A0 =C2=A0 The AS doesn=E2=80=99t issue the service account IDs, that=E2= =80=99s the whole point - integration with existing systems. Lot=E2=80=99s = of people don=E2=80=99t have the luxury of rebuilding systems from scratch = to fit in with the preferences of the OAuth WG.

=C2=A0 =C2=A0 ROPC doesn=E2=80=99t require client authentication, or even a= client identifier. If you=E2=80=99re using a service account you indeed do= n=E2=80=99t need to bother issuing client credentials. The same is true whe= n using the JWT bearer grant. If you want to increase security you can use = cert-bound access tokens.

=C2=A0 =C2=A0 > On 21 Feb 2020, at 20:28, Richard Backman, Annabelle <= ;richanna@amazon.c= om> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The client IDs can still be opaque identifiers provided = by the AS, they just happen to be associated with specific service accounts= . Or they could be the opaque IDs that the AS already issued for the servic= e account. Either way, the AS could issue a token with the appropriate subj= ect and other claims for the service account.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > If your client identity is bound to a specific service a= ccount identity (i.e., the resource owner), then ROPC reduces down to Clien= t Credentials. What's the point in passing two identifiers and two cred= entials for the same identity?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =E2=80=93
=C2=A0 =C2=A0 > Annabelle Backman (she/her)
=C2=A0 =C2=A0 > AWS Identity
=C2=A0 =C2=A0 > https://aws.amazon.com/identity/
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madde= n" <oau= th-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Sorry, I missed that message.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 While this may be a solution in specific ci= rcumstances, I don=E2=80=99t think it=E2=80=99s a general solution. e.g. an= AS may not allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/= draft-ietf-oauth-security-topics-14#section-4.13 or may return differen= t introspection results for client credentials tokens (e.g. with no =E2=80= =9Csub=E2=80=9D) and so on. In practice, this adds even more steps for some= body to migrate from existing ROPC usage.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 This is asking people to make fundamental c= hanges to their identity architecture rather than simply switching to a new= grant type.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =E2=80=94 Neil
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <torsten@lodderst= edt.net> wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I see - we have gone full cycle :-)
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Annabelle=E2=80=99s proposal would solve that. Relat= e a client id to a service account and obtain the token data from there. =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forge= rock.com> wrote:
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Yes, that is great. But mTLS doesn=E2=80=99t sup= port service accounts (!=3D clients). Maybe it should? Should there be a mT= LS *grant type*?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> =E2=80=94 Neil
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>> On 21 Feb 2020, at 14:20, Torsten Loddersted= t <torsten@= lodderstedt.net> wrote:
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Have you ever tried the client credentials g= rant with mTLS? After reading your description it seems to be simpler than = JWT Bearer.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> * work out if the AS even supports mTLS
=C2=A0 =C2=A0 >>>> * work out how to configure the AS to trust = my cert(s)
=C2=A0 =C2=A0 >>>> * Create key pair and cert using openssl
=C2=A0 =C2=A0 >>>> * Register your (self-signed) cert along wit= h your client_id
=C2=A0 =C2=A0 >>>> * Configure the HTTP client to use your key = pair for TLS Client Authentication
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Works very well for us.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>> On 21. Feb 2020, at 15:12, Neil Madden &= lt;neil.madd= en@forgerock.com> wrote:
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> No failures, but it is a much more compl= ex grant type to set up, when you consider everything you have to do:
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> * work out if the AS even supports JWT b= earer and how to turn it on
=C2=A0 =C2=A0 >>>>> * work out how to configure the AS to tr= ust my public key(s)
=C2=A0 =C2=A0 >>>>> - do I have to create a new HTTPS endpoi= nt to publish a JWK Set?
=C2=A0 =C2=A0 >>>>> * determine the correct settings for iss= uer, audience, subject, etc. Does the AS impose non-standard requirements? = e.g. RFC 7523 says that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim,= but Google only allows this to be present if your client is doing imperson= ation of an end-user (which requires additional permissions).
=C2=A0 =C2=A0 >>>>> * do I need a unique =E2=80=9Cjti=E2=80= =9D claim? (OIDC servers do, plain OAuth ones might not) If I do, can I reu= se the JWT or must it be freshly signed for every call?
=C2=A0 =C2=A0 >>>>> * locate and evaluate a JWT library for = my language of choice. Monitor that new dependency for security advisories.=
=C2=A0 =C2=A0 >>>>> * choose a suitable signature algorithm = (=E2=80=98ere be dragons)
=C2=A0 =C2=A0 >>>>> * figure out how to distribute the priva= te key to my service
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> Compared to =E2=80=9Ccreate a service ac= count and POST the username and password to the token endpoint=E2=80=9D it = adds a little friction. (It also adds a lot of advantages, but it is undeni= ably more complex).
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> =E2=80=94 Neil
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>> On 21 Feb 2020, at 13:41, Matthew De= Haast <matt=3D40coil.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> I have a feeling that if we had more= concise JWT libraries and command line tools, where using the JWT Bearer g= rant became a one-liner again then we wouldn=E2=80=99t be having this conve= rsation. So perhaps removing it is an incentive to make that happen.
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> Neil could you elaborate more on thi= s please. What failures are you currently experiencing/seeing with the JWT = Bearer grant?
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> Matt
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> On Thu, Feb 20, 2020 at 12:42 AM Nei= l Madden <neil.madden@forgerock.com> wrote:
=C2=A0 =C2=A0 >>>>>> I have a feeling that if we had more= concise JWT libraries and command line tools, where using the JWT Bearer g= rant became a one-liner again then we wouldn=E2=80=99t be having this conve= rsation. So perhaps removing it is an incentive to make that happen.
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>>> On 19 Feb 2020, at 22:01, Dick H= ardt <dick.har= dt@gmail.com> wrote:
=C2=A0 =C2=A0 >>>>>>>
=C2=A0 =C2=A0 >>>>>>> Neil: are you advocating that pa= ssword grant be preserved in 2.1? Or do you think that service account deve= lopers know enough about what they are doing to follow what is in 6749?
=C2=A0 =C2=A0 >>>>>>> =E1=90=A7
=C2=A0 =C2=A0 >>>>>>>
=C2=A0 =C2=A0 >>>>>>> On Wed, Feb 19, 2020 at 1:52 PM = Neil Madden <neil.madden@forgerock.com> wrote:
=C2=A0 =C2=A0 >>>>>>> OAuth2 clients are often private= to the AS - they live in a database that only the AS can access, have attr= ibutes specific to their use in OAuth2, and so on. Many existing systems ha= ve access controls based on users, roles, permissions and so on and expect = all users accessing the system to exist in some user repository, e.g. LDAP,= where they can be looked up and appropriate permissions determined. A serv= ice account can be created inside such a system as if it was a regular user= , managed through the normal account provisioning tools, assigned permissio= ns, roles, etc.
=C2=A0 =C2=A0 >>>>>>>
=C2=A0 =C2=A0 >>>>>>> Another reason is that sometimes= OAuth is just one authentication option out of many, and so permissions as= signed to service accounts are preferred over scopes because they are consi= stently applied no matter how a request is authenticated. This is often the= case when OAuth has been retrofitted to an existing system and they need t= o preserve compatibility with already deployed clients.
=C2=A0 =C2=A0 >>>>>>>
=C2=A0 =C2=A0 >>>>>>> See e.g. Google cloud platform (= GCP): https://developers.google= .com/identity/protocols/OAuth2ServiceAccount
=C2=A0 =C2=A0 >>>>>>> They use the JWT bearer grant ty= pe for service account authentication and assign permissions to those servi= ce accounts and typically have very broad scopes. For service-to-service AP= I calls you typically get an access token with a single scope that is effec= tively =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level = of permissions on the RO service account itself. They only break down fine-= grained scopes when you are dealing with user data and will be getting an a= ccess token approved by a real user (through a normal auth code flow).
=C2=A0 =C2=A0 >>>>>>>
=C2=A0 =C2=A0 >>>>>>> =E2=80=94 Neil
=C2=A0 =C2=A0 >>>>>>>
=C2=A0 =C2=A0 >>>>>>>> On 19 Feb 2020, at 21:35, To= rsten Lodderstedt <torsten@lodderstedt.net> wrote:
=C2=A0 =C2=A0 >>>>>>>>
=C2=A0 =C2=A0 >>>>>>>> Can you explain more in deta= il why the client credentials grant type isn=E2=80=99t applicable for the k= ind of use cases you mentioned?
=C2=A0 =C2=A0 >>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>> Am 19.02.2020 um 22:03 s= chrieb Neil Madden <neil.madden@forgerock.com>:
=C2=A0 =C2=A0 >>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>> I very much agree with t= his with regards to real users.
=C2=A0 =C2=A0 >>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>> The one legitimate use-c= ase for ROPC I=E2=80=99ve seen is for service accounts - where you essentia= lly want something like client_credentials but for whatever reason you need= the RO to be a service user rather than an OAuth2 client (typically so tha= t some lower layer of the system can still perform its required permission = checks).
=C2=A0 =C2=A0 >>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>> There are better grant t= ypes for this - e.g. JWT bearer - but they are a bit harder to implement. H= aving recently converted some code from ROPC to JWT bearer for exactly this= use-case, it went from a couple of lines of code to two screens of code. F= or service to service API calls within a datacenter I=E2=80=99m not convinc= ed this resulted in a material increase in security for the added complexit= y.
=C2=A0 =C2=A0 >>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>> =E2=80=94 Neil
=C2=A0 =C2=A0 >>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> On 18 Feb 2020, at 2= 1:57, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> I would also serious= ly look at the original motivation behind ROPC: I know it has been deployed= and is used in quite a lot of places but I have never actually come across= a use case where it is used for migration purposes and the migration is ac= tually executed (I know that is statistically not a very strong argument bu= t I challenge others to come up with one...)
=C2=A0 =C2=A0 >>>>>>>>>> In reality it turned= out just to be a one off that people used as an easy way out to stick to a= n anti-pattern and still claim to do OAuth 2.0. It is plain wrong, it is no= t OAuth and we need to get rid of it.
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> Hans.
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> On Tue, Feb 18, 2020= at 10:44 PM Aaron Parecki <aaron@parecki.com> wrote:
=C2=A0 =C2=A0 >>>>>>>>>> Agreed. Plus, the Se= curity BCP is already effectively acting as a grace period since it current= ly says the password grant MUST NOT be used, so in the OAuth 2.0 world that= 's already a pretty strong signal..
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> Aaron
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> On Tue, Feb 18, 2020= at 4:16 PM Justin Richer <jricher@mit.edu> wrote:
=C2=A0 =C2=A0 >>>>>>>>>> There is no need for= a grace period. People using OAuth 2..0 can still do OAuth 2.0. People usi= ng OAuth 2.1 will do OAuth 2.1.
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> =E2=80=94 Justin
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>>> On Feb 18, 2= 020, at 3:54 PM, Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org&= gt; wrote:
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> I would suggest = a SHOULD NOT instead of MUST, there are still sites using this and a grace = period should be provided before a MUST is pushed out as there are valid us= e cases out there still.
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> From: OAuth <= oauth-bounces@i= etf.org> On Behalf Of Dick Hardt
=C2=A0 =C2=A0 >>>>>>>>>>> Sent: Tuesday, F= ebruary 18, 2020 12:37 PM
=C2=A0 =C2=A0 >>>>>>>>>>> To: oauth@ietf.org
=C2=A0 =C2=A0 >>>>>>>>>>> Subject: [EXTERN= AL] [OAUTH-WG] OAuth 2.1: dropping password grant
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> Hey List
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> (Once again usin= g the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and = I are working on)
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> In the security = topics doc
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oa= uth-security-topics-14#section-2.4
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> The password gra= nt MUST not be used.
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> Some background = for those interested. I added this grant into OAuth 2.0 to allow applicatio= ns that had been provided password to migrate. Even with the caveats in OAu= th 2.0, implementors decide they want to prompt the user to enter their cre= dentials, the anti-pattern OAuth was created to eliminate.
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> Does anyone have= concerns with dropping the password grant from the OAuth 2.1 document so t= hat developers don't use it?
=C2=A0 =C2=A0 >>>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>> /Dick
=C2=A0 =C2=A0 >>>>>>>>>>> ________________= _______________________________
=C2=A0 =C2=A0 >>>>>>>>>>> OAuth mailing li= st
=C2=A0 =C2=A0 >>>>>>>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> ____________________= ___________________________
=C2=A0 =C2=A0 >>>>>>>>>> OAuth mailing list =C2=A0 =C2=A0 >>>>>>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>>>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>>>>>> --
=C2=A0 =C2=A0 >>>>>>>>>> ----
=C2=A0 =C2=A0 >>>>>>>>>> Aaron Parecki
=C2=A0 =C2=A0 >>>>>>>>>> aaronparecki.com =C2=A0 =C2=A0 >>>>>>>>>> @aaronpk
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> ____________________= ___________________________
=C2=A0 =C2=A0 >>>>>>>>>> OAuth mailing list =C2=A0 =C2=A0 >>>>>>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>>>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>>> --
=C2=A0 =C2=A0 >>>>>>>>>> hans.zandbelt@zmartzone.eu<= br> =C2=A0 =C2=A0 >>>>>>>>>> ZmartZone IAM - www.zm= artzone.eu
=C2=A0 =C2=A0 >>>>>>>>>> ____________________= ___________________________
=C2=A0 =C2=A0 >>>>>>>>>> OAuth mailing list =C2=A0 =C2=A0 >>>>>>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>>>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>>>>>
=C2=A0 =C2=A0 >>>>>>>>> ________________________= _______________________
=C2=A0 =C2=A0 >>>>>>>>> OAuth mailing list
=C2=A0 =C2=A0 >>>>>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>>>>> https:= //www.ietf.org/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>>>
=C2=A0 =C2=A0 >>>>>>> ________________________________= _______________
=C2=A0 =C2=A0 >>>>>>> OAuth mailing list
=C2=A0 =C2=A0 >>>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>>> https://www.ie= tf.org/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>>
=C2=A0 =C2=A0 >>>>>> ____________________________________= ___________
=C2=A0 =C2=A0 >>>>>> OAuth mailing list
=C2=A0 =C2=A0 >>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>> https://www.ietf.o= rg/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>> ____________________________________= ___________
=C2=A0 =C2=A0 >>>>>> OAuth mailing list
=C2=A0 =C2=A0 >>>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>>> https://www.ietf.o= rg/mailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> ________________________________________= _______
=C2=A0 =C2=A0 >>>>> OAuth mailing list
=C2=A0 =C2=A0 >>>>> OAuth@ietf.org
=C2=A0 =C2=A0 >>>>> https://www.ietf.org/m= ailman/listinfo/oauth
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 ___________________________________________= ____
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 OAuth mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 OAuth@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 https://www.ietf.org/mail= man/listinfo/oauth
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000856461059f203e10-- From nobody Sat Feb 22 07:54:35 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E137212001A for ; Sat, 22 Feb 2020 07:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-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 CdNCSBk7nNUZ for ; Sat, 22 Feb 2020 07:54:30 -0800 (PST) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA181200B5 for ; Sat, 22 Feb 2020 07:54:30 -0800 (PST) Received: by mail-pl1-x644.google.com with SMTP id y1so2164018plp.7 for ; Sat, 22 Feb 2020 07:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=qifMzz/L1poMPKJ0k/Arh4JZZG/8cdBNvdC+ZgDjaIs=; b=q/eEvAH02aBGrL5gJ+5qCfjHI7p7TIJMUBVJUWCUyWFWqkSjvV31uggFIOaSxYqhqs wckIMKl6x6q9bPxLH7/WnqwjLewYw9PY7LttOTe3U01VwByglVpfvHSbJVhCPota3tnk Kx4vvVuMnCztdMEgNS2JFsGRnpYrM6TP28Y/bwpfvxkrDieCr2KmOHtQeNKiBNLAz1I9 V9IPgGH0alummnpVo41YymGsBYQcZel/zZOW8gEvHhAocnOl0U96lLmmh/TDTFo1sOWb LLXi4z3Lbo6J/ipJRJ9+gROF8vaMKNWE9F/OaBAxYCLI/whW2K7NBKZI0lXnO3prmHDq nl7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=qifMzz/L1poMPKJ0k/Arh4JZZG/8cdBNvdC+ZgDjaIs=; b=taPzKteGFJKoGzwzZtzPipuf0gr7sSEzsMUg2XRcJngCoLlO16fewpWQ8vn8rnKVWp c/UiCP3DF0ntjR848/+G+EJ2JrnRhhq2rIEIDTai6ghcrBBwPW82gyWengugTaMWiZNz hjXQz+ogqFWi+5mqu09h01IJ+q9Wm7/vwpMVHGWrRRxU3WzcsgAHLCcPl5ih6D6Oy4t2 bUdT/xQmQKapGk2yUW4ygCQM35fAsMueRJm0bfPkfwPCRjPZgrgmXLaud4JK9CzKJiPX /5YqaKwT8Oc6q7Q70s2OszRK3nIq/oSs8SrbDjKYGYvAJB5/PboD3nLiRrTzDDTYkJRV d+lA== X-Gm-Message-State: APjAAAVucC4kEvLPoJP/AVdUvtuPjQqgZE4UHzN/6V+aZsoArxyOIFaw I9QNu0dpp8KQgfZHkeyFER6T+r8GcsngQIzL X-Google-Smtp-Source: APXvYqwYMUl8zEwzcKgA2JouzuV83qu8xhR8pjiWrhOsn2nkNiTj5GIXL676Q3cUGXtIKqMBhuLvFg== X-Received: by 2002:a17:90a:c389:: with SMTP id h9mr10416188pjt.128.1582386869752; Sat, 22 Feb 2020 07:54:29 -0800 (PST) Received: from ?IPv6:2001:569:7a71:1d00:ecb6:dcd0:da2a:4ce4? (node-1w7jr9qrfoxxb4ha4of2eefok.ipv6.telus.net. [2001:569:7a71:1d00:ecb6:dcd0:da2a:4ce4]) by smtp.gmail.com with ESMTPSA id d69sm7173509pfd.72.2020.02.22.07.54.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Feb 2020 07:54:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Sat, 22 Feb 2020 07:54:28 -0800 Message-Id: References: <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> Cc: Neil Madden , Matthew De Haast , "oauth@ietf.org" In-Reply-To: <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 15:54:34 -0000 It may be programmatically equiv but from a trust perspective very different= .=20 Usually client cred flows are from trusted entities and fixed endpoints.=20 Phil > On Feb 21, 2020, at 5:05 PM, Richard Backman, Annabelle wrote: >=20 > =EF=BB=BFROPC without a client ID or authentication is functionally equiva= lent to Client Credentials grant with client secret authentication in the re= quest body. You've just renamed "client_id" to "username" and "client_secret= " to "password". >=20 > The AS simply needs to be able to resolve the client ID to the service acc= ount. You could use any of the following strategies, depending on the enviro= nment: > * Use service account identifiers as client IDs > * Use encrypted blobs containing service account identifiers as client IDs= , so someone can't choose a client ID by creating a service account with a s= pecific identifier > * Use opaque values that the AS can resolve to service account identifiers= , e.g., via a database lookup >=20 > If the AS needs the service account's password because it's authenticating= against a legacy system, then use the service account password as the clien= t secret. Stack mTLS on top, if you want. If the AS just needs to resolve th= e account so it can put it in tokens that RSes will look at, then you can us= e whatever client authentication mechanism you want. >=20 > Is there a scenario I'm missing here? >=20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ >=20 >=20 > =EF=BB=BFOn 2/21/20, 1:53 PM, "Neil Madden" wr= ote: >=20 > The AS doesn=E2=80=99t issue the service account IDs, that=E2=80=99s th= e whole point - integration with existing systems. Lot=E2=80=99s of people d= on=E2=80=99t have the luxury of rebuilding systems from scratch to fit in wi= th the preferences of the OAuth WG. >=20 > ROPC doesn=E2=80=99t require client authentication, or even a client id= entifier. If you=E2=80=99re using a service account you indeed don=E2=80=99t= need to bother issuing client credentials. The same is true when using the J= WT bearer grant. If you want to increase security you can use cert-bound acc= ess tokens. >=20 >> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle wrote: >>=20 >> The client IDs can still be opaque identifiers provided by the AS, they j= ust happen to be associated with specific service accounts. Or they could be= the opaque IDs that the AS already issued for the service account. Either w= ay, the AS could issue a token with the appropriate subject and other claims= for the service account. >>=20 >> If your client identity is bound to a specific service account identity (= i.e., the resource owner), then ROPC reduces down to Client Credentials. Wha= t's the point in passing two identifiers and two credentials for the same id= entity? >>=20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >>=20 >>=20 >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" wrote: >>=20 >> Sorry, I missed that message.=20 >>=20 >> While this may be a solution in specific circumstances, I don=E2=80=99t= think it=E2=80=99s a general solution. e.g. an AS may not allow manually ch= oosing the client_id to avoid things like https://tools.ietf.org/html/draft-= ietf-oauth-security-topics-14#section-4.13 or may return different introspec= tion results for client credentials tokens (e.g. with no =E2=80=9Csub=E2=80=9D= ) and so on. In practice, this adds even more steps for somebody to migrate f= rom existing ROPC usage. >>=20 >> This is asking people to make fundamental changes to their identity arc= hitecture rather than simply switching to a new grant type. >>=20 >> =E2=80=94 Neil >>=20 >>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>>=20 >>> I see - we have gone full cycle :-) >>>=20 >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id to a s= ervice account and obtain the token data from there.=20 >>>=20 >>>> On 21. Feb 2020, at 15:31, Neil Madden wrot= e: >>>>=20 >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service accounts (= !=3D clients). Maybe it should? Should there be a mTLS *grant type*? >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt wrote: >>>>>=20 >>>>> Have you ever tried the client credentials grant with mTLS? After read= ing your description it seems to be simpler than JWT Bearer. >>>>>=20 >>>>> * work out if the AS even supports mTLS >>>>> * work out how to configure the AS to trust my cert(s) >>>>> * Create key pair and cert using openssl >>>>> * Register your (self-signed) cert along with your client_id >>>>> * Configure the HTTP client to use your key pair for TLS Client Authen= tication >>>>>=20 >>>>> Works very well for us.=20 >>>>>=20 >>>>>> On 21. Feb 2020, at 15:12, Neil Madden wr= ote: >>>>>>=20 >>>>>> No failures, but it is a much more complex grant type to set up, when= you consider everything you have to do: >>>>>>=20 >>>>>> * work out if the AS even supports JWT bearer and how to turn it on >>>>>> * work out how to configure the AS to trust my public key(s) >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>>> * determine the correct settings for issuer, audience, subject, etc. D= oes the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT= MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only allows this to b= e present if your client is doing impersonation of an end-user (which requir= es additional permissions). >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, p= lain OAuth ones might not) If I do, can I reuse the JWT or must it be freshl= y signed for every call? >>>>>> * locate and evaluate a JWT library for my language of choice. Monito= r that new dependency for security advisories. >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>>>> * figure out how to distribute the private key to my service >>>>>>=20 >>>>>> Compared to =E2=80=9Ccreate a service account and POST the username a= nd password to the token endpoint=E2=80=9D it adds a little friction. (It al= so adds a lot of advantages, but it is undeniably more complex). >>>>>>=20 >>>>>> =E2=80=94 Neil >>>>>>=20 >>>>>>=20 >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast wrote: >>>>>>>=20 >>>>>>> I have a feeling that if we had more concise JWT libraries and comma= nd line tools, where using the JWT Bearer grant became a one-liner again the= n we wouldn=E2=80=99t be having this conversation. So perhaps removing it is= an incentive to make that happen. >>>>>>>=20 >>>>>>> Neil could you elaborate more on this please. What failures are you c= urrently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>>=20 >>>>>>> Matt >>>>>>>=20 >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden wrote: >>>>>>> I have a feeling that if we had more concise JWT libraries and comma= nd line tools, where using the JWT Bearer grant became a one-liner again the= n we wouldn=E2=80=99t be having this conversation. So perhaps removing it is= an incentive to make that happen. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt wrote: >>>>>>>>=20 >>>>>>>> Neil: are you advocating that password grant be preserved in 2.1? O= r do you think that service account developers know enough about what they a= re doing to follow what is in 6749? >>>>>>>> =E1=90=A7 >>>>>>>>=20 >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden wrote: >>>>>>>> OAuth2 clients are often private to the AS - they live in a databas= e that only the AS can access, have attributes specific to their use in OAut= h2, and so on. Many existing systems have access controls based on users, ro= les, permissions and so on and expect all users accessing the system to exis= t in some user repository, e.g. LDAP, where they can be looked up and approp= riate permissions determined. A service account can be created inside such a= system as if it was a regular user, managed through the normal account prov= isioning tools, assigned permissions, roles, etc. >>>>>>>>=20 >>>>>>>> Another reason is that sometimes OAuth is just one authentication o= ption out of many, and so permissions assigned to service accounts are prefe= rred over scopes because they are consistently applied no matter how a reque= st is authenticated. This is often the case when OAuth has been retrofitted t= o an existing system and they need to preserve compatibility with already de= ployed clients. >>>>>>>>=20 >>>>>>>> See e.g. Google cloud platform (GCP): https://developers.google.com= /identity/protocols/OAuth2ServiceAccount >>>>>>>> They use the JWT bearer grant type for service account authenticati= on and assign permissions to those service accounts and typically have very b= road scopes. For service-to-service API calls you typically get an access to= ken with a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D and= everything is managed at the level of permissions on the RO service account= itself. They only break down fine-grained scopes when you are dealing with u= ser data and will be getting an access token approved by a real user (throug= h a normal auth code flow). >>>>>>>>=20 >>>>>>>> =E2=80=94 Neil >>>>>>>>=20 >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt wrote: >>>>>>>>>=20 >>>>>>>>> Can you explain more in detail why the client credentials grant ty= pe isn=E2=80=99t applicable for the kind of use cases you mentioned? >>>>>>>>>=20 >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden : >>>>>>>>>>=20 >>>>>>>>>> I very much agree with this with regards to real users.=20 >>>>>>>>>>=20 >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for ser= vice accounts - where you essentially want something like client_credentials= but for whatever reason you need the RO to be a service user rather than an= OAuth2 client (typically so that some lower layer of the system can still p= erform its required permission checks). >>>>>>>>>>=20 >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but the= y are a bit harder to implement. Having recently converted some code from RO= PC to JWT bearer for exactly this use-case, it went from a couple of lines o= f code to two screens of code. For service to service API calls within a dat= acenter I=E2=80=99m not convinced this resulted in a material increase in se= curity for the added complexity. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Neil >>>>>>>>>>=20 >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would also seriously look at the original motivation behind RO= PC: I know it has been deployed and is used in quite a lot of places but I h= ave never actually come across a use case where it is used for migration pur= poses and the migration is actually executed (I know that is statistically n= ot a very strong argument but I challenge others to come up with one...) >>>>>>>>>>> In reality it turned out just to be a one off that people used a= s an easy way out to stick to an anti-pattern and still claim to do OAuth 2.= 0. It is plain wrong, it is not OAuth and we need to get rid of it. >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote: >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting as a= grace period since it currently says the password grant MUST NOT be used, s= o in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>>=20 >>>>>>>>>>> Aaron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer w= rote: >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 can= still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still s= ites using this and a grace period should be provided before a MUST is pushe= d out as there are valid use cases out there still. >>>>>>>>>>>>=20 >>>>>>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password gra= nt >>>>>>>>>>>>=20 >>>>>>>>>>>> Hey List=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the d= oc that Aaron, Torsten, and I are working on) >>>>>>>>>>>>=20 >>>>>>>>>>>> In the security topics doc >>>>>>>>>>>>=20 >>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14= #section-2.4 >>>>>>>>>>>>=20 >>>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>>=20 >>>>>>>>>>>> Some background for those interested. I added this grant into O= Auth 2.0 to allow applications that had been provided password to migrate. E= ven with the caveats in OAuth 2.0, implementors decide they want to prompt t= he user to enter their credentials, the anti-pattern OAuth was created to el= iminate.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Does anyone have concerns with dropping the password grant from= the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>>=20 >>>>>>>>>>>> /Dick >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> ---- >>>>>>>>>>> Aaron Parecki >>>>>>>>>>> aaronparecki.com >>>>>>>>>>> @aaronpk >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=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 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Feb 24 06:49:14 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9BE3A0C99 for ; Mon, 24 Feb 2020 06:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 HDiOirQRuRlt for ; Mon, 24 Feb 2020 06:49:10 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566793A0C96 for ; Mon, 24 Feb 2020 06:49:09 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id a9so9702828wmj.3 for ; Mon, 24 Feb 2020 06:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8sN2840a0f2PLOPYvaMiKdOoUxoA8aCUKtlfur0MKhE=; b=VxVXXm/20uj6UCh4WQn8PUS6dXhsJ4TmI9koALG1dzz5KjJXZCL7SSkYAYIaKW8BnV xCUFWE8Wi/GohnTFL7eLroCp3HqFZI+Pw5jzTjseNNFjUS7DS/qY6I0PTZle6TdxZl5C mtRH6ZQSiJ/RQmOt7NbELJmBsqyx4fPqlDOJI= 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=8sN2840a0f2PLOPYvaMiKdOoUxoA8aCUKtlfur0MKhE=; b=JjglHKP5ZMpn9yzYwjKlQnCGAGNFfpxI+kr6Q37T73iK01qMYBdqd2SMHbfQp5UGXJ PiReM1liIH/TRxJM1O7CmWXYTB8Rbw4XAYlBT9MvjCEMIDQSJRrQyhRoj3eSHZTEPAg7 a+s36rqDxAMOMG/3Y/w6gtJnvLdYcAFICpDLDTW2Pvb9jEwMATmrc5SLK4dlRJjEKgb9 LTVp5QjNbFX0HW+PZ8uFz37Rk56LICtnxNYf+pKswaF5csTt2tAp0EWjoE+1kLbzL+Th pucw0POc9UOv32NsjlfnjuXgF/EQqS0XWgGBnCN3zNK+ryvxnNqAFHFSn2GhOF+dgwag ZPww== X-Gm-Message-State: APjAAAUsJJmFe6CcWikWPTa5xqnPvqeyH48pV8TFgKGLmqToZSxc7Nlz f4m1Mo97e08AmbPBnI9e4zcwnA== X-Google-Smtp-Source: APXvYqwSKPW5L0wE5Xtd0Y90yGE9cQeph8OBawqrPpZh5RrSgMfepdh1anJcsR0dOnuCBpX/iOUZYA== X-Received: by 2002:a1c:6a16:: with SMTP id f22mr21959212wmc.53.1582555747198; Mon, 24 Feb 2020 06:49:07 -0800 (PST) Received: from zaphod.home.gateway (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id p15sm17982231wma.40.2020.02.24.06.49.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2020 06:49:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: Date: Mon, 24 Feb 2020 14:49:04 +0000 Cc: "Richard Backman, Annabelle" , Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> To: Dick Hardt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 14:49:13 -0000 Well, kinda. People can still theoretically use OAuth 1 too, but the = world has moved on - software has dropped support for it, websites = don=E2=80=99t support it, and so on. I=E2=80=99m a bit confused about what OAuth 2.1 is intended to be. If = it=E2=80=99s not a new version of OAuth (=E2=80=9Cobsoletes=E2=80=9D the = old RFC), then is not just another BCP? If it is a new version and it = removes grant types (OAuth 3.0?) then that effectively has the same = impact as removing them from OAuth 2.0, unless we=E2=80=99re envisioning = some way for a client to negotiate version 2.0 support from an AS? =E2=80=94 Neil > On 22 Feb 2020, at 01:41, Dick Hardt wrote: >=20 > I'm a little confused on where this thread is going. If we take ROPC = out of OAuth 2.1 then: >=20 > 1) Existing deployments can keep using ROPC - why break it if it is = working. >=20 > 2) New deployments can use ROPC and be OAuth 2.0 compliant. >=20 > 3) New deployments that don't need ROPC can be OAuth 2.1 compliant From nobody Mon Feb 24 07:23:47 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597E23A0D70 for ; Mon, 24 Feb 2020 07:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tuApHC8Mgs-U for ; Mon, 24 Feb 2020 07:23:36 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C373A0D40 for ; Mon, 24 Feb 2020 07:23:36 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id a6so9837287wme.2 for ; Mon, 24 Feb 2020 07:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lIKUaeNsXJ484Z21tUnMqA5twtYvIxF52igHu1UtgQE=; b=aR6T0lAobdCT0yGszCyNNK22PNcQOTXy8dtUKmzB2yY7jzMaN6DWkGjlE9pZ+uP0H2 nAv9KnujX7PsXYSThEue6Pq5Hov19Y4LaaWgtqPyx1UJ9QXv7/fE3uf0VsXIe/daBwlG tk2by2N6tB/0000z7Xbu2UY6V8wqUr0XDRneE= 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=lIKUaeNsXJ484Z21tUnMqA5twtYvIxF52igHu1UtgQE=; b=mjyn+8Vbw8T762CtiHah3bCT3fgrulB7Sp5VaVBIH5c2C0DkrDiIRlYDskKr+zrxbP Q39gLhlmkyD9ajgM5huutaRvwhEZk8t/poO8Jcg9c54EaCuESdBCw303rjXv++01lmAm RTjJy3RPfs+KFtb71raV22ttc+hbNrIonaJNllDf3lGnRGnUyCYUCjgRJ78TgD+qlXZm lAV0Oq4n9yeANUL3SJOgn12gvhVrowZIe6oEBhExQp54sbkfdpwWRefoWWgc/t3U7N8l j1wjIJmYz1wqijPo8hX2eRODJIcQrDTzAEJGqmOVaTcP4vdQ2UE5zJYG4LjBfxi/Xe2F uliw== X-Gm-Message-State: APjAAAVBefyVmoQcod9Ad4a5xmYW/j3jrgPkwKWOdIL40oiXL/pZHNRr 7qxH4RD0bLr7n96EPOQq9Y1KntyN96zUVA== X-Google-Smtp-Source: APXvYqwkRRHQnVGAO02mQ2SELfZ8tGcSGZZbkbg5GFMagbK6JWtbv8ofByVE4a9dRTAr201vR5Ua6A== X-Received: by 2002:a1c:8095:: with SMTP id b143mr22105102wmd.7.1582557814461; Mon, 24 Feb 2020 07:23:34 -0800 (PST) Received: from zaphod.home.gateway (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id j15sm19610103wrp.9.2020.02.24.07.23.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2020 07:23:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> Date: Mon, 24 Feb 2020 15:23:32 +0000 Cc: Torsten Lodderstedt , Matthew De Haast , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21613133-5B2C-4ECB-BF5C-3F9EA3401ED8@forgerock.com> References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 15:23:46 -0000 But again, I=E2=80=99m talking about existing deployments. If you have = an existing deployment using ROPC with service accounts and you have = tens or hundreds of thousands of such accounts, this really sounds like = a lot of work to change over.=20 I forgot one of the other reasons for preferring a service account over = an OAuth 2 client - some features of OAuth/OIDC require client secrets = to be recoverable on the AS. For example, if you request an ID token = signed with HMAC in an implicit/hybrid OIDC flow then this is signed = using the client secret as the HMAC key. This prevents the AS from = hashing the client secret, so client_credentials grant introduces = security weaknesses compared to an ROPC service account flow. So you=E2=80= =99d really want to move both to client_credentials flow and a more = secure authentication mechanism - e.g. mTLS, and public key = signed/encrypted ID tokens. (NB: this is not just due to the implicit grant - e.g., CIBA backchannel = auth in push mode has the same issue if you use HMAC-signed ID tokens). =E2=80=94 Neil > On 22 Feb 2020, at 01:05, Richard Backman, Annabelle = wrote: >=20 > ROPC without a client ID or authentication is functionally equivalent = to Client Credentials grant with client secret authentication in the = request body. You've just renamed "client_id" to "username" and = "client_secret" to "password". >=20 > The AS simply needs to be able to resolve the client ID to the service = account. You could use any of the following strategies, depending on the = environment: > * Use service account identifiers as client IDs > * Use encrypted blobs containing service account identifiers as client = IDs, so someone can't choose a client ID by creating a service account = with a specific identifier > * Use opaque values that the AS can resolve to service account = identifiers, e.g., via a database lookup >=20 > If the AS needs the service account's password because it's = authenticating against a legacy system, then use the service account = password as the client secret. Stack mTLS on top, if you want. If the AS = just needs to resolve the account so it can put it in tokens that RSes = will look at, then you can use whatever client authentication mechanism = you want. >=20 > Is there a scenario I'm missing here? >=20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ >=20 >=20 > =EF=BB=BFOn 2/21/20, 1:53 PM, "Neil Madden" = wrote: >=20 > The AS doesn=E2=80=99t issue the service account IDs, that=E2=80=99s = the whole point - integration with existing systems. Lot=E2=80=99s of = people don=E2=80=99t have the luxury of rebuilding systems from scratch = to fit in with the preferences of the OAuth WG. >=20 > ROPC doesn=E2=80=99t require client authentication, or even a = client identifier. If you=E2=80=99re using a service account you indeed = don=E2=80=99t need to bother issuing client credentials. The same is = true when using the JWT bearer grant. If you want to increase security = you can use cert-bound access tokens. >=20 >> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle = wrote: >>=20 >> The client IDs can still be opaque identifiers provided by the AS, = they just happen to be associated with specific service accounts. Or = they could be the opaque IDs that the AS already issued for the service = account. Either way, the AS could issue a token with the appropriate = subject and other claims for the service account. >>=20 >> If your client identity is bound to a specific service account = identity (i.e., the resource owner), then ROPC reduces down to Client = Credentials. What's the point in passing two identifiers and two = credentials for the same identity? >>=20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >>=20 >>=20 >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" = wrote: >>=20 >> Sorry, I missed that message.=20 >>=20 >> While this may be a solution in specific circumstances, I don=E2=80=99= t think it=E2=80=99s a general solution. e.g. an AS may not allow = manually choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. >>=20 >> This is asking people to make fundamental changes to their identity = architecture rather than simply switching to a new grant type. >>=20 >> =E2=80=94 Neil >>=20 >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: >>>=20 >>> I see - we have gone full cycle :-)=20 >>>=20 >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id to = a service account and obtain the token data from there.=20 >>>=20 >>>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: >>>>=20 >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: >>>>>=20 >>>>> Have you ever tried the client credentials grant with mTLS? After = reading your description it seems to be simpler than JWT Bearer. >>>>>=20 >>>>> * work out if the AS even supports mTLS >>>>> * work out how to configure the AS to trust my cert(s) >>>>> * Create key pair and cert using openssl >>>>> * Register your (self-signed) cert along with your client_id >>>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication >>>>>=20 >>>>> Works very well for us.=20 >>>>>=20 >>>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: >>>>>>=20 >>>>>> No failures, but it is a much more complex grant type to set up, = when you consider everything you have to do: >>>>>>=20 >>>>>> * work out if the AS even supports JWT bearer and how to turn it = on >>>>>> * work out how to configure the AS to trust my public key(s) >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? >>>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >>>>>> * figure out how to distribute the private key to my service >>>>>>=20 >>>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). >>>>>>=20 >>>>>> =E2=80=94 Neil >>>>>>=20 >>>>>>=20 >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: >>>>>>>=20 >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>=20 >>>>>>> Neil could you elaborate more on this please. What failures are = you currently experiencing/seeing with the JWT Bearer grant?=20 >>>>>>>=20 >>>>>>> Matt >>>>>>>=20 >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: >>>>>>>>=20 >>>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? >>>>>>>> =E1=90=A7 >>>>>>>>=20 >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: >>>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. >>>>>>>>=20 >>>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. >>>>>>>>=20 >>>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). >>>>>>>>=20 >>>>>>>> =E2=80=94 Neil >>>>>>>>=20 >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: >>>>>>>>>=20 >>>>>>>>> Can you explain more in detail why the client credentials = grant type isn=E2=80=99t applicable for the kind of use cases you = mentioned? >>>>>>>>>=20 >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : >>>>>>>>>>=20 >>>>>>>>>> I very much agree with this with regards to real users.=20 >>>>>>>>>>=20 >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). >>>>>>>>>>=20 >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but = they are a bit harder to implement. Having recently converted some code = from ROPC to JWT bearer for exactly this use-case, it went from a couple = of lines of code to two screens of code. For service to service API = calls within a datacenter I=E2=80=99m not convinced this resulted in a = material increase in security for the added complexity. >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Neil >>>>>>>>>>=20 >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I would also seriously look at the original motivation = behind ROPC: I know it has been deployed and is used in quite a lot of = places but I have never actually come across a use case where it is used = for migration purposes and the migration is actually executed (I know = that is statistically not a very strong argument but I challenge others = to come up with one...) >>>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting = as a grace period since it currently says the password grant MUST NOT be = used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>>=20 >>>>>>>>>>> Aaron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 = can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.=20 >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>>=20 >>>>>>>>>>>> From: OAuth On Behalf Of Dick = Hardt >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password = grant >>>>>>>>>>>>=20 >>>>>>>>>>>> Hey List=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>>=20 >>>>>>>>>>>> In the security topics doc >>>>>>>>>>>>=20 >>>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 >>>>>>>>>>>>=20 >>>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>>=20 >>>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Does anyone have concerns with dropping the password grant = from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>>=20 >>>>>>>>>>>> /Dick >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> ---- >>>>>>>>>>> Aaron Parecki >>>>>>>>>>> aaronparecki.com >>>>>>>>>>> @aaronpk >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=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 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 >=20 >=20 From nobody Mon Feb 24 09:04:04 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0618F3A0E96 for ; Mon, 24 Feb 2020 09:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZaPOC08acwJ for ; Mon, 24 Feb 2020 09:03:59 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988D33A0E8E for ; Mon, 24 Feb 2020 09:03:58 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id n18so10936040ljo.7 for ; Mon, 24 Feb 2020 09:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kDEb0jYxvtkUTjzziDvtD1Kfu9u5sjVBt096Utw47N0=; b=IMx/cLpCjcm0DADoNVpf98eTT2hnAZxORjhpHA0+KUhCrtKIDBZfeUkse2rXACOU3r aMiDgxrusZs1O1PRkYGWwzbrT+45nVPpiezKdya+NNFx+84QoWTxg/FgRY7BkU0WC0at s2Pv20M/D4xIAxoh6bw6fchhfGjP/CATDKuUj350d5CejbpWc1ED+qI9bMvJEZ8ZzXQS q4xZYDAs6q7Vp14DuXmpiA98mEB4M6CWDZry21656bNj867UzmEHzmPPVz6m6yz6w7ce aQGYhaD5kp1h1q1UbR0FodZtde1p6roYJXov8QnfDFtPx5qaCCzf8t43aMAWneHIMq2S WuZw== 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=kDEb0jYxvtkUTjzziDvtD1Kfu9u5sjVBt096Utw47N0=; b=qCB6ZYw78AwsnrfWyXXoAb1JFUNsXcl9PNRmfGwQ9CDHk8vW/aix4iVYaU9OeT693u /vPtPImS0ltj8h0jyJiNn7zuRvjXimLUdNyG3zawSBiYh4qyJKHWJUIBg/mWM7HhELY/ K9aG9AkN6Q7egMyRnzUqCdFUZ6Rb3a5zV3qyrmr/h+ss5dc2NZXsE574zFDZ6JNPh+nX NJcpszBLMZ4ChrfPVSSvGuJmowZJhhUOF6lH56pnR7/SyaFCnwtItKt2It4L4tMeqmVa 41WBKrLqj/B6+7EdxD2HxvMXxtljCrk521agFHsDsSjSJN6/9BhnLiayQAgd4iHuasO8 JP8Q== X-Gm-Message-State: APjAAAUAkbIaMqR+DTUIHJqRnAvD9N415IJaUU/HdzfT3nM4XAIb91Tc Z0JmCBB9pgkFa63c6COVadnDk9gc1Ef+Ime9ehaTqFtMD89dRoBVIcprheVjvpmvxSrM8JluqQh /1D3TivNxoZUwImw0 X-Google-Smtp-Source: APXvYqx1zVo85kUCC6FeDqqGYgBPAaXgXb5qS+7Pv8Patk1O7y2KGnqxUxgJ1iwART8rco/A6b0gdScM1p/2f9/d2CA= X-Received: by 2002:a2e:3504:: with SMTP id z4mr31105084ljz.273.1582563836537; Mon, 24 Feb 2020 09:03:56 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> In-Reply-To: <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> From: Brian Campbell Date: Mon, 24 Feb 2020 10:03:29 -0700 Message-ID: To: Neil Madden Cc: Justin Richer , Matthew De Haast , "oauth@ietf.org" , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="0000000000005021a7059f555bde" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 17:04:03 -0000 --0000000000005021a7059f555bde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Concur with the sentiment expressed by Neil here. On Fri, Feb 21, 2020 at 3:32 PM Neil Madden wrote: > I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be > doing=E2=80=9D unless we have concrete security or interoperability reaso= ns for > doing so. > > I also don=E2=80=99t agree that people doing this are doing anything wron= g. I > don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve l= earnt over the > years not to second-guess their reasons for doing it. > > Are Google wrong for using the JWT bearer grant (not client credentials) > and service accounts? They even go so far as to say =E2=80=9Cscopes are n= ot a > security mechanism=E2=80=9D [1] and tell people to use service account ro= les > instead. (Precisely because they also support non-OAuth auth methods, whi= ch > bypass any scopes). > > Are we really going to tell them to rewrite it all to use the client > credentials grant? > > [1]: > https://cloud.google.com/compute/docs/access/service-accounts#accesscopes= iam > > > On 21 Feb 2020, at 21:04, Justin Richer wrote: > > > > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, an= d it=E2=80=99s > time to get rid of it and send people toward what they really ought to be > doing. > > > > Another thing I=E2=80=99ve seen is using different service accounts to = get > different sets of access for one client =E2=80=94 if you=E2=80=99re doing= that, you=E2=80=99ve got > a client pretending to do two different things, or your APIs should be > using scopes to differentiate access instead of client/user identity. > > > > =E2=80=94 Justin > > > >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> > >> The client IDs can still be opaque identifiers provided by the AS, the= y > just happen to be associated with specific service accounts. Or they coul= d > be the opaque IDs that the AS already issued for the service account. > Either way, the AS could issue a token with the appropriate subject and > other claims for the service account. > >> > >> If your client identity is bound to a specific service account identit= y > (i.e., the resource owner), then ROPC reduces down to Client Credentials. > What's the point in passing two identifiers and two credentials for the > same identity? > >> > >> =E2=80=93 > >> Annabelle Backman (she/her) > >> AWS Identity > >> https://aws.amazon.com/identity/ > >> > >> > >> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < > oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote: > >> > >> Sorry, I missed that message. > >> > >> While this may be a solution in specific circumstances, I don=E2=80= =99t think > it=E2=80=99s a general solution. e.g. an AS may not allow manually choosi= ng the > client_id to avoid things like > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4= .13 > or may return different introspection results for client credentials toke= ns > (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds ev= en more steps for > somebody to migrate from existing ROPC usage. > >> > >> This is asking people to make fundamental changes to their identity > architecture rather than simply switching to a new grant type. > >> > >> =E2=80=94 Neil > >> > >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt > wrote: > >>> > >>> I see - we have gone full cycle :-) > >>> > >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id to = a service > account and obtain the token data from there. > >>> > >>>> On 21. Feb 2020, at 15:31, Neil Madden > wrote: > >>>> > >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service account= s (!=3D > clients). Maybe it should? Should there be a mTLS *grant type*? > >>>> > >>>> =E2=80=94 Neil > >>>> > >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>>> > >>>>> Have you ever tried the client credentials grant with mTLS? After > reading your description it seems to be simpler than JWT Bearer. > >>>>> > >>>>> * work out if the AS even supports mTLS > >>>>> * work out how to configure the AS to trust my cert(s) > >>>>> * Create key pair and cert using openssl > >>>>> * Register your (self-signed) cert along with your client_id > >>>>> * Configure the HTTP client to use your key pair for TLS Client > Authentication > >>>>> > >>>>> Works very well for us. > >>>>> > >>>>>> On 21. Feb 2020, at 15:12, Neil Madden > wrote: > >>>>>> > >>>>>> No failures, but it is a much more complex grant type to set up, > when you consider everything you have to do: > >>>>>> > >>>>>> * work out if the AS even supports JWT bearer and how to turn it o= n > >>>>>> * work out how to configure the AS to trust my public key(s) > >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? > >>>>>> * determine the correct settings for issuer, audience, subject, > etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says tha= t > the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only allow= s this to be > present if your client is doing impersonation of an end-user (which > requires additional permissions). > >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do= , plain OAuth > ones might not) If I do, can I reuse the JWT or must it be freshly signed > for every call? > >>>>>> * locate and evaluate a JWT library for my language of choice. > Monitor that new dependency for security advisories. > >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) > >>>>>> * figure out how to distribute the private key to my service > >>>>>> > >>>>>> Compared to =E2=80=9Ccreate a service account and POST the usernam= e and > password to the token endpoint=E2=80=9D it adds a little friction. (It al= so adds a > lot of advantages, but it is undeniably more complex). > >>>>>> > >>>>>> =E2=80=94 Neil > >>>>>> > >>>>>> > >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast 40coil.com@dmarc.ietf.org> wrote: > >>>>>>> > >>>>>>> I have a feeling that if we had more concise JWT libraries and > command line tools, where using the JWT Bearer grant became a one-liner > again then we wouldn=E2=80=99t be having this conversation. So perhaps re= moving it > is an incentive to make that happen. > >>>>>>> > >>>>>>> Neil could you elaborate more on this please. What failures are > you currently experiencing/seeing with the JWT Bearer grant? > >>>>>>> > >>>>>>> Matt > >>>>>>> > >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>>>> I have a feeling that if we had more concise JWT libraries and > command line tools, where using the JWT Bearer grant became a one-liner > again then we wouldn=E2=80=99t be having this conversation. So perhaps re= moving it > is an incentive to make that happen. > >>>>>>> > >>>>>>> > >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt > wrote: > >>>>>>>> > >>>>>>>> Neil: are you advocating that password grant be preserved in 2.1= ? > Or do you think that service account developers know enough about what th= ey > are doing to follow what is in 6749? > >>>>>>>> =E1=90=A7 > >>>>>>>> > >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>>>>> OAuth2 clients are often private to the AS - they live in a > database that only the AS can access, have attributes specific to their u= se > in OAuth2, and so on. Many existing systems have access controls based on > users, roles, permissions and so on and expect all users accessing the > system to exist in some user repository, e.g. LDAP, where they can be > looked up and appropriate permissions determined. A service account can b= e > created inside such a system as if it was a regular user, managed through > the normal account provisioning tools, assigned permissions, roles, etc. > >>>>>>>> > >>>>>>>> Another reason is that sometimes OAuth is just one authenticatio= n > option out of many, and so permissions assigned to service accounts are > preferred over scopes because they are consistently applied no matter how= a > request is authenticated. This is often the case when OAuth has been > retrofitted to an existing system and they need to preserve compatibility > with already deployed clients. > >>>>>>>> > >>>>>>>> See e.g. Google cloud platform (GCP): > https://developers.google.com/identity/protocols/OAuth2ServiceAccount > >>>>>>>> They use the JWT bearer grant type for service account > authentication and assign permissions to those service accounts and > typically have very broad scopes. For service-to-service API calls you > typically get an access token with a single scope that is effectively =E2= =80=9Call > of GCP=E2=80=9D and everything is managed at the level of permissions on = the RO > service account itself. They only break down fine-grained scopes when you > are dealing with user data and will be getting an access token approved b= y > a real user (through a normal auth code flow). > >>>>>>>> > >>>>>>>> =E2=80=94 Neil > >>>>>>>> > >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>>>>>>> > >>>>>>>>> Can you explain more in detail why the client credentials grant > type isn=E2=80=99t applicable for the kind of use cases you mentioned? > >>>>>>>>> > >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden < > neil.madden@forgerock.com>: > >>>>>>>>>> > >>>>>>>>>> I very much agree with this with regards to real users. > >>>>>>>>>> > >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for = service > accounts - where you essentially want something like client_credentials b= ut > for whatever reason you need the RO to be a service user rather than an > OAuth2 client (typically so that some lower layer of the system can still > perform its required permission checks). > >>>>>>>>>> > >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but > they are a bit harder to implement. Having recently converted some code > from ROPC to JWT bearer for exactly this use-case, it went from a couple = of > lines of code to two screens of code. For service to service API calls > within a datacenter I=E2=80=99m not convinced this resulted in a material= increase > in security for the added complexity. > >>>>>>>>>> > >>>>>>>>>> =E2=80=94 Neil > >>>>>>>>>> > >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt < > hans.zandbelt@zmartzone.eu> wrote: > >>>>>>>>>>> > >>>>>>>>>>> I would also seriously look at the original motivation behind > ROPC: I know it has been deployed and is used in quite a lot of places bu= t > I have never actually come across a use case where it is used for migrati= on > purposes and the migration is actually executed (I know that is > statistically not a very strong argument but I challenge others to come u= p > with one...) > >>>>>>>>>>> In reality it turned out just to be a one off that people use= d > as an easy way out to stick to an anti-pattern and still claim to do OAut= h > 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. > >>>>>>>>>>> > >>>>>>>>>>> Hans. > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki < > aaron@parecki.com> wrote: > >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting > as a grace period since it currently says the password grant MUST NOT be > used, so in the OAuth 2.0 world that's already a pretty strong signal.. > >>>>>>>>>>> > >>>>>>>>>>> Aaron > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer > wrote: > >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 > can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. > >>>>>>>>>>> > >>>>>>>>>>> =E2=80=94 Justin > >>>>>>>>>>> > >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are stil= l > sites using this and a grace period should be provided before a MUST is > pushed out as there are valid use cases out there still. > >>>>>>>>>>>> > >>>>>>>>>>>> From: OAuth On Behalf Of Dick Hardt > >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM > >>>>>>>>>>>> To: oauth@ietf.org > >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password > grant > >>>>>>>>>>>> > >>>>>>>>>>>> Hey List > >>>>>>>>>>>> > >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for th= e > doc that Aaron, Torsten, and I are working on) > >>>>>>>>>>>> > >>>>>>>>>>>> In the security topics doc > >>>>>>>>>>>> > >>>>>>>>>>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > >>>>>>>>>>>> > >>>>>>>>>>>> The password grant MUST not be used. > >>>>>>>>>>>> > >>>>>>>>>>>> Some background for those interested. I added this grant int= o > OAuth 2.0 to allow applications that had been provided password to migrat= e. > Even with the caveats in OAuth 2.0, implementors decide they want to prom= pt > the user to enter their credentials, the anti-pattern OAuth was created t= o > eliminate. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Does anyone have concerns with dropping the password grant > from the OAuth 2.1 document so that developers don't use it? > >>>>>>>>>>>> > >>>>>>>>>>>> /Dick > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> OAuth mailing list > >>>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> OAuth mailing list > >>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>>> -- > >>>>>>>>>>> ---- > >>>>>>>>>>> Aaron Parecki > >>>>>>>>>>> aaronparecki.com > >>>>>>>>>>> @aaronpk > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> OAuth mailing list > >>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> hans.zandbelt@zmartzone.eu > >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> OAuth mailing list > >>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> OAuth mailing list > >>>>>>>>>> OAuth@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000005021a7059f555bde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Concur with the sentiment expressed by Neil here.

On F= ri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote:
I=E2=80=99m not really sure the WG s= hould be telling people what they =E2=80=9Cought to be doing=E2=80=9D unles= s we have concrete security or interoperability reasons for doing so.

I also don=E2=80=99t agree that people doing this are doing anything wrong.= I don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve = learnt over the years not to second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) an= d service accounts? They even go so far as to say =E2=80=9Cscopes are not a= security mechanism=E2=80=9D [1] and tell people to use service account rol= es instead. (Precisely because they also support non-OAuth auth methods, wh= ich bypass any scopes).

Are we really going to tell them to rewrite it all to use the client creden= tials grant?

[1]: https://cloud.googl= e.com/compute/docs/access/service-accounts#accesscopesiam

> On 21 Feb 2020, at 21:04, Justin Richer <jricher@mit.edu> wrote:
>
> +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, a= nd it=E2=80=99s time to get rid of it and send people toward what they real= ly ought to be doing.
>
> Another thing I=E2=80=99ve seen is using different service accounts to= get different sets of access for one client =E2=80=94 if you=E2=80=99re do= ing that, you=E2=80=99ve got a client pretending to do two different things= , or your APIs should be using scopes to differentiate access instead of cl= ient/user identity.
>
> =E2=80=94 Justin
>
>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle <richan= na=3D40ama= zon.com@dmarc.ietf.org> wrote:
>>
>> The client IDs can still be opaque identifiers provided by the AS,= they just happen to be associated with specific service accounts. Or they = could be the opaque IDs that the AS already issued for the service account.= Either way, the AS could issue a token with the appropriate subject and ot= her claims for the service account.
>>
>> If your client identity is bound to a specific service account ide= ntity (i.e., the resource owner), then ROPC reduces down to Client Credenti= als. What's the point in passing two identifiers and two credentials fo= r the same identity?
>>
>> =E2=80=93
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>>
>>
>> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden= " <oaut= h-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote:
>>
>>=C2=A0 =C2=A0Sorry, I missed that message.
>>
>>=C2=A0 =C2=A0While this may be a solution in specific circumstances= , I don=E2=80=99t think it=E2=80=99s a general solution. e.g. an AS may not= allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-= oauth-security-topics-14#section-4.13 or may return different introspec= tion results for client credentials tokens (e.g. with no =E2=80=9Csub=E2=80= =9D) and so on. In practice, this adds even more steps for somebody to migr= ate from existing ROPC usage.
>>
>>=C2=A0 =C2=A0This is asking people to make fundamental changes to t= heir identity architecture rather than simply switching to a new grant type= .
>>
>>=C2=A0 =C2=A0=E2=80=94 Neil
>>
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>
>>> I see - we have gone full cycle :-)
>>>
>>> Annabelle=E2=80=99s proposal would solve that. Relate a client= id to a service account and obtain the token data from there.
>>>
>>>> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>
>>>> Yes, that is great. But mTLS doesn=E2=80=99t support servi= ce accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*?
>>>>
>>>> =E2=80=94 Neil
>>>>
>>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <torsten@loddersted= t.net> wrote:
>>>>>
>>>>> Have you ever tried the client credentials grant with = mTLS? After reading your description it seems to be simpler than JWT Bearer= .
>>>>>
>>>>> * work out if the AS even supports mTLS
>>>>> * work out how to configure the AS to trust my cert(s)=
>>>>> * Create key pair and cert using openssl
>>>>> * Register your (self-signed) cert along with your cli= ent_id
>>>>> * Configure the HTTP client to use your key pair for T= LS Client Authentication
>>>>>
>>>>> Works very well for us.
>>>>>
>>>>>> On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forgero= ck.com> wrote:
>>>>>>
>>>>>> No failures, but it is a much more complex grant t= ype to set up, when you consider everything you have to do:
>>>>>>
>>>>>> * work out if the AS even supports JWT bearer and = how to turn it on
>>>>>> * work out how to configure the AS to trust my pub= lic key(s)
>>>>>> - do I have to create a new HTTPS endpoint to publ= ish a JWK Set?
>>>>>> * determine the correct settings for issuer, audie= nce, subject, etc. Does the AS impose non-standard requirements? e.g. RFC 7= 523 says that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Googl= e only allows this to be present if your client is doing impersonation of a= n end-user (which requires additional permissions).
>>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? = (OIDC servers do, plain OAuth ones might not) If I do, can I reuse the JWT = or must it be freshly signed for every call?
>>>>>> * locate and evaluate a JWT library for my languag= e of choice. Monitor that new dependency for security advisories.
>>>>>> * choose a suitable signature algorithm (=E2=80=98= ere be dragons)
>>>>>> * figure out how to distribute the private key to = my service
>>>>>>
>>>>>> Compared to =E2=80=9Ccreate a service account and = POST the username and password to the token endpoint=E2=80=9D it adds a lit= tle friction. (It also adds a lot of advantages, but it is undeniably more = complex).
>>>>>>
>>>>>> =E2=80=94 Neil
>>>>>>
>>>>>>
>>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast <= ;matt=3D40co= il.com@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>> I have a feeling that if we had more concise J= WT libraries and command line tools, where using the JWT Bearer grant becam= e a one-liner again then we wouldn=E2=80=99t be having this conversation. S= o perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>> Neil could you elaborate more on this please. = What failures are you currently experiencing/seeing with the JWT Bearer gra= nt?
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden &= lt;neil.madd= en@forgerock.com> wrote:
>>>>>>> I have a feeling that if we had more concise J= WT libraries and command line tools, where using the JWT Bearer grant becam= e a one-liner again then we wouldn=E2=80=99t be having this conversation. S= o perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>>
>>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:
>>>>>>>>
>>>>>>>> Neil: are you advocating that password gra= nt be preserved in 2.1? Or do you think that service account developers kno= w enough about what they are doing to follow what is in 6749?
>>>>>>>> =E1=90=A7
>>>>>>>>
>>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madde= n <neil.m= adden@forgerock.com> wrote:
>>>>>>>> OAuth2 clients are often private to the AS= - they live in a database that only the AS can access, have attributes spe= cific to their use in OAuth2, and so on. Many existing systems have access = controls based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where the= y can be looked up and appropriate permissions determined. A service accoun= t can be created inside such a system as if it was a regular user, managed = through the normal account provisioning tools, assigned permissions, roles,= etc.
>>>>>>>>
>>>>>>>> Another reason is that sometimes OAuth is = just one authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently ap= plied no matter how a request is authenticated. This is often the case when= OAuth has been retrofitted to an existing system and they need to preserve= compatibility with already deployed clients.
>>>>>>>>
>>>>>>>> See e.g. Google cloud platform (GCP): https://developers.google.com/ident= ity/protocols/OAuth2ServiceAccount
>>>>>>>> They use the JWT bearer grant type for ser= vice account authentication and assign permissions to those service account= s and typically have very broad scopes. For service-to-service API calls yo= u typically get an access token with a single scope that is effectively =E2= =80=9Call of GCP=E2=80=9D and everything is managed at the level of permiss= ions on the RO service account itself. They only break down fine-grained sc= opes when you are dealing with user data and will be getting an access toke= n approved by a real user (through a normal auth code flow).
>>>>>>>>
>>>>>>>> =E2=80=94 Neil
>>>>>>>>
>>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodd= erstedt <to= rsten@lodderstedt.net> wrote:
>>>>>>>>>
>>>>>>>>> Can you explain more in detail why the= client credentials grant type isn=E2=80=99t applicable for the kind of use= cases you mentioned?
>>>>>>>>>
>>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Nei= l Madden <neil.madden@forgerock.com>:
>>>>>>>>>>
>>>>>>>>>> I very much agree with this with r= egards to real users.
>>>>>>>>>>
>>>>>>>>>> The one legitimate use-case for RO= PC I=E2=80=99ve seen is for service accounts - where you essentially want s= omething like client_credentials but for whatever reason you need the RO to= be a service user rather than an OAuth2 client (typically so that some low= er layer of the system can still perform its required permission checks). >>>>>>>>>>
>>>>>>>>>> There are better grant types for t= his - e.g. JWT bearer - but they are a bit harder to implement. Having rece= ntly converted some code from ROPC to JWT bearer for exactly this use-case,= it went from a couple of lines of code to two screens of code. For service= to service API calls within a datacenter I=E2=80=99m not convinced this re= sulted in a material increase in security for the added complexity.
>>>>>>>>>>
>>>>>>>>>> =E2=80=94 Neil
>>>>>>>>>>
>>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans= Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would also seriously look at= the original motivation behind ROPC: I know it has been deployed and is us= ed in quite a lot of places but I have never actually come across a use cas= e where it is used for migration purposes and the migration is actually exe= cuted (I know that is statistically not a very strong argument but I challe= nge others to come up with one...)
>>>>>>>>>>> In reality it turned out just = to be a one off that people used as an easy way out to stick to an anti-pat= tern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth an= d we need to get rid of it.
>>>>>>>>>>>
>>>>>>>>>>> Hans.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 = PM Aaron Parecki <aaron@parecki.com> wrote:
>>>>>>>>>>> Agreed. Plus, the Security BCP= is already effectively acting as a grace period since it currently says th= e password grant MUST NOT be used, so in the OAuth 2.0 world that's alr= eady a pretty strong signal..
>>>>>>>>>>>
>>>>>>>>>>> Aaron
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 P= M Justin Richer <jr= icher@mit.edu> wrote:
>>>>>>>>>>> There is no need for a grace p= eriod. People using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2= .1 will do OAuth 2.1.
>>>>>>>>>>>
>>>>>>>>>>> =E2=80=94 Justin
>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 18, 2020, at 3:= 54 PM, Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:=
>>>>>>>>>>>>
>>>>>>>>>>>> I would suggest a SHOULD N= OT instead of MUST, there are still sites using this and a grace period sho= uld be provided before a MUST is pushed out as there are valid use cases ou= t there still.
>>>>>>>>>>>>
>>>>>>>>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
>>>>>>>>>>>> Sent: Tuesday, February 18= , 2020 12:37 PM
>>>>>>>>>>>> To: oauth@ietf.org
>>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH= -WG] OAuth 2.1: dropping password grant
>>>>>>>>>>>>
>>>>>>>>>>>> Hey List
>>>>>>>>>>>>
>>>>>>>>>>>> (Once again using the OAut= h 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are work= ing on)
>>>>>>>>>>>>
>>>>>>>>>>>> In the security topics doc=
>>>>>>>>>>>>
>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-securi= ty-topics-14#section-2.4
>>>>>>>>>>>>
>>>>>>>>>>>> The password grant MUST no= t be used.
>>>>>>>>>>>>
>>>>>>>>>>>> Some background for those = interested. I added this grant into OAuth 2.0 to allow applications that ha= d been provided password to migrate. Even with the caveats in OAuth 2.0, im= plementors decide they want to prompt the user to enter their credentials, = the anti-pattern OAuth was created to eliminate.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone have concerns = with dropping the password grant from the OAuth 2.1 document so that develo= pers don't use it?
>>>>>>>>>>>>
>>>>>>>>>>>> /Dick
>>>>>>>>>>>> __________________________= _____________________
>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>> https://= www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>> --
>>>>>>>>>>> ----
>>>>>>>>>>> Aaron Parecki
>>>>>>>>>>> aaronparecki.com
>>>>>>>>>>> @aaronpk
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu=
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf= .org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mai= lman/listinfo/oauth
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>
>>>>>> _______________________________________________ >>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>>
>>>>
>>>
>>
>>=C2=A0 =C2=A0_______________________________________________
>>=C2=A0 =C2=A0OAuth mailing list
>>=C2=A0 =C2=A0OA= uth@ietf.org
>>=C2=A0 =C2=A0https://www.ietf.org/mailman/listinf= o/oauth
>>
>>
>> _______________________________________________
>> 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

<= 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. --0000000000005021a7059f555bde-- From nobody Mon Feb 24 10:50:57 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364F13A0ABF for ; Mon, 24 Feb 2020 10:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeDrmRMSqIAN for ; Mon, 24 Feb 2020 10:50:54 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824213A10F6 for ; Mon, 24 Feb 2020 10:50:54 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id c16so9970174oic.3 for ; Mon, 24 Feb 2020 10:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8y31/VpBt7+cTZkCeNhHUfzZ80M8vXTaOniY+WloKaY=; b=bc6/nNuY87UpBo5EYO2dTTjyxg1+Zx2YlUyg3DjxZSTGRsA1KK1yOJNVyF6xUN1UA9 FcDlKdMPoBa7w5+A1rZ2idzPtIGPTiL3VQbzrORWmUxk6xk62lixJ26yMkXIAHJTX5Fm tPYMIe859icJJirUHXEfRd+pnR+b8DG0UcTV474s+B/DNGecNayX69XyrPL0mcJqpYJM CB5AeCPvSQX2ah4ZsoknzwlWJf0PI1C6+l2MoTn4uDT/maBreHYPj8DmDh0FXgaJe9J0 72jKwnGPuCc7ZpiCxXk1OyYRFNet0N/cPl4ql3bUX4yeVBiDhu8xI/NSk1lx1ByQ9ezX k/yg== 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=8y31/VpBt7+cTZkCeNhHUfzZ80M8vXTaOniY+WloKaY=; b=e2K8ajE8ygh/U09FlkyFeYy39INbSXBjY3561MA8s9mNo7W/p4f9SfO3R9+W/OdOie 4tin3DAMfqO63JlSfo1wcwcdMa2OId6Y+d54S3SlU632GA8Yj31PSyYsoH2gh2QtIt6u OmWi/H4tO/O6Ripm4lB9sQHo4DFKP2fu1ORjlrzf0WzANevb4naRi/oYFLT0/mi8aec7 7HPXWhBnx7e9QaYgNJPkAW0b1WduuvIWiezVdzRiuTHnmzLw9Z5Yim1at3kbP1eufOx4 +J8IUM0QWPJYThc0jjNSOPU8b9TZcR/6M0Xdcytxb37+kbwlNGtxbjJkpLvqVJcOI6ci 1rSQ== X-Gm-Message-State: APjAAAV15fJHQFFl0rJApeIkGFyilRd2kxbph3A+Rg5IS6KHz8o7ZqqH cHSSs5nVfI6cDdFA6do7j8LCUv0v3uEKQMEGZpsThA== X-Google-Smtp-Source: APXvYqzoYs3s2UmKXYrCyu1ZgBqgybX5Xk76iiWIt+Aymz20z3kCEd+IRoeWsDTfH/s5rMYxO+FV3blb1wWOyyMnnRQ= X-Received: by 2002:aca:45c1:: with SMTP id s184mr390911oia.158.1582570253259; Mon, 24 Feb 2020 10:50:53 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> In-Reply-To: From: William Denniss Date: Mon, 24 Feb 2020 10:50:38 -0800 Message-ID: To: Neil Madden Cc: Dick Hardt , Matthew De Haast , "oauth@ietf.org" , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="000000000000c7905f059f56d989" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 18:50:56 -0000 --000000000000c7905f059f56d989 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to drop ROPC from the Security BCP, as it is not the best current practice. Speaking generally, the argument that people are currently using it and will need to change, therefore we shouldn't deprecate anything is actually antithetical to the goals of a BCP. As has been pointed out, they can ignore the BCP should they wish and keep doing what they are doing. Really the question should be: is this the right way to do this? I believe the answer to that is "no", particularly when reading the original text in RFC 6749 Section 1.3.3 that we're essentially striking out here. If people are doing different things with this grant type, then that's probably worthy of it's own grant type. As you wrote earlier Niel "There are better grant types for this - e.g. JWT bearer - but they are a bit harder to implement.". Perhaps we can document the better practice for this use-case to help point people using ROPC for this in the right direction. Regarding the "harder to implement" concern, I also don't think that's a reason for not deprecating. When I wrote RFC 8252 everyone was doing native app authorization in web views, and would need to change what they were doing to adopt the BCP which was actually a lot of work (but, for the reasons documented, it was really important to change). This was actually why I wrote that BCP... to justify and help drive that necessary change. On Mon, Feb 24, 2020 at 6:49 AM Neil Madden wrote: > Well, kinda. People can still theoretically use OAuth 1 too, but the worl= d > has moved on - software has dropped support for it, websites don=E2=80=99= t support > it, and so on. > > I=E2=80=99m a bit confused about what OAuth 2.1 is intended to be. If it= =E2=80=99s not a > new version of OAuth (=E2=80=9Cobsoletes=E2=80=9D the old RFC), then is n= ot just another > BCP? If it is a new version and it removes grant types (OAuth 3.0?) then > that effectively has the same impact as removing them from OAuth 2.0, > unless we=E2=80=99re envisioning some way for a client to negotiate versi= on 2.0 > support from an AS? > > =E2=80=94 Neil > > > On 22 Feb 2020, at 01:41, Dick Hardt wrote: > > > > I'm a little confused on where this thread is going. If we take ROPC ou= t > of OAuth 2.1 then: > > > > 1) Existing deployments can keep using ROPC - why break it if it is > working. > > > > 2) New deployments can use ROPC and be OAuth 2.0 compliant. > > > > 3) New deployments that don't need ROPC can be OAuth 2.1 compliant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000c7905f059f56d989 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to drop ROPC from the Security BCP, as it is not t= he best current practice.

Speaking generally, the = argument that people are currently using it and will need to change, theref= ore we shouldn't deprecate anything is actually antithetical to the goa= ls of a BCP. As has been pointed out, they can ignore the BCP should they w= ish and keep doing what they are doing. Really the question should be: is t= his the right way to do this? I believe the answer to that is "no"= ;, particularly when reading the original text in RFC 6749 Section 1.3.3 th= at we're essentially striking out here. If people are doing different t= hings with this grant type, then that's probably worthy of it's own= grant type.

As you wrote earlier Niel "There= are better grant types for this - e.g. JWT bearer - but they are a bit har= der to implement.". Perhaps we can document the better practice for th= is use-case to help point people using ROPC for this in the right direction= . Regarding the "harder to implement" concern, I also don't t= hink that's a reason for not deprecating. When I wrote RFC 8252 everyon= e was doing native app authorization in web views, and would need to change= what they were doing to adopt the BCP which was actually a lot of work (bu= t, for the reasons documented, it was really important to change). This was= actually why I wrote that BCP... to justify and help drive that necessary = change.

On Mon, Feb 24, 2020 at 6:49 AM Neil Madde= n <neil.m= adden@forgerock.com> wrote:
Well, kinda. People can still= theoretically use OAuth 1 too, but the world has moved on - software has d= ropped support for it, websites don=E2=80=99t support it, and so on.

I=E2=80=99m a bit confused about what OAuth 2.1 is intended to be. If it=E2= =80=99s not a new version of OAuth (=E2=80=9Cobsoletes=E2=80=9D the old RFC= ), then is not just another BCP? If it is a new version and it removes gran= t types (OAuth 3.0?) then that effectively has the same impact as removing = them from OAuth 2.0, unless we=E2=80=99re envisioning some way for a client= to negotiate version 2.0 support from an AS?

=E2=80=94 Neil

> On 22 Feb 2020, at 01:41, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> I'm a little confused on where this thread is going. If we take RO= PC out of OAuth 2.1 then:
>
> 1) Existing deployments can keep using ROPC - why break it if it is wo= rking.
>
> 2) New deployments can use ROPC and be OAuth 2.0 compliant.
>
> 3) New deployments that don't need ROPC can be OAuth 2.1 compliant=

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c7905f059f56d989-- From nobody Mon Feb 24 11:00:39 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAEA3A1124 for ; Mon, 24 Feb 2020 11:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rLV9HqiZSI5 for ; Mon, 24 Feb 2020 11:00:34 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E5E3A1126 for ; Mon, 24 Feb 2020 11:00:34 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id 77so9721930oty.6 for ; Mon, 24 Feb 2020 11:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iwITUu1pwNIA+5azy03hfGElgAuUYPWGfWt3vTX1aJY=; b=G4P2UvpeKbuRtHWiSkPBd7cA1sIrqA8rFN0ry7GZzVQ60loN9uctpB8GE4mWigRvGh kjS3VsPIGguwmo7QhKpyDUQ2DX5nlPOD+Semm39cTTpQvHwu6EZfu92shH84voUGux19 E0kZ1c/YhmcluPjdlDtLr+5aQJkfUkkwshaw2LoTfFd4brnjNdI+TfwFq7Kq9ZspnNNj m+0oDCxX1up/DSx29WIGRyflpa7F9O7l8OQbpM15UZ/XnNHKaaFzYIqHxb2LlBHv+riX bJGvMkHG6D9cB/Efwe8YStDgwomHn8KVdrSMiPRQwCrqDjXwlH6Y/LF4lpvXc6ylOz3+ KuuQ== 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=iwITUu1pwNIA+5azy03hfGElgAuUYPWGfWt3vTX1aJY=; b=SDa98UEKbb+3nBgsD2sQRv31mnEQzcAZ6TRlyCwUG8nUXiJgUyxrcCFSQ2kiNhFHZl 3RLounRzv0BmX9dUwqsM4xM1z+eDjyuZl+OujTew+yj29AblpaHbUYhY5Gs7W38/Shm0 r0Cv4g+/Dv0kbrZABCkJo2y8nr7Kp0/uPVmjqSTeYCUvB1XV4pLKW7DuxcNd+PoZqkkq 3I4CzKLwZ4F1F1bEF3LeE8G5lPQLeIkuUmXQwpr5fCg1XM5TNSJjWCS0og+/Qwogpnk9 iwspuNOP7Su3mGJNaObP0fP0v+sTVr5LmR6h8KyDvpCtfLMNseQUh+kmXDTwrMEoW4o3 LnFQ== X-Gm-Message-State: APjAAAU0139w3x9uS1M96Ow8yfr1R/JNmzoWaSA3BruoAmvABKl3rGZI 5qSyAEzf0/boCtt7Nk3JRQfwg1Q39tY+E0ano6xMCg== X-Google-Smtp-Source: APXvYqxaYi34l4z65VNATV38cwyezft9rGbOa8CJVqrBHaUEc5ZUZj3rSy6bc35dVMWd2dRIXsgG7mnXxRPHf22pgEc= X-Received: by 2002:a9d:116:: with SMTP id 22mr17574738otu.149.1582570832996; Mon, 24 Feb 2020 11:00:32 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com> In-Reply-To: From: William Denniss Date: Mon, 24 Feb 2020 11:00:21 -0800 Message-ID: To: Neil Madden Cc: Dick Hardt , Matthew De Haast , "oauth@ietf.org" , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="000000000000558beb059f56fc30" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 19:00:38 -0000 --000000000000558beb059f56fc30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 24, 2020 at 6:49 AM Neil Madden wrote: > Well, kinda. People can still theoretically use OAuth 1 too, but the worl= d > has moved on - software has dropped support for it, websites don=E2=80=99= t support > it, and so on > I=E2=80=99m a bit confused about what OAuth 2.1 is intended to be. If it= =E2=80=99s not a > new version of OAuth (=E2=80=9Cobsoletes=E2=80=9D the old RFC), then is n= ot just another > BCP? If it is a new version and it removes grant types (OAuth 3.0?) then that effectively has the same impact as removing them from OAuth 2.0, > unless we=E2=80=99re envisioning some way for a client to negotiate versi= on 2.0 > support from an AS? > Many implementations don't support the "password" grant today (and in fact, never supported it), so it's not like you can rely on its presence for interop. If the client needs to negotiate which grant types it can use, then RFC 8414 provides this today with the "grant_types_supported" key. William > > =E2=80=94 Neil > > > On 22 Feb 2020, at 01:41, Dick Hardt wrote: > > > > I'm a little confused on where this thread is going. If we take ROPC ou= t > of OAuth 2.1 then: > > > > 1) Existing deployments can keep using ROPC - why break it if it is > working. > > > > 2) New deployments can use ROPC and be OAuth 2.0 compliant. > > > > 3) New deployments that don't need ROPC can be OAuth 2.1 compliant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000558beb059f56fc30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Feb 24, 2020 at 6:49 AM Neil Madd= en <neil.madden@forgerock.c= om> wrote:
I=E2=80=99m a bit confused about what OAuth 2.1 is intended to be. If it=E2= =80=99s not a new version of OAuth (=E2=80=9Cobsoletes=E2=80=9D the old RFC= ), then is not just another BCP? If it is a new version and it removes gran= t types (OAuth 3.0?)

then that effectively has the same impact as removi= ng them from OAuth 2.0, unless we=E2=80=99re envisioning some way for a cli= ent to negotiate version 2.0 support from an AS?

<= /div>
Many implementations don't support the "password&qu= ot; grant today (and in fact, never supported it), so it's not like you= can rely on its presence for interop.

If the client needs to negotiate which grant types it can use, then R= FC 8414 provides this today with the "grant_types_supported" key.=

William

=C2=A0

=E2=80=94 Neil

> On 22 Feb 2020, at 01:41, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> I'm a little confused on where this thread is going. If we take RO= PC out of OAuth 2.1 then:
>
> 1) Existing deployments can keep using ROPC - why break it if it is wo= rking.
>
> 2) New deployments can use ROPC and be OAuth 2.0 compliant.
>
> 3) New deployments that don't need ROPC can be OAuth 2.1 compliant=

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000558beb059f56fc30-- From nobody Mon Feb 24 16:14:05 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3923A1613 for ; Mon, 24 Feb 2020 16:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ua05jFzDexMA for ; Mon, 24 Feb 2020 16:13:59 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AEC3A1614 for ; Mon, 24 Feb 2020 16:13:59 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id x1so12233705iop.7 for ; Mon, 24 Feb 2020 16:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qlg7kPT5uQhNXUxxty/X09XVUwaAw+XWl2vnjc9ztQ0=; b=CelH2OjHlofFv3bdNEBXXrltLC2K62YKUIESE509mca6aAttxH/rbLt/3Q8pFtrf2V ++BbTiDNWkpzlJEuqMfH7J1Qtqhsotb1TyCz1MSUDNXE/3GsIs2mlMOeoPLuRhqvaPOH CjV7h6057Mdgl/e+RuwGO+bcBhk4q09oPOU9el8vFncImq9lPDknjhpoJI6AlEIfTxd1 4Lq6Epq1Dls5yHnmHgePNsjFhDGm1kgznduaPYTYPy1boJLOzjf/CFHrkcepISnM72FT KnGcCAXSGTgrZ6rLoYow454R9y7JiXlNu3Ogmgp6xCMToQ3A8HnFcphnoWG++Cvjd+HW o6/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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qlg7kPT5uQhNXUxxty/X09XVUwaAw+XWl2vnjc9ztQ0=; b=qoV+9PokDwwc/jBsv8bYzl/O4aNHiAXkuOiIvEH0A5Q5mTu/KfZw+7YX/zeq4XrykX cTiLBQ1119db5F7XjKROq4AQcyDPaO0QRjdMxqHbWyIFykhE/mBDHZOJdWn8ZhDa+HZK YSgqS1nWzpx/QKY+EhlPQ5StxA7RFazv7I8UGcp0f+Z/53R1kPgUWm78Bimec1cFFZnm ngvsxZS9dpbmbkoKx+VkrqNDXHdFyG8Nz1zxnQic7J8zOilToRfO3W29UPdc3B0t8RKk euAfJRZThEcqN3etlVb3mdt3/N/gyvgsDyHbQMbaILZbQt9/dzqDQF443b9gUOZzh7lV W2/A== X-Gm-Message-State: APjAAAUyEUzJwoQEf4X1dAm1RPRu3RWQ+xQLN6bkfoCdj7tzvcDnE8kt BDKMiezsg/yWw/CG73q1W5QsH78nkfU= X-Google-Smtp-Source: APXvYqzsSfjFA2rwGST/HYyntG57DCBldlnmgsHrz+cnDP3k+7olEJFoZRErpL2abhoMa+PLILpipQ== X-Received: by 2002:a05:6602:2431:: with SMTP id g17mr54568597iob.106.1582589637532; Mon, 24 Feb 2020 16:13:57 -0800 (PST) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com. [209.85.166.174]) by smtp.gmail.com with ESMTPSA id w15sm3365203iow.61.2020.02.24.16.13.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Feb 2020 16:13:55 -0800 (PST) Received: by mail-il1-f174.google.com with SMTP id l4so77984ilj.1 for ; Mon, 24 Feb 2020 16:13:55 -0800 (PST) X-Received: by 2002:a92:d183:: with SMTP id z3mr62219662ilz.214.1582589635497; Mon, 24 Feb 2020 16:13:55 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> In-Reply-To: From: Aaron Parecki Date: Mon, 24 Feb 2020 16:13:42 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Brian Campbell Cc: Neil Madden , Matthew De Haast , "oauth@ietf.org" , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="0000000000000c9629059f5b5d3b" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 00:14:03 -0000 --0000000000000c9629059f5b5d3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we might be going about this discussion the wrong way. On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell wrote: > Concur with the sentiment expressed by Neil here. > > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden > wrote: > >> I=E2=80=99m not really sure the WG should be telling people what they = =E2=80=9Cought to >> be doing=E2=80=9D unless we have concrete security or interoperability r= easons for >> doing so. > > I 100% agree that the job of a standard is not to tell people "what they ought to be doing". Instead, a standard is more about documenting the current state of the art as deployed in existing implementations. With that in mind, I think that leaves us with two concrete problems with the password grant: 1) The actual problem with the password grant is end users entering passwords in applications, which the group (mostly) agrees on 2) People are re-appropriating the password grant for things like service accounts or backends that are inflexible, not actually using it for end user credentials So it seems like there's actually something missing from OAuth which is leading people to find the password grant and use that because it's the only thing that most closely fits their existing model. It seems like we'd be better off defining a new extension that captures the use case people are actually doing, instead of encouraging the continuing use of the password grant for this purpose. ---- Aaron Parecki aaronparecki.com @aaronpk On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell wrote: > Concur with the sentiment expressed by Neil here. > > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden > wrote: > >> I=E2=80=99m not really sure the WG should be telling people what they = =E2=80=9Cought to >> be doing=E2=80=9D unless we have concrete security or interoperability r= easons for >> doing so. >> >> I also don=E2=80=99t agree that people doing this are doing anything wro= ng. I >> don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve = learnt over the >> years not to second-guess their reasons for doing it. >> >> Are Google wrong for using the JWT bearer grant (not client credentials) >> and service accounts? They even go so far as to say =E2=80=9Cscopes are = not a >> security mechanism=E2=80=9D [1] and tell people to use service account r= oles >> instead. (Precisely because they also support non-OAuth auth methods, wh= ich >> bypass any scopes). >> >> Are we really going to tell them to rewrite it all to use the client >> credentials grant? >> >> [1]: >> https://cloud.google.com/compute/docs/access/service-accounts#accesscope= siam >> >> > On 21 Feb 2020, at 21:04, Justin Richer wrote: >> > >> > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, a= nd it=E2=80=99s >> time to get rid of it and send people toward what they really ought to b= e >> doing. >> > >> > Another thing I=E2=80=99ve seen is using different service accounts to= get >> different sets of access for one client =E2=80=94 if you=E2=80=99re doin= g that, you=E2=80=99ve got >> a client pretending to do two different things, or your APIs should be >> using scopes to differentiate access instead of client/user identity. >> > >> > =E2=80=94 Justin >> > >> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote: >> >> >> >> The client IDs can still be opaque identifiers provided by the AS, >> they just happen to be associated with specific service accounts. Or the= y >> could be the opaque IDs that the AS already issued for the service accou= nt. >> Either way, the AS could issue a token with the appropriate subject and >> other claims for the service account. >> >> >> >> If your client identity is bound to a specific service account >> identity (i.e., the resource owner), then ROPC reduces down to Client >> Credentials. What's the point in passing two identifiers and two >> credentials for the same identity? >> >> >> >> =E2=80=93 >> >> Annabelle Backman (she/her) >> >> AWS Identity >> >> https://aws.amazon.com/identity/ >> >> >> >> >> >> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < >> oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com >> > wrote: >> >> >> >> Sorry, I missed that message. >> >> >> >> While this may be a solution in specific circumstances, I don=E2=80= =99t >> think it=E2=80=99s a general solution. e.g. an AS may not allow manually= choosing >> the client_id to avoid things like >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-= 4.13 >> or may return different introspection results for client credentials tok= ens >> (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds e= ven more steps for >> somebody to migrate from existing ROPC usage. >> >> >> >> This is asking people to make fundamental changes to their identity >> architecture rather than simply switching to a new grant type.. >> >> >> >> =E2=80=94 Neil >> >> >> >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> >> >>> I see - we have gone full cycle :-) >> >>> >> >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id to= a >> service account and obtain the token data from there. >> >>> >> >>>> On 21. Feb 2020, at 15:31, Neil Madden >> wrote: >> >>>> >> >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service accoun= ts (!=3D >> clients). Maybe it should? Should there be a mTLS *grant type*? >> >>>> >> >>>> =E2=80=94 Neil >> >>>> >> >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>>>> >> >>>>> Have you ever tried the client credentials grant with mTLS? After >> reading your description it seems to be simpler than JWT Bearer.. >> >>>>> >> >>>>> * work out if the AS even supports mTLS >> >>>>> * work out how to configure the AS to trust my cert(s) >> >>>>> * Create key pair and cert using openssl >> >>>>> * Register your (self-signed) cert along with your client_id >> >>>>> * Configure the HTTP client to use your key pair for TLS Client >> Authentication >> >>>>> >> >>>>> Works very well for us. >> >>>>> >> >>>>>> On 21. Feb 2020, at 15:12, Neil Madden >> wrote: >> >>>>>> >> >>>>>> No failures, but it is a much more complex grant type to set up, >> when you consider everything you have to do: >> >>>>>> >> >>>>>> * work out if the AS even supports JWT bearer and how to turn it = on >> >>>>>> * work out how to configure the AS to trust my public key(s) >> >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >> >>>>>> * determine the correct settings for issuer, audience, subject, >> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says th= at >> the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only allo= ws this to be >> present if your client is doing impersonation of an end-user (which >> requires additional permissions). >> >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers d= o, plain OAuth >> ones might not) If I do, can I reuse the JWT or must it be freshly signe= d >> for every call? >> >>>>>> * locate and evaluate a JWT library for my language of choice. >> Monitor that new dependency for security advisories. >> >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons) >> >>>>>> * figure out how to distribute the private key to my service >> >>>>>> >> >>>>>> Compared to =E2=80=9Ccreate a service account and POST the userna= me and >> password to the token endpoint=E2=80=9D it adds a little friction. (It a= lso adds a >> lot of advantages, but it is undeniably more complex). >> >>>>>> >> >>>>>> =E2=80=94 Neil >> >>>>>> >> >>>>>> >> >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast > 40coil.com@dmarc.ietf.org> wrote: >> >>>>>>> >> >>>>>>> I have a feeling that if we had more concise JWT libraries and >> command line tools, where using the JWT Bearer grant became a one-liner >> again then we wouldn=E2=80=99t be having this conversation. So perhaps r= emoving it >> is an incentive to make that happen. >> >>>>>>> >> >>>>>>> Neil could you elaborate more on this please. What failures are >> you currently experiencing/seeing with the JWT Bearer grant? >> >>>>>>> >> >>>>>>> Matt >> >>>>>>> >> >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden < >> neil.madden@forgerock.com> wrote: >> >>>>>>> I have a feeling that if we had more concise JWT libraries and >> command line tools, where using the JWT Bearer grant became a one-liner >> again then we wouldn=E2=80=99t be having this conversation. So perhaps r= emoving it >> is an incentive to make that happen. >> >>>>>>> >> >>>>>>> >> >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt >> wrote: >> >>>>>>>> >> >>>>>>>> Neil: are you advocating that password grant be preserved in >> 2.1? Or do you think that service account developers know enough about w= hat >> they are doing to follow what is in 6749? >> >>>>>>>> =E1=90=A7 >> >>>>>>>> >> >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden < >> neil.madden@forgerock.com> wrote: >> >>>>>>>> OAuth2 clients are often private to the AS - they live in a >> database that only the AS can access, have attributes specific to their = use >> in OAuth2, and so on. Many existing systems have access controls based o= n >> users, roles, permissions and so on and expect all users accessing the >> system to exist in some user repository, e.g. LDAP, where they can be >> looked up and appropriate permissions determined. A service account can = be >> created inside such a system as if it was a regular user, managed throug= h >> the normal account provisioning tools, assigned permissions, roles, etc. >> >>>>>>>> >> >>>>>>>> Another reason is that sometimes OAuth is just one >> authentication option out of many, and so permissions assigned to servic= e >> accounts are preferred over scopes because they are consistently applied= no >> matter how a request is authenticated. This is often the case when OAuth >> has been retrofitted to an existing system and they need to preserve >> compatibility with already deployed clients. >> >>>>>>>> >> >>>>>>>> See e.g. Google cloud platform (GCP): >> https://developers.google.com/identity/protocols/OAuth2ServiceAccount >> >>>>>>>> They use the JWT bearer grant type for service account >> authentication and assign permissions to those service accounts and >> typically have very broad scopes. For service-to-service API calls you >> typically get an access token with a single scope that is effectively = =E2=80=9Call >> of GCP=E2=80=9D and everything is managed at the level of permissions on= the RO >> service account itself. They only break down fine-grained scopes when yo= u >> are dealing with user data and will be getting an access token approved = by >> a real user (through a normal auth code flow). >> >>>>>>>> >> >>>>>>>> =E2=80=94 Neil >> >>>>>>>> >> >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>>>>>>>> >> >>>>>>>>> Can you explain more in detail why the client credentials gran= t >> type isn=E2=80=99t applicable for the kind of use cases you mentioned? >> >>>>>>>>> >> >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden < >> neil.madden@forgerock.com>: >> >>>>>>>>>> >> >>>>>>>>>> I very much agree with this with regards to real users. >> >>>>>>>>>> >> >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is for= service >> accounts - where you essentially want something like client_credentials = but >> for whatever reason you need the RO to be a service user rather than an >> OAuth2 client (typically so that some lower layer of the system can stil= l >> perform its required permission checks). >> >>>>>>>>>> >> >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but >> they are a bit harder to implement. Having recently converted some code >> from ROPC to JWT bearer for exactly this use-case, it went from a couple= of >> lines of code to two screens of code. For service to service API calls >> within a datacenter I=E2=80=99m not convinced this resulted in a materia= l increase >> in security for the added complexity. >> >>>>>>>>>> >> >>>>>>>>>> =E2=80=94 Neil >> >>>>>>>>>> >> >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt < >> hans.zandbelt@zmartzone.eu> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> I would also seriously look at the original motivation behin= d >> ROPC: I know it has been deployed and is used in quite a lot of places b= ut >> I have never actually come across a use case where it is used for migrat= ion >> purposes and the migration is actually executed (I know that is >> statistically not a very strong argument but I challenge others to come = up >> with one...) >> >>>>>>>>>>> In reality it turned out just to be a one off that people >> used as an easy way out to stick to an anti-pattern and still claim to d= o >> OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of = it. >> >>>>>>>>>>> >> >>>>>>>>>>> Hans. >> >>>>>>>>>>> >> >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki < >> aaron@parecki.com> wrote: >> >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting >> as a grace period since it currently says the password grant MUST NOT be >> used, so in the OAuth 2.0 world that's already a pretty strong signal.. >> >>>>>>>>>>> >> >>>>>>>>>>> Aaron >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer < >> jricher@mit.edu> wrote: >> >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 >> can still do OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1. >> >>>>>>>>>>> >> >>>>>>>>>>> =E2=80=94 Justin >> >>>>>>>>>>> >> >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin > 40microsoft.com@dmarc.ietf.org> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are >> still sites using this and a grace period should be provided before a MU= ST >> is pushed out as there are valid use cases out there still. >> >>>>>>>>>>>> >> >>>>>>>>>>>> From: OAuth On Behalf Of Dick Hard= t >> >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >> >>>>>>>>>>>> To: oauth@ietf.org >> >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password >> grant >> >>>>>>>>>>>> >> >>>>>>>>>>>> Hey List >> >>>>>>>>>>>> >> >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for >> the doc that Aaron, Torsten, and I are working on) >> >>>>>>>>>>>> >> >>>>>>>>>>>> In the security topics doc >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-= 2.4 >> >>>>>>>>>>>> >> >>>>>>>>>>>> The password grant MUST not be used. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Some background for those interested. I added this grant >> into OAuth 2.0 to allow applications that had been provided password to >> migrate. Even with the caveats in OAuth 2.0, implementors decide they wa= nt >> to prompt the user to enter their credentials, the anti-pattern OAuth wa= s >> created to eliminate. >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Does anyone have concerns with dropping the password grant >> from the OAuth 2.1 document so that developers don't use it? >> >>>>>>>>>>>> >> >>>>>>>>>>>> /Dick >> >>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>> OAuth mailing list >> >>>>>>>>>>>> OAuth@ietf.org >> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>>>>>>>>> >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> OAuth mailing list >> >>>>>>>>>>> OAuth@ietf.org >> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>>>>>>>>> -- >> >>>>>>>>>>> ---- >> >>>>>>>>>>> Aaron Parecki >> >>>>>>>>>>> aaronparecki.com >> >>>>>>>>>>> @aaronpk >> >>>>>>>>>>> >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> OAuth mailing list >> >>>>>>>>>>> OAuth@ietf.org >> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> -- >> >>>>>>>>>>> hans.zandbelt@zmartzone.eu >> >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> OAuth mailing list >> >>>>>>>>>>> OAuth@ietf.org >> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> OAuth mailing list >> >>>>>>>>>> OAuth@ietf.org >> >>>>>>>>>> https://www.ietf..org/mailman/listinfo/oauth >> >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> 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 >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000000c9629059f5b5d3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we migh= t be going about this discussion the wrong way.

On Mon, Feb= 24, 2020 at 9:04 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wro= te:
Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, = 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote:
I=E2=80=99m not really sure th= e WG should be telling people what they =E2=80=9Cought to be doing=E2=80=9D= unless we have concrete security or interoperability reasons for doing so.=

I 100% agree that the j= ob of a standard is not to tell people "what they ought to be doing&qu= ot;. Instead, a standard is more about documenting the current state of the= art as deployed in existing implementations.

With= that in mind, I think that leaves us with two concrete problems with the p= assword grant:

1) The actual problem with the pass= word grant is end users entering passwords in applications, which the group= (mostly) agrees on
2) People are re-appropriating the password g= rant for things like service accounts or backends that are inflexible, not = actually using it for end user credentials

=
So it seems like there's actually something missing from OAu= th which is leading people to find the password grant and use that because = it's the only thing that most closely fits their existing model. It see= ms like we'd be better off defining a new extension that captures the u= se case people are actually doing, instead of encouraging the continuing us= e of the password grant for this purpose.

----
Aaron Parecki



On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell &= lt;bcampbell=3D40pingi= dentity.com@dmarc.ietf.org> wrote:
Concur with the sentiment expres= sed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forge= rock.com> wrote:
I=E2=80=99m not really sure the WG should be telling people what th= ey =E2=80=9Cought to be doing=E2=80=9D unless we have concrete security or = interoperability reasons for doing so.

I also don=E2=80=99t agree that people doing this are doing anything wrong.= I don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve = learnt over the years not to second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) an= d service accounts? They even go so far as to say =E2=80=9Cscopes are not a= security mechanism=E2=80=9D [1] and tell people to use service account rol= es instead. (Precisely because they also support non-OAuth auth methods, wh= ich bypass any scopes).

Are we really going to tell them to rewrite it all to use the client creden= tials grant?

[1]: https://cloud.googl= e.com/compute/docs/access/service-accounts#accesscopesiam

> On 21 Feb 2020, at 21:04, Justin Richer <jricher@mit.edu> wrote:
>
> +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, a= nd it=E2=80=99s time to get rid of it and send people toward what they real= ly ought to be doing.
>
> Another thing I=E2=80=99ve seen is using different service accounts to= get different sets of access for one client =E2=80=94 if you=E2=80=99re do= ing that, you=E2=80=99ve got a client pretending to do two different things= , or your APIs should be using scopes to differentiate access instead of cl= ient/user identity.
>
> =E2=80=94 Justin
>
>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle <richan= na=3D40ama= zon.com@dmarc.ietf.org> wrote:
>>
>> The client IDs can still be opaque identifiers provided by the AS,= they just happen to be associated with specific service accounts. Or they = could be the opaque IDs that the AS already issued for the service account.= Either way, the AS could issue a token with the appropriate subject and ot= her claims for the service account.
>>
>> If your client identity is bound to a specific service account ide= ntity (i.e., the resource owner), then ROPC reduces down to Client Credenti= als. What's the point in passing two identifiers and two credentials fo= r the same identity?
>>
>> =E2=80=93
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>>
>>
>> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden= " <oaut= h-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote:
>>
>>=C2=A0 =C2=A0Sorry, I missed that message.
>>
>>=C2=A0 =C2=A0While this may be a solution in specific circumstances= , I don=E2=80=99t think it=E2=80=99s a general solution. e.g. an AS may not= allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-= oauth-security-topics-14#section-4.13 or may return different introspec= tion results for client credentials tokens (e.g. with no =E2=80=9Csub=E2=80= =9D) and so on. In practice, this adds even more steps for somebody to migr= ate from existing ROPC usage.
>>
>>=C2=A0 =C2=A0This is asking people to make fundamental changes to t= heir identity architecture rather than simply switching to a new grant type= ..
>>
>>=C2=A0 =C2=A0=E2=80=94 Neil
>>
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>
>>> I see - we have gone full cycle :-)
>>>
>>> Annabelle=E2=80=99s proposal would solve that. Relate a client= id to a service account and obtain the token data from there.
>>>
>>>> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>
>>>> Yes, that is great. But mTLS doesn=E2=80=99t support servi= ce accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*?
>>>>
>>>> =E2=80=94 Neil
>>>>
>>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <torsten@loddersted= t.net> wrote:
>>>>>
>>>>> Have you ever tried the client credentials grant with = mTLS? After reading your description it seems to be simpler than JWT Bearer= ..
>>>>>
>>>>> * work out if the AS even supports mTLS
>>>>> * work out how to configure the AS to trust my cert(s)=
>>>>> * Create key pair and cert using openssl
>>>>> * Register your (self-signed) cert along with your cli= ent_id
>>>>> * Configure the HTTP client to use your key pair for T= LS Client Authentication
>>>>>
>>>>> Works very well for us.
>>>>>
>>>>>> On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forgero= ck.com> wrote:
>>>>>>
>>>>>> No failures, but it is a much more complex grant t= ype to set up, when you consider everything you have to do:
>>>>>>
>>>>>> * work out if the AS even supports JWT bearer and = how to turn it on
>>>>>> * work out how to configure the AS to trust my pub= lic key(s)
>>>>>> - do I have to create a new HTTPS endpoint to publ= ish a JWK Set?
>>>>>> * determine the correct settings for issuer, audie= nce, subject, etc. Does the AS impose non-standard requirements? e.g. RFC 7= 523 says that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Googl= e only allows this to be present if your client is doing impersonation of a= n end-user (which requires additional permissions).
>>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? = (OIDC servers do, plain OAuth ones might not) If I do, can I reuse the JWT = or must it be freshly signed for every call?
>>>>>> * locate and evaluate a JWT library for my languag= e of choice. Monitor that new dependency for security advisories.
>>>>>> * choose a suitable signature algorithm (=E2=80=98= ere be dragons)
>>>>>> * figure out how to distribute the private key to = my service
>>>>>>
>>>>>> Compared to =E2=80=9Ccreate a service account and = POST the username and password to the token endpoint=E2=80=9D it adds a lit= tle friction. (It also adds a lot of advantages, but it is undeniably more = complex).
>>>>>>
>>>>>> =E2=80=94 Neil
>>>>>>
>>>>>>
>>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast <= ;matt=3D40co= il.com@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>> I have a feeling that if we had more concise J= WT libraries and command line tools, where using the JWT Bearer grant becam= e a one-liner again then we wouldn=E2=80=99t be having this conversation. S= o perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>> Neil could you elaborate more on this please. = What failures are you currently experiencing/seeing with the JWT Bearer gra= nt?
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden &= lt;neil.madd= en@forgerock.com> wrote:
>>>>>>> I have a feeling that if we had more concise J= WT libraries and command line tools, where using the JWT Bearer grant becam= e a one-liner again then we wouldn=E2=80=99t be having this conversation. S= o perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>>
>>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:
>>>>>>>>
>>>>>>>> Neil: are you advocating that password gra= nt be preserved in 2.1? Or do you think that service account developers kno= w enough about what they are doing to follow what is in 6749?
>>>>>>>> =E1=90=A7
>>>>>>>>
>>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madde= n <neil.m= adden@forgerock.com> wrote:
>>>>>>>> OAuth2 clients are often private to the AS= - they live in a database that only the AS can access, have attributes spe= cific to their use in OAuth2, and so on. Many existing systems have access = controls based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where the= y can be looked up and appropriate permissions determined. A service accoun= t can be created inside such a system as if it was a regular user, managed = through the normal account provisioning tools, assigned permissions, roles,= etc.
>>>>>>>>
>>>>>>>> Another reason is that sometimes OAuth is = just one authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently ap= plied no matter how a request is authenticated. This is often the case when= OAuth has been retrofitted to an existing system and they need to preserve= compatibility with already deployed clients.
>>>>>>>>
>>>>>>>> See e.g. Google cloud platform (GCP): https://developers.google.com/ident= ity/protocols/OAuth2ServiceAccount
>>>>>>>> They use the JWT bearer grant type for ser= vice account authentication and assign permissions to those service account= s and typically have very broad scopes. For service-to-service API calls yo= u typically get an access token with a single scope that is effectively =E2= =80=9Call of GCP=E2=80=9D and everything is managed at the level of permiss= ions on the RO service account itself. They only break down fine-grained sc= opes when you are dealing with user data and will be getting an access toke= n approved by a real user (through a normal auth code flow).
>>>>>>>>
>>>>>>>> =E2=80=94 Neil
>>>>>>>>
>>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodd= erstedt <to= rsten@lodderstedt.net> wrote:
>>>>>>>>>
>>>>>>>>> Can you explain more in detail why the= client credentials grant type isn=E2=80=99t applicable for the kind of use= cases you mentioned?
>>>>>>>>>
>>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Nei= l Madden <neil.madden@forgerock.com>:
>>>>>>>>>>
>>>>>>>>>> I very much agree with this with r= egards to real users.
>>>>>>>>>>
>>>>>>>>>> The one legitimate use-case for RO= PC I=E2=80=99ve seen is for service accounts - where you essentially want s= omething like client_credentials but for whatever reason you need the RO to= be a service user rather than an OAuth2 client (typically so that some low= er layer of the system can still perform its required permission checks). >>>>>>>>>>
>>>>>>>>>> There are better grant types for t= his - e.g. JWT bearer - but they are a bit harder to implement. Having rece= ntly converted some code from ROPC to JWT bearer for exactly this use-case,= it went from a couple of lines of code to two screens of code. For service= to service API calls within a datacenter I=E2=80=99m not convinced this re= sulted in a material increase in security for the added complexity.
>>>>>>>>>>
>>>>>>>>>> =E2=80=94 Neil
>>>>>>>>>>
>>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans= Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would also seriously look at= the original motivation behind ROPC: I know it has been deployed and is us= ed in quite a lot of places but I have never actually come across a use cas= e where it is used for migration purposes and the migration is actually exe= cuted (I know that is statistically not a very strong argument but I challe= nge others to come up with one...)
>>>>>>>>>>> In reality it turned out just = to be a one off that people used as an easy way out to stick to an anti-pat= tern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth an= d we need to get rid of it.
>>>>>>>>>>>
>>>>>>>>>>> Hans.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 = PM Aaron Parecki <aaron@parecki.com> wrote:
>>>>>>>>>>> Agreed. Plus, the Security BCP= is already effectively acting as a grace period since it currently says th= e password grant MUST NOT be used, so in the OAuth 2.0 world that's alr= eady a pretty strong signal..
>>>>>>>>>>>
>>>>>>>>>>> Aaron
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 P= M Justin Richer <jr= icher@mit.edu> wrote:
>>>>>>>>>>> There is no need for a grace p= eriod. People using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2= ..1 will do OAuth 2.1.
>>>>>>>>>>>
>>>>>>>>>>> =E2=80=94 Justin
>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 18, 2020, at 3:= 54 PM, Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:=
>>>>>>>>>>>>
>>>>>>>>>>>> I would suggest a SHOULD N= OT instead of MUST, there are still sites using this and a grace period sho= uld be provided before a MUST is pushed out as there are valid use cases ou= t there still.
>>>>>>>>>>>>
>>>>>>>>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
>>>>>>>>>>>> Sent: Tuesday, February 18= , 2020 12:37 PM
>>>>>>>>>>>> To: oauth@ietf.org
>>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH= -WG] OAuth 2.1: dropping password grant
>>>>>>>>>>>>
>>>>>>>>>>>> Hey List
>>>>>>>>>>>>
>>>>>>>>>>>> (Once again using the OAut= h 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are work= ing on)
>>>>>>>>>>>>
>>>>>>>>>>>> In the security topics doc=
>>>>>>>>>>>>
>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-securi= ty-topics-14#section-2.4
>>>>>>>>>>>>
>>>>>>>>>>>> The password grant MUST no= t be used.
>>>>>>>>>>>>
>>>>>>>>>>>> Some background for those = interested. I added this grant into OAuth 2.0 to allow applications that ha= d been provided password to migrate. Even with the caveats in OAuth 2.0, im= plementors decide they want to prompt the user to enter their credentials, = the anti-pattern OAuth was created to eliminate.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone have concerns = with dropping the password grant from the OAuth 2.1 document so that develo= pers don't use it?
>>>>>>>>>>>>
>>>>>>>>>>>> /Dick
>>>>>>>>>>>> __________________________= _____________________
>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>> https://= www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>> --
>>>>>>>>>>> ----
>>>>>>>>>>> Aaron Parecki
>>>>>>>>>>> aaronparecki.com
>>>>>>>>>>> @aaronpk
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu=
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf= ..org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mai= lman/listinfo/oauth
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>
>>>>>> _______________________________________________ >>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>>
>>>>
>>>
>>
>>=C2=A0 =C2=A0_______________________________________________
>>=C2=A0 =C2=A0OAuth mailing list
>>=C2=A0 =C2=A0OA= uth@ietf.org
>>=C2=A0 =C2=A0https://www.ietf.org/mailman/listinf= o/oauth
>>
>>
>> _______________________________________________
>> 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

<= 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
--0000000000000c9629059f5b5d3b-- From nobody Mon Feb 24 16:55:53 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4C13A16B2 for ; Mon, 24 Feb 2020 16:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVqqoKEscix9 for ; Mon, 24 Feb 2020 16:55:48 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6963A16B0 for ; Mon, 24 Feb 2020 16:55:47 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id n25so8297092lfl.0 for ; Mon, 24 Feb 2020 16:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bOXtt2dbM/hCU5lSCpn6ThobUi8ayJZ+Xze1QOLtvDE=; b=fCoaUuzM6Tw7fI6eu2MSGTguPE3c4C6Qak3xsCxjtaAASRh263g4AcXXpdJzIiAp0Y 2epWsZI6l9oXDYFMQ/uZREdlCC5lUq0P852ftakQvsVWMnq7RJRbb/UJgQwrvOzElDvu cWZv9MvYps5GfeB+5+GwpgoIFGYbEzYukj67zb2EVurJ0dVu454wOfavO2umLdqE2h5X Var7fuGv/rsN3M4JDLT9XjwuRE7P0tL0jhVYlYDgbcWIyIwb85KcaHh865mJ3/oMAnef o7B2sbugRiZY8METAb8vuvA6GV52qvKSEJ3o42J1WXuUSOug+CgW7yE/CzZExK0toKcr JpYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=bOXtt2dbM/hCU5lSCpn6ThobUi8ayJZ+Xze1QOLtvDE=; b=H/J1QH444p6FCPxZqZ/3VBakoD4ph3ya41hsvt/Ick6nmfvhvbvk2KcHPQTHwCab42 9ynQpMNQ6JNlUF4TP7j6X4VVJCUkKiwT7v9bhKu1ZBnI1C7iYe7ilkC4WzoGUaotTH9G EnghlIs4l4/EJWqTBa79k41tuvm141joNCxRJU+xWJ7mXfgyLF9LslveJCfUkIgeg/pS a88I8FMjrw5P2ziYZLnpabClhfxqGEZ38IFMxMqn703fBMRWcrUg2L7D/AD3q1hx8qjM Aud6fUd0304uR1XFi4rvjWoYSiVdXfFo9FEJ3/2LaPX5cyNrZw3QEt/khO8qZ/yUMtVc HkIw== X-Gm-Message-State: APjAAAW2mOLYBqFmdWCtuTQ5uj8qOuWqCtzur86ICY7LSveKWlq2wGFw X2ICCqQreUj5jnHSVWl+gS28fnw1HjkE89vxJPN4p7wT+9A= X-Google-Smtp-Source: APXvYqzrgWMIJUMZyhNyRULk2DDkd8kdAQhLPse2VAdbb8VSsXaDm5xJiLcWNoHgo2wgpu1+hoseGusI+/5JZ3JjTCc= X-Received: by 2002:a05:6512:108e:: with SMTP id j14mr15960033lfg.18.1582592144974; Mon, 24 Feb 2020 16:55:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bruno Brito Date: Mon, 24 Feb 2020 21:55:35 -0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000a029c8059f5bf2be" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 30 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 00:55:52 -0000 --000000000000a029c8059f5bf2be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > a standard is more about documenting the current state of the art as deployed in existing implementations. For those whose still keep their ROPC grants working whats the problem about be OAuth 2.0 compliant? And those who changes their implememntations, they will be OAuth 2.1 compliant, isn't simple? Afterall the show must go on. On Mon, Feb 24, 2020 at 9:14 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: OAuth 2.1: dropping password grant (Aaron Parecki) > > > > ---------- Forwarded message ---------- > From: Aaron Parecki > To: Brian Campbell > Cc: Neil Madden , Matthew De Haast 40coil.com@dmarc.ietf.org>, "oauth@ietf.org" , "Richard > Backman, Annabelle" > Bcc: > Date: Mon, 24 Feb 2020 16:13:42 -0800 > Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant > I think we might be going about this discussion the wrong way. > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Concur with the sentiment expressed by Neil here. >> >> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden >> wrote: >> >>> I=E2=80=99m not really sure the WG should be telling people what they = =E2=80=9Cought to >>> be doing=E2=80=9D unless we have concrete security or interoperability = reasons for >>> doing so. >> >> > I 100% agree that the job of a standard is not to tell people "what they > ought to be doing". Instead, a standard is more about documenting the > current state of the art as deployed in existing implementations. > > With that in mind, I think that leaves us with two concrete problems with > the password grant: > > 1) The actual problem with the password grant is end users entering > passwords in applications, which the group (mostly) agrees on > 2) People are re-appropriating the password grant for things like service > accounts or backends that are inflexible, not actually using it for end > user credentials > > So it seems like there's actually something missing from OAuth which is > leading people to find the password grant and use that because it's the > only thing that most closely fits their existing model. It seems like we'= d > be better off defining a new extension that captures the use case people > are actually doing, instead of encouraging the continuing use of the > password grant for this purpose. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Concur with the sentiment expressed by Neil here. >> >> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden >> wrote: >> >>> I=E2=80=99m not really sure the WG should be telling people what they = =E2=80=9Cought to >>> be doing=E2=80=9D unless we have concrete security or interoperability = reasons for >>> doing so. >>> >>> I also don=E2=80=99t agree that people doing this are doing anything wr= ong. I >>> don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve= learnt over the >>> years not to second-guess their reasons for doing it. >>> >>> Are Google wrong for using the JWT bearer grant (not client credentials= ) >>> and service accounts? They even go so far as to say =E2=80=9Cscopes are= not a >>> security mechanism=E2=80=9D [1] and tell people to use service account = roles >>> instead. (Precisely because they also support non-OAuth auth methods, w= hich >>> bypass any scopes). >>> >>> Are we really going to tell them to rewrite it all to use the client >>> credentials grant? >>> >>> [1]: >>> https://cloud.google.com/compute/docs/access/service-accounts#accesscop= esiam >>> >>> > On 21 Feb 2020, at 21:04, Justin Richer wrote: >>> > >>> > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, = and it=E2=80=99s >>> time to get rid of it and send people toward what they really ought to = be >>> doing. >>> > >>> > Another thing I=E2=80=99ve seen is using different service accounts t= o get >>> different sets of access for one client =E2=80=94 if you=E2=80=99re doi= ng that, you=E2=80=99ve got >>> a client pretending to do two different things, or your APIs should be >>> using scopes to differentiate access instead of client/user identity. >>> > >>> > =E2=80=94 Justin >>> > >>> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org> wrote: >>> >> >>> >> The client IDs can still be opaque identifiers provided by the AS, >>> they just happen to be associated with specific service accounts. Or th= ey >>> could be the opaque IDs that the AS already issued for the service acco= unt. >>> Either way, the AS could issue a token with the appropriate subject and >>> other claims for the service account. >>> >> >>> >> If your client identity is bound to a specific service account >>> identity (i.e., the resource owner), then ROPC reduces down to Client >>> Credentials. What's the point in passing two identifiers and two >>> credentials for the same identity? >>> >> >>> >> =E2=80=93 >>> >> Annabelle Backman (she/her) >>> >> AWS Identity >>> >> https://aws.amazon.com/identity/ >>> >> >>> >> >>> >> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < >>> oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com >>> > wrote: >>> >> >>> >> Sorry, I missed that message. >>> >> >>> >> While this may be a solution in specific circumstances, I don=E2= =80=99t >>> think it=E2=80=99s a general solution. e.g. an AS may not allow manuall= y choosing >>> the client_id to avoid things like >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section= -4.13 >>> or may return different introspection results for client credentials to= kens >>> (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds = even more steps for >>> somebody to migrate from existing ROPC usage. >>> >> >>> >> This is asking people to make fundamental changes to their identit= y >>> architecture rather than simply switching to a new grant type... >>> >> >>> >> =E2=80=94 Neil >>> >> >>> >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> >>> >>> I see - we have gone full cycle :-) >>> >>> >>> >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id t= o a >>> service account and obtain the token data from there. >>> >>> >>> >>>> On 21. Feb 2020, at 15:31, Neil Madden >>> wrote: >>> >>>> >>> >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service accou= nts (!=3D >>> clients). Maybe it should? Should there be a mTLS *grant type*? >>> >>>> >>> >>>> =E2=80=94 Neil >>> >>>> >>> >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>>> >>> >>>>> Have you ever tried the client credentials grant with mTLS? After >>> reading your description it seems to be simpler than JWT Bearer... >>> >>>>> >>> >>>>> * work out if the AS even supports mTLS >>> >>>>> * work out how to configure the AS to trust my cert(s) >>> >>>>> * Create key pair and cert using openssl >>> >>>>> * Register your (self-signed) cert along with your client_id >>> >>>>> * Configure the HTTP client to use your key pair for TLS Client >>> Authentication >>> >>>>> >>> >>>>> Works very well for us. >>> >>>>> >>> >>>>>> On 21. Feb 2020, at 15:12, Neil Madden >>> wrote: >>> >>>>>> >>> >>>>>> No failures, but it is a much more complex grant type to set up, >>> when you consider everything you have to do: >>> >>>>>> >>> >>>>>> * work out if the AS even supports JWT bearer and how to turn it >>> on >>> >>>>>> * work out how to configure the AS to trust my public key(s) >>> >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>> >>>>>> * determine the correct settings for issuer, audience, subject, >>> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says t= hat >>> the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only all= ows this to be >>> present if your client is doing impersonation of an end-user (which >>> requires additional permissions). >>> >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth >>> ones might not) If I do, can I reuse the JWT or must it be freshly sign= ed >>> for every call? >>> >>>>>> * locate and evaluate a JWT library for my language of choice. >>> Monitor that new dependency for security advisories. >>> >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be dragons= ) >>> >>>>>> * figure out how to distribute the private key to my service >>> >>>>>> >>> >>>>>> Compared to =E2=80=9Ccreate a service account and POST the usern= ame and >>> password to the token endpoint=E2=80=9D it adds a little friction. (It = also adds a >>> lot of advantages, but it is undeniably more complex). >>> >>>>>> >>> >>>>>> =E2=80=94 Neil >>> >>>>>> >>> >>>>>> >>> >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast >> 40coil.com@dmarc.ietf.org> wrote: >>> >>>>>>> >>> >>>>>>> I have a feeling that if we had more concise JWT libraries and >>> command line tools, where using the JWT Bearer grant became a one-liner >>> again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it >>> is an incentive to make that happen. >>> >>>>>>> >>> >>>>>>> Neil could you elaborate more on this please. What failures are >>> you currently experiencing/seeing with the JWT Bearer grant? >>> >>>>>>> >>> >>>>>>> Matt >>> >>>>>>> >>> >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden < >>> neil.madden@forgerock.com> wrote: >>> >>>>>>> I have a feeling that if we had more concise JWT libraries and >>> command line tools, where using the JWT Bearer grant became a one-liner >>> again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it >>> is an incentive to make that happen. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt >>> wrote: >>> >>>>>>>> >>> >>>>>>>> Neil: are you advocating that password grant be preserved in >>> 2.1? Or do you think that service account developers know enough about = what >>> they are doing to follow what is in 6749? >>> >>>>>>>> =E1=90=A7 >>> >>>>>>>> >>> >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden < >>> neil.madden@forgerock.com> wrote: >>> >>>>>>>> OAuth2 clients are often private to the AS - they live in a >>> database that only the AS can access, have attributes specific to their= use >>> in OAuth2, and so on. Many existing systems have access controls based = on >>> users, roles, permissions and so on and expect all users accessing the >>> system to exist in some user repository, e.g. LDAP, where they can be >>> looked up and appropriate permissions determined. A service account can= be >>> created inside such a system as if it was a regular user, managed throu= gh >>> the normal account provisioning tools, assigned permissions, roles, etc= . >>> >>>>>>>> >>> >>>>>>>> Another reason is that sometimes OAuth is just one >>> authentication option out of many, and so permissions assigned to servi= ce >>> accounts are preferred over scopes because they are consistently applie= d no >>> matter how a request is authenticated. This is often the case when OAut= h >>> has been retrofitted to an existing system and they need to preserve >>> compatibility with already deployed clients. >>> >>>>>>>> >>> >>>>>>>> See e.g. Google cloud platform (GCP): >>> https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>> >>>>>>>> They use the JWT bearer grant type for service account >>> authentication and assign permissions to those service accounts and >>> typically have very broad scopes. For service-to-service API calls you >>> typically get an access token with a single scope that is effectively = =E2=80=9Call >>> of GCP=E2=80=9D and everything is managed at the level of permissions o= n the RO >>> service account itself. They only break down fine-grained scopes when y= ou >>> are dealing with user data and will be getting an access token approved= by >>> a real user (through a normal auth code flow). >>> >>>>>>>> >>> >>>>>>>> =E2=80=94 Neil >>> >>>>>>>> >>> >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>>>>>>> >>> >>>>>>>>> Can you explain more in detail why the client credentials >>> grant type isn=E2=80=99t applicable for the kind of use cases you menti= oned? >>> >>>>>>>>> >>> >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden < >>> neil.madden@forgerock.com>: >>> >>>>>>>>>> >>> >>>>>>>>>> I very much agree with this with regards to real users. >>> >>>>>>>>>> >>> >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is fo= r service >>> accounts - where you essentially want something like client_credentials= but >>> for whatever reason you need the RO to be a service user rather than an >>> OAuth2 client (typically so that some lower layer of the system can sti= ll >>> perform its required permission checks). >>> >>>>>>>>>> >>> >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - bu= t >>> they are a bit harder to implement. Having recently converted some code >>> from ROPC to JWT bearer for exactly this use-case, it went from a coupl= e of >>> lines of code to two screens of code. For service to service API calls >>> within a datacenter I=E2=80=99m not convinced this resulted in a materi= al increase >>> in security for the added complexity. >>> >>>>>>>>>> >>> >>>>>>>>>> =E2=80=94 Neil >>> >>>>>>>>>> >>> >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt < >>> hans.zandbelt@zmartzone.eu> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> I would also seriously look at the original motivation >>> behind ROPC: I know it has been deployed and is used in quite a lot of >>> places but I have never actually come across a use case where it is use= d >>> for migration purposes and the migration is actually executed (I know t= hat >>> is statistically not a very strong argument but I challenge others to c= ome >>> up with one...) >>> >>>>>>>>>>> In reality it turned out just to be a one off that people >>> used as an easy way out to stick to an anti-pattern and still claim to = do >>> OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of= it. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Hans. >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki < >>> aaron@parecki.com> wrote: >>> >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively actin= g >>> as a grace period since it currently says the password grant MUST NOT b= e >>> used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Aaron >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer < >>> jricher@mit.edu> wrote: >>> >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..= 0 >>> can still do OAuth 2.0. People using OAuth 2...1 will do OAuth 2.1. >>> >>>>>>>>>>> >>> >>>>>>>>>>> =E2=80=94 Justin >>> >>>>>>>>>>> >>> >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin >> 40microsoft.com@dmarc.ietf.org> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are >>> still sites using this and a grace period should be provided before a M= UST >>> is pushed out as there are valid use cases out there still. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> From: OAuth On Behalf Of Dick >>> Hardt >>> >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>> >>>>>>>>>>>> To: oauth@ietf.org >>> >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping passwor= d >>> grant >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Hey List >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for >>> the doc that Aaron, Torsten, and I are working on) >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> In the security topics doc >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section= -2.4 >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> The password grant MUST not be used. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Some background for those interested. I added this grant >>> into OAuth 2.0 to allow applications that had been provided password to >>> migrate. Even with the caveats in OAuth 2.0, implementors decide they w= ant >>> to prompt the user to enter their credentials, the anti-pattern OAuth w= as >>> created to eliminate. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Does anyone have concerns with dropping the password grant >>> from the OAuth 2.1 document so that developers don't use it? >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> /Dick >>> >>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>> >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>> -- >>> >>>>>>>>>>> ---- >>> >>>>>>>>>>> Aaron Parecki >>> >>>>>>>>>>> aaronparecki.com >>> >>>>>>>>>>> @aaronpk >>> >>>>>>>>>>> >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> -- >>> >>>>>>>>>>> hans.zandbelt@zmartzone.eu >>> >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> OAuth mailing list >>> >>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>> https://www.ietf...org/mailman/listinfo/oauth >>> >>> >>>>>>>> >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> 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 >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000a029c8059f5bf2be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> a standard is more about documenting the current= state of the art as deployed in existing implementations.

For those whose still keep their ROPC grants working whats the problem = about be OAuth 2.0 compliant?=C2=A0
And those who changes their implemem= ntations, they will be OAuth 2.1 compliant, isn't simple?

Aftera= ll the show must go on.

On Mon, Feb 24, 2020 at 9:14 PM <oauth-request@ietf.org> wrote:
Send OAuth mailing list= submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

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

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

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

=C2=A0 =C2=A01. Re: OAuth 2.1: dropping password grant (Aaron Parecki)



---------- Forwarded message ----------
From:=C2=A0Aaron Par= ecki <aaron@parec= ki.com>
To:=C2=A0Brian Campbell <bcampbell=3D40pingidentity.com@dm= arc.ietf.org>
Cc:=C2=A0Neil Madden <neil.madden@forgerock.com>, Mat= thew De Haast <matt=3D40coil.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, "Richard = Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Bcc:= =C2=A0
Date:=C2=A0Mon, 24 Feb 2020 16:13:42 -0800
Subject:=C2=A0Re: [= OAUTH-WG] OAuth 2.1: dropping password grant
I think we might be going about this dis= cussion the wrong way.

On Mon, Feb 24, 2020 at 9:04 AM Bria= n Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
=
Co= ncur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at= 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote:
I=E2=80=99m not really sure the WG sh= ould be telling people what they =E2=80=9Cought to be doing=E2=80=9D unless= we have concrete security or interoperability reasons for doing so.

I 100% agree that the job of a= standard is not to tell people "what they ought to be doing". In= stead, a standard is more about documenting the current state of the art as= deployed in existing implementations.

With that i= n mind, I think that leaves us with two concrete problems with the password= grant:

1) The actual problem with the password gr= ant is end users entering passwords in applications, which the group (mostl= y) agrees on
2) People are re-appropriating the password grant fo= r things like service accounts or backends that are inflexible, not actuall= y using it for end user credentials

<= div>So it seems like there's actually something missing from OAuth whic= h is leading people to find the password grant and use that because it'= s the only thing that most closely fits their existing model. It seems like= we'd be better off defining a new extension that captures the use case= people are actually doing, instead of encouraging the continuing use of th= e password grant for this purpose.

=
----
Aaron Parecki
@aaronpk



On Mon, Feb 24, 2020 at 9:04 AM Brian Cam= pbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Concur = with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32= PM Neil Madden <neil.madden@forgerock.com> wrote:
I=E2=80=99m not really sure the WG should = be telling people what they =E2=80=9Cought to be doing=E2=80=9D unless we h= ave concrete security or interoperability reasons for doing so.

I also don=E2=80=99t agree that people doing this are doing anything wrong.= I don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve = learnt over the years not to second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) an= d service accounts? They even go so far as to say =E2=80=9Cscopes are not a= security mechanism=E2=80=9D [1] and tell people to use service account rol= es instead. (Precisely because they also support non-OAuth auth methods, wh= ich bypass any scopes).

Are we really going to tell them to rewrite it all to use the client creden= tials grant?

[1]: https://cloud.googl= e.com/compute/docs/access/service-accounts#accesscopesiam

> On 21 Feb 2020, at 21:04, Justin Richer <jricher@mit.edu> wrote:
>
> +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, a= nd it=E2=80=99s time to get rid of it and send people toward what they real= ly ought to be doing.
>
> Another thing I=E2=80=99ve seen is using different service accounts to= get different sets of access for one client =E2=80=94 if you=E2=80=99re do= ing that, you=E2=80=99ve got a client pretending to do two different things= , or your APIs should be using scopes to differentiate access instead of cl= ient/user identity.
>
> =E2=80=94 Justin
>
>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle <richan= na=3D40ama= zon.com@dmarc.ietf.org> wrote:
>>
>> The client IDs can still be opaque identifiers provided by the AS,= they just happen to be associated with specific service accounts. Or they = could be the opaque IDs that the AS already issued for the service account.= Either way, the AS could issue a token with the appropriate subject and ot= her claims for the service account.
>>
>> If your client identity is bound to a specific service account ide= ntity (i.e., the resource owner), then ROPC reduces down to Client Credenti= als. What's the point in passing two identifiers and two credentials fo= r the same identity?
>>
>> =E2=80=93
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>>
>>
>> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden= " <oaut= h-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote:
>>
>>=C2=A0 =C2=A0Sorry, I missed that message.
>>
>>=C2=A0 =C2=A0While this may be a solution in specific circumstances= , I don=E2=80=99t think it=E2=80=99s a general solution. e.g. an AS may not= allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-= oauth-security-topics-14#section-4.13 or may return different introspec= tion results for client credentials tokens (e.g. with no =E2=80=9Csub=E2=80= =9D) and so on. In practice, this adds even more steps for somebody to migr= ate from existing ROPC usage.
>>
>>=C2=A0 =C2=A0This is asking people to make fundamental changes to t= heir identity architecture rather than simply switching to a new grant type= ...
>>
>>=C2=A0 =C2=A0=E2=80=94 Neil
>>
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>
>>> I see - we have gone full cycle :-)
>>>
>>> Annabelle=E2=80=99s proposal would solve that. Relate a client= id to a service account and obtain the token data from there.
>>>
>>>> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>
>>>> Yes, that is great. But mTLS doesn=E2=80=99t support servi= ce accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*?
>>>>
>>>> =E2=80=94 Neil
>>>>
>>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <torsten@loddersted= t.net> wrote:
>>>>>
>>>>> Have you ever tried the client credentials grant with = mTLS? After reading your description it seems to be simpler than JWT Bearer= ...
>>>>>
>>>>> * work out if the AS even supports mTLS
>>>>> * work out how to configure the AS to trust my cert(s)=
>>>>> * Create key pair and cert using openssl
>>>>> * Register your (self-signed) cert along with your cli= ent_id
>>>>> * Configure the HTTP client to use your key pair for T= LS Client Authentication
>>>>>
>>>>> Works very well for us.
>>>>>
>>>>>> On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forgero= ck.com> wrote:
>>>>>>
>>>>>> No failures, but it is a much more complex grant t= ype to set up, when you consider everything you have to do:
>>>>>>
>>>>>> * work out if the AS even supports JWT bearer and = how to turn it on
>>>>>> * work out how to configure the AS to trust my pub= lic key(s)
>>>>>> - do I have to create a new HTTPS endpoint to publ= ish a JWK Set?
>>>>>> * determine the correct settings for issuer, audie= nce, subject, etc. Does the AS impose non-standard requirements? e.g. RFC 7= 523 says that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Googl= e only allows this to be present if your client is doing impersonation of a= n end-user (which requires additional permissions).
>>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? = (OIDC servers do, plain OAuth ones might not) If I do, can I reuse the JWT = or must it be freshly signed for every call?
>>>>>> * locate and evaluate a JWT library for my languag= e of choice. Monitor that new dependency for security advisories.
>>>>>> * choose a suitable signature algorithm (=E2=80=98= ere be dragons)
>>>>>> * figure out how to distribute the private key to = my service
>>>>>>
>>>>>> Compared to =E2=80=9Ccreate a service account and = POST the username and password to the token endpoint=E2=80=9D it adds a lit= tle friction. (It also adds a lot of advantages, but it is undeniably more = complex).
>>>>>>
>>>>>> =E2=80=94 Neil
>>>>>>
>>>>>>
>>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast <= ;matt=3D40co= il.com@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>> I have a feeling that if we had more concise J= WT libraries and command line tools, where using the JWT Bearer grant becam= e a one-liner again then we wouldn=E2=80=99t be having this conversation. S= o perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>> Neil could you elaborate more on this please. = What failures are you currently experiencing/seeing with the JWT Bearer gra= nt?
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden &= lt;neil.madd= en@forgerock.com> wrote:
>>>>>>> I have a feeling that if we had more concise J= WT libraries and command line tools, where using the JWT Bearer grant becam= e a one-liner again then we wouldn=E2=80=99t be having this conversation. S= o perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>>
>>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:
>>>>>>>>
>>>>>>>> Neil: are you advocating that password gra= nt be preserved in 2.1? Or do you think that service account developers kno= w enough about what they are doing to follow what is in 6749?
>>>>>>>> =E1=90=A7
>>>>>>>>
>>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madde= n <neil.m= adden@forgerock.com> wrote:
>>>>>>>> OAuth2 clients are often private to the AS= - they live in a database that only the AS can access, have attributes spe= cific to their use in OAuth2, and so on. Many existing systems have access = controls based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where the= y can be looked up and appropriate permissions determined. A service accoun= t can be created inside such a system as if it was a regular user, managed = through the normal account provisioning tools, assigned permissions, roles,= etc.
>>>>>>>>
>>>>>>>> Another reason is that sometimes OAuth is = just one authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently ap= plied no matter how a request is authenticated. This is often the case when= OAuth has been retrofitted to an existing system and they need to preserve= compatibility with already deployed clients.
>>>>>>>>
>>>>>>>> See e.g. Google cloud platform (GCP): https://developers.google.com/ident= ity/protocols/OAuth2ServiceAccount
>>>>>>>> They use the JWT bearer grant type for ser= vice account authentication and assign permissions to those service account= s and typically have very broad scopes. For service-to-service API calls yo= u typically get an access token with a single scope that is effectively =E2= =80=9Call of GCP=E2=80=9D and everything is managed at the level of permiss= ions on the RO service account itself. They only break down fine-grained sc= opes when you are dealing with user data and will be getting an access toke= n approved by a real user (through a normal auth code flow).
>>>>>>>>
>>>>>>>> =E2=80=94 Neil
>>>>>>>>
>>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodd= erstedt <to= rsten@lodderstedt.net> wrote:
>>>>>>>>>
>>>>>>>>> Can you explain more in detail why the= client credentials grant type isn=E2=80=99t applicable for the kind of use= cases you mentioned?
>>>>>>>>>
>>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Nei= l Madden <neil.madden@forgerock.com>:
>>>>>>>>>>
>>>>>>>>>> I very much agree with this with r= egards to real users.
>>>>>>>>>>
>>>>>>>>>> The one legitimate use-case for RO= PC I=E2=80=99ve seen is for service accounts - where you essentially want s= omething like client_credentials but for whatever reason you need the RO to= be a service user rather than an OAuth2 client (typically so that some low= er layer of the system can still perform its required permission checks). >>>>>>>>>>
>>>>>>>>>> There are better grant types for t= his - e.g. JWT bearer - but they are a bit harder to implement. Having rece= ntly converted some code from ROPC to JWT bearer for exactly this use-case,= it went from a couple of lines of code to two screens of code. For service= to service API calls within a datacenter I=E2=80=99m not convinced this re= sulted in a material increase in security for the added complexity.
>>>>>>>>>>
>>>>>>>>>> =E2=80=94 Neil
>>>>>>>>>>
>>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans= Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would also seriously look at= the original motivation behind ROPC: I know it has been deployed and is us= ed in quite a lot of places but I have never actually come across a use cas= e where it is used for migration purposes and the migration is actually exe= cuted (I know that is statistically not a very strong argument but I challe= nge others to come up with one...)
>>>>>>>>>>> In reality it turned out just = to be a one off that people used as an easy way out to stick to an anti-pat= tern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth an= d we need to get rid of it.
>>>>>>>>>>>
>>>>>>>>>>> Hans.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 = PM Aaron Parecki <aaron@parecki.com> wrote:
>>>>>>>>>>> Agreed. Plus, the Security BCP= is already effectively acting as a grace period since it currently says th= e password grant MUST NOT be used, so in the OAuth 2.0 world that's alr= eady a pretty strong signal..
>>>>>>>>>>>
>>>>>>>>>>> Aaron
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 P= M Justin Richer <jr= icher@mit.edu> wrote:
>>>>>>>>>>> There is no need for a grace p= eriod. People using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2= ...1 will do OAuth 2.1.
>>>>>>>>>>>
>>>>>>>>>>> =E2=80=94 Justin
>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 18, 2020, at 3:= 54 PM, Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:=
>>>>>>>>>>>>
>>>>>>>>>>>> I would suggest a SHOULD N= OT instead of MUST, there are still sites using this and a grace period sho= uld be provided before a MUST is pushed out as there are valid use cases ou= t there still.
>>>>>>>>>>>>
>>>>>>>>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
>>>>>>>>>>>> Sent: Tuesday, February 18= , 2020 12:37 PM
>>>>>>>>>>>> To: oauth@ietf.org
>>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH= -WG] OAuth 2.1: dropping password grant
>>>>>>>>>>>>
>>>>>>>>>>>> Hey List
>>>>>>>>>>>>
>>>>>>>>>>>> (Once again using the OAut= h 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are work= ing on)
>>>>>>>>>>>>
>>>>>>>>>>>> In the security topics doc=
>>>>>>>>>>>>
>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-securi= ty-topics-14#section-2.4
>>>>>>>>>>>>
>>>>>>>>>>>> The password grant MUST no= t be used.
>>>>>>>>>>>>
>>>>>>>>>>>> Some background for those = interested. I added this grant into OAuth 2.0 to allow applications that ha= d been provided password to migrate. Even with the caveats in OAuth 2.0, im= plementors decide they want to prompt the user to enter their credentials, = the anti-pattern OAuth was created to eliminate.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone have concerns = with dropping the password grant from the OAuth 2.1 document so that develo= pers don't use it?
>>>>>>>>>>>>
>>>>>>>>>>>> /Dick
>>>>>>>>>>>> __________________________= _____________________
>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>> https://= www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>> --
>>>>>>>>>>> ----
>>>>>>>>>>> Aaron Parecki
>>>>>>>>>>> aaronparecki.com
>>>>>>>>>>> @aaronpk
>>>>>>>>>>>
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu=
>>>>>>>>>>> ______________________________= _________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.= ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf= ...org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mai= lman/listinfo/oauth
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>
>>>>>> _______________________________________________ >>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>>
>>>>
>>>
>>
>>=C2=A0 =C2=A0_______________________________________________
>>=C2=A0 =C2=A0OAuth mailing list
>>=C2=A0 =C2=A0OA= uth@ietf.org
>>=C2=A0 =C2=A0https://www.ietf.org/mailman/listinf= o/oauth
>>
>>
>> _______________________________________________
>> 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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ...=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.______________________= _________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a029c8059f5bf2be-- From nobody Mon Feb 24 18:18:04 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83163A1813 for ; Mon, 24 Feb 2020 18:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCt6i64m5F3Y for ; Mon, 24 Feb 2020 18:17:59 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541E53A184B for ; Mon, 24 Feb 2020 18:17:59 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id z3so12808897wru.3 for ; Mon, 24 Feb 2020 18:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vu8g4oZ1Esw/DQR7qXRxBMBCW0t7yY46/quaJlYGFQ0=; b=uLvuDeBWITloAhMbS6ysVpBRA2TjcpGpkD+LTAz+VvsE8ADvP+61je8ED/W05EZO34 u+fWomxp3RhNKDO53j+1KrjLl1ltnK0/TjfU/5YbJvsVdAKDPraMRfS4UD60e2b7gpw1 mb2B+aZeUfyEiS/DD8hKO8C31OX2i6vA6q9xDTXXQtfUgRTUop2VKoPCBkMec/PHIoMy 9bKiSCvjdwTFt2NlL252An31ISZTBkAHb0lsiRaorDjfPv8PuHfpj3GMtkfTcYNCqndJ /4492QaJXj2rZ4SqtjNbb6CDqEXR7I/PxdcKb3dCBVFDNDImP5J3P8l5JTe5z9u9MQeO FyMw== 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=vu8g4oZ1Esw/DQR7qXRxBMBCW0t7yY46/quaJlYGFQ0=; b=i7XX85zo3HUJ9IcKf9HT0idpjqYTIEdqvsr96eNLGwVyStKPRQX9HGMiqOqlfw2TXm RfBz7d3QMyMc63fqUzXnHcL3PC9/kzkPW6OOyYQdRR7ITrtkF3WORv3/8jJ+vFZ9KrpO JHLcud+yzWcqs9Ww3loTVWwF8sA1IBQLktKyI0vLH9QdAjQ7DNIHPGB7xee1Rp/S7SzT FcJ/leirSIgb9JVYN4j4/yjpYQ+OUzo7RPYjfmINxKS4BhVmwDqr2cJBHSgAcDwnnm/7 ffj1p2x0IGeoXIwc0jt+9u48rb1Lheu8ZF5qWPKVcGCzWchX75aHMQGi1vtHTArNv7EY J5Yg== X-Gm-Message-State: APjAAAV4WpfXTH7jXeEo/+EG48yLiJyO93G5hEPe0XAH3aYBEeeGj3nR NTmwJpqDEQyrWdTGyBbghDLNACwULDr8+BVCNLNuXEatGQM= X-Google-Smtp-Source: APXvYqz354Lit8cF97INEV8sbueTny9rq+h1A6+l0/6Q89645P0Ahfpgf3l65Ht8oLXDVIVNOJGyKfi/jl0Lh6LGrj8= X-Received: by 2002:adf:f18e:: with SMTP id h14mr11579798wro.51.1582597077298; Mon, 24 Feb 2020 18:17:57 -0800 (PST) MIME-Version: 1.0 References: <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com> <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com> <20200118025320.GV80030@kduck.mit.edu> In-Reply-To: From: Nat Sakimura Date: Tue, 25 Feb 2020 11:17:45 +0900 Message-ID: To: John Bradley Cc: oauth Content-Type: multipart/alternative; boundary="0000000000009d7402059f5d1847" Archived-At: Subject: Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 02:18:03 -0000 --0000000000009d7402059f5d1847 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, where should we take it to? Just add back client_id as it used to be? On Fri, Jan 24, 2020 at 6:55 AM John Bradley wrote: > > ---------- Forwarded message --------- > From: John Bradley > Date: Sat, Jan 18, 2020, 9:31 PM > Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request > (JAR) vs OIDC request object > To: Benjamin Kaduk > > > If you put the iss in the JWE header it is integrity protected, as JWE > only supports AAD encryption algs. > > It is more of a problem when the client is sending a requestURI in that > case having the clientID in the GET to the Authorization endpoint is usef= ul. > > I think there is a argument for explicitly allowing the clientID as long > as it exactly matches the clientID in the JAR. > > John B. > > On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk wrote: > >> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote: >> > I don=E2=80=99t agree with this stance from a security or implementati= on >> perspective. >> > >> > If there=E2=80=99s a clear order of precedence for the information, it= =E2=80=99s not >> particularly problematic. Everything inside the request object is to be >> taken over things outside the request object. We have the exact same >> semantics and process with dynamic registration, where the software >> statement is carried alongside plain JSON claims, and the two are mixed >> with a very simple algorithm: >> > >> > - If a field is inside the signed payload, use that value and ignore >> any copy of it on the outside >> > - If a field is not inside the signed payload and is outside the >> signed payload, use the outside value >> > >> > Can someone please point out a concrete security issue with this >> algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics t= hat we need here, >> and it would solve not only the ability to use this for use cases that c= all >> for a more static request object (perhaps signed by a third party and no= t >> the client) along side the plain parameters that can vary, but also the >> backwards compatibility issue that=E2=80=99s been discussed. With this a= lgorithm in >> place, you could have OIDC clients actually be compliant with the spec, >> since OIDC requires replication of the values inside the request object = on >> the outside with exact matches. An OIDC server wouldn=E2=80=99t be fully= compliant >> with the new spec since it would reject some compliant JAR requests that >> are missing the external parameters, but that=E2=80=99s fairly easy logi= c to add on >> the OIDC side. And in that case you get a matrix of compatibility like: >> >> I agree that the merge algorithm is simple and fairly straightforward to >> implement. But, as Joseph has been alluding, it's only simple if you've >> already made the decision to use all the parameters, both from inside an= d >> from outside the signed payload. The security risk lies about having to >> make the trust decision twice, more than the mundane details of actually >> doing the merge. (Though there is still some latent risk, given that >> we've >> seen some really crazy quality of implementation out there.) >> >> It's certainly *possible* that things end up fine in many well-deliniate= d >> cases where merging can be used. But it's more complicated to reason >> about, and I don't remmber seeing much previous discussion about the >> specifics of the double trust decision. >> >> -Ben >> >> > >> > JAR Server | OIDC Server | >> > ------------+------------+--------------+ >> > JAR Client | YES | NO | >> > OIDC Client | YES | YES | >> > >> > Breaking one out of the four possible combinations in a very >> predictable way is, I think, the best way to handle backwards compatibil= ity >> here. >> > >> > But between this issue and JAR=E2=80=99s problematic call for the valu= e of a >> request_uri to always be a JWT and be fetchable by the AS (neither of wh= ich >> are true in the case of PAR) makes me think we need to pull this back an= d >> rework those things, in a push back to the IESG=E2=80=99s comments. >> > >> > =E2=80=94 Justin >> > >> > >> > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan >> wrote: >> > > >> > > I agree with this, particularly the security concerns of merging. If >> we merge, we can much guarantee there will eventually be a security issu= e >> where an attacker is able to gain an advantage by adding a parameter to = the >> url query (which the server would then happily process if that parameter >> isn=E2=80=99t found inside the request object). Ruling out that case mak= es security >> analysis (particularly when creating new OAuth2 parameters) significantl= y >> simpler. >> > > >> > > Putting the iss in the JWE header and having the client_id duplicate= d >> outside the request object seem to address all the concerns I=E2=80=99ve= seen >> raised. >> > > >> > > (It seems like it may be unnecessary to have the client_id duplicate= d >> outside if the request_uri is a PAR one though.) >> > > >> > > Joseph >> > > >> > > >> > > >> > >> On 16 Jan 2020, at 22:40, John Bradley wrote: >> > >> >> > >> I agree with the IESG reasoning that merging is problimatic. Once = we >> > >> allow that given a unknown list of possible paramaters with diffren= t >> > >> security properties it would be quite difficult to specify safely. >> > >> >> > >> Query paramaters can still be sent outside the JAR, but if they are >> in >> > >> the OAuth registry the AS MUST ignore them. >> > >> >> > >> Puting the iss in the JWE headder addresses the encryption issue >> without >> > >> merging. >> > >> >> > >> I understand that some existing servers have dependencys on getting >> the >> > >> clientID as a query paramater. >> > >> >> > >> Is that the only paramater that people have a issue with as oposed >> to a >> > >> nice to have? >> > >> >> > >> Would allowing the AS to not ignore the clientID as a query >> paramater as >> > >> long as it matches the one inside the JAR, basicly the same as >> Connect >> > >> request object but for just the one paramater make life easier for >> the >> > >> servers? >> > >> >> > >> I am not promising a change but gathering info before proposing >> something. >> > >> >> > >> John B. >> > >> >> > >> >> > >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote: >> > >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote= : >> > >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote: >> > >>>>> Well, embedding a client_id claim in the JWE header in order to >> > >>>>> achieve "request parameters outside the request object should no= t >> be >> > >>>>> referred to" is like "putting the cart before the horse". Why do >> we >> > >>>>> have to avoid using the traditional client_id request parameter = so >> > >>>>> stubbornly? >> > >>>>> >> > >>>>> The last paragraph of Section 3.2.1 >> > >>>>> of RFC 6749 >> says >> > >>>>> as follows. >> > >>>>> >> > >>>>> /A client MAY use the "client_id" request parameter to identif= y >> > >>>>> itself when sending requests to the token endpoint. In the >> > >>>>> "authorization_code" "grant_type" request to the token endpoin= t, >> > >>>>> *an unauthenticated client MUST send its "client_id" to preven= t >> > >>>>> itself from inadvertently accepting a code intended for a clie= nt >> > >>>>> with a different "client_id".* This protects the client from >> > >>>>> substitution of the authentication code. (It provides no >> > >>>>> additional security for the protected resource.)/ >> > >>>>> >> > >>>>> >> > >>>>> If the same reasoning applies, a client_id must always be sent >> with >> > >>>>> request / request_uri because client authentication is not >> performed >> > >>>>> at the authorization endpoint. In other words, */an >> unauthenticated >> > >>>>> client (every client is unauthenticated at the authorization >> endpoint) >> > >>>>> MUST send its "client_id" to prevent itself from inadvertently >> > >>>>> accepting a request object for a client with a different >> "client_id"./* >> > >>>>> >> > >>>> Identifying the client in JAR request_uri requests can be really >> useful >> > >>>> so that an AS which requires request_uri registration to prevent >> DDoS >> > >>>> attacks and other checks can do those without having to index all >> > >>>> request_uris individually. I mentioned this before. >> > >>>> >> > >>>> I really wonder what the reasoning of the IESG reviewers was to >> insist >> > >>>> on no params outside the JAR JWT / request_uri. >> > >>>> >> > >>>> I'm beginning to realise this step of the review process isn't >> > >>>> particularly transparent to WG members. >> > >>> Could you expand on that a bit more? My understanding is that the >> IESG >> > >>> ballot mail gets copied to the WG precisely so that there is >> transparency, >> > >>> e.g., the thread starting at >> > >>> >> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI >> > >>> Which admittely is from almost three years ago, but that's the >> earliest >> > >>> that I found that could be seen as the source of this behavior. >> > >>> >> > >>> -Ben >> > >>> >> > >>> P.S. some other discussion at >> > >>> >> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 >> and >> > >>> >> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY >> and >> > >>> so on. >> > >>> >> > >>> _______________________________________________ >> > >>> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000009d7402059f5d1847 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, where should we take it to?=C2=A0
Just add back cl= ient_id as it used=C2=A0to be?

On Fri, Jan 24, 2020 at 6:55 AM John Br= adley <ve7jtb@ve7jtb.com> wr= ote:

---------- Forwarded message ---------
From: John Bradley <ve7jtb@ve7jtb.com&= gt;
Date: Sat, Jan 18, 2020, 9:31 PM
Subject: Re: [OAUTH-WG] [= EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request objec= t
To: Benjamin Kaduk <kaduk@mit.edu>


If you put the = iss in the JWE header it is integrity protected, as JWE only=C2=A0supports = AAD encryption algs.

It is more of a problem when the cl= ient is sending a requestURI in that case having the clientID in the GET to= the Authorization endpoint is useful.

I think the= re is a argument=C2=A0for explicitly allowing the clientID as long as it ex= actly matches the clientID in the JAR.

John B.

On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk <kaduk@mit.edu> wrot= e:
On Fri, Jan 1= 7, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> I don=E2=80=99t agree with this stance from a security or implementati= on perspective.
>
> If there=E2=80=99s a clear order of precedence for the information, it= =E2=80=99s not particularly problematic. Everything inside the request obje= ct is to be taken over things outside the request object. We have the exact= same semantics and process with dynamic registration, where the software s= tatement is carried alongside plain JSON claims, and the two are mixed with= a very simple algorithm:
>
>=C2=A0 - If a field is inside the signed payload, use that value and ig= nore any copy of it on the outside
>=C2=A0 - If a field is not inside the signed payload and is outside the= signed payload, use the outside value
>
> Can someone please point out a concrete security issue with this algor= ithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics that we n= eed here, and it would solve not only the ability to use this for use cases= that call for a more static request object (perhaps signed by a third part= y and not the client) along side the plain parameters that can vary, but al= so the backwards compatibility issue that=E2=80=99s been discussed. With th= is algorithm in place, you could have OIDC clients actually be compliant wi= th the spec, since OIDC requires replication of the values inside the reque= st object on the outside with exact matches. An OIDC server wouldn=E2=80=99= t be fully compliant with the new spec since it would reject some compliant= JAR requests that are missing the external parameters, but that=E2=80=99s = fairly easy logic to add on the OIDC side. And in that case you get a matri= x of compatibility like:

I agree that the merge algorithm is simple and fairly straightforward to implement.=C2=A0 But, as Joseph has been alluding, it's only simple if = you've
already made the decision to use all the parameters, both from inside and from outside the signed payload.=C2=A0 The security risk lies about having = to
make the trust decision twice, more than the mundane details of actually doing the merge.=C2=A0 (Though there is still some latent risk, given that = we've
seen some really crazy quality of implementation out there.)

It's certainly *possible* that things end up fine in many well-deliniat= ed
cases where merging can be used.=C2=A0 But it's more complicated to rea= son
about, and I don't remmber seeing much previous discussion about the specifics of the double trust decision.

-Ben

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JAR Server | OID= C Server=C2=A0 |
> ------------+------------+--------------+
> JAR Client=C2=A0 |=C2=A0 =C2=A0 =C2=A0YES=C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 NO=C2=A0 =C2=A0 =C2=A0 |
> OIDC Client |=C2=A0 =C2=A0 =C2=A0YES=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0YES=C2=A0 =C2=A0 =C2=A0 |
>
> Breaking one out of the four possible combinations in a very predictab= le way is, I think, the best way to handle backwards compatibility here. >
> But between this issue and JAR=E2=80=99s problematic call for the valu= e of a request_uri to always be a JWT and be fetchable by the AS (neither o= f which are true in the case of PAR) makes me think we need to pull this ba= ck and rework those things, in a push back to the IESG=E2=80=99s comments.<= br> >
>=C2=A0 =E2=80=94 Justin
>
>
> > On Jan 16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.c= om> wrote:
> >
> > I agree with this, particularly the security concerns of merging.= If we merge, we can much guarantee there will eventually be a security iss= ue where an attacker is able to gain an advantage by adding a parameter to = the url query (which the server would then happily process if that paramete= r isn=E2=80=99t found inside the request object). Ruling out that case make= s security analysis (particularly when creating new OAuth2 parameters) sign= ificantly simpler.
> >
> > Putting the iss in the JWE header and having the client_id duplic= ated outside the request object seem to address all the concerns I=E2=80=99= ve seen raised.
> >
> > (It seems like it may be unnecessary to have the client_id duplic= ated outside if the request_uri is a PAR one though.)
> >
> > Joseph
> >
> >
> >
> >> On 16 Jan 2020, at 22:40, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >>
> >> I agree with the IESG reasoning that merging is problimatic.= =C2=A0 Once we
> >> allow that given a unknown list of possible paramaters with d= iffrent
> >> security properties it would be quite difficult to specify sa= fely.
> >>
> >> Query paramaters can still be sent outside the JAR, but if th= ey are in
> >> the OAuth registry the AS MUST ignore them.
> >>
> >> Puting the iss in the JWE headder addresses the encryption is= sue without
> >> merging.
> >>
> >> I understand that some existing servers have dependencys on g= etting the
> >> clientID as a query paramater.
> >>
> >> Is that the only paramater that people have a issue with as o= posed to a
> >> nice to have?
> >>
> >> Would allowing the AS to not ignore the clientID as a query p= aramater as
> >> long as it matches the one inside the JAR, basicly the same a= s Connect
> >> request object but for just the one paramater make life easie= r for the
> >> servers?
> >>
> >> I am not promising a change but gathering info before proposi= ng something.
> >>
> >> John B.
> >>
> >>
> >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
> >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvi= nov wrote:
> >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> >>>>> Well, embedding a client_id claim in the JWE head= er in order to
> >>>>> achieve "request parameters outside the requ= est object should not be
> >>>>> referred to" is like "putting the cart = before the horse". Why do we
> >>>>> have to avoid using the traditional client_id req= uest parameter so
> >>>>> stubbornly?
> >>>>>
> >>>>> The last paragraph of Section 3.2.1
> >>>>> <https://to= ols.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says
> >>>>> as follows.
> >>>>>
> >>>>>=C2=A0 =C2=A0/A client MAY use the "client_id= " request parameter to identify
> >>>>>=C2=A0 =C2=A0itself when sending requests to the t= oken endpoint.=C2=A0 In the
> >>>>>=C2=A0 =C2=A0"authorization_code" "= grant_type" request to the token endpoint,
> >>>>>=C2=A0 =C2=A0*an unauthenticated client MUST send = its "client_id" to prevent
> >>>>>=C2=A0 =C2=A0itself from inadvertently accepting a= code intended for a client
> >>>>>=C2=A0 =C2=A0with a different "client_id"= ;.*=C2=A0 This protects the client from
> >>>>>=C2=A0 =C2=A0substitution of the authentication co= de.=C2=A0 (It provides no
> >>>>>=C2=A0 =C2=A0additional security for the protected= resource.)/
> >>>>>
> >>>>>
> >>>>> If the same reasoning applies, a client_id must a= lways be sent with
> >>>>> request / request_uri because client authenticati= on is not performed
> >>>>> at the authorization endpoint. In other words, */= an unauthenticated
> >>>>> client (every client is unauthenticated at the au= thorization endpoint)
> >>>>> MUST send its "client_id" to prevent it= self from inadvertently
> >>>>> accepting a request object for a client with a di= fferent "client_id"./*
> >>>>>
> >>>> Identifying the client in JAR request_uri requests ca= n be really useful
> >>>> so that an AS which requires request_uri registration= to prevent DDoS
> >>>> attacks and other checks can do those without having = to index all
> >>>> request_uris individually. I mentioned this before. > >>>>
> >>>> I really wonder what the reasoning of the IESG review= ers was to insist
> >>>> on no params outside the JAR JWT / request_uri.
> >>>>
> >>>> I'm beginning to realise this step of the review = process isn't
> >>>> particularly transparent to WG members.
> >>> Could you expand on that a bit more?=C2=A0 My understandi= ng is that the IESG
> >>> ballot mail gets copied to the WG precisely so that there= is transparency,
> >>> e.g., the thread starting at
> >>> = https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI=
> >>> Which admittely is from almost three years ago, but that&= #39;s the earliest
> >>> that I found that could be seen as the source of this beh= avior.
> >>>
> >>> -Ben
> >>>
> >>> P.S. some other discussion at
> >>> = https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8= and
> >>> = https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY= and
> >>> so on.
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman= /listinfo/oauth
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/l= istinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinf= o/oauth
>

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

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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--0000000000009d7402059f5d1847-- From nobody Mon Feb 24 20:53:49 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAB23A0985 for ; Mon, 24 Feb 2020 20:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" 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 wyrqkvgv0966 for ; Mon, 24 Feb 2020 20:53:45 -0800 (PST) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686B23A0983 for ; Mon, 24 Feb 2020 20:53:45 -0800 (PST) Received: by mail-pl1-x643.google.com with SMTP id a6so4982365plm.3 for ; Mon, 24 Feb 2020 20:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:subject:message-id:from:to:cc:mime-version; bh=qpKMfEcJhM7F0FfuZ8Ok1sXC+9q0ivWMaUAbhV4wf7E=; b=DUOT4IJShQKsqs6zqa7m7I0NjW8pOw1alRgrz+6kFNXfqgenqLSVsdBzqD5G3ftlEf 2WtsdEKW13jCPOuvXub9tyNkUBCMo5XckdR5F8aOWwleHEh5QexetM6EAgxiYEVAPyn5 ZV0vVSmFPkQ94KmKmFGZToc9Tm+y+4KpECwHxeQGO0aQcJyCrFvyWDcLmnJXUdnl7KLJ JcLU4bOA9wfiZXIrIZwfAg0W5NfOSYQ8MEiXesQJrx74eh89dn8+HProV4tgr+SR5e+T x9wi4nukMjItAGceceie7gwn0KsaV3zEHTRT7snaKT/JXLwbbZCNDq/l5cCOVToOyGSI zJpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:message-id:from:to:cc:mime-version; bh=qpKMfEcJhM7F0FfuZ8Ok1sXC+9q0ivWMaUAbhV4wf7E=; b=ClgUkNSmQAvQDi3jhlx6a0zOpKWb4H6jeKQc/s0R8iqLb9A05xeKsvYBy7RW+B90bk BRvyYsQN1dxHf6pfr/pUXasvLS7jzI32awt1bbzBYnrfAOd5j9/e4ad0zICR9IBQy/8o mlO8ysiWTWpuIGbHpztexXZ87WWtcrgPLC5weqZz+4QeN5u/kh/lHBL0mmpYKT0dHK6K kuIrl8Y1Kl7AteDsyCSyfJi74lXObe5pBEpEzfBDtfLKyNmdcgxgu5Fc38tLXf9PyxI4 D7pxxXpnflzqtHzkIcdSGLuI8KQP3aoVVqvsHwuYO2buXb9VaMeik48seftdAkOE39B0 Z5tw== X-Gm-Message-State: APjAAAX9o+jCD4sWqQq0KKADDyaFLUHEZQgFiO7yLd9fBl5rUuJ5hCmi UcnREQLHZvNE8rA3cQ0FCEc= X-Google-Smtp-Source: APXvYqwEqxdb+EMfA1ZE2dlOlPFFFIgIJ33nEACR/JxL3xxIUoYx652emKnyIr3KI93PmyyySDnB3Q== X-Received: by 2002:a17:90a:c706:: with SMTP id o6mr2867962pjt.82.1582606424687; Mon, 24 Feb 2020 20:53:44 -0800 (PST) Received: from ?IPv6:2600:380:c020:e687:2ad7:a632:95cd:5c16? ([2600:380:c020:e687:2ad7:a632:95cd:5c16]) by smtp.gmail.com with ESMTPSA id k9sm15135753pfh.153.2020.02.24.20.53.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2020 20:53:43 -0800 (PST) Date: Mon, 24 Feb 2020 20:53:37 -0800 Message-ID: From: "lanerashaad80@gmail.com" To: Brian Campbell , Neil Madden Cc: Matthew De Haast , oauth@ietf.org, "Richard Backman, Annabelle" MIME-Version: 1.0 X-Priority: 3 Content-Type: multipart/alternative; boundary="--_com.lge.email_1665507008870670" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 04:53:48 -0000 ----_com.lge.email_1665507008870670 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sent from my LG Stylo 5+, an AT&T 4G LTE smartphone------ Original message------From: Brian CampbellDate: Mon, Feb 24, 2020 9:04 AMTo: Neil Madden;Cc: Matthew De Haast;oauth@ietf.org;Richard Backman, Annabelle;Subject:Re: [OAUTH-WG] OAuth 2.1: dropping password grantConcur with the sentiment expressed by Neil here. On Fri, Feb 21, 2020 at 3:32 PM Neil Madden wrote:I’m not really sure the WG should be telling people what they “ought to be doing” unless we have concrete security or interoperability reasons for doing so. I also don’t agree that people doing this are doing anything wrong. I don’t always agree with what our customers do, but I’ve learnt over the years not to second-guess their reasons for doing it. Are Google wrong for using the JWT bearer grant (not client credentials) and service accounts? They even go so far as to say “scopes are not a security mechanism” [1] and tell people to use service account roles instead. (Precisely because they also support non-OAuth auth methods, which bypass any scopes). Are we really going to tell them to rewrite it all to use the client credentials grant? [1]: https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam > On 21 Feb 2020, at 21:04, Justin Richer wrote: > > +1. I’ve seen this anti-pattern deployed all over the place, and it’s time to get rid of it and send people toward what they really ought to be doing. > > Another thing I’ve seen is using different service accounts to get different sets of access for one client — if you’re doing that, you’ve got a client pretending to do two different things, or your APIs should be using scopes to differentiate access instead of client/user identity. > > — Justin > >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: >> >> The client IDs can still be opaque identifiers provided by the AS, they just happen to be associated with specific service accounts. Or they could be the opaque IDs that the AS already issued for the service account. Either way, the AS could issue a token with the appropriate subject and other claims for the service account. >> >> If your client identity is bound to a specific service account identity (i.e., the resource owner), then ROPC reduces down to Client Credentials. What's the point in passing two identifiers and two credentials for the same identity? >> >> – >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> >> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" wrote: >> >>   Sorry, I missed that message. >> >>   While this may be a solution in specific circumstances, I don’t think it’s a general solution. e.g. an AS may not allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or may return different introspection results for client credentials tokens (e.g. with no “sub”) and so on. In practice, this adds even more steps for somebody to migrate from existing ROPC usage. >> >>   This is asking people to make fundamental changes to their identity architecture rather than simply switching to a new grant type.. >> >>   — Neil >> >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt wrote: >>> >>> I see - we have gone full cycle :-) >>> >>> Annabelle’s proposal would solve that. Relate a client id to a service account and obtain the token data from there. >>> >>>> On 21. Feb 2020, at 15:31, Neil Madden wrote: >>>> >>>> Yes, that is great. But mTLS doesn’t support service accounts (!= clients). Maybe it should? Should there be a mTLS *grant type*? >>>> >>>> — Neil >>>> >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt wrote: >>>>> >>>>> Have you ever tried the client credentials grant with mTLS? After reading your description it seems to be simpler than JWT Bearer.. >>>>> >>>>> * work out if the AS even supports mTLS >>>>> * work out how to configure the AS to trust my cert(s) >>>>> * Create key pair and cert using openssl >>>>> * Register your (self-signed) cert along with your client_id >>>>> * Configure the HTTP client to use your key pair for TLS Client Authentication >>>>> >>>>> Works very well for us. >>>>> >>>>>> On 21. Feb 2020, at 15:12, Neil Madden wrote: >>>>>> >>>>>> No failures, but it is a much more complex grant type to set up, when you consider everything you have to do: >>>>>> >>>>>> * work out if the AS even supports JWT bearer and how to turn it on >>>>>> * work out how to configure the AS to trust my public key(s) >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>>>>> * determine the correct settings for issuer, audience, subject, etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT MUST contain a “sub” claim, but Google only allows this to be present if your client is doing impersonation of an end-user (which requires additional permissions). >>>>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might not) If I do, can I reuse the JWT or must it be freshly signed for every call? >>>>>> * locate and evaluate a JWT library for my language of choice. Monitor that new dependency for security advisories. >>>>>> * choose a suitable signature algorithm (‘ere be dragons) >>>>>> * figure out how to distribute the private key to my service >>>>>> >>>>>> Compared to “create a service account and POST the username and password to the token endpoint” it adds a little friction. (It also adds a lot of advantages, but it is undeniably more complex). >>>>>> >>>>>> — Neil >>>>>> >>>>>> >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast 40coil.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> I have a feeling that if we had more concise JWT libraries and command line tools, where using the JWT Bearer grant became a one-liner again then we wouldn’t be having this conversation. So perhaps removing it is an incentive to make that happen. >>>>>>> >>>>>>> Neil could you elaborate more on this please. What failures are you currently experiencing/seeing with the JWT Bearer grant? >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden wrote: >>>>>>> I have a feeling that if we had more concise JWT libraries and command line tools, where using the JWT Bearer grant became a one-liner again then we wouldn’t be having this conversation. So perhaps removing it is an incentive to make that happen. >>>>>>> >>>>>>> >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt wrote: >>>>>>>> >>>>>>>> Neil: are you advocating that password grant be preserved in 2.1? Or do you think that service account developers know enough about what they are doing to follow what is in 6749? >>>>>>>> ᐧ >>>>>>>> >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden wrote: >>>>>>>> OAuth2 clients are often private to the AS - they live in a database that only the AS can access, have attributes specific to their use in OAuth2, and so on. Many existing systems have access controls based on users, roles, permissions and so on and expect all users accessing the system to exist in some user repository, e.g. LDAP, where they can be looked up and appropriate permissions determined. A service account can be created inside such a system as if it was a regular user, managed through the normal account provisioning tools, assigned permissions, roles, etc. >>>>>>>> >>>>>>>> Another reason is that sometimes OAuth is just one authentication option out of many, and so permissions assigned to service accounts are preferred over scopes because they are consistently applied no matter how a request is authenticated. This is often the case when OAuth has been retrofitted to an existing system and they need to preserve compatibility with already deployed clients. >>>>>>>> >>>>>>>> See e.g. Google cloud platform (GCP): https://developers.google.com/identity/protocols/OAuth2ServiceAccount >>>>>>>> They use the JWT bearer grant type for service account authentication and assign permissions to those service accounts and typically have very broad scopes. For service-to-service API calls you typically get an access token with a single scope that is effectively “all of GCP” and everything is managed at the level of permissions on the RO service account itself. They only break down fine-grained scopes when you are dealing with user data and will be getting an access token approved by a real user (through a normal auth code flow). >>>>>>>> >>>>>>>> — Neil >>>>>>>> >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt wrote: >>>>>>>>> >>>>>>>>> Can you explain more in detail why the client credentials grant type isn’t applicable for the kind of use cases you mentioned? >>>>>>>>> >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden : >>>>>>>>>> >>>>>>>>>> I very much agree with this with regards to real users. >>>>>>>>>> >>>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for service accounts - where you essentially want something like client_credentials but for whatever reason you need the RO to be a service user rather than an OAuth2 client (typically so that some lower layer of the system can still perform its required permission checks). >>>>>>>>>> >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but they are a bit harder to implement. Having recently converted some code from ROPC to JWT bearer for exactly this use-case, it went from a couple of lines of code to two screens of code. For service to service API calls within a datacenter I’m not convinced this resulted in a material increase in security for the added complexity. >>>>>>>>>> >>>>>>>>>> — Neil >>>>>>>>>> >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt wrote: >>>>>>>>>>> >>>>>>>>>>> I would also seriously look at the original motivation behind ROPC: I know it has been deployed and is used in quite a lot of places but I have never actually come across a use case where it is used for migration purposes and the migration is actually executed (I know that is statistically not a very strong argument but I challenge others to come up with one...) >>>>>>>>>>> In reality it turned out just to be a one off that people used as an easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it. >>>>>>>>>>> >>>>>>>>>>> Hans. >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote: >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting as a grace period since it currently says the password grant MUST NOT be used, so in the OAuth 2.0 world that's already a pretty strong signal.. >>>>>>>>>>> >>>>>>>>>>> Aaron >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1. >>>>>>>>>>> >>>>>>>>>>> — Justin >>>>>>>>>>> >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still sites using this and a grace period should be provided before a MUST is pushed out as there are valid use cases out there still. >>>>>>>>>>>> >>>>>>>>>>>> From: OAuth On Behalf Of Dick Hardt >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>>>>>>>>>>> To: oauth@ietf.org >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >>>>>>>>>>>> >>>>>>>>>>>> Hey List >>>>>>>>>>>> >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on) >>>>>>>>>>>> >>>>>>>>>>>> In the security topics doc >>>>>>>>>>>> >>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4 >>>>>>>>>>>> >>>>>>>>>>>> The password grant MUST not be used. >>>>>>>>>>>> >>>>>>>>>>>> Some background for those interested. I added this grant into OAuth 2.0 to allow applications that had been provided password to migrate. Even with the caveats in OAuth 2.0, implementors decide they want to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Does anyone have concerns with dropping the password grant from the OAuth 2.1 document so that developers don't use it? >>>>>>>>>>>> >>>>>>>>>>>> /Dick >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> -- >>>>>>>>>>> ---- >>>>>>>>>>> Aaron Parecki >>>>>>>>>>> aaronparecki.com >>>>>>>>>>> @aaronpk >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> hans.zandbelt@zmartzone.eu >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> >> >> _______________________________________________ >> 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. ----_com.lge.email_1665507008870670 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Sent from my LG Stylo 5+, an AT&T 4G LTE smartphone

------ Original message------
From: Brian Campbell
Date: Mon, Feb 24, 2020 9:04 AM
To: Neil Madden;
Cc: Matthew De Haast;oauth@ietf.org;Richard Backman, Annabelle;
Subject:Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote:
I’m not really sure the WG should be telling people what they “ought to be doing” unless we have concrete security or interoperability reasons for doing so.

I also don’t agree that people doing this are doing anything wrong. I don’t always agree with what our customers do, but I’ve learnt over the years not to second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) and service accounts? They even go so far as to say “scopes are not a security mechanism” [1] and tell people to use service account roles instead. (Precisely because they also support non-OAuth auth methods, which bypass any scopes).

Are we really going to tell them to rewrite it all to use the client credentials grant?

[1]: https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam

> On 21 Feb 2020, at 21:04, Justin Richer <jricher@mit.edu> wrote:
>
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time to get rid of it and send people toward what they really ought to be doing.
>
> Another thing I’ve seen is using different service accounts to get different sets of access for one client — if you’re doing that, you’ve got a client pretending to do two different things, or your APIs should be using scopes to differentiate access instead of client/user identity.
>
> — Justin
>
>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote:
>>
>> The client IDs can still be opaque identifiers provided by the AS, they just happen to be associated with specific service accounts. Or they could be the opaque IDs that the AS already issued for the service account. Either way, the AS could issue a token with the appropriate subject and other claims for the service account.
>>
>> If your client identity is bound to a specific service account identity (i.e., the resource owner), then ROPC reduces down to Client Credentials. What's the point in passing two identifiers and two credentials for the same identity?
>>
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>>
>>
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote:
>>
>>   Sorry, I missed that message.
>>
>>   While this may be a solution in specific circumstances, I don’t think it’s a general solution. e.g. an AS may not allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or may return different introspection results for client credentials tokens (e.g. with no “sub”) and so on. In practice, this adds even more steps for somebody to migrate from existing ROPC usage.
>>
>>   This is asking people to make fundamental changes to their identity architecture rather than simply switching to a new grant type..
>>
>>   — Neil
>>
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>
>>> I see - we have gone full cycle :-)
>>>
>>> Annabelle’s proposal would solve that. Relate a client id to a service account and obtain the token data from there.
>>>
>>>> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>
>>>> Yes, that is great. But mTLS doesn’t support service accounts (!= clients). Maybe it should? Should there be a mTLS *grant type*?
>>>>
>>>> — Neil
>>>>
>>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>>
>>>>> Have you ever tried the client credentials grant with mTLS? After reading your description it seems to be simpler than JWT Bearer..
>>>>>
>>>>> * work out if the AS even supports mTLS
>>>>> * work out how to configure the AS to trust my cert(s)
>>>>> * Create key pair and cert using openssl
>>>>> * Register your (self-signed) cert along with your client_id
>>>>> * Configure the HTTP client to use your key pair for TLS Client Authentication
>>>>>
>>>>> Works very well for us.
>>>>>
>>>>>> On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>>>
>>>>>> No failures, but it is a much more complex grant type to set up, when you consider everything you have to do:
>>>>>>
>>>>>> * work out if the AS even supports JWT bearer and how to turn it on
>>>>>> * work out how to configure the AS to trust my public key(s)
>>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>>>>>> * determine the correct settings for issuer, audience, subject, etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT MUST contain a “sub” claim, but Google only allows this to be present if your client is doing impersonation of an end-user (which requires additional permissions).
>>>>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might not) If I do, can I reuse the JWT or must it be freshly signed for every call?
>>>>>> * locate and evaluate a JWT library for my language of choice. Monitor that new dependency for security advisories.
>>>>>> * choose a suitable signature algorithm (‘ere be dragons)
>>>>>> * figure out how to distribute the private key to my service
>>>>>>
>>>>>> Compared to “create a service account and POST the username and password to the token endpoint” it adds a little friction. (It also adds a lot of advantages, but it is undeniably more complex).
>>>>>>
>>>>>> — Neil
>>>>>>
>>>>>>
>>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast 40coil.com@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>> I have a feeling that if we had more concise JWT libraries and command line tools, where using the JWT Bearer grant became a one-liner again then we wouldn’t be having this conversation. So perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>> Neil could you elaborate more on this please. What failures are you currently experiencing/seeing with the JWT Bearer grant?
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <neil.madden@forgerock.com> wrote:
>>>>>>> I have a feeling that if we had more concise JWT libraries and command line tools, where using the JWT Bearer grant became a one-liner again then we wouldn’t be having this conversation. So perhaps removing it is an incentive to make that happen.
>>>>>>>
>>>>>>>
>>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Neil: are you advocating that password grant be preserved in 2.1? Or do you think that service account developers know enough about what they are doing to follow what is in 6749?
>>>>>>>> ᐧ
>>>>>>>>
>>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@forgerock.com> wrote:
>>>>>>>> OAuth2 clients are often private to the AS - they live in a database that only the AS can access, have attributes specific to their use in OAuth2, and so on. Many existing systems have access controls based on users, roles, permissions and so on and expect all users accessing the system to exist in some user repository, e.g. LDAP, where they can be looked up and appropriate permissions determined. A service account can be created inside such a system as if it was a regular user, managed through the normal account provisioning tools, assigned permissions, roles, etc.
>>>>>>>>
>>>>>>>> Another reason is that sometimes OAuth is just one authentication option out of many, and so permissions assigned to service accounts are preferred over scopes because they are consistently applied no matter how a request is authenticated. This is often the case when OAuth has been retrofitted to an existing system and they need to preserve compatibility with already deployed clients.
>>>>>>>>
>>>>>>>> See e.g. Google cloud platform (GCP): https://developers.google.com/identity/protocols/OAuth2ServiceAccount
>>>>>>>> They use the JWT bearer grant type for service account authentication and assign permissions to those service accounts and typically have very broad scopes. For service-to-service API calls you typically get an access token with a single scope that is effectively “all of GCP” and everything is managed at the level of permissions on the RO service account itself. They only break down fine-grained scopes when you are dealing with user data and will be getting an access token approved by a real user (through a normal auth code flow).
>>>>>>>>
>>>>>>>> — Neil
>>>>>>>>
>>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>>>>>>
>>>>>>>>> Can you explain more in detail why the client credentials grant type isn’t applicable for the kind of use cases you mentioned?
>>>>>>>>>
>>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden <neil.madden@forgerock.com>:
>>>>>>>>>>
>>>>>>>>>> I very much agree with this with regards to real users.
>>>>>>>>>>
>>>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for service accounts - where you essentially want something like client_credentials but for whatever reason you need the RO to be a service user rather than an OAuth2 client (typically so that some lower layer of the system can still perform its required permission checks).
>>>>>>>>>>
>>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but they are a bit harder to implement. Having recently converted some code from ROPC to JWT bearer for exactly this use-case, it went from a couple of lines of code to two screens of code. For service to service API calls within a datacenter I’m not convinced this resulted in a material increase in security for the added complexity.
>>>>>>>>>>
>>>>>>>>>> — Neil
>>>>>>>>>>
>>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would also seriously look at the original motivation behind ROPC: I know it has been deployed and is used in quite a lot of places but I have never actually come across a use case where it is used for migration purposes and the migration is actually executed (I know that is statistically not a very strong argument but I challenge others to come up with one...)
>>>>>>>>>>> In reality it turned out just to be a one off that people used as an easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
>>>>>>>>>>>
>>>>>>>>>>> Hans.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <aaron@parecki.com> wrote:
>>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting as a grace period since it currently says the password grant MUST NOT be used, so in the OAuth 2.0 world that's already a pretty strong signal..
>>>>>>>>>>>
>>>>>>>>>>> Aaron
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrote:
>>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1.
>>>>>>>>>>>
>>>>>>>>>>> — Justin
>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still sites using this and a grace period should be provided before a MUST is pushed out as there are valid use cases out there still.
>>>>>>>>>>>>
>>>>>>>>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
>>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM
>>>>>>>>>>>> To: oauth@ietf.org
>>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant
>>>>>>>>>>>>
>>>>>>>>>>>> Hey List
>>>>>>>>>>>>
>>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)
>>>>>>>>>>>>
>>>>>>>>>>>> In the security topics doc
>>>>>>>>>>>>
>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
>>>>>>>>>>>>
>>>>>>>>>>>> The password grant MUST not be used.
>>>>>>>>>>>>
>>>>>>>>>>>> Some background for those interested. I added this grant into OAuth 2.0 to allow applications that had been provided password to migrate. Even with the caveats in OAuth 2.0, implementors decide they want to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone have concerns with dropping the password grant from the OAuth 2.1 document so that developers don't use it?
>>>>>>>>>>>>
>>>>>>>>>>>> /Dick
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>> --
>>>>>>>>>>> ----
>>>>>>>>>>> Aaron Parecki
>>>>>>>>>>> aaronparecki.com
>>>>>>>>>>> @aaronpk
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf..org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>
>>
>> _______________________________________________
>> 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.
----_com.lge.email_1665507008870670-- From nobody Tue Feb 25 00:33:32 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1343A0A1C for ; Tue, 25 Feb 2020 00:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=swissre.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfA3l68dzxRE for ; Tue, 25 Feb 2020 00:33:27 -0800 (PST) Received: from esa3.hc1106-67.c3s2.iphmx.com (esa3.hc1106-67.c3s2.iphmx.com [139.138.62.223]) (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 6ABC93A0A1A for ; Tue, 25 Feb 2020 00:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1582619607; x=1614155607; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=i/63xXo1eq34lmIZqMv6p6R8DyRhirDkexRHFfKFIR8=; b=L6ipmUlEr9a+6I7sBwSOPExF2l3O7uE4Nx3ASEHxxBLizDG2SC3mKMw7 EWgCQtzIc6WR/AoCtOJJ9KopoTGmVcWvI0/X68A/XpJK7FNsZyAf3142X v8RbFEgS4weBJJjUybf6dyoU/4Avk+NyHRyUJuMiq3hX6t2NhuLL/JSph 2PJFAgNhILTQMZbGw/aJg6Pju6cRZnKeg2gGjDh9aa7qQ4b6/etCvk1tX /5YzC9bYChf3gAWrx2KUnUucadL/gMXVH14rsDRdnNGzr+yGgiMudGIQt bpF3gJ2qvv2lo/Gqv5Z023xbA9euXRgnV9GZWahFymOfxkPUVpPGlgz1D g==; IronPort-SDR: lcQ31G7wV4753cXxBjzblzFKZ5l4uNSyE21U4U/YvgjXWhQsdCqkLYQBOvPY3gR8Pg5FqBNQ2t /xe+O5jcOM+KQ2H+JU8vq13iT1lMaBQsuZrToMsDOsHPzUMrgCtWJS5l0HYNWfdd7eftXORVJg pTVK3kSwPLABkjHOUVDmv1Pd05Nd+VY7tk/rMjJsP3DVv7rnILxruYLw5UqtOf8yHEgL/w0Aws fhY1c4Rm0Pw4vmdge9zbrTeuvOwxG/oo715wpAi3MI6v98N1yFlEtlpOLsAaXOnYI8OgZ5CKE9 sHI= X-Amp-Result: SKIPPED(no attachment in message) Received: from edge.swissre.com ([193.246.239.101]) by esa3.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 25 Feb 2020 08:33:24 +0000 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by edge.swissre.com (193.246.239.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 25 Feb 2020 09:33:23 +0100 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5009.corp.gwpnet.com (10.53.1.44) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 25 Feb 2020 09:33:20 +0100 Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1497.000; Tue, 25 Feb 2020 09:33:20 +0100 From: Lee McGovern To: "oauth@ietf.org" Thread-Topic: OAuth Digest, Vol 136, Issue 31 Thread-Index: AQHV63ZnyKJJW6ybskaDjxDkOzeChqgrlV3g Date: Tue, 25 Feb 2020 08:33:20 +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_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2020-02-25T08:33:18.9372049Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.62.28.10] x-rcom-deduphash: a4346d8d-0090-4ded-9c99-3a1b55df94a0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-GBS-PROC: 2hq/bq6V77WAjFgw5xSV5H9YUOyRjtR2WGAraag/d9c= Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 31 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 08:33:32 -0000 I agree with Bruno and Dick regarding version compliance -----Original Message----- From: OAuth On Behalf Of oauth-request@ietf.org Sent: Dienstag, 25. Februar 2020 01:56 To: oauth@ietf.org Subject: OAuth Digest, Vol 136, Issue 31 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of OAuth digest..." Today's Topics: 1. Re: OAuth Digest, Vol 136, Issue 30 (Bruno Brito) ---------------------------------------------------------------------- Message: 1 Date: Mon, 24 Feb 2020 21:55:35 -0300 From: Bruno Brito To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 30 Message-ID: Content-Type: text/plain; charset=3D"utf-8" > a standard is more about documenting the current state of the art as deployed in existing implementations. For those whose still keep their ROPC grants working whats the problem abou= t be OAuth 2.0 compliant? And those who changes their implememntations, they will be OAuth 2.1 compli= ant, isn't simple? Afterall the show must go on. On Mon, Feb 24, 2020 at 9:14 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific = > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: OAuth 2.1: dropping password grant (Aaron Parecki) > > > > ---------- Forwarded message ---------- > From: Aaron Parecki > To: Brian Campbell > Cc: Neil Madden , Matthew De Haast 40coil.com@dmarc.ietf.org>, "oauth@ietf.org" , = > "Richard Backman, Annabelle" > Bcc: > Date: Mon, 24 Feb 2020 16:13:42 -0800 > Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant I think we = > might be going about this discussion the wrong way. > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Concur with the sentiment expressed by Neil here. >> >> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden = >> >> wrote: >> >>> I?m not really sure the WG should be telling people what they ?ought = >>> to be doing? unless we have concrete security or interoperability = >>> reasons for doing so. >> >> > I 100% agree that the job of a standard is not to tell people "what = > they ought to be doing". Instead, a standard is more about documenting = > the current state of the art as deployed in existing implementations. > > With that in mind, I think that leaves us with two concrete problems = > with the password grant: > > 1) The actual problem with the password grant is end users entering = > passwords in applications, which the group (mostly) agrees on > 2) People are re-appropriating the password grant for things like = > service accounts or backends that are inflexible, not actually using = > it for end user credentials > > So it seems like there's actually something missing from OAuth which = > is leading people to find the password grant and use that because it's = > the only thing that most closely fits their existing model. It seems = > like we'd be better off defining a new extension that captures the use = > case people are actually doing, instead of encouraging the continuing = > use of the password grant for this purpose. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Concur with the sentiment expressed by Neil here. >> >> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden = >> >> wrote: >> >>> I?m not really sure the WG should be telling people what they ?ought = >>> to be doing? unless we have concrete security or interoperability = >>> reasons for doing so. >>> >>> I also don?t agree that people doing this are doing anything wrong. = >>> I don?t always agree with what our customers do, but I?ve learnt = >>> over the years not to second-guess their reasons for doing it. >>> >>> Are Google wrong for using the JWT bearer grant (not client = >>> credentials) and service accounts? They even go so far as to say = >>> ?scopes are not a security mechanism? [1] and tell people to use = >>> service account roles instead. (Precisely because they also support = >>> non-OAuth auth methods, which bypass any scopes). >>> >>> Are we really going to tell them to rewrite it all to use the client = >>> credentials grant? >>> >>> [1]: >>> https://cloud.google.com/compute/docs/access/service-accounts#access >>> copesiam >>> >>> > On 21 Feb 2020, at 21:04, Justin Richer wrote: >>> > >>> > +1. I?ve seen this anti-pattern deployed all over the place, and = >>> > +it?s >>> time to get rid of it and send people toward what they really ought = >>> to be doing. >>> > >>> > Another thing I?ve seen is using different service accounts to get >>> different sets of access for one client ? if you?re doing that, = >>> you?ve got a client pretending to do two different things, or your = >>> APIs should be using scopes to differentiate access instead of client/u= ser identity. >>> > >>> > ? Justin >>> > >>> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle = >>> >> >> 40amazon.com@dmarc.ietf.org> wrote: >>> >> >>> >> The client IDs can still be opaque identifiers provided by the = >>> >> AS, >>> they just happen to be associated with specific service accounts. Or = >>> they could be the opaque IDs that the AS already issued for the service= account. >>> Either way, the AS could issue a token with the appropriate subject = >>> and other claims for the service account. >>> >> >>> >> If your client identity is bound to a specific service account >>> identity (i.e., the resource owner), then ROPC reduces down to = >>> Client Credentials. What's the point in passing two identifiers and = >>> two credentials for the same identity? >>> >> >>> >> ? >>> >> Annabelle Backman (she/her) >>> >> AWS Identity >>> >> https://aws.amazon.com/identity/ >>> >> >>> >> >>> >> ?On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < >>> oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com = >>> > wrote: >>> >> >>> >> Sorry, I missed that message. >>> >> >>> >> While this may be a solution in specific circumstances, I don?t >>> think it?s a general solution. e.g. an AS may not allow manually = >>> choosing the client_id to avoid things like >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#sect >>> ion-4.13 or may return different introspection results for client = >>> credentials tokens (e.g. with no ?sub?) and so on. In practice, this = >>> adds even more steps for somebody to migrate from existing ROPC = >>> usage. >>> >> >>> >> This is asking people to make fundamental changes to their = >>> >> identity >>> architecture rather than simply switching to a new grant type... >>> >> >>> >> ? Neil >>> >> >>> >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> >>> >>> I see - we have gone full cycle :-) >>> >>> >>> >>> Annabelle?s proposal would solve that. Relate a client id to a >>> service account and obtain the token data from there. >>> >>> >>> >>>> On 21. Feb 2020, at 15:31, Neil Madden = >>> >>>> >>> wrote: >>> >>>> >>> >>>> Yes, that is great. But mTLS doesn?t support service accounts = >>> >>>> (!=3D >>> clients). Maybe it should? Should there be a mTLS *grant type*? >>> >>>> >>> >>>> ? Neil >>> >>>> >>> >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>>> >>> >>>>> Have you ever tried the client credentials grant with mTLS? = >>> >>>>> After >>> reading your description it seems to be simpler than JWT Bearer... >>> >>>>> >>> >>>>> * work out if the AS even supports mTLS >>> >>>>> * work out how to configure the AS to trust my cert(s) >>> >>>>> * Create key pair and cert using openssl >>> >>>>> * Register your (self-signed) cert along with your client_id >>> >>>>> * Configure the HTTP client to use your key pair for TLS = >>> >>>>> Client >>> Authentication >>> >>>>> >>> >>>>> Works very well for us. >>> >>>>> >>> >>>>>> On 21. Feb 2020, at 15:12, Neil Madden = >>> >>>>>> >>> wrote: >>> >>>>>> >>> >>>>>> No failures, but it is a much more complex grant type to set = >>> >>>>>> up, >>> when you consider everything you have to do: >>> >>>>>> >>> >>>>>> * work out if the AS even supports JWT bearer and how to turn = >>> >>>>>> it >>> on >>> >>>>>> * work out how to configure the AS to trust my public key(s) >>> >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set? >>> >>>>>> * determine the correct settings for issuer, audience, = >>> >>>>>> subject, >>> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 = >>> says that the JWT MUST contain a ?sub? claim, but Google only allows = >>> this to be present if your client is doing impersonation of an = >>> end-user (which requires additional permissions). >>> >>>>>> * do I need a unique ?jti? claim? (OIDC servers do, plain = >>> >>>>>> OAuth >>> ones might not) If I do, can I reuse the JWT or must it be freshly = >>> signed for every call? >>> >>>>>> * locate and evaluate a JWT library for my language of choice. >>> Monitor that new dependency for security advisories. >>> >>>>>> * choose a suitable signature algorithm (?ere be dragons) >>> >>>>>> * figure out how to distribute the private key to my service >>> >>>>>> >>> >>>>>> Compared to ?create a service account and POST the username = >>> >>>>>> and >>> password to the token endpoint? it adds a little friction. (It also = >>> adds a lot of advantages, but it is undeniably more complex). >>> >>>>>> >>> >>>>>> ? Neil >>> >>>>>> >>> >>>>>> >>> >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast >> 40coil.com@dmarc.ietf.org> wrote: >>> >>>>>>> >>> >>>>>>> I have a feeling that if we had more concise JWT libraries = >>> >>>>>>> and >>> command line tools, where using the JWT Bearer grant became a = >>> one-liner again then we wouldn?t be having this conversation. So = >>> perhaps removing it is an incentive to make that happen. >>> >>>>>>> >>> >>>>>>> Neil could you elaborate more on this please. What failures = >>> >>>>>>> are >>> you currently experiencing/seeing with the JWT Bearer grant? >>> >>>>>>> >>> >>>>>>> Matt >>> >>>>>>> >>> >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden < >>> neil.madden@forgerock.com> wrote: >>> >>>>>>> I have a feeling that if we had more concise JWT libraries = >>> >>>>>>> and >>> command line tools, where using the JWT Bearer grant became a = >>> one-liner again then we wouldn?t be having this conversation. So = >>> perhaps removing it is an incentive to make that happen. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt >>> wrote: >>> >>>>>>>> >>> >>>>>>>> Neil: are you advocating that password grant be preserved = >>> >>>>>>>> in >>> 2.1? Or do you think that service account developers know enough = >>> about what they are doing to follow what is in 6749? >>> >>>>>>>> ? >>> >>>>>>>> >>> >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden < >>> neil.madden@forgerock.com> wrote: >>> >>>>>>>> OAuth2 clients are often private to the AS - they live in a >>> database that only the AS can access, have attributes specific to = >>> their use in OAuth2, and so on. Many existing systems have access = >>> controls based on users, roles, permissions and so on and expect all = >>> users accessing the system to exist in some user repository, e.g. = >>> LDAP, where they can be looked up and appropriate permissions = >>> determined. A service account can be created inside such a system as = >>> if it was a regular user, managed through the normal account provisioni= ng tools, assigned permissions, roles, etc. >>> >>>>>>>> >>> >>>>>>>> Another reason is that sometimes OAuth is just one >>> authentication option out of many, and so permissions assigned to = >>> service accounts are preferred over scopes because they are = >>> consistently applied no matter how a request is authenticated. This = >>> is often the case when OAuth has been retrofitted to an existing = >>> system and they need to preserve compatibility with already deployed cl= ients. >>> >>>>>>>> >>> >>>>>>>> See e.g. Google cloud platform (GCP): >>> https://developers.google.com/identity/protocols/OAuth2ServiceAccoun >>> t >>> >>>>>>>> They use the JWT bearer grant type for service account >>> authentication and assign permissions to those service accounts and = >>> typically have very broad scopes. For service-to-service API calls = >>> you typically get an access token with a single scope that is = >>> effectively ?all of GCP? and everything is managed at the level of = >>> permissions on the RO service account itself. They only break down = >>> fine-grained scopes when you are dealing with user data and will be = >>> getting an access token approved by a real user (through a normal auth = code flow). >>> >>>>>>>> >>> >>>>>>>> ? Neil >>> >>>>>>>> >>> >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>>>>>>> >>> >>>>>>>>> Can you explain more in detail why the client credentials >>> grant type isn?t applicable for the kind of use cases you mentioned? >>> >>>>>>>>> >>> >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden < >>> neil.madden@forgerock.com>: >>> >>>>>>>>>> >>> >>>>>>>>>> I very much agree with this with regards to real users. >>> >>>>>>>>>> >>> >>>>>>>>>> The one legitimate use-case for ROPC I?ve seen is for = >>> >>>>>>>>>> service >>> accounts - where you essentially want something like = >>> client_credentials but for whatever reason you need the RO to be a = >>> service user rather than an >>> OAuth2 client (typically so that some lower layer of the system can = >>> still perform its required permission checks). >>> >>>>>>>>>> >>> >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - = >>> >>>>>>>>>> but >>> they are a bit harder to implement. Having recently converted some = >>> code from ROPC to JWT bearer for exactly this use-case, it went from = >>> a couple of lines of code to two screens of code. For service to = >>> service API calls within a datacenter I?m not convinced this = >>> resulted in a material increase in security for the added complexity. >>> >>>>>>>>>> >>> >>>>>>>>>> ? Neil >>> >>>>>>>>>> >>> >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt < >>> hans.zandbelt@zmartzone.eu> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> I would also seriously look at the original motivation >>> behind ROPC: I know it has been deployed and is used in quite a lot = >>> of places but I have never actually come across a use case where it = >>> is used for migration purposes and the migration is actually = >>> executed (I know that is statistically not a very strong argument = >>> but I challenge others to come up with one...) >>> >>>>>>>>>>> In reality it turned out just to be a one off that = >>> >>>>>>>>>>> people >>> used as an easy way out to stick to an anti-pattern and still claim = >>> to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get = rid of it. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Hans. >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki < >>> aaron@parecki.com> wrote: >>> >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively = >>> >>>>>>>>>>> acting >>> as a grace period since it currently says the password grant MUST = >>> NOT be used, so in the OAuth 2.0 world that's already a pretty strong s= ignal.. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Aaron >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer < >>> jricher@mit.edu> wrote: >>> >>>>>>>>>>> There is no need for a grace period. People using OAuth = >>> >>>>>>>>>>> 2..0 >>> can still do OAuth 2.0. People using OAuth 2...1 will do OAuth 2.1. >>> >>>>>>>>>>> >>> >>>>>>>>>>> ? Justin >>> >>>>>>>>>>> >>> >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin >> 40microsoft.com@dmarc.ietf.org> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are >>> still sites using this and a grace period should be provided before = >>> a MUST is pushed out as there are valid use cases out there still. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> From: OAuth On Behalf Of Dick >>> Hardt >>> >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM >>> >>>>>>>>>>>> To: oauth@ietf.org >>> >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping = >>> >>>>>>>>>>>> password >>> grant >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Hey List >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder = >>> >>>>>>>>>>>> for >>> the doc that Aaron, Torsten, and I are working on) >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> In the security topics doc >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#sect >>> ion-2.4 >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> The password grant MUST not be used. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Some background for those interested. I added this = >>> >>>>>>>>>>>> grant >>> into OAuth 2.0 to allow applications that had been provided password = >>> to migrate. Even with the caveats in OAuth 2.0, implementors decide = >>> they want to prompt the user to enter their credentials, the = >>> anti-pattern OAuth was created to eliminate. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Does anyone have concerns with dropping the password = >>> >>>>>>>>>>>> grant >>> from the OAuth 2.1 document so that developers don't use it? >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> /Dick >>> >>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>> >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>> -- >>> >>>>>>>>>>> ---- >>> >>>>>>>>>>> Aaron Parecki >>> >>>>>>>>>>> aaronparecki.com @aaronpk >>> >>>>>>>>>>> >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> -- >>> >>>>>>>>>>> hans.zandbelt@zmartzone.eu ZmartZone IAM - = >>> >>>>>>>>>>> www.zmartzone.eu = >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> OAuth mailing list >>> >>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>> https://www.ietf...org/mailman/listinfo/oauth >>> >>> >>>>>>>> >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> 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 >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 136, Issue 31 ************************************** This e-mail, including attachments, is intended for the person(s) or compan= y named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful= and is prohibited. If you are not the intended recipient, please delete th= is message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electr= onic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re= , we strongly advise you not to use the Swiss Re e-mail account for any pri= vate, non-business related communications. From nobody Tue Feb 25 03:40:46 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD53A0A36 for ; Tue, 25 Feb 2020 03:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=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 clU7etlq6LOl for ; Tue, 25 Feb 2020 03:40:40 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AFF3A0A27 for ; Tue, 25 Feb 2020 03:40:40 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id a9so2811264wmj.3 for ; Tue, 25 Feb 2020 03:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UzUk/xTLEurB71WTvshuFUl6XWU6lIZRtkmMej1+hLA=; b=GONggUl6HSCYQGK2eAN3tiySTZOLc6PLt2Cyaz80G11O3IgPNte0/OZHqoBwnU8FtW IgZx/ETgHrsNb0pFgcM5QJp3PT7l47hZvxHf46ok5EurmVy7vkGmKcFOq7ZMO/IbvBFI aiP4U+AFd57KWYa1w1kHQnBpyR6ugdAFyB098= 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=UzUk/xTLEurB71WTvshuFUl6XWU6lIZRtkmMej1+hLA=; b=tq8NmGT6UAD03V1Pc4vXIwr6vsfbELFPqCs4TVu4fEAy+PBFW1sPrLe6FlQGiUUmvn gTojD81yeq5YZSbZXj44UtpMHdnx4JGRDpW5RvDXEbZrUX0fmCPs1nJx8HQcgrh2bv7Q RlKQSVDExK/gM0Iq0ylO2Md1xdcfhbkDsjknZp/cr8S78nP6VZUtrinrX8kEk/TAMZwK q1i2cajLrStnrpwGINhYHctFMXtG0GjIswH4wWKB0+ooGnx4tt9nuV2MeMXG5dij/sgu LOxpByFR/4SXQwUZwlMEsdhF25KD8vDL5xIIsXQpHUBmUr8qXCrxoNM6LZ3lQhqDTuzr jWgQ== X-Gm-Message-State: APjAAAUqM9mX/OnjyeVda/uQ/Cgsh7uksZHDECvbOY6GeZkoJdzfgPk5 iYmgI2bj/Oh1fbEGSXdAvVvSkQ== X-Google-Smtp-Source: APXvYqwcZDvYlorgghTy9DjNLUPDLsMBZk2HsvVFP4s7sah9RBwtW64iNK363YHyN8gZDWD7OagsnA== X-Received: by 2002:a1c:6389:: with SMTP id x131mr4763170wmb.174.1582630838008; Tue, 25 Feb 2020 03:40:38 -0800 (PST) Received: from zaphod.home.gateway (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id c6sm7224828wrx.39.2020.02.25.03.40.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 03:40:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Neil Madden In-Reply-To: Date: Tue, 25 Feb 2020 11:40:35 +0000 Cc: Brian Campbell , Matthew De Haast , "oauth@ietf.org" , "Richard Backman, Annabelle" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> To: Aaron Parecki X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 11:40:45 -0000 I=E2=80=99d be open to defining a new service_account grant type and = removing/deprecating the ROPC grant. I=E2=80=99d also be happy if we = just said that service account flows should use the JWT bearer grant, = and we document the best practices around that and encourage client libs = to implement support for it. Should there be a dedicated draft for best practices for = service-to-service usage? =E2=80=94 Neil > On 25 Feb 2020, at 00:13, Aaron Parecki wrote: >=20 > I think we might be going about this discussion the wrong way. >=20 > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell = wrote: > Concur with the sentiment expressed by Neil here.=20 >=20 > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden = wrote: > I=E2=80=99m not really sure the WG should be telling people what they = =E2=80=9Cought to be doing=E2=80=9D unless we have concrete security or = interoperability reasons for doing so. >=20 > I 100% agree that the job of a standard is not to tell people "what = they ought to be doing". Instead, a standard is more about documenting = the current state of the art as deployed in existing implementations. >=20 > With that in mind, I think that leaves us with two concrete problems = with the password grant: >=20 > 1) The actual problem with the password grant is end users entering = passwords in applications, which the group (mostly) agrees on > 2) People are re-appropriating the password grant for things like = service accounts or backends that are inflexible, not actually using it = for end user credentials >=20 > So it seems like there's actually something missing from OAuth which = is leading people to find the password grant and use that because it's = the only thing that most closely fits their existing model. It seems = like we'd be better off defining a new extension that captures the use = case people are actually doing, instead of encouraging the continuing = use of the password grant for this purpose. >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 >=20 >=20 > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell = wrote: > Concur with the sentiment expressed by Neil here.=20 >=20 > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden = wrote: > I=E2=80=99m not really sure the WG should be telling people what they = =E2=80=9Cought to be doing=E2=80=9D unless we have concrete security or = interoperability reasons for doing so. >=20 > I also don=E2=80=99t agree that people doing this are doing anything = wrong. I don=E2=80=99t always agree with what our customers do, but = I=E2=80=99ve learnt over the years not to second-guess their reasons for = doing it. >=20 > Are Google wrong for using the JWT bearer grant (not client = credentials) and service accounts? They even go so far as to say = =E2=80=9Cscopes are not a security mechanism=E2=80=9D [1] and tell = people to use service account roles instead. (Precisely because they = also support non-OAuth auth methods, which bypass any scopes). >=20 > Are we really going to tell them to rewrite it all to use the client = credentials grant? >=20 > [1]: = https://cloud.google.com/compute/docs/access/service-accounts#accesscopesi= am >=20 > > On 21 Feb 2020, at 21:04, Justin Richer wrote: > >=20 > > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, = and it=E2=80=99s time to get rid of it and send people toward what they = really ought to be doing. > >=20 > > Another thing I=E2=80=99ve seen is using different service accounts = to get different sets of access for one client =E2=80=94 if you=E2=80=99re= doing that, you=E2=80=99ve got a client pretending to do two different = things, or your APIs should be using scopes to differentiate access = instead of client/user identity.=20 > >=20 > > =E2=80=94 Justin > >=20 > >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle = wrote: > >>=20 > >> The client IDs can still be opaque identifiers provided by the AS, = they just happen to be associated with specific service accounts. Or = they could be the opaque IDs that the AS already issued for the service = account. Either way, the AS could issue a token with the appropriate = subject and other claims for the service account. > >>=20 > >> If your client identity is bound to a specific service account = identity (i.e., the resource owner), then ROPC reduces down to Client = Credentials. What's the point in passing two identifiers and two = credentials for the same identity? > >>=20 > >> =E2=80=93 > >> Annabelle Backman (she/her) > >> AWS Identity > >> https://aws.amazon.com/identity/ > >>=20 > >>=20 > >> =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" = wrote: > >>=20 > >> Sorry, I missed that message.=20 > >>=20 > >> While this may be a solution in specific circumstances, I don=E2=80= =99t think it=E2=80=99s a general solution. e.g. an AS may not allow = manually choosing the client_id to avoid things like = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.= 13 or may return different introspection results for client credentials = tokens (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this = adds even more steps for somebody to migrate from existing ROPC usage. > >>=20 > >> This is asking people to make fundamental changes to their = identity architecture rather than simply switching to a new grant type.. > >>=20 > >> =E2=80=94 Neil > >>=20 > >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt = wrote: > >>>=20 > >>> I see - we have gone full cycle :-)=20 > >>>=20 > >>> Annabelle=E2=80=99s proposal would solve that. Relate a client id = to a service account and obtain the token data from there.=20 > >>>=20 > >>>> On 21. Feb 2020, at 15:31, Neil Madden = wrote: > >>>>=20 > >>>> Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (!=3D clients). Maybe it should? Should there be a mTLS *grant = type*? > >>>>=20 > >>>> =E2=80=94 Neil > >>>>=20 > >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt = wrote: > >>>>>=20 > >>>>> Have you ever tried the client credentials grant with mTLS? = After reading your description it seems to be simpler than JWT Bearer.. > >>>>>=20 > >>>>> * work out if the AS even supports mTLS > >>>>> * work out how to configure the AS to trust my cert(s) > >>>>> * Create key pair and cert using openssl > >>>>> * Register your (self-signed) cert along with your client_id > >>>>> * Configure the HTTP client to use your key pair for TLS Client = Authentication > >>>>>=20 > >>>>> Works very well for us.=20 > >>>>>=20 > >>>>>> On 21. Feb 2020, at 15:12, Neil Madden = wrote: > >>>>>>=20 > >>>>>> No failures, but it is a much more complex grant type to set = up, when you consider everything you have to do: > >>>>>>=20 > >>>>>> * work out if the AS even supports JWT bearer and how to turn = it on > >>>>>> * work out how to configure the AS to trust my public key(s) > >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK = Set? > >>>>>> * determine the correct settings for issuer, audience, subject, = etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says = that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only = allows this to be present if your client is doing impersonation of an = end-user (which requires additional permissions). > >>>>>> * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers = do, plain OAuth ones might not) If I do, can I reuse the JWT or must it = be freshly signed for every call? > >>>>>> * locate and evaluate a JWT library for my language of choice. = Monitor that new dependency for security advisories. > >>>>>> * choose a suitable signature algorithm (=E2=80=98ere be = dragons) > >>>>>> * figure out how to distribute the private key to my service > >>>>>>=20 > >>>>>> Compared to =E2=80=9Ccreate a service account and POST the = username and password to the token endpoint=E2=80=9D it adds a little = friction. (It also adds a lot of advantages, but it is undeniably more = complex). > >>>>>>=20 > >>>>>> =E2=80=94 Neil > >>>>>>=20 > >>>>>>=20 > >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast = wrote: > >>>>>>>=20 > >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. > >>>>>>>=20 > >>>>>>> Neil could you elaborate more on this please. What failures = are you currently experiencing/seeing with the JWT Bearer grant?=20 > >>>>>>>=20 > >>>>>>> Matt > >>>>>>>=20 > >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden = wrote: > >>>>>>> I have a feeling that if we had more concise JWT libraries and = command line tools, where using the JWT Bearer grant became a one-liner = again then we wouldn=E2=80=99t be having this conversation. So perhaps = removing it is an incentive to make that happen. > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt = wrote: > >>>>>>>>=20 > >>>>>>>> Neil: are you advocating that password grant be preserved in = 2.1? Or do you think that service account developers know enough about = what they are doing to follow what is in 6749? > >>>>>>>> =E1=90=A7 > >>>>>>>>=20 > >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden = wrote: > >>>>>>>> OAuth2 clients are often private to the AS - they live in a = database that only the AS can access, have attributes specific to their = use in OAuth2, and so on. Many existing systems have access controls = based on users, roles, permissions and so on and expect all users = accessing the system to exist in some user repository, e.g. LDAP, where = they can be looked up and appropriate permissions determined. A service = account can be created inside such a system as if it was a regular user, = managed through the normal account provisioning tools, assigned = permissions, roles, etc. > >>>>>>>>=20 > >>>>>>>> Another reason is that sometimes OAuth is just one = authentication option out of many, and so permissions assigned to = service accounts are preferred over scopes because they are consistently = applied no matter how a request is authenticated. This is often the case = when OAuth has been retrofitted to an existing system and they need to = preserve compatibility with already deployed clients. > >>>>>>>>=20 > >>>>>>>> See e.g. Google cloud platform (GCP): = https://developers.google.com/identity/protocols/OAuth2ServiceAccount > >>>>>>>> They use the JWT bearer grant type for service account = authentication and assign permissions to those service accounts and = typically have very broad scopes. For service-to-service API calls you = typically get an access token with a single scope that is effectively = =E2=80=9Call of GCP=E2=80=9D and everything is managed at the level of = permissions on the RO service account itself. They only break down = fine-grained scopes when you are dealing with user data and will be = getting an access token approved by a real user (through a normal auth = code flow). > >>>>>>>>=20 > >>>>>>>> =E2=80=94 Neil > >>>>>>>>=20 > >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt = wrote: > >>>>>>>>>=20 > >>>>>>>>> Can you explain more in detail why the client credentials = grant type isn=E2=80=99t applicable for the kind of use cases you = mentioned? > >>>>>>>>>=20 > >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden = : > >>>>>>>>>>=20 > >>>>>>>>>> I very much agree with this with regards to real users.=20 > >>>>>>>>>>=20 > >>>>>>>>>> The one legitimate use-case for ROPC I=E2=80=99ve seen is = for service accounts - where you essentially want something like = client_credentials but for whatever reason you need the RO to be a = service user rather than an OAuth2 client (typically so that some lower = layer of the system can still perform its required permission checks). > >>>>>>>>>>=20 > >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - = but they are a bit harder to implement. Having recently converted some = code from ROPC to JWT bearer for exactly this use-case, it went from a = couple of lines of code to two screens of code. For service to service = API calls within a datacenter I=E2=80=99m not convinced this resulted in = a material increase in security for the added complexity. > >>>>>>>>>>=20 > >>>>>>>>>> =E2=80=94 Neil > >>>>>>>>>>=20 > >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt = wrote: > >>>>>>>>>>>=20 > >>>>>>>>>>> I would also seriously look at the original motivation = behind ROPC: I know it has been deployed and is used in quite a lot of = places but I have never actually come across a use case where it is used = for migration purposes and the migration is actually executed (I know = that is statistically not a very strong argument but I challenge others = to come up with one...) > >>>>>>>>>>> In reality it turned out just to be a one off that people = used as an easy way out to stick to an anti-pattern and still claim to = do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid = of it. > >>>>>>>>>>>=20 > >>>>>>>>>>> Hans. > >>>>>>>>>>>=20 > >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki = wrote: > >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively = acting as a grace period since it currently says the password grant MUST = NOT be used, so in the OAuth 2.0 world that's already a pretty strong = signal.. > >>>>>>>>>>>=20 > >>>>>>>>>>> Aaron > >>>>>>>>>>>=20 > >>>>>>>>>>>=20 > >>>>>>>>>>>=20 > >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer = wrote: > >>>>>>>>>>> There is no need for a grace period. People using OAuth = 2..0 can still do OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1.=20= > >>>>>>>>>>>=20 > >>>>>>>>>>> =E2=80=94 Justin > >>>>>>>>>>>=20 > >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin = wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are = still sites using this and a grace period should be provided before a = MUST is pushed out as there are valid use cases out there still. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> From: OAuth On Behalf Of Dick = Hardt > >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM > >>>>>>>>>>>> To: oauth@ietf.org > >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping = password grant > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Hey List=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for = the doc that Aaron, Torsten, and I are working on) > >>>>>>>>>>>>=20 > >>>>>>>>>>>> In the security topics doc > >>>>>>>>>>>>=20 > >>>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.= 4 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> The password grant MUST not be used. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Some background for those interested. I added this grant = into OAuth 2.0 to allow applications that had been provided password to = migrate. Even with the caveats in OAuth 2.0, implementors decide they = want to prompt the user to enter their credentials, the anti-pattern = OAuth was created to eliminate.=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Does anyone have concerns with dropping the password = grant from the OAuth 2.1 document so that developers don't use it? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> /Dick > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> 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 > >>>>>>>>>>> ---- > >>>>>>>>>>> Aaron Parecki > >>>>>>>>>>> aaronparecki.com > >>>>>>>>>>> @aaronpk > >>>>>>>>>>>=20 > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> OAuth mailing list > >>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>>>=20 > >>>>>>>>>>>=20 > >>>>>>>>>>> --=20 > >>>>>>>>>>> hans.zandbelt@zmartzone.eu > >>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> OAuth mailing list > >>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>>=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 > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>=20 > >>>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >>=20 > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Feb 25 06:17:28 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97B3A0D87 for ; Tue, 25 Feb 2020 06:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxZlM44lkPNM for ; Tue, 25 Feb 2020 06:17:22 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F14D3A0DB8 for ; Tue, 25 Feb 2020 06:17:22 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id i6so7260321pfc.1 for ; Tue, 25 Feb 2020 06:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=6zbjq+7xF1RiHZZY1lVL1vE+X4lzJZIUAuapZlacBfA=; b=Hiv+2FdDrXbUr9rIVKAD3yHf3wug7usPB0Rk/q4BQXuYkhqfVCl7qCqiwHkBSbkvuv jdphEV1yjLryClg1XTJ+e0uvj3hP4JFZZ8tUWoRK/4Eog2oiAIH20H8W+/BA+UMvD3sO qelCoQe/avPnwGRPr/m44av0ctyQtBCLpDPoS7R9B9GzvMi6RfF1U1ZDYAcTaS4HkQIL nBK0gCE4Q9dvcvGubQL+sF4piqHMTBp1Zj7d2YLjDAqo4hbqcZBkgR5q2AhLRB2boDUm KIpqRaGYQQCAhSWwC6uOFnqSBgXbgIxJlmkKurN7th5e7Q50sF3uFNaPWpN+8YUFqKi7 VgrQ== 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=6zbjq+7xF1RiHZZY1lVL1vE+X4lzJZIUAuapZlacBfA=; b=SjlLHWQmQek2G+bwgAFlU0gk+dXOvZu08II+17Mf2Lf3tH3HDNi9Rs3v1k2un2nBQj 5ciklDXMaEgO7calHaQOL+OVAsEQ1fIlNlSaS9/chu3Y+rDOpq2d9F2Bya7luGZifDbi ROCoYJopt1GN7IixOohVht250zeMZb4/GSbNHRXm7NzXE3vVMBkR/asK+o8O1jdCGRHd WLu16haYhyqQPRY6b8rpUx4M6hIR7ha9trYNXLDhsEb1LnbliuMtbcaspZLiw3brZEm7 4h3wsOGMDciWlWLFtnt8j26Yiu/Sd/BNClHSPo8b/paLKqGKCVF+p6qV5f8mj3NOi0Yi KFQg== X-Gm-Message-State: APjAAAXa0d+zxA80i7kDr+P5KDJvzMIi592rXzaHBDGXCtuSpLTRithi pgSXJMaojFC7OVtUB4NayGA= X-Google-Smtp-Source: APXvYqy7CUJlST+hLhhz4BjNQ6A4MPp138ZYfFbl3kJTvJ/5KZpjlDpuUkcGR5EvuAGoVA4xTVZe2w== X-Received: by 2002:a63:8f49:: with SMTP id r9mr59148796pgn.190.1582640241102; Tue, 25 Feb 2020 06:17:21 -0800 (PST) Received: from [192.168.0.112] (fp276f55ec.tkyc610.ap.nuro.jp. [39.111.85.236]) by smtp.gmail.com with ESMTPSA id z10sm16660471pgf.35.2020.02.25.06.17.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 06:17:20 -0800 (PST) Date: Tue, 25 Feb 2020 23:17:08 +0900 From: Nat Sakimura To: Aaron Parecki , Neil Madden Cc: Matthew De Haast , Brian Campbell , "=?utf-8?Q?oauth=40ietf.org?=" , =?utf-8?Q?Richard_Backman=2C_Annabelle?= Message-ID: <3aa0ac2f-f480-4054-974c-cf468f6070be@Spark> In-Reply-To: References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> X-Readdle-Message-ID: 3aa0ac2f-f480-4054-974c-cf468f6070be@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e552c69_46e87ccd_85a" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 14:17:26 -0000 --5e552c69_46e87ccd_85a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Let us do it then and deprecate ROPC. There definitely are use-cases that need this pattern around me as well, = but we are using JWT bearer grant instead. Standardizing the behavior is = good. I am fine with new service=5Faccount grant type as well, btw. Nat 2020=E5=B9=B42=E6=9C=8825=E6=97=A5 20:41 +0900=E3=80=81Neil Madden =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > I=E2=80=99d be open to defining a new service=5Faccount grant type and = removing/deprecating the ROPC grant. I=E2=80=99d also be happy if we just= said that service account flows should use the JWT bearer grant, and we = document the best practices around that and encourage client libs to impl= ement support for it. > > Should there be a dedicated draft for best practices for service-to-ser= vice usage=3F > > =E2=80=94 Neil > > > On 25 =46eb 2020, at 00:13, Aaron Parecki wrote= : > > > > I think we might be going about this discussion the wrong way. > > > > On Mon, =46eb 24, 2020 at 9:04 AM Brian Campbell wrote: > > Concur with the sentiment expressed by Neil here. > > > > On =46ri, =46eb 21, 2020 at 3:32 PM Neil Madden wrote: > > I=E2=80=99m not really sure the WG should be telling people what they= =E2=80=9Cought to be doing=E2=80=9D unless we have concrete security or = interoperability reasons for doing so. > > > > I 100% agree that the job of a standard is not to tell people =22what= they ought to be doing=22. Instead, a standard is more about documenting= the current state of the art as deployed in existing implementations. > > > > With that in mind, I think that leaves us with two concrete problems = with the password grant: > > > > 1) The actual problem with the password grant is end users entering p= asswords in applications, which the group (mostly) agrees on > > 2) People are re-appropriating the password grant for things like ser= vice accounts or backends that are inflexible, not actually using it for = end user credentials > > > > So it seems like there's actually something missing from OAuth which = is leading people to find the password grant and use that because it's th= e only thing that most closely fits their existing model. It seems like w= e'd be better off defining a new extension that captures the use case peo= ple are actually doing, instead of encouraging the continuing use of the = password grant for this purpose. > > > > ---- > > Aaron Parecki > > aaronparecki.com > > =40aaronpk > > > > > > > > On Mon, =46eb 24, 2020 at 9:04 AM Brian Campbell wrote: > > Concur with the sentiment expressed by Neil here. > > > > On =46ri, =46eb 21, 2020 at 3:32 PM Neil Madden wrote: > > I=E2=80=99m not really sure the WG should be telling people what they= =E2=80=9Cought to be doing=E2=80=9D unless we have concrete security or = interoperability reasons for doing so. > > > > I also don=E2=80=99t agree that people doing this are doing anything = wrong. I don=E2=80=99t always agree with what our customers do, but I=E2=80= =99ve learnt over the years not to second-guess their reasons for doing i= t. > > > > Are Google wrong for using the JWT bearer grant (not client credentia= ls) and service accounts=3F They even go so far as to say =E2=80=9Cscopes= are not a security mechanism=E2=80=9D =5B1=5D and tell people to use ser= vice account roles instead. (Precisely because they also support non-OAut= h auth methods, which bypass any scopes). > > > > Are we really going to tell them to rewrite it all to use the client = credentials grant=3F > > > > =5B1=5D: https://cloud.google.com/compute/docs/access/service-account= s=23accesscopesiam > > > > > On 21 =46eb 2020, at 21:04, Justin Richer wrote= : > > > > > > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place= , and it=E2=80=99s time to get rid of it and send people toward what they= really ought to be doing. > > > > > > Another thing I=E2=80=99ve seen is using different service accounts= to get different sets of access for one client =E2=80=94 if you=E2=80=99= re doing that, you=E2=80=99ve got a client pretending to do two different= things, or your APIs should be using scopes to differentiate access inst= ead of client/user identity. > > > > > > =E2=80=94 Justin > > > > > > > On =46eb 21, 2020, at 3:28 PM, Richard Backman, Annabelle wrote: > > > > > > > > The client IDs can still be opaque identifiers provided by the AS= , they just happen to be associated with specific service accounts. Or th= ey could be the opaque IDs that the AS already issued for the service acc= ount. Either way, the AS could issue a token with the appropriate subject= and other claims for the service account. > > > > > > > > If your client identity is bound to a specific service account id= entity (i.e., the resource owner), then ROPC reduces down to Client Crede= ntials. What's the point in passing two identifiers and two credentials f= or the same identity=3F > > > > > > > > =E2=80=93 > > > > Annabelle Backman (she/her) > > > > AWS Identity > > > > https://aws.amazon.com/identity/ > > > > > > > > > > > > On 2/21/20, 6:48 AM, =22OAuth on behalf of Neil Madden=22 wrote: > > > > > > > > Sorry, I missed that message. > > > > > > > > While this may be a solution in specific circumstances, I don=E2=80= =99t think it=E2=80=99s a general solution. e.g. an AS may not allow manu= ally choosing the client=5Fid to avoid things like https://tools.ietf.org= /html/draft-ietf-oauth-security-topics-14=23section-4.13 or may return di= fferent introspection results for client credentials tokens (e.g. with no= =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds even more steps= for somebody to migrate from existing ROPC usage. > > > > > > > > This is asking people to make fundamental changes to their identi= ty architecture rather than simply switching to a new grant type.. > > > > > > > > =E2=80=94 Neil > > > > > > > > > On 21 =46eb 2020, at 14:34, Torsten Lodderstedt wrote: > > > > > > > > > > I see - we have gone full cycle :-) > > > > > > > > > > Annabelle=E2=80=99s proposal would solve that. Relate a client = id to a service account and obtain the token data from there. > > > > > > > > > > > On 21. =46eb 2020, at 15:31, Neil Madden wrote: > > > > > > > > > > > > Yes, that is great. But mTLS doesn=E2=80=99t support service = accounts (=21=3D clients). Maybe it should=3F Should there be a mTLS *gra= nt type*=3F > > > > > > > > > > > > =E2=80=94 Neil > > > > > > > > > > > > > On 21 =46eb 2020, at 14:20, Torsten Lodderstedt wrote: > > > > > > > > > > > > > > Have you ever tried the client credentials grant with mTLS=3F= After reading your description it seems to be simpler than JWT Bearer.. > > > > > > > > > > > > > > * work out if the AS even supports mTLS > > > > > > > * work out how to configure the AS to trust my cert(s) > > > > > > > * Create key pair and cert using openssl > > > > > > > * Register your (self-signed) cert along with your client=5F= id > > > > > > > * Configure the HTTP client to use your key pair for TLS Cl= ient Authentication > > > > > > > > > > > > > > Works very well for us. > > > > > > > > > > > > > > > On 21. =46eb 2020, at 15:12, Neil Madden wrote: > > > > > > > > > > > > > > > > No failures, but it is a much more complex grant type to = set up, when you consider everything you have to do: > > > > > > > > > > > > > > > > * work out if the AS even supports JWT bearer and how to = turn it on > > > > > > > > * work out how to configure the AS to trust my public key= (s) > > > > > > > > - do I have to create a new HTTPS endpoint to publish a J= WK Set=3F > > > > > > > > * determine the correct settings for issuer, audience, su= bject, etc. Does the AS impose non-standard requirements=3F e.g. R=46C 75= 23 says that the JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Goog= le only allows this to be present if your client is doing impersonation o= f an end-user (which requires additional permissions). > > > > > > > > * do I need a unique =E2=80=9Cjti=E2=80=9D claim=3F (OIDC= servers do, plain OAuth ones might not) If I do, can I reuse the JWT or = must it be freshly signed for every call=3F > > > > > > > > * locate and evaluate a JWT library for my language of ch= oice. Monitor that new dependency for security advisories. > > > > > > > > * choose a suitable signature algorithm (=E2=80=98ere be = dragons) > > > > > > > > * figure out how to distribute the private key to my serv= ice > > > > > > > > > > > > > > > > Compared to =E2=80=9Ccreate a service account and POST th= e username and password to the token endpoint=E2=80=9D it adds a little f= riction. (It also adds a lot of advantages, but it is undeniably more com= plex). > > > > > > > > > > > > > > > > =E2=80=94 Neil > > > > > > > > > > > > > > > > > > > > > > > > > On 21 =46eb 2020, at 13:41, Matthew De Haast wrote: > > > > > > > > > > > > > > > > > > I have a feeling that if we had more concise JWT librar= ies and command line tools, where using the JWT Bearer grant became a one= -liner again then we wouldn=E2=80=99t be having this conversation. So per= haps removing it is an incentive to make that happen. > > > > > > > > > > > > > > > > > > Neil could you elaborate more on this please. What fail= ures are you currently experiencing/seeing with the JWT Bearer grant=3F > > > > > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > > > > > > On Thu, =46eb 20, 2020 at 12:42 AM Neil Madden wrote: > > > > > > > > > I have a feeling that if we had more concise JWT librar= ies and command line tools, where using the JWT Bearer grant became a one= -liner again then we wouldn=E2=80=99t be having this conversation. So per= haps removing it is an incentive to make that happen. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 19 =46eb 2020, at 22:01, Dick Hardt wrote: > > > > > > > > > > > > > > > > > > > > Neil: are you advocating that password grant be prese= rved in 2.1=3F Or do you think that service account developers know enoug= h about what they are doing to follow what is in 6749=3F > > > > > > > > > > =E1=90=A7 > > > > > > > > > > > > > > > > > > > > On Wed, =46eb 19, 2020 at 1:52 PM Neil Madden wrote: > > > > > > > > > > OAuth2 clients are often private to the AS - they liv= e in a database that only the AS can access, have attributes specific to = their use in OAuth2, and so on. Many existing systems have access control= s based on users, roles, permissions and so on and expect all users acces= sing the system to exist in some user repository, e.g. LDAP, where they c= an be looked up and appropriate permissions determined. A service account= can be created inside such a system as if it was a regular user, managed= through the normal account provisioning tools, assigned permissions, rol= es, etc. > > > > > > > > > > > > > > > > > > > > Another reason is that sometimes OAuth is just one au= thentication option out of many, and so permissions assigned to service a= ccounts are preferred over scopes because they are consistently applied n= o matter how a request is authenticated. This is often the case when OAut= h has been retrofitted to an existing system and they need to preserve co= mpatibility with already deployed clients. > > > > > > > > > > > > > > > > > > > > See e.g. Google cloud platform (GCP): https://develop= ers.google.com/identity/protocols/OAuth2ServiceAccount > > > > > > > > > > They use the JWT bearer grant type for service accoun= t authentication and assign permissions to those service accounts and typ= ically have very broad scopes. =46or service-to-service API calls you typ= ically get an access token with a single scope that is effectively =E2=80= =9Call of GCP=E2=80=9D and everything is managed at the level of permissi= ons on the RO service account itself. They only break down fine-grained s= copes when you are dealing with user data and will be getting an access t= oken approved by a real user (through a normal auth code flow). > > > > > > > > > > > > > > > > > > > > =E2=80=94 Neil > > > > > > > > > > > > > > > > > > > > > On 19 =46eb 2020, at 21:35, Torsten Lodderstedt wrote: > > > > > > > > > > > > > > > > > > > > > > Can you explain more in detail why the client crede= ntials grant type isn=E2=80=99t applicable for the kind of use cases you = mentioned=3F > > > > > > > > > > > > > > > > > > > > > > > Am 19.02.2020 um 22:03 schrieb Neil Madden : > > > > > > > > > > > > > > > > > > > > > > > > I very much agree with this with regards to real = users. > > > > > > > > > > > > > > > > > > > > > > > > The one legitimate use-case for ROPC I=E2=80=99ve= seen is for service accounts - where you essentially want something like= client=5Fcredentials but for whatever reason you need the RO to be a ser= vice user rather than an OAuth2 client (typically so that some lower laye= r of the system can still perform its required permission checks). > > > > > > > > > > > > > > > > > > > > > > > > There are better grant types for this - e.g. JWT = bearer - but they are a bit harder to implement. Having recently converte= d some code from ROPC to JWT bearer for exactly this use-case, it went fr= om a couple of lines of code to two screens of code. =46or service to ser= vice API calls within a datacenter I=E2=80=99m not convinced this resulte= d in a material increase in security for the added complexity. > > > > > > > > > > > > > > > > > > > > > > > > =E2=80=94 Neil > > > > > > > > > > > > > > > > > > > > > > > > > On 18 =46eb 2020, at 21:57, Hans Zandbelt wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > I would also seriously look at the original mot= ivation behind ROPC: I know it has been deployed and is used in quite a l= ot of places but I have never actually come across a use case where it is= used for migration purposes and the migration is actually executed (I kn= ow that is statistically not a very strong argument but I challenge other= s to come up with one...) > > > > > > > > > > > > > In reality it turned out just to be a one off t= hat people used as an easy way out to stick to an anti-pattern and still = claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to = get rid of it. > > > > > > > > > > > > > > > > > > > > > > > > > > Hans. > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, =46eb 18, 2020 at 10:44 PM Aaron Pareck= i wrote: > > > > > > > > > > > > > Agreed. Plus, the Security BCP is already effec= tively acting as a grace period since it currently says the password gran= t MUST NOT be used, so in the OAuth 2.0 world that's already a pretty str= ong signal.. > > > > > > > > > > > > > > > > > > > > > > > > > > Aaron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, =46eb 18, 2020 at 4:16 PM Justin Richer= wrote: > > > > > > > > > > > > > There is no need for a grace period. People usi= ng OAuth 2..0 can still do OAuth 2.0. People using OAuth 2..1 will do OAu= th 2.1. > > > > > > > > > > > > > > > > > > > > > > > > > > =E2=80=94 Justin > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46eb 18, 2020, at 3:54 PM, Anthony Nada= lin wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would suggest a SHOULD NOT instead of MUST,= there are still sites using this and a grace period should be provided b= efore a MUST is pushed out as there are valid use cases out there still. > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: OAuth On B= ehalf Of Dick Hardt > > > > > > > > > > > > > > Sent: Tuesday, =46ebruary 18, 2020 12:37 PM > > > > > > > > > > > > > > To: oauth=40ietf.org > > > > > > > > > > > > > > Subject: =5BEXTERNAL=5D =5BOAUTH-WG=5D OAuth = 2.1: dropping password grant > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hey List > > > > > > > > > > > > > > > > > > > > > > > > > > > > (Once again using the OAuth 2.1 name as a pla= ceholder for the doc that Aaron, Torsten, and I are working on) > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the security topics doc > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://tools.ietf.org/html/draft-ietf-oauth-= security-topics-14=23section-2.4 > > > > > > > > > > > > > > > > > > > > > > > > > > > > The password grant MUST not be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some background for those interested. I added= this grant into OAuth 2.0 to allow applications that had been provided p= assword to migrate. Even with the caveats in OAuth 2.0, implementors deci= de they want to prompt the user to enter their credentials, the anti-patt= ern OAuth was created to eliminate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Does anyone have concerns with dropping the p= assword grant from the OAuth 2.1 document so that developers don't use it= =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > /Dick > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=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 > > > > > > > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=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 > > > > > > > > > > > > > -- > > > > > > > > > > > > > ---- > > > > > > > > > > > > > Aaron Parecki > > > > > > > > > > > > > aaronparecki.com > > > > > > > > > > > > > =40aaronpk > > > > > > > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > hans.zandbelt=40zmartzone.eu > > > > > > > > > > > > > ZmartZone IAM - www.zmartzone.eu > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=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 > > > > > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=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 > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=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 > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=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 > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=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 > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=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 > > > > > > > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=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 > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=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 > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =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 > > > > CON=46IDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any revie= w, use, distribution or disclosure by others is strictly prohibited.. If = you have received this communication in error, please notify the sender i= mmediately 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=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 --5e552c69_46e87ccd_85a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Let us do it then and deprecate ROPC.&=23160;
There definitely are use-cases that need this patte= rn around me as well, but we are using JWT bearer grant instead. Standard= izing the behavior is good. I am fine with new service=5Faccount grant ty= pe as well, btw.&=23160;

Nat
2020=E5=B9=B42=E6=9C=8825=E6=97=A5 = 20:41 +0900=E3=80=81Neil Madden <neil.madden=40forgerock.com> =E3=81= =AE=E3=83=A1=E3=83=BC=E3=83=AB:
I=E2= =80=99d be open to defining a new service=5Faccount grant type and removi= ng/deprecating the ROPC grant. I=E2=80=99d also be happy if we just said = that service account flows should use the JWT bearer grant, and we docume= nt the best practices around that and encourage client libs to implement = support for it.

Should there be a dedicated draft for best practices for service-to-servi= ce usage=3F

=E2=80=94 Neil

On= 25 =46eb 2020, at 00:13, Aaron Parecki <aaron=40parecki.com> wrote= :

I think we might be going about this discussion the wrong way.

On Mon, =46eb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=3D40pingid= entity.com=40dmarc.ietf.org> wrote:
Concur with the sentiment expressed by Neil here.

On =46ri, =46eb 21, 2020 at 3:32 PM Neil Madden <neil.madden=40forgero= ck.com> wrote:
I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be doing=E2=80=9D unless we have concrete security or inte= roperability reasons for doing so.

I 100% agree that the job of a standard is not to tell people =22what the= y ought to be doing=22. Instead, a standard is more about documenting the= current state of the art as deployed in existing implementations.

With that in mind, I think that leaves us with two concrete problems with= the password grant:

1) The actual problem with the password grant is end users entering passw= ords in applications, which the group (mostly) agrees on
2) People are re-appropriating the password grant for things like service= accounts or backends that are inflexible, not actually using it for end = user credentials

So it seems like there's actually something missing from OAuth which is l= eading people to find the password grant and use that because it's the on= ly thing that most closely fits their existing model. It seems like we'd = be better off defining a new extension that captures the use case people = are actually doing, instead of encouraging the continuing use of the pass= word grant for this purpose.

----
Aaron Parecki
aaronparecki.com
=40aaronpk



On Mon, =46eb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=3D40pingid= entity.com=40dmarc.ietf.org> wrote:
Concur with the sentiment expressed by Neil here.

On =46ri, =46eb 21, 2020 at 3:32 PM Neil Madden <neil.madden=40forgero= ck.com> wrote:
I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be doing=E2=80=9D unless we have concrete security or inte= roperability reasons for doing so.

I also don=E2=80=99t agree that people doing this are doing anything wron= g. I don=E2=80=99t always agree with what our customers do, but I=E2=80=99= ve learnt over the years not to second-guess their reasons for doing it.<= br />
Are Google wrong for using the JWT bearer grant (not client credentials) = and service accounts=3F They even go so far as to say =E2=80=9Cscopes are= not a security mechanism=E2=80=9D =5B1=5D and tell people to use service= account roles instead. (Precisely because they also support non-OAuth au= th methods, which bypass any scopes).

Are we really going to tell them to rewrite it all to use the client cred= entials grant=3F

=5B1=5D: https://cloud.google.com/compute/docs/access/service-accounts=23= accesscopesiam

On= 21 =46eb 2020, at 21:04, Justin Richer <jricher=40mit.edu> wrote:<= br />
+1. I=E2=80=99ve seen this anti-pattern deployed all over the place, and = it=E2=80=99s time to get rid of it and send people toward what they reall= y ought to be doing.

Another thing I=E2=80=99ve seen is using different service accounts to ge= t different sets of access for one client =E2=80=94 if you=E2=80=99re doi= ng that, you=E2=80=99ve got a client pretending to do two different thing= s, or your APIs should be using scopes to differentiate access instead of= client/user identity.

=E2=80=94 Justin

On= =46eb 21, 2020, at 3:28 PM, Richard Backman, Annabelle <richanna=3D40= amazon.com=40dmarc.ietf.org> wrote:

The client IDs can still be opaque identifiers provided by the AS, they j= ust happen to be associated with specific service accounts. Or they could= be the opaque IDs that the AS already issued for the service account. Ei= ther way, the AS could issue a token with the appropriate subject and oth= er claims for the service account.

If your client identity is bound to a specific service account identity (= i.e., the resource owner), then ROPC reduces down to Client Credentials. = What's the point in passing two identifiers and two credentials for the s= ame identity=3F

=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


=EF=BB=BFOn 2/21/20, 6:48 AM, =22OAuth on behalf of Neil Madden=22 <oa= uth-bounces=40ietf.org on behalf of neil.madden=40forgerock.com> wrote= :

Sorry, I missed that message.

While this may be a solution in specific circumstances, I don=E2=80=99t t= hink it=E2=80=99s a general solution. e.g. an AS may not allow manually c= hoosing the client=5Fid to avoid things like https://tools.ietf.org/html/= draft-ietf-oauth-security-topics-14=23section-4.13 or may return differen= t introspection results for client credentials tokens (e.g. with no =E2=80= =9Csub=E2=80=9D) and so on. In practice, this adds even more steps for so= mebody to migrate from existing ROPC usage.

This is asking people to make fundamental changes to their identity archi= tecture rather than simply switching to a new grant type..

=E2=80=94 Neil

On= 21 =46eb 2020, at 14:34, Torsten Lodderstedt <torsten=40lodderstedt.n= et> wrote:

I see - we have gone full cycle :-)

Annabelle=E2=80=99s proposal would solve that. Relate a client id to a se= rvice account and obtain the token data from there.

On= 21. =46eb 2020, at 15:31, Neil Madden <neil.madden=40forgerock.com>= ; wrote:

Yes, that is great. But mTLS doesn=E2=80=99t support service accounts (=21= =3D clients). Maybe it should=3F Should there be a mTLS *grant type*=3F
=E2=80=94 Neil

On= 21 =46eb 2020, at 14:20, Torsten Lodderstedt <torsten=40lodderstedt.n= et> wrote:

Have you ever tried the client credentials grant with mTLS=3F After readi= ng your description it seems to be simpler than JWT Bearer..

* work out if the AS even supports mTLS
* work out how to configure the AS to trust my cert(s)
* Create key pair and cert using openssl
* Register your (self-signed) cert along with your client=5Fid
* Configure the HTTP client to use your key pair for TLS Client Authentic= ation

Works very well for us.

On= 21. =46eb 2020, at 15:12, Neil Madden <neil.madden=40forgerock.com>= ; wrote:

No failures, but it is a much more complex grant type to set up, when you= consider everything you have to do:

* work out if the AS even supports JWT bearer and how to turn it on
= * work out how to configure the AS to trust my public key(s)
- do I have to create a new HTTPS endpoint to publish a JWK Set=3F
* determine the correct settings for issuer, audience, subject, etc. Does= the AS impose non-standard requirements=3F e.g. R=46C 7523 says that the= JWT MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only allows t= his to be present if your client is doing impersonation of an end-user (w= hich requires additional permissions).
* do I need a unique =E2=80=9Cjti=E2=80=9D claim=3F (OIDC servers do, pla= in OAuth ones might not) If I do, can I reuse the JWT or must it be fresh= ly signed for every call=3F
* locate and evaluate a JWT library for my language of choice. Monitor th= at new dependency for security advisories.
* choose a suitable signature algorithm (=E2=80=98ere be dragons)
* figure out how to distribute the private key to my service

Compared to =E2=80=9Ccreate a service account and POST the username and p= assword to the token endpoint=E2=80=9D it adds a little friction. (It als= o adds a lot of advantages, but it is undeniably more complex).

=E2=80=94 Neil


On= 21 =46eb 2020, at 13:41, Matthew De Haast <matt=3D40coil.com=40dmarc.= ietf.org> wrote:

I have a feeling that if we had more concise JWT libraries and command li= ne tools, where using the JWT Bearer grant became a one-liner again then = we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s an incentive to make that happen.

Neil could you elaborate more on this please. What failures are you curre= ntly experiencing/seeing with the JWT Bearer grant=3F

Matt

On Thu, =46eb 20, 2020 at 12:42 AM Neil Madden <neil.madden=40forgeroc= k.com> wrote:
I have a feeling that if we had more concise JWT libraries and command li= ne tools, where using the JWT Bearer grant became a one-liner again then = we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s an incentive to make that happen.


On= 19 =46eb 2020, at 22:01, Dick Hardt <dick.hardt=40gmail.com> wrote= :

Neil: are you advocating that password grant be preserved in 2.1=3F Or do= you think that service account developers know enough about what they ar= e doing to follow what is in 6749=3F
=E1=90=A7

On Wed, =46eb 19, 2020 at 1:52 PM Neil Madden <neil.madden=40forgerock= .com> wrote:
OAuth2 clients are often private to the AS - they live in a database that= only the AS can access, have attributes specific to their use in OAuth2,= and so on. Many existing systems have access controls based on users, ro= les, permissions and so on and expect all users accessing the system to e= xist in some user repository, e.g. LDAP, where they can be looked up and = appropriate permissions determined. A service account can be created insi= de such a system as if it was a regular user, managed through the normal = account provisioning tools, assigned permissions, roles, etc.

Another reason is that sometimes OAuth is just one authentication option = out of many, and so permissions assigned to service accounts are preferre= d over scopes because they are consistently applied no matter how a reque= st is authenticated. This is often the case when OAuth has been retrofitt= ed to an existing system and they need to preserve compatibility with alr= eady deployed clients.

See e.g. Google cloud platform (GCP): https://developers.google.com/ident= ity/protocols/OAuth2ServiceAccount
They use the JWT bearer grant type for service account authentication and= assign permissions to those service accounts and typically have very bro= ad scopes. =46or service-to-service API calls you typically get an access= token with a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D= and everything is managed at the level of permissions on the RO service = account itself. They only break down fine-grained scopes when you are dea= ling with user data and will be getting an access token approved by a rea= l user (through a normal auth code flow).

=E2=80=94 Neil

On= 19 =46eb 2020, at 21:35, Torsten Lodderstedt <torsten=40lodderstedt.n= et> wrote:

Can you explain more in detail why the client credentials grant type isn=E2= =80=99t applicable for the kind of use cases you mentioned=3F

Am= 19.02.2020 um 22:03 schrieb Neil Madden <neil.madden=40forgerock.com&= gt;:

I very much agree with this with regards to real users.

The one legitimate use-case for ROPC I=E2=80=99ve seen is for service acc= ounts - where you essentially want something like client=5Fcredentials bu= t for whatever reason you need the RO to be a service user rather than an= OAuth2 client (typically so that some lower layer of the system can stil= l perform its required permission checks).

There are better grant types for this - e.g. JWT bearer - but they are a = bit harder to implement. Having recently converted some code from ROPC to= JWT bearer for exactly this use-case, it went from a couple of lines of = code to two screens of code. =46or service to service API calls within a = datacenter I=E2=80=99m not convinced this resulted in a material increase= in security for the added complexity.

=E2=80=94 Neil

On= 18 =46eb 2020, at 21:57, Hans Zandbelt <hans.zandbelt=40zmartzone.eu&= gt; wrote:

I would also seriously look at the original motivation behind ROPC: I kno= w it has been deployed and is used in quite a lot of places but I have ne= ver actually come across a use case where it is used for migration purpos= es and the migration is actually executed (I know that is statistically n= ot a very strong argument but I challenge others to come up with one...)<= br /> In reality it turned out just to be a one off that people used as an easy= way out to stick to an anti-pattern and still claim to do OAuth 2.0. It = is plain wrong, it is not OAuth and we need to get rid of it.

Hans.

On Tue, =46eb 18, 2020 at 10:44 PM Aaron Parecki <aaron=40parecki.com&= gt; wrote:
Agreed. Plus, the Security BCP is already effectively acting as a grace p= eriod since it currently says the password grant MUST NOT be used, so in = the OAuth 2.0 world that's already a pretty strong signal..

Aaron



On Tue, =46eb 18, 2020 at 4:16 PM Justin Richer <jricher=40mit.edu>= wrote:
There is no need for a grace period. People using OAuth 2..0 can still do= OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1.

=E2=80=94 Justin

On= =46eb 18, 2020, at 3:54 PM, Anthony Nadalin <tonynad=3D40microsoft.co= m=40dmarc.ietf.org> wrote:

I would suggest a SHOULD NOT instead of MUST, there are still sites using= this and a grace period should be provided before a MUST is pushed out a= s there are valid use cases out there still.

=46rom: OAuth <oauth-bounces=40ietf.org> On Behalf Of Dick Hardt Sent: Tuesday, =46ebruary 18, 2020 12:37 PM
To: oauth=40ietf.org
Subject: =5BEXTERNAL=5D =5BOAUTH-WG=5D OAuth 2.1: dropping password grant=

Hey List

(Once again using the OAuth 2.1 name as a placeholder for the doc that Aa= ron, Torsten, and I are working on)

In the security topics doc

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14=23section= -2.4

The password grant MUST not be used.

Some background for those interested. I added this grant into OAuth 2.0 t= o allow applications that had been provided password to migrate. Even wit= h the caveats in OAuth 2.0, implementors decide they want to prompt the u= ser to enter their credentials, the anti-pattern OAuth was created to eli= minate.


Does anyone have concerns with dropping the password grant from the OAuth= 2.1 document so that developers don't use it=3F

/Dick
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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
--
----
Aaron Parecki
aaronparecki.com
=40aaronpk

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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


--
hans.zandbelt=40zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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




=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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

CON=46IDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.. If you = have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from you= r 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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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
--5e552c69_46e87ccd_85a-- From nobody Tue Feb 25 14:52:25 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBE43A0789; Tue, 25 Feb 2020 14:52:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158267113813.11133.3835985962594781644.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2020 14:52:18 -0800 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 22:52:18 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the updates in the -08; they address the bulk of the substantive issues! I have a few points remaining on the -08 text but I think there are more localized issues to resolve. Can IANA please confirm that the new allocations in the -08 have received appropriate Expert (e.g., media type) review? I see some updates in the datatracker history relating to the -08 but nothing in the email archives. It looks like we need to register 'active' as a JWT claim? I don't think the new semantics for "jti" in the introspection response are compatible with the RFC 7519 definition. Specifically, we say that "jti" will be tied to the input access token, but 7519 says that "jti" has to change when the contents of the JWT change ("MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object"), and we admit at least the possibility of "active" and "iat" changing. Section 5 says that: If the access token is considered active, it MUST contain the claims "iss" and "aud" in order to prevent misuse of the JWT as an ID or access token (see Section 8.1). But I don't think the predicate is correct -- misuse is still possible by services that do not check the "active" claim's value. Shouldn't the "iss"+"aud" requirements be unconditional? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [New comments on the added text in the diff from -07 to -08.] Section 3 To support encrypted token introspection response JWTs, the authorization server MUST also be provided with the respective resource server encryption keys and algorithms. IIRC, based on some list discussion this text was going to be tweaked to avoid implying that JWE is mandatory. (Unfortunately, this is the thread that evolved into "client certs and TLS Terminating Reverse Proxies", so it's hard to be sure whether I saw any other followups.) The AS MUST restrict the use of client credentials by a RS to the calls it requires, e.g. the AS MAY restrict such a client to call the token introspection endpoint only. How the AS implements this restriction is beyond the scope of this specification. This should probably be clarified a bit more, in the context of "client credentials tend to be used by privileged, fixed endpoints, and the default may just be to allow them all access to all endpoints". Right now it's not clear what's being restricted (and who "it" is that requires calls) Section 5 This specification registers the "application/token- introspection+jwt" media type, which is used as value of the "typ" header parameter of the JWT to indicate that the payload is a token introspection response. Do we also want to note that checking 'jti' is not mandatory and so this does not necessarily provide full protection? (I guess Section 8.1 covers this in more detail.) The value of the "aud" claims MUST identify the resource server receiving the token introspection response. We may want to dig into this a bit more: should there be any relationship between this "aud" value and the "client_id" that an RS might be using (as obtained from dynamic registration)? Does this value need to be different from the audience that is used in access tokens for which this RS is the audience? (Should it be the same?) My instincts lean towards "different" but I would like broader input. exp The "exp" claim indicates when the access token passed in the introspection request will expire. On the face of it this seems divergent from RFC 7519's "the expiration time on or after which the JWT MUST NOT be accepted for processing", though upon further examination the distinction is not quite so large. That is, it's in effect saying that the introspection response should not be accepted for processing after the base token has expired, which usually makes sense. There is a bit of a complication, though, in that the "active" claim implies that we might still have RSes that plan to use the introspection response after the "exp" date has passed, which sounds a lot like a DISCUSS-level internal inconsistency. If possible, the AS MUST narrow down the "scope" value to the scopes relevant to the particular RS. This sounds kind of like a "SHOULD"... The example response header contains the following JSON document: I think this is the JOSE header in the HTTP response (body), not the (HTTP) response header. Section 8.1 As an alternative approach, such an attack can be prevented like any other token substitution attack by restricting the audience of the I'd suggest avoiding describing these as "alternatives"; they seem more like complementary approaches as part of a defense-in-depth solution (especially since we are basically mandating both of them). "aud" value set to the resource server's identifier. Any recipient of an JWT MUST check these values in order to detect substitution attacks. This "MUST" might be out of place -- this is a requirement from RFC 7519, and not an attempt by this document to make new requirements on the behavior of all JWT consumers (if it was, that would be a DISCUSS point!). Resource servers MUST additionally apply the countermeasures against replay as described in [I-D.ietf-oauth-security-topics], section 3.2. In a similar vein, which set of resources servers is this normative "MUST" intended to be binding upon? Section 9 In any case, the AS MUST ensure that the scope of the legal basis is enforced throughout the whole process. The AS MUST retain the scope of the legal basis with the access token, e.g. in the scope value, and the AS MUST determine the data a resource server is allowed to receive based on the resource server's identity and suitable token data, e.g. the scope value. I suspect I'm just being dense, but could you walk me through how the access token "scope" value can encode the legal basis for data transfer? From nobody Wed Feb 26 09:21:59 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3A3A0D59 for ; Wed, 26 Feb 2020 09:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=UPmOFUXm; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=UPmOFUXm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFLCeEyNkpsC for ; Wed, 26 Feb 2020 09:21:56 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140073.outbound.protection.outlook.com [40.107.14.73]) (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 231C53A0D57 for ; Wed, 26 Feb 2020 09:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Os619CVkeuiv/qnlbvE9jrkIPPp23CR5mWQfte9X2W4=; b=UPmOFUXmfV9eFqhHuMtW90rzrqZVWyqPRCnIU7GbLVHuwuE8cHqpD3w6/YQ4fEBA0H2jhWnj0ZMv7iXt5FWdvUe7smVGGf26y6B9WAvrNKPyv01kBQFXltKrS8oIAizUGvOmrQMttZon19m/qlIxj63WhSRFenlX8JG/EZA5KiE= Received: from VI1PR08CA0238.eurprd08.prod.outlook.com (2603:10a6:802:15::47) by DB6PR0802MB2471.eurprd08.prod.outlook.com (2603:10a6:4:9f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.22; Wed, 26 Feb 2020 17:21:53 +0000 Received: from AM5EUR03FT038.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::202) by VI1PR08CA0238.outlook.office365.com (2603:10a6:802:15::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Wed, 26 Feb 2020 17:21:53 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT038.mail.protection.outlook.com (10.152.17.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Wed, 26 Feb 2020 17:21:52 +0000 Received: ("Tessian outbound 0420f1404d58:v42"); Wed, 26 Feb 2020 17:21:52 +0000 X-CR-MTA-TID: 64aa7808 Received: from fdf7dd64a97d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A870F6A8-2855-4B3F-A6FA-19A850FC883C.1; Wed, 26 Feb 2020 17:21:47 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fdf7dd64a97d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 26 Feb 2020 17:21:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FmWahnco62V7OgHJJSaNZvEIraI2UsFYZNhpCeiLmP+8XduC32JKJqBJzwByWfbgwKM2IAMNyl+jaWc93xnXvkS7jK7Aom4HoKkHVBesO7ic74xp38gnFPHwSREsuq3HVcrvArVJKbAPkj6kHxStEbvxD5Lg87yGDaAl1R89cDpdar+Eb5U3S2FjTXHs5T/yBPBxpaQsNMmRIYWjZ5Zqtth8NBRr8yNSzWuVNf/SyJy6UXGtNxq3iGMVO3Y/tZRFFF9BIwN9GsOb4vgrOMVOIeBGZ2hWWQ0MR7vozzGQR/jK3HecjjC2fCT92oRIueMagzmqLTWS2XoVPYL5sCVOlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Os619CVkeuiv/qnlbvE9jrkIPPp23CR5mWQfte9X2W4=; b=Yyt+5gc6GQozN9jpGPRtde60XHGb6ZQ6/HCINu6Reru9xOuKFxDXZJlHuh4Lorp6UNy/nq0kKT2jFu4mpF3YdcwjBPthbG5sVpCwYD9LPqte7Jkh5giL9YaH9LWb+cbFqa/8VWVfjI+hFvlXDHhk807AcL17i+ecclMDbB+lyPq4MTr84m+/zXMhmcWbT9msBE5UJCHsCVDNFfS5i5uYSbA1w2wj2YLtwczGuV66MMZTpGAbb7C8EtsXgtx9N1toEf27H9uUwtxy8UGm3ipzfF9z8C8tTIDQOgsH5XxE2ofaufEGbZTozFZ8Ji+ZgRyv0e/IU9rRnAPB1OmGKzf1tA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Os619CVkeuiv/qnlbvE9jrkIPPp23CR5mWQfte9X2W4=; b=UPmOFUXmfV9eFqhHuMtW90rzrqZVWyqPRCnIU7GbLVHuwuE8cHqpD3w6/YQ4fEBA0H2jhWnj0ZMv7iXt5FWdvUe7smVGGf26y6B9WAvrNKPyv01kBQFXltKrS8oIAizUGvOmrQMttZon19m/qlIxj63WhSRFenlX8JG/EZA5KiE= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB4161.eurprd08.prod.outlook.com (20.178.203.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Wed, 26 Feb 2020 17:21:47 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 17:21:47 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Virtual Interim Meeting for the PoP Discussion Thread-Index: AdXsyMgbOEQddn8uSq61fh+IFqH9Yg== Date: Wed, 26 Feb 2020 17:21:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ts-tracking-id: 3bf5275f-35e0-4646-b47c-9adcd5ae760d.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.195.207] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: c62c2b88-d29f-4e3f-3ffd-08d7bae05f4a X-MS-TrafficTypeDiagnostic: AM0PR08MB4161:|DB6PR0802MB2471: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4941;OLM:7219; x-forefront-prvs: 0325F6C77B X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(346002)(39860400002)(376002)(136003)(189003)(199004)(86362001)(64756008)(16799955002)(55016002)(66946007)(66446008)(66556008)(5660300002)(966005)(76116006)(2906002)(52536014)(316002)(4744005)(66476007)(9686003)(7696005)(26005)(71200400001)(478600001)(66616009)(81156014)(8676002)(8936002)(186003)(6916009)(33656002)(81166006)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4161; H:AM0PR08MB3716.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-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 9M7HhfwqEmkbY4+GbEZJ3RQEDNztD5q0c7c8C7mkMDeOuWowd9kd1GVRsC8/GnJhf5PQQOQWS8J8dpcQetwi8fVwlCSYG/F6vUCWmIxaX0W3l0rjmfoS+SzBcnbto3gdZo87HyEUNtBw2S5ba5d/O3uiSZvU4ropjx4L40BDqfGslPwDGkMvaXQ0E0f53ckjgGjMk4iA8BlIVwr4qqs4aXr0Nc0DqLO8bmujp+R6Nvq/3r2QQ4W5wY4wbWsC5H/gjoNavu93MpF7/D6K7Z5JcI+5czSM1ooBOQ5d8gVAQNYC5nocQcl6anTpAHoBs35rneTOXDHQDeqMT5sUcuJA09/0ef1tQsgCfIL378JxG5KYZkfbQ8qTXYNSXosU879sJMgnzPDzFn4am0ZVFFThdBVEhvivUxbaVHBKiaEXk8wWrdtJVEtnzBz0wF+axoDmZPaF6HW+FbvKDDOtKTgZnt4YV/oxLHwyq2skmTZHH3Miklw/7nFVmFPsub+bEii6srhHC7pY3edAudR386smPg== x-ms-exchange-antispam-messagedata: PKD6E+fahbtzLbzTaXVwhEaYfFKQD1dq2VqpbtEsJA2aYPBn7w4Or2miT0XlFX/Ao6nQgv+XhQ2YVO7paLOUkNq/slNbApEuYwXZWJjcrc7REXLd5D53SnsJcV7yR9yL0LZpjOoFn8rF6FuRpvZDAA== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4161 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT038.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(396003)(199004)(189003)(86362001)(5660300002)(55016002)(235185007)(356004)(16799955002)(8936002)(336012)(9686003)(478600001)(186003)(52536014)(8676002)(7696005)(26005)(33656002)(316002)(6506007)(966005)(81166006)(36906005)(70206006)(2906002)(26826003)(81156014)(6916009)(70586007)(66616009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0802MB2471; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 7b93e338-895b-4968-5383-08d7bae05bd6 X-Forefront-PRVS: 0325F6C77B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3MK9hjNkt/NbegEavQ9VSLbx31yPGEy5/xTERlwMgjD6aIlsYZkcccf13Lq5H+S7hur2gGP+7IGu7VYq3SkYXRVkt/5urd+BbLBdunhtqJvEZh7LilGfmt4vo10OBeHpHX4+mBH300GuN4D1SHZjh6KxRYCGML1ruzEz39nvH5nCKr2FHtmfFeJFHZzRaOBTd0SMsJSqtbXfzhktDaLWj23HKDZwaLcfmNbteKjDFZZgIGS+gx23BUm50JmyiL8iJOKgWdRenaKrDKBxM4J68IeFTC6+0ksKkGPYg/DV0diEBCZFag3YWAuS9BDV/Lrub+FRwesIIRQkihspeeyqiueR1svJ+fH7VPErMKSiDJAcaXcnjKNHFSJgDIlCLCFVMCq4SWoNb63AZd4GO2NqdWkxOj1qmA2gU/OBbcEVySZzwYyFy7KuK9BZqIPjV2OBnyS0lXGgcMAiHUq2Z+lfSPvrDBCT4lqQuN8hT+yrRXdp0m3uVbUcN5e9Bf8jcIg6ArSSVwb4QeKWU/xUoHk+vw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2020 17:21:52.9596 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c62c2b88-d29f-4e3f-3ffd-08d7bae05f4a X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2471 Archived-At: Subject: [OAUTH-WG] Virtual Interim Meeting for the PoP Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 17:21:58 -0000 --_004_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_ Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_" --_000_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here are the details for the virtual interim meeting to discuss the proof-o= f-possession tokens. Date: March, 9th Time: 6:00 PM - 7:30 PM Monday, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, = Stockholm, Vienna Meeting number (access code): 641 458 628 Meeting password: BWsAF9rT Webex link: https://ietf.webex.com/ietf/j.php?MTID=3Dm03e9c040f9cd66650e1663f1da17d294 Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here are the details for the virtual interim meet= ing to discuss the proof-of-possession tokens.

 

Date: March, 9th

Time: 6:00 PM - 7:30 PM Monday, (UTC+01:= 00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

 

Meeting number (access = code): 641 458 628

Meeting password: BWsAF= 9rT

 

Webex link:

https://ietf.webex.com/ietf/j.php?MTID=3Dm03e9c04= 0f9cd66650e1663f1da17d294

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_-- --_004_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_ Content-Type: text/calendar; name="Webex_Meeting_OAuth_Virtual_InterimMeeting_9March.ics" Content-Description: Webex_Meeting_OAuth_Virtual_InterimMeeting_9March.ics Content-Disposition: attachment; filename="Webex_Meeting_OAuth_Virtual_InterimMeeting_9March.ics"; size=6784; creation-date="Wed, 26 Feb 2020 17:21:30 GMT"; modification-date="Wed, 26 Feb 2020 17:19:08 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkV1cm9wZS9CZXJsaW4NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9uZWlu Zm8tb3V0bG9vay9FdXJvcGUvQmVybGluDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQmVybGluDQpC RUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMjAwDQpUWk5B TUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9O VEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZS T006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6MTk3MDEwMjVU MDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UNCkVORDpTVEFO REFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMjI2VDE3MDgz MVoNCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86 aGFubmVzLnRzY2hvZmVuaWdAYXJtLmNvbQ0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlv biBQcm90b2NvbCBXb3JraW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpE VFNUQVJUO1RaSUQ9RXVyb3BlL0JlcmxpbjoyMDIwMDMwOVQxODAwMDANCkRURU5EO1RaSUQ9RXVy b3BlL0JlcmxpbjoyMDIwMDMwOVQxOTMwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW0wM2U5YzA0MGY5Y2Q2NjY1MGUxNjYzZjFkYTE3ZDI5NA0KVFJB TlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU4MjczNjkxMQ0KVUlEOjIwNDVkMzU3LWZlNzgtNDkwYS1i OTA0LTU2MGRjN2FlMzYwMg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdc bmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0wM2U5YzA0MGY5Y2Q2NjY1 MGUxNjYzZjFkYTE3ZDI5NFxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQxIDQ1OCA2 MjhcblxuXG5NZWV0aW5nIHBhc3N3b3JkOiBCV3NBRjlyVFxuXG5cblxuSk9JTiBCWSBQSE9ORVxu MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuVGFwIGhlcmUg dG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUy QjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQxNDU4NjI4JTIzJTIzKjAxKlxuXG5cblxuSk9JTiBGUk9N IEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2NDE0NTg2MjhAaWV0Zi53 ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBt ZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29m dCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjY0MTQ1ODYyOC5pZXRmQGx5bmMud2ViZXgu Y29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJvcmF0aW9u aGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQgTk9USUNF OiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90 aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3 aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRo aXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3Mu IElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNv bmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4NClgtQUxU LURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbioge1xuICAg IHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxhcHNlOiBz ZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fVxuXG50 ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAxNHB4Owlm b250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdv cmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1zaXplOiAy OHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31cblxuLmZv b3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVlbiBhbmQg KG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXplOiAyMnB4 ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50OwkJbWF4 LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEwMCUgIWlt cG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7XG4JCXdp ZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG59 XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRpbmc6IDA7 IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5cbgk8dHIg c3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4JCTx0ZCBh bGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJCTwhLS08 dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDogMTAwJTsg cGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249ImxlZnQiIGNs YXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRv cCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxuXG5cblxu XG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJl eCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJPHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQx IDQ1OCA2Mjg8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+XG4JCQlc bgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QldzQUY5clQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFi bGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDog MjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTx0cj5c bgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFibGUgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0aDphdXRv O3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9yZGVyOjBw eCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBweCFpbXBv cnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5bGU9InBh ZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTAzZTljMDQwZjljZDY2NjUwZTE2NjNmMWRhMTdkMjk0IiBzdHlsZT0iY29sb3I6 I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9pbiBtZWV0 aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+XG4JCQk8 L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiIHN0eWxl PSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklB TCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQgU0laRT0i NCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCws KjAxKjY0MTQ1ODYyOCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNv cmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWln aHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0la RT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0 ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjY0MTQ1ODYyOEBpZXRmLndl YmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj42NDE0 NTg2MjhAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIu NjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9O VD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48 dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNp emU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4g dXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48 L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMz OyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7 Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjQxNDU4NjI4LmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjY0MTQ1ODYyOC5pZXRmQGx5 bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4JCQk8dGFibGUgc3R5bGU9Indp ZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAgICA8 dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4J CQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6 QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdv IHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7 IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPlxuCQkJCQk8 L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgi Pjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8L3RkPlxuCTwvdHI+XG48L3Rh YmxlPlxuDQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJzDQpQUklPUklUWTo1 DQpDTEFTUzpQVUJMSUMNClJFQ1VSUkVOQ0UtSUQ7VFpJRD1FdXJvcGUvQmVybGluOjIwMjAwMzA5 VDE4MDAwMA0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVT Q1JJUFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVIN Cg== --_004_AM0PR08MB3716EA26DFDA0F087AC72B18FAEA0AM0PR08MB3716eurp_-- From nobody Thu Feb 27 09:51:11 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C0D3A0E14; Thu, 27 Feb 2020 09:51:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158282586005.2244.5252680392454483607@ietfa.amsl.com> Date: Thu, 27 Feb 2020 09:51:00 -0800 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-03-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 17:51:00 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-03-09 from 18:00 to 19:30 Europe/Vienna. Agenda: This meeting is setup to discuss proof-of-possession tokens. Several documents are relevant to this discussion, including https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 https://tools.ietf.org/html/draft-richanna-oauth-http-signature-pop-00 https://tools.ietf.org/html/draft-cavage-http-signatures-12 https://tools.ietf.org/html/rfc8613 https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07 https://tools.ietf.org/html/rfc7800 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33 https://tools.ietf.org/html/draft-ietf-oauth-mtls-17 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m9fc3ef4d116ad78e120c520eda96b269 From nobody Thu Feb 27 11:40:35 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368F43A0A42 for ; Thu, 27 Feb 2020 11:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPPsjyTXtmrT for ; Thu, 27 Feb 2020 11:40:31 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35FC3A0A41 for ; Thu, 27 Feb 2020 11:40:31 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 9E0783430 for ; Thu, 27 Feb 2020 19:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1582832429; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+p+/2FaOpEd8Ou/jQtT5xwFPBVRcBuCGiKU/biT6aWc=; b=Xj4hOLdBP7/zsmq9p/nj3vr0oOFzsja0xVLpyJw8vFvl6UZn694YnzCUgi6426HTZmT/X+ TRem9Xhv8n9x+QfHTM8/9ObQo0DiW4JWqZuMoJAjVlij6TnwC6wYKHOEH10qCtMi82rtsl 4FUzsXA8+3XxtjmpBft3m/HWQy0ApKI= To: oauth@ietf.org References: <158282586005.2244.5252680392454483607@ietfa.amsl.com> From: Daniel Fett Message-ID: <4575f9c4-7d28-63a2-d69f-d0d0baf4289e@danielfett.de> Date: Thu, 27 Feb 2020 20:39:24 +0100 MIME-Version: 1.0 In-Reply-To: <158282586005.2244.5252680392454483607@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------0F6119CFF5A4FB4D6664232E" Content-Language: de-AT-frami ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1582832429; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+p+/2FaOpEd8Ou/jQtT5xwFPBVRcBuCGiKU/biT6aWc=; b=cEySAuecPlEf5T9nM61LO4/jVyLz94r4Fj3kFfxsJ0gs4p4mNZUe4FjnUEEoJ6plKxdBQ7 cndjvh67+C6aStuegt9DSI9PFtk8r/YXNUD6ec+Fx5vWaPDvLh9sVgJTtWXmL+dZrH7AqC /B/s+emfK47qAjqJgFFDg4xF3PCH0LA= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1582832429; a=rsa-sha256; cv=none; b=VMv0mvlsY0VNOme3QQtxO8d5LbKXSQX2zS3RPo949yFWs6HkXyulKLyfsMIAG+5kmwMc/CVHjpn1CBsZv7S25uxOqAvMqN8JpE/9vzRB4lCXvB+STwiemGa8gqmScqNnw9iSfgM8fd48s2POLrnEGUoO2UXpc1xNuNhgqfmjP0I= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: --- Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-03-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 19:40:33 -0000 This is a multi-part message in MIME format. --------------0F6119CFF5A4FB4D6664232E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit What about DPoP? -Daniel Am 27.02.20 um 18:51 schrieb IESG Secretary: > The Web Authorization Protocol (oauth) Working Group will hold > a virtual interim meeting on 2020-03-09 from 18:00 to 19:30 Europe/Vienna. > > Agenda: > This meeting is setup to discuss proof-of-possession tokens. > > Several documents are relevant to this discussion, including > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 > https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 > https://tools.ietf.org/html/draft-richanna-oauth-http-signature-pop-00 > https://tools.ietf.org/html/draft-cavage-http-signatures-12 > https://tools.ietf.org/html/rfc8613 > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07 > https://tools.ietf.org/html/rfc7800 > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33 > https://tools.ietf.org/html/draft-ietf-oauth-mtls-17 > > Information about remote participation: > https://ietf.webex.com/ietf/j.php?MTID=m9fc3ef4d116ad78e120c520eda96b269 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------0F6119CFF5A4FB4D6664232E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
What about DPoP?

-Daniel

Am 27.02.20 um 18:51 schrieb IESG Secretary:
The Web Authorization Protocol (oauth) Working Group will hold
a virtual interim meeting on 2020-03-09 from 18:00 to 19:30 Europe/Vienna.

Agenda:
This meeting is setup to discuss proof-of-possession tokens.

Several documents are relevant to this discussion, including 
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
https://tools.ietf.org/html/draft-richanna-oauth-http-signature-pop-00
https://tools.ietf.org/html/draft-cavage-http-signatures-12
https://tools.ietf.org/html/rfc8613
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07
https://tools.ietf.org/html/rfc7800
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33
https://tools.ietf.org/html/draft-ietf-oauth-mtls-17

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=m9fc3ef4d116ad78e120c520eda96b269

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


--------------0F6119CFF5A4FB4D6664232E-- From nobody Thu Feb 27 11:56:49 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB43A0AA4 for ; Thu, 27 Feb 2020 11:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCF6ZooNQ0wN for ; Thu, 27 Feb 2020 11:56:45 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3FD3A0AA2 for ; Thu, 27 Feb 2020 11:56:45 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id f24so341877lfh.3 for ; Thu, 27 Feb 2020 11:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5KULZdLBqf8Cy+HWprna/QtY5FYoIoO8+zmJHUnOkP4=; b=WbwCcdhbNXjNqH8kk+jmJvfZ+/0BX1ipQ+jc4NKeVBWhwHU2EAEN0xC7sy9b4daPV7 Z5X42UrdFuj+0jzENbZKyd6GlP/g4ak1xsvVqKEEjiKoq4OK18UEnyp1+z6b/IrFiUZc lGosebkrulLADjRtYmoVgbZJEy9HXR9p9xmTTo1XnR7p9wxNMOQ/KyatDo/6AeKvhjUQ 0vGnYa6P8ChffLqGo6df9wumM2FkFDX8DSDWrGWdMqMMv0eMR3cug14R6eBhTPQFiKFT IAuYOi4rtvO2m4dfY0+ybg/vUwji/zM4i0Uh23OYJS9L3Pi6lMGOHSmCvRqSVGYYGOsr z6QA== 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=5KULZdLBqf8Cy+HWprna/QtY5FYoIoO8+zmJHUnOkP4=; b=hq6Na6O/aipzGaWSqIywIHn3gGW2KmSJIRGBjv8qt1R4/goiU98EQaCnKTeXsAd5kz HItcocZrs8VKpu0EGGEC3ctz8TWnVgKUCU/IjZyndRA+O9tr9uXRmF9w3d1IlqDdp6BX FuKnRLnPwCBJSq0Nwuir9VZCI6uhKjRF3J7ldnpX+A9QdvXWTp4EEXyLs+vtKXFO/ZXl hKsnk38+eMx+EQfToFYvgDpLtiXeR1PLCpSmvnU4BoFLErRSH1R1Wk8bVt+TPsmgmA34 WAe4a3fLjBTJGQnrMkWE/4cNr98a5xJZ6W6BJlHWx62yjwU3VRnw2wUi6l0gbDtlVpl+ xy5A== X-Gm-Message-State: ANhLgQ0hqmrjmmpGuQF0sHlMYyBZakXqaGemb9tGtmzdJJlLZpDqwk8Y DBuSWTwKZAP1gVY2puOX9QcA6YokaAg1wYmIt4Js/IvVHYlxr3isgnZ0vr0Mdc0y8sWn8BP+Pyt xn4KHmLtNCCjBbNYa X-Google-Smtp-Source: ADFU+vvj+DKe8z3cpRl3cEXHfSSN0AeGu+sq84MoXGXp0H8BLruORTZ+pysx4e3M5O8x/oG0phV9umdUmHJ3qjR3cXY= X-Received: by 2002:a19:3f4f:: with SMTP id m76mr562699lfa.63.1582833403298; Thu, 27 Feb 2020 11:56:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Thu, 27 Feb 2020 12:56:17 -0700 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="000000000000be1751059f941e7e" Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting for the PoP Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 19:56:48 -0000 --000000000000be1751059f941e7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for scheduling this Hannes. I'll put together some slides to help facilitate the discussion. On Wed, Feb 26, 2020 at 10:22 AM Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi all, > > > > Here are the details for the virtual interim meeting to discuss the > proof-of-possession tokens. > > > > Date: March, 9th > > Time: 6:00 PM - 7:30 PM Monday, (UTC+01:00) Amsterdam, Berlin, Bern, Rome= , > Stockholm, Vienna > > > > Meeting number (access code): 641 458 628 > > Meeting password: BWsAF9rT > > > > Webex link: > > https://ietf.webex.com/ietf/j.php?MTID=3Dm03e9c040f9cd66650e1663f1da17d29= 4 > > > > Ciao > > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000be1751059f941e7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for scheduling this Hannes. I'll put together s= ome slides to help facilitate the discussion.

On Wed, Feb 26, 2020 at 1= 0:22 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

Here are the details for the virtual interim meeting to discuss the proo= f-of-possession tokens.

=C2=A0

Date: March, 9th

Time: 6:00 PM - 7:30 PM=C2=A0Monday, (UTC+01:00) Amsterdam, Berlin, Bern= , Rome, Stockholm, Vienna

=C2=A0

Meeting number (access = code): 641 458 628

Meeting password: BWsAF= 9rT

=C2=A0

Webex link:

https://ietf.webex.com/ietf/j.php?MTID=3Dm= 03e9c040f9cd66650e1663f1da17d294

=C2=A0

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000be1751059f941e7e-- From bjung@pingidentity.com Thu Feb 27 22:21:10 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C713A1104 for ; Thu, 27 Feb 2020 22:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 2sAmEcBv4z31 for ; Thu, 27 Feb 2020 22:21:07 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014F53A1103 for ; Thu, 27 Feb 2020 22:21:05 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id v6so1208227lfo.13 for ; Thu, 27 Feb 2020 22:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=RC6NEDKQqmAmnCWDq7X9AuB+dwS8kqgM7gU7Rh4AnFY=; b=CYAyemCLrLNZTbLj/mFvry9rsolPNMXxa0MIY2cehQHCiMNc44OuKLuXjptwrq+b9Z xMBmsrR/1NfA9UELbngX/RtinRiEj5dxkpf5uh9xVnjleZBD5O0eW8pYTl2vsrpdcgvC R1u/eYJwGkUvIYnQjDhiJSz4YHkkhY9RqgKLEi+e9rj/O7UzjnURPI4kvntTLuM+Iv4f WLE8/PaljA1tPZfDF6saB+7VTrNSPJda7uODiXZK0xRx3eVSl91hU25PohLbCqUDNGxC ub1Vp4k1lkIqdcC9P8trJQ6tM4pzS8DgFvbNXT14I7wSl/0kxklIXQI4xZaM90qcaTd2 HJHw== 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=RC6NEDKQqmAmnCWDq7X9AuB+dwS8kqgM7gU7Rh4AnFY=; b=D3VzgIp/8hOj0LOuHcT1J8rtvMBqbxy5SLr5FS7Xf1rQjJGUAjLmWstbh6uc855ORb iLLSelJkLS2e7We0TA/CjeGRJqOTdIjn1HLfP2jVsnmUUDqtOgUD9oWrzUOK5sKyCzgO ub7DTP0p4NdkgMe50/IcJMv5B6rztXEMDvyjWKbQifCaoVoxSM5xAJeaML1g/41OIG4R 003PgaX8chjWUWqeL1NNQMB2isdGpYtyhEh+NjoLhIjs3AHtn5Riu6WF1n6HZHw9Copk clsXUBKq8nMBrwlNORoGs7bZhoAIm/EeMTCwtVG5Gf22DeFfHBoEyGufLktyp+1WQzDx xQKQ== X-Gm-Message-State: ANhLgQ1zFNSCm7YRcQ6mN1lM/0QSQhkgsaLojnSPI8iGYblivI5jafB0 iLj8kihdF+J87vPcpYG6PJDVk1lE9gyw3T38UB3sqtAvQTZv/ocdTqTaFXK7AurXcF0btGwN4Zh XXdYKhtzQqFm67hm41+E= X-Google-Smtp-Source: ADFU+vu+awKRKZYadcnJyF4neruPaDU9cN1WHHwFAHRWkJMJjcfy7idVaoKCdg03yZ5G8XWHwvncJXzOkkHmK5ZKVBk= X-Received: by 2002:a19:915c:: with SMTP id y28mr1709227lfj.127.1582870863344; Thu, 27 Feb 2020 22:21:03 -0800 (PST) MIME-Version: 1.0 From: Bill Jung Date: Thu, 27 Feb 2020 22:20:52 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000890bcb059f9cd700" Archived-At: X-Mailman-Approved-At: Fri, 28 Feb 2020 01:59:43 -0800 Subject: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 06:27:26 -0000 --000000000000890bcb059f9cd700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, hopefully I am using the right email address. Simply put, can this spec be enhanced to clarify "Who can use the introspection endpoint for a refresh token? A resource provider or a client app or both?" RFC7662 clearly mentions that the user of introspection endpoint is a 'protected resource' and that makes sense for an access token. If we allow this to client apps, it'll give unnecessary token information to them. However, the spec also mentions that refresh tokens can also be used against the endpoint. In case of refresh tokens, user of the endpoint should be a client app because refresh tokens are used by clients to get another access token. (Cannot imagine how/why a resource server would introspect a refresh token) Is it correct to assume that the endpoint should be allowed to client apps if they want to examine refresh token's expiry time? Then the RFC should clearly mention it. Thanks in advance. *
* In https://tools.ietf.org/html/rfc7662 In '1. Introduction' section says, *"This specification defines a protocol that allows authorizedprotected resources to query the authorization server to determinethe set of metadata for a given token that was presented to them byan OAuth 2.0 client."* Above makes clear that user of the endpoint is a "protected resource". And under 'token' in '2.1. Introspection Request' section says, *"For refresh tokens,this is the "refresh_token" value returned from the token endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."* So looks like a refresh token is allowed for this endpoint. [image: Ping Identity] Bill Jung Manager, Response Engineering bjung@pingidentity.com w: +1 604.697.7037 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Blog logo] --=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._ --000000000000890bcb059f9cd700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, hopefully I am using the right email address.=C2=A0=

Simply put, can this spec be enhanced to clarify &= quot;Who can use the introspection endpoint for a refresh token? A resource= provider or a client app or both?"=C2=A0

RFC7662 clearly menti= ons that the user of introspection endpoint is a 'protected resource= 9; and that makes sense for an access token. If we allow this to client app= s, it'll give unnecessary token information to them.
However, the sp= ec also mentions that refresh tokens can also be used against the endpoint.=
In case of refresh tokens, user of the endpoint should be a client app= because refresh tokens are used by clients to get another access token. (C= annot imagine how/why a resource server would introspect a refresh token)
Is it correct to assume that the endpoint should be allowed to client= apps if they want to examine refresh token's expiry time? Then the RFC= should clearly mention it.

Thanks in advance.=C2=A0

<= Details from the spec>
In https://tools.ietf.org/html/rfc7662
In '1.=C2=A0 Introd= uction' section says,
"This specific= ation defines a protocol that allows authorized
protected resources to q= uery the authorization server to determine
the set of metadata for a giv= en token that was presented to them by
an OAuth 2.0 client."=
Above makes clear that user of the endpoint is a "protected re= source".

And under 'token' in '2.1.=C2=A0 Introspe= ction Request' section says,
"For re= fresh tokens,
this is the "refresh_token" value returned from = the token endpoint
as defined in OAuth 2.0 [RFC6749], Section 5.1."=
So looks like a refresh token is allowed for this endpoint.= =C2=A0

<= /div>
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000890bcb059f9cd700-- From nobody Fri Feb 28 06:44:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A83A195F for ; Fri, 28 Feb 2020 06:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV-asGCt8O5Y for ; Fri, 28 Feb 2020 06:44:10 -0800 (PST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B506D3A1904 for ; Fri, 28 Feb 2020 06:44:09 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id m10so9512950wmc.0 for ; Fri, 28 Feb 2020 06:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wuESfpBQ/o97HkizzwAqptio6FzYmLmZud5v6bqdn14=; b=xoz0wkE4FIDVQUF1ZxQUKuJ7RtFPonFJwr6InDYPs9RmSLY40LlkgfrXt0F3cKZw+M Tgnh1S/YUfzJU39szaEqC+8woZktbrokcLjNM9kCLdCLqV5hWE4ySuznOGguWbB3/K++ VZMvJYwVjggx3zv33SoTZY6ovMOTUVkIJObRD+/JSr0zmWd7zf6GqpI8xtuJ+VxgY05W xtc2CEKh5j6m8LBAkVrisc6zLiBX+LifrRDmjnaTNQIBBpscCzDGFswg+U+gF2XYBg/L HuyJLeYk65yuD9D1gOCY4uwFXms7MozrJUKOVhrxmONSGqTYUuCMiTh5WpL1Xduz1cJ8 8R2Q== 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=wuESfpBQ/o97HkizzwAqptio6FzYmLmZud5v6bqdn14=; b=oBd2Hi/M+2K5HBRweSt2c4+ZtxrXzFc9768zN3mBZs5ydu6mRMc5myWEDmETa/w8cD LmWseoNVlUymnbdJn8jbhNn1soj6lTTnu4ONN2xU/V/Znle/mqo6ujWB2uaK03I+lupX wujPjj+iF3ogvR1mrc3Zo7Ni46KDN+orDFPVLYPh9eIr7M/p6CqzAxNR1DGMew2zae0P xk5iOCQXOXdbazCf4Jdy4K4ozf6LSK9DZGO2CqhO0Au7UPfGxU899c0FgZzMTulMK1rG CM1C2VFQUak2Itm6t+CoWi5h/fqnWcJT7VENG9AwGzXqOK55qMc3cic4SFTmOis3f5PE ApbQ== X-Gm-Message-State: APjAAAUJPRbkjUmJ2BeIBVD+4gEwLUlaUYC0KTbq9wMWnj7J4UF7XkPz D7IP3sY6Pgm5W9SliLEBkUoR4w== X-Google-Smtp-Source: APXvYqyDzuy707O00WFRxkJnY6EZxsseW2Brsip/2f7Ts2ycVGUhaw/WDeDDCIO7V6b3avYCMlNraA== X-Received: by 2002:a7b:cc88:: with SMTP id p8mr5056372wma.141.1582901047255; Fri, 28 Feb 2020 06:44:07 -0800 (PST) Received: from p200300eb8f11fd30144d505b7f770dad.dip0.t-ipconnect.de (p200300EB8F11FD30144D505B7F770DAD.dip0.t-ipconnect.de. [2003:eb:8f11:fd30:144d:505b:7f77:dad]) by smtp.gmail.com with ESMTPSA id g7sm12691931wrq.21.2020.02.28.06.44.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 06:44:06 -0800 (PST) From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2BA6DE8D-4FCE-49A7-94E6-D822C356A39A"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 28 Feb 2020 15:44:05 +0100 In-Reply-To: <158267113813.11133.3835985962594781644.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth , Rifaat Shekh-Yusef , Roman Danyliw To: Benjamin Kaduk References: <158267113813.11133.3835985962594781644.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 14:44:21 -0000 --Apple-Mail=_2BA6DE8D-4FCE-49A7-94E6-D822C356A39A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben,=20 > On 25. Feb 2020, at 23:52, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 >=20 >=20 This post focuses on clarifying your DISCUSS comments in order to get = the process moving again.=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for the updates in the -08; they address the bulk of the > substantive issues! I have a few points remaining on the -08 text but = I > think there are more localized issues to resolve. >=20 > Can IANA please confirm that the new allocations in the -08 have > received appropriate Expert (e.g., media type) review? I see some > updates in the datatracker history relating to the -08 but nothing in > the email archives. >=20 > It looks like we need to register 'active' as a JWT claim? That=E2=80=99s correct. Will add this.=20 >=20 > I don't think the new semantics for "jti" in the introspection = response > are compatible with the RFC 7519 definition. Specifically, we say = that > "jti" will be tied to the input access token, but 7519 says that "jti" > has to change when the contents of the JWT change ("MUST be assigned = in > a manner that ensures that there is a negligible probability that the > same value will be accidentally assigned to a different data object"), > and we admit at least the possibility of "active" and "iat" changing. I think the key word is =E2=80=9Caccidentally=E2=80=9D. This spec causes = the AS to purposefully issue JWTs with the same =E2=80=9Cjti=E2=80=9D in = order to allow replay detection with respect to the introspected access = token. =E2=80=9Ciat=E2=80=9D is changed in order to give the RS an = indication and proof when the introspection response was minted by the = AS. =E2=80=9CActive" does not really change, since the introspection = response of an inactive token is empty except the =E2=80=9Cactive=E2=80=9D= element.=20 So I don=E2=80=99t see issues regarding RFC 7519. >=20 > Section 5 says that: >=20 > If the access token is considered active, it MUST contain the claims > "iss" and "aud" in order to prevent misuse of the JWT as an ID or > access token (see Section 8.1). >=20 > But I don't think the predicate is correct -- misuse is still possible > by services that do not check the "active" claim's value. Shouldn't = the > "iss"+"aud" requirements be unconditional? Introspection responses for inactive tokens won=E2=80=99t contain any = data except =E2=80=9Cactive=E2=80=9D:false. I don=E2=80=99t see how they = could be misused and therefore think the text is ok. Please let me know whether you agree with my statements. I would then = quickly publish a new revision (including changes to address your = comments). best regards, Torsten.=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > [New comments on the added text in the diff from -07 to -08.] >=20 > Section 3 >=20 > To support encrypted token introspection response JWTs, the > authorization server MUST also be provided with the respective > resource server encryption keys and algorithms. >=20 > IIRC, based on some list discussion this text was going to be tweaked = to > avoid implying that JWE is mandatory. (Unfortunately, this is the > thread that evolved into "client certs and TLS Terminating Reverse > Proxies", so it's hard to be sure whether I saw any other followups.) >=20 > The AS MUST restrict the use of client credentials by a RS to the > calls it requires, e.g. the AS MAY restrict such a client to call = the > token introspection endpoint only. How the AS implements this > restriction is beyond the scope of this specification. >=20 > This should probably be clarified a bit more, in the context of = "client > credentials tend to be used by privileged, fixed endpoints, and the > default may just be to allow them all access to all endpoints". Right > now it's not clear what's being restricted (and who "it" is that > requires calls) >=20 > Section 5 >=20 > This specification registers the "application/token- > introspection+jwt" media type, which is used as value of the "typ" > header parameter of the JWT to indicate that the payload is a token > introspection response. >=20 > Do we also want to note that checking 'jti' is not mandatory and so = this > does not necessarily provide full protection? (I guess Section 8.1 > covers this in more detail.) >=20 > The value of the "aud" claims MUST identify the resource server > receiving the token introspection response. >=20 > We may want to dig into this a bit more: should there be any > relationship between this "aud" value and the "client_id" that an RS > might be using (as obtained from dynamic registration)? > Does this value need to be different from the audience that is used in > access tokens for which this RS is the audience? (Should it be the > same?) My instincts lean towards "different" but I would like broader > input. >=20 > exp The "exp" claim indicates when the access token passed in = the > introspection request will expire. >=20 > On the face of it this seems divergent from RFC 7519's "the expiration > time on or after which the JWT MUST NOT be accepted for processing", > though upon further examination the distinction is not quite so large. > That is, it's in effect saying that the introspection response should > not be accepted for processing after the base token has expired, which > usually makes sense. There is a bit of a complication, though, in = that > the "active" claim implies that we might still have RSes that plan to > use the introspection response after the "exp" date has passed, which > sounds a lot like a DISCUSS-level internal inconsistency. >=20 > If possible, the AS MUST narrow down the "scope" value to the scopes > relevant to the particular RS. >=20 > This sounds kind of like a "SHOULD"... >=20 > The example response header contains the following JSON document: >=20 > I think this is the JOSE header in the HTTP response (body), not the > (HTTP) response header. >=20 > Section 8.1 >=20 > As an alternative approach, such an attack can be prevented like any > other token substitution attack by restricting the audience of the >=20 > I'd suggest avoiding describing these as "alternatives"; they seem = more > like complementary approaches as part of a defense-in-depth solution > (especially since we are basically mandating both of them). >=20 > "aud" value set to the resource server's identifier. Any recipient > of an JWT MUST check these values in order to detect substitution > attacks. >=20 > This "MUST" might be out of place -- this is a requirement from RFC > 7519, and not an attempt by this document to make new requirements on > the behavior of all JWT consumers (if it was, that would be a DISCUSS > point!). >=20 > Resource servers MUST additionally apply the countermeasures against > replay as described in [I-D.ietf-oauth-security-topics], section = 3.2. >=20 > In a similar vein, which set of resources servers is this normative > "MUST" intended to be binding upon? >=20 > Section 9 >=20 > In any case, the AS MUST ensure that the scope of the legal basis is > enforced throughout the whole process. The AS MUST retain the scope > of the legal basis with the access token, e.g. in the scope value, > and the AS MUST determine the data a resource server is allowed to > receive based on the resource server's identity and suitable token > data, e.g. the scope value. >=20 > I suspect I'm just being dense, but could you walk me through how the > access token "scope" value can encode the legal basis for data = transfer? >=20 >=20 >=20 --Apple-Mail=_2BA6DE8D-4FCE-49A7-94E6-D822C356A39A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC38w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggaDMIIEa6ADAgECAhBP3hBL7ZVb3outZYfMQV7jMA0GCSqGSIb3 DQEBCwUAMGsxCzAJBgNVBAYTAklUMQ4wDAYDVQQHDAVNaWxhbjEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxJzAlBgNVBAMMHkFjdGFsaXMgQXV0aGVudGljYXRpb24gUm9vdCBD QTAeFw0xOTA5MjAwNzEyMDVaFw0zMDA5MjIxMTIyMDJaMIGNMQswCQYDVQQGEwJJVDEQMA4GA1UE CAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt2hzetk81C/73GfKPc6UfP+J Gc7aGmPzGUeQJ1go3CdFpsBPonREDXUDdmRCIRkTDroH30RLsTO/0hEFiYjCyvvbSVSm05sXkvfJ XOXefNqK21fBayr4JCgMRyLVwqRYXlKI7bb42nYSm7YcXGTDmdcydmJuuqcLqFQawWiBMNRRVEi4 uW5uXBZgWGmq8NoKH/+5xGBFbf6tNTWcGhPVceResuwK155+OiH6jTW01Na8aLj7c7IAGJ0Y9e6h iHtRthfW7SwbU7ys73a3nNXv8Kv9XNr0RvJKHoOsKqxjffew3GKQrMXIHB5tm/je3XEnIxUT8JG3 sEsk7IfF3VirSwIDAQABo4IB/jCCAfowDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRS2Ig6 yJ94Zu2J83s4cJTJAgI20DBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3Nw MDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUH AgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAnBgNVHSUEIDAeBggrBgEF BQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMJMIHjBgNVHR8EgdswgdgwgZaggZOggZCGgY1sZGFwOi8v bGRhcDA1LmFjdGFsaXMuaXQvY24lM2RBY3RhbGlzJTIwQXV0aGVudGljYXRpb24lMjBSb290JTIw Q0EsbyUzZEFjdGFsaXMlMjBTLnAuQS4lMmYwMzM1ODUyMDk2NyxjJTNkSVQ/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdDtiaW5hcnkwPaA7oDmGN2h0dHA6Ly9jcmwwNS5hY3RhbGlzLml0L1JlcG9z aXRvcnkvQVVUSC1ST09UL2dldExhc3RDUkwwHQYDVR0OBBYEFGvyjZ5owSUEH1E0V/YWXJTqTWka MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAYES6GaKrcvsOQZpEwboVOb2dri/f Jrcpb7GSEW9JmA+Kep4GLmp9X50Iv8EK478kwf2aAjnPnsOdiItALcIgecS1qVxN+EY+V5GCNEy4 VAsB5gzlQBmKI9P4PxLt9pnQJneCVEvDnVBMZAllIL5s3uaCiIEb8eYZqG8taOWSM1nqjoCZULcc hXWYajBqaJg0RUOZ6f5IB0lb26HA/7EUVmh1nSVglDoUeD7elINXHph0z3if1722UydcoH4Jj3Za Y9dtQ4wJSNhSZOzES72UkS6we/556FOGs7oeJWuQe8Rq2EeeSGmGliZKUbYo4jB/C2omMn0L4QwI 5wMNrWd2FRNUUwxMBmbJYtEaDRTQ72HPA8DnbRkvRDSJkjsToqU6ZpBlBf4s5EwrhXqFVb2rM9mG CPDZJi7Hw3y8BYD/d3iTL6PW5UjOTSpFcnSIP4HW5PI6MTHXl+ab6ajCnvJw6E1TGLh3zJypv5CQ 8Ftm0z7MKLt5Zr2E4jojZXeZn1sUpSqidZyp9mG/LYMRmHMkthDRnDnO2tHv5+YOO4cUEbTt5Bww E5RPjqovsnedyd5SijIK+k1MCXFLMTfERz3qUN3i/fwueXcGy4jEf2n/FvYsEY3GBHXZCMVWPffB fbl/ITjs9Q9NG37bAEm/mg2yNq02NLjDbQIKgt9W0aBU9SsxggOpMIIDpQIBATCBojCBjTELMAkG A1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAh BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVu dCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCC AdcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMjI4MTQ0NDA1 WjAvBgkqhkiG9w0BCQQxIgQgO6u7eMG9/u5kEG8L64P2cxwLESsMhofbK0Ul5bKy6rQwgbMGCSsG AQQBgjcQBDGBpTCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcM EFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSww KgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7 IHRfgzCBtQYLKoZIhvcNAQkQAgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJn YW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8w MzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzIC EGl8QiQdCJabMXrMOyB0X4MwDQYJKoZIhvcNAQEBBQAEggEAMzjcy22cPX6eTfb2w4wXNcQ5G2yV xO3q8xPIcTBq7ALVti5wiEy8xn7wRJYV/HloQJaHAiS/A6zxpWYmxTA6dCeHOSVdoQU2BMrMZFgc PV6Zi1RlvaqvH2oIs9EtjYfjGxE1fHigpFaZxFAHV4EpQrY5EUcEbwveFLYacZtKpVaTaW3VyDmZ A0ccuQbZ5j6C+vywaWbU9pZF3y8qnjv4LJ+KpdEN3kOWYH1uCiu2eL7Va0KJKZlHxQtQrUlWCW+T lyMtZWyS+wPSnfxp6tjGX789EQ79Ju1q7y0IjpdNgXGkZ8s37HsiHolKSyy26i3S/qJ2ArhGzfzg BrYSm+dxHAAAAAAAAA== --Apple-Mail=_2BA6DE8D-4FCE-49A7-94E6-D822C356A39A-- From nobody Fri Feb 28 06:55:12 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E92F3A1924 for ; Fri, 28 Feb 2020 06:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 jvovHbPtLkav for ; Fri, 28 Feb 2020 06:55:08 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CACE3A0B1E for ; Fri, 28 Feb 2020 06:55:04 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id dm3so3690173edb.1 for ; Fri, 28 Feb 2020 06:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oLqzG0LkT9jxtKE59A0kruZ9OwZOTiX2uxvioYWJJE0=; b=mhzp7XgT6g7Nrs4ZvcLuItNXWOProphN04Ooi4G3FJayUjwaZpK4HQEpmuo8O9YIkV kmxvFW0SHMADTKEZ7KHB+hw4XKoI9vQ1GIQlAy6EB2WauUXgetjxkhti+U/zlMPn0sJS L10G3rOkXOXnTXcbIL8/yQCXfG6P7aVmZ8dZbf89PsgWkRebrOOyB7WVOwF7HEiF855m aditkIED52xytyLifdYeVAGss9NdQ9ax09zpuuQ5JEzw1pJuPaYzM27r/B/iMH0LkS2q mHHGkKXiJIqzghufG/WaRGjt1v/MdVZqbFA4saFE/9dn8tPoxyPVW95sSeALqCDVxbDs Hgug== 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=oLqzG0LkT9jxtKE59A0kruZ9OwZOTiX2uxvioYWJJE0=; b=rYgCA5fwA6UfmIMSC9TiahjPErGyajFzkwW7XgiReriSgXPoqXdQKjvXCB9U5B31I4 cEmXluGUZPX68VdK4y3qhdzLdQJw+aR5v2JFx2l6v1I24NOx5bbtTTOJHwOQTzEkwbuX 7YwowxJgn1DVU4XSudU7khwmi2CdgdCz2uXuqJh2mHlAD+URCmQSqXmaWaG9i1HnV+d1 8Qjizo5oxGVur4bbOmNFLB/YJr23fDAbI89ITewj8HSMFSkUOW9/RRBd2OoAmAAf6Ftd Tm/Yt0BsbOy1h0HsRsUPpmI6WzlnoogSULvUl0fyG5W9ukVuJc3fzM2gMKYsCGHSY7Ht Nq0w== X-Gm-Message-State: APjAAAVipUW+yHd8eaEexg7VyVHnD+pokXRt9WRcKSj4Qz3k0SMecJBI BCdTpQaxHs20IMe62YhnE1New9Nc31NjXt6FfK5u6nH8hT4= X-Google-Smtp-Source: APXvYqwS6CUildrjCFyGR0MP//0PLZNWBtDQz2tS5qLQwTWyhnzbgDn33YcY1y34aqC0hnG183kXBrMqP/QDcsU7tC4= X-Received: by 2002:aa7:d747:: with SMTP id a7mr4658223eds.82.1582901702763; Fri, 28 Feb 2020 06:55:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Skaife Date: Fri, 28 Feb 2020 14:54:53 +0000 Message-ID: To: Bill Jung Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b535ba059fa405a0" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 14:55:10 -0000 --000000000000b535ba059fa405a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, In additional to Bill's query, the use of the term "protected resource" in the context of RFC7662 is quite confusing. As defined by RFC6749 (which RFC7662 defers to for definition of the terms), the term "protected resource" is defined as an "access-restricted resource" that a client can request. In the context of RFC7662, it doesn't make sense for an "access-restricted resource" to be making any requests to the introspection endpoints - surely it is the resource server that is the intended consumer of the introspection endpoints? This is also backed up by Section 4 (Security Considerations) of RFC7662 which reverts to using the term "resource server" as the consumer of the introspection endpoints. For example, in these quotes: "However, since resource servers using token introspection rely on the authorization server to determine the state of a token.." and "...the authorization server MUST determine whether or not the token can be used at the resource server making the introspection call" Apologies if I've misinterpreted something here, but if RFC7662 has a different meaning for the term "protected resource" from RFC6749 then it should be stated clearly within that document. I also agree with Bill's observation that it doesn't make sense for a refresh token to passed into an introspection request as a refresh token should only be accessible to the client and the authorization server (neither of which are intended consumers of the introspection endpoints). Many thanks, David Skaife On Fri, Feb 28, 2020 at 9:59 AM Bill Jung wrote: > Hello, hopefully I am using the right email address. > > Simply put, can this spec be enhanced to clarify "Who can use the > introspection endpoint for a refresh token? A resource provider or a clie= nt > app or both?" > > RFC7662 clearly mentions that the user of introspection endpoint is a > 'protected resource' and that makes sense for an access token. If we allo= w > this to client apps, it'll give unnecessary token information to them. > However, the spec also mentions that refresh tokens can also be used > against the endpoint. > In case of refresh tokens, user of the endpoint should be a client app > because refresh tokens are used by clients to get another access token. > (Cannot imagine how/why a resource server would introspect a refresh toke= n) > > Is it correct to assume that the endpoint should be allowed to client app= s > if they want to examine refresh token's expiry time? Then the RFC should > clearly mention it. > > Thanks in advance. > > *
* > In https://tools.ietf.org/html/rfc7662 > In '1. Introduction' section says, > > > > *"This specification defines a protocol that allows authorizedprotected > resources to query the authorization server to determinethe set of metada= ta > for a given token that was presented to them byan OAuth 2.0 client."* > Above makes clear that user of the endpoint is a "protected resource". > > And under 'token' in '2.1. Introspection Request' section says, > > > *"For refresh tokens,this is the "refresh_token" value returned from the > token endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."* > So looks like a refresh token is allowed for this endpoint. > > > [image: Ping Identity] > > Bill Jung > Manager, Response Engineering > bjung@pingidentity.com > w: +1 604.697.7037 > Connect with us: [image: Glassdoor logo] > [image: > LinkedIn logo] [image: twitter > logo] [image: facebook logo] > [image: youtube logo] > [image: Blog logo] > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b535ba059fa405a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

In additional to Bill's query, = the use of the term "protected resource" in the context of RFC766= 2 is quite confusing. As defined by RFC6749 (which RFC7662 defers to for de= finition=C2=A0of the terms), the term "protected resource" is def= ined as an "access-restricted resource" that a client can request= . In the context of RFC7662, it doesn't make sense for an "access-= restricted resource" to be making any requests to the introspection en= dpoints - surely it is the resource server that is the intended consumer of= the introspection endpoints? This is also backed up by Section 4 (Security= Considerations) of RFC7662 which reverts to using the term "resource = server" as the consumer of the introspection endpoints.
For example= , in these quotes:
"However, since resource servers using token introspection rely on the= =C2=A0authoriza= tion server to determine the state of a token.." and
"...the=C2=A0authorization server MUST determine whe= ther or not the token can=C2=A0be used at the resource server making the introspection cal= l"

Apologies if I've misinterpreted something here, but if RFC7662 = has a different meaning for the term "protected resource" from RF= C6749 then it should be stated clearly within that document. I also agree w= ith Bill's observation that it doesn't make sense for a refresh tok= en to passed into an introspection request as a refresh token should only b= e accessible to the client and the authorization server (neither of which a= re intended consumers of the introspection endpoints).


Many thanks,
David Skaife

On Fri, Feb 28, 2020 at 9:59 AM = Bill Jung <bjung=3D= 40pingidentity.com@dmarc.ietf.org> wrote:
Hello, hopefully I am usi= ng the right email address.=C2=A0

Simply put, can t= his spec be enhanced to clarify "Who can use the introspection endpoin= t for a refresh token? A resource provider or a client app or both?"= =C2=A0

RFC7662 clearly mentions that the user of introspection endpo= int is a 'protected resource' and that makes sense for an access to= ken. If we allow this to client apps, it'll give unnecessary token info= rmation to them.
However, the spec also mentions that refresh tokens can= also be used against the endpoint.
In case of refresh tokens, user of = the endpoint should be a client app because refresh tokens are used by clie= nts to get another access token. (Cannot imagine how/why a resource server = would introspect a refresh token)

Is it correct to assume that the e= ndpoint should be allowed to client apps if they want to examine refresh to= ken's expiry time? Then the RFC should clearly mention it.

Than= ks in advance.=C2=A0

<Details from the spec>
In https://tools= .ietf.org/html/rfc7662
In '1.=C2=A0 Introduction' section sa= ys,
"This specification defines a protoc= ol that allows authorized
protected resources to query the authorization= server to determine
the set of metadata for a given token that was pres= ented to them by
an OAuth 2.0 client."
Above makes cl= ear that user of the endpoint is a "protected resource".

= And under 'token' in '2.1.=C2=A0 Introspection Request' sec= tion says,
"For refresh tokens,
this = is the "refresh_token" value returned from the token endpoint
= as defined in OAuth 2.0 [RFC6749], Section 5.1."
So look= s like a refresh token is allowed for this endpoint.=C2=A0


= = =
3D"Ping
Bill Jung
Manager, Response Engine= ering
bjung@pingidentity.com=
w: +1 604.697.7037
= =
Connect with us: 3D"Glassdoor = 3D"Linke= 3D"twitter 3D"facebook = =

<= 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
--000000000000b535ba059fa405a0-- From albin@bergson.nu Fri Feb 28 07:47:04 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAE93A1A7C for ; Fri, 28 Feb 2020 07:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, 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 wwAF3OIqKm8g for ; Fri, 28 Feb 2020 07:47:03 -0800 (PST) Received: from smtpout-36.fbg1.glesys.net (smtpout-36.fbg1.glesys.net [IPv6:2a02:751:100:1::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 A5AC13A1A83 for ; Fri, 28 Feb 2020 07:47:02 -0800 (PST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by mail-halon-01.fbg1.glesys.net (Halon) with ESMTPSA id 8cf6a0d3-5a41-11ea-bd3c-0bec97ae8c39; Fri, 28 Feb 2020 16:46:59 +0100 (CET) Received: by mail-lj1-f178.google.com with SMTP id d10so3802104ljl.9 for ; Fri, 28 Feb 2020 07:46:59 -0800 (PST) X-Gm-Message-State: ANhLgQ1mhLn2xKQNRkiTJRJ2LcQuzagJYtNzPzp7BuZcgDOP78B8Cxim SoS+6Xd95DwkJ9Os82mtqOjAHs722UTx6CH9bYw= X-Google-Smtp-Source: ADFU+vtMt7IHmJz4hKU+2RM3AA631E0McfxXfDD68d0dYwRl+hgC0U3YF/hO65K/ntxAApYCXbVaM/boVLHRIyNGdvM= X-Received: by 2002:a2e:6f19:: with SMTP id k25mr3364461ljc.84.1582904817112; Fri, 28 Feb 2020 07:46:57 -0800 (PST) MIME-Version: 1.0 From: Albin Nilsson Date: Fri, 28 Feb 2020 16:46:46 +0100 X-Gmail-Original-Message-ID: Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000565ae0059fa4bff2" Archived-At: Subject: [OAUTH-WG] PKCE and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 15:48:32 -0000 --000000000000565ae0059fa4bff2 Content-Type: text/plain; charset="UTF-8" Hello, I'm having some trouble with oauth and the Authorization Code flow and PKCE. How can I get a refresh token? The refresh token flow requires a client_secret, but PKCE prohibits client_secret. Is refresh token a no go? Kind regards, Albin --000000000000565ae0059fa4bff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm having some troubl= e with oauth and the Authorization Code flow and PKCE. How can I get a refr= esh token? The refresh token flow requires a client_secret, but PKCE prohib= its client_secret. Is refresh token a no go?

Kind re= gards,
Albin
--000000000000565ae0059fa4bff2-- From nobody Fri Feb 28 08:08:27 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC353A1A8E for ; Fri, 28 Feb 2020 08:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 f1u-ws9She6i for ; Fri, 28 Feb 2020 08:08:23 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803863A1A78 for ; Fri, 28 Feb 2020 08:08:23 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id p14so3889325edy.13 for ; Fri, 28 Feb 2020 08:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :content-transfer-encoding; bh=dx7a5PGQbjSnp0oY/lgvx1GAmmfq06oX4j1bFloXpYY=; b=PpC9nMNACr0pcSZq9KUoiztwEivFXt6M27Ya8Hz8H+iIaVCg9yhc+PtaL9M+Dg+4B2 kxzfMYpTQl4mT4aBfZCIQOmKXwCadYR+cUFtCfgmCq4LCYJtxx421vyqBwJ5y71SNNbz S1a4tyEsXK89qL5fi6lN4oG6i3QTOwt2FNDpkMtKvBAWbylsWKJLkh0GGKe3jk8qbAFx cuPDNR3QWagQg8/yZD7VGs3hOyGbx5kB+WvAvTdXV5fMmknS4vqZM9ZrIZ/8oR2T8YhQ s23TTDSrd0L3FnrR0v2FgcaH79jWFSEU19lfStHk1mzPOZg+lP+MSonC0bN6/5s03z3T Ev9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:content-transfer-encoding; bh=dx7a5PGQbjSnp0oY/lgvx1GAmmfq06oX4j1bFloXpYY=; b=PBRqlFH52E2sJg3P/5TQ0b1gZ1M64DCE993qELi3zDre4g9MN5sScT8SEeBjcD6yoO 7xK8OBT/HG1KgH6lIO3pf9/StQo+KonCUARch6lt0xdSY6VK6yZCFVvhgAW99MV3428Q tcDKuWDjNQ8/h024ArbAytlpVENTugG8CsTajvzN++5TT55bSld1avyPQMXAvuy6E3lw T4LnY/glx+F4ChQiwc7X9pyDh+qxamIBkdWZ9IftDlCy5oVwBsfKJhXa6U325hynOREy MHo5vSo9Ce0swTn3JM/SfyXzQ6MZ1r2mDIn1VaVvTYX1ortdf+syU3xre/4MDij8VQtf J7mw== X-Gm-Message-State: APjAAAXeTgiu3ktNm6nluFki8YVlX7q+gCYchXysbQzGkFvH7+d5RrE5 JyQa5uoKAgYC7D13zB0wP8JSI4RSJWlBdeHiH3q3TQ== X-Google-Smtp-Source: APXvYqyxiy2VBTfdWVXq60ETukCJLgPcJSquhdCAc/DTCYvtWt/1h+yvIVI+cfoGF2SNYAzhALcFE4iWeHS1gkLL418= X-Received: by 2002:a05:6402:b81:: with SMTP id cf1mr4878334edb.131.1582906102059; Fri, 28 Feb 2020 08:08:22 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 28 Feb 2020 08:08:21 -0800 From: Ron Alleva In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 28 Feb 2020 08:08:21 -0800 Message-ID: To: Albin Nilsson , oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] PKCE and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 16:08:26 -0000 Hi Albin, It=E2=80=99s important to note that PKCE does explicitly prohibit client_secret, just offers a secure way of obtaining an access token when it=E2=80=99s impossible for a client_secret to be kept secret, as woul= d be the case with a mobile application. The type of attack it prevents against is during the authorization_code flow, where a malicious app on the device could intercept the browser redirect happening, and getting the authorization_code. Since using a refresh token to get a new access token does not use the browser redirect flow, it=E2=80=99s not subject to that type of attack, so PKCE is not necessary. I=E2=80=99d imagine which ever Authorization Server you are using would all= ow you to get refresh tokens, and use them with or without client authentication (see section 2.3 of the OAuth spec). It may or may not require a client secret (even though said client secret is not guaranteed to be secret). Hope this helps (and I didn=E2=80=99t mess up any details :D), Ron On February 28, 2020 at 10:48:53 AM, Albin Nilsson (albin@bergson.nu) wrote= : > Hello, > > I'm having some trouble with oauth and the Authorization Code flow and > PKCE. How can I get a refresh token? The refresh token flow requires a > client_secret, but PKCE prohibits client_secret. Is refresh token a no go= ? > > Kind regards, > Albin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Feb 28 11:07:12 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ECD3A19EA for ; Fri, 28 Feb 2020 11:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlDVZd4SlW-8 for ; Fri, 28 Feb 2020 11:07:07 -0800 (PST) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C533A19E5 for ; Fri, 28 Feb 2020 11:07:07 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 5DECB385F6F; Fri, 28 Feb 2020 19:07:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1582916824; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PM9SNqF0BB6hDcf/dlCKLaxzNnk7/TGIigmm3ZGOXMY=; b=MMa7ClAirNbDENn3aqohg/NRKu0+3o7yhaAOzbyD7TiLp3TW1GBVD5KrEu30zCcHaimPGt mZ+2bT+rmNFuoXFacUPDHQvDEWORJ9RPN8bgnghSCVdktHFAn5cNUU6Sj1YROqND9I7f0C pzsOg4fNIBSkYpM0vIr/rSRVYElVOLE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 From: David Waite In-Reply-To: Date: Fri, 28 Feb 2020 12:07:03 -0700 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Albin Nilsson ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1582916825; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PM9SNqF0BB6hDcf/dlCKLaxzNnk7/TGIigmm3ZGOXMY=; b=C3fNfLMsQlyyiaS2YXXUvfvkOaRWKaiIKiTrYIyqtmAtK4dtP6nqa0TsvYGPQa6+65/dfS 2aKm/ZhtRNBNJxuTp1KqoMGk0ycfWbyXPTUdhKXoJaq0z+pZSU5yiKUFKulZRUKu96owdk ULaVNGXY871ED0jci6bcJ2yctmG/oUw= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1582916825; a=rsa-sha256; cv=none; b=NpvoIc2vHgh5R1CJBR7qp/XjjnmWQ7W7ihpNSNS3Cg/g0h64LWd0/8ND2QNcmzPraGgjHO 8BLCRgkweGlD5G5LWqQukzgOc6mOMG6ntlkSAnEalxZ3Zc0S+pZJ3dZdgQ1s0MrOTKp4if 8ZVQiNlPwWaSFrN2owAR2VNoqzmZZ5c= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] PKCE and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 19:07:09 -0000 > On Feb 28, 2020, at 8:46 AM, Albin Nilsson wrote: >=20 > Hello, >=20 > I'm having some trouble with oauth and the Authorization Code flow and = PKCE. How can I get a refresh token? The refresh token flow requires a = client_secret, but PKCE prohibits client_secret. Is refresh token a no = go? PKCE provides XSRF protection and proof that the two parts of the code = flow are from the same client. It does not forbid using client secrets, = and is recommended by the security BCP for both public and confidential = clients due to its XSRF protection. Refresh token grant requests only require authentication (such as with a = client secret) for confidential clients. Public clients are permitted to = refresh without providing a secret or other credentials. The lack of allowances for public clients by some implementations = initially is why the AppAuth BCP and browser-based apps draft allows for = the use of a secret in both the code request and refresh request - with = the understanding by the AS that policy-wise this must be treated as a = public client. -DW From nobody Fri Feb 28 12:13:55 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830083A1D41 for ; Fri, 28 Feb 2020 12:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYpqk6-LCPzC for ; Fri, 28 Feb 2020 12:13:46 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276B13A1D54 for ; Fri, 28 Feb 2020 12:13:46 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id j34so3013882qtk.4 for ; Fri, 28 Feb 2020 12:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m7jjfQGPCkLu3GUYCflpKD4PFk7HbcsSSlSD0Qg9kBs=; b=i0Gmu3d1nP5lfvLg3r893Vo2RbBVFqEy8mPhEl0WOtpOW4V3k02oRR5uhCzh4l3v6s BYGJqsu4rEpvaUxkuCWE33hr99V3nFk4JfCDW48qmUApbFevV3eXhQEm+sfUD9KmgMbi 8uXzILwQcDhNQr6OI66YtdITsq2Fp5kgvxuKSEQcMrIKkzizEovWlv4r2pzUsFlqX4p+ A3+wyxi00Dlh5zdmni3GEFupCvBmVjotxP2gQqY57WILQrtzKNqtL0mE0EK1mZC26K2T n5gFz0g1Gc3bjvFkjsxM2kQLgPOtkLugPVXHeTOUJkKJ4g5d0pCVwc9viMUm9GKmMcHq 1OBQ== 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=m7jjfQGPCkLu3GUYCflpKD4PFk7HbcsSSlSD0Qg9kBs=; b=UBArb9i9AwKexHdVDZl2zrWs2wG3H6jRdMN0yEl96MjMVa1DotcuN83c1HT/OT6ck+ b4YvIqCINvnLt5VXLKu3gZn57YFna+Za9hf956zV5DuNKUVA3Tz5qh6+rEPQdcdwA1+G bQNyP3wFQ+nNj3mVUcWS2UjSItVCKpvPq18cm8hMdQIFBzsXcWCNPXoBG9W98uEGoqQN BPI5pObgg9yi5tDJ39JZQ926dvK1NL1noAYf5xUF8GlfnNtnXMK/IchzsVCD8aoXv5Mw wS9JLd4sIxxF/H4UeSX9AySrP87JaCHrbnX9vgqUhXB9QS8dqtiFVpuMRhuOcDPp9602 0iAw== X-Gm-Message-State: APjAAAX1CE5Jgjt779OSnJSDcthUClFbQBmy5yP6zq/9J8WAMYrQwm6u 36gRIGQOTeUCSwjoSynvH8wx20Hf8b8t7dvlbpA= X-Google-Smtp-Source: APXvYqzvG6MsQc1dRFR8/YzVvf9a6lsozo4TGCvXO4xwRCu6bK2To6sMHxwGETha+fqzEjRlOUrwwnb9/KUy+W6AXY0= X-Received: by 2002:aed:3ec6:: with SMTP id o6mr4378655qtf.80.1582920825090; Fri, 28 Feb 2020 12:13:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Naveen Agarwal Date: Fri, 28 Feb 2020 12:13:33 -0800 Message-ID: To: Albin Nilsson Cc: oauth Content-Type: multipart/alternative; boundary="0000000000007cb59b059fa879ef" Archived-At: Subject: Re: [OAUTH-WG] PKCE and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 20:13:54 -0000 --0000000000007cb59b059fa879ef Content-Type: text/plain; charset="UTF-8" Hi Albin, Are you writing both the client and the server or writing client code to auth against a standard server? Unless you are writing the auth server code, using a library would be the best way to simplify. Thanks Naveen On Fri, Feb 28, 2020 at 7:48 AM Albin Nilsson wrote: > Hello, > > I'm having some trouble with oauth and the Authorization Code flow and > PKCE. How can I get a refresh token? The refresh token flow requires a > client_secret, but PKCE prohibits client_secret. Is refresh token a no go? > > Kind regards, > Albin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000007cb59b059fa879ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Albin,

Are you writing both the clie= nt and the server or writing client code to auth against a standard server?= Unless you are writing the auth server code, using a library would be the = best way to simplify.

Thanks

<= div>Naveen

On Fri, Feb 28, 2020 at 7:48 AM Albin Nilsson <albin@bergson.nu> wrote:
Hello,

I'm having some trouble with oauth and the Authoriza= tion Code flow and PKCE. How can I get a refresh token? The refresh token f= low requires a client_secret, but PKCE prohibits client_secret. Is refresh = token a no go?

Kind regards,
Albin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000007cb59b059fa879ef-- From nobody Fri Feb 28 12:56:35 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802853A1DCE for ; Fri, 28 Feb 2020 12:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPATpfKHGRTY for ; Fri, 28 Feb 2020 12:56:32 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D763A1DD0 for ; Fri, 28 Feb 2020 12:56:31 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id n25so3125527lfl.0 for ; Fri, 28 Feb 2020 12:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HKx48jYcPucsK+qdWJCvbzQPZoQwoVR6OQ8qCWIqCfQ=; b=LqM2VPMmvEz5BDG9aOERBu07TJkR1qHHrqE9uolm21ym92LX5ICMkZuBppyneH/MYU zReYQ5vBp2v/Ehfdosnb4jclvqZrg/JKNG6HS0YUvgEyFCH2MovKFlKSPBN0nQxS57+W 8zDWYAHsOnsfHNwyW2I0Sw6QDHfQEn+k80LHsLz+i7sjU6P5KuuJFlTcY2E3CyegDIwh IP2iUVzdubAW1TgY3fshA2oLLYJPUjDWuZaCUV1l0onsYFae/i1DdR3sGBgfgSfLWvvt JWgifYscIfshqcpdHoGgOmKdsffpb+iw4RR6XuA4vf8k8imuerLXW+O4vM/mzqbK8VpW +VPA== 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=HKx48jYcPucsK+qdWJCvbzQPZoQwoVR6OQ8qCWIqCfQ=; b=MXP+9ExEGhDRNm14ZrGpsuIUIY5WODcggj7ei70CnvfNb1ruv9BTS5HOUh+0PonnUu nfyNlX+6uYLOUZmnkef0uurtjNIZXQVvsjBy3sUGqE2IIOjqc9XtI1Iqx/lhDvEw0g2R 2wRW4HkomIPYuahs4USt1J+vkKo2fSKUmhceHBc42RUJu8buasdznZcudDDaR7xT7vUs oJdKpyv2h95v+KhPgTQTtB9MVKThLHcmGBoZhSjXQHHQon1uQmoglBV3if78KIYQ+EkG +kM7REuCPs2VACwEqSCOpJwfnIF/8NtDhi59+UOXHEhk8CVtPIYGZN7nc0ejRyPKLpC4 gW0A== X-Gm-Message-State: ANhLgQ1e8dRUeq1/LJ1lmzXuIX1k/V03xlCU47dgRveZcnsDv1zbULnR P8/7T4VuZZ6hZT+xm9I5UXRhZRnLMCdSYN1gxAiXjobA X-Google-Smtp-Source: ADFU+vvE4utuBeDTTqdWP7Ck30+1tHPY88a450QFiwgPcQDUrxR7ims2PC83storQV6QiiJm5XZxpnHhWtV065Lvk4Q= X-Received: by 2002:a19:bece:: with SMTP id o197mr3682196lff.164.1582923389760; Fri, 28 Feb 2020 12:56:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 28 Feb 2020 12:56:03 -0800 Message-ID: To: Dominick Baier Cc: oauth@ietf.org, Brian Campbell , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000005a7d40059fa91256" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 20:56:34 -0000 --0000000000005a7d40059fa91256 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm looking to close out this topic. I heard that Brian and Vittorio shared some points of view in the office hours, and wanted to confirm: + Remove implicit flow from OAuth 2.1 and continue to highlight that grant types are an extension mechanism. For example, if OpenID Connect were to be updated to refer to OAuth 2.1 rather than OAuth 2.0, OIDC could define the implicit grant type with all the appropriate considerations. =E1=90=A7 On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier wrote: > No - please get rid of it. > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 18. February 2020 at 21:32:31, Dick Hardt (dick.hardt@gmail.com) wrote= : > > Hey List > > (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, > Torsten, and I are working on) > > Given the points Aaron brought up in > > https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU > > > Does anyone have concerns with dropping the implicit flow from the OAuth > 2.1 document so that developers don't use it? > > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000005a7d40059fa91256 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm looking to close out this topic. I heard that Bria= n and Vittorio shared some points of view in the office hours, and wanted t= o confirm:

+ Remove implicit flow from OAuth 2.1 and= continue to highlight that grant types are an extension mechanism.

For example, if OpenID Connect were to be updated to refe= r to OAuth 2.1 rather than OAuth 2.0, OIDC could define the implicit grant = type with all the appropriate considerations.


=
=E1=90=A7

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 18, 2020 at 10:49 PM Domin= ick Baier <dbaier@leastpriv= ilege.com> wrote:
N= o - please get rid of it.

=E2=80=94=E2=80=94=E2=80=94
D= ominick Baier

On 18. February 2020 at 21:32:31, Dick Har= dt (dick.hardt@gm= ail.com) wrote:

Hey List=C2=A0

(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)

Given the points Aaron brought up in



Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it?

/Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000005a7d40059fa91256-- From nobody Fri Feb 28 13:03:13 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5292C3A1DE4 for ; Fri, 28 Feb 2020 13:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWf19mUnYzT0 for ; Fri, 28 Feb 2020 13:03:10 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599943A1DD9 for ; Fri, 28 Feb 2020 13:03:10 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id w69so3985030ilk.6 for ; Fri, 28 Feb 2020 13:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wyx00yQAA+yJHA2tnj/NtzAWmTwxFd/jdVBt1BcCiuc=; b=t3pdLxwp5nRr+tpgxydHHM4V9Jp8MRPuI+0t7ZjRXD3ScYZKXU8GZpxPosojsstyQv +pH894QUzfpvNqi7uTfSUlbjiPmCI1n1HS+a05eiN7rUltBEjCvgHCCrgq8UjIpTISXB uHZKNYr50leH7A1VbgeKcWb8a4ss4Ke4yrBddEjuN7yTCTTlM4VS/9EFkXABeHO43T5M TRejIRnIArJL0ZX2ygusfFXMakj/jmdEHbD4unSXP/5vnJgo1qrOU0ltTrn6dFSFcH9e ZBYAtPpsX1+PoAlf8B0VHU9pW0rNCx4C5ZJoCskhkwSkauYzhNDs6AYiKoBYp21h1BSL ki6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wyx00yQAA+yJHA2tnj/NtzAWmTwxFd/jdVBt1BcCiuc=; b=Xe2vH0AV6GixIEWlaZGhA1z6wB7YUifjl9mqGibsUQ7NAkz/y2rPkidl4MgdT6CRfx V5xm9VM7TWpbK5/sShDkbYSiLEBMmYfr7tIuf1qY/JysQCN07g4j69dOWEpAI4HtUMzD Jt1lk6vrTHTujRQUd2tQu4As1Nhg48GKnz+lyRMKEJ/Qqo4LM6TgKV51dN+r/2Gt3Emo JTY6XEjzdBCgWLiBSvP1a2wdHOLRnAaDyxVx03F/tK3U8Qn7PfDFIAOjZGBaPyYlbS4J PRbgm1DlQFT3eBVfqKk0ia36nNlDbrLdMJYRZwuoHEHXAZfbg42rJJgA3sXLeMb40pPH Kbgw== X-Gm-Message-State: APjAAAWUwa3A3WKyKLl/rUiz/nVfHwWNKWYN5+B2OZ3GNwWZ01xKqxxQ whl9sVeSp9a+xessdgzRg3R3C5cggTc= X-Google-Smtp-Source: APXvYqwLtOR+2cbc8UNT0ngN30wGzyLcvUZB0a0OwhZQZrG2hz5sEbzK69YDVXYhj5YAfSwo8YTSYg== X-Received: by 2002:a92:9603:: with SMTP id g3mr6263267ilh.231.1582923789325; Fri, 28 Feb 2020 13:03:09 -0800 (PST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id n81sm640276ili.28.2020.02.28.13.03.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 13:03:08 -0800 (PST) Received: by mail-io1-f51.google.com with SMTP id n21so4980770ioo.10 for ; Fri, 28 Feb 2020 13:03:08 -0800 (PST) X-Received: by 2002:a6b:148b:: with SMTP id 133mr4977237iou.214.1582923788408; Fri, 28 Feb 2020 13:03:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Fri, 28 Feb 2020 13:02:57 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Mike Jones Cc: "oauth@ietf.org" , "david@alkaline-solutions.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] More product group review comments on the OAuth 2.0 for Browser-Based Apps spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 21:03:13 -0000 > 9.3. Client Impersonation > It is implied that consent granted to public client should not be recorde= d: >> Even when the user has previously approved an >> authorization request for a given client_id, the request SHOULD be >> processed as if no previous request had been approved, unless the >> identity of the client can be proven. > Do we agree with this? If implemented, it will add significant number of = consent prompts. This text in this BCP is summarizing section 10.2 of RFC6749, not defining anything new. The following paragraph allows the authorization server to treat an exact match of a registered redirect URI as proof of identity for the client to avoid the consent screen. This is actually allowing the exact behavior the commenter wants. I will try to rephrase this text to make it more clear. > Many of our application services give the access tokens to browser instea= d and have JS call the resource server directly. How is this different from the pattern defined in 6.3, "JavaScript Applications without a Backend"? Is the difference that the OAuth exchange is handled by something other than the SPA? If that's the case, it sounds like that might be a new pattern that could be worth documenting as well, if that's a common pattern others have implemented and have good suggestions for. ---- Aaron Parecki aaronparecki.com @aaronpk ---- Aaron Parecki aaronparecki.com @aaronpk On Fri, Feb 21, 2020 at 5:02 PM Mike Jones wr= ote: > > More comments hot off the presses from a Microsoft product architect=E2= =80=A6 > > > > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#sectio= n-6.2 > > Applications with BE > > > > If I read this correctly, the prescribed pattern is to have browser JS ca= ll into its own BE only and have the BE call into 3P WebAPIs: > > When the JavaScript application in the browser wants to make a > > request to the Resource Server, it MUST instead make the request to > > the Application Server, and the Application Server will make the > > request with the access token to the Resource Server (C), and forward > > the response (D) back to the browser. > > > > Many of our application services give the access tokens to browser instea= d and have JS call the resource server directly. > > If we enforce the prescribed pattern, then app server becomes proxy to al= l resource servers. This may not scale of our services > > > > SPO, for example, has a pattern that is a mix b/n application with and wi= thout BE. It can behave as public or conf client depending on the redirect = URI as we allow URI to be marked as =E2=80=98SPA=E2=80=99. > > > > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#sectio= n-9.3 > > 9.3. Client Impersonation > > It is implied that consent granted to public client should not be recorde= d: > > Even when the user has previously approved an > > authorization request for a given client_id, the request SHOULD be > > processed as if no previous request had been approved, unless the > > identity of the client can be proven. > > > > Do we agree with this? If implemented, it will add significant number of = consent prompts. > > > > tx > > From nobody Fri Feb 28 13:03:59 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF43A1DE4 for ; Fri, 28 Feb 2020 13:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACMN9ECetBot for ; Fri, 28 Feb 2020 13:03:54 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761183A1DD8 for ; Fri, 28 Feb 2020 13:03:53 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id n25so3138508lfl.0 for ; Fri, 28 Feb 2020 13:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/fM/nttRh2YHSngKkE+FnrHBIadjpoRRvPhU8ccTdAg=; b=lohKyN64VEsniexy/p2Yyv4OXa5TqbkoOcsJhYbh6Ty0ljcJptP9Lr+szEE85wZcvu TeIk8hiCDN1BrwRkS7sNvRaf8ut+zxcU+TDMZkOTkYcGXgadWAa16YR8rQLJRG3iRbEh cCW5Chzd8AJ2eLCZbvMeAMVivhtASfkOhfiwMO3KnCJXNsfZUry2BoCsh7TA0vetXFiq X4Ue50sQydp6X+28UYU7Jm2bWgW8zybRxRJM7gtrYNPbxHsq0xQ4hyIClThVNbGoui5w 6U2nBxwe/TDW9je5KsTXYJH2iRY25taYrRxNYabUFiRTSNOOimTrwZo57qPlbcY7pmAn Eulg== 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=/fM/nttRh2YHSngKkE+FnrHBIadjpoRRvPhU8ccTdAg=; b=BdSyD213KI8+qz9R92PKNrSSS82kCAP+1241tQcYEM0YgEl1fMU0DVERhMUxeKb9Za tc7i7J0Vp+Td1ghvPDTFNXN5NIlL9GPxv9pBNpdX8FFyqGna/1bHyQyqI/W+QY9t7OZ7 iUIX/+GXDxbZ3TKV+JNd2x0xK+g05M5Pf0D+XSvUdLEj8c5c8BXLGWXEPeAxBdnBtksq 5Y68FON2PKE29OsCD0oiZkBOyWmS7LoY+9PUZ/AzXVaO3JKy9rGJSR26E60SGLY4E4eC sneNRKyEyCiZGqOZi9JmNwz18JD/Vbzc0jUhR+qmuGMTyhXncN1eejzSn7RNizpRL9Ub RxLQ== X-Gm-Message-State: ANhLgQ3tXy09qayLXfuLgWCtvPdD2qm4yN84TiW4NRHHOJinn9IAvmn6 wU3gUtccK5XQl6nR22v3taT9B4EP5pAIS1tObaI= X-Google-Smtp-Source: ADFU+vuDeOmbyh+s8TWpqpyOZz3pTCVfTEO9u30UbFkVNH4StfhOdrGHIqYGYVFW91ovIHqKSho8ylwsg/42Fq4jPe0= X-Received: by 2002:a05:6512:10c2:: with SMTP id k2mr3705116lfg.0.1582923831476; Fri, 28 Feb 2020 13:03:51 -0800 (PST) MIME-Version: 1.0 References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <045164C6-685B-45FE-A6F6-0E15DBD5FE08@mit.edu> <5820B70D-1935-4A78-BD53-42AC2DF36336@forgerock.com> <3aa0ac2f-f480-4054-974c-cf468f6070be@Spark> In-Reply-To: <3aa0ac2f-f480-4054-974c-cf468f6070be@Spark> From: Dick Hardt Date: Fri, 28 Feb 2020 13:03:24 -0800 Message-ID: To: Nat Sakimura Cc: Aaron Parecki , Neil Madden , Brian Campbell , Matthew De Haast , "oauth@ietf.org" , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="000000000000ae867c059fa92ced" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 21:03:58 -0000 --000000000000ae867c059fa92ced Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It looks like there is consensus to remove ROPC for a user -- but that the password grant is not a bad practice for service accounts. That leads to providing clarity on service accounts. 1) add service account grant to the OAuth 2.1 document 2) write an OAuth 2.1 extension for service account grants. (the grant type could continue to be "password", but now clearly in the context of a service account in a different document) With the goal of OAuth 2.1 being a capture of all the best practices, (2) makes more sense as it could discuss all aspects of service accounts including mapping a client to a service account. What do others think? =E1=90=A7 On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura wrote: > Let us do it then and deprecate ROPC. > There definitely are use-cases that need this pattern around me as well, > but we are using JWT bearer grant instead. Standardizing the behavior is > good. I am fine with new service_account grant type as well, btw. > > Nat > 2020=E5=B9=B42=E6=9C=8825=E6=97=A5 20:41 +0900=E3=80=81Neil Madden =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > I=E2=80=99d be open to defining a new service_account grant type and > removing/deprecating the ROPC grant. I=E2=80=99d also be happy if we just= said that > service account flows should use the JWT bearer grant, and we document th= e > best practices around that and encourage client libs to implement support > for it. > > Should there be a dedicated draft for best practices for > service-to-service usage? > > =E2=80=94 Neil > > On 25 Feb 2020, at 00:13, Aaron Parecki wrote: > > I think we might be going about this discussion the wrong way. > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > Concur with the sentiment expressed by Neil here. > > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden > wrote: > I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be > doing=E2=80=9D unless we have concrete security or interoperability reaso= ns for > doing so. > > I 100% agree that the job of a standard is not to tell people "what they > ought to be doing". Instead, a standard is more about documenting the > current state of the art as deployed in existing implementations. > > With that in mind, I think that leaves us with two concrete problems with > the password grant: > > 1) The actual problem with the password grant is end users entering > passwords in applications, which the group (mostly) agrees on > 2) People are re-appropriating the password grant for things like service > accounts or backends that are inflexible, not actually using it for end > user credentials > > So it seems like there's actually something missing from OAuth which is > leading people to find the password grant and use that because it's the > only thing that most closely fits their existing model. It seems like we'= d > be better off defining a new extension that captures the use case people > are actually doing, instead of encouraging the continuing use of the > password grant for this purpose. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > Concur with the sentiment expressed by Neil here. > > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden > wrote: > I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be > doing=E2=80=9D unless we have concrete security or interoperability reaso= ns for > doing so. > > I also don=E2=80=99t agree that people doing this are doing anything wron= g. I > don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve l= earnt over the > years not to second-guess their reasons for doing it. > > Are Google wrong for using the JWT bearer grant (not client credentials) > and service accounts? They even go so far as to say =E2=80=9Cscopes are n= ot a > security mechanism=E2=80=9D [1] and tell people to use service account ro= les > instead. (Precisely because they also support non-OAuth auth methods, whi= ch > bypass any scopes). > > Are we really going to tell them to rewrite it all to use the client > credentials grant? > > [1]: > https://cloud.google.com/compute/docs/access/service-accounts#accesscopes= iam > > On 21 Feb 2020, at 21:04, Justin Richer wrote: > > +1. I=E2=80=99ve seen this anti-pattern deployed all over the place, and = it=E2=80=99s time > to get rid of it and send people toward what they really ought to be doin= g. > > Another thing I=E2=80=99ve seen is using different service accounts to ge= t > different sets of access for one client =E2=80=94 if you=E2=80=99re doing= that, you=E2=80=99ve got > a client pretending to do two different things, or your APIs should be > using scopes to differentiate access instead of client/user identity. > > =E2=80=94 Justin > > On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > The client IDs can still be opaque identifiers provided by the AS, they > just happen to be associated with specific service accounts. Or they coul= d > be the opaque IDs that the AS already issued for the service account. > Either way, the AS could issue a token with the appropriate subject and > other claims for the service account. > > If your client identity is bound to a specific service account identity > (i.e., the resource owner), then ROPC reduces down to Client Credentials. > What's the point in passing two identifiers and two credentials for the > same identity? > > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > =EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" < > oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote: > > Sorry, I missed that message. > > While this may be a solution in specific circumstances, I don=E2=80=99t t= hink it=E2=80=99s > a general solution. e.g. an AS may not allow manually choosing the > client_id to avoid things like > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4= .13 > or may return different introspection results for client credentials toke= ns > (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds ev= en more steps for > somebody to migrate from existing ROPC usage. > > This is asking people to make fundamental changes to their identity > architecture rather than simply switching to a new grant type.. > > =E2=80=94 Neil > > On 21 Feb 2020, at 14:34, Torsten Lodderstedt > wrote: > > I see - we have gone full cycle :-) > > Annabelle=E2=80=99s proposal would solve that. Relate a client id to a se= rvice > account and obtain the token data from there. > > On 21. Feb 2020, at 15:31, Neil Madden wrote: > > Yes, that is great. But mTLS doesn=E2=80=99t support service accounts (!= =3D > clients). Maybe it should? Should there be a mTLS *grant type*? > > =E2=80=94 Neil > > On 21 Feb 2020, at 14:20, Torsten Lodderstedt > wrote: > > Have you ever tried the client credentials grant with mTLS? After reading > your description it seems to be simpler than JWT Bearer.. > > * work out if the AS even supports mTLS > * work out how to configure the AS to trust my cert(s) > * Create key pair and cert using openssl > * Register your (self-signed) cert along with your client_id > * Configure the HTTP client to use your key pair for TLS Client > Authentication > > Works very well for us. > > On 21. Feb 2020, at 15:12, Neil Madden wrote: > > No failures, but it is a much more complex grant type to set up, when you > consider everything you have to do: > > * work out if the AS even supports JWT bearer and how to turn it on > * work out how to configure the AS to trust my public key(s) > - do I have to create a new HTTPS endpoint to publish a JWK Set? > * determine the correct settings for issuer, audience, subject, etc. Does > the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT > MUST contain a =E2=80=9Csub=E2=80=9D claim, but Google only allows this t= o be present if > your client is doing impersonation of an end-user (which requires > additional permissions). > * do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, plain= OAuth ones might > not) If I do, can I reuse the JWT or must it be freshly signed for every > call? > * locate and evaluate a JWT library for my language of choice. Monitor > that new dependency for security advisories. > * choose a suitable signature algorithm (=E2=80=98ere be dragons) > * figure out how to distribute the private key to my service > > Compared to =E2=80=9Ccreate a service account and POST the username and p= assword > to the token endpoint=E2=80=9D it adds a little friction. (It also adds a= lot of > advantages, but it is undeniably more complex). > > =E2=80=94 Neil > > > On 21 Feb 2020, at 13:41, Matthew De Haast > wrote: > > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again the= n > we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s an > incentive to make that happen. > > Neil could you elaborate more on this please. What failures are you > currently experiencing/seeing with the JWT Bearer grant? > > Matt > > On Thu, Feb 20, 2020 at 12:42 AM Neil Madden > wrote: > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again the= n > we wouldn=E2=80=99t be having this conversation. So perhaps removing it i= s an > incentive to make that happen. > > > On 19 Feb 2020, at 22:01, Dick Hardt wrote: > > Neil: are you advocating that password grant be preserved in 2.1? Or do > you think that service account developers know enough about what they are > doing to follow what is in 6749? > =E1=90=A7 > > On Wed, Feb 19, 2020 at 1:52 PM Neil Madden > wrote: > OAuth2 clients are often private to the AS - they live in a database that > only the AS can access, have attributes specific to their use in OAuth2, > and so on. Many existing systems have access controls based on users, > roles, permissions and so on and expect all users accessing the system to > exist in some user repository, e.g. LDAP, where they can be looked up and > appropriate permissions determined. A service account can be created insi= de > such a system as if it was a regular user, managed through the normal > account provisioning tools, assigned permissions, roles, etc. > > Another reason is that sometimes OAuth is just one authentication option > out of many, and so permissions assigned to service accounts are preferre= d > over scopes because they are consistently applied no matter how a request > is authenticated. This is often the case when OAuth has been retrofitted = to > an existing system and they need to preserve compatibility with already > deployed clients. > > See e.g. Google cloud platform (GCP): > https://developers.google.com/identity/protocols/OAuth2ServiceAccount > They use the JWT bearer grant type for service account authentication and > assign permissions to those service accounts and typically have very broa= d > scopes. For service-to-service API calls you typically get an access toke= n > with a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D and = everything is > managed at the level of permissions on the RO service account itself. The= y > only break down fine-grained scopes when you are dealing with user data a= nd > will be getting an access token approved by a real user (through a normal > auth code flow). > > =E2=80=94 Neil > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt > wrote: > > Can you explain more in detail why the client credentials grant type isn= =E2=80=99t > applicable for the kind of use cases you mentioned? > > Am 19.02.2020 um 22:03 schrieb Neil Madden : > > I very much agree with this with regards to real users. > > The one legitimate use-case for ROPC I=E2=80=99ve seen is for service acc= ounts - > where you essentially want something like client_credentials but for > whatever reason you need the RO to be a service user rather than an OAuth= 2 > client (typically so that some lower layer of the system can still perfor= m > its required permission checks). > > There are better grant types for this - e.g. JWT bearer - but they are a > bit harder to implement. Having recently converted some code from ROPC to > JWT bearer for exactly this use-case, it went from a couple of lines of > code to two screens of code. For service to service API calls within a > datacenter I=E2=80=99m not convinced this resulted in a material increase= in > security for the added complexity. > > =E2=80=94 Neil > > On 18 Feb 2020, at 21:57, Hans Zandbelt > wrote: > > I would also seriously look at the original motivation behind ROPC: I kno= w > it has been deployed and is used in quite a lot of places but I have neve= r > actually come across a use case where it is used for migration purposes a= nd > the migration is actually executed (I know that is statistically not a ve= ry > strong argument but I challenge others to come up with one...) > In reality it turned out just to be a one off that people used as an easy > way out to stick to an anti-pattern and still claim to do OAuth 2.0. It i= s > plain wrong, it is not OAuth and we need to get rid of it. > > Hans. > > On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote: > Agreed. Plus, the Security BCP is already effectively acting as a grace > period since it currently says the password grant MUST NOT be used, so in > the OAuth 2.0 world that's already a pretty strong signal.. > > Aaron > > > > On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote: > There is no need for a grace period. People using OAuth 2..0 can still do > OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1. > > =E2=80=94 Justin > > On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 40microsoft.com@dmarc.ietf.org> wrote: > > > I would suggest a SHOULD NOT instead of MUST, there are still sites using > this and a grace period should be provided before a MUST is pushed out as > there are valid use cases out there still. > > From: OAuth On Behalf Of Dick Hardt > Sent: Tuesday, February 18, 2020 12:37 PM > To: oauth@ietf.org > Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > > Hey List > > (Once again using the OAuth 2.1 name as a placeholder for the doc that > Aaron, Torsten, and I are working on) > > In the security topics doc > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2= .4 > > The password grant MUST not be used. > > Some background for those interested. I added this grant into OAuth 2.0 t= o > allow applications that had been provided password to migrate. Even with > the caveats in OAuth 2.0, implementors decide they want to prompt the use= r > to enter their credentials, the anti-pattern OAuth was created to elimina= te. > > > Does anyone have concerns with dropping the password grant from the OAuth > 2.1 document so that developers don't use it? > > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf..org/mailman/listinfo/oauth > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 privilege= d > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.. If you have > received this communication in error, please notify the sender immediatel= y > by e-mail and delete the message and any file attachments from your > computer. Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > 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 > --000000000000ae867c059fa92ced Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It looks like there is consensus to remove ROPC for a= user -- but that the password grant is not a bad practice for service acco= unts. That leads to providing clarity on service accounts.

1) add service account grant to the OAuth 2.1 document
<= br>
2) write an OAuth 2.1 extension for service account grants. (= the grant type could continue to be "password", but now clearly i= n the context of a service account in a different document)

<= /div>
With the goal of OAuth 2.1 being a capture of all the best practi= ces, (2) makes more sense as it could discuss all aspects of service accoun= ts including mapping a client to a service account.=C2=A0

What do others think?


3D""=E1=90=A7

On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura <sakimura@gmail.com> wrote:
Let us do it then and deprecate ROPC.=C2=A0
There definitely are use-cases that need this pattern aro= und me as well, but we are using JWT bearer grant instead. Standardizing th= e behavior is good. I am fine with new service_account grant type as well, = btw.=C2=A0

Nat
2020=E5=B9=B42=E6=9C=8825=E6=97=A5 20:41 = +0900=E3=80=81Neil Madden <neil.madden@forgerock.com> =E3=81=AE=E3=83=A1=E3= =83=BC=E3=83=AB:
I=E2=80=99d be open to defining a new service_= account grant type and removing/deprecating the ROPC grant. I=E2=80=99d als= o be happy if we just said that service account flows should use the JWT be= arer grant, and we document the best practices around that and encourage cl= ient libs to implement support for it.

Should there be a dedicated draft for best practices for service-to-service= usage?

=E2=80=94 Neil

On 25 Feb 2020, at 00:13, Aaron Parecki <aaron@parecki.com&= gt; wrote:

I think we might be going about this discussion the wrong way.

On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=3D40pingidentity.c= om@dmarc.ietf.org> wrote:
Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote= :
I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be doing=E2=80=9D unless we have concrete security or intero= perability reasons for doing so.

I 100% agree that the job of a standard is not to tell people "what th= ey ought to be doing". Instead, a standard is more about documenting t= he current state of the art as deployed in existing implementations.

With that in mind, I think that leaves us with two concrete problems with t= he password grant:

1) The actual problem with the password grant is end users entering passwor= ds in applications, which the group (mostly) agrees on
2) People are re-appropriating the password grant for things like service a= ccounts or backends that are inflexible, not actually using it for end user= credentials

So it seems like there's actually something missing from OAuth which is= leading people to find the password grant and use that because it's th= e only thing that most closely fits their existing model. It seems like we&= #39;d be better off defining a new extension that captures the use case peo= ple are actually doing, instead of encouraging the continuing use of the pa= ssword grant for this purpose.

----
Aaron Parecki
aaronparecki.com<= br> @aaronpk



On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=3D40pingidentity.c= om@dmarc.ietf.org> wrote:
Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com> wrote= :
I=E2=80=99m not really sure the WG should be telling people what they =E2= =80=9Cought to be doing=E2=80=9D unless we have concrete security or intero= perability reasons for doing so.

I also don=E2=80=99t agree that people doing this are doing anything wrong.= I don=E2=80=99t always agree with what our customers do, but I=E2=80=99ve = learnt over the years not to second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) an= d service accounts? They even go so far as to say =E2=80=9Cscopes are not a= security mechanism=E2=80=9D [1] and tell people to use service account rol= es instead. (Precisely because they also support non-OAuth auth methods, wh= ich bypass any scopes).

Are we really going to tell them to rewrite it all to use the client creden= tials grant?

[1]: https://cloud.google.com/compute/docs/= access/service-accounts#accesscopesiam

On 21 Feb 2020, at 21:04, Justin Richer <jricher@mit.edu> = wrote:

+1. I=E2=80=99ve seen this anti-pattern deployed all over the place, and it= =E2=80=99s time to get rid of it and send people toward what they really ou= ght to be doing.

Another thing I=E2=80=99ve seen is using different service accounts to get = different sets of access for one client =E2=80=94 if you=E2=80=99re doing t= hat, you=E2=80=99ve got a client pretending to do two different things, or = your APIs should be using scopes to differentiate access instead of client/= user identity.

=E2=80=94 Justin

On Feb 21, 2020, at 3:28 PM, Richard Backman, An= nabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

The client IDs can still be opaque identifiers provided by the AS, they jus= t happen to be associated with specific service accounts. Or they could be = the opaque IDs that the AS already issued for the service account. Either w= ay, the AS could issue a token with the appropriate subject and other claim= s for the service account.

If your client identity is bound to a specific service account identity (i.= e., the resource owner), then ROPC reduces down to Client Credentials. What= 's the point in passing two identifiers and two credentials for the sam= e identity?

=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.= amazon.com/identity/


=EF=BB=BFOn 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" &l= t;oauth-bounces= @ietf.org on behalf of neil.madden@forgerock.com> wrote:

Sorry, I missed that message.

While this may be a solution in specific circumstances, I don=E2=80=99t thi= nk it=E2=80=99s a general solution. e.g. an AS may not allow manually choos= ing the client_id to avoid things like http= s://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or may return different introspection results for client credentials toke= ns (e.g. with no =E2=80=9Csub=E2=80=9D) and so on. In practice, this adds e= ven more steps for somebody to migrate from existing ROPC usage.

This is asking people to make fundamental changes to their identity archite= cture rather than simply switching to a new grant type..

=E2=80=94 Neil

On 21 Feb 2020, at 14:34, Torsten Lodderstedt &l= t;torsten@lodd= erstedt.net> wrote:

I see - we have gone full cycle :-)

Annabelle=E2=80=99s proposal would solve that. Relate a client id to a serv= ice account and obtain the token data from there.

On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@for= gerock.com> wrote:

Yes, that is great. But mTLS doesn=E2=80=99t support service accounts (!=3D= clients). Maybe it should? Should there be a mTLS *grant type*?

=E2=80=94 Neil

On 21 Feb 2020, at 14:20, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Have you ever tried the client credentials grant with mTLS? After reading y= our description it seems to be simpler than JWT Bearer..

* work out if the AS even supports mTLS
* work out how to configure the AS to trust my cert(s)
* Create key pair and cert using openssl
* Register your (self-signed) cert along with your client_id
* Configure the HTTP client to use your key pair for TLS Client Authenticat= ion

Works very well for us.

On 21. Feb 2020, at 15:12, Neil Madden <neil.madden@forg= erock.com> wrote:

No failures, but it is a much more complex grant type to set up, when you c= onsider everything you have to do:

* work out if the AS even supports JWT bearer and how to turn it on
* work out how to configure the AS to trust my public key(s)
- do I have to create a new HTTPS endpoint to publish a JWK Set?
* determine the correct settings for issuer, audience, subject, etc. Does t= he AS impose non-standard requirements? e.g. RFC 7523 says that the JWT MUS= T contain a =E2=80=9Csub=E2=80=9D claim, but Google only allows this to be = present if your client is doing impersonation of an end-user (which require= s additional permissions).
* do I need a unique =E2=80=9Cjti=E2=80=9D claim? (OIDC servers do, plain O= Auth ones might not) If I do, can I reuse the JWT or must it be freshly sig= ned for every call?
* locate and evaluate a JWT library for my language of choice. Monitor that= new dependency for security advisories.
* choose a suitable signature algorithm (=E2=80=98ere be dragons)
* figure out how to distribute the private key to my service

Compared to =E2=80=9Ccreate a service account and POST the username and pas= sword to the token endpoint=E2=80=9D it adds a little friction. (It also ad= ds a lot of advantages, but it is undeniably more complex).

=E2=80=94 Neil


On 21 Feb 2020, at 13:41, Matthew De Haast <= ;matt=3D40co= il.com@dmarc.ietf.org> wrote:

I have a feeling that if we had more concise JWT libraries and command line= tools, where using the JWT Bearer grant became a one-liner again then we w= ouldn=E2=80=99t be having this conversation. So perhaps removing it is an i= ncentive to make that happen.

Neil could you elaborate more on this please. What failures are you current= ly experiencing/seeing with the JWT Bearer grant?

Matt

On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <neil.madden@forgerock.com> wrot= e:
I have a feeling that if we had more concise JWT libraries and command line= tools, where using the JWT Bearer grant became a one-liner again then we w= ouldn=E2=80=99t be having this conversation. So perhaps removing it is an i= ncentive to make that happen.


On 19 Feb 2020, at 22:01, Dick Hardt <dick.hardt@gmail.com> wrote:

Neil: are you advocating that password grant be preserved in 2.1? Or do you= think that service account developers know enough about what they are doin= g to follow what is in 6749?
=E1=90=A7

On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@forgerock..com&= gt; wrote:
OAuth2 clients are often private to the AS - they live in a database that o= nly the AS can access, have attributes specific to their use in OAuth2, and= so on. Many existing systems have access controls based on users, roles, p= ermissions and so on and expect all users accessing the system to exist in = some user repository, e.g. LDAP, where they can be looked up and appropriat= e permissions determined. A service account can be created inside such a sy= stem as if it was a regular user, managed through the normal account provis= ioning tools, assigned permissions, roles, etc.

Another reason is that sometimes OAuth is just one authentication option ou= t of many, and so permissions assigned to service accounts are preferred ov= er scopes because they are consistently applied no matter how a request is = authenticated. This is often the case when OAuth has been retrofitted to an= existing system and they need to preserve compatibility with already deplo= yed clients.

See e.g. Google cloud platform (GCP): https://deve= lopers.google.com/identity/protocols/OAuth2ServiceAccount
They use the JWT bearer grant type for service account authentication and a= ssign permissions to those service accounts and typically have very broad s= copes. For service-to-service API calls you typically get an access token w= ith a single scope that is effectively =E2=80=9Call of GCP=E2=80=9D and eve= rything is managed at the level of permissions on the RO service account it= self. They only break down fine-grained scopes when you are dealing with us= er data and will be getting an access token approved by a real user (throug= h a normal auth code flow).

=E2=80=94 Neil

On 19 Feb 2020, at 21:35, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Can you explain more in detail why the client credentials grant type isn=E2= =80=99t applicable for the kind of use cases you mentioned?

Am 19.02.2020 um 22:03 schrieb Neil Madden <<= a href=3D"mailto:neil.madden@forgerock.com" target=3D"_blank">neil.madden@f= orgerock.com>:

I very much agree with this with regards to real users.

The one legitimate use-case for ROPC I=E2=80=99ve seen is for service accou= nts - where you essentially want something like client_credentials but for = whatever reason you need the RO to be a service user rather than an OAuth2 = client (typically so that some lower layer of the system can still perform = its required permission checks).

There are better grant types for this - e.g. JWT bearer - but they are a bi= t harder to implement. Having recently converted some code from ROPC to JWT= bearer for exactly this use-case, it went from a couple of lines of code t= o two screens of code. For service to service API calls within a datacenter= I=E2=80=99m not convinced this resulted in a material increase in security= for the added complexity.

=E2=80=94 Neil

On 18 Feb 2020, at 21:57, Hans Zandbelt <hans.zandbelt@z= martzone.eu> wrote:

I would also seriously look at the original motivation behind ROPC: I know = it has been deployed and is used in quite a lot of places but I have never = actually come across a use case where it is used for migration purposes and= the migration is actually executed (I know that is statistically not a ver= y strong argument but I challenge others to come up with one...)
In reality it turned out just to be a one off that people used as an easy w= ay out to stick to an anti-pattern and still claim to do OAuth 2.0. It is p= lain wrong, it is not OAuth and we need to get rid of it.

Hans.

On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <aaron@parecki.com> wrote:
Agreed. Plus, the Security BCP is already effectively acting as a grace per= iod since it currently says the password grant MUST NOT be used, so in the = OAuth 2.0 world that's already a pretty strong signal..

Aaron



On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jricher@mit.edu> wrote:
There is no need for a grace period. People using OAuth 2..0 can still do O= Auth 2.0. People using OAuth 2..1 will do OAuth 2.1.

=E2=80=94 Justin

On Feb 18, 2020, at 3:54 PM, Anthony Nadalin &= lt;tonynad=3D40microsoft.com@dmarc.ietf.org> wrote:

I would suggest a SHOULD NOT instead of MUST, there are still sites using t= his and a grace period should be provided before a MUST is pushed out as th= ere are valid use cases out there still.

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: oauth@ietf.org<= br> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant

Hey List

(Once again using the OAuth 2.1 name as a placeholder for the doc that Aaro= n, Torsten, and I are working on)

In the security topics doc

https://tools.ietf.org/html/draft-ietf-oauth= -security-topics-14#section-2.4

The password grant MUST not be used.

Some background for those interested. I added this grant into OAuth 2.0 to = allow applications that had been provided password to migrate. Even with th= e caveats in OAuth 2.0, implementors decide they want to prompt the user to= enter their credentials, the anti-pattern OAuth was created to eliminate.<= br>

Does anyone have concerns with dropping the password grant from the OAuth 2= .1 document so that developers don't use it?

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<= br> @aaronpk

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


--
hans.zandbe= lt@zmartzone.eu
ZmartZone IAM - www.z= martzone.eu
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

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

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

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

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




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


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


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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ae867c059fa92ced-- From nobody Fri Feb 28 14:38:32 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9840E3A1F82; Fri, 28 Feb 2020 14:35:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931961.19931.10431875623243706301@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:19 -0800 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 107 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:26 -0000 Dear Rifaat Shekh-Yusef, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (2:00 requested) Monday, 23 March 2020, Afternoon Session I 1330-1530 Room Name: Regency E size: 150 --------------------------------------------- oauth Session 2 (2:00 requested) Tuesday, 24 March 2020, Afternoon Session II 1550-1720 Room Name: Georgia B size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/oauth.ics Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: sipcore anima acme txauth Technology Overlap: saag tls People who must be present: Roman Danyliw Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: We have few presenters that cannot attend Friday session. We would appreciate not scheduling an OAuth session on Friday. --------------------------------------------------------- From nobody Fri Feb 28 16:11:10 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F0A3A0775; Fri, 28 Feb 2020 16:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJi-2QcktkP3; Fri, 28 Feb 2020 16:11:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A03A3A0776; Fri, 28 Feb 2020 16:11:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5D468F40714; Fri, 28 Feb 2020 16:10:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200229001046.5D468F40714@rfc-editor.org> Date: Fri, 28 Feb 2020 16:10:46 -0800 (PST) Archived-At: Subject: [OAUTH-WG] =?utf-8?q?RFC_8705_on_OAuth_2=2E0_Mutual-TLS_Client_A?= =?utf-8?q?uthentication_and_Certificate-Bound_Access=C2=A0Tokens?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:11:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8705 Title: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Author: B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt Status: Standards Track Stream: IETF Date: February 2020 Mailbox: brian.d.campbell@gmail.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp, torsten@lodderstedt.net Pages: 24 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-mtls-17.txt URL: https://www.rfc-editor.org/info/rfc8705 DOI: 10.17487/RFC8705 This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed 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. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Feb 28 16:11:35 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38B63A07DC; Fri, 28 Feb 2020 16:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7JzOJuseZQo; Fri, 28 Feb 2020 16:11:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2713A07C4; Fri, 28 Feb 2020 16:11:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 22955F40720; Fri, 28 Feb 2020 16:11:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200229001105.22955F40720@rfc-editor.org> Date: Fri, 28 Feb 2020 16:11:05 -0800 (PST) Archived-At: Subject: [OAUTH-WG] =?utf-8?q?RFC_8707_on_Resource_Indicators_for_OAuth_2?= =?utf-8?q?=2E0?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:11:31 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8707 Title: Resource Indicators for OAuth 2.0 Author: B. Campbell, J. Bradley, H. Tschofenig Status: Standards Track Stream: IETF Date: February 2020 Mailbox: brian.d.campbell@gmail.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net Pages: 11 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-resource-indicators-08.txt URL: https://www.rfc-editor.org/info/rfc8707 DOI: 10.17487/RFC8707 This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Feb 28 16:17:37 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7953A077A; Fri, 28 Feb 2020 16:17:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158293545544.19684.8246492840178395679@ietfa.amsl.com> Date: Fri, 28 Feb 2020 16:17:35 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:17:36 -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 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename : draft-ietf-oauth-browser-based-apps-05.txt Pages : 21 Date : 2020-02-28 Abstract: This specification details the security considerations and best practices that must be taken into account when developing browser- based applications that use OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 28 16:27:10 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FC03A07A4 for ; Fri, 28 Feb 2020 16:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6AmzFr6Iwjl for ; Fri, 28 Feb 2020 16:27:07 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B073A07A3 for ; Fri, 28 Feb 2020 16:27:07 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id r4so3028458iln.0 for ; Fri, 28 Feb 2020 16:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9a8z83l7vGm6TNsfzqt4FeCcK8WxRHNyjz2NdQZlbK8=; b=cqeYHKuKV+ENKvYCrElmdZVfFvEeSoJWBQuMmyVBedGy4yQ9VMydnXtDMSwQImWJsJ OHKDTXkMJ8vbcQMl5sJ6N5AJW2aRzhLBRCoEslx0q6R67c3P93LYl6SCkKULv8eSZObj 7I14VhPZcm8rWdPFmP7gnw1iWEt2ZYsujBtSNGgSpWWN05EmM8wq+lFWC3jiTbKydn3C 59e//sk14ZPsXeKHEAIs2nAfMM+0TwjwJTbAdPurYlQZ5nOQ7oFWH3RL9/50qSV5k1Qh fDFnMinkVz3aBpnvsPFFVW6k9ad9rzq3JPE7TlGqGg1oY4C3h5wwAH65odVxuAWpH/xp q4KQ== 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=9a8z83l7vGm6TNsfzqt4FeCcK8WxRHNyjz2NdQZlbK8=; b=LauVLsE58WtwqQD943ADVm4uVHEAc6r/pYHr2fsKNOc9xMf0f1e4QWu3w1iQ7MYNST Fi6F5LadSx3K8UagtPj+3s0P8H/Cl3iueRI0bkCvgfc55lNhvsb0na9EXzMDwEKlmqoE sJ7t2ii2sC96CmWByZ2svj1ifeP07l2b45hQGioY+E/PeiYmJSqF/U+ce7Ai+H9TY19O hSlAyfTdV0fBI8PW6slnL5EGBnISRNHJI+9AHY2BPY04BCXXufHGjQpzYz2Vos5fIGe/ 6oV57Trt8304z+SaWukj4+txzUGtAe18haghKCwsRwichGhL1wrGY8SHR5HsgS+GoxSn /2CA== X-Gm-Message-State: APjAAAWw/FjbDIMZl1EcW/7Hy2J9ADxhkJ6hT6pSfwSDZAjUiFMJ8hoL f7+BjPHRt5/S1b+2rk0XDiZhEHWavYE= X-Google-Smtp-Source: APXvYqyQcUmvkWhHW58kawEF6/OtXdIHm7CVh9vM4YSVAxq5azcdstMnxfj2Xr45MY/0iEPP/wC37g== X-Received: by 2002:a92:1b95:: with SMTP id f21mr7257781ill.138.1582936026460; Fri, 28 Feb 2020 16:27:06 -0800 (PST) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com. [209.85.166.174]) by smtp.gmail.com with ESMTPSA id h23sm2613529ioh.56.2020.02.28.16.27.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 16:27:05 -0800 (PST) Received: by mail-il1-f174.google.com with SMTP id x2so4370941ila.9 for ; Fri, 28 Feb 2020 16:27:05 -0800 (PST) X-Received: by 2002:a92:d183:: with SMTP id z3mr6616647ilz.214.1582936025703; Fri, 28 Feb 2020 16:27:05 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Fri, 28 Feb 2020 16:26:34 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] Side meetings for IETF 107 Vancouver X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:27:09 -0000 I reserved a room for a side meeting immediately following our first session on Monday. I put down "OAuth 2.1" as the topic, because I assume we'll have a lot to talk about again after the first session, but any topic is welcome really. Our first official meeting slot is 1:30-3:30pm Monday, and I've reserved 3:30-5:00pm for the side meeting. https://trac.ietf.org/trac/ietf/meeting/wiki/107sidemeetings#point1 ---- Aaron Parecki aaronparecki.com @aaronpk From nobody Fri Feb 28 16:27:22 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088783A07B1 for ; Fri, 28 Feb 2020 16:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwgoLfT7auY8 for ; Fri, 28 Feb 2020 16:27:13 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05213A07C7 for ; Fri, 28 Feb 2020 16:27:12 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id g19so5415957eds.11 for ; Fri, 28 Feb 2020 16:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9a8z83l7vGm6TNsfzqt4FeCcK8WxRHNyjz2NdQZlbK8=; b=cqeYHKuKV+ENKvYCrElmdZVfFvEeSoJWBQuMmyVBedGy4yQ9VMydnXtDMSwQImWJsJ OHKDTXkMJ8vbcQMl5sJ6N5AJW2aRzhLBRCoEslx0q6R67c3P93LYl6SCkKULv8eSZObj 7I14VhPZcm8rWdPFmP7gnw1iWEt2ZYsujBtSNGgSpWWN05EmM8wq+lFWC3jiTbKydn3C 59e//sk14ZPsXeKHEAIs2nAfMM+0TwjwJTbAdPurYlQZ5nOQ7oFWH3RL9/50qSV5k1Qh fDFnMinkVz3aBpnvsPFFVW6k9ad9rzq3JPE7TlGqGg1oY4C3h5wwAH65odVxuAWpH/xp q4KQ== 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=9a8z83l7vGm6TNsfzqt4FeCcK8WxRHNyjz2NdQZlbK8=; b=BFlo1myH+06t52KIKb6t5XNiPcEbwhdu+e+AS5/8hI2IsycqKlWFTkoASYB+m4i3tc 8yT70/Eo+G/jNVsUmoJ2NDLyPLy5MBtzVDf8MVAffiTSiBMyqI5XUxdAyo1MylW2QYRh jFXdy4k3nh4g3Hbbxuqpwc80t1jOlwSY/g4X9fpRkcC3zOLeUzt8bojohLAWg2jagOIe s8o7I8fC6oDQfg5MQpP5tsu8N3vQcXOBvN3+RkBnH4WMS29LmLRSZhaUAS60fYzriXK8 DEffcwFO6jYU8ddIJ9bPuacRO5E4g2DP6JpUyddV1x+QyuiJd2BTiW6ZJwwFmbknKeVf G6Wg== X-Gm-Message-State: APjAAAUR8dzAAvbWasyuVczNeS6NGCDLmIDtg6QmYf+GUp3ium9Iv9O+ p4wa1jn81UjlOsFB0G5pXq4hzHPzOHw= X-Google-Smtp-Source: APXvYqzbjqtaSDcYPjyrwGcGIyx8iaE3z7Bc7MwmiHzLOHSL+hxVosffV/uK2d0RCsPaD//dmKwXoA== X-Received: by 2002:a05:6402:b3a:: with SMTP id bo26mr6406230edb.242.1582936030957; Fri, 28 Feb 2020 16:27:10 -0800 (PST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id y14sm637756edt.76.2020.02.28.16.27.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 16:27:10 -0800 (PST) Received: by mail-wr1-f43.google.com with SMTP id z15so5222733wrl.1 for ; Fri, 28 Feb 2020 16:27:10 -0800 (PST) X-Received: by 2002:a5d:4885:: with SMTP id g5mr6839623wrq.93.1582936030292; Fri, 28 Feb 2020 16:27:10 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Fri, 28 Feb 2020 16:26:34 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] Side meetings for IETF 107 Vancouver X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:27:20 -0000 I reserved a room for a side meeting immediately following our first session on Monday. I put down "OAuth 2.1" as the topic, because I assume we'll have a lot to talk about again after the first session, but any topic is welcome really. Our first official meeting slot is 1:30-3:30pm Monday, and I've reserved 3:30-5:00pm for the side meeting. https://trac.ietf.org/trac/ietf/meeting/wiki/107sidemeetings#point1 ---- Aaron Parecki aaronparecki.com @aaronpk From nobody Fri Feb 28 16:28:00 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A13A07A3 for ; Fri, 28 Feb 2020 16:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSPfwyelqKzP for ; Fri, 28 Feb 2020 16:27:55 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829F13A07A5 for ; Fri, 28 Feb 2020 16:27:55 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id c26so5432006eds.8 for ; Fri, 28 Feb 2020 16:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aly2sekyftKL3xTxoVjQH2nXvS+WhpDNZeV49uIGmI8=; b=XcnukaDr06yPQX3BqgSeKoiKkCwlgd4xct2ZN4Z1vs3INLECAVg3SzwKmDiHxP1nx4 xWA0TIkQqvp4qkfX+TnEttM+H2ewUMi8NScsl9hIwisYZUI0eo5OfGjJcuhPLTnoxg0f mE3+Rkg9IuT5Rs/3AL9Gi34CwCGvpQ3Oke+mDygE1gmRV8Gzq2BpXVoqRI6UxspH8Si8 VtrR+Q3POHrrcgeVAKCBx8v/ezk1xCVvFF152j6ATnED/VQjEBCeycWafX/IsWT9VNoe AYkEJKr5OJW8OalrPmtoDMVhD4T/KV1u6fAfRDHk4Hb31wM6bHyXYNGYMefoT1zh0ydO BkfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aly2sekyftKL3xTxoVjQH2nXvS+WhpDNZeV49uIGmI8=; b=A5ZKYKR6JrV3Mjzt7jme+qVh2q3zoKhJQQRzfzL6RLuxYB1sgx46X4QTkmvUpcw6pg B0UP2aXX3bUHiLm+fVcK0PwhjeNuHuKxXRHMU7dFDCGnQtRb4vpUvlbQSsLFoQKyNZfv +Cz/AaaR0ceG0I/r+V4pVp/b1nyJwtvxjvt1ovAYshrmHuQMXSMdxSnKM3b3RXImnrt+ QOpHSb0mt1opWKZqmeJEo7sbr1L54bdjs9CcxbUYTnebs0FH7PdcAWUoKvwDDrbYhLg3 8kEYQWGE0c7LK6Y7I5b/a6vyQa6sZjv4hGQ8+End/cERg4fj6i/Wcxx2MRNu4fnpR+i2 s81g== X-Gm-Message-State: APjAAAWPM6zoLmBpDL3PUv8tzyXot+ay0XdbeUQPt56L+ksW1g7qNKHM SiCUiptzxk3s+MBn2I+14svKbImnvH0M7A== X-Google-Smtp-Source: APXvYqznUNng58YwZQN3C544gnvO9OaGJUNs5wLAvQTcYLWqoKbXyYe93sUyGlxL/V2lWCnw9cr2Hw== X-Received: by 2002:a17:906:1e8f:: with SMTP id e15mr6189331ejj.153.1582936072955; Fri, 28 Feb 2020 16:27:52 -0800 (PST) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com. [209.85.221.45]) by smtp.gmail.com with ESMTPSA id q5sm622625edb.70.2020.02.28.16.27.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 16:27:52 -0800 (PST) Received: by mail-wr1-f45.google.com with SMTP id r7so5208618wro.2 for ; Fri, 28 Feb 2020 16:27:52 -0800 (PST) X-Received: by 2002:adf:90e1:: with SMTP id i88mr7345558wri.95.1582936071300; Fri, 28 Feb 2020 16:27:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Fri, 28 Feb 2020 16:27:40 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Mike Jones Cc: "oauth@ietf.org" , "david@alkaline-solutions.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Review of OAuth 2.0 for Browser-Based Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:27:59 -0000 Thank you for the thorough review! My responses and feedback is below. I've gone ahead and published a new draft based on this feedback so that the edits can be read in context. It is now available here: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05 I've made all "EDITORIAL" changes as suggested with the exception of the be= low: > Authorization Server Mix-Up Mitigation =E2=80=93 Please also reference dr= aft-ietf-oauth-mix-up-mitigation here. It appears that draft expired in January 2017, so it feels strange to reference an outdated draft. If that document is picked up again and shows signs that it is on track to publication I'd be happy to reference it. I'm going to avoid getting into the "ADDITIONAL OVERALL ISSUES" in this thread to keep it manageable. I will follow up with those specific points in a new thread later. As for the "SUBSTANTIVE" list, I've made most of the changes as suggested, with a few exceptions. These are noted below. > 1. Introduction =E2=80=93 The first sentence says that this spec is about= applications running entirely in a browser. Many browser-based applicatio= ns also use helper services. Please broaden the scope to encompass both pa= tterns. Changed "running entirely in a browser" to "executing in a browser". > 2. Overview =E2=80=93 Change =E2=80=9CThis was the principal motivation= =E2=80=9D to =E2=80=9CThis was one of the motivations=E2=80=9D. Done > 3. Terminology =E2=80=93 In the =E2=80=9COAuth=E2=80=9D definition, also= reference RFC 6750. Done > 4. Overview =E2=80=93 Change =E2=80=9Cthe current best practice for brow= ser-based applications is to use OAuth 2.0 authorization code flow with PKC= E=E2=80=9D to =E2=80=9Cthe current best practice for browser-based applicat= ions is to use either OAuth 2.0 authorization code flow with PKCE or OpenID= Connect =E2=80=9D. This parallels the same = recommendation in the forthcoming OAuth Security BCP specification. This feels too broad. It ends up sounding like it's okay to use the implicit flow to get an access token if you're also "using OpenID Connect". I would rather reference a specific grant type / response mode in OpenID Connect similar to how this sentence references specifically authorization code with PKCE. Any suggestions? > 4. Overview =E2=80=93 Change =E2=80=9CProtect themselves against CSRF at= tacks by using the OAuth 2.0 state parameter to carry one-time use CSRF tok= ens, or by ensuring the authorization server supports PKCE=E2=80=9D to =E2= =80=9CProtect themselves against CSRF attacks by using the OAuth 2.0 state = parameter or the OpenID Connect nonce parameter to carry one-time use CSRF = tokens or by ensuring the authorization server supports PKCE=E2=80=9D. Done > 4. Overview =E2=80=93 The intended meaning of this text isn=E2=80=99t cl= ear: =E2=80=9CRegister one or more redirect URIs, and not vary the redirect= URI per authorization request=E2=80=9D. Do you mean to include a register= ed redirect_uri value in each authorization request? This needs to be clar= ified. The intent is to prevent dynamic redirect URIs such as varying the query string component. I will update this to: "Register one or more redirect URIs, and use only exact registered redirect URIs in authorization requests" > 4. Overview =E2=80=93 Change =E2=80=9CSupport the PKCE extension=E2=80= =9D to =E2=80=9CSupport the PKCE extension or OpenID Connect=E2=80=9D. The Security BCP already requires that authorization servers MUST support PKCE. I don't think it makes sense for this BCP to allow supporting OpenID Connect *instead of* PKCE, which is what the text above would do. > 5. First-Party Applications =E2=80=93 The third paragraph says that =E2= =80=9Cfirst-party applications using OAuth or OpenID Connect MUST use the a= uthorization code flow=E2=80=9D. OpenID Connect can be safely used with ot= her response_type values than simply =E2=80=9Ccode=E2=80=9D. For instance,= the =E2=80=9Ccode id_token=E2=80=9D value is just as safe. Please general= ize this language when describing the use of OpenID Connect to recognize th= at other response_type value may continue to be safely used. The intent here is to require a redirect-based flow rather than for example the password grant. I will update this to: "To conform to this best practice, first-party applications using OAuth or OpenID Connect MUST use a redirect-based flow (such as the OAuth Authorization Code flow) as described later in this document." > 6.2. JavaScript Applications with a Backend =E2=80=93 The sentence =E2= =80=9CThe Application Server utilizes own session with the browser to store= the access token=E2=80=9D raises a question with no obvious answer: Where= is the specification recommending or suggesting that the access token be s= tored in this case? Please clarify. I've updated this text to: "The Application Server stores this access token itself and establishes its own cookie-based session with the Browser application. The Application Server can store the access token either server-side, or in the cookie itself." > 6.2. JavaScript Applications with a Backend =E2=80=93 The last paragraph= talks about exposing the access token to the end user but fails to describ= e the perceived risk or threat. If there are such risks or threats, please= be explicit about what they are and their mitigations. I thought I remembered seeing an attack described where the user can extract an access token from an application and use it for things the developers didn't intend. I can't find a reference to that right now though. Anyone have an idea of where that might be? If we can't come up with something to point to about that, I'm inclined to drop this sentence. > 6.3. JavaScript Applications without a Backend =E2=80=93 This sentence t= ells a false and incomplete story =E2=80=9CThe application then runs in the= browser, and is considered a public client since it has no ability to be i= ssued a client secret.=E2=80=9D Public clients can definitely be issued Cl= ient ID/Client Secret pairs using OAuth Dynamic Client Registration [RFC 75= 91]. Please revise this description accordingly. (Likewise, the following= paragraph says that =E2=80=9CThe JavaScript app is then responsible for st= oring the access token securely using appropriate browser APIs. If this is= safe, then storing the dynamically issued Client ID/Client Secret pair sho= uld be safe to do so in the same manner.) This phrasing could use some work, but the point still stands. An application deployed this way has no mechanism to securely authenticate with the authorization server, which is the RFC6749 definition of a confidential client. Dynamic client registration doesn't solve this, because the registration endpoint would have to be publicly available and then anyone could register a client so there's no way to tell whether this particular javascript application is the "real" one. I don't see any way that an application in this architecture could be treated as a confidential client. I will rephrase this to the below: "In this architecture, the JavaScript code is first loaded from a static web host into the browser (A), and the application then runs in the browser. This application is considered a public client, since there is no way to issue it a client secret and there is no other secure client authentication mechanism available in the browser." > 7.1. Initiating the Authorization Request from a Browser-Based Applicati= on =E2=80=93 As in other places where the text says that PKCE must be used,= please revise this instance to say that either PKCE or OpenID Connect must= be used =E2=80=93 just as is done in the forthcoming Security BCP. Again, saying "use OpenID Connect" is not specific enough. One of the things this BCP is trying to capture is the advice of only issuing access tokens at the token endpoint with an authorization code. Since OpenID Connect defines a few additional ways of issuing access tokens, it would need to get more specific about what part of OpenID Connect is okay here. Also, in the case that an application is not using OpenID Connect at all, only using OAuth, it needs to be clear still that PKCE is required, and that simply adding some unspecified part of OpenID Connect doesn't magically solve the problems with the implicit flow. Can you provide more specific guidance on when it's okay to not use PKCE? For example using certain response type or response mode combinations, and what parts of ID token validation must be followed in order to safely ignore PKCE? > 7.1. Initiating the Authorization Request from a Browser-Based Applicati= on =E2=80=93 As in other places where the spec says that the =E2=80=9Cstate= =E2=80=9D parameter must be used, revise this instance to say that either t= he OAuth =E2=80=9Cstate=E2=80=9D parameter or the OpenID Connect =E2=80=9Cn= once=E2=80=9D parameter must be used to prevent the applicable attacks. I've changed this paragraph to the below to better match the Security BCP, and to match what was discussed during IETF 106: "Browser-based apps MUST prevent CSRF attacks against their redirect URI. This can be accomplished by any of the below: * using PKCE, and confirming that the authorization server supports PKCE * if the application is using OpenID Connect, by using the OpenID Connect "nonce" parameter * using a unique value for the OAuth 2.0 "state" parameter" This section then references the Security BCP. > 9.2. Client Authentication =E2=80=93 The second paragraph talks about se= crets that are statically included and warns against them, which is good. = But please also add text describing how OAuth Dynamic Client Registration [= RFC 7591] can be used to safely statically create these secrets. Do we know of anyone doing this in the wild with SPAs right now? This feels like it has limited use at best, since dynamic registration doesn't actually authenticate the client for public clients. You could use the client secret instead of PKCE to prevent stolen authorization codes, but since PKCE also solves that problem, it doesn't seem very useful to recommend this. > 9.3. Client Impersonation =E2=80=93 Add text to the first paragraph desc= ribing how the use of the OpenID Connect =E2=80=9Cid_token_hint=E2=80=9D pa= rameter can be used to satisfy the requirement that the identity of the cli= ent can be assured. I am not familiar with how the id_token_hint provides assurance of the client identity. If the id_token was obtained via any front-channel mechanism, then it is at risk of being stolen, and then it can't be considered client authentication. Additionally, merely using the id_token in a GET request means it's susceptible to all the same problems we are avoiding with exposing access tokens in URLs, so again it doesn't seem useful as client authentication. > 9.3. Client Impersonation =E2=80=93 The wording of this phrase is ambigu= ous: =E2=80=9CIf authorization servers restrict redirect URIs to a fixed s= et of absolute HTTPS URIs without wildcard domains, paths, or query string = components=E2=80=A6=E2=80=9D It could be interpreted with the =E2=80=9Cwit= hout=E2=80=9D applying to =E2=80=9Cpaths or query string components=E2=80= =9D, meaning that no path or query string components may be present at all.= (I think you meant only that wildcard values not be present, but that=E2= =80=99s not the meaning of the phrase, as written.) Correct, this was supposed to say that wildcard values for any of those three components are not allowed. I will rephrase it to: "...a fixed set of absolute HTTPS URIs, preventing the use of wildcard domains, wildcard paths, or wildcard query string components..." > 9.4. Cross-Site Request Forgery Protections =E2=80=93 As in other places= where the spec says that the =E2=80=9Cstate=E2=80=9D parameter must be use= d, revise this instance to say that either the OAuth =E2=80=9Cstate=E2=80= =9D parameter or the OpenID Connect =E2=80=9Cnonce=E2=80=9D parameter must = be used to prevent the applicable attacks. I've replaced this section with the below: "Clients MUST prevent Cross-Site Request Forgery (CSRF) attacks against their redirect URI. Clients can accomplish this by either ensuring the authorization server sup= ports PKCE and relying on the CSRF protection that PKCE provides, or using the "s= tate" parameter to carry one-time-use CSRF tokens as described in {{auth_code_request}}, or if the client is also an OpenID Connect client, using the OpenID Connect "nonce" parameter. See Section 2.1 of [oauth-security-topics] for additional details." > 9.8. OAuth Implicit Grant Authorization Flow =E2=80=93 The paragraph end= s with =E2=80=9Cnot all of which have sufficient mitigation strategies=E2= =80=9D. It would be useful to be more specific here, saying which attacks = do not have sufficient mitigation strategies. The following sections with headers beginning with "Threat" describe the attacks, I've updated the text to hopefully clarify that. I've also added a new header structure here which should help make that relationship between the paragraphs more apparent. > 9.8.5. Countermeasures =E2=80=93 The phrase =E2=80=9Cusing the authoriza= tion code with PKCE avoids these attacks=E2=80=9D doesn=E2=80=99t say what = attacks are being referred to. Please revise so that the attacks in questi= on are unambiguously referenced. I've updated this section along with the change above. > Appendix A. Server Support Checklist =E2=80=93 In bullet 3, revise to sa= y that either PKCE or OpenID Connect is required, as per other locations in= the specification. This does not match what the Security BCP says: "Authorization servers MUST support PKCE" ---- Aaron Parecki aaronparecki.com @aaronpk On Fri, Feb 21, 2020 at 4:48 PM Mike Jones wr= ote: > > I did a cover-to-cover read of draft-ietf-oauth-browser-based-apps-04. M= y review comments follow in three sections: substantive comments on the te= xt, substantive overall issues to consider (provided by Microsoft product e= ngineers), and editorial issues. > > > > SUBSTANTIVE > > > > 1. Introduction =E2=80=93 The first sentence says that this spec is about= applications running entirely in a browser. Many browser-based applicatio= ns also use helper services. Please broaden the scope to encompass both pa= tterns. > > > > 2. Overview =E2=80=93 Change =E2=80=9CThis was the principal motivation= =E2=80=9D to =E2=80=9CThis was one of the motivations=E2=80=9D. > > > > 3. Terminology =E2=80=93 In the =E2=80=9COAuth=E2=80=9D definition, also= reference RFC 6750. > > > > 4. Overview =E2=80=93 Change =E2=80=9Cthe current best practice for brow= ser-based applications is to use OAuth 2.0 authorization code flow with PKC= E=E2=80=9D to =E2=80=9Cthe current best practice for browser-based applicat= ions is to use either OAuth 2.0 authorization code flow with PKCE or OpenID= Connect =E2=80=9D. This parallels the same = recommendation in the forthcoming OAuth Security BCP specification. > > > > 4. Overview =E2=80=93 Change =E2=80=9CUse the OAuth 2.0 authorization co= de flow with the PKCE extension=E2=80=9D to =E2=80=9CUse either the OAuth = 2.0 authorization code flow with the PKCE extension or OpenID Connect=E2=80= =9D. > > > > 4. Overview =E2=80=93 Change =E2=80=9CProtect themselves against CSRF at= tacks by using the OAuth 2.0 state parameter to carry one-time use CSRF tok= ens, or by ensuring the authorization server supports PKCE=E2=80=9D to =E2= =80=9CProtect themselves against CSRF attacks by using the OAuth 2.0 state = parameter or the OpenID Connect nonce parameter to carry one-time use CSRF = tokens or by ensuring the authorization server supports PKCE=E2=80=9D. > > > > 4. Overview =E2=80=93 The intended meaning of this text isn=E2=80=99t cl= ear: =E2=80=9CRegister one or more redirect URIs, and not vary the redirect= URI per authorization request=E2=80=9D. Do you mean to include a register= ed redirect_uri value in each authorization request? This needs to be clar= ified. > > > > 4. Overview =E2=80=93 Change =E2=80=9CSupport the PKCE extension=E2=80= =9D to =E2=80=9CSupport the PKCE extension or OpenID Connect=E2=80=9D. > > > > 5. First-Party Applications =E2=80=93 The third paragraph says that =E2= =80=9Cfirst-party applications using OAuth or OpenID Connect MUST use the a= uthorization code flow=E2=80=9D. OpenID Connect can be safely used with ot= her response_type values than simply =E2=80=9Ccode=E2=80=9D. For instance,= the =E2=80=9Ccode id_token=E2=80=9D value is just as safe. Please general= ize this language when describing the use of OpenID Connect to recognize th= at other response_type value may continue to be safely used. > > > > 6.2. JavaScript Applications with a Backend =E2=80=93 The sentence =E2= =80=9CThe Application Server utilizes own session with the browser to store= the access token=E2=80=9D raises a question with no obvious answer: Where= is the specification recommending or suggesting that the access token be s= tored in this case? Please clarify. > > > > 6.2. JavaScript Applications with a Backend =E2=80=93 The last paragraph= talks about exposing the access token to the end user but fails to describ= e the perceived risk or threat. If there are such risks or threats, please= be explicit about what they are and their mitigations. > > > > 6.3. JavaScript Applications without a Backend =E2=80=93 This sentence t= ells a false and incomplete story =E2=80=9CThe application then runs in the= browser, and is considered a public client since it has no ability to be i= ssued a client secret.=E2=80=9D Public clients can definitely be issued Cl= ient ID/Client Secret pairs using OAuth Dynamic Client Registration [RFC 75= 91]. Please revise this description accordingly. (Likewise, the following= paragraph says that =E2=80=9CThe JavaScript app is then responsible for st= oring the access token securely using appropriate browser APIs. If this is= safe, then storing the dynamically issued Client ID/Client Secret pair sho= uld be safe to do so in the same manner.) > > > > 7.1. Initiating the Authorization Request from a Browser-Based Applicati= on =E2=80=93 As in other places where the text says that PKCE must be used,= please revise this instance to say that either PKCE or OpenID Connect must= be used =E2=80=93 just as is done in the forthcoming Security BCP. > > > > 7.1. Initiating the Authorization Request from a Browser-Based Applicati= on =E2=80=93 As in other places where the spec says that the =E2=80=9Cstate= =E2=80=9D parameter must be used, revise this instance to say that either t= he OAuth =E2=80=9Cstate=E2=80=9D parameter or the OpenID Connect =E2=80=9Cn= once=E2=80=9D parameter must be used to prevent the applicable attacks. > > > > 9.2. Client Authentication =E2=80=93 The second paragraph talks about se= crets that are statically included and warns against them, which is good. = But please also add text describing how OAuth Dynamic Client Registration [= RFC 7591] can be used to safely statically create these secrets. > > > > 9.3. Client Impersonation =E2=80=93 Add text to the first paragraph desc= ribing how the use of the OpenID Connect =E2=80=9Cid_token_hint=E2=80=9D pa= rameter can be used to satisfy the requirement that the identity of the cli= ent can be assured. > > > > 9.3. Client Impersonation =E2=80=93 The wording of this phrase is ambigu= ous: =E2=80=9CIf authorization servers restrict redirect URIs to a fixed s= et of absolute HTTPS URIs without wildcard domains, paths, or query string = components=E2=80=A6=E2=80=9D It could be interpreted with the =E2=80=9Cwit= hout=E2=80=9D applying to =E2=80=9Cpaths or query string components=E2=80= =9D, meaning that no path or query string components may be present at all.= (I think you meant only that wildcard values not be present, but that=E2= =80=99s not the meaning of the phrase, as written.) > > > > 9.4. Cross-Site Request Forgery Protections =E2=80=93 As in other places= where the spec says that the =E2=80=9Cstate=E2=80=9D parameter must be use= d, revise this instance to say that either the OAuth =E2=80=9Cstate=E2=80= =9D parameter or the OpenID Connect =E2=80=9Cnonce=E2=80=9D parameter must = be used to prevent the applicable attacks. > > > > 9.8. OAuth Implicit Grant Authorization Flow =E2=80=93 The paragraph end= s with =E2=80=9Cnot all of which have sufficient mitigation strategies=E2= =80=9D. It would be useful to be more specific here, saying which attacks = do not have sufficient mitigation strategies. > > > > 9.8.5. Countermeasures =E2=80=93 The phrase =E2=80=9Cusing the authoriza= tion code with PKCE avoids these attacks=E2=80=9D doesn=E2=80=99t say what = attacks are being referred to. Please revise so that the attacks in questi= on are unambiguously referenced. > > > > Appendix A. Server Support Checklist =E2=80=93 In bullet 3, revise to sa= y that either PKCE or OpenID Connect is required, as per other locations in= the specification. > > > > ADDITIONAL OVERALL ISSUES FROM MICROSOFT ENGINEERS > > > > These issues should be considered in the context of this document. For t= hese, I=E2=80=99m requesting working group discussions =E2=80=93 not specif= ic resolutions at this time. > > There seems to be a lot of focus on exact redirect URI validation for add= ressing the biggest risk (open redirect), but while certainly absolutely cr= itical, it frankly ignores the reality of how apps integrate with authoriza= tion servers these days a bit. The pattern we are seeing is that a lot of a= pplications have simply shifted to including their own redirect URIs in 'st= ate' parameters. Even our own services use this pattern as cookie space is = quite limited. We are seeing a lot of security issues and there are no real= solutions in any of the BCP documents or RFCs. > In Section 4, the spec requires exact matching of redirect URIs. The OAut= h Security BCP mentions that there are alternatives to exact redirect URI m= atching =E2=80=9CAs an alternative to exact redirect URI matching, the AS c= ould also authenticate clients, e.g., using [I-D.ietf-oauth-jwsreq].=E2=80= =9D While I don=E2=80=99t think client authentication is suitable for brows= er based apps, accepting signed requests via OpenID Connect=E2=80=99s =E2= =80=9Crequest_uri=E2=80=9D parameter would be a suitable alternative patter= n to exact redirect URI checking. For consistency, I think both docs should= have the same recommendation for redirect URI matching. > Considering the above, we probably don't have many more good options for = fragment flows. That's one of the reasons why I still think hybrid patterns= have a place, but we need mechanisms to protect against code injection. Un= fortunately, the security-topics document dismisses solutions that we could= make work (code-bound state, nonce) in favor of solutions that don't help = (PKCE). This might be outside of this immediate discussion about the implic= it flow, but standards need to evolve to better mitigate that risk. > The big problem with giving SPAs refresh tokens is that refresh tokens pr= ovide offline access =E2=80=93 they live on after the user signs out =E2=80= =93 including when an attacker steals them. For JavaScript SPAs, where XSS = is a big concern, and where access is only intended to be provided for an o= nline user, these refresh tokens represent an unnecessary security liabilit= y. Disabling CORS on /token forces an implementation pattern without refres= h tokens for web apps. So today, we have a tradeoff between using the impli= cit flow and accepting attacks around browser history and generically injec= ted scripts with limited impact duration OR using the two legged flow and a= ccept attacks with specifically injected scripts with unlimited duration, p= lus a little perf/cogs hit. > > > > EDITORIAL > > > > 1. Introduction =E2=80=93 Change =E2=80=9Cnative apps as well as browser= -based apps=E2=80=9D to =E2=80=9Cnative apps and browser-based apps=E2=80= =9D. > > > > 4. Overview =E2=80=93 Change =E2=80=9COAuth 2.0 RFC 6749=E2=80=9D to =E2= =80=9COAuth 2.0 =E2=80= =9D. > > > > 4. Overview =E2=80=93 Change =E2=80=9Cthe flow assures that=E2=80=9D to = =E2=80=9Cthe flow ensures that=E2=80=9D. > > > > 5. First-Party Applications =E2=80=93 The first sentence of the second p= aragraph has no verb. > > > > 5. First-Party Applications =E2=80=93 The fifth paragraph starts with = =E2=80=9CBy using the Authorization Code flow and redirecting the user to t= he authorization server=E2=80=9D. I believe that this is continuing the me= ssage in the (single-sentence) fourth paragraph. The exposition will be le= ss confusing if these paragraphs are merged. > > > > 6. Application Architecture Patterns =E2=80=93 The bulleted list is not = in the same order as the corresponding subsections. Please reorder them to= make them parallel. > > > > 6.2. JavaScript Applications with a Backend =E2=80=93 This section refer= ences the OWASP Foundation as an organization. It would be far more useful= to instead list the documents containing the specific applicable recommend= ations. Please revise accordingly. > > > > 9.5. Authorization Server Mix-Up Mitigation =E2=80=93 Please also refere= nce draft-ietf-oauth-mix-up-mitigation here. > > > > 9.8.3. Threat: Manipulation of Scripts =E2=80=93 Please change =E2=80=9C= is far greater=E2=80=9D to =E2=80=9Cmay be amplified=E2=80=9D to avoid an o= verreaching statement. Likewise, delete the word =E2=80=9Cvery=E2=80=9D la= ter in the paragraph. > > > > 9.9. Additional Security Considerations =E2=80=93 This section reference= s the OWASP Foundation as an organization. It would be far more useful to = instead list the documents containing the specific applicable recommendatio= ns. Please revise accordingly. > > > > 11.1. Normative References =E2=80=93 These references are missing URLs: = CSP2, Fetch, oauth-security-topics. > > > > 11.1. Informative References =E2=80=93 This reference is missing a URL: = HTML. > > > > -- Mike > > From nobody Sat Feb 29 23:10:31 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F213A091A for ; Sat, 29 Feb 2020 23:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXRg1TYihbsI for ; Sat, 29 Feb 2020 23:10:28 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FA83A0918 for ; Sat, 29 Feb 2020 23:10:27 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id t11so2053187wrw.5 for ; Sat, 29 Feb 2020 23:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=QeGGH82X+89nSs46fpGHfT9I9wFGVsx4xBgF9GCRXWY=; b=GG/M9or+cLks+b8Ucc7e5qiXy7GrMro3Qa5IBzxRSBeVgDNjoA1PtoowSHDB5O+yVR vhd9OMfEiEYWzpJ+Yf4oDBDlSeSNaUlTytbxxwvBjIMG4HqISHhFB8tAOg33zS1WQF4P ITgyTE59veGY0X8aeA+tf3ubhIvXXQ2nd9+epTLKQtTqpP6TfPQYDFPpwGmcLdp2jmMD OyGbCQUR/NWfIx6XaRTnSj5sdx+T/RmlzU4z2rdNYlB0WPA00SC3WuC5vAEezIe28eQY WiAnqHzsqi6SM+NNOAmwHT6Z6tPWOJN+oP9WSE+nY6EUC/wIcFA3I1WYzHrRtHd6uis9 4X8A== 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=QeGGH82X+89nSs46fpGHfT9I9wFGVsx4xBgF9GCRXWY=; b=HxST7HEmvwAH6qB3wEzFJQ5cksM0Mo1s+Symug5WBRF9MaaQ9hoqikY+bO8vfyMq11 on2Osu80q1OCrq9WiJ9j0IwFzQfIemRoNAWX/lXL58j9t14nU2V1YB3+zEzpv+lZABrH rZUXQYaJ8j0+ng7wj5rEXNpV5wlwr/oJubhSOYoByKWCSZF4HOW0HjoqmePcKRoEiA0B /lRtiPiugAmVnWB9zxrZMSp/mWBXKRiOU8uMgl7fikzbL3yh4dXh5bjKJLejhbkZUonK rSC/+O1UkGrb1C6aV6ZpAySQzueNZC6MpWWIdI1CiST8YrlCtyUR5niJ/DmzNqwzR6sS DEdQ== X-Gm-Message-State: APjAAAWt7F4m2++AbMD1DqJWh+ilz7lqDTUKuRmNMm8L8DH+rNyhsTQ9 MakZtacNgqKITjER5YAiDGgBbE78n6sIC711EQpd4WUeExCaYg== X-Google-Smtp-Source: APXvYqyIp3SdhPphYocKvDtaAylF3p4SCH6LIBjaqR4Wri5jkwSfCtOiLrceCdt8AkR1+PT0zzFKI4wMuLvx9Bt8zxA= X-Received: by 2002:a5d:67c7:: with SMTP id n7mr14628624wrw.319.1583046625566; Sat, 29 Feb 2020 23:10:25 -0800 (PST) MIME-Version: 1.0 From: Takahiko Kawasaki Date: Sun, 1 Mar 2020 16:10:38 +0900 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c7b46d059fc5c3b3" Archived-At: Subject: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2020 07:10:30 -0000 --000000000000c7b46d059fc5c3b3 Content-Type: text/plain; charset="UTF-8" Hello, I'm wondering if the following conflicts in "JWT Response for OAuth Token Introspection" (draft 8 ) have already been pointed out. RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an introspection response hold the values of the 'resource' request parameters, whereas "JWT Response for OAuth Token Introspection" says that 'aud' MUST identify the resource server receiving the token introspection response. The definitions conflict. RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an introspection response indicate when the access/refresh token was issued, whereas "JWT Response for OAuth Token Introspection" says that 'iat' indicates when the introspection response in JWT format was issued. The definitions conflict. Best Regards, Takahiko Kawasaki Authlete, Inc. --000000000000c7b46d059fc5c3b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm wondering if the followi= ng conflicts in "JWT Response for OAuth Token Introspection" (draft 8) have already been pointed out.

RFC 8707 (Resource I= ndicators for OAuth 2.0) requires that 'aud' in an introspection re= sponse hold the values of the 'resource' request parameters, wherea= s "JWT Response for OAuth Token Introspection" says that 'aud= ' MUST identify the resource server receiving the token introspection r= esponse. The definitions conflict.

RFC 7662 (OAuth 2.0 Token Introspe= ction) requires that 'iat' in an introspection response indicate wh= en the access/refresh token was issued, whereas "JWT Response for OAut= h Token Introspection" says that 'iat' indicates when the intr= ospection response in JWT format was issued. The definitions conflict.
<= /div>

Best Regards,
Takahiko Kawasaki
Authlete, Inc.



--000000000000c7b46d059fc5c3b3-- From nobody Sat Feb 29 23:12:47 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE063A0918 for ; Sat, 29 Feb 2020 23:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6Tz25wCSLpK for ; Sat, 29 Feb 2020 23:12:44 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5A83A091E for ; Sat, 29 Feb 2020 23:12:44 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id n7so552903wrt.11 for ; Sat, 29 Feb 2020 23:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B0sfCalBUlmmDvtPf6FqmGKWgtIjl5JZf6aoP1BfFhQ=; b=geB058TsBYKRKifwQtTlhj1RtN7WvESj1c6ttW36CjVmJDPnnv9zmEIPnCd8RQICog 3XC93wlbz9bm54SQ1dwqWhGRkuCZNM1ud0uExkhLL8Htp9JG6E9LWuwlmoda8p/a4vQ9 q8TChDkVd+0jLx02ffearPCV4uWpn9ZXftvQu/8KrEOfJTAAhUJZJSpHOgPBxSv5HSLN GISHa9tN6sYgHcCGMbZNqKudpFaco7ektShGqbFryFRQfx3VG9Y8WoZb42cCNZcAMs72 5wM4+/10B9C4jqxDdIoiYRO+lZql4Oj5sOjK7R6LEex2BPNWNmtP4VFqthW6YvxznQJN 2Ilw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B0sfCalBUlmmDvtPf6FqmGKWgtIjl5JZf6aoP1BfFhQ=; b=kW6Li1L4282/LJpujhkZO7VIKHvvRhP1tTxltDvyXLeVUyKRk7gD5fOwfuCPt4kOz6 ITb7MpnKw9ScueSrtuoO6g6+6qiyivW8H76d32cEnTYLyyhRUmdp1go0wI5H6H46wWz9 U1G/fjYh5xEscbcXs2GTkW55Ax9xCekq6WCzwGMcywAQQKq20qh1zm1gTt3iKAPXXRiX kpokagCbD9HWUCaPrArkkMoURxehZHMmDFftYmNzrvT7GpaxhRHuyjT+nYbFM9JXPAQL 4Yh2dpD14qPCCLHCvnkRfReEfnZWaiY2isP6SpRdf+gx7EQugROC5LuHnGmGfdV0JlYF T7gg== X-Gm-Message-State: APjAAAV0YLoClmXCyC6KjlXR756yzmOaNrm5uJnX2IoVIb44GZnKitgs neUfYtJht1zIWTg4Qwt6jZdKndtG0bXy7GGYK3ZgdqFznoc= X-Google-Smtp-Source: APXvYqzdIc7Mmdlwx2H3mSEHPqGNH5ZzOSCwWZjt2y8RU8nMhuHGfZMAf0XRTIwcqaDT10qXHZcESFqDDQkY0xaqh3I= X-Received: by 2002:a5d:5301:: with SMTP id e1mr13949796wrv.44.1583046762777; Sat, 29 Feb 2020 23:12:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Deinega Date: Sat, 29 Feb 2020 23:12:31 -0800 Message-ID: To: Bill Jung Cc: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2020 07:12:47 -0000 Hello Bill, I'm just thinking out loud about possible scenarios for a protected resource here... It may decide to revoke a refresh token if a client application tried to use it instead of an access token when the protected resource is paranoid about security. In order to do that an introspection response should include a non-standard parameter which indicates that the requested token is refresh_token. A user of the introspection endpoint should rely only on a value of the active parameter (which is a boolean indicator) of the endpoint response. This applies to both types of tokens. Note, the expiration date, as well as other parameters, are defined as optional in the specification. Both token types can be revoked before the expiration date comes even if this parameter is presented as part of the response. In my opinion, there are a number of reasons why this check (for a refresh token) can be useful on the client application side. -- Regards, Andrii On Fri, Feb 28, 2020 at 1:59 AM Bill Jung wrote: > > Hello, hopefully I am using the right email address. > > Simply put, can this spec be enhanced to clarify "Who can use the introsp= ection endpoint for a refresh token? A resource provider or a client app or= both?" > > RFC7662 clearly mentions that the user of introspection endpoint is a 'pr= otected resource' and that makes sense for an access token. If we allow thi= s to client apps, it'll give unnecessary token information to them. > However, the spec also mentions that refresh tokens can also be used agai= nst the endpoint. > In case of refresh tokens, user of the endpoint should be a client app be= cause refresh tokens are used by clients to get another access token. (Cann= ot imagine how/why a resource server would introspect a refresh token) > > Is it correct to assume that the endpoint should be allowed to client app= s if they want to examine refresh token's expiry time? Then the RFC should = clearly mention it. > > Thanks in advance. > >
> In https://tools.ietf.org/html/rfc7662 > In '1. Introduction' section says, > "This specification defines a protocol that allows authorized > protected resources to query the authorization server to determine > the set of metadata for a given token that was presented to them by > an OAuth 2.0 client." > Above makes clear that user of the endpoint is a "protected resource". > > And under 'token' in '2.1. Introspection Request' section says, > "For refresh tokens, > this is the "refresh_token" value returned from the token endpoint > as defined in OAuth 2.0 [RFC6749], Section 5.1." > So looks like a refresh token is allowed for this endpoint. > > > Bill Jung > Manager, Response Engineering > bjung@pingidentity.com > w: +1 604.697.7037 > Connect with us: > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited.. If you have = received this communication in error, please notify the sender immediately = by e-mail and delete the message and any file attachments from your compute= r. Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
On Wed, Feb 19, 2020 at 3:07 PM Mike Jones <Michael.Jone= s=3D40microsoft.com@dmarc= .ietf.org> wrote:

The OAuth 2.0 Token Exchange specification=C2=A0 is = now RFC 8725 and BCP 225.=C2=A0 The abstract of the specification is:=

=C2=A0

JSON Web Tokens, also kn= own 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 identi= ty and in other application areas. This Best Current Practices document upd= ates RFC 7519 to provide actionable guidance leading to secure implementati= on and deployment of JWTs.

=C2=A0

The JSON Web Token (JWT) specification [RFC 7519] was approved i= n May 2015, almost five years ago, and has been in production use since= at least 2013.=C2=A0 This Best Curr= ent Practices specification contains a compendium of lessons learned fr= om real JWT deployments and implementations over that period.=C2=A0 It desc= ribes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise a= rise.=C2=A0 Importantly, the BCP introduces no breaking changes to the JWT = specification and does not require changes to existing deployments.<= u>

=C2=A0

The BCP came about as JWTs were starting to be used = in new families of protocols and applications, both in the IETF and by othe= rs.=C2=A0 For instance, JWTs are being used by the IETF STIR working group = to enable verification of the calling party's authorization to use a particular telephone number for an incoming call, p= roviding verified C= aller ID to help combat fraudulent and unwanted telephone calls.=C2=A0 = The advice in the BCP can be used by new JWT profiles and applications to t= ake advantage of what=E2=80=99s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

P.S.=C2=A0 This notice was also posted at https://self-issued.info/?p=3D2052 and as @selfissued.

=C2=A0

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