From nobody Sun Oct 1 19:57:57 2017 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 8736713431B; Sun, 1 Oct 2017 19:57:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: Cc: oauth@ietf.org, draft-ietf-oauth-discovery.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150691307049.28713.16129351135750922617@ietfa.amsl.com> Date: Sun, 01 Oct 2017 19:57:50 -0700 Archived-At: Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-discovery-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 02:57:50 -0000 Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-ietf-oauth-discovery-07 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-discovery-07.txt Reviewer: Brian Carpenter Review Date: 2017-10-02 IETF LC End Date: 2017-10-09 IESG Telechat date: Summary: Ready -------- Comment: -------- As far as my competence goes, I have no issues with this draft. Just for fun, I checked that the JSON example works as the value of a GRASP objective (draft-ietf-anima-grasp) with the GRASP prototype code. And yes, of course it does, so we could map OAuth over the ANIMA discover/synchronize model if we wanted. FWIW there are a couple of errors in the shepherd's writeup: > This document does not request any actions by IANA. > > 18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. > > None. Wrong, there are extensive IANA considerations and a requirement for multiple Designated Experts. > There is no text in formal languages in the document. Maybe not, but there is a JSON example (which as noted above seems to be fine). -- From nobody Tue Oct 3 06:51:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28043134602 for ; Tue, 3 Oct 2017 06:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viz5vnOfj9Rl for ; Tue, 3 Oct 2017 06:51:10 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0099.outbound.protection.outlook.com [104.47.38.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709321345E3 for ; Tue, 3 Oct 2017 06:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6gQSepqKwPDeJ7ptrwCyejvzuMj3zAZMM32hiJu67RE=; b=Kv/C2TX3crIrPpMNKgM9S+zx25BA5VOAVOmYXdTq7Sb9VHCFCS7EwDq4wtR+8xKwufoQ7X7GWZrqeSe8H5nYoORWQC/Obfp4ZbWK/Gm4Ih9ln/kqV01hNphzxRWspItZBLVVG5CKu8XbiiNL/RwtjjcUVRLY1TLmwEIlbYo39y0= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0151.namprd21.prod.outlook.com (10.173.189.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.122.0; Tue, 3 Oct 2017 13:51:08 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0122.000; Tue, 3 Oct 2017 13:51:08 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Adding a SAML 2 token type to the OAuth Token Exchange spec Thread-Index: AdM8TmiMyZFiaKDRSBqiPBGbOdL9Lw== Date: Tue, 3 Oct 2017 13:51:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.130.119.138] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0151; 6:jSc/MSU0AJdA6m8dLxL4B4jIAmCIKwC+y6K60VFTDVbxdz1/NoI4aO8WHjBkYiJTjMXnuwCoPmthRRyw8x7sAJQNfgZDFhhem9hEonlZR8sfcsqdAn1NfREd9xtH7+ZeFUq/XXr4VSztWQE7OByv8QYp8Pg0GfS+/CrMvn0BPnEld+zCAQktvIdgMxdTQrXKwJR2Eyzuh6A7Xj781tYvjlDUK/E6/CgUX+9LwYS3teWHthbTkTrMTAPveNxQ/jprLJyokuXNoc2xZIuCby3AqezqS/i4IzbH3zd+67LXkKCAAd/ZKfYfp7L6z8d/+d0YGK1DBVsMKjrBe+bsgj14QA==; 5:mYy2gEyS8JYzY5dTZkV2R1pQuMauWhF3v8zTiNEefdZLJWYZ3AJDrYCdP6IRt+eEue5JcgnMyAuT3sH0dHgVMCl6tP8MSmnxq9jXOBsNOwRQX/WORCUK4wPmH7p+PNjjcN3+F4Qf1MD4F621fycVdA==; 24:WMMMj6O7azH0i90PKu8Mk47hbojpnollmEloGDaLfLZ12JwBtNhgAFbvQhWXAOeCjF0Y97T09MhdU6n4dJjFhm1knbd+jQbREOaFRjSKsA8=; 7:D5EpvTL/LJ6z+M+HvotiHGoqWcN2XkqxIs+HHaiv1WGTsiRuYNHPFvYsPlXyBlK8rlG5Ymttd0nLjSyepGXwC1VL0hm41Z9nNMGqQLmlqacisxkXVhuXYnoGBYI9rVxh5mn1MjLizcFrtMYDALglsBjYVE+Xpy/zM5QbP6i9q+RRgM9/C1XpU3mNFhjxQcifl6tj7RwAWWQwKoUMQJXK2XTz4X2ZVfDY6JeVq+SfUOo= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 227374a1-2416-4ec4-a252-08d50a65cced x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0151; x-ms-traffictypediagnostic: CY4PR21MB0151: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(12181511122)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0151; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0151; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(47760400005)(189002)(199003)(9686003)(54896002)(6306002)(53936002)(101416001)(8990500004)(55016002)(99286003)(7736002)(50986999)(54356999)(74316002)(10090500001)(14454004)(72206003)(106356001)(478600001)(105586002)(81156014)(68736007)(2351001)(33656002)(81166006)(1730700003)(10290500003)(8676002)(2900100001)(8936002)(25786009)(22452003)(6116002)(790700001)(102836003)(3846002)(86362001)(66066001)(316002)(86612001)(2906002)(6916009)(2501003)(3660700001)(7696004)(6436002)(189998001)(5640700003)(97736004)(5660300001)(3280700002)(77096006)(6506006)(5630700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0151; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05049AF48AB53010817C8521F5720CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 227374a1-2416-4ec4-a252-08d50a65cced X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2017 13:51:08.7702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0151 Archived-At: Subject: [OAUTH-WG] Adding a SAML 2 token type to the OAuth Token Exchange spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 13:51:12 -0000 --_000_CY4PR21MB05049AF48AB53010817C8521F5720CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A Microsoft use case has come up in which people would like to perform a to= ken exchange for a SAML token. The spec already defines urn:ietf:params:oau= th:token-type:jwt for requesting JWT tokens. Would anybody object to us ad= ding urn:ietf:params:oauth:token-type:saml2 to the next draft to also give = us a standard way to ask for SAML 2.0 tokens? It could always be done in its own spec, but adding it in Token Exchange se= ems more expedient. -- Mik= e --_000_CY4PR21MB05049AF48AB53010817C8521F5720CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A Microsoft use case has come up in which people wou= ld like to perform a token exchange for a SAML token. The spec already defi= nes urn:ietf:params:oauth:t= oken-type:jwt for requesting JWT tokens.  Would anybody object = to us adding urn:ietf:params:oauth:t= oken-type:saml2 to the next draft to also give us a standard way to = ask for SAML 2.0 tokens?

 

It could always be done in its own spec, but adding = it in Token Exchange seems more expedient.

 

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

 

 

