From nobody Thu Apr 1 12:11:21 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B133A1F86 for ; Thu, 1 Apr 2021 12:11:19 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aueb.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_wu--A3zIA5 for ; Thu, 1 Apr 2021 12:11:13 -0700 (PDT) Received: from blade-b3-vm-relay.servers.aueb.gr (blade-b3-vm-relay.servers.aueb.gr [195.251.255.106]) by ietfa.amsl.com (Postfix) with ESMTP id E79583A1F7F for ; Thu, 1 Apr 2021 12:11:12 -0700 (PDT) Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [195.251.255.217]) by blade-b3-vm-relay.servers.aueb.gr (Postfix) with ESMTP id 1CFE7B45 for ; Thu, 1 Apr 2021 22:11:09 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aueb.gr; s=201901; t=1617304269; bh=qGRkn++ASj4svbleyg+fMmaDx8j3KBiu0LGH/Jt/5R8=; h=From:Subject:Date:To:From; b=jD8ne/goRglmgf6gSv+UF6/PqWjMW4bNsdqtJQJlKHl+G0czwQa4JcMJ1VW0kuad7 qUgcpYYBam2g5QIx3FFacI8lgjdCcOFxujfbks7TiXSZGlESbeKGkbXXDWVapzpPdh XgfxTl2pDoTcted6wHIACvfA+d6aBZUAqzcZfPnvoLjtXktNu056u1Msl4M7Q96H0h JjQxqHuuqr2Q8EfAQK2jUgYexhya0RNJvjZV+gBerOqLmKlY1YmzmUZ9/rDnP9SNHk 5SVAWFc/6TD2msWoIyDeB7mHyK8pFaw2oEYB9IQoG6tiRmA9HL4JYoMAKyVKKvV1cD nXEyL6+aM+yfQ== Received: from [192.168.1.30] (athedsl-238333.home.otenet.gr [85.74.250.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fotiou) by blade-a1-vm-smtp.servers.aueb.gr (Postfix) with ESMTPSA id EC4A8734 for ; Thu, 1 Apr 2021 22:11:08 +0300 (EEST) From: Nikos Fotiou Content-Type: multipart/signed; boundary="Apple-Mail=_6EC31ECB-C477-471A-B4FD-C568A7F2FA9E"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <42E6041E-9F06-4276-A3D0-63C7FE18A335@aueb.gr> Date: Thu, 1 Apr 2021 22:11:07 +0300 To: oauth X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [OAUTH-WG] About JSON Web Token (JWT) Profile for OAuth 2.0 Access 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: Thu, 01 Apr 2021 19:11:20 -0000 --Apple-Mail=_6EC31ECB-C477-471A-B4FD-C568A7F2FA9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, By reading this draft = (https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-05) I got = the impression that it implies using JWTs as bearer tokens, e.g., it = does consider any of the semantics defined in RFC7800. Is this correct? = If yes what was the rational behind this design choice? Thanks a lot, Nikos -- Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr --Apple-Mail=_6EC31ECB-C477-471A-B4FD-C568A7F2FA9E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDgkw ggbQMIIEuKADAgECAhBAB3aGT+I5a2zJV9kPcbUZMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQG EwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9u cyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWlj cyBhbmQgQnVzaW5lc3MgQ0EgUjIwHhcNMTkxMjEyMTQxNzU4WhcNMjExMjExMTQxNzU4WjCCAQkx CzAJBgNVBAYTAkdSMQ8wDQYDVQQHDAZBdGhlbnMxNDAyBgNVBAoMK0F0aGVucyBVbml2ZXJzaXR5 IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtl eSBjcmVhdGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMQ8wDQYDVQQEDAZGT1RJT1kxETAP BgNVBCoMCE5JS09MQU9TMRMwEQYDVQQFEwozODY2OTQxMjIxMRgwFgYDVQQDDA9OSUtPTEFPUyBG T1RJT1kxHTAbBgkqhkiG9w0BCQEWDmZvdGlvdUBhdWViLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAgLLzGBqZBB4A0EYdBSjLSUYjNMZYSS14Z4+Esf6iK7wrSw8pOfjLBMqtJOyw azPxWgmmvhk6PaCLhZYgwPqdGQk3z+m3Hm2ao9fnFghTIBhXyypOJVCEVNblcY1r6+HZZLZZ/Z5N nMLuNKK+uWQ7dRR/GZDOFGcnOtcmMx9GKrgSrawVOsghzBRg5wLbvCaCNJsJ90mRYsyUjkg9OglG 2dzZ7Bi02BzozUwP69dFaKG7ml12C9FwQiaBURg3dDbgl7AuGY1AZcqBAPwKNni0Jkpl5XL2Jzjb zQj73EbTFMrsgG1PbGw/uZgQyCqAVHS1HiIJhyMTn7cttd5CobkMMwIDAQABo4IBqTCCAaUwHwYD VR0jBBgwFoAUd2BZxxknkkBQvIKZbY8+SdAQ9CowbQYIKwYBBQUHAQEEYTBfMDoGCCsGAQUFBzAC hi5odHRwOi8vcmVwby5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhQXVlYkNBUjIuY3J0MCEGCCsGAQUF BzABhhVodHRwOi8vb2NzcC5oYXJpY2EuZ3IwGQYDVR0RBBIwEIEOZm90aW91QGF1ZWIuZ3IwWAYD VR0gBFEwTzAIBgYEAI96AQEwQwYNKwYBBAGBzxEBAQICATAyMDAGCCsGAQUFBwIBFiRodHRwczov L3JlcG8uaGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUF BwMEBgorBgEEAYI3CgMMMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmx2MS5oYXJpY2EuZ3Iv SGFyaWNhQXVlYkNBUjIvY3JsdjEuZGVyLmNybDAdBgNVHQ4EFgQUcMJMYLF3+xjl9x4Fc4V2qRdA oVIwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAo/QEb7ED5Z7e3qdVPfIdKRpnL Q+JH3V7w4CKouEZkSjH2m+y0WOtMoF4cPCNrMH90n/IH9QuGcyYALRQTXAKsgF5s5TIeHc8fpFAe sjoVjTHTijK94b4ekh81jU/o8sRhsfWjPzAjzhSogWuh9yYox7fx0pvnux9lGE2+mVhE0xJqzP4N 6zGmVsYYOg6YfOtjYK46lvT5WOKkdK9lD9S3vmws0BPOCirvIqc9/fzKngZMTcsXMEZp91z40SuU xn48P370TKgvzIkmnDVB/iOobkdErAgp5j2o6s/Bt2m91VwLW3xOIV4F9y8BGOxsRqvRkv7wMKmh TjkAT+MVF7uw1S+vmeTeL+pdFUBAKJRizEqjCL6D7ZwpKszeMhi6Sx31ooOPpTOWtPh/fLfRRJBY NFcrYgMlBr0WWe1nIYajWskliR+5HNyNY8/zQApm9SGqr4VjaYdEwnU+NVLiZ2pikWyrg5B8Qyqc JCNdZRezjOPqM6DN+t52HMSnqHFxsy6cqOfqOSAsitZT2LkBWVDj3TxkENnw04hPUS4ip48jMB0s zuajEMmKqs5/uGY9EyQ3bHlDDWQxu/DULZJOcsZPX67mcOTLfXOXFnyW/gOGbvCgitlimm7xrDHm VWvB4AE7XPK7ogjGmG1qEq7vnYOcgj93DGizi+QkmVMCJwpGYjCCBzEwggYZoAMCAQICCBjdh64f S7Z7MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNh ZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMT N0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEw HhcNMTUwNzI4MDcxMDQ4WhcNMjMwNzI2MDcxMDQ4WjCBjzELMAkGA1UEBhMCR1IxRDBCBgNVBAoT O0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9y aXR5MTowOAYDVQQDEzFBdGhlbnMgVW5pdmVyc2l0eSBvZiBFY29ub21pY3MgYW5kIEJ1c2luZXNz IENBIFIyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjTO6hsbRRbmkpEjRUM1K7/Mn 2XgBgh/Tp6AbDXt5rS/oFBc/GJ5bCJFc7P1d1LHMSM1VT0advzlwE2xdnR0X9ThYKIm67gOAs1RU HxLqSYcrg2qkGdm1LadSwfn8KTDAxXynmVHhduU5jOTWS/LbX18EkZQ0tWiTEHxN+Uj7RFGzPrrE C6C3x+W/jZ9uZEfjLOxC0FHkYGndlHWh2SnoJyKvcWXE1F3DEdsGhm7gK/wxRG70U1ryihV3upd4 3YNdxEzBBEP2RIR8UDPLt4UpdfmmTk9uVJR6waYYtpnF10PSpuMRXNqV2dtlXCz8OEuoWFSlJbUF 7VmwiZIDg5P7INZ9bRWercaBquvOdDk0hBcuUfadx7TfPQHRhhUAP9UGvGcJsX7gP/3R0eUMGC6Q H+Ly5LKdfHpubVABNQnXcKXgVQtjJWGObSGsnz/X3PmhF+MYlQRtrT7852Paf0xnQ1klXaLpd04j RK/EoVrJs9jZWggPatQsX9aWuXR7xWGqOR3kT7aetAwk3FgT896eUj5V1C5eJZy9b21SJm5ux2Wt mrcpCtDcYSafDaJ/0toGUPnZZnDMyyKYbuQvNu7AVYcT5uFTu84JKTqjl8jrXb4PITFN7rjKPOb0 geJm+RtTDe9Shan4d0vty9xWUDvMV5utJPIkreaRdGDbbNJQkP0CAwEAAaOCAocwggKDMA8GA1Ud EwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR3YFnHGSeSQFC8gpltjz5J0BD0 KjBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEuaGFyaWNhLmdyL0hhcmljYVJvb3RDQTIw MTEvY3JsdjEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9E2FKI54IpCnl2BMEI+5BJTBuBggrBgEF BQcBAQRiMGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLmhhcmljYS5ncjA7BggrBgEFBQcwAoYv aHR0cDovL3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhUm9vdENBMjAxMS5jcnQwggE3BgNVHSAE ggEuMIIBKjCCASYGBFUdIAAwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5nci9k b2N1bWVudHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVtaWMgYW5k IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoGJVGhp cyBjZXJ0aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91ciBDUFMuIFRoaXMg Q2VydGlmaWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBl ZHVjYXRpb25hbCBwdXJwb3Nlcy4wLQYDVR0eBCYwJKAiMAmCB2F1ZWIuZ3IwCYEHYXVlYi5ncjAK gQguYXVlYi5ncjANBgkqhkiG9w0BAQsFAAOCAQEAhSXJoQDbTRBYH549pfk9+3CjT+HnAcFajp60 aV8UYR63DZflolPCDagaRxADLd3SpbOuGlRGNw+MgYpAp/d6i5BfVpjMVIhp5E7zr6TDJgVIwt2U xuLejfowumCNkRJD+RrdUcLKHzcPOfSD40MRHprehXT1bvyuka26ogF6U0T2uEDoOIaObV/RS9wg Gx9y63/QIc/tsZNQ3pzcAbTecnax6ITfSvnnfeMol6IcS+rKxPwKjPPFQq93qT8w61qe+zEx54vR wJXi241edkTmBTJddM5Cdhxxy98xYX+eYNnf5x96vVDQ1qc2wcecMHADZBrfVV/tx0Ev6hTlYBhO mzGCA68wggOrAgEBMIGkMIGPMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVt aWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0 aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MgQ0EgUjICEEAHdoZP4jlr bMlX2Q9xtRkwDQYJYIZIAWUDBAIBBQCgggHbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTIxMDQwMTE5MTEwOFowLwYJKoZIhvcNAQkEMSIEIGXSorZIJdnqyX5rnrZH WCtCgMBg1qtswg9IFvMuSLy5MIG1BgkrBgEEAYI3EAQxgacwgaQwgY8xCzAJBgNVBAYTAkdSMUQw QgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQu IEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBC dXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZD3G1GTCBtwYLKoZIhvcNAQkQAgsxgaeggaQwgY8x CzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5z dGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2Yg RWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZD3G1GTANBgkqhkiG9w0B AQsFAASCAQAac3QgzHLsu05uzJLGrOVZd0gmCMCEb9fbJVM3SreZj+1yhmm7tt5dY6VZjKYCIAEf uhYa+2jA4JiaRL2dDVQalwPIfDtyYw+L/z5JQR+Ie/NCR51UJD5TMfB4Zr2K2wOqWSsRo3xKhL3F m4k5SUV7nC/oeAS8pE0sVl4H3qh09ZZM20FZGxLhhPS5LttfIjv+wajqcWBku3mzOQ7XwaV0jNa6 FhRZSUQQ46HHyaei5Q3U4Dto23LnZXqw7hEARU79Lsd/iv/me+0lq9pWxalIW1bie1w13VstD4g9 0xlimgmiH/qsoFUWgoBaxQNqv4lcbEAHzeUbm58DAgcIdWg/AAAAAAAA --Apple-Mail=_6EC31ECB-C477-471A-B4FD-C568A7F2FA9E-- From nobody Thu Apr 1 13:32:15 2021 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 C0ACD3A2263; Thu, 1 Apr 2021 13:32:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-oauth-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes Tschofenig , hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <161730912872.14258.15710315415917535021@ietfa.amsl.com> Date: Thu, 01 Apr 2021 13:32:08 -0700 Archived-At: Subject: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with 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: Thu, 01 Apr 2021 20:32:09 -0000 Martin Duke has entered the following ballot position for draft-ietf-oauth-access-token-jwt-12: No Objection 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-access-token-jwt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (2.1) "...can use any signing algorithm." I presume there ought to be some qualifiers on allowed algorithms? (4) and (5) "This specification does not provide a mechanism for identifying a specific key as the one used to sign JWT access tokens." I don't understand; there's a key ID right there in the token header? (4) I presume it's important that any resouree server rejection of the token should be constant-time. Is this somewhere in the RFC tree, or do we need to explicitly say it here and/or in Security Considerations? From nobody Fri Apr 2 02:55:46 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703E53A0A1E for ; Fri, 2 Apr 2021 02:55:44 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gib-NpB7snqB for ; Fri, 2 Apr 2021 02:55:40 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7813A0A16 for ; Fri, 2 Apr 2021 02:55:40 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id h7so4295390ilj.8 for ; Fri, 02 Apr 2021 02:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lkYWTnvzlzOLz8TzZcl3b6dTHxD7csH90lkzfnmlpFk=; b=BtQXYYGnO4haciX5oVeripHvp3IRlgjwUsc9xTbG4fjuiK3z32xZHsDdF8HkpbLeyf +M0CrlVJAREa3892nYS4mmjV8+kmX74UUQkljW+4nilIR6lEkayTEB6ck5A77Hu5K3sn 9B+Ku3/2cSwDMEBQoNtfWemhSjneSsRXVUpdLG9lSch/Kb6gA4/CVdNIHe+R3erztDUz +t+X1hnyPWee+tIk4WsKqnlP18iXY0YdofCzFhZ9Q5RDu8ZSbEAF9TrWtoOg7m8LOd2p Dt87dDwOBwN5CbQ8Ys1ZdxA6n+ztzOnBR9QQR2zqiy3E9NgQyo9DRljCjx2/ZoKe2OGP s7EQ== 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=lkYWTnvzlzOLz8TzZcl3b6dTHxD7csH90lkzfnmlpFk=; b=h2EuWdNkWsFMKntNP50xhHVULW4vsgAwqeJQH6CP+8fPaKpYgCfDvkTPdbHwwBqT+m HkQWbPsOb8uSTNztJA0UY8FeNzx5fCq4BFLJqAWsC6jQ0FX+jwgHAGkHI+ma2XEZY/Ns HnTclom5APL/nQ6/Hu1WZ2iIo/9Ke+LQBejRqdJk5pohmp+9hLnIVDnU8RrgBv1HlBD7 +cj6n7OYiIPot28bRWtTHGDY8TOXzfl3deye312xk1GEaSYjnJYMfrX+UAix3I6hxOoX MhjCTyrkdnNr3yWAJ33vZEKo4jP5Whv+uid6coByAVp5HEIUAYVH0IRFjgm/qC59EPcr W4gg== X-Gm-Message-State: AOAM53210Wh5zDq72oQLj81xmAebIdsdFGivbPMDOuD2HI/3L7Z7FRYL 01ai7+ddGxDCU6JZ3bIhdALd47w8JvAaQDgXqZqJUShnGlqCzA== X-Google-Smtp-Source: ABdhPJyrsntR5e/ISfHjf5EfmoPLd7jn30BV4cnkBkaE+4uduoNIOf42rnB26bvO5zjY2KwSwih3QBze3YBFfVqBLKg= X-Received: by 2002:a92:d712:: with SMTP id m18mr10800568iln.127.1617357338714; Fri, 02 Apr 2021 02:55:38 -0700 (PDT) MIME-Version: 1.0 From: Roberto Polli Date: Fri, 2 Apr 2021 11:55:27 +0200 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000a624b505befa59ac" Archived-At: Subject: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 09:55:44 -0000 --000000000000a624b505befa59ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vittorio et al, some considerations on oauth access token jwt follows. You can see them here too https://docs.google.com/document/d/1XsvBzGvhcY0N6vJNgLx6G1dJ5trvgwYRJA9F_NC= akbU/edit An example with client_credential grant type would be nice too. My 2=C2=A2, R. =C2=A7 1.2 Terminology + The terms "Collision-Resistant", is used according to Section 2 of {{JWT}}. =C2=A72.1 Header - mentioning "none" alg can be redundant. I'd reference all the JWT BCP instead. - I'd add an example header, eg ~~~ example { "typ": "at+jwt", "alg": "PS256" } ~~~ =C2=A7 2.2.1 Authentication Information Claims Is it worth mentioning the "implicit flow"? =C2=A72.2.2 Identity Claims - use the "Collision-Resistant" definition in {{JWT}} =C2=A72.2.3 Authorization Claims - " ... scope parameter..." should `scope` be quoted? - "All the individual scope strings in the "scope" claim MUST have meaning for the resources indicated in the "aud" claim." ^ otherwise the error returned is ...? Should we reference =C2=A74 here? =C2=A72.2.3.1 Claims for Authorization Outside of Delegation Scenarios - which are the delegated scenarios described in RFC7519? Do you refer to "When using an administratively delegated namespace" ? It is not clear to a first-reader. =C2=A73 Requesting a JWT Access Token - an example with `client_credential` grant type would be great. - iiuc `jti` is required, the example does not report it. =C2=A74 Validating JWT Access Tokens - the step about forbidding "none" is limitative WRT JWT BCP 8725 --000000000000a624b505befa59ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vittorio et al,

some considerations = on oauth access token jwt follows.

An example = with client_credential grant type would be nice too.

My 2=C2=A2,
R.

=C2=A7 1.2=C2=A0 Termi= nology

+=C2=A0The terms "Collision-Resistant",=C2=A0 is used according to = Section 2 of {{JWT}}.=C2=A0

=C2=A72.1 Header

- mentioning = "none" alg can be redundant. I'd reference all the JWT BCP in= stead.
- I'd add an example header, eg

~~~ example

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap">{

=C2=A0=C2=A0"typ": "at+jwt= ",

=C2=A0= =C2=A0"alg": "PS256"

}

~~~



=C2=A7 2.2.1 Authentication Information Claims=

Is it worth mentioning the "implicit flow&qu= ot;?

=C2=A72.2.2 Identity Claims

- use the "Collision-Resistant" definition in {{JWT}}

=C2=A72.2.3 Authorization Claims

=
- " ... scope parameter..."=C2=A0 should `scope` be quoted?<= /div>
-=C2=A0 "All the in= dividual scope strings in the "scope" claim MUST have meaning for the resources indicated in= the "aud" claim."
^ otherwise the error returned is ...? Should we refer= ence =C2=A74 here?

=C2=A72.2.3.1 Claims for Authorization O= utside of Delegation Scenarios
- which are the delegated scenarios descr= ibed in RFC7519? Do you refer=C2=A0to "When using an administratively = delegated
=C2=A0 =C2=A0 =C2=A0 namespace" ? It is not clear to a fi= rst-reader.

<= div>=C2=A73 Requesting a JWT Acces= s Token
- an exam= ple with `client_credential` grant type would be great.
- iiuc `jti` is required, the exampl= e does not report it.

=C2=A74 Validating JWT Access Tokens

- t= he step about forbidding "none" is limitative WRT JWT BCP 8725
--000000000000a624b505befa59ac-- From nobody Fri Apr 2 12:18:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA933A2040 for ; Fri, 2 Apr 2021 12:18:18 -0700 (PDT) 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, 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wszeb_W21Odg for ; Fri, 2 Apr 2021 12:18:13 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB0E3A203E for ; Fri, 2 Apr 2021 12:18:13 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id v10so4145620pfn.5 for ; Fri, 02 Apr 2021 12:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=zD09ScUBub9iXtSBZKXC4M1i6J2x9y08PrYcxsJetCo=; b=XvlL+gPHdBWJHi7uDeLj5Zcq2jXH+i3NDaMeWc0Q03LbhVGve6uaF4vi2xYb/Cr8Io c+gG/Gy4sILWrJiTIhCmdf4vcCfyGUJQmTa1L3I6F3HjNAAGXc9gRFpMJ4AGg6qbP6TO gRP5rP9Qq6i0yiLNtaNEiGQ9nXDVDHr/w6RCGOIrcBbciYc53IUwfKmFwBgc0+81ZM3p mS4diFnSe6ZXzm2uauRFVA+BguSaKQKLG1wYUH02ZITmF6VSg6kBCVMsabTFxSHKd2Uv QJ7y5FQ841EwY9EqNSoDtwTjAiDnZ8LT9sANRr8bHPMNCp57GIRk9VcitpLMEdFq9D2y 7aZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=zD09ScUBub9iXtSBZKXC4M1i6J2x9y08PrYcxsJetCo=; b=B+G+Gp65kyIBVORy5gGG2MlkZtyT+WETLf+zEvc7g6jmi2zUDNi/LDZXUOi4vJl33z kB7dc1ZkMvBtqJOAKKBN2NfvTWjGDNeANwOa/VJTMrcDd8G2bwez3Mujawt+p1/Kql44 Z7bbwJmv7RlDgpt9F/+uVdERPT7vdz2s9Iaameo3dSybgtRADWrtU0/vaL4QKGpCQ2cS xUYsxBCf8MD+u2gS5N7Bl+0EYvxDKcAD9H8IU+hbF/fbQORXy4pLBQuUs9W0LKkQTMYC khOfi/huk8cnnvSxXp5VPVyI5V4RQm3whN7z5rqNIaBlqhZQgsRBwHQVHkl1OnO9s8Xh P9vQ== X-Gm-Message-State: AOAM531F4448cxzkahl6S3PNS8LtHSteigE1GyoKep2lhpUub6ydUa3p ZR/Wlwf5b7CmIIfOr6co4xBRLK0Re+BXvw== X-Google-Smtp-Source: ABdhPJwGycC4kpottcQwNMNwrsDDkrDL36r/EzbjDCOs1kGhtOwP+IAApLI9HVQ6DwWCHXKne20dAQ== X-Received: by 2002:a63:e746:: with SMTP id j6mr12850547pgk.91.1617391092355; Fri, 02 Apr 2021 12:18:12 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id 22sm8793769pjl.31.2021.04.02.12.18.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Apr 2021 12:18:12 -0700 (PDT) From: To: "'Nikos Fotiou'" , "'oauth'" References: <42E6041E-9F06-4276-A3D0-63C7FE18A335@aueb.gr> In-Reply-To: <42E6041E-9F06-4276-A3D0-63C7FE18A335@aueb.gr> Date: Fri, 2 Apr 2021 12:18:10 -0700 Message-ID: <057901d727f4$ebae4850$c30ad8f0$@auth0.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJDbSulm5vRZLDhbd+SAlQ8zqad/anJDd9g Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] About JSON Web Token (JWT) Profile for OAuth 2.0 Access 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, 02 Apr 2021 19:18:18 -0000 Hi Nikos, Thanks for looking into this! The profile aims at reflecting currently adopted practice as much as it is viable, and the overwhelming majority of the use cases involving access tokens today relies on bearer tokens. Note: although there's no practical difference between versions in the matter you brought up here, in general I recommend referring to the latest draft: we are currently on version 12 (https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12). -----Original Message----- From: OAuth On Behalf Of Nikos Fotiou Sent: Thursday, April 1, 2021 12:11 PM To: oauth Subject: [OAUTH-WG] About JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens Hi, By reading this draft (https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-05) I got the impression that it implies using JWTs as bearer tokens, e.g., it does consider any of the semantics defined in RFC7800. Is this correct? If yes what was the rational behind this design choice? Thanks a lot, Nikos -- Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr From nobody Sun Apr 4 08:25:09 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96C13A1710 for ; Sun, 4 Apr 2021 08:25:07 -0700 (PDT) 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 oEfg2DH6C0l4 for ; Sun, 4 Apr 2021 08:25:02 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E623A170E for ; Sun, 4 Apr 2021 08:25:02 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id d12so14103676lfv.11 for ; Sun, 04 Apr 2021 08:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cQZSNdgjHBHFfnpMo1NrE9YaTb6ARCEusgxPIBSnoS4=; b=O2MNSTpz02oVhoSLmIou4pHk+ztU/kI5YOV176ZkU0O0SMSdQu17z2was+k7BzuxpI YNQfV2Xp6M5bbzmWlQ4TOJJC6EoDbHJ0HSC5FRFeIoRIZhYm9ptbE+vAoX64nIzk2t7F 6ZnPm83p0q+MzlKmtmikBTQH5+GOOQ8zfBMSfJIRAYqllN9cLTvtfktt8BNBEq73urqr gvM+pvBLhWjFjboD6nIa1W7Vfi4oGyuQ0+TjTM4ECoWmlT4SIVQ2PbLPO3JJMhqUUMML M96mSRoRh19U/H4eK5Oigk2mnrlWOikhXBS/CM8zxEWxl0rMtvsATRTCSX5je5OAH155 coaQ== 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=cQZSNdgjHBHFfnpMo1NrE9YaTb6ARCEusgxPIBSnoS4=; b=NbIGkg8xP9fV4Dma8Szo3UE0A9Vds4s2GqQbllxni4woPHHqRHKYyb1HhJNa5s6h1M aTKItP7iLeNlVmxpXataGQn5hDmCqu60Qx74XlP/O3u/nnE7/vtoaiDrf7HC8yIfE84t c3cYcXeHi4OSxt9rJrCs64NAEwufHi5moEfL/Y38qnD/zEWJfyBngYsHaiiQ9eTmBfU/ hs1Dx2GoScU5O6vBvbRy+VdENAerdnOkAEjZ+H0DjUTzYxAKX2vQ2P9SYA/8uR4uR7iM a3QSVHLTfw41tVNVg+aIrxKAvJ4zekG+C40BqVyliFwxoIN9SS0mv/GtcaTm7BA7PJio w4kg== X-Gm-Message-State: AOAM533YMvoa9td0cByySadDOWKZtKR7iBs8vZ0WQRcfbJir9ZHCqAJY 3scxSA+RMuUlruTf64n/rSQN1G/AALBNQAsv7p+x7bkQ8bM= X-Google-Smtp-Source: ABdhPJxP8CV5Kad5jtbNRpP+Vd6YU3GAeNPakT0zPQRYB6H57Rt7YsNiGCZENkUJYr4yv9fWohD91lsaiV2jqw/EB9g= X-Received: by 2002:a05:6512:3298:: with SMTP id p24mr14228432lfe.221.1617549898385; Sun, 04 Apr 2021 08:24:58 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sun, 4 Apr 2021 11:24:47 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000019896705bf272ff6" Archived-At: Subject: [OAUTH-WG] OAuth Interim Meeting - April 5th - RAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 15:25:08 -0000 --00000000000019896705bf272ff6 Content-Type: text/plain; charset="UTF-8" All, The coming OAuth WG Interim meeting is this coming* Monday, April 5th, at 12:00 pm EDT.* The meeting will be focused on the RAR document: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ The following link has links to the slide and draft and will be used to capture the notes and attendees: https://codimd.ietf.org/notes-ietf-interim-2021-oauth-04-oauth?both *Webex Meeting Link:* https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b Regards, Rifaat & Hannes --00000000000019896705bf272ff6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The coming OAuth WG Interim meeting is th= is coming=C2=A0Monday, April 5th, at 12:00 pm EDT.
The meet= ing will be focused on the RAR document:

The following link = has links to the slide and draft and will be used to capture the notes and = attendees:

We= bex Meeting Link:
https://ietf.webex.= com/ietf/j.php?MTID=3Dm827c194bdcaa0077de44241f8001ce9b

Regards,=
=C2=A0Rifaat & Hannes




--00000000000019896705bf272ff6-- From nobody Sun Apr 4 11:01:06 2021 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 EBD873A1313; Sun, 4 Apr 2021 11:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: "The IESG" Cc: draft-ietf-oauth-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Francesca Palombini Message-ID: <161755926036.31657.529017576412672874@ietfa.amsl.com> Date: Sun, 04 Apr 2021 11:01:00 -0700 Archived-At: Subject: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with 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: Sun, 04 Apr 2021 18:01:01 -0000 Francesca Palombini has entered the following ballot position for draft-ietf-oauth-access-token-jwt-12: No Objection 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-access-token-jwt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document. Please find some comments and clarifying questions below. Francesca 1. ----- registration. If encryption was negotiated with the authorization server at registration time and the incoming JWT access token is not encrypted, the resource server SHOULD reject it. FP: Why is this just SHOULD and not MUST? In which case does it make sense to accept a non-encrypted token when encryption was negotiated? 2. ----- Section 2.1: Section 4). JWT access tokens MUST NOT use "none" as the signing algorithm. See Section 4 for more details. Section 4: For the purpose of facilitating validation data retrieval, it is here RECOMMENDED that authorization servers sign JWT access tokens with an asymmetric algorithm. ... o The resource server MUST validate the signature of all incoming JWT access tokens according to [RFC7515] using the algorithm specified in the JWT alg Header Parameter. The resource server FP: It might be obvious, but I think it would be useful to have an explicit sentence stating that JWT MUST be signed. The quoted text from Section 2.1 seem to imply it. Section 4 only RECOMMENDS that the JWT is signed with and asymmetric algorithm. Later on, Section 4 implies that all JWT are signed. On the other hand I note that encryption can be negotiated (and is optional) from the followig point; in that case it is not clear that the token is still signed (so the nested JWT would be a JWE nested in a JWS), or only JWE is used. What I am looking for is simple clarifications to be added for example in the introduction. o If the JWT access token is encrypted, decrypt it using the keys and algorithms that the resource server specified during registration. If encryption was negotiated with the authorization 3. ----- On the same note, and depending on the previous answer, why is the media type registered and used "application/at+jwt" and not something like "application/at+jws"/"application/at+jwe" or rather "application/at+jose" to be compliant with https://www.rfc-editor.org/rfc/rfc7515.html#section-9.2.1 ? I think that the structure transported is in fact a JWS or a JWE, rather than the JWT, and if that's the case that should be made clear in the text (one example where this could be clarified is in the following sentence) Resource servers receiving a JWT access token MUST validate it in the following manner. From nobody Sun Apr 4 14:16:00 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED263A1AF1 for ; Sun, 4 Apr 2021 14:15:53 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aueb.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NELIQIRwfvgI for ; Sun, 4 Apr 2021 14:15:49 -0700 (PDT) Received: from blade-b3-vm-relay.servers.aueb.gr (blade-b3-vm-relay.servers.aueb.gr [195.251.255.106]) by ietfa.amsl.com (Postfix) with ESMTP id 704733A1AE2 for ; Sun, 4 Apr 2021 14:15:47 -0700 (PDT) Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [195.251.255.217]) by blade-b3-vm-relay.servers.aueb.gr (Postfix) with ESMTP id 12603977 for ; Mon, 5 Apr 2021 00:15:45 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aueb.gr; s=201901; t=1617570945; bh=pYyavVvo+qCyatyWr+5zcdJNLmQIfv4vf3J8EtKKG/o=; h=From:Subject:Date:To:From; b=wHfbYDgt0YFf+qk/xudEFzUNhLFNWCUCMPH3yNYDRzdwy9QQkB+SdCF5G7Sb3rbxD aSwIWd2YjGPpxxSBnFW14yIvLwtmqcu5VNRRtj4d/dNt+Wi3NHFm81kmsV9v5fnGZM 3HuHxN1+bjyjex6XS0+Hzmo71hJCS/X4UxDR3bDIh8HdJjrR0DYZIUPPAyBVWkk7YT 5Dq1ydp3tuAg0yUtNjsBLcQSvVKIYkgEnHHHMkxZJnw1V2PU9bHHWky4pGgsUqh6Ey UerC0NaJJUcP/UPXMX/qfwza5+neO6DiAsO03j+c423xW3wTVDlt6G8K86wQH8pF/J YVqTqAEKnl1Wg== Received: from [192.168.1.30] (athedsl-238333.home.otenet.gr [85.74.250.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fotiou) by blade-a1-vm-smtp.servers.aueb.gr (Postfix) with ESMTPSA id CE8B3327 for ; Mon, 5 Apr 2021 00:15:44 +0300 (EEST) From: Nikos Fotiou Content-Type: multipart/signed; boundary="Apple-Mail=_D7B9D607-C7E3-473C-8840-E1DA8B1D5A41"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <745359AE-98D7-4AC0-B088-E522E8CF3FFC@aueb.gr> Date: Mon, 5 Apr 2021 00:15:43 +0300 To: oauth X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [OAUTH-WG] dpop terminogly X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 21:15:59 -0000 --Apple-Mail=_D7B9D607-C7E3-473C-8840-E1DA8B1D5A41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi I am wondering if the following terminology is more appropriate for = the DPoP draft (https://tools.ietf.org/html/draft-fett-oauth-dpop-04): - Since a DPoP proof is a JWT encoded in a JWS may be it is better to = say "DPoP proof payload" instead of "DPoP proof body" (end of page 4). - For the same reason use "JOSE header" instead of "JSON header" = (beginning of page 5) - Moreover, here and there it is stated "the header of the JWT". AFAIU = JWTs do not have headers themselves but the header is part of the = JWS/JWE structure in which the JWT is encoded. So may be it is more = appropriate to say "the JOSE header" instead of "the header of the JWT".=20= Best, Nikos -- Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr --Apple-Mail=_D7B9D607-C7E3-473C-8840-E1DA8B1D5A41 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDgkw ggbQMIIEuKADAgECAhBAB3aGT+I5a2zJV9kPcbUZMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQG EwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9u cyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWlj cyBhbmQgQnVzaW5lc3MgQ0EgUjIwHhcNMTkxMjEyMTQxNzU4WhcNMjExMjExMTQxNzU4WjCCAQkx CzAJBgNVBAYTAkdSMQ8wDQYDVQQHDAZBdGhlbnMxNDAyBgNVBAoMK0F0aGVucyBVbml2ZXJzaXR5 IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtl eSBjcmVhdGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMQ8wDQYDVQQEDAZGT1RJT1kxETAP BgNVBCoMCE5JS09MQU9TMRMwEQYDVQQFEwozODY2OTQxMjIxMRgwFgYDVQQDDA9OSUtPTEFPUyBG T1RJT1kxHTAbBgkqhkiG9w0BCQEWDmZvdGlvdUBhdWViLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAgLLzGBqZBB4A0EYdBSjLSUYjNMZYSS14Z4+Esf6iK7wrSw8pOfjLBMqtJOyw azPxWgmmvhk6PaCLhZYgwPqdGQk3z+m3Hm2ao9fnFghTIBhXyypOJVCEVNblcY1r6+HZZLZZ/Z5N nMLuNKK+uWQ7dRR/GZDOFGcnOtcmMx9GKrgSrawVOsghzBRg5wLbvCaCNJsJ90mRYsyUjkg9OglG 2dzZ7Bi02BzozUwP69dFaKG7ml12C9FwQiaBURg3dDbgl7AuGY1AZcqBAPwKNni0Jkpl5XL2Jzjb zQj73EbTFMrsgG1PbGw/uZgQyCqAVHS1HiIJhyMTn7cttd5CobkMMwIDAQABo4IBqTCCAaUwHwYD VR0jBBgwFoAUd2BZxxknkkBQvIKZbY8+SdAQ9CowbQYIKwYBBQUHAQEEYTBfMDoGCCsGAQUFBzAC hi5odHRwOi8vcmVwby5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhQXVlYkNBUjIuY3J0MCEGCCsGAQUF BzABhhVodHRwOi8vb2NzcC5oYXJpY2EuZ3IwGQYDVR0RBBIwEIEOZm90aW91QGF1ZWIuZ3IwWAYD VR0gBFEwTzAIBgYEAI96AQEwQwYNKwYBBAGBzxEBAQICATAyMDAGCCsGAQUFBwIBFiRodHRwczov L3JlcG8uaGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUF BwMEBgorBgEEAYI3CgMMMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmx2MS5oYXJpY2EuZ3Iv SGFyaWNhQXVlYkNBUjIvY3JsdjEuZGVyLmNybDAdBgNVHQ4EFgQUcMJMYLF3+xjl9x4Fc4V2qRdA oVIwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAo/QEb7ED5Z7e3qdVPfIdKRpnL Q+JH3V7w4CKouEZkSjH2m+y0WOtMoF4cPCNrMH90n/IH9QuGcyYALRQTXAKsgF5s5TIeHc8fpFAe sjoVjTHTijK94b4ekh81jU/o8sRhsfWjPzAjzhSogWuh9yYox7fx0pvnux9lGE2+mVhE0xJqzP4N 6zGmVsYYOg6YfOtjYK46lvT5WOKkdK9lD9S3vmws0BPOCirvIqc9/fzKngZMTcsXMEZp91z40SuU xn48P370TKgvzIkmnDVB/iOobkdErAgp5j2o6s/Bt2m91VwLW3xOIV4F9y8BGOxsRqvRkv7wMKmh TjkAT+MVF7uw1S+vmeTeL+pdFUBAKJRizEqjCL6D7ZwpKszeMhi6Sx31ooOPpTOWtPh/fLfRRJBY NFcrYgMlBr0WWe1nIYajWskliR+5HNyNY8/zQApm9SGqr4VjaYdEwnU+NVLiZ2pikWyrg5B8Qyqc JCNdZRezjOPqM6DN+t52HMSnqHFxsy6cqOfqOSAsitZT2LkBWVDj3TxkENnw04hPUS4ip48jMB0s zuajEMmKqs5/uGY9EyQ3bHlDDWQxu/DULZJOcsZPX67mcOTLfXOXFnyW/gOGbvCgitlimm7xrDHm VWvB4AE7XPK7ogjGmG1qEq7vnYOcgj93DGizi+QkmVMCJwpGYjCCBzEwggYZoAMCAQICCBjdh64f S7Z7MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNh ZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMT N0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEw HhcNMTUwNzI4MDcxMDQ4WhcNMjMwNzI2MDcxMDQ4WjCBjzELMAkGA1UEBhMCR1IxRDBCBgNVBAoT O0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9y aXR5MTowOAYDVQQDEzFBdGhlbnMgVW5pdmVyc2l0eSBvZiBFY29ub21pY3MgYW5kIEJ1c2luZXNz IENBIFIyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjTO6hsbRRbmkpEjRUM1K7/Mn 2XgBgh/Tp6AbDXt5rS/oFBc/GJ5bCJFc7P1d1LHMSM1VT0advzlwE2xdnR0X9ThYKIm67gOAs1RU HxLqSYcrg2qkGdm1LadSwfn8KTDAxXynmVHhduU5jOTWS/LbX18EkZQ0tWiTEHxN+Uj7RFGzPrrE C6C3x+W/jZ9uZEfjLOxC0FHkYGndlHWh2SnoJyKvcWXE1F3DEdsGhm7gK/wxRG70U1ryihV3upd4 3YNdxEzBBEP2RIR8UDPLt4UpdfmmTk9uVJR6waYYtpnF10PSpuMRXNqV2dtlXCz8OEuoWFSlJbUF 7VmwiZIDg5P7INZ9bRWercaBquvOdDk0hBcuUfadx7TfPQHRhhUAP9UGvGcJsX7gP/3R0eUMGC6Q H+Ly5LKdfHpubVABNQnXcKXgVQtjJWGObSGsnz/X3PmhF+MYlQRtrT7852Paf0xnQ1klXaLpd04j RK/EoVrJs9jZWggPatQsX9aWuXR7xWGqOR3kT7aetAwk3FgT896eUj5V1C5eJZy9b21SJm5ux2Wt mrcpCtDcYSafDaJ/0toGUPnZZnDMyyKYbuQvNu7AVYcT5uFTu84JKTqjl8jrXb4PITFN7rjKPOb0 geJm+RtTDe9Shan4d0vty9xWUDvMV5utJPIkreaRdGDbbNJQkP0CAwEAAaOCAocwggKDMA8GA1Ud EwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR3YFnHGSeSQFC8gpltjz5J0BD0 KjBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEuaGFyaWNhLmdyL0hhcmljYVJvb3RDQTIw MTEvY3JsdjEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9E2FKI54IpCnl2BMEI+5BJTBuBggrBgEF BQcBAQRiMGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLmhhcmljYS5ncjA7BggrBgEFBQcwAoYv aHR0cDovL3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhUm9vdENBMjAxMS5jcnQwggE3BgNVHSAE ggEuMIIBKjCCASYGBFUdIAAwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5nci9k b2N1bWVudHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVtaWMgYW5k IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoGJVGhp cyBjZXJ0aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91ciBDUFMuIFRoaXMg Q2VydGlmaWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBl ZHVjYXRpb25hbCBwdXJwb3Nlcy4wLQYDVR0eBCYwJKAiMAmCB2F1ZWIuZ3IwCYEHYXVlYi5ncjAK gQguYXVlYi5ncjANBgkqhkiG9w0BAQsFAAOCAQEAhSXJoQDbTRBYH549pfk9+3CjT+HnAcFajp60 aV8UYR63DZflolPCDagaRxADLd3SpbOuGlRGNw+MgYpAp/d6i5BfVpjMVIhp5E7zr6TDJgVIwt2U xuLejfowumCNkRJD+RrdUcLKHzcPOfSD40MRHprehXT1bvyuka26ogF6U0T2uEDoOIaObV/RS9wg Gx9y63/QIc/tsZNQ3pzcAbTecnax6ITfSvnnfeMol6IcS+rKxPwKjPPFQq93qT8w61qe+zEx54vR wJXi241edkTmBTJddM5Cdhxxy98xYX+eYNnf5x96vVDQ1qc2wcecMHADZBrfVV/tx0Ev6hTlYBhO mzGCA68wggOrAgEBMIGkMIGPMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVt aWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0 aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MgQ0EgUjICEEAHdoZP4jlr bMlX2Q9xtRkwDQYJYIZIAWUDBAIBBQCgggHbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTIxMDQwNDIxMTU0M1owLwYJKoZIhvcNAQkEMSIEILxfOJOSFecPHQpR+tJ4 H7vhsiqtnTgRW2M70SJ6GDl7MIG1BgkrBgEEAYI3EAQxgacwgaQwgY8xCzAJBgNVBAYTAkdSMUQw QgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQu IEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBC dXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZD3G1GTCBtwYLKoZIhvcNAQkQAgsxgaeggaQwgY8x CzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5z dGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2Yg RWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZD3G1GTANBgkqhkiG9w0B AQsFAASCAQAR/P53BzVy2hCOxocjrWYvfCRKGl+32h0kXry61zNE6m0b1OZRzZohAQCEuqC1A2aL qzJuZ3Oq+fMVszADcX0t5igYB/cNqHiB9+FzI0J4XdnKtXklP9JlTRdXhFbqLpBEq2ZgcCCxxFeY b9jhJrRKaO/Z2VD7Do9OGxsF1IU/QYaWkjLOp6JAiZBRaxb9Q+8pGp03cBGUuZYyWmMKuyY3SpMu Er7TGKvkNC8kVlv4xW8Ffb++7b21PeQajIWI474yLnOBh7zslECgkbh51NJzZMw+1ALt6L58hiyS BZldOglQ/8F1KjAj/IfkX/8oPzoH/zWs4RMSkI3vINcx9KH9AAAAAAAA --Apple-Mail=_D7B9D607-C7E3-473C-8840-E1DA8B1D5A41-- From nobody Sun Apr 4 16:46:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432443A1F55 for ; Sun, 4 Apr 2021 16:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-vIZjV_JgVI for ; Sun, 4 Apr 2021 16:46:41 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE89D3A1F53 for ; Sun, 4 Apr 2021 16:46:41 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id u8so7391207qtq.12 for ; Sun, 04 Apr 2021 16:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hxItlsgmOxDUVlU0ovNMqqbkNb1rb9Xr/qEQ5tzxvIc=; b=V7IiGK6E3b4qsIFokioP2htopOtNmG1Y58BI+OTks+h+9KOYtyQc5kOLwaNpPdAr7U Trhr2ZVNWx/K7kBjPyRcHo1sOPBzrdT55SKxJXdWlxmthwaWGfxz7Llp0hrhWsXQRoZc L5seFWAzZDB0StvdH6HIX9aWO3rtgp3cPiXpyu60k7KSFhjzm4+sBeaInM5MsydIeVGW MQbR8BHs6D1kHBi2O22zxbLtIuHK2MOHGNYc5Xgj1etn+l0HBs4KB09coxOEdBRCVktf mxzmoFaJltK4kEj2uGOZ9rp4g4efhqezm8ZPPZsYc3nvnD5y1XlSiWlglfMJss/j/zuw hqNg== 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=hxItlsgmOxDUVlU0ovNMqqbkNb1rb9Xr/qEQ5tzxvIc=; b=ET2Y2pD2mYnsjYlXamZtmpOY3/IYX9H09nQ9fEkDhY0MYMpPWiflW67q8fHhgKMNux a5C+Ql7Qm4EDMrrj0NYXjORbFnqTq5FehOruyz9eLRT5nM3DV4McL0AkBcIAz5gG8tYn 8NpIOpU3CbvK0F3Yo3VyPvtoeLL4eVBl7531WeuxBXLbJ9Ce1U7zCXgXLtQ13kiWXXmH czI6ilD4fzTlu7dH+Ouq1+BpmPR1OSuadS7XOovAi3xsq/7zIaD7lhYZ/J+jzx397Y50 akIrFDH2J4Va86jGF+Z9ztHqPTAButiBHKQoWGKnAN2QwqX7rMhqYKV+5NfbwOW/QEPZ DlBA== X-Gm-Message-State: AOAM532Y9vQi+OPECzt9iNbWblCeo2BPm98Vca2Ge9OkfcMD0E2Aw+QK liA/jcXHrdirlQp299AQNy549vSsWDpF3Q== X-Google-Smtp-Source: ABdhPJzOfpon9ofeCAHvBbCT0diaMCDFTq7bnedHvQVO6bGMPy8iX+o/ZwqyHwEh0m7hNUyzjBpDCA== X-Received: by 2002:a05:622a:18a:: with SMTP id s10mr20018649qtw.237.1617579999722; Sun, 04 Apr 2021 16:46:39 -0700 (PDT) Received: from [192.168.1.157] (pool-108-21-243-205.nycmny.fios.verizon.net. [108.21.243.205]) by smtp.gmail.com with ESMTPSA id c5sm12491782qkg.105.2021.04.04.16.46.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Apr 2021 16:46:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Manuel Nieves In-Reply-To: <745359AE-98D7-4AC0-B088-E522E8CF3FFC@aueb.gr> Date: Sun, 4 Apr 2021 19:46:37 -0400 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <6212452E-F608-4F0B-A9C5-6DB51C96069C@gmail.com> References: <745359AE-98D7-4AC0-B088-E522E8CF3FFC@aueb.gr> To: Nikos Fotiou X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [OAUTH-WG] dpop terminogly X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 23:46:46 -0000 Hello you want to better help me understand what is this you referring = too? > On Apr 4, 2021, at 5:15 PM, Nikos Fotiou wrote: >=20 > Hi I am wondering if the following terminology is more appropriate for = the DPoP draft (https://tools.ietf.org/html/draft-fett-oauth-dpop-04): > - Since a DPoP proof is a JWT encoded in a JWS may be it is better to = say "DPoP proof payload" instead of "DPoP proof body" (end of page 4). > - For the same reason use "JOSE header" instead of "JSON header" = (beginning of page 5) > - Moreover, here and there it is stated "the header of the JWT". AFAIU = JWTs do not have headers themselves but the header is part of the = JWS/JWE structure in which the JWT is encoded. So may be it is more = appropriate to say "the JOSE header" instead of "the header of the JWT".=20= >=20 > Best, > Nikos >=20 > -- > Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou > Researcher - Mobile Multimedia Laboratory > Athens University of Economics and Business > https://mm.aueb.gr >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Apr 5 08:06:53 2021 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 97AFF3A1C2F; Mon, 5 Apr 2021 08:06:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161763520750.31676.16609794460117567178@ietfa.amsl.com> Date: Mon, 05 Apr 2021 08:06:47 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-05-03 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, 05 Apr 2021 15:06:48 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-05-03 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: OAuth 2.1 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Mon Apr 5 11:36:27 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1373A22F6 for ; Mon, 5 Apr 2021 11:36:26 -0700 (PDT) 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, 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 3eTVMneiPdL6 for ; Mon, 5 Apr 2021 11:36:25 -0700 (PDT) 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 CA7613A22F4 for ; Mon, 5 Apr 2021 11:36:24 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id v140so971070lfa.4 for ; Mon, 05 Apr 2021 11:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NvbXgqX8+c+HSEeRvgMpnOJmB+jEvSsv0Kwfkgr1CQA=; b=Frhy5B8Z4DPG2zrWnwA2WmUM6UKzx1gZUjI9FuZmR7vRRDTN0poVC9VQ9bnJ5MqNPs SVjhiSq/ohiFfU62lyaRdusPnbV600faNlorbcfeN8kOWC62m4Z3fgY06N/Ofa2dMBmk M0Tq+oRMNInbQZxD5Tjg+pS1uIidJ+lkp9Pmj+m0M1tTShVQjvN6u72yRsjqtFoOfTb+ afpiNyzHJ1oOuNPUSgIsccXikXDAjjeYtu2sYEm/GjbFiGcJHP6jiWRfA5R2el67Wdmy sTcz2LoH6VbDSLue/9MfLZyPnEXTEAaEtFeZG6PxNGyAo2QyEpfZqjaj6ldpscjWi8J9 qu/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NvbXgqX8+c+HSEeRvgMpnOJmB+jEvSsv0Kwfkgr1CQA=; b=VbxFL6/fiV86UvQQIS1YUsF0g8tUUdHLSAEUppHxs3CushTldA5sJIqHo2K6KtcPW3 /7vjeQYanv9JLmA4k+45ifvvjs/lPsxPyVi2dUN3qifro5toj6tInFmt4GPzeLzaslGL KdQup5JUZX0cvdLjICkDaFSUCcUr5iSTyM+epcquDkS4Y3O/R91Ikdqea/OyCuaSMTHr LfFIqvtedIlFfAirMKFurKWHFDtqejfI1litot8euFDLFIuXw0Zb6wrPVC2HTnfgpvos o0KxiCxPg7tp0CYcO9BGiJdQNz3yy4eHqA8knGh0uxXr8wpHHE/E+G3lKLDRTq+RRUG7 Qjnw== X-Gm-Message-State: AOAM532iBaW+sCCwnOm7Wn0E7BcEr8d9Le+u5jGuD0zlS0Y1X/jeWWQv 2Rw81iSmRC6frS+YUSHBOe2VEBgLrLYEqLw2Sp6hIwfg1co= X-Google-Smtp-Source: ABdhPJx8wj9VrfXf1ze4CpVykVHmc5yxWZbLdX5jRyPtV2V+Ejss0IGKxsQI9+GEh4A86yBsIH0O6Pa+lmcS8ZBTcdg= X-Received: by 2002:a19:f812:: with SMTP id a18mr18456272lff.254.1617647779822; Mon, 05 Apr 2021 11:36:19 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 5 Apr 2021 14:36:08 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000049be8c05bf3df963" Archived-At: Subject: [OAUTH-WG] April 5th Interim Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 18:36:26 -0000 --00000000000049be8c05bf3df963 Content-Type: text/plain; charset="UTF-8" All, Take a look at the following links for the April 5th interim meeting minutes: https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-04-oauth https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-04-202104051200/ Thanks to *Brian Campbell *for taking these notes. Regards, Rifaat & Hannes --00000000000049be8c05bf3df963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Take a look at the following links= for the April=C2=A05th interim meeting minutes:

Thanks to Brian Campbell=C2= =A0for taking these notes.

Regards,
= =C2=A0Rifaat & Hannes
--00000000000049be8c05bf3df963-- From nobody Mon Apr 5 15:58:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01793A2B88 for ; Mon, 5 Apr 2021 15:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5ld2I91doofK for ; Mon, 5 Apr 2021 15:58:00 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7F83A2B87 for ; Mon, 5 Apr 2021 15:57:59 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id f16so14307385ljm.1 for ; Mon, 05 Apr 2021 15:57:59 -0700 (PDT) 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=DZ6ARyjTLwFnQUPV0visI6KnwvrH88wH3YCNA8JpTXI=; b=cFRVNS6l9t7Mt+hVcAA+yiOjs1P7VKfIyZ0CfajgMZ0F2+JX9io2Snih3/zCUx+jz2 gehgA4cWtGg8bq4i1PUmKbNaepRRYkMqwcoptPz5Ypuf2wnaaG01rDQSON60igFkXaAe Z6j4Ig8r4RETVVs6lZDe0G4+jni9u+bWJAPO7CEN6szyGy4El2yBIyvtSztis91X3kAz fHbHSalaHt+K5xsl8U9yN/m5dUtl+NEC4W2Ny2zFP+ybVt6sen1/9cos9LRBN8LZGGvN 0DqWc5qiaXn18FeFn9xpKA6klpvhP9/a87N5b+3+sHepbqb5SMNtE31h30ttMpPbOIAf MDMg== 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=DZ6ARyjTLwFnQUPV0visI6KnwvrH88wH3YCNA8JpTXI=; b=auMnw1+hK43aOZiughhLeHsxwunLuhJ7J/ulJsv+NKFXrphTxdouMDhIZU5e9xRDjq 4ScGr7VFBRE0CJWg5JKQPL9C36GPtbgxuUd+y49hyx23EJeBQr3jGha3F0dHhBdIslEK vqtrgANbQmNqPe+iHjoRh2RiJ+j11X7VCaWMHhDCK2d2uARhGWBuYC4fWPDMgH8xHFCN e756PswfueP3mP8HHsbQlonFn1NqXt1xICpDJCXzLmkgYGrp7GqJksqlbna2lP1lvv6L XE6H19TnmYJ84zmEO5n87iOIAZMi0TXZeR1zrvdbBv+QPoieF+iFN0ozE2eYEFeSVQo7 LALA== X-Gm-Message-State: AOAM531nDlCNIIaiVHO/m/1vebgYa6G5cFJE6vpkoQDawXmO7eahys8p pzS1RnsKUPZNBoVsg6kTJhddQU53AVBEewIXywDDOsk0QTqS+9gA1LIiIuJaPH/CDOgVyPIhZHF LPrtaNCOEddEhkA== X-Google-Smtp-Source: ABdhPJz0mOI7sSHiiJY1QPtR8jIjk7DKnYrxbRUC7MCgx8sXce6yFE+abdnO+8sYjolzEsZuSKK2Bk5WQpnoKZS7Fps= X-Received: by 2002:a2e:90c4:: with SMTP id o4mr16992575ljg.293.1617663476424; Mon, 05 Apr 2021 15:57:56 -0700 (PDT) MIME-Version: 1.0 References: <745359AE-98D7-4AC0-B088-E522E8CF3FFC@aueb.gr> In-Reply-To: <745359AE-98D7-4AC0-B088-E522E8CF3FFC@aueb.gr> From: Brian Campbell Date: Mon, 5 Apr 2021 16:57:30 -0600 Message-ID: To: Nikos Fotiou Cc: oauth Content-Type: multipart/alternative; boundary="000000000000e0faf705bf41a08c" Archived-At: Subject: Re: [OAUTH-WG] dpop terminogly X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 22:58:05 -0000 --000000000000e0faf705bf41a08c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nikos, The https://tools.ietf.org/html/draft-fett-oauth-dpop-04 draft you've referenced is several revisions out of date. Looking at https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ will show the current latest, which is currently https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-02.html. Some of that terminology has been cleaned up already. There are a couple places where payload could be used rather than body that I'll change in the next revision. I think that JWT header is probably more meaningful to most readers than JOSE. And while it is technically a JOSE header, it's also a JWS header, which is also a JWT header. This JWT is a JWS. Both have a header. The same header. On Sun, Apr 4, 2021 at 3:16 PM Nikos Fotiou wrote: > Hi I am wondering if the following terminology is more appropriate for th= e > DPoP draft (https://tools.ietf.org/html/draft-fett-oauth-dpop-04): > - Since a DPoP proof is a JWT encoded in a JWS may be it is better to say > "DPoP proof payload" instead of "DPoP proof body" (end of page 4). > - For the same reason use "JOSE header" instead of "JSON header" > (beginning of page 5) > - Moreover, here and there it is stated "the header of the JWT". AFAIU > JWTs do not have headers themselves but the header is part of the JWS/JWE > structure in which the JWT is encoded. So may be it is more appropriate t= o > say "the JOSE header" instead of "the header of the JWT". > > Best, > Nikos > > -- > Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou > Researcher - Mobile Multimedia Laboratory > Athens University of Economics and Business > https://mm.aueb.gr > > _______________________________________________ > 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._ --000000000000e0faf705bf41a08c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nikos,

The https://tools.iet= f.org/html/draft-fett-oauth-dpop-04 draft you've referenced is seve= ral revisions out of date. Looking at https://datatracker.ietf.org/doc/draft-ietf-= oauth-dpop/ will show the current latest, which is currently https://www= .ietf.org/archive/id/draft-ietf-oauth-dpop-02.html.

=
Some of that terminology has been cleaned up already. There are = a couple places where payload could be used rather than body that I'll = change in the next revision. I think that JWT header is probably more meani= ngful to most readers than JOSE. And while it is technically a JOSE header,= it's also a JWS header, which is also a JWT header. This JWT is a JWS.= Both have a header. The same header.


On Sun, Apr = 4, 2021 at 3:16 PM Nikos Fotiou <fotio= u@aueb.gr> wrote:
Hi I am wondering if the following terminology is more appropria= te for the DPoP draft (https://tools.ietf.org/ht= ml/draft-fett-oauth-dpop-04):
- Since a DPoP proof is a JWT encoded in a JWS may be it is better to say &= quot;DPoP proof payload" instead of "DPoP proof body" (end o= f page 4).
- For the same reason use "JOSE header" instead of "JSON hea= der" (beginning of page 5)
- Moreover, here and there it is stated "the header of the JWT". = AFAIU JWTs do not have headers themselves but the header is part of the JWS= /JWE structure in which the JWT is encoded. So may be it is more appropriat= e to say "the JOSE header" instead of "the header of the JWT= ".

Best,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https:/= /mm.aueb.gr

_______________________________________________
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. --000000000000e0faf705bf41a08c-- From nobody Tue Apr 6 01:59:45 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25713A17B4 for ; Tue, 6 Apr 2021 01:59:43 -0700 (PDT) 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, 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 yvbjJrd5J7Nu for ; Tue, 6 Apr 2021 01:59:38 -0700 (PDT) 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 685253A17B1 for ; Tue, 6 Apr 2021 01:59:38 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id c15so3616870ilj.1 for ; Tue, 06 Apr 2021 01:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=30eseHcdTQh7BVqsUhrDfYPetopNv2Ygk56KIOrxODw=; b=QpTMbmL+5/XwFuJtksx7wvnCZUXVQEm3Xn3N+YqDqa2Ax3oAL6kFJ1qKdiFAxvptjS V3amRHuVQoLxKlPFl2JQMpLSFyTLGXkk/jsVh7BD+fV6t0WpOXrobaQq/syFvU4sBxNO K0nzQJspGYqdwmi3mKgTgvmpzN++18IB2ENpcFfGTJroVE24M+jrwIM11U4HwVYT9OF4 /fEUeJvzlq/3E0IDul/ML25i3oLB+4e4SoKtZLKuHPpAtCYXJ8ww6H0QeH4e7sGGZpnO s+Vj+NR6YSTj/1ia3I1CFNFKk3t+ojkVc7v3J+yBztlkXsSBD83+L3tJ1IF/cwjwt3AB m4Yg== 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=30eseHcdTQh7BVqsUhrDfYPetopNv2Ygk56KIOrxODw=; b=Vnr1IO3Fub9zjjbpAZuLUgjg6vlpQTpU6v0AFMmuv9bTUrhXurF4m3a9wExymJplSD tuyk3dZEjgT9ITHT3uU/QoGQj/HWc16LyNaK16puK0cQOxLFKy+AOX5XDfFMDrqfpZCU EkWeDHofnzVHv55Q22/Y33B8xXGqnP9X6+Bw6SD76QUzRkAh7vURtnzvXGu2VUz1cqF+ nL4hpgpWeh40q2hEad6rw4OB90tImz2LQ249i5f+kciC54JB/reE2E+hKG/fIgxlwXXX NTjkYRu+R+Bz5/XX5w12nNrVW9oaQZPNS7zY0dqzNL618x/UE4zvhM6ZTDvqH6LB77XC kW5g== X-Gm-Message-State: AOAM531NE/W3maaVVoN+cyPDsKZr/WiyVSUN+lgjA9mpFB9VBBxkzlJX 0r3Lj9QGoZit1jufTBUoIFX0CYN76yMw2/iuZ+o= X-Google-Smtp-Source: ABdhPJwlVlLAGxrU3Zs0X/Ydd3EtZZYktrxKozyPxUQjqAHJEGk+55Ukf7GWD14QtjrbXrfpHnPBuD2bsac+92r9i9U= X-Received: by 2002:a05:6e02:cce:: with SMTP id c14mr2053089ilj.32.1617699576942; Tue, 06 Apr 2021 01:59:36 -0700 (PDT) MIME-Version: 1.0 References: <42E6041E-9F06-4276-A3D0-63C7FE18A335@aueb.gr> <057901d727f4$ebae4850$c30ad8f0$@auth0.com> In-Reply-To: <057901d727f4$ebae4850$c30ad8f0$@auth0.com> From: Thibault Normand Date: Tue, 6 Apr 2021 10:59:26 +0200 Message-ID: To: vittorio.bertocci=40auth0.com@dmarc.ietf.org Cc: Nikos Fotiou , oauth Content-Type: multipart/alternative; boundary="000000000000a3172905bf4a0874" Archived-At: Subject: Re: [OAUTH-WG] About JSON Web Token (JWT) Profile for OAuth 2.0 Access 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: Tue, 06 Apr 2021 08:59:44 -0000 --000000000000a3172905bf4a0874 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, As an implementor, I considered that JWT is a way to serialize token claims so for me - JWT Profile for OAuth 2.0 Access Tokens became Rich Token Profile for OAuth 2.0 Access Tokens. I have implemented different token encoders (JWT / CWT / PASETO / Macaroon) which are all finally just rich tokens (with claims) encoded using a defined transport format. Rich Tokens (authorization by value/claims) are the opposite of flat tokens (opaque tokens for authorization by reference). Regards, Le ven. 2 avr. 2021 =C3=A0 21:18, a =C3=A9crit : > Hi Nikos, > Thanks for looking into this! > The profile aims at reflecting currently adopted practice as much as it i= s > viable, and the overwhelming majority of the use cases involving access > tokens today relies on bearer tokens. > Note: although there's no practical difference between versions in the > matter you brought up here, in general I recommend referring to the lates= t > draft: we are currently on version 12 > (https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12). > > -----Original Message----- > From: OAuth On Behalf Of Nikos Fotiou > Sent: Thursday, April 1, 2021 12:11 PM > To: oauth > Subject: [OAUTH-WG] About JSON Web Token (JWT) Profile for OAuth 2.0 Acce= ss > Tokens > > Hi, > By reading this draft > (https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-05) I got > the > impression that it implies using JWTs as bearer tokens, e.g., it does > consider any of the semantics defined in RFC7800. Is this correct? If yes > what was the rational behind this design choice? > > Thanks a lot, > Nikos > > -- > Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile > Multimedia Laboratory Athens University of Economics and Business > https://mm.aueb.gr > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Thibault Normand "Il existe moins bien mais c'est plus cher !" http://www.zenithar.org --000000000000a3172905bf4a0874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

As an implementor, I = considered that JWT is a way to serialize token claims so for me - JWT Prof= ile for OAuth 2.0 Access Tokens became Rich Token Profile for OAuth 2.0 Acc= ess Tokens.
I have implemented different token encoders (JWT= / CWT / PASETO / Macaroon) which are all finally just rich tokens (with cl= aims) encoded using a defined transport format.

Rich Tokens (authorization by value/claims) are the opposite of flat toke= ns (opaque tokens for authorization by reference).

Regards,

Le=C2=A0ven. 2 avr. 2021 =C3=A0=C2=A021:18, <vittorio= .bertocci=3D40auth0.com@dmarc= .ietf.org> a =C3=A9crit=C2=A0:
Hi Nikos,
Thanks for looking into this!
The profile aims at reflecting currently adopted practice as much as it is<= br> viable, and the overwhelming majority of the use cases involving access
tokens today relies on bearer tokens.
Note: although there's no practical difference between versions in the<= br> matter you brought up here, in general I recommend referring to the latest<= br> draft: we are currently on version 12
(https://tools.ietf.org/html/draft-i= etf-oauth-access-token-jwt-12).

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Nikos Fotiou
Sent: Thursday, April 1, 2021 12:11 PM
To: oauth <oauth@iet= f.org>
Subject: [OAUTH-WG] About JSON Web Token (JWT) Profile for OAuth 2.0 Access=
Tokens

Hi,
By reading this draft
(https://tools.ietf.org/html/draft-i= etf-oauth-access-token-jwt-05) I got the
impression that it implies using JWTs as bearer tokens, e.g., it does
consider any of the semantics defined in RFC7800. Is this correct? If yes what was the rational behind this design choice?

Thanks a lot,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobil= e
Multimedia Laboratory Athens University of Economics and Business
https:/= /mm.aueb.gr


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


--
Thibault Normand
"Il existe moins bien mais c'e= st plus cher !"
http://www.zenithar.org
--000000000000a3172905bf4a0874-- From nobody Tue Apr 6 05:19:34 2021 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 3138B3A1F07; Tue, 6 Apr 2021 05:19:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <161771156410.10254.11880146751203807355@ietfa.amsl.com> Date: Tue, 06 Apr 2021 05:19:24 -0700 Archived-At: Subject: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwsreq-32: (with 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, 06 Apr 2021 12:19:25 -0000 Lars Eggert has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection 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-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.2, paragraph 5, comment: > The entire Request URI MUST NOT exceed 512 ASCII characters. There > are three reasons for this restriction. > > 1. Many phones in the market as of this writing still do not accept > large payloads. The restriction is typically either 512 or 1024 > ASCII characters. > > 2. On a slow connection such as 2G mobile connection, a large URL > would cause the slow response and therefore the use of such is > not advisable from the user experience point of view. What is the third reason? Also, 512 bytes at 2G speeds (~40Kb/s) take ~100ms to transmit; it's not clear that larger payloads would therefore be so much worse, given that the 2G latencies are probably the overriding issue here. Would a SHOULD NOT suffice? ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 4, paragraph 10, nit: - Signing it with the "RS256" algorithm results in this Request Object + Signing it with the "RS256" algorithm [RFC7518] results in this Request Object + ++++++++++ From nobody Tue Apr 6 05:48:21 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF63A21D4; Tue, 6 Apr 2021 05:48:10 -0700 (PDT) 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=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od06BtGfWiaO; Tue, 6 Apr 2021 05:48:05 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E913A21B1; Tue, 6 Apr 2021 05:47:31 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:68eb:fc77:3b2:d84e] (unknown [IPv6:2a00:ac00:4000:400:68eb:fc77:3b2:d84e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 931E1600314; Tue, 6 Apr 2021 15:47:22 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1617713242; bh=mDcZ+aUWQbIEn4JwL9dZpLz4A6eF/yHQHJpID9pkAIo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Px6O184eJf6aK5+96qMxZcOOePal5GfwJlPk1VOpEgDnxVyJreE7WqMS/j3EpJ6Qq furp+TN06+ZNJguaTLGj7kLA5f/QKS35IQ1to33M89AJD9tipU5ZC2cFQSbBGfKvaf 7D9ic+lsqsHwzOKr/km1NZl5C2Fm2g6848e3ZEyg= From: Lars Eggert Message-Id: <991C08E0-DB8A-46BC-ADA1-77A6DC62B18B@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_96A42F2F-6ED9-49D4-A62E-B6FCD32F19EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 6 Apr 2021 15:47:22 +0300 In-Reply-To: <161269010849.30071.8142300590273121238@ietfa.amsl.com> Cc: General Area Review Team , last-call@ietf.org, oauth@ietf.org, draft-ietf-oauth-access-token-jwt.all@ietf.org To: Roni Even References: <161269010849.30071.8142300590273121238@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-MailScanner-ID: 931E1600314.AF1AF X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [OAUTH-WG] [Last-Call] Genart last call review of draft-ietf-oauth-access-token-jwt-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 12:48:17 -0000 --Apple-Mail=_96A42F2F-6ED9-49D4-A62E-B6FCD32F19EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Roni, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-2-7, at 11:28, Roni Even via Datatracker = wrote: >=20 > Reviewer: Roni Even > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-oauth-access-token-jwt-?? > Reviewer: Roni Even > Review Date: 2021-02-07 > IETF LC End Date: 2021-02-09 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > The document is ready for publication as a standard track RFC with nit >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: > In section 3 the get example has client_id as s6BhdRkqt3 and the = claims has s6BhdRkqt3_ >=20 >=20 >=20 >=20 >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_96A42F2F-6ED9-49D4-A62E-B6FCD32F19EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmBsWFoACgkQVLXDCb9w wVeR+xAAtfcff0p3zV3mA3JEGPscEpNw/Hxcx5FFmbMDOSJDIlNdP5myBTrCZif8 8nZGciL7sSFtLT9Z9l4pemSjgOkIdk+xEmsCGTaS00MKoquy4Lvx+33c6vSRgJV9 b8DknzPtYNW5YYRscbruPPG/t19AqcMCDEBnkwqjYJv3zFipneUwsoMoYGUt0Jxa CF6AFAuX9VheGYpBa0IiPbMxvBrI9wO0XYvhV1s9IiPdEUmTqOTRNU4E315TdMqB zPqTSEvGkhlsJX6t5FWwkf65IYfK6TINiFiQsy/HV4ZL8Ce8HCLFpU3ppxtwF8Wd lxO9yAAy3u7ivqKHljBM6Ek8Fzm94ynQalcIzE3FzntO2blEemdlz9GXXOJuFEwG b81vEHeatOtcaWknq/wesxfZS9Z6UVHGjRPhnDwWW8g3hTXSYyeOvgkBY0lBQN85 cJ70WDJ0CdqqsG4tDWxmixm0lKlYl1nwo1PyHE0INLVoXdfYR/CdQ9qQYRAM5ENd X56T7Mb8qIBDK0mXAa0vNhTKClQmXMrttceFSMm271qaGSkVl0yrdsRR+02nt7Qx 4UpAqDXEqkbl+uzzt7djv92gLp9O1+xKArN5hFfxYQUu4uEZNkmdJCHg7T/As8W8 ggwQFttZcOdGDaKsW4fw2cespsqeuJFatpcKWyGrC9g3SS8bCbM= =QOaA -----END PGP SIGNATURE----- --Apple-Mail=_96A42F2F-6ED9-49D4-A62E-B6FCD32F19EA-- From nobody Tue Apr 6 05:56:00 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29AA3A200E; Tue, 6 Apr 2021 05:55:56 -0700 (PDT) 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=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY91z0f_luhP; Tue, 6 Apr 2021 05:55:52 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5833A25D7; Tue, 6 Apr 2021 05:54:13 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:68eb:fc77:3b2:d84e] (unknown [IPv6:2a00:ac00:4000:400:68eb:fc77:3b2:d84e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 9D49B600314; Tue, 6 Apr 2021 15:54:04 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1617713644; bh=+CVqj0tecUHUKknkCjqCdBw0K+Ofa6NpfRflas/gI1k=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=wQ0iiDU2ayjjXeZU91kvsl6iMSa0lBK9E6suHTIzsG9UQwc9HM4iixAIiUJzMbbCD TgR/cncuxqXN7Pn1UC1E6VaxpBJHE1aRk8ymlho/ThRn3XeGbjvWO3S/R7BPMNNxSO 8WI+fmZ+m7PItfugi9bqS9He7aDCs9oyXE24xmXQ= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FA1A2ABA-A85D-426B-9174-7450529C25E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 6 Apr 2021 15:54:04 +0300 In-Reply-To: <160097760981.16330.7303031575099438606@ietfa.amsl.com> Cc: General Area Review Team , last-call@ietf.org, oauth@ietf.org, draft-ietf-oauth-jwsreq.all@ietf.org To: Joel Halpern References: <160097760981.16330.7303031575099438606@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-MailScanner-ID: 9D49B600314.A19F5 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [OAUTH-WG] [Last-Call] Genart last call review of draft-ietf-oauth-jwsreq-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, 06 Apr 2021 12:55:57 -0000 --Apple-Mail=_FA1A2ABA-A85D-426B-9174-7450529C25E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joel, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2020-9-24, at 23:00, Joel Halpern via Datatracker = wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-oauth-jwsreq-30 > Reviewer: Joel Halpern > Review Date: 2020-09-24 > IETF LC End Date: 2020-10-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This document is ready for publication as a Proposed Standard >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_FA1A2ABA-A85D-426B-9174-7450529C25E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmBsWewACgkQVLXDCb9w wVc0pBAAjSMANovxwKH+UmQnFT5nKJoYijDkb/Z8F+InmANQeDv89LAmkw8I49Y7 4SrUt4tElsuwSHFg5AW1FNSM9X/BcgRt//PyC1yGNydG9gPn5hrKHbwp9fiIBhoZ mjADfuOFbIO6myD2ZRazO1kV+dc6+8iiCjDdwVYHyd3ra6Bjx23gJTWPmI3iEHNm nzcpE1dVLuxb+UlECAlYPTABs8xmPL6mkJTR6IyQVZXXXiRJFCPBkF7y2zbbWkNG Jv0/Bx1mk2edQWrtdKZ3K/JhZXmwXwn6CL8g5XCv9mITYXgHqhdiFSjS445Ceq3d xLe4Is6U8b91Wt3g+ThJcAXlGGLejcZwFiAZMxTeH5Gk5HbbUR06G/BAtl+f4suN CK9l/yy5D3YTyZkzlBGkXXjPwZeB9F1YpR8jeMV7c1/u9AfXRNT13LxOb8mUTGXN TKCAnurQR/b0oE39bLlAieq4oqZRRfvj297G0EgxKxj3bWwHgza18A98qXezo3xM 44MB5Xkr5a9iYWJeVwjGQpJRynrhyIYU206NspykMEgzUo+8a9S105Z7T73koAza GJ5PkwfGU4k6P9SuqJZdMEK8+e8UKW8MF/2mHe/EJ3SMNWRk37GueP5/cteNNk5h Jk67qekrrLxY1xBwbJMDCyFJ40QegRTlUKzlhWfxCaYIUw+wvKA= =uKjO -----END PGP SIGNATURE----- --Apple-Mail=_FA1A2ABA-A85D-426B-9174-7450529C25E7-- From nobody Tue Apr 6 06:06:02 2021 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 4551E3A2073; Tue, 6 Apr 2021 06:06:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161771436122.1506.973742618731100764@ietfa.amsl.com> Date: Tue, 06 Apr 2021 06:06:01 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.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, 06 Apr 2021 13:06:01 -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-17.txt Pages : 52 Date : 2021-04-06 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 is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17 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 Apr 6 06:15:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAA33A20C1 for ; Tue, 6 Apr 2021 06:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 Ix6aiRmZ55iO for ; Tue, 6 Apr 2021 06:15:38 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E72C3A20C6 for ; Tue, 6 Apr 2021 06:15:38 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 3C9C523B1E for ; Tue, 6 Apr 2021 13:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1617714931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cy16hMC/AjxokMrr5U7HRtD4Hgr7Te6JLG5WTReKdl8=; b=E04M41/cFDGVOm/bOBnZ0wwwGzswhNFWLN49DMnGN6sdaoAOcVCH334ofpDdfm8FgnQesX uUhpSXwjYG3DZNqhvIqcLny44xOf1StCBD2F1hjhDnAYkhPLl25eyom4XP3zhNqpRGDaTd ZLoWXAgZ8a5MS4YapUw6NN+4exDTras= To: oauth@ietf.org References: <161771436122.1506.973742618731100764@ietfa.amsl.com> From: Daniel Fett Message-ID: <63c57751-ff04-4e75-a74d-c4ba1105fb56@danielfett.de> Date: Tue, 6 Apr 2021 15:15:30 +0200 MIME-Version: 1.0 In-Reply-To: <161771436122.1506.973742618731100764@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------C96EEBFC76BA739C1E5D89F8" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1617714931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cy16hMC/AjxokMrr5U7HRtD4Hgr7Te6JLG5WTReKdl8=; b=s0u+Uv48y8LTJ6AQ9CtpBLgrjGO3QYN2Vkw9t6kqpp8UbQmuKY6Mgx4AyiulemZsxoC7zb /+IoquCPp08Uc6AmGqmhMvYTmixMotxacf+Da595TaF5JiT53o6y9EGahQ+ebZaTMQW6MG RDJaCevlxVX/5hp3ls11KarVsIHOl+E= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1617714931; a=rsa-sha256; cv=none; b=Z1PDhLVsRRSByqYDO06q3rJVzAn29UsGiArB6kwvO2KCO7vF3M1KQMnpqkbZAAgVwIoG+a qMHm+D68Tv1CCAC9d4CfI4ZZFcxLJsxytXnBVZcaUPFtBDsXJTqELP9lPswqxPxJCfDl3M /SSz/R2hVqNlSCztOX8FLPU7Ya4sC9U= 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] I-D Action: draft-ietf-oauth-security-topics-17.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, 06 Apr 2021 13:15:44 -0000 This is a multi-part message in MIME format. --------------C96EEBFC76BA739C1E5D89F8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, this version most importantly updates the recommendations for Mix-Up mitigation, building upon https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The description of Mix-Up attacks has also been improved. Smaller changes:    * Make the use of metadata RECOMMENDED for both servers and clients    * Make announcing PKCE support in metadata the RECOMMENDED way (before: either metadata or deployment-specific way)    * AS also MUST NOT expose open redirectors.    * Mention that attackers can collaborate.    * Make HTTPS mandatory for most redirect URIs. I'll present more details in the interim meeting next monday. As always, your feedback is appreciated. We hope that we can proceed to a WGLC for this document soon. -Daniel Am 06.04.21 um 15:06 schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-17.txt > Pages : 52 > Date : 2021-04-06 > > 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 is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17 > > > 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 -- https://danielfett.de --------------C96EEBFC76BA739C1E5D89F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi all,

this version most importantly updates the recommendations for Mix-Up mitigation, building upon https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The description of Mix-Up attacks has also been improved.

Smaller changes:

   * Make the use of metadata RECOMMENDED for both servers and clients
   * Make announcing PKCE support in metadata the RECOMMENDED way (before: either metadata or deployment-specific way)
   * AS also MUST NOT expose open redirectors.
   * Mention that attackers can collaborate.
   * Make HTTPS mandatory for most redirect URIs.

I'll present more details in the interim meeting next monday.

As always, your feedback is appreciated. We hope that we can proceed to a WGLC for this document soon.

-Daniel

Am 06.04.21 um 15:06 schrieb internet-drafts@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-17.txt
	Pages           : 52
	Date            : 2021-04-06

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 is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html

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


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



-- 
https://danielfett.de
--------------C96EEBFC76BA739C1E5D89F8-- From nobody Tue Apr 6 07:49:24 2021 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 3186C3A2421; Tue, 6 Apr 2021 07:49:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <161772055811.5316.2684855466711644353@ietfa.amsl.com> Date: Tue, 06 Apr 2021 07:49:18 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-jwsreq-32=3A_=28with_COMMENT=29?= 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, 06 Apr 2021 14:49:19 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection 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-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Not too many differences since my review on the -26 (hence I reviewed mainly the diff). Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1 -- Is it normal that the abstract has a) and b) while the introduction has a), b), and c) ? -- Section 5.2 -- I see that "Many phones in the market as of this writing" is still in the text... Does this assertion still hold in 2021 ? Is it backed by some references ? From nobody Tue Apr 6 11:39:06 2021 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 C59133A2BD3; Tue, 6 Apr 2021 11:39:04 -0700 (PDT) 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-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161773434423.7915.18084233237302538767@ietfa.amsl.com> Date: Tue, 06 Apr 2021 11:39:04 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with 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, 06 Apr 2021 18:39:05 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection 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-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the new security considerations text in Sections 10.7 and 10.8 since I last reviewed; it does a great job capturing my comments (and the current deployed reality). Thanks also to Watson Ladd for the latest secdir review and the authors for their responses to it. Section 6.2 The Authorization Server MUST validate the signature of the JSON Web Signature [RFC7515] signed Request Object. The signature MUST be validated using a key associated with the client and the algorithm specified in the "alg" Header Parameter. [...] The last version I reviewed had some language tying the algorithm used for verification back to a registration (and I commented that perhaps a registration might not always exist). This language seems to set the recipient up to blindly use the "alg" header parameter, even if it's "none", and we should probably have some hedging language here (I see we do have language elsewhere that bans "none" specifically)... If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be performed, as specified in Sections 3.1 and 3.2 of [RFC8725]. ... and maybe that would just take the form of swapping the order of these two sentences, now that I keep reading. Section 10.2 Do any of the procedures listed for steps (c) and/or (d) need to be performed in step (e) as well? (In particular, the requirements on the returned URI seem like they would still apply, and possibly the need for client authentication. Section 10.3 Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my previous review suggested that there might be value in future work that specifies the linkage across these endpoints to try to address the cross-phase attacks discussed in [FETT]. However, the paragraph that I had commented on (that mentions "an extension specification") has since been removed, and I failed to track down why just from a quick mailarchive search. There may well have been a good reason for removing it (and the reference to [FETT]), so please help refresh my memory if that's the case. Section 10.4 The introduction of "request_uri" introduces several attack possibilities. Consult the security considerations in Section 7 of RFC3986 [RFC3986] for more information regarding risks associated with URIs. My previous comments had mentioned that because of time skew the dereferenced request URI might actually have the contents of a different request than the one intended, and Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ pointed out that OIDC actually does use a nonce that would prevent such an occurrence. Hopefully Nat did get a chance to think about whether there was anything else that we should mention in this document, on this topic. ("There isn't anything else to mention here" is a fine answer; I just wanted to close the loop on that thread, since I didn't find one in the mail archive.) Section 11.1 nit: s/TFP/trusted third-party service/ (multiple instances), since we stopped using "Trust Framework Provider" in the main body. Sction 14.1 Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 -- thank you for referencing it as BCP 195! I expect the RFC Editor will catch the new reference if you don't want to figure out how to notate it properly. From nobody Tue Apr 6 12:12:47 2021 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 C25DA3A2CF9; Tue, 6 Apr 2021 12:12:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <161773636523.29106.4072676907227033622@ietfa.amsl.com> Date: Tue, 06 Apr 2021 12:12:45 -0700 Archived-At: Subject: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-jwsreq-32: (with 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, 06 Apr 2021 19:12:46 -0000 Martin Duke has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection 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-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- After reading Sec 10.5, I was a little unclear how the client and auth server necessarily achieve interoperability, but I think it's just an editorial fix. If the server advertises that a signed object is required, then it cannot communicate with a client that does not support the extension. But if the object_required metadata is missing, then what is the metadata that tells the client to use a signed object if it can? IIUC the answer is that the server metadata includes the request_object_signing_alg_values_supported and/or request_object_encryption_alg_values_supported parameter in the metadata. It might be helpful to spell that out here. Is this correct? From nobody Tue Apr 6 17:42:56 2021 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 84A103A37E0; Tue, 6 Apr 2021 17:42:51 -0700 (PDT) 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-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes Tschofenig , hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161775617097.3695.11007880898305683894@ietfa.amsl.com> Date: Tue, 06 Apr 2021 17:42:51 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 00:42:52 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-access-token-jwt-12: No Objection 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-access-token-jwt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.1 JWT access tokens MUST include this media type in the "typ" header parameter to explicitly declare that the JWT represents an access token complying with this profile. Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix be omitted. [...] Just to check: is the reason this is only RECOMMENDED just because that's the requirement level that RFC 7515 used? AFAIK we can be more stringent here and just always require it to appear as "at+jwt", to simplify processing, if that is compatible with existing deployments (or we are willing to declare them non-conformant). (Section 4 would change accordingly if this text changes.) Section 2.2 Why does "iat" get an extra sentence describing the claim in addition to "as defined in [reference]" but not iss/exp/jti/etc.? Section 2.2.1 response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token, or exchanging one access token for another via [RFC8693]). nit: RFC 8693 doesn't effectuate token exchange; the protocol it specifies does. So "via the token exchange mechanism of [RFC8693]" or "via [RFC8693] procedures" or such seems more grammatically correct. Section 2.2.2 Any additional identity attribute whose semantic is well described by an entry in the JSON Web Token (JWT) IANA registry introduced in [RFC7519] SHOULD be encoded using the corresponding claim name. Note that the JWT IANA registry includes the claims found in Section 5.1 of [OpenID.Core]. I assume that ths "SHOULD be encoded using the corresponding claim name" just refers to the claim name used, and is not advising that all identity attributes be always included. If so, perhaps a few more words would help clarify, such as "if that attribute is to be included in the JWT access token" at the end of the sentence. Semantically it would also work to start the sentence with "when being included", but IMO that would detract from the focus of the sentence. Authorization servers including resource owner attributes in JWT access tokens should exercise care and verify that all privacy requirements are met, as discussed in Section 6. I'd suggest to s/should/need to/. Section 2.2.3 All the individual scope strings in the "scope" claim MUST have meaning for the resources indicated in the "aud" claim. See Section 5 for more considerations about the relationship between scope strings and resources indicated by the "aud" claim. ["aud" vs "resource?] Section 2.2.3.1 An authorization server wanting to include such attributes in a JWT access token SHOULD use as claim types the "groups","roles" and "entitlements" attributes of the "User" resource schema defined by Section 4.1.2 of [RFC7643]). I do see that we go on to clarify that we register JWT claims for "groups", "roles", and "entitlements" and recommend encoding guidance for the values of these claims, but I'm still stumbling over the phrase "claim types" here. What is a "claim type"? I suspect from context that it is meant to refer to a "claim name" as recorded in the JWT Claims registry, but I'm not 100% certain. It might also help readability to split this into two sentences: "use as claims [list]. The semantic contents of these claims are desribed in their definitions as attributes of [...]", since the current wording has me trying to use "attributes" in a JWT context, but it's intended to clarify the RFC 7643 reference. Authorization servers SHOULD encode the corresponding claim values according to the guidance defined in [RFC7643]. In particular, a Why is this only a "SHOULD"? We are defining these JWT claims, so we can nail down exactly what they contain. non-normative example of "groups" attribute can be found in Section 8.2 of [RFC7643]. No specific vocabulary is provided for "roles" and "entitlements". Similarly, we may want to be more concrete about "roles" and "entitlements" if we don't already later in this document. Section 3 This section is titled "Requesting a JWT Access Token" but the contents don't really seem to provide a procedure for specifically requesting a JWT access token. (nit) the "exp" claim in the example is from 2018; we might want to use something a little more "current" to time of actual publication. Is the provided "state" in the example sufficiently long to provide CSRF protection (as is recommended by RFC 6749)? Section 4 Authorization servers SHOULD use OAuth 2.0 Authorization Server Metadata [RFC8414] to advertise to resource servers their signing keys via "jwks_uri" and what "iss" claim value to expect via the issuer metadata value. Alternatively, authorization servers (nit) please use consistent formatting and terminology for the "jwks_uri" and "issuer" metadata values. o If the JWT access token is encrypted, decrypt it using the keys and algorithms that the resource server specified during registration. If encryption was negotiated with the authorization server at registration time and the incoming JWT access token is not encrypted, the resource server SHOULD reject it. Why is this only a SHOULD and not a MUST? o The resource server MUST validate the signature of all incoming JWT access tokens according to [RFC7515] using the algorithm specified in the JWT alg Header Parameter. The resource server MUST reject any JWT in which the value of "alg" is "none". The resource server MUST use the keys provided by the authorization server. Would the algorithm verification of Sections 3.1 and 3.2 of RFC 8725 be relevant here? Also, might local policy decide in the future to blanket reject (then-)weak algorithms that are not "none"? o The current time MUST be before the time represented by the "exp" claim. RFC 7519 talk about an optional small leeway, "usually no more than a few minutes" to account for clock skew; are we taking a stance one way or the other on such leeway? The resource server MUST handle errors as described in Section 3.1 of [RFC6750]. [...] I'm not sure that I saw anything before now in this document that limits its applicability to bearer tokens only. Do we need to start now? Section 5 Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. For example, if the authorization server elects to use the client_id as the "sub" value for access tokens issued client credentials grant, the authorization server should prevent clients to nit: missing word (maybe "using the client credentials grant"?) register an arbitrary client_id value, as this would allow malicious nit: s/to register/from registering/ To preventing cross-JWT confusion, authorization servers MUST use a nit: s/preventing/prevent/ Authorization servers should use particular care when handling requests that might lead to ambiguous authorization grants. For example: if a request includes multiple resource indicators, the authorization server should ensure that each scope string included in the resulting JWT access token, if any, can be unambiguously correlated to a specific resource among the ones listed in the "aud" claim. The details on how to recognize and mitigate this and other ambiguous situations is highly scenario-dependent, hence out of scope for this profile. Only using single-valued "aud" would also help prevent this kind of mix-up, right? Do we have a recommendation for single-valued "aud" in one of the BCPs that we could point to? Authorization servers should not rely on the use of different keys for signing OpenID Connect ID Tokens and JWT tokens as a method to nit: maybe s/should not/cannot/, since this is just a statement of fact? Section 6 As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek inside the token claims collection. (nit?) "of unencrypted tokens"? token is visible to the client. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. I suggest s/should/needs to/. In every scenario, the content of the JWT access token will eventually be accessible to the resource server. It's important to evaluate whether the resource server gained the proper entitlement to have access to any content received in form of claims, for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on. I feel like it might be helpful to call out here that claims like those including information about RO authentication (Section 2.2.1), identity claims (Section 2.2.2), and authorization claims (Section 2.2.3) are ones that not all RSes should be entitled to access. I'm not sure about the best way to indicate this, but perhaps another sentence at the end about "For example, a user might not wish to consent to granting a given RS information about any of the non-mandatory claims enumerated in Section 2.2 (and subsections)" would help. Section 8.1 URLs for the OIDC documents would be helpful. I think RFC 7523 does not need to be normative. Section 8.2 Please include the draft name for [OAuth2.Security.BestPractices] (I assume it's draft-ietf-oauth-security-topics). We have a "MUST handle errors as described in Section 3.1 of [RFC6750]" which would make RFC 6750 a normative reference (but one of my comments suggests that we may not want to limit ourselves to just those procedures). From nobody Wed Apr 7 03:28:40 2021 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 C083E3A163F; Wed, 7 Apr 2021 03:28:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Francesca Palombini Message-ID: <161779131466.27557.9529080709711615188@ietfa.amsl.com> Date: Wed, 07 Apr 2021 03:28:34 -0700 Archived-At: Subject: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 10:28:35 -0000 Francesca Palombini has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection 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-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure behavior should be defined at the AS. Francesca 1. ----- A Request Object (Section 2.1) has the "mime-type" "application/ FP: Please use "media type" instead of "mime-type" and reference https://tools.ietf.org/html/rfc6838 2. ----- The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes the extension FP: This example is the first time "base64url" appears in the document. I think it would make sense to mention that base64url is used when JWT is introduced, for example in the first paragraph of section 4. 3. ----- If decryption fails, the Authorization Server MUST return an "invalid_request_object" error. ... If signature validation fails, the Authorization Server MUST return an "invalid_request_object" error. ... If the validation fails, then the Authorization Server MUST return an error as specified in OAuth 2.0 [RFC6749]. FP: very minor, but I suggests you add "to the client, in response to the request defined in 5.2.2. of this specification". The reason is that the doc specifies that the AS might be having other exchanges (to fetch the Request Object) at the same time, and it can't hurt to be precise. Also regarding the reference to RFC 6749 - can you add a specific section to reference? 4. ----- specified in the "alg" Header Parameter. If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be ... same parameter is provided in the query parameter. The Client ID values in the "client_id" request parameter and in the Request Object "client_id" claim MUST be identical. The Authorization Server then FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then? Same comment "... MUST be identical" - is any error returned if it's not? 5. ----- location, (b) check the content type of the response is "application/ FP: For consistency, please change "content type" to "media type". From nobody Wed Apr 7 13:07:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C313A27AB for ; Wed, 7 Apr 2021 13:07:10 -0700 (PDT) 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKNUEGWtuALq for ; Wed, 7 Apr 2021 13:07:06 -0700 (PDT) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B603A27AA for ; Wed, 7 Apr 2021 13:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1617826023; bh=FWl8ap99B2f1gwrC6r1DPyLbKr0vZop6mhjMLdqTLGc=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=p3EDqK4i36ByOUWYvdZhk0gfXUwFk1WRxoX3lwvdusEReea21o4TRJVPRV6y0Rs/KAzau+annLWwWMlBbhpF0l4+P6bpTBU0W9+RPI316pn/y3hy5LsNLI7PM69dnNc1I/lWIhD9oHeQ77cEq+kmTGZCXZdg460AXdhHCprvteKmsNBwjmSdcov3dEEwfvQcshEsX4sbpJ9JTlaObAjOigHdVOr2Xb/DtTIGFDC9IEXUnO2Nfv0Kyu+0eUJtMQVxm8iAujARBP6Q7X/QxaIModpLWYGjgGp6fzaeey1ToSircnwmQ0Jv/zOvrMR+uq916ZJhLeCzFC3A8xAkGoRZIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1617826023; bh=iC/EyPZNLqhXLvn4TloINTBUnHq3V+ATyepXlIALFNz=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=Hrb7XQMEjLfcGSHcWh1BsP1qalYdUUJXeV2rrawZjXbvXMLj9a2JFWEWzxPUp8WgViVvRH5a3okjtSNowGdmXSUx/B9MXO5/U+/6AhlKnwiUEvOhB9bfJ2hKE676hZ54ElRJ0z/9XN3Pj25zf1FA/M27fxI19GhYCEBK50DGB2X0JG0ACiI6/PmxqtRk7wh+Qd2FiJqGBOiC1U2yzcoAAWiii7V8/d8nOvlDOU63WDL9NpSz1x0o0n9c2iEWwnIFwlW007tB2yqBVNpllMnDPW0Aifpz8SphS2s99C7mp0yScKG7jBuiK6qViWI5OhLaUDZjr4iUSTgbchHalp/ZDA== X-YMail-OSG: QI_yvi4VM1neh4s3yvU_gxBf7DqFhawBQaup4_geODX14jFjfkkFo8TQXT2004m TSs3IMwDzw95W40KY7xo0sZHUAI9YT03_xkWKxvQsDRcCvoOw7Pgcw5xjo11kr31IhS9ZyOj2VWB cnSkxKe75SzhqxEYyLR.2mv8PUA0d7jy3yUFgqd3wcScBliNgYALHr8Fu40irunNUrXBNwyEtRRp eeI1X5Jdc5HQNI4dKjYt6ALgT8Eryc2ohK3n_t2Xao5TC1NdeqKI4z7NCrgbRaxQ92UoVwSpd1nW .HSYrnp7APZ.mxD6RRN04PssdplVxiJx8MpiDEzrJRF_44VCvXp6SlVZFyl293OAEbA2nGxWmBzI cW8YSZQzu9PIF4jLJR2om3hRKYgXtqoCyL7g2BGM3c4EQ3X__oTISwh2IUT36fTLsTVXltp5pc3r g9Pp.uX1UZddsbmZMuwc0WPQIL2jxppBF02m_T335jyu06bAtHN3r9iqYl.ndATX.mHZ9YPR8_.E BF.qJxxx0zqvMEsjQ9fe7QVAj7.4PZX25EES.lS.IaOIzz7ucC5ebcBVxAIV60sD1cdYk7rwTRNS Qcm7.TYpPL.HdqVTeOaEIRf9am755R2n6XExk7t6hrh4VoP6jSk19EYD1meT0DO5wIB8cV0Ftb.. Vlr7ekDHWQmvdM3hafhFdffdScm0F5XUj.NYSI1RCdNXYJdgaff7AMatp2ZnHdNmwxY__HwrXe8q lO3b5QzYvcj.F_HPQQkSwQQy9Z8vvhw1pakHRhiEQuDRPHiqzws5Xx9I1v2FOQVornSZNUMd4mBI EV8Qg8UPLeHKdzBhA60qe3yR3.DBu38dXNbNErPN8hrAV0PRpCCztdv0g0vbXY8.c6AtodXGzZrz TaUoOXH8fgyEimsFUQ8ty7qcc9d9.J0tFe41pOrfobZMOf6JfuYb5P8KvqIBf2z263ahn0pAAamr exYLqFK8D3OJ0sdm5Tm37QkbSKP04w_EXEL.9YFlmniYcSl0fe4cIaT3E8cs91p0LvFu.bnO5yrY z_w6dcbRVDzMCdftCLWkVKWDHcbL8w7qyAiW3D0Bh.DW5aAE6r_o2AS57IJSXVSb6isFvQsApKno SZ4.pksirhWn1ZsnSi8E.3wHTDUYxfAaJzrgTDrjwwQ4GbEr0DDu8LkvzpsUlUYgrfqoLHBxTrx4 I94a023pOb1_aBfupYMEvcoSQ4Jy5NH37F2Vi_jwCV.4y3dXzPCWuutq9swjwJ_YkqRaKUGXUYg7 xUQp_HTWha_n5WvKFkR7t3pl7IVKcdS9MtZuJmM7k9T_ng.htenYpBEH_qhc0ukhyzsnkBzG7r_j 2mtfh.XhJf7T.C0b7LXTFlRK2uTcsZY12_nT_ebPaR3bjbw63dmgIes41lRHie2cRgLJ3Yg2n8aN 3UgIVA.xetoTNJfZ0Ve01mZDLJpG1jl8MgCillhxp4MutLMpJ1N63Vge6BPyMzki5Htk8vFsdyfz IqX1VB0GQwJ4g2miTqwuf6CNci9NzAoKEX0Y9x47JGS_4zA6.8vu9k2iKF7YIkohVKOLLiOr7_Ee mCsk3nn8V1.jSdKl3ot5GorUX3Cl29sMYQ7VdRI8kldjsg5IRyDKboOSl9xsxMQSWRffUUAB.rxv 7HkIJlleNZv6eq7xpDlvrLHZfN5jqXQDTax0QWwXhb9JIGaTfccZJLReIlF6sXtFZue0gNKiEKzd FOHmWKuPmpcwPHK6plm5i4MKjjJhZYnJwwJzuwwwU0sxN80bWt4Mgm2XzBaH5qF7zt312.XkgpYI Bw83ZF.zhZ0CR4WvjPkWt59CFLTK1MlICvsnQpYv0d9y2rUDUBzkMNYM9DpD04u0u0BVzHy9L7sH uLLlqCSmu.I48HzweSK7jHGSV4oFkh2IZjNo_p9XLy1s46LsJ_ep2a5VRQD_LWI4QCTWumhV2gkS hc49587f5bzxS825YnSCVO4LL1VjbDgViOl7JIp9YT2WVXWp4_bXIti35CODQXKi7oezODWv.nUG z0HwbLSD1bNKPvVFc5FcglIogjF0qggk.ObULsrRzpY.EkaPFULdNvMFs4UoJ_OBqD6bmbcYMNSm A4RkF51jgL0s99lOA.D1jZ86Vj6NrvuGQ9zuEyGXoi9sdnaW7plDOEN.JJ0Twmgvv4BpUZ6vfs1O 28i4UFv8tnFUr6EHKKzLGZtW2J_EFWmGSUrXxUmg5zXEn7Cf7r.9w_DtADPI1CuqEtkaPSfF5kSS x5H5SFVivIDRNe.JegdlYb9MXu9BWhDWw5C5wJ24bQ0nk2ue6TSR.X4ZrMJ.aeotVJsGHL1pGnK3 9baKLm80R.YJTff1sG0AY68Ino0tLp.Z8w4CAjsmz9T63YuNgF47hWvmJTOR6fpvtpSLWe3NMmnq xhe1SW4mRPvJ5527LBTCfrTjVsgoXnXv7a4oIn9pSO_uB2Jtr3W8ktMMNiiCzVsdp5oS4r4noz25 xbKTr6I0j X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Wed, 7 Apr 2021 20:07:03 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fde7e89d33765bb925a9a95c56596cf4; Wed, 07 Apr 2021 20:06:59 +0000 (UTC) To: Daniel Fett , oauth@ietf.org References: <161771436122.1506.973742618731100764@ietfa.amsl.com> <63c57751-ff04-4e75-a74d-c4ba1105fb56@danielfett.de> From: George Fletcher Organization: AOL LLC Message-ID: <35d57c1b-5e1f-aec7-8669-c93260e873da@aol.com> Date: Wed, 7 Apr 2021 16:06:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <63c57751-ff04-4e75-a74d-c4ba1105fb56@danielfett.de> Content-Type: multipart/alternative; boundary="------------CFEE964D3604FAC3675760A2" Content-Language: en-US X-Mailer: WebService/1.1.18033 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/16) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 20:07:11 -0000 This is a multi-part message in MIME format. --------------CFEE964D3604FAC3675760A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit While this is mostly covered in section 8.6 of RFC 8252 for native apps, I wonder if we shouldn't mention "Client Impersonation" in this doc as well in that any public client can be easily impersonated. Mobile OS's are providing additional mechanisms for "authenticating" the client but it's unclear whether those will be made available in desktop environments where native apps also exist. At this stage Universal Links (iOS) and App Links (Android) should be best practice for any mobile native app. Best practice for desktop apps is less clear. Impersonating a public client is very easy especially if the only mechanism available for the callback is a custom scheme URL. Thoughts? On 4/6/21 9:15 AM, Daniel Fett wrote: > Hi all, > > this version most importantly updates the recommendations for Mix-Up > mitigation, building upon > https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The > description of Mix-Up attacks has also been improved. > > Smaller changes: > >    * Make the use of metadata RECOMMENDED for both servers and clients >    * Make announcing PKCE support in metadata the RECOMMENDED way > (before: either metadata or deployment-specific way) >    * AS also MUST NOT expose open redirectors. >    * Mention that attackers can collaborate. >    * Make HTTPS mandatory for most redirect URIs. > > I'll present more details in the interim meeting next monday. > > As always, your feedback is appreciated. We hope that we can proceed > to a WGLC for this document soon. > > -Daniel > > Am 06.04.21 um 15:06 schrieb internet-drafts@ietf.org: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : OAuth 2.0 Security Best Current Practice >> Authors : Torsten Lodderstedt >> John Bradley >> Andrey Labunets >> Daniel Fett >> Filename : draft-ietf-oauth-security-topics-17.txt >> Pages : 52 >> Date : 2021-04-06 >> >> 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 is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17 >> >> >> 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 > > > -- > https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------CFEE964D3604FAC3675760A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit While this is mostly covered in section 8.6 of RFC 8252 for native apps, I wonder if we shouldn't mention "Client Impersonation" in this doc as well in that any public client can be easily impersonated. Mobile OS's are providing additional mechanisms for "authenticating" the client but it's unclear whether those will be made available in desktop environments where native apps also exist. At this stage Universal Links (iOS) and App Links (Android) should be best practice for any mobile native app. Best practice for desktop apps is less clear.

Impersonating a public client is very easy especially if the only mechanism available for the callback is a custom scheme URL.

Thoughts?

On 4/6/21 9:15 AM, Daniel Fett wrote:
Hi all,

this version most importantly updates the recommendations for Mix-Up mitigation, building upon https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The description of Mix-Up attacks has also been improved.

Smaller changes:

   * Make the use of metadata RECOMMENDED for both servers and clients
   * Make announcing PKCE support in metadata the RECOMMENDED way (before: either metadata or deployment-specific way)
   * AS also MUST NOT expose open redirectors.
   * Mention that attackers can collaborate.
   * Make HTTPS mandatory for most redirect URIs.

I'll present more details in the interim meeting next monday.

As always, your feedback is appreciated. We hope that we can proceed to a WGLC for this document soon.

-Daniel

Am 06.04.21 um 15:06 schrieb internet-drafts@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-17.txt
	Pages           : 52
	Date            : 2021-04-06

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 is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html

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


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



-- 
https://danielfett.de

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

--------------CFEE964D3604FAC3675760A2-- From nobody Wed Apr 7 13:16:41 2021 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 30FEE3A2803; Wed, 7 Apr 2021 13:16:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161782660007.10351.16571659051707204723@ietfa.amsl.com> Date: Wed, 07 Apr 2021 13:16:40 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-03.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, 07 Apr 2021 20:16:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) Authors : Daniel Fett Brian Campbell John Bradley Torsten Lodderstedt Michael Jones David Waite Filename : draft-ietf-oauth-dpop-03.txt Pages : 32 Date : 2021-04-07 Abstract: This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 7 13:30:18 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CF23A2891 for ; Wed, 7 Apr 2021 13:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rIkm2rE40fvM for ; Wed, 7 Apr 2021 13:30:12 -0700 (PDT) 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 594483A288B for ; Wed, 7 Apr 2021 13:30:12 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id r8so156029lfp.10 for ; Wed, 07 Apr 2021 13:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pTfGUZfCgF5Jz1giUJand53gWAAI//265kjzGz8Nt04=; b=egRKKZuzb6lbE4pu/fFAzaQI7MUyjnZ2hqn7kMqz9bJ1/UJTlfXt9Um7SbY59F69Xf ViEv8oSCgCmvqO5/tEu+ye15flrViD/6oRq4vp3kJxeAGkOyMIrIKewcDTY2kE4k7VQm hrX1B6UX3kwb5/fecWGjYm3T9pvmxYf3W2eM31cesKZwVPOjdwQy6Cm4jB+mE3XDp3s1 rGi1wQb1PkxEjFAYj1bMxMvsIWeYr6ns9pvDs8wqKjsA++1NmJBNCTNxXmTh6zEgbJCv h4pdCllM7HGjArRgKsDo+GI/uN8JmwP1twu0+lYdwhYshO6bFkthXhvY3SSbdqhk7FY/ hMFw== 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=pTfGUZfCgF5Jz1giUJand53gWAAI//265kjzGz8Nt04=; b=bPM7CoWSvu82ijt0ZfBsYg52IkvGFAprmSNTRpINbewm1Q12XUdgo1FIYBQkJ2aEzD cSZ0vFoNZCI6gmidPOq33e4uomN3zG3espThX2c4Ez6ezDS/Ar1cfm/Kca92CsOFNfbH WlROfLUKTpRqziM1NzKDf4qBo6VTwWKeLRAUKu41uXCQERMAdajSXFPbZNfi+EmVERec QUO+9vNV7mYh1F7HjZhcFuDLXSDouS1NXHILSO9R5l/JQUM1F97iuQ0hD7QdWmJemJfT +OzfDCWSE03sZzVWdVFnQqQ1nafubbVKgiLL9j9ZoNrze+9pUmH2DJWLSadSOtH7/BIr kylA== X-Gm-Message-State: AOAM532j6Py3Cf/ysBcOCJ3udOunUVHwlcvlNWgbc4kozfn1NK5/7+IE dJqOoeUlw2oS7jy59SnNF9h98Hn+upRE3a+V3p0rM8Y48LckgnisL+43s+kzFkyDOpRjMeCJbCF u6IoUh11MpxHFPhiyHSVeKw== X-Google-Smtp-Source: ABdhPJy/1HyqYybGu0byi2H5o9jilW4vJqVodfuItf7XLJ70gnsqdv07IFdcbqy+DyfOyblp93wUs0ebtJhAxyr3tFg= X-Received: by 2002:ac2:442a:: with SMTP id w10mr3627457lfl.657.1617827409416; Wed, 07 Apr 2021 13:30:09 -0700 (PDT) MIME-Version: 1.0 References: <161782660036.10351.46460390355713291@ietfa.amsl.com> In-Reply-To: <161782660036.10351.46460390355713291@ietfa.amsl.com> From: Brian Campbell Date: Wed, 7 Apr 2021 14:29:43 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000000befe505bf67cce4" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 20:30:17 -0000 --0000000000000befe505bf67cce4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A new revision of DPoP has been published. The doc history snippet is copied below. The main change here is the addition of an access token hash claim. -03 * Add an access token hash ("ath") claim to the DPoP proof when used in conjunction with the presentation of an access token for protected resource access * add Untrusted Code in the Client Context section to security considerations * Editorial updates and fixes ---------- Forwarded message --------- From: Date: Wed, Apr 7, 2021 at 2:16 PM Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt A new version of I-D, draft-ietf-oauth-dpop-03.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-ietf-oauth-dpop Revision: 03 Title: OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) Document date: 2021-04-07 Group: oauth Pages: 32 URL: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.tx= t Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Html: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-0= 3 Abstract: This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=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._ --0000000000000befe505bf67cce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A new revision of DPoP has been published. The doc hi= story snippet is copied below. The main change here is the addition of an a= ccess token hash claim.

=C2=A0 =C2=A0-03

=C2=A0 = =C2=A0* =C2=A0Add an access token hash ("ath") claim to the DPoP = proof when used
=C2=A0 =C2=A0 =C2=A0 in conjunction with the presentatio= n of an access token for
=C2=A0 =C2=A0 =C2=A0 protected resource access<= br>
=C2=A0 =C2=A0* =C2=A0add Untrusted Code in the Client Context sectio= n to security
=C2=A0 =C2=A0 =C2=A0 considerations

=C2=A0 =C2=A0* = =C2=A0Editorial updates and fixes

---------- Forwarded messa= ge ---------
From: <internet-drafts@ietf.org>
Date: Wed, Apr 7, = 2021 at 2:16 PM
Subject: New Version Notification for draft-ietf-oauth-d= pop-03.txt


A new version of I-D, draft-ietf-oauth-dpop-03.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dpop
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Demonstrating Proof-of-P= ossession at the Application Layer (DPoP)
Document date:=C2=A0 2021-04-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-ietf-oauth-dpop-03
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-03

Abstract:
=C2=A0 =C2=A0This document describes a mechanism for sender-constraining OA= uth 2.0
=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application = level.
=C2=A0 =C2=A0This mechanism allows for the detection of replay attacks with= access
=C2=A0 =C2=A0and refresh tokens.




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

The IETF Secretariat



<= 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. --0000000000000befe505bf67cce4-- From nobody Wed Apr 7 18:00:35 2021 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 5D4CF3A3148; Wed, 7 Apr 2021 18:00:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <161784363329.31791.17335805411740728428@ietfa.amsl.com> Date: Wed, 07 Apr 2021 18:00:33 -0700 Archived-At: Subject: [OAUTH-WG] John Scudder's No Objection on draft-ietf-oauth-jwsreq-32 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 01:00:33 -0000 John Scudder has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection 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-jwsreq/ There are no remarks associated with this position. From nobody Wed Apr 7 21:36:38 2021 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 D79523A3897; Wed, 7 Apr 2021 21:36:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161785659276.2418.17087888491489897871@ietfa.amsl.com> Date: Wed, 07 Apr 2021 21:36:32 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-33.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 04:36:33 -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 : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Michael B. Jones Filename : draft-ietf-oauth-jwsreq-33.txt Pages : 35 Date : 2021-04-07 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, (b) the source of the communication is not authenticated, and (c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-33 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-33 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 Apr 7 21:44:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8793A38D5; Wed, 7 Apr 2021 21:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SDoW4Zv6oduQ; Wed, 7 Apr 2021 21:44:28 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640134.outbound.protection.outlook.com [40.107.64.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2173A38D3; Wed, 7 Apr 2021 21:44:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XIu8u+iK0Lil1kSZzEXe7Is/efGjCYj+S8ZJA7NLbuVCbxAqXPNlUR8z5juXLFpxkwGfIdIQCPDsA4gOX8wiASyC+HiWjNJwehFxg8Nyb/gsBwoyULjEPmc0QXDi0BNXTKYOwsI4h9Tyl/6nAWKHU24T5T9UGw4xpJEa458GLA8jOSNCnrqZcrgAHGWnoNxU+YAWo2c8nH/2Lf4Tw5YmN+68D/q+HxM+/Y8YfjvmnH+It0LElDwOBH5IoWqIUeth15PjTIuBDLnn6mj71xZz7KJcRqYs4JnSWaw0T+dZR9gpQG/mnOvFo/p12TenkhdXR62wObzgaakw2XyIdJnV/Q== 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=bGDQvz8818rPY9cceU5OVQkbHX4Yhyx2ppXmPdvAxl8=; b=KyfHEg8CpWXbGYacDuiQt10LQJfysjYS37VefhTrjUU93GPRDJrXC37AR5SUhTPskJWFAJ8KQT0QMd6bOhbA8TBYwgwuOxLBBgnw0xENetCZ7xhUQdTaFBrr00nqNYmN/VTDmwy98IWqmlYZnuA5nhw67QsbAWDQ1vOfsSyHkXRwt2iY9nlFFCY7YLvPck/8rJOtVg2td4Yy9F7d0MpQFN9rtl6oyv5lE24qCv9BLQN5W4OTgbyy8TVjhKfOB1cTmrvaoytBfcedw1zJb/2EppSI6qr6dZod6X6UDcC4sJAEqAyJ/d/v2nMWdloe9PMhAFh4tAVsIXDBLHy4+9tIEg== 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=bGDQvz8818rPY9cceU5OVQkbHX4Yhyx2ppXmPdvAxl8=; b=SY34Ea+6olonho5KYaQNHkHgXYlUaLuXwO3JzsQ0CjG90tRmIRcKxkTxaTL1COo4M1WPaJGNvS8ydeWPY6HIgNnXuAK72W9cVyHz4lb0ONqQyJVENE6Slpu5V3YBb8LvXeqeG4mIkFjWVGTemD2RG9xRDxD7mMcQzeN69ZiwWkg= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0751.namprd00.prod.outlook.com (2603:10b6:5:1be::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4056.0; Thu, 8 Apr 2021 04:44:18 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 04:44:18 +0000 From: Mike Jones To: "lars@eggert.org" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Lars Eggert's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMdS6wR40z732TzeqDhT7BSa8oA== Date: Thu, 8 Apr 2021 04:44:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T01:16:16Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=bc9455a8-ba37-4fa3-8707-bfa81d31df75; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: eggert.org; dkim=none (message not signed) header.d=none;eggert.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.56.42.184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a8b1b88-644a-4dc9-eb35-08d8fa48f89a x-ms-traffictypediagnostic: DM6PR00MB0751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sCXhc5OvNrmCz3amsCgXUtngsi/Rs88urqbs60bYFrQg195G0xsWpMbfp6haiWZ53myUlV+XBCS4fkQ+xMxAOaa/+8N2iroLk0fr4oEv8XbkhpudhUFu8+lZvbg57/zJ2fBwQtxfKBvfQ4yDU1LlU0p+aIf6F2SBl7B0E5XarMsGS3FpOQPr02j+96nqPXCHJCC5hD80eytc94velSnxrLKf7TyL1glvOyDLyHg5eSfD1gbvSTT8NCvzbtq2VlbQAoX3Fch9s6v4EqzWUk+mVk5AxGR3Vrz0TClxkmGWiCIpQw5ceVUxe0QkYpDgi+MLQ1v1C5uEsIPzD/3b4KIi82777b3icL2zOZgToafM3q31EwiQR0Yy9qb7r48SQpyIOfbjpb++0T4lF4nlcyUUiUdLWHNUs0eY6xmGV+SZf42XAkaCeD64fRv4dQycHPr7s+lGUr5RPw6QzdHG8udyiSnOk9hpG3eqROiP93jSrq38+PREoUnbcVQ1lnGC+CjQk4C4rjlF8n2gW3BlVi7YUkwQ3tXx68ymxfX2sbqAH1J+IqwhmuRJe20sJInFyX0qx81OKigchl4op/zgHd877uwI5uqVLQg0t4bYgEPvBKp6SK3oFLcn+I3eWRER291QdklcbdTBiI41HQ05qY2PrOmme6uPeU6DKJBPl3mUxvJi/OeWy6ABGMlH349RkTGNdBLUw41PKXw55UleM/5zL//5V8mwbCq83Rb5ZyjhGUM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(2906002)(86362001)(26005)(5660300002)(55016002)(71200400001)(186003)(52536014)(478600001)(83380400001)(54906003)(8990500004)(110136005)(33656002)(966005)(7696005)(10290500003)(4326008)(66476007)(9686003)(66946007)(6506007)(316002)(82950400001)(38100700001)(8676002)(76116006)(66556008)(82960400001)(64756008)(66446008)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?VERVeU8xZm9oWStQWjB2NGJnNDF4TnFpaTd4UGtUK2hydHA3Qi95TlVmWW5J?= =?utf-8?B?R3VKREdqSmhCNFNLMGxNT09Pei94Y3ppUnJDNXNvZlZtMkFWM0dSQ2U1RmFJ?= =?utf-8?B?ZWt4cnk0SUU2VWpaRVgyTmYvVENiSXVWTzcremhiSldvSnkvRFVyVjhZU0pX?= =?utf-8?B?bWRQVi9iMmVPNFdaV3hVQmVnKzFrU1JkQW1HUTJFVTBPREpVTWRjMm5Velp1?= =?utf-8?B?OVJZK2xFWHhzT3VCTmFkUFRsUCtYU0I0N1I4YXdvdS9qUnBHYjNMOEVoaC9l?= =?utf-8?B?eVFFWTJVUWhwVGNmVnZTWUo0R2FweEpuNCtGZXZpVmxuYUpiN0VPWFZxWVhh?= =?utf-8?B?WEVaRGtTOFloa0IxeWZBOVNkZ3Q0SWJxMFZRQ0dTR29sOWlXZ0w3SzRlQlZq?= =?utf-8?B?Rm9IZzEyVE9aNE9UU0dVdVBPSDh2aWg1VXpGcnQ4WnAwNUFsbDF3WlBQTVJU?= =?utf-8?B?VUIwWk92alNiVDRrU2ZvWWFRU1hVRWJ1blNzUVZuNmt4R3FGcmpwSkxPY1lw?= =?utf-8?B?WjlUQzE5OThtd09DWFZ1alBOOFFwVVhISFlCL1Z3UGdkZ2txTGdoOVlmaS9n?= =?utf-8?B?WHVMdEFVaUczR1cxVm1MNnl5RFVDQy9oMXhleG10cStRRWUycEIrN1FpUG15?= =?utf-8?B?eXFQVXpsQmNIM1lLbjBpTVZQSjNMZUhSVVRvMlRSaGtpUmcyenR0eW4vWVpU?= =?utf-8?B?b1JIMXNJVU5KNGZVMHp3SjhMYnNadHlTNEs2blY3bzgrVjZER3RLRXl0QXhv?= =?utf-8?B?aGpCTW9wbWVGa0dUOEIvM0pRRGtLSkJsK283R0xEWUhFRjRmTTNLYUpCd1Bn?= =?utf-8?B?L09STGxaSkVCeE5pZ1g0TkFPTlhYUGViYnIrNnJUUjVDYnExZTFQVFg0T3FO?= =?utf-8?B?K1RPalZhbU4xS3I2U0lmOGJsa2dFRXdrNmF1MmdjSlREN1V6ZExPSGdxdURL?= =?utf-8?B?S2VUQTJMWW51L3dFR3VNektUS3BZOFpsK1k3N1Q3U011RE94K2c1SkQ2SlRw?= =?utf-8?B?Uzd4ZG9nRnduZ3ZXdWVFRUt3dHUzU083NVB6aFl5RG0xWWVFdk9FTkNGZ295?= =?utf-8?B?NHNkNkxML0NVdjlFUk9xVTgvL2JzeVFGeVVzdW5aZmI0K2VXN2ozQSsxeE9m?= =?utf-8?B?aEU1c1IvbzliNytOTmZhL0Z2LzY3R0k0MGJRRjVKbUxjZjBUZmNxRUx3dTJu?= =?utf-8?B?VkhtZXlVc1lJN1c3RDhzSlpWRmZsdnJXZjhEY3NMZk96NGE1cncwelg4MEhM?= =?utf-8?B?cEp6cS9rTkcrRzJXdlFKTDR1L2dTbnRiODM2Y3hmT0VSR3d3eXdMQzF4Mkxy?= =?utf-8?B?Mm9JTGFZRjJibHJkbkxKNUdPQ25SYzM4NG9VOU92Qnp6ZUd4dThMUEZQSm5V?= =?utf-8?B?eERGM01GVExsYlI5MVhLdVhLZ1g3cmVmN25iK2NIa0dEUTBrTnlrZUNqK3J3?= =?utf-8?B?bjZrQjhRL0toUFRWcDBPREFiL1VSdlNTdFk4RFlIUk55T2w4NmZnUjk4SHVv?= =?utf-8?B?NXExOFB2akRzc1M5SHdGVkIzOVVFUnFmbmVMVjRiamtoY3NCZjZrYzJLeXhn?= =?utf-8?B?OXl2UUxzemUrQ05wY3dmMzNvNlJtdTVWbllRMkJPaEtvVDJNNjJqdXQxUzh2?= =?utf-8?B?OVZ2RWFpVlRIQUJmT21QeTVYc240M3NkVmE1WThJUFZmcVVlK3pUVXdUZk9E?= =?utf-8?B?TEpGbWl4OWR1NE93OUN2RUMzVGxXL3hnSkl4RzB6ZVlrbmlDcjZCdzQrWUVJ?= =?utf-8?Q?CukII9zSVHk4D4Mcjrongu3hB6v54rQ+v5BMp4a?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a8b1b88-644a-4dc9-eb35-08d8fa48f89a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 04:44:18.7597 (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: 9Bdnc6OCwjTAkyu6XNAanG7U+n7kUVH4MiEoFo2YpWw43HF5n5gInmPugwyaHogPpGmjfWNXF/WL/PIWDUL3Zw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0751 Archived-At: Subject: Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 04:44:32 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgTGFycy4gIFdlJ3ZlIHB1Ymxpc2hlZCBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzMgdG8gYWRkcmVzcyB5 b3VyIGFuZCBvdGhlciBJRVNHIGNvbW1lbnRzLg0KDQpSZXNwb25zZXMgYXJlIGlubGluZSBiZWxv dywgcHJlZml4ZWQgYnkgIk1pa2U+Ii4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IExhcnMgRWdnZXJ0IHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gDQpTZW50 OiBUdWVzZGF5LCBBcHJpbCA2LCAyMDIxIDU6MTkgQU0NClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz4NCkNjOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcUBpZXRmLm9yZzsgb2F1dGgtY2hhaXJz QGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzsgSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldA0KU3Vi amVjdDogTGFycyBFZ2dlcnQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1qd3Ny ZXEtMzI6ICh3aXRoIENPTU1FTlQpDQoNCkxhcnMgRWdnZXJ0IGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzI6IE5v IE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBh cmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRo LWp3c3JlcS8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN ClNlY3Rpb24gNS4yLCBwYXJhZ3JhcGggNSwgY29tbWVudDoNCj4gICAgVGhlIGVudGlyZSBSZXF1 ZXN0IFVSSSBNVVNUIE5PVCBleGNlZWQgNTEyIEFTQ0lJIGNoYXJhY3RlcnMuICBUaGVyZQ0KPiAg ICBhcmUgdGhyZWUgcmVhc29ucyBmb3IgdGhpcyByZXN0cmljdGlvbi4NCj4NCj4gICAgMS4gIE1h bnkgcGhvbmVzIGluIHRoZSBtYXJrZXQgYXMgb2YgdGhpcyB3cml0aW5nIHN0aWxsIGRvIG5vdCBh Y2NlcHQNCj4gICAgICAgIGxhcmdlIHBheWxvYWRzLiAgVGhlIHJlc3RyaWN0aW9uIGlzIHR5cGlj YWxseSBlaXRoZXIgNTEyIG9yIDEwMjQNCj4gICAgICAgIEFTQ0lJIGNoYXJhY3RlcnMuDQo+DQo+ ICAgIDIuICBPbiBhIHNsb3cgY29ubmVjdGlvbiBzdWNoIGFzIDJHIG1vYmlsZSBjb25uZWN0aW9u LCBhIGxhcmdlIFVSTA0KPiAgICAgICAgd291bGQgY2F1c2UgdGhlIHNsb3cgcmVzcG9uc2UgYW5k IHRoZXJlZm9yZSB0aGUgdXNlIG9mIHN1Y2ggaXMNCj4gICAgICAgIG5vdCBhZHZpc2FibGUgZnJv bSB0aGUgdXNlciBleHBlcmllbmNlIHBvaW50IG9mIHZpZXcuDQoNCldoYXQgaXMgdGhlIHRoaXJk IHJlYXNvbj8NCg0KTWlrZT4gQ2hhbmdlZCAidGhyZWUiIHRvICJ0d28iLg0KDQpBbHNvLCA1MTIg Ynl0ZXMgYXQgMkcgc3BlZWRzICh+NDBLYi9zKSB0YWtlIH4xMDBtcyB0byB0cmFuc21pdDsgaXQn cyBub3QgY2xlYXIgdGhhdCBsYXJnZXIgcGF5bG9hZHMgd291bGQgdGhlcmVmb3JlIGJlIHNvIG11 Y2ggd29yc2UsIGdpdmVuIHRoYXQgdGhlIDJHIGxhdGVuY2llcyBhcmUgcHJvYmFibHkgdGhlIG92 ZXJyaWRpbmcgaXNzdWUgaGVyZS4gV291bGQgYSBTSE9VTEQgTk9UIHN1ZmZpY2U/DQoNCk1pa2U+ IFRoaXMgaXMgbm93IGEgU0hPVUxELg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBbGwgY29t bWVudHMgYmVsb3cgYXJlIHZlcnkgbWlub3IgY2hhbmdlIHN1Z2dlc3Rpb25zIHRoYXQgeW91IG1h eSBjaG9vc2UgdG8gaW5jb3Jwb3JhdGUgaW4gc29tZSB3YXkgKG9yIGlnbm9yZSksIGFzIHlvdSBz ZWUgZml0LiBUaGVyZSBpcyBubyBuZWVkIHRvIGxldCBtZSBrbm93IHdoYXQgeW91IGRpZCB3aXRo IHRoZXNlIHN1Z2dlc3Rpb25zLg0KDQpTZWN0aW9uIDQsIHBhcmFncmFwaCAxMCwgbml0Og0KLSAg ICBTaWduaW5nIGl0IHdpdGggdGhlICJSUzI1NiIgYWxnb3JpdGhtIHJlc3VsdHMgaW4gdGhpcyBS ZXF1ZXN0IE9iamVjdA0KKyAgICBTaWduaW5nIGl0IHdpdGggdGhlICJSUzI1NiIgYWxnb3JpdGht IFtSRkM3NTE4XSByZXN1bHRzIGluIHRoaXMgUmVxdWVzdCBPYmplY3QNCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArKysrKysrKysrDQoNCk1pa2U+IEkgYWRkZWQg dGhlIG1pc3NpbmcgcmVmZXJlbmNlLg0KDQoJCQkJVGhhbmtzIGFnYWluIQ0KCQkJCS0tIE1pa2UN Cg0KDQoNCg== From nobody Wed Apr 7 21:46:02 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F693A38F1; Wed, 7 Apr 2021 21:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KULKGF477ksJ; Wed, 7 Apr 2021 21:44:37 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640097.outbound.protection.outlook.com [40.107.64.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E663A38F9; Wed, 7 Apr 2021 21:44:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LldVwI6kNBmUdfN7zr6mpvtue3pD0nhzxdEQmSZkinyLqVLMyJDHDqdqr76ADHzw+ANwZB3nwQh7TF5LU6tdLyCYBMTBIp0T7uSx5SppT33+jpiFd0kCTl8qqeKhuBlrDBK75nzWnwSbRKsI3wBtByXjKjqawY4egbpF+B8eUhynvre1NX5H7QGjGpf4cQz8M7GV4u4KKWMC9OZU/zy+XMXfkSvF6JEO0SF8Yq3jqNsunKOp/AoUu8kEG8aEJRDYTfk9ZtwBk5giPy5SBTDTHkP7M5Tthw5QbcBamz3ZNgdGRqmvzBcZwwl45zpIqLBiMS4UfEl5banf/xLv/EqQ0w== 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=B/grCNfGJW6FkRY/r8kt4R0I2yZspFVkaxL3swrTrVs=; b=dkICRC1c7ZRPQ/O48eCVWrkV0fEWEU3MmqjCgyfIBFGsXwzParNbmI0LbWqF1TdzsIV+1w2UuvluPWo/EDmMebGkVCLugEeULK+4OB7LyEInwRkKlhmNhcgz2iPo3lkHuDIx2MOf474F0eQupb+DpjQScP+4OsHPbKO9MsH7porjPPWfix9ZMh8ak6j7JSU8R+ocgJPlc+/Mb2FSW8ZpLamw4oi2iv7NRqNnUOzrpKAV2v5WRfXoUwX9EBH8xWxpIUNsBniDJl7cj6rpasZ8xwUfN5SCiuHMW/07aacjncwKwG+NxlpZ0djsjYQIQ846zHLXuwOTToczaPLf4v0cVg== 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=B/grCNfGJW6FkRY/r8kt4R0I2yZspFVkaxL3swrTrVs=; b=KSntSwDUjkf8wj01WmdkeeO8zIaK9xJT3PWWnunJ/0yoO+9KqKrEBZ2hV6tfr/kKGai1N6GqTASgg7V3Ebr//iGGZAWEHwXritXqqj0wZtBeBhIDwiiwdbSVAcWEHd314hUEbEdeuCAlWwVBdt3K/RcOoY6tKxmqIdPmbw/N7ZA= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0751.namprd00.prod.outlook.com (2603:10b6:5:1be::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4056.0; Thu, 8 Apr 2021 04:44:30 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 04:44:30 +0000 From: Mike Jones To: "evyncke@cisco.com" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1?= =?utf-8?Q?th-jwsreq-32:_(with_COMMENT)?= Thread-Index: AdcsMdpvP7kT4KrMSkq32B7JGYoiNA== Date: Thu, 8 Apr 2021 04:44:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:15:00Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5dcb7e2a-8e5e-4a55-b62f-ff9be88fc627; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.56.42.184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2e5695c9-5302-4b30-92f9-08d8fa48ff94 x-ms-traffictypediagnostic: DM6PR00MB0751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NM0I3qn1+OlH24dw897DPQpfKRhx1EVCnmc21f2b5IW9a994uZgRcAXXM/Zm9RDMFiUU2DQR/MmfLcjYJ61pXOXv5WNJl0gngIfzzkFUlnWO+AKsDBynav1yJhJFgURyrDQZ/QMzQiYg5Ebdh/fUvOtZrt+AJMnzecZ5QyfYn0QT1qq+Nq01wd5tUOw7j3icUWQswrPq71Qdg7RGknxOCNsAMLM4e4yZjHGHv2yPgVW7fC6PTyw4LtfQVtYrA4pawjqhSKm5O4f0vtMq+hMJ50IiFXuxTN1+msuZNNo02TC81+NXKpg5EI2HkYyCN6f306lVPHdndYReOUgaE+UXEQtHjVEJFbsmUYAbpX0JAT0CwJbjG4W9xzclF/juXOTgAporxxRWLdYS9BZqEqW6YGGpLHJjcco839CfiJKytSbyqqcmEFzJXYxFA0QghjgEX1yqX04YlBRdap0bXi41ycQK+HmqbCIyXF/C6nZH8ru4IXhH+8jvzA894iakrDfpOabYxyAOulOj4wxh/KT3LHOCaGz9sE/4VUHvwF1F/2vRm+8u7mAPyiIGrdP21cm+V0qp1+UH4F/xzEkg87Qst4pfYMotisw69LaXf99vVQgv6/yEp9GWi2MrZnJmKLM/w60Re3v9WOW04/8bAhdSiHEubzekfr0uGbBKrHyxv1wfyMNLIiX3PDrniL9RYSSHUfaYzOkFRXD5DfQChwOEBwZWdd09JE5wY8xk/BL6sZQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(2906002)(86362001)(26005)(5660300002)(55016002)(71200400001)(186003)(52536014)(478600001)(83380400001)(54906003)(8990500004)(110136005)(33656002)(966005)(7696005)(10290500003)(4326008)(66476007)(9686003)(66946007)(6506007)(316002)(82950400001)(224303003)(38100700001)(76116006)(66556008)(82960400001)(64756008)(66446008)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?MS9tUGdjUXFPKzhjQmJVWVdZRWFCUW01TGdjSmpTY0JQTTl2UDBtK0pOci9J?= =?utf-8?B?YWZnRVMxRjZsbUI0WkZUUWFON1VSV05lRENManFVV0VYdWJlaHppcGViMHU0?= =?utf-8?B?bm41MHFFTVV5L1dPT0Urci8ySFYzS2JnTlJGTjNDVlRla1hBZ21aVEVpY09z?= =?utf-8?B?Vit2TDF6WXIvZWFIR3pmZUlJUVFUei9OWmFWWVNtaXdmZUc4UTVTd0Jkemww?= =?utf-8?B?RVZOMmJhd2dhZU1veGNENjdyS3JoVnZzckR5U2xDTkl0RmhpR25jMnRsdXMv?= =?utf-8?B?L2ptSzRNbFpDbGFYbHRmNzJDY1pXL2k5S1ZxT2FLblRiVjI4b1RQSXVKSmxD?= =?utf-8?B?c3FNcWRtbGIzS3lHbmIwT1UxSWoxZy90bWZWMG9Ld3JxaU5CNDUzd0NnN1NR?= =?utf-8?B?blNSelhldERaUWc5UTVzYkxKcVRUL2c2RkJzTjE5K0FGZDg4MHZWNDdyaFZP?= =?utf-8?B?V0VWbEllWXUydXUyTnU3V1ZnL256dFExbHkzRFk2c3VvS1pWTjVPQzVpNUNU?= =?utf-8?B?ZXNuU2pYMnRaeTlQakVlc0YxWkZ4YTBYR0VHdDBOa3R5b21VOEJhVWdSZ1Ur?= =?utf-8?B?NXA1Q3Zvd3BYaFNLbVJQVlN4SXpJTFhlOHMyQzFLRWxGVmlkeStFc3FIaGti?= =?utf-8?B?bjYxVExOZTNwRmRRYWJ6amkxTHQrNVVGazk4L0RVL1l6V1NjU2crelZBOEx2?= =?utf-8?B?bWNrWW1BRjhVSmZmY3pjQVd0WjRRU2VkQnUwSEwyc1VEdHZEQ1NBTnZVeENh?= =?utf-8?B?Y0xYaEczZUFCL3k4VDBIVkRRNlB3ZW91VVNqOFovaU1QYnF1SUxnK3hPOGxj?= =?utf-8?B?YVRLQU5wZ1dneGsydzNJMWt2VEtPa3BkSm5TNWd0dkdVV0ZTOVJTYVpnb3J6?= =?utf-8?B?VXA4ZXh0MlJZTTROcjN5aTZFamNJNHN0Nkp0SjNYeGlJdTZHMDhUNWFZSGcz?= =?utf-8?B?SHQxdFdrQ1dlMmdudk9MTFllU0lxNTU4YUNBc3lhaXVNWlByV1ZTdzRObnZ0?= =?utf-8?B?aFlVd0Y3eHBmaW5rZU9kZUpVMnRhZDcraGNFUzRWaCt6NUkweWJPNys5TUQ0?= =?utf-8?B?NExrSHVTOFlJVTFldzU3U2NWRit4eDdqN3ZaS0pPaDNEWEdZam9adm03R0xE?= =?utf-8?B?UlpQd0NhSlRzVTZuMjRSdmNGNUtXcTBTU1ZuZGkwU2EzQXZMZitOeTV1MVVH?= =?utf-8?B?VGhWdGtGQ0RkUjQzUVRHcUlvV05BTjdHd2pDZEVBZENaMFhJNVFVd1hyRWto?= =?utf-8?B?OXVoclB6VXVuRHJTQkptdUJuaStSVk5IbkpyWGdqZFluUjdFWUxlTEZUSWpl?= =?utf-8?B?V282a1g5V1BGMTYxaGNxTmlEUE9iaXZ5am9vOUlhRTloS1I1eUh6R0xaaG1a?= =?utf-8?B?ZlhvWk9rNEd4WnNESFlmcjZoYTVTRVhkME9GWHVDUDBYRGROY1lWZVFWNVhs?= =?utf-8?B?UVp6aXhpeVd4RmRJUjU0S2svQTNlL1JMazRDdHZ1Nzh5WFdkdGdscmFKRmtH?= =?utf-8?B?b1dIYW9CM3ozOUZmZjJEcWxrNlA2VDFmTXZSVVU5c0N6c2NCc084N3B0YTY3?= =?utf-8?B?eW43M3pLamkrZldXL2JsdGl6Tkl4dlFKQ1ltd25nSmNBNnlTSzJnYUdCcEw1?= =?utf-8?B?L2VxRHFkUHRRRmxtRm9lMVNQV1k1TXJ3MDRxdTVXRzBvaTA1R2tVRTk2M25D?= =?utf-8?B?UVlQOHFQa2lhbmpoeWE3LzZ2K1JjZFZMWm1Wck8wZ2tPNG9pWWRSd1N1Z1l6?= =?utf-8?Q?WPfq5DRW2yutLzj6hIHc9utECutv9UhhdQwA2j1?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e5695c9-5302-4b30-92f9-08d8fa48ff94 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 04:44:30.4202 (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: qInoym1N3NQ8JjNu5s1dmwJ8SOEImmld41n/ZpuhR9fD0TY2wSr0rJ8RKozoSIMIHSmHsSmDNqWSUaJVBIv7og== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0751 Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-jwsreq-32=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 04:44:47 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgw4lyaWMuICBXZSd2ZSBwdWJsaXNoZWQgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMzIHRvIGFkZHJlc3Mg eW91ciBhbmQgb3RoZXIgSUVTRyBjb21tZW50cy4NCg0KUmVzcG9uc2VzIGFyZSBpbmxpbmUgYmVs b3csIHByZWZpeGVkIGJ5ICJNaWtlPiIuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiANClNl bnQ6IFR1ZXNkYXksIEFwcmlsIDYsIDIwMjEgNzo0OSBBTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxQGlldGYub3JnOyBvYXV0aC1jaGFp cnNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnOyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0DQpT dWJqZWN0OiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1q d3NyZXEtMzI6ICh3aXRoIENPTU1FTlQpDQoNCsOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUg Zm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMy OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0K VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v YXV0aC1qd3NyZXEvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgZG9jdW1lbnQuIE5vdCB0 b28gbWFueSBkaWZmZXJlbmNlcyBzaW5jZSBteSByZXZpZXcgb24gdGhlIC0yNiAoaGVuY2UgSSBy ZXZpZXdlZCBtYWlubHkgdGhlIGRpZmYpLg0KDQpQbGVhc2UgZmluZCBiZWxvdyBzb21lIG5vbi1i bG9ja2luZyBDT01NRU5UIHBvaW50cyAoYnV0IHJlcGxpZXMgd291bGQgYmUgYXBwcmVjaWF0ZWQp Lg0KDQpJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KDQpS ZWdhcmRzLA0KDQotw6lyaWMNCg0KPT0gQ09NTUVOVFMgPT0NCg0KLS0gU2VjdGlvbiAxIC0tDQpJ cyBpdCBub3JtYWwgdGhhdCB0aGUgYWJzdHJhY3QgaGFzIGEpIGFuZCBiKSB3aGlsZSB0aGUgaW50 cm9kdWN0aW9uIGhhcyBhKSwgYiksIGFuZCBjKSA/DQoNCk1pa2U+IFRoYW5rcyBmb3IgdGhlIGNh dGNoLiAgV2UndmUgYWRkZWQgKGMpIHRvIHRoZSBhYnN0cmFjdC4NCg0KLS0gU2VjdGlvbiA1LjIg LS0NCkkgc2VlIHRoYXQgIk1hbnkgcGhvbmVzIGluIHRoZSBtYXJrZXQgYXMgb2YgdGhpcyB3cml0 aW5nIiBpcyBzdGlsbCBpbiB0aGUgdGV4dC4uLiBEb2VzIHRoaXMgYXNzZXJ0aW9uIHN0aWxsIGhv bGQgaW4gMjAyMSA/IElzIGl0IGJhY2tlZCBieSBzb21lIHJlZmVyZW5jZXMgPw0KDQpNaWtlPiBJ J20gbm90IHN1cmUgdGhlIGRlZ3JlZSB0byB3aGljaCB0aGlzIGlzIHN0aWxsIHRydWUuICBBbHNv IHJlZmVycmluZyB0byB0aGlzIHJhdGlvbmFsZSwgTGFycyBFZ2dlcnQgc3VnZ2VzdGVkIHRoYXQg d2UgY2hhbmdlIHRoZSAiTVVTVCBOT1QgZXhjZWVkIDUxMiBjaGFyYWN0ZXJzIiB0byAiU0hPVUxE IE5PVCBleGNlZWQgNTEyIGNoYXJhY3RlcnMiLiAgV2UgaGF2ZSBhZGRyZXNzZWQgdGhpcyBpbiB0 aGUgbWFubmVyIHN1Z2dlc3RlZCBieSBMYXJzLg0KDQoJCQkJVGhhbmtzIGFnYWluLA0KCQkJCS0t IE1pa2UNCg0K From nobody Wed Apr 7 21:46:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBF43A3903; Wed, 7 Apr 2021 21:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 12l5ELTsXW3c; Wed, 7 Apr 2021 21:44:52 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640116.outbound.protection.outlook.com [40.107.64.116]) (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 1CC143A38F8; Wed, 7 Apr 2021 21:44:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B95FTEf95KYClSqPpQ4FnCmzojJu3yex02N+U3ciN7o62HI2KytBJWPKTTFWBc8aBd/FrSWMNIxBh7zFaKNlUiBwIzBlteXQDwnPATg5zZ6yXYYwbTexmRiIrHobmI96RTkLmqanm0x490SlygarvBZuGUbx6LTHBn1eBCqNtih/+XfPkyYq93YqdtxZSVhlyX5ACh7v22V6YPZVe1W1AxIllcy84UWwhkfPAPF/cTDtWTWZMbEHTXGXZJb895iF+8586mGpgMVj4q0yVSuFp9Ho/4Tqq16YTBeQoJncr88t+bK5YEIaBnOHP16uIgRJiL67xg4tHjJrpjJ7h/ocJw== 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=GFXyuUa71H/LDyH59ew1qn3tT7yi/O4h11bbSMOobOI=; b=KsZ/MLYe5EE1kcbaxgjOGXuS0DzUsRicepi2UlXDzFo2JxJag0HCwcgqjQKHXxHheqE48Ra0bVFB1LtsbRhjMB8Ulav9D2Orh4YVAi9ZZG0UqPTljY2mjj9qQbHEhckpW4oYa0F0brNZwn/KWpTkdtdbaeBMZO9vQepVTRN9Dq4OQ4aIkBzGfLWn8Z4L5E/Czy5ijjlBwisxwtkbIGXsEBgbfzHK+KTN6PtwRIGy3C45W3YgtOOt7KqjnDcGRpCCqihfc58NR5JbRpwkUbstdea8cj79kqM4kCwZmQ6YF6CrvIRF8CTNbbq2aRaQDFAW360SfeWdaMnintSrPhznzQ== 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=GFXyuUa71H/LDyH59ew1qn3tT7yi/O4h11bbSMOobOI=; b=BlmjqSu3awNHX0OvyC3WcJyxyyecGM+ElVUGdj2rw/K5FT9QxUsUXSl8nFmi9sK9u1bA/50v2EChyMpQsygPjzwX2tvsPwx/HnilE01QNAxs7p5iKY9S8u3ok+s3g+8o3BHbsm2jqEyM0rb7+dMhxy0xHZTlkpxvJlcFm8vJPL8= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0751.namprd00.prod.outlook.com (2603:10b6:5:1be::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4056.0; Thu, 8 Apr 2021 04:44:43 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 04:44:43 +0000 From: Mike Jones To: "martin.h.duke@gmail.com" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Martin Duke's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMeE2oUFxE2TgSviIoMFwJNqYLQ== Date: Thu, 8 Apr 2021 04:44:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:25:43Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=96a4b1eb-99cb-4bfa-b273-7ffeaa4214a2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.56.42.184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0367f5a-cccb-4fa5-7a09-08d8fa490729 x-ms-traffictypediagnostic: DM6PR00MB0751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MylrDGNlvNt1AI3Lwd3P+jcPwBy35+vhBy7YXf1B1jzWucDBOQQKty3pSrDrQr3lP75rn6/bRB/LxmyGxmsdD+1jzlHCVv5m2v/7LOmN/GOi/Tc5xqgcgFzX1NPl2QJ4bFu+d3Od11V/2to0HbL2oN5a9RSI2OmRkK+v3oBqMbd0Stk256hOhhdAgK32W0H/HiUdwJdX9+VmHLDmyDNOJeVkyvLBoQ+VMdY9a8HqLrMyZzUZjQoneDLUabk2Fvn0lORZYUtwg1CpxeRe7rKPZTjcP4zh9Rj9VzhjVZtdCXc1dyaRsfFs2ILY9AjV9qCoCXfJ7gzqGk17gjw25Gik4ZWhb2wDqD9YsoTBUaqn2ryDYww+AunDkAnw/yxvMmT8IsWKRyAxE/moCgHQOEZXrwgcx1kX6ItHd9gWTBuE2bUwLwMbHFrvzrVzRb4JlHTe0k4/0bD9oUkrmCzlZ1tLabqYV1XYpVF787zsX2HaDAZgqIFsKIF6ZonqmzBVTROYQaEp6wvUqwb0MNmykS3CgLhBeOtvmPx1BQCaFjrDTKQ5OgClWa/xvvxRt8QIBlQfBP2KtkM/mUUS2Rbmxl8har+JdY1xN+TxeQNsjONkvE7jKB9vz6dgG+5yrSZ5a2+9/RXtTgZfkTX6fxog93xjtV55I7Pod+fgk4++htsWDgrQJLBL9oS9foASY0T4iYX58g0l8ABwQt9CG/A3PbZM5ONHv77GKb6M84UNgBIUCUA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(2906002)(86362001)(26005)(5660300002)(55016002)(71200400001)(186003)(52536014)(478600001)(83380400001)(54906003)(8990500004)(110136005)(33656002)(966005)(7696005)(10290500003)(4326008)(66476007)(9686003)(66946007)(6506007)(316002)(82950400001)(38100700001)(8676002)(76116006)(66556008)(82960400001)(64756008)(66446008)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?bzhzengwL1owbFZwNlQzUWZLeFQvMk5wQWhjNitFM0g4clZEdVpHTUgvSEYx?= =?utf-8?B?U1JjWG9jRENpUjd5RzZvck1vK0dQUDFYdkQ3MjB1WFZBZjd5dzljeWpJNWZE?= =?utf-8?B?Yk1taXdhbmREM0VlZGYwSDNQQUh4cWp1NjUxOWRhVUVhbDZaR0RBdmVCQytB?= =?utf-8?B?dWloYkFxVCtLdHA1N3g3QnQ2NFFwRHY5cVhHSWhDVC92OUhQN3J3VzEvRnRG?= =?utf-8?B?N2FKWWhibGI5RXdzYnBzTWJROXRLcWtRMnVRUHhucDN3eEpJNUlvRTRyMWFC?= =?utf-8?B?czNpQnUwOUNTTXE0a3NMbFFWaEhRWFpkbU1INmVsMDhBM1Ixb0d2ek9icHFS?= =?utf-8?B?bkg3NG5yQXBMdWgzdTZXNlRTdmNqamhoZEhKUWpjT3NPQ0pnVEJQaUg5RjYx?= =?utf-8?B?TVJ1b2xYbWZmaHlLR2EwSGZpVjczdlplaURNd1o3aUJ5dlVMYmdGVWNoSDdm?= =?utf-8?B?aysrZm92bXhiL2FxSy9JRG9oMmdLZlJuVzIrRm9OdWZEdEgyMk11SjFtZ2Mr?= =?utf-8?B?SFNnMlRCREpQV0pESHFEWTFPTWtnNkZuWGVMVERnM2dnZXYyNnpPUHA0Z3hV?= =?utf-8?B?ZTVqOU43cGtFK0hIVnk5d2xqNnZBRTB3R0xQVDFEMk0xclZrT2F5TlhnK2Jp?= =?utf-8?B?bHZBMldLVEFmdDNjNnEvUkQ2QlN3U05PV09mZTNybTdtRXV3MkdDYWVsZWRO?= =?utf-8?B?Qnp6eW9KMTFld3Npc0VYZUVESDZLZ00rR0l3dFRpK0xVVzZoUDVYQWZEZXpC?= =?utf-8?B?ejVDNWM1Wi9WUTJtRHd4R2krakxmMjRJZmtFQmxCaWk0TUJnalYxNFhORTNt?= =?utf-8?B?eDBFanpjdy9YWFJVUkNjZEJhZnpRVXlSVnNVbWJjb3d2RlpoS1p1Zk1pK25J?= =?utf-8?B?eTlmdmw1Ykw0dTJ1QmVCbVNIN0pBNUkzSDRNT1ppR2huaXcrODJUK1dObTlz?= =?utf-8?B?eGUwZDlaM2hPWVBJZGtzYjlGQ2RQNjJSR21tZHVjQlJkRDgwNGxockc1Rm5Y?= =?utf-8?B?LzNvcHdMR1psaGZpM2hDQjFjbStQTkFjSnl4MVVOT2NNRVkzQ0Z2TmVwM0t4?= =?utf-8?B?Z0llTEE5N0JaalZQbVNqNmdkTS9rWWhTOVNRZjhneWN1TVJoYk5qSjA2WUZX?= =?utf-8?B?b1hNaE5LWHhlaVF1UngrOHdVUWtKWmowMlJCSkhLVUg4ckpkVWZMMWxYcEtS?= =?utf-8?B?ODRTUmlaM2RIZDA4RWhmWXhyd2pPeSt1ZTkrMFQyaU8zSnptL3RUWU93NWRF?= =?utf-8?B?SGx5WXVnWEYxQlB3VDVCRU5TMkQxdWpaODZiSWlKYXpUOVpLQitzanhqTk1a?= =?utf-8?B?TVNSMVYwZXg4OE1xY0R6TDBzNnhHdmxpempvYUE4cFVnd0Zha1BIbTJWQkNJ?= =?utf-8?B?c00zZUVHSjdzR2tjZG54bEYwMHExN2VsSit0K1hOcWxXMS9Sd3NORFczekdV?= =?utf-8?B?OW9GbGhkOU9ybGpiRXdDNFlGYytDbHIydW5aR3pYb2FkQ0RpaWpBcm5RV3VK?= =?utf-8?B?UjRLVWpJbXVET05BWU85RFRoWVc5RHE2ZE9ZcEhwRXpYUzRGZEVIc1VGYkRW?= =?utf-8?B?ZjVEY2R3WFNJMXY3RGxaNUFXU2tPbXZTbVhwaDZIMzhXSXVqNU82dGl5NXo3?= =?utf-8?B?VU5uOUVxTmQ1Q1RHZEdGd0J5Rks0VVhtcDN6OXB6QzU3K1JQVkIxd0NFOFlv?= =?utf-8?B?WjE5dW9QVmFac3ArWHVaRVRrbnRPVHF6c0dHaTFHbHdYQUgvL1dwdG1SZEtr?= =?utf-8?Q?v0N53bz7S9kSUV013Pbg5pUk6bEWGPGnZKPQy5B?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0367f5a-cccb-4fa5-7a09-08d8fa490729 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 04:44:43.2180 (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: 9iGB0wleU9jRizcNXFmgEnR96fYXHLdLx2rXFH6cE9Tw+BatctSX0a2AJRB/tOv1lVYF4MX0kpraHTQZFFHYTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0751 Archived-At: Subject: Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 04:44:58 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgTWFydGluLiAgV2UndmUgcHVibGlzaGVkIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMyB0byBhZGRyZXNz IHlvdXIgYW5kIG90aGVyIElFU0cgY29tbWVudHMuDQoNClJlc3BvbnNlcyBhcmUgaW5saW5lIGJl bG93LCBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTWFydGluIER1a2UgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiANClNl bnQ6IFR1ZXNkYXksIEFwcmlsIDYsIDIwMjEgMTI6MTMgUE0NClRvOiBUaGUgSUVTRyA8aWVzZ0Bp ZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcUBpZXRmLm9yZzsgb2F1dGgtY2hh aXJzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzsgSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldA0K U3ViamVjdDogTWFydGluIER1a2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1q d3NyZXEtMzI6ICh3aXRoIENPTU1FTlQpDQoNCk1hcnRpbiBEdWtlIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzI6 IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0 IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGlu IHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3Lmll dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpU aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv dW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9h dXRoLWp3c3JlcS8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCkFmdGVyIHJlYWRpbmcgU2VjIDEwLjUsIEkgd2FzIGEgbGl0dGxlIHVuY2xlYXIgaG93IHRo ZSBjbGllbnQgYW5kIGF1dGggc2VydmVyIG5lY2Vzc2FyaWx5IGFjaGlldmUgaW50ZXJvcGVyYWJp bGl0eSwgYnV0IEkgdGhpbmsgaXQncyBqdXN0IGFuIGVkaXRvcmlhbCBmaXguDQoNCklmIHRoZSBz ZXJ2ZXIgYWR2ZXJ0aXNlcyB0aGF0IGEgc2lnbmVkIG9iamVjdCBpcyByZXF1aXJlZCwgdGhlbiBp dCBjYW5ub3QgY29tbXVuaWNhdGUgd2l0aCBhIGNsaWVudCB0aGF0IGRvZXMgbm90IHN1cHBvcnQg dGhlIGV4dGVuc2lvbi4gQnV0IGlmIHRoZSBvYmplY3RfcmVxdWlyZWQgbWV0YWRhdGEgaXMgbWlz c2luZywgdGhlbiB3aGF0IGlzIHRoZSBtZXRhZGF0YSB0aGF0IHRlbGxzIHRoZSBjbGllbnQgdG8g dXNlIGEgc2lnbmVkIG9iamVjdCBpZiBpdCBjYW4/DQoNCklJVUMgdGhlIGFuc3dlciBpcyB0aGF0 IHRoZSBzZXJ2ZXIgbWV0YWRhdGEgaW5jbHVkZXMgdGhlIHJlcXVlc3Rfb2JqZWN0X3NpZ25pbmdf YWxnX3ZhbHVlc19zdXBwb3J0ZWQgYW5kL29yIHJlcXVlc3Rfb2JqZWN0X2VuY3J5cHRpb25fYWxn X3ZhbHVlc19zdXBwb3J0ZWQgcGFyYW1ldGVyIGluIHRoZSBtZXRhZGF0YS4gSXQgbWlnaHQgYmUg aGVscGZ1bCB0byBzcGVsbCB0aGF0IG91dCBoZXJlLg0KDQpJcyB0aGlzIGNvcnJlY3Q/DQoNCk1p a2U+IFllcywgY29ycmVjdC4gIEkndmUgYWRkZWQgdGhlIGNsYXJpZnlpbmcgcG9pbnQgdGhhdCB5 b3Ugc3VnZ2VzdGVkIGJ5IGFkZGluZyB0aGlzIHBhcmFncmFwaCB0byB0aGUgZW5kIG9mIFNlY3Rp b24gMTAuNToNCgkgICAgTm90ZSB0aGF0IGV2ZW4gaWYgInJlcXVpcmVfc2lnbmVkX3JlcXVlc3Rf b2JqZWN0Ig0KCSAgICBtZXRhZGF0YSB2YWx1ZXMgYXJlIG5vdCBwcmVzZW50LCB0aGUgY2xpZW50 IE1BWSB1c2Ugc2lnbmVkIHJlcXVlc3Qgb2JqZWN0cywNCgkgICAgcHJvdmlkZWQgdGhhdCB0aGVy ZSBhcmUgc2lnbmluZyBhbGdvcml0aG1zIG11dHVhbGx5IHN1cHBvcnRlZCBieSB0aGUgY2xpZW50 IGFuZCB0aGUgc2VydmVyLg0KCSAgICBVc2Ugb2Ygc2lnbmluZyBhbGdvcml0aG0gbWV0YWRhdGEg aXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4NCg0KCQkJCVRoYW5rcyBhZ2FpbiwNCgkJCQktLSBN aWtlDQoNCg== From nobody Wed Apr 7 21:46:11 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660663A38FB; Wed, 7 Apr 2021 21:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tFdYcyKtJzjJ; Wed, 7 Apr 2021 21:45:06 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640112.outbound.protection.outlook.com [40.107.64.112]) (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 0A8963A38F9; Wed, 7 Apr 2021 21:45:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gz3UNQymYpvgiP60ZCzxK8ZeEhaqP+/65xGro6e75LgcdfHWhH6Efp6FAI2Dmqz8xWN5vSKLe20RNLr3jN6AtQ3+O7HBERyFijtlvbJvAOjdjxq4vSU7v4MCEpF8+nXx4pPJ+0ccVKwUjyqonpN59ohFlyZNiYB34f2LHQOZ2Ju3fCQ69xH/Dcz4aB5Xgkd0iJGHsaywCz//jNP6rs/CDKcr84l2QlogRBDXoSz6q0w90lFRP/IvUOtq5oZAmY+/Sk04FxkNfUTnqeRfRP4/sBQKYsL31fiiM6AwRV1CKeikgZgu1i3bk8spzoLSLAeWOaye2bpr3gS0Kf5imDrF2w== 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=Q0GvpO2Hy3DjHZjlXOVIG/B2xalvtwJ/6eOxPGWiFGg=; b=jRiRFQKlIszfR8QqPbpebTekgozdhc7EPB6+esJR7mHGoVlLxtZcWmps0B6XiUsWcfSPf4/5z51emfEDy0y/pl6S4509u8zmI5MdtcZdAeiab+mmZbWUPpL4VWvrrUCzqqxFU7CmBMIKaXBbkGg1c4r+LvjRU82vruExN4Jp4cYf6fyd+/6sRGSNjtQVsxg+1LkYMIhCkVPNyJdFgWpl1LBm24epGG+yT3abRziCYgkU5jhRPbukgGVGwpW5wlK1C6dxi/VxRZhBbzJkFnuDJ960k0DTCf1k6oh6KtjTli9ncLUTw5QxHtZRZj7uxVzKtZkn14WLw0o/K+7ItLxLDw== 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=Q0GvpO2Hy3DjHZjlXOVIG/B2xalvtwJ/6eOxPGWiFGg=; b=F9NKcr0/axCG7g0ttv5kHhZ09pYRNFwp6mV5CL8cOr3oAMF8chEm3fk44p20zowU9jPeG1LW8qz/z0kWtTc8uwVKButZcXIMCFqGdiVj4TYc7VxB03Ioh+/e1o4FRUZHSqi7+T9k0P4awoQkJ3m3fJYcZaOy8YnTLrlccpO5hbo= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0751.namprd00.prod.outlook.com (2603:10b6:5:1be::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4056.0; Thu, 8 Apr 2021 04:44:59 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 04:44:59 +0000 From: Mike Jones To: "francesca.palombini@ericsson.com" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMekdJv5IcULvQ1qzavuY873M4w== Date: Thu, 8 Apr 2021 04:44:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:41:17Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cdfb0104-3004-44ad-80cf-5c9eac18df57; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.56.42.184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14cc71dd-cbba-4be5-acfd-08d8fa4910e5 x-ms-traffictypediagnostic: DM6PR00MB0751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C9zHeEUctsZiKYkcPuOdfjMvPgabIiMTwwlGNtFBTF3O69vNW4rLXjEU2tsJtDuTzlTKqzbVIoxwSjY8fs1nQ5S7WF/MYrNfa9P+G1gGSwJBsvmLCyEqX5bpceluofxZvpB/kGGJCXhmk8tJkV2ulDuykuBhLRzhV5mqnXhf/Scfe81+e75kE6SvoNI0hhIQbgFyTQUHBI3s745dwmybtvRSpQN8jjcBGuFL1kEztbLa+rvRzFvFItw8a/rHi15ppLRLpe4tJGjv/GZDdkdf5uhdHdUOt+cHHXx7iYU7Fo0MdBzIrP4lar/lIzkFo9jyWhx3hVd70IIm3HXy/NkIChDg9jcTzPTTsUl7mJMq7WGqgQ8XeRYjjcH2JhGAs0HE6sIc6GUoDImRN2gUZRb7w/WpLIas5Hv5GU/bfDVCBN77US3092UH4DFntqZh1hWGZaAxV+HP5Kurob0ATU03FfLoDWtcBGTfK6YQbdfS8zGEy0BFqYuLKluXBzYNrcO2kHVb0/4q9nx0WQq5uwmOsnfwj3JpnKgeweXsA5FVlu7zWBTnl1djz/rst8zTAI74LO+SmkkM+KzzZjlUqHYEqXM7EG7GAIxbKs0OBvx4pp1ABKin3FmRWFCr+130JvPTQvQV39P5Q+qHiz1M0DuVwRNxer89fSkAdRneENj+rG1K0N65oAR1vNrWrJ6J6M38OdROGdt1zmeSmwlbaACXGyN9GDyr0JLM9bUJb9abUss= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(2906002)(86362001)(26005)(5660300002)(55016002)(71200400001)(186003)(52536014)(478600001)(83380400001)(54906003)(8990500004)(110136005)(33656002)(966005)(7696005)(10290500003)(4326008)(66476007)(9686003)(66946007)(6506007)(316002)(82950400001)(38100700001)(8676002)(76116006)(66556008)(82960400001)(64756008)(66446008)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?dVppQXlqcVM4M1d4bGtQVlorZEVmOHZTWGxnNFg1WVZNM1RrdHNsY3ZFZGhG?= =?utf-8?B?M1JMRjhmcGN0cytMUjlvcFcyNGxPZ01Ja3IrK0R0Y2ZpWEQ1dTh1VzFyQm50?= =?utf-8?B?K3c5TkhVSE9HS3A2RzZYNFNTRnh1Q0tmU252WnJOUGwrWkJXU1A5dmx4R2Vp?= =?utf-8?B?RnZ2cFVyNVlFK2ZYRkF0NlhrMUkzM3VEWEVtNkhmd1dqRCtqY29TMkVEUjVy?= =?utf-8?B?UmdDUDV0K3FDcXVyakl2SGhFWjgwaFB0SkxOWmU1Smt5YmdwN29UbC9qWnN5?= =?utf-8?B?cnlFZW5NVWt0anpRSE8xcVZKYTRSWkpRbEpxTXpGclh6WTUvdjJ0VXFpOXhk?= =?utf-8?B?SzFNUU5oT01qS1VVdFRzeEJaRmM3V0Y5YTlEYlhxbS9zbWpNeElBR0NTak1C?= =?utf-8?B?T0R2c01Tc2N5ZXF0c2V1c2RrWG5odmxaZ0N2YThpNHJyTjIwdEtxL0JIRGtO?= =?utf-8?B?MU56Q3FPMG4yMCtaUjZQTUUvZVhNVEI1cVQwTTVPeGVDRlZuMGdOWVEyLzZH?= =?utf-8?B?R1RJK1RUeklGNm4rVkZneFVmbnkwVll4empLV1VSY0dCd0RnQkJ3K0RWZ3d5?= =?utf-8?B?KytmV2ppb0JTMXRDNlc0QnI0cWJrTmkvUTk0c01WOExrQXBEZjhRSFZKMGw4?= =?utf-8?B?UXY2a3lTTi9WZFRyR0hySGFJTXZYWXFOcVlQcHl2enhwQ1BXd3BueHJRT0FP?= =?utf-8?B?VmxiSTZpMTBHdk11STBmazFZUXBYNzJsUGE2Zjh5QStYOUN3aXJBcnJ4R1A2?= =?utf-8?B?eTJnZklLektGa09yMDJsV3RIZ1o3NlVTL0Vab1lvOXk5bks2U0hSeWlOUEZL?= =?utf-8?B?clVMVXY5V3dYSnZLMnNyRWhzbXplV3Z1SDBHM2VrWHdKWHIrTkE4ZnozbGND?= =?utf-8?B?TnJUODJncEwxOVdMeDl6S0VOOXVQYU5DLytxaTdMVXdaR3A3d1RoR3RubVQw?= =?utf-8?B?OEZ4SGxGd2g2Z1VpSk0rMnBuSjVBWTJxZWplTmFzb1JrSHRtTzgrbmZJNmdF?= =?utf-8?B?YjI1VW1odlNpU0dzd1ZlZDBrRjlpSVRhQzBVQnMrUllnNXlJeFZGS3M0M1Fw?= =?utf-8?B?MDM5dUVleW9sYTRCK0pmdVJkcE43d1dvTkIzYWxNelNINWNDbWZqd2oyVVc0?= =?utf-8?B?VnZBRUVZMEpiVjBweW0rNmRaRTVzMXZzZDVFbmN0RmZYNmxWZ1gwcEpmTUpj?= =?utf-8?B?NkNZdW5zMy9uZU1ndVBaMmxOWkN6UEU4cVlxZWdBeWp5dkZMS1R5VUtvRHhR?= =?utf-8?B?VEFSRmFHVURpZms2aU5OWVBxcDc4RkRFWWdKalgzYXZwSmdWZTd0NllFeVQy?= =?utf-8?B?ejZqNWFJSzJjWjgvQzk5ZmVVbituK213aEEzSTl5alNJb24yV2p5R0tLYXRV?= =?utf-8?B?RUQwQzVnS013cHduOVhtZzVGaHJSNkp3VkRLVmUwYkZHemVDSWtKSktwSGR3?= =?utf-8?B?bDFoK2YxVTE5NGpzUk9ZNEU0U0M5dnR1eVR2eHNCYVlzRWpxNEVuWmVSa3RI?= =?utf-8?B?SFpvL2VaK3AvS2lPY2RsdCtzTUNHRnZ1QVZwakZ2YVlHWTdhM1dLUk5RVWpB?= =?utf-8?B?UTd1RDR3MW9TUktOMEtiU0J2bVE2NkYzK091L1BQTGxDanVrejZ1YnNBSnd3?= =?utf-8?B?RWdHeFI1R2ZKa25va05vbkhFNkl0KzdOMDl4bXlkNFRmRmo5MkZnVmhZL3di?= =?utf-8?B?clZ6RWoyRnB3N1JOd2VxamxjMkZIMU9sejZwQUpPeTRTZy9YZmRNK2NXbGh2?= =?utf-8?Q?MQnxFWxI3tK4v62LinPeyQPqN9qr/jJHo29ViyK?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14cc71dd-cbba-4be5-acfd-08d8fa4910e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 04:44:59.4340 (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: hRvdDc8F3aiV6d8mUBmOYhw/8w5YQxUuqG5yIEw3PZrHWQvNcQPgb2Wxbg/ve4mGwTDEIAr+1j+EtIOAFpTLYw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0751 Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 04:45:15 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgRnJhbmNlc2NhLiAgV2UndmUgcHVibGlzaGVkIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMyB0byBhZGRy ZXNzIHlvdXIgYW5kIG90aGVyIElFU0cgY29tbWVudHMuDQoNClJlc3BvbnNlcyBhcmUgaW5saW5l IGJlbG93LCBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogRnJhbmNlc2NhIFBhbG9tYmluaSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0 Zi5vcmc+IA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA3LCAyMDIxIDM6MjkgQU0NClRvOiBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcUBpZXRmLm9y Zzsgb2F1dGgtY2hhaXJzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzsgSGFubmVzLlRzY2hvZmVu aWdAZ214Lm5ldA0KU3ViamVjdDogRnJhbmNlc2NhIFBhbG9tYmluaSdzIE5vIE9iamVjdGlvbiBv biBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMjogKHdpdGggQ09NTUVOVCkNCg0KRnJhbmNlc2Nh IFBhbG9tYmluaSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN CmRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMyOiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25k aW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxs IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBs ZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNz LWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEvDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFuayB5b3UgZm9yIHRoZSB3b3JrIG9u IHRoaXMgZG9jdW1lbnQuIEkgb25seSBoYXZlIG1pbm9yIGNvbW1lbnRzLCB0aGUgbW9zdCBpbnRl cmVzdGluZyBpcyBwcm9iYWJseSA0LiBhYm91dCBpZiBhZGRpdGlvbmFsIGZhaWx1cmUgYmVoYXZp b3Igc2hvdWxkIGJlIGRlZmluZWQgYXQgdGhlIEFTLg0KDQpGcmFuY2VzY2ENCg0KMS4gLS0tLS0N Cg0KICAgQSBSZXF1ZXN0IE9iamVjdCAoU2VjdGlvbiAyLjEpIGhhcyB0aGUgIm1pbWUtdHlwZSIg ImFwcGxpY2F0aW9uLw0KDQpGUDogUGxlYXNlIHVzZSAibWVkaWEgdHlwZSIgaW5zdGVhZCBvZiAi bWltZS10eXBlIiBhbmQgcmVmZXJlbmNlDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NjgzOA0KDQpNaWtlPiBUaGFua3MsIHVwZGF0ZWQsIGFsdGhvdWdoIHJlZmVyZW5jaW5nIFJGQyAy MDQ2IGZvciB0aGUgdGVybSAibWVkaWEgdHlwZSIgKHdoaWNoIGlzIG5vdCBzdXBlcnNlZGVkIGJ5 IFJGQyA2ODM4KS4NCg0KMi4gLS0tLS0NCg0KICAgVGhlIGZvbGxvd2luZyBpcyBhbiBleGFtcGxl IG9mIHRoZSBDbGFpbXMgaW4gYSBSZXF1ZXN0IE9iamVjdCBiZWZvcmUNCiAgIGJhc2U2NHVybCBl bmNvZGluZyBhbmQgc2lnbmluZy4gIE5vdGUgdGhhdCBpdCBpbmNsdWRlcyB0aGUgZXh0ZW5zaW9u DQoNCkZQOiBUaGlzIGV4YW1wbGUgaXMgdGhlIGZpcnN0IHRpbWUgImJhc2U2NHVybCIgYXBwZWFy cyBpbiB0aGUgZG9jdW1lbnQuIEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB0byBtZW50aW9u IHRoYXQgYmFzZTY0dXJsIGlzIHVzZWQgd2hlbiBKV1QgaXMgaW50cm9kdWNlZCwgZm9yIGV4YW1w bGUgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQuDQoNCk1pa2U+IFJlZmVyZW5j ZSBhZGRlZC4NCg0KMy4gLS0tLS0NCg0KICAgSWYgZGVjcnlwdGlvbiBmYWlscywgdGhlIEF1dGhv cml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuIGFuDQogICAiaW52YWxpZF9yZXF1ZXN0X29iamVj dCIgZXJyb3IuDQoNCi4uLg0KDQogICBJZiBzaWduYXR1cmUgdmFsaWRhdGlvbiBmYWlscywgdGhl IEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuDQogICBhbiAiaW52YWxpZF9yZXF1ZXN0 X29iamVjdCIgZXJyb3IuDQoNCi4uLg0KDQogICBJZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhl biB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4NCiAgIGVycm9yIGFzIHNw ZWNpZmllZCBpbiBPQXV0aCAyLjAgW1JGQzY3NDldLg0KDQpGUDogdmVyeSBtaW5vciwgYnV0IEkg c3VnZ2VzdHMgeW91IGFkZCAidG8gdGhlIGNsaWVudCwgaW4gcmVzcG9uc2UgdG8gdGhlIHJlcXVl c3QgZGVmaW5lZCBpbiA1LjIuMi4gb2YgdGhpcyBzcGVjaWZpY2F0aW9uIi4gVGhlIHJlYXNvbiBp cyB0aGF0IHRoZSBkb2Mgc3BlY2lmaWVzIHRoYXQgdGhlIEFTIG1pZ2h0IGJlIGhhdmluZyBvdGhl ciBleGNoYW5nZXMgKHRvIGZldGNoIHRoZSBSZXF1ZXN0DQpPYmplY3QpIGF0IHRoZSBzYW1lIHRp bWUsIGFuZCBpdCBjYW4ndCBodXJ0IHRvIGJlIHByZWNpc2UuIEFsc28gcmVnYXJkaW5nIHRoZSBy ZWZlcmVuY2UgdG8gUkZDIDY3NDkgLSBjYW4geW91IGFkZCBhIHNwZWNpZmljIHNlY3Rpb24gdG8g cmVmZXJlbmNlPw0KDQpNaWtlPiBEb25lDQoNCjQuIC0tLS0tDQoNCiAgIHNwZWNpZmllZCBpbiB0 aGUgImFsZyIgSGVhZGVyIFBhcmFtZXRlci4gIElmIGEgImtpZCIgSGVhZGVyIFBhcmFtZXRlcg0K ICAgaXMgcHJlc2VudCwgdGhlIGtleSBpZGVudGlmaWVkIE1VU1QgYmUgdGhlIGtleSB1c2VkLCBh bmQgTVVTVCBiZSBhDQogICBrZXkgYXNzb2NpYXRlZCB3aXRoIHRoZSBjbGllbnQuICBBbGdvcml0 aG0gdmVyaWZpY2F0aW9uIE1VU1QgYmUNCg0KLi4uDQoNCiAgIHNhbWUgcGFyYW1ldGVyIGlzIHBy b3ZpZGVkIGluIHRoZSBxdWVyeSBwYXJhbWV0ZXIuICBUaGUgQ2xpZW50IElEDQogICB2YWx1ZXMg aW4gdGhlICJjbGllbnRfaWQiIHJlcXVlc3QgcGFyYW1ldGVyIGFuZCBpbiB0aGUgUmVxdWVzdCBP YmplY3QNCiAgICJjbGllbnRfaWQiIGNsYWltIE1VU1QgYmUgaWRlbnRpY2FsLiAgVGhlIEF1dGhv cml6YXRpb24gU2VydmVyIHRoZW4NCg0KRlA6ICJNVVNUIGJlIGEga2V5IGFzc29jaWF0ZWQgd2l0 aCB0aGUgY2xpZW50IiAtIHdoYXQgaWYgaXQgaXMgbm90PyBkb2VzIHRoZSBBUyByZXR1cm4gYW4g ZXJyb3IgdG8gdGhlIGNsaWVudCB0aGVuPyBTYW1lIGNvbW1lbnQgIi4uLiBNVVNUIGJlIGlkZW50 aWNhbCIgLSBpcyBhbnkgZXJyb3IgcmV0dXJuZWQgaWYgaXQncyBub3Q/DQoNCk1pa2U+IEkgYmVs aWV2ZSB0aGF0IHRoZSByZXNwb25zZXMgdG8gdGhlc2UgdmFsaWRhdGlvbiBlcnJvcnMgYXJlIGFs cmVhZHkgZGVzY3JpYmVkIGluIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoLCB3aGljaCBzYXlzICJJ ZiBzaWduYXR1cmUgdmFsaWRhdGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1V U1QgcmV0dXJuIGFuICdpbnZhbGlkX3JlcXVlc3Rfb2JqZWN0JyBlcnJvciB0byB0aGUgY2xpZW50 IGluIHJlc3BvbnNlIHRvIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QuIg0KDQo1LiAtLS0tLQ0K DQogICBsb2NhdGlvbiwgKGIpIGNoZWNrIHRoZSBjb250ZW50IHR5cGUgb2YgdGhlIHJlc3BvbnNl IGlzICJhcHBsaWNhdGlvbi8NCg0KRlA6IEZvciBjb25zaXN0ZW5jeSwgcGxlYXNlIGNoYW5nZSAi Y29udGVudCB0eXBlIiB0byAibWVkaWEgdHlwZSIuDQoNCk1pa2U+IERvbmUNCg0KCQkJCVRoYW5r cyBhZ2FpbiwNCgkJCQktLSBNaWtlDQoNCg0K From nobody Wed Apr 7 21:46:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CEB3A3923; Wed, 7 Apr 2021 21:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pFWkfDBbjP05; Wed, 7 Apr 2021 21:45:22 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650121.outbound.protection.outlook.com [40.107.65.121]) (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 E4F3C3A38E8; Wed, 7 Apr 2021 21:45:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QOCpXIssr6yr0PBlPoYJPFql3+osl4h6uVyIuPFcodglnPqubTbn4uXfEiGIdGPKtob/Ca/eqJL0JIr7AX1Nu8p4Bnh8Vc8kwefjKHc8CWf/kEv5Wi+7VCTQN7hBBP358KwB3BrBoN5xS4oP6s/AKT96Z+BSRnLQOsj8dPhcjrRjFgNA6FjWD/h83dj1OUq5u7NtkLkktpiJyCdEycF578JBKE3uBEHTedXesDp8r68jYxHzy3C2YjcXcq+tSidNzyzfRUvXjfn9diKMxJP0CQSbVtrvMgERG39sS/GsA7Rs8d7nnWw9lBHBcFLpviNV9Rd7rBb9tAPjdzrgq55PsA== 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=/biIXCMthW3FrJsz45WgnJqgwmqTX6X3p5W6uuNrVcM=; b=hVJceHlrlKYAGe9bi4OI6Gd8XxCj8gdveLlG9548u2TlhheCs8OJy8xY+yiH9psfN6rU7BFJufDgTF4Jw8lWf1/JyvSYjOJ5ViQT5nPZmb4Ol0+9L7p7BPdS1wpoVjOqDt5hmoDvEM45hj0ETdxLSs8O8d+cXrRCZ9WBddbf7A5NwK4PzEEq8Z/uKaJ+//u6PGE+28t/t+ZZjjnwhMce4aoWUPQbqzCjL27bRY1mSP4hMi/3GEp2oLtge4woqlmZhHUqZuqNjzyUqG51P9/j3NJ7sov/h/zpQyS5cEefVX5yKUzFGOkB/g4gwv7bUH9kDFTx3VUk95acaY6kNumqxw== 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=/biIXCMthW3FrJsz45WgnJqgwmqTX6X3p5W6uuNrVcM=; b=I34zao+UrsDecAz7rujW+B+jYDN4TUNIZqQWISy+R5oxvm5gYgT1gKlPoZAoI+1Z22GtCwxXBBf6/mxVFzkNYOW/oI4XKASAdhc/coIJ4m98ycjgPplqMTMWcvPx7nXRbweJ/pUBkUVdOe8Dllm+d97W3wukSK/LH2AvPK+g34w= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0751.namprd00.prod.outlook.com (2603:10b6:5:1be::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4056.0; Thu, 8 Apr 2021 04:45:15 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 04:45:15 +0000 From: Mike Jones To: "kaduk@mit.edu" , "iesg@ietf.org" CC: "oauth@ietf.org" , "oauth-chairs@ietf.org" , "draft-ietf-oauth-jwsreq@ietf.org" Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMfO/NEOxoPc0Q7+XxyHrniar1Q== Date: Thu, 8 Apr 2021 04:45: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_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T03:26:52Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6c7997a7-2d38-4338-9da6-27affa75a2f8; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.56.42.184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de30a62f-2a08-4b18-4cbf-08d8fa491a57 x-ms-traffictypediagnostic: DM6PR00MB0751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rEqIW0PvIR78MIRxsZySegbkEdG2/Q1tH+JjyB53mBgQ3NlNcJKIN+ivFqbEXAYzbDKMSHSwIzMNLzxKEPgIyKeljg977Y+t8niKopedg0bp/s2fnZ64fflMTtHmEUlPGy495unJZalZqo9CRVNvYO4xVLT3LeH8ceikT6PiSVAdG+7XSJfwxWmor2EXBPobg9Pkw5dJHT/CZGVgBpQl0LHTgIpPOdpxbEvQuk5SKmV21AqjYi0gtBjdiB9fKrUtI37i9yEyXML7q2qORPQ94zbBOiUqK0VAO5SpJtIoUR2duZ9UgnsqWSMkKGlnCVNPeNMX847kZVCpoHaEGFxbRsjNMR0W5ZJIb3ACDv81+oDNkwX1Ael12TSXyMqRMWqtVW3donNc8FoefEjtrE0+6bvkL5wfnaaZ0WKTyPtH319gnciX5zSlodUrEmnyzINR3bxLniE8byAr+P6j+KPHgv+nzKWOpNgC/RDO68bFjagGTWAc5srERKm3PRAlr244kdLG5mZoh+4weJ1vQZ4f9KVo0Yw6f/mCGuDL4gZpUWyRxhI+ilyVYGH4f/dK42Nw+W/peTqXAkeDs0kQxjzIz9I0VK4F14ROI09hqNa2rybV3SCdBOzgo0FvMEGFHc6bJGjUz0P14ccmu10l1DfQnTCR8TxqEHAsauXu44SOwUzr4VKTZfC2mURunIpCAgvM6rnoTXHsjYDFB6IN+ns1fGWdgIm+/dppqX/tfgxzFpU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(2906002)(86362001)(26005)(5660300002)(55016002)(71200400001)(186003)(52536014)(478600001)(83380400001)(54906003)(8990500004)(110136005)(33656002)(966005)(7696005)(10290500003)(4326008)(66476007)(9686003)(66946007)(6506007)(316002)(82950400001)(38100700001)(8676002)(76116006)(66556008)(82960400001)(64756008)(66446008)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?1pQdqBa8npGvczXupJER9h1A183+ewpuSOu+oaha4p7ugYH6FUrKPXrTiugc?= =?us-ascii?Q?gaG9akJrsMyZ9Xg98A2pFlC1blSTQPoIShm9s2Iufr2wkBXlPtmi9qZ+zPm5?= =?us-ascii?Q?n22XTbxmISEwj26NYXFFns4hprDu2+bY3m9UXOCFDXCDjlQI47xy2mK0z8qF?= =?us-ascii?Q?g/iZpHz5NxnHKyVBIaWq0eQ6YuFxz3VkkTXvMzgUzvN9JyP/Ie8W2c0Jq48C?= =?us-ascii?Q?X33cDtDysp7k86Uh+hmdH/DOvYQjxO6fxmKAoEofLUj8pQmzRdWwH6JhgSh7?= =?us-ascii?Q?Xmkej4GV9jruAqA8owRH+ZNmjaXCpJ7xq4R+yuLp5VLAYtkytXBYxPqiQQMh?= =?us-ascii?Q?8pBGsFsQ/miTEE/OkVl8rpmtt193nngP00Wl7BJxS/neGGnfjHkzG+7Kf6B8?= =?us-ascii?Q?rQLCQWgZedkI8LfJtW5CB2Y86VbJJSteR3oynQ+e7YNq4k6j/kpcxAvA/1g9?= =?us-ascii?Q?0yohBLdmSyswMhtbwnVHLpK5vfvr48QV8vy81mVtrF49xm9vxbc/WKHhsdNt?= =?us-ascii?Q?yk7EiFt41DmTU4x1si37YoZh1giwyCK8d2YP1A13qNeaYy59Pvvf6ZM8o+UI?= =?us-ascii?Q?9pNRReodohf0FK3Xg+EOCt1wahNC//Pnqj6ar9FzvbnDb5fRe/GFadN4Siq9?= =?us-ascii?Q?rSJXDATyA3OyxmnLllla0xXt1U12WMlgRlJYfL9uciEGEQnR7I2NGT6IdrRt?= =?us-ascii?Q?xzlAiDslFqN/bGM998y3o6QFMPLt2vryZYZWtmry/qr0L7iwRh0xO3hzTREj?= =?us-ascii?Q?B1Jdio37dAwzVZuT8+yiNU/bdYmjJ8zrgp0oLt6dsgcN0KfoyFBnFZ+9y+6+?= =?us-ascii?Q?F5XVOi5gxTc1gIgHh7SLJAST5Sz4ePypof96LXvhQ/4ZnEmUt7mD/yy2J3tW?= =?us-ascii?Q?+8eetnFt6rIfWUi9uAB86/LIifEV9eZuxB8DAShOvrXxEB8xr1BTE4q83G4G?= =?us-ascii?Q?A5A3yWwHt8cciCHQrjscG+JsEMuc7gUku3F2VW+F7x5muyW+6GMYrWXj821u?= =?us-ascii?Q?quTRgHsGcSja0ozKmH/1H0z9ED++yZPhTSfJh+88Io7hC95FC0KrPL+arpMs?= =?us-ascii?Q?2tWJ6vAAyG0FYfCd5wWoOiKxkQqF3bRKOSzzphrl69PnYQu/cqF31PBqahe4?= =?us-ascii?Q?W1atnoMGmhQrHLEP5ccDFMHwtuy+XBRaai33YxN9d4dXpu3MI5auyy6lAvuH?= =?us-ascii?Q?TOQ5KT64BWj59ZI0l75iE/Ey4xAai6O/2fp7/CHxV46KkbMrfe+w8mNCU8ZM?= =?us-ascii?Q?TA73k2RD794Kij1u7hy3HMwfuX+hVVaXtnWaoC+awGjTlRO6UMCwLr2LeTr1?= =?us-ascii?Q?Br1mdoJJsc2F392wFr2LbgVz?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de30a62f-2a08-4b18-4cbf-08d8fa491a57 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 04:45:15.3431 (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: OCVUabnqBc7l0iqrffY+VjEx8L+f6jdd1QxEKvLdlx5UJfhbhlUs88+kga5sDivTFJjCoKZEou+Us7EW5ZEcVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0751 Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 04:45:30 -0000 Thanks for your review, Ben. We've published https://tools.ietf.org/html/d= raft-ietf-oauth-jwsreq-33 to address your and other IESG comments. Responses are inline below, prefixed by "Mike>". -----Original Message----- From: OAuth On Behalf Of Benjamin Kaduk via Datatr= acker Sent: Tuesday, April 6, 2021 11:39 AM To: The IESG Cc: oauth@ietf.org; oauth-chairs@ietf.org; draft-ietf-oauth-jwsreq@ietf.org Subject: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with= COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection 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 introduc= tory 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-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the new security considerations text in Sections 10.7 and 10.8 since I last reviewed; it does a great job capturing my comments (and = the current deployed reality). Thanks also to Watson Ladd for the latest secdir review and the authors for= their responses to it. Mike> Glad to hear it! Section 6.2 The Authorization Server MUST validate the signature of the JSON Web Signature [RFC7515] signed Request Object. The signature MUST be validated using a key associated with the client and the algorithm specified in the "alg" Header Parameter. [...] The last version I reviewed had some language tying the algorithm used for = verification back to a registration (and I commented that perhaps a registr= ation might not always exist). This language seems to set the recipient up= to blindly use the "alg" header parameter, even if it's "none", and we sho= uld probably have some hedging language here (I see we do have language els= ewhere that bans "none" specifically)... If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be performed, as specified in Sections 3.1 and 3.2 of [RFC8725]. ... and maybe that would just take the form of swapping the order of these = two sentences, now that I keep reading. Mike> Order swapped, per your suggestion. Section 10.2 Do any of the procedures listed for steps (c) and/or (d) need to be perform= ed in step (e) as well? (In particular, the requirements on the returned U= RI seem like they would still apply, and possibly the need for client authe= ntication. Mike> Having re-read (c), (d), and (e), I don't think so. The returned URI= in (e) can be an opaque identifier that is not a URL, so the URL checking = logic wouldn't apply. Section 10.3 Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to= my previous review suggested that there might be value in future work that= specifies the linkage across these endpoints to try to address the cross-p= hase attacks discussed in [FETT]. However, the paragraph that I had commen= ted on (that mentions "an extension specification") has since been removed,= and I failed to track down why just from a quick mailarchive search. Ther= e may well have been a good reason for removing it (and the reference to [F= ETT]), so please help refresh my memory if that's the case. Mike> It was removed as suggested by Watson Ladd in the discussion that res= ulted from his SecDir review. Section 10.4 The introduction of "request_uri" introduces several attack possibilities. Consult the security considerations in Section 7 of RFC3986 [RFC3986] for more information regarding risks associated with URIs. My previous comments had mentioned that because of time skew the dereferenc= ed request URI might actually have the contents of a different request than= the one intended, and Nat's response at https://mailarchive.ietf.org/arch/= msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ pointed out that OIDC actually does use a nonce that would prevent such an = occurrence. Hopefully Nat did get a chance to think about whether there wa= s anything else that we should mention in this document, on this topic. ("= There isn't anything else to mention here" is a fine answer; I just wanted = to close the loop on that thread, since I didn't find one in the mail archi= ve.) Mike> OpenID Connect requests using some response_type values include a non= ce and those using others don't. Thinking about it some more, I don't thin= k there's any particular risks about using these URLs that are sufficiently= different than those of other URLs that they're worth mentioning here. Section 11.1 nit: s/TFP/trusted third-party service/ (multiple instances), since we stop= ped using "Trust Framework Provider" in the main body. Mike> Thanks for the catch - corrected! Sction 14.1 Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 -- than= k you for referencing it as BCP 195! I expect the RFC Editor will catch th= e new reference if you don't want to figure out how to notate it properly. Mike> Thanks for the heads-up. I'll plan to ask the RFC Editor what the ri= ght way to do this is. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth Thanks again! -- Mike From nobody Wed Apr 7 23:22:27 2021 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 910DC3A3BDC; Wed, 7 Apr 2021 23:22:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-oauth-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes Tschofenig X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <161786294101.28888.16150454715315694485@ietfa.amsl.com> Date: Wed, 07 Apr 2021 23:22:21 -0700 Archived-At: Subject: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with 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: Thu, 08 Apr 2021 06:22:22 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-oauth-access-token-jwt-12: No Objection 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-access-token-jwt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My co-AD pretty much nailed it. I would go further and say that her comment about "Why is this only SHOULD?" applies to a lot of the SHOULDs in here. SHOULD presents a choice; why might an implementer reasonably not do any of the SHOULD things in here? For readability, I suggest that the three registrations packed into Section 7.2.1 be separated somehow, as right now they appear to be one continuous bullet list. Separate subsections would work, or even just a line of prose before each would suffice. The first half of the second paragraph of Section 6 seems much more like an interoperability issue than a privacy issue to me. From nobody Wed Apr 7 23:30:45 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F13A12BB; Wed, 7 Apr 2021 23:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UORBdnaH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uXjvS60+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgYt0J9gVPsi; Wed, 7 Apr 2021 23:30:34 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D68D3A12AF; Wed, 7 Apr 2021 23:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4016; q=dns/txt; s=iport; t=1617863434; x=1619073034; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QwHuO1X693/yqzDIIzwCTUIWs+j3rJbQLUoyLxxcLSo=; b=UORBdnaH8ReiXEcEQurPbnyfv9re2Lys17gphQl2Q8XgshiYdO4qdirJ CyDdSln3kDe+T2k5sw/pQG5RRcevV8s/xOnTt9LWIZyLamFKl/G8Lwvc5 DKZpG8MOLJ5ZOSApoOZUCrD2mqPuElCX/Igw8qK/45StStzbjPlcLYBsj c=; X-IPAS-Result: =?us-ascii?q?A0AZAAANom5gmJldJa1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?T4HAQELAYFSUX5aNjGEQoNIA4RZYIgpJQOZO4EuFIERA1QLAQEBDQEBKAoCB?= =?us-ascii?q?AEBhFACF4FgAiU0CQ4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFoh?= =?us-ascii?q?VANhkQBAQEBAyMRDAEBNwELBAIBCA4DAwEBAQMCJgICAjAVBQMIAQEEAQ0Fg?= =?us-ascii?q?nEBglUDLwEOoSECih93gTKBAYIEAQEGgTcCDkGDHhiCEwMGgQ8qAYJ1hAmCP?= =?us-ascii?q?YQRJxyBSUKBEycMEIJfPoIeQgEBAQKBKAESASgxAoJdNYIrgVlxZAQiGRACB?= =?us-ascii?q?AJ/GWkRAWGQVIM1pTeBCwqDC4ljjWWFNAQfg02KeJYshRGQBItqkl6EYQIEA?= =?us-ascii?q?gQFAg4BAQaBVDhrWBEHcBUxDyUBVR2BIylQFwIOjh8Zg1eFFIVFcwI2AgYBC?= =?us-ascii?q?QEBAwkBe4wVAQE?= IronPort-PHdr: A9a23:vp3qHBGlMJsFPx6pjcvXRZ1GftoY04WcBSYc94YnhrRSc6+q45XlO gnF6O5wiEPSNa3e6vlejPHRvbymUmsFst6Ns3EHJZpLURJNycAbhBcpD8PND0rnZOXrYCo3E IUnNhdl8ni3PFITFJP4YFvf8Xiz5iQVARLxKUx+IeGmUoLXht68gua1/ZCbag5UhT27NLV1K hj+rQjYusQMx4V4LaNkwRrSqXwOcONTlgtV IronPort-HdrOrdr: A9a23:svKOgKkXOjxjKTIgfQp5VO3lKQbpDfMujmdD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1aiui/vXwXsFd3AUV4hLxW5Ce2GmO2dxQxRLAod8NL f03LsFmxOLf3MLYsOnQlwMWOber9PG/aiWHyIuLRgh9QWIkHeU87b8CReVxVMzVDlIzLck/w H+4k7Ez4+ktOy2zQKZ6n/L4/1t6Zvc4/ZgJOjJsMgaLT3wlh2lDb4AZ5SutC04ydvfk2oCv8 LLp34bTqFOwlPXOlq4uB78nzTnuQxel0PK7X+9rT/drdfiRDQ8YvAxwL5xVhfC8UIvsJVd/c twrhiknqFaBx/BgyjxjuKgP3oB+ybEwgtBrccpg3NSSocYYrNKxLZvgX99KosKHy7x9ekcYY 9TJfzc//pffBe7aH3UrwBUsaSRd0kzBRuPTww+vNWU2VFt7QlE5nYfrfZv+ksoxdYYcd1p9u 7EOqNnmPVlVckNd59wA+8HXI+eFnHNaQikChPXHX3XUIU8f17doZ/+57s4oMuwfoYT8Zc0kJ PdFHtFqG8JfV70A8Hm5uwNzjn9BEGGGRj9wMBX4JZ0/pfmQqDwDCGFQFcy1+ytvusYGc+ef/ qoIppZD7vCIALVaMB09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGef+3UILbrDDY4SmLyCn YOR1HIVZ19x3HufkW9rAnaWnvrdEC614l3CrLm8+8az5VINoAkiHlPtX2JouWwbRFSuK0/e0 VzZJn9lLmgmGWw9WHUq2FgOh9XCFdJ8KztOkk6/zMiAgfRS/Iuqt+fcWdd0D+sPRlkVf7bFw ZZuhBw4qK4L5uZwCg4ENK5OmeGj38ezUj6Fqs0q+mm34PIa5k4BpEpVOhaDgPQDSF4ng5stS NecgMeX1TeETnvkK2hi5QRCIjkBoRBqTbuBfQRhWPUtE2aq81qe2ASWCS2V9WLxSw0QSBPu1 F3+6gDobaJlDq1M1EjiOAgPFAkUhXKPJt2SCC+IKRdgPTCZRx5R2biv03qtzgDPk7Rs3g0qk OkByuOYv3PCkdaoRljo9bX2WIxUH6ccUJ2Ym19qqtnGw39yylO+N7OQLav2G2MbVZH5ecRPF j+EGovCzIr4cyr3xiInzvHL1Ea/9EFO+zQC6lLScCM5lqkNJCImaYaH/Vd4ZZiM5T0vvUWVP +EEjXlWQ/QD/kowjqRrn0oPTMckghXrdr1whH/qGC30HkjaMCiU2hOVvUVJcqR4HPjQOvN2J Jljcgtte/1KWnpbMWaoJunIAJrO1fWoWSsSfsvpo0RtaUutKFrF52za0qE6FhXmBE/Jtzzjk UQXeBy563AIJZme4gXdzhC9lQk0NSJI01DiH27PsYuOVUshWTcJdWH/v7BrqcuGFSIoE/oIk aEmhctt8vtTm+Gz/oXGqgwKWNZZAw172lj5vqLc8nVBB+xf+9O8VKmOhaGAfFgYbnAHa9Vog dx4tmOkePSbSb+1QzKtTZwI65F8Q+cMImPKRPJHfQN/82xOFyKjKfv/dW6iy3vTyCnL0sfno 9IeCUrH4V+oyhniJdy1Ce8Sqb6+B1411Rf5CxqjV7r1Myt5nzBEURPLA3ehdFXUFBoQw61pN WA9fLd0nL3pCVB093EEkxbe9lVAdgeToTtNU5VWIMtla/t+7BqmzhJZRclEnU1hz/81f53xL vR4oSkZ8TyTXPzfU8b8TFLBoRojjUmpGFJfc+594+8aGwsZ6c1Kup64JtXnjJvokXy6FNZbw wFjH1d6r3w X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,205,1613433600"; d="scan'208";a="672741274" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2021 06:30:33 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 1386UXoN016891 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2021 06:30:33 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 8 Apr 2021 01:30:33 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 8 Apr 2021 01:30:33 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 8 Apr 2021 01:30:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jzzq0EZ5tg+ksRb0zNVKYYkvfQrz8gstnMvicvzDVKx7PQgJbz1OBmS1z1nSji9jJHy+FX2//fzhF7aOg4rtQjh+Zy3Ngugf1LQkf0xO2X1Ry2mSVoHja2Vsl82YP7ijkpcpUhd4kqqJ+idFB+uFmjLp0i9mjNc9+MPBjSMwUKGI4aegATFts2/25JTp0JrqE+HXKHeV7NmSLY4UT5tb1AYCNnUCOLuZZMpd7k7E0XXu8ZkZANaHv7iCFkhHBaGK/og17lASEERVhG9zxR9JeT+gziAYz+rXu47SK2dkdw8Bp7MBs3yLOygVTag1JmKrNAOR5jMSUi6frIKA+JSw9g== 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=QwHuO1X693/yqzDIIzwCTUIWs+j3rJbQLUoyLxxcLSo=; b=FFuyZg6/gFWCGS6LGTdhqHuhYKzbk+cLbjV4zXYxuIdSflp37YqLMYPNE5J9UJ/tUmIZX3Q2MxyF3VViSNyLywLJBvikyuoW190qj56s6oSAg7yArIYjuM72GZBT83miuZrRKAY9XSWxJPs/FrDIDF0nb4mNn+2+VbIhiVRZqEcSlW5KyzMBcZX+S0VpmclUu7YIfxp9sqrk3oNxarPR8j3t5rjUfAtIvXVkt50oU0R3c/ko0n5ZwI2HIdESM8Ji0u2FULepUrFYBkuN53o5Pg2NPWiODPx23EkxyMAd/Gm35wSz+ENFZO62962Xm/W4+5eEg0UVYtyRDZlojPRgVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QwHuO1X693/yqzDIIzwCTUIWs+j3rJbQLUoyLxxcLSo=; b=uXjvS60+lJtxkwl3L5NyMWGIua8LwAGRNkZuglmcb/8ZJ3fn9PcSMf5zQ/BbWC1CdW8AO6OSv8PtnZfkWMeOWWLArxPxnq39G6D5Rz7vmuoGj4mkM/uIw2xpXUj4AROjLyrtGxQ/B9p0/Vh51kPkLPI/fjv9b4gp5FhTS+mWk5U= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5192.namprd11.prod.outlook.com (2603:10b6:510:3b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17; Thu, 8 Apr 2021 06:30:32 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4020.017; Thu, 8 Apr 2021 06:30:32 +0000 From: "Eric Vyncke (evyncke)" To: Mike Jones , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1?= =?utf-8?Q?th-jwsreq-32:_(with_COMMENT)?= Thread-Index: AdcsMdpvP7kT4KrMSkq32B7JGYoiNAAH5VWA Date: Thu, 8 Apr 2021 06:30:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:15:00Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5dcb7e2a-8e5e-4a55-b62f-ff9be88fc627; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:8074:6283:a731:8954] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c970e872-9036-496c-e13d-08d8fa57cf5e x-ms-traffictypediagnostic: PH0PR11MB5192: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6T99H/V8+JgS6ds1zWGEP7Z3P1MQjVACP8yvmOgiDtwrUi17uGei6MA7sL7iD1dAHPavEkcGeTvsrUMPowq+dFBM4fmnyzInWEOtj/P6cumhBNo4va9n8bCam2qQgDgfq1asN2AlDxkA78nP9tZr+GVo+RYppdyCxk0ASYnLjovwHOzLfycIk6yG3VwFCpq91TsIqcNS5cDx/nteC7QDX1A0MeTUSQI7//m7vXmJg4WHbJz9fSQdAecT4X6tjqNEAPN8NdQ1P5Mu3gLmL2V7bWBAmQ91CCUEx+PF3dTU4uJQQJy6OPfMb23xXD1PLq4jVCz2c3wCQa1Wq3ptFReYldSQnExmFYMgHuk7DgXW7V+JWdrNhoL4V5CYMZM9yjs99Vd0NlTj0nJ40UYbR8r2JS8MlS/Atf6L8QtmEzM/JHrE95liOM3a1TX/Gb5Jr9MIJFqv8/1/3yIYX/NZL/GRk+Anq8gCzjim3jUOQQaxUNkIxqKjtWIBv5uIrIM4Lo7SHN68b5u4q/4KQHVosMdh1KTt3IHIiY9RAcjdcGZ8kYM5tKHoU3ChnOQ2mDHZ3mij3uY+ZrYfw67v2Aps0VRtzwZQkCziS8xPHo1imQDp7w8hmkd5zQgH0FIWpa75RvZNRId9kRQlvk/OVpN4zozdisDQ6cGmH4VLyWh8ejXCr2i/GoE9cNxzsa7zQvIYQB9d2yHovLAoS4li2axDv4LUh6UaVvEpJl0SY3dDfP/RMVOSm8dybA6Y7w1RKklm0lGKitELwSZ3wx1ujtyGhy9f6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(396003)(376002)(39860400002)(136003)(2616005)(33656002)(4326008)(6486002)(83380400001)(8936002)(36756003)(224303003)(110136005)(966005)(54906003)(316002)(66946007)(86362001)(5660300002)(76116006)(91956017)(478600001)(6506007)(53546011)(71200400001)(6512007)(186003)(38100700001)(2906002)(66556008)(66476007)(66446008)(64756008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?S3pqcVNITGtEZlpIZk9VZ0dYR0VHM0ZwakpZbWtXK2ErWTQwUzlwVnRGbS9p?= =?utf-8?B?RDFUdnpFelRKc0NreGJGaHljZkcrREFoNkI3L2h2N1lJeFBZQWZCMFdqWkdh?= =?utf-8?B?SThZakF4bEVrRU53eSsxYlNBcDJCOEdrU3Q1SVZ5dU01TzVHdUNuZDQ0d3F0?= =?utf-8?B?VktaNUcwUjIvSWx6YXZmbmNHSUVwR0p0MEdnVStScTl1VVlON3Q1NzZQSnNC?= =?utf-8?B?cFlwVHczWlUxYkV0NWNtZ016YnozcnB6UDIwemc0amRiYmh0VDlVdkZSV0p3?= =?utf-8?B?SWhMbHVxMTFDc1hCNXJYY3BZS2Q0QnhYZ1diUHB4ZHFpaVhwM0o1ZUtlSHBk?= =?utf-8?B?aHQ0RWh4cHFtbWVra0NnU3dGelczaGpudUZ3QTNldUo1eXlqR1RzSTBkNGRH?= =?utf-8?B?SURnMkZwdWpKT2FaaURMNVlJSlp2SGhZMkUyNElJMmwySElSeUhzN3dlYmtn?= =?utf-8?B?UWd6aEg4RVJLNHl1eTJDcWJXWFltZ2ZDSFV6bFgwcmlERERPZ1VFRUFuRThP?= =?utf-8?B?VVZaUGs3Y3o5MVE0akJjUUxlQjkyVVgzVk9RVGZFNDlyaFdoaHJ1VE5Dbk93?= =?utf-8?B?UUdBejc5djFPTUovL3JIVE54RG80Y0JZT1BONDB3dGt3ZnVobUxnUVhPNHJw?= =?utf-8?B?WW0vdE5wUFRRQ3czcHZIQmNUSlZSTFN6bjV3akxrVGNPRmtEZTFEQkFsTFNZ?= =?utf-8?B?YTFma1gzcXpQcDc5R1BTVXA5NmRvSi9CenhxTnNhSkdpQlF6UHhOQ1VCc0Ix?= =?utf-8?B?QnJ6NC9pLzZ5anB1S1JwWVJjN0wwL0JGdno5QWIzTHRyenByZnFUQ1krL0Y3?= =?utf-8?B?ckpkZzZ3T0NaZlp2RVlBNE5Oakdha01IYk9NMzVSdStjMW1PQklTdGNHMm83?= =?utf-8?B?enBQTjFXU0ZlUEtPKytKcnVOa1JWOFh3WWN3bUxMZGd4THFOR2VDMWNqNGx5?= =?utf-8?B?dDFibGV4OU1tQjJIYkdIbnQ2RDBnTFdNblZ6amN6UGFIUGlJcG53cnU4Z09n?= =?utf-8?B?R1ErSmJKalhXRnVtMjk1RG9jTHY1aHR4b2xld0c3RFZiWkhzcC9FSVJ6QXZB?= =?utf-8?B?a2hWc21oZ3BONUJkdWFmWTNyaVhYQ1J3b3RVbWpCMGdIZ2N0OHhxT3BkWDJX?= =?utf-8?B?eHVRV3ZVRUxWeFNCaENLN2wyN3dOb2lBZmt5K3d6OXJEUTZDcmpjVzlVNmdE?= =?utf-8?B?MEVRT20yMlFkWTBGbWI5WXZZdzg4YWRvTFBlSE1yM084S1ZodGc1c0Vab0cx?= =?utf-8?B?N3FZYm5NZEdrUVlia3dIdnYzb2MrandKalZ2STBiQytDVnQ3U1lyM1EraXYz?= =?utf-8?B?aHpCUGR6N2lXYWRNN0FSOFlLWlFMTE9keTl2N1ZQajBFYnFWVnQ4OEJlNldp?= =?utf-8?B?Q1ZRWEJRWkU1NjJvZFltaEg0dUV0T2NMNkUxVnRvQWZBcXZSVmNTWjBQcVhn?= =?utf-8?B?aVd2NnFUVHNTVGdIb3BaVWJia2U5bjRIZEpaUDRmUVdtU1hVTS9tQ3hiN0hV?= =?utf-8?B?dVR6R2pUMFZEcWFYVnlkVHI2aDQ2R1o4ME1VQ0doK0xSSlVCaCtZSmJZcDB2?= =?utf-8?B?VGgxbTlVellWbFhzZFNJcFBWeThPZjNRZ0NQSVFHeDg4RjNUZ09qd2Z6NjRF?= =?utf-8?B?d29XNkJDNHpmUEdQRThNZFlqT2dQdHUwVjhtNDdVTE0wakFoZWdLYnE5M25L?= =?utf-8?B?bWp6WUgwYmxaZDBVVGl0S2lqakxVcmJQWVlnaTFJbHdKWUYyNk9IYVhDUXVQ?= =?utf-8?B?b1JWTmRsZ1hsWVBBYUU3ZVVGcjFJZ2tLZU1MMzFaRU1SYzF1dmVER3p5N2Vn?= =?utf-8?B?WnZtMTRhbWt0Z0ZNRnBPeEd4VzhCcG5BL3VWWDc0b2lJZEtmb2xHelNGUkdJ?= =?utf-8?Q?Qf//nBPQx+CMs?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c970e872-9036-496c-e13d-08d8fa57cf5e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 06:30:31.9024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c6cwiwtxrZxO4tqVG+VRQ9LZIdnXDFx6mLk9rJ+4+Wfw//NYD/XTl3oN41xNMyqDrH1QuwdpftqX01+9775gFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5192 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-jwsreq-32=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 06:30:40 -0000 VGhhbmsgeW91IE1pa2UgZm9yIHlvdXIgcmVwbHkgYW5kIHlvdXIgbW9kaWZpY2F0aW9ucy4NCg0K UmVnYXJkcw0KDQotw6lyaWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkRhdGU6IFRodXJzZGF5 LCA4IEFwcmlsIDIwMjEgYXQgMDY6NDQNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5j b20+LCAiaWVzZ0BpZXRmLm9yZyIgPGllc2dAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtb2F1 dGgtandzcmVxQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmc+LCAi b2F1dGgtY2hhaXJzQGlldGYub3JnIiA8b2F1dGgtY2hhaXJzQGlldGYub3JnPiwgIm9hdXRoQGll dGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+LCAiSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldCIgPEhh bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+DQpTdWJqZWN0OiBSRTogw4lyaWMgVnluY2tlJ3MgTm8g T2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMyOiAod2l0aCBDT01NRU5UKQ0K DQogICAgVGhhbmtzIGZvciB5b3VyIHJldmlldywgw4lyaWMuICBXZSd2ZSBwdWJsaXNoZWQgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMzIHRvIGFk ZHJlc3MgeW91ciBhbmQgb3RoZXIgSUVTRyBjb21tZW50cy4NCg0KICAgIFJlc3BvbnNlcyBhcmUg aW5saW5lIGJlbG93LCBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQogICAgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCiAgICBGcm9tOiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIDxub3Jl cGx5QGlldGYub3JnPiANCiAgICBTZW50OiBUdWVzZGF5LCBBcHJpbCA2LCAyMDIxIDc6NDkgQU0N CiAgICBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQogICAgQ2M6IGRyYWZ0LWlldGYtb2F1 dGgtandzcmVxQGlldGYub3JnOyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3Jn OyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0DQogICAgU3ViamVjdDogw4lyaWMgVnluY2tlJ3Mg Tm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMyOiAod2l0aCBDT01NRU5U KQ0KDQogICAgw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KICAgIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMyOiBObyBPYmplY3Rpb24N Cg0KICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRh Y3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFu ZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBo LCBob3dldmVyLikNCg0KDQogICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KICAg IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZToNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW9hdXRoLWp3c3JlcS8NCg0KDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgQ09NTUVOVDoN CiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRv IHRoaXMgZG9jdW1lbnQuIE5vdCB0b28gbWFueSBkaWZmZXJlbmNlcyBzaW5jZSBteSByZXZpZXcg b24gdGhlIC0yNiAoaGVuY2UgSSByZXZpZXdlZCBtYWlubHkgdGhlIGRpZmYpLg0KDQogICAgUGxl YXNlIGZpbmQgYmVsb3cgc29tZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMgKGJ1dCByZXBs aWVzIHdvdWxkIGJlIGFwcHJlY2lhdGVkKS4NCg0KICAgIEkgaG9wZSB0aGF0IHRoaXMgaGVscHMg dG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsDQoNCiAgICBSZWdhcmRzLA0KDQogICAgLcOpcmljDQoN CiAgICA9PSBDT01NRU5UUyA9PQ0KDQogICAgLS0gU2VjdGlvbiAxIC0tDQogICAgSXMgaXQgbm9y bWFsIHRoYXQgdGhlIGFic3RyYWN0IGhhcyBhKSBhbmQgYikgd2hpbGUgdGhlIGludHJvZHVjdGlv biBoYXMgYSksIGIpLCBhbmQgYykgPw0KDQogICAgTWlrZT4gVGhhbmtzIGZvciB0aGUgY2F0Y2gu ICBXZSd2ZSBhZGRlZCAoYykgdG8gdGhlIGFic3RyYWN0Lg0KDQogICAgLS0gU2VjdGlvbiA1LjIg LS0NCiAgICBJIHNlZSB0aGF0ICJNYW55IHBob25lcyBpbiB0aGUgbWFya2V0IGFzIG9mIHRoaXMg d3JpdGluZyIgaXMgc3RpbGwgaW4gdGhlIHRleHQuLi4gRG9lcyB0aGlzIGFzc2VydGlvbiBzdGls bCBob2xkIGluIDIwMjEgPyBJcyBpdCBiYWNrZWQgYnkgc29tZSByZWZlcmVuY2VzID8NCg0KICAg IE1pa2U+IEknbSBub3Qgc3VyZSB0aGUgZGVncmVlIHRvIHdoaWNoIHRoaXMgaXMgc3RpbGwgdHJ1 ZS4gIEFsc28gcmVmZXJyaW5nIHRvIHRoaXMgcmF0aW9uYWxlLCBMYXJzIEVnZ2VydCBzdWdnZXN0 ZWQgdGhhdCB3ZSBjaGFuZ2UgdGhlICJNVVNUIE5PVCBleGNlZWQgNTEyIGNoYXJhY3RlcnMiIHRv ICJTSE9VTEQgTk9UIGV4Y2VlZCA1MTIgY2hhcmFjdGVycyIuICBXZSBoYXZlIGFkZHJlc3NlZCB0 aGlzIGluIHRoZSBtYW5uZXIgc3VnZ2VzdGVkIGJ5IExhcnMuDQoNCiAgICAJCQkJVGhhbmtzIGFn YWluLA0KICAgIAkJCQktLSBNaWtlDQoNCg0K From nobody Wed Apr 7 23:42:48 2021 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 503103A3C52; Wed, 7 Apr 2021 23:42:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <161786416623.14717.14919497824682714822@ietfa.amsl.com> Date: Wed, 07 Apr 2021 23:42:46 -0700 Archived-At: Subject: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-33: (with 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: Thu, 08 Apr 2021 06:42:46 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-oauth-jwsreq-33: No Objection 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-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Ah, jwsreq. We meet again. Fortunately, looking only at the diff from my last ballot comments to this one, I only have a couple of minor things this time: Sections 9.2 and 9.3 each say they are registering "values", but each registers only one. "+1" to Francesca's points #1 and #5. Thanks for changing the media type name to use hyphens instead of dots. That avoided a big mess. From nobody Thu Apr 8 02:47:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC993A0AB4; Thu, 8 Apr 2021 02:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqWuFlQ_tRDf; Thu, 8 Apr 2021 02:47:28 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150078.outbound.protection.outlook.com [40.107.15.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2153A0AB1; Thu, 8 Apr 2021 02:47:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KLj5/EJ/BRIptKZuRjdGI05zf8b/JiGCzSl7TDAXy9kNS93hG5PhD+7noupvlsG2Bmm/mp3pL1jjnj5tEt/E8QcUP02r//aAPJn/YYbOKO7iDrjuiAPaP7hx6lKXq2ZsA1UPiWiQncqEkp0WJgjLjMQwpSyHRZRvQqOE234hCBijfcbp5uxqttThaVDoddrTBa3NroYSpTTapxdNSMMbHSuP/Et2fmBPZncavj9Z9aHxcW/jmk5H2tBCyysiRrdvMT5MO/nQDEQwG6zxdKfRgxpVdmUm8k7BCJqM4y32K9z3ttAYdAKLm+JQDwa9hLzQ+8x2fiRh129OTDHA6pr7Fw== 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=KltulfR+gEZ237wxcc9HMErP3Vl0X2KW1MmjvpV7/J8=; b=FSZ/Sd53fAkiW9YxDPgGuNvsaWbDheHLpisVt6ChhBAXOaYpSLSieA+iJULNjkbkD70AvKsB7KE+8hDk/TwjMmdvAH+EzvIag/m/0N4zEeZp/0nlYs5rp+FxauJe+/QXnmVi0gRqAha39uUWXOm2ppXbpcGxOtzRmYL60TIQwSpUdnGPULRuVEDW/M1uXLExTUpSmzYAVOjpjQW3Ly3sUi4WskP+0zhllB4JysmYn/HOhPHQFTDOHShOIkqC7X31V9iJAKBAJqyleIkGYTp2qNldz/CY/3XoCXvdAxm7Ebwj4qebPQNDAqVMx5BL0n1zg0rLB9YFcAZMomSaTWu/kA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KltulfR+gEZ237wxcc9HMErP3Vl0X2KW1MmjvpV7/J8=; b=U0lMfiGc9FjkzZ9ZuEK2jgSafGMxi92ORWBsjOguL3aaNh6gSNfLoVXKdBoB2jPRrCZUpM1mlctb/e0bYy1Uaa7zMDHwb2EtTlS1LR2nOQE7WC1k+2Lu8fgper5I6FqYIqAuBCR8tuMZciGRlHoGAGRO4pGHVIThKMUJm6AUCXM= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR07MB3452.eurprd07.prod.outlook.com (2603:10a6:7:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.8; Thu, 8 Apr 2021 09:47:24 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b%5]) with mapi id 15.20.4020.017; Thu, 8 Apr 2021 09:47:24 +0000 From: Francesca Palombini To: Mike Jones , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMekdJv5IcULvQ1qzavuY873M4wAOwfAA Date: Thu, 8 Apr 2021 09:47:24 +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: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:41:17Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cdfb0104-3004-44ad-80cf-5c9eac18df57; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: microsoft.com; dkim=none (message not signed) header.d=none; microsoft.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:3c1d:e0b2:6f4d:a5e4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ccdd39c-6ee8-45b8-5744-08d8fa735057 x-ms-traffictypediagnostic: HE1PR07MB3452: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wtCNU7xVw8Y4lE/UgDi+/d4dK+Nw/zus3lDnxmSR3IQXgyTWxX8AiHbTpjnGdBcYzsEBZBF1tevUFTAkEL7dHRLpYPXko8tCy4ugxMHP5U5O/v24+emP4PnGtWH/IH7yOp82al2BXSrZNcIdDkBcjosoRUvqrhintn3NCIrZdvi+wU/614wuwIDQ/iDDbx9XpW4UIb3yT1QEmyMX8I7SdvAaDQqSW6CykjhhpSKa7DbvCw1RQ/xHWKqm0KWxaJQXWViekj65I5MDv2M0HyltxoRVoJWLoOe9dJ9C8Xj+Kv1a0nNvT9uILkUuSN7OyWcnWmYXDsEdF1sqn4DRxN4+4AnLFlpheUcv6lWw42dfCbL5IqzEyKKbYYCo0eWba4DIRkiapK81zSQERt6NpRf4BZe+vbwxO40c8BTOrMPZu8dTFEnznuoo4WT0ZrBcPAadr3so4WmELbcqd88ebGHiuM4zTyOqR7v7tRIaiq1s5R+/DuhqmRF1Nz7dpkfTk5V5bHgnM/jv8kq7HFMn6+TviUsCLIoWhxUZmOGH9HhhpbpUZFH11G4AmKzMC3OXHtRehEUBfsL8TmvZ8hIg6eCgNmiqnpBgKINZIgWVvru7V/CLsIHIKauSzo7EWLDzHZxWMF9BoJF8gEDLLFO1HQQ2HMu4KP5ae/n6EGLXkwMslQEQhyfGd++04N4WV3FVlqQ4iS/mHbCCZHPK4K/sdv0V7A8MYtV5edm4l0T30NUMD31ORN2+zzt5Mf6P3SdrLtOMp6rEcnabJXO3PN1odkeFuQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(44832011)(8936002)(2616005)(76116006)(66476007)(186003)(110136005)(64756008)(8676002)(4326008)(66446008)(54906003)(66946007)(6512007)(316002)(66556008)(478600001)(53546011)(36756003)(966005)(33656002)(6486002)(6506007)(86362001)(83380400001)(5660300002)(2906002)(71200400001)(38100700001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cUFwR2lLbnoxRHNTMVZGVys2czJCSkFkdUVDbVRxcjlVSmEwWjJIcE1INTZE?= =?utf-8?B?elpwQmpYcnlNcmR4ajcybkRRMnBiNW1Xazk5eTMxTTZCR2FvdXE1WDRlVmdw?= =?utf-8?B?cHhzajJ3TGlBeStGODFPdkhIUGlvYU1pS1hzTThhOHY2VURTbmN4RUZUUnVt?= =?utf-8?B?RmNVWHMyS1VKTGhwRmczcmRpbGFhWno0VVlpN05FOHpyWit0UGlLQkszYjBq?= =?utf-8?B?bld3UW1DeTVqUkFqeHNNSXdHcjB4SWpxK2NBSkVTVHNPWkM2VVVONWY0dkJ2?= =?utf-8?B?OUNDZHNvcThNTFJCRWh1Q0p3QUtjOVQ5a2JDeXFLZ1d2MStVdjd5TnJVQ0dR?= =?utf-8?B?alp3eHk3YzNJOGVuK3EvSEhUWERTNGFxMzNHb2N1OE5BcjRWVEpKSEE3RzZ2?= =?utf-8?B?NFJKWk1XVVRNN280Zm9oQTdqTzNnblVLU0hOTkQzN3VFcHRNd2pOclFiRlJ1?= =?utf-8?B?ZzZQeXZyeEYyR3dnbVE5d0FJWDJSbDJKdUQ3THVUelRRaUU3ZDBXNmY1b0Nn?= =?utf-8?B?ZEl1VExoZjlZZ2Nqd2d3NDFqTXUzWEJFcXhxdWtwbkF4TDZ2d2VFTThPSzhl?= =?utf-8?B?QituZnRlQWViWVNlOXQ3cHJBeFIvVXl3UG55RmZtSmxldzBneWMvNEdpTmdO?= =?utf-8?B?SkcwZTZwNURqRTJlTWlheVlCZ0tMSVNCalRKdklKZm9LeXlXRkJJNVRUZU02?= =?utf-8?B?MUJlZFQ5Z1dKd05FU3hNdDcwSzRWRnpZc0toK3AyYWxqMlFVRlhQNmhBa2NX?= =?utf-8?B?WDNpWkZIV1Q0MS9XT2pta3FWRlkycDZ5bUh2RDNHMUd0OUVhUlhHUExuREt0?= =?utf-8?B?YndQb2ozT0pNVVh5OVh6Tk5Gc2tRcmdVQVJITXYya2UrUjBrZE5OYXBzSEZt?= =?utf-8?B?RFI2MlA1NEQxYkFPSGVpQzFCaVhBSDd0ZVRRbWUzaFhFa0lGMndCRlMzbFhR?= =?utf-8?B?T1B5OXhMOXhURVhpSFJGU0JmRmYwUGN6WnlyaWpQLzVBZEdxRzlrVEJJZElF?= =?utf-8?B?WFJNMENjY3BsaUtXRVNubzE3U0hmTzFpU0xISGQwcTRsbmYrdDd4SDdrT0ht?= =?utf-8?B?c3RNUi9rTERBV3hZMHN5SUMyWlAwVWh2UnBSTUFsZnFCRVVxTVhNVFdPczZF?= =?utf-8?B?TkpERlIxY2lpSjRGV0pNbVgrbzdvZnI3VnVtRlQvN3FEZkE0QTNVb2FwdXNk?= =?utf-8?B?d295SGNOWDdVY0J4bEhFeExLRFVLdmgwM1NUR1k3OUJCcmlYT0xIeGo4T291?= =?utf-8?B?K1VQa3E3eDJPcDJKTmUydU14bzJLdjFuMERNMHo4Ympydkx4SmNFTE0vWUJx?= =?utf-8?B?L2xVUjdJVTRCNWE5QVlzdGV1YW5HMXRZWUtmTUgvQThuSktDa0ZlbnFHcllQ?= =?utf-8?B?RU45eUZhVFNEZnZacWlKdHNFWG44R2VFSDFXaythVm1HSEkvRVFLUVRzY3Ew?= =?utf-8?B?bU9IRGFnaUhWZzVoeXMwSTdVQXRadzBqWVpVNWFNY1gzMWRlQ2wxUWphczl4?= =?utf-8?B?UmJTdkVENS9jRmNNRW50TC9QVGRFWEpnN1NIZ0srWlpBQU5NQUtHaVVta21O?= =?utf-8?B?K2pxSkp4STRMU2hmTzV1UmVKVlNNOVNmUUZ0cVE4citpSUxpSXM0UkNoUUU4?= =?utf-8?B?SnVNVTJod3pocFJNOWVGSXRoOTVkYTVma2grR0k4SnIyVmZZNEcvYVRLY0hZ?= =?utf-8?B?L1pjclJFUjRmdTBtdmc4QmwrcWszdnRqbTRoMFdjMGxQeE5oVFpwMVgzaFl5?= =?utf-8?B?WitLbnNvSFFFZHpLLzJWdndJQlV5S252T29XVnFRREtLaWNXUDRnUytwVnBN?= =?utf-8?B?SHljUDcvaG1jR1lJQ3FFaFk2cGxNNDR2anBuZDNvRk1vVHQ3ZGRmTmpPMFV3?= =?utf-8?B?ZlVmQzNDV20vbUVwaVpuUEtIQnhmVVR4VHhDY05Ub0JHQmc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ccdd39c-6ee8-45b8-5744-08d8fa735057 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 09:47:24.7300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1GcQGi5fsJhnR3RR5WFg5WhDs8DJBx9VMDNBS8+76DX4gLl0v3v9ayMne5iGBaL7qI9c+RbvgT8DxEQBcNLI8prO/x422ndu2ljBzy5vsjRYt+ieU487kDX+C9X71aWm X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3452 Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 09:47:33 -0000 SGkgTWlrZSENCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVwbHkuIEl0IGxvb2tzIGdvb2QgdG8g bWUsIGp1c3Qgb25lIGFuc3dlciB0byBwb2ludCA0LiA6DQoNCiAgICA0LiAtLS0tLQ0KDQogICAg ICAgc3BlY2lmaWVkIGluIHRoZSAiYWxnIiBIZWFkZXIgUGFyYW1ldGVyLiAgSWYgYSAia2lkIiBI ZWFkZXIgUGFyYW1ldGVyDQogICAgICAgaXMgcHJlc2VudCwgdGhlIGtleSBpZGVudGlmaWVkIE1V U1QgYmUgdGhlIGtleSB1c2VkLCBhbmQgTVVTVCBiZSBhDQogICAgICAga2V5IGFzc29jaWF0ZWQg d2l0aCB0aGUgY2xpZW50LiAgQWxnb3JpdGhtIHZlcmlmaWNhdGlvbiBNVVNUIGJlDQoNCiAgICAu Li4NCg0KICAgICAgIHNhbWUgcGFyYW1ldGVyIGlzIHByb3ZpZGVkIGluIHRoZSBxdWVyeSBwYXJh bWV0ZXIuICBUaGUgQ2xpZW50IElEDQogICAgICAgdmFsdWVzIGluIHRoZSAiY2xpZW50X2lkIiBy ZXF1ZXN0IHBhcmFtZXRlciBhbmQgaW4gdGhlIFJlcXVlc3QgT2JqZWN0DQogICAgICAgImNsaWVu dF9pZCIgY2xhaW0gTVVTVCBiZSBpZGVudGljYWwuICBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg dGhlbg0KDQogICAgRlA6ICJNVVNUIGJlIGEga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50 IiAtIHdoYXQgaWYgaXQgaXMgbm90PyBkb2VzIHRoZSBBUyByZXR1cm4gYW4gZXJyb3IgdG8gdGhl IGNsaWVudCB0aGVuPyBTYW1lIGNvbW1lbnQgIi4uLiBNVVNUIGJlIGlkZW50aWNhbCIgLSBpcyBh bnkgZXJyb3IgcmV0dXJuZWQgaWYgaXQncyBub3Q/DQoNCiAgICBNaWtlPiBJIGJlbGlldmUgdGhh dCB0aGUgcmVzcG9uc2VzIHRvIHRoZXNlIHZhbGlkYXRpb24gZXJyb3JzIGFyZSBhbHJlYWR5IGRl c2NyaWJlZCBpbiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCwgd2hpY2ggc2F5cyAiSWYgc2lnbmF0 dXJlIHZhbGlkYXRpb24gZmFpbHMsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVy biBhbiAnaW52YWxpZF9yZXF1ZXN0X29iamVjdCcgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiByZXNw b25zZSB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiINCg0KRlA6IEFzIEkgcmVhZCBpdCwg dGhlIGZpcnN0IHBhcmFncmFwaCBzYXlzOiANCg0KICAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVy IE1VU1QgdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgSlNPTiBXZWINCiAgIFNpZ25hdHVy ZSBbUkZDNzUxNV0gc2lnbmVkIFJlcXVlc3QgT2JqZWN0LiAgSWYgYSAia2lkIiBIZWFkZXINCg0K VGhlbiBmb2xsb3dzIHVwIHdpdGggYSBudW1iZXIgb2Ygb3RoZXIgY2hlY2tzIHRoYXQgbmVlZCB0 byBiZSBkb25lICh0aGUgdGV4dCBJIHF1b3RlZCBpbiBteSBvcmlnaW5hbCBjb21tZW50KS4gQW5k IHRoZW4gZW5kcyB3aXRoIHRoZSBzZW50ZW5jZSB5b3UgcXVvdGVkOg0KDQogICBJZiBzaWduYXR1 cmUgdmFsaWRhdGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJu DQogICBhbiAiaW52YWxpZF9yZXF1ZXN0X29iamVjdCIgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiBy ZXNwb25zZSB0byB0aGUNCiAgIGF1dGhvcml6YXRpb24gcmVxdWVzdC4NCg0KU2FtZSBmb3IgdGhl IHNlY29uZCAtIHRoZSB0ZXh0IEkgcmVwb3J0ZWQgaXMgZm9sbG93ZWQgYnk6DQoNCiAgVGhlIEF1 dGhvcml6YXRpb24gU2VydmVyIHRoZW4NCiAgIHZhbGlkYXRlcyB0aGUgcmVxdWVzdCBhcyBzcGVj aWZpZWQgaW4gT0F1dGggMi4wIFtSRkM2NzQ5XS4NCg0KQW5kIHRoZW4gYWdhaW4gZnJvbSB0aGUg dGV4dCB5b3UgcXVvdGVkOg0KDQogICBJZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhlbiB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4NCiAgIGVycm9yIHRvIHRoZSBjbGll bnQgaW4gcmVzcG9uc2UgdG8gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXMNCiAgIHNwZWNp ZmllZCBpbiBTZWN0aW9uIDUuMiBvZiBPQXV0aCAyLjAgW1JGQzY3NDldLg0KDQpTbyB3aGlsZSBy ZWFkaW5nIEkgY29uc2lkZXJlZCB0aGF0IHRoZSB2YWxpZGF0aW9uIChlaXRoZXIgb2YgdGhlIHNp Z25hdHVyZSBmb3IgcGFyIDEgb3Igb2YgdGhlIHJlcXVlc3QgZm9yIHBhciAyKSBpcyBzZXBhcmF0 ZSBmcm9tIHRoZSBhZGRpdGlvbmFsIGNoZWNrcy4gVGhlIGludGVudCBvZiBpdCBjb3VsZCBiZSBt YWRlIGNsZWFyIGJ5IGEgbWlub3IgYWRkaXRpb24gaW4gZWFjaCBwYXI6DQoNCjFzdCBwYXJhZ3Jh cGg6DQoNCk9MRDoNCg0KICAgSWYgc2lnbmF0dXJlIHZhbGlkYXRpb24gZmFpbHMsIHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVybg0KICAgYW4gImludmFsaWRfcmVxdWVzdF9vYmpl Y3QiIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlDQogICBhdXRob3JpemF0 aW9uIHJlcXVlc3QuDQoNCk5FVzoNCg0KICAgSWYgc2lnbmF0dXJlIHZhbGlkYXRpb24gZmlhbHMs IG9yIGlmIHRoZSBrZXkgaWRlbnRpZmllZCBpcyBub3QgYXNzb2NpYXRlZCB3aXRoIHRoZSBjbGll bnQsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVybg0KICAgYW4gImludmFsaWRf cmVxdWVzdF9vYmplY3QiIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlDQog ICBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQoNCjJuZCBwYXJhZ3JhcGg6DQoNCk9MRDoNCg0KICAg SWYgdGhlIHZhbGlkYXRpb24gZmFpbHMsIHRoZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1V U1QgcmV0dXJuIGFuDQogICBlcnJvciB0byB0aGUgY2xpZW50IGluIHJlc3BvbnNlIHRvIHRoZSBh dXRob3JpemF0aW9uIHJlcXVlc3QsIGFzDQogICBzcGVjaWZpZWQgaW4gU2VjdGlvbiA1LjIgb2Yg T0F1dGggMi4wIFtSRkM2NzQ5XS4NCg0KTkVXOg0KDQogICBJZiB0aGUgdmFsaWRhdGlvbiBvZiB0 aGUgcmVxdWVzdCBvciB0aGUgQ2xpZW50IElEIGNoZWNrIGZhaWxzLCB0aGVuIHRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciBNVVNUIHJldHVybiBhbg0KICAgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiBy ZXNwb25zZSB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBhcw0KICAgc3BlY2lmaWVkIGlu IFNlY3Rpb24gNS4yIG9mIE9BdXRoIDIuMCBbUkZDNjc0OV0uDQoNCg0KSSB0aGluayB0aGlzIHdv dWxkIGNsYXJpZnkgdGhlIHRleHQsIGJ1dCBJJ2xsIGxlYXZlIGl0IHVwIHRvIHlvdSB0byBkZWNp ZGUgaWYgaXQncyB3b3J0aCBhZGRpbmcuDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMDgv MDQvMjAyMSwgMDY6NDUsICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PiB3cm90ZToNCg0KICAgIFRoYW5rcyBmb3IgeW91ciByZXZpZXcsIEZyYW5jZXNjYS4gIFdlJ3Zl IHB1Ymxpc2hlZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1q d3NyZXEtMzMgdG8gYWRkcmVzcyB5b3VyIGFuZCBvdGhlciBJRVNHIGNvbW1lbnRzLg0KDQogICAg UmVzcG9uc2VzIGFyZSBpbmxpbmUgYmVsb3csIHByZWZpeGVkIGJ5ICJNaWtlPiIuDQoNCiAgICAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IEZyYW5jZXNjYSBQYWxvbWJpbmkg dmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiANCiAgICBTZW50OiBXZWRuZXNkYXks IEFwcmlsIDcsIDIwMjEgMzoyOSBBTQ0KICAgIFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4N CiAgICBDYzogZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmc7IG9hdXRoLWNoYWlyc0Bp ZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmc7IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQNCiAgICBT dWJqZWN0OiBGcmFuY2VzY2EgUGFsb21iaW5pJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt b2F1dGgtandzcmVxLTMyOiAod2l0aCBDT01NRU5UKQ0KDQogICAgRnJhbmNlc2NhIFBhbG9tYmlu aSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFm dC1pZXRmLW9hdXRoLWp3c3JlcS0zMjogTm8gT2JqZWN0aW9uDQoNCiAgICBXaGVuIHJlc3BvbmRp bmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwg ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KICAg IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwNCiAgICBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCiAgICBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEvDQoN Cg0KDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQogICAgVGhhbmsgeW91IGZvciB0aGUgd29yayBvbiB0aGlzIGRvY3VtZW50LiBJIG9ubHkgaGF2 ZSBtaW5vciBjb21tZW50cywgdGhlIG1vc3QgaW50ZXJlc3RpbmcgaXMgcHJvYmFibHkgNC4gYWJv dXQgaWYgYWRkaXRpb25hbCBmYWlsdXJlIGJlaGF2aW9yIHNob3VsZCBiZSBkZWZpbmVkIGF0IHRo ZSBBUy4NCg0KICAgIEZyYW5jZXNjYQ0KDQogICAgMS4gLS0tLS0NCg0KICAgICAgIEEgUmVxdWVz dCBPYmplY3QgKFNlY3Rpb24gMi4xKSBoYXMgdGhlICJtaW1lLXR5cGUiICJhcHBsaWNhdGlvbi8N Cg0KICAgIEZQOiBQbGVhc2UgdXNlICJtZWRpYSB0eXBlIiBpbnN0ZWFkIG9mICJtaW1lLXR5cGUi IGFuZCByZWZlcmVuY2UNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjgzOA0K DQogICAgTWlrZT4gVGhhbmtzLCB1cGRhdGVkLCBhbHRob3VnaCByZWZlcmVuY2luZyBSRkMgMjA0 NiBmb3IgdGhlIHRlcm0gIm1lZGlhIHR5cGUiICh3aGljaCBpcyBub3Qgc3VwZXJzZWRlZCBieSBS RkMgNjgzOCkuDQoNCiAgICAyLiAtLS0tLQ0KDQogICAgICAgVGhlIGZvbGxvd2luZyBpcyBhbiBl eGFtcGxlIG9mIHRoZSBDbGFpbXMgaW4gYSBSZXF1ZXN0IE9iamVjdCBiZWZvcmUNCiAgICAgICBi YXNlNjR1cmwgZW5jb2RpbmcgYW5kIHNpZ25pbmcuICBOb3RlIHRoYXQgaXQgaW5jbHVkZXMgdGhl IGV4dGVuc2lvbg0KDQogICAgRlA6IFRoaXMgZXhhbXBsZSBpcyB0aGUgZmlyc3QgdGltZSAiYmFz ZTY0dXJsIiBhcHBlYXJzIGluIHRoZSBkb2N1bWVudC4gSSB0aGluayBpdCB3b3VsZCBtYWtlIHNl bnNlIHRvIG1lbnRpb24gdGhhdCBiYXNlNjR1cmwgaXMgdXNlZCB3aGVuIEpXVCBpcyBpbnRyb2R1 Y2VkLCBmb3IgZXhhbXBsZSBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC4NCg0K ICAgIE1pa2U+IFJlZmVyZW5jZSBhZGRlZC4NCg0KICAgIDMuIC0tLS0tDQoNCiAgICAgICBJZiBk ZWNyeXB0aW9uIGZhaWxzLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4N CiAgICAgICAiaW52YWxpZF9yZXF1ZXN0X29iamVjdCIgZXJyb3IuDQoNCiAgICAuLi4NCg0KICAg ICAgIElmIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgTVVTVCByZXR1cm4NCiAgICAgICBhbiAiaW52YWxpZF9yZXF1ZXN0X29iamVjdCIgZXJyb3Iu DQoNCiAgICAuLi4NCg0KICAgICAgIElmIHRoZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGVuIHRoZSBB dXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVybiBhbg0KICAgICAgIGVycm9yIGFzIHNwZWNp ZmllZCBpbiBPQXV0aCAyLjAgW1JGQzY3NDldLg0KDQogICAgRlA6IHZlcnkgbWlub3IsIGJ1dCBJ IHN1Z2dlc3RzIHlvdSBhZGQgInRvIHRoZSBjbGllbnQsIGluIHJlc3BvbnNlIHRvIHRoZSByZXF1 ZXN0IGRlZmluZWQgaW4gNS4yLjIuIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiIuIFRoZSByZWFzb24g aXMgdGhhdCB0aGUgZG9jIHNwZWNpZmllcyB0aGF0IHRoZSBBUyBtaWdodCBiZSBoYXZpbmcgb3Ro ZXIgZXhjaGFuZ2VzICh0byBmZXRjaCB0aGUgUmVxdWVzdA0KICAgIE9iamVjdCkgYXQgdGhlIHNh bWUgdGltZSwgYW5kIGl0IGNhbid0IGh1cnQgdG8gYmUgcHJlY2lzZS4gQWxzbyByZWdhcmRpbmcg dGhlIHJlZmVyZW5jZSB0byBSRkMgNjc0OSAtIGNhbiB5b3UgYWRkIGEgc3BlY2lmaWMgc2VjdGlv biB0byByZWZlcmVuY2U/DQoNCiAgICBNaWtlPiBEb25lDQoNCiAgICA0LiAtLS0tLQ0KDQogICAg ICAgc3BlY2lmaWVkIGluIHRoZSAiYWxnIiBIZWFkZXIgUGFyYW1ldGVyLiAgSWYgYSAia2lkIiBI ZWFkZXIgUGFyYW1ldGVyDQogICAgICAgaXMgcHJlc2VudCwgdGhlIGtleSBpZGVudGlmaWVkIE1V U1QgYmUgdGhlIGtleSB1c2VkLCBhbmQgTVVTVCBiZSBhDQogICAgICAga2V5IGFzc29jaWF0ZWQg d2l0aCB0aGUgY2xpZW50LiAgQWxnb3JpdGhtIHZlcmlmaWNhdGlvbiBNVVNUIGJlDQoNCiAgICAu Li4NCg0KICAgICAgIHNhbWUgcGFyYW1ldGVyIGlzIHByb3ZpZGVkIGluIHRoZSBxdWVyeSBwYXJh bWV0ZXIuICBUaGUgQ2xpZW50IElEDQogICAgICAgdmFsdWVzIGluIHRoZSAiY2xpZW50X2lkIiBy ZXF1ZXN0IHBhcmFtZXRlciBhbmQgaW4gdGhlIFJlcXVlc3QgT2JqZWN0DQogICAgICAgImNsaWVu dF9pZCIgY2xhaW0gTVVTVCBiZSBpZGVudGljYWwuICBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg dGhlbg0KDQogICAgRlA6ICJNVVNUIGJlIGEga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50 IiAtIHdoYXQgaWYgaXQgaXMgbm90PyBkb2VzIHRoZSBBUyByZXR1cm4gYW4gZXJyb3IgdG8gdGhl IGNsaWVudCB0aGVuPyBTYW1lIGNvbW1lbnQgIi4uLiBNVVNUIGJlIGlkZW50aWNhbCIgLSBpcyBh bnkgZXJyb3IgcmV0dXJuZWQgaWYgaXQncyBub3Q/DQoNCiAgICBNaWtlPiBJIGJlbGlldmUgdGhh dCB0aGUgcmVzcG9uc2VzIHRvIHRoZXNlIHZhbGlkYXRpb24gZXJyb3JzIGFyZSBhbHJlYWR5IGRl c2NyaWJlZCBpbiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCwgd2hpY2ggc2F5cyAiSWYgc2lnbmF0 dXJlIHZhbGlkYXRpb24gZmFpbHMsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVy biBhbiAnaW52YWxpZF9yZXF1ZXN0X29iamVjdCcgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiByZXNw b25zZSB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiINCg0KICAgIDUuIC0tLS0tDQoNCiAg ICAgICBsb2NhdGlvbiwgKGIpIGNoZWNrIHRoZSBjb250ZW50IHR5cGUgb2YgdGhlIHJlc3BvbnNl IGlzICJhcHBsaWNhdGlvbi8NCg0KICAgIEZQOiBGb3IgY29uc2lzdGVuY3ksIHBsZWFzZSBjaGFu Z2UgImNvbnRlbnQgdHlwZSIgdG8gIm1lZGlhIHR5cGUiLg0KDQogICAgTWlrZT4gRG9uZQ0KDQog ICAgCQkJCVRoYW5rcyBhZ2FpbiwNCiAgICAJCQkJLS0gTWlrZQ0KDQoNCg0K From nobody Thu Apr 8 06:45:49 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FE73A1839; Thu, 8 Apr 2021 06:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 HbVRDPNWBBWN; Thu, 8 Apr 2021 06:45:43 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650125.outbound.protection.outlook.com [40.107.65.125]) (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 E80C43A1838; Thu, 8 Apr 2021 06:45:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I7+Ibtlo2EuFJp4b431DHMvFh4IK3P3FCPe7C7SeGqXPsovzgobgW7894DPLoWtPIiFg16kO+yDtOOstUMm+P+Ca2YBQOexbqFMVVim8jvq3R+Rxsgto0oRw5LmzVfACZMsZgw3TxraI6jfRXY2wDqgTY0ylFCMXWPEOBjLrNddK3z/565rd4DRoOQjc+zblXb6/U+YNachW0ivrlUf77TyFZHnbQSHDVxzwynhYP9KzfqPuIFzLgAHKocDllDDeoXvA+aau/WMh0DO41ZPm0oKvpoX5OyXMq/ALcN+sCTvZ79tQpoZbQMwQE0+iNRlWpon+UIPwJN6RJpJ+mY2+9Q== 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=QmiZmVsI+EegafOYWp7MZkX8fIWAclxC5gWw5aZhYsE=; b=V8v5DIucE24bHNTRoqpXYnbyea3BrAJtfQhwdfQwYnY6JgM3LHMsBWsPxGHs8PrZvLQRwysVwnRF5YdB2VRsRKHd1lu+m/YwH3qiZ5BS8GJRR2j8ugHOJkvbSIhv4Ow5KbbpMzA7U2y9AyNcYCXs4q8c36yrxs8NNnwokztvwtetmLZkyxaZNPDN09UAWE7/q0dH2DH71KmZlt1WrRHACTJXCoi0E2keXF0amMgcSNqoOHJz4GoND5rrw9uxfGt7UoKrdG3GN/TYXUYE5dDAD6we+wJvZMs7Lbz9Egq/syaWXr1KnSfc83v7H4uJuLhcyI0Ntl+sL/zeGqkJO/wVJQ== 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=QmiZmVsI+EegafOYWp7MZkX8fIWAclxC5gWw5aZhYsE=; b=Kfxim0MldgUDFaUwpHfeg2gSJJJKzdST+axNVmj9m+cKeyFVVQ03ye+XNM+qZS6WnecZj5MdDexgENyGfyfWzxU/f2/on6F5CU3ExqBHpc29lgIaZSq5YIuy336W5WIhKqSpk8pokfnZihwpRjFQEhJWLm2pClJN2JjaaaWtmWg= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0848.namprd00.prod.outlook.com (2603:10b6:5:1bf::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4058.0; Thu, 8 Apr 2021 13:45:34 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 13:45:34 +0000 From: Mike Jones To: "superuser@gmail.com" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-33: (with COMMENT) Thread-Index: AdcsfXHbVuEHxvFASVOnHTGuwDl8pA== Date: Thu, 8 Apr 2021 13:45:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T13:42:45Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9636321e-049b-45fc-8790-7dd1547eae25; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2607:fb90:b2d9:b46f:e920:2135:f44b:10a6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0499a890-9b4f-4410-2335-08d8fa9495cd x-ms-traffictypediagnostic: DM6PR00MB0848: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xy6uFT7XdPwjgFePFxTkpgVoy/ukkvReDIzqacCiup2BDzBbe99hikSQl85v12wck51W9DfSHYJAnzSDJmMlEWm48UHq/tjZxzzCuspmn2fZdinvIdfJ9EEfKveYRu/VAVb4Rh6h9VWmPlbH+W2k0vrseeRBQs8Z95MzJoZCklRBJS3RGBxu/THtGbi7q4D7YhZ8vX7gUCbVfEFmO4JKPzYqhEs8c59uBGXQGdPDhIQKtvyGA0q7vrOxNlhas61bMmMWgYySAdIifV7xVhlEEsTBNecvaW1EBfkGoaN0Q55ZktVO2g9eWyl+g6OelNEX+9wBIlw2VazsMdFUroskCIh1pPnOav4gl98GnZOlrKhebsalVz2Y1JP2+tLizTzVyn/h4LG9fgSooSmX0jHyhF5Jnm3SGxTdswwPVyhMFBubQ9ckwgWnokka7wXIeAjAEikL2HVs1tutmpoPVs/3PD1Y5X3nDXW10uVYcjKpWfF+spo3itAV7O1bF3knT3uwHIIPi408HfHI0WKYwnycoyQC0cWdbQZ9+6iPi8yVsbDrGipT+YNibhLMH9Q3ty019auKROBUtynmj3+xT6I+fe81ZfCokNva/3Samz4+GZji2EUwJ5HmkHPpA8FOLlZQo/VrpFLjXGfhqf3Nj7D8ub/P57ABumLuEZ3iaBiiiGzzitT9P3XXYfcw5W/WuS2xCzRZfTwPiD7AskzVoQG3SyhA8hJljS24DBhe/arehaI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(478600001)(6506007)(186003)(66476007)(966005)(316002)(4326008)(66946007)(76116006)(10290500003)(66556008)(86362001)(110136005)(54906003)(66446008)(8990500004)(71200400001)(64756008)(83380400001)(8936002)(52536014)(7696005)(55016002)(9686003)(33656002)(5660300002)(8676002)(38100700001)(2906002)(82950400001)(82960400001)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?UDlpT1k5VEI5VUJ4ekgwWjhtVGp5b2hLU2F2eWtIT1J3a2c3ZHd6c2NsK292?= =?utf-8?B?UXZsRTZtU1ZLR1k4VTAxblA5dU16Zkh3YW9GNFRZLzJtdlJKbjM0R1JvVmp4?= =?utf-8?B?T0V4ckljdE54QndIbHBTSVE1aXR2THEycjl5ZVR2TEFKQ01sd1F5dzY1YlJI?= =?utf-8?B?aURldU41L3hWd0lYcWlSdU4reGJDeERVaUM4Zk5iVDl6NGJTbDVrRWFRV0RT?= =?utf-8?B?V1g3SG1IVDIrcC9DZlRTZFBKTmpOY0hSNEdwK2t0SGlRTlpsdGhBU1BNRDg3?= =?utf-8?B?ODFyOVRtRDJEY3lIMC9aRFNmUU1xVk5LMEpwdXBwVnJRd0c3R0NMSk10TjM3?= =?utf-8?B?Z0QzbmN6S2hkMGU0N0J6L2VtamtWM2pwWk1kYmM5MU5FT21xVzQzbUxnVVlQ?= =?utf-8?B?anhUb1F0NmtDSGpGQlAxUlprakFRTXlyYk9YTjdtUWY5OUQybk1KTTB6M0pt?= =?utf-8?B?QjFPNXdBdUJYMndSbDhZNXdmKyt3T2tpaU9NZG1TSEFROURmRG82enI0VDAw?= =?utf-8?B?TDRrSk55ckR1SXpHTWxwd092Vndwa01yN0FWVmtkdTdrdTdZbmpaTG9TdTYy?= =?utf-8?B?akorZ2k1cnk1MmNPbU10b05jQnJWQ0lWdC9HMWhFRnExQlRWZjB1TXVBcWdN?= =?utf-8?B?Zkx4elh4ME1NTjZHTEErTWxEN0pmeXNTektyQ2lsbHVCR1E1Mjl4emd4QURh?= =?utf-8?B?bFFBc1paaW9iWjZ1L2pmTGRHb1NzQm02WUIvNk1LdURpN1ZGOHJaOVk2MFVT?= =?utf-8?B?a1BIRmJ5VGp2YkMzZUFQV0lWNGxrV0daYVBxVitTbnhiaE50RmptNE5BMnZk?= =?utf-8?B?OUZ4VnoxRUFqd3haS1dsRXdEYmtCUmppZ3hKdkJuWHE1dzJ0M3BHc2tnRGJI?= =?utf-8?B?S0cxY0hPYlViT2ZhaTI2c3grQ054bTdvNEQwMjROaHJpVzYrb1owVitvbDFv?= =?utf-8?B?SDZYVzNWS2t4eGFQTjBFN0t1T0o1SjJ6VHUyQzlpREVYTGFiV3RGSVRrbzZh?= =?utf-8?B?aE5rcXhveUJiOWtvbXNNV3EyR1UvOFFTWUhCVmZlMk9acTBOMnRpQmMvQUtj?= =?utf-8?B?RHk5SnVYUExRVjZjbkVldXBUbHhodmh0YnFHOXgvZlRlMzRaNzdTNUFJZGlz?= =?utf-8?B?TTJvOVlCTnl0QjlHYjVhRTVhYkpRZ1U4NDdiUkcxNDdBVG83ME5BazcrZUJn?= =?utf-8?B?enptSWtzYVNpUGRNc3YxSXFSSFBWTzkzeVRHTDVYVm1rT282WXJJcGFELzFD?= =?utf-8?B?QWZjbTI1Q05HODExLy9MeVB5ZFVHMDVQOUdMOEt6eWluQ1lnVWtRb0Nkc3U4?= =?utf-8?B?RktuVkUvdUNDVEsvekVKeWpFSldpNHVLVDNoV0lQdEp0Qi9vdDZidlFvZTdB?= =?utf-8?B?UVAzTVNZeGxXd0JzRFhlRlNRckV4TWtJRkdmTytTRTBxc0FJMkFZblNXK2I3?= =?utf-8?B?TVorYkgvZlRQSjljRjZYRUQvYUZ0Z2xkYnl5TkoxTWlrZlMzNDI0N3pML2FC?= =?utf-8?B?aFdGVlV6WUNCekNULzVlbVY0dHFxeVFRRDRIbzM0SlJETmN1eDUrVlk2Wkti?= =?utf-8?B?QTFvREFSZ3c5eXR3dnRoYmVTTmxWYXZ0Rng4OVo5TDYra0NYV1hXazNBSGVQ?= =?utf-8?B?aUQyaEwvWXZzaEdiRkVIWko3QVNqQVl4bUIwanlNZVVITXJwaElLbXVxUGRB?= =?utf-8?B?L043dDRFQk1rc0hyRFdENHQveVdFaFF5MGJROFFOWkdMVnBsb1NzbzJUai8x?= =?utf-8?B?b3lobzJsbGhtMkp1N0ZzdExlTGlwZU8wUy81djR4WEtwSTJnRGxVWVV5Wngz?= =?utf-8?B?SjF1aVg5bHZkM2ZZYUs5VldnWFVwUFVtcnpwaVJ4V1NYQUUxRW5DNzZqTmVo?= =?utf-8?Q?DB5Nw8qC2HQOG?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0499a890-9b4f-4410-2335-08d8fa9495cd X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 13:45:34.7798 (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: 4n2gGOH142HYfv0fr7c8zHNdklbm4N4qXfY1e5LCsmx1kXypbejwnRAWwXkW2eySpdwCn5oQCysQXASDgs7xVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0848 Archived-At: Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-33: (with 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: Thu, 08 Apr 2021 13:45:47 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgTXVycmF5LiAgTXkgcmVwbGllcyBhcmUgaW5saW5lLCBw cmVmaXhlZCBieSAiTWlrZT4iLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TXVycmF5IEt1Y2hlcmF3eSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IA0KU2Vu dDogV2VkbmVzZGF5LCBBcHJpbCA3LCAyMDIxIDExOjQzIFBNDQpUbzogVGhlIElFU0cgPGllc2dA aWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmc7IG9hdXRoLWNo YWlyc0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmc7IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQN ClN1YmplY3Q6IE11cnJheSBLdWNoZXJhd3kncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1v YXV0aC1qd3NyZXEtMzM6ICh3aXRoIENPTU1FTlQpDQoNCk11cnJheSBLdWNoZXJhd3kgaGFzIGVu dGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLW9hdXRo LWp3c3JlcS0zMzogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBp bnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpm b3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRp b25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtb2F1dGgtandzcmVxLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KQWgsIGp3c3JlcS4gIFdlIG1lZXQgYWdhaW4uICBGb3J0dW5hdGVseSwg bG9va2luZyBvbmx5IGF0IHRoZSBkaWZmIGZyb20gbXkgbGFzdCBiYWxsb3QgY29tbWVudHMgdG8g dGhpcyBvbmUsIEkgb25seSBoYXZlIGEgY291cGxlIG9mIG1pbm9yIHRoaW5ncyB0aGlzIHRpbWU6 DQoNClNlY3Rpb25zIDkuMiBhbmQgOS4zIGVhY2ggc2F5IHRoZXkgYXJlIHJlZ2lzdGVyaW5nICJ2 YWx1ZXMiLCBidXQgZWFjaCByZWdpc3RlcnMgb25seSBvbmUuDQoNCk1pa2U+IFRoYW5rcy4gIEkg Y29ycmVjdCB0aGlzIGluIGFuIHVwZGF0ZWQgZHJhZnQgYWZ0ZXIgdGhlIHRlbGVjaGF0Lg0KDQoi KzEiIHRvIEZyYW5jZXNjYSdzIHBvaW50cyAjMSBhbmQgIzUuDQoNCk1pa2U+IFdlIGFkZHJlc3Nl ZCB0aG9zZSBwb2ludHMgaW4gZHJhZnQgMzMgKHB1Ymxpc2hlZCBsYXN0IG5pZ2h0LCBteSB0aW1l KS4NCg0KVGhhbmtzIGZvciBjaGFuZ2luZyB0aGUgbWVkaWEgdHlwZSBuYW1lIHRvIHVzZSBoeXBo ZW5zIGluc3RlYWQgb2YgZG90cy4gIFRoYXQgYXZvaWRlZCBhIGJpZyBtZXNzLg0KDQpNaWtlPiBZ b3UncmUgd2VsY29tZSENCg0KCQkJCS0tIE1pa2UNCg0K From nobody Thu Apr 8 06:49:15 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1213A1856; Thu, 8 Apr 2021 06:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.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, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py6vemG29Qzv; Thu, 8 Apr 2021 06:49:05 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650139.outbound.protection.outlook.com [40.107.65.139]) (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 E12DB3A1854; Thu, 8 Apr 2021 06:49:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ciCWHiBlk/eV3ite/uKq7Aj+Wd/R/MWrOc8I6wHogd48T4uhtpoEQl1wOpgPzJQaLim3AvAE49EAMfdYQZgoWyH57yAss25sJB/zdom8/eYevTBgIEct0fy7WHJAfLetYOOqq/m+eVzTaLVhCvS7FBwUk9Bi3RYvTqQjVT4H85jUz+SAbc86AVd66s/LVE0zPganfY/AovvSzb0XY+8mmNt1kZYpliMroZCQGvQAzrHUWM93aWzlh3NH4ywnd86+LmdlUhNF2gMhev3m+G4BVH4i/IoqeEwWOD926AIZNHHSZDY6ibr9OpQqqE0NTEttunQ3dl/5pVkYeogeKpy0Dw== 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=sY7OutVUxO1uziilFgvaJDtdjaipdCCZSOKyt+E/3WA=; b=U3m1ZgxVMLU9uNNgSdlvvxmT9nD7OdsZKfkvUmGDRb81tr1V0Zxo5moqSGEg3EzXRaHh5NE40q4fYm6UVIdu5mR46aYP+yaNQ6XxTr6WimexEbXX0/fch/gLp3fLZzy2e8OUs5lfPZrD+adCuE6QSaYFTkfcqjvqaHwcswatb2at8PpZCVjfr6tFQND+CPnLGly7c02wQ7vjRJJEVTEbVwIqRW8wHILVCpeeQX5CKBCii50LdbJkdzaIEZGfIfv6JvjpYeB4IwLAGDL4A5zTQiw/q0hMoCkFXxoQdnobo3cFHILUvR/QnMkmxvRN4VtnXct0+uzfqu/fouP13mJaaw== 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=sY7OutVUxO1uziilFgvaJDtdjaipdCCZSOKyt+E/3WA=; b=FF7ZbZuFVCYF0RynSl4kcKmSNtFDdo0uEaLUZoOJTkICmSB+oB6TSAs4AbI5r8rh4Xms4UGplR41bVv+6q1JtjQEmB7rofyvQuf6gYBAGewsdbKrLGQ4JSGjm7Jh1KYkEHWtZTasRrl69iP1l8wrI4c6nRJ/F6UPSaYdVMRp5bY= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0848.namprd00.prod.outlook.com (2603:10b6:5:1bf::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4058.0; Thu, 8 Apr 2021 13:48:50 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 13:48:49 +0000 From: Mike Jones To: "francesca.palombini@ericsson.com" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMekdJv5IcULvQ1qzavuY873M4wAOwfAAAAQud6A= Date: Thu, 8 Apr 2021 13:48:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:41:17Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cdfb0104-3004-44ad-80cf-5c9eac18df57; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2607:fb90:b2d9:b46f:e920:2135:f44b:10a6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 546cc217-bc56-4bfc-52ef-08d8fa950a1c x-ms-traffictypediagnostic: DM6PR00MB0848: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bXqxdDyqlhiICh6hRnLAFnSPF5/MWFemZYTEv2IhsrrWBdugGaAkX0mj7JZWbE7/RXDR51Xsxaw99r9iydYXsH9BB7ln+n2mEpjTQnRNL9aBhiYjSztOPHj0pPmWTn3GHDhgoGYYCFALBcqah3sPramDU5ejwzec5Vx3A0uuMOfpKMXxqAoeznlfODqm3uvvz9NJpxyQfFmH8dhaXNaWEE3fdPaC6heBiFnax+J/cfUw3C/iCS/hEqs66EPbzX/yz2LfIcwDrV3NdZ3cA3adzjcUegyWYKHxELe1BEqr/Y+Ac1ckIUrT9e+F6pLg3b4PCryqVtcaZROOmw/Al5NHtcFEmMOukwTVhFIZLlTXvyE0D/xhqEXLQ65hEkDJjUUTiY5HAOwE67IrtVVkaNX5v8CwyJd2zFdMKZN1omdzBA0MzoV64FWfn81A7vo5wHz84D73eyWa3jC2vwaJ68wljYWL21UtrS2NneUp7/QJIe+E1HEQqcLVIS2Cp4Cr4fjEJsn99avdIbW2AA+RYT/e4HbltyxJm7J1OTztn6QNqW9lXLQcYMT3szYijtdfliz//iP0b+ktg9Q0lwyELUyNAQbo+275+3npC2OP/Zft6qLCia5Fdudjq4KocCRUJDZhwjljcEOwj6hFKom3I3y/bHZ7MME48ivFv9JCDtyAqUN0ZSKBJmhaZclBkPKvgNgGgm6ZwCmNsZLZ8fu44GnEg3NfLeZn7HgcTSgI2xMVcKg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(478600001)(6506007)(186003)(66476007)(966005)(316002)(4326008)(66946007)(76116006)(10290500003)(66556008)(86362001)(110136005)(54906003)(66446008)(8990500004)(71200400001)(64756008)(83380400001)(8936002)(52536014)(7696005)(55016002)(9686003)(33656002)(5660300002)(8676002)(38100700001)(2906002)(82950400001)(82960400001)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?bXE1WG9LSElnNnRQZGc4WUFxWW5Ib1F4MEdpdDVoL1Q5SEw4RCtnZ0EvRkx2?= =?utf-8?B?T1NPSjRWcHYrZGZpWDJ3Z3JaSXE5QlEzbTRrT0hhZE5CYi9zZUtwb2ZCRERR?= =?utf-8?B?WDE0NmN5a3hEczN0RzRCMGR2cVdESFNicjlsRHVxalppRlVxcDhNNmZ5QUZ6?= =?utf-8?B?ZXZIRzV3RnZJZmZtRDJrOEsyNHZoeSswS0pvUGRhRktiMXRvanVBRnN0bU5u?= =?utf-8?B?dGZpOTJHZCsrT2tveWZpNkNVZGN4UDRha1pTWnN5cXNGTG9td1FTSmdJSTRP?= =?utf-8?B?dkJ4R0ZHTUMrcTVNbHQvdWJHR1VMTDJ5Z3c1VTJYOTVJL1BxRWFwTzZWTGVS?= =?utf-8?B?NHZmZ2thYTRUUTlNVnFwc2UwMkVlN01TM1hJSWYydmcrT1NCSG5kQlVQVHJU?= =?utf-8?B?eW9VaEpnVmN2dG5jbjF3OTFKWGsvS2diVTdobU5FT3Qvbk9obzNKK3p2eTFX?= =?utf-8?B?YUZ4Z1FnZjJObkd5U0JBU3Z2aVVxbW1UT0JJWE1QOGVkcUNEMyt3YTlra3Ay?= =?utf-8?B?QkZ2ZGlsUkFWU2UraFA1VitaL1hBMDFrTklUVWptc29lMktjT041YzA1alNB?= =?utf-8?B?Zm42bTdXd1Q1dmNVMlhHcEFmcTFnUllReXhJUDJBK25acncrYVZ2alJNbUpE?= =?utf-8?B?UytTNldvVDNHRTdvMHMwSkEzNXVUcjhwRmI0ZkxEL1RJSVU1ekp4R2U1cS8x?= =?utf-8?B?cUUzckphK1hwamtGUS8vakxqWjF5RUdyT29qRHM1ZE5zUC9lV2tKMVp0R3VI?= =?utf-8?B?ZmtUWitFTmwrbEQrbUFZSDFwNTBNTDdVOGQvR2lZNXYxM2lITWRsSjJCbkNP?= =?utf-8?B?cktkMXg4b2E2T25uRE02VkRNWHpHUmdkMm1oTHB3YS9sVmNDOVNCUEF3SlpG?= =?utf-8?B?SEhQdGZiNGtuZDh6QVk5V2NuM1BZTVhXUXc1bWpXc1RXZWhjY3lmL2FqVWR2?= =?utf-8?B?YlhRWGV4M1c4QnhxdmxrUlFwNDV4MFUzV3h2MGRRcnJjZ2tTVldFT1BjRWtC?= =?utf-8?B?ejQ0cGlWbjJnbnU5QWdJUVVjSEMvbUd0ZEhqQXBTb0o3WGdPSVh0WnI5cHBU?= =?utf-8?B?VWJiYStzTGxCa0lzWitVNEZaanJ1RkFyMGc2ODNlSWxYdlBzQlJZWmJrTFBB?= =?utf-8?B?UW9TMUV4dUcrd090Rmtkd3ZpWmwyclp0TjA4cUxXOWFVcG1IMjNBWnpZek9n?= =?utf-8?B?NzBOTTYwc1c2cWRUNlErUUtST29heDVMcDUveVJOc29aMVFCMENVMWM3Qk9l?= =?utf-8?B?M0MzZ3RBbG5OQVBvZFEweER1Nk9veFVXZXVuUjh2Y0tMUDU4bXRkZzA5bnRh?= =?utf-8?B?MmhoaGNXV3pSZEZtenpQZ3lLc0RYaHZDYUJPWTZBRzVHZ0JRc1llMFB3ZXpq?= =?utf-8?B?WTFhUmpYNEZtNWU0N0p5YTN3K3JWazVWRWNsMnZpaHIrd0hFWDhsaERYSDB3?= =?utf-8?B?cFJVUitkNFU3cWE1R3NFQ1UvajdLR0tKeTZFQlhCdmpmWFVTUVA1M3JjWFVT?= =?utf-8?B?WHBRTmV2bDZuR25NRTZMWEZkV25qczlmbnhSNE9rR2RuTmNMRWFleEVRa2l6?= =?utf-8?B?c015ZnhYQ2tQelZ2aGFxZHJlaTh0NWVCWE80Vlp3czBRZURYY1ErY2x6ZzBi?= =?utf-8?B?M3JHQ2lsVFpTY08rd25hb1ZCd3RmY1Zlb3FpMWJ3eERCT2NxZUVLMGVVN2hu?= =?utf-8?B?cDZETytzVUNlbzV4a3FaOWJIaXhsMUhjaFFHb29iM0Ztcmw1Yk85bTZ3OEJI?= =?utf-8?B?VFdWb0tleGpNMkt6U1pXSGdDelRpb0syclYyZExkdDRmVysxdGJ5Z2JWK3dQ?= =?utf-8?B?L3RRUFJxSVQzclQvMzVlNmlyTU5BOFZsS1JqV0JubGhjeW9QRU5FbUNrTytM?= =?utf-8?Q?p6JwbbhkYLRp1?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 546cc217-bc56-4bfc-52ef-08d8fa950a1c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 13:48:49.8875 (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: ictj71NCLwUJvk5D2tjbkoU+01La3RZRlfi3MTK+jjAOb+DxciqnXx8peOo875dK3kfsUYKY0Ivum6dMtqWcew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0848 Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 13:49:10 -0000 VGhhbmtzIGZvciBzd2VhdGluZyB0aGUgZGV0YWlscywgRnJhbmNlc2NhLiAgSSdsbCBwbGFuIHRv IHB1Ymxpc2ggYW4gdXBkYXRlZCBkcmFmdCBhZnRlciB0aGUgdGVsZWNoYXQgbWFraW5nIHRoZSBl cnJvciBoYW5kbGluZyBmb3IgdGhlIGNhc2Ugd2hlbiB0aGUga2V5IGlzbid0IGFzc29jaWF0ZWQg d2l0aCB0aGUgY2xpZW50IGNsZWFyZXIuDQoNCgkJCQlUaGFua3MgYWdhaW4sDQoJCQkJLS0gTWlr ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRnJhbmNlc2NhIFBhbG9tYmlu aSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+IA0KU2VudDogVGh1cnNkYXksIEFw cmlsIDgsIDIwMjEgMjo0NyBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT47IGllc2dAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcUBpZXRm Lm9yZzsgb2F1dGgtY2hhaXJzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzsgSGFubmVzLlRzY2hv ZmVuaWdAZ214Lm5ldA0KU3ViamVjdDogUmU6IEZyYW5jZXNjYSBQYWxvbWJpbmkncyBObyBPYmpl Y3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzI6ICh3aXRoIENPTU1FTlQpDQoNCkhp IE1pa2UhDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlcGx5LiBJdCBsb29rcyBnb29kIHRvIG1l LCBqdXN0IG9uZSBhbnN3ZXIgdG8gcG9pbnQgNC4gOg0KDQogICAgNC4gLS0tLS0NCg0KICAgICAg IHNwZWNpZmllZCBpbiB0aGUgImFsZyIgSGVhZGVyIFBhcmFtZXRlci4gIElmIGEgImtpZCIgSGVh ZGVyIFBhcmFtZXRlcg0KICAgICAgIGlzIHByZXNlbnQsIHRoZSBrZXkgaWRlbnRpZmllZCBNVVNU IGJlIHRoZSBrZXkgdXNlZCwgYW5kIE1VU1QgYmUgYQ0KICAgICAgIGtleSBhc3NvY2lhdGVkIHdp dGggdGhlIGNsaWVudC4gIEFsZ29yaXRobSB2ZXJpZmljYXRpb24gTVVTVCBiZQ0KDQogICAgLi4u DQoNCiAgICAgICBzYW1lIHBhcmFtZXRlciBpcyBwcm92aWRlZCBpbiB0aGUgcXVlcnkgcGFyYW1l dGVyLiAgVGhlIENsaWVudCBJRA0KICAgICAgIHZhbHVlcyBpbiB0aGUgImNsaWVudF9pZCIgcmVx dWVzdCBwYXJhbWV0ZXIgYW5kIGluIHRoZSBSZXF1ZXN0IE9iamVjdA0KICAgICAgICJjbGllbnRf aWQiIGNsYWltIE1VU1QgYmUgaWRlbnRpY2FsLiAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRo ZW4NCg0KICAgIEZQOiAiTVVTVCBiZSBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudCIg LSB3aGF0IGlmIGl0IGlzIG5vdD8gZG9lcyB0aGUgQVMgcmV0dXJuIGFuIGVycm9yIHRvIHRoZSBj bGllbnQgdGhlbj8gU2FtZSBjb21tZW50ICIuLi4gTVVTVCBiZSBpZGVudGljYWwiIC0gaXMgYW55 IGVycm9yIHJldHVybmVkIGlmIGl0J3Mgbm90Pw0KDQogICAgTWlrZT4gSSBiZWxpZXZlIHRoYXQg dGhlIHJlc3BvbnNlcyB0byB0aGVzZSB2YWxpZGF0aW9uIGVycm9ycyBhcmUgYWxyZWFkeSBkZXNj cmliZWQgaW4gdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgsIHdoaWNoIHNheXMgIklmIHNpZ25hdHVy ZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4g YW4gJ2ludmFsaWRfcmVxdWVzdF9vYmplY3QnIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9u c2UgdG8gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4iDQoNCkZQOiBBcyBJIHJlYWQgaXQsIHRo ZSBmaXJzdCBwYXJhZ3JhcGggc2F5czogDQoNCiAgIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBN VVNUIHZhbGlkYXRlIHRoZSBzaWduYXR1cmUgb2YgdGhlIEpTT04gV2ViDQogICBTaWduYXR1cmUg W1JGQzc1MTVdIHNpZ25lZCBSZXF1ZXN0IE9iamVjdC4gIElmIGEgImtpZCIgSGVhZGVyDQoNClRo ZW4gZm9sbG93cyB1cCB3aXRoIGEgbnVtYmVyIG9mIG90aGVyIGNoZWNrcyB0aGF0IG5lZWQgdG8g YmUgZG9uZSAodGhlIHRleHQgSSBxdW90ZWQgaW4gbXkgb3JpZ2luYWwgY29tbWVudCkuIEFuZCB0 aGVuIGVuZHMgd2l0aCB0aGUgc2VudGVuY2UgeW91IHF1b3RlZDoNCg0KICAgSWYgc2lnbmF0dXJl IHZhbGlkYXRpb24gZmFpbHMsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVybg0K ICAgYW4gImludmFsaWRfcmVxdWVzdF9vYmplY3QiIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVz cG9uc2UgdG8gdGhlDQogICBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQoNClNhbWUgZm9yIHRoZSBz ZWNvbmQgLSB0aGUgdGV4dCBJIHJlcG9ydGVkIGlzIGZvbGxvd2VkIGJ5Og0KDQogIFRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciB0aGVuDQogICB2YWxpZGF0ZXMgdGhlIHJlcXVlc3QgYXMgc3BlY2lm aWVkIGluIE9BdXRoIDIuMCBbUkZDNjc0OV0uDQoNCkFuZCB0aGVuIGFnYWluIGZyb20gdGhlIHRl eHQgeW91IHF1b3RlZDoNCg0KICAgSWYgdGhlIHZhbGlkYXRpb24gZmFpbHMsIHRoZW4gdGhlIEF1 dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuIGFuDQogICBlcnJvciB0byB0aGUgY2xpZW50 IGluIHJlc3BvbnNlIHRvIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGFzDQogICBzcGVjaWZp ZWQgaW4gU2VjdGlvbiA1LjIgb2YgT0F1dGggMi4wIFtSRkM2NzQ5XS4NCg0KU28gd2hpbGUgcmVh ZGluZyBJIGNvbnNpZGVyZWQgdGhhdCB0aGUgdmFsaWRhdGlvbiAoZWl0aGVyIG9mIHRoZSBzaWdu YXR1cmUgZm9yIHBhciAxIG9yIG9mIHRoZSByZXF1ZXN0IGZvciBwYXIgMikgaXMgc2VwYXJhdGUg ZnJvbSB0aGUgYWRkaXRpb25hbCBjaGVja3MuIFRoZSBpbnRlbnQgb2YgaXQgY291bGQgYmUgbWFk ZSBjbGVhciBieSBhIG1pbm9yIGFkZGl0aW9uIGluIGVhY2ggcGFyOg0KDQoxc3QgcGFyYWdyYXBo Og0KDQpPTEQ6DQoNCiAgIElmIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUgQXV0aG9y aXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4NCiAgIGFuICJpbnZhbGlkX3JlcXVlc3Rfb2JqZWN0 IiBlcnJvciB0byB0aGUgY2xpZW50IGluIHJlc3BvbnNlIHRvIHRoZQ0KICAgYXV0aG9yaXphdGlv biByZXF1ZXN0Lg0KDQpORVc6DQoNCiAgIElmIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGZpYWxzLCBv ciBpZiB0aGUga2V5IGlkZW50aWZpZWQgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50 LCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4NCiAgIGFuICJpbnZhbGlkX3Jl cXVlc3Rfb2JqZWN0IiBlcnJvciB0byB0aGUgY2xpZW50IGluIHJlc3BvbnNlIHRvIHRoZQ0KICAg YXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KDQoybmQgcGFyYWdyYXBoOg0KDQpPTEQ6DQoNCiAgIElm IHRoZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNU IHJldHVybiBhbg0KICAgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiByZXNwb25zZSB0byB0aGUgYXV0 aG9yaXphdGlvbiByZXF1ZXN0LCBhcw0KICAgc3BlY2lmaWVkIGluIFNlY3Rpb24gNS4yIG9mIE9B dXRoIDIuMCBbUkZDNjc0OV0uDQoNCk5FVzoNCg0KICAgSWYgdGhlIHZhbGlkYXRpb24gb2YgdGhl IHJlcXVlc3Qgb3IgdGhlIENsaWVudCBJRCBjaGVjayBmYWlscywgdGhlbiB0aGUgQXV0aG9yaXph dGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4NCiAgIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVz cG9uc2UgdG8gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXMNCiAgIHNwZWNpZmllZCBpbiBT ZWN0aW9uIDUuMiBvZiBPQXV0aCAyLjAgW1JGQzY3NDldLg0KDQoNCkkgdGhpbmsgdGhpcyB3b3Vs ZCBjbGFyaWZ5IHRoZSB0ZXh0LCBidXQgSSdsbCBsZWF2ZSBpdCB1cCB0byB5b3UgdG8gZGVjaWRl IGlmIGl0J3Mgd29ydGggYWRkaW5nLg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDA4LzA0 LzIwMjEsIDA2OjQ1LCAiTWlrZSBKb25lcyIgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4g d3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBGcmFuY2VzY2EuICBXZSd2ZSBw dWJsaXNoZWQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandz cmVxLTMzIHRvIGFkZHJlc3MgeW91ciBhbmQgb3RoZXIgSUVTRyBjb21tZW50cy4NCg0KICAgIFJl c3BvbnNlcyBhcmUgaW5saW5lIGJlbG93LCBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQogICAgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIHZp YSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gDQogICAgU2VudDogV2VkbmVzZGF5LCBB cHJpbCA3LCAyMDIxIDM6MjkgQU0NCiAgICBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQog ICAgQ2M6IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxQGlldGYub3JnOyBvYXV0aC1jaGFpcnNAaWV0 Zi5vcmc7IG9hdXRoQGlldGYub3JnOyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0DQogICAgU3Vi amVjdDogRnJhbmNlc2NhIFBhbG9tYmluaSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9h dXRoLWp3c3JlcS0zMjogKHdpdGggQ09NTUVOVCkNCg0KICAgIEZyYW5jZXNjYSBQYWxvbWJpbmkg aGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgZHJhZnQt aWV0Zi1vYXV0aC1qd3NyZXEtMzI6IE5vIE9iamVjdGlvbg0KDQogICAgV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNCiAgICBQ bGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy1jcml0ZXJpYS5odG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQogICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLw0KDQoN Cg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICAgIFRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgb24gdGhpcyBkb2N1bWVudC4gSSBvbmx5IGhhdmUg bWlub3IgY29tbWVudHMsIHRoZSBtb3N0IGludGVyZXN0aW5nIGlzIHByb2JhYmx5IDQuIGFib3V0 IGlmIGFkZGl0aW9uYWwgZmFpbHVyZSBiZWhhdmlvciBzaG91bGQgYmUgZGVmaW5lZCBhdCB0aGUg QVMuDQoNCiAgICBGcmFuY2VzY2ENCg0KICAgIDEuIC0tLS0tDQoNCiAgICAgICBBIFJlcXVlc3Qg T2JqZWN0IChTZWN0aW9uIDIuMSkgaGFzIHRoZSAibWltZS10eXBlIiAiYXBwbGljYXRpb24vDQoN CiAgICBGUDogUGxlYXNlIHVzZSAibWVkaWEgdHlwZSIgaW5zdGVhZCBvZiAibWltZS10eXBlIiBh bmQgcmVmZXJlbmNlDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4MzgNCg0K ICAgIE1pa2U+IFRoYW5rcywgdXBkYXRlZCwgYWx0aG91Z2ggcmVmZXJlbmNpbmcgUkZDIDIwNDYg Zm9yIHRoZSB0ZXJtICJtZWRpYSB0eXBlIiAod2hpY2ggaXMgbm90IHN1cGVyc2VkZWQgYnkgUkZD IDY4MzgpLg0KDQogICAgMi4gLS0tLS0NCg0KICAgICAgIFRoZSBmb2xsb3dpbmcgaXMgYW4gZXhh bXBsZSBvZiB0aGUgQ2xhaW1zIGluIGEgUmVxdWVzdCBPYmplY3QgYmVmb3JlDQogICAgICAgYmFz ZTY0dXJsIGVuY29kaW5nIGFuZCBzaWduaW5nLiAgTm90ZSB0aGF0IGl0IGluY2x1ZGVzIHRoZSBl eHRlbnNpb24NCg0KICAgIEZQOiBUaGlzIGV4YW1wbGUgaXMgdGhlIGZpcnN0IHRpbWUgImJhc2U2 NHVybCIgYXBwZWFycyBpbiB0aGUgZG9jdW1lbnQuIEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5z ZSB0byBtZW50aW9uIHRoYXQgYmFzZTY0dXJsIGlzIHVzZWQgd2hlbiBKV1QgaXMgaW50cm9kdWNl ZCwgZm9yIGV4YW1wbGUgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQuDQoNCiAg ICBNaWtlPiBSZWZlcmVuY2UgYWRkZWQuDQoNCiAgICAzLiAtLS0tLQ0KDQogICAgICAgSWYgZGVj cnlwdGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuIGFuDQog ICAgICAgImludmFsaWRfcmVxdWVzdF9vYmplY3QiIGVycm9yLg0KDQogICAgLi4uDQoNCiAgICAg ICBJZiBzaWduYXR1cmUgdmFsaWRhdGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVy IE1VU1QgcmV0dXJuDQogICAgICAgYW4gImludmFsaWRfcmVxdWVzdF9vYmplY3QiIGVycm9yLg0K DQogICAgLi4uDQoNCiAgICAgICBJZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhlbiB0aGUgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4NCiAgICAgICBlcnJvciBhcyBzcGVjaWZp ZWQgaW4gT0F1dGggMi4wIFtSRkM2NzQ5XS4NCg0KICAgIEZQOiB2ZXJ5IG1pbm9yLCBidXQgSSBz dWdnZXN0cyB5b3UgYWRkICJ0byB0aGUgY2xpZW50LCBpbiByZXNwb25zZSB0byB0aGUgcmVxdWVz dCBkZWZpbmVkIGluIDUuMi4yLiBvZiB0aGlzIHNwZWNpZmljYXRpb24iLiBUaGUgcmVhc29uIGlz IHRoYXQgdGhlIGRvYyBzcGVjaWZpZXMgdGhhdCB0aGUgQVMgbWlnaHQgYmUgaGF2aW5nIG90aGVy IGV4Y2hhbmdlcyAodG8gZmV0Y2ggdGhlIFJlcXVlc3QNCiAgICBPYmplY3QpIGF0IHRoZSBzYW1l IHRpbWUsIGFuZCBpdCBjYW4ndCBodXJ0IHRvIGJlIHByZWNpc2UuIEFsc28gcmVnYXJkaW5nIHRo ZSByZWZlcmVuY2UgdG8gUkZDIDY3NDkgLSBjYW4geW91IGFkZCBhIHNwZWNpZmljIHNlY3Rpb24g dG8gcmVmZXJlbmNlPw0KDQogICAgTWlrZT4gRG9uZQ0KDQogICAgNC4gLS0tLS0NCg0KICAgICAg IHNwZWNpZmllZCBpbiB0aGUgImFsZyIgSGVhZGVyIFBhcmFtZXRlci4gIElmIGEgImtpZCIgSGVh ZGVyIFBhcmFtZXRlcg0KICAgICAgIGlzIHByZXNlbnQsIHRoZSBrZXkgaWRlbnRpZmllZCBNVVNU IGJlIHRoZSBrZXkgdXNlZCwgYW5kIE1VU1QgYmUgYQ0KICAgICAgIGtleSBhc3NvY2lhdGVkIHdp dGggdGhlIGNsaWVudC4gIEFsZ29yaXRobSB2ZXJpZmljYXRpb24gTVVTVCBiZQ0KDQogICAgLi4u DQoNCiAgICAgICBzYW1lIHBhcmFtZXRlciBpcyBwcm92aWRlZCBpbiB0aGUgcXVlcnkgcGFyYW1l dGVyLiAgVGhlIENsaWVudCBJRA0KICAgICAgIHZhbHVlcyBpbiB0aGUgImNsaWVudF9pZCIgcmVx dWVzdCBwYXJhbWV0ZXIgYW5kIGluIHRoZSBSZXF1ZXN0IE9iamVjdA0KICAgICAgICJjbGllbnRf aWQiIGNsYWltIE1VU1QgYmUgaWRlbnRpY2FsLiAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRo ZW4NCg0KICAgIEZQOiAiTVVTVCBiZSBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudCIg LSB3aGF0IGlmIGl0IGlzIG5vdD8gZG9lcyB0aGUgQVMgcmV0dXJuIGFuIGVycm9yIHRvIHRoZSBj bGllbnQgdGhlbj8gU2FtZSBjb21tZW50ICIuLi4gTVVTVCBiZSBpZGVudGljYWwiIC0gaXMgYW55 IGVycm9yIHJldHVybmVkIGlmIGl0J3Mgbm90Pw0KDQogICAgTWlrZT4gSSBiZWxpZXZlIHRoYXQg dGhlIHJlc3BvbnNlcyB0byB0aGVzZSB2YWxpZGF0aW9uIGVycm9ycyBhcmUgYWxyZWFkeSBkZXNj cmliZWQgaW4gdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgsIHdoaWNoIHNheXMgIklmIHNpZ25hdHVy ZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4g YW4gJ2ludmFsaWRfcmVxdWVzdF9vYmplY3QnIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9u c2UgdG8gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4iDQoNCiAgICA1LiAtLS0tLQ0KDQogICAg ICAgbG9jYXRpb24sIChiKSBjaGVjayB0aGUgY29udGVudCB0eXBlIG9mIHRoZSByZXNwb25zZSBp cyAiYXBwbGljYXRpb24vDQoNCiAgICBGUDogRm9yIGNvbnNpc3RlbmN5LCBwbGVhc2UgY2hhbmdl ICJjb250ZW50IHR5cGUiIHRvICJtZWRpYSB0eXBlIi4NCg0KICAgIE1pa2U+IERvbmUNCg0KICAg IAkJCQlUaGFua3MgYWdhaW4sDQogICAgCQkJCS0tIE1pa2UNCg0KDQoNCg== From nobody Thu Apr 8 08:53:48 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3313A0C06 for ; Thu, 8 Apr 2021 08:53:46 -0700 (PDT) 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 eE7mPL4LpYu9 for ; Thu, 8 Apr 2021 08:53:41 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E0C3A0C03 for ; Thu, 8 Apr 2021 08:53:41 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id CC76823EB8; Thu, 8 Apr 2021 15:53:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1617897211; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bRhdyi2RSgMDY7+01zKc/VOOOqvy2ctvgrdn82OuvLo=; b=hX8iJq0H3N8enem7RRZV/cjpQpFG82BLxdusGZGKoHVF6cOGOuZVKUmzmFAoyAts5BoHkl cKo/4iWdekUcvdJAIvMp7m3VZJ6V4CZPM4MoO5aFAT8qB7dqLenMty5Wbxc9zry+LIJnjT utvpYzKmyAfA2OZGBAInpmvNF6ZBZqA= To: George Fletcher , oauth@ietf.org References: <161771436122.1506.973742618731100764@ietfa.amsl.com> <63c57751-ff04-4e75-a74d-c4ba1105fb56@danielfett.de> <35d57c1b-5e1f-aec7-8669-c93260e873da@aol.com> From: Daniel Fett Message-ID: <10e3f3b4-9f96-153a-fe41-0a2b3c27f095@danielfett.de> Date: Thu, 8 Apr 2021 17:53:30 +0200 MIME-Version: 1.0 In-Reply-To: <35d57c1b-5e1f-aec7-8669-c93260e873da@aol.com> Content-Type: multipart/alternative; boundary="------------D919D254C028EE8689CE991F" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1617897211; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bRhdyi2RSgMDY7+01zKc/VOOOqvy2ctvgrdn82OuvLo=; b=GlR0G/9iCW9CfkEDK4OyMz3mUksn9ZJzQ70JUyNYz0eTGTYAbZyhOYof8990cJG99582XB o54sbeA6n20JbB+d2Gz7UbLElr1vx/Rkd/sMB3BQcBFlYMc+FVROZOzuy+//Nvi4HhlZiY X55x9kE6LEtRKRgTeNb4KRzsWWE9+CE= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1617897211; a=rsa-sha256; cv=none; b=DoW+pVAaOIhMqUUQZAGOmnJMCHKGn191Ztq2u5jgspqoNd9oPgT4wQyXXwaFNdgyTiXF44 Y11qDLjBXIiun1lUB0qHhYBlOqkzr5lygzi1HPV/vGrbtI+OYzTNdXlt+M0nf4IgFS34my RVSPGzFzdFsVvKiBSnsOMF2AydlXuaE= 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] I-D Action: draft-ietf-oauth-security-topics-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 15:53:46 -0000 This is a multi-part message in MIME format. --------------D919D254C028EE8689CE991F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi George, client impersonation is covered extensively in RFC6749 already, with further recommendations in RFC6819. The basics of this attack have not changed since public clients where introduced, but, as you mention, on mobile operating systems we see new mechanics for authenticating clients (or the lack thereof). I worked together with Joseph Heenan and Fabian Hauck to develop new best practices in this area [1]. I feel that the complexity of this whole topic would be much better dealt with in an update to BCP 212 (RFC 8252). Since the basics have been covered elsewhere, I do not see an immediate need to update the security BCP and quite frankly, I fear that this would set us back at least another year or so. -Daniel [1] https://danielfett.de/2020/11/27/improving-app2app/ Am 07.04.21 um 22:06 schrieb George Fletcher: > While this is mostly covered in section 8.6 of RFC 8252 for native > apps, I wonder if we shouldn't mention "Client Impersonation" in this > doc as well in that any public client can be easily impersonated. > Mobile OS's are providing additional mechanisms for "authenticating" > the client but it's unclear whether those will be made available in > desktop environments where native apps also exist. At this stage > Universal Links (iOS) and App Links (Android) should be best practice > for any mobile native app. Best practice for desktop apps is less clear. > > Impersonating a public client is very easy especially if the only > mechanism available for the callback is a custom scheme URL. > > Thoughts? > > On 4/6/21 9:15 AM, Daniel Fett wrote: >> Hi all, >> >> this version most importantly updates the recommendations for Mix-Up >> mitigation, building upon >> https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The >> description of Mix-Up attacks has also been improved. >> >> Smaller changes: >> >>    * Make the use of metadata RECOMMENDED for both servers and clients >>    * Make announcing PKCE support in metadata the RECOMMENDED way >> (before: either metadata or deployment-specific way) >>    * AS also MUST NOT expose open redirectors. >>    * Mention that attackers can collaborate. >>    * Make HTTPS mandatory for most redirect URIs. >> >> I'll present more details in the interim meeting next monday. >> >> As always, your feedback is appreciated. We hope that we can proceed >> to a WGLC for this document soon. >> >> -Daniel >> >> Am 06.04.21 um 15:06 schrieb internet-drafts@ietf.org: >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Web Authorization Protocol WG of the IETF. >>> >>> Title : OAuth 2.0 Security Best Current Practice >>> Authors : Torsten Lodderstedt >>> John Bradley >>> Andrey Labunets >>> Daniel Fett >>> Filename : draft-ietf-oauth-security-topics-17.txt >>> Pages : 52 >>> Date : 2021-04-06 >>> >>> 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 is also an HTML version available at: >>> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17 >>> >>> >>> 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 >> >> >> -- >> https://danielfett.de >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- https://danielfett.de --------------D919D254C028EE8689CE991F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi George,

client impersonation is covered extensively in RFC6749 already, with further recommendations in RFC6819. The basics of this attack have not changed since public clients where introduced, but, as you mention, on mobile operating systems we see new mechanics for authenticating clients (or the lack thereof).

I worked together with Joseph Heenan and Fabian Hauck to develop new best practices in this area [1]. I feel that the complexity of this whole topic would be much better dealt with in an update to BCP 212 (RFC 8252).

Since the basics have been covered elsewhere, I do not see an immediate need to update the security BCP and quite frankly, I fear that this would set us back at least another year or so.

-Daniel


[1] https://danielfett.de/2020/11/27/improving-app2app/



Am 07.04.21 um 22:06 schrieb George Fletcher:
While this is mostly covered in section 8.6 of RFC 8252 for native apps, I wonder if we shouldn't mention "Client Impersonation" in this doc as well in that any public client can be easily impersonated. Mobile OS's are providing additional mechanisms for "authenticating" the client but it's unclear whether those will be made available in desktop environments where native apps also exist. At this stage Universal Links (iOS) and App Links (Android) should be best practice for any mobile native app. Best practice for desktop apps is less clear.

Impersonating a public client is very easy especially if the only mechanism available for the callback is a custom scheme URL.

Thoughts?

On 4/6/21 9:15 AM, Daniel Fett wrote:
Hi all,

this version most importantly updates the recommendations for Mix-Up mitigation, building upon https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The description of Mix-Up attacks has also been improved.

Smaller changes:

   * Make the use of metadata RECOMMENDED for both servers and clients
   * Make announcing PKCE support in metadata the RECOMMENDED way (before: either metadata or deployment-specific way)
   * AS also MUST NOT expose open redirectors.
   * Mention that attackers can collaborate.
   * Make HTTPS mandatory for most redirect URIs.

I'll present more details in the interim meeting next monday.

As always, your feedback is appreciated. We hope that we can proceed to a WGLC for this document soon.

-Daniel

Am 06.04.21 um 15:06 schrieb internet-drafts@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-17.txt
	Pages           : 52
	Date            : 2021-04-06

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 is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html

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


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



-- 
https://danielfett.de

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



-- 
https://danielfett.de
--------------D919D254C028EE8689CE991F-- From nobody Thu Apr 8 09:52:49 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31293A11D9 for ; Thu, 8 Apr 2021 09:52:47 -0700 (PDT) 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 BPDih7boSXdp for ; Thu, 8 Apr 2021 09:52:45 -0700 (PDT) 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 646C63A11D8 for ; Thu, 8 Apr 2021 09:52:45 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id r8so5103365lfp.10 for ; Thu, 08 Apr 2021 09:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=pzGYMb9orr8N23Y4tVR1Tee/MMq9k1+f8oQnFELgomY=; b=tsnFE1GkEEk3e62M87Brm5U04IdU/6KUmRQyXJP85ddzqC4OYsEJVC/reW3S6P72Vq lMIFxb0LI8LllQ+rks9kb2EjeuqSgLNBZiJlJenAlgRU6ZOiK3f9/lC1rJcEAKZLmbM5 B8NpftqXlUO665Yn3gQdo6gylIdEndGwXDqAEXwx+vnvatCIuLBi06rEesjTKK11tUah mLD7ulK6LxFAgl+8rLJUj4Q19gEMPrxTROa4WX81YwDHLsZ+5xLZvveG/oP7T2zTW/QH D5h/A3dj1MqaxnkVP+gWOwwcn566ZqB2IVAqbWchmbMEJ86HBChUbknEiREFqDjbRQ9L 0JFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pzGYMb9orr8N23Y4tVR1Tee/MMq9k1+f8oQnFELgomY=; b=g9Rl6NqEVXWYhekyXeBTZjp6TPD47xMsydb+00evMropKEWv/VT1OMn59EuqKbuNB7 UAPCkPQbYvD0eCE/ZM4q3pqzKmlulDB6yXmiN4GTDn9VZKbr+XE+6rFInd7br1eFeTrg vLqGMnPk1f3KJBDrn9bL7jXi/49w+9kvXjY9O7rqf+Qg/QV1/LEYW05kLF830Xnydfdx rbNCOBPGL93dzWylMtJn7DVo/rPqDtlVPPQBMzauthL7bMgnYQdKqjfRbOY6oUiakWSf iWvI5kakeiyWzM12t/rWsjVvyW9gC6sso6TUfU74XuFT6dd4JwZ3cOZ89up3lh02c/3/ JQ0g== X-Gm-Message-State: AOAM531sFSu94l9TPvlmB4p/CaaUzoQmz869qRZmfsydaZS4vpG+NvNb ohXm+Z2LnE3zEDI/GED/9LigE1F7TEq1Fwod7KsLRyIE X-Google-Smtp-Source: ABdhPJzMY+XQ/ahpIyfk8heFFrvld8id38K3bExhlLSlOKpwyEHB1v5HOVSoyUWsq3CeBBIenW8WOw6v2qHE3j1fsRE= X-Received: by 2002:a19:c3d0:: with SMTP id t199mr3436918lff.221.1617900762170; Thu, 08 Apr 2021 09:52:42 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Thu, 8 Apr 2021 12:52:30 -0400 Message-ID: To: oauth Cc: Nat Sakimura , John Bradley , Michael.Jones@microsoft.com, Vittorio Bertocci Content-Type: multipart/alternative; boundary="000000000000360a2405bf78e03b" Archived-At: Subject: [OAUTH-WG] IESG has approved two OAuth WG docs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 16:52:48 -0000 --000000000000360a2405bf78e03b Content-Type: text/plain; charset="UTF-8" All, Today, the IESG has approved the *JWT Secured Authorization Request (JAR)* and *JWT Profile for Access Token* documents. https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ Congratulations to the authors and thanks to the WG members that helped with these documents. Regards, Rifaat & Hannes --000000000000360a2405bf78e03b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Today, the IESG has approved the <= b>JWT Secured Authorization Request (JAR) and JWT Profile for Access= Token=C2=A0documents.
h= ttps://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
<= /div>

Congratulations to the authors and thanks to the W= G members=C2=A0that helped with these documents.

R= egards,
=C2=A0Rifaat & Hannes

--000000000000360a2405bf78e03b-- From nobody Thu Apr 8 12:12:41 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F146F3A17EC; Thu, 8 Apr 2021 12:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 YgRtGOpxcB5x; Thu, 8 Apr 2021 12:12:31 -0700 (PDT) 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 8C4B13A17AF; Thu, 8 Apr 2021 12:12:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 138JCNYG032272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Apr 2021 15:12:28 -0400 Date: Thu, 8 Apr 2021 12:12:23 -0700 From: Benjamin Kaduk To: Martin Duke Cc: The IESG , draft-ietf-oauth-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Message-ID: <20210408191223.GT79563@kduck.mit.edu> References: <161730912872.14258.15710315415917535021@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161730912872.14258.15710315415917535021@ietfa.amsl.com> Archived-At: Subject: Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with 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: Thu, 08 Apr 2021 19:12:36 -0000 On Thu, Apr 01, 2021 at 01:32:08PM -0700, Martin Duke via Datatracker wrote: > Martin Duke has entered the following ballot position for > draft-ietf-oauth-access-token-jwt-12: No Objection > > 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-access-token-jwt/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (2.1) "...can use any signing algorithm." I presume there ought to be some > qualifiers on allowed algorithms? > > (4) and (5) "This specification > does not provide a mechanism for identifying a specific key as the > one used to sign JWT access tokens." > > I don't understand; there's a key ID right there in the token header? The concern here is about identifying keys authorized to sign JWS access tokens. The server-provided metadata that lists such keys has a single bucket that covers keys used for signing different things, so you don't get any security benefit from key isolation, and a compromise of any of the (other) keys listed by the server would allow the attacker to sign JWT access tokens that are accepted as valid. So in a sense this is not about which key was actually used, but rather which key is supposed to be used. > (4) I presume it's important that any resouree server rejection of the token > should be constant-time. Is this somewhere in the RFC tree, or do we need to > explicitly say it here and/or in Security Considerations? (A good question, but I don't actually have the answer handy in memory.) -Ben From nobody Thu Apr 8 12:14:22 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7013A17F7 for ; Thu, 8 Apr 2021 12:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 VmNlQYxgTp8Z for ; Thu, 8 Apr 2021 12:14:19 -0700 (PDT) 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 740E93A17F6 for ; Thu, 8 Apr 2021 12:14:19 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 138JECFf000447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Apr 2021 15:14:16 -0400 Date: Thu, 8 Apr 2021 12:14:11 -0700 From: Benjamin Kaduk To: Roberto Polli Cc: oauth Message-ID: <20210408191411.GU79563@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 19:14:21 -0000 Hi Roberto, On Fri, Apr 02, 2021 at 11:55:27AM +0200, Roberto Polli wrote: > Hi Vittorio et al, > > some considerations on oauth access token jwt follows. > You can see them here too > https://docs.google.com/document/d/1XsvBzGvhcY0N6vJNgLx6G1dJ5trvgwYRJA9F_NCakbU/edit > > An example with client_credential grant type would be nice too. > > My 2¢, > R. > > § 1.2 Terminology > > + The terms "Collision-Resistant", is used according to Section 2 of > {{JWT}}. > > §2.1 Header > > - mentioning "none" alg can be redundant. I'd reference all the JWT BCP > instead. > - I'd add an example header, eg > > ~~~ example > > { > > "typ": "at+jwt", > > "alg": "PS256" > > } > > ~~~ > > > § 2.2.1 Authentication Information Claims > > Is it worth mentioning the "implicit flow"? > > §2.2.2 Identity Claims > > - use the "Collision-Resistant" definition in {{JWT}} > > §2.2.3 Authorization Claims > > - " ... scope parameter..." should `scope` be quoted? > - "All the individual scope strings in the "scope" claim MUST have meaning > for the resources indicated in the "aud" claim." > ^ otherwise the error returned is ...? Should we reference §4 here? > > §2.2.3.1 Claims for Authorization Outside of Delegation Scenarios > - which are the delegated scenarios described in RFC7519? Do you refer to > "When using an administratively delegated > namespace" ? It is not clear to a first-reader. > > §3 Requesting a JWT Access Token > - an example with `client_credential` grant type would be great. > - iiuc `jti` is required, the example does not report it. That's a very good catch; thank you! -Ben > §4 Validating JWT Access Tokens > > - the step about forbidding "none" is limitative WRT JWT BCP 8725 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Apr 8 14:15:08 2021 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 C9FEF3A1CF9; Thu, 8 Apr 2021 14:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161791650375.5790.7664311489703706929@ietfa.amsl.com> Date: Thu, 08 Apr 2021 14:15:03 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-34.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 21:15:04 -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 : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Michael B. Jones Filename : draft-ietf-oauth-jwsreq-34.txt Pages : 36 Date : 2021-04-08 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, (b) the source of the communication is not authenticated, and (c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-34 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-34 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-34 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 8 14:20:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080E53A1D22; Thu, 8 Apr 2021 14:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Y_4flU4JiLKA; Thu, 8 Apr 2021 14:20:06 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640122.outbound.protection.outlook.com [40.107.64.122]) (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 566B33A1D1D; Thu, 8 Apr 2021 14:20:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OdRlaqbGhcp0Gx51eJYYz+t/2KaO6bwkGbFw+7ShFw0UWqibBX2/NuaQ3Cf918m+9Mk9Y69Idbq7SG3yOnxzETvwK+ERvuSR+hTyKvR4b2cNbp1f+n90VNru57XZWo7qZ2uG8WXwgl+h1Y9rEoU3D0CccoOSMImX29UkuNjRp77rUA/SpixDeY4a0FqsFjCX3d8PuvihVZC7cPzBvATnnTiX/TMv0udx/b7qedhhIO94Oltk/1/nukhaiU8X9F8h2vwrLYcRoJVqcKjkgdQWpjjmSJPhmu2qMx1fI1oAkAI24dyUN7Vz10J9XfZ/azkljBg1RAvI20aw+zij8nbhxQ== 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=5WOUl2ZJSDEIaZtfVN8tbDTEgldIsvLn5uz5HcKfQac=; b=DilkhdTvKeDVv/TafjkKL/TLBqJPGOKfRorvoWxuoXNyiDRmxGAd0fjYAFYhyX3hAaFsnGmt2K/lk1uW2vbgUwON0fhqk933Ok4lU3DMMlY1+ArlYKM0s2XIzPUcGjpDa0mWxwn/Z9j3zYNfx7ad/Dm/8/k0de3PjVHl32JRYLCmwoImqqq/eoVhoeLDlnbWF7sfRmAj+ouPSnyCRc44souuQqDFp2AcWhE8fhwh4R8dMnjsIjiu43JocdJXVWg+g/e8J95lErE53CkrlUCzX2qt+EYfNXMG39REmPOpsyTMwnWyJoq/ahWGimwJvBRNRZ7dyac8eZg6mjBHNW8CTw== 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=5WOUl2ZJSDEIaZtfVN8tbDTEgldIsvLn5uz5HcKfQac=; b=Q9reSdKH0Uk8mai/IaJYgvAoPT2f21fMclhJW8hxn/jpWoGd65OYoNzISDvD9JJYb89qEiTSXinwsLLRxwP3360asceQNSWA/opHZWNBwXsRA5mBLnroucUSbKpmSKKjgepdn/pvflVwKi6HdpuKdqzBZpWrAMlRqm+LVuXabQI= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0556.namprd00.prod.outlook.com (2603:10b6:5:165::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4061.0; Thu, 8 Apr 2021 21:19:50 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 21:19:50 +0000 From: Mike Jones To: "superuser@gmail.com" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-33: (with COMMENT) Thread-Index: AdcsfXHbVuEHxvFASVOnHTGuwDl8pAAN5avA Date: Thu, 8 Apr 2021 21:19:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T13:42:45Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9636321e-049b-45fc-8790-7dd1547eae25; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2607:fb90:b2d9:b46f:98fa:8445:2e2a:29e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 415b5423-3e42-47e2-b6c0-08d8fad40b53 x-ms-traffictypediagnostic: DM6PR00MB0556: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0XBOJhly2AghwvAIvTcgBaHh8FgVEc4faPr6cYGT99a6t8pcupCNgJ1PZE8GPO/29ommmVtIJqPsaBCe1Ti7HoIjdpD6qCHdJfZDy+H8mJbm6amHAR4NC1yP1y6GuFBeC5UV/dMqbb/StmS51luAoSGA1wzmvCWl1MYn0zbq7urv9q0uhuMutl5hjhsCYD6hbDTcWiq+3BjxjVTZD+okj2kjEdspVufGSApg9llD8yOZUI8eZ4fv5p56+W0jLp2LpNJVKlZrLXyWjE48U4EjtRYXfd1hVwKWOpssvcK6HtGtUB/+2SGqbbOgwK0o7qK5Gb7cq/uMMKNtVyWr6T7TEMEtt9G9b800a7lNkMKP59iemIGTrGZvtbQFRfKqiWIFwmzXXvRhrWpeUjy0Bt3H8JhALAFFlQl62ROwGsHDihOzH9OFxb9uUNe2ncrxBU4y8ExsLIhTATEHxmusrp9T9hc0SdiIr6FMx2x1yyWQBj07dDFf9ob9uORb3KE1o2+avbuKkrDstynLQgdy5O1eItutaVX8+aphUVl9+bxo/RCMp4tgDvyrBgB+jKojulKN21e+JaopaPVQneK/VbLzAJlFi+qfgEz0Liw9CNkOXhh++hm3u8/PrliHNVXuor7RJkwacEC19VToO+Zl5uOcAjqv21qG68JG4aa91Q0RIkpCb8BisOzWCA+CM3oWh6jfJH3wigaZXLtqDLcL87Jo9LhDwQ7karh/HM3bxVRlz6s= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(66446008)(966005)(9686003)(316002)(66556008)(82960400001)(82950400001)(54906003)(66946007)(86362001)(2940100002)(478600001)(7696005)(66476007)(8936002)(8676002)(8990500004)(6506007)(64756008)(55016002)(53546011)(2906002)(38100700001)(186003)(10290500003)(83380400001)(71200400001)(5660300002)(110136005)(4326008)(52536014)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?MWhXLzdXZElBUEZuV01wSDlrMzRiUWlUZDdvZks4eGwrTW15QVdDL1V0cWFG?= =?utf-8?B?aE5MbmRieFdZbWJ5a0pSRnBtd2I1MXpFbjVieC9wdFMrbDVpaGEzMTJtUkRV?= =?utf-8?B?Z0hISFhKL2RLSEpWa0QrU25KMjFVY2k5Uk9OaWZNOU9ZZmhUcmZGMG5tcWV5?= =?utf-8?B?SmxMclR4WUpWVHZLYzl4U0QxRWZtZkZDejUvd3lhenp2NG9aSEk2K1l5ZEY4?= =?utf-8?B?WkpGK0Y3N1h4WkRnb2FIWUVEMUx4RWlmNzdscmUyM0Q0OWZ2bWdnUTluNTJI?= =?utf-8?B?ZUpNSlViTTBoejB3UW16OUs3Z0VBcFdQMVRvVW91N29rNDc3eFQzNjBLSDV2?= =?utf-8?B?alp6VjYxY1FJZFJycjU1cEpVZStjT0VEVW9RMGZvVmtmeHFkcnFiS2N2Tjlp?= =?utf-8?B?aWw4bnYxOEhzTEIxdVF5UGo2N2NvSFZRSlhnMTExS1FlSUlDaVNhaHBkbkFp?= =?utf-8?B?N0xoZ1dhbmYwbmdqUXNlS1ltSHd3S2IyRnVxeGtudlhzM29WeGxJckJCcDhl?= =?utf-8?B?bkxsL01YbHFyK05vQUt3MmhUYTFITElsZXJHL2lObGd1NXlmSk9YU1JRN1B0?= =?utf-8?B?TlhOVFFPS0tDeUw5OXQzZzk4QTU5ODh2MGVhLy8zWTZLUHFQWlU2UUlCYmlT?= =?utf-8?B?VVBYUXZxZEpoRU03RFR5cVZqUmcvZWt4MTZRZWtKWSsyaDBncEpZY0l5TTlv?= =?utf-8?B?OU9ydlM0Qlp3ZVpPWDZXTmQzOWJ4eVpOVHNtTVhWSVJSMVdlL1JlbFFvKzdQ?= =?utf-8?B?eWRwYXFvbnovM0pyUkQzNEpyRHJ0aFh2Q2pUKzRTdlFvZFBZRUV5Rkhmek5B?= =?utf-8?B?OTlWa2J3aEFzcFYvZitrK1NLZDJpVm1CdDlwVTBjL1A1OVZZcklRVG5XMWwx?= =?utf-8?B?TTh0Rk9ETWNvOFNPVTR5dWRreEJKVW9vdEQ1UEkybmxWVm5PRHRqSHVYZFli?= =?utf-8?B?UFp4eFZDTHdKUjZaU0l6dnVUd0dVOUVmTnZnTWRBUzdjeHplQ0ZONHZCNStw?= =?utf-8?B?T0RMRldWNk5XNHJvR2lWWkFVM0JUNnFOQklWZ29MTUcyWHQ2VUl2TmM2Rzc2?= =?utf-8?B?UGpXRjAyT2dDbmFsZVFGbm5hMGhOUXlKV3pJMUxyZ1pDNSs2UWFlZ2Jud1N4?= =?utf-8?B?eUxmdURxOXpMbW5kZlJZSlVXV2RQYkkxckt2alZnajQ1N1V5eTNUUWsySDYx?= =?utf-8?B?NWtzTVRwaGU1aFpDU215SWJUY1RSRk5xU2RUU1Fsb1k1VkloSVZWdms3eno1?= =?utf-8?B?WW9MV25SeUZoRWtyVXpxSHFjNHN6NDBKdGtaa1ROT2lTMzVDUEtjeUk5b3dJ?= =?utf-8?B?eWZZcXU3UHZXWFp4Y2EydW80VlR2NEVMeTNsWExWTUt0dU5iKytqMFVucWc3?= =?utf-8?B?eEFPdzBuSTF1S2tmQ0o5SUpCMjNTeUNCYysxKzg4blVJL1ZaTTBWc3A3MUdQ?= =?utf-8?B?c3paTGZpWVdSMzVmSndWemJrZVFNZUpmbjh3VEQ4Ym5rR0p3bjJUTHRXbDhD?= =?utf-8?B?bTQ1WWJxMlliRkErTGNNcWgyMHBOTUJNd2N4VGNscldUM2xYYnlZRFVlVUVM?= =?utf-8?B?cUt5dFgzL1cxbm9LK2NOR0xaQW95QVFIdm40TkE4d2xYOVBXNlpFL3REaWsw?= =?utf-8?B?MHJEOEFxR1Y1dkZvL0h2S2pUY1hiM2ttRjdkeGFSNVpka2x0TmhYRlEyZy9q?= =?utf-8?B?dUg4Ulgvd1FQK0JIQU5YTlJiWkplWXI5MDl6djFLWlhiTFAzUkxZd2liZDd3?= =?utf-8?B?bk1PdUVZT1luMHlQYkpoem5UV0c5b0dCU3pTNEtIaDhka1M4ZVVIb01oakh2?= =?utf-8?B?U1IwWXJjWTkyWnlqWjl6dWlud0I4VVExMWlwRmg5MVJpdnVkNFpzMTYwUTU2?= =?utf-8?Q?T477AOkQOF3BO?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 415b5423-3e42-47e2-b6c0-08d8fad40b53 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 21:19:50.2261 (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: 0Hiaq8HUxC9+mGJRMP+5xJMJ8CDKmZj0uA1CP8clSKhCf09l3tC+XYD2oqqByJEpjh6inr5AC66Cz8AZs9HrVg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0556 Archived-At: Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-33: (with 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: Thu, 08 Apr 2021 21:20:11 -0000 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTM0IGlu Y29ycG9yYXRlcyB0aGUgZml4ZXMgeW91IHN1Z2dlc3RlZC4NCg0KCQkJCVRoYW5rcyBhZ2FpbiEN CgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWtlIEpv bmVzIA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDgsIDIwMjEgNjo0NiBBTQ0KVG86IE11cnJheSBL dWNoZXJhd3kgPHN1cGVydXNlckBnbWFpbC5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4N CkNjOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcUBpZXRmLm9yZzsgb2F1dGgtY2hhaXJzQGlldGYu b3JnOyBvYXV0aEBpZXRmLm9yZzsgSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldA0KU3ViamVjdDog UkU6IE11cnJheSBLdWNoZXJhd3kncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1q d3NyZXEtMzM6ICh3aXRoIENPTU1FTlQpDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcsIE11cnJh eS4gIE15IHJlcGxpZXMgYXJlIGlubGluZSwgcHJlZml4ZWQgYnkgIk1pa2U+Ii4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11cnJheSBLdWNoZXJhd3kgdmlhIERhdGF0cmFj a2VyIDxub3JlcGx5QGlldGYub3JnPiANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNywgMjAyMSAx MTo0MyBQTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtb2F1 dGgtandzcmVxQGlldGYub3JnOyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3Jn OyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0DQpTdWJqZWN0OiBNdXJyYXkgS3VjaGVyYXd5J3Mg Tm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMzOiAod2l0aCBDT01NRU5U KQ0KDQpNdXJyYXkgS3VjaGVyYXd5IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzM6IE5vIE9iamVjdGlvbg0KDQpX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS8NCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkFoLCBqd3NyZXEuICBX ZSBtZWV0IGFnYWluLiAgRm9ydHVuYXRlbHksIGxvb2tpbmcgb25seSBhdCB0aGUgZGlmZiBmcm9t IG15IGxhc3QgYmFsbG90IGNvbW1lbnRzIHRvIHRoaXMgb25lLCBJIG9ubHkgaGF2ZSBhIGNvdXBs ZSBvZiBtaW5vciB0aGluZ3MgdGhpcyB0aW1lOg0KDQpTZWN0aW9ucyA5LjIgYW5kIDkuMyBlYWNo IHNheSB0aGV5IGFyZSByZWdpc3RlcmluZyAidmFsdWVzIiwgYnV0IGVhY2ggcmVnaXN0ZXJzIG9u bHkgb25lLg0KDQpNaWtlPiBUaGFua3MuICBJIGNvcnJlY3QgdGhpcyBpbiBhbiB1cGRhdGVkIGRy YWZ0IGFmdGVyIHRoZSB0ZWxlY2hhdC4NCg0KIisxIiB0byBGcmFuY2VzY2EncyBwb2ludHMgIzEg YW5kICM1Lg0KDQpNaWtlPiBXZSBhZGRyZXNzZWQgdGhvc2UgcG9pbnRzIGluIGRyYWZ0IDMzIChw dWJsaXNoZWQgbGFzdCBuaWdodCwgbXkgdGltZSkuDQoNClRoYW5rcyBmb3IgY2hhbmdpbmcgdGhl IG1lZGlhIHR5cGUgbmFtZSB0byB1c2UgaHlwaGVucyBpbnN0ZWFkIG9mIGRvdHMuICBUaGF0IGF2 b2lkZWQgYSBiaWcgbWVzcy4NCg0KTWlrZT4gWW91J3JlIHdlbGNvbWUhDQoNCgkJCQktLSBNaWtl DQoNCg== From nobody Thu Apr 8 14:20:48 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD583A1D27; Thu, 8 Apr 2021 14:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 7dRWq88Ia_1s; Thu, 8 Apr 2021 14:20:35 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640121.outbound.protection.outlook.com [40.107.64.121]) (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 349A43A1D6B; Thu, 8 Apr 2021 14:20:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRgUxMkfFOvPmSe6uIouYYlNnwmdqlLnGcte26+goHquHBw35GCcaN/pFxyU2DHvGxtjS+To0clkCUPuhOsWQWXfIjQU0LTUUrbu+pCd83A4GEJgImkz5NStotP7HwQiRHT5cyKkrUKvdQ6X/yjKFmCLql26iwHaixYpyWkhJ+I3Y6zrKEHtDiTfC0FcTf5Oh2+8bX/RAFWSyg0gMn2DE/8wNWqSpvcVZZCrG1nNoSY4Q85PFuG8y+INnGzl0xq95gD9Fqfc7zp/on2Rm8DU9YWl5Gm13YDXl2PAlmE5nk1yJtjo7LqCcJoORJ6Bj0lhoE97qDyoWBhCcVZVOa8EyA== 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=b6TXDxTcnRnbo3HXfn/D6B/SW5v+DPdDDbxds0BGsnM=; b=YKRODoza6kB3wsvhv5N64iyIRO3aP0m9ANOn9lS0K1uMS7ktEagSLgB6HpFH+qcEkEag5xDGbMrTT1Ro1GelXcacVQ1txEilj29MYG9HfwpSiYGBldC0wrSPPv0ESFF3T9d64JDAfxYSa06siLxi/SbhI0O4Wtw10zRmeyz2z7OhSDUrX3KXbtXVqu4NIyrdpYj2fJ18N4t1zNIfiU3avnCQPww+zjBg/zbjz7QcKXg0NMN6UHrwjwsPztvZaA2lcfuM0MJ666nQPxO5nHOSehA3SRCXVjF0UXycLL37pZsy3sCtlMW4VGc3purMuGW/e7hdx7RxBVK9NcubdIUY6w== 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=b6TXDxTcnRnbo3HXfn/D6B/SW5v+DPdDDbxds0BGsnM=; b=SvmfCXFMYDDBPQ1L/4VDx4VJH6htX/zMltWwxRfeL1JmgdruxeH3beueE5vRRvgCjBfpyitiQ+T+N7Y+muzXJ3Zk6ayXh+7fKRCJHL8gliM8grzXo3Zw54wKLFhppdyFYDvEzLGxGMaZsbQcFMVPg/1wVLKGcbLPHCPM9E/DV/c= Received: from DM5PR00MB0421.namprd00.prod.outlook.com (2603:10b6:4:a0::33) by DM6PR00MB0556.namprd00.prod.outlook.com (2603:10b6:5:165::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4061.0; Thu, 8 Apr 2021 21:20:26 +0000 Received: from DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5]) by DM5PR00MB0421.namprd00.prod.outlook.com ([fe80::e553:4e87:8c7e:63d5%7]) with mapi id 15.20.4056.000; Thu, 8 Apr 2021 21:20:25 +0000 From: Mike Jones To: "francesca.palombini@ericsson.com" , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMekdJv5IcULvQ1qzavuY873M4wAOwfAAAAQud6AADjkDsA== Date: Thu, 8 Apr 2021 21:20:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:41:17Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cdfb0104-3004-44ad-80cf-5c9eac18df57; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2607:fb90:b2d9:b46f:98fa:8445:2e2a:29e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebe4df76-1b2d-40d5-85bb-08d8fad4209b x-ms-traffictypediagnostic: DM6PR00MB0556: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s8pYqy97Bam5rOh4lVbbVJMAr6HHtAazGstlcshp83tQ4lA+1g9xe4YN78HpgAXWvgjju/bLUu2xTBgHhZdzXtum2hFKJ4oh5lnjiSTANEuSkhUKjvA9O8He5J1aanXKaMn/xytJrDc+ATAReww3xbogrf8KnCwbdaONDUMpmKtoAKPlI92PtLLVOUX3yhEA09y1aB4aH7n1f6DQr0+vp+fUT9a07BMsq5l9oswRu176pjzo5x0ED04DANCVejcVVjSwT4hlgHGZg3EB93A0KD8irfTIHKyKJyt7PzKRjfDLBkDANQ9ME+MwCLDO5cPYLtEHgDgyY00RWWBVU4fswMQhqkXSvMWzq4vd9JsqBeadB2nQTH+5FNcjMgs3qV4trVOp53SV0q34x7n1zAhoRQ1CUySzI+ozAKYR7gIrJ5+W8cE3bltrG/QAemyrMzdFD094RlL/O1kJvZSiQoEDNl6vaYR8jnjkqaw9+GqYYEZmgN8TLbppxJlKk6Zn1lW730OWncFlDYF8fjitcCUe1/s5GF27l1/dPf071kVY2LujxWjLyAa4rkI9DHblkeuRWoAztadv9QDHhywGKGAjVziu7L47osnK9NBPTxNMEprTW0o66FaV8wdKFLac2/6vVk9FSIiZOLXv5RD5PTbvPcV1GZ/q9xZHDYu9MxAKlLttNa/Wr82zp4a91nPJHU9GG1RzV0oIJIxz7FCrjgJbYD7GODmN+jZ/Y+LqYjGOg5s= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0421.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(66446008)(966005)(9686003)(316002)(66556008)(82960400001)(82950400001)(54906003)(66946007)(86362001)(2940100002)(478600001)(7696005)(66476007)(8936002)(8676002)(8990500004)(6506007)(64756008)(55016002)(53546011)(2906002)(38100700001)(186003)(10290500003)(83380400001)(71200400001)(5660300002)(110136005)(4326008)(52536014)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?KzUwdDBtQXc4eGpTeHU3Q2dEZ2o3bUlRM0dneWZZUlNNVXdXYUtwdGlzd2Fj?= =?utf-8?B?c0hsNW95eFVXU0JOWTJYQmsxbjNHVDlSUUgydmtOdnJSVFAzdXI0OXhtK3lp?= =?utf-8?B?V2RycjZwL2tDMlpwdjh6ZUowdGVWRERsVnh0M2hnNHN3K1BqUlkwQi92akwv?= =?utf-8?B?c0FiRXhBNUxnZUNRcUsxSWNTNk8wRXVHcDl6Tk5rZEp0MWRLU3Z1NXo5bjVR?= =?utf-8?B?K1c0Y2tZNDQxMHpmVWRhWEprYnplTFkzK0J6L2s0S0I1eVV1SHJlcWlmQ1JM?= =?utf-8?B?SnlMOFkrbk5jRWF2L3d6cXVnL0w2QnJJc002TFpJb1pPTkZhb1FnTjk3cml1?= =?utf-8?B?UTM0cUFScVRiNzllOVlWWUprcUhVMjhZMTFxMHBvakdiaTJTRU1CUXdBWXlW?= =?utf-8?B?dEdaaEFGWmFYak10bzdpY0JhbVdBS0lGVlkxbFpsZEU0YWlFRENjamZ3N3Bh?= =?utf-8?B?cS82WXMvaEdOVUczRWFnQ3ZUR1VscFV6aEYyWks3Vkg5TXl2QWFLUUpnUmFO?= =?utf-8?B?Q3R2L0hsTnNUZUtsUXhUYktyTGtZVlhZMFMzZVBiVll4ZUFhL3pOTEpGcTVj?= =?utf-8?B?UjZKM3BxMG1RZlNVV2lBQzNWR29RWVlJRjB1YUhydGtnMHhLbk9uelRMQnFY?= =?utf-8?B?Z2NaUHhFby9CWktCNGNaVUo3V0l2WDNZWENNZVQybWNmODRzQ0RXVTJVbXZi?= =?utf-8?B?cWVzL1pOZDZmcUlBelZKZlVnQk9yR2JSTlVMVFp2TTJYczRBcWNnS0ViNG15?= =?utf-8?B?bGYrU1dMRUpwL0ltL3BldlAzb0dSQ1F2UHJxck9admJXUGQ5RUo5MjRybVBa?= =?utf-8?B?M1JtQWJ0SjJFcmZJVGJzK1hYYXNHeUY5NHNvWFMxeDUrd3BncU82MXdWYVJK?= =?utf-8?B?aEo2anJVMk5UYU5kd25WOWo3KzJMWExiY2JjUjRVazZSWDl3eGgzelJuYnNh?= =?utf-8?B?eFRXNFlhQ2FDbEwxcFZkUFRUaU5XMlZ3eEExZnAxTUxIV3R1QlRoRUkrNmZW?= =?utf-8?B?bHRXVkQ5dkd6ZGl1dFlrMFgzQ0NmcWpFSzRtK0FDdXNQU0NzUTVXUndzeUdz?= =?utf-8?B?VXprYTAveFFUdzJYQVUvWGhaTlNVQk83cUJ4OTdQak4yMi9KR0oxMUlLVmx3?= =?utf-8?B?cjJoSzRJTjlSaFJ3cThKZ096cUw2Vi9jWnd6ZFpYLzlKdDgwci9pbXdMMkRu?= =?utf-8?B?RWpJMzN5VXlJN0hMUnRKRlo3UlNuem12b2dUSTA2T0lYUThwUHNjVy9sSURx?= =?utf-8?B?TEdVK01yS21oYU9HZVpYaktLbFJSbmJpdWFKTE5wWXdIVHBkZ2dwYVlFL2lz?= =?utf-8?B?QW94YkgrK0ZpZFpvNzBTc1pqRWpqcGQ0UGk2bVZ3L0tqcSt1MW43VCt2aWND?= =?utf-8?B?WnNWSXFtZVVhekg2OElkU3UrU01LV1lGOWN1RHNBTktyRTZHelpyZ01Xd2xo?= =?utf-8?B?RjNjVU9ZT1FMb1l1bmN6a0UxT3pjR2RKNGpiazZrbktOc3l2ODQ3YTY0NjN2?= =?utf-8?B?dzJ5YStSMys0NnFhV1BpSlRMRHdmQlg3aURsdGNUcC9kWFRFbngyYmZ4Y2dy?= =?utf-8?B?NEMrYnBFQ01TYS9ybjE3aGpISVB1NXlSc2JsU3pqdUx5ckdnaE9mcHF1MlRY?= =?utf-8?B?QmFvNGs5TGIxUFVCT1Q4dXgwRmFUcmdUdi9jOURJWFBOZlFaVXozZzBmU1ll?= =?utf-8?B?VkhyczRHTWFCWk83V2N2YkpCd1dReVpMLzViSUZhNVpIeUlLSW9JbHMwRTJN?= =?utf-8?B?MktHY29PYjJNSlFlSUVzaFZIZFkyQXpxLzJIYzVDWlA4YThsQkt1RVhuWTl4?= =?utf-8?B?eW1LRFI4MXpoN1dscUhQU0gxdWh5ZGNOVG5ROHV6ZWNlV1VySWZjNWZvdGk3?= =?utf-8?Q?MJtYEPYRd/uEx?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0421.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebe4df76-1b2d-40d5-85bb-08d8fad4209b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 21:20:25.9609 (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: SqqOPTKdPbILjGOKjJYEfu3bpoAaGY6le3c10OvMIkytoF/In6V7yAjT5CQsWudR0vEd9wcWceoWrUy2oEviwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0556 Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 21:20:47 -0000 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTM0IGlu Y29ycG9yYXRlcyB0aGUgZml4ZXMgeW91IHN1Z2dlc3RlZC4NCg0KCQkJCVRoYW5rcyBhZ2FpbiwN CgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWtlIEpv bmVzIA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDgsIDIwMjEgNjo0OSBBTQ0KVG86IEZyYW5jZXNj YSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPjsgaWVzZ0BpZXRm Lm9yZw0KQ2M6IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxQGlldGYub3JnOyBvYXV0aC1jaGFpcnNA aWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnOyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0DQpTdWJq ZWN0OiBSRTogRnJhbmNlc2NhIFBhbG9tYmluaSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LW9hdXRoLWp3c3JlcS0zMjogKHdpdGggQ09NTUVOVCkNCg0KVGhhbmtzIGZvciBzd2VhdGluZyB0 aGUgZGV0YWlscywgRnJhbmNlc2NhLiAgSSdsbCBwbGFuIHRvIHB1Ymxpc2ggYW4gdXBkYXRlZCBk cmFmdCBhZnRlciB0aGUgdGVsZWNoYXQgbWFraW5nIHRoZSBlcnJvciBoYW5kbGluZyBmb3IgdGhl IGNhc2Ugd2hlbiB0aGUga2V5IGlzbid0IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50IGNsZWFy ZXIuDQoNCgkJCQlUaGFua3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmlu aUBlcmljc3Nvbi5jb20+IA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDgsIDIwMjEgMjo0NyBBTQ0K VG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IGllc2dAaWV0Zi5v cmcNCkNjOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcUBpZXRmLm9yZzsgb2F1dGgtY2hhaXJzQGll dGYub3JnOyBvYXV0aEBpZXRmLm9yZzsgSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldA0KU3ViamVj dDogUmU6IEZyYW5jZXNjYSBQYWxvbWJpbmkncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1v YXV0aC1qd3NyZXEtMzI6ICh3aXRoIENPTU1FTlQpDQoNCkhpIE1pa2UhDQoNClRoYW5rcyBmb3Ig dGhlIHF1aWNrIHJlcGx5LiBJdCBsb29rcyBnb29kIHRvIG1lLCBqdXN0IG9uZSBhbnN3ZXIgdG8g cG9pbnQgNC4gOg0KDQogICAgNC4gLS0tLS0NCg0KICAgICAgIHNwZWNpZmllZCBpbiB0aGUgImFs ZyIgSGVhZGVyIFBhcmFtZXRlci4gIElmIGEgImtpZCIgSGVhZGVyIFBhcmFtZXRlcg0KICAgICAg IGlzIHByZXNlbnQsIHRoZSBrZXkgaWRlbnRpZmllZCBNVVNUIGJlIHRoZSBrZXkgdXNlZCwgYW5k IE1VU1QgYmUgYQ0KICAgICAgIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudC4gIEFsZ29y aXRobSB2ZXJpZmljYXRpb24gTVVTVCBiZQ0KDQogICAgLi4uDQoNCiAgICAgICBzYW1lIHBhcmFt ZXRlciBpcyBwcm92aWRlZCBpbiB0aGUgcXVlcnkgcGFyYW1ldGVyLiAgVGhlIENsaWVudCBJRA0K ICAgICAgIHZhbHVlcyBpbiB0aGUgImNsaWVudF9pZCIgcmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGlu IHRoZSBSZXF1ZXN0IE9iamVjdA0KICAgICAgICJjbGllbnRfaWQiIGNsYWltIE1VU1QgYmUgaWRl bnRpY2FsLiAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRoZW4NCg0KICAgIEZQOiAiTVVTVCBi ZSBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudCIgLSB3aGF0IGlmIGl0IGlzIG5vdD8g ZG9lcyB0aGUgQVMgcmV0dXJuIGFuIGVycm9yIHRvIHRoZSBjbGllbnQgdGhlbj8gU2FtZSBjb21t ZW50ICIuLi4gTVVTVCBiZSBpZGVudGljYWwiIC0gaXMgYW55IGVycm9yIHJldHVybmVkIGlmIGl0 J3Mgbm90Pw0KDQogICAgTWlrZT4gSSBiZWxpZXZlIHRoYXQgdGhlIHJlc3BvbnNlcyB0byB0aGVz ZSB2YWxpZGF0aW9uIGVycm9ycyBhcmUgYWxyZWFkeSBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2lu ZyBwYXJhZ3JhcGgsIHdoaWNoIHNheXMgIklmIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGZhaWxzLCB0 aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4gJ2ludmFsaWRfcmVxdWVzdF9v YmplY3QnIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlIGF1dGhvcml6YXRp b24gcmVxdWVzdC4iDQoNCkZQOiBBcyBJIHJlYWQgaXQsIHRoZSBmaXJzdCBwYXJhZ3JhcGggc2F5 czogDQoNCiAgIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBzaWdu YXR1cmUgb2YgdGhlIEpTT04gV2ViDQogICBTaWduYXR1cmUgW1JGQzc1MTVdIHNpZ25lZCBSZXF1 ZXN0IE9iamVjdC4gIElmIGEgImtpZCIgSGVhZGVyDQoNClRoZW4gZm9sbG93cyB1cCB3aXRoIGEg bnVtYmVyIG9mIG90aGVyIGNoZWNrcyB0aGF0IG5lZWQgdG8gYmUgZG9uZSAodGhlIHRleHQgSSBx dW90ZWQgaW4gbXkgb3JpZ2luYWwgY29tbWVudCkuIEFuZCB0aGVuIGVuZHMgd2l0aCB0aGUgc2Vu dGVuY2UgeW91IHF1b3RlZDoNCg0KICAgSWYgc2lnbmF0dXJlIHZhbGlkYXRpb24gZmFpbHMsIHRo ZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVybg0KICAgYW4gImludmFsaWRfcmVxdWVz dF9vYmplY3QiIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlDQogICBhdXRo b3JpemF0aW9uIHJlcXVlc3QuDQoNClNhbWUgZm9yIHRoZSBzZWNvbmQgLSB0aGUgdGV4dCBJIHJl cG9ydGVkIGlzIGZvbGxvd2VkIGJ5Og0KDQogIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0aGVu DQogICB2YWxpZGF0ZXMgdGhlIHJlcXVlc3QgYXMgc3BlY2lmaWVkIGluIE9BdXRoIDIuMCBbUkZD Njc0OV0uDQoNCkFuZCB0aGVuIGFnYWluIGZyb20gdGhlIHRleHQgeW91IHF1b3RlZDoNCg0KICAg SWYgdGhlIHZhbGlkYXRpb24gZmFpbHMsIHRoZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1V U1QgcmV0dXJuIGFuDQogICBlcnJvciB0byB0aGUgY2xpZW50IGluIHJlc3BvbnNlIHRvIHRoZSBh dXRob3JpemF0aW9uIHJlcXVlc3QsIGFzDQogICBzcGVjaWZpZWQgaW4gU2VjdGlvbiA1LjIgb2Yg T0F1dGggMi4wIFtSRkM2NzQ5XS4NCg0KU28gd2hpbGUgcmVhZGluZyBJIGNvbnNpZGVyZWQgdGhh dCB0aGUgdmFsaWRhdGlvbiAoZWl0aGVyIG9mIHRoZSBzaWduYXR1cmUgZm9yIHBhciAxIG9yIG9m IHRoZSByZXF1ZXN0IGZvciBwYXIgMikgaXMgc2VwYXJhdGUgZnJvbSB0aGUgYWRkaXRpb25hbCBj aGVja3MuIFRoZSBpbnRlbnQgb2YgaXQgY291bGQgYmUgbWFkZSBjbGVhciBieSBhIG1pbm9yIGFk ZGl0aW9uIGluIGVhY2ggcGFyOg0KDQoxc3QgcGFyYWdyYXBoOg0KDQpPTEQ6DQoNCiAgIElmIHNp Z25hdHVyZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCBy ZXR1cm4NCiAgIGFuICJpbnZhbGlkX3JlcXVlc3Rfb2JqZWN0IiBlcnJvciB0byB0aGUgY2xpZW50 IGluIHJlc3BvbnNlIHRvIHRoZQ0KICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KDQpORVc6DQoN CiAgIElmIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGZpYWxzLCBvciBpZiB0aGUga2V5IGlkZW50aWZp ZWQgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50LCB0aGUgQXV0aG9yaXphdGlvbiBT ZXJ2ZXIgTVVTVCByZXR1cm4NCiAgIGFuICJpbnZhbGlkX3JlcXVlc3Rfb2JqZWN0IiBlcnJvciB0 byB0aGUgY2xpZW50IGluIHJlc3BvbnNlIHRvIHRoZQ0KICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0 Lg0KDQoybmQgcGFyYWdyYXBoOg0KDQpPTEQ6DQoNCiAgIElmIHRoZSB2YWxpZGF0aW9uIGZhaWxz LCB0aGVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVybiBhbg0KICAgZXJyb3Ig dG8gdGhlIGNsaWVudCBpbiByZXNwb25zZSB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBh cw0KICAgc3BlY2lmaWVkIGluIFNlY3Rpb24gNS4yIG9mIE9BdXRoIDIuMCBbUkZDNjc0OV0uDQoN Ck5FVzoNCg0KICAgSWYgdGhlIHZhbGlkYXRpb24gb2YgdGhlIHJlcXVlc3Qgb3IgdGhlIENsaWVu dCBJRCBjaGVjayBmYWlscywgdGhlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1 cm4gYW4NCiAgIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlIGF1dGhvcml6 YXRpb24gcmVxdWVzdCwgYXMNCiAgIHNwZWNpZmllZCBpbiBTZWN0aW9uIDUuMiBvZiBPQXV0aCAy LjAgW1JGQzY3NDldLg0KDQoNCkkgdGhpbmsgdGhpcyB3b3VsZCBjbGFyaWZ5IHRoZSB0ZXh0LCBi dXQgSSdsbCBsZWF2ZSBpdCB1cCB0byB5b3UgdG8gZGVjaWRlIGlmIGl0J3Mgd29ydGggYWRkaW5n Lg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDA4LzA0LzIwMjEsIDA2OjQ1LCAiTWlrZSBK b25lcyIgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCiAgICBUaGFua3Mg Zm9yIHlvdXIgcmV2aWV3LCBGcmFuY2VzY2EuICBXZSd2ZSBwdWJsaXNoZWQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMzIHRvIGFkZHJlc3MgeW91 ciBhbmQgb3RoZXIgSUVTRyBjb21tZW50cy4NCg0KICAgIFJlc3BvbnNlcyBhcmUgaW5saW5lIGJl bG93LCBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICBGcm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBs eUBpZXRmLm9yZz4gDQogICAgU2VudDogV2VkbmVzZGF5LCBBcHJpbCA3LCAyMDIxIDM6MjkgQU0N CiAgICBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQogICAgQ2M6IGRyYWZ0LWlldGYtb2F1 dGgtandzcmVxQGlldGYub3JnOyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3Jn OyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0DQogICAgU3ViamVjdDogRnJhbmNlc2NhIFBhbG9t YmluaSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMjogKHdpdGgg Q09NTUVOVCkNCg0KICAgIEZyYW5jZXNjYSBQYWxvbWJpbmkgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzI6 IE5vIE9iamVjdGlvbg0KDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAg Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCg0KDQogICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLw0KDQoNCg0KICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIFRoYW5rIHlvdSBmb3IgdGhl IHdvcmsgb24gdGhpcyBkb2N1bWVudC4gSSBvbmx5IGhhdmUgbWlub3IgY29tbWVudHMsIHRoZSBt b3N0IGludGVyZXN0aW5nIGlzIHByb2JhYmx5IDQuIGFib3V0IGlmIGFkZGl0aW9uYWwgZmFpbHVy ZSBiZWhhdmlvciBzaG91bGQgYmUgZGVmaW5lZCBhdCB0aGUgQVMuDQoNCiAgICBGcmFuY2VzY2EN Cg0KICAgIDEuIC0tLS0tDQoNCiAgICAgICBBIFJlcXVlc3QgT2JqZWN0IChTZWN0aW9uIDIuMSkg aGFzIHRoZSAibWltZS10eXBlIiAiYXBwbGljYXRpb24vDQoNCiAgICBGUDogUGxlYXNlIHVzZSAi bWVkaWEgdHlwZSIgaW5zdGVhZCBvZiAibWltZS10eXBlIiBhbmQgcmVmZXJlbmNlDQogICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4MzgNCg0KICAgIE1pa2U+IFRoYW5rcywgdXBk YXRlZCwgYWx0aG91Z2ggcmVmZXJlbmNpbmcgUkZDIDIwNDYgZm9yIHRoZSB0ZXJtICJtZWRpYSB0 eXBlIiAod2hpY2ggaXMgbm90IHN1cGVyc2VkZWQgYnkgUkZDIDY4MzgpLg0KDQogICAgMi4gLS0t LS0NCg0KICAgICAgIFRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBsZSBvZiB0aGUgQ2xhaW1zIGlu IGEgUmVxdWVzdCBPYmplY3QgYmVmb3JlDQogICAgICAgYmFzZTY0dXJsIGVuY29kaW5nIGFuZCBz aWduaW5nLiAgTm90ZSB0aGF0IGl0IGluY2x1ZGVzIHRoZSBleHRlbnNpb24NCg0KICAgIEZQOiBU aGlzIGV4YW1wbGUgaXMgdGhlIGZpcnN0IHRpbWUgImJhc2U2NHVybCIgYXBwZWFycyBpbiB0aGUg ZG9jdW1lbnQuIEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB0byBtZW50aW9uIHRoYXQgYmFz ZTY0dXJsIGlzIHVzZWQgd2hlbiBKV1QgaXMgaW50cm9kdWNlZCwgZm9yIGV4YW1wbGUgaW4gdGhl IGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQuDQoNCiAgICBNaWtlPiBSZWZlcmVuY2UgYWRk ZWQuDQoNCiAgICAzLiAtLS0tLQ0KDQogICAgICAgSWYgZGVjcnlwdGlvbiBmYWlscywgdGhlIEF1 dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuIGFuDQogICAgICAgImludmFsaWRfcmVxdWVz dF9vYmplY3QiIGVycm9yLg0KDQogICAgLi4uDQoNCiAgICAgICBJZiBzaWduYXR1cmUgdmFsaWRh dGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuDQogICAgICAg YW4gImludmFsaWRfcmVxdWVzdF9vYmplY3QiIGVycm9yLg0KDQogICAgLi4uDQoNCiAgICAgICBJ ZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVT VCByZXR1cm4gYW4NCiAgICAgICBlcnJvciBhcyBzcGVjaWZpZWQgaW4gT0F1dGggMi4wIFtSRkM2 NzQ5XS4NCg0KICAgIEZQOiB2ZXJ5IG1pbm9yLCBidXQgSSBzdWdnZXN0cyB5b3UgYWRkICJ0byB0 aGUgY2xpZW50LCBpbiByZXNwb25zZSB0byB0aGUgcmVxdWVzdCBkZWZpbmVkIGluIDUuMi4yLiBv ZiB0aGlzIHNwZWNpZmljYXRpb24iLiBUaGUgcmVhc29uIGlzIHRoYXQgdGhlIGRvYyBzcGVjaWZp ZXMgdGhhdCB0aGUgQVMgbWlnaHQgYmUgaGF2aW5nIG90aGVyIGV4Y2hhbmdlcyAodG8gZmV0Y2gg dGhlIFJlcXVlc3QNCiAgICBPYmplY3QpIGF0IHRoZSBzYW1lIHRpbWUsIGFuZCBpdCBjYW4ndCBo dXJ0IHRvIGJlIHByZWNpc2UuIEFsc28gcmVnYXJkaW5nIHRoZSByZWZlcmVuY2UgdG8gUkZDIDY3 NDkgLSBjYW4geW91IGFkZCBhIHNwZWNpZmljIHNlY3Rpb24gdG8gcmVmZXJlbmNlPw0KDQogICAg TWlrZT4gRG9uZQ0KDQogICAgNC4gLS0tLS0NCg0KICAgICAgIHNwZWNpZmllZCBpbiB0aGUgImFs ZyIgSGVhZGVyIFBhcmFtZXRlci4gIElmIGEgImtpZCIgSGVhZGVyIFBhcmFtZXRlcg0KICAgICAg IGlzIHByZXNlbnQsIHRoZSBrZXkgaWRlbnRpZmllZCBNVVNUIGJlIHRoZSBrZXkgdXNlZCwgYW5k IE1VU1QgYmUgYQ0KICAgICAgIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudC4gIEFsZ29y aXRobSB2ZXJpZmljYXRpb24gTVVTVCBiZQ0KDQogICAgLi4uDQoNCiAgICAgICBzYW1lIHBhcmFt ZXRlciBpcyBwcm92aWRlZCBpbiB0aGUgcXVlcnkgcGFyYW1ldGVyLiAgVGhlIENsaWVudCBJRA0K ICAgICAgIHZhbHVlcyBpbiB0aGUgImNsaWVudF9pZCIgcmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGlu IHRoZSBSZXF1ZXN0IE9iamVjdA0KICAgICAgICJjbGllbnRfaWQiIGNsYWltIE1VU1QgYmUgaWRl bnRpY2FsLiAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRoZW4NCg0KICAgIEZQOiAiTVVTVCBi ZSBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudCIgLSB3aGF0IGlmIGl0IGlzIG5vdD8g ZG9lcyB0aGUgQVMgcmV0dXJuIGFuIGVycm9yIHRvIHRoZSBjbGllbnQgdGhlbj8gU2FtZSBjb21t ZW50ICIuLi4gTVVTVCBiZSBpZGVudGljYWwiIC0gaXMgYW55IGVycm9yIHJldHVybmVkIGlmIGl0 J3Mgbm90Pw0KDQogICAgTWlrZT4gSSBiZWxpZXZlIHRoYXQgdGhlIHJlc3BvbnNlcyB0byB0aGVz ZSB2YWxpZGF0aW9uIGVycm9ycyBhcmUgYWxyZWFkeSBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2lu ZyBwYXJhZ3JhcGgsIHdoaWNoIHNheXMgIklmIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGZhaWxzLCB0 aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4gJ2ludmFsaWRfcmVxdWVzdF9v YmplY3QnIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlIGF1dGhvcml6YXRp b24gcmVxdWVzdC4iDQoNCiAgICA1LiAtLS0tLQ0KDQogICAgICAgbG9jYXRpb24sIChiKSBjaGVj ayB0aGUgY29udGVudCB0eXBlIG9mIHRoZSByZXNwb25zZSBpcyAiYXBwbGljYXRpb24vDQoNCiAg ICBGUDogRm9yIGNvbnNpc3RlbmN5LCBwbGVhc2UgY2hhbmdlICJjb250ZW50IHR5cGUiIHRvICJt ZWRpYSB0eXBlIi4NCg0KICAgIE1pa2U+IERvbmUNCg0KICAgIAkJCQlUaGFua3MgYWdhaW4sDQog ICAgCQkJCS0tIE1pa2UNCg0KDQoNCg== From nobody Thu Apr 8 16:15:17 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0B93A2104; Thu, 8 Apr 2021 16:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLcgw3QG4Axb; Thu, 8 Apr 2021 16:15:08 -0700 (PDT) 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 22D3C3A2103; Thu, 8 Apr 2021 16:15:07 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 138NF0Ir027088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Apr 2021 19:15:05 -0400 Date: Thu, 8 Apr 2021 16:15:00 -0700 From: Benjamin Kaduk To: Mike Jones Cc: "iesg@ietf.org" , "oauth@ietf.org" , "oauth-chairs@ietf.org" , "draft-ietf-oauth-jwsreq@ietf.org" Message-ID: <20210408231500.GC79563@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with 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: Thu, 08 Apr 2021 23:15:13 -0000 Hi Mike, Also inline... On Thu, Apr 08, 2021 at 04:45:15AM +0000, Mike Jones wrote: > Thanks for your review, Ben. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments. > > Responses are inline below, prefixed by "Mike>". > > -----Original Message----- > From: OAuth On Behalf Of Benjamin Kaduk via Datatracker > Sent: Tuesday, April 6, 2021 11:39 AM > To: The IESG > Cc: oauth@ietf.org; oauth-chairs@ietf.org; draft-ietf-oauth-jwsreq@ietf.org > Subject: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwsreq-32: No Objection > > 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-jwsreq/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the new security considerations text in Sections 10.7 and > 10.8 since I last reviewed; it does a great job capturing my comments (and the current deployed reality). > > Thanks also to Watson Ladd for the latest secdir review and the authors for their responses to it. > > Mike> Glad to hear it! > > Section 6.2 > > The Authorization Server MUST validate the signature of the JSON Web > Signature [RFC7515] signed Request Object. The signature MUST be > validated using a key associated with the client and the algorithm > specified in the "alg" Header Parameter. [...] > > The last version I reviewed had some language tying the algorithm used for verification back to a registration (and I commented that perhaps a registration might not always exist). This language seems to set the recipient up to blindly use the "alg" header parameter, even if it's "none", and we should probably have some hedging language here (I see we do have language elsewhere that bans "none" specifically)... > > If a "kid" Header Parameter > is present, the key identified MUST be the key used, and MUST be a > key associated with the client. Algorithm verification MUST be > performed, as specified in Sections 3.1 and 3.2 of [RFC8725]. > > ... and maybe that would just take the form of swapping the order of these two sentences, now that I keep reading. > > Mike> Order swapped, per your suggestion. > > Section 10.2 > > Do any of the procedures listed for steps (c) and/or (d) need to be performed in step (e) as well? (In particular, the requirements on the returned URI seem like they would still apply, and possibly the need for client authentication. > > Mike> Having re-read (c), (d), and (e), I don't think so. The returned URI in (e) can be an opaque identifier that is not a URL, so the URL checking logic wouldn't apply. Okay. Thanks for taking a second look. > Section 10.3 > > Nat's response at > https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my previous review suggested that there might be value in future work that specifies the linkage across these endpoints to try to address the cross-phase attacks discussed in [FETT]. However, the paragraph that I had commented on (that mentions "an extension specification") has since been removed, and I failed to track down why just from a quick mailarchive search. There may well have been a good reason for removing it (and the reference to [FETT]), so please help refresh my memory if that's the case. > > Mike> It was removed as suggested by Watson Ladd in the discussion that resulted from his SecDir review. Ah! Thanks for refreshing my memory. > Section 10.4 > > The introduction of "request_uri" introduces several attack > possibilities. Consult the security considerations in Section 7 of > RFC3986 [RFC3986] for more information regarding risks associated > with URIs. > > My previous comments had mentioned that because of time skew the dereferenced request URI might actually have the contents of a different request than the one intended, and Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ > pointed out that OIDC actually does use a nonce that would prevent such an occurrence. Hopefully Nat did get a chance to think about whether there was anything else that we should mention in this document, on this topic. ("There isn't anything else to mention here" is a fine answer; I just wanted to close the loop on that thread, since I didn't find one in the mail archive.) > > Mike> OpenID Connect requests using some response_type values include a nonce and those using others don't. Thinking about it some more, I don't think there's any particular risks about using these URLs that are sufficiently different than those of other URLs that they're worth mentioning here. Okay, as before, thanks for thinking through it again. -Ben > Section 11.1 > > nit: s/TFP/trusted third-party service/ (multiple instances), since we stopped using "Trust Framework Provider" in the main body. > > Mike> Thanks for the catch - corrected! > > Sction 14.1 > > Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 -- thank you for referencing it as BCP 195! I expect the RFC Editor will catch the new reference if you don't want to figure out how to notate it properly. > > Mike> Thanks for the heads-up. I'll plan to ask the RFC Editor what the right way to do this is. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > Thanks again! > -- Mike > From nobody Thu Apr 8 20:38:41 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B73A29B7 for ; Thu, 8 Apr 2021 20:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 YYGwUrrwrSxo for ; Thu, 8 Apr 2021 20:38:37 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650134.outbound.protection.outlook.com [40.107.65.134]) (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 2B3B63A29B5 for ; Thu, 8 Apr 2021 20:38:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LXiRk6QgGB1OhP8pD7QJAvqYKLLcOMG6ww9LLvFMQgcefrtUccIWkzTAnMHMe9bKJVwn4w58Wu82nPru5sADvjlQvznK5pSsEB6fQsLSFNjbhbJpF+DmZwBZwsZ2NBuwE2yh6sp7coMItsgYAE0XVdlzVdeoE+O5+SKvsw6gqnKql44VR6FmgR46ZuKElYMp/LBLjDc47hMo7dFR0KeU3kcwJZJbFJnx1X1xQIEIJYoJTVZR+v+JwrcvRRJKkzKAop5B1PqT+58pHNLugham6AVKXkwJXdG9xM0ne+/RfU8rl5fz3Itej+oI8MQJ3btT+5giRfLf9su/JzpocpMykw== 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=Ul8jZAAUiArhMyjmSUm/FBTzEMjwS9sgrWnUKJVh6R0=; b=bSgY2/OtDwQ72awryq9VFZjz5OnKYEkl+lWF7j1mmIofhnLf/wTxDE6SJLET3OS2qxuTZXOnnPXX8qjy0MPP/LGGJlDRvEd5tFGOxqD7tNw9CcAOC+yv7DoQoVqzDCU1UdxOoJTr0cuc7k8yfux3PpjCnRhkDEYnfThOcz3DriULsEF2wLg3gY5z2+5XkEhI86aK3/kGXqQrK1qF3umD75TsHxGOgc3bL/IwYEEcyx7YchpknYhQPJqV3BMwzRDbvc55Ui5I6vlpAU7Hv0rTKko12ObPwXjocVbyfLxZ/M5ZiId38DTv+wcbl+DNHRJ8MVq8ukmMnAD/JslzGN8+BQ== 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=Ul8jZAAUiArhMyjmSUm/FBTzEMjwS9sgrWnUKJVh6R0=; b=McrLpYR7hPDy2HGuYOumVUlwcc3AFSF+99d2qXHpy0kxn3zXQr409RA2egAopbPxBLJCXUSEPpVPNcB+j6UCojcgLA1sFQ7noo4fvDoHU9D2wnpKV1EBXwdHdTrgW6eKohhRyem545Ix0qJJpdW6G6rVNWQq7K5dZV35ItDUftI= Received: from MW2PR00MB0426.namprd00.prod.outlook.com (2603:10b6:302:b::14) by MW2PR00MB0345.namprd00.prod.outlook.com (2603:10b6:302:9::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4061.0; Fri, 9 Apr 2021 03:38:29 +0000 Received: from MW2PR00MB0426.namprd00.prod.outlook.com ([fe80::25cb:2dab:599c:9df2]) by MW2PR00MB0426.namprd00.prod.outlook.com ([fe80::25cb:2dab:599c:9df2%9]) with mapi id 15.20.4067.000; Fri, 9 Apr 2021 03:38:28 +0000 From: Mike Jones To: "bcampbell=40pingidentity.com@dmarc.ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt Thread-Index: Adcs8coOG7uzwq9pTwiwUOpovV+Fug== Date: Fri, 9 Apr 2021 03:38:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-09T03:36:00Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f01a2e7c-c6ca-4386-9867-c98816467376; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2607:fb90:b2d9:b46f:e920:2135:f44b:10a6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 457678b9-3f65-4b98-90f4-08d8fb08f09b x-ms-traffictypediagnostic: MW2PR00MB0345: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uKBteMEy+vQUX+R3zrtyLNyKOXrWouAuicWuEEa+AhhvD8xHdLOf7dgbx8/jLhSM2GlRdMJkyJDC4gMu/j2J6TrsN6WdAlbeUlHRxNoBhXLLWdKr+tsnA+Ekv8XbjcHvR63zU7onT9X5peRiAf7JZhUCym//0bWA/NnkAw8/aACymX24MQhmy6QE0DL+lhTBM6LR3P/Me6C9OdH+XegzkXtQO5t8xYLVVKQfVs3pKleVCrKLrtz51UQC+ov3PzpBkMB3GJE9Bw66p41eaIXaubJTi8Ey5mL50CxxAoYR7Jt8pEFPLk6MrEY7FKOWIiqdQ/z6FEYq1xqN0WgMtbQWuLEC88e8D9vYUu7j6pcyRG62c0A8tQde2Vs1nIjwDwTOR16+NBfa0I/LVH3wjHOsSJHb53Ij8M5whLPXVqngZW6qjF1bAXMSYq13zFiwiLxZaDeq9KNVyeFpN9vl2FU63s+zPWdxrBOy/Y75TrrCUck88o28jb4zXGVLXHEG5k4canSjYwsRM3aDNPptB37SC3Ju1FdMATzvbttDfC9PXqQucs7EXFjEz+3tDxmqpfH05PAP6hRbyBNfpjNsG7PiP7n1X+duMNt8nUCA2Ysk3zCY5k4keizDtR2meZQBoMwL8EdRpxc8rnRr0p8dj2BECmRzowjYzbFlRrhxXez3k+lHrWVOkmESL8aeiCXP9c44LK6/u2dQOjkJksFakc0XDgygjYtLc5D4VIDsFDdFYTPA7iQDmYuahrmWerbH1uaauFMQF7OhWCiP0mhrW4s03Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR00MB0426.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(71200400001)(15650500001)(186003)(10290500003)(83380400001)(66574015)(9686003)(478600001)(38100700001)(33656002)(52536014)(5660300002)(82950400001)(166002)(110136005)(66476007)(66556008)(2906002)(316002)(82960400001)(66446008)(66946007)(76116006)(966005)(8676002)(8936002)(8990500004)(6506007)(55016002)(53546011)(64756008)(86362001)(7696005)(21615005)(61000200002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?Y2QzMTJTNjJTZXBLRGpZditOOVk3S2I4L2haZGNKd1A1MWpkWGl0UU9oa2w0?= =?utf-8?B?ajMvMDdvOU5pZmdFaW81OXYxTDJRV1FhQnlCQnRzbnRlNjd3S2oyQVZpYlJM?= =?utf-8?B?R2lDWGdKcHF4L21pcTlNTENPeW9veXJJRkkxQ0VtTnN3SEdaSkZHZG1OMjYw?= =?utf-8?B?U2FNMXRYakxURHhUSGpNK1h5OHdPY0ZRblVWdXNVTy8zQ1dMbHpvNEsrOGxl?= =?utf-8?B?bEoxdnJyRENmQVV4bGpLaWpQRkpCY3E0NURoVFlBTHkyTVMvdkpNK2ZKcUY3?= =?utf-8?B?bXBLZWJGUStnMWZwOU1FR09ZTXpaazNrTm4yZW5vWndCblh3eG5CRzdwbkdq?= =?utf-8?B?U1JZL0pWb01uWmc1ejd6WEx6Q0pUSXRwQmRjMERTaDN6VTNkTDZwaDRpVldu?= =?utf-8?B?RGJTck9XQnZFSHR5eDlqb2J0TE5SdERaeDMrWjJtWjBuWGc0TmdMbmhGMmZt?= =?utf-8?B?Vlp6Zk5INWQ2K2hHMkJ1dEhCRTV3SEliYy8rcmJtU0VWVnVFeVpjcmxBb3lx?= =?utf-8?B?SmVqZ3pxd0JBcGNuVlZNQ3Z6WE8xajhMRnFCUVRVMjg1QzM4bklQUzRnQ1dY?= =?utf-8?B?Y3lhSThnQnFMWjNjaGFsMmo3cTFNQWhiV0hFby9XNTJRbEtxcUtRWEFDeGFF?= =?utf-8?B?VUhnKzYydXJNMnpHcWlkMFNubmlvWlg3RDBzSVp6dUlBYmlLRjRvQkNSS1lV?= =?utf-8?B?UEVqNlROQS9aelpzbi9kYzVuRmtsK3VwTyswUEtkcDVQYXkrTVZNQkV3Smpv?= =?utf-8?B?elBxUCsrQmU4LzVHcDlrbkFueXduQWUva3QxWXc1Wkl1cVRNQkZ0QzEyRnJq?= =?utf-8?B?ZzNENm5CdjFoczl0SFNteFAyS2Z0aS8xTi9jZWZFM1I5V3ZvMTdBTmlQT1E1?= =?utf-8?B?UURoZUhySzBra1FpSkxPMkNqbUhsRmtlSUdiR0xKM3lsZWVma3UyemZ0eHlX?= =?utf-8?B?ZTA4OGhFZFRkMElXRW5XcFQrRitoNjB6a0RBQmlHSEpiK2Rpbm5OL1FTR3Ji?= =?utf-8?B?WlMwVHU1MGlOakMxYXFBdVE0NG1TdjRyc1JHUnBrUDI3bktybUxUdkVFQVNQ?= =?utf-8?B?WU1uOUtzbWtUejBRUzNVZ21kZjdZUDNEbFhPNWVzT3R4UjBkU2wzV3l6NmxF?= =?utf-8?B?OTNlZ0ZIcEZkVVlYVUYyMUxnd1Z6MzRmRkdMcnF5UkZRYWk1UXNYcGdLQ0xP?= =?utf-8?B?cTJHWjVRY0YxYm1pNWxnbURUVnJhb2NDYmdIdWp3RHZXQTJ0TmV1WXBJbEQ3?= =?utf-8?B?MmxsR0FxSGdhdW4rMFFUQml1ZGNzRjB5OGZ1YzhycDVDa25HSlJPMlJvalNY?= =?utf-8?B?NU14U1FGSG8rWDU2a0xpSEo0TGFOSkw5ZFV4ZS9pN2gyZ0FKUkg1amtLNllr?= =?utf-8?B?ak5mWks0UjlSZWlYTTNtb0lUQXhHNDNMWXpyRW9NMXFKTzJkK0I4Vy9yaUkx?= =?utf-8?B?d1ppVUpjczNTTlRGVk1kVFdRb2l6M3RqOGdWMlhuaXh5amtuMytudUY1TGIr?= =?utf-8?B?SVRzSHZ3UUNqcFV1OTNFRWpkQ1RUdTlHdnB5aFh5bkNSaVVzNmF2TTJXRUJ6?= =?utf-8?B?NVU1UjVqKzdBcEtyVWlES2h0SlZkT1dIV3lkdW1kRmxmQS80ek1waWJLK29R?= =?utf-8?B?N2grc2lhcHFUSlE4cUcyWW5LR2V4N2F0Zk92SG1UV25rR0VSS0VxenYvTTk1?= =?utf-8?B?c1BwWE9iSkRuUEViRDFhaitnSTJlRkdPYThnK2IrTGc0blR0NlpiSVZHYmor?= =?utf-8?B?S3BDc2xiY05LYWpMZVkrRFVZQ1pWT3BWWnhrN2dJdG1pSkpvNHNrb3k3WDRN?= =?utf-8?B?a1oyVjhwVHJaMUovOWFDblJnTnB0QmtpOWExWW5GMDIveWNPNE1rRGpkS2pv?= =?utf-8?Q?D+EbltQigj+ZL?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0426A27B97B4C96D29604C6CF5739MW2PR00MB0426namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR00MB0426.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 457678b9-3f65-4b98-90f4-08d8fb08f09b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 03:38:28.6483 (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: 54UVj+bM2lkXC2YUPRzRFqlWvE5lpZtXSHQzjGgFUtGPHs/qk2BKzZ77xJckKgTDy7MJoyo/wzHPWukyvfiqKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0345 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 03:38:40 -0000 --_000_MW2PR00MB0426A27B97B4C96D29604C6CF5739MW2PR00MB0426namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYWQgZXhwZWN0ZWQgdGhhdCB3ZSB3b3VsZCB1c2UgdGhlIGV4aXN0aW5nIG1lbWJlciBuYW1l IOKAnGF0X2hhc2jigJ0gZm9yIHRoZSBhY2Nlc3MgdG9rZW4gaGFzaCB2YWx1ZSwgcmF0aGVyIHRo YW4gdGhlIG5ldyBuYW1lIOKAnGF0aOKAnSwgc2luY2UgdGhlcmXigJlzIGFscmVhZHkgcHJlY2Vk ZW50IGZvciB1c2luZyBpdC4gIENvdWxkIHdlIGNoYW5nZSB0byB0aGUgc3RhbmRhcmQgbmFtZSBm b3IgdGhpcyB3aGVuIHdlIHB1Ymxpc2ggdGhlIG5leHQgdmVyc2lvbj8NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNywgMjAyMSAxOjMwIFBN DQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogW09BVVRILVdHXSBGd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1kcG9wLTAzLnR4dA0K DQpBIG5ldyByZXZpc2lvbiBvZiBEUG9QIGhhcyBiZWVuIHB1Ymxpc2hlZC4gVGhlIGRvYyBoaXN0 b3J5IHNuaXBwZXQgaXMgY29waWVkIGJlbG93LiBUaGUgbWFpbiBjaGFuZ2UgaGVyZSBpcyB0aGUg YWRkaXRpb24gb2YgYW4gYWNjZXNzIHRva2VuIGhhc2ggY2xhaW0uDQoNCiAgIC0wMw0KDQogICAq ICBBZGQgYW4gYWNjZXNzIHRva2VuIGhhc2ggKCJhdGgiKSBjbGFpbSB0byB0aGUgRFBvUCBwcm9v ZiB3aGVuIHVzZWQNCiAgICAgIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIHByZXNlbnRhdGlvbiBv ZiBhbiBhY2Nlc3MgdG9rZW4gZm9yDQogICAgICBwcm90ZWN0ZWQgcmVzb3VyY2UgYWNjZXNzDQoN CiAgICogIGFkZCBVbnRydXN0ZWQgQ29kZSBpbiB0aGUgQ2xpZW50IENvbnRleHQgc2VjdGlvbiB0 byBzZWN1cml0eQ0KICAgICAgY29uc2lkZXJhdGlvbnMNCg0KICAgKiAgRWRpdG9yaWFsIHVwZGF0 ZXMgYW5kIGZpeGVzDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tDQpG cm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+Pg0KRGF0ZTogV2VkLCBBcHIgNywgMjAyMSBhdCAyOjE2IFBNDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb2F1dGgtZHBvcC0wMy50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1vYXV0aC1kcG9wLTAzLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCcmlhbiBDYW1wYmVsbCBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaWV0Zi1v YXV0aC1kcG9wDQpSZXZpc2lvbjogICAgICAgMDMNClRpdGxlOiAgICAgICAgICBPQXV0aCAyLjAg RGVtb25zdHJhdGluZyBQcm9vZi1vZi1Qb3NzZXNzaW9uIGF0IHRoZSBBcHBsaWNhdGlvbiBMYXll ciAoRFBvUCkNCkRvY3VtZW50IGRhdGU6ICAyMDIxLTA0LTA3DQpHcm91cDogICAgICAgICAgb2F1 dGgNClBhZ2VzOiAgICAgICAgICAzMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1vYXV0aC1kcG9wLTAzLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtZHBv cC8NCkh0bWw6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0 LWlldGYtb2F1dGgtZHBvcC0wMy5odG1sDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZHBvcC0wMw0KRGlmZjogICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWRwb3AtMDMN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBmb3Ig c2VuZGVyLWNvbnN0cmFpbmluZyBPQXV0aCAyLjANCiAgIHRva2VucyB2aWEgYSBwcm9vZi1vZi1w b3NzZXNzaW9uIG1lY2hhbmlzbSBvbiB0aGUgYXBwbGljYXRpb24gbGV2ZWwuDQogICBUaGlzIG1l Y2hhbmlzbSBhbGxvd3MgZm9yIHRoZSBkZXRlY3Rpb24gb2YgcmVwbGF5IGF0dGFja3Mgd2l0aCBh Y2Nlc3MNCiAgIGFuZCByZWZyZXNoIHRva2Vucy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24g b3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFu ZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_MW2PR00MB0426A27B97B4C96D29604C6CF5739MW2PR00MB0426namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgaGFkIGV4 cGVjdGVkIHRoYXQgd2Ugd291bGQgdXNlIHRoZSBleGlzdGluZyBtZW1iZXIgbmFtZSDigJxhdF9o YXNo4oCdIGZvciB0aGUgYWNjZXNzIHRva2VuIGhhc2ggdmFsdWUsIHJhdGhlciB0aGFuIHRoZSBu ZXcgbmFtZSDigJxhdGjigJ0sIHNpbmNlIHRoZXJl4oCZcyBhbHJlYWR5IHByZWNlZGVudCBmb3Ig dXNpbmcgaXQuJm5ic3A7IENvdWxkIHdlIGNoYW5nZSB0byB0aGUgc3RhbmRhcmQNCiBuYW1lIGZv ciB0aGlzIHdoZW4gd2UgcHVibGlzaCB0aGUgbmV4dCB2ZXJzaW9uPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtv YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KQnJpYW4gQ2Ft cGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCA3LCAyMDIxIDE6MzAgUE08 YnI+DQo8Yj5Ubzo8L2I+IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW09BVVRILVdHXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtaWV0Zi1vYXV0aC1kcG9wLTAzLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QSBuZXcgcmV2aXNpb24gb2YgRFBvUCBoYXMgYmVlbiBwdWJsaXNoZWQu IFRoZSBkb2MgaGlzdG9yeSBzbmlwcGV0IGlzIGNvcGllZCBiZWxvdy4gVGhlIG1haW4gY2hhbmdl IGhlcmUgaXMgdGhlIGFkZGl0aW9uIG9mIGFuIGFjY2VzcyB0b2tlbiBoYXNoIGNsYWltLg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQom bmJzcDsgJm5ic3A7LTAzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyogJm5ic3A7QWRkIGFuIGFj Y2VzcyB0b2tlbiBoYXNoICgmcXVvdDthdGgmcXVvdDspIGNsYWltIHRvIHRoZSBEUG9QIHByb29m IHdoZW4gdXNlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGluIGNvbmp1bmN0aW9uIHdpdGgg dGhlIHByZXNlbnRhdGlvbiBvZiBhbiBhY2Nlc3MgdG9rZW4gZm9yPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgcHJvdGVjdGVkIHJlc291cmNlIGFjY2Vzczxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsqICZuYnNwO2FkZCBVbnRydXN0ZWQgQ29kZSBpbiB0aGUgQ2xpZW50IENvbnRleHQgc2VjdGlv biB0byBzZWN1cml0eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnNpZGVyYXRpb25zPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyogJm5ic3A7RWRpdG9yaWFsIHVwZGF0ZXMgYW5kIGZpeGVz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQpG cm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiBXZWQsIEFwciA3LCAyMDIxIGF0 IDI6MTYgUE08YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtb2F1dGgtZHBvcC0wMy50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1vYXV0aC1kcG9wLTAzLnR4dDxicj4NCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQnJpYW4gQ2FtcGJlbGwgYW5kIHBvc3RlZCB0 byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtb2F1dGgtZHBvcDxicj4NClJl dmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAzPGJyPg0KVGl0bGU6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPQXV0aCAyLjAgRGVtb25zdHJhdGluZyBQcm9vZi1v Zi1Qb3NzZXNzaW9uIGF0IHRoZSBBcHBsaWNhdGlvbiBMYXllciAoRFBvUCk8YnI+DQpEb2N1bWVu dCBkYXRlOiZuYnNwOyAyMDIxLTA0LTA3PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBvYXV0aDxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgMzI8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRm LW9hdXRoLWRwb3AtMDMudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYtb2F1dGgtZHBvcC0wMy50eHQ8L2E+PGJyPg0KU3RhdHVz OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWRwb3AvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1kcG9w LzwvYT48YnI+DQpIdG1sOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLW9hdXRo LWRwb3AtMDMuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hp dmUvaWQvZHJhZnQtaWV0Zi1vYXV0aC1kcG9wLTAzLmh0bWw8L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtZHBvcC0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRwb3AtMDM8L2E+PGJyPg0KRGlmZjom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWRwb3AtMDMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1v YXV0aC1kcG9wLTAzPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBmb3Igc2VuZGVyLWNvbnN0cmFpbmlu ZyBPQXV0aCAyLjA8YnI+DQombmJzcDsgJm5ic3A7dG9rZW5zIHZpYSBhIHByb29mLW9mLXBvc3Nl c3Npb24gbWVjaGFuaXNtIG9uIHRoZSBhcHBsaWNhdGlvbiBsZXZlbC48YnI+DQombmJzcDsgJm5i c3A7VGhpcyBtZWNoYW5pc20gYWxsb3dzIGZvciB0aGUgZGV0ZWN0aW9uIG9mIHJlcGxheSBhdHRh Y2tzIHdpdGggYWNjZXNzPGJyPg0KJm5ic3A7ICZuYnNwO2FuZCByZWZyZXNoIHRva2Vucy48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9h Pi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_MW2PR00MB0426A27B97B4C96D29604C6CF5739MW2PR00MB0426namp_-- From nobody Thu Apr 8 21:03:11 2021 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 30BEC3A2A7C; Thu, 8 Apr 2021 21:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: draft-ietf-oauth-access-token-jwt.all@ietf.org, last-call@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161794098307.30044.1825515016931854191@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Thu, 08 Apr 2021 21:03:03 -0700 Archived-At: Subject: [OAUTH-WG] Secdir telechat review of draft-ietf-oauth-access-token-jwt-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 04:03:04 -0000 Reviewer: Joseph Salowey Review result: Ready Thank you authors. This version addresses all my comments. From nobody Fri Apr 9 00:45:15 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868333A1446 for ; Fri, 9 Apr 2021 00:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGHVdE89Xn0S for ; Fri, 9 Apr 2021 00:45:10 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C0E3A1444 for ; Fri, 9 Apr 2021 00:45:10 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id l4so7116920ejc.10 for ; Fri, 09 Apr 2021 00:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ox73i/+oR3UBxScYYFuwyTGtQ5d1GMVme+YLXzyqpEs=; b=XPyztbjJU40MlhFiDKWz34HY7ZBdC2ahV/dTuP3KXVHkbdqkgXyRWUGJQAYrqp6F13 NqePg541PxgV/7nLxoXWC3Uor5x+kSyi9Ffuhmx3mzgWEpQHT4HmC9+yjBG2JHKxeF/w Bn9s931nFgD09992KzLMu6PUGytByMyfzcRmynoc5lDPfWvQNxEGGKLKWtbVmajeNyty znpJhx+nEbG1leuUWYxf16HXSeiP9IyOATDD6Rrvb6ODBNOi6rTwz2huZCaWB9TRQuGC Od1VJugjQpRymtwQxVVqVR7IMbaSgpHiLAd3ffcsl6XwRWxovue2BQCngEmTUSpRnKYl BocQ== 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=ox73i/+oR3UBxScYYFuwyTGtQ5d1GMVme+YLXzyqpEs=; b=HTej6hy1DeKjdAs2lYOy0t0gOIC+TsnRLaWk5prUAeXPlqm2FrvAPznTtXHUKb8juF H0RBie6WILezHiCVoyAMqv+lPr5m4w1ArvhsmddwIuDHBdolpdaYHjHDjAbJEYYDhIJn p9KhoaGIHDa+jeXjfn2wPKTNlJcQZyJHWjdj8nhb6excqCM7dnuBT7kPlyYFJbz6zVLe yJQi3XjWXv+mq8/8xaWqjjK5cbYqvBfL4fvKz3e+px4s+5dPqGbftdyph/KMmBb/Yuvl 0KUVd/BIWYCbZLAFrcSNZZLBt0KgsHXerPd7CaQqf43+9YsmKQv67mLee5ymRhSyQXQh iOYw== X-Gm-Message-State: AOAM530EteUcsR08e15+cHvbn4AK0+hI1kOrT5Xo8QYjkT3kLa54P554 UwsVfF70EUtCKr200Q5xfsCjv9YHMqGW X-Google-Smtp-Source: ABdhPJwmxGfR0y44UojA5fay7y+SDGeh4KmtvrrtgWUZ4x2b4ffWqmPdEzsM8f0JnJa3hO3S2EJOtw== X-Received: by 2002:a17:907:2d9f:: with SMTP id gt31mr14943362ejc.463.1617954308305; Fri, 09 Apr 2021 00:45:08 -0700 (PDT) Received: from [192.168.68.100] (173.c3.airnet.cz. [94.74.199.173]) by smtp.gmail.com with ESMTPSA id r19sm806068ejr.55.2021.04.09.00.45.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Apr 2021 00:45:07 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-89A07A01-0313-4CA8-A135-115D3A62573A Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Fri, 9 Apr 2021 09:45:06 +0200 Message-Id: References: Cc: bcampbell=40pingidentity.com@dmarc.ietf.org, oauth@ietf.org In-Reply-To: To: Mike Jones X-Mailer: iPhone Mail (18D70) Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 07:45:14 -0000 --Apple-Mail-89A07A01-0313-4CA8-A135-115D3A62573A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would support that too but only if the way it's calculated would get align= ed as well. If it remains being a fixed sha256 of the whole token rather tha= n what at_hash does, using a new claim makes sense.=20 Odesl=C3=A1no z iPhonu > 9. 4. 2021 v 5:38, Mike Jones : >=20 > =EF=BB=BF > I had expected that we would use the existing member name =E2=80=9Cat_hash= =E2=80=9D for the access token hash value, rather than the new name =E2=80=9C= ath=E2=80=9D, since there=E2=80=99s already precedent for using it. Could w= e change to the standard name for this when we publish the next version? > =20 > Thanks, > -- Mike > =20 > From: OAuth On Behalf Of Brian Campbell > Sent: Wednesday, April 7, 2021 1:30 PM > To: oauth > Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpo= p-03.txt > =20 > A new revision of DPoP has been published. The doc history snippet is copi= ed below. The main change here is the addition of an access token hash claim= . >=20 > -03 >=20 > * Add an access token hash ("ath") claim to the DPoP proof when used > in conjunction with the presentation of an access token for > protected resource access >=20 > * add Untrusted Code in the Client Context section to security > considerations >=20 > * Editorial updates and fixes > =20 > ---------- Forwarded message --------- > From: > Date: Wed, Apr 7, 2021 at 2:16 PM > Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt >=20 >=20 > A new version of I-D, draft-ietf-oauth-dpop-03.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. >=20 > Name: draft-ietf-oauth-dpop > Revision: 03 > Title: OAuth 2.0 Demonstrating Proof-of-Possession at the Applica= tion Layer (DPoP) > Document date: 2021-04-07 > Group: oauth > Pages: 32 > URL: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.t= xt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > Html: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.h= tml > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-= 03 >=20 > Abstract: > This document describes a mechanism for sender-constraining OAuth 2.0 > tokens via a proof-of-possession mechanism on the application level. > This mechanism allows for the detection of replay attacks with access > and refresh tokens. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-89A07A01-0313-4CA8-A135-115D3A62573A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would support that too but only if the wa= y it's calculated would get aligned as well. If it remains being a fixed sha= 256 of the whole token rather than what at_hash does, using a new claim make= s sense. 

Odesl=C3=A1no z iPhonu

9. 4. 2021 v 5:38, Mike Jone= s <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:

=EF=BB=BF

I had expected that we w= ould use the existing member name =E2=80=9Cat_hash=E2=80=9D for the access t= oken hash value, rather than the new name =E2=80=9Cath=E2=80=9D, since there= =E2=80=99s already precedent for using it.  Could we change to the stan= dard name for this when we publish the next version?

 

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;   Thanks,

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;   -- Mike

 

From: OAuth <oauth-bounces@ietf.org> = On Behalf Of Brian Campbell
Sent: Wednesday, April 7, 2021 1:30 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oaut= h-dpop-03.txt

 

A new revision of DPoP has been published. The doc hi= story snippet is copied below. The main change here is the addition of an ac= cess token hash claim.


   -03

   *  Add an access token hash ("ath") claim to the DPoP proo= f when used
      in conjunction with the presentation of an access token= for
      protected resource access

   *  add Untrusted Code in the Client Context section to sec= urity
      considerations

   *  Editorial updates and fixes

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.o= rg>
Date: Wed, Apr 7, 2021 at 2:16 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt



A new version of I-D, draft-ietf-oauth-dpop-03.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-ietf-oauth-dpop
Revision:       03
Title:          OAuth 2.0 Demonstrating Proof-of-Po= ssession at the Application Layer (DPoP)
Document date:  2021-04-07
Group:          oauth
Pages:          32
URL:            https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
Status:         https://datatracker.ietf.= org/doc/draft-ietf-oauth-dpop/
Html:           https://www.ie= tf.org/archive/id/draft-ietf-oauth-dpop-03.html
Htmlized:       https://tools.ietf.org/html/draft= -ietf-oauth-dpop-03
Diff:           https://www.iet= f.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-03

Abstract:
   This document describes a mechanism for sender-constraining OAu= th 2.0
   tokens via a proof-of-possession mechanism on the application l= evel.
   This mechanism allows for the detection of replay attacks with a= ccess
   and refresh tokens.




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

The IETF Secretariat


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

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-89A07A01-0313-4CA8-A135-115D3A62573A-- From nobody Fri Apr 9 01:35:08 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA68F3A1803; Fri, 9 Apr 2021 01:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rejaSnI8jpr5; Fri, 9 Apr 2021 01:34:58 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80071.outbound.protection.outlook.com [40.107.8.71]) (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 764943A1801; Fri, 9 Apr 2021 01:34:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ly1Smk70FK/CmJ2nkamK8rLYloSf8qN6iKI56MfROkwBjQi61+HcZdMQ8snVFLPRr9JQFIY4z3VLLsNj/rfOMH/v+VWmabybXb2fiHFqx2WCHROAnAO6slswAcTjWSLlZTGun+7CxNmMaJfbpQcAH9EEls+oM/N0DniyI/BNtlo4VI9FGtpMsZH/RYFkBtfNrzhdyyXUfJpXPORSUcimSm5xQZ4cVDP1Xs5lCVGyumX1ORk5QfjM9L4vhipSBMCuQcV+jy0JEqTMnwtckTlUaveZ2ttxJAqXWDUZ8nowj1UQdZtCNdXbKsZB07FdqRJ+Tgyb8D4BWiXamqPJT4mcxA== 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=XdlR8WwyUi5cpbDJfAro2PYj2YXT7iA5Mp1JUMXJ7xI=; b=aQ6zJRkAWnzSHJvW8i1rwlynbaLrJaakJEHP8jNWTVo6mQLxVTAUGFZnlMvxtI9JgFyxQ2kEoKTxYPNscK0OczzkSJHPnoopzkH6UQRhp4sfeToz7M5Am62WAaIHkOiFgXWDI7FRp0zijrszD7PzFKztmmKlAkXvlQVvOtNOV3OFfFiGmJcY1E94KXIDOak5xMLGWWcxE1nYJqtP1fChr/cft/H2DqxJ6dptyg+cVML37hTjVOMHpAvypBH0JmedUo0oLJq8X8mBS6dV0EgOoV2K708UAPD00iIJvMI6nzYzk+iWgUmypq2HyHbUkFfjsIjnXfMTNZOBQ7uWIIhTVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XdlR8WwyUi5cpbDJfAro2PYj2YXT7iA5Mp1JUMXJ7xI=; b=bBOyd8eL4vTxhPol0g5jEPsC9nXlA0QK2i+CqpGgHb8+z6VE/rbRPN7QmuXdBvNgM24qYKGh3Qtc7f/LlBsjZ/mMWVdJuYULltotqAkYoYAE7WVGIjx+x3iazCt9/AQzX9K6THfca93i+1KP11R0xIphcBM5qDxcWjbtUPca4/o= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2348.eurprd07.prod.outlook.com (2603:10a6:3:74::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.6; Fri, 9 Apr 2021 08:34:54 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b%5]) with mapi id 15.20.4020.017; Fri, 9 Apr 2021 08:34:54 +0000 From: Francesca Palombini To: Mike Jones , "iesg@ietf.org" CC: "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "Hannes.Tschofenig@gmx.net" Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT) Thread-Index: AdcsMekdJv5IcULvQ1qzavuY873M4wAOwfAAAAQud6AADjkDsAAdWseA Date: Fri, 9 Apr 2021 08:34:54 +0000 Message-ID: <1B07BB5E-C66C-4E6C-A619-C432645E0F54@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-08T02:41:17Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cdfb0104-3004-44ad-80cf-5c9eac18df57; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: microsoft.com; dkim=none (message not signed) header.d=none; microsoft.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:fdb0:324c:f5cc:a67] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 30090258-ad6c-4364-1dc0-08d8fb325995 x-ms-traffictypediagnostic: HE1PR0701MB2348: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BqXH+tNa3v29ezGlzf86WBTCGqIifdt9+AewAlPXYYh+fohP8Mo5zMOmNNiFqEFBGytiLarq4x6/OqU6GMkTzcjwg5Qth1Razj0srIklXSueumZYRCBykF7Yx/1Mfdd8I148agGI906S/dKsxv1BfVNpvYGXzRnxlNit36uqchOwdU01DFq6PoUU668kbQZv1FfHtBjcv8+kFckBYTIBRJ8mSu1VpywoF6A8aLus/KVdyqFN594popWjPAmwATkxNostu16onHK9BO9z4yahTNFUVd6FE8gWuJxfftQhq28h8kNhDtlZE5yMxiK8H//bb6n2A4/zJoKuC2UV1wprYd4Yxb1qv7X4VPM5YuXTFR3AtBXS1GFZske9EZiEabu9YAw3JxiwhS0RxqXJ/NRnOdCxjBAASTjLbj8SXr9xtJdQyW1V1tZIIORpTqKQQkDQ9eGdUrDOdGwaM58EiOg0r2YQr3hsBVF/AliVfAb848jqeiodT28lLStwoJWKzaOXRxGa9RXKMuzIWtHYqGfOnYctNRd8rstxSHZ0HFVFNIzZqFgZcpbBQ53NCq+IJAclioJuJciHz2KZIRIXnsGZixauP0CiuGjyqjV3LmccK22Hkl9oRKeQ+zXd35J5bxzRbMBz/RJUyMsQDwug9XxCDJIojg9zX4nSLQxGjXf0IRQdGPity7BIXmuftnB8L7tKlZmj23WNnHHoNMspK9vQNv4KzESQX0h+sXI8pOeOkeD2KALY5jcufU8omUEO0s4T5RxVgB45D5sPVJjxlYxF4Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(346002)(39860400002)(366004)(396003)(71200400001)(6512007)(186003)(6486002)(38100700001)(8936002)(5660300002)(2906002)(4326008)(44832011)(6506007)(478600001)(54906003)(110136005)(53546011)(66946007)(2616005)(86362001)(66556008)(66476007)(36756003)(64756008)(966005)(66446008)(76116006)(33656002)(8676002)(316002)(83380400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cDcvd1lLVDRrTzYyZ1VSV05mK0Vvd2JlOTI2S0NXMjM3VVI1MFZLN0toNUFR?= =?utf-8?B?NHdaZmFIQ0RZYVNuMG1PU1pId1Z4dUJqQi96Z0pzVzR3TU1lZklqbStGWGFE?= =?utf-8?B?Y2c4bU1sZFdFWmUwUDRaN0xoWCtBUHVTVmxKc0pvbWY2aDV2aVJJVVVNSU9l?= =?utf-8?B?ZVJMZU1Zbnd0V3N2NDlOcW8valB5Q1NLNWVqZzYwdHJYS3ExYS91OEdSbHBI?= =?utf-8?B?TVVabitsT1gvVjJUeTNicUhXRjRrbU8xUEZtdytxdkpVUmk0S25Rc3E2Wmdv?= =?utf-8?B?dUpnejhXYWg4c0FTK1RnVW9LUkNVOU0vYU1TWnBLNWxsU251NHN1NG8xQlFT?= =?utf-8?B?Rnk0bzE1NHg1VWtSalRFdDY1VEtCWHZhKzdESXd3eHVMVXAzc3FYLzJxek1F?= =?utf-8?B?dWFBTXZBbEtFdjJ5YmMxWDlJbzhIWjVtWUN4aEJKRTZtN1U3TmtKSjBRV2Ju?= =?utf-8?B?NjRFbk5mV2FwWTcvK3NXMWMyY29ySHBJTDhpTFdPZVJTYTNRSkpZSHNBVGVt?= =?utf-8?B?WmEzMkRsb0xZSk9kanhsejJSdDNMSDBDRW5Ydi9UdDZRNEkwKzJqQU9nMjNm?= =?utf-8?B?cmpObkR6b00zMytDajV3L1NUc1lkSHN2ZjJYNDlhd1R5Q3Q5R0pYUUxOYXVt?= =?utf-8?B?T0k2Uno0SE1VaERqM2UyQk16K1NBUGhKMjNtWjNTZVo5aTNLaW11cWVqUU5H?= =?utf-8?B?VlJQaGRROEV2bm1DZC9OWUhiZUh1c3d3L1FJYU1MdG5JRkEzc3JhcFU5aDNP?= =?utf-8?B?bTJ3ckNBRnNXK01ESzVrdzRkUG1nNkc3NDRrUkNSMzd4NWtoOCtoRTlBYWtZ?= =?utf-8?B?YkxEb2xkd1g5LzBDV1lWTlVHUlJEaXF3T0M1eGVTeWFUZkNqdGtjSEdVRGFP?= =?utf-8?B?U0NZUkNZM0Q0d2ViMDlLeU0veUdEejZMSElsZ28vZDlUR3dRQUFIUGY5VVFG?= =?utf-8?B?WGdTZHNtanVVSnpOdWV1UW1UT29ENXR3d1JtdnRacTN5OXd0bHZrcGVvSWpX?= =?utf-8?B?TWVTMWdLS1RJZWJRbVl3VnhEanprdmRnUldCTjV0TWFmQWs2ZW9UQWhuWHBq?= =?utf-8?B?WjBraEVVY1NjclR4WDRMUXBmSjNyeWhOcUQrQjJoSnNOOVBXay96QkIva0Ev?= =?utf-8?B?VGhoaVFTMTZ1L1BVd3NERExmY0Y2c01oOGhPQStJZHBCdlZHT2F1dkhnWTlE?= =?utf-8?B?YnNQUTlNcm5HQkxCMlEydXY2L3dxazdjK3pqZ1JVbkh3YUptZVVVZldIbmZu?= =?utf-8?B?UUdpeFYrbVpndnY0eGQwdFZ6UXFXRURNTHlFTTFpaHIzNFY5VGtuenB3bE1y?= =?utf-8?B?eDhtbS8xcXF6b0Z5eUtKT2oyeWhnMUJXelN6RCtseDBLKzNZUCtPNTdGVWRE?= =?utf-8?B?d09taWgraE5GamloQldEMzk0MEtPeTJ3MGs5dFpVazNMSG5ubmVJSFVTcGRZ?= =?utf-8?B?VUdja2ZidUdLL3JoM3R6Q1NzdXJIR0hpYmNIbTgzTFNBUks0bXg1M2E4M0hy?= =?utf-8?B?YUxKTElOdHRYYnB2SUxvNDBqZmVBdW00djVpbU45YmZ3TFhrbW9yUHloMFl1?= =?utf-8?B?L3FxM0NmUS9VR2RVNHJJTUh2SmJyKzkyTmtxZDdIaEdBUzdJL1VtaWZQUmJO?= =?utf-8?B?bFRDL24zS0ZaQmJ5WGVCclcwZVd1d2ZSZkpZeEhzRG5sbmZZKy9neW1Xa0tL?= =?utf-8?B?VXEvRDVlWVJ6L2ZWQ09Ed2I2akoxcVRLWENwSklDUmVkNC93cGZnZVNMNkU3?= =?utf-8?B?cFpuZ3pEK01lYjZRYkV5aXVpZEFpVkFOMEltNUFNMXFxRWRBTmZrOWw4T1Fa?= =?utf-8?B?NHdQV29saC9VaWdzNEd1MWRqSEZRdlpXL1N0UlIvR2FlSWc0T2tRR2tmYnNu?= =?utf-8?B?eG9uTU5kdFZFUWhsY01uVE9YVHAxVkNaSzNBZk5TMXdGUGc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5984AEB254566241B66ED7CCDC7E0752@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30090258-ad6c-4364-1dc0-08d8fb325995 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 08:34:54.1827 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UD5i5JEPC6blF3HOjjuPb+yH9TYrGOYGfIO5cymXieQkaLkR3OTtcqDUYWFdySpmzKZsm+GOZOC9s4zhmuoQeCdwBuOfu7feZFdj8SbP7qUVO9Ublzev3bYS7X2fqxgx X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2348 Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with 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, 09 Apr 2021 08:35:03 -0000 SGkgTWlrZSEgVGhhbmsgeW91LCBpdCBsb29rcyBnb29kIHRvIG1lLiBJIGhhdmUgdXBkYXRlZCBt eSBiYWxsb3QgdG8gcmVmbGVjdCB0aGF0Lg0KDQpGcmFuY2VzY2ENCg0K77u/T24gMDgvMDQvMjAy MSwgMjM6MjAsICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90 ZToNCg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3 c3JlcS0zNCBpbmNvcnBvcmF0ZXMgdGhlIGZpeGVzIHlvdSBzdWdnZXN0ZWQuDQoNCiAgICAJCQkJ VGhhbmtzIGFnYWluLA0KICAgIAkJCQktLSBNaWtlDQoNCiAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KICAgIEZyb206IE1pa2UgSm9uZXMgDQogICAgU2VudDogVGh1cnNkYXksIEFwcmls IDgsIDIwMjEgNjo0OSBBTQ0KICAgIFRvOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2Eu cGFsb21iaW5pQGVyaWNzc29uLmNvbT47IGllc2dAaWV0Zi5vcmcNCiAgICBDYzogZHJhZnQtaWV0 Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmc7IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsgb2F1dGhAaWV0 Zi5vcmc7IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQNCiAgICBTdWJqZWN0OiBSRTogRnJhbmNl c2NhIFBhbG9tYmluaSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0z MjogKHdpdGggQ09NTUVOVCkNCg0KICAgIFRoYW5rcyBmb3Igc3dlYXRpbmcgdGhlIGRldGFpbHMs IEZyYW5jZXNjYS4gIEknbGwgcGxhbiB0byBwdWJsaXNoIGFuIHVwZGF0ZWQgZHJhZnQgYWZ0ZXIg dGhlIHRlbGVjaGF0IG1ha2luZyB0aGUgZXJyb3IgaGFuZGxpbmcgZm9yIHRoZSBjYXNlIHdoZW4g dGhlIGtleSBpc24ndCBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudCBjbGVhcmVyLg0KDQogICAg CQkJCVRoYW5rcyBhZ2FpbiwNCiAgICAJCQkJLS0gTWlrZQ0KDQogICAgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFs b21iaW5pQGVyaWNzc29uLmNvbT4gDQogICAgU2VudDogVGh1cnNkYXksIEFwcmlsIDgsIDIwMjEg Mjo0NyBBTQ0KICAgIFRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ OyBpZXNnQGlldGYub3JnDQogICAgQ2M6IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxQGlldGYub3Jn OyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnOyBIYW5uZXMuVHNjaG9mZW5p Z0BnbXgubmV0DQogICAgU3ViamVjdDogUmU6IEZyYW5jZXNjYSBQYWxvbWJpbmkncyBObyBPYmpl Y3Rpb24gb24gZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzI6ICh3aXRoIENPTU1FTlQpDQoNCiAg ICBIaSBNaWtlIQ0KDQogICAgVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVwbHkuIEl0IGxvb2tzIGdv b2QgdG8gbWUsIGp1c3Qgb25lIGFuc3dlciB0byBwb2ludCA0LiA6DQoNCiAgICAgICAgNC4gLS0t LS0NCg0KICAgICAgICAgICBzcGVjaWZpZWQgaW4gdGhlICJhbGciIEhlYWRlciBQYXJhbWV0ZXIu ICBJZiBhICJraWQiIEhlYWRlciBQYXJhbWV0ZXINCiAgICAgICAgICAgaXMgcHJlc2VudCwgdGhl IGtleSBpZGVudGlmaWVkIE1VU1QgYmUgdGhlIGtleSB1c2VkLCBhbmQgTVVTVCBiZSBhDQogICAg ICAgICAgIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudC4gIEFsZ29yaXRobSB2ZXJpZmlj YXRpb24gTVVTVCBiZQ0KDQogICAgICAgIC4uLg0KDQogICAgICAgICAgIHNhbWUgcGFyYW1ldGVy IGlzIHByb3ZpZGVkIGluIHRoZSBxdWVyeSBwYXJhbWV0ZXIuICBUaGUgQ2xpZW50IElEDQogICAg ICAgICAgIHZhbHVlcyBpbiB0aGUgImNsaWVudF9pZCIgcmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGlu IHRoZSBSZXF1ZXN0IE9iamVjdA0KICAgICAgICAgICAiY2xpZW50X2lkIiBjbGFpbSBNVVNUIGJl IGlkZW50aWNhbC4gIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0aGVuDQoNCiAgICAgICAgRlA6 ICJNVVNUIGJlIGEga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50IiAtIHdoYXQgaWYgaXQg aXMgbm90PyBkb2VzIHRoZSBBUyByZXR1cm4gYW4gZXJyb3IgdG8gdGhlIGNsaWVudCB0aGVuPyBT YW1lIGNvbW1lbnQgIi4uLiBNVVNUIGJlIGlkZW50aWNhbCIgLSBpcyBhbnkgZXJyb3IgcmV0dXJu ZWQgaWYgaXQncyBub3Q/DQoNCiAgICAgICAgTWlrZT4gSSBiZWxpZXZlIHRoYXQgdGhlIHJlc3Bv bnNlcyB0byB0aGVzZSB2YWxpZGF0aW9uIGVycm9ycyBhcmUgYWxyZWFkeSBkZXNjcmliZWQgaW4g dGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgsIHdoaWNoIHNheXMgIklmIHNpZ25hdHVyZSB2YWxpZGF0 aW9uIGZhaWxzLCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4gJ2ludmFs aWRfcmVxdWVzdF9vYmplY3QnIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhl IGF1dGhvcml6YXRpb24gcmVxdWVzdC4iDQoNCiAgICBGUDogQXMgSSByZWFkIGl0LCB0aGUgZmly c3QgcGFyYWdyYXBoIHNheXM6IA0KDQogICAgICAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1V U1QgdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgSlNPTiBXZWINCiAgICAgICBTaWduYXR1 cmUgW1JGQzc1MTVdIHNpZ25lZCBSZXF1ZXN0IE9iamVjdC4gIElmIGEgImtpZCIgSGVhZGVyDQoN CiAgICBUaGVuIGZvbGxvd3MgdXAgd2l0aCBhIG51bWJlciBvZiBvdGhlciBjaGVja3MgdGhhdCBu ZWVkIHRvIGJlIGRvbmUgKHRoZSB0ZXh0IEkgcXVvdGVkIGluIG15IG9yaWdpbmFsIGNvbW1lbnQp LiBBbmQgdGhlbiBlbmRzIHdpdGggdGhlIHNlbnRlbmNlIHlvdSBxdW90ZWQ6DQoNCiAgICAgICBJ ZiBzaWduYXR1cmUgdmFsaWRhdGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1V U1QgcmV0dXJuDQogICAgICAgYW4gImludmFsaWRfcmVxdWVzdF9vYmplY3QiIGVycm9yIHRvIHRo ZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlDQogICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0 Lg0KDQogICAgU2FtZSBmb3IgdGhlIHNlY29uZCAtIHRoZSB0ZXh0IEkgcmVwb3J0ZWQgaXMgZm9s bG93ZWQgYnk6DQoNCiAgICAgIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciB0aGVuDQogICAgICAg dmFsaWRhdGVzIHRoZSByZXF1ZXN0IGFzIHNwZWNpZmllZCBpbiBPQXV0aCAyLjAgW1JGQzY3NDld Lg0KDQogICAgQW5kIHRoZW4gYWdhaW4gZnJvbSB0aGUgdGV4dCB5b3UgcXVvdGVkOg0KDQogICAg ICAgSWYgdGhlIHZhbGlkYXRpb24gZmFpbHMsIHRoZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVy IE1VU1QgcmV0dXJuIGFuDQogICAgICAgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiByZXNwb25zZSB0 byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBhcw0KICAgICAgIHNwZWNpZmllZCBpbiBTZWN0 aW9uIDUuMiBvZiBPQXV0aCAyLjAgW1JGQzY3NDldLg0KDQogICAgU28gd2hpbGUgcmVhZGluZyBJ IGNvbnNpZGVyZWQgdGhhdCB0aGUgdmFsaWRhdGlvbiAoZWl0aGVyIG9mIHRoZSBzaWduYXR1cmUg Zm9yIHBhciAxIG9yIG9mIHRoZSByZXF1ZXN0IGZvciBwYXIgMikgaXMgc2VwYXJhdGUgZnJvbSB0 aGUgYWRkaXRpb25hbCBjaGVja3MuIFRoZSBpbnRlbnQgb2YgaXQgY291bGQgYmUgbWFkZSBjbGVh ciBieSBhIG1pbm9yIGFkZGl0aW9uIGluIGVhY2ggcGFyOg0KDQogICAgMXN0IHBhcmFncmFwaDoN Cg0KICAgIE9MRDoNCg0KICAgICAgIElmIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4NCiAgICAgICBhbiAiaW52YWxpZF9yZXF1 ZXN0X29iamVjdCIgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiByZXNwb25zZSB0byB0aGUNCiAgICAg ICBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQoNCiAgICBORVc6DQoNCiAgICAgICBJZiBzaWduYXR1 cmUgdmFsaWRhdGlvbiBmaWFscywgb3IgaWYgdGhlIGtleSBpZGVudGlmaWVkIGlzIG5vdCBhc3Nv Y2lhdGVkIHdpdGggdGhlIGNsaWVudCwgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0 dXJuDQogICAgICAgYW4gImludmFsaWRfcmVxdWVzdF9vYmplY3QiIGVycm9yIHRvIHRoZSBjbGll bnQgaW4gcmVzcG9uc2UgdG8gdGhlDQogICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KDQog ICAgMm5kIHBhcmFncmFwaDoNCg0KICAgIE9MRDoNCg0KICAgICAgIElmIHRoZSB2YWxpZGF0aW9u IGZhaWxzLCB0aGVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVybiBhbg0KICAg ICAgIGVycm9yIHRvIHRoZSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gdGhlIGF1dGhvcml6YXRpb24g cmVxdWVzdCwgYXMNCiAgICAgICBzcGVjaWZpZWQgaW4gU2VjdGlvbiA1LjIgb2YgT0F1dGggMi4w IFtSRkM2NzQ5XS4NCg0KICAgIE5FVzoNCg0KICAgICAgIElmIHRoZSB2YWxpZGF0aW9uIG9mIHRo ZSByZXF1ZXN0IG9yIHRoZSBDbGllbnQgSUQgY2hlY2sgZmFpbHMsIHRoZW4gdGhlIEF1dGhvcml6 YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuIGFuDQogICAgICAgZXJyb3IgdG8gdGhlIGNsaWVudCBp biByZXNwb25zZSB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBhcw0KICAgICAgIHNwZWNp ZmllZCBpbiBTZWN0aW9uIDUuMiBvZiBPQXV0aCAyLjAgW1JGQzY3NDldLg0KDQoNCiAgICBJIHRo aW5rIHRoaXMgd291bGQgY2xhcmlmeSB0aGUgdGV4dCwgYnV0IEknbGwgbGVhdmUgaXQgdXAgdG8g eW91IHRvIGRlY2lkZSBpZiBpdCdzIHdvcnRoIGFkZGluZy4NCiAgICBUaGFua3MsDQogICAgRnJh bmNlc2NhDQoNCiAgICBPbiAwOC8wNC8yMDIxLCAwNjo0NSwgIk1pa2UgSm9uZXMiIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQogICAgICAgIFRoYW5rcyBmb3IgeW91ciBy ZXZpZXcsIEZyYW5jZXNjYS4gIFdlJ3ZlIHB1Ymxpc2hlZCBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzMgdG8gYWRkcmVzcyB5b3VyIGFuZCBvdGhl ciBJRVNHIGNvbW1lbnRzLg0KDQogICAgICAgIFJlc3BvbnNlcyBhcmUgaW5saW5lIGJlbG93LCBw cmVmaXhlZCBieSAiTWlrZT4iLg0KDQogICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQogICAgICAgIEZyb206IEZyYW5jZXNjYSBQYWxvbWJpbmkgdmlhIERhdGF0cmFja2VyIDxub3Jl cGx5QGlldGYub3JnPiANCiAgICAgICAgU2VudDogV2VkbmVzZGF5LCBBcHJpbCA3LCAyMDIxIDM6 MjkgQU0NCiAgICAgICAgVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KICAgICAgICBDYzog ZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmc7IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsg b2F1dGhAaWV0Zi5vcmc7IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQNCiAgICAgICAgU3ViamVj dDogRnJhbmNlc2NhIFBhbG9tYmluaSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9hdXRo LWp3c3JlcS0zMjogKHdpdGggQ09NTUVOVCkNCg0KICAgICAgICBGcmFuY2VzY2EgUGFsb21iaW5p IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgICAgICBk cmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMjogTm8gT2JqZWN0aW9uDQoNCiAgICAgICAgV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K DQoNCiAgICAgICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgICAgICBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCiAgICAgICAg VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW9hdXRoLWp3c3JlcS8NCg0KDQoNCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAg ICBDT01NRU5UOg0KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICAgICAgVGhhbmsgeW91IGZv ciB0aGUgd29yayBvbiB0aGlzIGRvY3VtZW50LiBJIG9ubHkgaGF2ZSBtaW5vciBjb21tZW50cywg dGhlIG1vc3QgaW50ZXJlc3RpbmcgaXMgcHJvYmFibHkgNC4gYWJvdXQgaWYgYWRkaXRpb25hbCBm YWlsdXJlIGJlaGF2aW9yIHNob3VsZCBiZSBkZWZpbmVkIGF0IHRoZSBBUy4NCg0KICAgICAgICBG cmFuY2VzY2ENCg0KICAgICAgICAxLiAtLS0tLQ0KDQogICAgICAgICAgIEEgUmVxdWVzdCBPYmpl Y3QgKFNlY3Rpb24gMi4xKSBoYXMgdGhlICJtaW1lLXR5cGUiICJhcHBsaWNhdGlvbi8NCg0KICAg ICAgICBGUDogUGxlYXNlIHVzZSAibWVkaWEgdHlwZSIgaW5zdGVhZCBvZiAibWltZS10eXBlIiBh bmQgcmVmZXJlbmNlDQogICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODM4 DQoNCiAgICAgICAgTWlrZT4gVGhhbmtzLCB1cGRhdGVkLCBhbHRob3VnaCByZWZlcmVuY2luZyBS RkMgMjA0NiBmb3IgdGhlIHRlcm0gIm1lZGlhIHR5cGUiICh3aGljaCBpcyBub3Qgc3VwZXJzZWRl ZCBieSBSRkMgNjgzOCkuDQoNCiAgICAgICAgMi4gLS0tLS0NCg0KICAgICAgICAgICBUaGUgZm9s bG93aW5nIGlzIGFuIGV4YW1wbGUgb2YgdGhlIENsYWltcyBpbiBhIFJlcXVlc3QgT2JqZWN0IGJl Zm9yZQ0KICAgICAgICAgICBiYXNlNjR1cmwgZW5jb2RpbmcgYW5kIHNpZ25pbmcuICBOb3RlIHRo YXQgaXQgaW5jbHVkZXMgdGhlIGV4dGVuc2lvbg0KDQogICAgICAgIEZQOiBUaGlzIGV4YW1wbGUg aXMgdGhlIGZpcnN0IHRpbWUgImJhc2U2NHVybCIgYXBwZWFycyBpbiB0aGUgZG9jdW1lbnQuIEkg dGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB0byBtZW50aW9uIHRoYXQgYmFzZTY0dXJsIGlzIHVz ZWQgd2hlbiBKV1QgaXMgaW50cm9kdWNlZCwgZm9yIGV4YW1wbGUgaW4gdGhlIGZpcnN0IHBhcmFn cmFwaCBvZiBzZWN0aW9uIDQuDQoNCiAgICAgICAgTWlrZT4gUmVmZXJlbmNlIGFkZGVkLg0KDQog ICAgICAgIDMuIC0tLS0tDQoNCiAgICAgICAgICAgSWYgZGVjcnlwdGlvbiBmYWlscywgdGhlIEF1 dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0dXJuIGFuDQogICAgICAgICAgICJpbnZhbGlkX3Jl cXVlc3Rfb2JqZWN0IiBlcnJvci4NCg0KICAgICAgICAuLi4NCg0KICAgICAgICAgICBJZiBzaWdu YXR1cmUgdmFsaWRhdGlvbiBmYWlscywgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1QgcmV0 dXJuDQogICAgICAgICAgIGFuICJpbnZhbGlkX3JlcXVlc3Rfb2JqZWN0IiBlcnJvci4NCg0KICAg ICAgICAuLi4NCg0KICAgICAgICAgICBJZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhlbiB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgTVVTVCByZXR1cm4gYW4NCiAgICAgICAgICAgZXJyb3IgYXMg c3BlY2lmaWVkIGluIE9BdXRoIDIuMCBbUkZDNjc0OV0uDQoNCiAgICAgICAgRlA6IHZlcnkgbWlu b3IsIGJ1dCBJIHN1Z2dlc3RzIHlvdSBhZGQgInRvIHRoZSBjbGllbnQsIGluIHJlc3BvbnNlIHRv IHRoZSByZXF1ZXN0IGRlZmluZWQgaW4gNS4yLjIuIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiIuIFRo ZSByZWFzb24gaXMgdGhhdCB0aGUgZG9jIHNwZWNpZmllcyB0aGF0IHRoZSBBUyBtaWdodCBiZSBo YXZpbmcgb3RoZXIgZXhjaGFuZ2VzICh0byBmZXRjaCB0aGUgUmVxdWVzdA0KICAgICAgICBPYmpl Y3QpIGF0IHRoZSBzYW1lIHRpbWUsIGFuZCBpdCBjYW4ndCBodXJ0IHRvIGJlIHByZWNpc2UuIEFs c28gcmVnYXJkaW5nIHRoZSByZWZlcmVuY2UgdG8gUkZDIDY3NDkgLSBjYW4geW91IGFkZCBhIHNw ZWNpZmljIHNlY3Rpb24gdG8gcmVmZXJlbmNlPw0KDQogICAgICAgIE1pa2U+IERvbmUNCg0KICAg ICAgICA0LiAtLS0tLQ0KDQogICAgICAgICAgIHNwZWNpZmllZCBpbiB0aGUgImFsZyIgSGVhZGVy IFBhcmFtZXRlci4gIElmIGEgImtpZCIgSGVhZGVyIFBhcmFtZXRlcg0KICAgICAgICAgICBpcyBw cmVzZW50LCB0aGUga2V5IGlkZW50aWZpZWQgTVVTVCBiZSB0aGUga2V5IHVzZWQsIGFuZCBNVVNU IGJlIGENCiAgICAgICAgICAga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50LiAgQWxnb3Jp dGhtIHZlcmlmaWNhdGlvbiBNVVNUIGJlDQoNCiAgICAgICAgLi4uDQoNCiAgICAgICAgICAgc2Ft ZSBwYXJhbWV0ZXIgaXMgcHJvdmlkZWQgaW4gdGhlIHF1ZXJ5IHBhcmFtZXRlci4gIFRoZSBDbGll bnQgSUQNCiAgICAgICAgICAgdmFsdWVzIGluIHRoZSAiY2xpZW50X2lkIiByZXF1ZXN0IHBhcmFt ZXRlciBhbmQgaW4gdGhlIFJlcXVlc3QgT2JqZWN0DQogICAgICAgICAgICJjbGllbnRfaWQiIGNs YWltIE1VU1QgYmUgaWRlbnRpY2FsLiAgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRoZW4NCg0K ICAgICAgICBGUDogIk1VU1QgYmUgYSBrZXkgYXNzb2NpYXRlZCB3aXRoIHRoZSBjbGllbnQiIC0g d2hhdCBpZiBpdCBpcyBub3Q/IGRvZXMgdGhlIEFTIHJldHVybiBhbiBlcnJvciB0byB0aGUgY2xp ZW50IHRoZW4/IFNhbWUgY29tbWVudCAiLi4uIE1VU1QgYmUgaWRlbnRpY2FsIiAtIGlzIGFueSBl cnJvciByZXR1cm5lZCBpZiBpdCdzIG5vdD8NCg0KICAgICAgICBNaWtlPiBJIGJlbGlldmUgdGhh dCB0aGUgcmVzcG9uc2VzIHRvIHRoZXNlIHZhbGlkYXRpb24gZXJyb3JzIGFyZSBhbHJlYWR5IGRl c2NyaWJlZCBpbiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCwgd2hpY2ggc2F5cyAiSWYgc2lnbmF0 dXJlIHZhbGlkYXRpb24gZmFpbHMsIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHJldHVy biBhbiAnaW52YWxpZF9yZXF1ZXN0X29iamVjdCcgZXJyb3IgdG8gdGhlIGNsaWVudCBpbiByZXNw b25zZSB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiINCg0KICAgICAgICA1LiAtLS0tLQ0K DQogICAgICAgICAgIGxvY2F0aW9uLCAoYikgY2hlY2sgdGhlIGNvbnRlbnQgdHlwZSBvZiB0aGUg cmVzcG9uc2UgaXMgImFwcGxpY2F0aW9uLw0KDQogICAgICAgIEZQOiBGb3IgY29uc2lzdGVuY3ks IHBsZWFzZSBjaGFuZ2UgImNvbnRlbnQgdHlwZSIgdG8gIm1lZGlhIHR5cGUiLg0KDQogICAgICAg IE1pa2U+IERvbmUNCg0KICAgICAgICAJCQkJVGhhbmtzIGFnYWluLA0KICAgICAgICAJCQkJLS0g TWlrZQ0KDQoNCg0KDQo= From nobody Fri Apr 9 08:04:23 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2755E3A241E for ; Fri, 9 Apr 2021 08:04:22 -0700 (PDT) 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 rEzcx_K_ZEYn for ; Fri, 9 Apr 2021 08:04:16 -0700 (PDT) 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 EB57E3A241B for ; Fri, 9 Apr 2021 08:04:15 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id x13so47345lfr.2 for ; Fri, 09 Apr 2021 08:04:15 -0700 (PDT) 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=LKBrDcPzHy5D1ah49QFvDEcp1h/J/9SRT2wIatiZoaA=; b=TkM3PyoE8mBVGiLRJqfmhXex/uoMUNvWCOzT3uwtd7XO2HNcBeBlh72j0ZOyNzdQdH hvaiVYDJ13URm7AjiKp/hqfu0S3OBY50Yph7717vwtQ0sczEFPUkNNgY1Z/oVSYcDHwE Mrc7VvQjGcd3pHpFc+oj9t/c3eBKgoS4ev15TB9UCM65Rv+C4nkimVo7ozKZmh5Cypfe BPZy7tEAC8blMd0AIYF749oB1FFl9L5b4WGB8j44ld4NYYfnNTvI1lZq/OolKn4dUayT VAmo+OBJUFODxIX8jvr3tQbGKmn9bh/kUu+gIatVGrtnQrZwnpfGmDx+0JNPgSb/x/6f xRSg== 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=LKBrDcPzHy5D1ah49QFvDEcp1h/J/9SRT2wIatiZoaA=; b=C0xZ3GaDSqvIlU0LuFjc224OivP/hFkWOl83IBykYJ381KObtfxNsmX4CD0K318qgE r0ACarTedJXIdiR2PQCEj3PsDGKX2L5G99POCFbnA9z/vZZB6QDQoIpud7hePKp00P6i s65tSw2cDPARY4eZl2UWnZ8+zs2+Wc3+vIIMzr9OyJ7KandTBNzO771CsWJ1XyB0kPvJ Q4qFQQypn5Qao7aT6b6k49XHFOZtDcHSKCebMz+OiqO5DMyM7BF+fTvPmQLADMpwT9aU 6kRpnlhrnzXQaibZaFbTQxo6R3H5zw62mPENS0OE+8QuT9PS8Gw2hcPeCM1bpaLvENZn LHEQ== X-Gm-Message-State: AOAM532Q626+T2HAKOpMw5OCsbVEiBOSAXuKaHt1rsUL69JBBModgY+U WlrsDO7jTjNConM/vKSUConECY7KS8cNYNKUHG8b+J7mHwnpiz10t/wP/tvghCzR8/50VcpAXTD 1Hz1U8HCiyVXF2g== X-Google-Smtp-Source: ABdhPJxTdn64wiShBsvOgC/1V4cC9+vzkeFFLVlufv59CSuH2CZ2Sii83tQJAwXKeF8tRQfWYzMbttVh09VPgoVGkj4= X-Received: by 2002:a05:6512:31c2:: with SMTP id j2mr11295153lfe.77.1617980653141; Fri, 09 Apr 2021 08:04:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Fri, 9 Apr 2021 09:03:46 -0600 Message-ID: To: Filip Skokan Cc: Mike Jones , oauth Content-Type: multipart/alternative; boundary="0000000000001597c005bf8b7a14" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 15:04:22 -0000 --0000000000001597c005bf8b7a14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For a hash of the access token in the proof JWT, discussion about whether to use the existing 'at_hash' claim or define a new 'ath' claim using only SHA-256 have been floating around since last year (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ attempts to describe the tradeoffs) without a clear consensus emerging for one over the other. I've been on the fence myself seeing the merits and drawbacks in both. In the absence of clear preference or an obvious 'best' option, the PR from Justin https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ with the SHA-256 only 'ath' claim was sufficient to make the decision. I'm not married to the 'ath' but don't want to change it back and forth. I would like to see something like consensus for making a change. And strong consensus has been elusive here. On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan wrote: > I would support that too but only if the way it's calculated would get > aligned as well. If it remains being a fixed sha256 of the whole token > rather than what at_hash does, using a new claim makes sense. > > Odesl=C3=A1no z iPhonu > > 9. 4. 2021 v 5:38, Mike Jones 40microsoft.com@dmarc.ietf.org>: > > =EF=BB=BF > > I had expected that we would use the existing member name =E2=80=9Cat_has= h=E2=80=9D for > the access token hash value, rather than the new name =E2=80=9Cath=E2=80= =9D, since there=E2=80=99s > already precedent for using it. Could we change to the standard name for > this when we publish the next version? > > > > Thanks, > > -- Mike > > > > *From:* OAuth *On Behalf Of * Brian Campbell > *Sent:* Wednesday, April 7, 2021 1:30 PM > *To:* oauth > *Subject:* [OAUTH-WG] Fwd: New Version Notification for > draft-ietf-oauth-dpop-03.txt > > > > A new revision of DPoP has been published. The doc history snippet is > copied below. The main change here is the addition of an access token has= h > claim. > > > -03 > > * Add an access token hash ("ath") claim to the DPoP proof when used > in conjunction with the presentation of an access token for > protected resource access > > * add Untrusted Code in the Client Context section to security > considerations > > * Editorial updates and fixes > > > > ---------- Forwarded message --------- > From: > Date: Wed, Apr 7, 2021 at 2:16 PM > Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt > > > > A new version of I-D, draft-ietf-oauth-dpop-03.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-ietf-oauth-dpop > Revision: 03 > Title: OAuth 2.0 Demonstrating Proof-of-Possession at the > Application Layer (DPoP) > Document date: 2021-04-07 > Group: oauth > Pages: 32 > URL: > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > Html: > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop= -03 > > Abstract: > This document describes a mechanism for sender-constraining OAuth 2.0 > tokens via a proof-of-possession mechanism on the application level. > This mechanism allows for the detection of replay attacks with access > and refresh tokens. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > *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 > > --=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._ --0000000000001597c005bf8b7a14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For a hash of the access token in the proof JWT, disc= ussion about whether to use the existing 'at_hash' claim or define = a new 'ath' claim using only SHA-256 have been floating around sinc= e last year (https://mailarchive.ietf.org/arch/= msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ attempts to describe the tradeof= fs) without a clear consensus emerging for one over the other. I've bee= n on the fence myself seeing the merits and drawbacks in both. In the absen= ce of clear preference or an obvious 'best' option, the PR from Jus= tin https://mailarchive.ietf.org/arch/msg/oauth= /C2G9cUetGSj6WnNcRdZE8wLR19I/ with the SHA-256 only 'ath' claim= was sufficient to make the decision.

I'm= not married to the 'ath' but don't want to change it back and = forth. I would like to see something like consensus for making a change. An= d strong consensus has been elusive here.





On Fri, Apr 9, 2021 = at 1:45 AM Filip Skokan <panva.ip@gmail.com> wrote:
I would support that too but o= nly if the way it's calculated would get aligned as well. If it remains= being a fixed sha256 of the whole token rather than what at_hash does, usi= ng a new claim makes sense.=C2=A0

Odesl=C3=A1no z= =C2=A0iPhonu

9. 4. 2021= v=C2=A05:38, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>= ;:

=EF= =BB=BF

I had expected th= at we would use the existing member name =E2=80=9Cat_hash=E2=80=9D for the = access token hash value, rather than the new name =E2=80=9Cath=E2=80=9D, si= nce there=E2=80=99s already precedent for using it.=C2=A0 Could we change t= o the standard name for this when we publish the next version?

=C2=A0<= /u>

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

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Brian Campbell
Sent: Wednesday, April 7, 2021 1:30 PM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oau= th-dpop-03.txt

=C2=A0

A new revision of DPoP has been published. The doc h= istory snippet is copied below. The main change here is the addition of an = access token hash claim.


=C2=A0 =C2=A0-03

=C2=A0 =C2=A0* =C2=A0Add an access token hash ("ath") claim to th= e DPoP proof when used
=C2=A0 =C2=A0 =C2=A0 in conjunction with the presentation of an access toke= n for
=C2=A0 =C2=A0 =C2=A0 protected resource access

=C2=A0 =C2=A0* =C2=A0add Untrusted Code in the Client Context section to se= curity
=C2=A0 =C2=A0 =C2=A0 considerations

=C2=A0 =C2=A0* =C2=A0Editorial updates and fixes

=C2=A0

---------- Forwarded message ---------
From: <int= ernet-drafts@ietf.org>
Date: Wed, Apr 7, 2021 at 2:16 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt



A new version of I-D, draft-ietf-oauth-dpop-03.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-dpop
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Demonstrating Proof-of-P= ossession at the Application Layer (DPoP)
Document date:=C2=A0 2021-04-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.iet= f.org/doc/draft-ietf-oauth-dpop/
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.= ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/dra= ft-ietf-oauth-dpop-03
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-03

Abstract:
=C2=A0 =C2=A0This document describes a mechanism for sender-constraining OA= uth 2.0
=C2=A0 =C2=A0tokens via a proof-of-possession mechanism on the application = level.
=C2=A0 =C2=A0This mechanism allows for the detection of replay attacks with= access
=C2=A0 =C2=A0and refresh tokens.




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

The IETF Secretariat


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=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/listi= nfo/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. --0000000000001597c005bf8b7a14-- From nobody Fri Apr 9 08:20:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A413A249C for ; Fri, 9 Apr 2021 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e-jSJ2711sf for ; Fri, 9 Apr 2021 08:20:25 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA473A2498 for ; Fri, 9 Apr 2021 08:20:25 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id q10so4151750pgj.2 for ; Fri, 09 Apr 2021 08:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=zw78c+Twti2IS7MynkhvJDhzHMjHGxfY+AopUNsc82I=; b=ti9FtRAu0Y5oEeNXhaIsS5DNX/bp66bX+GCmw7BQERenQST9beyqEueZfc8qMJnIBy rNfT6b5/kCsUgBYjfJtEv/f5ZkJ8on0SCkRwr91KiwcC/yW6az/NtqynmPf/wUxvXtXy WI4Q2eGqMqg1P0kiy2DllvJlv7Pby7Re+e2Papu2+cOhL+xkHQavFgNh72iqN/8of27V 9G+zFJcAAuyllYfm4duBwbXJu4qQTvMVH5tZeKEsgMGmw+qXGocQuXg8pXlyZATwOmt9 9FCoXzkblNOCIeeUQT/2+zUAFsompWDfSS3K/M7wxUGASVyw+wFRmleDS+xkoOYtxBlE BFcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=zw78c+Twti2IS7MynkhvJDhzHMjHGxfY+AopUNsc82I=; b=jKdy0eMEjgBhSdLbZrMz5tLo7IuTH7LnilZG6FQzm7VboUzF9IhvFB1yopajC4FFK6 2G5hW6i2ZkESIhUQVLQi3QAMcOD9J2VlK58eF2e/YCALnQDt7gIYNvde+9uMwKRO+xWu vWaxsVki/LUo2IZYNUZKUeQMFNOFbVFYr/16Mk/h8IkOU/3rNIUHxjkFShG5tafihcY3 hiURM/3eU5WNAAB0GGd68WfTnXCNgMuhReERe/CRjc1unxwa2WdcY1ioYPQxFlqEWIAf PryxYZPa9Ae5nY1Oh5XihRPImA3AlUD3DqXhOd3I54GQAvrPsicck88NSeb/T/gVKuV1 AVZw== X-Gm-Message-State: AOAM531mga/8HnsCGi0nfomp25nES+LT/3sXo/BXrTiIaLJspuHb65af ajBcBa/+Y5SnatEOAmOvr0IzRaeQdqsvPuEgWfA= X-Google-Smtp-Source: ABdhPJy5mowf/eB37Zo7fwXp9K7q2Lm5HVLjcAEMJM63hjJk7L1KbaOAQCL/eItn89OOagigmGCUgw== X-Received: by 2002:a63:9dcb:: with SMTP id i194mr13186060pgd.87.1617981623662; Fri, 09 Apr 2021 08:20:23 -0700 (PDT) Received: from [192.168.87.35] ([45.166.146.78]) by smtp.gmail.com with ESMTPSA id gd12sm2677129pjb.48.2021.04.09.08.20.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Apr 2021 08:20:23 -0700 (PDT) To: oauth@ietf.org References: From: John Bradley Message-ID: <73d17eaf-13e0-38e4-9cbf-56689ab11489@ve7jtb.com> Date: Fri, 9 Apr 2021 11:20:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E13B6F3D512D7D5CA3FC3F1B" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 15:20:30 -0000 This is a multi-part message in MIME format. --------------E13B6F3D512D7D5CA3FC3F1B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I think that using "auth" with the fixed full sha256 hash is fine. The original response size reasons for truncating the hash in the definition of at_hash are no longer really neccicary in current browsers and networks. A new claim is fine. On 4/9/2021 11:03 AM, Brian Campbell wrote: > For a hash of the access token in the proof JWT, discussion about > whether to use the existing 'at_hash' claim or define a new 'ath' > claim using only SHA-256 have been floating around since last year > (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ > > attempts to describe the tradeoffs) without a clear consensus emerging > for one over the other. I've been on the fence myself seeing the > merits and drawbacks in both. In the absence of clear preference or an > obvious 'best' option, the PR from Justin > https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ > > with the SHA-256 only 'ath' claim was sufficient to make the decision. > > I'm not married to the 'ath' but don't want to change it back and > forth. I would like to see something like consensus for making a > change. And strong consensus has been elusive here. > > > > > > > On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan > wrote: > > I would support that too but only if the way it's calculated would > get aligned as well. If it remains being a fixed sha256 of the > whole token rather than what at_hash does, using a new claim makes > sense.  > > Odesláno z iPhonu > >> 9. 4. 2021 v 5:38, Mike Jones >> > >: >> >>  >> >> I had expected that we would use the existing member name >> “at_hash†for the access token hash value, rather than the new >> name “athâ€, since there’s already precedent for using it.  Could >> we change to the standard name for this when we publish the next >> version? >> >>   >> >>                                                           Thanks, >> >>                                                           -- Mike >> >>   >> >> *From:* OAuth > > *On Behalf Of * Brian Campbell >> *Sent:* Wednesday, April 7, 2021 1:30 PM >> *To:* oauth > >> *Subject:* [OAUTH-WG] Fwd: New Version Notification for >> draft-ietf-oauth-dpop-03.txt >> >>   >> >> A new revision of DPoP has been published. The doc history >> snippet is copied below. The main change here is the addition of >> an access token hash claim. >> >> >>    -03 >> >>    *  Add an access token hash ("ath") claim to the DPoP proof >> when used >>       in conjunction with the presentation of an access token for >>       protected resource access >> >>    *  add Untrusted Code in the Client Context section to security >>       considerations >> >>    *  Editorial updates and fixes >> >>   >> >> ---------- Forwarded message --------- >> From: > >> Date: Wed, Apr 7, 2021 at 2:16 PM >> Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt >> >> >> >> A new version of I-D, draft-ietf-oauth-dpop-03.txt >> has been successfully submitted by Brian Campbell and posted to the >> IETF repository. >> >> Name:           draft-ietf-oauth-dpop >> Revision:       03 >> Title:          OAuth 2.0 Demonstrating Proof-of-Possession at >> the Application Layer (DPoP) >> Document date:  2021-04-07 >> Group:          oauth >> Pages:          32 >> URL:            >> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt >> >> Status:        >>  https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >> >> Html:          >>  https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html >> >> Htmlized:      >>  https://tools.ietf.org/html/draft-ietf-oauth-dpop-03 >> >> Diff:          >>  https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03 >> >> >> Abstract: >>    This document describes a mechanism for sender-constraining >> OAuth 2.0 >>    tokens via a proof-of-possession mechanism on the application >> level. >>    This mechanism allows for the detection of replay attacks with >> access >>    and refresh tokens. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at >> tools.ietf.org . >> >> The IETF Secretariat >> >> >> */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 >> > > > /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 --------------E13B6F3D512D7D5CA3FC3F1B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I think that using "auth" with the fixed full sha256 hash is fine.

The original response size reasons for truncating the hash in the definition of at_hash are no longer really neccicary in current browsers and networks.

A new claim is fine.

On 4/9/2021 11:03 AM, Brian Campbell wrote:
For a hash of the access token in the proof JWT, discussion about whether to use the existing 'at_hash' claim or define a new 'ath' claim using only SHA-256 have been floating around since last year (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ attempts to describe the tradeoffs) without a clear consensus emerging for one over the other. I've been on the fence myself seeing the merits and drawbacks in both. In the absence of clear preference or an obvious 'best' option, the PR from Justin https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ with the SHA-256 only 'ath' claim was sufficient to make the decision.

I'm not married to the 'ath' but don't want to change it back and forth. I would like to see something like consensus for making a change. And strong consensus has been elusive here.






On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan <panva.ip@gmail.com> wrote:
I would support that too but only if the way it's calculated would get aligned as well. If it remains being a fixed sha256 of the whole token rather than what at_hash does, using a new claim makes sense. 

Odesláno z iPhonu

9. 4. 2021 v 5:38, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:



I had expected that we would use the existing member name “at_hash†for the access token hash value, rather than the new name “athâ€, since there’s already precedent for using it.  Could we change to the standard name for this when we publish the next version?

 

                                                          Thanks,

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Wednesday, April 7, 2021 1:30 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt

 

A new revision of DPoP has been published. The doc history snippet is copied below. The main change here is the addition of an access token hash claim.


   -03

   *  Add an access token hash ("ath") claim to the DPoP proof when used
      in conjunction with the presentation of an access token for
      protected resource access

   *  add Untrusted Code in the Client Context section to security
      considerations

   *  Editorial updates and fixes

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Wed, Apr 7, 2021 at 2:16 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt



A new version of I-D, draft-ietf-oauth-dpop-03.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-ietf-oauth-dpop
Revision:       03
Title:          OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)
Document date:  2021-04-07
Group:          oauth
Pages:          32
URL:            https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Html:           https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




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

The IETF Secretariat


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

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
--------------E13B6F3D512D7D5CA3FC3F1B-- From nobody Fri Apr 9 08:38:22 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB963A2515 for ; Fri, 9 Apr 2021 08:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzFFtYRONMaI for ; Fri, 9 Apr 2021 08:38:16 -0700 (PDT) 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 401D33A2514 for ; Fri, 9 Apr 2021 08:38:16 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id c15so5082564ilj.1 for ; Fri, 09 Apr 2021 08:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LFg1sQw5K3k1xjtgdc5FkjSB8I6vPWnJBC3Lcl88sVA=; b=mEerOivfk5sjnBqKF2CwZoYW4eKsfYb2hqSM8nXgr5giJ+tDtyxTdfBH1iJiPAlv/l V295KbeSYroSSeDf2AXI7bcEVCqk6WDzoS/qWguaQSomJHq9zvMW2FcMt9BKoIxay3EI BmusKU+4I+uvWxq+LlA9gpbKhRnXYJsYlmItwI6Dd8PQjfGrF7+6JZryOgQuMC0JGYKJ UG1b8BrGivRYzKeBFfRZVfVrFbLgIt1wiK614+u5nrCuVyGWebgqiLj6V/lE2yHsXJFD DN1iymNCFWEnkzXYXvesZZtugQbPsR9a2Jzpx01VHehy1H6LwxMAYTd1fiSAnLT0eSGL j8XA== 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=LFg1sQw5K3k1xjtgdc5FkjSB8I6vPWnJBC3Lcl88sVA=; b=FgLI8+T0y02Pw4rX+Y92jbM49kMWqnLH0sz/UsXgwTxcTvkj/z08bDH+D/L+yYQw+h bta4+aUAtnjASGelgnZaQ8LsKZoZ1xrjBtKgtG4HPao/Maeu9P/PV5eiIw3y9TCKudLJ L5nl/D5WuXgLLS/tG/48mP/FnlSVHn7YOdRrhFuHw22up+l6Ey4TMqYU3/KysJVcbPOi BvuqWB/tDPylG3gqTrqMfzKdf7BwVJL3fe0GjIZtAWY0fykqs5ENpUgQrK8lzTWzhSco Jc5nuFQ+w7Nk0Z/egDNS54ao9a5rZH0zfNJfk5US4zRhxVlrvwazi7WplJvIdH+HfnW/ OUsQ== X-Gm-Message-State: AOAM53265F6cxnEIGtGEfz7roN4rcrip9UGDUZ1K//ti4ergjU487+xB W+WhuGorYj5pxZNnp3Pa85Ef7fVolzzNq83SUgqFNP/JUvY= X-Google-Smtp-Source: ABdhPJxr23dHxmSL8ghd14M5v5rEvd3QU+ji/OO3cj9AwXAQPL/osGJR24yzFnlxLiEn++R8C1qEt2oCxzyuq0OrR9s= X-Received: by 2002:a05:6e02:158c:: with SMTP id m12mr12330794ilu.121.1617982694430; Fri, 09 Apr 2021 08:38:14 -0700 (PDT) MIME-Version: 1.0 From: Savage Hood Date: Fri, 9 Apr 2021 10:38:00 -0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c11bdf05bf8bf3e0" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 15:38:19 -0000 --000000000000c11bdf05bf8bf3e0 Content-Type: text/plain; charset="UTF-8" "Re: Contents of OAuth digest..." --000000000000c11bdf05bf8bf3e0 Content-Type: text/html; charset="UTF-8"
"Re: Contents of OAuth digest..."
--000000000000c11bdf05bf8bf3e0-- From nobody Sat Apr 10 10:00:30 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E1C3A14EF for ; Sat, 10 Apr 2021 10:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJI3oKxYdFgk for ; Sat, 10 Apr 2021 10:00:25 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CAA3A14DD for ; Sat, 10 Apr 2021 10:00:25 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id r20so10148145ljk.4 for ; Sat, 10 Apr 2021 10:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KEsCL8R+9H6lxYyyynCa46/BreuGO6mT6h630rk+Y5E=; b=R2O9GqvJ9rY8Oi9ishb2lgzI2W/gJkZePMtQoI6LW/uZH9ymPFL4ehsHV69E20Hy8h WZbkyKFKMc/vNc0qFVmxj0b9y0fJqWENvZwVIkNzodvqIutaufcZ2F6MSwzvFl5sjttN ZW6oaEs9QXxCq0BoS4muLLp+zZyocSdWRBSqJ+DPibFJnexaSwRIzjYhr0pTbsZg/9X7 sBYMA0hgGyRBplRxxl5pj8oICcZttGPIeFqyd8Rbg62HMOIbhPYECSXtPIOVMhI4MIjx 9mp0mTmpd2HutvCfkqO75fbtDQZud60ppuohGhY/I4NcH9siWS+27ZV9M6E49Vk2IKF4 ejiQ== 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=KEsCL8R+9H6lxYyyynCa46/BreuGO6mT6h630rk+Y5E=; b=BHHIStLDrv73rqBCxpW3c7Rr8Ar3E+7nEny8PkQYT9TqZ7bxzgla6BfVWcaTMrZpbq BuFDV1Mo7+PBgnLcy620kF9S5lgLXtqdg8fIEYTgf/zTMPCERh6uxGNE0tqmHTpyNDlP OC6eTYeS3CuFNGB7XTg7TGmuTNJx7qpKWdem8l2KY3Cgtk3sW3qeazS2gCy5Z+FXi679 pqmOOdyzakd8KoKyvK9EfXOltkUKxRWQUUaLDOUpMz8XLPXY7OTzp51vkVz5r+0hwDXL NUuwks7LuE416d7g9pLb8zlVx+msT8gQHL9BDgd3zO4nXXnYZEHKuUCI4V47YEySkzzv Tiwg== X-Gm-Message-State: AOAM531P7vxMr2mIHnR3fP+/keriXpswvA73Y0q8EaMre1A0PdZcEp7F 3u2/XNbk3XJc0C8IsKyyyrA9Jd7RoJi1+Gp6iTF7sHy8 X-Google-Smtp-Source: ABdhPJw/pSP/2AE41B+E5Tiv02KxKh8d+0tCspMdmzLetPp7Lof6sxRjr6uli1z8f8Chmh5PZqAC7W6EOM2Gc2dadRk= X-Received: by 2002:a2e:5741:: with SMTP id r1mr8527065ljd.424.1618074022459; Sat, 10 Apr 2021 10:00:22 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sat, 10 Apr 2021 13:00:12 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000543c8805bfa137e5" Archived-At: Subject: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2021 17:00:30 -0000 --000000000000543c8805bfa137e5 Content-Type: text/plain; charset="UTF-8" All, The coming OAuth WG Interim meeting is this coming* Monday, April 12th, at 12:00 pm EDT.* The meeting will be focused on the *Security BCP *document: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ The following link has links to the slide and draft and will be used to capture the notes and attendees: https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both *Webex Meeting Link:* https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b Regards, Rifaat & Hannes --000000000000543c8805bfa137e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 All,

The coming OAuth WG Interim meeting is = this coming=C2=A0Monday, April 12th, at 12:00 pm EDT.
The m= eeting will be focused on the Security BCP document:

The following link has links to t= he slide and draft and will be used to capture the notes and attendees:

Webex Meeting Li= nk:
https://ietf.webex.com/ietf/j.php?= MTID=3Dm827c194bdcaa0077de44241f8001ce9b

Regards,
=C2=A0Rifaa= t & Hannes

--000000000000543c8805bfa137e5-- From nobody Mon Apr 12 04:36:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315D73A19CA for ; Mon, 12 Apr 2021 04:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 lJkqn6Ldi5uU for ; Mon, 12 Apr 2021 04:36:27 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428AE3A19C9 for ; Mon, 12 Apr 2021 04:36:27 -0700 (PDT) Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d88 with ME id rncN2400C2sDAeJ03ncN8f; Mon, 12 Apr 2021 13:36:25 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 12 Apr 2021 13:36:25 +0200 X-ME-IP: 90.26.9.133 To: Rifaat Shekh-Yusef , oauth References: From: Denis Message-ID: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> Date: Mon, 12 Apr 2021 13:36:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8610C36021BC948FD582E887" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 11:36:33 -0000 This is a multi-part message in MIME format. --------------8610C36021BC948FD582E887 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To all, In RFC 6819 OAuth 2.0 Security), it is assumed in section 2.2 (Attack Assumptions)that : * two of the three parties involved in the OAuth protocol may collude to mount an attack against the 3rd party. For example, the client and authorization server may be under control of an attacker and collude to trick a user to gain access to resources. These three parties are the client, the AS and the RS. The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed. This should be added in section 1 ( Introduction) The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states:     " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly". Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client. Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. This sub-section would need to include to other sub-sections: 4.16.1Attack Description 4.16.2Countermeasures The following text is a skeleton proposed for these subsections: *4.16****Collaboration attack between clients against a RS* The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server. *4.16.1****Attack Description* The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS. This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client. It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys. *4.16.2****Countermeasures* This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens. Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states: Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. This statement is correct but insufficient, since it does not say how resources servers cannot get confused. Section 6(Privacy Considerations) states:      This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information      for correlating incoming requests with data stored locally for the authenticated principal. This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match, the access token shall be discarded. In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims contained into the access token. Denis >   All, > > The coming OAuth WG Interim meeting is this coming* Monday, April > 12th, at 12:00 pm EDT.* > The meeting will be focused on the *Security BCP *document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > > > The following link has links to the slide and draft and will be used > to capture the notes and attendees: > https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both > > > *Webex Meeting Link:* > https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b > > > Regards, >  Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------8610C36021BC948FD582E887 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

To all,

In RFC 6819 OAuth 2.0 Security), it is assumed in section 2.2 (Attack Assumptions) that :

  • two of the three parties involved in the OAuth protocol may collude to mount an attack against the 3rd party.
    For example, the client and authorization server may be under control of an attacker and collude to trick a user to gain access to resources.

These three parties are the client, the AS and the RS.

The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed.

This should be added in section 1 ( Introduction)

The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states:

    " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly".

Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client
voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client.

Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

This sub-section would need to include to other sub-sections:

4.16.1  Attack Description
4.16.2  Countermeasures

The following text is a skeleton proposed for these subsections:

4.16  Collaboration attack between clients against a RS

The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server.

4.16.1  Attack Description

The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS.
This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client.

It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform
all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys.

4.16.2  Countermeasures

This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token
data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.

Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states:

   Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers.

This statement is correct but insufficient, since it does not say how resources servers cannot get confused.

Section 6  (Privacy Considerations) states:  

     This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information
     for correlating incoming requests with data stored locally for the authenticated principal.

This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage
user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either
a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match,
the access token shall be discarded.

In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims
contained into the access token.

Denis


  All,

The coming OAuth WG Interim meeting is this coming Monday, April 12th, at 12:00 pm EDT.
The meeting will be focused on the Security BCP document:

The following link has links to the slide and draft and will be used to capture the notes and attendees:

Webex Meeting Link:
https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b

Regards,
 Rifaat & Hannes 


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


--------------8610C36021BC948FD582E887-- From nobody Mon Apr 12 05:36:25 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7C3A1BFE for ; Mon, 12 Apr 2021 05:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 W4LBbqZWbnVZ for ; Mon, 12 Apr 2021 05:36:18 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B583A1C04 for ; Mon, 12 Apr 2021 05:36:18 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 1EEBC2465B for ; Mon, 12 Apr 2021 12:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618230975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wrR6XICKPuOFk/u6+QfGFIJ9xP2WcupWCaNqcsh1FJI=; b=A95IZMu8B5oIlBbsNlh9RowscRyXosymjkzUyLs9L6Y5BktZLO3qVk8nQkQISF28tDYD2G DLlCteitnXyZgloFS9knKoLfG09gLosMoBCtLXfWonxJvbSzK4/xs667qnOsCvz9BbCdYd 03ebFutXQx0z65zmvMsbGWGsNGM4XQM= To: oauth@ietf.org References: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> From: Daniel Fett Message-ID: <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> Date: Mon, 12 Apr 2021 14:36:14 +0200 MIME-Version: 1.0 In-Reply-To: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> Content-Type: multipart/alternative; boundary="------------1F800BD78CD29C1F6E7EC52D" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618230975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wrR6XICKPuOFk/u6+QfGFIJ9xP2WcupWCaNqcsh1FJI=; b=axBICptaGq9VMpIr2z/Ftz0jEOnCWyj31niFkY0Syh9jOBii/CshPcylTiSjMLpWHXXlyH dkCrKoxQZlbzZdjf09ilTBHkVJo1VnXLilQqkX9xmNgbpfCxNm0yJ54O7Kp81MKkMGHek6 v+4rMJY9igCbbImOqIPCwr9ygaA8bJQ= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1618230975; a=rsa-sha256; cv=none; b=ZREf5+sd9ixSDMNJgPqxKFltLd4cYXkkKM/G09Cf3vQZCLw6/NzHALe/A9As2QvfyzV4BT k1HF+k31QMy9x/TTLRdZyknQUKZL5vyzyB2VWcdajnW25UfGNG/068wperkKJWLUPPkE3p b68NtpVqVyGzggdkCe75fEMV6/bEPzU= 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] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 12:36:23 -0000 This is a multi-part message in MIME format. --------------1F800BD78CD29C1F6E7EC52D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Denis, I was awaiting your mail and I admire your perseverence with bringing this topic to our attention. To your points: Am 12.04.21 um 13:36 schrieb Denis: > The case where two clients collude to mount an attack against a RS is > not addressed. It now needs to be addressed. > > > This should be added in section 1 ( Introduction) > No. > The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) > clearly states: > >     " In the following, this attacker model is updated (...) to > include new types of attackers and to define the attacker model more > clearly". > > Section 3 should include the case of a collusion or a collaboration > attack between clients against a RS, where one of them is a legitimate > client > voluntarily "helping" another client to use or to request access > tokens that would normally "belong" to the legitimate client. > As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:     Attackers can collaborate to reach a common goal. It also says    Note that in this attacker model, an attacker (see A1) can be a RO or    act as one.  For example, an attacker can use his own browser to    replay tokens or authorization codes obtained by any of the attacks    described above at the client or RS. Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update. > > Finally, section 4 (Attacks and Mitigations) should include an > additional subsection, e.g. section 4.16, addressing the case of a > collaboration attack > between clients against a RS. > If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017. Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft. There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts. A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently, it is obvious that what you describe in the "attack" is possible. There is no expectation that OAuth would defend against this kind of thing, just as there is no mitigation against password sharing in password-based authentication. Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property. I therefore propose to proceed with the Security BCP without including this attack. -Daniel -- https://danielfett.de --------------1F800BD78CD29C1F6E7EC52D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Denis,

I was awaiting your mail and I admire your perseverence with bringing this topic to our attention.

To your points:

Am 12.04.21 um 13:36 schrieb Denis:
The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed.


This should be added in section 1 ( Introduction)

No.


The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states:

    " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly".

Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client
voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client.


As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.


Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017. Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently, it is obvious that what you describe in the "attack" is possible. There is no expectation that OAuth would defend against this kind of thing, just as there is no mitigation against password sharing in password-based authentication. Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including this attack.

-Daniel


-- 
https://danielfett.de
--------------1F800BD78CD29C1F6E7EC52D-- From nobody Mon Apr 12 05:58:10 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107193A1D2E for ; Mon, 12 Apr 2021 05:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 ZPpczwzkjP2i for ; Mon, 12 Apr 2021 05:57:57 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5F43A1CEF for ; Mon, 12 Apr 2021 05:57:54 -0700 (PDT) Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d40 with ME id roxo2400H2sDAeJ03oxoUC; Mon, 12 Apr 2021 14:57:52 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 12 Apr 2021 14:57:52 +0200 X-ME-IP: 90.26.9.133 To: Daniel Fett , oauth@ietf.org References: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> From: Denis Message-ID: <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> Date: Mon, 12 Apr 2021 14:57:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> Content-Type: multipart/alternative; boundary="------------2FC3F1096B586A20CDCB5179" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 12:58:08 -0000 This is a multi-part message in MIME format. --------------2FC3F1096B586A20CDCB5179 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Daniel, > Denis, > > I was awaiting your mail and I admire your perseverence with bringing > this topic to our attention. [Denis] I admire your perseverence with constantly refusing to include this attack. :-) > > To your points: > > Am 12.04.21 um 13:36 schrieb Denis: >> The case where two clients collude to mount an attack against a RS is >> not addressed. It now needs to be addressed. >> >> >> This should be added in section 1 ( Introduction) >> > No. > > >> The first sentence of section 3 (The Updated OAuth 2.0 Attacker >> Model) clearly states: >> >>     " In the following, this attacker model is updated (...) to >> include new types of attackers and to define the attacker model more >> clearly". >> >> Section 3 should include the case of a collusion or a collaboration >> attack between clients against a RS, where one of them is a >> legitimate client >> voluntarily "helping" another client to use or to request access >> tokens that would normally "belong" to the legitimate client. >> > > As I'm sure you have noticed, we have updated Section 3 following your > last input. It now explicitly says: > >     Attackers can collaborate to reach a common goal. > > It also says > >    Note that in this attacker model, an attacker (see A1) can be a RO or >    act as one.  For example, an attacker can use his own browser to >    replay tokens or authorization codes obtained by any of the attacks >    described above at the client or RS. > > Your scenario is therefore covered. It was already before, but that > was obviously too implicit, so we made it more clear with the recent > update. > [Denis] I don't believe that the scenario is covered with the above sentences. >> Finally, section 4 (Attacks and Mitigations) should include an >> additional subsection, e.g. section 4.16, addressing the case of a >> collaboration attack >> between clients against a RS. >> > If I remember correctly, you first presented this attack at the OAuth > Security Workshop in 2017. > Since then, it has been brought up countless times on this mailing > list, both with regards to the Security BCP as well as for the JWT > Token draft. > > There has been practically no positive resonance at the meeting 2017 > or here on the mailing list as to including this in either of the drafts. > > A number of reasons come to mind, but first and foremost, I think that > what you describe is not perceived as an attack, or, worded differently, > it is obvious that what you describe in the "attack" is possible. > [Denis] Here after comes the important sentence which is wrong: > *There is no expectation that OAuth would defend against this kind of > thin**g*, > just as there is no mitigation against password sharing in > password-based authentication. > [Denis] In the section 4.16.2 there is a clear proposal that explains how *"OAuth can successfully defend against this kind of thin**g"*. *So* *there **IS **a solution*. Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim. Such an access token would be transferable to anyone and the RS would not be able to identify the attack. I therefore propose to proceed with the Security BCP *with the inclusion of this attack*. > Even though the Security BCP attacker model includes the general > setting required for the attack, the attack does not violate an > expected security property. > > I therefore propose to proceed with the Security BCP without including > this attack. > > -Daniel > [Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it. Section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. This sub-section would need to include to other sub-sections: 4.16.1Attack Description 4.16.2Countermeasures The following text is a skeleton proposed for these subsections: *4.16****Collaboration attack between clients against a RS* The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server. *4.16.1****Attack Description* The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS. This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client. It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys. *4.16.2****Countermeasures* This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens. Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states: Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. This statement is correct but insufficient, since it does not say how resources servers cannot get confused. Section 6(Privacy Considerations) states:      This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information      for correlating incoming requests with data stored locally for the authenticated principal. This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match, the access token shall be discarded. In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims contained into the access token. Denis > > -- > https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2FC3F1096B586A20CDCB5179 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Daniel,

Denis,

I was awaiting your mail and I admire your perseverence with bringing this topic to our attention.

[Denis] I admire your perseverence with constantly refusing to include this attack. :-)

To your points:

Am 12.04.21 um 13:36 schrieb Denis:
The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed.


This should be added in section 1 ( Introduction)

No.


The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states:

    " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly".

Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client
voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client.


As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.

[Denis] I don't believe that the scenario is covered with the above sentences.


Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017.
Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible.

[Denis] Here after comes the important sentence which is wrong:


There is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in password-based authentication.

[Denis] In the section 4.16.2 there is a clear proposal that explains how "OAuth can successfully defend against this kind of thing". So there IS a solution.

Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim.
Such an access token would be transferable to anyone and the RS would not be able to identify the attack.

I therefore propose to proceed with the Security BCP with the inclusion of this attack.

Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including this attack.

-Daniel

[Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it.

Section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

This sub-section would need to include to other sub-sections:

4.16.1  Attack Description
4.16.2  Countermeasures

The following text is a skeleton proposed for these subsections:

4.16  Collaboration attack between clients against a RS

The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server.

4.16.1  Attack Description

The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS.
This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client.

It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform
all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys.

4.16.2  Countermeasures

This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token
data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.

Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states:

   Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers.

This statement is correct but insufficient, since it does not say how resources servers cannot get confused.

Section 6  (Privacy Considerations) states:  

     This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information
     for correlating incoming requests with data stored locally for the authenticated principal.

This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage
user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either
a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match,
the access token shall be discarded.

In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims
contained into the access token.

Denis


-- 
https://danielfett.de

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


--------------2FC3F1096B586A20CDCB5179-- From nobody Mon Apr 12 06:14:09 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4BE3A1D72 for ; Mon, 12 Apr 2021 06:14:07 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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=udelt-no.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 TJ2TNnQKjiMH for ; Mon, 12 Apr 2021 06:14:02 -0700 (PDT) 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 523503A1D6F for ; Mon, 12 Apr 2021 06:14:02 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id n138so21359274lfa.3 for ; Mon, 12 Apr 2021 06:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mFGp0uvILPCzOtz41BHv7TBs5ibj3CtxutiilZc4bQo=; b=xq0sqXbXVmzoDfioUtJMyBfhgsXk4kH0sGn0su1zk71tn6H/IOmnvhIBb2qVo01LND kGqzhCPUW6IyYZrfZ++FyUUMfFjXWB6jVx2WR1jJhU060sYvTztEGRFKNQOuXuhpyDNH 856WROlHOzdJeIj5L7cgnM9qyy7FHckxaOQZg8qED+HT0wzV0L760RPLCjYnn8aLa3kO jD+ZXoXcO9A7Zm6pvs6LDg4+TLjpsKXQl9WbNiyOeMhr8Z5iOidkULpNI9EVYp7Mw572 /aBfeQXkF355R426Fv7qzIur+K2z+yI8wFGNKAqa1m/oIQysT6RU4JJnofQNaYrvN13S 2V9w== 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=mFGp0uvILPCzOtz41BHv7TBs5ibj3CtxutiilZc4bQo=; b=d/n3uxykVeIboMm+xW2cBJVvLu6oPdgNjNv7nl2wzG8UFyqnHDNQ7DS8eZP56clVPV 0klbdAHiQGOwF262sl3lWeQP6AVr4mLRKKvQVinJ1c/fVhGQ19Af7X/Ortg03oi/cgGi fuMqaBaWRmVc9rY7P6WyLbbXPE7fQ1aW0VaE/MCY0c6ULNhbpahqoNoxWxNl4/IqZcR5 EixDziTk9A1NDukfO5aIO8jzqW1/+L16OyQSTNU7l+2aPcJu9/dXD+w1kxBgqf4NptvM 9FadVWUgiZTtXStBXPGoWGbmV8ej9x7qjOc/dkJ4q951nqpEZy+l7EF3MR5X6DbrPlWs wORA== X-Gm-Message-State: AOAM533oVqkiiKqjIgXzDXy681Na2wslgHwv7EIRFiz0d662IazcqSbe Yskog2zmFjRYt7qzJaVCXkhZ1LxAkkK3ZaXUUfnYZQ== X-Google-Smtp-Source: ABdhPJyVL+i9q7NucoeIhZ8TKgZ01U0KMeNM7CV9rlXGG1KpRppsrl10pSxKU93mIa2E0Vcn9im59mrlYMKE69VqoQQ= X-Received: by 2002:a05:6512:922:: with SMTP id f2mr7607977lft.171.1618233234652; Mon, 12 Apr 2021 06:13:54 -0700 (PDT) MIME-Version: 1.0 References: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> In-Reply-To: <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> From: Steinar Noem Date: Mon, 12 Apr 2021 15:13:43 +0200 Message-ID: To: Denis Cc: Daniel Fett , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000001d92da05bfc649fc" Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 13:14:08 -0000 --0000000000001d92da05bfc649fc Content-Type: text/plain; charset="UTF-8" Hi Denis, I don't understand the attack or the countermeasures you are describing completely - but that doesn't really matter. As far as I know OAuth doesn't require a specific token format, so the countermeasure you describe is based on an assumption that the AT is a JWT. If that's the case, isn't what you are describing as a countermeasure related and already covered by the work being done in the JWT spec for Access Tokens? https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12#page-5 S man. 12. apr. 2021 kl. 14:58 skrev Denis : > Hi Daniel, > > Denis, > > I was awaiting your mail and I admire your perseverence with bringing this > topic to our attention. > > > [Denis] I admire your perseverence with constantly refusing to include > this attack. :-) > > > To your points: > > Am 12.04.21 um 13:36 schrieb Denis: > > The case where two clients collude to mount an attack against a RS is not > addressed. It now needs to be addressed. > > > This should be added in section 1 ( Introduction) > > No. > > > The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) > clearly states: > > " In the following, this attacker model is updated (...) to include > new types of attackers and to define the attacker model more clearly". > > Section 3 should include the case of a collusion or a collaboration attack > between clients against a RS, where one of them is a legitimate client > voluntarily "helping" another client to use or to request access tokens > that would normally "belong" to the legitimate client. > > > As I'm sure you have noticed, we have updated Section 3 following your > last input. It now explicitly says: > > Attackers can collaborate to reach a common goal. > > It also says > > Note that in this attacker model, an attacker (see A1) can be a RO or > act as one. For example, an attacker can use his own browser to > replay tokens or authorization codes obtained by any of the attacks > described above at the client or RS. > > Your scenario is therefore covered. It was already before, but that was > obviously too implicit, so we made it more clear with the recent update. > > [Denis] I don't believe that the scenario is covered with the above > sentences. > > Finally, section 4 (Attacks and Mitigations) should include an additional > subsection, e.g. section 4.16, addressing the case of a collaboration > attack > between clients against a RS. > > If I remember correctly, you first presented this attack at the OAuth > Security Workshop in 2017. > Since then, it has been brought up countless times on this mailing list, > both with regards to the Security BCP as well as for the JWT Token draft. > > There has been practically no positive resonance at the meeting 2017 or > here on the mailing list as to including this in either of the drafts. > > A number of reasons come to mind, but first and foremost, I think that > what you describe is not perceived as an attack, or, worded differently, > it is obvious that what you describe in the "attack" is possible. > > [Denis] Here after comes the important sentence which is wrong: > > *There is no expectation that OAuth would defend against this kind of thin* > *g*, > just as there is no mitigation against password sharing in password-based > authentication. > > [Denis] In the section 4.16.2 there is a clear proposal that explains how * > "OAuth can successfully defend against this kind of thin**g"*. *So* *there > **IS **a solution*. > > Currently, when reading the text, an implementer might consider to deliver > an access token that contains a claim such as "older the 18" without any > "sub" or equivalent claim. > Such an access token would be transferable to anyone and the RS would not > be able to identify the attack. > > I therefore propose to proceed with the Security BCP *with the inclusion > of this attack*. > > Even though the Security BCP attacker model includes the general setting > required for the attack, the attack does not violate an expected security > property. > > I therefore propose to proceed with the Security BCP without including > this attack. > > -Daniel > > [Denis] Since you have deleted the remaining of my email, I copy it again. > If you respond to this email, please DO NOT delete it. > > Section 4 (Attacks and Mitigations) should include an additional > subsection, e.g. section 4.16, addressing the case of a collaboration > attack > between clients against a RS. > > This sub-section would need to include to other sub-sections: > > 4.16.1 Attack Description > 4.16.2 Countermeasures > > The following text is a skeleton proposed for these subsections: > > *4.16* *Collaboration attack between clients against a RS* > > The goal of the attack is for an illegitimate client to obtain an access > token from an authorization server with the help of a client of the > authorization server. > > *4.16.1* *Attack Description* > > The legitimate client performs in real time all the cryptographic > computations needed by the illegitimate client to get an access token and > to present it to a RS. > This attack is not a replay of a access token, but the use of a legitimate > access token by an illegitimate client with the complicity of the > legitimate client. > > It should be observed that protecting some private keys into a secure > element is ineffective to counter this kind of attack, since the legitimate > client can perform > all the computations needed by the illegitimate client, without the need > to know or to transfer the values of these private keys. > > *4.16.2* *Countermeasures* > > This attack may be countered by using a "sub" claim into the access token. > It should be observed that the "sub" claim is a REQUIRED claim in the JWT > access token > data structure. See section 2.2 from JSON Web Token (JWT) Profile for > OAuth 2.0 Access Tokens. > > Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for > OAuth 2.0 Access Tokens states: > > Authorization servers should prevent scenarios where clients can > affect the value of the "sub" claim in ways that could confuse resource > servers. > > This statement is correct but insufficient, since it does not say how > resources servers cannot get confused. > > Section 6 (Privacy Considerations) states: > > This profile mandates the presence of the "sub" claim in every JWT > access token, making it possible for resource servers to rely on that > information > for correlating incoming requests with data stored locally for the > authenticated principal. > > This statement is correct but is unclear. To be more precise, in order to > counter the collaboration attack between clients against a RS, the RS > should manage > user accounts associated either with a globally unique identifier or an > identifier specific to an AS-RS pair while the "sub" claim shall contain > either > a globally unique identifier or an identifier specific to an AS-RS pair > which shall be compared with the identifier of the user account. If there > is no match, > the access token shall be discarded. > > In this way, the access token will be linked to the user account of the > legitimate client and the illegitimate client cannot take advantage of the > claims > contained into the access token. > > Denis > > > -- https://danielfett.de > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --0000000000001d92da05bfc649fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis, I=C2=A0don't understand the attack or the c= ountermeasures you are describing completely - but that doesn't really matter.
=C2=A0
As far as = I know OAuth doesn't require a specific token format, so the countermea= sure you describe is based on an assumption that the AT is a JWT. If that&#= 39;s=C2=A0the case, isn't what you are describing as a countermeasure r= elated and already covered by the work being done in the JWT spec for Acces= s Tokens?


S=C2= =A0=C2=A0

man. 12. apr. 2021 kl. 14:58 skrev Denis <denis.ietf@free.fr>:
=20 =20 =20
Hi Daniel,

=20
Denis,

I was awaiting your mail and I admire your perseverence with bringing this topic to our attention.

[Denis] I admire your perseverence with constantly refusing to include this attack. :-)

To your points:

Am 12.04.21 um 13:36 schrieb Denis:
=20
The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed.


This should be added in section 1 ( Introduction)

No.


The first sentence of section 3 (Th= e Updated OAuth 2.0 Attacker Model) clearly states:

=C2=A0=C2=A0=C2=A0 " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly".

Section 3 should include the= case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client
voluntarily "helping" another client to use or to r= equest access tokens that would normally "belong" to the legitimate client.


As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

=C2=A0=C2=A0=C2=A0 Attackers can collaborate to reach a common goa= l.

It also says

=C2=A0=C2=A0 Note that in this attacker model, an attacker (see A1= ) can be a RO or
=C2=A0=C2=A0 act as one.=C2=A0 For example, an attacker can use his= own browser to
=C2=A0=C2=A0 replay tokens or authorization codes obtained by any o= f the attacks
=C2=A0=C2=A0 described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.

[Denis] I don't believe that the scenario is covered with the above sentences.


Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017.
Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible.

[Denis] Here after comes the important sentence which is wrong:


There is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in password-based authentication.

[Denis] In the section 4.16.2 there is a clear proposal that explains how "OAuth can successfully defend against this kin= d of thing". So there IS a solution.

Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim.
Such an access token would be transferable to anyone and the RS would not be able to identify the attack.

I therefore propose to proceed with the Security BCP with the inclusion of this attack.

Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including this attack.

-Daniel

[Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it.

Section 4 (Atta= cks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

This sub-section would need to include to other sub-sections:

4.16.1=C2=A0 Attack Description
4.16.2=C2=A0 Countermeasures

The following text is a skeleton proposed for these subsections:

4.16=C2=A0 Collaboration attack between clients against a RS

The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server.

4.16.1=C2=A0 Attack Description

The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS.
This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client.

It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform
all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys.

4.16.2=C2=A0 Countermeasures
This attack may be countered by using a "sub" claim int= o the access token. It should be observed that the "sub" clai= m is a REQUIRED claim in the JWT access token
data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.

Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states:

=C2=A0=C2=A0 Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource ser= vers.

This statement is correct but insufficient, since it does not say how resources servers cannot get confused.

Section 6=C2=A0 (Privacy Considerations) states:=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 This profile mandates the presence of the "sub" claim in eve= ry JWT access token, making it possible for resource servers to rely on that information
=C2=A0=C2=A0=C2= =A0=C2=A0 for correlating incoming requests with data stored locally for the authenticated principal.

This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage
user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either
a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match,
the access token shall be discarded.

In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims
contained into the access token.

Denis


--=20
https://danielfett.de

_______________________________________________
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


--
Vennlig hilsen=

Steinar Noem
Partner Udelt AS
Systemutvikler<= /div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
--0000000000001d92da05bfc649fc-- From nobody Mon Apr 12 07:00:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866763A1F54 for ; Mon, 12 Apr 2021 07:00:54 -0700 (PDT) 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 vivO7RrdULkT for ; Mon, 12 Apr 2021 07:00:50 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE603A1F51 for ; Mon, 12 Apr 2021 07:00:49 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 86FEB24817; Mon, 12 Apr 2021 14:00:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618236044; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EuXfzD+TgVxNa80/LDwklJl25W05qQS7sovsYXOqswM=; b=kPkpdwB6QTSzpxkTOmAq7I0V4XJR9na+REZ4J80XbJeTEVR+YtsjsHgMH70G+QS3PIaWmd D30lQuDgBCPYY0HcSegW99HZggequwHV5oK3U7C11G1m6P8F0wGn6S+aTKXtAyswVQR176 MDYHMrmCqkawHFK1Vya3BSVTQuvotfg= To: Denis , oauth@ietf.org References: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> From: Daniel Fett Message-ID: <9913e316-ab20-b9fa-bb59-15241d943622@danielfett.de> Date: Mon, 12 Apr 2021 16:00:43 +0200 MIME-Version: 1.0 In-Reply-To: <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> Content-Type: multipart/alternative; boundary="------------086EC9AE37B7AEAC2C998E1C" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618236044; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EuXfzD+TgVxNa80/LDwklJl25W05qQS7sovsYXOqswM=; b=P7i/SHGQrSw22jKJ/YewC1ikrwN1m7Nn5HJsUKD5jh1j67tNs4DY6+Lur5xIjQPtd4jd4f C8HVDN7cBFE873hGuM4aZdYo9KLZ+P+XFgMIBRgcfPeBN1WaCyYvHWmaXLTS5et0hbDT6y J2XzSrOeugVpWPFSdj0AmFdoh5fXSeM= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1618236044; a=rsa-sha256; cv=none; b=Rk5hc5ZZypBlg7KegI6Q5BzKhlnP5fAV7my4ecz9bsq2/Q2SWcDNK67lXc1/6zr0FXfQGT NYLV71uCmxeCNE9LyRc5hXNjrWzTl3qQ7o/RslQGhcRBGmlueX7F6g8Kjjgb4TnamHWN07 sbtWQVrIyCsDUtljDCoCIYyaRYeksio= 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] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 14:00:55 -0000 This is a multi-part message in MIME format. --------------086EC9AE37B7AEAC2C998E1C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Denis, Am 12.04.21 um 14:57 schrieb Denis: >> >>> The first sentence of section 3 (The Updated OAuth 2.0 Attacker >>> Model) clearly states: >>> >>>     " In the following, this attacker model is updated (...) to >>> include new types of attackers and to define the attacker model more >>> clearly". >>> >>> Section 3 should include the case of a collusion or a collaboration >>> attack between clients against a RS, where one of them is a >>> legitimate client >>> voluntarily "helping" another client to use or to request access >>> tokens that would normally "belong" to the legitimate client. >>> >> >> As I'm sure you have noticed, we have updated Section 3 following >> your last input. It now explicitly says: >> >>     Attackers can collaborate to reach a common goal. >> >> It also says >> >>    Note that in this attacker model, an attacker (see A1) can be a RO or >>    act as one.  For example, an attacker can use his own browser to >>    replay tokens or authorization codes obtained by any of the attacks >>    described above at the client or RS. >> >> Your scenario is therefore covered. It was already before, but that >> was obviously too implicit, so we made it more clear with the recent >> update. >> > [Denis] I don't believe that the scenario is covered with the above > sentences. > I don't understand. This is not about believing, it is written very clearly and conclusively in the text of the current draft. We've had this discussion before, and, although irrelevant for the meaning of the BCP itself, I would like to refer you again to the formal model in our research paper, which the BCP attacker model is based on. It has a *very* precise definition of the attacker model that does not leave room for interpretation. The natural-language description in the BCP, as usual, is more fuzzy than the formal definition, but both attacker models include clients cooperating. > >>> Finally, section 4 (Attacks and Mitigations) should include an >>> additional subsection, e.g. section 4.16, addressing the case of a >>> collaboration attack >>> between clients against a RS. >>> >> If I remember correctly, you first presented this attack at the OAuth >> Security Workshop in 2017. >> Since then, it has been brought up countless times on this mailing >> list, both with regards to the Security BCP as well as for the JWT >> Token draft. >> >> There has been practically no positive resonance at the meeting 2017 >> or here on the mailing list as to including this in either of the >> drafts. >> >> A number of reasons come to mind, but first and foremost, I think >> that what you describe is not perceived as an attack, or, worded >> differently, >> it is obvious that what you describe in the "attack" is possible. >> > [Denis] Here after comes the important sentence which is wrong: > > >> *There is no expectation that OAuth would defend against this kind of >> thin**g*, >> just as there is no mitigation against password sharing in >> password-based authentication. >> > [Denis] In the section 4.16.2 there is a clear proposal that explains > how *"OAuth can successfully defend against this kind of thin**g"*. > *So* *there **IS **a solution*. > I did not say that there is no solution. > > Currently, when reading the text, an implementer might consider to > deliver an access token that contains a claim such as "older the 18" > without any "sub" or equivalent claim. > Such an access token would be transferable to anyone and the RS would > not be able to identify the attack. > Your proposed solution does not enable an RS to identify the attack unless used together with some form of authentication way outside the scope of OAuth. Again, this also goes deeply into OIDC territory. > I therefore propose to proceed with the Security BCP *with the > inclusion of this attack*. > >> Even though the Security BCP attacker model includes the general >> setting required for the attack, the attack does not violate an >> expected security property. >> >> I therefore propose to proceed with the Security BCP without >> including this attack. >> >> -Daniel >> > [Denis] Since you have deleted the remaining of my email, I copy it > again. If you respond to this email, please DO NOT delete it. > I deleted the remainder of the mail as it was not relevant to my answer (see RFC1855, Section 3.1.1). Everybody can access your original mail on the mailing list. -Daniel -- https://danielfett.de --------------086EC9AE37B7AEAC2C998E1C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Denis,

Am 12.04.21 um 14:57 schrieb Denis:

The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states:

    " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly".

Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client
voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client.


As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.

[Denis] I don't believe that the scenario is covered with the above sentences.

I don't understand. This is not about believing, it is written very clearly and conclusively in the text of the current draft.

We've had this discussion before, and, although irrelevant for the meaning of the BCP itself, I would like to refer you again to the formal model in our research paper, which the BCP attacker model is based on. It has a *very* precise definition of the attacker model that does not leave room for interpretation. The natural-language description in the BCP, as usual, is more fuzzy than the formal definition, but both attacker models include clients cooperating.



Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017.
Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible.

[Denis] Here after comes the important sentence which is wrong:


There is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in password-based authentication.

[Denis] In the section 4.16.2 there is a clear proposal that explains how "OAuth can successfully defend against this kind of thing". So there IS a solution.

I did not say that there is no solution.

Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim.
Such an access token would be transferable to anyone and the RS would not be able to identify the attack.

Your proposed solution does not enable an RS to identify the attack unless used together with some form of authentication way outside the scope of OAuth.

Again, this also goes deeply into OIDC territory.

I therefore propose to proceed with the Security BCP with the inclusion of this attack.

Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including this attack.

-Daniel

[Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it.

I deleted the remainder of the mail as it was not relevant to my answer (see RFC1855, Section 3.1.1). Everybody can access your original mail on the mailing list.

-Daniel

-- 
https://danielfett.de
--------------086EC9AE37B7AEAC2C998E1C-- From nobody Mon Apr 12 07:56:35 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC293A211B for ; Mon, 12 Apr 2021 07:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 5VeoXNWwMdtl for ; Mon, 12 Apr 2021 07:56:30 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D2F3A1904 for ; Mon, 12 Apr 2021 07:56:26 -0700 (PDT) Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d52 with ME id rqwP240072sDAeJ03qwPy9; Mon, 12 Apr 2021 16:56:24 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 12 Apr 2021 16:56:24 +0200 X-ME-IP: 90.26.9.133 To: Daniel Fett , oauth@ietf.org References: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> <9913e316-ab20-b9fa-bb59-15241d943622@danielfett.de> From: Denis Message-ID: <3362fd52-fcd2-7f80-f7e4-5dcc1cceff73@free.fr> Date: Mon, 12 Apr 2021 16:56:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <9913e316-ab20-b9fa-bb59-15241d943622@danielfett.de> Content-Type: multipart/alternative; boundary="------------EB08CF4724D8CFEB1ACBD9F1" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 14:56:34 -0000 This is a multi-part message in MIME format. --------------EB08CF4724D8CFEB1ACBD9F1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi  Daniel, > (...) >>> >>> As I'm sure you have noticed, we have updated Section 3 following >>> your last input. It now explicitly says: >>> >>>     Attackers can collaborate to reach a common goal. >>> >>> It also says >>> >>>    Note that in this attacker model, an attacker (see A1) can be a RO or >>>    act as one.  For example, an attacker can use his own browser to >>>    replay tokens or authorization codes obtained by any of the attacks >>>    described above at the client or RS. >>> >>> Your scenario is therefore covered. It was already before, but that >>> was obviously too implicit, so we made it more clear with the recent >>> update. >>> >> [Denis] I don't believe that the scenario is covered with the above >> sentences. >> > I don't understand. This is not about believing, it is written very > clearly and conclusively in the text of the current draft. > > We've had this discussion before, and, although irrelevant for the > meaning of the BCP itself, I would like to refer you again to the > formal model in our research paper, which the BCP attacker model is > based on. It has a *very* precise definition of the attacker model > that does not leave room for interpretation. The natural-language > description in the BCP, as usual, is more fuzzy than the formal > definition, but both attacker models include clients cooperating. > [Denis]. Your very last sentence is finally using two magic words that are not present anywhere in the BCP: "*clients cooperating*". However, *clients collusion* or *clients collaboration* would be more accurate. > >>>> Finally, section 4 (Attacks and Mitigations) should include an >>>> additional subsection, e.g. section 4.16, addressing the case of a >>>> collaboration attack >>>> between clients against a RS. >>>> >>> If I remember correctly, you first presented this attack at the >>> OAuth Security Workshop in 2017. >>> Since then, it has been brought up countless times on this mailing >>> list, both with regards to the Security BCP as well as for the JWT >>> Token draft. >>> >>> There has been practically no positive resonance at the meeting 2017 >>> or here on the mailing list as to including this in either of the >>> drafts. >>> >>> A number of reasons come to mind, but first and foremost, I think >>> that what you describe is not perceived as an attack, or, worded >>> differently, >>> it is obvious that what you describe in the "attack" is possible. >>> >> [Denis] Here after comes the important sentence which is wrong: >> >> >>> *There is no expectation that OAuth would defend against this kind >>> of thin**g*, >>> just as there is no mitigation against password sharing in >>> password-based authentication. >>> >> [Denis] In the section 4.16.2 there is a clear proposal that explains >> how *"OAuth can successfully defend against this kind of thin**g"*. >> *So* *there **IS **a solution*. >> > I did not say that there is no solution. [Denis] Well, ... ask anybody else how he would interpret your statement. >> Currently, when reading the text, an implementer might consider to >> deliver an access token that contains a claim such as "older the 18" >> without any "sub" or equivalent claim. >> Such an access token would be transferable to anyone and the RS would >> not be able to identify the attack. >> > Your proposed solution does not enable an RS to identify the attack > unless used together with some form of authentication way outside the > scope of OAuth. > [Denis] I never said that there is "some form of authentication". The word "authentication" is not present in my text proposal. At the moment (/and this is a topic of its own that could be discussed later on/), a "sub" claim present in an access token is unrelated to any identifier used during an authentication exchange between an end-user and a RS. This means that your statement is incorrect. *"OAuth can successfully defend against this kind of thin**g" and, since countermeasures exist, they should be described. * > Again, this also goes deeply into OIDC territory. > >> I therefore propose to proceed with the Security BCP *with the >> inclusion of this attack*. >> >>> Even though the Security BCP attacker model includes the general >>> setting required for the attack, the attack does not violate an >>> expected security property. >>> >>> I therefore propose to proceed with the Security BCP without >>> including this attack. >>> >>> -Daniel >>> >> [Denis] Since you have deleted the remaining of my email, I copy it >> again. If you respond to this email, please DO NOT delete it. >> > I deleted the remainder of the mail as it was not relevant to my > answer (see RFC1855, Section 3.1.1). Everybody can access your > original mail on the mailing list. > > -Daniel > I re-established the remainder of the mail as it is relevant to *my *answer. However, reading it again, the "Attack description" does not refer to a JWT access token whereas it is not the case for the two other sub-sections. Nevertheless, these two sub-sections could be easily generalized to also address the case where JWT access tokens are not being used. Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. This sub-section would need to include to other sub-sections: 4.16.1Attack Description 4.16.2Countermeasures The following text is a skeleton proposed for these subsections: *4.16****Collaboration attack between clients against a RS* The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server. *4.16.1****Attack Description* The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS. This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client. It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys. *4.16.2****Countermeasures* This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens. Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states: Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. This statement is correct but insufficient, since it does not say how resources servers cannot get confused. Section 6(Privacy Considerations) states:      This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information      for correlating incoming requests with data stored locally for the authenticated principal. This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match, the access token shall be discarded. Denis PS. I re-read RFC1855, Section 3.1.1, but there is nothing in the Netiquette to delete or maintain some parts of a received message. > -- > https://danielfett.de --------------EB08CF4724D8CFEB1ACBD9F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi  Daniel,

(...)

As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.

[Denis] I don't believe that the scenario is covered with the above sentences.

I don't understand. This is not about believing, it is written very clearly and conclusively in the text of the current draft.

We've had this discussion before, and, although irrelevant for the meaning of the BCP itself, I would like to refer you again to the formal model in our research paper, which the BCP attacker model is based on. It has a *very* precise definition of the attacker model that does not leave room for interpretation. The natural-language description in the BCP, as usual, is more fuzzy than the formal definition, but both attacker models include clients cooperating.

[Denis]. Your very last sentence is finally using two magic words that are not present anywhere in the BCP: "clients cooperating".
However, clients collusion or clients collaboration would be more accurate.


Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017.
Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible.

[Denis] Here after comes the important sentence which is wrong:


There is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in password-based authentication.

[Denis] In the section 4.16.2 there is a clear proposal that explains how "OAuth can successfully defend against this kind of thing". So there IS a solution.

I did not say that there is no solution.

[Denis] Well, ... ask anybody else how he would interpret your statement.


Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim.
Such an access token would be transferable to anyone and the RS would not be able to identify the attack.

Your proposed solution does not enable an RS to identify the attack unless used together with some form of authentication way outside the scope of OAuth.

[Denis] I never said that there is "some form of authentication". The word "authentication" is not present in my text proposal.

At the moment (and this is a topic of its own that could be discussed later on), a "sub" claim present in an access token is unrelated to any identifier
used during an authentication exchange between an end-user and a RS.

This means that your statement is incorrect.

"OAuth can successfully defend against this kind of thing" and, since countermeasures exist, they should be described.

Again, this also goes deeply into OIDC territory.

I therefore propose to proceed with the Security BCP with the inclusion of this attack.

Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including this attack.

-Daniel

[Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it.

I deleted the remainder of the mail as it was not relevant to my answer (see RFC1855, Section 3.1.1). Everybody can access your original mail on the mailing list.

-Daniel

I re-established the remainder of the mail as it is relevant to my answer.

However, reading it again, the "Attack description" does not refer to a JWT access token whereas it is not the case for the two other sub-sections.
Nevertheless, these two sub-sections could be easily generalized to also address the case where JWT access tokens are not being used.

Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

This sub-section would need to include to other sub-sections:

4.16.1  Attack Description
4.16.2  Countermeasures

The following text is a skeleton proposed for these subsections:

4.16  Collaboration attack between clients against a RS

The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server.

4.16.1  Attack Description

The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS.
This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client.

It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform
all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys.

4.16.2  Countermeasures

This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token
data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.

Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states:

   Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers.

This statement is correct but insufficient, since it does not say how resources servers cannot get confused.

Section 6  (Privacy Considerations) states:  

     This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information
     for correlating incoming requests with data stored locally for the authenticated principal.

This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage
user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either
a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match,
the access token shall be discarded.

Denis

PS. I re-read RFC1855, Section 3.1.1, but there is nothing in the Netiquette to delete or maintain some parts of a received message.


-- 
https://danielfett.de


--------------EB08CF4724D8CFEB1ACBD9F1-- From nobody Mon Apr 12 08:09:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABDA3A21AD for ; Mon, 12 Apr 2021 08:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 sek1h6SH8n0F for ; Mon, 12 Apr 2021 08:08:59 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974023A21A6 for ; Mon, 12 Apr 2021 08:08:58 -0700 (PDT) Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d52 with ME id rr8w240042sDAeJ03r8wvq; Mon, 12 Apr 2021 17:08:56 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 12 Apr 2021 17:08:56 +0200 X-ME-IP: 90.26.9.133 To: Steinar Noem Cc: Daniel Fett , IETF oauth WG References: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> From: Denis Message-ID: <192154b5-3bb2-8db1-6869-2c30fc9800aa@free.fr> Date: Mon, 12 Apr 2021 17:08:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F52A7A60DE53775EA8646BBC" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 15:09:04 -0000 This is a multi-part message in MIME format. --------------F52A7A60DE53775EA8646BBC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Steinar, Please read first the response just posted to Daniel. > Hi Denis, I don't understand the attack or the countermeasures you are > describing completely - but that doesn't really matter. Since it does not matter, let us continue. :-) > As far as I know OAuth doesn't require a specific token format, so the > countermeasure you describe is based on an assumption that the AT is a > JWT. It is correct that the proposed text refers to countermeasures that are obtained using JWT access tokens. However, the countermeasures that are explained can easily be generalized to any form of access token. > If that's the case, isn't what you are describing as a countermeasure > related and already covered by the work being done in the JWT spec for > Access Tokens? I would like that, unfortunately this is not the case. I copied and pasted only the "good" sentences of the JWT spec for Access Token and purposely omitted to copied and paste the sentences that do not allow to protect against this attack. In particular that one: (...) if a solution requires preventing a resource server from correlating the principal’s activity within the resource itself,       the authorization server should assign different "sub" values for every JWT access token issued. In such a case, it would be rather easy to transmit an access token including a claim saying that the subject is over 18 without the RS being able to notice that the access token which is being presented is the result of a client collaboration attack. Denis > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12#page-5 > > > S > > man. 12. apr. 2021 kl. 14:58 skrev Denis >: > > Hi Daniel, > >> Denis, >> >> I was awaiting your mail and I admire your perseverence with >> bringing this topic to our attention. > > [Denis] I admire your perseverence with constantly refusing to > include this attack. :-) >> >> To your points: >> >> Am 12.04.21 um 13:36 schrieb Denis: >>> The case where two clients collude to mount an attack against a >>> RS is not addressed. It now needs to be addressed. >>> >>> >>> This should be added in section 1 ( Introduction) >>> >> No. >> >> >>> The first sentence of section 3 (The Updated OAuth 2.0 Attacker >>> Model) clearly states: >>> >>>     " In the following, this attacker model is updated (...) to >>> include new types of attackers and to define the attacker model >>> more clearly". >>> >>> Section 3 should include the case of a collusion or a >>> collaboration attack between clients against a RS, where one of >>> them is a legitimate client >>> voluntarily "helping" another client to use or to request access >>> tokens that would normally "belong" to the legitimate client. >>> >> >> As I'm sure you have noticed, we have updated Section 3 following >> your last input. It now explicitly says: >> >>     Attackers can collaborate to reach a common goal. >> >> It also says >> >>    Note that in this attacker model, an attacker (see A1) can be >> a RO or >>    act as one.  For example, an attacker can use his own browser to >>    replay tokens or authorization codes obtained by any of the >> attacks >>    described above at the client or RS. >> >> Your scenario is therefore covered. It was already before, but >> that was obviously too implicit, so we made it more clear with >> the recent update. >> > [Denis] I don't believe that the scenario is covered with the > above sentences. > > >>> Finally, section 4 (Attacks and Mitigations) should include an >>> additional subsection, e.g. section 4.16, addressing the case of >>> a collaboration attack >>> between clients against a RS. >>> >> If I remember correctly, you first presented this attack at the >> OAuth Security Workshop in 2017. >> Since then, it has been brought up countless times on this >> mailing list, both with regards to the Security BCP as well as >> for the JWT Token draft. >> >> There has been practically no positive resonance at the meeting >> 2017 or here on the mailing list as to including this in either >> of the drafts. >> >> A number of reasons come to mind, but first and foremost, I think >> that what you describe is not perceived as an attack, or, worded >> differently, >> it is obvious that what you describe in the "attack" is possible. >> > [Denis] Here after comes the important sentence which is wrong: > > >> *There is no expectation that OAuth would defend against this >> kind of thin**g*, >> just as there is no mitigation against password sharing in >> password-based authentication. >> > [Denis] In the section 4.16.2 there is a clear proposal that > explains how *"OAuth can successfully defend against this kind of > thin**g"*. *So* *there **IS **a solution*. > > Currently, when reading the text, an implementer might consider to > deliver an access token that contains a claim such as "older the > 18" without any "sub" or equivalent claim. > Such an access token would be transferable to anyone and the RS > would not be able to identify the attack. > > I therefore propose to proceed with the Security BCP *with the > inclusion of this attack*. > >> Even though the Security BCP attacker model includes the general >> setting required for the attack, the attack does not violate an >> expected security property. >> >> I therefore propose to proceed with the Security BCP without >> including this attack. >> >> -Daniel >> > [Denis] Since you have deleted the remaining of my email, I copy > it again. If you respond to this email, please DO NOT delete it. > > Section 4 (Attacks and Mitigations) should include an > additional subsection, e.g. section 4.16, addressing the case > of a collaboration attack > between clients against a RS. > > This sub-section would need to include to other sub-sections: > > 4.16.1Attack Description > 4.16.2Countermeasures > > The following text is a skeleton proposed for these subsections: > > *4.16****Collaboration attack between clients against a RS* > > The goal of the attack is for an illegitimate client to obtain > an access token from an authorization server with the help of > a client of the authorization server. > > *4.16.1****Attack Description* > > The legitimate client performs in real time all the > cryptographic computations needed by the illegitimate client > to get an access token and to present it to a RS. > This attack is not a replay of a access token, but the use of > a legitimate access token by an illegitimate client with the > complicity of the legitimate client. > > It should be observed that protecting some private keys into a > secure element is ineffective to counter this kind of attack, > since the legitimate client can perform > all the computations needed by the illegitimate client, > without the need to know or to transfer the values of these > private keys. > > *4.16.2****Countermeasures* > > This attack may be countered by using a "sub" claim into the > access token. It should be observed that the "sub" claim is a > REQUIRED claim in the JWT access token > data structure. See section 2.2 from JSON Web Token (JWT) > Profile for OAuth 2.0 Access Tokens. > > Section 5 (Security Considerations) from JSON Web Token (JWT) > Profile for OAuth 2.0 Access Tokens states: > > Authorization servers should prevent scenarios where clients > can affect the value of the "sub" claim in ways that could > confuse resource servers. > > This statement is correct but insufficient, since it does not > say how resources servers cannot get confused. > > Section 6(Privacy Considerations) states: > > This profile mandates the presence of the "sub" claim in every > JWT access token, making it possible for resource servers to > rely on that information >      for correlating incoming requests with data stored > locally for the authenticated principal. > > This statement is correct but is unclear. To be more precise, > in order to counter the collaboration attack between clients > against a RS, the RS should manage > user accounts associated either with a globally unique > identifier or an identifier specific to an AS-RS pair while > the "sub" claim shall contain either > a globally unique identifier or an identifier specific to an > AS-RS pair which shall be compared with the identifier of the > user account. If there is no match, > the access token shall be discarded. > > In this way, the access token will be linked to the user > account of the legitimate client and the illegitimate client > cannot take advantage of the claims > contained into the access token. > > Denis > >> >> -- >> https://danielfett.de >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > | steinar@udelt.no  | hei@udelt.no >   | +47 955 21 620 | www.udelt.no >  | --------------F52A7A60DE53775EA8646BBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Steinar,

Please read first the response just posted to Daniel.

Hi Denis, I don't understand the attack or the countermeasures you are describing completely - but that doesn't really matter.

Since it does not matter, let us continue. :-)

 
As far as I know OAuth doesn't require a specific token format, so the countermeasure you describe is based on an assumption that the AT is a JWT.

It is correct that the proposed text refers to countermeasures that are obtained using JWT access tokens.
However, the countermeasures that are explained can easily be generalized to any form of access token.


If that's the case, isn't what you are describing as a countermeasure related and already covered by the work being done in the JWT spec for Access Tokens?

I would like that, unfortunately this is not the case. I copied and pasted only the "good" sentences of the JWT spec for Access Token and purposely omitted
to copied and paste the sentences that do not allow to protect against this attack. In particular that one:

(...) if a solution requires preventing a resource server from correlating the principal’s activity within the resource itself,
      the authorization server should assign different "sub" values for every JWT access token issued.

In such a case, it would be rather easy to transmit an access token including a claim saying that the subject is over 18 without the RS being able to notice
that the access token which is being presented is the result of a client collaboration attack.

Denis







man. 12. apr. 2021 kl. 14:58 skrev Denis <denis.ietf@free.fr>:
Hi Daniel,

Denis,

I was awaiting your mail and I admire your perseverence with bringing this topic to our attention.

[Denis] I admire your perseverence with constantly refusing to include this attack. :-)

To your points:

Am 12.04.21 um 13:36 schrieb Denis:
The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed.


This should be added in section 1 ( Introduction)

No.


The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states:

    " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly".

Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client
voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client.


As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.

[Denis] I don't believe that the scenario is covered with the above sentences.


Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017.
Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible.

[Denis] Here after comes the important sentence which is wrong:


There is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in password-based authentication.

[Denis] In the section 4.16.2 there is a clear proposal that explains how "OAuth can successfully defend against this kind of thing". So there IS a solution.

Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim.
Such an access token would be transferable to anyone and the RS would not be able to identify the attack.

I therefore propose to proceed with the Security BCP with the inclusion of this attack.

Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including this attack.

-Daniel

[Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it.

Section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

This sub-section would need to include to other sub-sections:

4.16.1  Attack Description
4.16.2  Countermeasures

The following text is a skeleton proposed for these subsections:

4.16  Collaboration attack between clients against a RS

The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server.

4.16.1  Attack Description

The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS.
This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client.

It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform
all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys.

4.16.2  Countermeasures

This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token
data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.

Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states:

   Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers.

This statement is correct but insufficient, since it does not say how resources servers cannot get confused.

Section 6  (Privacy Considerations) states:  

     This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information
     for correlating incoming requests with data stored locally for the authenticated principal.

This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage
user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either
a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match,
the access token shall be discarded.

In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims
contained into the access token.

Denis


-- 
https://danielfett.de

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


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


--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
 
| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no | 


--------------F52A7A60DE53775EA8646BBC-- From nobody Mon Apr 12 08:19:22 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5763A2200 for ; Mon, 12 Apr 2021 08:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 ov5chf4t-u-p for ; Mon, 12 Apr 2021 08:19:16 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC8B3A21FC for ; Mon, 12 Apr 2021 08:19:16 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 88BD42481B; Mon, 12 Apr 2021 15:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618240753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h8IqALkpVt3Y2pOJoi868+CTQpRD52DxRn/toPhJHzU=; b=Anceoa8A1CCQeqtVzdgK+yIYFIMp4ieCiCApGs6vAKxq7foboH+n1b62USEvcHIr7+gyFJ ClTixY+CoxBx5aRgbNPLoeiLRw9MeYW0sQJwRYQE4Lh4GlZHyaKtaSW+/RRjp8UBM8Jdc9 6V3XalOR5s7FipIwnyisHL0xdKW70EY= To: Denis , oauth@ietf.org References: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr> <9913e316-ab20-b9fa-bb59-15241d943622@danielfett.de> <3362fd52-fcd2-7f80-f7e4-5dcc1cceff73@free.fr> From: Daniel Fett Message-ID: Date: Mon, 12 Apr 2021 17:19:12 +0200 MIME-Version: 1.0 In-Reply-To: <3362fd52-fcd2-7f80-f7e4-5dcc1cceff73@free.fr> Content-Type: multipart/alternative; boundary="------------D03C1BFCA894D1DD7E40C8C8" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618240753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h8IqALkpVt3Y2pOJoi868+CTQpRD52DxRn/toPhJHzU=; b=XfWg3/SLXmttCYDjt/cz8kAGH5GpyljKXUguj5jgYQFvykajUcwsgoIPSgPRW+Lu2CG3C7 GVtuFqXarFVugn9jCtV/xjcQz6EFxOz42rAMO+68R0XzkzZxLqJr6c5y1ZGuIlguxPVSDD UO3VZi7YwiLBP0E4Hi/H30vk9bcZyUk= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1618240753; a=rsa-sha256; cv=none; b=rV/AM68WKyipMdt1SlAk3s2llJJElUDOSeZU7xYPp39GJn4jlD0sU8LjaGHNA4wY+iejq1 ndlbXdRn210s5R+6J4goymuj2/O6EEKFGcAgtjGN1Jgto64nnMTBhF7XtUzJBStyEjN5o0 NjeexKI881iKexNUQ8D31zfdf60PpeI= 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] OAuth Interim Meeting - April 12 - Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 15:19:21 -0000 This is a multi-part message in MIME format. --------------D03C1BFCA894D1DD7E40C8C8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 12.04.21 um 16:56 schrieb Denis: > Hi  Daniel, > >> (...) >>>> >>>> As I'm sure you have noticed, we have updated Section 3 following >>>> your last input. It now explicitly says: >>>> >>>>     Attackers can collaborate to reach a common goal. >>>> >>>> It also says >>>> >>>>    Note that in this attacker model, an attacker (see A1) can be a >>>> RO or >>>>    act as one.  For example, an attacker can use his own browser to >>>>    replay tokens or authorization codes obtained by any of the attacks >>>>    described above at the client or RS. >>>> >>>> Your scenario is therefore covered. It was already before, but that >>>> was obviously too implicit, so we made it more clear with the >>>> recent update. >>>> >>> [Denis] I don't believe that the scenario is covered with the above >>> sentences. >>> >> I don't understand. This is not about believing, it is written very >> clearly and conclusively in the text of the current draft. >> >> We've had this discussion before, and, although irrelevant for the >> meaning of the BCP itself, I would like to refer you again to the >> formal model in our research paper, which the BCP attacker model is >> based on. It has a *very* precise definition of the attacker model >> that does not leave room for interpretation. The natural-language >> description in the BCP, as usual, is more fuzzy than the formal >> definition, but both attacker models include clients cooperating. >> > [Denis]. Your very last sentence is finally using two magic words that > are not present anywhere in the BCP: "*clients cooperating*". > However, *clients collusion* or *clients collaboration* would be more > accurate. > * (A1) Web Attackers that can set up and operate an arbitrary number of network endpoints including browsers and servers (except for the concrete RO, AS, and RS). Web attackers may set up web sites that are visited by the RO, operate their own user agents, and participate in the protocol. Web attackers may, in particular, operate OAuth clients that are registered at AS, and operate their own authorization and resource servers that can be used (in parallel) by the RO and other resource owners. (...) Attackers can collaborate to reach a common goal. >> >>>>> Finally, section 4 (Attacks and Mitigations) should include an >>>>> additional subsection, e.g. section 4.16, addressing the case of a >>>>> collaboration attack >>>>> between clients against a RS. >>>>> >>>> If I remember correctly, you first presented this attack at the >>>> OAuth Security Workshop in 2017. >>>> Since then, it has been brought up countless times on this mailing >>>> list, both with regards to the Security BCP as well as for the JWT >>>> Token draft. >>>> >>>> There has been practically no positive resonance at the meeting >>>> 2017 or here on the mailing list as to including this in either of >>>> the drafts. >>>> >>>> A number of reasons come to mind, but first and foremost, I think >>>> that what you describe is not perceived as an attack, or, worded >>>> differently, >>>> it is obvious that what you describe in the "attack" is possible. >>>> >>> [Denis] Here after comes the important sentence which is wrong: >>> >>> >>>> *There is no expectation that OAuth would defend against this kind >>>> of thin**g*, >>>> just as there is no mitigation against password sharing in >>>> password-based authentication. >>>> >>> [Denis] In the section 4.16.2 there is a clear proposal that >>> explains how *"OAuth can successfully defend against this kind of >>> thin**g"*. *So* *there **IS **a solution*. >>> >> I did not say that there is no solution. > > [Denis] Well, ... ask anybody else how he would interpret your statement. > Feel free. > >>> Currently, when reading the text, an implementer might consider to >>> deliver an access token that contains a claim such as "older the 18" >>> without any "sub" or equivalent claim. >>> Such an access token would be transferable to anyone and the RS >>> would not be able to identify the attack. >>> >> Your proposed solution does not enable an RS to identify the attack >> unless used together with some form of authentication way outside the >> scope of OAuth. >> > [Denis] I never said that there is "some form of authentication". The > word "authentication" is not present in my text proposal. > > At the moment (/and this is a topic of its own that could be discussed > later on/), a "sub" claim present in an access token is unrelated to > any identifier > used during an authentication exchange between an end-user and a RS. > It is very much possible that I did not understand your proposed solution correctly. Part of the problem is that a concise and concret attack description is missing (where end-user and clients are not conflated). If you could provide such a description, in the style of the mix-up attack description (i.e., using concrete protocol participants and protocol messages), that would greatly benefit the discussion. > PS. I re-read RFC1855, Section 3.1.1, but there is nothing in the > Netiquette to delete or maintain some parts of a received message. > - If you are sending a reply to a message or a posting be sure you summarize the original at the top of the message, or include just enough text of the original to give a context. This will make sure readers understand when they start to read your response. -- https://danielfett.de --------------D03C1BFCA894D1DD7E40C8C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 12.04.21 um 16:56 schrieb Denis:
Hi  Daniel,

(...)

As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update.

[Denis] I don't believe that the scenario is covered with the above sentences.

I don't understand. This is not about believing, it is written very clearly and conclusively in the text of the current draft.

We've had this discussion before, and, although irrelevant for the meaning of the BCP itself, I would like to refer you again to the formal model in our research paper, which the BCP attacker model is based on. It has a *very* precise definition of the attacker model that does not leave room for interpretation. The natural-language description in the BCP, as usual, is more fuzzy than the formal definition, but both attacker models include clients cooperating.

[Denis]. Your very last sentence is finally using two magic words that are not present anywhere in the BCP: "clients cooperating".
However, clients collusion or clients collaboration would be more accurate.



   *  (A1) Web Attackers that can set up and operate an arbitrary number
      of network endpoints including browsers and servers (except for
      the concrete RO, AS, and RS).  Web attackers may set up web sites
      that are visited by the RO, operate their own user agents, and
      participate in the protocol.

      Web attackers may, in particular, operate OAuth clients that are
      registered at AS, and operate their own authorization and resource
      servers that can be used (in parallel) by the RO and other
      resource owners.

(...)

      Attackers can collaborate to reach a common goal.


Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack
between clients against a RS.

If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017.
Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible.

[Denis] Here after comes the important sentence which is wrong:


There is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in password-based authentication.

[Denis] In the section 4.16.2 there is a clear proposal that explains how "OAuth can successfully defend against this kind of thing". So there IS a solution.

I did not say that there is no solution.

[Denis] Well, ... ask anybody else how he would interpret your statement.

Feel free.

Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim.
Such an access token would be transferable to anyone and the RS would not be able to identify the attack.

Your proposed solution does not enable an RS to identify the attack unless used together with some form of authentication way outside the scope of OAuth.

[Denis] I never said that there is "some form of authentication". The word "authentication" is not present in my text proposal.

At the moment (and this is a topic of its own that could be discussed later on), a "sub" claim present in an access token is unrelated to any identifier
used during an authentication exchange between an end-user and a RS.

It is very much possible that I did not understand your proposed solution correctly. Part of the problem is that a concise and concret attack description is missing (where end-user and clients are not conflated). If you could provide such a description, in the style of the mix-up attack description (i.e., using concrete protocol participants and protocol messages), that would greatly benefit the discussion.


PS. I re-read RFC1855, Section 3.1.1, but there is nothing in the Netiquette to delete or maintain some parts of a received message.

    - If you are sending a reply to a message or a posting be sure you
      summarize the original at the top of the message, or include just
      enough text of the original to give a context.  This will make
      sure readers understand when they start to read your response.


-- 
https://danielfett.de
--------------D03C1BFCA894D1DD7E40C8C8-- From nobody Mon Apr 12 08:28:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8F3A2266 for ; Mon, 12 Apr 2021 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng-2xc1RqB6X for ; Mon, 12 Apr 2021 08:28:14 -0700 (PDT) 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 1BB323A2264 for ; Mon, 12 Apr 2021 08:28:13 -0700 (PDT) Received: from [192.168.1.22] (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 13CFSBHN003312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Apr 2021 11:28:12 -0400 From: Justin Richer Message-Id: <36FA80E9-E383-40BB-9778-9A9E68B7D865@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_FE83B0DA-76B4-4AA5-945C-0DE6D4670CE2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 12 Apr 2021 11:28:11 -0400 In-Reply-To: <73d17eaf-13e0-38e4-9cbf-56689ab11489@ve7jtb.com> Cc: oauth To: John Bradley References: <73d17eaf-13e0-38e4-9cbf-56689ab11489@ve7jtb.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 15:28:20 -0000 --Apple-Mail=_FE83B0DA-76B4-4AA5-945C-0DE6D4670CE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As mentioned, my own intention for using a new claim =E2=80=9Cath=E2=80=9D= was to have a fixed hash size, not dependent on the surrounding JWS = envelopes that =E2=80=9Cat_hash=E2=80=9D is based on. I=E2=80=99ve = implemented both approaches on several platforms now, and I greatly = prefer the fixed hash.=20 It=E2=80=99s a new name because it is a new claim with new contents and = new semantics. =E2=80=94 Justin > On Apr 9, 2021, at 11:20 AM, John Bradley wrote: >=20 > I think that using "auth" with the fixed full sha256 hash is fine. >=20 > The original response size reasons for truncating the hash in the = definition of at_hash are no longer really neccicary in current browsers = and networks. >=20 > A new claim is fine. >=20 > On 4/9/2021 11:03 AM, Brian Campbell wrote: >> For a hash of the access token in the proof JWT, discussion about = whether to use the existing 'at_hash' claim or define a new 'ath' claim = using only SHA-256 have been floating around since last year = (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ = = attempts to describe the tradeoffs) without a clear consensus emerging = for one over the other. I've been on the fence myself seeing the merits = and drawbacks in both. In the absence of clear preference or an obvious = 'best' option, the PR from Justin = https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ = = with the SHA-256 only 'ath' claim was sufficient to make the decision.=20= >>=20 >> I'm not married to the 'ath' but don't want to change it back and = forth. I would like to see something like consensus for making a change. = And strong consensus has been elusive here.=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan > wrote: >> I would support that too but only if the way it's calculated would = get aligned as well. If it remains being a fixed sha256 of the whole = token rather than what at_hash does, using a new claim makes sense.=20 >>=20 >> Odesl=C3=A1no z iPhonu >>=20 >>> 9. 4. 2021 v 5:38, Mike Jones = >: >>>=20 >>> =EF=BB=BF >>> I had expected that we would use the existing member name = =E2=80=9Cat_hash=E2=80=9D for the access token hash value, rather than = the new name =E2=80=9Cath=E2=80=9D, since there=E2=80=99s already = precedent for using it. Could we change to the standard name for this = when we publish the next version? >>>=20 >>> =20 >>> Thanks, >>>=20 >>> -- Mike >>>=20 >>> =20 >>> From: OAuth > = On Behalf Of Brian Campbell >>> Sent: Wednesday, April 7, 2021 1:30 PM >>> To: oauth > >>> Subject: [OAUTH-WG] Fwd: New Version Notification for = draft-ietf-oauth-dpop-03.txt >>>=20 >>> =20 >>> A new revision of DPoP has been published. The doc history snippet = is copied below. The main change here is the addition of an access token = hash claim. >>>=20 >>>=20 >>> -03 >>>=20 >>> * Add an access token hash ("ath") claim to the DPoP proof when = used >>> in conjunction with the presentation of an access token for >>> protected resource access >>>=20 >>> * add Untrusted Code in the Client Context section to security >>> considerations >>>=20 >>> * Editorial updates and fixes >>>=20 >>> =20 >>> ---------- Forwarded message --------- >>> From: > >>> Date: Wed, Apr 7, 2021 at 2:16 PM >>> Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-oauth-dpop-03.txt >>> has been successfully submitted by Brian Campbell and posted to the >>> IETF repository. >>>=20 >>> Name: draft-ietf-oauth-dpop >>> Revision: 03 >>> Title: OAuth 2.0 Demonstrating Proof-of-Possession at the = Application Layer (DPoP) >>> Document date: 2021-04-07 >>> Group: oauth >>> Pages: 32 >>> URL: = https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ = >>> Html: = https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html = >>> Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-03 = >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-03 = >>>=20 >>> Abstract: >>> This document describes a mechanism for sender-constraining OAuth = 2.0 >>> tokens via a proof-of-possession mechanism on the application = level. >>> This mechanism allows for the detection of replay attacks with = access >>> and refresh tokens. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you.=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FE83B0DA-76B4-4AA5-945C-0DE6D4670CE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = mentioned, my own intention for using a new claim =E2=80=9Cath=E2=80=9D = was to have a fixed hash size, not dependent on the surrounding JWS = envelopes that =E2=80=9Cat_hash=E2=80=9D is based on. I=E2=80=99ve = implemented both approaches on several platforms now, and I greatly = prefer the fixed hash. 

It=E2=80=99s a new name because it is a new claim with new = contents and new semantics.

 =E2=80=94 Justin

On Apr = 9, 2021, at 11:20 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

=20

I think that using "auth" with the fixed = full sha256 hash is fine.

The original response size reasons for = truncating the hash in the definition of at_hash are no longer really neccicary in current browsers and networks.

A new claim is fine.

On 4/9/2021 11:03 AM, Brian Campbell wrote:
=20
For a hash of the access token in the proof JWT, = discussion about whether to use the existing 'at_hash' claim or define a new 'ath' claim using only SHA-256 have been floating around since last year (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAW= WlSuRDzXA/ attempts to describe the tradeoffs) without a clear consensus emerging for one over the other. I've been on the fence myself seeing the merits and drawbacks in both. In the absence of clear preference or an obvious 'best' option, the PR from Justin https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZ= E8wLR19I/ with the SHA-256 only 'ath' claim was sufficient to make the decision.

I'm not married to the 'ath' but don't want to = change it back and forth. I would like to see something like consensus for making a change. And strong consensus has been elusive here.






On Fri, Apr 9, 2021 at = 1:45 AM Filip Skokan <panva.ip@gmail.com> wrote:
I would support that too but only = if the way it's calculated would get aligned as well. If it remains being a fixed sha256 of the whole token rather than what at_hash does, using a new claim makes sense. 

Odesl=C3=A1no = z iPhonu

9. 4. 2021 = v 5:38, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:

=EF=BB=BF

I had expected that we would use the existing member name =E2=80=9Cat_hash=E2=80=9D for the access = token hash value, rather than the new name =E2=80=9Cath=E2=80=9D, = since there=E2=80=99s already precedent for using it.  Could we = change to the standard name for this when we publish the next version?

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Thanks,

          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Wednesday, April 7, 2021 = 1:30 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Fwd: New = Version Notification for draft-ietf-oauth-dpop-03.txt

 

A new = revision of DPoP has been published. The doc history snippet is copied below. The main change here is the addition of an access token hash claim.


=    -03

   *  Add an access token hash = ("ath") claim to the DPoP proof when used
      in conjunction with the = presentation of an access token for
      protected resource = access

   *  add Untrusted Code in the = Client Context section to security
      considerations
=
   *  Editorial updates and = fixes

 

---------- = Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Wed, Apr 7, 2021 at 2:16 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt



A new version of I-D, draft-ietf-oauth-dpop-03.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:          =  draft-ietf-oauth-dpop
Revision:       03
Title:          OAuth = 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)
Document date:  2021-04-07
Group:          = oauth
Pages:          32
URL:            = https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Html:          =  https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-03
Diff:          =  https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dpop-03

Abstract:
   This document describes a = mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession = mechanism on the application level.
   This mechanism allows for the = detection of replay attacks with access
   and refresh tokens.




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

The IETF Secretariat


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

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

= --Apple-Mail=_FE83B0DA-76B4-4AA5-945C-0DE6D4670CE2-- From nobody Mon Apr 12 08:45:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8146C3A234D for ; Mon, 12 Apr 2021 08:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOP64MXJN6GQ for ; Mon, 12 Apr 2021 08:45:44 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDFC3A234A for ; Mon, 12 Apr 2021 08:45:43 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id x21-20020a17090a5315b029012c4a622e4aso7331702pjh.2 for ; Mon, 12 Apr 2021 08:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=bWJxHBKQVVKZTAKqRKnq1MmSeIWm6d9BnVIWjSZe1E4=; b=nDIyze/4iiMg5be4o8/5auYdc+eZ4e7I9Y2CFmBf3BNmbShEdIIhBQWXURq3aSinMd ggX3jDwqje3iR6Hwj9YS6KHzr2aggmu8usvy4HJOwAt/L3CAqqrS5mciVmJC+6slAjdO yX/rB2FT93Zq9KZRZBJB2EGkYs1ZGa3DYYWPwtgmZd9SenH4Vz6su6Yu6X3qQ6CCM7/C sRre5aJ1+uzDM8dO5r7LVI1pYZYWbrOMogp5RcvCEBPbYmUDE0m2voAOxxS8hjHUjK4W kB/Yp2+CRt2ZoFc9IWEFE4cSiu05sgtFWxP+vHqLX/0PHHuYABglPXu/Xgayd4SXK+wt nwJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=bWJxHBKQVVKZTAKqRKnq1MmSeIWm6d9BnVIWjSZe1E4=; b=evorXDEMS+QMbsTgJcn5+JiD652Iv/s4P3y+ug3KL8pvEC8x1SVyL01fsTeT2aEa3E ClKc3X8Lj9nfPXY6ecJihVpfPKuv5uKDwydw6ToFzs823/TQ/0m6JwFS/lYnoVUmRchf S4igQUggzxujg5xvcGxQehwNtiesyUl12JEIyBNqGecGEnmDN6Q5E+AW6qpbJ1SDicpz UT+fcIviqQk1vCv8tPMq/XE24C3twWbrB47+mKimv+TBiHhdOA2jh+2Nf8ULu7O2jNz1 YZqAXLMfiVeFwTmnJ/cFIpCHpgT2Z8pwISNhWmnypgauBbKxH4JizWCFtb9fAxOe3kGE 2zbw== X-Gm-Message-State: AOAM533yk63J5oZ4zGJ1rBiRU+ia8j1lPHA1h8rTLx87k8JFnkFkSgpa J7QrPWAw1HnbyC8m/vBTWMVP4KeQxFi+I4FXasU= X-Google-Smtp-Source: ABdhPJxvA+hApLaG2zyM3ygYqPP7Ck+1OQM2/2jG54jm2o61goA1rwFOTDhC3czMgEXXx7/ka0NVPQ== X-Received: by 2002:a17:90a:e7cc:: with SMTP id kb12mr29142584pjb.31.1618242342145; Mon, 12 Apr 2021 08:45:42 -0700 (PDT) Received: from [192.168.87.35] ([45.166.146.78]) by smtp.gmail.com with ESMTPSA id x13sm11243974pgf.13.2021.04.12.08.45.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Apr 2021 08:45:41 -0700 (PDT) To: Justin Richer Cc: oauth References: <73d17eaf-13e0-38e4-9cbf-56689ab11489@ve7jtb.com> <36FA80E9-E383-40BB-9778-9A9E68B7D865@mit.edu> From: John Bradley Message-ID: <0b1b9a7f-5efc-72cb-ac2b-91b68f6a3d24@ve7jtb.com> Date: Mon, 12 Apr 2021 11:45:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <36FA80E9-E383-40BB-9778-9A9E68B7D865@mit.edu> Content-Type: multipart/alternative; boundary="------------F638B5E43171E574D31AAEEB" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 15:45:50 -0000 This is a multi-part message in MIME format. --------------F638B5E43171E574D31AAEEB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sorry I ment "ath" was fine as a claim name for that. I added the extra u. On 4/12/2021 11:28 AM, Justin Richer wrote: > As mentioned, my own intention for using a new claim “ath†was to have > a fixed hash size, not dependent on the surrounding JWS envelopes that > “at_hash†is based on. I’ve implemented both approaches on several > platforms now, and I greatly prefer the fixed hash.  > > It’s a new name because it is a new claim with new contents and new > semantics. > >  — Justin > >> On Apr 9, 2021, at 11:20 AM, John Bradley > > wrote: >> >> I think that using "auth" with the fixed full sha256 hash is fine. >> >> The original response size reasons for truncating the hash in the >> definition of at_hash are no longer really neccicary in current >> browsers and networks. >> >> A new claim is fine. >> >> On 4/9/2021 11:03 AM, Brian Campbell wrote: >>> For a hash of the access token in the proof JWT, discussion about >>> whether to use the existing 'at_hash' claim or define a new 'ath' >>> claim using only SHA-256 have been floating around since last year >>> (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ >>> >>> attempts to describe the tradeoffs) without a clear consensus >>> emerging for one over the other. I've been on the fence myself >>> seeing the merits and drawbacks in both. In the absence of clear >>> preference or an obvious 'best' option, the PR from Justin >>> https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ >>> >>> with the SHA-256 only 'ath' claim was sufficient to make the decision. >>> >>> I'm not married to the 'ath' but don't want to change it back and >>> forth. I would like to see something like consensus for making a >>> change. And strong consensus has been elusive here. >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan >> > wrote: >>> >>> I would support that too but only if the way it's calculated >>> would get aligned as well. If it remains being a fixed sha256 of >>> the whole token rather than what at_hash does, using a new claim >>> makes sense.  >>> >>> Odesláno z iPhonu >>> >>>> 9. 4. 2021 v 5:38, Mike Jones >>>> >>> >: >>>> >>>>  >>>> >>>> I had expected that we would use the existing member name >>>> “at_hash†for the access token hash value, rather than the new >>>> name “athâ€, since there’s already precedent for using it.  >>>> Could we change to the standard name for this when we publish >>>> the next version? >>>> >>>>   >>>> >>>>                                                           Thanks, >>>> >>>>                                                           -- Mike >>>> >>>>   >>>> >>>> *From:* OAuth >>> > *On Behalf Of * Brian Campbell >>>> *Sent:* Wednesday, April 7, 2021 1:30 PM >>>> *To:* oauth > >>>> *Subject:* [OAUTH-WG] Fwd: New Version Notification for >>>> draft-ietf-oauth-dpop-03.txt >>>> >>>>   >>>> >>>> A new revision of DPoP has been published. The doc history >>>> snippet is copied below. The main change here is the addition >>>> of an access token hash claim. >>>> >>>> >>>>    -03 >>>> >>>>    *  Add an access token hash ("ath") claim to the DPoP proof >>>> when used >>>>       in conjunction with the presentation of an access token for >>>>       protected resource access >>>> >>>>    *  add Untrusted Code in the Client Context section to security >>>>       considerations >>>> >>>>    *  Editorial updates and fixes >>>> >>>>   >>>> >>>> ---------- Forwarded message --------- >>>> From: > >>>> Date: Wed, Apr 7, 2021 at 2:16 PM >>>> Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt >>>> >>>> >>>> >>>> A new version of I-D, draft-ietf-oauth-dpop-03.txt >>>> has been successfully submitted by Brian Campbell and posted to the >>>> IETF repository. >>>> >>>> Name:           draft-ietf-oauth-dpop >>>> Revision:       03 >>>> Title:          OAuth 2.0 Demonstrating Proof-of-Possession at >>>> the Application Layer (DPoP) >>>> Document date:  2021-04-07 >>>> Group:          oauth >>>> Pages:          32 >>>> URL:            >>>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt >>>> >>>> Status:        >>>>  https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >>>> >>>> Html:          >>>>  https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html >>>> >>>> Htmlized:      >>>>  https://tools.ietf.org/html/draft-ietf-oauth-dpop-03 >>>> >>>> Diff:          >>>>  https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03 >>>> >>>> >>>> Abstract: >>>>    This document describes a mechanism for sender-constraining >>>> OAuth 2.0 >>>>    tokens via a proof-of-possession mechanism on the >>>> application level. >>>>    This mechanism allows for the detection of replay attacks >>>> with access >>>>    and refresh tokens. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time >>>> of submission >>>> until the htmlized version and diff are available at >>>> tools.ietf.org . >>>> >>>> The IETF Secretariat >>>> >>>> >>>> */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 >>>> >>> >>> >>> /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 > --------------F638B5E43171E574D31AAEEB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Sorry I ment "ath" was fine as a claim name for that. I added the extra u.

On 4/12/2021 11:28 AM, Justin Richer wrote:
As mentioned, my own intention for using a new claim “ath†was to have a fixed hash size, not dependent on the surrounding JWS envelopes that “at_hash†is based on. I’ve implemented both approaches on several platforms now, and I greatly prefer the fixed hash. 

It’s a new name because it is a new claim with new contents and new semantics.

 — Justin

On Apr 9, 2021, at 11:20 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I think that using "auth" with the fixed full sha256 hash is fine.

The original response size reasons for truncating the hash in the definition of at_hash are no longer really neccicary in current browsers and networks.

A new claim is fine.

On 4/9/2021 11:03 AM, Brian Campbell wrote:
For a hash of the access token in the proof JWT, discussion about whether to use the existing 'at_hash' claim or define a new 'ath' claim using only SHA-256 have been floating around since last year (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ attempts to describe the tradeoffs) without a clear consensus emerging for one over the other. I've been on the fence myself seeing the merits and drawbacks in both. In the absence of clear preference or an obvious 'best' option, the PR from Justin https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ with the SHA-256 only 'ath' claim was sufficient to make the decision.

I'm not married to the 'ath' but don't want to change it back and forth. I would like to see something like consensus for making a change. And strong consensus has been elusive here.






On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan <panva.ip@gmail.com> wrote:
I would support that too but only if the way it's calculated would get aligned as well. If it remains being a fixed sha256 of the whole token rather than what at_hash does, using a new claim makes sense. 

Odesláno z iPhonu

9. 4. 2021 v 5:38, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:



I had expected that we would use the existing member name “at_hash†for the access token hash value, rather than the new name “athâ€, since there’s already precedent for using it.  Could we change to the standard name for this when we publish the next version?

 

                                                          Thanks,

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Wednesday, April 7, 2021 1:30 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt

 

A new revision of DPoP has been published. The doc history snippet is copied below. The main change here is the addition of an access token hash claim.


   -03

   *  Add an access token hash ("ath") claim to the DPoP proof when used
      in conjunction with the presentation of an access token for
      protected resource access

   *  add Untrusted Code in the Client Context section to security
      considerations

   *  Editorial updates and fixes

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Wed, Apr 7, 2021 at 2:16 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt



A new version of I-D, draft-ietf-oauth-dpop-03.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-ietf-oauth-dpop
Revision:       03
Title:          OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)
Document date:  2021-04-07
Group:          oauth
Pages:          32
URL:            https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Html:           https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-dpop-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




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

The IETF Secretariat


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

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

--------------F638B5E43171E574D31AAEEB-- From nobody Mon Apr 12 13:09:49 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242973A0553 for ; Mon, 12 Apr 2021 13:09:48 -0700 (PDT) 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 POSZNFiJuMnH for ; Mon, 12 Apr 2021 13:09:43 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BF03A045E for ; Mon, 12 Apr 2021 13:09:43 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id r22so6157745ljc.5 for ; Mon, 12 Apr 2021 13:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0zpPVZ98qqEA9z3V7OMT1JqHvXsfiCcBKAmBeNILCQw=; b=PGbs6zwqLnLw9Lsfd8a6IKpjR7YPxSqDYz6N1pIBRA6rpOLpS3E0Yf1TArxrIfguRj +Lv35TLWW+DhB5oaY8078AbsJtsCEXUfBO83v7zdNqaZv2i4kbdEUErHjufg3u68x1Qt sboLVnGr+Lkqvp9GfqOk/clcKVPDpRXI31zu4LVWewd5kB9g4E+oyAa45o+tEew2gXA5 8Un/+YAcRes3tNw1x+DDuGSBB6ZVPjmBG6Lsl22nD9qBIcS9KQkf3F+1D3SRseoPSior 0UHTHO4iJBy8fL7Nn+SPFgljR3w3lgT4FQjTkgtBPfof3/glAAoMrj3SpOVgVQk+tkI7 UlRQ== 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=0zpPVZ98qqEA9z3V7OMT1JqHvXsfiCcBKAmBeNILCQw=; b=WxkJEemKiNy9S45V3QGuwNPWmo3xedaWIKBGjEDUOk4DGklpO8m7tyoRGUcjaQa/Jt qH6fCU5zvELapXRZZT9hhCXhpmI+zSWzaipLi3+0+9wzoRbDzVtfKhZqiaPNsAnD7yx8 ZUaWnUFvgmXbUgEgRLWcDRrDpX8Plm2MZOGJq/Ugd+CCVtZ1uy9Qb72WGveUd5sbzQ9v kvlqtUkUT9wSATW7NKsg+D+YpU3HAaJwdQE7nlO6EdjMoHjAYsWlcUV1jj9qY9Yc+RY1 ttPKuRogPrR8RvuDh7ruap3TtF21MutJKxJqZki90ShkBpbHV1QV7m3dBdIT4fePZqhf pKNw== X-Gm-Message-State: AOAM532On5JNdfMte7RmFF7Ukfw6cml5AvhHzBeMWlFzjbfsXwR+k91g kYVdChIqgtkb6C3T/u8hOaleJO0ZpZTBlLqJuj+NhF+mnR4= X-Google-Smtp-Source: ABdhPJwXOFhEfjLbwMXatQjZNXbTt/JOd/rHSyG3xX0+tMaXDL8SEp7X5OhfRjP3CusCDx2wKDnTdN3xLKVZtynNfPI= X-Received: by 2002:a05:651c:106c:: with SMTP id y12mr11933374ljm.458.1618258180809; Mon, 12 Apr 2021 13:09:40 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 12 Apr 2021 16:09:29 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000005a7ef05bfcc184f" Archived-At: Subject: [OAUTH-WG] April 12th Interim Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 20:09:48 -0000 --00000000000005a7ef05bfcc184f Content-Type: text/plain; charset="UTF-8" All, Take a look at the following links for the April 12th interim meeting minutes: https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-05-oauth https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-05-202104121200/ Thanks to *Dick Hardt *for taking these notes. Regards, Rifaat & Hannes --00000000000005a7ef05bfcc184f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Take a look at the following links= for the April 12th interim meeting minutes:

Thanks to=C2=A0Dick Hardt=C2=A0for taking these notes.

Regards,
=C2= =A0Rifaat & Hannes
--00000000000005a7ef05bfcc184f-- From nobody Mon Apr 12 23:50:57 2021 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 8EE3A3A0CC4; Mon, 12 Apr 2021 23:50:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161829665543.5849.8337548825848209549@ietfa.amsl.com> Date: Mon, 12 Apr 2021 23:50:55 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-07.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, 13 Apr 2021 06:50:56 -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-07.txt Pages : 22 Date : 2021-04-12 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 call to the authorization endpoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-par-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-07 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 Apr 13 07:34:29 2021 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 6324E3A197C; Tue, 13 Apr 2021 07:34:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161832446333.27988.15821920693407061318@ietfa.amsl.com> Date: Tue, 13 Apr 2021 07:34:23 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-18.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, 13 Apr 2021 14:34:23 -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-18.txt Pages : 53 Date : 2021-04-13 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 is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-18.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-18 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 Apr 13 07:47:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D211A3A19EE for ; Tue, 13 Apr 2021 07:47:35 -0700 (PDT) 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 q4dyMQeRi5zN for ; Tue, 13 Apr 2021 07:47:31 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7953E3A19EB for ; Tue, 13 Apr 2021 07:47:31 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 9ED7624A2E for ; Tue, 13 Apr 2021 14:47:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618325248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NrfgzjeyBCIQekVJ1KcuKAXmD4zdrfdSs2Xb/tfa0fU=; b=vkuyqhCXHVOj+h4odFc9FeYkyCRo2KR9ut+gVcm0b70TS0Yg4rn3yfDVKaxhQuEdk1A9O3 SuVK/dLmVZBx0u0jB3y9JvLRui5hjmC5J249TfvsyVLP5NTo2WExxBgsLd8Cp8ObRWassj 4nPGkxeKKKF2o58/SZa7a4XCUGJcsUw= To: oauth@ietf.org References: <161832446333.27988.15821920693407061318@ietfa.amsl.com> From: Daniel Fett Message-ID: <91601a0c-733a-f113-dad5-5232629c337c@danielfett.de> Date: Tue, 13 Apr 2021 16:47:28 +0200 MIME-Version: 1.0 In-Reply-To: <161832446333.27988.15821920693407061318@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------43CB1FDB503F2FD18F45564A" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618325248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NrfgzjeyBCIQekVJ1KcuKAXmD4zdrfdSs2Xb/tfa0fU=; b=GiRRoN5CO+3k4wF8i47i/ybrhQSgeFLiOZJCizWKqa1sOk+ljLJXnXjyaFlsR4jjXMHYZ7 cuRDJu6wiXhsOGb7x9qrsziivHU6+OFJPpait1vX1VWEcE5jdBKCeesZlLVbn3cyz6bjQZ V3AKJWLmG9WgZgPHNKf/G29VG47oPK0= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1618325248; a=rsa-sha256; cv=none; b=hgxDYVK5tujugO8rjZ87ejYoSkOY/KoKOYaODvNTYQH8zSmgbpSlJ915PUuaNzl5Bwspfz puiD8bTAzpbskvK4PI+7iRwS8snl3l78lRJ9cIhQjozuS5O7RdU/qReuusabJshESvnBft eOgtd5r7Iao4KM7hSETnmfpVO7duufs= 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] I-D Action: draft-ietf-oauth-security-topics-18.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 14:47:36 -0000 This is a multi-part message in MIME format. --------------43CB1FDB503F2FD18F45564A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, This version includes some minor editorial fixes and a new wording for disallowing insecure redirect URIs, as discussed on yesterday's call. I would kindly ask the chairs to start a WGLC on this version. Given the nature of a Best Current Practice document and the relatively broad topic, there will always be more things to add to this document. In order to deliver this document, it would be great if we could come to the consensus that after this WGLC any attacks, mitigations, and security topics not covered in draft-ietf-oauth-security-topics-18 go into a future update of the BCP. Exceptions would be grave oversights in proposed mitigations, factual errors, and anything coming up in the IETF process after WGLC, of course. Cheers, Daniel Am 13.04.21 um 16:34 schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-18.txt > Pages : 53 > Date : 2021-04-13 > > 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 is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-18.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-18 > > > 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 -- https://danielfett.de --------------43CB1FDB503F2FD18F45564A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi all,

This version includes some minor editorial fixes and a new wording for disallowing insecure redirect URIs, as discussed on yesterday's call.

I would kindly ask the chairs to start a WGLC on this version.

Given the nature of a Best Current Practice document and the relatively broad topic, there will always be more things to add to this document. In order to deliver this document, it would be great if we could come to the consensus that after this WGLC any attacks, mitigations, and security topics not covered in draft-ietf-oauth-security-topics-18 go into a future update of the BCP. Exceptions would be grave oversights in proposed mitigations, factual errors, and anything coming up in the IETF process after WGLC, of course.

Cheers,
Daniel

Am 13.04.21 um 16:34 schrieb internet-drafts@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-18.txt
	Pages           : 53
	Date            : 2021-04-13

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 is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-18.html

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


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



-- 
https://danielfett.de
--------------43CB1FDB503F2FD18F45564A-- From nobody Wed Apr 14 00:18:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404653A1121 for ; Wed, 14 Apr 2021 00:18:54 -0700 (PDT) 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHf8h2IpjZrq for ; Wed, 14 Apr 2021 00:18:49 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0: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 809DB3A1117 for ; Wed, 14 Apr 2021 00:18:49 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id l76so13763416pga.6 for ; Wed, 14 Apr 2021 00:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=TT44O72YjBoTNTLMhQoUQqJy8A4obPOqSv2JDiNjE3I=; b=S6ddssb/1agvBeXWMQqhlHFRftE+HOSDMNLF3EJPNhTYzhrMjw4BF/wCziLPJxpz+0 1BlcjJ7riqqvsxZtHSjODSJxq2qiPaWbWQQEre0IDyRerGFkMsrEMWoBdsHNcJktD48D 66fK44yk9lYDBOaeZY5PWMkslRMNSNlC5/lpIDCzXKoI3R61gDOZnQBSOzvflR0vVqWN 7LTr1JZrVuqPHAIqkCYHxM4D5NxAn0Nph9+jU+HoxIho5bsYHTyvN9njn1l9fTT8maND uLaS/pog3t3OqeTClkLFPrLcSLf5pCS9y043LOY4kEDby6X0c9li4g7xCTrmqViKgNRB TrMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=TT44O72YjBoTNTLMhQoUQqJy8A4obPOqSv2JDiNjE3I=; b=Uy9wTlrsJROyitpGI3PmpH8sxXk5ADNUY76NHxEr+ZGsE8xuP05unJcJ8ha11Mega6 H+4fuG6uM0QWEBhRlKaNceOpK14YZAMOWLiI1cfPPUXeUUVKD0YbygHiduIiDqkkZXma yiY6xExjkrSKvSmdys08ZKYYnlD+28APLARLKTkwmXfTKxwWIaJbRQ0ZZy2rkWLnliBo L6QQubzcde43LwinW1h6+z1mcuHLZqhnOxUUIu1Bkxsmdvi9Vbu0+qR8Rw18bZvstFXg ULCxhRYugYLanA5PE6qtBRsCvLGt5ldiJOKJ4GKVfI4g67VH7PbXi+9SBrsBI5ZoqHRe YUIw== X-Gm-Message-State: AOAM533hMmZKPBJBEfcSPUZY05V7Z7RLg84svUbT2SLYmohlP5Hzza+9 2BxBe0V7uJRB9JHIouCOYS7a2A== X-Google-Smtp-Source: ABdhPJx7MxdoTq/AQfhSbBRLisSFBmZ3dAUEDnAlTKGc5BXPc498hnMny/vCIyB3Hx3F+S0atbCn8w== X-Received: by 2002:a63:1352:: with SMTP id 18mr34912790pgt.11.1618384727922; Wed, 14 Apr 2021 00:18:47 -0700 (PDT) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id pg11sm3768606pjb.53.2021.04.14.00.18.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 00:18:47 -0700 (PDT) From: Vittorio Bertocci To: Roberto Polli , oauth Thread-Topic: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications Thread-Index: AXdZQnYypLO8gLFSWhSr/r3KNpSwl7+vd+NF X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 14 Apr 2021 07:18:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB40528FB106077C3E36C645D6AE4E9CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 07:18:54 -0000 --_000_CO6PR18MB40528FB106077C3E36C645D6AE4E9CO6PR18MB4052namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Roberto, Thanks for the comments and apologies for the delay. Inline * An example with client_credential grant type would be nice too. Are you thinking of specific aspects that aren=92t sufficiently clear from = the text that would be clarified by one example? Unless there=92s something= specific, at this late stage I=92d like to avoid big edits. * + The terms "Collision-Resistant", is used according to Section 2 of= {{JWT}}. Is the feedback to add the reference to section 2, or to add a dash? The re= ferenced section 4.2 of RFC7519 clarifies the use of the term, hence it see= ms unnecessary to mention section 2 as well (given that the notion of colli= sion resistance is clear outside of this context too). * - mentioning "none" alg can be redundant. I'd reference all the JWT B= CP instead. Calling out =93none=94 was specifically brought up during discussions as so= mething that is worth calling out. Although we might be formally covered by= simply referencing the BCP, forcing the user to resolve a reference and pr= ocess another large document seems to lose efficacy, clarity and immediacy = of the guidance. * Is it worth mentioning the "implicit flow"? What would you want to highlight of that particular case? * - " ... scope parameter..." should `scope` be quoted? That=92s=92 a good question! Given that scope the parameter and scope the c= laim appear in the same sentence, I chose to use the quotes for the claim a= nd leave the parameter unquoted to make it easier for the reader to follow = (see also the subsequent paragraph). I am inclined to leave it as is and se= e whether the editors accept it. * ^ otherwise the error returned is ...? Should we reference =A74 here? This was a hotly debated point. The consensus we landed on is enshrined in = P4 of Section 5, which we do reference from there. Substantially, establish= ing clear rules for how to make that match or how the AS should react to it= is very hard, hence we explicitly leave handling the details to individual= implementations. * which are the delegated scenarios described in RFC7519? Do you refer = to "When using an administratively delegated namespace" ? It is not clear to a first-reader. I mean the most classical oauth use cases :) The core scenarios described i= n RFC7519 are about a resource owner delegating limited access to a third p= arty application, as stated in the abstract and most of the document. The m= ainstream literature covering oauth uses the term consistently, and the sec= tion goes on describing user level attributes that have no direct role in t= he identity of the client application. I believe the intent of this section= should be reasonably clear with someone with some familiarity with oauth, = which I=92d assume as prerequisite. * - iiuc `jti` is required, the example does not report it. Great catch! In draft 06 we made both JTI and IAT REQUIRED, but we never up= dated the sample. Adding both in the upcoming revision. Thank you. * the step about forbidding "none" is limitative WRT JWT BCP 8725 I think the limitation in the case of JWTs used as ATs is justified. Whereas openid connect=92s ID_tokens (also JWTs) can be acquired thru a dir= ect TLS channel between the client and the AS, hence obviating for the need= of an explicit signature check, that isn=92t usually the case with access = tokens- there the requestor (the client) and the intended recipient (the RS= ) are separate entities. The responsibility of the token validation falls o= n the RS, which has no direct channel toward the AS (excluding introspectio= n, which would largely make the entire JWT encoding of ATs moot) hence need= s a way of validating tokens independently, and a signature is the common p= ractice. Although alternative mechanisms are possible, they are uncommon en= ough to be safely excluded from an interop profile. From: OAuth on behalf of Roberto Polli Date: Friday, April 2, 2021 at 02:55 To: oauth Subject: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications Hi Vittorio et al, some considerations on oauth access token jwt follows. You can see them here too https://docs.google.com/document/d/1XsvBzGvhcY0N6= vJNgLx6G1dJ5trvgwYRJA9F_NCakbU/edit An example with client_credential grant type would be nice too. My 2=A2, R. =A7 1.2 Terminology + The terms "Collision-Resistant", is used according to Section 2 of {{JWT= }}. =A72.1 Header - mentioning "none" alg can be redundant. I'd reference all the JWT BCP ins= tead. - I'd add an example header, eg ~~~ example { "typ": "at+jwt", "alg": "PS256" } ~~~ =A7 2.2.1 Authentication Information Claims Is it worth mentioning the "implicit flow"? =A72.2.2 Identity Claims - use the "Collision-Resistant" definition in {{JWT}} =A72.2.3 Authorization Claims - " ... scope parameter..." should `scope` be quoted? - "All the individual scope strings in the "scope" claim MUST have meaning= for the resources indicated in the "aud" claim." ^ otherwise the error returned is ...? Should we reference =A74 here? =A72.2.3.1 Claims for Authorization Outside of Delegation Scenarios - which are the delegated scenarios described in RFC7519? Do you refer to "= When using an administratively delegated namespace" ? It is not clear to a first-reader. =A73 Requesting a JWT Access Token - an example with `client_credential` grant type would be great. - iiuc `jti` is required, the example does not report it. =A74 Validating JWT Access Tokens - the step about forbidding "none" is limitative WRT JWT BCP 8725 --_000_CO6PR18MB40528FB106077C3E36C645D6AE4E9CO6PR18MB4052namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Roberto,

Thanks for the comments and apologies for the delay.= Inline

 

  • An example with client_credential grant type would be nice too.<= /o:p>

Are you thinking of specific aspects that aren=92t s= ufficiently clear from the text that would be clarified by one example? Unl= ess there=92s something specific, at this late stage I=92d like to avoid bi= g edits.

 

  • + The terms "Collision-Resistant",  is= used according to Section 2 of {{JWT}}. 

Is the feedback to add the reference to section 2, o= r to add a dash? The referenced section 4.2 of RFC7519 clarifies the use of= the term, hence it seems unnecessary to mention section 2 as well (given t= hat the notion of collision resistance is clear outside of this context too).

 

  • - mentioning "none" alg can be redundant. I'd reference all= the JWT BCP instead.

Calling out =93none=94 was specifically brought up d= uring discussions as something that is worth calling out. Although we might= be formally covered by simply referencing the BCP, forcing the user to res= olve a reference and process another large document seems to lose efficacy, clarity and immediacy of the guidance.

 

  • Is it worth mentioning the "implicit flow"?
    • =

What would you want to highlight of that particular = case?

 

  • - " ... scope parameter..."  should `scope` be quoted?=

That=92s=92 a good question! Given that scope the pa= rameter and scope the claim appear in the same sentence, I chose to use the= quotes for the claim and leave the parameter unquoted to make it easier fo= r the reader to follow (see also the subsequent paragraph). I am inclined to leave it as is and see whether the editors ac= cept it.

 

  • ^ otherwise the error returned is ...? Should we reference= =A74 here?

This was a hotly debated point. The consensus we lan= ded on is enshrined in P4 of Section 5, which we do reference from there. S= ubstantially, establishing clear rules for how to make that match or how th= e AS should react to it is very hard, hence we explicitly leave handling the details to individual implementatio= ns.

 

  • which are the delegated scenarios described in RFC7519? Do you refer&= nbsp;to "When using an administratively delegated
          namespace" ? It is not clear to a first-reader.

I mean the most classical oauth use cases :) The cor= e scenarios described in RFC7519 are about a resource owner delegating limi= ted access to a third party application, as stated in the abstract and most= of the document. The mainstream literature covering oauth uses the term consistently, and the section goes on describ= ing user level attributes that have no direct role in the identity of the c= lient application. I believe the intent of this section should be reasonabl= y clear with someone with some familiarity with oauth, which I=92d assume as prerequisite.   

 

  • - iiuc `jti` is required, the example does not report it.<= /span>

Great catch! In draft 06 we made both JTI and IAT RE= QUIRED, but we never updated the sample. Adding both in the upcoming revisi= on. Thank you.

 

  • the step about forbidding "none" is limitative WRT JWT BCP = 8725

I think the limitation in the case of JWTs used as A= Ts is justified.

Whereas openid connect=92s ID_tokens (also JWTs) can= be acquired thru a direct TLS channel between the client and the AS, hence= obviating for the need of an explicit signature check, that isn=92t usuall= y the case with access tokens- there the requestor (the client) and the intended recipient (the RS) are separate en= tities. The responsibility of the token validation falls on the RS, which h= as no direct channel toward the AS (excluding introspection, which would la= rgely make the entire JWT encoding of ATs moot) hence needs a way of validating tokens independently, and a s= ignature is the common practice. Although alternative mechanisms are possib= le, they are uncommon enough to be safely excluded from an interop profile.

 

From= : OAuth <oauth-b= ounces@ietf.org> on behalf of Roberto Polli <robipolli@gmail.com><= br> Date: Friday, April 2, 2021 at 02:55
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] oauth-access-token-jwt: comments and clarificati= ons

 

Hi Vittorio et al,

 

some considerations on oauth access token jwt follow= s.

 

An example with client_credential grant type would b= e nice too.

 

My 2=A2,

R.

 

=A7 1.2  Terminology

 

+ The terms "Collision-Resistan= t",  is used according to Section 2 of {{JWT}}. =

 

=A72.1 Header

 

- mentioning "none" alg can be redundant. = I'd reference all the JWT BCP instead.

- I'd add an example header, eg

 

~~~ example=

{

  "= typ": "at+jwt",

  "= alg": "PS256"

}

~~~

 

 

=A7 2.2.1 Authentication Information Claims

 

Is it worth mentioning the "implicit flow"= ?

 

=A72.2.2 Identity Claims

 

- use the "Collision-Resistant" definition= in {{JWT}}

 

=A72.2.3 Authorization Claims

 

- " ... scope parameter..."  should `= scope` be quoted?

-  "All the individual scope st= rings in the "scope" claim MUST have meaning for the resources in= dicated in the "aud" claim."

^ otherwise the error returned is ...? Sh= ould we reference =A74 here?


=A72.2.3.1 Claims for Authorization Outside of Delegation Scenarios
- which are the delegated scenarios described in RFC7519? Do you refer = ;to "When using an administratively delegated
      namespace" ? It is not clear to a first-reader.



=A73 Requesting a JWT Access Token=

- an example with `client_credential` gra= nt type would be great.

- iiuc `jti` is required, the example doe= s not report it.

 

=A74 Validating JWT Access Tokens

 

- the step about forbidding "none" is limi= tative WRT JWT BCP 8725

--_000_CO6PR18MB40528FB106077C3E36C645D6AE4E9CO6PR18MB4052namp_-- From nobody Wed Apr 14 00:19:02 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8C13A117B for ; Wed, 14 Apr 2021 00:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrdfN2Mg2VVL for ; Wed, 14 Apr 2021 00:18:53 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0: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 5420E3A111C for ; Wed, 14 Apr 2021 00:18:53 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id p67so8187186pfp.10 for ; Wed, 14 Apr 2021 00:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=1yG4WqoPLmPG14Ybtj3JjqltXcJU+8FicDYGlfptpgs=; b=PhBRI7zmDc+fFFIXroSbfZzHXAm5UFO06xftI/bXyiWrtx3akrYha9uq0bbDBe00w6 4x7d8jp+CUh/Jz3DAUPfdZSpfP5Uv7yLzbuzWCfaMEvFvHOjQ2znrnv7OGPjWPAVd9qd aswgPtjOPB+lnRT+DF4iWxrqm0vf1EVYOvC0rp9SRTLe2tS6Dalz9gOKcRxsa5avlMPe kmEq0ClJPi0qYxCtgMAiOHggM2BsnppN8kXRi84scGOropAwOHQCDjhLIEw3pqgInpaN fZpEJynU8FHU3F/yUYWKLjANVj3VxSPV2Tks2HOzEbzRFlQVM/UfLCrmLU61O3+Bo5Zg +3kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=1yG4WqoPLmPG14Ybtj3JjqltXcJU+8FicDYGlfptpgs=; b=onycpwygejh+ypL7+wi8rh+5j+1gZ1jDGMZ4A5BMbfwOI5FnQ3s6GFO9ncUpKnzz+r gweTmkUKKNqDtV/5AtbYsSQ3Q3A6FW5lOWPAqVTzPp3+3Urixu+lMYsvQ8OOyh2x6b4m vz3LJdATY6/exqCWhwtD1+MN1X3VYZU7QVEQjHrvIK0TyJWGhVLcAoVPztJzLPRfcaBw gTG7eY1xacBb6EjXpMtpLMEBAGilYki3yEcb6vJLbRySJaKkfc4Dj+YwjFbTo8baFxr6 +yaOWedpPZWxa8g9zV3SIRC6OB72Nqy7d8IV3ijuPk+ui9dXfJxXxiT5Alw4LqBMCBtd MItg== X-Gm-Message-State: AOAM53295f6ipzBKIDj0MVB5hinK9s3GRTPH3wOSSW4bX/dsGgtcFKJn MIppbKD9ukBWggMDq1bNCU2WkQ== X-Google-Smtp-Source: ABdhPJz5s1r7fqRc9lln9RC9B12dtMoq45C5cW535FvZI1TDwD/VBSo89eG10AHbWwsIi88a3uHSQQ== X-Received: by 2002:a63:43c2:: with SMTP id q185mr35424598pga.41.1618384731358; Wed, 14 Apr 2021 00:18:51 -0700 (PDT) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id w1sm16348598pgh.26.2021.04.14.00.18.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 00:18:50 -0700 (PDT) From: Vittorio Bertocci To: Murray Kucherawy , The IESG CC: "draft-ietf-oauth-access-token-jwt@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , Hannes Tschofenig Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) Thread-Index: ATUxNDgwYmwhajVWzfY8mwnpZvepcMP/lGTY X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 14 Apr 2021 07:18:50 +0000 Message-ID: References: <161786294101.28888.16150454715315694485@ietfa.amsl.com> In-Reply-To: <161786294101.28888.16150454715315694485@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 07:19:00 -0000 SGkgTXVycmF5LA0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzISBBbnN3ZXJzIGlubGluZQ0K DQo+ICAgTXkgY28tQUQgcHJldHR5IG11Y2ggbmFpbGVkIGl0LiAgIEkgd291bGQgZ28gZnVydGhl ciBhbmQgc2F5IHRoYXQgaGVyIGNvbW1lbnQNCj4gICAgYWJvdXQgIldoeSBpcyB0aGlzIG9ubHkg U0hPVUxEPyIgYXBwbGllcyB0byBhIGxvdCBvZiB0aGUgU0hPVUxEcyBpbiBoZXJlLiANCj4gICAg U0hPVUxEIHByZXNlbnRzIGEgY2hvaWNlOyB3aHkgbWlnaHQgYW4gaW1wbGVtZW50ZXIgcmVhc29u YWJseSBub3QgZG8gYW55IG9mIHRoZQ0KPiAgICBTSE9VTEQgdGhpbmdzIGluIGhlcmU/DQpJbiBs aW5lIG9mIHByaW5jaXBsZSwgSSBhZ3JlZS0gYnV0IHRoYXQncyB3aGVyZSB0aGUgY29uc2Vuc3Vz IGJyb3VnaHQgdXMuIE1hbnkgb2YgdGhlIFNIT1VMRCB5b3Ugc2VlIGluIHRoZSBjdXJyZW50IGRy YWZ0IGFjdHVhbGx5IHN0YXJ0ZWQgYXMgTVVTVCwgYW5kIHRoZSBkaXNjdXNzaW9uIGRyb3ZlIHRv d2FyZCB0aGVtIGJlaW5nIHJlbGF4ZWQuIFRoZSB0ZWNobm9sb2d5IHdlIGFyZSB0cnlpbmcgdG8g c3RhbmRhcmRpemUgaGVyZSBoYXMgYmVlbiBpbiBwcm9kdWN0aW9uIHVzZSBmb3IgbWFueSB5ZWFy cywgaGVuY2UgdGhlcmUncyBhIHdlYWx0aCBvZiByZWFsIHdvcmxkIHNjZW5hcmlvcyB0aGF0IGlu Zmx1ZW5jZWQgdGhlIGRlYmF0ZS4NCkZvciBhIG1vcmUgcHJlY2lzZSBkaXNjdXNzaW9uLCB3ZSBz aG91bGQgc2VsZWN0IHNwZWNpZmljIGluc3RhbmNlczogYnV0IGZvciBhbiBleGFtcGxlIG9mIHR5 cGljYWwgY2lyY3Vtc3RhbmNlcyB0aGF0IGxlZCB0b3dhcmQgU0hPVUxELCB0aGUgY2FzZSBkaXNj dXNzZWQgd2l0aCBGcmFuY2VzY2EgaXMgcHJldHR5IHR5cGljYWwuDQoNCj5Gb3IgcmVhZGFiaWxp dHksIEkgc3VnZ2VzdCB0aGF0IHRoZSB0aHJlZSByZWdpc3RyYXRpb25zIHBhY2tlZCBpbnRvIFNl Y3Rpb24NCiA+ICAgNy4yLjEgYmUgc2VwYXJhdGVkIHNvbWVob3csIGFzIHJpZ2h0IG5vdyB0aGV5 IGFwcGVhciB0byBiZSBvbmUgY29udGludW91cw0KID4gICBidWxsZXQgbGlzdC4gIFNlcGFyYXRl IHN1YnNlY3Rpb25zIHdvdWxkIHdvcmssIG9yIGV2ZW4ganVzdCBhIGxpbmUgb2YgcHJvc2UNCiA+ ICAgYmVmb3JlIGVhY2ggd291bGQgc3VmZmljZS4NCkdyZWF0IHN1Z2dlc3Rpb24sIHRoYW5rIHlv dSEgSSBhZGRlZCBzZWN0aW9ucyBmb3IgaW1wcm92ZWQgcmVhZGFiaWxpdHkuDQoNCj4gICAgVGhl IGZpcnN0IGhhbGYgb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA2IHNlZW1zIG11 Y2ggbW9yZSBsaWtlIGFuDQo+ICAgIGludGVyb3BlcmFiaWxpdHkgaXNzdWUgdGhhbiBhIHByaXZh Y3kgaXNzdWUgdG8gbWUuDQpJIGFncmVlIHRoYXQsIHRha2VuIGluIGlzb2xhdGlvbiwgdGhlIGNv bm5lY3Rpb24gdG8gcHJpdmFjeSBvZiB0aGF0IGFzcGVjdCBpcyBub3QgaW1tZWRpYXRlbHkgc2Vs Zi1ldmlkZW50LiBJIHdvdWxkIGFyZ3VlIGl0IGlzIG5vdCBhYm91dCBpbnRlcm9wIGVpdGhlciwg Z2l2ZW4gdGhhdCBub25jb21wbGlhbmNlIHdpdGggdGhlIGd1aWRhbmNlIGdpdmVuIHRoZXJlIGRv ZXNu4oCZdCBpbXBhY3Qgd2hhdCdzIHRyYW5zbWl0dGVkLiBOb25ldGhlbGVzcywgSSBiZWxpZXZl IHRoZSBwcml2YWN5IHNlY3Rpb24gaXMgdGhlIGNsb3Nlc3QgbWF0Y2ggd2UgaGF2ZSBmb3IgdGhh dCBndWlkYW5jZSwgZ2l2ZW4gaXRzIG1hbnkgdG91Y2ggcG9pbnRzIHRvIHByaXZhY3kgbWF0dGVy cyAodGhlIGFiaWxpdHkgb2YgYSBjbGllbnQgdG8gaW5zcGVjdCBBVHMgaXMgYSBwcml2YWN5IGNv bmNlcm47IHRoZSBkZWNpc2lvbiB0byB1c2UgYSBKV1QgQVRzLCB3aGljaCB1bHRpbWF0ZWx5IG1h a2VzIHNwZWxsaW5nIG91dCB0aGUgZ3VpZGFuY2UgbmVjZXNzYXJ5LCBpcyBpbmZsdWVuY2VkIGJ5 IHByaXZhY3kgY29uc2lkZXJhdGlvbnM7IGFuZCBzbyBvbiBhbmQgc28gZm9ydGgpLiBJbiBzdW0s IGFsdGhvdWdoIEkgYWdyZWUgaXQncyBub3QgYSBwZXJmZWN0IGZpdCwgSSB0aGluayB0aGF0J3Mg dGhlIGJlc3QgZml0IHdlIGhhdmU7IGFuZCBnaXZlbiB0aGF0IGNvbnNvbGlkYXRpbmcgY29uc2Vu c3VzIGZvciB0aGF0IHBhcnQgaGFzIGJlZW4gcGFydGljdWxhcmx5IHBhaW5mdWwsIEkgYW0gaW5j bGluZWQgdG8gbGVhdmUgdGhhdCBwYXJ0IGFzIGlzLiAgIA0KDQoNCu+7v09uIDQvNy8yMSwgMjM6 MjIsICJNdXJyYXkgS3VjaGVyYXd5IHZpYSBEYXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+ IHdyb3RlOg0KDQogICAgTXVycmF5IEt1Y2hlcmF3eSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1q d3QtMTI6IE5vIE9iamVjdGlvbg0KICAgIA0KICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KICAgIGVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzDQogICAgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQogICAgDQogICAg DQogICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElF U0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgDQogICAgDQogICAgVGhlIGRv Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBo ZXJlOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1 dGgtYWNjZXNzLXRva2VuLWp3dC8NCiAgICANCiAgICANCiAgICANCiAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQogICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgTXkgY28tQUQgcHJl dHR5IG11Y2ggbmFpbGVkIGl0LiAgIEkgd291bGQgZ28gZnVydGhlciBhbmQgc2F5IHRoYXQgaGVy IGNvbW1lbnQNCiAgICBhYm91dCAiV2h5IGlzIHRoaXMgb25seSBTSE9VTEQ/IiBhcHBsaWVzIHRv IGEgbG90IG9mIHRoZSBTSE9VTERzIGluIGhlcmUuIA0KICAgIFNIT1VMRCBwcmVzZW50cyBhIGNo b2ljZTsgd2h5IG1pZ2h0IGFuIGltcGxlbWVudGVyIHJlYXNvbmFibHkgbm90IGRvIGFueSBvZiB0 aGUNCiAgICBTSE9VTEQgdGhpbmdzIGluIGhlcmU/DQogICAgDQogICAgRm9yIHJlYWRhYmlsaXR5 LCBJIHN1Z2dlc3QgdGhhdCB0aGUgdGhyZWUgcmVnaXN0cmF0aW9ucyBwYWNrZWQgaW50byBTZWN0 aW9uDQogICAgNy4yLjEgYmUgc2VwYXJhdGVkIHNvbWVob3csIGFzIHJpZ2h0IG5vdyB0aGV5IGFw cGVhciB0byBiZSBvbmUgY29udGludW91cw0KICAgIGJ1bGxldCBsaXN0LiAgU2VwYXJhdGUgc3Vi c2VjdGlvbnMgd291bGQgd29yaywgb3IgZXZlbiBqdXN0IGEgbGluZSBvZiBwcm9zZQ0KICAgIGJl Zm9yZSBlYWNoIHdvdWxkIHN1ZmZpY2UuDQogICAgDQogICAgVGhlIGZpcnN0IGhhbGYgb2YgdGhl IHNlY29uZCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA2IHNlZW1zIG11Y2ggbW9yZSBsaWtlIGFuDQog ICAgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSB0aGFuIGEgcHJpdmFjeSBpc3N1ZSB0byBtZS4NCiAg ICANCiAgICANCiAgICANCiAgICANCg== From nobody Wed Apr 14 00:19:14 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F7B3A11DE for ; Wed, 14 Apr 2021 00:19:02 -0700 (PDT) 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmD_edFY8xpt for ; Wed, 14 Apr 2021 00:18:58 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1893A1167 for ; Wed, 14 Apr 2021 00:18:56 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id p67so8187315pfp.10 for ; Wed, 14 Apr 2021 00:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=PJaQ9eTa+/inRNEiB/Wg3tmXKBVCnemTH7nzL2leqr8=; b=dlAw0O1h0ndyiqbK7nNXXz1uEbZV13icQGrTOJ60e9PJL0cV1RblzYWUu8ZmL/7l1X F3nx7N6yHL31PoD/naKdefthtTu8CIaY67uySvdJZAMAyOw5xf+sXhJMEa67OcwVj38V O1z7RFr1jdqodrOe3AyUPlsWCqhqyUWaP4MbnF13RwXwnfvH0eQs0e13Z+Di+QeVT2sP oJjz0wcrSVzQOgb+0bPH9r4Ek2cn7MtjKHP/s3zhr2Cd2iQ0zZo6e5VKiuJFsiBNfe5K qhpJREpxuzpHV3c8gVhugEb+e/X3ZcSYdMSiXxJL0L+RMpojnIbyQ7WjjH4DFWgUXAM+ qBXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=PJaQ9eTa+/inRNEiB/Wg3tmXKBVCnemTH7nzL2leqr8=; b=FRMzYTbQWFj7KT9TktfaipoqYOS0BfJVNX1HtFeVU9NYlJtZ1WuB/Fw0HAMWf8ZLHp cq3tXWwAu59E2h+CEuLxMIb2tlVIrUPWkWf6H4DLeq6oWDqA0weeD9fmncAznSBc+P6Y e5h4bvquHy5ppnJTREtb9LS9qmCyVrXr3N8Y70WMdsrfn3Sv9RVY8V/uqztN06WiakwZ upDE1iV5UNG59Gze01AfnUXhPpfULyYFCKVABnwOV9OPc7P+tAhKlnmu1ZuEiO7N30n9 GUuum9MEckK5KiWo702k3NCs4dE1zn2WSjj2NKfHpu2d8jGJ8/9RiSoiOLFbGANaUxPR WCtw== X-Gm-Message-State: AOAM533nvESGX7zK8gAuJQROnbek8I42wgiRC3bdAwMfWuV90MOCmDiG b6F/efI0yx2upNeqghIEFL3kQw== X-Google-Smtp-Source: ABdhPJxDeyzefJ6IK2VMZQfpeioo80qKzB4gluNBPnoG9FcA3M+GSoT7QOIfjE5SbKf9Ml+RZzRg/w== X-Received: by 2002:a65:4303:: with SMTP id j3mr35595007pgq.55.1618384735315; Wed, 14 Apr 2021 00:18:55 -0700 (PDT) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id k22sm14213072pfa.93.2021.04.14.00.18.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 00:18:54 -0700 (PDT) From: Vittorio Bertocci To: Francesca Palombini , The IESG CC: "draft-ietf-oauth-access-token-jwt@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "hannes.tschofenig@arm.com" Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) Thread-Index: ATQxMDY21bw61opi7lXBW2kIpARnpcX/nG17 X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 14 Apr 2021 07:18:54 +0000 Message-ID: References: <161755926036.31657.529017576412672874@ietfa.amsl.com> In-Reply-To: <161755926036.31657.529017576412672874@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 07:19:06 -0000 SGkgRnJhbmNlc2NhLA0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgdGhvdWdodGZ1bCBjb21t ZW50cyENCkNvbW1lbnRzIGJlbG93Lg0KDQo+ICAgIDEuIC0tLS0tDQo+ICAgIFsuLi5dDQpXaGls ZSBpdCBpcyByZWFzb25hYmxlIHRvIGV4cGVjdCB0aGF0IGEgUlMgcmVjZWl2aW5nIGFuIHVuZW5j cnlwdGVkIHRva2VuIGFmdGVyIHJlcXVlc3RpbmcgaXQgdG8gYmUgZW5jcnlwdGVkIHdpbGwgcmVq ZWN0IGl0LCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgY2FzZXMgd2hlcmUgdGhlIFJTIG1pZ2h0IGVs ZWN0IHRvIGRvIG90aGVyd2lzZS4gRm9yIGV4YW1wbGUsIHRoZSBzb2x1dGlvbiBtaWdodCBiZSBh bHJlYWR5IHdvcmtpbmcgaW4gcHJvZHVjdGlvbjogdGhlIGVuY3J5cHRpb24gcmVxdWlyZW1lbnQg bWlnaHQgYmUgYW4gaW1wcm92ZW1lbnQgdGhhdCBpcyBzdGlsbCBwcm9wYWdhdGluZyB0aHJ1IHRo ZSBzeXN0ZW0sIGFuZCB0aGVyZSBtaWdodCBzdGlsbCBiZSBhY2Nlc3MgdG9rZW5zIGNhY2hlZCBp biBjbGllbnRzIHRoYXQgdGhlIFJTIG1pZ2h0IHN0aWxsIGJlIHdpbGxpbmcgdG8gYWNjZXB0IHRv IGd1YXJhbnRlZSBidXNpbmVzcyBjb250aW51aXR5LiAiU0hPVUxEIiBnaXZlcyBhIHN0cm9uZyBz aWduYWwgdG8gaW1wbGVtZW50ZXJzIG9mIHdoYXQgdGhlIGRlc2lyZWQgYmVoYXZpb3IgaXMsIGJ1 dCBsZWF2ZXMgdGhlbSBzb21lIGZyZWVkb20gdG8gYWNjb21tb2RhdGUgc2l0dWF0aW9ucyBsaWtl IHRoZSBhZm9yZW1lbnRpb25lZCBvbmUuDQoNCj4gMi4gLS0tDQo+IFsuLi5dDQpGYWlyIGVub3Vn aC4gSSBhZGRlZCB0aGUgZm9sbG93aW5nIHRleHQgYXQgdGhlIGJlZ2lubmluZyBvZiAyLjEuIFRo YW5rcyBmb3IgY2F0Y2hpbmcgdGhpcy4NCiAgICAgSldUIGFjY2VzcyB0b2tlbnMgTVVTVCBiZSBz aWduZWQuIEFsdGhvdWdoIEpXVCBhY2Nlc3MgdG9rZW5zIGNhbiB1c2UgYW55IHNpZ25pbmcgYWxn b3JpdGhtWy4uXQ0KVGhpcyBjaGFuZ2Ugd2lsbCBhcHBlYXIgaW4gdGhlIG5leHQgcmV2aXNpb24s IHdoaWNoIEkgd2lsbCBwb3N0IHNvb24uDQoNCj4gICAgIDMuIC0tLS0tDQo+IFsuLi5dDQoNCkZv cm1hbGx5LCBJIGFncmVlIHRoYXQgSk9TRSB3b3VsZCBhbHNvIHdvcmsuIFRoZSBjaG9pY2Ugb2Yg bWVkaWEgdHlwZSBkZXJpdmVzIGZyb20gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1 MTkjc2VjdGlvbi0xMC4zLjEuIFRoZXJlIGlzIG5vIGZ1bmN0aW9uYWwgZGlmZmVyZW5jZSBiZXR3 ZWVuIEpXUyBhbmQgSldFIGluIHRoZSBpbnRlbnQgYSBjbGllbnQgaGFzIHdoZW4gY2FsbGluZyBh biBSUywgaGVyZSB0aGVyZSdzIG5vdCBtdWNoIHRvIGJlIGdhaW5lZCBpbiB1c2luZyBkaWZmZXJl bnQgTUlNRSB0eXBlcyBmb3IgdGhvc2UgY2FzZXMuIEZ1cnRoZXJtb3JlLCB3aGVyZWFzIGRldmVs b3BlcnMgYXJlIGZhbWlsaWFyIHdpdGggdGhlIHRlcm0gIkpXVCIsIGJvdGggZnJvbSBkaXJlY3Qg dXNlIGFuZCB0aGFua3MgdG8gdGhlIHBvcHVsYXJpdHkgb2YgT3BlbklEIENvbm5lY3QgKHdoaWNo IGRvZXMgdXNlIGFwcGxpY2F0aW9uL2p3dCksIHRlcm1zIGxpa2UgSldTLCBKV0Ugb3IgSk9TRSB3 b3VsZG4ndCBiZSBhcyBwcm9tcHRseSB1bmRlcnN0b29kIGFzIEpXVC4gVGhyb3VnaG91dCB0aGUg ZGlzY3Vzc2lvbnMgaW4gdGhlIGxhc3QgY291cGxlIG9mIHllYXJzLCB0aGUgY29uc2Vuc3VzIG9u IHRoZSB1c2Ugb2YgYXQrand0IHdhcyBzb2xpZC0gbXkgaG9wZSBpcyB0aGF0IHdpbGwgbWFrZSBp bnR1aXRpdmUgc2Vuc2UgZm9yIGltcGxlbWVudGVycywgdG9vLg0KDQoNCu+7v09uIDQvNC8yMSwg MTE6MDEsICJGcmFuY2VzY2EgUGFsb21iaW5pIHZpYSBEYXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0 Zi5vcmc+IHdyb3RlOg0KDQogICAgRnJhbmNlc2NhIFBhbG9tYmluaSBoYXMgZW50ZXJlZCB0aGUg Zm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLW9hdXRoLWFjY2Vz cy10b2tlbi1qd3QtMTI6IE5vIE9iamVjdGlvbg0KICAgIA0KICAgIFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KICAg IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzDQogICAgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQog ICAgDQogICAgDQogICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgDQogICAgDQog ICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC8NCiAgICANCiAgICANCiAgICANCiAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgVGhh bmsgeW91IGZvciB0aGUgd29yayBvbiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgZmluZCBzb21lIGNv bW1lbnRzIGFuZA0KICAgIGNsYXJpZnlpbmcgcXVlc3Rpb25zIGJlbG93Lg0KICAgIA0KICAgIEZy YW5jZXNjYQ0KICAgIA0KICAgIDEuIC0tLS0tDQogICAgDQogICAgICAgICAgcmVnaXN0cmF0aW9u LiAgSWYgZW5jcnlwdGlvbiB3YXMgbmVnb3RpYXRlZCB3aXRoIHRoZSBhdXRob3JpemF0aW9uDQog ICAgICAgICAgc2VydmVyIGF0IHJlZ2lzdHJhdGlvbiB0aW1lIGFuZCB0aGUgaW5jb21pbmcgSldU IGFjY2VzcyB0b2tlbiBpcw0KICAgICAgICAgIG5vdCBlbmNyeXB0ZWQsIHRoZSByZXNvdXJjZSBz ZXJ2ZXIgU0hPVUxEIHJlamVjdCBpdC4NCiAgICANCiAgICBGUDogV2h5IGlzIHRoaXMganVzdCBT SE9VTEQgYW5kIG5vdCBNVVNUPyBJbiB3aGljaCBjYXNlIGRvZXMgaXQgbWFrZSBzZW5zZSB0bw0K ICAgIGFjY2VwdCBhIG5vbi1lbmNyeXB0ZWQgdG9rZW4gd2hlbiBlbmNyeXB0aW9uIHdhcyBuZWdv dGlhdGVkPw0KICAgIA0KICAgIDIuIC0tLS0tDQogICAgDQogICAgU2VjdGlvbiAyLjE6DQogICAg DQogICAgICAgU2VjdGlvbiA0KS4gIEpXVCBhY2Nlc3MgdG9rZW5zIE1VU1QgTk9UIHVzZSAibm9u ZSIgYXMgdGhlIHNpZ25pbmcNCiAgICAgICBhbGdvcml0aG0uICBTZWUgU2VjdGlvbiA0IGZvciBt b3JlIGRldGFpbHMuDQogICAgDQogICAgU2VjdGlvbiA0Og0KICAgIA0KICAgICAgIEZvciB0aGUg cHVycG9zZSBvZiBmYWNpbGl0YXRpbmcgdmFsaWRhdGlvbiBkYXRhIHJldHJpZXZhbCwgaXQgaXMg aGVyZQ0KICAgICAgIFJFQ09NTUVOREVEIHRoYXQgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNpZ24g SldUIGFjY2VzcyB0b2tlbnMgd2l0aCBhbg0KICAgICAgIGFzeW1tZXRyaWMgYWxnb3JpdGhtLg0K ICAgIA0KICAgICAgIC4uLg0KICAgIA0KICAgICAgIG8gIFRoZSByZXNvdXJjZSBzZXJ2ZXIgTVVT VCB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlIG9mIGFsbCBpbmNvbWluZw0KICAgICAgICAgIEpXVCBh Y2Nlc3MgdG9rZW5zIGFjY29yZGluZyB0byBbUkZDNzUxNV0gdXNpbmcgdGhlIGFsZ29yaXRobQ0K ICAgICAgICAgIHNwZWNpZmllZCBpbiB0aGUgSldUIGFsZyBIZWFkZXIgUGFyYW1ldGVyLiAgVGhl IHJlc291cmNlIHNlcnZlcg0KICAgIA0KICAgIEZQOiBJdCBtaWdodCBiZSBvYnZpb3VzLCBidXQg SSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBhbiBleHBsaWNpdA0KICAgIHNlbnRl bmNlIHN0YXRpbmcgdGhhdCBKV1QgTVVTVCBiZSBzaWduZWQuIFRoZSBxdW90ZWQgdGV4dCBmcm9t IFNlY3Rpb24gMi4xIHNlZW0NCiAgICB0byBpbXBseSBpdC4gU2VjdGlvbiA0IG9ubHkgUkVDT01N RU5EUyB0aGF0IHRoZSBKV1QgaXMgc2lnbmVkIHdpdGggYW5kDQogICAgYXN5bW1ldHJpYyBhbGdv cml0aG0uIExhdGVyIG9uLCBTZWN0aW9uIDQgaW1wbGllcyB0aGF0IGFsbCBKV1QgYXJlIHNpZ25l ZC4gT24NCiAgICB0aGUgb3RoZXIgaGFuZCBJIG5vdGUgdGhhdCBlbmNyeXB0aW9uIGNhbiBiZSBu ZWdvdGlhdGVkIChhbmQgaXMgb3B0aW9uYWwpIGZyb20NCiAgICB0aGUgZm9sbG93aWcgcG9pbnQ7 IGluIHRoYXQgY2FzZSBpdCBpcyBub3QgY2xlYXIgdGhhdCB0aGUgdG9rZW4gaXMgc3RpbGwgc2ln bmVkDQogICAgKHNvIHRoZSBuZXN0ZWQgSldUIHdvdWxkIGJlIGEgSldFIG5lc3RlZCBpbiBhIEpX UyksIG9yIG9ubHkgSldFIGlzIHVzZWQuIFdoYXQgSQ0KICAgIGFtIGxvb2tpbmcgZm9yIGlzIHNp bXBsZSBjbGFyaWZpY2F0aW9ucyB0byBiZSBhZGRlZCBmb3IgZXhhbXBsZSBpbiB0aGUNCiAgICBp bnRyb2R1Y3Rpb24uDQogICAgDQogICAgICAgICBvICBJZiB0aGUgSldUIGFjY2VzcyB0b2tlbiBp cyBlbmNyeXB0ZWQsIGRlY3J5cHQgaXQgdXNpbmcgdGhlIGtleXMNCiAgICAgICAgICBhbmQgYWxn b3JpdGhtcyB0aGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXIgc3BlY2lmaWVkIGR1cmluZw0KICAgICAg ICAgIHJlZ2lzdHJhdGlvbi4gIElmIGVuY3J5cHRpb24gd2FzIG5lZ290aWF0ZWQgd2l0aCB0aGUg YXV0aG9yaXphdGlvbg0KICAgIA0KICAgIDMuIC0tLS0tDQogICAgDQogICAgT24gdGhlIHNhbWUg bm90ZSwgYW5kIGRlcGVuZGluZyBvbiB0aGUgcHJldmlvdXMgYW5zd2VyLCB3aHkgaXMgdGhlIG1l ZGlhIHR5cGUNCiAgICByZWdpc3RlcmVkIGFuZCB1c2VkICJhcHBsaWNhdGlvbi9hdCtqd3QiIGFu ZCBub3Qgc29tZXRoaW5nIGxpa2UNCiAgICAiYXBwbGljYXRpb24vYXQrandzIi8iYXBwbGljYXRp b24vYXQrandlIiBvciByYXRoZXIgImFwcGxpY2F0aW9uL2F0K2pvc2UiIHRvIGJlDQogICAgY29t cGxpYW50IHdpdGggaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzc1MTUuaHRtbCNz ZWN0aW9uLTkuMi4xID8gSQ0KICAgIHRoaW5rIHRoYXQgdGhlIHN0cnVjdHVyZSB0cmFuc3BvcnRl ZCBpcyBpbiBmYWN0IGEgSldTIG9yIGEgSldFLCByYXRoZXIgdGhhbiB0aGUNCiAgICBKV1QsIGFu ZCBpZiB0aGF0J3MgdGhlIGNhc2UgdGhhdCBzaG91bGQgYmUgbWFkZSBjbGVhciBpbiB0aGUgdGV4 dCAob25lIGV4YW1wbGUNCiAgICB3aGVyZSB0aGlzIGNvdWxkIGJlIGNsYXJpZmllZCBpcyBpbiB0 aGUgZm9sbG93aW5nIHNlbnRlbmNlKQ0KICAgIA0KICAgICAgIFJlc291cmNlIHNlcnZlcnMgcmVj ZWl2aW5nIGEgSldUIGFjY2VzcyB0b2tlbiBNVVNUIHZhbGlkYXRlIGl0IGluIHRoZQ0KICAgICAg IGZvbGxvd2luZyBtYW5uZXIuDQogICAgDQogICAgDQogICAgDQogICAgDQo= From nobody Wed Apr 14 00:19:17 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC843A117B for ; Wed, 14 Apr 2021 00:19:05 -0700 (PDT) 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ol9v5na_6eJ for ; Wed, 14 Apr 2021 00:19:01 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF6C3A112D for ; Wed, 14 Apr 2021 00:18:59 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id f29so13768194pgm.8 for ; Wed, 14 Apr 2021 00:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=ANNjAhCero6/eXOu5c3OKP1TscT0UFy/7v9SNgS32BE=; b=KTjQzofm54wnd+Lll3ciK57gjhTNR6gayog7Jo2wqo8+2B0ZuTnkQNLAmzGq9Nxgee GXMrIqYnepOe7AZMkJMND+gODC5dUZgiAv9s4yDV3u/bhVEKU9MN6HKohXcNWM/j7FG0 P5MJUQpcK9RdboUyLkAlhRa4ZwmQyUPdqWXiwAN9AsV0I9SCn37h3hOnOeLN3189Dh0u l/hPeTVJfkfgLjD9muv87I4Ovb+Ke5fRh+P4TxLiAGZrih+4UlbFpgRNOIKyKvZ1vb3N A/2CZNjW8Tgq3ZqFrQJ5OZ8PWS23u3iQCXYRBo6IbmF+A4Q488OSNkZ+quGWLvsdF8M5 4Oqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=ANNjAhCero6/eXOu5c3OKP1TscT0UFy/7v9SNgS32BE=; b=EvyoDEVWSZuXY+RFPzdp4pg1kRkIfDuhEHkb3q58dkMlcPPTaY76c+CKyJi/ndhvgT xamFsN+RWtZJZ2V5vBxn12C3TAdNLxNH2whAVQoPGtYS8rEjGAB/wvFk1O5YwfR9DJwT z6MtYuJZINjRgBea9lQIJj9QWAxo8DYebH/t4ulK6t6x562Z0WZ753PRMw/s3ztYqTOE knlS/TVDHYPsOe3D+KZnIoxHnKme9Kr4Un+rBeXKUqo/W+Wq2mv8tIZo0fp/tUukZ9Nr C/wQEQLEj1gpmP8zzAND3S25XdXMm7e5iD4pRfQ8NcTl9NVrb6dAku3dnfbob0XP75Yi mvXQ== X-Gm-Message-State: AOAM531rFQM4Ib8ubq0oddNF+YujBeKSnuO5A6w6JKlh5zwOeenXxMrt 7ChWSqyGhqjsBo1p4Q1A0IjQuHvuW5nXNw== X-Google-Smtp-Source: ABdhPJwfBbY11Wx+K7Kgidb3osqh49ckvQ8+2JnazUMzsF1PHndBur6amABghCd/BdKZUAyIZHn6Hw== X-Received: by 2002:a63:3047:: with SMTP id w68mr16950728pgw.94.1618384738622; Wed, 14 Apr 2021 00:18:58 -0700 (PDT) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id a81sm13806730pfa.165.2021.04.14.00.18.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 00:18:58 -0700 (PDT) From: Vittorio Bertocci To: Benjamin Kaduk , Martin Duke CC: The IESG , "draft-ietf-oauth-access-token-jwt@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) Thread-Index: ATExMzg3VOGotTUf2QrPIgQODNbq7TM3Mzk0ymXc04s= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 14 Apr 2021 07:18:57 +0000 Message-ID: References: <161730912872.14258.15710315415917535021@ietfa.amsl.com> <20210408191223.GT79563@kduck.mit.edu> In-Reply-To: <20210408191223.GT79563@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 07:19:09 -0000 VGhhbmtzIE1hcnRpbiBmb3IgdGhlIGNvbW1lbnRzIGFuZCBCZW5qYW1pbiBmb3IgYWRkcmVzc2lu ZyBzb21lIG9mIHRoZW0hDQpDb21tZW50cyBvbiB0aGUgcmVtYWluaW5nIG9uZXM6DQoNCiAgICA+ ICgyLjEpICIuLi5jYW4gdXNlIGFueSBzaWduaW5nIGFsZ29yaXRobS4iIEkgcHJlc3VtZSB0aGVy ZSBvdWdodCB0byBiZSBzb21lDQogICAgPiBxdWFsaWZpZXJzIG9uIGFsbG93ZWQgYWxnb3JpdGht cz8NClRoZSBhbGdvcml0aG1zIHJlZmVycmVkIHRvIGhlcmUgYXJlIHRoZSBvbmVzIGRlZmluZWQg YnkgdGhlIHVzdWFsIEpXVC9KV1MsIGFzIGluIEpXQSAoUkZDNzUxOCkuIFRoZSByZWFkZXIgc2hv dWxkIGJlIGFibGUgdG8gZ2V0IGl0IGZyb20gdGhlIGNvbnRleHQgd2l0aG91dCBhbWJpZ3VpdHku DQoNCiAgICA+ICg0KSBJIHByZXN1bWUgaXQncyBpbXBvcnRhbnQgdGhhdCBhbnkgcmVzb3VyZWUg c2VydmVyIHJlamVjdGlvbiBvZiB0aGUgdG9rZW4NCiAgICA+IHNob3VsZCBiZSBjb25zdGFudC10 aW1lLiBJcyB0aGlzIHNvbWV3aGVyZSBpbiB0aGUgUkZDIHRyZWUsIG9yIGRvIHdlIG5lZWQgdG8N CiAgICA+IGV4cGxpY2l0bHkgc2F5IGl0IGhlcmUgYW5kL29yIGluIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zPw0KSSBhbSB0aGlua2luZyBvZiBhbmFsb2dvdXMgZGVzY3JpcHRpb25zIGluIG90aGVy IHNwZWNzIGFuZCBJIGRvbuKAmXQgcmVjYWxsIG1lbnRpb25zIG9mIHRoYXQgYXNwZWN0LCBoZW5j ZSBJIGFzc3VtZWQgd2UgZGlkbuKAmXQgaGF2ZSB0byBzcGVjaWZ5IGl0IGhlcmUgZWl0aGVyLiBJ biBwYXJ0aWN1bGFyLCBJIGdsYW5jZWQgdGhydSBSRkM2NzUwICBzZWN0aW9uIDMsIHdoaWNoIHRo aXMgc3BlYyBzcGVjaWFsaXplcyBmb3IgdGhlIHNwZWNpZmljIEpXVCBBVCBzY2VuYXJpbywgYW5k IHRoZXkgZG9u4oCZdCBtZW50aW9uIHRoYXQgZWl0aGVyLg0KDQrvu79PbiA0LzgvMjEsIDEyOjEy LCAiQmVuamFtaW4gS2FkdWsiIDxrYWR1a0BtaXQuZWR1PiB3cm90ZToNCg0KICAgIE9uIFRodSwg QXByIDAxLCAyMDIxIGF0IDAxOjMyOjA4UE0gLTA3MDAsIE1hcnRpbiBEdWtlIHZpYSBEYXRhdHJh Y2tlciB3cm90ZToNCiAgICA+IE1hcnRpbiBEdWtlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcg0KICAgID4gZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4t and0LTEyOiBObyBPYmplY3Rpb24NCiAgICA+IA0KICAgID4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgPiBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcw0KICAgID4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQog ICAgPiANCiAgICA+IA0KICAgID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgID4gZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICA+ IA0KICAgID4gDQogICAgPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QvDQogICAgPiANCiAg ICA+IA0KICAgID4gDQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBDT01NRU5UOg0KICAgID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAgID4gDQogICAgPiAoMi4xKSAiLi4uY2FuIHVzZSBhbnkgc2lnbmlu ZyBhbGdvcml0aG0uIiBJIHByZXN1bWUgdGhlcmUgb3VnaHQgdG8gYmUgc29tZQ0KICAgID4gcXVh bGlmaWVycyBvbiBhbGxvd2VkIGFsZ29yaXRobXM/DQogICAgPiANCiAgICA+ICg0KSBhbmQgKDUp ICJUaGlzIHNwZWNpZmljYXRpb24NCiAgICA+ICAgIGRvZXMgbm90IHByb3ZpZGUgYSBtZWNoYW5p c20gZm9yIGlkZW50aWZ5aW5nIGEgc3BlY2lmaWMga2V5IGFzIHRoZQ0KICAgID4gICAgb25lIHVz ZWQgdG8gc2lnbiBKV1QgYWNjZXNzIHRva2Vucy4iDQogICAgPiANCiAgICA+IEkgZG9uJ3QgdW5k ZXJzdGFuZDsgdGhlcmUncyBhIGtleSBJRCByaWdodCB0aGVyZSBpbiB0aGUgdG9rZW4gaGVhZGVy Pw0KICAgIA0KICAgIFRoZSBjb25jZXJuIGhlcmUgaXMgYWJvdXQgaWRlbnRpZnlpbmcga2V5cyBh dXRob3JpemVkIHRvIHNpZ24gSldTIGFjY2Vzcw0KICAgIHRva2Vucy4gIFRoZSBzZXJ2ZXItcHJv dmlkZWQgbWV0YWRhdGEgdGhhdCBsaXN0cyBzdWNoIGtleXMgaGFzIGEgc2luZ2xlDQogICAgYnVj a2V0IHRoYXQgY292ZXJzIGtleXMgdXNlZCBmb3Igc2lnbmluZyBkaWZmZXJlbnQgdGhpbmdzLCBz byB5b3UgZG9uJ3QgZ2V0DQogICAgYW55IHNlY3VyaXR5IGJlbmVmaXQgZnJvbSBrZXkgaXNvbGF0 aW9uLCBhbmQgYSBjb21wcm9taXNlIG9mIGFueSBvZiB0aGUNCiAgICAob3RoZXIpIGtleXMgbGlz dGVkIGJ5IHRoZSBzZXJ2ZXIgd291bGQgYWxsb3cgdGhlIGF0dGFja2VyIHRvIHNpZ24gSldUDQog ICAgYWNjZXNzIHRva2VucyB0aGF0IGFyZSBhY2NlcHRlZCBhcyB2YWxpZC4NCiAgICANCiAgICBT byBpbiBhIHNlbnNlIHRoaXMgaXMgbm90IGFib3V0IHdoaWNoIGtleSB3YXMgYWN0dWFsbHkgdXNl ZCwgYnV0IHJhdGhlcg0KICAgIHdoaWNoIGtleSBpcyBzdXBwb3NlZCB0byBiZSB1c2VkLg0KICAg IA0KICAgID4gKDQpIEkgcHJlc3VtZSBpdCdzIGltcG9ydGFudCB0aGF0IGFueSByZXNvdXJlZSBz ZXJ2ZXIgcmVqZWN0aW9uIG9mIHRoZSB0b2tlbg0KICAgID4gc2hvdWxkIGJlIGNvbnN0YW50LXRp bWUuIElzIHRoaXMgc29tZXdoZXJlIGluIHRoZSBSRkMgdHJlZSwgb3IgZG8gd2UgbmVlZCB0bw0K ICAgID4gZXhwbGljaXRseSBzYXkgaXQgaGVyZSBhbmQvb3IgaW4gU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM/DQogICAgDQogICAgKEEgZ29vZCBxdWVzdGlvbiwgYnV0IEkgZG9uJ3QgYWN0dWFsbHkg aGF2ZSB0aGUgYW5zd2VyIGhhbmR5IGluIG1lbW9yeS4pDQogICAgDQogICAgLUJlbg0KICAgIA0K From nobody Wed Apr 14 00:32:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C0A3A11CF for ; Wed, 14 Apr 2021 00:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 pqgixJHq5cOW for ; Wed, 14 Apr 2021 00:32:26 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEAC63A11CB for ; Wed, 14 Apr 2021 00:32:25 -0700 (PDT) Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d65 with ME id sXYN2400A2sDAeJ03XYNUJ; Wed, 14 Apr 2021 09:32:23 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 14 Apr 2021 09:32:23 +0200 X-ME-IP: 90.26.9.133 To: Rifaat Shekh-Yusef , oauth References: From: Denis Message-ID: <00d5a113-0614-0338-cb06-c5ee961ffc7b@free.fr> Date: Wed, 14 Apr 2021 09:32:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8872A1C063CFD1DA64357D9E" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] April 12th Interim Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 07:32:30 -0000 This is a multi-part message in MIME format. --------------8872A1C063CFD1DA64357D9E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Rifaat, One addition that may be useful: Before the sentence: "Hannes: I was not aware of this work in ISO", there is a sentence missing: Denis: ISO/SC 27/WG 5 is just starting to work on PWI about age verification. If you are a member of ISO / SC 27/ WG 5 you can contribute.  and another addition: "at the OAuth work in Zürich in 2017" Denis: Proving you are over 18 without sharing who you are. I have presented a solution *at the OAuth work in Zürich in 2017 *and no one was interested. Denis > All, > > Take a look at the following links for the April 12th interim meeting > minutes: > https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-05-oauth > > https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-05-202104121200/ > > > Thanks to *Dick Hardt *for taking these notes. > > Regards, >  Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------8872A1C063CFD1DA64357D9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Rifaat,

One addition that may be useful:

Before the sentence: "Hannes: I was not aware of this work in ISO", there is a sentence missing:
Denis: ISO/SC 27/WG 5 is just starting to work on PWI about age verification. If you are a member of ISO / SC 27/ WG 5 you can contribute.
 and another addition: "at the OAuth work in Zürich in 2017"
Denis: Proving you are over 18 without sharing who you are. I have presented a solution at the OAuth work in Zürich in 2017 and no one was interested.

Denis

All,

Take a look at the following links for the April 12th interim meeting minutes:

Thanks to Dick Hardt for taking these notes.

Regards,
 Rifaat & Hannes

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


--------------8872A1C063CFD1DA64357D9E-- From nobody Wed Apr 14 01:26:41 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0483A147E for ; Wed, 14 Apr 2021 01:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 7fthm0L6JS8I for ; Wed, 14 Apr 2021 01:26:37 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by ietfa.amsl.com (Postfix) with ESMTP id B747C3A1496 for ; Wed, 14 Apr 2021 01:26:21 -0700 (PDT) Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d65 with ME id sYJn2400L2sDAeJ03YJn7U; Wed, 14 Apr 2021 10:18:50 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 14 Apr 2021 10:18:50 +0200 X-ME-IP: 90.26.9.133 To: Vittorio Bertocci , Murray Kucherawy , The IESG Cc: "draft-ietf-oauth-access-token-jwt@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" References: <161786294101.28888.16150454715315694485@ietfa.amsl.com> From: Denis Message-ID: Date: Wed, 14 Apr 2021 10:18:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E14EDA3AB3E9AB1E2301683B" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 08:26:39 -0000 This is a multi-part message in MIME format. --------------E14EDA3AB3E9AB1E2301683B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Murray, Thank you for your comments. I come back on one of your comments (while other comments and Vittorio's responses are deleted): > The first half of the second paragraph of Section 6 seems much more > like an interoperability issue than a privacy issue to me. I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. I would argue it is not about interop either, given that noncompliance with *the guidance given there* doesn’t impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have *for that ****guidance*, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy concern; the decision to use a JWT ATs, which ultimately makes spelling out *the guidance* necessary, is influenced by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, I am inclined to leave that part as is. The second paragraph of Section 6 (Privacy Considerations) is as follows: The client *MUST NOT* inspect the content of the access token: the    authorization server and the resource server might decide to change    token format at any time (for example by switching from this profile    to opaque tokens) hence any logic in the client relying on the    ability to read the access token content would break without    recourse. /T//he OAuth 2.0 framework assumes that access tokens are// //   treated as opaque by clients./  Administrators of authorization    servers should also take into account that the content of an access    token is visible to the client.  Whenever client access to the access    token content presents privacy issues for a given scenario, the    authorization server should take explicit steps to prevent it. As soon as there is a *MUST NOT*, this is not a *guidance *any more. Some words of this paragraph, i.e. "/any logic in the client relying on the *ability *to read the access token content/" simply recognize that the client *is able to inspect the content **of the access token*, but if it does it this is at its own risk since "/the resource server might decide to change//token format at any time (for example by switching from this profile to opaque tokens)/". The second paragraph may be rewritten by placing in front of it an important sentence that comes later on in this paragraph: The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Then after, the first sentence that includes the *MUST NOT* can be removed and the current text can be re-used after it, by shuffling the order of the remaining sentences. The end result would be the following:   The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.   Administrators of authorization servers should take into account that the content   of an access token is visible to the client. The authorization server and the resource   server might decide to change token format at any time (for example by switching from   this profile to opaque tokens) hence any logic in the client relying on the ability to read   the access token content would break without recourse. Whenever client access to the access   token content presents privacy issues for a given scenario, the authorization server should   take explicit steps to prevent it. The key benefits are the following: the *guidance *is still there, but the sentence with the "*MUST NOT*" has been removed. Denis --------------E14EDA3AB3E9AB1E2301683B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Murray,

Thank you for your comments. I come back on one of your comments (while other comments and Vittorio's responses are deleted):
   The first half of the second paragraph of Section 6 seems much more like an
   interoperability issue than a privacy issue to me.

I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. 
I would argue it is not about interop either, given that noncompliance with the guidance given there doesn’t 
impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have for that 
guidance, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy 
concern; the decision to use a JWT ATs, which ultimately makes spelling out the guidance necessary, is influenced 
by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think 
that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, 
I am inclined to leave that part as is.

The second paragraph of Section 6 (Privacy Considerations) is as follows:

   The client MUST NOT inspect the content of the access token: the
   authorization server and the resource server might decide to change
   token format at any time (for example by switching from this profile
   to opaque tokens) hence any logic in the client relying on the
   ability to read the access token content would break without
   recourse.  The OAuth 2.0 framework assumes that access tokens are
   treated as opaque by clients.  Administrators of authorization
   servers should also take into account that the content of an access
   token is visible to the client.  Whenever client access to the access
   token content presents privacy issues for a given scenario, the
   authorization server should take explicit steps to prevent it.

As soon as there is a MUST NOT, this is not a guidance any more.

Some words of this paragraph, i.e. "any logic in the client relying on the ability to read the access token content" simply recognize that
the client is able to inspect the content of the access token, but if it does it this is at its own risk since "the resource server might decide
to change token format at any time (for example by switching from this profile to opaque tokens)".

The second paragraph may be rewritten by placing in front of it an important sentence that comes later on in this paragraph:

The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.

Then after, the first sentence that includes the MUST NOT can be removed and the current text can be re-used after it, by shuffling the order
of the remaining sentences.

The end result would be the following:

  The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.  
  Administrators of authorization servers should take into account that the content
  of an access token is visible to the client. The authorization server and the resource
  server might decide to change token format at any time (for example by switching from
  this profile to opaque tokens) hence any logic in the client relying on the ability to read
  the access token content would break without recourse. Whenever client access to the access
  token content presents privacy issues for a given scenario, the authorization server should
  take explicit steps to prevent it.  

The key benefits are the following: the guidance is still there, but the sentence with the "MUST NOT" has been removed.

Denis


--------------E14EDA3AB3E9AB1E2301683B-- From nobody Wed Apr 14 05:49:26 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197363A0D97 for ; Wed, 14 Apr 2021 05:49:25 -0700 (PDT) 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 1xYEVZj0AKXr for ; Wed, 14 Apr 2021 05:49:20 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978313A0D8E for ; Wed, 14 Apr 2021 05:49:20 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u4so23133026ljo.6 for ; Wed, 14 Apr 2021 05:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TOWq2KiF6k/tTbS0B/NU0I23/R4+9947VkPc7yJls1o=; b=CDrSfT2/VLJeNF/1zfBMZioOurZjeF6OgphjOyVwVRfmCCGIQ2KoqQI2Yx/4TOau4Y BiwWyGJj1PcZ6BEsKbwQkVbnc/FfSEiBr8+QyMKynbQ4KJLJxDb2GFQ2rXqZupuSbVYA 08lQ6AfU6nWzpA5o6ykaYS6DhBhqVg4B4UUkaqtnrEkvtqu3Wey2GGTYiha3cY/5T1Bb pe3pLHbx7cOJDAmsVHNa/k2oFBHoaouuFTMPUP1E8nz8Uo1EL1C3ZBmpX9PbFqQllZ0y EPyeGPF8a64VC2r0Geiq2qtQuhAOpfQM+UWAVEd5l+liVwVidVLqTIFVoTDIcTJbHLJR 69wQ== 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=TOWq2KiF6k/tTbS0B/NU0I23/R4+9947VkPc7yJls1o=; b=AFEtZlQ9dO3GJaHrJYrbbgm85WixF1nQRYGhVaqYW+8hlxsFI1VXxZQaWApmFWwSjy TDiCKmC+C5KnvlLqs00tY8bZRbN1LmNm811LcK9+WOcQtZYrAE18YEgLudl1Dnp9LNWa mUjilugo2GCrBU66PTtEP0vksIzDutXWgsiVxViQzpsP5dLmB/oCPpDOp5zizIRBkkWk xjSbQHN/EpY07IssJ4P63vvOqRn4LzUQrylUyJgWNUdh+MTttMj7/fCEbjuJksnj1Fv8 mzonmbyVpAsiIqBNetU1u9qE1u7k9LVvfNdAXHUXOCjz431QiUnBCVxxWqZfRhSuZVfZ Mv/Q== X-Gm-Message-State: AOAM533yCCzHus/bDOO/3akejOSrufaVR4QqvAoKpxGRVA6+GJZfxXbQ tQtLtaTzrsdq1Rwlu1xo/nxhKUlwBC81Odwg7+8n6eZvzyo= X-Google-Smtp-Source: ABdhPJwXsaAPd7ht9lELHhgtRsqJEw2WlH5GncVU6kSJvhJPJjr7toKmtax5R4W+fFZREDVfPSKk/7z0HmNUqAfYt0c= X-Received: by 2002:a05:651c:106c:: with SMTP id y12mr16712078ljm.458.1618404557344; Wed, 14 Apr 2021 05:49:17 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Wed, 14 Apr 2021 08:49:06 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000be513e05bfee2ce3" Archived-At: Subject: [OAUTH-WG] WGLC for Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 12:49:25 -0000 --000000000000be513e05bfee2ce3 Content-Type: text/plain; charset="UTF-8" All, This is to start a WG Last Call on the *Security BCP *document, that ends *April 28.* https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ Please, review the document and raise any *new* concerns you have with this document. Regards, Rifaat & Hannes --000000000000be513e05bfee2ce3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This is to start a WG Last Call on= the Security BCP document, that ends April 28.
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

Please, review the document and raise any new = concerns you have with this document.

Regards,
=C2=A0Rifaat & Hannes

--000000000000be513e05bfee2ce3-- From nobody Wed Apr 14 08:23:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF863A12D1 for ; Wed, 14 Apr 2021 08:23:46 -0700 (PDT) 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, 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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz8_4074adnE for ; Wed, 14 Apr 2021 08:23:41 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55403A12F0 for ; Wed, 14 Apr 2021 08:23:10 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id k8so14644065pgf.4 for ; Wed, 14 Apr 2021 08:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=ZpOkS+aEx8HRIWpnFKhIWXrTwnAdvzzIL+tKFwuK6T0=; b=UW8+fXHMBE5zz5EUa01j543UL+ozyWMpQIGrO69JbpX9vK/MdvEhYS8u1nOdfMms9g jSFKUs92NfEzmXMfXYhDMPDDQccNed9ri2T1E0kQdYt6K88CmqMgEH1WJcSFIxkF8inG tg4gaqMe6s+kWyHdNFMMlFuoYhc0zunyUCQl7YP3r2MAy0AlUlgNI3MWDEq4lHb5p2sO UB3yQ+Cci9En/1JDlyzCHwd95h+PVMh0ANlRu9w+nWyWWiPoetjYu5hC4ZXN8QYsYLgB 967ZM1yvwaLloVpRT+gAJwZvEUpjV8g/+mCHtYPpBkQQaj3LC1P+pCnwE7JzKbZC7dQR 6H3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=ZpOkS+aEx8HRIWpnFKhIWXrTwnAdvzzIL+tKFwuK6T0=; b=n+ZGXWzwAXhIs/XEa/WYMeBPKtka6NrcNS2wRZU/IBKKO+mQT9bgEjQXhX0Dk1YXaS vOPvnRRaSuhXAAGgpyOmw6BZzgyC2YK+VeUq21BzLzRPxlyl5wFZm2pxKel35okEG3qH w0LpEyB6OMC2IH0jDOnZeaYhulCU2ww6RxZeAM3NBJihx9PvFiOybzeQzyrc3ycnFOWS 3Eb/9qKd2ZaLNrvjBloqOU8yY03/ypIHx1Qt+BFStC6qRwj6oFW/sIx10F84iRDSKtHd EBYBe2AVoC1ZNN2pwNxURCwY90UCDhwbt+Bow7oZF1KzZycSg6SFJben+rW5DGTKD82g sOPQ== X-Gm-Message-State: AOAM530fllt0OKSh5m5Eq0ByTJUIIEobW8kuXt1HQy6a68/ZRjmw5jdF gRPwesfLbRQbWxplcV/tsLqxP7l6fb9D3vvA X-Google-Smtp-Source: ABdhPJz6GhHA4qZc9T5xdJsOug29TKrUct2QwbaDCNPY9y+OJkA8AyXTHxqP48FK3q0L8w9hDoZESw== X-Received: by 2002:a05:6a00:d4f:b029:251:75bc:85af with SMTP id n15-20020a056a000d4fb029025175bc85afmr7297314pfv.61.1618413789248; Wed, 14 Apr 2021 08:23:09 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id ch21sm4328598pjb.8.2021.04.14.08.23.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 08:23:08 -0700 (PDT) From: To: "'Denis'" , "'Vittorio Bertocci'" , "'Murray Kucherawy'" , "'The IESG'" Cc: , , References: <161786294101.28888.16150454715315694485@ietfa.amsl.com> In-Reply-To: Date: Wed, 14 Apr 2021 08:23:07 -0700 Message-ID: <00b301d73142$128aae40$37a00ac0$@auth0.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01D73107.662E2030" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK6olU5aiFsYlY19s08mwnpZvepcAJUOXKHARXdSLKo0e1x4A== Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 15:23:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B4_01D73107.662E2030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, this aspect was debated at length (one example in = https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/,= there are many others) and the consensus reflected in the current text = was clear. =20 From: Denis =20 Sent: Wednesday, April 14, 2021 1:19 AM To: Vittorio Bertocci ; = Murray Kucherawy ; The IESG Cc: draft-ietf-oauth-access-token-jwt@ietf.org; oauth-chairs@ietf.org; = oauth@ietf.org Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on = draft-ietf-oauth-access-token-jwt-12: (with COMMENT) =20 Hi Murray, =20 Thank you for your comments. I come back on one of your comments (while = other comments and Vittorio's responses are deleted): The first half of the second paragraph of Section 6 seems much more = like an interoperability issue than a privacy issue to me. I agree that, taken in isolation, the connection to privacy of that = aspect is not immediately self-evident.=20 I would argue it is not about interop either, given that noncompliance = with the guidance given there doesn=E2=80=99t=20 impact what's transmitted. Nonetheless, I believe the privacy section is = the closest match we have for that=20 guidance, given its many touch points to privacy matters (the ability of = a client to inspect ATs is a privacy=20 concern; the decision to use a JWT ATs, which ultimately makes spelling = out the guidance necessary, is influenced=20 by privacy considerations; and so on and so forth). In sum, although I = agree it's not a perfect fit, I think=20 that's the best fit we have; and given that consolidating consensus for = that part has been particularly painful,=20 I am inclined to leave that part as is. =20 =20 The second paragraph of Section 6 (Privacy Considerations) is as = follows: =20 The client MUST NOT inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Administrators of authorization servers should also take into account that the content of an access token is visible to the client. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. As soon as there is a MUST NOT, this is not a guidance any more. Some words of this paragraph, i.e. "any logic in the client relying on = the ability to read the access token content" simply recognize that=20 the client is able to inspect the content of the access token, but if it = does it this is at its own risk since "the resource server might decide=20 to change token format at any time (for example by switching from this = profile to opaque tokens)". The second paragraph may be rewritten by placing in front of it an = important sentence that comes later on in this paragraph: The OAuth 2.0 framework assumes that access tokens are treated as opaque = by clients.=20 Then after, the first sentence that includes the MUST NOT can be removed = and the current text can be re-used after it, by shuffling the order of the remaining sentences. The end result would be the following: The OAuth 2.0 framework assumes that access tokens are treated as = opaque by clients. =20 Administrators of authorization servers should take into account that = the content=20 of an access token is visible to the client. The authorization server = and the resource=20 server might decide to change token format at any time (for example by = switching from=20 this profile to opaque tokens) hence any logic in the client relying = on the ability to read=20 the access token content would break without recourse. Whenever client = access to the access=20 token content presents privacy issues for a given scenario, the = authorization server should=20 take explicit steps to prevent it. =20 The key benefits are the following: the guidance is still there, but the = sentence with the "MUST NOT" has been removed. Denis =20 ------=_NextPart_000_00B4_01D73107.662E2030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Denis, this aspect was = debated at length (one example in https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGy= vJ9Hnxw/, there are many others) and the consensus reflected in the = current text was clear.

 

From: Denis = <denis.ietf@free.fr>
Sent: Wednesday, April 14, 2021 = 1:19 AM
To: Vittorio Bertocci = <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>; Murray Kucherawy = <superuser@gmail.com>; The IESG = <iesg@ietf.org>
Cc: = draft-ietf-oauth-access-token-jwt@ietf.org; oauth-chairs@ietf.org; = oauth@ietf.org
Subject: Re: [OAUTH-WG] Murray Kucherawy's No = Objection on draft-ietf-oauth-access-token-jwt-12: (with = COMMENT)

 

Hi = Murray,

 

Thank you for your comments. I come back on one of = your comments (while other comments and Vittorio's responses are = deleted):

=C2=A0=C2=A0 The first half of =
the second paragraph of Section 6 seems much more like =
an
=C2=A0=C2=A0 interoperability =
issue than a privacy issue to me.
I agree that, taken in isolation, the =
connection to privacy of that aspect is not immediately self-evident. =

I would =
argue it is not about interop either, given that noncompliance with =
the guidance given there doesn=E2=80=99t =

impact =
what's transmitted. Nonetheless, I believe the privacy section is the =
closest match we have for that =

guidance, given its many touch points to privacy =
matters (the ability of a client to inspect ATs is a privacy =

concern; =
the decision to use a JWT ATs, which ultimately makes spelling out =
the guidance necessary, is influenced =

by privacy =
considerations; and so on and so forth). In sum, although I agree it's =
not a perfect fit, I think 
that's the best fit we have; and given that =
consolidating consensus for that part has been particularly painful, =

I am =
inclined to leave that part as is.=C2=A0=C2=A0 =

 

The second paragraph of Section 6 (Privacy = Considerations) is as follows:

 

   The client = MUST NOT inspect the content of the access token: = the
   authorization server and the resource server might = decide to change
   token format at any time (for example = by switching from this profile
   to opaque tokens) hence = any logic in the client relying on the
   ability to read = the access token content would break without
   = recourse.  The OAuth 2.0 framework assumes that access tokens = are
   treated as opaque by clients.  = Administrators of authorization
   servers should also take = into account that the content of an access
   token is = visible to the client.  Whenever client access to the = access
   token content presents privacy issues for a given = scenario, the
   authorization server should take explicit = steps to prevent it.

As soon as there is a = MUST NOT, this is not a guidance any = more.

Some words of this paragraph, i.e. "any = logic in the client relying on the ability to read the access = token content" simply recognize that
the client is able = to inspect the content of the access token, but if it does it this = is at its own risk since "the resource server might decide =
to change token format at any time (for example by switching from = this profile to opaque tokens)".

The second = paragraph may be rewritten by placing in front of it an important = sentence that comes later on in this = paragraph:

The OAuth 2.0 = framework assumes that access tokens are treated as opaque by clients. =

Then after, the first sentence that = includes the MUST NOT can be removed and the current text can be = re-used after it, by shuffling the order
of the remaining = sentences.

The end result would be the = following:

  The OAuth 2.0 framework assumes that = access tokens are treated as opaque by clients.  
  = Administrators of authorization servers should take into account that = the content
  of an access token is visible to the client. The = authorization server and the resource
  server might decide to = change token format at any time (for example by switching from =
  this profile to opaque tokens) hence any logic in the client = relying on the ability to read
  the access token content would = break without recourse. Whenever client access to the access
  = token content presents privacy issues for a given scenario, the = authorization server should
  take explicit steps to prevent = it.  

The key benefits are the following: = the guidance is still there, but the sentence with the = "MUST NOT" has been = removed.

Denis

 

------=_NextPart_000_00B4_01D73107.662E2030-- From nobody Wed Apr 14 08:39:28 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED58B3A13D2 for ; Wed, 14 Apr 2021 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 nHxHB9tOHTOH for ; Wed, 14 Apr 2021 08:39:22 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141533A13DE for ; Wed, 14 Apr 2021 08:39:21 -0700 (PDT) Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d77 with ME id sffH2400v2sDAeJ03ffJLw; Wed, 14 Apr 2021 17:39:20 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 14 Apr 2021 17:39:20 +0200 X-ME-IP: 90.26.9.133 To: vittorio.bertocci@auth0.com, 'Vittorio Bertocci' , 'Murray Kucherawy' , 'The IESG' Cc: draft-ietf-oauth-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org References: <161786294101.28888.16150454715315694485@ietfa.amsl.com> <00b301d73142$128aae40$37a00ac0$@auth0.com> From: Denis Message-ID: Date: Wed, 14 Apr 2021 17:39:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <00b301d73142$128aae40$37a00ac0$@auth0.com> Content-Type: multipart/alternative; boundary="------------D139FA4AE264743A00A11C6C" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 15:39:27 -0000 This is a multi-part message in MIME format. --------------D139FA4AE264743A00A11C6C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Vittorio, Since Murray raised the concern, I have responded. A *guidance *section should not contain any *MUST*, *SHALL*, *MUST *or *SHALL NOT.* I believe that my proposal is a fair compromise on this topic by keeping all the sentences, except the first half of the second paragraph of Section 6, as noticed by Murray. Denis > Hi Denis, this aspect was debated at length (one example in > https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/ > , > there are many others) and the consensus reflected in the current text > was clear. > > *From:* Denis > *Sent:* Wednesday, April 14, 2021 1:19 AM > *To:* Vittorio Bertocci > ; Murray Kucherawy > ; The IESG > *Cc:* draft-ietf-oauth-access-token-jwt@ietf.org; > oauth-chairs@ietf.org; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Murray Kucherawy's No Objection on > draft-ietf-oauth-access-token-jwt-12: (with COMMENT) > > Hi Murray, > > Thank you for your comments. I come back on one of your comments > (while other comments and Vittorio's responses are deleted): > >    The first half of the second paragraph of Section 6 seems much > more like an > >    interoperability issue than a privacy issue to me. > > I agree that, taken in isolation, the connection to privacy of that > aspect is not immediately self-evident. > I would argue it is not about interop either, given that noncompliance > with *the guidance given there* doesn’t > impact what's transmitted. Nonetheless, I believe the privacy section > is the closest match we have *for that * > *guidance*, given its many touch points to privacy matters (the ability of a > client to inspect ATs is a privacy > concern; the decision to use a JWT ATs, which ultimately makes > spelling out *the guidance* necessary, is influenced > by privacy considerations; and so on and so forth). In sum, although I > agree it's not a perfect fit, I think > that's the best fit we have; and given that consolidating consensus > for that part has been particularly painful, > I am inclined to leave that part as is. > > The second paragraph of Section 6 (Privacy Considerations) is as follows: > > The client *MUST NOT* inspect the content of the access token: the >    authorization server and the resource server might decide to change >    token format at any time (for example by switching from this profile >    to opaque tokens) hence any logic in the client relying on the >    ability to read the access token content would break without >    recourse. /The OAuth 2.0 framework assumes that access tokens are >    treated as opaque by clients./  Administrators of authorization >    servers should also take into account that the content of an access >    token is visible to the client.  Whenever client access to the access >    token content presents privacy issues for a given scenario, the >    authorization server should take explicit steps to prevent it. > > As soon as there is a *MUST NOT*, this is not a *guidance *any more. > > Some words of this paragraph, i.e. "/any logic in the client relying > on the *ability *to read the access token content/" simply recognize that > the client *is able to inspect the content of the access token*, but > if it does it this is at its own risk since "/the resource server > might decide > to change token format at any time (for example by switching from this > profile to opaque tokens)/". > > The second paragraph may be rewritten by placing in front of it an > important sentence that comes later on in this paragraph: > > The OAuth 2.0 framework assumes that access tokens are treated as > opaque by clients. > > Then after, the first sentence that includes the *MUST NOT* can be > removed and the current text can be re-used after it, by shuffling the > order > of the remaining sentences. > > The end result would be the following: > >   The OAuth 2.0 framework assumes that access tokens are treated as > opaque by clients. >   Administrators of authorization servers should take into account > that the content >   of an access token is visible to the client. The authorization > server and the resource >   server might decide to change token format at any time (for example > by switching from >   this profile to opaque tokens) hence any logic in the client relying > on the ability to read >   the access token content would break without recourse. Whenever > client access to the access >   token content presents privacy issues for a given scenario, the > authorization server should >   take explicit steps to prevent it. > > The key benefits are the following: the *guidance *is still there, but > the sentence with the "*MUST NOT*" has been removed. > > Denis > --------------D139FA4AE264743A00A11C6C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Vittorio,

Since Murray raised the concern, I have responded. A guidance section should not contain any MUST, SHALL, MUST or SHALL NOT.
I believe that my proposal is a fair compromise on this topic by keeping all the sentences, except the first half of the second paragraph
of Section 6, as noticed by Murray.

Denis

Hi Denis, this aspect was debated at length (one example in https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/, there are many others) and the consensus reflected in the current text was clear.

 

From: Denis <denis.ietf@free.fr>
Sent: Wednesday, April 14, 2021 1:19 AM
To: Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>; Murray Kucherawy <superuser@gmail.com>; The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-access-token-jwt@ietf.org; oauth-chairs@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

 

Hi Murray,

 

Thank you for your comments. I come back on one of your comments (while other comments and Vittorio's responses are deleted):

   The first half of the second paragraph of Section 6 seems much more like an
   interoperability issue than a privacy issue to me.
I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. 
I would argue it is not about interop either, given that noncompliance with the guidance given there doesn’t 
impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have for that 
guidance, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy 
concern; the decision to use a JWT ATs, which ultimately makes spelling out the guidance necessary, is influenced 
by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think 
that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, 
I am inclined to leave that part as is.  

 

The second paragraph of Section 6 (Privacy Considerations) is as follows:

 

   The client MUST NOT inspect the content of the access token: the
   authorization server and the resource server might decide to change
   token format at any time (for example by switching from this profile
   to opaque tokens) hence any logic in the client relying on the
   ability to read the access token content would break without
   recourse.  The OAuth 2.0 framework assumes that access tokens are
   treated as opaque by clients.  Administrators of authorization
   servers should also take into account that the content of an access
   token is visible to the client.  Whenever client access to the access
   token content presents privacy issues for a given scenario, the
   authorization server should take explicit steps to prevent it.

As soon as there is a MUST NOT, this is not a guidance any more.

Some words of this paragraph, i.e. "any logic in the client relying on the ability to read the access token content" simply recognize that
the client is able to inspect the content of the access token, but if it does it this is at its own risk since "the resource server might decide
to change token format at any time (for example by switching from this profile to opaque tokens)".

The second paragraph may be rewritten by placing in front of it an important sentence that comes later on in this paragraph:

The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.

Then after, the first sentence that includes the MUST NOT can be removed and the current text can be re-used after it, by shuffling the order
of the remaining sentences.

The end result would be the following:

  The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.  
  Administrators of authorization servers should take into account that the content
  of an access token is visible to the client. The authorization server and the resource
  server might decide to change token format at any time (for example by switching from
  this profile to opaque tokens) hence any logic in the client relying on the ability to read
  the access token content would break without recourse. Whenever client access to the access
  token content presents privacy issues for a given scenario, the authorization server should
  take explicit steps to prevent it.  

The key benefits are the following: the guidance is still there, but the sentence with the "MUST NOT" has been removed.

Denis

 


--------------D139FA4AE264743A00A11C6C-- From nobody Wed Apr 14 13:55:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABEC3A1F83 for ; Wed, 14 Apr 2021 13:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lnbkCNhKC5Hy for ; Wed, 14 Apr 2021 13:55:44 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294393A1F7D for ; Wed, 14 Apr 2021 13:55:43 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id f41so12098240lfv.8 for ; Wed, 14 Apr 2021 13:55:43 -0700 (PDT) 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=hbeiOGb5eic8F1eeQ0pkkErTvoZ5oIauVeiuc5qM1gA=; b=c+KSmYCd5eAOtD7x3j3GGHILN2ABYsKUek5OfiSmcnMpj5DwrfYPB296fjWX6FUmb/ Mygul3AWpulfBxrBRjfZN3qEVtZrfPEimLkWrreIn79m4J9TjHgPZ4uI7aM1pjoibl9C CSQVCF/+Uv6k4FNF3dMCeSeR/uYdFhtRszvvdPfXVDzvOfszGYYZLx1TZRPCJJyAyxps tyL3VlUUQ4NuFAN8tVhp+Cy5nXDJV5vnFRL1SEvmLtItYQxf5HuqrN79pqrCEMqVSu9o YLdOoQicb2GaSuhtaZQJk3Nta/mv0RnF5NOJC3VHZjtgWR1IFpK/2PCOJwvBVZzKoaaO z76Q== 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=hbeiOGb5eic8F1eeQ0pkkErTvoZ5oIauVeiuc5qM1gA=; b=qRxNgWck2CpROdO8UH9DmdwEuRSodh+01Q29M7/aLovr6ufWFbL8mpvvN7nT4BmHHz /7xfEztM/8wVPkDPT/ynFp0ZN336T0lc1kz0hXVaRb1gFdhnkrmlquyDRpmN5jTEqZa/ muCpNc2W8vhpY6+JtkGZmGbJjCIyII2VS2Zrlk3q42dWSuwd8G+ilpKgMt4s3Qf77Sn6 Iu7negauL9y1gCepxx4Ag/W887jqxUH7+NAO36prh5NSIqpz7Ph7ybCot1EoFrX8u4Og ji50GuCTr+v3muLNaMIqexpxOuk4OufyGCBveswNKVfhS0ae/LsQKu9l5j+WCQSC3FKK 0fFw== X-Gm-Message-State: AOAM531uW5dQbWokZrfb1vwRhVtOL9UXy+hNw6l1zteDIxvFKImJpBIS sRtugmWwFwD10jIzcNlwUl9djIn7MkVUvS1zTdr6MyLmlnbkT6GvWOWMW0bkKSIB8aRh9RPcqU2 nuruZBDFuAtyGvg== X-Google-Smtp-Source: ABdhPJxpBFwEuCtjAeeiNaoUj7OSJIIbDD6+IXa97mKHOVX327B51nGG2XMFgTJnwpLtBzKyCxRLrjIu442LaMP2Sas= X-Received: by 2002:a05:6512:1318:: with SMTP id x24mr47165lfu.376.1618433741564; Wed, 14 Apr 2021 13:55:41 -0700 (PDT) MIME-Version: 1.0 References: <161755926036.31657.529017576412672874@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 14 Apr 2021 14:55:14 -0600 Message-ID: To: Vittorio Bertocci Cc: Francesca Palombini , The IESG , "draft-ietf-oauth-access-token-jwt@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000424b2705bff4f828" Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 20:55:49 -0000 --000000000000424b2705bff4f828 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2021 at 1:19 AM Vittorio Bertocci wrote: > > 3. ----- > > [...] > > Formally, I agree that JOSE would also work. The choice of media type > derives from https://tools.ietf.org/html/rfc7519#section-10.3.1. There is > no functional difference between JWS and JWE in the intent a client has > when calling an RS, here there's not much to be gained in using different > MIME types for those cases. Furthermore, whereas developers are familiar > with the term "JWT", both from direct use and thanks to the popularity of > OpenID Connect (which does use application/jwt), terms like JWS, JWE or > JOSE wouldn't be as promptly understood as JWT. Throughout the discussion= s > in the last couple of years, the consensus on the use of at+jwt was solid= - > my hope is that will make intuitive sense for implementers, too. > I think the use of 'at+jwt' was also (or even primarily) motivated by explicitly typing per the JWT BCP https://datatracker.ietf.org/doc/html/rfc8725#section-3.11 as a means of preventing Cross-JWT Confusion https://datatracker.ietf.org/doc/html/rfc8725#section-2.8 --=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._ --000000000000424b2705bff4f828 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 14, 2021 at 1:19 AM Vitto= rio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 =C2=A03. -----
> [...]

Formally, I agree that JOSE would also work. The choice of media type deriv= es from https://tools.ietf.org/html/rfc7519#secti= on-10.3.1. There is no functional difference between JWS and JWE in the= intent a client has when calling an RS, here there's not much to be ga= ined in using different MIME types for those cases. Furthermore, whereas de= velopers are familiar with the term "JWT", both from direct use a= nd thanks to the popularity of OpenID Connect (which does use application/j= wt), terms like JWS, JWE or JOSE wouldn't be as promptly understood as = JWT. Throughout the discussions in the last couple of years, the consensus = on the use of at+jwt was solid- my hope is that will make intuitive sense f= or implementers, too.

I think the use o= f 'at+jwt' was also (or even primarily) motivated by explicitly typ= ing per the JWT BCP https://datatracker.ietf.org/doc/html/rfc8725#section-3.11<= /a> as a means of preventing Cross-JWT Confusion https://datatracker.ietf.org/do= c/html/rfc8725#section-2.8=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000424b2705bff4f828-- From nobody Thu Apr 15 00:04:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284473A127E for ; Thu, 15 Apr 2021 00:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackmanit.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3566Y7DfYLpX for ; Thu, 15 Apr 2021 00:04:25 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9F13A0FF7 for ; Thu, 15 Apr 2021 00:04:24 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id a4so22208055wrr.2 for ; Thu, 15 Apr 2021 00:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=to:from:subject:message-id:date:user-agent:mime-version; bh=ZneqGhEc5BcIiaAhRTsbsCv++ZRYf9GpWOHrZIEUVrU=; b=Zi8bT6vfJ6x9ITObhftPK7Jsh3W17KFS4ytxIDRhCThn2o2kWSMOopW8JVlruGzTZV FIDbU/O4fSl4KBPnBCCpfrFajkpDhFeEFySYmRtUApHyZDD9eo6AVDk+eAyF4rrKlDD0 5q5WlmfktA4X4NfrBACkAaScrOp32bweH3jc0F5Q+iua6KdSlJZpfpYM0Ln71g85fBf5 ei64MRj6hIvec6Hc2JgJ9vQP65lzxRkfeByf3Un2eanLjv2VGk34kazYhb/0KdTvhOz3 6rW0+Y5KklFkY59R97wPvc+LsKsjvQHKReEaczAkd0iQxtGRAzPe37pwhKH1iapf5qMk UDPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=ZneqGhEc5BcIiaAhRTsbsCv++ZRYf9GpWOHrZIEUVrU=; b=RtgfNAFMoXuF7OWTJ4K7UhGTSU+3XTnaK/0guDo7cJI0X4HUjaQAjQueqtGYFvfCBL VJTawybMIhhY+3QfD18/ALobKIhF9BRhvFQ6RnWzOL9g3dC1zf5hq5DyVwAJ+TnI6v19 5q5ZefneLGhdwy25HzkQcI2lvWx5UnQWPF1If3nhEjmDPuMxfurMFESrMgwGJUBHX6k0 rjsIqAlG0jntyV8GzFbn39qSzD+abJhtrIt1ZDkV+5X+hi9u/bFK9uotM0z1JZlJIxXJ BQWcWqw4DG4TH8dJ4+2gZZaNB8ZiegIByon5dohMt91eQNzE4Um9MDpjL5NNMvY2TN4n I8xA== X-Gm-Message-State: AOAM533mQnET7mct4ZkMbtFVKS5y5pS5T4X5tJ1e3jwZSwI1jvY4ap4t mTRx20TkBU4nQq2lJbnWtVlI6VQ/C1z3+PJV X-Google-Smtp-Source: ABdhPJyCi0NPYjQ2tRBnApKMmOu8OWH+5IJYwlP88sokAMOPeTmQB4sDaKpx6VrLufk4RWdxbVkvdg== X-Received: by 2002:adf:f186:: with SMTP id h6mr1704770wro.89.1618470261193; Thu, 15 Apr 2021 00:04:21 -0700 (PDT) Received: from [10.10.11.6] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id e9sm1667869wrs.84.2021.04.15.00.04.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Apr 2021 00:04:20 -0700 (PDT) To: oauth From: Karsten Meyer zu Selhausen Message-ID: <634f7b10-bb26-e05c-7d79-566c893c32b6@hackmanit.de> Date: Thu, 15 Apr 2021 09:04:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ROpBhCmA4xT3Cd3fBoZAEyJQPluaaF7ot" Archived-At: Subject: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 07:04:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ROpBhCmA4xT3Cd3fBoZAEyJQPluaaF7ot Content-Type: multipart/mixed; boundary="Qd5UJQ2aNxv58e6C72Pv9LCMSvEzV0PaQ"; protected-headers="v1" From: Karsten Meyer zu Selhausen To: oauth Message-ID: <634f7b10-bb26-e05c-7d79-566c893c32b6@hackmanit.de> Subject: Call for Feedback on draft-ietf-oauth-iss-auth-resp-00 --Qd5UJQ2aNxv58e6C72Pv9LCMSvEzV0PaQ Content-Type: multipart/alternative; boundary="------------0DF87A89F6A1503ADA2B7C34" Content-Language: en-US This is a multi-part message in MIME format. --------------0DF87A89F6A1503ADA2B7C34 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, the latest version of the security BCP references=20 draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to mix-up attacks.= There have not been any concerns with the first WG draft version so far: = https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ I would like to ask the WG if there are any comments on or concerns with = the current draft version. Otherwise I hope we can move forward with the next steps and hopefully=20 finish the draft before/with the security BCP. Best regards, Karsten --=20 Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Is your OAuth or OpenID Connect client vulnerable to the severe impacts o= f mix-up attacks? Learn how to protect your client in our latest blog pos= t on single sign-on: https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-= against-mix-up-attacks Hackmanit GmbH Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz --------------0DF87A89F6A1503ADA2B7C34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,=

the latest version of= the security BCP references draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to mix-up attacks.

There have not been a= ny concerns with the first WG draft version so far: https://datatracker.ietf.or= g/doc/draft-ietf-oauth-iss-auth-resp/

I would like to ask t= he WG if there are any comments on or concerns with the current draft version.

Otherwise I hope we c= an move forward with the next steps and hopefully finish the draft before/with the security BCP.

Best regards,
Karsten

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

Is your OAuth or OpenID Connect client vulnerable to the severe impacts o=
f mix-up attacks? Learn how to protect your client in our latest blog pos=
t on single sign-on:
https:=
//www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-agains=
t-mix-up-attacks

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

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
--------------0DF87A89F6A1503ADA2B7C34-- --Qd5UJQ2aNxv58e6C72Pv9LCMSvEzV0PaQ-- --ROpBhCmA4xT3Cd3fBoZAEyJQPluaaF7ot Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEDtqqxgHePX8hI3D4RTXA59sW8UgFAmB35XIFAwAAAAAACgkQRTXA59sW8UhJ MQ//TuSYwsQp/VSRjjZd/nkpqwJvArgio839O7p5DfI8cUZ41FdYnMk/TGXriOB1/93mx2O9Fme8 Yl5Li6oDm4VmEO06Lk8wyXd51LwZQ6mu2niQOCh0ONbu5/di3LfQu0AENd3OBW9XM278VRrMhfd4 b/8LJTkI0jBveRWKU43T5YNJ7Jze++Z0PqfZSPZuMgUpIscp8O4k2Fc+Uzqkn8cWZlEP/f2K/uQl oV1FIWDaP4qr7iYtz6QXmtEqcxu6iqBoKK6JkkE0VELo42/MGmYKWcYm3aMyxUXM7LxrEe9JXEpc knM5i45kqfMduH8+vatSKPjaGi+ndecb0oAK2uYa9wjtZHHo+sz0QFpZ84+FPqRRTaD0RshrFd5Z TCBAT8TYuGyKbcH5akhD1hWF1/JJavsqfZuJDPW+J34FlmmIBTlscgU+poKrItad/6uo9qNENmi8 JEziTgZdD+URrmyc/XesB0rxMsQ3keFPRCokp4K4metL5OdR78ofuFGt6QgGc3IcVEJTaor/KDLk drZVm0x9tWgud+58iWFNJSR/HeI6QERgU1ii8nKyXCHQ/8RACTvZWw2pGb+utfVZtpNwB5YWFH+d a7jC8z+YxMSOrWaE34O/WGAhutjYcD3P/lKi1S79imdbtvKVDu0tITjRpRWwuNjD/tyrBt6ARz5K S4k= =1WoD -----END PGP SIGNATURE----- --ROpBhCmA4xT3Cd3fBoZAEyJQPluaaF7ot-- From nobody Thu Apr 15 13:41:33 2021 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 6C23B3A2E2B; Thu, 15 Apr 2021 13:41:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Hannes.Tschofenig@gmx.net, The IESG , draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161851928337.13297.1994990913988085366@ietfa.amsl.com> Date: Thu, 15 Apr 2021 13:41:23 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' to Proposed Standard (draft-ietf-oauth-jwsreq-34.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 20:41:24 -0000 The IESG has approved the following document: - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' (draft-ietf-oauth-jwsreq-34.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Technical Summary The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. Working Group Summary The document changes the encoding of the parameters in the authorization request to a JSON-based encoding. After the second IESG review, the WG removed the faceted media type registration. This document has history of multiple IESG reviews: 2021-04 => returned for third IESG telechat (AD#3) 2020-09 => returned to WG 2020-09 => procedural issues raised on the requested IANA actions 2020-08 => returned for second IESG telechat (AD#3); enough positions to pass; in RFCeditor queue [responsible AD changes to AD#3] [note: mistakes in state changes between approved/IESG review made in datatracker] [responsible AD change to AD#2] 2017-07 => First telechat review (AD#1) Document Quality The request object and the request uri is an optional feature in the OpenID Connect Core specification and two working groups in the OpenID Foundation (namely the Modrna WG and the FAPI WG) are considering using this extension. The following implementations are available. As part of the OpenID Foundation certification program the following implementations of OpenID Connect Core indicate support for this functionality: * CZ.NIC mojeID, * Thierry Habart's SimpleIdentitySever v.2.0.0, * Roland Hedberg's pyoidc 0.7.7, * Peercraft ApS's Peercarft, * MIT's MITREidConnect, * Gluue Server 2.3, * Filip Skokan's node-oidc pre supports. Authlete (https://www.authlete.com/), a commerical, closed source server implementation, has also implemented this specification and is offering it. There is an open source implementation from NRI in PHP and Scala. NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc IdentityServer implements JAR: https://github.com/IdentityServer Personnel Hannes Tschofenig is the document shepherd Roman Danyliw is the responsible area director From nobody Sun Apr 18 10:52:51 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162583A214A for ; Sun, 18 Apr 2021 10:52:50 -0700 (PDT) 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 sb_qFwzns6e2 for ; Sun, 18 Apr 2021 10:52:45 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD2B3A2147 for ; Sun, 18 Apr 2021 10:52:45 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id r20so36714863ljk.4 for ; Sun, 18 Apr 2021 10:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XSCyoSXphsqIkdNK+VQvpO2LL15vLBBSBkJiyA6H7cc=; b=CtwcoJTMG0XYwNGFU+wEvOn560zE95b15vZgEi/if2818SaW/A2kmZwMPxrUFq1cXT 7EY4y0XgDz6EnhvGOrTuqbGhL/0Qm36DXFxSPupdhJSjAalhJZ/d/ltNGQEvhWha+Rd1 1I94UvYyhpqDZeCguYveP1mB5XXYTYE2rrziAdDzTlYgX4GGnX6uZkQ7GQDeHA0Hr3r0 JQLFKz5PGzxh7/aCMwHT6RobvmKUEeDfkPXVMWeIgG1e2ZCXryxB7DtIGIRZkNQOZ+bo EdaeIf33IMhprDxoUBkO+Jk6/MOgrN7Tfa0gBpWekSXL3Bf5tSpQi51FIcKaGKyPwpai 3cWw== 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=XSCyoSXphsqIkdNK+VQvpO2LL15vLBBSBkJiyA6H7cc=; b=BJ1gBZHzO1A8BVTS4qs+XXYJvTHT/+lmDyfBDDb1lrKKsEbea78AKtwp+2qlohOJOo UVRiB4ckepbMoi9tuhNtbQ7ce2lWceRZTWcf9niucX4rR0yBtRzELPpJVZVm6qgeFkeX GFDwqRFwK8imkWMIfyxTLOhIuzbydUlXv4Jd7MDTgK0eTht2JwGJ5v8vtGMjApgP74Ni XQWjS+VEweCMyiq3eifWHRHu4jeEQv9uw5ta8yMiPBCfM18n8x8c0B/uaVpnO9BqlcfT NoncGZ2WQWy2q/WpIhKSr9T3P3ayn0ZF0t+j6YWpbBZpxAM9iGi/DshKHHqN3rqBT+Am NHJQ== X-Gm-Message-State: AOAM531M4hA/K8N+PRuuxuCVBszbwvBdUz02lX0haik0ZmD9jHi/b1c3 b8HlaOyuXiUL7eGWoeF0d7r3Ym6qXKYjE2+cPIN0MnIexLM= X-Google-Smtp-Source: ABdhPJzrS/EbpO+ue4rjO750NffnVhghym2MyGRqpjtcM6hJYeamCl82X48IPAdkD2oEQvseGGmk7rHJzan6GIN6tgs= X-Received: by 2002:a2e:b537:: with SMTP id z23mr8901910ljm.350.1618768357230; Sun, 18 Apr 2021 10:52:37 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sun, 18 Apr 2021 13:52:26 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000e813fb05c042e054" Archived-At: Subject: [OAUTH-WG] OAuth WG Interim Meeting - Identity Use Cases in Browser Catalog X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 17:52:50 -0000 --000000000000e813fb05c042e054 Content-Type: text/plain; charset="UTF-8" All, The coming OAuth WG Interim meeting is this coming* Monday, April 19th, at 12:00 pm EDT.* The meeting will be focused on the *Identity Use Cases in Browser Catalog * document: https://datatracker.ietf.org/doc/draft-bertocci-identity-in-browser/ The following link has links to the slide and draft and will be used to capture the notes and attendees: https://codimd.ietf.org/notes-ietf-interim-2021-oauth-06-oauth?both *Webex Meeting Link:* https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b Regards, Rifaat & Hannes --000000000000e813fb05c042e054 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The coming OAuth WG Interim meeting is this co= ming=C2=A0Monday, April 19th, at 12:00 pm EDT.
The meeting = will be focused on the Identity Use Cases in Browser Catalog documen= t:

The following link has links = to the slide and draft and will be used to capture the notes and attendees:=


--000000000000e813fb05c042e054-- From nobody Sun Apr 18 17:53:24 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EEE3A15B0 for ; Sun, 18 Apr 2021 17:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 0c__4-FR6a40 for ; Sun, 18 Apr 2021 17:53:17 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3D63A15AF for ; Sun, 18 Apr 2021 17:53:17 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id i10so17413193lfe.11 for ; Sun, 18 Apr 2021 17:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UqopO9JMOQvjdMZ9TAm8i4Pk6+TLi698mZ0U5tTfyI8=; b=Ur1NK2v+vb9LGRmlF3IYdlTk+EvG21iRES7wID5r3RD1gsaqjUVan+XfYmgHILGaWY kgStkQe3p9z5YcSfuMoxz24v/VBbM08aFeN+i8Y+PJDuvffBV9+145VizMhTkZEH0aa/ /4dVYIqf6W8me9HigKXuMCdKmvqmyHK0OA5NhPI2BNTez7AUxsUMCPQAnsCTH8GspNqY 0rajjmTnEEBtp93c/varlVxJTtZJJ1MG7NjWPUa5sa5xNkhFCbIbW3/ruPUktzQlZ8EV d3ZzwDiQ4vJXTt1pbNhA5H5qsvLtVCrsf0PQZvd1IQ9Y3u3GA0hr3G3QFR1+NimLGit1 5p4Q== 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=UqopO9JMOQvjdMZ9TAm8i4Pk6+TLi698mZ0U5tTfyI8=; b=Q8LFaRmZOuw/1nQ89jJeaFP7rPg7tMkfbsDi9tikblaGE2h+vXGFIs7EGfkSAomRLb 4SQyZp/KACaIOfCoMOpLpE9E7FTeg3vbNWDXj0/IND8B38m04LnJCtZxNygruOWSEPUB 0z8Pm3TeMgmpXHFQpd5NnirZ5IsUk2EjQXFacXFI4sU9DoMJ0qqCOdtDTCOoySq+aOCP kTXIQ9iPi+bGsvnm3G5P9y7vDAVD6x4WWm+5I844AXDNQieJQRfLwDVK/uOyI2o7fn1m SkQQDrU2XyLLQsuAQtrlrhKzvMgtkBBv3vDSC/Dxf+qG/4qroJ+G/hs6DfKvghc7fR9k msmg== X-Gm-Message-State: AOAM532xY3IXyKd2S8M3v6Pyu6M1iq5txBHsjQgDRS2ymd7VAc+MIX3U OZAO7NcuZ7OOBmLm7ZHDegVycLRehfMQHYfZseHOZwywgcQ= X-Google-Smtp-Source: ABdhPJywNcnCPopOVO43fbVkbxGisCCpZiFY6M4K2SI0sKf09oFCNj+ibxCWFgvDhNeY7VJNbRlRS76YiUKquubTG+A= X-Received: by 2002:ac2:5932:: with SMTP id v18mr3555876lfi.379.1618793594369; Sun, 18 Apr 2021 17:53:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Sun, 18 Apr 2021 20:53:03 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000028376405c048c123" Archived-At: Subject: Re: [OAUTH-WG] OAuth WG Interim Meeting - Identity Use Cases in Browser Catalog X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 00:53:22 -0000 --00000000000028376405c048c123 Content-Type: text/plain; charset="UTF-8" The slides for this meeting: https://datatracker.ietf.org/meeting/interim-2021-oauth-06/materials/slides-interim-2021-oauth-06-sessa-ietf-browser-changes-and-identity-00 Regards, Rifaat On Sun, Apr 18, 2021 at 1:52 PM Rifaat Shekh-Yusef wrote: > All, > > The coming OAuth WG Interim meeting is this coming* Monday, April 19th, > at 12:00 pm EDT.* > The meeting will be focused on the *Identity Use Cases in Browser Catalog > *document: > https://datatracker.ietf.org/doc/draft-bertocci-identity-in-browser/ > > The following link has links to the slide and draft and will be used to > capture the notes and attendees: > https://codimd.ietf.org/notes-ietf-interim-2021-oauth-06-oauth?both > > *Webex Meeting Link:* > https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b > > Regards, > Rifaat & Hannes > > --00000000000028376405c048c123 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Rifaat


On Sun, Apr 18, 2021= at 1:52 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
All,

The coming OAuth WG = Interim meeting is this coming=C2=A0Monday, April 19th, at 12:00 pm EDT.=
The meeting will be focused on the Identity Use Cases in B= rowser Catalog document:
=
The following link has links to the slide and draft and will= be used to capture the notes and attendees:

<= div>
--00000000000028376405c048c123-- From nobody Mon Apr 19 09:21:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46903A3942 for ; Mon, 19 Apr 2021 09:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 0t3FR_ZSC3Y0 for ; Mon, 19 Apr 2021 09:21:01 -0700 (PDT) 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 DB7713A3944 for ; Mon, 19 Apr 2021 09:21:00 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id k4-20020a7bc4040000b02901331d89fb83so6282128wmi.5 for ; Mon, 19 Apr 2021 09:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=ER4oVkzIgzlESRm13ch6iihWDt7It396Y+RohFZdgqs=; b=q8iHxYh11ObrJrN+mVm7LJKyGwaRL8eEwTfoPJEHY8di3s3nCq/hFLdUWkcgAk12u4 QEuCXNMHN9ZhB6b0KzUpM9E3YBJkJe4DStorx98Q7aoyeEGvgYEYNPz/LQ+oCrgwzyHs pm4KYThoYFjEhlRZia5GbsK7cdnMa+X58uh0oLiI7ZcquTIYlN4c1vVa98lR5WCaLoX2 27Hha16eJfoiAJ6zBmJRPVEnuDEtHv09JK5kWhIWxVIe9ZTiEDVN0902ksXdF1X8rtpI guy68e2kpVWu3ujgg90ugd/s/vdimdWGc9WeIlTLeyCPiRPvYqf3IuNMVvm0BxMkmTwb 9+2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=ER4oVkzIgzlESRm13ch6iihWDt7It396Y+RohFZdgqs=; b=QcCtLOb1vx0Zt3GckJkR5Y3XgNqXl+k1/3zVD9Y5qv4/o4h0bs6D98wgDcbmqzvDTQ CzZ7LAbrW7GwST6dQMMTdlWQRgX7Mz/Cj+J8pnXAZbdpR0i6eUKlXuuDQo3fnOKbb1mn 3jbnxqAiRnaiGBHHILlISS/4Nj3gusz09nYr+blqlgMHGR52dAhjFVYjHjO1xz0wK1VV dZsqpBZJEbQYAkpS7qWLYBeLQ0mAHzz99DdFYNbexGuDOS4Nc+icE2tqXOKUqvEFVnRp ifWhX5EfDAr/E6iyhaWC8rdYTlz169L2qXmsc4ecI5h3B6dU8MWMrOq5Hx6qBRLySMAX 9bsg== X-Gm-Message-State: AOAM533Hqg6Tqqacbb6P51qHAKMvrxLmC8EfwlsElY4IJ6M+HQnrv0zC JTfOeisnS0aOczff9u3IUyhQ3l/lnu3bL3px X-Google-Smtp-Source: ABdhPJwtNXH9eVgf81DRC+AV7fDPzjXZnhXKrTdtA1XBVZdUTzPEdrIEHWb1T7D8h6ESzyzIN/WHIQ== X-Received: by 2002:a05:600c:24c:: with SMTP id 12mr23010088wmj.185.1618849257754; Mon, 19 Apr 2021 09:20:57 -0700 (PDT) Received: from [192.168.71.138] (p549ee0f6.dip0.t-ipconnect.de. [84.158.224.246]) by smtp.gmail.com with ESMTPSA id w7sm17576368wru.87.2021.04.19.09.20.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 09:20:57 -0700 (PDT) From: Torsten Lodderstedt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <6CEA35A4-EF22-498E-8E32-4106329285A7@lodderstedt.net> Date: Mon, 19 Apr 2021 18:20:56 +0200 Cc: Justin Richer , Brian Campbell To: oauth X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [OAUTH-WG] authorization_details token request parameter and comparison in RAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 16:21:06 -0000 Hi all, in the recent RAR session, we started a discussion about an = authorization_details token request parameter.=20 This parameter would allow us to solve several outstanding topics:=20 - Let the client determine what privileges to assign to the first access = token issued in exchange for an authorisation code - Downscoping privileges of pre-existing grant (code, refresh token, = CIBA, device) - Request access tokens with client credentials =20 We also discussed the challenge of comparing requested and already = granted authorization details and how this relates to the way = application/API specific logic might be integrated into an AS. In order to continue the discussion, we would like to share the = following PR with you for discussion:=20 https://github.com/oauthstuff/draft-oauth-rar/pull/66 It introduces the authorization_details token request parameter and = gives examples of how comparison could be performed in this context.=20 Please give us feedback on the PR to drive the discussion.=20 best regards, Torsten. =20 From nobody Mon Apr 19 14:05:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417933A26C8 for ; Mon, 19 Apr 2021 14:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AEW_XGq11Y5 for ; Mon, 19 Apr 2021 14:05:38 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AA03A26CA for ; Mon, 19 Apr 2021 14:05:37 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id o16so41029999ljp.3 for ; Mon, 19 Apr 2021 14:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tuUam1gTHo8n3NCFUrTVzYMm6rWoqHExP7UyQrdJBKI=; b=t5rgj+LnAcnBrqiU9F2opuR3LJBA8tdtWK3jYG4Ll4LvUsfmcXBM99EJpwfn1ex0vS AqzxrMZs+4YrUBwEWwQpYGoZpOQ/SzXKAUlFiySrGwn7kOIMe0ycw6//m+XoHV3lfs7v qtC+Bh9IGcKaiij5kFAuOEhmAEaRQ+8QdjSjtEBn0iSGRuks8szJviyAc2xDW3fb0+ja gnH9H7WYkUUWFAa/nkcfBJjo/9qvAQEZcM64CY8JEU7u1YscalX6QkOK33dJNnwkWeQ5 7lAJDvIcEl1uo2SogljA0xg3jxsCaY3DZl+AldpAScCJlBb9jY6uh19vED9rk0enq+U7 0rGg== 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=tuUam1gTHo8n3NCFUrTVzYMm6rWoqHExP7UyQrdJBKI=; b=pNiEr+5red5ch491vtkxymJg9c8BEZYCMp5iLuwM7yZxWg2mnm+lBRu1zGnQ01Snd+ bXZDgaeSahXKTWarZpsPxxemP4amiWzIqXgZhfa1ji50DimB8NZxmctIItgeeNvcqz/T 8zo+8CPVD6j7pO2sYjLJe9ZZf7CRtO6ogy5DVf9msSq4kRUeGxb7izqb1znuEZMNjIN4 2SmEFr7IogqFU7Z9QxwSZxL+3aWSXboNOWA8t0MSEeGBVvdjpH1uwNLnCNAUQer32mU7 eq3VjOI2S6qx71wufASPSCZBuVHBMKalYSO8rXXu5DrzsAmcIkpALnDY3MSTh5K2kAHx GWKg== X-Gm-Message-State: AOAM533sUbq8ecyK4/1ZxXRTMhk5dEEwyLyuIIoh0DS2cwJzNw+ZUrUf m4i3NhB2y5ppF7eORuhULzCWfyCC8I+nomRTWkYeH1ep+0U= X-Google-Smtp-Source: ABdhPJz7h/KB0sgkPYg8feqIVSS6DroQ2hxDnIPhyn3pPB6JpQmau4nvc5CFL9Vau0UWRQusbglvoo+SSrYxz6Sav0c= X-Received: by 2002:a2e:b051:: with SMTP id d17mr12448370ljl.255.1618866333964; Mon, 19 Apr 2021 14:05:33 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 19 Apr 2021 17:05:22 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c65de905c059b079" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 21:05:42 -0000 --000000000000c65de905c059b079 Content-Type: text/plain; charset="UTF-8" All, Take a look at the following links for the April 19th interim meeting minutes: https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-06-oauth https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-06-202104191200/ Thanks to *Heather Flanagan *for taking these notes. Regards, Rifaat & Hannes --000000000000c65de905c059b079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Take a look at the following links= for the April 19th interim meeting=C2=A0minutes:

Thanks to Heather Flanagan=C2=A0for taking these notes.
<= br>
Regards,
=C2=A0Rifaat & Hannes
--000000000000c65de905c059b079-- From nobody Mon Apr 19 14:07:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514F03A26F9 for ; Mon, 19 Apr 2021 14:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 0PrerWiL8b-2 for ; Mon, 19 Apr 2021 14:07:38 -0700 (PDT) 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 4AC903A26F0 for ; Mon, 19 Apr 2021 14:07:38 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id x19so27775273lfa.2 for ; Mon, 19 Apr 2021 14:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WA/YtgJOaDMABLKwkUjvLYLDwRGvPnAx2YcbKJPvIa4=; b=c1FoJpOtVEjskWTiEpFE5mnMnSRoQgmjMjYFHe/VN4LCib9yLDdolpQmDVAojiLt0r 0LWqP15r9hVVLckm1FCnFqq4QjFKAu/KTZfim72u0F2zA57j1uPh3u2SbIVLJoews4EW SmlLyq19Yjhd0Wp+q8jJ33pgZh/NA8Hi2FSfAGe1YckyafZHUwFysJ9q0Patq99OzH26 Y4YKzMYGajMXqkH5sutAQStia1gGN83PXPTAWkDUknnWaYwV7jYfBp3mvT+HroiQacuy 8BWGXEIi+ePtPAZklfwMi4ZaGllKIAMfmJK6Ukoua4+7BsftxRoV5temIOTpZq1XNaF0 xS2w== 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=WA/YtgJOaDMABLKwkUjvLYLDwRGvPnAx2YcbKJPvIa4=; b=sWrNw/8v6p1+ithbOOizn4uMWP6q/SFY2vQ3AQU9h6dR98ZYiyNPljEacp9ibKs2XR BjoT7ErMDQnTJsOy4LhyHNGK22R5NyAP/UGLQfe1NqilKFThk4jsMebhT2xGUw/sUU4j vmk372fdmx4T6RAZ7yowy5q1aeTd4BuyuYVxOHephxjfuu45eG75N5zIEqbLmv0m30B9 E4cm63A0LTgPuYZOZlOE0LE7MgNUhYIyGu3Qe4z/WDxw7zt8RBzpmA69LNEi4fzIkpOS HJIfIS1BFFkLoK6k55dAPcXrVhZ7jWYTxeX5zrs3u2lf3D/PMyAzXbIa9ZtK5lQhpoky ykHg== X-Gm-Message-State: AOAM530H5C9CWbAWsCBj49Pu5FleqfMubZTx/GlpcVD6Z9yFxpjD4jSg hlanEIoHK5D7uc1RyGph1q2xiL+HmAFk9bz4PGmlLDh79Cw= X-Google-Smtp-Source: ABdhPJy/ZpCKORlUPjMEn2k6S6EFrsfwUY3hFDjbyAk43Ay+H2uUro+4cANdpY8cuQ9SBdOP57KqEdZ1SfkpQ5Ow+xs= X-Received: by 2002:ac2:5932:: with SMTP id v18mr6615667lfi.379.1618866454459; Mon, 19 Apr 2021 14:07:34 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 19 Apr 2021 17:07:23 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000f4f94105c059b738" Archived-At: Subject: [OAUTH-WG] April 19th Interim Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 21:07:43 -0000 --000000000000f4f94105c059b738 Content-Type: text/plain; charset="UTF-8" All, Take a look at the following links for the April 19th interim meeting minutes: https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-06-oauth https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-06-202104191200/ Thanks to *Heather Flanagan *for taking these notes. Regards, Rifaat & Hannes --000000000000f4f94105c059b738 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Take a look at the following links= for the April 19th interim meeting=C2=A0minutes:

=
Thanks to=C2=A0Heather Flanagan=C2=A0for taking these notes.

Regards,
=C2=A0Rifaat & Hannes
--000000000000f4f94105c059b738-- From nobody Mon Apr 19 15:45:40 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4D83A4796; Mon, 19 Apr 2021 15:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 YmPiYg3G_IBu; Mon, 19 Apr 2021 15:45:33 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675EE3A4795; Mon, 19 Apr 2021 15:45:33 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id l9so2065751ilh.10; Mon, 19 Apr 2021 15:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Idk5Zq1BptK7ly9OLUwVLE6+hIB+cZzlnZ1/nq3ABco=; b=YS5wrWiP3/eG1PLlpDLlXQIrBt66Sp1WjSxxbvTrON7detJF/RJ8VTvtr0spnFmRiG JlSeG4ETQjaLwtejv9Uuoe2JMUoQOBlMz1pNqnrYkcP/vQjpWVt7yEkSt7UoZDPDOb10 OV1gPxITJT48HJ+HaMqkae8qTehWeH1X24Nmepr4X7QAexztY8ghbnI3iaxHvzKQCr9K n9Nl2t0rvjVDDFFs3kM4TOutrgDQUsnlmXazil7zsCjB6VomFG8c7n3wW8H9XvNZNThq +3qIyqIgxghSoPwfjBg4UU9BhgcrKjUlX6VgXq6rcxfTj9o0aGnD5FFc07rVbbuXowil P/CQ== 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=Idk5Zq1BptK7ly9OLUwVLE6+hIB+cZzlnZ1/nq3ABco=; b=KVwpUMaQFsaELE6Y4lq0MFejRjFXv+ytOtCVsDLZfLEyp1YbpQi9nc+/1soYCrGdy6 4b1uPbsMLF9JbES3xvh58xoMkJ8iiHRYV5oCNl0g4f3ZF9aj4d4IoebNOndYJPqzheZx QvuAaElO5feGVkf4yeGzydXT58lMxdkC5KMirxAYkilyx6gYqgH7a2IU3UdvoTkA4GbO m7pr0ka6Vx/zwxHgPhQumBHFokQPPLhkNJMn6+eWaqlBMiJ9LjoIVJ75VuT0LB++Fhx+ 3uRsfXQ58PVyxJ8UwQGz1mNQH9bv8w0c5qJ4ap4FJpFsZHgr1TaF6neyYrW9+RQHdTWf SDaA== X-Gm-Message-State: AOAM532Qg77+KvtAdjMWGbeQ5nLnKlSMESGoG71F7dy0mSiwb+xt9E+J aEkPEyDdd1PYKTa/UlafwEKVPEqAyWAvxmOTIPk= X-Google-Smtp-Source: ABdhPJzqLWP0/NAvWhWtRBxhD/cUADFJOHE3Ve2Z88QnyNnCKpLy5hdRi2O7a9G8Y7Sj+QFwgZRNu6ZuKRUKcDGUxlM= X-Received: by 2002:a05:6e02:4c4:: with SMTP id f4mr19498364ils.272.1618872331701; Mon, 19 Apr 2021 15:45:31 -0700 (PDT) MIME-Version: 1.0 References: <161730912872.14258.15710315415917535021@ietfa.amsl.com> <20210408191223.GT79563@kduck.mit.edu> In-Reply-To: From: Martin Duke Date: Mon, 19 Apr 2021 15:45:20 -0700 Message-ID: To: Vittorio Bertocci Cc: Benjamin Kaduk , The IESG , "draft-ietf-oauth-access-token-jwt@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000044936305c05b16c6" Archived-At: Subject: Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with 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: Mon, 19 Apr 2021 22:45:38 -0000 --00000000000044936305c05b16c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alright, this all sounds good without any changes, except: On Wed, Apr 14, 2021 at 12:18 AM Vittorio Bertocci < vittorio.bertocci@auth0.com> wrote: > > > (4) I presume it's important that any resouree server rejection of > the token > > should be constant-time. Is this somewhere in the RFC tree, or do w= e > need to > > explicitly say it here and/or in Security Considerations? > I am thinking of analogous descriptions in other specs and I don=E2=80=99= t recall > mentions of that aspect, hence I assumed we didn=E2=80=99t have to specif= y it here > either. In particular, I glanced thru RFC6750 section 3, which this spec > specializes for the specific JWT AT scenario, and they don=E2=80=99t ment= ion that > either. > IMO it would be good to add this here, especially if it isn't described elsewhere in the ecosystem. That said, I'm happy to defer to the Security AD as to whether this is an important addition. --00000000000044936305c05b16c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alright, this all sounds good without any changes, ex= cept:

On Wed, Apr 14, 2021 at 12:18 AM Vittorio Bertocci <vittorio.bertocci@auth0.com> wro= te:

=C2=A0 =C2=A0 > (4) I presume it's important that any resouree serve= r rejection of the token
=C2=A0 =C2=A0 > should be constant-time. Is this somewhere in the RFC tr= ee, or do we need to
=C2=A0 =C2=A0 > explicitly say it here and/or in Security Considerations= ?
I am thinking of analogous descriptions in other specs and I don=E2=80=99t = recall mentions of that aspect, hence I assumed we didn=E2=80=99t have to s= pecify it here either. In particular, I glanced thru RFC6750=C2=A0 section = 3, which this spec specializes for the specific JWT AT scenario, and they d= on=E2=80=99t mention that either.

IMO i= t would be good to add this here, especially if it isn't described else= where in the ecosystem. That said, I'm happy to defer to the Security A= D as to whether this is an important addition.
=C2=A0
--00000000000044936305c05b16c6-- From nobody Wed Apr 21 09:48:27 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F072A3A2F3E; Wed, 21 Apr 2021 09:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEvSBVTdRkbt; Wed, 21 Apr 2021 09:48:15 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60057.outbound.protection.outlook.com [40.107.6.57]) (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 A5F8F3A2F29; Wed, 21 Apr 2021 09:48:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GfoVVGSa5QNr5zg3QCA4l1EEmp8swNWP9CYoKiPi9STwXHnCv+SQADr9waV5mnKwDUs1triH6LtJPVYKfjkbBeX2wAlRbuheF2eQDWkZzTb7VxtOenzCLfJFUDqiRDs4fgOUFDU5fJMZ/7pksUokabylcaMJg0Cmiq2+Ex3/9T3k/mUQe6BRMg/yfu0KcNMLtZoTJkSoQHpSk2mUFlqBPkdtymJCWNt7cKTqMJr6VKpsA3uxZzOKZs/PFEFIiSiEweW0n+4iBm+PFnVk/GL954jQu2ehbKlmGusauBNKik7WY66Xx0W/AssZQPqdyM0jCQQavsssF+EAloEVgbQmsA== 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=CCTWadiuGuhhdVBravumWluiEBA9mGzkdUEWt6SYbAI=; b=YK9oTQC5K51vL0obGsgdgiC50lh00PCavD8HpA0oKI0owdXZ+qtruZBeu+TPhakzY3fdjAQcYdq4S/dYNE7oUuwAkcUsQcGsJsvOcwndfk0PNZt7nwzl0N+pga1KvSnEyVGLOI7TVNiB3YWurSpkbPHXoInnicU/6H0tDFjTGCVo+EStc2Ya9Aqt7dvwOgGmxWdbmwr+vACjJfwlY4ezGLA8uYJTZ0WdyAWF3oPCazLO3mZLn26/KYbItPJZ0oHO50aywGZGlVXSdV2CZl1Q5qwcr5MTHXpfB7u69HQXs2zBYRhZ8dXrrH8S2TQb2GThRpDRfJhu0MqgfT2HjDln9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CCTWadiuGuhhdVBravumWluiEBA9mGzkdUEWt6SYbAI=; b=cs6EpDcQwIniBxaQ5K5yIn3B0pJHPCKXLN5riR7zXqJey/mB2Iij0CJZdt7rjbDZW+ILwuJLeshj9VnxskQekq130Evb1O+WcxafsIwyy+ytb3bvV3Az4nu1AVAIzUSpxIddUIjMjpjuTNXHPMIWjgvkkvPbdHdi0tBWKcXt5Mk= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR07MB3098.eurprd07.prod.outlook.com (2603:10a6:7:38::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.12; Wed, 21 Apr 2021 16:48:09 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b%5]) with mapi id 15.20.4087.016; Wed, 21 Apr 2021 16:48:09 +0000 From: Francesca Palombini To: Vittorio Bertocci , The IESG CC: "draft-ietf-oauth-access-token-jwt@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" , "hannes.tschofenig@arm.com" Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) Thread-Index: AQHXKXyD5hOK0id2SE6ls8YO/IoD/6qzqeEAgAvA4wA= Date: Wed, 21 Apr 2021 16:48:09 +0000 Message-ID: <979E7789-1F3A-47DB-A1F1-94C746079B3F@ericsson.com> References: <161755926036.31657.529017576412672874@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: auth0.com; dkim=none (message not signed) header.d=none;auth0.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:f0de:f0f3:791a:7da1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df238987-2f83-4c1c-838e-08d904e53ed2 x-ms-traffictypediagnostic: HE1PR07MB3098: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6J6s22GCKcYqDrO2PhGtqVhJoznnpn65/7neULnBy8IwjteluKqt/DM7KhetzV81DR7xFMSsds7J9R4c7+mY7RvTeD54GfZIsfbV9JjI2uCqewJ+yWkcG8WLGr8sRQacu00t+tiguuDWUivBz2NXRvw64q5aYWqyFImRAJjLJShx9mKtcsMaEZki+vrMdfC3PXQFpPi4IZZYPkgV//kxwMpN2idtQvMxIfpW8XdkOlBZWZ5TMr5cKUv6BMlvjGU+YkB0J9rVp01K/7GElF+Q2sY2xO9PWMVrQNjY8OJiOhxbVpY5cRM2mIwzVTHNNk3KCLgbW6zlkEo4U6hOWmssICcCYNVB1XcrTQWM8prV7qbGaZrsci3pv624RwA3Xd0/i08GRXpA/U7jNWFPIBuBy0/yzQL0xYCIEuYs9YhQpv9wMGYXbGH/YvtJA9FPG3xyftr/J+SibgivjTHFpBNNYYLnjyR99PpoGO50IbRVBsopzwk4XYbywE57QyumKXPS8ztaBUidB+jeS2ZpPNtZhwQOnwKx0oenD1mST76TKHB+woggAW8SIzXovRtmruGrGmpNr/D4SDtCWA837uUHKrtUcE6ksphYmW2TXpgMyaiTYwTq+biu7Upz67WJgvPrMCxS0mnqsHFw9nK33zKCQRtMsVs3V+2ne0O4l5rEY8N/6Ae1Zyk3latM8sdcrimrWZQBztqT9OSTHuOzgJQLF+KuKJyYtSGoN/isYgtThq8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(5660300002)(186003)(54906003)(33656002)(36756003)(66476007)(2616005)(86362001)(44832011)(122000001)(966005)(64756008)(66446008)(6486002)(71200400001)(2906002)(6512007)(38100700002)(110136005)(76116006)(4326008)(8676002)(53546011)(83380400001)(8936002)(6506007)(66556008)(498600001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?bU9zNFYvNFNIbHhSR2EwUzRwQ1Frb2YzUnBsY2NoaCtYZWtWbDRQTVJ0c1VD?= =?utf-8?B?UTRXT2FEOFVXOVFhOWNDRi9JMEF1clc5WjI0SDZUaklnalBPaWR1VU1nK09O?= =?utf-8?B?ZXkzWlhSNHl4R095WVNwNXdqOXdDTFMxRjV5ZjY5UmNvak1hMXhmWGNZTDF5?= =?utf-8?B?blAzYzgzSTZhejNwSlJDNHN5UVprYzBFSFlNMDhFQTYvNC9XVzhNTHNZSlpD?= =?utf-8?B?UW9lOHh2MnQ2TDM4MWp0SGRyNlpBSXpnUWJsVTY5K1lCNGhZeGlaRWNSSWtx?= =?utf-8?B?YmlyOVZxUkpidkZoS2o0bGUyRjErMzJET3Yvek43Znp1NGFUcUFjeFhyZS9l?= =?utf-8?B?d0xsTDl4RDBIRENjZDdvdVJ6WnZJK2JCRWY0ME9KQzdTbzJoQUQ0WkVRWkJy?= =?utf-8?B?VzZTNFZmUEQ4czlSSWw3WEJzek5JS2ROSXUrbll1UjFadndmVkZqb3dnQ2JZ?= =?utf-8?B?eUp1a3dDVmlCbFFSR1R4dWdIbkpHcGRxb3ByKzFaZi9FK2ZqSFh1bnBFcVUy?= =?utf-8?B?bjZFWnJLS29kV091NTlsVFJveDRvY3FuT2lZL3Y5UXpjaEl5SDJkdGdhQ3pk?= =?utf-8?B?cjNlcGV0cFUyZjVscmoxeDJzZER4ZEVoMjQ3c1RNRjFyL0FKMEFjNFpSOHl6?= =?utf-8?B?Q0FCUkYvL05JVnZQdEhOS05hTFM3cG9zYllKem9VS3BQN3pTRi9iWk5tcHhu?= =?utf-8?B?UTF3YXZKTUFUd1E4MVNzRTVtTmtSNkZ6UGg4aGNXREx1UTBUcGVCQStKb2FD?= =?utf-8?B?VThzUDNBV3dqdVZaUTU5bWhHb2ovZ1NBWmEzbEFHZERhTzh5Z1J1VFA3ZWtH?= =?utf-8?B?cWtscXZkL1BMZVpOaEMxNGxZam1YM3ZkbjJVSDNUNUM5ZW9ydktDYWVFcW9u?= =?utf-8?B?OGIvMWJSRFFFWFZyZDhrckFINWZWby9sejlJbmNrdDhraHBkZGVYdm1KZU00?= =?utf-8?B?eXlyT3NwUGFIem1iZi8vcy80djZ1cWFFVVQ1V0xlWVB3M2VDVy96V0U3RTMr?= =?utf-8?B?MDh2MlBjdTE5TkZFdkpnTGpXWFJWYkV5VDBMWlFJdktmeitrQTlQS09mWUpF?= =?utf-8?B?Ykh1Z0lTYk9Oc2RPbzVidXVob0xOV2hIajN1ck9TS0Q2TEIrSGlIU2R3ZEd3?= =?utf-8?B?bW44WlJzU1hnbWRyYkJ3WkUvUGN4WDlFdTFCSURjWXlKcDVZYXdubjRPVFpL?= =?utf-8?B?NHJZMFFMZVhkNzBqY3Q3allnZ0E1Ymphcyt1QkhrU0Nrb3VjbnhDNklCMk92?= =?utf-8?B?NXg0UmZjL05nKy9McXVPdFZGT0kvNm5SSHR3Z241Q0tuRU5HQ0VRUE8yQnNX?= =?utf-8?B?TDBSRGd4SWpDRWtGNS9oaElJVExyeGg3Qis1YnExc3h3b0tWOTh6ZG1sSmNM?= =?utf-8?B?TW5pV0FnMUphSmwwdzRrQmZKNS8ycGFEZEFSeWZRdnJ0TFdnN3k2bkRiZGZJ?= =?utf-8?B?MEgzNzF4b2lhVGJnY2ttc2lOTDArVHJtWG5XNGFDQ3VDb3Z6NkpxYjFUT3NP?= =?utf-8?B?dFlxczZ5VnI3dmJlL2FYY004NEZDZDhsTGZyNnc4U2ZmSCtSVjk2aDk3eFdr?= =?utf-8?B?U0VCWmNUMWQzSzZsWGYveExVazcxQU5EWFAyQXBrWWNKOW1Mdjh6cDNmc0My?= =?utf-8?B?MXFGNWdSczNBcWJFd0tQbmpYaDJsTW01YnRKY0Yxayt2YnNmeUNEOWFTclRP?= =?utf-8?B?SFdISzdSNzgwVEV0YVlzVjI5Ulh5VlJWMjBZSjQ5ZUs4Q1h2YjlSbERmOE92?= =?utf-8?B?VUNtT25CenBMMEhaVkh0WWJPNlI4bHE3SUZRcUZSQjJnQ2hCWXhpdDU5K291?= =?utf-8?B?eG0vQmtKU3Z4bFBmL09GWWtzWGdlRFBTSjQ2alZWSkY0SmZUVHk0TSsyNDMy?= =?utf-8?B?TU5MbThSZVNRM01DQWJIdWk3TUxXY2V2cUsvMDM2d0VaWkE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <00C2063ADE8AEC4EB2C5665656D8F7E6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: df238987-2f83-4c1c-838e-08d904e53ed2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 16:48:09.5652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aRa88Rn2qTdj7gEKlWZ0jGqqR1W3EZTdI1GsE1szCJGRRYv2R/RG3dkQMKwVa/OhFocIjaTwwOwEzxwEXaisuifcwL5wuyQagI9x8FPhMKdvyA+ylMFddqcng5/Z7SW9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3098 Archived-At: Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 16:48:26 -0000 SGkgVml0dG9yaW8hDQoNClRoYW5rcyBmb3IgdGhlIGFuc3dlcnMuIEknbSBvayB3aXRoIHRoZSBt b3RpdmF0aW9uIGZvciB1c2luZyAiYXBwbGljYXRpb24vYXQrand0IiwgdGhhbmtzIGZvciBjbGFy aWZ5aW5nLCBhbmQgdGhhbmtzIGZvciBhZGRyZXNzaW5nIDIuDQpSZSAxLiBJTU8gaXQgd291bGQg Y2xhcmlmeSB0aGUgaW50ZW50aW9uIG9mIHRoZSBTSE9VTEQgdG8gYWRkIHdoYXQgeW91IHdyb3Rl IGluIHJlc3BvbnNlIHRvIG15IGNvbW1lbnQgaW50byB0aGUgZHJhZnQgaXRzZWxmLCBidXQgSSds bCBsZWF2ZSBpdCB1cCB0byB5b3UuDQoNCkZyYW5jZXNjYQ0KDQrvu79PbiAxNC8wNC8yMDIxLCAw OToxOSwgIlZpdHRvcmlvIEJlcnRvY2NpIiA8dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPiB3 cm90ZToNCg0KICAgIEhpIEZyYW5jZXNjYSwNCiAgICBUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFu ZCB0aG91Z2h0ZnVsIGNvbW1lbnRzIQ0KICAgIENvbW1lbnRzIGJlbG93Lg0KDQogICAgPiAgICAx LiAtLS0tLQ0KICAgID4gICAgWy4uLl0NCiAgICBXaGlsZSBpdCBpcyByZWFzb25hYmxlIHRvIGV4 cGVjdCB0aGF0IGEgUlMgcmVjZWl2aW5nIGFuIHVuZW5jcnlwdGVkIHRva2VuIGFmdGVyIHJlcXVl c3RpbmcgaXQgdG8gYmUgZW5jcnlwdGVkIHdpbGwgcmVqZWN0IGl0LCB0aGVyZSBhcmUgYSBudW1i ZXIgb2YgY2FzZXMgd2hlcmUgdGhlIFJTIG1pZ2h0IGVsZWN0IHRvIGRvIG90aGVyd2lzZS4gRm9y IGV4YW1wbGUsIHRoZSBzb2x1dGlvbiBtaWdodCBiZSBhbHJlYWR5IHdvcmtpbmcgaW4gcHJvZHVj dGlvbjogdGhlIGVuY3J5cHRpb24gcmVxdWlyZW1lbnQgbWlnaHQgYmUgYW4gaW1wcm92ZW1lbnQg dGhhdCBpcyBzdGlsbCBwcm9wYWdhdGluZyB0aHJ1IHRoZSBzeXN0ZW0sIGFuZCB0aGVyZSBtaWdo dCBzdGlsbCBiZSBhY2Nlc3MgdG9rZW5zIGNhY2hlZCBpbiBjbGllbnRzIHRoYXQgdGhlIFJTIG1p Z2h0IHN0aWxsIGJlIHdpbGxpbmcgdG8gYWNjZXB0IHRvIGd1YXJhbnRlZSBidXNpbmVzcyBjb250 aW51aXR5LiAiU0hPVUxEIiBnaXZlcyBhIHN0cm9uZyBzaWduYWwgdG8gaW1wbGVtZW50ZXJzIG9m IHdoYXQgdGhlIGRlc2lyZWQgYmVoYXZpb3IgaXMsIGJ1dCBsZWF2ZXMgdGhlbSBzb21lIGZyZWVk b20gdG8gYWNjb21tb2RhdGUgc2l0dWF0aW9ucyBsaWtlIHRoZSBhZm9yZW1lbnRpb25lZCBvbmUu DQoNCiAgICA+IDIuIC0tLQ0KICAgID4gWy4uLl0NCiAgICBGYWlyIGVub3VnaC4gSSBhZGRlZCB0 aGUgZm9sbG93aW5nIHRleHQgYXQgdGhlIGJlZ2lubmluZyBvZiAyLjEuIFRoYW5rcyBmb3IgY2F0 Y2hpbmcgdGhpcy4NCiAgICAgICAgIEpXVCBhY2Nlc3MgdG9rZW5zIE1VU1QgYmUgc2lnbmVkLiBB bHRob3VnaCBKV1QgYWNjZXNzIHRva2VucyBjYW4gdXNlIGFueSBzaWduaW5nIGFsZ29yaXRobVsu Ll0NCiAgICBUaGlzIGNoYW5nZSB3aWxsIGFwcGVhciBpbiB0aGUgbmV4dCByZXZpc2lvbiwgd2hp Y2ggSSB3aWxsIHBvc3Qgc29vbi4NCg0KICAgID4gICAgIDMuIC0tLS0tDQogICAgPiBbLi4uXQ0K DQogICAgRm9ybWFsbHksIEkgYWdyZWUgdGhhdCBKT1NFIHdvdWxkIGFsc28gd29yay4gVGhlIGNo b2ljZSBvZiBtZWRpYSB0eXBlIGRlcml2ZXMgZnJvbSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzUxOSNzZWN0aW9uLTEwLjMuMS4gVGhlcmUgaXMgbm8gZnVuY3Rpb25hbCBkaWZmZXJl bmNlIGJldHdlZW4gSldTIGFuZCBKV0UgaW4gdGhlIGludGVudCBhIGNsaWVudCBoYXMgd2hlbiBj YWxsaW5nIGFuIFJTLCBoZXJlIHRoZXJlJ3Mgbm90IG11Y2ggdG8gYmUgZ2FpbmVkIGluIHVzaW5n IGRpZmZlcmVudCBNSU1FIHR5cGVzIGZvciB0aG9zZSBjYXNlcy4gRnVydGhlcm1vcmUsIHdoZXJl YXMgZGV2ZWxvcGVycyBhcmUgZmFtaWxpYXIgd2l0aCB0aGUgdGVybSAiSldUIiwgYm90aCBmcm9t IGRpcmVjdCB1c2UgYW5kIHRoYW5rcyB0byB0aGUgcG9wdWxhcml0eSBvZiBPcGVuSUQgQ29ubmVj dCAod2hpY2ggZG9lcyB1c2UgYXBwbGljYXRpb24vand0KSwgdGVybXMgbGlrZSBKV1MsIEpXRSBv ciBKT1NFIHdvdWxkbid0IGJlIGFzIHByb21wdGx5IHVuZGVyc3Rvb2QgYXMgSldULiBUaHJvdWdo b3V0IHRoZSBkaXNjdXNzaW9ucyBpbiB0aGUgbGFzdCBjb3VwbGUgb2YgeWVhcnMsIHRoZSBjb25z ZW5zdXMgb24gdGhlIHVzZSBvZiBhdCtqd3Qgd2FzIHNvbGlkLSBteSBob3BlIGlzIHRoYXQgd2ls bCBtYWtlIGludHVpdGl2ZSBzZW5zZSBmb3IgaW1wbGVtZW50ZXJzLCB0b28uDQoNCg0KICAgIE9u IDQvNC8yMSwgMTE6MDEsICJGcmFuY2VzY2EgUGFsb21iaW5pIHZpYSBEYXRhdHJhY2tlciIgPG5v cmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgICAgIEZyYW5jZXNjYSBQYWxvbWJpbmkgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgICAgIGRyYWZ0 LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0xMjogTm8gT2JqZWN0aW9uDQoNCiAgICAgICAg V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsDQogICAgICAgIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQogICAgICAgIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNCiAgICAgICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAg ICAgICBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQg cG9zaXRpb25zLg0KDQoNCiAgICAgICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QvDQoN Cg0KDQogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgQ09NTUVOVDoNCiAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQogICAgICAgIFRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgb24gdGhpcyBkb2N1 bWVudC4gUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBhbmQNCiAgICAgICAgY2xhcmlmeWluZyBx dWVzdGlvbnMgYmVsb3cuDQoNCiAgICAgICAgRnJhbmNlc2NhDQoNCiAgICAgICAgMS4gLS0tLS0N Cg0KICAgICAgICAgICAgICByZWdpc3RyYXRpb24uICBJZiBlbmNyeXB0aW9uIHdhcyBuZWdvdGlh dGVkIHdpdGggdGhlIGF1dGhvcml6YXRpb24NCiAgICAgICAgICAgICAgc2VydmVyIGF0IHJlZ2lz dHJhdGlvbiB0aW1lIGFuZCB0aGUgaW5jb21pbmcgSldUIGFjY2VzcyB0b2tlbiBpcw0KICAgICAg ICAgICAgICBub3QgZW5jcnlwdGVkLCB0aGUgcmVzb3VyY2Ugc2VydmVyIFNIT1VMRCByZWplY3Qg aXQuDQoNCiAgICAgICAgRlA6IFdoeSBpcyB0aGlzIGp1c3QgU0hPVUxEIGFuZCBub3QgTVVTVD8g SW4gd2hpY2ggY2FzZSBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8NCiAgICAgICAgYWNjZXB0IGEgbm9u LWVuY3J5cHRlZCB0b2tlbiB3aGVuIGVuY3J5cHRpb24gd2FzIG5lZ290aWF0ZWQ/DQoNCiAgICAg ICAgMi4gLS0tLS0NCg0KICAgICAgICBTZWN0aW9uIDIuMToNCg0KICAgICAgICAgICBTZWN0aW9u IDQpLiAgSldUIGFjY2VzcyB0b2tlbnMgTVVTVCBOT1QgdXNlICJub25lIiBhcyB0aGUgc2lnbmlu Zw0KICAgICAgICAgICBhbGdvcml0aG0uICBTZWUgU2VjdGlvbiA0IGZvciBtb3JlIGRldGFpbHMu DQoNCiAgICAgICAgU2VjdGlvbiA0Og0KDQogICAgICAgICAgIEZvciB0aGUgcHVycG9zZSBvZiBm YWNpbGl0YXRpbmcgdmFsaWRhdGlvbiBkYXRhIHJldHJpZXZhbCwgaXQgaXMgaGVyZQ0KICAgICAg ICAgICBSRUNPTU1FTkRFRCB0aGF0IGF1dGhvcml6YXRpb24gc2VydmVycyBzaWduIEpXVCBhY2Nl c3MgdG9rZW5zIHdpdGggYW4NCiAgICAgICAgICAgYXN5bW1ldHJpYyBhbGdvcml0aG0uDQoNCiAg ICAgICAgICAgLi4uDQoNCiAgICAgICAgICAgbyAgVGhlIHJlc291cmNlIHNlcnZlciBNVVNUIHZh bGlkYXRlIHRoZSBzaWduYXR1cmUgb2YgYWxsIGluY29taW5nDQogICAgICAgICAgICAgIEpXVCBh Y2Nlc3MgdG9rZW5zIGFjY29yZGluZyB0byBbUkZDNzUxNV0gdXNpbmcgdGhlIGFsZ29yaXRobQ0K ICAgICAgICAgICAgICBzcGVjaWZpZWQgaW4gdGhlIEpXVCBhbGcgSGVhZGVyIFBhcmFtZXRlci4g IFRoZSByZXNvdXJjZSBzZXJ2ZXINCg0KICAgICAgICBGUDogSXQgbWlnaHQgYmUgb2J2aW91cywg YnV0IEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGhhdmUgYW4gZXhwbGljaXQNCiAgICAg ICAgc2VudGVuY2Ugc3RhdGluZyB0aGF0IEpXVCBNVVNUIGJlIHNpZ25lZC4gVGhlIHF1b3RlZCB0 ZXh0IGZyb20gU2VjdGlvbiAyLjEgc2VlbQ0KICAgICAgICB0byBpbXBseSBpdC4gU2VjdGlvbiA0 IG9ubHkgUkVDT01NRU5EUyB0aGF0IHRoZSBKV1QgaXMgc2lnbmVkIHdpdGggYW5kDQogICAgICAg IGFzeW1tZXRyaWMgYWxnb3JpdGhtLiBMYXRlciBvbiwgU2VjdGlvbiA0IGltcGxpZXMgdGhhdCBh bGwgSldUIGFyZSBzaWduZWQuIE9uDQogICAgICAgIHRoZSBvdGhlciBoYW5kIEkgbm90ZSB0aGF0 IGVuY3J5cHRpb24gY2FuIGJlIG5lZ290aWF0ZWQgKGFuZCBpcyBvcHRpb25hbCkgZnJvbQ0KICAg ICAgICB0aGUgZm9sbG93aWcgcG9pbnQ7IGluIHRoYXQgY2FzZSBpdCBpcyBub3QgY2xlYXIgdGhh dCB0aGUgdG9rZW4gaXMgc3RpbGwgc2lnbmVkDQogICAgICAgIChzbyB0aGUgbmVzdGVkIEpXVCB3 b3VsZCBiZSBhIEpXRSBuZXN0ZWQgaW4gYSBKV1MpLCBvciBvbmx5IEpXRSBpcyB1c2VkLiBXaGF0 IEkNCiAgICAgICAgYW0gbG9va2luZyBmb3IgaXMgc2ltcGxlIGNsYXJpZmljYXRpb25zIHRvIGJl IGFkZGVkIGZvciBleGFtcGxlIGluIHRoZQ0KICAgICAgICBpbnRyb2R1Y3Rpb24uDQoNCiAgICAg ICAgICAgICBvICBJZiB0aGUgSldUIGFjY2VzcyB0b2tlbiBpcyBlbmNyeXB0ZWQsIGRlY3J5cHQg aXQgdXNpbmcgdGhlIGtleXMNCiAgICAgICAgICAgICAgYW5kIGFsZ29yaXRobXMgdGhhdCB0aGUg cmVzb3VyY2Ugc2VydmVyIHNwZWNpZmllZCBkdXJpbmcNCiAgICAgICAgICAgICAgcmVnaXN0cmF0 aW9uLiAgSWYgZW5jcnlwdGlvbiB3YXMgbmVnb3RpYXRlZCB3aXRoIHRoZSBhdXRob3JpemF0aW9u DQoNCiAgICAgICAgMy4gLS0tLS0NCg0KICAgICAgICBPbiB0aGUgc2FtZSBub3RlLCBhbmQgZGVw ZW5kaW5nIG9uIHRoZSBwcmV2aW91cyBhbnN3ZXIsIHdoeSBpcyB0aGUgbWVkaWEgdHlwZQ0KICAg ICAgICByZWdpc3RlcmVkIGFuZCB1c2VkICJhcHBsaWNhdGlvbi9hdCtqd3QiIGFuZCBub3Qgc29t ZXRoaW5nIGxpa2UNCiAgICAgICAgImFwcGxpY2F0aW9uL2F0K2p3cyIvImFwcGxpY2F0aW9uL2F0 K2p3ZSIgb3IgcmF0aGVyICJhcHBsaWNhdGlvbi9hdCtqb3NlIiB0byBiZQ0KICAgICAgICBjb21w bGlhbnQgd2l0aCBodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPWNmOTY4ZjY5 LTkwMGRiNjZiLWNmOTZjZmYyLTg2OWExNGY0YjA4Yy1kOWFmYzk1MTVjYWFjMWM0JnE9MSZlPWUw Nzk1MDY1LTg2NWEtNDk1MC04N2E1LWFjMWIyYjFkOGU1OCZ1PWh0dHBzJTNBJTJGJTJGd3d3LnJm Yy1lZGl0b3Iub3JnJTJGcmZjJTJGcmZjNzUxNS5odG1sJTIzc2VjdGlvbi05LjIuMSA/IEkNCiAg ICAgICAgdGhpbmsgdGhhdCB0aGUgc3RydWN0dXJlIHRyYW5zcG9ydGVkIGlzIGluIGZhY3QgYSBK V1Mgb3IgYSBKV0UsIHJhdGhlciB0aGFuIHRoZQ0KICAgICAgICBKV1QsIGFuZCBpZiB0aGF0J3Mg dGhlIGNhc2UgdGhhdCBzaG91bGQgYmUgbWFkZSBjbGVhciBpbiB0aGUgdGV4dCAob25lIGV4YW1w bGUNCiAgICAgICAgd2hlcmUgdGhpcyBjb3VsZCBiZSBjbGFyaWZpZWQgaXMgaW4gdGhlIGZvbGxv d2luZyBzZW50ZW5jZSkNCg0KICAgICAgICAgICBSZXNvdXJjZSBzZXJ2ZXJzIHJlY2VpdmluZyBh IEpXVCBhY2Nlc3MgdG9rZW4gTVVTVCB2YWxpZGF0ZSBpdCBpbiB0aGUNCiAgICAgICAgICAgZm9s bG93aW5nIG1hbm5lci4NCg0KDQoNCg0KDQo= From nobody Mon Apr 26 04:54:53 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C9E3A1C20 for ; Mon, 26 Apr 2021 04:54:51 -0700 (PDT) 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, 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 akxJJMGRzHIp for ; Mon, 26 Apr 2021 04:54:46 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B3F3A1C1D for ; Mon, 26 Apr 2021 04:54:46 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id s9so5784932ljj.6 for ; Mon, 26 Apr 2021 04:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cbewmUlzgm1VoagOgyMCIUSQFyrISeLbo8zCtlQ4O9A=; b=Lh56fafLaWC5H8hiZefyLClu4LeHFWD4Y7SXZbCARglv5x6HHs2VMtyZU15B7o7m+k ISDZCb1g10TW4gD84BcFcTX2kMLK9TJGQ4cRKCtiGZAt4GLI3JP+EpVHB/0budHzlY1h I1jNMcicNuwuFjwj+TuFlqN5cnBcmlR2aoGBBYmKtZa0N+Np9dKIESfk+3LaUP0Xk6yj tWBxxg0t6/WNK21U0Qcq4qXXHvoeHT4nTMAIDjwPEW4eW5+PXvXKeYGolvCed7Nk9ueS 984hPkjP4+JWjs3oYdFCYuc5M9ovCgygQv2OEacdEKiMszgzJPzDDWS/dT9S1gear3po UHpw== 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=cbewmUlzgm1VoagOgyMCIUSQFyrISeLbo8zCtlQ4O9A=; b=LAMK+/A8Dv4W+oNzzeKgUQZAVvoAXoUIx/4eYd/IHppKG/1v8n1cpfegrb7DoE9NRf ZNdpHvX+lepTyrSUFD99mrZAvyr1cY7xK6CQBTl7u6HuyNcaSKI2Akb3gLss1l35MlWl HBSPJomW4ArXEU6TJzh7O266TbSeiJSHuxbU1e4yIsEKj1oWo0TZ3tnuXu4Yb7Ugu8Xc chGnWA0sVX9Wnf/v+tC6VCpq17L4y8jk3zuxnzamx+azB0uNyViidin5XL881uvgPPER 7LrYwKIZHU1Pm/YK5P15r6B/ExSI0eIYMunNJ8iRh3YTR+KWplKdc76DPUY5AyXkzmL2 x46A== X-Gm-Message-State: AOAM530xc8fiva/uy0v2+kL54sc+yud6mtJo+2BeJhv64uuNMRi6GxTb 17Qg2TvzwwBdfeRzIlwKwZR2fLoQuFF4HHyGFVttz1pux6U= X-Google-Smtp-Source: ABdhPJznB0fZmZkyt1ZR/3lyYTu3+C/hEEvB6cNPsM4pro6OKmBhiSsyfHI232jutzkM5ESXgLb5F/+w4uiAJX0ndjY= X-Received: by 2002:a2e:b051:: with SMTP id d17mr12570968ljl.255.1619438084052; Mon, 26 Apr 2021 04:54:44 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 26 Apr 2021 07:54:33 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000bc58e305c0decfef" Archived-At: Subject: [OAUTH-WG] OAuth WG Interim Meeting - TMI BFF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 11:54:51 -0000 --000000000000bc58e305c0decfef Content-Type: text/plain; charset="UTF-8" All, The OAuth WG interim meeting today is focused on the TMI BFF document: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ Webex Meeting Link: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b Regards, Rifaat & Hannes --000000000000bc58e305c0decfef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The OAuth WG interim meeting today= is focused=C2=A0on the TMI BFF document:

Webex Meeting Link:<= br>https://ietf.webex.com/ietf/j.php?MTID=3Dm827c194bdcaa0077de= 44241f8001ce9b

Regards,
=C2=A0Rifaat & Hannes
--000000000000bc58e305c0decfef-- From nobody Mon Apr 26 08:34:07 2021 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 C40183A256B; Mon, 26 Apr 2021 08:33:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161945123965.12454.12576905303855743877@ietfa.amsl.com> Date: Mon, 26 Apr 2021 08:33:59 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-04-26 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, 26 Apr 2021 15:34:02 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-04-26 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: TMI BFF https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Mon Apr 26 11:51:24 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCE53A2CB1 for ; Mon, 26 Apr 2021 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgbJocmnm4v7 for ; Mon, 26 Apr 2021 11:51:22 -0700 (PDT) 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 EE1E63A2CAF for ; Mon, 26 Apr 2021 11:51:21 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id m7so54512999ljp.10 for ; Mon, 26 Apr 2021 11:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=plfCQT13Ig4aWhqI7eLewNyD3lJdcRVX5EyEMGrKuzQ=; b=QmpO19Mb247AERWujYXDCLvihjAfnxlVJonJfOLfGWfiNi6q4OIYcIb0Snaa98WCPk Gt2pOMjJxrx20ccfxtReZaaL6wU/n+WqkSpP8gmuiVLjbbtW2bq6OAMAyHJ+UYbAZa5P QREhPJ6vqX3Nc5q/cbQWXuLmX8PtK0snED27VoxcWRaJqIRDJWogaFsJskX0QnfI9g3v /gDTeKmoDqjpswBv2o2ykfXVB6oSIk3Te6MdVpEGcFfL+OM0DknGAgrcLBn4AIfsH19n M4bQtXWshNTwyDR9lh9908TcBbJX2nS2DE0ZgKST7/GnAekhaEJAhgKZsX7h21CIOqfg NR+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:from:date:message-id:subject:to; bh=plfCQT13Ig4aWhqI7eLewNyD3lJdcRVX5EyEMGrKuzQ=; b=qmSAjZw8mx+zd2dSFmMMut+mH6OcJ90qYcgZOT/XmHjaZcDzboMjti4tpl5S5Xk3b4 v9ob3DD04gW+VVsCvdt5rmFpzOx315eFfQkaqYBL7JJRQYnVo9oxd+MFU4dvrMImU6Dw m7MetosUR2jQ1kU20MhTmRDc8la4hKRPebKx2MYDs1TrQ+PSrBHYTjbgASFLRdSMJbN4 qxF0svCso5/lZxf8vZppv3j9geaxZnPwmtoCcQXWcJi3QOIS/L6ygCIjRkyAGasaD9C5 dykpo62LmlwrlFusLwAaNncJaNfm0wVgdv5aETf9zdw7XzXiqVsfG9nCB1zy5f/RoFiQ hL3A== X-Gm-Message-State: AOAM531eL98keItj0k8VyFHLThnjrbIvfAufLwXTUgNaOXFxrrZMAjVx TP8RKbqf7LGpLdCUH3NIjomgjffKrhWrA/YSGrki7NpH X-Google-Smtp-Source: ABdhPJxm3r0QH9lRMSI2oef8QJU70fC+wKrFFCkLZqsvUoogcLfvQO0XDB7gDabCU/009VGmxDNfBU6SLYYP7mraLrg= X-Received: by 2002:a2e:8e8d:: with SMTP id z13mr14346760ljk.278.1619463078028; Mon, 26 Apr 2021 11:51:18 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 26 Apr 2021 14:51:06 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000007e2a1605c0e4a189" Archived-At: Subject: [OAUTH-WG] April 26th Interim Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 18:51:24 -0000 --0000000000007e2a1605c0e4a189 Content-Type: text/plain; charset="UTF-8" All, Take a look at the following links for the April 26th interim meeting minutes: https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-09-oauth https://datatracker.ietf.org/meeting/interim-2021-oauth-09/materials/minutes-interim-2021-oauth-09-202104261200-00 Thanks to *Justin Richer *for taking these notes. Regards, Rifaat & Hannes --0000000000007e2a1605c0e4a189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Take a look at the following links= for the April 26th interim meeting=C2=A0minutes:

Thanks to=C2=A0Justin Richer=C2=A0for taking these notes.

Regards,
=C2=A0Rifaat & Hannes
--0000000000007e2a1605c0e4a189-- From nobody Mon Apr 26 11:53:39 2021 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 8D4323A2CBA; Mon, 26 Apr 2021 11:53:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161946321398.15717.13984293672998151943@ietfa.amsl.com> Date: Mon, 26 Apr 2021 11:53:34 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Interim Meeting Cancelled (was 2021-05-03) 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, 26 Apr 2021 18:53:35 -0000 The Web Authorization Protocol (oauth) virtual interim meeting for 2021-05-03 from 12:00 to 13:00 America/Toronto has been cancelled. From nobody Mon Apr 26 11:57:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616523A2CDB for ; Mon, 26 Apr 2021 11:57:32 -0700 (PDT) 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, 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 8Sm1gDDeHS0g for ; Mon, 26 Apr 2021 11:57:30 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038973A2CDA for ; Mon, 26 Apr 2021 11:57:29 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id o5so32289498ljc.1 for ; Mon, 26 Apr 2021 11:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MDg0mJUPiHyaLWQU1YhjPKBHJxtseKyO01AT+C92n9I=; b=WR6+7n4y3ay4baybzWHaWkL3yWh4bk/tb7yNGiUDGMeXAsDy76KNPa+1TSEfjNBpue +wUSNc+rcNzfu3hS19N2X7N6GJBSAJTXdAyD4IyT2c9uH+574lUUEoJ8mf1oMTwfvQEH t245RlSP7fmREF1SPVFnifLJqQ0a6MgofXeNdeYxa6RqlG8SqRtjOiSrhlJIh4dMCy+N kl1KF2PlKpSKext1si/+GQJEfjMYi76yEN4lLk4v0MRDSPo89QyWubTIFnCUrPGEYl59 Ro7k/X8X/LWvbHoCQ2Qw8akXdY3wQV8CipKMXufhS6la0pM+vm9msbTAhgAqjHluUoad ubZg== 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=MDg0mJUPiHyaLWQU1YhjPKBHJxtseKyO01AT+C92n9I=; b=JQ1YBaRRfNorf3CDAgFqOfH0WNhaW+ZUUXK51MFdGx8V+hvAjUbl1pPWRgyHEE8aqw xQlP9/bYHZwdWAGEoTVuS3vy6IPJxDGDrRRKCKdHPgUdGi5KyrMAzbOPIvfZYaepHCNj VkjOJUF1+QiT5tBvHWnLX3xmLpvxCB/ioQtK4Glb5JOTCq/D43OCx5aq02aXur2AYRfL J52nkEaaXLEXKGxPf6TrDOxLrOpYF9kidGNgnMeENfnn1OYAGVx9sfK1w88jDiKKRK+0 YAYv/gjXaNAOfPoCxhIidh4bDfmugonhK6DI9Ghk9Npzq09SJuUofOcN6tIn/9mUjWuy O//w== X-Gm-Message-State: AOAM530TF4Ta3tk+TEyPAU7NNDkL+s43SO9R4QHhGbzJUxXzGlpkxp3u nEq874dXHcbArnGH47RueTr+IkGvgDp6K+NhH8M/pWl0 X-Google-Smtp-Source: ABdhPJwygbUkSoZzgacbQT5VMrqz++1f0mPl6HueRjtCaGH3RvZCovKgwUDOsGuyXq2kPKb9IuFQ8eS9sI6ykEEcEOw= X-Received: by 2002:a2e:9802:: with SMTP id a2mr13690032ljj.104.1619463446090; Mon, 26 Apr 2021 11:57:26 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 26 Apr 2021 14:57:14 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000006e586105c0e4b73d" Archived-At: Subject: [OAUTH-WG] Next week's interim meeting cancelled X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 18:57:32 -0000 --0000000000006e586105c0e4b73d Content-Type: text/plain; charset="UTF-8" All, This is to confirm that the meeting that was planned for next week to continue the OAuth 2.1 discussion has been *canceled*. We will schedule a new meeting to continue that discussion when the authors are ready. Regards, Rifaat & Hannes --0000000000006e586105c0e4b73d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This is to confirm that the meetin= g=C2=A0that was planned for next week to continue the OAuth 2.1 discussion = has been canceled.
We will schedule a new meeting to conti= nue that discussion when the authors=C2=A0are ready.

Regards,
=C2=A0Rifaat & Hannes

--0000000000006e586105c0e4b73d-- From nobody Thu Apr 29 06:51:00 2021 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 1EEE53A3F65; Thu, 29 Apr 2021 06:50:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Hannes Tschofenig via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Cc: hannes.tschofenig@arm.com, iesg-secretary@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Message-ID: <161970425810.22894.2145066114109767432@ietfa.amsl.com> Date: Thu, 29 Apr 2021 06:50:58 -0700 Archived-At: Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-par-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 13:50:58 -0000 Hannes Tschofenig has requested publication of draft-ietf-oauth-par-07 as None on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ From nobody Thu Apr 29 08:34:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1383A4027 for ; Thu, 29 Apr 2021 08:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPG1KKfv8fsV for ; Thu, 29 Apr 2021 08:33:55 -0700 (PDT) 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 65EC73A4025 for ; Thu, 29 Apr 2021 08:33:55 -0700 (PDT) Received: from [192.168.1.22] (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 13TFXqSL003694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 29 Apr 2021 11:33:53 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_6E4B784B-8D6B-46E4-93E9-581CE9E8CF9A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <288F1E8C-7C56-4488-8825-791086D6EBCE@mit.edu> Date: Thu, 29 Apr 2021 11:33:52 -0400 To: oauth X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [OAUTH-WG] HTTP Message Signing and OAuth PoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 15:34:01 -0000 --Apple-Mail=_6E4B784B-8D6B-46E4-93E9-581CE9E8CF9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Many of you will remember an old draft that I was the editor of that = defined OAuth proof of possession methods using HTTP Message Signing. = When writing that draft I invented my own scheme because there wasn=E2=80=99= t an existing HTTP message signature standard that was robust enough for = our use cases. I=E2=80=99m happy to say that the landscape has changed: = Annabelle Backman and I have been working in the HTTP Working Group on = HTTP Message Signatures, a general-purpose HTTP signing draft with a lot = of power and a lot of flexibility. There=E2=80=99s even a relatively = straightforward way to map JOSE-defined signature algorithms into this = (even though, to be clear, it is not JOSE-based). The current draft is = here: = https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.h= tml = This draft has gone through a lot of change in the last few months, but = we, the editors, believe that it=E2=80=99s at a fairly stable place in = terms of the core functioning of the protocol now. It=E2=80=99s not = finished yet, but we think that any changes that come from here will be = smaller in scope, more of a cleanup and clarification than the deep = invasive surgery that has happened up until now. One of the things about this draft is that, on its own, it is not = sufficient for a security protocol. By design it needs some additional = details on where to get key materials, how to negotiate algorithms, what = fields need to be covered by the signature, etc. I am proposing that we = in the OAuth WG replace the long-since-expired OAuth PoP working group = draft with a new document based on HTTP Message Signatures. I believe = that this document can be relatively short and to the point, given that = much of the mechanics would be defined in the HTTP draft. If this is = something we would like to do in the WG, I am volunteering to write the = updated draft. I also want to be very clear that I still believe that this lives beside = DPoP, and that DPoP should continue even as we pick this back up. In = fact, I think that this work would take some pressure off of DPoP and = allow it to be the streamlined point solution that it was originally = intended to be. If the chairs would like, I would also be happy to discuss this at an = interim meeting. =E2=80=94 Justin= --Apple-Mail=_6E4B784B-8D6B-46E4-93E9-581CE9E8CF9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Many = of you will remember an old draft that I was the editor of that defined = OAuth proof of possession methods using HTTP Message Signing. When = writing that draft I invented my own scheme because there wasn=E2=80=99t = an existing HTTP message signature standard that was robust enough for = our use cases. I=E2=80=99m happy to say that the landscape has changed: = Annabelle Backman and I have been working in the HTTP Working Group on = HTTP Message Signatures, a general-purpose HTTP signing draft with a lot = of power and a lot of flexibility. There=E2=80=99s even a relatively = straightforward way to map JOSE-defined signature algorithms into this = (even though, to be clear, it is not JOSE-based). The current draft is = here:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-sign= atures-04.html

This draft has gone through a lot of change in the last few = months, but we, the editors, believe that it=E2=80=99s at a fairly = stable place in terms of the core functioning of the protocol now. = It=E2=80=99s not finished yet, but we think that any changes that come = from here will be smaller in scope, more of a cleanup and clarification = than the deep invasive surgery that has happened up until now.

One of the things about = this draft is that, on its own, it is not sufficient for a security = protocol. By design it needs some additional details on where to get key = materials, how to negotiate algorithms, what fields need to be covered = by the signature, etc. I am proposing that we in the OAuth WG replace = the long-since-expired OAuth PoP working group draft with a new document = based on HTTP Message Signatures. I believe that this document can be = relatively short and to the point, given that much of the mechanics = would be defined in the HTTP draft. If this is something we would like = to do in the WG, I am volunteering to write the updated draft.

I also want to be very = clear that I still believe that this lives beside DPoP, and that DPoP = should continue even as we pick this back up. In fact, I think that this = work would take some pressure off of DPoP and allow it to be the = streamlined point solution that it was originally intended to = be.

If the = chairs would like, I would also be happy to discuss this at an interim = meeting.

 =E2=80=94 Justin
= --Apple-Mail=_6E4B784B-8D6B-46E4-93E9-581CE9E8CF9A-- From nobody Thu Apr 29 09:13:42 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90FF3A10DB for ; Thu, 29 Apr 2021 09:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=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=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 IV0DjW-ax_UB for ; Thu, 29 Apr 2021 09:13:36 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1D13A415D for ; Thu, 29 Apr 2021 09:13:36 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id y30so2321687pgl.7 for ; Thu, 29 Apr 2021 09:13:36 -0700 (PDT) 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=dngPwQA7fnCn2e56ZpkhKybPQFhmXUUGKp1pfodtaUw=; b=R9GoCErAdTTG17e340hxP4n/Hx7yfZa3eOLsot6pdJ8B1J42qo0mPqcBkCj0kdKFMx KiYRKjmNGMatjPB2EutjSNmIzpZ+9chpEWBPz5wyjm3WY5CqJIeqex5j11Ly/+6UGItP buqG250/PQH+3VrquoF1nx+NfpgrvvIYERroxeIr94bZcuh5WUT1/iLMVl/stQTcIG5a F4DTHiqt5vtYIe6fZC2ztESaIA7bWZme4BN4V14C44nBdq59kFGjXJBGQHzl5Euy07GS +q/NIEJ49mOUWN2iroJ5tg/mySPFSQAE47SzMaH/yf79V22MwuJGd+MpZvK9E49CapxP v84g== 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=dngPwQA7fnCn2e56ZpkhKybPQFhmXUUGKp1pfodtaUw=; b=PVm294eGkdjUlQGa2bUwyQsjWzjhGdFwIiYqCh1yxanBDOzOpg2DHt2oMcSyYWHXF5 FBhdjjWwZM/UiKtuguIKKy+M4/RDUYTbHR4zG3VVUwA6Ijsu7H5ceFzpOCXu+09gOupr 1b8GH2U3GJCmywfhVMuomamtFtTGNfVui8wrfmfXxany9K7EPj5X1N5U/UvmfVP7jbpo mxpNaOOw8BdJ+18mh0h+HvdVh8QFaXpdS0wqjXuQHcYSrooUZuqnh9EuWkVp0z213rkv BsD0YrDHeMupP4P6PSevRYeYRjcw428pbttVt3g4+7eK27clEtkOWVhz4btyAMnmrjEf xq5w== X-Gm-Message-State: AOAM5323a2htntEa3vaUsZIAADelD0591Caryt73B/r+hRYg4/cSYhSR sSROqDuAvSp5zjgSAE1etxVlQJWTtVC6TA== X-Google-Smtp-Source: ABdhPJzZdIsCb2UV4cyZrYsqsCc5Kx6f96y+GhlZxdkfwO+KYo+QX+l3YNIRnupxh+GJ7ZgfiC1bjg== X-Received: by 2002:a63:f258:: with SMTP id d24mr463801pgk.174.1619712814710; Thu, 29 Apr 2021 09:13:34 -0700 (PDT) Received: from ?IPv6:2001:569:7a71:1d00:8837:96a:f01b:baae? (node-1w7jr9qrfoxx9lgl2e3usse5q.ipv6.telus.net. [2001:569:7a71:1d00:8837:96a:f01b:baae]) by smtp.gmail.com with ESMTPSA id mp3sm2734581pjb.15.2021.04.29.09.13.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Apr 2021 09:13:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-EB3D11EF-0A52-40BA-97F3-F98DF48AFDFB Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Thu, 29 Apr 2021 09:13:33 -0700 Message-Id: <0D578BC6-B402-460D-8DFD-5A367E48A9D7@independentid.com> References: <288F1E8C-7C56-4488-8825-791086D6EBCE@mit.edu> Cc: oauth In-Reply-To: <288F1E8C-7C56-4488-8825-791086D6EBCE@mit.edu> To: Justin Richer X-Mailer: iPhone Mail (18D70) Archived-At: Subject: Re: [OAUTH-WG] HTTP Message Signing and OAuth PoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 16:13:41 -0000 --Apple-Mail-EB3D11EF-0A52-40BA-97F3-F98DF48AFDFB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Justin Thanks for this. I am pleased the HTTPbis group took this up. It is a multi-= WG issue that needs their expertise.=20 I look forward to reading the new draft. Cheers, Phil > On Apr 29, 2021, at 8:34 AM, Justin Richer wrote: >=20 > =EF=BB=BFMany of you will remember an old draft that I was the editor of t= hat defined OAuth proof of possession methods using HTTP Message Signing. Wh= en writing that draft I invented my own scheme because there wasn=E2=80=99t a= n existing HTTP message signature standard that was robust enough for our us= e cases. I=E2=80=99m happy to say that the landscape has changed: Annabelle B= ackman and I have been working in the HTTP Working Group on HTTP Message Sig= natures, a general-purpose HTTP signing draft with a lot of power and a lot o= f flexibility. There=E2=80=99s even a relatively straightforward way to map J= OSE-defined signature algorithms into this (even though, to be clear, it is n= ot JOSE-based). The current draft is here: >=20 > https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.h= tml >=20 > This draft has gone through a lot of change in the last few months, but we= , the editors, believe that it=E2=80=99s at a fairly stable place in terms o= f the core functioning of the protocol now. It=E2=80=99s not finished yet, b= ut we think that any changes that come from here will be smaller in scope, m= ore of a cleanup and clarification than the deep invasive surgery that has h= appened up until now. >=20 > One of the things about this draft is that, on its own, it is not sufficie= nt for a security protocol. By design it needs some additional details on wh= ere to get key materials, how to negotiate algorithms, what fields need to b= e covered by the signature, etc. I am proposing that we in the OAuth WG repl= ace the long-since-expired OAuth PoP working group draft with a new document= based on HTTP Message Signatures. I believe that this document can be relat= ively short and to the point, given that much of the mechanics would be defi= ned in the HTTP draft. If this is something we would like to do in the WG, I= am volunteering to write the updated draft. >=20 > I also want to be very clear that I still believe that this lives beside D= PoP, and that DPoP should continue even as we pick this back up. In fact, I t= hink that this work would take some pressure off of DPoP and allow it to be t= he streamlined point solution that it was originally intended to be. >=20 > If the chairs would like, I would also be happy to discuss this at an inte= rim meeting. >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-EB3D11EF-0A52-40BA-97F3-F98DF48AFDFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Justin

Thanks for this. I= am pleased the HTTPbis group took this up. It is a multi-WG issue that need= s their expertise. 

I look forward to reading t= he new draft.

Cheers,

Phil<= /div>

On Apr 29, 2021, at 8:34= AM, Justin Richer <jricher@mit.edu> wrote:

=
=EF=BB=BFMany of you will remember a= n old draft that I was the editor of that defined OAuth proof of possession m= ethods using HTTP Message Signing. When writing that draft I invented my own= scheme because there wasn=E2=80=99t an existing HTTP message signature stan= dard that was robust enough for our use cases. I=E2=80=99m happy to say that= the landscape has changed: Annabelle Backman and I have been working in the= HTTP Working Group on HTTP Message Signatures, a general-purpose HTTP signi= ng draft with a lot of power and a lot of flexibility. There=E2=80=99s even a= relatively straightforward way to map JOSE-defined signature algorithms int= o this (even though, to be clear, it is not JOSE-based). The current draft i= s here:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatur= es-04.html

Thi= s draft has gone through a lot of change in the last few months, but we, the= editors, believe that it=E2=80=99s at a fairly stable place in terms of the= core functioning of the protocol now. It=E2=80=99s not finished yet, but we= think that any changes that come from here will be smaller in scope, more o= f a cleanup and clarification than the deep invasive surgery that has happen= ed up until now.

O= ne of the things about this draft is that, on its own, it is not sufficient f= or a security protocol. By design it needs some additional details on where t= o get key materials, how to negotiate algorithms, what fields need to be cov= ered by the signature, etc. I am proposing that we in the OAuth WG replace t= he long-since-expired OAuth PoP working group draft with a new document base= d on HTTP Message Signatures. I believe that this document can be relatively= short and to the point, given that much of the mechanics would be defined i= n the HTTP draft. If this is something we would like to do in the WG, I am v= olunteering to write the updated draft.

=
I also want to be very clear that I still believe that= this lives beside DPoP, and that DPoP should continue even as we pick this b= ack up. In fact, I think that this work would take some pressure off of DPoP= and allow it to be the streamlined point solution that it was originally in= tended to be.

If t= he chairs would like, I would also be happy to discuss this at an interim me= eting.

 =E2=80= =94 Justin
_______________________________________________=
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-EB3D11EF-0A52-40BA-97F3-F98DF48AFDFB-- From nobody Thu Apr 29 11:51:26 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910463A136C for ; Thu, 29 Apr 2021 11:51:24 -0700 (PDT) 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 tmTN_Tgll5wa for ; Thu, 29 Apr 2021 11:51:20 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB7E3A1369 for ; Thu, 29 Apr 2021 11:51:19 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id v6so940654ljj.5 for ; Thu, 29 Apr 2021 11:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wiqGO1eGVZVs+OgpAOd1SO3ghNGl9m205VW6jijJpWM=; b=fOxnhayOJCQEfyh827HcCoGVwjsgfRbwdAwx3+ZfTXMXV5powCgr9MkvvcHuoMZ3hs 4nSv9h5ul35BsEDgwPdobS1tov98uY9qvz+f2dTynBX3W9Hkj6yp3ujLWzqe76LXspbT rXZyzFXJJWHHMlJ1AXChhHVXuvvGL/8VTNoptZscgzGmDjRC4U/m8NWmEaCKMdoy7MGa 3brOBG6+EeUc94V+nqbwyvwEb89rOT0AB229/F9LxX2HanlT1pGP8d6ofDAq77BT2GML Z+tRvgNd//MK6b0RwPXo24t/IGXmjIO5T13w34MBR1Acqv5gNB5EKBJ5ivXzcc72W6hq r5hw== 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=wiqGO1eGVZVs+OgpAOd1SO3ghNGl9m205VW6jijJpWM=; b=umXq9QtVGV+8KFvS8sIdtKJWiQ2/nEozFCS6wRMPY3qtI2zgeD7s4SwIlfwdtx7Tys vK8gZIHvGWIi1TlzqfKlpf6cPywwjaVGT/yNYNiPb01dyNnntXQR7VfIyEj87GebnbNm 2AZr1HdHco5mA9Yoqd4XUt79ePqOJbmlGSV1aHGi68PuSv61EiY6AcNT3IzRYt72oDLW f7hYK1MQvTfx4BBFi/0ezRrBWe8SijhY8V5WvDLBaKbMkY1szExyy26zO0ATaeMNlhLe 7BDEg11Anpnkfy/cS4m5gxp//ZhVuXN3O2Q8ZFtiIX1g1uLUP3/HDgHkFvZVdBjEVRyZ 0U2A== X-Gm-Message-State: AOAM531BQTsD/Io11G5RoJ8I9HMcf+bBgW82oHpwsWtjh5++U34Ukfkt NB8QLNOvp7bi8mvXS/6Xicmlz3v2uhyPt/84kQI2925V0zY= X-Google-Smtp-Source: ABdhPJx/0hJJivtCAv2rw0bW10uRxBmOP8c17v/VHRIYui7CcwTe+nIHwf/TvnH1/QjZB+tOtaLrt8kddYavb8m0pPs= X-Received: by 2002:a05:651c:224:: with SMTP id z4mr823734ljn.350.1619722276652; Thu, 29 Apr 2021 11:51:16 -0700 (PDT) MIME-Version: 1.0 References: <288F1E8C-7C56-4488-8825-791086D6EBCE@mit.edu> In-Reply-To: <288F1E8C-7C56-4488-8825-791086D6EBCE@mit.edu> From: Rifaat Shekh-Yusef Date: Thu, 29 Apr 2021 14:51:05 -0400 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="000000000000ef49fb05c120fa5d" Archived-At: Subject: Re: [OAUTH-WG] HTTP Message Signing and OAuth PoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 18:51:25 -0000 --000000000000ef49fb05c120fa5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, Thanks for the update on this, We would be happy to schedule an interim meeting to discuss this. Do you have a date in mind? Regards, Rifaat & Hannes On Thu, Apr 29, 2021 at 11:34 AM Justin Richer wrote: > Many of you will remember an old draft that I was the editor of that > defined OAuth proof of possession methods using HTTP Message Signing. Whe= n > writing that draft I invented my own scheme because there wasn=E2=80=99t = an > existing HTTP message signature standard that was robust enough for our u= se > cases. I=E2=80=99m happy to say that the landscape has changed: Annabelle= Backman > and I have been working in the HTTP Working Group on HTTP Message > Signatures, a general-purpose HTTP signing draft with a lot of power and = a > lot of flexibility. There=E2=80=99s even a relatively straightforward way= to map > JOSE-defined signature algorithms into this (even though, to be clear, it > is not JOSE-based). The current draft is here: > > > https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.= html > > This draft has gone through a lot of change in the last few months, but > we, the editors, believe that it=E2=80=99s at a fairly stable place in te= rms of the > core functioning of the protocol now. It=E2=80=99s not finished yet, but = we think > that any changes that come from here will be smaller in scope, more of a > cleanup and clarification than the deep invasive surgery that has happene= d > up until now. > > One of the things about this draft is that, on its own, it is not > sufficient for a security protocol. By design it needs some additional > details on where to get key materials, how to negotiate algorithms, what > fields need to be covered by the signature, etc. I am proposing that we i= n > the OAuth WG replace the long-since-expired OAuth PoP working group draft > with a new document based on HTTP Message Signatures. I believe that this > document can be relatively short and to the point, given that much of the > mechanics would be defined in the HTTP draft. If this is something we wou= ld > like to do in the WG, I am volunteering to write the updated draft. > > I also want to be very clear that I still believe that this lives beside > DPoP, and that DPoP should continue even as we pick this back up. In fact= , > I think that this work would take some pressure off of DPoP and allow it = to > be the streamlined point solution that it was originally intended to be. > > If the chairs would like, I would also be happy to discuss this at an > interim meeting. > > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ef49fb05c120fa5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

Thanks for = the update on this,
We would be happy to schedule an interim meet= ing to discuss this.=C2=A0
Do you have a date in mind?
<= div>

Regards,
=C2=A0Rifaat & Hannes
<= div>

<= div>


On Thu, Apr 29, 2021 at 11:34 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu">jricher@mit.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Many of you will remember an old draft that I was the edito= r of that defined OAuth proof of possession methods using HTTP Message Sign= ing. When writing that draft I invented my own scheme because there wasn=E2= =80=99t an existing HTTP message signature standard that was robust enough = for our use cases. I=E2=80=99m happy to say that the landscape has changed:= Annabelle Backman and I have been working in the HTTP Working Group on HTT= P Message Signatures, a general-purpose HTTP signing draft with a lot of po= wer and a lot of flexibility. There=E2=80=99s even a relatively straightfor= ward way to map JOSE-defined signature algorithms into this (even though, t= o be clear, it is not JOSE-based). The current draft is here:


This= draft has gone through a lot of change in the last few months, but we, the= editors, believe that it=E2=80=99s at a fairly stable place in terms of th= e core functioning of the protocol now. It=E2=80=99s not finished yet, but = we think that any changes that come from here will be smaller in scope, mor= e of a cleanup and clarification than the deep invasive surgery that has ha= ppened up until now.

One of the things about this = draft is that, on its own, it is not sufficient for a security protocol. By= design it needs some additional details on where to get key materials, how= to negotiate algorithms, what fields need to be covered by the signature, = etc. I am proposing that we in the OAuth WG replace the long-since-expired = OAuth PoP working group draft with a new document based on HTTP Message Sig= natures. I believe that this document can be relatively short and to the po= int, given that much of the mechanics would be defined in the HTTP draft. I= f this is something we would like to do in the WG, I am volunteering to wri= te the updated draft.

I also want to be very clear= that I still believe that this lives beside DPoP, and that DPoP should con= tinue even as we pick this back up. In fact, I think that this work would t= ake some pressure off of DPoP and allow it to be the streamlined point solu= tion that it was originally intended to be.

If the= chairs would like, I would also be happy to discuss this at an interim mee= ting.

=C2=A0=E2=80=94 Justin
__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ef49fb05c120fa5d-- From nobody Fri Apr 30 10:00:40 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E673A1F8A for ; Fri, 30 Apr 2021 10:00:39 -0700 (PDT) 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, 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 AsS7omN6cTRL for ; Fri, 30 Apr 2021 10:00:36 -0700 (PDT) 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 392483A1F89 for ; Fri, 30 Apr 2021 10:00:36 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id q127so12194817qkb.1 for ; Fri, 30 Apr 2021 10:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:user-agent; bh=+uCwZsBwFMP+a36f7cIMfDyij0p+pPfs/cXb8A2OfdM=; b=okGDObeX6uXeF0/x2s0VfDMslxoxsaljFYo2c89PYIFvntaBottTGArxwsv5VQuyT7 FdeQeJQ7a00VyZhm/p7w/i2uqfLcs768Bq95FdednpH9ITivfGgXVnaPzIfDFlB7qpxY G0p432FEhj+H7nF1SAmYHWNmOjJ//pq+kzF/xdMGoTOZRjGWMgCxWaE1JtlYWB5YmcsZ rK8Kd1r2nYeC/njXvxIN4+/JGUSFO2GNYr99x032m4Ov9/owQisKnAXGkNG8q8GHrHCB lRoKVQy30hYUyrMn8R6tL73Nn4vxDDjjf2W3X3OJDrHFYnVCIdguG5d3fbFTrtQFFIF6 WKxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :user-agent; bh=+uCwZsBwFMP+a36f7cIMfDyij0p+pPfs/cXb8A2OfdM=; b=idKPpHkZdVKpOeQCU9q9iGz2P+km1kqdK8lTSi/sIwSLmHTtBCdoxrIy3nkHI1SGHW ozlg1BgQMi6gTuSkHOhRtYG5GGG5CFUgjxgtL5XY3R9PBU6Q6uD/FEbR0SjfskdcK4pj mErQdUjSmn35nD99iSXlyqjL9vh+ak8ViOq+7lP5DDEKAd+Ro6GirvY3/yA44v+xYh9A f7aWip6muVVow3OKfjQlrAvYPoVzHt1Ns8Cf8SScts4pMRvV0cWCrEFB5fjj1gvjDlVF AMzF8DgKON0ipg29kVEjWlRpl7nJyU2u2ZUEc/G5azW7RqDLmdJyzVVXo3DFXq5COiNS /yvA== X-Gm-Message-State: AOAM531jQL+YoCT9+C9+/EUIRW9S82fJtCmVFZHpDVG/K+vuUi/fY4np yg3fquzQqwRm0jh+Ngx13T2Xp8zxvANACQ== X-Google-Smtp-Source: ABdhPJwHETcM0gbkKOvjSem1t9eE6XlUlfi58il8Zm+fT7Zcybow9dxsF4XqkhqI17TuAMsTE3qExA== X-Received: by 2002:a05:620a:1224:: with SMTP id v4mr6371142qkj.237.1619802033855; Fri, 30 Apr 2021 10:00:33 -0700 (PDT) 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 s190sm1869697qkc.40.2021.04.30.10.00.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Apr 2021 10:00:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_26098197.719678388644" MIME-Version: 1.0 Date: Fri, 30 Apr 2021 13:00:33 -0400 Message-ID: From: "Brock Allen" To: "" User-Agent: Mailbird/2.9.29.0 X-Mailbird-ID: Mailbird-815c2b72-1a27-4133-b6a0-d7822931cc78@gmail.com Archived-At: Subject: [OAUTH-WG] thoughts on TMI BFF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 17:00:40 -0000 ------=_NextPart_26098197.719678388644 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello all --=C2=A0 I just watched the recent=C2=A0OAuth WG Interim call on TMI BFF and had som= e thoughts/feedback. First of all, thanks Vittorio and Brian for the effort and allowing this di= scussion. Given Vittorio's former employer I'm sure he's familiar with the = "rude Q&A" process, so this feedback is with all due respect. :) 1) The guidance on the headers for the user/session endpoint=C2=A0is welcom= e and needed, and not only for this endpoint but any endpoints the frontend= would be invoking. That kind of help is lacking in general in the industry= . I didn't look at the specific headers mentioned, but it might be good to = discuss xsrf issues and cookie prefix guidance as well. 2) The user/session endpoint feels a lot like authentication and session ma= nagement related, which historically falls to OIDC, and so this feels a bit= out of place in an OAuth RFC. Recall that the client might not have even a= uthenticated the user, so what happens in that case? So for that reason it = feels like this concept should not be here, but rather in an OIDC document. If this is not the will of the committee, then it feels like the user/sessi= on endpoint doesn't go far enough. As Aaron suggested, perhaps there's some= minimum set of claims to consider (especially if interoperability is liste= d as a requirement). But then that leads back to=C2=A0irreconcilable minuti= ae=C2=A0such as should we use "sub" and does "sub" mean user or client (to = use as an extreme example). Also, why would "iss" make sense, if the backen= d is abstracting the protocol details. I know those were examples in the sl= ides, but I can see those discussions being challen.. er... fun :) Additionally, there should be other features covered such as how to handle = session management such as inactivity expiration, initiating login and/or l= ogout from the frontend (which might involve an id_token or at least a "sid= " claim value for logout), and how to handle SLO notifications between the = frontend and backend (which might involve sharing a session state value), a= nd how to expose all those endpoints securely. This obviously is a slippery slope of features (and all heavily leaning mor= e into OIDC's area), but it feels incomplete if you're offering a framework= for a frontend to work with a backend on "protocol related things" which i= s more than just getting an access token. If it's not all covered, then peo= ple will homebrew it which is what this effort is meant to curtail. So, IMO, the user endpoint concept should be all or nothing. And if it's no= thing in the OAuth WG, perhaps it should be brought up in an OIDF context. 3) If the user/session endpoint is removed from the document, then it leave= s coverage on just the one endpoint to obtain access tokens. As I mentioned= , the headers guidance is quite valuable but it's useful for almost any bac= kend request. This all seems like perhaps it's better placed in the Browser= Apps BCP instead. 4) Torsten's comments got me thinking about the renewal of the access token= and how that can be quite coupled with the interaction with the API. Given= this interaction it feels like it makes more sense to have those done toge= ther, rather than asking the frontend to marshal/broker that coordination b= etween the API and backend. This somewhat defeats the goal of the document = to simplify the code in the frontend. And this also suggests (to me, at lea= st) that perhaps the better place for all that coupled coordination is in t= he backend with the reverse=C2=A0proxy style, but I digress. I know another motivation for the document is that there are some set of ap= plications have a performance requirement and can't afford the additional h= op of the reverse proxy style. So if the frontend is doing that coordinatio= n between API and token renewal then it will add some more overhead to do t= hat brokering, albeit infrequently. This is,=C2=A0arguably,=C2=A0a nit. 5) For me personally in all the consulting I've done helping customers use = OIDC/OAuth over the past 7 years (since OIDC was released) I've never seen = anyone trying to do it this way. I do believe that some people try this sty= le, but I wonder if it's just because they don't know any better (so lackin= g guidance) or is it really because they're actively trying to mitigate the= reverse proxy hop performance issue? If it's the former, then I don't agre= e that it makes sense to formalize a less secure approach when they simply = need better guidance (which arguably is the "full BFF" approach), and thus = the motivation for the document is slightly weakened (IMO). Thanks. -Brock ------=_NextPart_26098197.719678388644 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hello all -- = ;

I just watched the recent OAuth WG Interim call on TMI BFF and had some thoughts/feedback.

First of all, thanks Vittorio and Brian for the = effort and allowing this discussion. Given Vittorio's former employer I'm s= ure he's familiar with the "rude Q&A" process, so this feedback is with= all due respect. :)

1) The guidance on the= headers for the user/session endpoint is welcome and needed, and not only for this endpoint but any endpoints th= e frontend would be invoking. That kind of help is lacking in general in th= e industry. I didn't look at the specific headers mentioned, but it might b= e good to discuss xsrf issues and cookie prefix guidance as well.

2) The user/session endpoint feels a lot like authenti= cation and session management related, which historically falls to OIDC, an= d so this feels a bit out of place in an OAuth RFC. Recall that the client = might not have even authenticated the user, so what happens in that case? S= o for that reason it feels like this concept should not be here, but rather= in an OIDC document.

If this is not the will of the committee, then= it feels like the user/session endpoint doesn't go far enough. As Aaron su= ggested, perhaps there's some minimum set of claims to consider (especially= if interoperability is listed as a requirement). But then that leads back = to irreconcilable minutiae = ;such as should we use "sub" and doe= s "sub" mean user or client (to use as an extreme example). Also, why would= "iss" make sense, if the backend is abstracting the protocol details. I kn= ow those were examples in the slides, but I can see those discussions being= challen.. er... fun :)

Additionally, there should be other features= covered such as how to handle session management such as inactivity expira= tion, initiating login and/or logout from the frontend (which might involve= an id_token or at least a "sid" claim value for logout), and how to handle= SLO notifications between the frontend and backend (which might involve sh= aring a session state value), and how to expose all those endpoints securel= y.

<= span style=3D"font-size: 10pt">This obviously is a slippery slope of featur= es (and all heavily leaning more into OIDC's area), but it feels incomplete= if you're offering a framework for a frontend to work with a backend on "p= rotocol related things" which is more than just getting an access token. If= it's not all covered, then people will homebrew it which is what this effo= rt is meant to curtail.
So, IMO, the user endpoint concept should be all or not= hing. And if it's nothing in the OAuth WG, perhaps it should be brought up = in an OIDF context.

3) If the user/session endpoint is removed from the document,= then it leaves coverage on just the one endpoint to obtain access tokens. = As I mentioned, the headers guidance is quite valuable but it's useful for = almost any backend request. This all seems like perhaps it's better placed = in the Browser Apps BCP instead.

4) Torst= en's comments got me thinking about the renewal of the access token and how= that can be quite coupled with the interaction with the API. Given this in= teraction it feels like it makes more sense to have those done together, ra= ther than asking the frontend to marshal/broker that coordination between t= he API and backend. This somewhat defeats the goal of the document to simpl= ify the code in the frontend. And this also suggests (to me, at least) that= perhaps the better place for all that coupled coordination is in the backe= nd with the reverse proxy style, but I digress.

I know another motivation for the document is that there = are some set of applications have a performance requirement and can't affor= d the additional hop of the reverse proxy style. So if the frontend is doin= g that coordination between API and token renewal then it will add some mor= e overhead to do that brokering, albeit infrequently. This is, = arguably, a nit.

5) For me personally in all the consulting I've done helping cu= stomers use OIDC/OAuth over the past 7 years (since OIDC was released) I've= never seen anyone trying to do it this way. I do believe that some people = try this style, but I wonder if it's just because they don't know any bette= r (so lacking guidance) or is it really because they're actively trying to = mitigate the reverse proxy hop performance issue? If it's the former, then = I don't agree that it makes sense to formalize a less secure approach when = they simply need better guidance (which arguably is the "full BFF" approach= ), and thus the motivation for the document is slightly weakened (IMO).

Thanks.

-Brock

------=_NextPart_26098197.719678388644--