--_000_CY4PR21MB05049AF48AB53010817C8521F5720CY4PR21MB0504namp_-- From nobody Tue Oct 3 23:13:04 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3A3132D51 for ; Tue, 3 Oct 2017 23:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1jBBkvBV9mj for ; Tue, 3 Oct 2017 23:13:02 -0700 (PDT) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (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 F17CD1320D9 for ; Tue, 3 Oct 2017 23:13:01 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id zcvTdZHRWLYnizcvUdymmd; Tue, 03 Oct 2017 23:13:01 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <34a5f621-3ec1-d0c4-b669-e894662bb2ff@connect2id.com> Date: Wed, 4 Oct 2017 09:12:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080201060101070505000004" X-CMAE-Envelope: MS4wfJOrEJsO7f/mkyzAaOQL4CMXmmV84k3wI1i8uw+7tsDJZ0jfO6IKtijhWT3gZTm9AjXqOpNpV2jvfHgGhVzPAWhTnllYqDw0fJDJkEORA9+7ZMUzzsxQ 07FeDJvvm9I2KbfDBhv1lj3E6GZgUUtZQ+ed7a3Eta77G3tC2xIyDGFg Archived-At: Subject: Re: [OAUTH-WG] Adding a SAML 2 token type to the OAuth Token Exchange spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 06:13:03 -0000 This is a cryptographically signed message in MIME format. --------------ms080201060101070505000004 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US +1 Vladimir PS: Am I correct that the current token exchange spec can be used with mTLS and token binding as it is, without any additional changes? On 03/10/17 16:51, Mike Jones wrote: > A Microsoft use case has come up in which people would like to perform = a token exchange for a SAML token. The spec already defines urn:ietf:para= ms:oauth:token-type:jwt for requesting JWT tokens. Would anybody object = to us adding urn:ietf:params:oauth:token-type:saml2 to the next draft to = also give us a standard way to ask for SAML 2.0 tokens? > > It could always be done in its own spec, but adding it in Token Exchang= e seems more expedient. > > --= Mike --------------ms080201060101070505000004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEwMDQwNjEyNThaMC8GCSqGSIb3DQEJBDEiBCA5/AfqQrextaSU9ru/EyU40BqlbIDL 23I9nuap37PkbjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQBt8wxLa5k6 5e5anIUZkYbY0NHTKiDne3xQ1n01yA97tZoVKVCaG8h6OkuaRGz4m4eGsRFvJuKw/x4rmvCJ JzuCZAT2KpGHrK5qSBW3WBF8o12cFWLpc5QrFrYpmNs7xCe7nI57atc8gy1OrAuZ/u9eBtS4 akvsAkErp+2lbQW5sdVxZE6df55ln/AngJvpwFraV3g9luTru9e18dmYBHhFH6Dt0tcG534D K9DxPOK6P7ld0341aoD+9Tep2Rms5C69oj3SMTYPVM+J0XHCZS9Xai80edL/XI4x3PwrihHS mDqvP/OzQJfHDv/0GVH53IHXfy08gVoA7K7q8woJMlkmAAAAAAAA --------------ms080201060101070505000004-- From nobody Wed Oct 4 10:04:55 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E57913422B; Wed, 4 Oct 2017 10:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8V4wAXNCF2j; Wed, 4 Oct 2017 10:04:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B11133341; Wed, 4 Oct 2017 10:04:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 783C2B81F32; Wed, 4 Oct 2017 10:04:41 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org Message-Id: <20171004170441.783C2B81F32@rfc-editor.org> Date: Wed, 4 Oct 2017 10:04:41 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] BCP 212, RFC 8252 on OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 17:04:48 -0000 A new Request for Comments is now available in online RFC libraries. BCP 212 RFC 8252 Title: OAuth 2.0 for Native Apps Author: W. Denniss, J. Bradley Status: Best Current Practice Stream: IETF Date: October 2017 Mailbox: rfc8252@wdenniss.com, rfc8252@ve7jtb.com Pages: 21 Characters: 49680 Updates: RFC 6749 See Also: BCP 212 I-D Tag: draft-ietf-oauth-native-apps-12.txt URL: https://www.rfc-editor.org/info/rfc8252 DOI: 10.17487/RFC8252 OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. This document is a product of the Web Authorization Protocol Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Oct 6 08:41:55 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79011349B4 for ; Fri, 6 Oct 2017 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knpjO49xoY7i for ; Fri, 6 Oct 2017 08:41:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2F6132D17 for ; Fri, 6 Oct 2017 08:41:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 69C98B80C69; Fri, 6 Oct 2017 08:41:44 -0700 (PDT) To: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: brian.vosburgh@oracle.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171006154144.69C98B80C69@rfc-editor.org> Date: Fri, 6 Oct 2017 08:41:44 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5147) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 15:41:54 -0000 The following errata report has been submitted for RFC8252, "OAuth 2.0 for Native Apps". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5147 -------------------------------------- Type: Editorial Reported by: Brian Vosburgh Section: 6 Original Text ------------- Native apps needing user authorization create an authorization request URI with the authorization code grant type per Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being received by the native app. Corrected Text -------------- Notes ----- The embedded link for the text "Section 4.1" points at Section 4.1 of *this* RFC (i.e. https://tools.ietf.org/html/rfc8252#section-4.1); but, given the context of the surrounding text, it should point at Section 4.1 of *RFC6749* (i.e. https://tools.ietf.org/html/rfc6749#section-4.1). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8252 (draft-ietf-oauth-native-apps-12) -------------------------------------- Title : OAuth 2.0 for Native Apps Publication Date : October 2017 Author(s) : W. Denniss, J. Bradley Category : BEST CURRENT PRACTICE Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Oct 6 09:09:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04B1124B17 for ; Fri, 6 Oct 2017 09:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzkHRQKEWTlH for ; Fri, 6 Oct 2017 09:09:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89313134A04 for ; Fri, 6 Oct 2017 09:09:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 11F3AB81058; Fri, 6 Oct 2017 09:09:31 -0700 (PDT) To: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: brian.vosburgh@oracle.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171006160931.11F3AB81058@rfc-editor.org> Date: Fri, 6 Oct 2017 09:09:31 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5148) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:09:41 -0000 The following errata report has been submitted for RFC8252, "OAuth 2.0 for Native Apps". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5148 -------------------------------------- Type: Editorial Reported by: Brian Vosburgh Section: 8.1 Original Text ------------- Section 1 of PKCE [RFC7636] details how this limitation can be used to execute a code interception attack. Corrected Text -------------- Notes ----- The embedded link for the text "Section 1" points at Section 1 of *this* RFC (i.e. https://tools.ietf.org/html/rfc8252#section-1); but it should point at Section 1 of *RFC7636* (i.e. https://tools.ietf.org/html/rfc7636#section-1). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8252 (draft-ietf-oauth-native-apps-12) -------------------------------------- Title : OAuth 2.0 for Native Apps Publication Date : October 2017 Author(s) : W. Denniss, J. Bradley Category : BEST CURRENT PRACTICE Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Oct 6 09:16:30 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBE134A15 for ; Fri, 6 Oct 2017 09:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZR8CcPWek7I for ; Fri, 6 Oct 2017 09:16:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3FA134A0F for ; Fri, 6 Oct 2017 09:16:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A77B4B810D1; Fri, 6 Oct 2017 09:16:19 -0700 (PDT) To: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: brian.vosburgh@oracle.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171006161619.A77B4B810D1@rfc-editor.org> Date: Fri, 6 Oct 2017 09:16:19 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5149) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 16:16:28 -0000 The following errata report has been submitted for RFC8252, "OAuth 2.0 for Native Apps". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5149 -------------------------------------- Type: Editorial Reported by: Brian Vosburgh Section: 8.1 Original Text ------------- Authorization servers SHOULD reject authorization requests from native apps that don't use PKCE by returning an error message, as defined in Section 4.4.1 of PKCE [RFC7636]. Corrected Text -------------- Notes ----- The embedded link for the text "Section 4.4.1" points at Section 4.4.1 of *this* RFC (i.e. https://tools.ietf.org/html/rfc8252#section-4.4.1); but it should point at Section 4.4.1 of *RFC7636* (i.e. https://tools.ietf.org/html/rfc7636#section-4.4.1). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8252 (draft-ietf-oauth-native-apps-12) -------------------------------------- Title : OAuth 2.0 for Native Apps Publication Date : October 2017 Author(s) : W. Denniss, J. Bradley Category : BEST CURRENT PRACTICE Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Oct 6 11:19:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B61134BEA for ; Fri, 6 Oct 2017 11:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yos4_ZCqItDL for ; Fri, 6 Oct 2017 11:19:43 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3313C134BEC for ; Fri, 6 Oct 2017 11:19:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7A9801CAC53; Fri, 6 Oct 2017 11:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6CImeyJIGmA; Fri, 6 Oct 2017 11:19:35 -0700 (PDT) Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 135D91CAC51; Fri, 6 Oct 2017 11:19:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6548A1B7-7ABD-45B8-8794-48D63C9F2B2D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20171006154144.69C98B80C69@rfc-editor.org> Date: Fri, 6 Oct 2017 11:19:42 -0700 Cc: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, Kathleen Moriarty , ekr@rtfm.com, Hannes Tschofenig , RFC System , rifaat.ietf@gmail.com, oauth@ietf.org Message-Id: <2AAE0680-58AB-45D9-9B10-A135A82CA1D0@amsl.com> References: <20171006154144.69C98B80C69@rfc-editor.org> To: brian.vosburgh@oracle.com X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5147) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:19:45 -0000 --Apple-Mail=_6548A1B7-7ABD-45B8-8794-48D63C9F2B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, Please note that this errata report has been removed. As stated at=20 http://www.rfc-editor.org/errata.php: "Errata are for the RFCs as available from rfc-editor.org. We have sent separate mail regarding this error to=20 webmaster@tools.ietf.org. Thank you. RFC Editor/mf On Oct 6, 2017, at 8:41 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5147 >=20 > -------------------------------------- > Type: Editorial > Reported by: Brian Vosburgh >=20 > Section: 6 >=20 > Original Text > ------------- > Native apps needing user authorization create an authorization > request URI with the authorization code grant type per Section 4.1 = of > OAuth 2.0 [RFC6749], using a redirect URI capable of being received > by the native app. >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > The embedded link for the text "Section 4.1" points at Section 4.1 of = *this* RFC (i.e. https://tools.ietf.org/html/rfc8252#section-4.1); but, = given the context of the surrounding text, it should point at Section = 4.1 of *RFC6749* (i.e. https://tools.ietf.org/html/rfc6749#section-4.1). >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8252 (draft-ietf-oauth-native-apps-12) > -------------------------------------- > Title : OAuth 2.0 for Native Apps > Publication Date : October 2017 > Author(s) : W. Denniss, J. Bradley > Category : BEST CURRENT PRACTICE > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 --Apple-Mail=_6548A1B7-7ABD-45B8-8794-48D63C9F2B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

Please note that this errata report has been removed.  As = stated at 
http://www.rfc-editor.org/errata.php:

"Errata are for the RFCs as available = from rfc-editor.org.

We = have sent separate mail regarding this error to 
webmaster@tools.ietf.org.

Thank = you.

RFC = Editor/mf

On Oct 6, 2017, at 8:41 AM, RFC Errata = System <rfc-editor@rfc-editor.org>= ; wrote:

The following errata report has been submitted for = RFC8252,
"OAuth 2.0 for Native = Apps".

--------------------------------------
You may review = the report below and at:
http://www.rfc-editor.or= g/errata/eid5147

--------------------------------------
Type= : Editorial
Reported by: Brian Vosburgh = <brian.vosburgh@oracle.com>

Section: 6

Original = Text
-------------
Native apps needing user authorization create = an authorization
  request URI with the authorization code = grant type per Section 4.1 of
  OAuth 2.0 [RFC6749], using = a redirect URI capable of being received
  by the native = app.

Corrected = Text
--------------


Notes
-----
The embedded link = for the text "Section 4.1" points at Section 4.1 of *this* RFC (i.e. = https://tools.ietf.org/html/rfc8252#section-4.1); but, given the context = of the surrounding text, it should point at Section 4.1 of *RFC6749* = (i.e. = https://tools.ietf.org/html/rfc6749#section-4.1).

Instructions:
= -------------
This erratum is currently posted as "Reported". If = necessary, please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the verifying party =  
can log in to change the status and edit the report, if = necessary.

--------------------------------------
RFC8252 = (draft-ietf-oauth-native-apps-12)
-------------------------------------= -
Title =             &n= bsp; : OAuth 2.0 for Native Apps
Publication Date =    : October 2017
Author(s) =           : W. = Denniss, J. Bradley
Category =            : BEST = CURRENT PRACTICE
Source =             &n= bsp;: Web Authorization Protocol
Area =             &n= bsp;  : Security
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG


= --Apple-Mail=_6548A1B7-7ABD-45B8-8794-48D63C9F2B2D-- From nobody Fri Oct 6 11:20:03 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57086134BF4 for ; Fri, 6 Oct 2017 11:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFwa6cNABVkm for ; Fri, 6 Oct 2017 11:19:46 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA8F134BE6 for ; Fri, 6 Oct 2017 11:19:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7CCE21CAC54; Fri, 6 Oct 2017 11:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_IPAVlXPu2g; Fri, 6 Oct 2017 11:19:36 -0700 (PDT) Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 208D91CAC51; Fri, 6 Oct 2017 11:19:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_67C0E7C1-44EC-4BA4-9A6A-710F14259224" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20171006160931.11F3AB81058@rfc-editor.org> Date: Fri, 6 Oct 2017 11:19:43 -0700 Cc: rfc8252@wdenniss.com, RFC System , rfc8252@ve7jtb.com, Kathleen Moriarty , ekr@rtfm.com, Hannes Tschofenig , rifaat.ietf@gmail.com, oauth@ietf.org Message-Id: References: <20171006160931.11F3AB81058@rfc-editor.org> To: brian.vosburgh@oracle.com X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5148) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:19:48 -0000 --Apple-Mail=_67C0E7C1-44EC-4BA4-9A6A-710F14259224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, Please note that this errata report has been removed. As stated at=20 http://www.rfc-editor.org/errata.php: "Errata are for the RFCs as available from rfc-editor.org. We have sent separate mail regarding this error to=20 webmaster@tools.ietf.org. Thank you. RFC Editor/mf On Oct 6, 2017, at 9:09 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5148 >=20 > -------------------------------------- > Type: Editorial > Reported by: Brian Vosburgh >=20 > Section: 8.1 >=20 > Original Text > ------------- > Section 1 of PKCE [RFC7636] details how this limitation can be > used to execute a code interception attack. >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > The embedded link for the text "Section 1" points at Section 1 of = *this* RFC (i.e. https://tools.ietf.org/html/rfc8252#section-1); but it = should point at Section 1 of *RFC7636* (i.e. = https://tools.ietf.org/html/rfc7636#section-1). >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8252 (draft-ietf-oauth-native-apps-12) > -------------------------------------- > Title : OAuth 2.0 for Native Apps > Publication Date : October 2017 > Author(s) : W. Denniss, J. Bradley > Category : BEST CURRENT PRACTICE > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 --Apple-Mail=_67C0E7C1-44EC-4BA4-9A6A-710F14259224 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

Please note that this errata report has been removed.  As = stated at 
http://www.rfc-editor.org/errata.php:

"Errata are for the RFCs as available = from rfc-editor.org.

We = have sent separate mail regarding this error to 
webmaster@tools.ietf.org.

Thank = you.

RFC = Editor/mf

On Oct 6, 2017, at 9:09 AM, = RFC Errata System <rfc-editor@rfc-editor.org>= ; wrote:

The following errata report has been submitted for = RFC8252,
"OAuth 2.0 for Native = Apps".

--------------------------------------
You may review = the report below and at:
http://www.rfc-editor.or= g/errata/eid5148

--------------------------------------
Type= : Editorial
Reported by: Brian Vosburgh = <brian.vosburgh@oracle.com>

Section: 8.1

Original = Text
-------------
Section 1 of PKCE [RFC7636] details how this = limitation can be
  used to execute a code interception = attack.

Corrected = Text
--------------


Notes
-----
The embedded link = for the text "Section 1" points at Section 1 of *this* RFC (i.e. = https://tools.ietf.org/html/rfc8252#section-1); but it should point at = Section 1 of *RFC7636* (i.e. = https://tools.ietf.org/html/rfc7636#section-1).

Instructions:
--= -----------
This erratum is currently posted as "Reported". If = necessary, please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the verifying party =  
can log in to change the status and edit the report, if = necessary.

--------------------------------------
RFC8252 = (draft-ietf-oauth-native-apps-12)
-------------------------------------= -
Title =             &n= bsp; : OAuth 2.0 for Native Apps
Publication Date =    : October 2017
Author(s) =           : W. = Denniss, J. Bradley
Category =            : BEST = CURRENT PRACTICE
Source =             &n= bsp;: Web Authorization Protocol
Area =             &n= bsp;  : Security
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG


= --Apple-Mail=_67C0E7C1-44EC-4BA4-9A6A-710F14259224-- From nobody Fri Oct 6 11:20:09 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CE4134BF5 for ; Fri, 6 Oct 2017 11:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h8kkjXCPMlB for ; Fri, 6 Oct 2017 11:19:47 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8F0134BEA for ; Fri, 6 Oct 2017 11:19:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 05C311CAC51; Fri, 6 Oct 2017 11:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd3Jwmg9b61j; Fri, 6 Oct 2017 11:19:38 -0700 (PDT) Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 9B8651CAC57; Fri, 6 Oct 2017 11:19:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FECEFF01-847D-454B-9690-779E9D048808" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20171006161619.A77B4B810D1@rfc-editor.org> Date: Fri, 6 Oct 2017 11:19:46 -0700 Cc: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, Kathleen Moriarty , ekr@rtfm.com, Hannes Tschofenig , RFC System , rifaat.ietf@gmail.com, oauth@ietf.org Message-Id: References: <20171006161619.A77B4B810D1@rfc-editor.org> To: brian.vosburgh@oracle.com X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5149) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:19:49 -0000 --Apple-Mail=_FECEFF01-847D-454B-9690-779E9D048808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, Please note that this errata report has been removed. As stated at=20 http://www.rfc-editor.org/errata.php: "Errata are for the RFCs as available from rfc-editor.org. We have sent separate mail regarding this error to=20 webmaster@tools.ietf.org. Thank you. RFC Editor/mf On Oct 6, 2017, at 9:16 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5149 >=20 > -------------------------------------- > Type: Editorial > Reported by: Brian Vosburgh >=20 > Section: 8.1 >=20 > Original Text > ------------- > Authorization servers SHOULD reject > authorization requests from native apps that don't use PKCE by > returning an error message, as defined in Section 4.4.1 of PKCE > [RFC7636]. >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > The embedded link for the text "Section 4.4.1" points at Section 4.4.1 = of *this* RFC (i.e. https://tools.ietf.org/html/rfc8252#section-4.4.1); = but it should point at Section 4.4.1 of *RFC7636* (i.e. = https://tools.ietf.org/html/rfc7636#section-4.4.1). >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8252 (draft-ietf-oauth-native-apps-12) > -------------------------------------- > Title : OAuth 2.0 for Native Apps > Publication Date : October 2017 > Author(s) : W. Denniss, J. Bradley > Category : BEST CURRENT PRACTICE > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 --Apple-Mail=_FECEFF01-847D-454B-9690-779E9D048808 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

Please note that this errata report has = been removed.  As stated at 
http://www.rfc-editor.org/errata.php:

"Errata are for the RFCs as available = from rfc-editor.org.

We = have sent separate mail regarding this error to 
webmaster@tools.ietf.org.

Thank = you.

RFC = Editor/mf




On Oct 6, 2017, at 9:16 AM, RFC Errata System <rfc-editor@rfc-editor.org>= ; wrote:

The following errata report has been submitted for = RFC8252,
"OAuth 2.0 for Native = Apps".

--------------------------------------
You may review = the report below and at:
http://www.rfc-editor.or= g/errata/eid5149

--------------------------------------
Type= : Editorial
Reported by: Brian Vosburgh = <brian.vosburgh@oracle.com>

Section: 8.1

Original = Text
-------------
Authorization servers SHOULD reject
=   authorization requests from native apps that don't use PKCE = by
  returning an error message, as defined in Section = 4.4.1 of PKCE
  [RFC7636].

Corrected = Text
--------------


Notes
-----
The embedded link = for the text "Section 4.4.1" points at Section 4.4.1 of *this* RFC (i.e. = https://tools.ietf.org/html/rfc8252#section-4.4.1); but it should point = at Section 4.4.1 of *RFC7636* (i.e. = https://tools.ietf.org/html/rfc7636#section-4.4.1).

Instructions:-------------
This erratum is currently posted as "Reported". If = necessary, please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the verifying party =  
can log in to change the status and edit the report, if = necessary.

--------------------------------------
RFC8252 = (draft-ietf-oauth-native-apps-12)
-------------------------------------= -
Title =             &n= bsp; : OAuth 2.0 for Native Apps
Publication Date =    : October 2017
Author(s) =           : W. = Denniss, J. Bradley
Category =            : BEST = CURRENT PRACTICE
Source =             &n= bsp;: Web Authorization Protocol
Area =             &n= bsp;  : Security
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG


= --Apple-Mail=_FECEFF01-847D-454B-9690-779E9D048808-- From nobody Tue Oct 10 04:23:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FA21344EE for ; Tue, 10 Oct 2017 04:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTEBT0aBA87k for ; Tue, 10 Oct 2017 04:23:39 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD66134CB4 for ; Tue, 10 Oct 2017 04:23:39 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id c77so42505100oig.0 for ; Tue, 10 Oct 2017 04:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=a94JZsTRQZMiF54I4p1OV4R8brxDLmG+i2YDMt2tPdE=; b=WnXZP6HAJ773qKv7Fg7GPQLbtjGU2Yetkv0mmPueSM7SuoWkZaY0R/ZsShJutIhCkg +aexgoeip0o3WANhxay1G4jK//IBcCUQd3rvIJ1QDcC+vXvJPKzPkk4asqYj/xW63bRv Hskjvju5oLWSWGDr3i8882gWic/Z55Wr0kK2bElvWs9TVpjFUI3qJw1qtb3rFWMcjvQc r2xS/QEowKynV/IzFh61tO/6wlAgi4b5MpvGHmnRRYqZNnhvIg/X2q1UMmufoBnQSbso +Fz32OZFPG6XjQfIJ8xY4Zx0BTbshltRqw+AXsfbuROIYF0mPEdSPwRq8+H/oRF+OCAR nfUg== 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=a94JZsTRQZMiF54I4p1OV4R8brxDLmG+i2YDMt2tPdE=; b=tk4FlolcjABe/R21AqY08ekwoGslY3i8bP2mDnrLn1ypnxJlM45qj9ncOwvWeAO4ou e4FwXJNBQz1dnP+mLsytISOFcfL/umKFZhLPHBHV2wcaHgkK1PD+v0lpdVDHmn2x3vgZ HhGqsohRhSZehmOiEosU/VjXsBHYzzqPJeblR6WpzpM0PXiHbm0/PQsErdXCNMS2E6Pf OYUaBaCwL17sVM5Bgp3v4g0dHkA6+k8eLbI385oq/fK1laHzTvjBsEy4o6bWHhB6tKgt /Jb7yZvLaoaNX7ro3BBDdQ02+1MwpAJserrn3C/5679GAkADrMWuhUrO4jNMp7BqkBrD q+Ow== X-Gm-Message-State: AMCzsaU3Z5T5LX9+AQIoHvLQQ8KbEK9qTCsafWBKjljIlHYj6xt0CAXI YkncZ5TnHlUJRbyLq9EYVNVzDuk7OjWcnnv3tzLAYzE6 X-Google-Smtp-Source: AOwi7QBUfwJRzkzpWAwRfBigqwyoF75cleh4n+4iELCWXAFEPfnsE4p/ICxYj+zM8M7elIIKkBLB3ciTjCRKlyNtQv0= X-Received: by 10.202.75.2 with SMTP id y2mr6398081oia.56.1507634618504; Tue, 10 Oct 2017 04:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.19.211 with HTTP; Tue, 10 Oct 2017 04:22:58 -0700 (PDT) From: Jim Willeke Date: Tue, 10 Oct 2017 07:22:58 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a113e3db8e32ef0055b2f894d" Archived-At: Subject: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 11:23:41 -0000 --001a113e3db8e32ef0055b2f894d Content-Type: text/plain; charset="UTF-8" Wondering if you could help with Questions on urn:ietf:wg:oauth:2.0:oob as it appears to be an almost common usage, but no IETF documentation or registration that we can find on the defined usage. This has come up on several occasions. - https://stackoverflow.com/q/46643795/88122 - http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html - https://github.com/doorkeeper-gem/doorkeeper/issues/514 - https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html Should it be registered or defined? (or am I missing something?) With best regards, -- -jim Jim Willeke --001a113e3db8e32ef0055b2f894d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wondering if you could help with Questions on urn:ietf:wg:= oauth:2.0:oob as it appears to be an almost common usage, but no IETF docum= entation or registration that we can find on the defined usage.

This has come up on several occasions.
=

Should it be registered or defined?=C2=A0
(or= am I missing something?)

With best regards,<= /div>

---jim
Jim Willeke
--001a113e3db8e32ef0055b2f894d-- From nobody Tue Oct 10 07:04:51 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9FD13243A for ; Tue, 10 Oct 2017 07:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k1_xtCkJdh1 for ; Tue, 10 Oct 2017 07:04:48 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6A6132F2C for ; Tue, 10 Oct 2017 07:04:48 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id u130so45351203oib.11 for ; Tue, 10 Oct 2017 07:04:48 -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=kXxKnXyz1GD+Hhjnt/SA9BuNWDFgrDhcBkTJ6hThNfw=; b=f1oQ57CmNfwWj6ABrqmF5OJIqf/+8ec41RnQJyi2jgt1SrBO2pevVzuj+pzpYX0ZQQ Fw2LhE0aKgwZCdAeq3n35vawwkXL/YOuVRr/ymWtoxn9ae79o5jEjq/JZq+6yapyzYAP nJOi6ApygODy1QoAkqxYmY2r8Zt95wZR4Xi7FQhYvrezM8/rqRYx6EOffp6cHSgUs269 e5uPHiGifVATonYtRQUHDsPCl77VBpHi1R62UwsuJUheANWI0SrW0SAuY0kNh8/BVdPK 6Y1/OmfpY0LWxYoEUU8Ac8TUOKHDtachJIUU3bfn6PqubSYLbQEpJ8UPoNNVvHdY0pA1 cQ7g== 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=kXxKnXyz1GD+Hhjnt/SA9BuNWDFgrDhcBkTJ6hThNfw=; b=q0Y8ci1qrga/zvstLFM1jACUXLmUnqezn8SBa4eFpCKjHmdPHSk4xvLkzsgezJ1XGG PGSTd1BlV+MU7zhnogyMv6QbwBB6fTSs9FEyIpErMA38/7Sf4D8GLVsqUPB15DV9uldl TG3SAvdSaEE32qgdeJcfLMS1jcKl2KwQkEizlqb6P5bfm361uqN5lPxJWLqZ5W+fwoQW i54G93sL+Rv1hVChlI4OfjoYLrP8Jztl9xL8VD3sAOh80y+akKJPazSpXB/WuqQ16w4b mkfV99DKqZ8WF4HK1uSZkfwltJ7TGKsV3fj1EFu3OUF6AtZJG2jYQbHnyrqkIacE0b9o saXg== X-Gm-Message-State: AMCzsaUcX51H0BYwu4t+UCMRTAv6lGaeZt5GwNgSggKe/AJ0IZqcXo2w JERcicdITkiSBB/YK+m1FND+U6f00MytFnLr+sniYA== X-Google-Smtp-Source: AOwi7QBQRcXYxSmVOwDJCgjmFUWGhe4g9HBzPzBB3kIiRcWA4ko3xl2+qGT1uaz4h2pUVKzH8Xnx2bsAR+nByRaamOM= X-Received: by 10.202.66.70 with SMTP id p67mr7350480oia.428.1507644287403; Tue, 10 Oct 2017 07:04:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Broyer Date: Tue, 10 Oct 2017 14:04:37 +0000 Message-ID: To: Jim Willeke , oauth Content-Type: multipart/alternative; boundary="001a113dd27e32d7d9055b31cabe" Archived-At: Subject: Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:04:51 -0000 --001a113dd27e32d7d9055b31cabe Content-Type: text/plain; charset="UTF-8" To my knowledge, it's been replaced with RFC 8252. See https://developers.google.com/identity/protocols/OAuth2InstalledApp (notice the deprecation notices in options 3 and 4 in the "create authorization credentials" section; you can find the "oob" URN later in the doc, associated with the same options) On Tue, Oct 10, 2017 at 1:23 PM Jim Willeke wrote: > Wondering if you could help with Questions on urn:ietf:wg:oauth:2.0:oob as > it appears to be an almost common usage, but no IETF documentation or > registration that we can find on the defined usage. > > This has come up on several occasions. > > - https://stackoverflow.com/q/46643795/88122 > - http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html > - https://github.com/doorkeeper-gem/doorkeeper/issues/514 > - https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html > > > Should it be registered or defined? > (or am I missing something?) > > With best regards, > > -- > -jim > Jim Willeke > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113dd27e32d7d9055b31cabe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To my knowledge, it's been replaced with RFC 8252.
See https://developers.google.com/identity/protocols/OAuth2I= nstalledApp=C2=A0(notice the deprecation notices in options 3 and 4 in = the "create authorization credentials" section; you can find the = "oob" URN later in the doc, associated with the same options)

On Tue, Oct 1= 0, 2017 at 1:23 PM Jim Willeke <jim@w= illeke.com> wrote:
Wondering if you could help with Questions on urn:ietf:wg:oauth:2.= 0:oob as it appears to be an almost common usage, but no IETF documentation= or registration that we can find on the defined usage.

= This has come up on several occasions.

Should it be regis= tered or defined?=C2=A0
(or am I missing something?)
With best regards,

--
-jim
Jim Willeke
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113dd27e32d7d9055b31cabe-- From nobody Tue Oct 10 08:04:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1113334E for ; Tue, 10 Oct 2017 08:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bftee78mAwfP for ; Tue, 10 Oct 2017 08:03:57 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DC6134E27 for ; Tue, 10 Oct 2017 08:02:24 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id x54so52050283qth.12 for ; Tue, 10 Oct 2017 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7kim6GkZH6SEo+tihiE2JnYrrqKUFSe1Z5HHdB5LGTQ=; b=tV3E7RGPYlCUrhGgmde9cvezTo8JT7lS4jFZkY4Ls+EdkzzRRSD1qDOsAZfAO5ZYXN xES2H2DbbWntoHVgruuXZXVTsU0eDD+E3mNZiIvFV2r+ZaUfqHGHqeENkTBrcblbGep7 xUAZkMRf6k5EYDZ3oa4D+cTBZuVE1EKYWyHZsZJ4KE/r1xRpnx1WmQwag1IJmQDXXuqX PVlOO9Q1ECTvszLYe1b+NkIyVuy4Qssq/kDn00lA3zIcettOLSbYEqJ5pekyGkpESeTJ 5ZJYjs3EP0ru6xP460vur0hQLMqikCA+aA2z4d8afr5lY9f6bCLd5k1ZjAmaw5rCuX1t ve/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7kim6GkZH6SEo+tihiE2JnYrrqKUFSe1Z5HHdB5LGTQ=; b=EOUz5hCqhePxJgHTcOgxFKHsd4JDImf+4w9RMdyfw+RMebJcT/ZGIE0r0TOVCIeTpO 1iwVcssibsHXMm4cA4CR1A48iMog7a+u7eAqrvP4c5lKJaGhp8Nk45lFRt3Ew0FR2lhP F9mmxnfDAqEpMsnc0lhCBtJAcpbcFh/cCHVdI09tsyhmFUiQwo5z0kUL5ZXFtDqA7X7m eeO/LR8AWbirx7WKBlCjV7jvUAk+K8NqWftJCe2rxqlbAWChdOeyx6gwMaw8FmAyxNqX fFzxwNIoeMtJZcY4Xd54caKs1a0j93KJjtiYofXFani2tsTNor/QKxTEZqZqBsMYxzsp yuHg== X-Gm-Message-State: AMCzsaWNrmVQ42zHZkfGNUqlK79U/uRWM2xqudng5XcgZVUeVqwHJiNr 4Dd+ZgCh3EeZWf98KN5tNZ1fnLqQPpQ= X-Google-Smtp-Source: AOwi7QAPOG8Y5z1A4X4XGn4mfGrci0VB5bRggTpKCoxuviZcs+JXfJFnyPpsvqN2IXU+p4lNwwkuXw== X-Received: by 10.200.23.153 with SMTP id o25mr20614656qtj.119.1507647743441; Tue, 10 Oct 2017 08:02:23 -0700 (PDT) Received: from johns-mbp.lan ([191.115.185.170]) by smtp.gmail.com with ESMTPSA id f4sm6609779qtg.35.2017.10.10.08.02.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Oct 2017 08:02:22 -0700 (PDT) From: John Bradley Message-Id: <5C19128A-51FF-4F3B-AC1A-E04E0ABEC3D5@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Tue, 10 Oct 2017 12:02:18 -0300 In-Reply-To: Cc: oauth To: Jim Willeke References: X-Mailer: Apple Mail (2.3445.1.7) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045d62ba3b65d5055b3298cc" Archived-At: Subject: Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:04:08 -0000 --f403045d62ba3b65d5055b3298cc Content-Type: multipart/alternative; boundary="Apple-Mail=_A79C719D-B359-418E-B310-20438BC2F524" --Apple-Mail=_A79C719D-B359-418E-B310-20438BC2F524 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 urn:ietf:wg:oauth:2.0:oob is a google thing that is not part of the = OAuth 2 specification. I think it was mostly a windows thing. It is not a real redirect URI it is used as a flag to the authorization = server to have the result returned =E2=80=9COut Of Band=E2=80=9D and the = user cut and paste the token. On windows applications could snoop the title bars of other apps so = programatically retrieve the token value from the title bar. I don=E2=80=99t really want to put effort into expanding all the reasons = this is not secure. I don=E2=80=99t honestly know what would happen if you sent that = redirect URI to a non Google AS probably nothing good. =20 It is not part of the OAuth specification and not something people = should use without having a good reason and understanding the security = implications. William and I documented several ways to impliment native applications = on OSX and Windows in RFC8252. On windows you are really best off using a UWP app and the native token = broker with the code flow. Documentation = https://developers.google.com/api-client-library/python/auth/installed-app= This value signals to the Google Authorization Server that the = authorization code should be returned in the title bar of the browser, = with the page text prompting the user to copy the code and paste it in = the application. This is useful when the client (such as a Windows = application) cannot listen on an HTTP port without significant client = configuration. When you use this value, your application can then detect that the page = has loaded, and can read the title of the HTML page to obtain the = authorization code. It is then up to your application to close the = browser window if you want to ensure that the user never sees the page = that contains the authorization code. The mechanism for doing this = varies from platform to platform. If your platform doesn't allow you to detect that the page has loaded or = read the title of the page, you can have the user paste the code back to = your application, as prompted by the text in the confirmation page that = the OAuth 2.0 server generates. John B. > On Oct 10, 2017, at 8:22 AM, Jim Willeke wrote: >=20 > Wondering if you could help with Questions on = urn:ietf:wg:oauth:2.0:oob as it appears to be an almost common usage, = but no IETF documentation or registration that we can find on the = defined usage. >=20 > This has come up on several occasions. > https://stackoverflow.com/q/46643795/88122 = > http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html = > https://github.com/doorkeeper-gem/doorkeeper/issues/514 = > https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html = >=20 > Should it be registered or defined?=20 > (or am I missing something?) >=20 > With best regards, >=20 > -- > -jim > Jim Willeke > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A79C719D-B359-418E-B310-20438BC2F524 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8  urn:ietf:wg:oauth:2.0:oob is a google thing that is not = part of the OAuth 2 specification.

I think it was mostly a windows = thing.

It is = not a real redirect URI it is used as a flag to the authorization server = to have the result returned =E2=80=9COut Of Band=E2=80=9D and the user = cut and paste the token.

On windows applications could snoop the title bars of other = apps so programatically retrieve the token value from the title = bar.

I don=E2=80= =99t really want to put effort into expanding all the reasons this is = not secure.

I = don=E2=80=99t honestly know what would happen if you sent that redirect = URI to a non Google AS probably nothing good.   
It is not part of the OAuth specification and not something = people should use without having a good reason and understanding the = security implications.

William and I documented several ways to impliment native = applications on OSX and Windows in RFC8252.

On windows you are really best off = using a UWP app and the native token broker with the code flow.

Documentation
https://developers.google.com/api-client-library/python/auth/in= stalled-app

This value signals to the Google Authorization Server = that the authorization code should be returned in the title bar of the = browser, with the page text prompting the user to copy the code and = paste it in the application. This is useful when the client (such as a = Windows application) cannot listen on an HTTP port without significant = client configuration.

When you use this value, your = application can then detect that the page has loaded, and can read the = title of the HTML page to obtain the authorization code. It is then up = to your application to close the browser window if you want to ensure = that the user never sees the page that contains the authorization code. = The mechanism for doing this varies from platform to platform.

If your platform doesn't allow you to detect that the page = has loaded or read the title of the page, you can have the user paste = the code back to your application, as prompted by the text in the = confirmation page that the OAuth 2.0 server generates.


John B.
On Oct = 10, 2017, at 8:22 AM, Jim Willeke <jim@willeke.com> wrote:

Wondering if you could help with Questions on = urn:ietf:wg:oauth:2.0:oob as it appears to be an almost common usage, = but no IETF documentation or registration that we can find on the = defined usage.

This = has come up on several occasions.

Should it be registered or defined? 
(or am I missing something?)

With best = regards,

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

= --Apple-Mail=_A79C719D-B359-418E-B310-20438BC2F524-- --f403045d62ba3b65d5055b3298cc Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIGhXgdlbI3jMwVryLSHfp37MBMZ7 rEK4Hbe4PJaKn2dEMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MTAxMDE1MDIyNFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCXvKbC9hehlSLMvlPjbvhNXqhEZEkM9co5CjQPLASjRgvh TiI26wS1dUbU9w2TMYss8/rnKPwE3F5Hl0Jk5qGxLC/370d4O2XxiZEuLkjsNeGNfR66guuqJcag HTjt9q5VUTtB9y9pXmVjEW2Yc1edrDEk29oUMz3/np/WyjvwXUysVU36cnj4WfyvW/9zn1UB0nPE 183uWx7sxIhux+54VxMPSVjB9lF9TMyvlM3fyV99PO04EZI15euwW+qvJUAwrKaWh2YlliVZ3+r5 bDwGUR1RadIo2b8xBxp0l6FRS6HVcqNeOoknsrqa4p6M0UdC/JvCBHcrkYxa07PeF3kg --f403045d62ba3b65d5055b3298cc-- From nobody Tue Oct 10 11:51:31 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FB71346BF for ; Tue, 10 Oct 2017 11:51:28 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHZetgbMv9Uc for ; Tue, 10 Oct 2017 11:51:26 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017A71321DC for ; Tue, 10 Oct 2017 11:50:52 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id f66so2604977oib.2 for ; Tue, 10 Oct 2017 11:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=r4skaRC3oaaF5ggBHcOXjyWsXldGAT78RLDVTds6KrU=; b=taf6XYCkNKt1v9mCmRfIwJc8GzZeq+JxGCX7orn9Gxk1XXaYGB4btcn1hotJEHS0zW gDajAVbYPN08aOxeqfKRtcH2yPGlzD/iERcSewiDES38XVhN4sjFc1SZ8/RCY4pLzwVS AZT/jFAeb3InmZBK5CTaVNAYTeIwkLxBf5UIA76AW3eGsngnxfvbaImS3UfKW6LNhz3W y2+EhSrtut1igE07hTU4wQ0e0hQauhEvnhYQgRztk8dl40OufSE3zoU5TAKMAWYBcFAx RjCP4Z6VHXpMMwDiIWtj/U/OMf0m6SpVu72DfjSnict6MOwYKIk/WJVNa8p5nF8XsOGG xRIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=r4skaRC3oaaF5ggBHcOXjyWsXldGAT78RLDVTds6KrU=; b=jZ363ofmXvCwuPbQ1mEkI4FEHmEe7TQ38qUMYXX3hg/9gtNH9SF7KwwD/52Y22l2z7 auXcIlmcq+kJMysgGZxghuj8PQbtfxyVUcAqfSoTKN4qaNVl+Z4KrLFZv+bv7S4DXXDW Q28xkl90bYpRJbtKMfCoVagTMsjioo7kN+sUwN51lkz6KSVqWA16HEvMHC2ISsukkj3T eiHEj9lPYkdJdcBWUxVZIwmeesdRAke6/LQnHfFEPnMtGUmiNPNRLFBppQKUm8UcAtUT N2NLPyBNdQneirzec4EUAQYL7DDWGnUAqphBW27ERRy+m/aW/yWLWgKD+ZtEx9B0XfOn kbXA== X-Gm-Message-State: AMCzsaWSZ0TrIvHNKG0J6ykJxTI6XV8gQTMovzSb1TmjvCZg/5f7FoLE ZTNfaBO+iQT++oDZwao6fLVsV0fb8EhFRI91yFZgVBFe X-Google-Smtp-Source: AOwi7QAgzzoX6tc1aDNwyM/JuW4WJx6RE0IzO2xNtFnlNS8gNNImsf5Rnm24jcxQwHBSrs5FBVSbYlKfRHoM2p3BD9Q= X-Received: by 10.202.173.203 with SMTP id w194mr6504041oie.305.1507661451971; Tue, 10 Oct 2017 11:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.19.211 with HTTP; Tue, 10 Oct 2017 11:50:11 -0700 (PDT) In-Reply-To: <5C19128A-51FF-4F3B-AC1A-E04E0ABEC3D5@ve7jtb.com> References: <5C19128A-51FF-4F3B-AC1A-E04E0ABEC3D5@ve7jtb.com> From: Jim Willeke Date: Tue, 10 Oct 2017 14:50:11 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a113cf59c496d74055b35c903" Archived-At: Subject: Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 18:51:29 -0000 --001a113cf59c496d74055b35c903 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for all the feedback. -- -jim Jim Willeke On Tue, Oct 10, 2017 at 11:02 AM, John Bradley wrote: > urn:ietf:wg:oauth:2.0:oob is a google thing that is not part of the OAut= h > 2 specification. > > I think it was mostly a windows thing. > > It is not a real redirect URI it is used as a flag to the authorization > server to have the result returned =E2=80=9COut Of Band=E2=80=9D and the = user cut and paste > the token. > > On windows applications could snoop the title bars of other apps so > programatically retrieve the token value from the title bar. > > I don=E2=80=99t really want to put effort into expanding all the reasons = this is > not secure. > > I don=E2=80=99t honestly know what would happen if you sent that redirect= URI to a > non Google AS probably nothing good. > It is not part of the OAuth specification and not something people should > use without having a good reason and understanding the security > implications. > > William and I documented several ways to impliment native applications on > OSX and Windows in RFC8252. > > On windows you are really best off using a UWP app and the native token > broker with the code flow. > > Documentation > https://developers.google.com/api-client-library/python/auth/installed-ap= p > > This value signals to the Google Authorization Server that the > authorization code should be returned in the title bar of the browser, wi= th > the page text prompting the user to copy the code and paste it in the > application. This is useful when the client (such as a Windows applicatio= n) > cannot listen on an HTTP port without significant client configuration. > > When you use this value, your application can then detect that the page > has loaded, and can read the title of the HTML page to obtain the > authorization code. It is then up to your application to close the browse= r > window if you want to ensure that the user never sees the page that > contains the authorization code. The mechanism for doing this varies from > platform to platform. > > If your platform doesn't allow you to detect that the page has loaded or > read the title of the page, you can have the user paste the code back to > your application, as prompted by the text in the confirmation page that t= he > OAuth 2.0 server generates. > > John B. > > On Oct 10, 2017, at 8:22 AM, Jim Willeke wrote: > > Wondering if you could help with Questions on urn:ietf:wg:oauth:2.0:oob a= s > it appears to be an almost common usage, but no IETF documentation or > registration that we can find on the defined usage. > > This has come up on several occasions. > > - https://stackoverflow.com/q/46643795/88122 > - http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html > - https://github.com/doorkeeper-gem/doorkeeper/issues/514 > - https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html > > > Should it be registered or defined? > (or am I missing something?) > > With best regards, > > -- > -jim > Jim Willeke > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a113cf59c496d74055b35c903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for all the feedback.

--<= /span>
-jim
Jim W= illeke

On Tue, Oct 10, 2017 at 11:02 AM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
=C2=A0= urn:ietf:wg:oauth:2.0:oob is a google thing that is not part of the OAuth 2= specification.

I think it was mostly a windows thing.

It is not a real redirect URI it is used as a flag = to the authorization server to have the result returned =E2=80=9COut Of Ban= d=E2=80=9D and the user cut and paste the token.

O= n windows applications could snoop the title bars of other apps so programa= tically retrieve the token value from the title bar.

I don=E2=80=99t really want to put effort into expanding all the reasons= this is not secure.

I don=E2=80=99t honestly know= what would happen if you sent that redirect URI to a non Google AS probabl= y nothing good. =C2=A0=C2=A0
It is not part of the OAuth specific= ation and not something people should use without having a good reason and = understanding the security implications.

William a= nd I documented several ways to impliment native applications on OSX and Wi= ndows in RFC8252.

On windows you are really best o= ff using a UWP app and the native token broker with the code flow.
=
Documentation

This value signals to the Google Authorization Server that the author= ization code should be returned in the title bar of the browser, with the p= age text prompting the user to copy the code and paste it in the applicatio= n. This is useful when the client (such as a Windows application) cannot li= sten on an HTTP port without significant client configuration.

When you use this value, your app= lication can then detect that the page has loaded, and can read the title o= f the HTML page to obtain the authorization code. It is then up to your app= lication to close the browser window if you want to ensure that the user ne= ver sees the page that contains the authorization code. The mechanism for d= oing this varies from platform to platform.

If your platform doesn't allow you to detect that= the page has loaded or read the title of the page, you can have the user p= aste the code back to your application, as prompted by the text in the conf= irmation page that the OAuth 2.0 server generates.


<= /div>
John B.
= On Oct 10, 2017, at 8:22 AM, Jim Willeke <jim@willeke.com> wrote:

Wondering if you could help with Questions on ur= n:ietf:wg:oauth:2.0:oob as it appears to be an almost common usage, but no = IETF documentation or registration that we can find on the defined usage.
This has come up on several occasions.

Should it be registered or defined?=C2=A0
(or am I missing something?)

With best= regards,

--
-jim
Jim Willeke
_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


--001a113cf59c496d74055b35c903-- From nobody Thu Oct 12 09:57:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2913453E for ; Thu, 12 Oct 2017 09:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epQ087UwtHzM for ; Thu, 12 Oct 2017 09:57:43 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB90124F57 for ; Thu, 12 Oct 2017 09:57:43 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m16so6182712iod.1 for ; Thu, 12 Oct 2017 09:57: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=4OGtooGHhk2pYjUKFS5PBlVT+iRTyB0z41BoulB8/cA=; b=vMkkwGGnvvSmirE9YHiBcqfcsXZ2pjcRDKOYvXsEnHG6OERIpqcwDcL0JWRoz+Vvpy RHcmnX2gJONPWPoIxd4TxXw31FbAfTr2wEECTXjW8bLdw0zH805vyBKDgkt6QZLcrUBP UsuuG8IOX0MPB5vj3NmpM8ecGV+HuxWpqsRG4PnjGF7TyGCFhFhmerDkKYfC72CsAHOz 2hpt3pbmshUwWTADlDswTC+FEYMmuqbja6Yfap2X6+PiOB3y6lt4Qm5b8OFp/WcixjNj hOoRfoJXb4YJ0CaAuyDPX5q9fwk0SMYYJIa755zRy41uVeNSjj0dyTLII2ln17rpzCIa NukA== 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=4OGtooGHhk2pYjUKFS5PBlVT+iRTyB0z41BoulB8/cA=; b=oxs2MXd1s+31SE+9xo+1ZGTCrsv/u8a+eAtJaYLdxnc2cL+5iBSqGLVPKVh0e1rysr uNefjJTbavrtMGYEepK4EhMTFVJ9hOww+2O6B5t3rmNxXk7WlAFgEEd9/KM9CimtIoG5 k8tHqiS4Tu8AOrqHXHw1NGho92BD1Xc5pX7poyIym2SddHNUPmr0zbPf/+4S/REwTivn B62VaBS41sJ2xwmgrAmISOBupLjykzQkTPaIa0BLWaMh+dmLj97lUnuyQynT7Fi0x0VG Lb4s220n5GSloUKOZprrk38C/lt13LtIAyr9+Qwyu0aVkEZ05UiDN0sf4sgOQUQHx4xT KF1g== X-Gm-Message-State: AMCzsaVpVV1S70kFR9cUm7oeXqdqxnFJgRQRklO4b6GWoqV06aCSf3AN mGkGWYMOVAzMZag6RbhJeHpaXgBe+3+FCYGdRN00+g== X-Google-Smtp-Source: AOwi7QCycW5xV0mRUMjdkMkBiwU4h01lP3E5/JVdQuLHCidkmXttHQU6dgBMEMC+O0KhDxUsKRW+JX0ceiOggC3Vpxs= X-Received: by 10.107.21.131 with SMTP id 125mr4066506iov.295.1507827462363; Thu, 12 Oct 2017 09:57:42 -0700 (PDT) MIME-Version: 1.0 From: Nat Sakimura Date: Thu, 12 Oct 2017 16:57:30 +0000 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c05e7f846e14c055b5c70de" Archived-At: Subject: [OAUTH-WG] A few questions to draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 16:57:45 -0000 --94eb2c05e7f846e14c055b5c70de Content-Type: text/plain; charset="UTF-8" Thanks to the authors for coming up with this document. The scenario is very close to what I implemented back in 2011 or so, so I am naturally interested. Here are some questions I have with the draft. 1) Am I correct to assume that the draft targeting a device that is completely unable to accept user input? 2) I feel that it is appropriate to mention the shoulder hacking as well. In the Kiosk kind of use cases, the screen might be watched by the remote camera and the "session" might be hijacked by the remote attacker. (This is why I am asking 1) above. If the device has a capability to accept a number, the risk can be made much lower. ) 3) It probably is better to explicitly say that "device code MUST NOT be displayed" especially in the case of a public client. 4) Does section 3.4 and 3.5 exclude the possibility of using something like web socket? 5) If my read is correct, the client is doing the polling etc. by itself and not spawning a system browser. In a Kiosk kind of use case, I can imagine a case that the original app spawning a browser -- i.e, doing PKCE. In this case, the authorization server creates user authentication and authorization page that displays the verification URI and the user code. The client does nothing but a regular PKCE. This kind of use case is out of scope for this document, is it correct? Cheers, Nat Sakimura -- Nat Sakimura Chairman of the Board, OpenID Foundation --94eb2c05e7f846e14c055b5c70de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to the authors for coming up with this document.=C2= =A0
The scenario is very close to what I implemented back in 2011 or so= , so I am naturally interested.=C2=A0

Here are som= e questions I have with the draft.=C2=A0

1) Am I c= orrect to assume that the draft targeting a device that is completely unabl= e to accept user input?=C2=A0
2) I feel that it is appropriate to= mention the shoulder hacking as well. In the Kiosk kind of use cases, the = screen might be watched by the remote camera and the "session" mi= ght be hijacked by the remote attacker. (This is why I am asking 1) above. = If the device has a capability to accept a number, the risk can be made muc= h lower. )=C2=A0
3) It probably is better to explicitly say that = "device code MUST NOT be displayed" especially in the case of a p= ublic client.=C2=A0
4) Does section 3.4 and 3.5 exclude the possi= bility of using something like web socket?=C2=A0
5) If my read is= correct, the client is doing the polling etc. by itself and not spawning a= system browser. In a Kiosk kind of use case, I can imagine a case that the= original app spawning a browser -- i.e, doing PKCE. In this case, the auth= orization server creates user authentication and authorization page that di= splays the verification URI and the user code. The client does nothing but = a regular PKCE. This kind of use case is out of scope for this document, is= it correct?=C2=A0

Cheers,=C2=A0

Nat Sakimura




--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c05e7f846e14c055b5c70de-- From nobody Thu Oct 12 10:11:16 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B552F134219 for ; Thu, 12 Oct 2017 10:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfeDveRq-gnS for ; Thu, 12 Oct 2017 10:11:12 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B1C133224 for ; Thu, 12 Oct 2017 10:11:12 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id q4so14908744qtq.8 for ; Thu, 12 Oct 2017 10:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HjZyDmWhwQ7vvAdTg9Ydhc3sZfsaHjnbZtGK8gPE2xk=; b=qhwDOkoQLlpqEN8deSvGxNhUyM8467sCtcGsw8KdutoDxLVIygxdpw4ZJV6OZaLjYR ntPfEc89fJAEw1BpefNUbzWTiw24jdVn1N0qkI+e3Z+iHxm053iVvtsPGseFO4uENF5B ENltXluAEu+UbDsdHzS+aaEKrC1TWvSb9rtXkmO6i9KdAKMmOZhdPszLZCyjyEeW+3o0 dHmesCS7tJ0c6GN7f3JjOBbplwzEbMRwKj978P27d2C9tpqnTvxbHroPZ6I6GkMg31iu e9Lkng1icv8HT0uqKdQVG5FheHizr3FR2Y+mO/7lgOU6tTiej7WQ6pVvDvF2HYK7yChU sRHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HjZyDmWhwQ7vvAdTg9Ydhc3sZfsaHjnbZtGK8gPE2xk=; b=U3n2T63vpUQ65uo9ASPkTDGOHxv+1xwLCz/dWTpKmG1rZHh2wtKwuVti7NFnOilFVs Q86puUoZAuM8NoAn8i4tTdi8DgQZutulRhoaoMEsix+zaluROoVQYhQMDLfllBpUTnga TK9yNYR4xnX0ZsH0cZBnenkEoHYAJt+ovnWuPkTZfFzFSW+skN4NyG77XN5thk+FGRCF zuwfo6z2Scc3OBF3ebhktOFvPWGS40oGhZm8UVOPtq+1BLtWy9TPYedjdyRuVuBjrE+w 92D9uTEHLpXQOCS16Vqt3Z0g16UCJVXgOIYVfvhDM5XKKL9rOQEoTMQlYKLc8xfUzEJC 3RdQ== X-Gm-Message-State: AMCzsaU/akEEE/pvTozkkNSJJ8m9lkMy/HJxXTtNQO/Wk/KflgxieYo5 72wKyC2Wlw/ibvSnqMLqxbO/ViS1a/MI7Cr2WjE28SQh X-Google-Smtp-Source: AOwi7QD3AiA7LCE3LqIbPkOrZ6HeEL1rXeDpnqBU7wp5NRs8WiEsm78z+So6I4Z1IpavlaRPVCrX87kTsnHomB4B8sU= X-Received: by 10.37.78.133 with SMTP id c127mr2183389ybb.398.1507828271273; Thu, 12 Oct 2017 10:11:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.122.72 with HTTP; Thu, 12 Oct 2017 10:10:50 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Thu, 12 Oct 2017 10:10:50 -0700 Message-ID: To: Nat Sakimura Cc: oauth Content-Type: multipart/alternative; boundary="001a113e96027e8a7d055b5ca02c" Archived-At: Subject: Re: [OAUTH-WG] A few questions to draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 17:11:14 -0000 --001a113e96027e8a7d055b5ca02c Content-Type: text/plain; charset="UTF-8" Hi Nat, Thanks for reviewing the draft! On Thu, Oct 12, 2017 at 9:57 AM, Nat Sakimura wrote: > Thanks to the authors for coming up with this document. > The scenario is very close to what I implemented back in 2011 or so, so I > am naturally interested. > > Here are some questions I have with the draft. > > 1) Am I correct to assume that the draft targeting a device that is > completely unable to accept user input? > The spec itself requires zero input on the primary device (it's an exercise to the implementor on how to trigger it, etc). > 2) I feel that it is appropriate to mention the shoulder hacking as well. > In the Kiosk kind of use cases, the screen might be watched by the remote > camera and the "session" might be hijacked by the remote attacker. (This is > why I am asking 1) above. If the device has a capability to accept a > number, the risk can be made much lower. ) > We should add this as a security consideration. > 3) It probably is better to explicitly say that "device code MUST NOT be > displayed" especially in the case of a public client. > Agreed. > 4) Does section 3.4 and 3.5 exclude the possibility of using something > like web socket? > We are specifying a very basic approach assuming highly constrained clients. I like the idea of doing better than simple polling but not sure how to best add this and keep the spec streamlined. One thought was a HTTP2 long poll where the server just keeps the connection open, which I believe is possible as specified (though we don't mention it, and I don't have experience with this). > 5) If my read is correct, the client is doing the polling etc. by itself > and not spawning a system browser. > Correct. > In a Kiosk kind of use case, I can imagine a case that the original app > spawning a browser -- i.e, doing PKCE. In this case, the authorization > server creates user authentication and authorization page that displays the > verification URI and the user code. The client does nothing but a regular > PKCE. This kind of use case is out of scope for this document, is it > correct? > I don't quite follow, can you elaborate? Cheers, William > > Cheers, > > Nat Sakimura > > > > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113e96027e8a7d055b5ca02c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nat,

Thanks for reviewing the draft!

On Thu, Oct 12, 2017 at = 9:57 AM, Nat Sakimura <sakimura@gmail.com> wrote:
Thanks to the authors for coming = up with this document.=C2=A0
The scenario is very close to what I imple= mented back in 2011 or so, so I am naturally interested.=C2=A0
Here are some questions I have with the draft.=C2=A0

1) Am I correct to assume that the draft targeting a device= that is completely unable to accept user input?=C2=A0

The spec itself requires zero input on the primary = device (it's an exercise to the implementor on how to trigger it, etc).=
=C2=A0
2) I feel that it is appropriate to mention the shoulder hacking as well. = In the Kiosk kind of use cases, the screen might be watched by the remote c= amera and the "session" might be hijacked by the remote attacker.= (This is why I am asking 1) above. If the device has a capability to accep= t a number, the risk can be made much lower. )=C2=A0

We should add this as a security consideration.
=
=C2=A0
3) It= probably is better to explicitly say that "device code MUST NOT be di= splayed" especially in the case of a public client.=C2=A0
<= /blockquote>

Agreed.
=C2=A0
4) Does section 3.4 and 3.5 exclude= the possibility of using something like web socket?=C2=A0

We are specifying a very basic approach assumin= g highly constrained clients. I like the idea of doing better than simple p= olling but not sure how to best add this and keep the spec streamlined. One= thought was a HTTP2 long poll where the server just keeps the connection o= pen, which I believe is possible as specified (though we don't mention = it, and I don't have experience with this).
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
5) If my read is correc= t, the client is doing the polling etc. by itself and not spawning a system= browser.

Correct.
= =C2=A0
In a Kiosk= kind of use case, I can imagine a case that the original app spawning a br= owser -- i.e, doing PKCE. In this case, the authorization server creates us= er authentication and authorization page that displays the verification URI= and the user code. The client does nothing but a regular PKCE. This kind o= f use case is out of scope for this document, is it correct?=C2=A0

I don't quite follow, can you elabo= rate?

Cheers,
William
=C2=A0

Che= ers,=C2=A0

Nat Sakimura




--

Nat Sakimura

Chairman of the Board, OpenID Foundation


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


--001a113e96027e8a7d055b5ca02c-- From nobody Thu Oct 12 10:43:55 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9111013454F for ; Thu, 12 Oct 2017 10:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgIb24BMI--Z for ; Thu, 12 Oct 2017 10:43:41 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E780134317 for ; Thu, 12 Oct 2017 10:43:41 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id 189so6303119iow.10 for ; Thu, 12 Oct 2017 10:43:41 -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=QWZhPRZIm7xFd04TfbISlealhw7535X1EnPkKLRyjO8=; b=Rt+zE394uL3Sa07lhm+XAlP86X3Sfh50fOd7aKGH/gtkKoYSKOHoK2AVaN1KkXek04 QvBJ6q1zhe2EkXFZJamM4ejZEEKZelrhHhER9aiH2eJiQLeFtNoXhicneE0rNaSORztP sORVj7V5rDiKsY5ny47OBhwgqKkJ3L27E1r05ds5+3FiTFXvlDIgQbSPVDZnKZdVOLm3 kxAWkpY3YHPmw5nSQ9uPlfEis4+ksFFAl/hqrzsjTZS4sJUoysplSbXr4u9hJJF1QI5u XK3az03rJaCM54C1/rKg19gKF6pXFJa6FPqHN9cq2nywOunXzkIeGjOs0x8QQ2THaAoi 33Jw== 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=QWZhPRZIm7xFd04TfbISlealhw7535X1EnPkKLRyjO8=; b=iyyEc/s7h8hue8/7Hviba9dveJRv0kGU0LLS/xwF+mPLi6Cn33V+au0z0IuGmlEAN7 xlt67fTat7jQ+j6PwOWFlcSnE99S37y8BVCo/sBGe6KQ0S6TwvpKSbop0QMkj2G9mHsg JIRzp47m/LYnE3uFJCcJSuqe/xNzqeOQ0KUO7mZW9qbfWto7oROnDX/eeb5aGH2nhrnp 4x9j7hxuU0CuoF2ZKcuAideEO1CS1CACEtZYLrcAl2ZJ4GIod5XT4pzk+dr7SOqffdjK Y5o6XanHD2JSwPLGh1qFlAzzjxHtKgNjFBqT+dB2zg5PP78Jl0q1IB+vAKtGmiGQ8xx6 fQWA== X-Gm-Message-State: AMCzsaWAyZhOZTmTCdcGxmiFhB5m5iSImBpaY4gVGAMyCVvSLlC9PFp8 GTDaHBR9dVIjqVnEjdkm0h1WeWX1LjAYXQTXgk8= X-Google-Smtp-Source: ABhQp+ROtWrvu/j49S3XHJSWwo2hzb+/78BbWGUX4wA3QLFFMlAPGiVRznlr/SRXGO13UhMq3K5bd/5SMGb5ulxvf1U= X-Received: by 10.107.16.162 with SMTP id 34mr3878691ioq.169.1507830220411; Thu, 12 Oct 2017 10:43:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Thu, 12 Oct 2017 17:43:28 +0000 Message-ID: To: William Denniss Cc: oauth Content-Type: multipart/alternative; boundary="001a113edbd4ab58ef055b5d14b6" Archived-At: Subject: Re: [OAUTH-WG] A few questions to draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 17:43:44 -0000 --001a113edbd4ab58ef055b5d14b6 Content-Type: text/plain; charset="UTF-8" Thanks for the very quick response! Re: the last point -- I had a particular kind of Kiosk terminal based client which is split between the Kiosk which only has a browser with some hardware driving plugins and the server side that deals with most of the logic. The user comes to the kiosk terminal and touches a button on the screen. Then, it will trigger a browser to spawn and access a preconfigured URI on the server component of the client which creates the HTML user interface displaying the URI and the user code (probably in a QR code). The page starts polling the authorization endpoint then. Note that it is not the token endpoint in this case. The user then scans the QR code with his smartphone app to get to the authorization server. Then the user authenticates and authorizes at the authorization server. Once that is done, the polling finishes and the browser in the Kiosk get the `code`, which is handed back to the client. Then, the client calls the token endpoint to get the access token etc. Similar kind of scenario applies to a case where a client that resides on a small computer has to interact with various makes and OS of the user terminal, which is not under its control. Am I clear enough? Nat On Fri, Oct 13, 2017 at 2:11 AM William Denniss wrote: > Hi Nat, > > Thanks for reviewing the draft! > > On Thu, Oct 12, 2017 at 9:57 AM, Nat Sakimura wrote: > >> Thanks to the authors for coming up with this document. >> The scenario is very close to what I implemented back in 2011 or so, so I >> am naturally interested. >> >> Here are some questions I have with the draft. >> >> 1) Am I correct to assume that the draft targeting a device that is >> completely unable to accept user input? >> > > The spec itself requires zero input on the primary device (it's an > exercise to the implementor on how to trigger it, etc). > > >> 2) I feel that it is appropriate to mention the shoulder hacking as well. >> In the Kiosk kind of use cases, the screen might be watched by the remote >> camera and the "session" might be hijacked by the remote attacker. (This is >> why I am asking 1) above. If the device has a capability to accept a >> number, the risk can be made much lower. ) >> > > We should add this as a security consideration. > > >> 3) It probably is better to explicitly say that "device code MUST NOT be >> displayed" especially in the case of a public client. >> > > Agreed. > > >> 4) Does section 3.4 and 3.5 exclude the possibility of using something >> like web socket? >> > > We are specifying a very basic approach assuming highly constrained > clients. I like the idea of doing better than simple polling but not sure > how to best add this and keep the spec streamlined. One thought was a HTTP2 > long poll where the server just keeps the connection open, which I believe > is possible as specified (though we don't mention it, and I don't have > experience with this). > > >> 5) If my read is correct, the client is doing the polling etc. by itself >> and not spawning a system browser. >> > > Correct. > > >> In a Kiosk kind of use case, I can imagine a case that the original app >> spawning a browser -- i.e, doing PKCE. In this case, the authorization >> server creates user authentication and authorization page that displays the >> verification URI and the user code. The client does nothing but a regular >> PKCE. This kind of use case is out of scope for this document, is it >> correct? >> > > I don't quite follow, can you elaborate? > > Cheers, > William > > >> >> Cheers, >> >> Nat Sakimura >> >> >> >> >> -- >> >> Nat Sakimura >> >> Chairman of the Board, OpenID Foundation >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > -- Nat Sakimura Chairman of the Board, OpenID Foundation --001a113edbd4ab58ef055b5d14b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the very quick response!=C2=A0

Re: the last point -- I had a particular kind of Kiosk terminal based cl= ient which is split between the Kiosk which only has a browser with some ha= rdware driving plugins and the server side that deals with most of the logi= c. The user comes to the kiosk terminal and touches a button on the screen.= Then, it will trigger a browser to spawn and access a preconfigured URI on= the server component of the client which creates the HTML user interface d= isplaying the URI and the user code (probably in a QR code). The page start= s polling the authorization endpoint then. Note that it is not the token en= dpoint in this case. The user then scans the QR code with his smartphone ap= p to get to the authorization server. Then the user authenticates and autho= rizes at the authorization server. Once that is done, the polling finishes = and the browser in the Kiosk get the `code`, which is handed back to the cl= ient. Then, the client calls the token endpoint to get the access token etc= . Similar kind of scenario applies to a case where a client that resides on= a small computer has to interact with various makes and OS of the user ter= minal, which is not under its control.=C2=A0

Am I = clear enough?=C2=A0

Nat

On Fri, Oct 13, 2017 at 2:11 AM William D= enniss <wdenniss@google.com&g= t; wrote:
Hi Nat,<= div>
Thanks for reviewing the draft!

<= div class=3D"gmail_quote">
On Thu, Oct 12, 2017 at = 9:57 AM, Nat Sakimura <sakimura@gmail.com> wrote:
Thanks to the authors for coming = up with this document.=C2=A0
The scenario is very close to what I imple= mented back in 2011 or so, so I am naturally interested.=C2=A0
Here are some questions I have with the draft.=C2=A0

1) Am I correct to assume that the draft targeting a device= that is completely unable to accept user input?=C2=A0

The spec itself requires z= ero input on the primary device (it's an exercise to the implementor on= how to trigger it, etc).
=C2=A0
2) I feel that it is app= ropriate to mention the shoulder hacking as well. In the Kiosk kind of use = cases, the screen might be watched by the remote camera and the "sessi= on" might be hijacked by the remote attacker. (This is why I am asking= 1) above. If the device has a capability to accept a number, the risk can = be made much lower. )=C2=A0

We should add this as a security consideration.
=
=C2=A0
3) It probably is better to explicitly say that "d= evice code MUST NOT be displayed" especially in the case of a public c= lient.=C2=A0

Agreed.
=C2=A0
4) Does section 3.4 and 3.5 exclude= the possibility of using something like web socket?=C2=A0

We are specifying a ve= ry basic approach assuming highly constrained clients. I like the idea of d= oing better than simple polling but not sure how to best add this and keep = the spec streamlined. One thought was a HTTP2 long poll where the server ju= st keeps the connection open, which I believe is possible as specified (tho= ugh we don't mention it, and I don't have experience with this).
=C2=A0
5) If my read is correct, the client is doing th= e polling etc. by itself and not spawning a system browser.

Correct.
=
=C2=A0
In a Kiosk kind of use case, I can imagine a case that the or= iginal app spawning a browser -- i.e, doing PKCE. In this case, the authori= zation server creates user authentication and authorization page that displ= ays the verification URI and the user code. The client does nothing but a r= egular PKCE. This kind of use case is out of scope for this document, is it= correct?=C2=A0

I don't quite follow, can you elaborate?

=
Cheers,
William
=C2=A0

Cheers,=C2=A0

Nat= Sakimura




=
--
=

Nat Sakimura

Chairman of the Board, OpenID Foundation


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


--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a113edbd4ab58ef055b5d14b6-- From nobody Thu Oct 12 14:50:11 2017 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 815FC1344AD; Thu, 12 Oct 2017 14:50: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: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150784500346.16836.10053591552617872796@ietfa.amsl.com> Date: Thu, 12 Oct 2017 14:50:03 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 21:50:03 -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 : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-04.txt Pages : 18 Date : 2017-10-12 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for OAuth client authentication to the authorization sever as well as for certificate bound sender constrained access tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 12 15:07:48 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D2F132992 for ; Thu, 12 Oct 2017 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADbJHOKGHuuW for ; Thu, 12 Oct 2017 15:07:44 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F56132949 for ; Thu, 12 Oct 2017 15:07:43 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id h70so7034693ioi.4 for ; Thu, 12 Oct 2017 15:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vH6zR1R5VEbKuxJzFD4m4Q+2DrD5FHN/64nAexQ0er8=; b=P5veDXrGlVNrUjglBDd0POyhmolka+3pSuoWdVeDzj0z1yCzpW60PhrSddRqhxR/tG bhxMWnsXQnZfTGLvH54A8ppmXc79DzuwrgsfzkWwuquC67RQVGNR38f8dkwCUaDRaUdH QHFqIf0ZkVCx2x9AQPTM75NDiE1PSMWbP75PA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vH6zR1R5VEbKuxJzFD4m4Q+2DrD5FHN/64nAexQ0er8=; b=kK4oBMuBnWlnnK2sf9mY0Kx0Iw8gdnI64C4gVfToLs1p1Helu0dSLX1yg/ZSjWYGoO FuXcpQZdATuzfKK5AWeYLAD6vNKGZ7v2Evg91lTBSE1kGAYDrsjaKdAFtSifQpcjVJsd MeSsWzZNtUThF/5RSe+r+TYZYZBPud1o/Wk+6mhSK0U4nxfOL8PK0B5alf35uQPbMY3i piwAD+2Un0385O/zPZT9v43Qp4DY5LGxGDavutswALZG/PldBKSjqiRWnTcy3SSeW7vb IHyRazh9+4ZIw5cdhMav1qxiPW4r2L+QkFgqDb93ysz9ycBh/9mst94N7zCVWexYyKom M/fQ== X-Gm-Message-State: AMCzsaXaOetVwCn2KqFGE/PTAYNHwmDYSB2jK5kiS+Z0TuZqANi4PTDp icpl8DTXwtKVQqt4oGQ4XtlzdfzLVjS/pDvhZFpoki7WKYAKtcNIKOJz4K0ftpQBxAFh5/2Rx6u GgdGOt8lR87rYCw== X-Google-Smtp-Source: ABhQp+TGO2epZfvtLpOlZOGPhhDB/sgIBooGSabNJ5Ode6TYharGvNZzfqzmaVwUjZbNtjn/OAQuWR5ZdtFWpwzFxEY= X-Received: by 10.107.147.86 with SMTP id v83mr5501833iod.82.1507846062787; Thu, 12 Oct 2017 15:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.106.34 with HTTP; Thu, 12 Oct 2017 15:07:12 -0700 (PDT) In-Reply-To: <150784500346.16836.10053591552617872796@ietfa.amsl.com> References: <150784500346.16836.10053591552617872796@ietfa.amsl.com> From: Brian Campbell Date: Thu, 12 Oct 2017 16:07:12 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c05665cf2ec14055b60c4ce" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 22:07:46 -0000 --94eb2c05665cf2ec14055b60c4ce Content-Type: text/plain; charset="UTF-8" I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth 2.0" has been published. The changes, based on feedback and discussion on this list over the last two months, are listed below. draft-ietf-oauth-mtls-04 o Change the name of the 'Public Key method' to the more accurate 'Self-Signed Certificate method' and also change the associated authentication method metadata value to "self_signed_tls_client_auth". o Removed the "tls_client_auth_root_dn" client metadata field as discussed in https://mailarchive.ietf.org/arch/msg/oauth/ swDV2y0be6o8czGKQi1eJV-g8qc o Update draft-ietf-oauth-discovery reference to -07 o Clarify that MTLS client authentication isn't exclusive to the token endpoint and can be used with other endpoints, e.g. RFC 7009 revocation and 7662 introspection, that utilize client authentication as discussed in https://mailarchive.ietf.org/arch/msg/oauth/ bZ6mft0G7D3ccebhOxnEYUv4puI o Reorganize the document somewhat in an attempt to more clearly make a distinction between mTLS client authentication and certificate bound access tokens as well as a more clear delineation between the two (PKI/Public key) methods for client authentication o Editorial fixes and clarifications ---------- Forwarded message ---------- From: Date: Thu, Oct 12, 2017 at 3:50 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-04.txt Pages : 18 Date : 2017-10-12 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for OAuth client authentication to the authorization sever as well as for certificate bound sender constrained access tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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.* --94eb2c05665cf2ec14055b60c4ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth 2.0" has bee= n published. The changes, based on feedback and discussion on this list ove= r the last two months, are listed below.

   draft-ietf-oauth-mtls-04

   o  Change the name of the 'Public Key method' to the more accura=
te
      'Self-Signed Certificate method' and also change the associat=
ed
      authentication method metadata value to
      "self_signed_tls_client_auth".
   o  Removed the "tls_client_auth_root_dn" client metadata field=
 as
      discussed in https://mailarchive.ietf.org/=
arch/msg/oauth/
      swDV2y0be6o8czGKQi1eJV-g8qc
   o  Update draft-ietf-oauth-discovery reference to -07
   o  Clarify that MTLS client authentication isn't exclusive to the
      token endpoint and can be used with other endpoints, e.g.  RFC
      700=
9 revocation and 7662 introspection, that utilize client
      authentication as discussed in
      https://mailarchive.ietf.org/arch/msg=
/oauth/
      bZ6mft0G7D3ccebhOxnEYUv4puI
   o  Reorganize the document somewhat in an attempt to more clearly
      make a distinction between mTLS client authentication and
      certificate bound access tokens as well as a more clear
      delineation between the two (PKI/Public key) methods for client
      authentication
   o  Editorial fixes and clarifications

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: T= hu, Oct 12, 2017 at 3:50 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-o= auth-mtls-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mutual TLS Profile for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-12

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for OAu= th
=C2=A0 =C2=A0client authentication to the authorization sever as well as fo= r
=C2=A0 =C2=A0certificate bound sender constrained access tokens.


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

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

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


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

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

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c05665cf2ec14055b60c4ce-- From nobody Fri Oct 13 02:18:58 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65407132331 for ; Fri, 13 Oct 2017 02:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 l6IacwcCMFen for ; Fri, 13 Oct 2017 02:18:55 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) (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 93560133052 for ; Fri, 13 Oct 2017 02:18:55 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id 2w7Ie2ol8o61w2w7JelnPU; Fri, 13 Oct 2017 02:18:55 -0700 To: oauth@ietf.org References: <150784500346.16836.10053591552617872796@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <83c305ab-4c3b-b16e-1385-7e0e3af6a556@connect2id.com> Date: Fri, 13 Oct 2017 12:18:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2FC14BC7AD696C628EAD31D6" Content-Language: en-US X-CMAE-Envelope: MS4wfGkkuyUYz2Sc68s7AXZINzV7stRa+4oNJVXpxqNwoahBO++gM9NWz52BKjdMPCcYQP2RZ44y0DFh62hOTUcYji96JmEoPXdxG5xX3oFXrdCNJyP20gS/ asqtvuacGEUesGnL6+hidetNNFWQuHlnmSegTbnMK34Cs1ghNNu58Lm6 Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 09:18:57 -0000 This is a multi-part message in MIME format. --------------2FC14BC7AD696C628EAD31D6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Superb! Thanks for putting down everything that was discussed. I read the new version and have zero comments about it. Will sender-constrained access tokens also work in a token exchange scenario? (draft-ietf-oauth-token-exchange-09) Vladimir On 13/10/17 01:07, Brian Campbell wrote: > I'm pleased to announce that a new draft of "Mutual TLS Profile for OAu= th > 2.0" has been published. The changes, based on feedback and discussion = on > this list over the last two months, are listed below. > > draft-ietf-oauth-mtls-04 > > > o Change the name of the 'Public Key method' to the more accurate > 'Self-Signed Certificate method' and also change the associated > authentication method metadata value to > "self_signed_tls_client_auth". > o Removed the "tls_client_auth_root_dn" client metadata field as > discussed in https://mailarchive.ietf.org/arch/msg/oauth/ > > swDV2y0be6o8czGKQi1eJV-g8qc > > o Update draft-ietf-oauth-discovery > reference to > -07 > o Clarify that MTLS client authentication isn't exclusive to the > token endpoint and can be used with other endpoints, e.g. RFC > > 7009 revocation and 7662 > introspection, that utilize client > authentication as discussed in > https://mailarchive.ietf.org/arch/msg/oauth/ > > bZ6mft0G7D3ccebhOxnEYUv4puI > > o Reorganize the document somewhat in an attempt to more clearly > make a distinction between mTLS client authentication and > certificate bound access tokens as well as a more clear > delineation between the two (PKI/Public key) methods for client > authentication > o Editorial fixes and clarifications > > > ---------- Forwarded message ---------- > From: > Date: Thu, Oct 12, 2017 at 3:50 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the I= ETF. > > Title : Mutual TLS Profile for OAuth 2.0 > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-04.txt > Pages : 18 > Date : 2017-10-12 > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for OAuth > client authentication to the authorization sever as well as for > certificate bound sender constrained access tokens. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-04 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-04 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2FC14BC7AD696C628EAD31D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Superb! Thanks for putting down everything that was discussed. I read the new version and have zero comments about it.

Will sender-constrained access tokens also work in a token exchange scenario?

(draft-ietf-oauth-token-exchange-09)

Vladimir


On 13/10/17 01:07, Brian Campbell wrote:
I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth
2.0" has been published. The changes, based on feedback and discussion on
this list over the last two months, are listed below.

   draft-ietf-oauth-mtls-04
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-04>

   o  Change the name of the 'Public Key method' to the more accurate
      'Self-Signed Certificate method' and also change the associated
      authentication method metadata value to
      "self_signed_tls_client_auth".
   o  Removed the "tls_client_auth_root_dn" client metadata field as
      discussed in https://mailarchive.ietf.org/arch/msg/oauth/
<https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
      swDV2y0be6o8czGKQi1eJV-g8qc
<https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
   o  Update draft-ietf-oauth-discovery
<https://tools.ietf.org/html/draft-ietf-oauth-discovery> reference to
-07
   o  Clarify that MTLS client authentication isn't exclusive to the
      token endpoint and can be used with other endpoints, e.g.  RFC
<https://tools.ietf.org/html/rfc7009>
      7009 <https://tools.ietf.org/html/rfc7009> revocation and 7662
introspection, that utilize client
      authentication as discussed in
      https://mailarchive.ietf.org/arch/msg/oauth/
<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI>
      bZ6mft0G7D3ccebhOxnEYUv4puI
<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI>
   o  Reorganize the document somewhat in an attempt to more clearly
      make a distinction between mTLS client authentication and
      certificate bound access tokens as well as a more clear
      delineation between the two (PKI/Public key) methods for client
      authentication
   o  Editorial fixes and clarifications


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Oct 12, 2017 at 3:50 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

        Title           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-04.txt
        Pages           : 18
        Date            : 2017-10-12

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the authorization sever as well as for
   certificate bound sender constrained access tokens.


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

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

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


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

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

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




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

--------------2FC14BC7AD696C628EAD31D6-- From nobody Fri Oct 13 09:32:21 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB0133080 for ; Fri, 13 Oct 2017 09:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 fHToTkStQRUU for ; Fri, 13 Oct 2017 09:32:17 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DAD1330BF for ; Fri, 13 Oct 2017 09:32:16 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id n137so9587546iod.6 for ; Fri, 13 Oct 2017 09:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qnH3jWneGujgVUIq7hbPbSO0lmON1y3DRz0I81Fh7A8=; b=ArKwlIEsK9dy6DjMm4l/4OOeGjDN+du0bb8jA12QFoQ1rF8jpVBeNf4eWmumrCBdBf 4BTceT+3dHZsrtK2zKaufroKI2PK2B/QXLJApUM+EadelO+gFV9pLzJ2s8EGWgWzDUhL 516ZVR94Hxrdag6G9wI6En7K0tVgsl41JksVc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qnH3jWneGujgVUIq7hbPbSO0lmON1y3DRz0I81Fh7A8=; b=lgLQvT0hTjGQwZ5wYlAp4AhhP3amng2IveqRbMICU87WX9R0zHMLn8DFxlMyh0Mltg S5zU2SGg+bhynM979POL1EG2fsdRlYTe0GhHgO1hI/q50K1WkF+zPZ7ny6WNWcC4n4lw yEqo4Oi+SDvT7SCtVuiQDbJ0pk2nVnDN9jdn4wz2FBKBYTeeG8Er8g5+jRsmh7TApc/W /JESL7xOXzHhbMXr/Km1UViIVSoMw/4hKoxS9UDt345zGrCOcNXj64wIqUsSSU2NSBhz G8Ksk1d7pJLd5U7obKqgvJyijv6LPCwjF0gP+yAH8ujAn5fOSyU4JkP8Xd3kSMUkeT3t lODQ== X-Gm-Message-State: AMCzsaWBywI0ctibycpVFd8MSvxQBPiKzdXqaA0sp1s+Af0X/9o6C43O CJ8MNm1alnqBY36dqK7LLlGoixKGfNCifyJYlJ1T3fSJWXrXt+tfhtTtOhSf4SlJPCTFHsyCbYY DVMUfHohJ/b2THTvS X-Google-Smtp-Source: ABhQp+SCdam/QF3IidjrOlXJ/xfdgxZqfSAw4ociQxgvaC1DmtimdEpS5IQgdHyrP7Lr2GrIvBm7E98yJcSQtvNzjUo= X-Received: by 10.107.232.3 with SMTP id f3mr2489330ioh.156.1507912335700; Fri, 13 Oct 2017 09:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.106.34 with HTTP; Fri, 13 Oct 2017 09:31:44 -0700 (PDT) In-Reply-To: <83c305ab-4c3b-b16e-1385-7e0e3af6a556@connect2id.com> References: <150784500346.16836.10053591552617872796@ietfa.amsl.com> <83c305ab-4c3b-b16e-1385-7e0e3af6a556@connect2id.com> From: Brian Campbell Date: Fri, 13 Oct 2017 10:31:44 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="f403043819f01f51d2055b703302" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 16:32:20 -0000 --f403043819f01f51d2055b703302 Content-Type: text/plain; charset="UTF-8" Thanks for the review, Vladimir. And yes, sender-constrained access tokens should also work in a token exchange scenario. On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov wrote: > Superb! Thanks for putting down everything that was discussed. I read the > new version and have zero comments about it. > > Will sender-constrained access tokens also work in a token exchange > scenario? > > (draft-ietf-oauth-token-exchange-09) > > Vladimir > > On 13/10/17 01:07, Brian Campbell wrote: > > I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth > 2.0" has been published. The changes, based on feedback and discussion on > this list over the last two months, are listed below. > > draft-ietf-oauth-mtls-04 > > o Change the name of the 'Public Key method' to the more accurate > 'Self-Signed Certificate method' and also change the associated > authentication method metadata value to > "self_signed_tls_client_auth". > o Removed the "tls_client_auth_root_dn" client metadata field as > discussed in https://mailarchive.ietf.org/arch/msg/oauth/ > swDV2y0be6o8czGKQi1eJV-g8qc > o Update draft-ietf-oauth-discovery reference to > -07 > o Clarify that MTLS client authentication isn't exclusive to the > token endpoint and can be used with other endpoints, e.g. RFC > 7009 revocation and 7662 > introspection, that utilize client > authentication as discussed in > https://mailarchive.ietf.org/arch/msg/oauth/ > bZ6mft0G7D3ccebhOxnEYUv4puI > > o Reorganize the document somewhat in an attempt to more clearly > make a distinction between mTLS client authentication and > certificate bound access tokens as well as a more clear > delineation between the two (PKI/Public key) methods for client > authentication > o Editorial fixes and clarifications > > > ---------- Forwarded message ---------- > From: > Date: Thu, Oct 12, 2017 at 3:50 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : Mutual TLS Profile for OAuth 2.0 > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-04.txt > Pages : 18 > Date : 2017-10-12 > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for OAuth > client authentication to the authorization sever as well as for > certificate bound sender constrained access tokens. > > > The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-04https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04 > > A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403043819f01f51d2055b703302 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Vladimir. And yes, sender-constrain= ed access tokens should also work in a token exchange scenario.

On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov <v= ladimir@connect2id.com> wrote:
=20 =20 =20

Superb! Thanks for putting down everything that was discussed. I read the new version and have zero comments about it.

Will sender-constrained access tokens also work in a token exchange scenario?

(draft-ietf-oauth-token-exchange-09)

Vladimir


On 13/10/17 01:07, = Brian Campbell wrote:
I'm pleased to announce that a new draft of=
 "Mutual TLS Profile for OAuth
2.0" has been published. The changes, based on feedback and discussion=
 on
this list over the last two months, are listed below.

   draft-ietf-oauth-mtls-04
<htt=
ps://tools.ietf.org/html/draft-ietf-oauth-mtls-04>

   o  Change the name of the 'Public Key method' to the more accura=
te
      'Self-Signed Certificate method' and also change the associat=
ed
      authentication method metadata value to
      "self_signed_tls_client_auth".
   o  Removed the "tls_client_auth_root_dn" client metadata field=
 as
      discussed in htt=
ps://mailarchive.ietf.org/arch/msg/oauth/
<https://mailarchive.ietf.org/arch/msg/oauth/swDV2=
y0be6o8czGKQi1eJV-g8qc>
      swDV2y0be6o8czGKQi1eJV-g8qc
<https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8=
czGKQi1eJV-g8qc>
   o  Update draft-ietf-oauth-discovery
<https://=
tools.ietf.org/html/draft-ietf-oauth-discovery> reference to
-07
   o  Clarify that MTLS client authentication isn't exclusive to the
      token endpoint and can be used with other endpoints, e.g.  RFC
<https://tools.ietf.org/html=
/rfc7009>
      7009 <https://tools.ie=
tf.org/html/rfc7009> revocation and 7662
introspection, that utilize client
      authentication as discussed in
      https://mailarch=
ive.ietf.org/arch/msg/oauth/
<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3c=
cebhOxnEYUv4puI>
      bZ6mft0G7D3ccebhOxnEYUv4puI
<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3c=
cebhOxnEYUv4puI>

   o  Reorganize the document somewhat in an attempt to more clearly
      make a distinction between mTLS client authentication and
      certificate bound access tokens as well as a more clear
      delineation between the two (PKI/Public key) methods for client
      authentication
   o  Editorial fixes and clarifications


---------- Forwarded message ----------
From: <internet-drafts@ietf.org&=
gt;
Date: Thu, Oct 12, 2017 at 3:50 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

        Title           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-04.txt
        Pages           : 18
        Date            : 2017-10-12

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the authorization sever as well as for
   certificate bound sender constrained access tokens.


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

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

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


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

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

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




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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/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. --f403043819f01f51d2055b703302-- From nobody Fri Oct 13 14:58:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BE51320CF for ; Fri, 13 Oct 2017 14:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIwT8Zzy6MyL for ; Fri, 13 Oct 2017 14:58:55 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF94D124239 for ; Fri, 13 Oct 2017 14:58:55 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id b6so2969143pfh.7 for ; Fri, 13 Oct 2017 14:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=orWwdtTyR4iXTlQJiUyLBQX87D/OCozKLJPKHjsGkwI=; b=IzpCqdz9w6RcqTvrm1F4YW5MPHHtrusuJl9slXV5DLqcv/zpDCVaQxcvrdUbyDmwfk J2r6gYdxGczd2KkPhl/CejbLPaJyaDHDBWOkoOfU7ZDVhbRTY0QS8Kee/vDRQciRKWID Vrnwg3osrMDF8zYxvZ/1wkuNfEUPhSHCDWfttPQz2d8QtKp75thIPzoHx+Pezem4pyS9 kKEj+Fp5a+dWKSJ7ZpZyDXRYKfmA7mx9hF5Wtc9PqwoMpMLTzzdIKQr6pgwoRAt8l8x1 TQvUcmhTWxK91VHceJYqqHbMg+HYWIrlrrUC+Eem3LPjoqN6cXO23SoNSYwah5wUVRhk QtIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=orWwdtTyR4iXTlQJiUyLBQX87D/OCozKLJPKHjsGkwI=; b=Zdj/9EyhGQZ6IBNURZTgKudnqd1LUsaGy96PN+7pvuSdzsS1zExks1xhnjqD1Y3ZJx Qz7fprQvN7RyxdT99ociRUjAln3QSroCS0bfa3HbFwNiJ/PCULzKz0itEbaQV4Wrr7bJ BWVwTuSf0jAfiBEMkC7qi4RVUWuMFRZowHSJc5QTlMKnhQb7zr8/1fgZDLHj6OQrbtA0 36/VZZ77gHMGuUP9shH3ElWe36LQDhGJ3kQbmcZ8IIM/JZ4D1AbXtUrV75VLG9LKkD8d ulHrbC6PNx6e5GvuuC4ThxcXiiS1eNLG+9qzLpXNQ3m7Nk/4SQuaCplJ3ev1Vi0Ker40 Pybw== X-Gm-Message-State: AMCzsaWeNB4ddbCUlYA2408DfpbgeT+bJms6RxktP/z+hiXyR37nKTOr wWDtk+wdYlG7i5gfJRxG+Ii9Fol/TB8OS5yu6ooYFg== X-Google-Smtp-Source: AOwi7QCs8poIoEwHmpnl46GrSqO5xwIvCBqDsEpcgELfn02lINUEoImR9kwbQzMtkhXHJJn2yZitdCZQZT3fYAGZnoE= X-Received: by 10.101.87.202 with SMTP id q10mr2415528pgr.141.1507931935103; Fri, 13 Oct 2017 14:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Fri, 13 Oct 2017 14:58:54 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Fri, 13 Oct 2017 23:58:54 +0200 Message-ID: To: William Denniss Cc: "" , draft-ietf-oauth-device-flow.authors@ietf.org Content-Type: multipart/alternative; boundary="089e08237c18566f1a055b74c3d0" Archived-At: Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:58:58 -0000 --089e08237c18566f1a055b74c3d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping On Thu, Sep 7, 2017 at 10:11 PM, Samuel Erdtman wrote: > Hi Authors > > Thanks for writing this very useful draft. > > I have some review comments that I hope will be useful. > > As a general comment, has it been considered to include CoAP mappings too= ? > it might be good to reach even more constrained devices (maybe another > draft). > > > 1. Introduction > Missing newline between Step E and D > > 1. Introduction > The bullet list with the polling of the client and the user authorisation > is a bit hard to read, step D comes again after E. Maybe it would be easi= er > to read if using decimal numbers. > > =E2=80=981. Introduction=E2=80=99 and =E2=80=983. Protocol=E2=80=99 > I would like to move the ascii art and the corresponding list of steps > from =E2=80=981. Introduction=E2=80=99 to =E2=80=983. Protocol=E2=80=99= and use the terminology explained > in =E2=80=982. Terminology=E2=80=99 > > 3.1. Device Authorization Request > Is there no authentication? e.g. use of client secret? (or Pre-Shared Key > or Raw Public key as described in draft-erdtman-ace-rpcc) > I don=E2=80=99t think client identification is enough I think it should > authenticate, at least as the recommendation. > > 3.2. Device Authorization Response > I would like to change verification_uri be optional. If for example the > device vendor has a companion app that app could easily have the > verification_uri, that would simplify for the user that would only have t= o > enter the code. (and it could save some bytes). > > 3.2. Device Authorization Response > I think it would make sense to add an optional parameter with the token > endpoint uri, in that way it does not have to be hardcoded in the client > (or discovered) but the AS can tell the client where to get the token. Or > it could be done with a redirect to the token URL or the Device > Verification Code could be a the URL to poll instead. > > 3.4. Device Access Token Request > client_id, it says REQUIRED but then it states that it is to be used only > if =E2=80=9Cclient is not authenticating with the authorization server as= described > in Section 3.2.1. of [RFC6749].=E2=80=9D > I think the parameter should be optional and authentication required. > > 3.2. Device Authorization Response and 3.5. Device Access Token Respon= se > =E2=80=9CThe interval at which the client polls MUST NOT be more frequent= than > the "interval" parameter returned in the Device Authorization > Response (see Section 3.2).=E2=80=9D > =E2=80=9COPTIONAL. The minimum amount of time in seconds that the client > SHOULD wait between polling requests to the token endpoint.=E2=80= =9D > Feels like a contradiction between the parameter description and token > endpoint response. I would like to have MUST in both cases. > > 3.5. Device Access Token Response > I think last paragraph is better suited in the introduction section. > > 5.2. Device Trustworthiness > I think device authentication should/could be mentioned here > > > > > > > > --089e08237c18566f1a055b74c3d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ping

On Thu, Sep 7, 2017 at 10:11 PM, Samuel Erdtman &= lt;samuel@erdtman.se= > wrote:
<= div>
Hi Authors

Thanks for writing this very useful d= raft.

I have some review comments that I hope will be useful.<= br>
As a general comment, has it been considered to include CoAP m= appings too? it might be good to reach even more constrained devices (maybe= another draft).


1.=C2=A0 Introduction
Missing newline betwee= n Step E and D

1.=C2=A0 Introduction
The bullet list with the pol= ling of the client and the user authorisation is a bit hard to read, step D= comes again after E. Maybe it would be easier to read if using decimal num= bers.

=E2=80=981.=C2=A0 Introduction=E2=80=99 and =E2=80=983.=C2=A0 = Protocol=E2=80=99
I would like to move the ascii art and the correspondi= ng list of steps from =E2=80=981.=C2=A0 Introduction=E2=80=99 to =E2=80=983= .=C2=A0 Protocol=E2=80=99 and use the terminology explained in =E2=80=982.= =C2=A0 Terminology=E2=80=99

3.1.=C2=A0 Device Authorization Request<= br>Is there no authentication? e.g. use of client secret? (or Pre-Shared Ke= y or Raw Public key as described in draft-erdtman-ace-rpcc)
I don=E2=80= =99t think client identification is enough I think it should authenticate, = at least as the recommendation.

3.2.=C2=A0 Device Authorization Resp= onse
I would like to change verification_uri be optional. If for example= the device vendor has a companion app that app could easily have the verif= ication_uri, that would simplify for the user that would only have to enter= the code. (and it could save some bytes).

3.2.=C2=A0 Device Authori= zation Response
I think it would make sense to add an optional parameter= with the token endpoint uri, in that way it does not have to be hardcoded = in the client (or discovered) but the AS can tell the client where to get t= he token. Or it could be done with a redirect to the token URL or the Devic= e Verification Code could be a the URL to poll instead.

3.4.=C2=A0 D= evice Access Token Request
client_id, it says REQUIRED but then it state= s that it is to be used only if =E2=80=9Cclient is not authenticating with = the authorization server as described in Section 3.2.1. of [RFC6749].=E2=80= =9D
I think the parameter should be optional and authentication required= .

3.2.=C2=A0 Device Authorization Response and=C2=A0 3.5.=C2=A0 Devi= ce Access Token Response
=E2=80=9CThe interval at which the client polls= MUST NOT be more frequent than
=C2=A0=C2=A0 the "interval" pa= rameter returned in the Device Authorization
=C2=A0=C2=A0 Response (see = Section 3.2).=E2=80=9D
=E2=80=9COPTIONAL.=C2=A0 The minimum amount of ti= me in seconds that the client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD wait= between polling requests to the token endpoint.=E2=80=9D
Feels like a c= ontradiction between the parameter description and token endpoint response.= I would like to have MUST in both cases.

3.5.=C2=A0 Device Access T= oken Response
I think last paragraph is better suited in the introductio= n section.

5.2.=C2=A0 Device Trustworthiness
I think device authe= ntication should/could be mentioned here





<= br>

--089e08237c18566f1a055b74c3d0-- From nobody Fri Oct 13 15:22:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89396132811 for ; Fri, 13 Oct 2017 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odZPgVBvjw3l for ; Fri, 13 Oct 2017 15:22:13 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 EF5FD13219F for ; Fri, 13 Oct 2017 15:22:12 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id 1so22260407qtn.3 for ; Fri, 13 Oct 2017 15:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YT8BKTYZeYknPGOyEeczfENJGx9PIlNLbz89ZoxrcCc=; b=sVQ663jk9/P1rYSB7hoy1USAimcfKrJmgeUhXTNunxyZO/Q4/727fNNr9mnAXslKvE PeEXknAejhBmwG9iXieMpDpiWfDNpYC93ljRWHfAE+stQy9mVp3MsH6BpozLpl3keM3U 8M5Hy/BnEA9EByke3Pp2GqLImELErfR8JXjyojhO61ehSJcvq98bCduIKG1fXMCFVe6L sXDFU2kEQc7138sZae5V9Z85W2/fWVnxXzAxYNLEwSDregxJ+NgD1Qa/AMGx6LKePGKK lpTx23XG556XBA7LjuRRJWL57qpZrm5bq5kXO49G+ItLf2yx64TQoARh+oqrM2+Ds06f ZAQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YT8BKTYZeYknPGOyEeczfENJGx9PIlNLbz89ZoxrcCc=; b=jnnhJt1gV47UeervdGG95dtzGj9fSkbqiZ0nxo1v6uUXQa3paeAeMNCbgGBe7bmAJQ USh9DQeC3gUhD3HetfMKPCXVzc5omk/gHJEY6ANAHUzyGfBst8rNWPabr3tKjkAdcAOH +KKM6WH5vl1sgDLgzoAwTZLDlbxNrQvsl0RKgJAsc2+ibSZbPN+sznRIR6gOI0M2tbhv lI59jfWe+L6XrVMSLVLaC0TvLWQzfeO0aRPJsH1EqUsj1zBVm33ZpgSZrkCWrX3QRpeU 1pS3DmrD2NzcyQZSgSW34EfpTAzU78PywskhJPgiXdXcy7aTsYDPMQ5VT+bCsFRjqMaJ NmXA== X-Gm-Message-State: AMCzsaXu3Ze3yzWe5iTWNqb5JA7rUBxAk8Qn/PU2SfjitgeJq6USxxOe 5EWd6ceGrIJgtB3TThVlwtrduqOpUfo53HZmz2dpk/ICiqQ= X-Google-Smtp-Source: AOwi7QAcQcH0IPatYNh0/UQqKALKL0g0yuvtE/KVh7ks7ViqD8yVQEjW6ZGfXxJfz2bpATm8DVMwLJb/4yfVLTiL9KQ= X-Received: by 10.129.65.76 with SMTP id f12mr1863900ywk.274.1507933331671; Fri, 13 Oct 2017 15:22:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.122.72 with HTTP; Fri, 13 Oct 2017 15:21:51 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Fri, 13 Oct 2017 15:21:51 -0700 Message-ID: To: Samuel Erdtman Cc: draft-ietf-oauth-device-flow.authors@ietf.org, "" Content-Type: multipart/alternative; boundary="f403045e764c94d603055b751663" Archived-At: Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-device-flow-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 22:22:15 -0000 --f403045e764c94d603055b751663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 7, 2017 at 1:11 PM, Samuel Erdtman wrote: > Hi Authors > > Thanks for writing this very useful draft. > Hi Samuel, Thanks for reviewing the draft! > > I have some review comments that I hope will be useful. > > As a general comment, has it been considered to include CoAP mappings too= ? > it might be good to reach even more constrained devices (maybe another > draft). > > > 1. Introduction > Missing newline between Step E and D > 1. Introduction > The bullet list with the polling of the client and the user authorisation > is a bit hard to read, step D comes again after E. Maybe it would be easi= er > to read if using decimal numbers. > (D) is referenced in (E), I believe it's intentional. I'll expand the reference to "(step D)" to make that clear. > =E2=80=981. Introduction=E2=80=99 and =E2=80=983. Protocol=E2=80=99 > I would like to move the ascii art and the corresponding list of steps > from =E2=80=981. Introduction=E2=80=99 to =E2=80=983. Protocol=E2=80=99= and use the terminology explained > in =E2=80=982. Terminology=E2=80=99 > I'll discuss this with my co-authors, could make sense. > > 3.1. Device Authorization Request > Is there no authentication? e.g. use of client secret? (or Pre-Shared Key > or Raw Public key as described in draft-erdtman-ace-rpcc) > I don=E2=80=99t think client identification is enough I think it should > authenticate, at least as the recommendation. > There is no client authentication as they are public clients. This is covered in the security consideration "Non-confidential Clients". As draft is nearly ready to publish, I don't think we should take a reference on an I-D that would delay our publication. > > 3.2. Device Authorization Response > I would like to change verification_uri be optional. If for example the > device vendor has a companion app that app could easily have the > verification_uri, that would simplify for the user that would only have t= o > enter the code. (and it could save some bytes). > This type of use-case is mentioned in the section "Non-Browser User Interaction" if you own both the server and the client =E2=80=93 you can re= ally do whatever you like as it doesn't need to be interoperable. If this spec is useful for that case =E2=80=93 great, but I don't think we need to discuss = or cater for this more than we have. > 3.2. Device Authorization Response > I think it would make sense to add an optional parameter with the token > endpoint uri, in that way it does not have to be hardcoded in the client > (or discovered) but the AS can tell the client where to get the token. Or > it could be done with a redirect to the token URL or the Device > Verification Code could be a the URL to poll instead. > https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 can be used for programmatic discovery of the token URL (and we add to that in the section "Discovery Metadata"). > > 3.4. Device Access Token Request > client_id, it says REQUIRED but then it states that it is to be used only > if =E2=80=9Cclient is not authenticating with the authorization server as= described > in Section 3.2.1. of [RFC6749].=E2=80=9D > I think the parameter should be optional and authentication required. > See above. > > 3.2. Device Authorization Response and 3.5. Device Access Token Respon= se > =E2=80=9CThe interval at which the client polls MUST NOT be more frequent= than > the "interval" parameter returned in the Device Authorization > Response (see Section 3.2).=E2=80=9D > =E2=80=9COPTIONAL. The minimum amount of time in seconds that the client > SHOULD wait between polling requests to the token endpoint.=E2=80= =9D > Feels like a contradiction between the parameter description and token > endpoint response. I would like to have MUST in both cases. > The next version clarifies this a bit. PTAL. > > 3.5. Device Access Token Response > I think last paragraph is better suited in the introduction section. > I'm on the fence about this suggestion, as that paragraph does relate token polling. > > 5.2. Device Trustworthiness > I think device authentication should/could be mentioned here > "Non-confidential Clients" covers that. Best, William --f403045e764c94d603055b751663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Sep 7, 2017 at 1:11 PM, Samuel Erdtman <samuel@erdtman.se&= gt; wrote:
Hi Authors

Thanks for writing this= very useful draft.

H= i Samuel,

Thanks for reviewing the draft!
=C2=A0
=

I have some review comments that I hope will be useful.
<= br>
As a general comment, has it been considered to include CoAP mappi= ngs too? it might be good to reach even more constrained devices (maybe ano= ther draft).


1.=C2=A0 Introduction
Missing newline between St= ep E and D=C2=A0
1.=C2=A0 Introduction
The bullet list with t= he polling of the client and the user authorisation is a bit hard to read, = step D comes again after E. Maybe it would be easier to read if using decim= al numbers.

(D) is referenced in = (E), I believe it's intentional.

I'll expa= nd the reference to "(step D)" to make that clear.

=
=E2=80=981.=C2=A0 Introduction=E2=80=99 and =E2=80=983.=C2=A0 Protocol=E2= =80=99
I would like to move the ascii art and the corresponding list of = steps from =E2=80=981.=C2=A0 Introduction=E2=80=99 to =E2=80=983.=C2=A0 Pro= tocol=E2=80=99 and use the terminology explained in =E2=80=982.=C2=A0 Termi= nology=E2=80=99

I'll discuss = this with my co-authors, could make sense.
=C2=A0

3.1.=C2=A0 Dev= ice Authorization Request
Is there no authentication? e.g. use of client= secret? (or Pre-Shared Key or Raw Public key as described in draft-erdtman= -ace-rpcc)
I don=E2=80=99t think client identification is enough I think= it should authenticate, at least as the recommendation.

There is no client authentication as they are publi= c clients. This is covered in the security consideration "Non-confidential Clients". = As draft is ne= arly ready to publish, I don't think we should take a reference on an I= -D that would delay our publication.
=C2=A0

3.2.=C2= =A0 Device Authorization Response
I would like to change verification_ur= i be optional. If for example the device vendor has a companion app that ap= p could easily have the verification_uri, that would simplify for the user = that would only have to enter the code. (and it could save some bytes).
=

This type of use-case is mentioned i= n the section "N= on-Browser User Interaction" if you own both the server and the client= =E2=80=93=C2=A0you can really do whatever you like as it doesn't need = to be interoperable. If this spec is useful for that case =E2=80=93=C2=A0g= reat, but I don't think we need to discuss or cater for this more than = we have.


3.2.=C2=A0 Device Authorization ResponseI think it would make sense to add an optional parameter with the token en= dpoint uri, in that way it does not have to be hardcoded in the client (or = discovered) but the AS can tell the client where to get the token. Or it co= uld be done with a redirect to the token URL or the Device Verification Cod= e could be a the URL to poll instead.

=
= https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 can be used f= or programmatic discovery of the token URL (and we add to that in the secti= on "Discovery Metadata").
=C2=A0

3.4.=C2=A0 Device Acc= ess Token Request
client_id, it says REQUIRED but then it states that it= is to be used only if =E2=80=9Cclient is not authenticating with the autho= rization server as described in Section 3.2.1. of [RFC6749].=E2=80=9D
I = think the parameter should be optional and authentication required.

See above.
=C2=A0

3.2.=C2=A0 = Device Authorization Response and=C2=A0 3.5.=C2=A0 Device Access Token Resp= onse
=E2=80=9CThe interval at which the client polls MUST NOT be more fr= equent than
=C2=A0=C2=A0 the "interval" parameter returned in = the Device Authorization
=C2=A0=C2=A0 Response (see Section 3.2).=E2=80= =9D
=E2=80=9COPTIONAL.=C2=A0 The minimum amount of time in seconds that = the client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD wait between polling re= quests to the token endpoint.=E2=80=9D
Feels like a contradiction betwee= n the parameter description and token endpoint response. I would like to ha= ve MUST in both cases.

The next version clarifies this a bit. PTAL.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

3.5.= =C2=A0 Device Access Token Response
I think last paragraph is better sui= ted in the introduction section.

= I'm on the fence about this suggestion, as that paragraph does relate t= oken polling.
=C2=A0

5.2.=C2=A0 Device Trustworthiness
I thin= k device authentication should/could be mentioned here

"Non-confidential Clients" covers that.
=C2=A0<= /div>

Best,
William

--f403045e764c94d603055b751663-- From nobody Fri Oct 20 17:28:29 2017 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 AB6BE13450A; Fri, 20 Oct 2017 17:24:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ekr@rtfm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546269.20809.14796750658767641282.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:22 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 100 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:23 -0000 Dear Rifaat Shekh-Yusef, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (1:30:00) Wednesday, Afternoon Session II 1520-1650 Room Name: Orchard size: 50 --------------------------------------------- oauth Session 2 (1:30:00) Tuesday, Afternoon Session II 1550-1750 Room Name: Sophia size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: tokbind acme sipcore ace tls core saag fud teep secevent People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: Please avoid conflict with sec area BoFs. Please avoid Monday. --------------------------------------------------------- From nobody Sat Oct 21 16:09:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CFD133B95 for ; Sat, 21 Oct 2017 16:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.795 X-Spam-Level: * X-Spam-Status: No, score=1.795 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.344, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIzG0cls0Y2Q for ; Sat, 21 Oct 2017 16:08:58 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24616133B8A for ; Sat, 21 Oct 2017 16:08:58 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id v9so25370644oif.13 for ; Sat, 21 Oct 2017 16:08:58 -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=fq7FUsQNuyQCLLWt8GL4dOmf9qNYXyt5jyEuQ/WKCWo=; b=G8Uo5CiYV9mIQ6/h3yY5G5TJ8XJiCkOleCVsrpHNFQjp9MQqipB5Yu5P3ABchUakGT 5yrhg/a+d3tllV2BErFz9353mzAGn4dTBt386R02DoOOamo2xPr8ez10UuXg3fnIjhuQ drIiCIV5ofLz6q+rpVbBVvCmg50vSX6fxZbR20jzWLFoCUGnaW2QGdeoTcchxwjCXpOY +pcjWsBXGYHYvZqOG94HcjaVDudk+BchbhpvHeROBegTSc7j/YtNGwShunfcVYfRMBL/ +ESIniq7F389Z62FEzcuQBlVVAFdlX9+gYjL3rW6Zzagzul7tqUwEx2bQPpC+hBYIi70 sruw== 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=fq7FUsQNuyQCLLWt8GL4dOmf9qNYXyt5jyEuQ/WKCWo=; b=Pwb2IEuCYQRgyqXuwrbCAJ+9BRJzpEJWFpcmNrmIU4uiJCN7iemzdyG/+N5i28hUXg PLJv7I/cVGF1027+jwAGmSfDQe8tevDkSXg+fMpFt4Meov6V05y4gMWoMUVujbS2PhfG wcIHdG25o4OBQN87eyhtQsfOWANErDVtyk4rX55Co40kPA9+GHDyR6RWK1Au5GkO7WBc 8LNJ2Kk5IO+cH12cU2AqPQliA5NsrkwFYb6A5+qU+Jtndb5ZT6w/OYkgnpEWBw9YX5CN XV0mfJFj0nivX80ORdlPIp3AtPQ2cyVumHigMDqYpODAcjDxYxdR0bR2T5mSXpVYRHqj +GwA== X-Gm-Message-State: AMCzsaWnMI+wa5KPI9prD2uesLtx/A1wdqNObSfgOUUxtGYxgFTFeGaK kOOn9id4DqnFjRC9CR588QgVWPTCsDBd6j8tmJjkAA== X-Google-Smtp-Source: ABhQp+SBE14eroFW/GSGOLvLEo08EPQb+vuUQ3tLFWrDJcRDY0IlC1sYzIsi+b17egd2E34t1AVH/cNuPpch7Yev6L8= X-Received: by 10.157.89.225 with SMTP id u33mr5438264otg.203.1508627337134; Sat, 21 Oct 2017 16:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.24.197 with HTTP; Sat, 21 Oct 2017 16:08:55 -0700 (PDT) Received: by 10.74.24.197 with HTTP; Sat, 21 Oct 2017 16:08:55 -0700 (PDT) From: Salahattin Subak Date: Sun, 22 Oct 2017 02:08:55 +0300 Message-ID: To: OAuth@ietf.org Content-Type: multipart/alternative; boundary="f4030435b8d8874620055c16ac19" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 23:08:59 -0000 --f4030435b8d8874620055c16ac19 Content-Type: text/plain; charset="UTF-8" --f4030435b8d8874620055c16ac19 Content-Type: text/html; charset="UTF-8"
--f4030435b8d8874620055c16ac19-- From nobody Thu Oct 26 17:03:56 2017 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 A31EB138B5E; Thu, 26 Oct 2017 17:03: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: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150906263563.22135.3314949761020043351@ietfa.amsl.com> Date: Thu, 26 Oct 2017 17:03:55 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:03: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 Token Binding Authors : Michael B. Jones Brian Campbell John Bradley William Denniss Filename : draft-ietf-oauth-token-binding-05.txt Pages : 30 Date : 2017-10-26 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-05 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 26 18:49:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0559913F48D for ; Thu, 26 Oct 2017 18:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09NnTdxWZQHh for ; Thu, 26 Oct 2017 18:49:14 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0090.outbound.protection.outlook.com [104.47.41.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FD413968C for ; Thu, 26 Oct 2017 18:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NITpwHexTr1nKW6mfEZxz0mhesNfN7t4gg6fevxXGLI=; b=P59dVRstk7BttCCEt6Fi4C0z3SE9HAMyA75RYTJb+QFVvv2vAj7l7XD04RyJp0lPOZQwK7Y4voNtGQ3IkugqY3UCfeTbmMxsQ1O2i2WOesZmfMiql1kr4V2nnD7ka4ApjeQ+atC8yMc7MZYA9SCVr1kRu9/4OBMP7/BEqFnDfMk= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0757.namprd21.prod.outlook.com (10.173.192.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Fri, 27 Oct 2017 01:49:12 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0197.006; Fri, 27 Oct 2017 01:49:12 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth and OpenID Connect Token Binding specs updated Thread-Index: AdNOwS8Q2pa6FtsSQ0mfAarSebdK2A== Date: Fri, 27 Oct 2017 01:49:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-10-26T18:49:11.4969643-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0757; 6:mcSZN2v321dffTzGadSe6bVhF09GKbqyO44Ri5XalFj9zuVabdm9yH9Op14KsJnMGq8i3U2l0of3EEAWpz+BjwZqNlyiPzxISau3XG53yN7qKNKuEhgyWYgiHikKeHYWnvoGS1tiqqBDiI4ubZ9GyiEuVPfnsFT6+cCk1GlZ7I1+sYbV8N68ecoN5wAeH9eUjn6OY34ejLpxrUNsTqGO3qUsumfMsXWCLqgEUBelfmXqMJfr6O/yhXAMsb0EcYFAOuJT/vxa/hmQCG0fYK5ahiyiNXTIh7V1AcrOiZ/zYqdQ/BkqILY5Ayi0Pcs6dKfqJdUrIiq+BUPyaOWMyizQVh6MafNoPsyKKzKV42wk4n4=; 5:FLx3bcuCYxxaZ4rOcysz8ZX+QvvwpIbO4+4mFvZsrBbv/KXzLSh04kxOb2uBaGHifrxOziMOsFB5FCnTIxFTUqSEWXaRBuip/3yIW3Nl8+bh8MwGZtksHabmoTExxWGMOjLEVy3+sVB6uTXkNGQePw8EEGovynPajbRu8JDlQew=; 24:XSyczmv2vhTdCNURiUR9uaFPvsSbuKv81Fri733j453mWqwtV2F+hFQajDSuCYrwHoAivMBmoKJ+1eLg4eCWF5wNLAWt/TeGfMuj7d+FsC8=; 7:OgdtUeE3LDODagqiJ83zn0+Xg+AmeC2ryixe/NAcY0uGgYbxzZQ969vA06jIE5bngAa8b0+5lAIoBzkea0Tt8MyuX5OoN0JoEt27iDS7M1iA0yul3R7Pbg26wErO5Jd7OHmk8bzbez2f9g7q1FYBE0gd8Vvp20ueXC2e64jiznSZDBQSeVPuLf7UEgzcVGku+OOXQXn8+tD6qLADvrWLRgPD9EOu7Rf/T7On18JHJnK+PXKZQV199ytPwM297X1N x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7e5ff90a-c771-4bda-31b9-08d51cdcec77 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0757; x-ms-traffictypediagnostic: CY4PR21MB0757: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155)(21532816269658); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231020)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0757; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(209900001)(47760400005)(189002)(199003)(99286003)(6306002)(2906002)(55016002)(236005)(54896002)(53936002)(9686003)(7110500001)(10090500001)(189998001)(68736007)(7736002)(3280700002)(2900100001)(33656002)(74316002)(606006)(8990500004)(3660700001)(15650500001)(6506006)(77096006)(102836003)(6116002)(101416001)(6916009)(790700001)(72206003)(966005)(478600001)(10290500003)(97736004)(8936002)(25786009)(5660300001)(6436002)(2420400007)(5640700003)(14454004)(2351001)(7696004)(53376002)(22452003)(106356001)(8676002)(1730700003)(86612001)(105586002)(54356999)(86362001)(81156014)(5630700001)(50986999)(2501003)(81166006)(316002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0757; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504C66C604809958CEDB57BF55A0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e5ff90a-c771-4bda-31b9-08d51cdcec77 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 01:49:12.7609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0757 Archived-At: Subject: [OAUTH-WG] OAuth and OpenID Connect Token Binding specs updated X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 01:49:16 -0000 --_000_CY4PR21MB0504C66C604809958CEDB57BF55A0CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth 2.0 Token Binding specification has been updated to enable Token = Binding of JWT Authorization Grants and JWT Client Authentication. The dis= cussion of phasing in Token Binding was improved and generalized. See the = Document History section for other improvements applied. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-token-binding-05 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-token-binding-05.html An update to the closely-related OpenID Connect Token Bound Authentication = 1.0 specification was also simultaneously published. Its discussion of pha= sing in Token Binding was correspondingly updated. The OpenID Connect Token Binding specification is available in HTML and tex= t versions at: * http://openid.net/specs/openid-connect-token-bound-authentication-1_0= -02.html * http://openid.net/specs/openid-connect-token-bound-authentication-1_0= -02.txt Thanks to Brian Campbell for doing the bulk of the editing for both sets of= revisions. -- Mike P.S. This note was also published at http://self-issued.info/?p=3D1740 and= as @selfissued. --_000_CY4PR21MB0504C66C604809958CEDB57BF55A0CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth 2.0 Token Binding specification has been u= pdated to enable Token Binding of JWT Authorization Grants and JWT Client A= uthentication.  The discussion of phasing in Token Binding was improve= d and generalized.  See the Document History section for other improvements applied.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

An update to the closely-related OpenID Connect Toke= n Bound Authentication 1.0 specification was also simultaneously published.=   Its discussion of phasing in Token Binding was correspondingly updat= ed.

 

The OpenID Connect Token Binding specification is av= ailable in HTML and text versions at:

 

Thanks to Brian Campbell for doing the bulk of the e= diting for both sets of revisions.

 

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

 

P.S.  This note was also published at http://self-issued.info/?p=3D1740 and as @selfissued.

--_000_CY4PR21MB0504C66C604809958CEDB57BF55A0CY4PR21MB0504namp_-- From nobody Fri Oct 27 15:29:39 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC45513F5A9; Fri, 27 Oct 2017 15:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI8ZozI9ZypW; Fri, 27 Oct 2017 15:29:36 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0099.outbound.protection.outlook.com [104.47.37.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DF7138DE1; Fri, 27 Oct 2017 15:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UbcBffLafhzTQBBbvRR2lMWErZZtspI8GwIOKA46+fA=; b=j4gfoeprng4BXtLcC+fPb/J/4wURapr2oeLuaPkH6SpIY/mErxn1Qsk3IEcmpjSw5wW0F+isgTXTU0hOfeamWNBiGAL/RgNpStaYak0k/MQqxHv0525Wg39eAdwEvtZwf+12/eeD6mupdq55GrLmMh6pXj4/ATrukBVJAwva3e0= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Fri, 27 Oct 2017 22:29:35 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0197.006; Fri, 27 Oct 2017 22:29:35 +0000 From: Mike Jones To: Brian Carpenter , "gen-art@ietf.org" CC: "oauth@ietf.org" , "draft-ietf-oauth-discovery.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-oauth-discovery-07 Thread-Index: AQHTOyo9I1g5CQpaC06Nc4/g9OMn56L4b67Q Date: Fri, 27 Oct 2017 22:29:34 +0000 Message-ID: References: <150691307049.28713.16129351135750922617@ietfa.amsl.com> In-Reply-To: <150691307049.28713.16129351135750922617@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-10-27T15:29:29.1806411-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:8::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0856; 6:eBW4le2zqff7pPeLAnPbnT20/D1A05rFt/usb4AGK9XdL9790sw2ofUgDGU0CHhfFWfTZuyMGEmkHGco94RJoWFovjJ0yXvyzisjZd0Q2h2igyf2AodHLK0GHeTY14SGRcH3/uW+jsENFSiXvBwmjGZI6DjWnXXudNTaQfuQ2KraWaq6iow9OMJZMdovQst5gSCvqUOkVl0UiJ6xPkwqALzVSyOheWiqz3NLDlOKys6iqYkJOX/tcO7w7qe3jxodwpMMf3qNlvBTq7XeHBz8AnsD1YokbP8BW76VTF9iD+RmUlW9yxFc1yEkRVfSL7uOuTulTZ+fh+2DmdMUkWosldZ+Kz34F4YdeANKuFU3BLs=; 5:m+ZN4RojrjWzkuxJxFXKQGyPIQvVbSrXQiGUPES5P33ibgJ4gn4+l79ZVQTnx933qACqp8FNPMXswI55pGhWni9HtOzUEC5NmT1xfKfTjXFk4i/JBK8YhNEm+U8eMgxel6afDjtsOnspRy6C13IegxEIoZtAzJJ7g+DVjxKuPFw=; 24:NDhZpLOPvRIsONoDnA8t9MB8iimpOSsLeungi7+UNc2j2ECS3AC3QhME+E/Sdy5+jmvrLLeoSBSgPJimue4qwHBRqTW8aLWZkc/G+9GXAk4=; 7:2iwhgqDLaYBRxFMxOz1+vTrLquj3d0gUr8a5JOcuBJWQPMfPLxnZUafNHhtNtVt7179F1KjoeDdMp70WiNLTJiTpUlisjkNY56h0S2+IXQLe6UjfVO5DjVIcLgLGyBx2Yzch+c45oCw+VpqBSxgv8bvEp+4tPz+ui6Wt9Bqio7vus1tCq39VKOAMvkMmRGEEs9ScFfztg2qvKf7tMH/JjW3hLssVk7M8VuvJvbAcSxdepkM1jDrXIGX46cffPiqT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f71b707c-1957-4870-9fcd-08d51d8a3390 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0856; x-ms-traffictypediagnostic: CY4PR21MB0856: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231020)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0856; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0856; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(47760400005)(199003)(377424004)(13464003)(189002)(51914003)(2900100001)(54356999)(50986999)(10290500003)(25786009)(5660300001)(33656002)(14454004)(8676002)(55016002)(7696004)(72206003)(2906002)(189998001)(74316002)(106356001)(10090500001)(7736002)(76176999)(3660700001)(3280700002)(53546010)(101416001)(39060400002)(105586002)(478600001)(77096006)(97736004)(4326008)(229853002)(230783001)(6506006)(102836003)(305945005)(6116002)(6246003)(110136005)(6436002)(8936002)(53936002)(316002)(54906003)(81166006)(99286003)(86362001)(6306002)(81156014)(9686003)(8990500004)(2501003)(2950100002)(86612001)(68736007)(22452003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0856; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f71b707c-1957-4870-9fcd-08d51d8a3390 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 22:29:34.8750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0856 Archived-At: Subject: Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-discovery-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 22:29:39 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCB2YWxpZGF0aW5nIHRoZSBleGFtcGxlcywgQnJpYW4h DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBDYXJwZW50ZXIgW21h aWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KU2VudDogU3VuZGF5LCBPY3RvYmVy IDEsIDIwMTcgNzo1OCBQTQ0KVG86IGdlbi1hcnRAaWV0Zi5vcmcNCkNjOiBvYXV0aEBpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnkuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBHZW5h cnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wNw0KDQpS ZXZpZXdlcjogQnJpYW4gQ2FycGVudGVyDQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQpHZW4tQVJU IExhc3QgQ2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDcNCg0KSSBh bSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVy YWwgQXJlYSBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMg YmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy4NCg0KRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdCA8aHR0cDov L3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQoNCkRv Y3VtZW50OiBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wNy50eHQNClJldmlld2VyOiBCcmlh biBDYXJwZW50ZXINClJldmlldyBEYXRlOiAyMDE3LTEwLTAyDQpJRVRGIExDIEVuZCBEYXRlOiAy MDE3LTEwLTA5DQpJRVNHIFRlbGVjaGF0IGRhdGU6IA0KDQpTdW1tYXJ5OiBSZWFkeQ0KLS0tLS0t LS0NCg0KQ29tbWVudDoNCi0tLS0tLS0tDQoNCkFzIGZhciBhcyBteSBjb21wZXRlbmNlIGdvZXMs IEkgaGF2ZSBubyBpc3N1ZXMgd2l0aCB0aGlzIGRyYWZ0Lg0KSnVzdCBmb3IgZnVuLCBJIGNoZWNr ZWQgdGhhdCB0aGUgSlNPTiBleGFtcGxlIHdvcmtzIGFzIHRoZSB2YWx1ZSBvZiBhIEdSQVNQIG9i amVjdGl2ZSAoZHJhZnQtaWV0Zi1hbmltYS1ncmFzcCkgd2l0aCB0aGUgR1JBU1AgcHJvdG90eXBl IGNvZGUuIEFuZCB5ZXMsIG9mIGNvdXJzZSBpdCBkb2VzLCBzbyB3ZSBjb3VsZCBtYXAgT0F1dGgg b3ZlciB0aGUgQU5JTUEgZGlzY292ZXIvc3luY2hyb25pemUgbW9kZWwgaWYgd2Ugd2FudGVkLg0K DQpGV0lXIHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBlcnJvcnMgaW4gdGhlIHNoZXBoZXJkJ3Mgd3Jp dGV1cDoNCg0KPiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHJlcXVlc3QgYW55IGFjdGlvbnMgYnkg SUFOQS4NCj4NCj4gMTgpIExpc3QgYW55IG5ldyBJQU5BIHJlZ2lzdHJpZXMgdGhhdCByZXF1aXJl IEV4cGVydCBSZXZpZXcgZm9yIGZ1dHVyZSANCj4gYWxsb2NhdGlvbnMuIFByb3ZpZGUgYW55IHB1 YmxpYyBndWlkYW5jZSB0aGF0IHRoZSBJRVNHIHdvdWxkIGZpbmQgDQo+IHVzZWZ1bCBpbiBzZWxl Y3RpbmcgdGhlIElBTkEgRXhwZXJ0cyBmb3IgdGhlc2UgbmV3IHJlZ2lzdHJpZXMuDQo+DQo+IE5v bmUuDQoNCldyb25nLCB0aGVyZSBhcmUgZXh0ZW5zaXZlIElBTkEgY29uc2lkZXJhdGlvbnMgYW5k IGEgcmVxdWlyZW1lbnQgZm9yIG11bHRpcGxlIERlc2lnbmF0ZWQgRXhwZXJ0cy4NCg0KPiBUaGVy ZSBpcyBubyB0ZXh0IGluIGZvcm1hbCBsYW5ndWFnZXMgaW4gdGhlIGRvY3VtZW50LiANCg0KTWF5 YmUgbm90LCBidXQgdGhlcmUgaXMgYSBKU09OIGV4YW1wbGUgKHdoaWNoIGFzIG5vdGVkIGFib3Zl IHNlZW1zIHRvIGJlIGZpbmUpLg0KDQotLQ0KDQoNCg== From nobody Mon Oct 30 13:02:41 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E081613FB3F for ; Mon, 30 Oct 2017 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c6PrNlmsBhn for ; Mon, 30 Oct 2017 13:02:38 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 A297013FB39 for ; Mon, 30 Oct 2017 13:02:38 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id l24so12567002pgu.11 for ; Mon, 30 Oct 2017 13:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=A+9X6cqX9+tpHNO+UxXUhUdvLHHkw3+fOGP3rhk36sY=; b=meZjDqZKpslTV6r6QUJbHikt9ROlEkql6fACUQnKTz0vOr+/wot5nO4RNt9VbsOjxN oMudf5rOJhslOSo9uGuBH5vkZKP4/gZAHeRIuyrKYIcLvJVaCawT6Kfuv/kG6S2yoymj 9ZjA7xjEF8UExZSAcDTiPoG3aqbyxGll+ouXAK5NnYP1qxOAcGpHzDtp74iYS+cFrrtE GTxZFBbWlDVlx11S2IeUuHHob+wuIYrxJFdnY8aJIxi6dQbx539O/m2eDdVwsC1JWz+v s7Phnw9Qu5MMzQES1+P5GPZP9PoUSJ/wGAvlk8b8ZuQbrolFmXdjzZPxsV9UU2ACWXjF lTpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=A+9X6cqX9+tpHNO+UxXUhUdvLHHkw3+fOGP3rhk36sY=; b=EpYUYiEKVKv1ZwfAKw0vRW3ZpKgOYcgCtPFM2eFfl6WxTdn1+hwzTijDutv3Irn8YT ugjsaHr5N35vAN+hQrU7qIYnYjU0b+eQLVIyHYbHUAsyyzvdnYifwVpKhNBUCzyRIapo WwpxaRT7cSCb73JMaG+nC31Z/CvMVaH4bSowk34sJVuaLKAa2tK3c7GUK+/KmGES0EGN Q94RL8rYnDSVVcteQWTJ025PhmwIOKhgYdUQNppr7LXNvwNsaikEarhBaON00Ee0vb28 92WDs+SdVbsaDxGt/iAwhtRLkPtaIr8MvL7zJhqD+PO73Elcm8fd/WczLG5XiAO5Tycf hoEQ== X-Gm-Message-State: AMCzsaULH5JYKxpcUZ/8IOrzebmiOCpdZIsV7jCiMKwuG76z27ugDkgq s92KFuKpsf+hGkU0Mvds3UNeEtgXsfvCiI3nTApqSS20TXs= X-Google-Smtp-Source: ABhQp+QcBLYHFjefvU0P33ejUiM3+HjChhkGhyrQhsQQ5gP4YEuP5AqCQJaLgFArckwA2xxibYc0K2r1jxfujAtUhls= X-Received: by 10.159.214.149 with SMTP id n21mr8459206plp.336.1509393757879; Mon, 30 Oct 2017 13:02:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.199 with HTTP; Mon, 30 Oct 2017 13:02:37 -0700 (PDT) In-Reply-To: References: <150939333261.7744.6308016285582758380.idtracker@ietfa.amsl.com> From: Samuel Erdtman Date: Mon, 30 Oct 2017 21:02:37 +0100 Message-ID: To: "" , ace Content-Type: multipart/alternative; boundary="94eb2c1dc038c3d62c055cc91ecb" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-erdtman-ace-rpcc-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 20:02:41 -0000 --94eb2c1dc038c3d62c055cc91ecb Content-Type: text/plain; charset="UTF-8" We have published a new version of the draft-erdtman-ace-rpcc * Addresses review comments form Brian Campbell (thank you Brian). * Adds language about dynamic registration. Thoughts, comments? ---------- Forwarded message --------- From: Date: Mon, 30 Oct 2017 at 20:55 Subject: New Version Notification for draft-erdtman-ace-rpcc-02.txt To: Ludwig Seitz , Samuel Erdtman A new version of I-D, draft-erdtman-ace-rpcc-02.txt has been successfully submitted by Samuel Erdtman and posted to the IETF repository. Name: draft-erdtman-ace-rpcc Revision: 02 Title: Raw-Public-Key and Pre-Shared-Key as OAuth client credentials Document date: 2017-10-30 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-erdtman-ace-rpcc- 02.txt Status: https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/ Htmlized: https://tools.ietf.org/html/draft-erdtman-ace-rpcc-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-erdtman-ace- rpcc-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-erdtman-ace-rpcc-02 Abstract: This document describes Transport Layer Security (TLS) authentication using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth client authentication. Although defined for TLS the mechanisms are equally applicable for DTLS. 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 --94eb2c1dc038c3d62c055cc91ecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have published a new version of the draf= t-erdtman-ace-rpcc

* Addresses review comments form Brian Camp= bell (thank you Brian).
* Adds language about dynamic registration= .

Thoughts, comments?


---------- Forwarded= message ---------
From: <internet-drafts@ietf.org>
Date: Mon, 30 Oct 2= 017 at 20:55
Subject: New Version Notification for draft-erdtman-ace-rpc= c-02.txt
To: Ludwig Seitz <ludwig.seitz@ri.se>, Samuel Erdtman <erdtman@spotify.com>
<= /div>


A new version of I-D, draft-erdtman-ace-rpcc-02.txt
has been successfully submitted by Samuel Erdtman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-erdtman-ace-rpcc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Raw-Public-Key and Pre-Shared-Key = as OAuth client credentials
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-erdtman-ace-rpc= c-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://too= ls.ietf.org/html/draft-erdtman-ace-rpcc-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-erdtman-ace-rpcc-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-erdtman-ace-rpcc-02

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) authent= ication
=C2=A0 =C2=A0using Raw-Public-Key and Pre-Shared-Key as new mechanisms for = OAuth
=C2=A0 =C2=A0client authentication.=C2=A0 Although defined for TLS the mech= anisms are
=C2=A0 =C2=A0equally applicable for DTLS.




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


--94eb2c1dc038c3d62c055cc91ecb-- From nobody Mon Oct 30 14:11:47 2017 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 E9BC913FB89; Mon, 30 Oct 2017 14:11:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939790492.7861.6165797123100068511@ietfa.amsl.com> Date: Mon, 30 Oct 2017 14:11:44 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:11:45 -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 Device Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-07.txt Pages : 17 Date : 2017-10-30 Abstract: This OAuth 2.0 authorization flow for browserless and input constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-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 Mon Oct 30 14:24:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BC013FBB6 for ; Mon, 30 Oct 2017 14:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WNv0J8bK3OD for ; Mon, 30 Oct 2017 14:24:10 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B2813FB92 for ; Mon, 30 Oct 2017 14:24:07 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id w2so12910135ywa.9 for ; Mon, 30 Oct 2017 14:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FPoK4cSeSRh+gZa05I0Fws29N5ZCGCDl8rTLvSdLp4A=; b=hImpSMpzqNRNfO1sU2JjkuUFnzxbwFwxe6SkMrIWEo+VjsF4NR5xhg0PMp1xKPgr0I +1ZqWB0ZPsGHygIcBwVnCqckKT1iVtVT02mssQl24W/caqToG1+6Lwn6VzaHCEK1D75j ZEMmznV8IwvPWhBYZ1/tbCzUXUIFkCKM48RatRYQt2swPOIhED/54VtNaS97ex5oRq/y s/lLR0Q88+IuE23J69Zqy4DL8+DPu2jsIRrriMEyx76TxXdzkH+o/XaL+2lnDcSfjWmN Uy1/YNvcfv4wjS+FOQmAW3Rlf32a1UWaPEWHMgQbWy6zftLy8dfHXdiECEMXL8YoeF6v +myw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FPoK4cSeSRh+gZa05I0Fws29N5ZCGCDl8rTLvSdLp4A=; b=Ni6Epeja7FLtHvbFeqPdUa2m+CHxmlKCK94Ve36Z4dJ/7IL0JaKVpE+q2hpkHCgjzl fdVI1Jq10fdwQuCXoqammFFA9tsjrjp3Ma9FdG3KnYGcWvP19TYtPcjRL4d8QromPwFc Cdms2Q6uaz+bDEXj3dan3UU46iXb5UA2kcc6Z6TCsZxlsUiT11CZZMz5flefqrBtJlQH 66Hny5gRb/HBv1SxAxw0N8rHwieo4T1VHfmx7Ah2rZ1gNWige11lWpCu+hwxiN7hclrT DaUkLom+sNVEVeIcg/uoNc5qym+tUd5+rpIExyKMJKNseMCO5T1ejuweYIE/dXuSPV2H kMRg== X-Gm-Message-State: AMCzsaVxa1diOAC0GO/x84gZHzf06eSpnMCD2rr+nxQ9nOO6r85UCcMj vBscJHXuVroRWi6xXZBu6roH9a/zfGGLVi2WRSzVSZMm X-Google-Smtp-Source: ABhQp+QXCjs5EAukKGCkKEOEcIIOL3QPvEAsr6yC3DBOwfCPfsJ9FMMt5/m5xI7TXQpsK0C2nWeSFKk4+j9G7RD+aIQ= X-Received: by 10.37.36.80 with SMTP id k77mr6418956ybk.398.1509398645604; Mon, 30 Oct 2017 14:24:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.122.72 with HTTP; Mon, 30 Oct 2017 14:23:45 -0700 (PDT) In-Reply-To: <150939790492.7861.6165797123100068511@ietfa.amsl.com> References: <150939790492.7861.6165797123100068511@ietfa.amsl.com> From: William Denniss Date: Mon, 30 Oct 2017 14:23:45 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="001a113d4518196f63055cca427f" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:24:13 -0000 --001a113d4518196f63055cca427f Content-Type: text/plain; charset="UTF-8" As listed in the doc, changes include: -07 o Replaced the "user_code" URI parameter optimization with verification_uri_complete following the IETF99 working group discussion. o Added security consideration about spying. o Required that device_code not be shown. o Added text regarding a minimum polling interval. I believe this draft resolves all outstanding issues, and that the document is ready to re-start the WGLC. Thank you to everyone who contributed to the discussion at the IETF99 meeting in Prague, and on the list since then. We had some robust discussions, and I feel like we've landed in a good place. Best, William On Mon, Oct 30, 2017 at 2:11 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Device Flow for Browserless and Input > Constrained Devices > Authors : William Denniss > John Bradley > Michael B. Jones > Hannes Tschofenig > Filename : draft-ietf-oauth-device-flow-07.txt > Pages : 17 > Date : 2017-10-30 > > Abstract: > This OAuth 2.0 authorization flow for browserless and input > constrained devices, often referred to as the device flow, enables > OAuth clients to request user authorization from devices that have an > Internet connection, but don't have an easy input method (such as a > smart TV, media console, picture frame, or printer), or lack a > suitable browser for a more traditional OAuth flow. This > authorization flow instructs the user to perform the authorization > request on a secondary device, such as a smartphone. There is no > requirement for communication between the constrained device and the > user's secondary device. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-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/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113d4518196f63055cca427f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As listed in the doc, changes include:

= 
   -07

   o  Replaced the "user_code" URI parameter optimization with
      verification_uri_complete following the IETF99 working group
      discussion.
   o  Added security consideration about spying.
   o  Required that device_code not be shown.
   o  Added text regarding a minimum polling interval.


I believe this draft resolve= s all outstanding issues, and that the document is ready to re-start the WG= LC.

Thank you to everyone who contributed to the d= iscussion at the IETF99 meeting in Prague, and on the list since then. We h= ad some robust discussions, and I feel like we've landed in a good plac= e.

Best,
William


On Mon, Oct 30, 2017= at 2:11 PM, <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Will= iam Denniss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-device-flow-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-30

Abstract:
=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-oauth-device-flow-07
https://datatracker.ietf.org/d<= wbr>oc/html/draft-ietf-oauth-device-flow-07

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


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

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

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

--001a113d4518196f63055cca427f-- From nobody Mon Oct 30 14:30:48 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887C013FBBE for ; Mon, 30 Oct 2017 14:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCv0AeUxfYoG for ; Mon, 30 Oct 2017 14:30:30 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31E913FBB7 for ; Mon, 30 Oct 2017 14:30:29 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id i133so9059106vke.9 for ; Mon, 30 Oct 2017 14:30: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=mUT/Du92e67ZHGvNfYCr0aC7w5xl22sdlb16UKm8c68=; b=Iy/Z3Q9JTV+KH5qrQZiBAu8G37N6b8enHA5Y6UwmABZCYBRKmDiTuRNZZ61K05/USz IxwwbzzRuZJ2A7QKIvH2MyCH1TOWxj0FnUsUcByyexCcdz1AUI7NxhgVlJzCFakgT6yQ oQYK0HTEijGdNcPMOKgjDrvTokwIbCABTkaGFhbU2yId5oZ6mS/7LOOxSZj2NrcfLvJW +Ogdb+XhCbr4rNe9iwLuJi95WbBTYNHn2H2lhHJyezrhLOQn7Qe7mnMzctibrdVLITia Wyt4E21yvJRY61y41uEW60X6SKkpto1zcrDh2aewh3h2huYeYdm3nDptEABj9N/NS6nl dt0Q== 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=mUT/Du92e67ZHGvNfYCr0aC7w5xl22sdlb16UKm8c68=; b=QNjKQ6qMCzu7JU1qhypvK3OwKFFl75+umslPtMw/UXGPVpTE6SOOtZrTTPHB/JbYlt uSZZnW7GKloq29YyzykhkD5UYvRYsLE/VWeAfaCCgMMZ/SGstkFitG2yUwX5aWohWLjT IeZrrQ7Yc/JXt4Wo4+fXvp6x8YVhJINuFqd75vdAz7FDBPvh9yc2XSxVcQ3VSwIMX81j jjifCmh5bEx5aaBq15IdSv7fEzaAPZcQsAf+MSMwVmPRyW8nyWTi+FwkHuf1rgaxpaBC J5bqHRnmn6bZ6JIti8rDldB8/esSO4oXZTJBkC2HbYt73YeMtHhiHzzqh64A97QfRXCS 3cPQ== X-Gm-Message-State: AMCzsaWQ+e3wndcDXe0MtK6C95FgpFb1CwA4nWOM9DKhwt0YCnIJGP6o WdlUHNhT3PJXtTaqx3xO20ByuUYyWz4c4bHHMKRj3aA0 X-Google-Smtp-Source: ABhQp+RZc1EnWhupr94wHXVJnLHlZfW+xh1GZ2I+umVCtolxuGYs79a2b9qSe0zohBrPT958uZUruohasSgTK0cuN1o= X-Received: by 10.31.183.21 with SMTP id h21mr8045122vkf.60.1509399028621; Mon, 30 Oct 2017 14:30:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.68.162 with HTTP; Mon, 30 Oct 2017 14:30:28 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Mon, 30 Oct 2017 17:30:28 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a1143a07aece8ed055cca58aa" Archived-At: Subject: [OAUTH-WG] IETF100 Draft Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:30:31 -0000 --001a1143a07aece8ed055cca58aa Content-Type: text/plain; charset="UTF-8" All, We have just uploaded a draft agenda for the coming OAuth meetings: https://datatracker.ietf.org/meeting/100/materials/agenda-100-oauth/ Please, take a look and let us know if you have any comments or if we missed anything. Regards, Rifaat & Hannes. --001a1143a07aece8ed055cca58aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We have just uploaded a draft agen= da for the coming OAuth meetings:

Please, take a look and let us know if you have any comments or if we mis= sed anything.

Regards,
=C2=A0Rifaat &= ; Hannes.

--001a1143a07aece8ed055cca58aa--