From nobody Fri Jan 2 07:01:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744411A878B for ; Fri, 2 Jan 2015 07:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGDHVtXaSgPF for ; Fri, 2 Jan 2015 07:01:33 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A901A8788 for ; Fri, 2 Jan 2015 07:01:29 -0800 (PST) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP; 02 Jan 2015 16:01:27 +0100 X-IronPort-AV: E=Sophos;i="5.07,684,1413237600"; d="scan'208";a="593064914" Received: from unknown (HELO qeo40064.de.t-online.corp) ([10.224.209.65]) by s4de8nsazdfe010.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 02 Jan 2015 16:01:27 +0100 Received: from QEO00410.de.t-online.corp (10.224.209.110) by QEO40065.de.t-online.corp (10.224.209.65) with Microsoft SMTP Server (TLS) id 8.3.377.0; Fri, 2 Jan 2015 16:01:24 +0100 Received: from QEO00411.de.t-online.corp (10.224.209.111) by QEO00410.de.t-online.corp (10.224.209.114) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 2 Jan 2015 16:01:24 +0100 Received: from QEO00411.de.t-online.corp ([fe80::204f:5580:6b52:2397]) by QEO00411.de.t-online.corp ([fe80::204f:5580:6b52:2397%12]) with mapi id 15.00.0995.031; Fri, 2 Jan 2015 16:01:24 +0100 From: "Ebling, Sebastian" To: "OAuth@ietf.org" Thread-Topic: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 Thread-Index: AQHQGI1V40ObtTuxmkq9P1RmjhaELJym3NIAgAYViNA= Date: Fri, 2 Jan 2015 15:01:23 +0000 Message-ID: <18377bd2bfda4497918a529161e6089b@QEO00411.de.t-online.corp> References: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> In-Reply-To: <1155894743.2328533.1419875176762.JavaMail.yahoo@jws10672.mail.bf1.yahoo.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.224.192.139] x-esetresult: clean, is OK x-esetid: ADA63A3EB8F2F1ECF8EB65 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/S1aWhtAwskE7o8m6FML4SSQgWFk Subject: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 15:01:36 -0000 SGVsbG8sDQoNClRoZXJlIGlzIGEgbGl0dGxlIHR5cG8gaW4gU2VjdGlvbiAzLjIuMjoNClJlcGxh Y2UgIlRoZSBVUkwgZm9yIGZvciBhIGRvY3VtZW50IiB3aXRoICJUaGUgVVJMIGZvciBhIGRvY3Vt ZW50Ii4NCg0KDQpTZWN0aW9uIDMuIGNvbnRhaW5zDQoiMi4gIFNlcnZlciByZXNwb25kcyB3aXRo IGEgc3VjY2Vzc2Z1bCBhdXRoZW50aWNhdGlvbi4NCg0KICAgSW4gdGhlIGNhc2Ugd2hlcmUgYXV0 aG9yaXphdGlvbiBmYWlscyB0aGUgc2VydmVyIHNlbmRzIGFuIGVycm9yDQogICByZXN1bHQsIHRo ZW4gY2xpZW50IE1VU1QgdGhlbiBzZW5kIGFuIGFkZGl0aW9uYWwgbWVzc2FnZSB0byB0aGUNCiAg IHNlcnZlciBpbiBvcmRlciB0byBhbGxvdyB0aGUgc2VydmVyIHRvIGZpbmlzaCB0aGUgZXhjaGFu Z2UuIg0KVGhlcmUgaXMgYSBzd2l0Y2ggYmV0d2VlbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9y aXphdGlvbi4gRXZlbiBpZiB0aGUgYWNjZXNzIHRva2VuIHJlcHJlc2VudHMgYXV0aG9yaXphdGlv biBpbmZvcm1hdGlvbiBJIHN1Z2dlc3QgdG8gd3JpdGUgIkluIHRoZSBjYXNlIHdoZXJlIGF1dGhl bnRpY2F0aW9uIGZhaWxzIiBiZWNhdXNlIGl0IGlzIG1vcmUgY29uc2lzdGVudCBoZXJlLg0KDQpT ZWN0aW9uIDMuMi4yLiBpbnRyb2R1Y2VzICJvYXV0aC1jb25maWd1cmF0aW9uIiwgdGhlIGV4YW1w bGUgaW4gc2VjdGlvbiA0LjMgdXNlcyAib3BlbmlkLWNvbmZpZ3VyYXRpb24iLg0KDQpSZWdhcmRz DQoNClNlYmFzdGlhbiBFYmxpbmcNCg0KDQpWb246IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQmlsbCBNaWxscw0KR2VzZW5kZXQ6IE1vbnRhZywg MjkuIERlemVtYmVyIDIwMTQgMTg6NDYNCkFuOiBvYXV0aEBpZXRmLm9yZw0KQmV0cmVmZjogUmU6 IFtPQVVUSC1XR10gRndkOiBba2l0dGVuXSBXR0xDIG9mIGRyYWZ0LWlldGYta2l0dGVuLXNhc2wt b2F1dGgtMTgNCg0KTm8gb3RoZXIgY29tbWVudHMgb24gdGhpcz8gwqBBbnkgIkl0J3MgcmVhZHkg dG8gZ28uIj8NCg0KT24gTW9uZGF5LCBEZWNlbWJlciAxNSwgMjAxNCA5OjM0IEFNLCBCZW5qYW1p biBLYWR1ayA8a2FkdWtATUlULkVEVT4gd3JvdGU6DQoNCkhpIGFsbCwNCg0KVGhlcmUgbWF5IGJl IHNvbWUgaW50ZXJlc3RlZCBwYXJ0aWVzIG92ZXIgaGVyZTsgcGxlYXNlIGZlZWwgZnJlZSB0byBj aGltZQ0KaW4gb24gdGhpcyBXR0xDIG92ZXIgb24gdGhlIGtpdHRlbiBsaXN0Lg0KDQotQmVuDQoN Ci0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRGF0ZTogTW9uLCAxNSBE ZWMgMjAxNCAxMjoxNDozMCAtMDUwMA0KRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQE1JVC5F RFU+DQpUbzoga2l0dGVuQGlldGYub3JnDQpDYzoga2l0dGVuLWNoYWlyc0B0b29scy5pZXRmLm9y Zw0KU3ViamVjdDogW2tpdHRlbl0gV0dMQyBvZiBkcmFmdC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRo LTE4DQoNClRoaXMgbWVzc2FnZSBiZWdpbnMgdGhlIGZvdXJ0aCBXb3JraW5nIEdyb3VwIExhc3Qg Q2FsbCAoV0dMQykgb2YgIkEgc2V0IG9mDQpTQVNMIE1lY2hhbmlzbXMgZm9yIE9BdXRoIiA8ZHJh ZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0xOC50eHQ+LsKgIER1ZSB0bw0KdGhlIG92ZXJsYXAg b2YgdGhlIGxhc3QgY2FsbCBwZXJpb2Qgd2l0aCBob2xpZGF5cywgdGhlIGR1cmF0aW9uIG9mIHRo ZQ0KV0dMQyBpcyBleHRlbmRlZCB0byBmb3VyIHdlZWtzLCBzbyB0aGUgV0dMQyB3aWxsIGVuZCBv biAxMiBKYW51YXJ5IDIwMTUuDQpUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0xOA0KDQpC ZWNhdXNlIHRoZSBjaGFuZ2VzIGJldHdlZW4gLTE1IGFuZCAtMTggaW52b2x2ZSBiZWhhdmlvciBj aGFuZ2VzLA0KaW5jbHVkaW5nIGNoYW5nZXMgcmVnYXJkaW5nIGRpc2NvdmVyeSBhbmQgZHluYW1p YyByZWdpc3RyYXRpb24sIHRoZSBDaGFpcnMNCmRlY2lkZWQgdG8gaXNzdWUgYW4gYWRkaXRpb25h bCBsYXN0IGNhbGwuDQoNClBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBzZW5kIGNvbW1l bnRzIHRvIHRoZSBXb3JraW5nIEdyb3VwDQptYWlsaW5nIGxpc3QgPCBraXR0ZW4gYXQgaXRlZi5v cmcgPiBvciB0aGUgY28tY2hhaXJzIDwga2l0dGVuLWNoYWlycw0KYXQgdG9vbHMuaWV0Zi5vcmcg PiBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgV0dMQy7CoCBBbnkgYW5kIGFsbCBjb21tZW50cw0Kb24g dGhlIGRvY3VtZW50IGFyZSBzb3VnaHQgaW4gb3JkZXIgdG8gYWNjZXNzIHRoZSBzdHJlbmd0aCBv Zg0KY29uc2Vuc3VzLsKgIEV2ZW4gaWYgeW91IGhhdmUgcmVhZCBhbmQgY29tbWVudGVkIG9uIHRo aXMgb3IgZWFybGllcg0KdmVyc2lvbnMgb2YgdGhlIGRyYWZ0LCBwbGVhc2UgZmVlbCBmcmVlIHRv IGNvbW1lbnQgYWdhaW4uwqAgVGhpcyBpcw0KcGFydGljdWxhcmx5IGltcG9ydGFudCBpZiB5b3Ug Zm91bmQgaXNzdWVzIHdpdGggdGhlIHByZXZpb3VzIHZlcnNpb24uDQoNCkFzIGEgcmVtaW5kZXIs IGNvbW1lbnRzIGNhbiBiZSBhbnl0aGluZyBmcm9tICJ0aGlzIGxvb2tzIGZpbmUiIHRvDQoidGhp cyBpcyBhIGhvcnJpYmxlIGlkZWEiOyB0aGV5IGNhbiBpbmNsdWRlIHN1Z2dlc3Rpb25zIGZvciBt aW5vcg0KZWRpdG9yaWFsIGNvcnJlY3Rpb25zIHRvIHNpZ25pZmljYW50IGVkaXRvcmlhbCBjaGFu Z2VzLg0KDQoNCi0gWW91ciBLaXR0ZW4gQ2hhaXJzDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpLaXR0ZW4gbWFpbGluZyBsaXN0DQpLaXR0ZW5AaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8va2l0dGVuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg== From nobody Fri Jan 2 15:46:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77B91A1A77 for ; Fri, 2 Jan 2015 15:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 7txGzcn7LO9w for ; Fri, 2 Jan 2015 15:46:42 -0800 (PST) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71231A0687 for ; Fri, 2 Jan 2015 15:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1420242401; bh=pwl6vjUeiz0OUps1d06V9JZ0frBBA+yEkGJ8TsL52jk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=s+d4blX9SXMKEMywvfyFcTQwrmnWDo74MvZATMvVSPX/YzEWoxi+u6VvpNgRAbqE2wwWG37Dmz6mP85PPWFL/j8G1CLcfL9KYDZm8cDjsRChtUTK/rKOvShXhUi/E/fzoFDE76A8VRN0S4hTkEBdD69TI6d5smGrh643HM/LbdJueKRgRp2O+QP/QsqQAorTMnC+UxxfhZ6iG+oeP/I0BoVQj26YnXo5BK/X2RD3XQQTNOeROIaYAs3RCjJTc4GuOAeknQa9HVBj5Y5E8HZZc3msfzIWKlIPjyFUGtoO22G6s9wjFrUu/ivpwB6R5NajmUkSYiIjcCOFND+OwhAXlw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=mJA/PjnBRtZxy6AaFcoehG2YmgDj2sDK6r/Xcve93xp1SZQm1zx5IO2zsDpeDh+gmsIGZfL6HqJsns24SatXib66qUCaM+idAeo1hEvkci5UwcIwVYpTmyjBMHCmkaKci5bS+i5MdIzVeb5Dp10aQQkfetWN0VRoIfkkowVt7r2q28xw5yP9Jaj5wDtOiXnKJjnAlMHMELbimHn3xzkibHaxo0rSC0lY2jWT/8ehz11M7MNzaLEv4f5/oii8Y1nEq6JBqyg2KgWZLq2zi9Ay5SpAr+AhHCjFrgzN/BBFGUqRFR/LSuQ7oOB9t5uYb6f29zpTblYJANfp1rAdflNXEg==; Received: from [66.196.81.174] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jan 2015 23:46:41 -0000 Received: from [98.139.212.243] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jan 2015 23:46:41 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 02 Jan 2015 23:46:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 78940.56019.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: qFowuEQVM1kZN2fX7rVIydwjfqYSaYBkn2EulzPXNM7pd4XrbSrpXxFkUMxoFLY OaDz3Q0WY.BiGabbXBsal.GxFE0C9XHIaYiSwZ56CXdxHQeWzJACi033JtPLxhNsY8b4xNsdtuxJ thAGbbStxl.I2.dhh5g.x8cZzYfsGHNATWzvcMGFYFX1eB5Zi5fJB3WFFHRBr_B0s7FnS80gh.KI tTI8Rn.SfzHDaonYviiZega7C.G_IKt05HxeK6Z9TN_6Urpr3GCEPLzjSa6txU10v3N8bFtgvdIL npsM2U8fQ8M46VxfBWx8m06md0B9kIbXjuh99K94q5fhgv9WHIoUIUz9cLEUh3aa0zOEnRHYW5y8 pjOk7kmpk102vJo_9ToWDEKlX2ulEWjVRRcbhd6V46MUpfClfVNyY8iiSBGM8yX0uVS69PiCepW8 4maAoict_p1XS0kgGLu06s5lbNf3a17iAkdXHRcwNpkNE86Y1x._xBOtL_.4YPdcc3gnul.r9ve0 gpq.1dsXxt.B0kL1xqvzNdg9KxOk3PIy5Kg5EmwSlNelhKAcNhgM6jIXH Received: by 66.196.81.120; Fri, 02 Jan 2015 23:46:40 +0000 Date: Fri, 2 Jan 2015 23:46:38 +0000 (UTC) From: Bill Mills To: "Ebling, Sebastian" , "OAuth@ietf.org" Message-ID: <1589697503.3851395.1420242398911.JavaMail.yahoo@jws106146.mail.bf1.yahoo.com> In-Reply-To: <18377bd2bfda4497918a529161e6089b@QEO00411.de.t-online.corp> References: <18377bd2bfda4497918a529161e6089b@QEO00411.de.t-online.corp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3851394_1249082722.1420242398903" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/EBw39D7CZ9iwVQK5fVjrpRCdkV4 Subject: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 23:46:43 -0000 ------=_Part_3851394_1249082722.1420242398903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 3 items fixed, thank you=20 On Friday, January 2, 2015 7:01 AM, "Ebling, Sebastian" wrote: =20 Hello, There is a little typo in Section 3.2.2: Replace "The URL for for a document" with "The URL for a document". Section 3. contains "2.=C2=A0 Server responds with a successful authentication. =C2=A0 In the case where authorization fails the server sends an error =C2=A0 result, then client MUST then send an additional message to the =C2=A0 server in order to allow the server to finish the exchange." There is a switch between authentication and authorization. Even if the acc= ess token represents authorization information I suggest to write "In the c= ase where authentication fails" because it is more consistent here. Section 3.2.2. introduces "oauth-configuration", the example in section 4.3= uses "openid-configuration". Regards Sebastian Ebling Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von Bill Mills Gesendet: Montag, 29. Dezember 2014 18:46 An: oauth@ietf.org Betreff: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-= 18 No other comments on this? =C2=A0Any "It's ready to go."? On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk wrote: Hi all, There may be some interested parties over here; please feel free to chime in on this WGLC over on the kitten list. -Ben ---------- Forwarded message ---------- Date: Mon, 15 Dec 2014 12:14:30 -0500 From: Benjamin Kaduk To: kitten@ietf.org Cc: kitten-chairs@tools.ietf.org Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 This message begins the fourth Working Group Last Call (WGLC) of "A set of SASL Mechanisms for OAuth" .=C2=A0 Due= to the overlap of the last call period with holidays, the duration of the WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 Because the changes between -15 and -18 involve behavior changes, including changes regarding discovery and dynamic registration, the Chairs decided to issue an additional last call. Please review the document and send comments to the Working Group mailing list < kitten at itef.org > or the co-chairs < kitten-chairs at tools.ietf.org > before the end of the WGLC.=C2=A0 Any and all comments on the document are sought in order to access the strength of consensus.=C2=A0 Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again.=C2=A0 This is particularly important if you found issues with the previous version. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - Your Kitten Chairs _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_3851394_1249082722.1420242398903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
3 items fixed, thank you
=


On Friday, January 2, 2015 7:01 AM, "Ebling, Sebastian" &= lt;s.ebling@telekom.de> wrote:


Hello,

There is a= little typo in Section 3.2.2:
Replace "The URL for for a= document" with "The URL for a document".


Section 3. contains
"2.  Serv= er responds with a successful authentication.

  In the case where authorization fails the server sends an= error
  result, then client MUST then send an addi= tional message to the
  server in order to allow th= e server to finish the exchange."
There is a switch betwe= en authentication and authorization. Even if the access token represents au= thorization information I suggest to write "In the case where authenticatio= n fails" because it is more consistent here.

Section 3.2.2. introduces "oauth-configuration", the example in sect= ion 4.3 uses "openid-configuration".

R= egards

Sebastian Ebling


Von: OAuth [mailto:oauth-bounces@ietf= .org] Im Auftrag von Bill Mills
Gesendet: Montag, 29.= Dezember 2014 18:46
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitte= n-sasl-oauth-18

No other comments on t= his?  Any "It's ready to go."?

On= Monday, December 15, 2014 9:34 AM, Benjamin Kaduk <kaduk@MIT.EDU<= /a>> wrote:

Hi all,

There may be some interested parties over here; pleas= e feel free to chime
in on this WGLC over on the kitten l= ist.

-Ben

---------- Forwarded message ----------
Date: M= on, 15 Dec 2014 12:14:30 -0500
From: Benjamin Kaduk <<= a shape=3D"rect" ymailto=3D"mailto:kaduk@MIT.EDU" href=3D"mailto:kaduk@MIT.= EDU">kaduk@MIT.EDU>
To: kitten@ietf.org=
Cc: kitten-chair= s@tools.ietf.org
Subject: [kitten] WGLC of draft-ietf= -kitten-sasl-oauth-18

This message beg= ins the fourth Working Group Last Call (WGLC) of "A set of
SASL Mechanisms for OAuth" <draft-ietf-kitten-sasl-oauth-18.txt>.&n= bsp; Due to
the overlap of the last call period with holi= days, the duration of the
WGLC is extended to four weeks,= so the WGLC will end on 12 January 2015.
The draft is av= ailable at:

https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18

Because the changes between -15 and -18 invol= ve behavior changes,
including changes regarding discover= y and dynamic registration, the Chairs
decided to issue a= n additional last call.

Please review = the document and send comments to the Working Group
maili= ng list < kitten at itef.org > or the co-chairs < kitten-chairsat tools.ietf.org > before the end of the WGLC.  An= y and all comments
on the document are sought in order to= access the strength of
consensus.  Even if you have= read and commented on this or earlier
versions of the dr= aft, please feel free to comment again.  This is
par= ticularly important if you found issues with the previous version.

As a reminder, comments can be anything from "= this looks fine" to
"this is a horrible idea"; they can i= nclude suggestions for minor
editorial corrections to sig= nificant editorial changes.


- Your Kitten Chairs

_______= ________________________________________
Kitten mailing l= ist
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

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



<= /div>
------=_Part_3851394_1249082722.1420242398903-- From nobody Tue Jan 6 13:44:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494261A8715 for ; Tue, 6 Jan 2015 13:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_WW9R3SY2Id for ; Tue, 6 Jan 2015 13:43:58 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0694.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:694]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27561A1A39 for ; Tue, 6 Jan 2015 13:43:57 -0800 (PST) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 21:43:34 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.202]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.202]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 21:43:34 +0000 From: Antonio Sanso To: OAuth WG Thread-Topic: Top 5 OAuth 2 Implementation Vulnerabilities Thread-Index: AQHQKfnRKKww73yh7kGg2rf+vxnnzQ== Date: Tue, 6 Jan 2015 21:43:33 +0000 Message-ID: <0A9CB984-C465-4FA1-8373-1D236692021B@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.47.250] authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR02MB207; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(97736003)(77156002)(62966003)(120916001)(558084003)(99286002)(4396001)(110136001)(450100001)(15975445007)(102836002)(36756003)(2900100001)(68736005)(99396003)(66066001)(86362001)(19580395003)(54356999)(229853001)(2656002)(87936001)(106356001)(106116001)(40100003)(19617315012)(105586002)(64706001)(16236675004)(122556002)(107046002)(50986999)(83716003)(82746002)(92566001)(107886001)(46102003)(21056001)(31966008)(33656002)(101416001)(20776003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_0A9CB984C4654FA183731D236692021Badobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 21:43:33.8557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR02MB207 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/meEzj69ItQATKk1dUkZ5-WcQnWA Subject: [OAUTH-WG] Top 5 OAuth 2 Implementation Vulnerabilities X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:44:00 -0000 --_000_0A9CB984C4654FA183731D236692021Badobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.htm= l regards antonio --_000_0A9CB984C4654FA183731D236692021Badobecom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-impl= ementation.html

regards

antonio --_000_0A9CB984C4654FA183731D236692021Badobecom_-- From nobody Fri Jan 9 02:18:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AB71A8741 for ; Fri, 9 Jan 2015 02:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SGudWiQxUit for ; Fri, 9 Jan 2015 02:18:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95A91A8740 for ; Fri, 9 Jan 2015 02:18:10 -0800 (PST) Received: from [172.16.254.109] ([80.92.122.140]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M6Ana-1XtVsy2bko-00y7vr for ; Fri, 09 Jan 2015 11:18:07 +0100 Message-ID: <54AFAADC.2080106@gmx.net> Date: Fri, 09 Jan 2015 11:18:04 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LS6hsTobj04FD2A275l2hDrR0IaiOQnMh" X-Provags-ID: V03:K0:PyB+9PzGoX+4iR/SpsoclgvdDJBjfgE+XtTladBNXvhJtQNkfNM d4wuW07Fsd4PrBjtxuLdI6fC88GHoeVvxYmdSlsjq2ovT/e5fgl7wzCzQ3QvMyRTFmJ3n4d iMm4R+aqgPGMf3a7p8WUgHcJIGwToomtysesSZdHmeBeNwOVzHe0kH6ANpGm7DoBJnp5VFa DxSQV9xiWuRc+ZKkh+pKg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] OAuth Status X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 10:18:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LS6hsTobj04FD2A275l2hDrR0IaiOQnMh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Happy New Year! I thought it would be good to quickly summarize where we are with our work in OAuth as we start into 2015. Late last year we issued a few working group last calls. * SPOP https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ The WGLC was started already in the summer and led to a huge amount of feedback. This lead to an improved draft. Nat, John, Naveen: What is the status of the document? What are the open issues? At a minimum there is the issue with the name of the document since it actually does not propose a proof-of- possession solution. * Token Introspection https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ Justin told me that he believes the document is ready for the IESG. I will do my shepherd write-up and shepherd review of the latest version before I hand it over to Kathleen. * Dynamic Client Registration http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21 We had a fair amount of discussion about this document on the mailing list in response to my shepherd write-up. A new version of the document has been published and I will have to double-check whether the review comments have been incorporated. Then, the document will be ready for the IESG. * OAuth 2.0 Proof-of-Possession (PoP) Security Architecture=09 http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ We issued a WGLC and received comments, which had not yet been incorporated. The obvious next step is to publish a new version of the document with the comments addressed. There is also the new mailing list and we have to figure out how this aligns with the work we are doing. Info is here: http://www.ietf.org/mail-archive/web/oauth/current/msg13997.html Derek will be the shepherd for that document. I also wanted to produce a short write-up in response to a news story late last year that blamed OAuth for getting things wrong while the real issue is rather with the way how responsibility are distributed among different players in the eco-system. Here is the link to the discussion and the news story: http://www.ietf.org/mail-archive/web/oauth/current/msg13929.html We also have various documents in IESG processing, namely * JWT * Assertion Framework * SAML Bearer Assertion * JWT Bearer Assertion Kathleen asked us to do a final review of the documents to make sure that various review comments have been addressed appropriately. I am planning to have a look at it today. There is also a webinar upcoming, namely about Kantara UMA. This webinar will be a bit different than earlier presentations you have heard about UMA since it will be focused on Internet of Things. This is part of the webinar series we do in the IETF ACE working group. Here is a link to the announcement: http://www.ietf.org/mail-archive/web/oauth/current/msg14015.html Related to the work in this group is the SASL OAuth draft, which is currently in WGLC in the KITTEN working group and you might want to do a quick review of the document: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 Here is the WGLC announcement from the KITTEN chairs: http://www.ietf.org/mail-archive/web/oauth/current/msg14020.html There is also the "authentication in OAuth" topic that we wanted to progress. There is a write-up from Justin available, which will inform the debate, but there was also interest to do something more official in the working group. We discussed this at the last IETF meeting. Also at the last IETF meeting we briefly spoke about the token exchange/token delegation work and I got the impression that there is a bit of confusion about the scope of the work and what functionality should be covered in what document. The last two topics seem to be suitable for conference calls. So, we will try to arrange something to progress these topics. Finally, there is the open redirect Antonio raised in http://www.ietf.org/mail-archive/web/oauth/current/msg13367.html. The attack might be difficult to understand but it is still worthwhile to make an attempt to explain it to a wider audience (and also the mitigation technique). I believe a draft would be quite suitable for this purpose and I have spoken with Antonio about it already. These are the items that come to mind right now. A lot of work ahead of us, as it seems. What is missing from the list? Feedback? Ciao Hannes & Derek --LS6hsTobj04FD2A275l2hDrR0IaiOQnMh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUr6rcAAoJEGhJURNOOiAt/TkH/1eavd+84h8rKn4m4AtFHYGJ pJkwhAxGugaEzXkkR41ppU8LOk3LGN5HMVy1vwf+BmD0Hv/C9dph7QbQp+prlsbg zfqvttIBWXvdpY12VmQE7J+HFmQoGjggtI//y95WqG7bDgnNymXDrZnZ64cU8bQB mHdVrTwA+zGN085RcpdeX/TxzgJC6n3hnjdwLBdUWj+Qs6etlW7FuoKF1bzXI36q wnLh3xm3HjDFw6KAsEp/92AwE0UK0IdicyUQTy9KXVnweoT7GEnBCr7ri02KxU0O ScPDk30X9J30eaW4cG9k8eFg6BdMNH5LktOV0ZGpR5y9iPcw3mmaMOyYnN8ix3Q= =VRYn -----END PGP SIGNATURE----- --LS6hsTobj04FD2A275l2hDrR0IaiOQnMh-- From nobody Fri Jan 9 11:55:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D242F1AC3C0; Fri, 9 Jan 2015 11:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBoMrEbYBIi3; Fri, 9 Jan 2015 11:55:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 897AA1AC3D4; Fri, 9 Jan 2015 11:54:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109195457.6526.46731.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 11:54:57 -0800 Archived-At: Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants' to Proposed Standard (draft-ietf-oauth-jwt-bearer-12.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 19:55:41 -0000 The IESG has approved the following document: - 'JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants' (draft-ietf-oauth-jwt-bearer-12.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Kathleen Moriarty and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ Technical Summary This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. Working Group Summary Consensus from the working group was clear on this draft and can be seen clearly in the number of implementations. Document Quality There are numerous implementations of this draft listed in the shepherd report. The document had quite a bit of review and comments were considered and included as appropriate. Personnel The document shepherd is Hannes Tschofenig and the responsible area director is Kathleen Moriarty. IANA Note Entries are added to an existing IANA table, no new registries are created. From nobody Sat Jan 10 10:59:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE0C1AC3C5 for ; Fri, 9 Jan 2015 11:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr4lzMopgNNm; Fri, 9 Jan 2015 11:54:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C171A90FE; Fri, 9 Jan 2015 11:54:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109195417.25692.18791.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 11:54:17 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sat, 10 Jan 2015 10:59:26 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 19:54:20 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ From nobody Sat Jan 10 10:59:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABE01AC3C0 for ; Fri, 9 Jan 2015 11:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8SOZ4K8u-Jf; Fri, 9 Jan 2015 11:55:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A781A911D; Fri, 9 Jan 2015 11:54:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109195457.6526.89836.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 11:54:57 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sat, 10 Jan 2015 10:59:26 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 19:55:38 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ From nobody Sat Jan 10 10:59:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05EE1A90F4 for ; Fri, 9 Jan 2015 13:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLP8GeKa0IxU; Fri, 9 Jan 2015 13:06:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6A71A90E2; Fri, 9 Jan 2015 13:06:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109210605.4054.38979.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 13:06:05 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sat, 10 Jan 2015 10:59:27 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:06:07 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ From nobody Mon Jan 12 02:25:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D38D1A8AA3 for ; Mon, 12 Jan 2015 02:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN9GL_CRpdCF for ; Mon, 12 Jan 2015 02:24:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0606.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:606]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22D21A8AA8 for ; Mon, 12 Jan 2015 02:24:55 -0800 (PST) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 10:24:29 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.237]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.237]) with mapi id 15.01.0053.000; Mon, 12 Jan 2015 10:24:29 +0000 From: Antonio Sanso To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth Status Thread-Index: AQHQK/WYUKxZ5/ijqE2WfW1yra36J5y8TaoA Date: Mon, 12 Jan 2015 10:24:28 +0000 Message-ID: <459FF4A3-1BBF-43C7-B6BB-C7D831E2FDFD@adobe.com> References: <54AFAADC.2080106@gmx.net> In-Reply-To: <54AFAADC.2080106@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.147.117.11] authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR02MB207; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB207; x-forefront-prvs: 0454444834 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(53754006)(51704005)(377454003)(199003)(189002)(122556002)(15975445007)(64706001)(68736005)(2950100001)(102836002)(2900100001)(40100003)(77156002)(1720100001)(101416001)(99286002)(33656002)(110136001)(2351001)(66066001)(106116001)(105586002)(86362001)(19580395003)(19580405001)(106356001)(82746002)(76176999)(54356999)(50986999)(92566002)(46102003)(83716003)(2656002)(87936001)(2501002)(97736003)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <504A8C70D701E240A4B80AC549BEBDCC@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2015 10:24:28.8914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR02MB207 Archived-At: Subject: Re: [OAUTH-WG] OAuth Status X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 10:25:18 -0000 hi *, On Jan 9, 2015, at 11:18 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > Happy New Year! >=20 > I thought it would be good to quickly summarize where we are with our > work in OAuth as we start into 2015. >=20 > Late last year we issued a few working group last calls. >=20 > * SPOP > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >=20 > The WGLC was started already in the summer and led to a huge amount of > feedback. This lead to an improved draft. >=20 > Nat, John, Naveen: What is the status of the document? What are the open > issues? >=20 > At a minimum there is the issue with the name of the document since it > actually does not propose a proof-of- > possession solution. >=20 > * Token Introspection > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 > Justin told me that he believes the document is ready for the IESG. I > will do my shepherd write-up and shepherd review of the latest version > before I hand it over to Kathleen. >=20 > * Dynamic Client Registration > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21 >=20 > We had a fair amount of discussion about this document on the mailing > list in response to my shepherd write-up. A new version of the document > has been published and I will have to double-check whether the review > comments have been incorporated. Then, the document will be ready for > the IESG. >=20 > * OAuth 2.0 Proof-of-Possession (PoP) Security Architecture=09 > http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >=20 > We issued a WGLC and received comments, which had not yet been > incorporated. The obvious next step is to publish a new version of the > document with the comments addressed. There is also the new mailing list > and we have to figure out how this aligns with the work we > are doing. Info is here: > http://www.ietf.org/mail-archive/web/oauth/current/msg13997.html >=20 > Derek will be the shepherd for that document. >=20 > I also wanted to produce a short write-up in response to a news story > late last year that blamed OAuth for getting things wrong while the real > issue is rather with the way how responsibility are distributed among > different players in the eco-system. Here is the link to the discussion > and the news story: > http://www.ietf.org/mail-archive/web/oauth/current/msg13929.html >=20 > We also have various documents in IESG processing, namely > * JWT > * Assertion Framework > * SAML Bearer Assertion > * JWT Bearer Assertion >=20 > Kathleen asked us to do a final review of the documents to make sure > that various review comments have been addressed appropriately. I am > planning to have a look at it today. >=20 > There is also a webinar upcoming, namely about Kantara UMA. This webinar > will be a bit different than earlier presentations you have heard about > UMA since it will be focused on Internet of Things. This is part of the > webinar series we do in the IETF ACE working group. Here is a link to > the announcement: > http://www.ietf.org/mail-archive/web/oauth/current/msg14015.html >=20 > Related to the work in this group is the SASL OAuth draft, which is > currently in WGLC in the KITTEN working group and you might want to do a > quick review of the document: > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 >=20 > Here is the WGLC announcement from the KITTEN chairs: > http://www.ietf.org/mail-archive/web/oauth/current/msg14020.html >=20 > There is also the "authentication in OAuth" topic that we wanted to > progress. There is a write-up from Justin available, which will inform > the debate, but there was also interest to do something more official in > the working group. We discussed this at the last IETF meeting. >=20 > Also at the last IETF meeting we briefly spoke about the token > exchange/token delegation work and I got the impression that there is a > bit of confusion about the scope of the work and what functionality > should be covered in what document. >=20 > The last two topics seem to be suitable for conference calls. So, we > will try to arrange something to progress these topics. >=20 > Finally, there is the open redirect Antonio raised in > http://www.ietf.org/mail-archive/web/oauth/current/msg13367.html. The > attack might be difficult to understand but it is still worthwhile > to make an attempt to explain it to a wider audience (and also the > mitigation technique). I believe a draft would be quite suitable for > this purpose and I have spoken with Antonio about it already. >=20 thanks Hannes & Derek for including this here. Even if I do not have any experience in IETF processes and related I was wo= ndering if there is any change I can take a stub at and try to prepare a dr= aft about this particular issue. What do you guys think? Is there also anybody that would like to collaborat= e with me on this matter? regards antonio > These are the items that come to mind right now. A lot of work ahead of > us, as it seems. >=20 > What is missing from the list? Feedback? >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jan 12 03:12:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2267C1A8AAF for ; Mon, 12 Jan 2015 03:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PDSTJnRqaA1 for ; Mon, 12 Jan 2015 03:11:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402241A6F10 for ; Mon, 12 Jan 2015 03:11:56 -0800 (PST) Received: from [172.16.254.109] ([80.92.123.55]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LoaCE-1XYXzs0h7y-00gXTB for ; Mon, 12 Jan 2015 12:11:54 +0100 Message-ID: <54B3ABF8.8050007@gmx.net> Date: Mon, 12 Jan 2015 12:11:52 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oNCKLiCDPd3loIMsSsqwIDLCAITmvETrJ" X-Provags-ID: V03:K0:g12yFr0msvW8MgvS5s7uhAl1C7cEwy2TQSnDp3j8bDMNc7UQoLg /D/krSsu/BITxRFiS/qFjnJ/cSDbv/+4fhv7XsfE8gFQPJz6/JAtmrV/CRXvSjsxqnTjuDp 7RO0N5wVNfGr4yU2Kv/xFhK3dhjxbYUdN9X/6cKY7rn8VkAixBVUCCniCAmP8Xh0fXjcPSL TvYISVwb8YBdxd8rHn0Zw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 11:12:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oNCKLiCDPd3loIMsSsqwIDLCAITmvETrJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, Hi all, as noted in my status update I am trying to finalize the pending items. Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my review of draft-ietf-oauth-dyn-reg-management raised some questions about the terminology. If you look at the structure of the ToC then you will notice the followin= g: 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13 3.1. Client Registration Request . . . . . . . . . . . . . . . 14 3.1.1. Client Registration Request Using a Software Statement . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Client Registration Response . . . . . . . . . . . . . . 16 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Client Information Response . . . . . . . . . . . . . . . 17 4.2. Client Registration Error Response . . . . . . . . . . . 18 There is no 'Client Registration Response' in the protocol (only the Client Information Response) and section 3.2 is pretty much empty and only points to the later sections. So, I would suggest to do the followin= g. 3. Client Registration Endpoint 3.1. Client Registration Request 3.1.1. Client Registration Request Using a Software Statement 3.2. Client Registration Response 3.2.1. Client Information Response 3.2.2. Client Registration Error Response (A section with only a single sub-section is also a sign of a bad structure.) I re-read the terminology and looked at Figure 1 to see whether it makes sense and it still does not. I know that there may be many different deployment options but it should at least be clear to the reader where information comes from and where does it go. For example, when I try to follow the flow of the software statement then I read the following: " Software Statement: In some cases, a software statement will be issued directly by the organization or developer that creates the client softwar= e. " What does the figure tell us? It shows us that the client or developer gets the software assertion. +--------(A)- Initial Access Token (OPTIONAL) | | +----(B)- Software Statement (OPTIONAL) | | v v +-----------+ +---------------+ | |--(C)- Client Registration Request -->| Client | | Client or | | Registration | | Developer |<-(D)- Client Information Response ---| Endpoint | | | +---------------+ +-----------+ Maybe we should illustrate one example that makes sense and then say that there are others that could be used. It also does not make sense to show the developer in the box together with the client since the developer does not execute a protocol exchange with the client registration endpoint. Here is a proposal for improving this: FROM: +--------(A)- Initial Access Token (OPTIONAL) | | +----(B)- Software Statement (OPTIONAL) | | v v +-----------+ +---------------+ | |--(C)- Client Registration Request -->| Client | | Client or | | Registration | | Developer |<-(D)- Client Information Response ---| Endpoint | | | +---------------+ +-----------+ Figure 1: Abstract Dynamic Client Registration Flow TO: +-------- O -- (A)- Initial Access Token (OPTIONAL) | /|\ | +---- / \ -- (B)- Software Statement (OPTIONAL) | | Client | | Developer | | v v +--------------+ +---------------+ | |--(C)- Client Registration Request -->| Client | | Client | | Registration | | |<-(D)- Client Information Response ---| Endpoint | +--------------+ +---------------+ Figure 1: Abstract Dynamic Client Registration Flow Alternatively, one could also separate the distribution of software statements and the actual protocol exchange. Here is the proposal: +--------(A)- Initial Access Token (OPTIONAL) | | +----(B)- Software Statement (OPTIONAL) | | v v +-----------+ +---------------+ | |--(C)- Client Registration Request -->| Client | | Client | | Registration | | |<-(D)- Client Information Response ---| Endpoint | +-----------+ +---------------+ Figure 1: Abstract Dynamic Client Registration Flow +---------------+ | Authorization | | Server | +---------------+ | Initial |(A) Access | Token v O Client +------ /|\ Developer |+----- / \ || (A)||(B) Software || Statement vv +-----------+ | | | Client | | | +-----------+ Figure 2: Software Statement / Initial Access Token Distribution Example.= Then, there is also this statement in the Software Statement definition: " In other cases, a software statement will be issued by a third party organization for use by the organization or developer that creates the client software. " In the terminology section we are defining all the parties that are involved and now this mysterious "third party organization" is introduced. Is this one of the already defined parties or is this yet another organization? Finally, the client developer is defined as a single individual or an entire organization (i.e., a group of people). However, in the text you write 'client developer or organization'. For example, look at the software statement: "In some cases, a software statement will be issued directly by the organization or developer that creates the client software. " Wouldn't it be more consistent to use the client developer definition as is and just turn this sentence into " In some cases, a software statement will be issued directly by the client developer. " Ciao Hannes --oNCKLiCDPd3loIMsSsqwIDLCAITmvETrJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUs6v4AAoJEGhJURNOOiAtYFsIAJP5pToN4iiBsaZS683jXpcU It3JfUbyf0GfXFLQxGKZpeWjDN4bp67IAbBtRiyOmn0UtLvg0Y/SsgywxQcRobtH OrIG4vUNFCVHV8xUrmGAkOk/g7q2WDnHajJZ72e2CuulLOTl4g/hsaZjHP1NIcWG ezW+ypfABKF1J6AyXNRCO2iwt5/s6t1Es6bEaN7SZunpYq8RqTs0ko5Bbp+BvwmY b8PxZiQFsdL9v0er1adWozl3YNLluzApaVkdugRBkykzAuyWBkglwynHDS9l1CDq +5uqNCy3D0fvnOgSJAtaD7QnffCSswrwHIdjGoSOdmZ9u1uVdsQU+Og5/pAtM/o= =8sVe -----END PGP SIGNATURE----- --oNCKLiCDPd3loIMsSsqwIDLCAITmvETrJ-- From nobody Mon Jan 12 05:11:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB39F1A0191 for ; Mon, 12 Jan 2015 05:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=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 6ezMcQrqJ_2R for ; Mon, 12 Jan 2015 05:11:41 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AAC1A1B9B for ; Mon, 12 Jan 2015 05:11:40 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so31952694pab.6 for ; Mon, 12 Jan 2015 05:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=Z00FmXzeIAa5DY1m21bHz68eVr8W0oXGgp8zYSQR/dk=; b=qGv416x3dvgq9Jo6NQ2uosR0JYZjJGAG9QdtdKRh5kp25TI/i/hLvDl3bkhAC4Yccf sfozmLe6FaQqxAWfgnCYS1nI559FVs/z+5jYhTbTUhVtbyId4uy7+PtsRkQpsjK0bTTB K+6oIws356K43J5mSrIxLljzB4NGyJu0SshGnTNz4sWl+uDOh7hGwHD+1V29QMdsJxN+ cTZptWROeevqBCA02440aLZcfnOoZ3k61o3D1Qm2sVsfRAjvQtr2Za2A64szAvWEhGbA q1Z6slU8mRR2g+cdep9JewiGORnmBlgSVEznfU6cMXH4Y0cBf4J16X0l5FNuiijw98QB VJgQ== X-Received: by 10.66.121.230 with SMTP id ln6mr43996415pab.82.1421068300087; Mon, 12 Jan 2015 05:11:40 -0800 (PST) Received: from monk (ip24-250-56-242.ri.ri.cox.net. [24.250.56.242]) by mx.google.com with ESMTPSA id pf10sm14319866pbc.82.2015.01.12.05.11.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jan 2015 05:11:38 -0800 (PST) From: "Brock Allen" To: References: In-Reply-To: Date: Mon, 12 Jan 2015 08:11:20 -0500 Message-ID: <002401d02e69$43284220$c978c660$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01D02E3F.5A5372A0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdAlLOwe2gYzYJeGR8SIW2KjtIM6ngJPC9cQ Content-Language: en-us Archived-At: Subject: [OAUTH-WG] session status change notification questions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 13:11:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01D02E3F.5A5372A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A couple of questions about the session management spec related to the = status change notifications (section 4):=20 =20 1) Is there a working reference implementation of the JavaScript that = goes with the current draft of the spec? =20 =20 2) For the statement from section 4.2: =E2=80=9CThe OP iframe MUST = enforce that the caller has the same origin as its parent = frame.=E2=80=9D I=E2=80=99m uncertain how to do this in the OP iframe, = given that it seems to be a cross-origin security concern to ascertain = the origin of the parent window. I don=E2=80=99t think = =E2=80=98referrer=E2=80=99 is the most reliable approach. =20 =20 3) The spec states that the OP iframe and the RP iframe should be both = contained within the main RP window (so the iframes are siblings). Is = there a reason the RP iframe can=E2=80=99t contain the OP iframe? =20 If it can, then this would address my question #2 above, as the = source.window (on the message event args) can be compared to the = parent.window to ensure that only the parent is sending the messages. =20 =20 Thanks. =20 -Brock =20 ------=_NextPart_000_0025_01D02E3F.5A5372A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A couple = of questions about the session management spec related to the status = change notifications (section 4):

 =

1) Is = there a working reference implementation of the JavaScript that goes = with the current draft of the spec?

 =

 =

2) For the = statement from section 4.2: =E2=80=9CThe OP iframe MUST enforce that the = caller has the same origin as its parent frame.=E2=80=9D I=E2=80=99m = uncertain how to do this in the OP iframe, given that it seems to be a = cross-origin security concern to ascertain the origin of the parent = window. I don=E2=80=99t think =E2=80=98referrer=E2=80=99 is the most = reliable approach.

 =

 =

3) The = spec states that the OP iframe and the RP iframe should be both = contained within the main RP window (so the iframes are siblings). Is = there a reason the RP iframe can=E2=80=99t contain the OP = iframe?

 =

If it can, = then this would address my question #2 above, as the source.window (on = the message event args) can be compared to the parent.window to ensure = that only the parent is sending the messages.

 =

 =

Thanks.

 =

-Brock=

 =

------=_NextPart_000_0025_01D02E3F.5A5372A0-- From nobody Mon Jan 12 05:21:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71371A903B for ; Mon, 12 Jan 2015 05:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ldsbxjLjsCi for ; Mon, 12 Jan 2015 05:21:17 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE731A9030 for ; Mon, 12 Jan 2015 05:21:16 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id p6so17836014qcv.6 for ; Mon, 12 Jan 2015 05:21:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=96Ant6HXcEQQTUZ87vXX8NJlJ2pDiofkWgUgB0/In+8=; b=BXt0UsdjISn3fwy3JLLFHjPA2vi7fvlGl2ztGhzdd/CsQiS8UkG1hiswHWmy0dkSgW N36/mgQnmRuVi2QOs8QtQImjKd/oNiVKFP+exquPOITUFaHNAvIlGUWWe66dJNG9yRWr ueDAk4UcvAL5W96tuBzxth6y4uxcq+41rxXUv3bUfCCmxU6fpSxNOP/J3l3YuYQFVgKn GKnKC2NEaN2QnZm/LezBgU+Jz9tGMm4b6uhS7br+pVmwK4mikr1EiU3StXoHI76+7E1E LH0gIi2AdmKH+1Og8rynNm2XH9sgc5lbAoFlEWaH/iVUED8tPgJRsRd1p9QaDm7lDor3 BWWw== X-Gm-Message-State: ALoCoQn1QhJ+vm9Go0+R9q8sE77wbqSPPXnPVmbaXz2jOjtGj6qzGD+KYiHHH5E4rHA2byodGDGz X-Received: by 10.140.31.163 with SMTP id f32mr46113108qgf.23.1421068875707; Mon, 12 Jan 2015 05:21:15 -0800 (PST) Received: from [192.168.8.100] ([186.65.243.75]) by mx.google.com with ESMTPSA id p69sm14710504qga.27.2015.01.12.05.21.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 05:21:14 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_56A6D209-E275-4F88-ADD8-62410D6919C1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <002401d02e69$43284220$c978c660$@gmail.com> Date: Mon, 12 Jan 2015 10:21:09 -0300 Message-Id: <4CB069B6-093D-44A4-A0CC-82AE0E637285@ve7jtb.com> References: <002401d02e69$43284220$c978c660$@gmail.com> To: Brock Allen X-Mailer: Apple Mail (2.1993) Archived-At: Cc: OAuth@ietf.org Subject: Re: [OAUTH-WG] session status change notification questions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 13:21:20 -0000 --Apple-Mail=_56A6D209-E275-4F88-ADD8-62410D6919C1 Content-Type: multipart/alternative; boundary="Apple-Mail=_3CB025C3-CFBB-4531-ACEA-FA7DD1882848" --Apple-Mail=_3CB025C3-CFBB-4531-ACEA-FA7DD1882848 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If you are talking about this spec = http://openid.net/specs/openid-connect-session-1_0.html = , then the = correct list for questions is the openid Connect one at = http://lists.openid.net/mailman/listinfo/openid-specs-ab = . Session management is not currently a OAuth WG document. John B. > On Jan 12, 2015, at 10:11 AM, Brock Allen = wrote: >=20 > A couple of questions about the session management spec related to the = status change notifications (section 4):=20 > =20 > 1) Is there a working reference implementation of the JavaScript that = goes with the current draft of the spec? > =20 > =20 > 2) For the statement from section 4.2: =E2=80=9CThe OP iframe MUST = enforce that the caller has the same origin as its parent frame.=E2=80=9D = I=E2=80=99m uncertain how to do this in the OP iframe, given that it = seems to be a cross-origin security concern to ascertain the origin of = the parent window. I don=E2=80=99t think =E2=80=98referrer=E2=80=99 is = the most reliable approach. > =20 > =20 > 3) The spec states that the OP iframe and the RP iframe should be both = contained within the main RP window (so the iframes are siblings). Is = there a reason the RP iframe can=E2=80=99t contain the OP iframe? > =20 > If it can, then this would address my question #2 above, as the = source.window (on the message event args) can be compared to the = parent.window to ensure that only the parent is sending the messages. > =20 > =20 > Thanks. > =20 > -Brock > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_3CB025C3-CFBB-4531-ACEA-FA7DD1882848 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If you are talking about this spec http://openid.net/specs/openid-connect-session-1_0.html, =  then the correct list for questions is the openid Connect one = at http://lists.openid.net/mailman/listinfo/openid-specs-ab.
Session management is = not currently a OAuth WG document.

John B.
On = Jan 12, 2015, at 10:11 AM, Brock Allen <brockallen@gmail.com> wrote:

A couple of questions about the session management = spec related to the status change notifications (section 4): 
 
1) Is there a working reference = implementation of the JavaScript that goes with the current draft of the = spec?
 
 
2) For the = statement from section 4.2: =E2=80=9CThe OP iframe MUST enforce that the = caller has the same origin as its parent frame.=E2=80=9D I=E2=80=99m = uncertain how to do this in the OP iframe, given that it seems to be a = cross-origin security concern to ascertain the origin of the parent = window. I don=E2=80=99t think =E2=80=98referrer=E2=80=99 is the most = reliable approach.
 
 
3) The spec states that the OP iframe and the RP = iframe should be both contained within the main RP window (so the = iframes are siblings). Is there a reason the RP iframe can=E2=80=99t = contain the OP iframe?
 
If it can, then this would address my question #2 = above, as the source.window (on the message event args) can be compared = to the parent.window to ensure that only the parent is sending the = messages.
 
 
Thanks.
 
-Brock
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_3CB025C3-CFBB-4531-ACEA-FA7DD1882848-- --Apple-Mail=_56A6D209-E275-4F88-ADD8-62410D6919C1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMTIxMzIxMTBaMCMGCSqGSIb3DQEJBDEWBBSmJ9qwARarG+WJ8YccFOiU JWfYkjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCKVDUvhkDlGDyd+W6oCl5yWXx3mdnChXKNnsS1Mw8UhR0aaTRzri41 hPvFo2qgkuBOwi8iBJMObUcx0iIsezDaQUiDTIxosMsXYdyXF75gHg3wdfEujfyDDibAz7Hz7fP3 VJKljIS1TTe1Log+athNqdhnAaQY4pyrPwPSvjtlE6k8yQ5ge/Q5Uh+V6gKdd7q/GAba9YUQiRKn rxrjs6XCLbgKhjPMHGvqEfs2nB8YZeHr8Dxhxr3zsDMjmYSIehf5hMLrPdaEMKjOMIMw1NKsOr2a 5KgU0QciKNAEAtXDkF/5F2nNkdLoJzyX7pEyQa6Mxz7SfwX98SH4KW62erjIAAAAAAAA --Apple-Mail=_56A6D209-E275-4F88-ADD8-62410D6919C1-- From nobody Mon Jan 12 05:56:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085721A90F4 for ; Mon, 12 Jan 2015 05:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 fyzik-jm9mI5 for ; Mon, 12 Jan 2015 05:56:07 -0800 (PST) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83B01A90F1 for ; Mon, 12 Jan 2015 05:56:07 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id l89so17616618qgf.13 for ; Mon, 12 Jan 2015 05:56:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nrn+8tMJUmJ5ypYvgYwgtRPNBgmzPxDHq0cSuGJSF94=; b=Puyx7K9EGQpONXue26OxFeRbUpaUZTI9BL6hfP+IxWXEYDtQAVK6jySrR8w9OZH+nI D0fa8yOjWhwTYTBMGTByOovQfSf8oD6MhWKy6b1XQbmSUUIy9x7BNDhhDM6ZCa6qFlro BgohwbR50YpiBwdPqEknoPr6hqrBSya8Mk0iKfvbb6W0sjHU0iQtlTEzc8zByoODFGwN 1nJWLiLs5TIE+lCS5BPgzek1lUbv6srDanpG4cITqdJDs3nh3DviLPliMRPBB3Z5ICYr TxpQJ1d37xW0mSm/A+vXFf8eA0MplBbXEtISsRcl2Hv7i2Fhp1mdvWxkZBkt9mZdEcFO lBZg== X-Gm-Message-State: ALoCoQn3DEHIoZ4b9bQp/8uC0gDWe/GWGmZdl2l7lXlub+8hVtDPlq57gaInNdTaCNdMPn4ZiQ/r X-Received: by 10.229.212.67 with SMTP id gr3mr49422502qcb.6.1421070966675; Mon, 12 Jan 2015 05:56:06 -0800 (PST) Received: from [192.168.8.100] ([186.65.243.75]) by mx.google.com with ESMTPSA id g20sm14827193qar.17.2015.01.12.05.56.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 05:56:05 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_EEE85707-A58C-4287-BDC8-1935ED090C63"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <459FF4A3-1BBF-43C7-B6BB-C7D831E2FDFD@adobe.com> Date: Mon, 12 Jan 2015 10:56:01 -0300 Message-Id: References: <54AFAADC.2080106@gmx.net> <459FF4A3-1BBF-43C7-B6BB-C7D831E2FDFD@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Status X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 13:56:10 -0000 --Apple-Mail=_EEE85707-A58C-4287-BDC8-1935ED090C63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am willing to try and help you with it. John B. > On Jan 12, 2015, at 7:24 AM, Antonio Sanso wrote: >=20 > hi *, > On Jan 9, 2015, at 11:18 AM, Hannes Tschofenig = wrote: >=20 >> Hi all, >>=20 >> Happy New Year! >>=20 >> I thought it would be good to quickly summarize where we are with our >> work in OAuth as we start into 2015. >>=20 >> Late last year we issued a few working group last calls. >>=20 >> * SPOP >> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>=20 >> The WGLC was started already in the summer and led to a huge amount = of >> feedback. This lead to an improved draft. >>=20 >> Nat, John, Naveen: What is the status of the document? What are the = open >> issues? >>=20 >> At a minimum there is the issue with the name of the document since = it >> actually does not propose a proof-of- >> possession solution. >>=20 >> * Token Introspection >> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>=20 >> Justin told me that he believes the document is ready for the IESG. I >> will do my shepherd write-up and shepherd review of the latest = version >> before I hand it over to Kathleen. >>=20 >> * Dynamic Client Registration >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21 >>=20 >> We had a fair amount of discussion about this document on the mailing >> list in response to my shepherd write-up. A new version of the = document >> has been published and I will have to double-check whether the review >> comments have been incorporated. Then, the document will be ready for >> the IESG. >>=20 >> * OAuth 2.0 Proof-of-Possession (PoP) Security Architecture=09 >> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >>=20 >> We issued a WGLC and received comments, which had not yet been >> incorporated. The obvious next step is to publish a new version of = the >> document with the comments addressed. There is also the new mailing = list >> and we have to figure out how this aligns with the work = we >> are doing. Info is here: >> http://www.ietf.org/mail-archive/web/oauth/current/msg13997.html >>=20 >> Derek will be the shepherd for that document. >>=20 >> I also wanted to produce a short write-up in response to a news story >> late last year that blamed OAuth for getting things wrong while the = real >> issue is rather with the way how responsibility are distributed among >> different players in the eco-system. Here is the link to the = discussion >> and the news story: >> http://www.ietf.org/mail-archive/web/oauth/current/msg13929.html >>=20 >> We also have various documents in IESG processing, namely >> * JWT >> * Assertion Framework >> * SAML Bearer Assertion >> * JWT Bearer Assertion >>=20 >> Kathleen asked us to do a final review of the documents to make sure >> that various review comments have been addressed appropriately. I am >> planning to have a look at it today. >>=20 >> There is also a webinar upcoming, namely about Kantara UMA. This = webinar >> will be a bit different than earlier presentations you have heard = about >> UMA since it will be focused on Internet of Things. This is part of = the >> webinar series we do in the IETF ACE working group. Here is a link to >> the announcement: >> http://www.ietf.org/mail-archive/web/oauth/current/msg14015.html >>=20 >> Related to the work in this group is the SASL OAuth draft, which is >> currently in WGLC in the KITTEN working group and you might want to = do a >> quick review of the document: >> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 >>=20 >> Here is the WGLC announcement from the KITTEN chairs: >> http://www.ietf.org/mail-archive/web/oauth/current/msg14020.html >>=20 >> There is also the "authentication in OAuth" topic that we wanted to >> progress. There is a write-up from Justin available, which will = inform >> the debate, but there was also interest to do something more official = in >> the working group. We discussed this at the last IETF meeting. >>=20 >> Also at the last IETF meeting we briefly spoke about the token >> exchange/token delegation work and I got the impression that there is = a >> bit of confusion about the scope of the work and what functionality >> should be covered in what document. >>=20 >> The last two topics seem to be suitable for conference calls. So, we >> will try to arrange something to progress these topics. >>=20 >> Finally, there is the open redirect Antonio raised in >> http://www.ietf.org/mail-archive/web/oauth/current/msg13367.html. The >> attack might be difficult to understand but it is still worthwhile >> to make an attempt to explain it to a wider audience (and also the >> mitigation technique). I believe a draft would be quite suitable for >> this purpose and I have spoken with Antonio about it already. >>=20 >=20 > thanks Hannes & Derek for including this here. > Even if I do not have any experience in IETF processes and related I = was wondering if there is any change I can take a stub at and try to = prepare a draft about this particular issue. > What do you guys think? Is there also anybody that would like to = collaborate with me on this matter? >=20 > regards >=20 > antonio >=20 >=20 >> These are the items that come to mind right now. A lot of work ahead = of >> us, as it seems. >>=20 >> What is missing from the list? Feedback? >>=20 >> Ciao >> Hannes & Derek >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_EEE85707-A58C-4287-BDC8-1935ED090C63 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMTIxMzU2MDJaMCMGCSqGSIb3DQEJBDEWBBT/e0Mmg8oa2V+JbTLyPR/q r6wxLDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAKlmT0Fj299CyHuRDMm2hAxz43Ixs2gIT6JJ2hI7lBhVcSniO8uolB BYQ+cEQqNimKIntj+9YxiYs/MbgjM34XUeG50OGqrA6I3ZOKyFcTRcuun9q6zzkWgArGXhCkURv8 X4SNAuUV/IzirPJBerNgZSMxtaZ6NY/TnYlHLv1mIVoAuuBxJeADwAVkrJfikzsj/lySUmsUTf6r NglnZYtUHk5XbzJkXJTMx2lhMBUDphfzOI+Nybg1qAs9IQz6Mr4f3JfYCfFd4YOywq83GnyoRfs+ bXU43UvZ4uWBm/JeX+cvMA62wS1ngRfccjF3bCvmgPfdKe08Cd+Ry+ezHChBAAAAAAAA --Apple-Mail=_EEE85707-A58C-4287-BDC8-1935ED090C63-- From nobody Mon Jan 12 07:10:30 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17D01AC3AD for ; Mon, 12 Jan 2015 07:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbvrz_UBlR7Q for ; Mon, 12 Jan 2015 07:10:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C043D1AC39D for ; Mon, 12 Jan 2015 07:10:16 -0800 (PST) Received: from [172.16.254.109] ([80.92.123.55]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MaE4a-1YUQPO1oEa-00JqzT for ; Mon, 12 Jan 2015 16:10:14 +0100 Message-ID: <54B3E3D5.9040502@gmx.net> Date: Mon, 12 Jan 2015 16:10:13 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mTUaaJnoF9U347rSorCDrju2nIA1kwEbA" X-Provags-ID: V03:K0:SvCYmVoBHMt9tA8JE9klj7dz6ULfBeySo0fmkt2QToYoIZG6J21 djLrbbs7aLbP2MbjztA4ST/9mG3PRfBOqEIHpOxok8eEUloNXw2+MHB2/X9uCMzrrv2rQHO Br9tPiyGh5ytaGLLZj+o5rMCMb7atkskWq7jUQJDIKRjCYLnoo8hy1yNjZx1/AF+Xe5dZan KDm8g9cMm1tj/6rxk3XXw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Dynamic Client Registration Management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 15:10:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mTUaaJnoF9U347rSorCDrju2nIA1kwEbA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, Hi all, I re-read the latest version of the dynamic client registration management document and I still have a few issues with the document. Let me start with the document structure. When you look at the ToC you will notice that there is something wrong. 2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5 2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6 2.2. Client Update Request . . . . . . . . . . . . . . . . . . 6 2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9 3. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Client Information Response . . . . . . . . . . . . . . . 10 =09 Figure 1 describes a number of request and responses, namely * Client Registration Request and Client Information Response * Read or Update Request and Client Information Response * Delete Request and Delete Confirmation Section 3 only covers the "Client Information Response". It would of course been cleaner to have a response that matches the request. This avoids confusion. But that's where we are right now. Currently, most of the response message content is actually described in Section 2 rather than in Section 3. You may want to think about re-structure the text in the following way. This would also cause you to re-think a lot of the data duplication issue= =2E For example, an update request requires the client to re-submit all data and then, in the response, the authorization server has to submit a lot of the data back to the client again (even if it does not change it). That does not sound right to me. 2. Client Configuration Endpoint 2.1. Client Registration Request and Client Information Response 2.2. Client Read Request and Client Information Response 2.3. Client Update Request and Client Information Response 2.4. Client Delete Request and Delete Confirmation =09 Appendix B. Registration Tokens and Client Credentials Throughout the course of the dynamic registration protocol, there are three different classes of credentials in play, each with different properties and targets. o The initial access token is optionally used by the client or developer at the registration endpoint. s/client or developer/client This is an OAuth 2.0 token that is used to authorize the initial client registration request. The content, structure, generation, and validation of this token are out of scope for this specification. The authorization server can use this token to verify that the presenter is allowed to dynamically register new clients. This token may be shared among multiple instances of a client to allow them to each register separately, thereby letting the authorization server use this token to tie multiple instances of registered clients (each with their own distinct client identifier) back to the party to whom the initial access token was issued, usually an application developer. This token should be used only at the client registration endpoint. [hannes] Is this correct? "should only be used at the client registration endpoint" It would be better to say that this must only be used at the client registration endpoint since that was the purpose for creating it. o The registration access token is used by the client or developer at the client configuration endpoint and represents the holder's authorization to manage the registration of a client. s/client or developer/client This is an OAuth 2.0 bearer token that is issued from the client registration endpoint in response to a client registration request and is returned in a client information response. The registration access token is uniquely bound to the client identifier and is required to be presented with all calls to the client configuration endpoint. The registration access token should be protected and should not be shared between instances of a client (otherwise, one instance could change or delete registration values for all instances of the client). [hannes] The registration access token must be confidentiality protected in transit and also protected against unauthorized access when stored locally on the client. In what cases do you envision the registration access token to be shared among client instances? The registration access token can be rotated through the use of the client update method on the client configuration endpoint. The registration access token should be used only at the client configuration endpoint. [hannes] Why 'should' and not 'must'? Again, we create this registration access token specifically for the use with the client configuration endpoint.=09 =09 o The client credentials (such as "client_secret") are optional depending on the type of client and are used to retrieve OAuth tokens. [Hannes] Proposed text: "The use of client credentials (such as "client_secret") is optional and depends on the type of client." Client credentials are most often bound to particular instances of a client and should not be shared between instances. Note that since not all types of clients have client credentials, they cannot be used to manage client registrations at the client configuration endpoint. The client credentials can be rotated through the use of the client update method on the client configuration endpoint. The client credentials cannot be used for authentication at the client registration endpoint or at the client configuration endpoint. [hannes] Why do you mean that they cannot be used for authentication? What happens if a client uses a client credential in the interaction with these endpoints? B.1. Credential Rotation The authorization server MAY rotate the client's registration access token and/or client credentials (such as a "client_secret") throughout the lifetime of the client in order to minimize the risk of leakage of these credentials. [Hannes] Proposed text: "The authorization server may be configured to issue new registration access tokens and/or client credentials (such as a "client_secret") to the client throughout the lifetime of the client instance to limit the lifetime of the credentials. This may help to minimize impact of exposed credentials." [Hannes] Note also that the registration access token is a mandatory field in the client information response and so it appears that this rotation in some sense happens with every request/response unless the authorization server returns the same info all the time (which would be very wasteful). The client can discover that these values have changed by reading the client information response returned from either a read or update request to the client configuration endpoint. [Hannes] Proposed Text: "The authorization server conveys new new registration access tokens and/or client credentials to the client in the client information response of either a read or update request to the client configuration endpoint."= The client's current registration access token and client credentials (if applicable) MUST be included in this response. [Hannes] Shouldn't that read "The client's current registration access token and client credentials (if applicable) MUST be included in the request." The registration access token SHOULD be rotated only in response to an update request to the client configuration endpoint, at which point the new registration access token is returned to the client and the old registration access token SHOULD be discarded by both parties. [Hannes] We talked about the second SHOULD statement here on the mailing list before. I thought I convinced you to either turn it into a MUST or to tell the reader when to discard and it when it should not be discarded= =2E If you additionally take the text in Section 2.2 into account the entire story is inconsistent. Here is the text: " If the authorization server includes a new client secret and/or registration access token in its response, the client MUST immediately discard its previous client secret and/or registration access token. The value of the "client_id" MUST NOT change from the initial registration response. " Also the first SHOULD statement raises the question why it is there. Of course, it makes no sense to rotate the credential with a delete request. Is this what you are trying to say? I don't see why the registration access token cannot be rotated in response to a read request= =2E If the registration access token were to expire or be rotated outside of such requests, the client or developer might be locked out of managing the client's configuration. Methods by which the client can request credential rotation are outside the scope of this document. [Hannes] Proposed text: "Note that the authorization server decides about frequency of credential rotation and not the client." Ciao Hannes --mTUaaJnoF9U347rSorCDrju2nIA1kwEbA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUs+PVAAoJEGhJURNOOiAt1nYIAIlSSJkod9pgz0KOevjfoTV8 C9ryu3Vh1K1H+KzSlQh0SNu0brVqNj9t0NrdBG0xbsENlsV0IQdzYo7ssyU08g31 3OV1Pekh9MN29oGhRaAJMB1rjVM3RcbOciYivlvMzvIz8/9QC7wQMc/+mZPb2/JN tvZgzlnSPTGtXX3wO+PzhtfiTbFtPLWme09Ptfnd/YB4jNEjbZ0LSBBi2UI4HuPL wJl6fJ67B4CC3tY1ieK1xZQAAgwN8wFleTc967khlYpYupzmMqNzVYVctYvrlbo5 Bvq1XpR6zkbm/U4OJjwhW45OYRsB5YQ7pP0MtrOH+gZk4bsmt/7ke5OGhaUps70= =jPdw -----END PGP SIGNATURE----- --mTUaaJnoF9U347rSorCDrju2nIA1kwEbA-- From nobody Mon Jan 12 09:36:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9384D1ACCDE for ; Mon, 12 Jan 2015 09:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=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 GQ6Azecf70Yr for ; Mon, 12 Jan 2015 09:36:00 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6087D1ACD07 for ; Mon, 12 Jan 2015 09:36:00 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so33206058pab.5 for ; Mon, 12 Jan 2015 09:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=Zoi46yty1Zi3sCLfYT2mIWgkcuh8H40EbxiaxiGqZO4=; b=pM8xU9qT/G4wMB06VDAALXh0DHyDXW0KyCT1Ll/DVNKfiOo7VrQL8k6CinYlobZF0Y 5jVFvTjGZodrEK94SZ0yJrTqMV8TW6zT/zlOA7wYkCEoTyDp3gjFDsu+bX9SO44hHbS0 jI2h4x4VxcHpLV2vCIP78X6+JriDf9nGu/BnYn+ByiUFRTciuhmDGVBsnTIe28lpzMDe P+rAIg4yXMHCFHDOtIqk5ghyh7c0f60cjckoiHF1FVsEieRe19AtyOA84v4diVqdd0GA ygpExXIzkrS0Vj84U0+eVHilCcsYP/0N3fba4RPKWC1aMOL9yKzom8IsC9QlrK1BVaQw yjOA== X-Received: by 10.66.159.202 with SMTP id xe10mr38505281pab.46.1421084159431; Mon, 12 Jan 2015 09:35:59 -0800 (PST) Received: from monk (ip24-250-56-242.ri.ri.cox.net. [24.250.56.242]) by mx.google.com with ESMTPSA id t13sm7574431pdj.61.2015.01.12.09.35.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jan 2015 09:35:57 -0800 (PST) From: "Brock Allen" To: "'John Bradley'" References: <002401d02e69$43284220$c978c660$@gmail.com> <4CB069B6-093D-44A4-A0CC-82AE0E637285@ve7jtb.com> In-Reply-To: <4CB069B6-093D-44A4-A0CC-82AE0E637285@ve7jtb.com> Date: Mon, 12 Jan 2015 12:35:40 -0500 Message-ID: <004c01d02e8e$302e5180$908af480$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01D02E64.475ABA80" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHgJUIGBHg1bz2D1+UdLPO396LUSwHcTawxnI3vM5A= Content-Language: en-us Archived-At: Cc: OAuth@ietf.org Subject: Re: [OAUTH-WG] session status change notification questions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 17:36:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004D_01D02E64.475ABA80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yep, my mistake. Apologies for the spam (including this apology email). =20 -Brock =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Monday, January 12, 2015 8:21 AM To: Brock Allen Cc: OAuth@ietf.org Subject: Re: [OAUTH-WG] session status change notification questions =20 If you are talking about this spec = http://openid.net/specs/openid-connect-session-1_0.html, then the = correct list for questions is the openid Connect one at = http://lists.openid.net/mailman/listinfo/openid-specs-ab. =20 Session management is not currently a OAuth WG document. =20 John B. =20 On Jan 12, 2015, at 10:11 AM, Brock Allen > wrote: =20 A couple of questions about the session management spec related to the = status change notifications (section 4):=20 =20 1) Is there a working reference implementation of the JavaScript that = goes with the current draft of the spec? =20 =20 2) For the statement from section 4.2: =E2=80=9CThe OP iframe MUST = enforce that the caller has the same origin as its parent = frame.=E2=80=9D I=E2=80=99m uncertain how to do this in the OP iframe, = given that it seems to be a cross-origin security concern to ascertain = the origin of the parent window. I don=E2=80=99t think = =E2=80=98referrer=E2=80=99 is the most reliable approach. =20 =20 3) The spec states that the OP iframe and the RP iframe should be both = contained within the main RP window (so the iframes are siblings). Is = there a reason the RP iframe can=E2=80=99t contain the OP iframe? =20 If it can, then this would address my question #2 above, as the = source.window (on the message event args) can be compared to the = parent.window to ensure that only the parent is sending the messages. =20 =20 Thanks. =20 -Brock =20 _______________________________________________ OAuth mailing list OAuth@ietf.org = https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_004D_01D02E64.475ABA80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yep, my = mistake. Apologies for the spam (including this apology = email).

 =

-Brock=

 =

From:<= /b> = John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Monday, January = 12, 2015 8:21 AM
To: Brock Allen
Cc: = OAuth@ietf.org
Subject: Re: [OAUTH-WG] session status change = notification questions

 

If you are = talking about this spec http://o= penid.net/specs/openid-connect-session-1_0.html,  then the = correct list for questions is the openid Connect one at http://= lists.openid.net/mailman/listinfo/openid-specs-ab.

 

Session management is not currently a OAuth WG = document.

 

John B.

 

On Jan 12, 2015, at 10:11 AM, Brock Allen <brockallen@gmail.com> = wrote:

 

A couple = of questions about the session management spec related to the status = change notifications (section 4): 

 

1) Is = there a working reference implementation of the JavaScript that goes = with the current draft of the spec?

 

 

2) For the = statement from section 4.2: =E2=80=9CThe OP iframe MUST enforce that the = caller has the same origin as its parent frame.=E2=80=9D I=E2=80=99m = uncertain how to do this in the OP iframe, given that it seems to be a = cross-origin security concern to ascertain the origin of the parent = window. I don=E2=80=99t think =E2=80=98referrer=E2=80=99 is the most = reliable approach.

 

 

3) The = spec states that the OP iframe and the RP iframe should be both = contained within the main RP window (so the iframes are siblings). Is = there a reason the RP iframe can=E2=80=99t contain the OP = iframe?

 

If it can, = then this would address my question #2 above, as the source.window (on = the message event args) can be compared to the parent.window to ensure = that only the parent is sending the = messages.

 

 

Thanks.

 

-Brock

 

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth

 

------=_NextPart_000_004D_01D02E64.475ABA80-- From nobody Mon Jan 12 16:13:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BE31ACE1C; Mon, 12 Jan 2015 16:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PlsbCpLICtl; Mon, 12 Jan 2015 16:13:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 080751ACE3F; Mon, 12 Jan 2015 16:13:11 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113001311.28323.2958.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 16:13:11 -0800 Archived-At: Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'JSON Web Token (JWT)' to Proposed Standard (draft-ietf-oauth-json-web-token-32.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:13:23 -0000 The IESG has approved the following document: - 'JSON Web Token (JWT)' (draft-ietf-oauth-json-web-token-32.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Kathleen Moriarty and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ Technical Summary JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. Working Group Summary This document was uncontroversial. It defines a JSON-based security token format to increase interoperability both among OAuth deployments and in other application contexts as well. (ID tokens are specified in http://openid.net/specs/openid-connect-core-1_0.html#IDToken) Document Quality A substantial number of implementations exist, as documented at http://openid.net/developers/libraries/#jwt (scroll down to the 'JWT/JWS/JWE/JWK/JWA Implementations' section) An Excel sheet providing additional details about implementations can be found here: http://www.oauth-v2.org/wp-content/uploads/2014/04/JWT-Implementations.xlsx In last call, the discussions on "duplicate member names" also applies to this draft and is unresolved. This can get discussed generally as it applies to at least 3 of the drafts in the set under IESG review. Personnel The document shepherd is Hannes Tschofenig and the responsible area director is Kathleen Moriarty. IANA Note 'The registries use the 5226 'Specification Required' registration policy.' RFC Editor Note: This draft is part of a set of drafts that cross 2 working groups. I am working through the reviews (shepherd just confirmed them for the OAuth ones) and would like them processed as a set. The JOSE drafts will hopefully be ready shortly as well. The set includes (in order): 1 draft-ietf-jose-json-web-signature 2 draft-ietf-jose-json-web-encryption 3 draft-ietf-jose-json-web-key 4 draft-ietf-jose-json-web-algorithms 5 draft-ietf-oauth-json-web-token 6 draft-ietf-jose-cookbook 7 draft-ietf-oauth-assertions 8 draft-ietf-oauth-saml2-bearer 9 draft-ietf-oauth-jwt-bearer From nobody Mon Jan 12 16:15:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1A31ACE29; Mon, 12 Jan 2015 16:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhGdRHxjHlue; Mon, 12 Jan 2015 16:15:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4501ACE4D; Mon, 12 Jan 2015 16:15:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113001515.3307.23130.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 16:15:15 -0800 Archived-At: Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants' to Proposed Standard (draft-ietf-oauth-assertions-18.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:15:47 -0000 The IESG has approved the following document: - 'Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants' (draft-ietf-oauth-assertions-18.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Kathleen Moriarty and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ Technical Summary The Assertion Framework for OAuth 2.0 allows the use of assertions in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. Working Group Summary There was no controversy around this document. Document Quality The working group decided to separate the framework for assertion handling from instance documents supporting SAML assertion and JSON- based encoded tokens. Readers who want to implement the functionality also need to consult one of the extension documents, such as draft-ietf-oauth-saml2-bearer The draft previously went through IESG review and was sent back to the WG to improve interoperability. Updates have been made to address the prior concerns. Personnel The document shepherd is Hannes Tschofenig and the responsible-ish area director is Kathleen Moriarty. RFC Editor Note: This draft is part of a set of drafts that cross 2 working groups. I am working through the reviews (shepherd just confirmed them for the OAuth ones) and would like them processed as a set. The JOSE drafts will hopefully be ready shortly as well. The set includes (in order): 1 draft-ietf-jose-json-web-signature 2 draft-ietf-jose-json-web-encryption 3 draft-ietf-jose-json-web-key 4 draft-ietf-jose-json-web-algorithms 5 draft-ietf-oauth-json-web-token 6 draft-ietf-jose-cookbook 7 draft-ietf-oauth-assertions 8 draft-ietf-oauth-saml2-bearer 9 draft-ietf-oauth-jwt-bearer From nobody Mon Jan 12 16:17:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232FE1ACE3D; Mon, 12 Jan 2015 16:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgGNrXdZM0yA; Mon, 12 Jan 2015 16:17:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA441ACE56; Mon, 12 Jan 2015 16:16:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113001657.31239.18048.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 16:16:57 -0800 Archived-At: Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants' to Proposed Standard (draft-ietf-oauth-saml2-bearer-23.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:17:11 -0000 The IESG has approved the following document: - 'SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants' (draft-ietf-oauth-saml2-bearer-23.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Kathleen Moriarty and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ Technical Summary This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. Working Group Summary The OAuth assertion framework, which this document instantiates, has been submitted to the IESG before and was returned to the working group due to interoperability concerns. The working group has discussed those concerns and has worked on several iterations of the document to reduce the number of optional functionality. Along with the changes to the assertion framework document changes have been made to this document as well. Document Quality The document has gone through many iterations and has received substantial feedback. There are also multiple implementations of this draft noted in the shepherd writeup. Personnel The document shepherd is Hannes Tschofenig and the responsible area director is Kathleen Moriarty. IANA Note The document only adds entries to existing registries and does not define any new registries. RFC Editor Note: This draft is part of a set of drafts that cross 2 working groups. I am working through the reviews (shepherd just confirmed them for the OAuth ones) and would like them processed as a set. The JOSE drafts will hopefully be ready shortly as well. The set includes (in order): 1 draft-ietf-jose-json-web-signature 2 draft-ietf-jose-json-web-encryption 3 draft-ietf-jose-json-web-key 4 draft-ietf-jose-json-web-algorithms 5 draft-ietf-oauth-json-web-token 6 draft-ietf-jose-cookbook 7 draft-ietf-oauth-assertions 8 draft-ietf-oauth-saml2-bearer 9 draft-ietf-oauth-jwt-bearer From nobody Tue Jan 13 15:09:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7858F1B2B58 for ; Tue, 13 Jan 2015 15:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al2qTfKqn8Lv for ; Tue, 13 Jan 2015 15:09:02 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE191B2B32 for ; Tue, 13 Jan 2015 15:09:02 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 891C072E067; Tue, 13 Jan 2015 18:09:01 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 80C5672E05C; Tue, 13 Jan 2015 18:09:01 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0224.002; Tue, 13 Jan 2015 18:09:01 -0500 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHQLlidU4rOELMb8EiQ/dpBvkV0+Zy/AvOA Date: Tue, 13 Jan 2015 23:08:59 +0000 Message-ID: <9013AEED-9B4E-4F22-8E91-AE1430372530@mitre.org> References: <54B3ABF8.8050007@gmx.net> In-Reply-To: <54B3ABF8.8050007@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <856129CFEBDF2B4C81D87C671A487A51@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 23:09:05 -0000 Hi Hannes, thanks for the review. Comments inline. On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig = wrote: > Hi Justin, Hi all, >=20 > as noted in my status update I am trying to finalize the pending items. >=20 > Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my > review of draft-ietf-oauth-dyn-reg-management raised some questions > about the terminology. >=20 > If you look at the structure of the ToC then you will notice the followin= g: >=20 > 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13 > 3.1. Client Registration Request . . . . . . . . . . . . . . . 14 > 3.1.1. Client Registration Request Using a Software > Statement . . . . . . . . . . . . . . . . . . . . . . 15 > 3.2. Client Registration Response . . . . . . . . . . . . . . 16 > 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 4.1. Client Information Response . . . . . . . . . . . . . . . 17 > 4.2. Client Registration Error Response . . . . . . . . . . . 18 >=20 > There is no 'Client Registration Response' in the protocol (only the > Client Information Response) and section 3.2 is pretty much empty and > only points to the later sections. So, I would suggest to do the followin= g. >=20 > 3. Client Registration Endpoint > 3.1. Client Registration Request > 3.1.1. Client Registration Request Using a Software Statement > 3.2. Client Registration Response > 3.2.1. Client Information Response > 3.2.2. Client Registration Error Response >=20 > (A section with only a single sub-section is also a sign of a bad > structure.) >=20 I'm actually OK with this re-organization, as long as there's no objection = from the WG at this stage. I think what we have might be slightly vestigial= of the existing document. There *is* a client registration response, but i= t's one of two things: the information or error response. Collapsing them a= s above will likely make that section easier to read. Thoughts? > I re-read the terminology and looked at Figure 1 to see whether it makes > sense and it still does not. I know that there may be many different > deployment options but it should at least be clear to the reader where > information comes from and where does it go. >=20 > For example, when I try to follow the flow of the software statement > then I read the following: > " > Software Statement: In some cases, a software statement will be issued > directly by the organization or developer that creates the client softwar= e. > " >=20 > What does the figure tell us? It shows us that the client or developer > gets the software assertion. >=20 > +--------(A)- Initial Access Token (OPTIONAL) > | > | +----(B)- Software Statement (OPTIONAL) > | | > v v > +-----------+ +---------------+ > | |--(C)- Client Registration Request -->| Client | > | Client or | | Registration | > | Developer |<-(D)- Client Information Response ---| Endpoint | > | | +---------------+ > +-----------+ >=20 > Maybe we should illustrate one example that makes sense and then say > that there are others that could be used. The examples are included in Appendix A.=20 > It also does not make sense to > show the developer in the box together with the client since the > developer does not execute a protocol exchange with the client > registration endpoint. That's not true, a developer (person or organization) could very easily be = using the dynamic registration protocol on behalf of the software that they= 're developing. This is actually used in practice in a number of places, an= d if you'd like a concrete example just go to the MIT integration test site= : https://mitreid.org/manage/dev/dynreg (log in with user/password). >=20 > Here is a proposal for improving this: >=20 >=20 > FROM: >=20 > +--------(A)- Initial Access Token (OPTIONAL) > | > | +----(B)- Software Statement (OPTIONAL) > | | > v v > +-----------+ +---------------+ > | |--(C)- Client Registration Request -->| Client | > | Client or | | Registration | > | Developer |<-(D)- Client Information Response ---| Endpoint | > | | +---------------+ > +-----------+ >=20 > Figure 1: Abstract Dynamic Client Registration Flow >=20 > TO: >=20 > +-------- O -- (A)- Initial Access Token (OPTIONAL) > | /|\ > | +---- / \ -- (B)- Software Statement (OPTIONAL) > | | Client > | | Developer > | | > v v > +--------------+ +---------------+ > | |--(C)- Client Registration Request -->| Client | > | Client | | Registration | > | |<-(D)- Client Information Response ---| Endpoint | > +--------------+ +---------------+ >=20 > Figure 1: Abstract Dynamic Client Registration Flow >=20 >=20 > Alternatively, one could also separate the distribution of software > statements and the actual protocol exchange. Here is the proposal: >=20 > +--------(A)- Initial Access Token (OPTIONAL) > | > | +----(B)- Software Statement (OPTIONAL) > | | > v v > +-----------+ +---------------+ > | |--(C)- Client Registration Request -->| Client | > | Client | | Registration | > | |<-(D)- Client Information Response ---| Endpoint | > +-----------+ +---------------+ >=20 > Figure 1: Abstract Dynamic Client Registration Flow >=20 >=20 > +---------------+ > | Authorization | > | Server | > +---------------+ > | Initial > |(A) Access > | Token > v > O Client > +------ /|\ Developer > |+----- / \ > || > (A)||(B) Software > || Statement > vv > +-----------+ > | | > | Client | > | | > +-----------+ >=20 > Figure 2: Software Statement / Initial Access Token Distribution Example. >=20 This is inaccurate, as described above. I believe we should leave this as i= s. > Then, there is also this statement in the Software Statement definition: >=20 > " > In other cases, a > software statement will be issued by a third party organization > for use by the organization or developer that creates the client > software. > " >=20 > In the terminology section we are defining all the parties that are > involved and now this mysterious "third party organization" is > introduced. Is this one of the already defined parties or is this yet > another organization? This is just exemplary text, saying one way that it could happen. The "myst= erious" third party organization is someone who is not the authorization se= rver or software API publisher who issued the statement (those cases are co= vered by the preceding sentence). They're not a named party, it's just "who= ever made the software statement". We are not specifying which software sta= tements the AS decides to trust, since that's a policy decision outside of = our control as spec authors. Many authorization servers will only trust sof= tware statements that they issue, but others will have a configured set of = third parties that they will accept software statements from, probably as p= art of a trust framework. I think this text should be left as it is unless = there's a way to word this so that it doesn't sound like we're adding anoth= er explicitly named party to the mix. >=20 > Finally, the client developer is defined as a single individual or an > entire organization (i.e., a group of people). However, in the text you > write 'client developer or organization'. For example, look at the > software statement: >=20 > "In some cases, a software statement will be issued directly by the > organization or developer that creates the client software. > " >=20 > Wouldn't it be more consistent to use the client developer definition as > is and just turn this sentence into >=20 > " > In some cases, a software statement will be issued directly by the > client developer. > " >=20 Since "developer" can mean individual or organization, I'm fine with this s= implifying change as long as there's no objection from the WG. Thanks again for the review. -- Justin= From nobody Tue Jan 13 15:24:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2821B2B19 for ; Tue, 13 Jan 2015 15:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYPIEdRmdNG0 for ; Tue, 13 Jan 2015 15:24:09 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06501A87D5 for ; Tue, 13 Jan 2015 15:24:08 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0DNO4lL024193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jan 2015 23:24:05 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0DNO3ML012269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jan 2015 23:24:04 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0DNO39C009004; Tue, 13 Jan 2015 23:24:03 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Jan 2015 15:24:03 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Phil Hunt In-Reply-To: <9013AEED-9B4E-4F22-8E91-AE1430372530@mitre.org> Date: Tue, 13 Jan 2015 15:24:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54B3ABF8.8050007@gmx.net> <9013AEED-9B4E-4F22-8E91-AE1430372530@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1993) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 23:24:11 -0000 in line Phil @independentid www.independentid.com phil.hunt@oracle.com > On Jan 13, 2015, at 3:08 PM, Richer, Justin P. = wrote: >=20 > Hi Hannes, thanks for the review. Comments inline. >=20 > On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig = wrote: >=20 >> Hi Justin, Hi all, >>=20 >> as noted in my status update I am trying to finalize the pending = items. >>=20 >> Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my >> review of draft-ietf-oauth-dyn-reg-management raised some questions >> about the terminology. >>=20 >> If you look at the structure of the ToC then you will notice the = following: >>=20 >> 3. Client Registration Endpoint . . . . . . . . . . . . . . . . = 13 >> 3.1. Client Registration Request . . . . . . . . . . . . . . . = 14 >> 3.1.1. Client Registration Request Using a Software >> Statement . . . . . . . . . . . . . . . . . . . . . . = 15 >> 3.2. Client Registration Response . . . . . . . . . . . . . . = 16 >> 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >> 4.1. Client Information Response . . . . . . . . . . . . . . . = 17 >> 4.2. Client Registration Error Response . . . . . . . . . . . = 18 >>=20 >> There is no 'Client Registration Response' in the protocol (only the >> Client Information Response) and section 3.2 is pretty much empty and >> only points to the later sections. So, I would suggest to do the = following. >>=20 >> 3. Client Registration Endpoint >> 3.1. Client Registration Request >> 3.1.1. Client Registration Request Using a Software Statement >> 3.2. Client Registration Response >> 3.2.1. Client Information Response >> 3.2.2. Client Registration Error Response >>=20 >> (A section with only a single sub-section is also a sign of a bad >> structure.) >>=20 >=20 > I'm actually OK with this re-organization, as long as there's no = objection from the WG at this stage. I think what we have might be = slightly vestigial of the existing document. There *is* a client = registration response, but it's one of two things: the information or = error response. Collapsing them as above will likely make that section = easier to read. Thoughts? >=20 >> I re-read the terminology and looked at Figure 1 to see whether it = makes >> sense and it still does not. I know that there may be many different >> deployment options but it should at least be clear to the reader = where >> information comes from and where does it go. >>=20 >> For example, when I try to follow the flow of the software statement >> then I read the following: >> " >> Software Statement: In some cases, a software statement will be = issued >> directly by the organization or developer that creates the client = software. >> " >>=20 >> What does the figure tell us? It shows us that the client or = developer >> gets the software assertion. >>=20 >> +--------(A)- Initial Access Token (OPTIONAL) >> | >> | +----(B)- Software Statement (OPTIONAL) >> | | >> v v >> +-----------+ = +---------------+ >> | |--(C)- Client Registration Request -->| Client = | >> | Client or | | Registration = | >> | Developer |<-(D)- Client Information Response ---| Endpoint = | >> | | = +---------------+ >> +-----------+ >>=20 >> Maybe we should illustrate one example that makes sense and then say >> that there are others that could be used. >=20 > The examples are included in Appendix A.=20 >=20 >> It also does not make sense to >> show the developer in the box together with the client since the >> developer does not execute a protocol exchange with the client >> registration endpoint. >=20 > That's not true, a developer (person or organization) could very = easily be using the dynamic registration protocol on behalf of the = software that they're developing. This is actually used in practice in a = number of places, and if you'd like a concrete example just go to the = MIT integration test site: https://mitreid.org/manage/dev/dynreg (log in = with user/password). IMO. This defeats the purpose of dynamic registration. A developer that = wants to hand register would go through the SP=E2=80=99s developer = support pages as they do now. It also won=E2=80=99t work in cases where an individual client will = negotiate a client key (where the actual key is not shared and thus the = developer (or any other MITM) can=E2=80=99t get in between. >=20 >>=20 >> Here is a proposal for improving this: >>=20 >>=20 >> FROM: >>=20 >> +--------(A)- Initial Access Token (OPTIONAL) >> | >> | +----(B)- Software Statement (OPTIONAL) >> | | >> v v >> +-----------+ = +---------------+ >> | |--(C)- Client Registration Request -->| Client = | >> | Client or | | Registration = | >> | Developer |<-(D)- Client Information Response ---| Endpoint = | >> | | = +---------------+ >> +-----------+ >>=20 >> Figure 1: Abstract Dynamic Client Registration Flow >>=20 >> TO: >>=20 >> +-------- O -- (A)- Initial Access Token (OPTIONAL) >> | /|\ >> | +---- / \ -- (B)- Software Statement (OPTIONAL) >> | | Client >> | | Developer >> | | >> v v >> +--------------+ = +---------------+ >> | |--(C)- Client Registration Request -->| Client = | >> | Client | | Registration = | >> | |<-(D)- Client Information Response ---| Endpoint = | >> +--------------+ = +---------------+ >>=20 >> Figure 1: Abstract Dynamic Client Registration Flow >>=20 >>=20 >> Alternatively, one could also separate the distribution of software >> statements and the actual protocol exchange. Here is the proposal: >>=20 >> +--------(A)- Initial Access Token (OPTIONAL) >> | >> | +----(B)- Software Statement (OPTIONAL) >> | | >> v v >> +-----------+ +---------------+ >> | |--(C)- Client Registration Request -->| Client | >> | Client | | Registration | >> | |<-(D)- Client Information Response ---| Endpoint | >> +-----------+ +---------------+ >>=20 >> Figure 1: Abstract Dynamic Client Registration Flow >>=20 >>=20 >> +---------------+ >> | Authorization | >> | Server | >> +---------------+ >> | Initial >> |(A) Access >> | Token >> v >> O Client >> +------ /|\ Developer >> |+----- / \ >> || >> (A)||(B) Software >> || Statement >> vv >> +-----------+ >> | | >> | Client | >> | | >> +-----------+ >>=20 >> Figure 2: Software Statement / Initial Access Token Distribution = Example. >>=20 >=20 > This is inaccurate, as described above. I believe we should leave this = as is. >=20 >> Then, there is also this statement in the Software Statement = definition: >>=20 >> " >> In other cases, a >> software statement will be issued by a third party organization >> for use by the organization or developer that creates the client >> software. >> " >>=20 >> In the terminology section we are defining all the parties that are >> involved and now this mysterious "third party organization" is >> introduced. Is this one of the already defined parties or is this yet >> another organization? >=20 > This is just exemplary text, saying one way that it could happen. The = "mysterious" third party organization is someone who is not the = authorization server or software API publisher who issued the statement = (those cases are covered by the preceding sentence). They're not a named = party, it's just "whoever made the software statement". We are not = specifying which software statements the AS decides to trust, since = that's a policy decision outside of our control as spec authors. Many = authorization servers will only trust software statements that they = issue, but others will have a configured set of third parties that they = will accept software statements from, probably as part of a trust = framework. I think this text should be left as it is unless there's a = way to word this so that it doesn't sound like we're adding another = explicitly named party to the mix. >=20 >>=20 >> Finally, the client developer is defined as a single individual or an >> entire organization (i.e., a group of people). However, in the text = you >> write 'client developer or organization'. For example, look at the >> software statement: >>=20 >> "In some cases, a software statement will be issued directly by the >> organization or developer that creates the client software. >> " >>=20 >> Wouldn't it be more consistent to use the client developer definition = as >> is and just turn this sentence into >>=20 >> " >> In some cases, a software statement will be issued directly by the >> client developer. >> " >>=20 >=20 > Since "developer" can mean individual or organization, I'm fine with = this simplifying change as long as there's no objection from the WG. >=20 > Thanks again for the review. > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jan 13 15:26:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494571A87D5 for ; Tue, 13 Jan 2015 15:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWthbAurxi5X for ; Tue, 13 Jan 2015 15:26:21 -0800 (PST) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F761A1A86 for ; Tue, 13 Jan 2015 15:26:20 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q108so4729156qgd.1 for ; Tue, 13 Jan 2015 15:26:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=kD1Soq6uVIaH8LTBmJIDW6/1vNj3rPZFOBIOTxB+83o=; b=lWom37/zaTFu3UUX+orVwnBPc8n66QgVztMZ6ADJsCTpe/fM9Qi24FkogM2gl3ZN5d KPFZpoOClQ9m5VC1+injpGxy+KcFG5bh3elbg01kPMUDTuEi/W3SjGIXGU/C8urC3gUQ hBxv27uhgNhla4Ysj5QnyOHjJSd3DwLw8mZsM/OuFqYHgEGZA3GsFOeuUPzSTEOWdp9P j2TvQlq1xNZZxf/xHWQ/o+xemG6isZ66x2pB0AQaHJgxcx8AsMb+XgtpUIJbt/H2a/zx 6Vn+TO33BY2da4X+7JsM2Oh2fhxJxqj2/R2E2XBPzEcK0c3RBgANDihd8f/Rzg95f4DS Tgbw== X-Gm-Message-State: ALoCoQlKHRRAPpvgZRFe550oIPM7Ye28FN6On60bvDzm1kbfk4xMxX2n3ur9CwVvqju9sgrbX9aa X-Received: by 10.229.225.195 with SMTP id it3mr2023593qcb.24.1421191579969; Tue, 13 Jan 2015 15:26:19 -0800 (PST) Received: from [192.168.8.100] ([181.201.11.224]) by mx.google.com with ESMTPSA id j101sm18976290qge.10.2015.01.13.15.26.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 15:26:19 -0800 (PST) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_15AA85C3-D229-4C09-83C2-F5C16041E7EB"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <0C9709D9-42BE-4971-A1AD-9825811C69D7@ve7jtb.com> Date: Tue, 13 Jan 2015 20:26:15 -0300 To: OAuth WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [OAUTH-WG] oauth-pop-key-distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 23:26:24 -0000 --Apple-Mail=_15AA85C3-D229-4C09-83C2-F5C16041E7EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Looking at the text I noticed that.Sec 4.2 has an example that contains = a JWE as a key but a comment that the remainder of the plain JWK is = omitted. =20 That should probably be JWE. We should probably also have an example with the jwk object inline. One thing I think we have as a gap is that public clients have no real = protection for the refresh token.=20 Anyone intercepting any call to the token endpoint for a new AT will = get the RT and be able to get new POP keys for the AT. We don't currently have any examples in the spec of getting a key based = on a RT but it is required if you are using symmetric keys with multiple = RS. One thing that might work is to only provide a key to public clients = with the authorization_code grant_type. That protects the RT from being used if it is leaked by the app. I think Chuck Mortimore suggested on the list that the public client = could provide a public key as part of the initial Authz request, and = that key would be used to encrypt the token keys to the client. That is probably the most secure but would cause spop (yes we will = rename it) to intersect with pop key distribution. eg define a new code_challenge_method that sends a "jwk" as the = code_challenge and a signed jwt to the token endpoint as the = code_verifier. =20 Then using the code_challenge public key to encrypt the per AT key. That would be an extension of spop if we want to do it. At the moment I think the pop story for public clients/native apps is a = bit weak. =20 If people give me feedback plus any other updates for the key = distribution spec I will rev it over the next couple of days, as it = needs to be refreshed to keep it active. John B. --Apple-Mail=_15AA85C3-D229-4C09-83C2-F5C16041E7EB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMTMyMzI2MTZaMCMGCSqGSIb3DQEJBDEWBBTWXcHeWQoub9gn3oYRwjxR cyJOPjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAMsltHjJBfO4iVFDj2j+PCV7V1VXtwRw5Ip9JkR4H9qiznbrr1Tl3i Y44wbx/vfnoIsXhv/AKAALHFAKet70Hqrj2s+f/0wvASgVOcyKdfPI5+r4ioN+jLbhnBpwNfoiwo j34BxpoS1XR7GnQKSWdUll+AOP5mnBW9gbK2tPpiQudPA5HNnNQGaN5VpBgZq1Kl8/jVx2ziFacf xrKsO1f5D6z+PlBf+5TeQqZIhbpL2hFbjgjCaNUBMw/qi0SjsRS+uQGXtjthv6wOVr4UiUgPRGGd OzChye/82tkzAaMybfZjEpUtmzXSUPu+1fdkDy5w0HmF4HGPf7KcDG3nYY8rAAAAAAAA --Apple-Mail=_15AA85C3-D229-4C09-83C2-F5C16041E7EB-- From nobody Tue Jan 13 15:31:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC481B2BEF for ; Tue, 13 Jan 2015 15:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJrYUEG1qbj9 for ; Tue, 13 Jan 2015 15:31:20 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id B52AE1B2BCD for ; Tue, 13 Jan 2015 15:30:36 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6083072E04F; Tue, 13 Jan 2015 18:30:36 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 5749272E038; Tue, 13 Jan 2015 18:30:36 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0224.002; Tue, 13 Jan 2015 18:30:35 -0500 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHQLlidU4rOELMb8EiQ/dpBvkV0+Zy/AvOAgAAEM4CAAAHVAA== Date: Tue, 13 Jan 2015 23:30:34 +0000 Message-ID: References: <54B3ABF8.8050007@gmx.net> <9013AEED-9B4E-4F22-8E91-AE1430372530@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="Windows-1252" Content-ID: <42346A2E8F609449B9A3A2AB3C3A914E@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 23:31:22 -0000 >>=20 >>> It also does not make sense to >>> show the developer in the box together with the client since the >>> developer does not execute a protocol exchange with the client >>> registration endpoint. >>=20 >> That's not true, a developer (person or organization) could very easily = be using the dynamic registration protocol on behalf of the software that t= hey're developing. This is actually used in practice in a number of places,= and if you'd like a concrete example just go to the MIT integration test s= ite: https://mitreid.org/manage/dev/dynreg (log in with user/password). >=20 > IMO. This defeats the purpose of dynamic registration. A developer that w= ants to hand register would go through the SP=92s developer support pages a= s they do now. >=20 > It also won=92t work in cases where an individual client will negotiate a= client key (where the actual key is not shared and thus the developer (or = any other MITM) can=92t get in between. If it were only authenticated portal pages, then I'd agree with you, but it= 's not. The page I pointed to above is just a wrapper shell around the dyna= mic registration endpoint -- it doesn't even *need* the user's credentials = to function, but that's how our server is set up to present the page, which= might be confusing people. On our server, only server admins can access th= e "real" client registration page, which isn't as limited as the dynamic re= gistration page. There are other use cases that have things like build fram= eworks that do the registration on behalf of a client instance or version, = where it's the developer (in this case an organization/system) and not the = client software doing the registration.=20 Basically, there was a strong argument for leaving that particular door ope= n, all of which is documented in the Use Cases appendix and liberally on th= e list. -- Justin= From nobody Tue Jan 13 15:32:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE0C1B2B89 for ; Tue, 13 Jan 2015 15:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBEDQSU6Mor5 for ; Tue, 13 Jan 2015 15:31:55 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id D679E1B2BFE for ; Tue, 13 Jan 2015 15:31:42 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5905072E042; Tue, 13 Jan 2015 18:31:42 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 4B56672E040; Tue, 13 Jan 2015 18:31:42 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0224.002; Tue, 13 Jan 2015 18:31:41 -0500 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Dynamic Client Registration Management Thread-Index: AQHQLnnqv8eTlAcq7E+YOgPkXOZaDpy/CQiA Date: Tue, 13 Jan 2015 23:31:41 +0000 Message-ID: References: <54B3E3D5.9040502@gmx.net> In-Reply-To: <54B3E3D5.9040502@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 23:32:02 -0000 Hi Hannes, thanks for the review. Comments inline. On Jan 12, 2015, at 10:10 AM, Hannes Tschofenig = wrote: > Hi Justin, Hi all, >=20 > I re-read the latest version of the dynamic client registration > management document and I still have a few issues with the document. >=20 > Let me start with the document structure. >=20 > When you look at the ToC you will notice that there is something wrong. >=20 > 2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5 > 2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6 > 2.2. Client Update Request . . . . . . . . . . . . . . . . . . 6 > 2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9 > 3. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 10 > 3.1. Client Information Response . . . . . . . . . . . . . . . 10 > =09 > Figure 1 describes a number of request and responses, namely > * Client Registration Request and Client Information Response > * Read or Update Request and Client Information Response > * Delete Request and Delete Confirmation >=20 > Section 3 only covers the "Client Information Response". >=20 > It would of course been cleaner to have a response that matches the > request. This avoids confusion. But that's where we are right now. >=20 > Currently, most of the response message content is actually described in > Section 2 rather than in Section 3. >=20 > You may want to think about re-structure the text in the following way. > This would also cause you to re-think a lot of the data duplication issue= . >=20 > For example, an update request requires the client to re-submit all data > and then, in the response, the authorization server has to submit a lot > of the data back to the client again (even if it does not change it). > That does not sound right to me. >=20 >=20 > 2. Client Configuration Endpoint > 2.1. Client Registration Request and Client Information Response > 2.2. Client Read Request and Client Information Response > 2.3. Client Update Request and Client Information Response > 2.4. Client Delete Request and Delete Confirmation > =09 >=20 This suggestion sounds much more confusing than what's already there. Secti= on 3 describes the extensions to the client information response (as define= d in DynReg core) that are common to all the create, read, and update reque= sts. It describes the content of the response, while the information in sec= tion 2 describes the HTTP particulars that are going to be different depend= ing on what action you're taking. What you're suggesting would duplicate a = large amount of information unnecessarily. > Appendix B. Registration Tokens and Client Credentials >=20 > Throughout the course of the dynamic registration protocol, there are > three different classes of credentials in play, each with different > properties and targets. >=20 > o The initial access token is optionally used by the client or > developer at the registration endpoint. >=20 > s/client or developer/client As in the comments on the core Dynamic Registration protocol, "client or de= veloper" is correct. >=20 > This is an OAuth 2.0 > token that is used to authorize the initial client registration > request. The content, structure, generation, and validation of > this token are out of scope for this specification. The > authorization server can use this token to verify that the > presenter is allowed to dynamically register new clients. This > token may be shared among multiple instances of a client to allow > them to each register separately, thereby letting the > authorization server use this token to tie multiple instances of > registered clients (each with their own distinct client > identifier) back to the party to whom the initial access token was > issued, usually an application developer. This token should be > used only at the client registration endpoint. >=20 > [hannes] Is this correct? "should only be used at the client > registration endpoint" > It would be better to say that this must only be used at the client > registration endpoint since that was the purpose for creating it. >=20 We could instead say "This token is intended to be used only at the client = registration endpoint."=20 > o The registration access token is used by the client or developer > at the client configuration endpoint and represents the holder's > authorization to manage the registration of a client. >=20 > s/client or developer/client Again, no, it's correct as-is. >=20 > This is an > OAuth 2.0 bearer token that is issued from the client registration > endpoint in response to a client registration request and is > returned in a client information response. The registration > access token is uniquely bound to the client identifier and is > required to be presented with all calls to the client > configuration endpoint. The registration access token should be > protected and should not be shared between instances of a client > (otherwise, one instance could change or delete registration > values for all instances of the client). >=20 > [hannes] The registration access token must be confidentiality protected > in transit and also protected against unauthorized access when stored > locally on the client. >=20 That's correct, it's an OAuth bearer token and inherits the protections nee= ded thereupon. > In what cases do you envision the registration access token to be shared > among client instances? Only if somebody made a mistake? That's why we say not to do it. Think of i= t this way: if the developer uses dynamic registration and then bakes the r= egistration token into the client and then ships copies of said client to a= thousand different users, that registration token isn't much of a secret a= nymore. >=20 > The registration access > token can be rotated through the use of the client update method > on the client configuration endpoint. The registration access > token should be used only at the client configuration endpoint. >=20 > [hannes] Why 'should' and not 'must'? Again, we create this registration > access token specifically for the use with the client configuration > endpoint.=09 We've historically been light handed about telling people where to use thei= r tokens. It's possible that some people want to issue tokens that do multi= ple things beyond the registration endpoint, but that's the kind of thing w= e need more deployment experience around. I suggest we use the same text su= ggested above instead of a normative-sounding phrase: "This token is intend= ed to be used only at the client registration endpoint." Will that work? > =09 > o The client credentials (such as "client_secret") are optional > depending on the type of client and are used to retrieve OAuth > tokens. >=20 > [Hannes] Proposed text: "The use of client credentials (such as > "client_secret") is optional > and depends on the type of client." >=20 > Client credentials are most often bound to particular > instances of a client and should not be shared between instances. > Note that since not all types of clients have client credentials, > they cannot be used to manage client registrations at the client > configuration endpoint. The client credentials can be rotated > through the use of the client update method on the client > configuration endpoint. The client credentials cannot be used for > authentication at the client registration endpoint or at the > client configuration endpoint. >=20 > [hannes] Why do you mean that they cannot be used for authentication? > What happens if a client uses a client credential in the interaction > with these endpoints? It won't work to authenticate the client, if they're following the protocol= . That's what the registration access token is for. >=20 > B.1. Credential Rotation >=20 > The authorization server MAY rotate the client's registration access > token and/or client credentials (such as a "client_secret") > throughout the lifetime of the client in order to minimize the risk > of leakage of these credentials. >=20 > [Hannes] Proposed text: "The authorization server may be configured to > issue new registration access > tokens and/or client credentials (such as a "client_secret") to the > client > throughout the lifetime of the client instance to limit the lifetime > of the credentials. > This may help to minimize impact of exposed credentials." >=20 I'm fine with this suggested text, thanks! > [Hannes] Note also that the registration access token is a mandatory > field in the client information response and so it appears that this > rotation in some sense happens with every request/response unless the > authorization server returns the same info all the time (which would be > very wasteful). It *could* happen every time, yes. Clients doing the management API need to= be prepared for that. >=20 > The client can discover that these > values have changed by reading the client information response > returned from either a read or update request to the client > configuration endpoint. >=20 > [Hannes] Proposed Text: "The authorization server conveys new new > registration access > tokens and/or client credentials to the client in the client > information response of > either a read or update request to the client configuration endpoint." >=20 I'm Ok with this suggested text, thanks! > The client's current registration access > token and client credentials (if applicable) MUST be included in this > response. >=20 > [Hannes] Shouldn't that read "The client's current registration access > token and client credentials (if applicable) MUST be included in the > request." >=20 No, it's talking about the Client Information Response coming back from the= server. I'll amend the text to say "client information response" here so i= t's clear. > The registration access token SHOULD be rotated only in response to > an update request to the client configuration endpoint, at which > point the new registration access token is returned to the client and > the old registration access token SHOULD be discarded by both > parties. >=20 > [Hannes] We talked about the second SHOULD statement here on the mailing > list before. I thought I convinced you to either turn it into a MUST or > to tell the reader when to discard and it when it should not be discarded= . >=20 > If you additionally take the text in Section 2.2 into account the entire > story is inconsistent. Here is the text: >=20 > " If the > authorization server includes a new client secret and/or registration > access token in its response, the client MUST immediately discard its > previous client secret and/or registration access token. The value > of the "client_id" MUST NOT change from the initial registration > response. > " >=20 It's not inconsistent -- the client MUST throw out the token, and the serve= r SHOULD throw out the token if it can. There are plenty of OAuth implement= ations that use stateless tokens that can't be revoked actively but only ex= pire. In those cases, you've got two active tokens during the expiration wi= ndow, and that's a security/performance tradeoff made by the server impleme= ntors. What we really need is a new normative term: MUST IF POSSIBLE. Sugge= stions on how to do that? >=20 > Also the first SHOULD statement raises the question why it is there. Of > course, it makes no sense to rotate the credential with a delete > request. Is this what you are trying to say? I don't see why the > registration access token cannot be rotated in response to a read request= . We're trying to say "don't rotate the client's registration token or secret= without giving them a way to recover", using either update or read. Otherw= ise, the client won't be able to call the configuration endpoint because it= s credential for accessing said endpoint will be gone (which is the paragra= ph just below here, that you copy below).=20 I also believe that paragraph is supposed to say "update or read", and not = just "update", so I'll fix that inconsistency. >=20 > If the registration access token were to expire or be > rotated outside of such requests, the client or developer might be > locked out of managing the client's configuration. >=20 > Methods by which the client can request credential rotation are > outside the scope of this document. >=20 > [Hannes] Proposed text: "Note that the authorization server decides > about frequency of credential rotation and not the client." Thanks, I'll add that text to the end. -- Justin >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jan 13 16:05:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA7F1B2BC5 for ; Tue, 13 Jan 2015 16:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O1t9B1ry5Xj for ; Tue, 13 Jan 2015 16:05:40 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDF21ACE09 for ; Tue, 13 Jan 2015 16:05:39 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id l6so975524qcy.13 for ; Tue, 13 Jan 2015 16:05:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Zer9WaI+I1HTcwNZYB4UAhWfSlhUxF8nxNU18xrGMzw=; b=NTBlpKF8mFvIdQJNzaECHaUXJtZ8QJG45/qkIKaJYUYe2bIQLQpgMMPYU/Qjlu+iQL 4JzLHcQ9drUhoWHpzb+72GTbEHcjy0BQt1a5F5fuwpxuitEhg+xbACdakuSFzXRYhlrF f/R/FutLM+AHHr2JTCieIGo1F0/sssUwR5S4NFOfui7saztB6ideoO9U9TNQbZf6oJ2r yppnO6vFu52Lw6zc+r9PCHDAsIlzdN+TsSifZ+aH8SGlH/bHMuiU4E+TYWCBGTsLWtHe s3QZQTxPjMYZnQwAoqLFxUEO3CatzU5FODm/GEUOQTfZGQwm03ta5vqu3U90+F9gybB0 ++VA== X-Gm-Message-State: ALoCoQk+6OgwTdGHp0ds6M1fWCa7yEAEmPgSVLqj8m5HbGbnpbDBrJ74s+hRltAtI68FxT7YQHhY X-Received: by 10.140.88.48 with SMTP id s45mr2118353qgd.28.1421193939102; Tue, 13 Jan 2015 16:05:39 -0800 (PST) Received: from [192.168.8.100] ([181.201.11.224]) by mx.google.com with ESMTPSA id 4sm19048558qgh.22.2015.01.13.16.05.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 16:05:38 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B00AFB09-9EE8-460F-85C2-C4B288D7D6DD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: Date: Tue, 13 Jan 2015 21:05:33 -0300 Message-Id: <37FEC9CC-64CD-4AC7-A3C4-08A4F957B114@ve7jtb.com> References: <54B3ABF8.8050007@gmx.net> <9013AEED-9B4E-4F22-8E91-AE1430372530@mitre.org> To: Phil Hunt X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 00:05:43 -0000 --Apple-Mail=_B00AFB09-9EE8-460F-85C2-C4B288D7D6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have used the dynamic client registration API for building portals = for developers to register clients. =20 I am seeing that across several telco operators at the moment. Yes everyone could have custom web pages but this is at-least a common = way to build that sort of thing. This is not just about registering instances of native apps. The GSMA mobile connect profile is going to use dynamic client = registration based on a software statement from a trusted party to allow = web sites to register as clients to 800+ AS. Those sites may well be developers of there own client or have a central = admin for several clients. I don't think that we want to say that it is only the client that = interacts with the registration or management endpoint. =20 That is too limiting on the applications for this API. John B. > On Jan 13, 2015, at 8:24 PM, Phil Hunt wrote: >=20 > in line > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Jan 13, 2015, at 3:08 PM, Richer, Justin P. = wrote: >>=20 >> Hi Hannes, thanks for the review. Comments inline. >>=20 >> On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig = wrote: >>=20 >>> Hi Justin, Hi all, >>>=20 >>> as noted in my status update I am trying to finalize the pending = items. >>>=20 >>> Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my >>> review of draft-ietf-oauth-dyn-reg-management raised some questions >>> about the terminology. >>>=20 >>> If you look at the structure of the ToC then you will notice the = following: >>>=20 >>> 3. Client Registration Endpoint . . . . . . . . . . . . . . . . = 13 >>> 3.1. Client Registration Request . . . . . . . . . . . . . . . = 14 >>> 3.1.1. Client Registration Request Using a Software >>> Statement . . . . . . . . . . . . . . . . . . . . . . = 15 >>> 3.2. Client Registration Response . . . . . . . . . . . . . . = 16 >>> 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >>> 4.1. Client Information Response . . . . . . . . . . . . . . . = 17 >>> 4.2. Client Registration Error Response . . . . . . . . . . . = 18 >>>=20 >>> There is no 'Client Registration Response' in the protocol (only the >>> Client Information Response) and section 3.2 is pretty much empty = and >>> only points to the later sections. So, I would suggest to do the = following. >>>=20 >>> 3. Client Registration Endpoint >>> 3.1. Client Registration Request >>> 3.1.1. Client Registration Request Using a Software Statement >>> 3.2. Client Registration Response >>> 3.2.1. Client Information Response >>> 3.2.2. Client Registration Error Response >>>=20 >>> (A section with only a single sub-section is also a sign of a bad >>> structure.) >>>=20 >>=20 >> I'm actually OK with this re-organization, as long as there's no = objection from the WG at this stage. I think what we have might be = slightly vestigial of the existing document. There *is* a client = registration response, but it's one of two things: the information or = error response. Collapsing them as above will likely make that section = easier to read. Thoughts? >>=20 >>> I re-read the terminology and looked at Figure 1 to see whether it = makes >>> sense and it still does not. I know that there may be many different >>> deployment options but it should at least be clear to the reader = where >>> information comes from and where does it go. >>>=20 >>> For example, when I try to follow the flow of the software statement >>> then I read the following: >>> " >>> Software Statement: In some cases, a software statement will be = issued >>> directly by the organization or developer that creates the client = software. >>> " >>>=20 >>> What does the figure tell us? It shows us that the client or = developer >>> gets the software assertion. >>>=20 >>> +--------(A)- Initial Access Token (OPTIONAL) >>> | >>> | +----(B)- Software Statement (OPTIONAL) >>> | | >>> v v >>> +-----------+ = +---------------+ >>> | |--(C)- Client Registration Request -->| Client = | >>> | Client or | | Registration = | >>> | Developer |<-(D)- Client Information Response ---| Endpoint = | >>> | | = +---------------+ >>> +-----------+ >>>=20 >>> Maybe we should illustrate one example that makes sense and then say >>> that there are others that could be used. >>=20 >> The examples are included in Appendix A.=20 >>=20 >>> It also does not make sense to >>> show the developer in the box together with the client since the >>> developer does not execute a protocol exchange with the client >>> registration endpoint. >>=20 >> That's not true, a developer (person or organization) could very = easily be using the dynamic registration protocol on behalf of the = software that they're developing. This is actually used in practice in a = number of places, and if you'd like a concrete example just go to the = MIT integration test site: https://mitreid.org/manage/dev/dynreg (log in = with user/password). >=20 > IMO. This defeats the purpose of dynamic registration. A developer = that wants to hand register would go through the SP=E2=80=99s developer = support pages as they do now. >=20 > It also won=E2=80=99t work in cases where an individual client will = negotiate a client key (where the actual key is not shared and thus the = developer (or any other MITM) can=E2=80=99t get in between. >=20 >>=20 >>>=20 >>> Here is a proposal for improving this: >>>=20 >>>=20 >>> FROM: >>>=20 >>> +--------(A)- Initial Access Token (OPTIONAL) >>> | >>> | +----(B)- Software Statement (OPTIONAL) >>> | | >>> v v >>> +-----------+ = +---------------+ >>> | |--(C)- Client Registration Request -->| Client = | >>> | Client or | | Registration = | >>> | Developer |<-(D)- Client Information Response ---| Endpoint = | >>> | | = +---------------+ >>> +-----------+ >>>=20 >>> Figure 1: Abstract Dynamic Client Registration Flow >>>=20 >>> TO: >>>=20 >>> +-------- O -- (A)- Initial Access Token (OPTIONAL) >>> | /|\ >>> | +---- / \ -- (B)- Software Statement (OPTIONAL) >>> | | Client >>> | | Developer >>> | | >>> v v >>> +--------------+ = +---------------+ >>> | |--(C)- Client Registration Request -->| Client = | >>> | Client | | Registration = | >>> | |<-(D)- Client Information Response ---| Endpoint = | >>> +--------------+ = +---------------+ >>>=20 >>> Figure 1: Abstract Dynamic Client Registration Flow >>>=20 >>>=20 >>> Alternatively, one could also separate the distribution of software >>> statements and the actual protocol exchange. Here is the proposal: >>>=20 >>> +--------(A)- Initial Access Token (OPTIONAL) >>> | >>> | +----(B)- Software Statement (OPTIONAL) >>> | | >>> v v >>> +-----------+ +---------------+ >>> | |--(C)- Client Registration Request -->| Client | >>> | Client | | Registration | >>> | |<-(D)- Client Information Response ---| Endpoint | >>> +-----------+ +---------------+ >>>=20 >>> Figure 1: Abstract Dynamic Client Registration Flow >>>=20 >>>=20 >>> +---------------+ >>> | Authorization | >>> | Server | >>> +---------------+ >>> | Initial >>> |(A) Access >>> | Token >>> v >>> O Client >>> +------ /|\ Developer >>> |+----- / \ >>> || >>> (A)||(B) Software >>> || Statement >>> vv >>> +-----------+ >>> | | >>> | Client | >>> | | >>> +-----------+ >>>=20 >>> Figure 2: Software Statement / Initial Access Token Distribution = Example. >>>=20 >>=20 >> This is inaccurate, as described above. I believe we should leave = this as is. >>=20 >>> Then, there is also this statement in the Software Statement = definition: >>>=20 >>> " >>> In other cases, a >>> software statement will be issued by a third party organization >>> for use by the organization or developer that creates the client >>> software. >>> " >>>=20 >>> In the terminology section we are defining all the parties that are >>> involved and now this mysterious "third party organization" is >>> introduced. Is this one of the already defined parties or is this = yet >>> another organization? >>=20 >> This is just exemplary text, saying one way that it could happen. The = "mysterious" third party organization is someone who is not the = authorization server or software API publisher who issued the statement = (those cases are covered by the preceding sentence). They're not a named = party, it's just "whoever made the software statement". We are not = specifying which software statements the AS decides to trust, since = that's a policy decision outside of our control as spec authors. Many = authorization servers will only trust software statements that they = issue, but others will have a configured set of third parties that they = will accept software statements from, probably as part of a trust = framework. I think this text should be left as it is unless there's a = way to word this so that it doesn't sound like we're adding another = explicitly named party to the mix. >>=20 >>>=20 >>> Finally, the client developer is defined as a single individual or = an >>> entire organization (i.e., a group of people). However, in the text = you >>> write 'client developer or organization'. For example, look at the >>> software statement: >>>=20 >>> "In some cases, a software statement will be issued directly by the >>> organization or developer that creates the client software. >>> " >>>=20 >>> Wouldn't it be more consistent to use the client developer = definition as >>> is and just turn this sentence into >>>=20 >>> " >>> In some cases, a software statement will be issued directly by the >>> client developer. >>> " >>>=20 >>=20 >> Since "developer" can mean individual or organization, I'm fine with = this simplifying change as long as there's no objection from the WG. >>=20 >> Thanks again for the review. >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B00AFB09-9EE8-460F-85C2-C4B288D7D6DD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMTQwMDA1MzRaMCMGCSqGSIb3DQEJBDEWBBT49uOU/Rw0HGX5p2w6NdJB 6tqwkTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBpqWeaHec9qvMlIK6dTHJfsWrkXgUuquuTc0dEgsuZ50pqkWmJnmAS n3gy4L/6LnaFSJ8s3TAaofqZ7MR8EnO7REJrNcfGwkq4B8/0Ur9oxPJ3plQF2Ty0+5LumT14E2w6 WIDl1iJClKHI32WARtd2C5oWo9XOkQRBZAsfL/qzYJuDRdFezLwUEbv4zrWUb09gRmCBc3Cu7z07 igUrdYdVipD8OvDvvWFu1gut1au/ZlEL4UgDoIS80aWAjw82nIt5cRE1nzk8GloaFZO3uhxGtmGe lEVLqSsuz2uV21pIZ9p0c2oz38XPeqMntwaPJ8xKNnYWjc0F3j9ajxay/zO1AAAAAAAA --Apple-Mail=_B00AFB09-9EE8-460F-85C2-C4B288D7D6DD-- From nobody Tue Jan 13 23:34:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CE11A8A50 for ; Tue, 13 Jan 2015 23:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 7znUqjycC4Kg for ; Tue, 13 Jan 2015 23:34:02 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (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 74D8D1A8AC8 for ; Tue, 13 Jan 2015 23:34:01 -0800 (PST) Received: from [79.253.63.146] (helo=[192.168.71.131]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YBISl-0003mz-BF; Wed, 14 Jan 2015 08:33:59 +0100 References: <0C9709D9-42BE-4971-A1AD-9825811C69D7@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0C9709D9-42BE-4971-A1AD-9825811C69D7@ve7jtb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <037ABA76-8414-4272-BAAA-327A92744FBC@lodderstedt.net> X-Mailer: iPad Mail (12B440) From: Torsten Lodderstedt Date: Wed, 14 Jan 2015 08:33:57 +0100 To: John Bradley X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] oauth-pop-key-distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 07:34:05 -0000 Hi John, > Am 14.01.2015 um 00:26 schrieb John Bradley : >=20 > We don't currently have any examples in the spec of getting a key based on= a RT but it is required if you are using symmetric keys with multiple RS. I think one could treat RTs like any other tokens in pop and issue a corresp= onding key. As a consequence refresh requests to the AS would be signed. Sou= nds straight forward to me (at least on a conceptual level). kind regards, Torsten.= From nobody Wed Jan 14 22:49:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFADF1B2B0B for ; Wed, 14 Jan 2015 22:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 4sQ_HkhBkFmw for ; Wed, 14 Jan 2015 22:49:16 -0800 (PST) Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA791B2AFB for ; Wed, 14 Jan 2015 22:49:15 -0800 (PST) Received: by mail-ie0-f195.google.com with SMTP id rd18so2568491iec.2 for ; Wed, 14 Jan 2015 22:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tz7YNkAAR8Suczs3zR0uoyB29endH4DoK7nwnznMaZU=; b=GjCsMvqC5h4xlyCw+UmC+FaeL3LxHqpIzycMsgqG/jZwpiCkLRDO1k1AwMIbrDbkdJ Uc23c+KaoG/sRHhS/mdWQB4vmobl6x71b4kgbmQuzvgZIkp4cgfZLuoNQPA0KWb6kEpH iMh5rkrHuuMZSZLHZ57IgSFMHAHE1/XmZKpj6d9pkq1PEUOS04tFEfN6pQcER1yCD+ij Lx8vsMZr1jy+g5PDswLwUs3HMvQw6A6Vnkvj8pA1SP1kHFQIwgcWbTBrYs6o8CFy9BpB qr/KBGwTYd1UjbtSGKgxcq5PMu5uf8ZwwsR8T4GvhZ2yIKpq6OCvqA2jwelP8T63ZVY8 zCBw== MIME-Version: 1.0 X-Received: by 10.107.161.138 with SMTP id k132mr8389014ioe.60.1421304555091; Wed, 14 Jan 2015 22:49:15 -0800 (PST) Received: by 10.107.16.29 with HTTP; Wed, 14 Jan 2015 22:49:15 -0800 (PST) Date: Thu, 15 Jan 2015 09:49:15 +0300 Message-ID: From: Andrea Keneth To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [OAUTH-WG] To Ask X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 06:49:17 -0000 -- An Keneth I Ask Help Admin There Are Some Events I Have Not Understanding From nobody Thu Jan 15 12:13:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4327D1B32C3 for ; Thu, 15 Jan 2015 12:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0qt_Dw-fMUs for ; Thu, 15 Jan 2015 12:13:02 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A941B3264 for ; Thu, 15 Jan 2015 12:13:02 -0800 (PST) Received: from BLUPR03MB152.namprd03.prod.outlook.com (10.255.212.28) by BLUPR03MB002.namprd03.prod.outlook.com (10.255.208.36) with Microsoft SMTP Server (TLS) id 15.1.65.13; Thu, 15 Jan 2015 20:13:00 +0000 Received: from CH1PR03CA011.namprd03.prod.outlook.com (10.255.156.156) by BLUPR03MB152.namprd03.prod.outlook.com (10.255.212.28) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 15 Jan 2015 20:12:59 +0000 Received: from BN1AFFO11FD059.protection.gbl (10.255.156.132) by CH1PR03CA011.outlook.office365.com (10.255.156.156) with Microsoft SMTP Server (TLS) id 15.1.59.20 via Frontend Transport; Thu, 15 Jan 2015 20:12:58 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD059.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Thu, 15 Jan 2015 20:12:58 +0000 Received: from TK5EX14MBXC291.redmond.corp.microsoft.com ([169.254.2.131]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0210.003; Thu, 15 Jan 2015 20:12:47 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: Proposed RFC Editor's note for draft-ietf-oauth-json-web-token Thread-Index: AdAw/598kpzhHacHQXyPC17umOvrvQ== Date: Thu, 15 Jan 2015 20:12:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439E650F2C@TK5EX14MBXC291.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439E650F2CTK5EX14MBXC291r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(288314003)(199003)(65554003)(105444003)(189002)(229853001)(84326002)(106466001)(6806004)(19580395003)(97736003)(86612001)(81156004)(46102003)(19300405004)(86362001)(110136001)(69596002)(230783001)(54356999)(55846006)(512954002)(102836002)(15975445007)(64706001)(26826002)(62966003)(104016003)(66066001)(2656002)(33656002)(87936001)(50986999)(19619215002)(19625215002)(16236675004)(92566002)(2900100001)(2920100001)(77156002)(68736005)(2930100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB152; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-DmarcStatus-Test: Passed X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(3003004)(3005004); SRVR:BLUPR03MB152; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR03MB152; X-Forefront-PRVS: 0457F11EAF X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB152; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2015 20:12:58.7796 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB152 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB002; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: Derek Atkins , "oauth@ietf.org" Subject: [OAUTH-WG] Proposed RFC Editor's note for draft-ietf-oauth-json-web-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 20:13:05 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439E650F2CTK5EX14MBXC291r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kathleen, After you approved the JWT spec, while editing the JOSE specs, I found a mi= ssing reference to the Unicode spec that was also missing in the JWT spec, = which had already been approved by that point. Per our conversation, I pro= pose that you send this editor's note: =3D=3D=3D=3D RFC Editor's Note for draft-ietf-oauth-json-web-token =3D=3D= =3D=3D A reference to the Unicode specification is missing. Please make these cha= nges to the XML source: OLD: algorithm is, the Unicode string encoding NEW: algorithm is, the Unicode strin= g encoding After the reference to RFC 20, ADD: The Unicode Standard The Unicode Consortium
Thank you, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439E650F2CTK5EX14MBXC291r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kathleen,

 

After you approved the JWT spec, while editing the J= OSE specs, I found a missing reference to the Unicode spec that was also mi= ssing in the JWT spec, which had already been approved by that point. = Per our conversation, I propose that you send this editor’s note:

 

=3D=3D=3D=3D RFC Editor’s Note for draft-ietf-= oauth-json-web-token =3D=3D=3D=3D

 

A reference to the Unicode specification is missing.=   Please make these changes to the XML source:

 

OLD:

        &nbs= p;        algorithm is, the Unicode string en= coding

NEW:

        &nbs= p;        algorithm is, the Unicode <xref = target=3D"UNICODE"/> string encoding

 

After the reference to RFC 20, ADD:

 

      <reference anchor= =3D"UNICODE" target=3D"http://www.unicode.org/versions/lates= t/">

        &nbs= p;      <front>

        &nbs= p;        <title abbrev=3D"Unicode&qu= ot;>The Unicode Standard</title>

        &nbs= p;        <author>

        &nbs= p;          <organization>The= Unicode Consortium</organization>

        &nbs= p;          <address /><= /o:p>

        &nbs= p;        </author>

        &nbs= p;        <date year=3D"1991-"/&= gt;

        &nbs= p;      </front>

        &nbs= p;      <!--

        &nbs= p;      <annotation>

        &nbs= p;        Note that this reference is to the = latest version of Unicode,

        &nbs= p;        rather than to a specific release.&= nbsp; It is not expected that future changes in

        &nbs= p;        the UNICODE specification will impa= ct the syntax of JSON or the UTF-8 encoding.

        &nbs= p;      </annotation>

        &nbs= p;      -->

      </reference>

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thank you,

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

 

--_000_4E1F6AAD24975D4BA5B16804296739439E650F2CTK5EX14MBXC291r_-- From nobody Thu Jan 15 13:39:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB60D1A6FD5; Thu, 15 Jan 2015 13:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj5LedcZTd_c; Thu, 15 Jan 2015 13:39:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95B1A87D5; Thu, 15 Jan 2015 13:39:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115213903.402.75574.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 13:39:03 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-22.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 21:39:06 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-22.txt Pages : 38 Date : 2015-01-15 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-22 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 Jan 15 13:39:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920571A6FD5; Thu, 15 Jan 2015 13:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UUckvhg7fxy; Thu, 15 Jan 2015 13:39:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD911A8859; Thu, 15 Jan 2015 13:39:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115213912.27113.43338.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 13:39:12 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 21:39:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-07.txt Pages : 17 Date : 2015-01-15 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-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 Thu Jan 15 13:53:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E821A8BBD for ; Thu, 15 Jan 2015 13:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcKRnsbtcUbO for ; Thu, 15 Jan 2015 13:53:43 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C81A8AAA for ; Thu, 15 Jan 2015 13:53:42 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 616B03AE08B for ; Thu, 15 Jan 2015 16:53:42 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 5A9243AE03E for ; Thu, 15 Jan 2015 16:53:42 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0224.002; Thu, 15 Jan 2015 16:53:41 -0500 From: "Richer, Justin P." To: "" Thread-Topic: New Version Notification - draft-ietf-oauth-dyn-reg-22.txt Thread-Index: AQHQMQu3u2fa7gbR+Emvjywh+XWRVJzCDS4A Date: Thu, 15 Jan 2015 21:53:41 +0000 Message-ID: References: <20150115213903.402.88632.idtracker@ietfa.amsl.com> In-Reply-To: <20150115213903.402.88632.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <9770453942648842B6E74BD5CD7AC00D@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification - draft-ietf-oauth-dyn-reg-22.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 21:53:45 -0000 A very minor update incorporating some of the changes suggested by Hannes (= mostly wording or document structure - the actual content of the document i= s effectively the same). -- Justin On Jan 15, 2015, at 4:39 PM, internet-drafts@ietf.org wrote: >=20 > A new version (-22) has been submitted for draft-ietf-oauth-dyn-reg: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-dyn-reg-22.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-22 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > IETF Secretariat. >=20 From nobody Thu Jan 15 13:54:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908621A8F4A for ; Thu, 15 Jan 2015 13:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwy9bEkELvAT for ; Thu, 15 Jan 2015 13:54:04 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0255C1A8AAA for ; Thu, 15 Jan 2015 13:54:04 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ABA183AE0D6 for ; Thu, 15 Jan 2015 16:54:03 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id A51C63AE082 for ; Thu, 15 Jan 2015 16:54:03 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0224.002; Thu, 15 Jan 2015 16:54:03 -0500 From: "Richer, Justin P." To: "" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-07.txt Thread-Index: AQHQMQvFcFLUVh3QK0utp5zCQEAVf5zCDUYA Date: Thu, 15 Jan 2015 21:54:02 +0000 Message-ID: <77F45EE6-1459-4AE0-AB3F-FC2835A9D2B2@mitre.org> References: <20150115213912.27113.43338.idtracker@ietfa.amsl.com> In-Reply-To: <20150115213912.27113.43338.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <4871AED5D3EA3446AE61C246ECBF7EF7@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 21:54:05 -0000 A very minor update incorporating some of the changes suggested by Hannes (= mostly wording or document structure - the actual content of the document i= s effectively the same). -- Justin On Jan 15, 2015, at 4:39 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. >=20 > Title : OAuth 2.0 Dynamic Client Registration Management= Protocol > Authors : Justin Richer > Michael B. Jones > John Bradley > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-management-07.txt > Pages : 17 > Date : 2015-01-15 >=20 > Abstract: > This specification defines methods for management of dynamic OAuth > 2.0 client registrations for use cases in which the properties of a > registered client may need to be changed during the lifetime of the > client. Not all authorization servers supporting dynamic client > registration will support these management methods. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-management-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jan 16 05:31:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644701ACDCC for ; Mon, 12 Jan 2015 11:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdPHhQt7g1iz; Mon, 12 Jan 2015 11:38:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4ED1ACDDD; Mon, 12 Jan 2015 11:38:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112193846.31713.67092.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 11:38:46 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:11 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 19:38:54 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ From nobody Fri Jan 16 05:31:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394891ACDEF for ; Mon, 12 Jan 2015 12:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozTSFARMEyAt; Mon, 12 Jan 2015 12:06:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9981ACE41; Mon, 12 Jan 2015 12:05:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112200524.15364.18554.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 12:05:24 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:14 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 20:06:20 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ From nobody Fri Jan 16 05:31:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FA41ACE43 for ; Mon, 12 Jan 2015 16:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDOOOHrqlCSf; Mon, 12 Jan 2015 16:14:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A01A91ACE48; Mon, 12 Jan 2015 16:14:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-assertions@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113001400.31615.96171.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 16:14:00 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:16 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:14:33 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ From nobody Fri Jan 16 05:31:30 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDFD1ACE43 for ; Mon, 12 Jan 2015 16:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geVDXQ3HTeb0; Mon, 12 Jan 2015 16:15:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D901ACE4A; Mon, 12 Jan 2015 16:15:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-assertions@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113001515.3307.87967.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 16:15:15 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:15:44 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ From nobody Fri Jan 16 05:31:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256A51ACE3F for ; Mon, 12 Jan 2015 16:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-JcAfuA0-s9; Mon, 12 Jan 2015 16:16:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CFD1ACE5B; Mon, 12 Jan 2015 16:15:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113001556.29537.96957.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 16:15:56 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:16:28 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ From nobody Fri Jan 16 05:31:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4921ACE3D for ; Mon, 12 Jan 2015 16:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6Ne-B6xK8Yq; Mon, 12 Jan 2015 16:17:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1534F1ACE52; Mon, 12 Jan 2015 16:16:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113001657.31239.26467.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 16:16:57 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:17:08 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ From nobody Fri Jan 16 05:31:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FD31A8873 for ; Mon, 12 Jan 2015 17:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGDw2GrCYHWI; Mon, 12 Jan 2015 17:34:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1708F1ACE50; Mon, 12 Jan 2015 17:34:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113013421.26689.12850.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 17:34:21 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:34:28 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ From nobody Fri Jan 16 05:31:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3311A1A8876 for ; Mon, 12 Jan 2015 17:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1n-qcIYLjOC; Mon, 12 Jan 2015 17:53:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD4B1A8866; Mon, 12 Jan 2015 17:53:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-assertions@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113015302.30331.20698.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 17:53:02 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:53:09 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ From nobody Fri Jan 16 05:31:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5381A8A14 for ; Mon, 12 Jan 2015 19:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxlQFGnXmzHf; Mon, 12 Jan 2015 19:07:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4143C1A8A05; Mon, 12 Jan 2015 19:06:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113030621.19614.74920.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 19:06:21 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:07:07 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ From nobody Fri Jan 16 05:31:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C741A8A16 for ; Mon, 12 Jan 2015 21:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP0JSNX_SNZi; Mon, 12 Jan 2015 21:06:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E41A8A17; Mon, 12 Jan 2015 21:06:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-assertions@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113050612.19134.69610.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 21:06:12 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 05:06:20 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ From nobody Fri Jan 16 05:31:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB6D1A8A1B for ; Mon, 12 Jan 2015 22:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JIO7EbJ4Ylq; Mon, 12 Jan 2015 22:05:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 211981A89EB; Mon, 12 Jan 2015 22:05:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113060527.4536.8922.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 22:05:27 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 06:05:31 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ From nobody Fri Jan 16 05:31:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF8D1ACD69 for ; Tue, 13 Jan 2015 12:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6qzJvr-cqmm; Tue, 13 Jan 2015 12:05:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0901ACD4F; Tue, 13 Jan 2015 12:05:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113200511.12129.341.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 12:05:11 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 20:05:14 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ From nobody Fri Jan 16 05:31:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530D1ACD54 for ; Tue, 13 Jan 2015 12:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTjZk_nOtken; Tue, 13 Jan 2015 12:05:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1771ACD4F; Tue, 13 Jan 2015 12:05:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-assertions@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113200513.12129.86393.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 12:05:13 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:17 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 20:05:28 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ From nobody Fri Jan 16 05:31:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C331ACDE8 for ; Wed, 14 Jan 2015 11:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUOkkEjCCS4V; Wed, 14 Jan 2015 11:06:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF341ACE19; Wed, 14 Jan 2015 11:06:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114190615.20325.50198.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 11:06:15 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:18 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 19:06:47 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ From nobody Fri Jan 16 05:31:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25EB1AD49D for ; Wed, 14 Jan 2015 12:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lHNlH2iR4zn; Wed, 14 Jan 2015 12:05:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 828D01B29A3; Wed, 14 Jan 2015 12:05:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-assertions@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114200513.11568.67003.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 12:05:13 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:18 -0800 Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 20:05:22 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ From amit.gupta@insideview.com Fri Jan 16 00:39:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E725B1A0194 for ; Fri, 16 Jan 2015 00:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XzHUR8_F1Qn for ; Fri, 16 Jan 2015 00:39:10 -0800 (PST) Received: from server506.appriver.com (server506i.appriver.com [50.56.144.147]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846501A6F2D for ; Fri, 16 Jan 2015 00:39:10 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/16/2015 2:39:08 AM X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Primary: amit.gupta@insideview.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-85/SG:5 1/16/2015 2:38:56 AM X-GBUdb-Analysis: 1, 169.254.1.45, Ugly c=1 p=-0.9966 Source White X-Signature-Violations: 0-0-0-22755-c X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->United States X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: smtp.exg6.exghost.com X-Note-Return-Path: amit.gupta@insideview.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 139610586; Fri, 16 Jan 2015 02:39:08 -0600 Received: from DAGN10A-E6.exg6.exghost.com ([169.254.1.45]) by HT03-E6.exg6.exghost.com ([50.56.144.21]) with mapi id 14.03.0210.002; Fri, 16 Jan 2015 02:39:08 -0600 From: Amit Gupta To: "torsten@lodderstedt.net" , "mscurtescu@google.com" , "sdronia@gmx.de" Thread-Topic: RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens Thread-Index: AdAxZRlLaRyw+19oS/CIjljjczH2vw== Date: Fri, 16 Jan 2015 08:39:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.61.191.156] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:18 -0800 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 08:40:59 -0000 --_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Torsten, Stefanie, Marius I wanted to suggest an addition to the token revocation rfc7009 to provide = more clarity on how revocation of refresh tokens should be handled. I feel = the rfc should, 1. Describe how the client/resource-owner can provide "standing instruction= s" to the OAuth server to revoke refresh tokens. 2. Describe the default way to for the OAuth server to define constrains fo= r revocation of refresh token if this constrains are not specified by the c= lient/resource owner. The way it could be handled is: 1. Store a Client level threshold (clt) of number of valid refresh tokens p= er "user-client" combination (and OAuth server can store the default value = for clt, if undefined by the client or resource owner). 2. Keep the "time to live" for the access token reasonably small (few minut= es to couple of hours). a. Revocation of active token removes the token ad the refresh token. b. When new tokens are generated, up to "clt" number of Refresh tokens is m= aintained by the OAuth server (the most recent refresh token over writes th= e cltth refresh token for user-client combination). c. Revocation of inactive token removes the refresh token. We have implemented such a scheme for our OAuth server, whereby "clt" is se= t to five by default (if not specified in client the properties). Therefore= , 1. Whenever a new token and refresh token is created, it overwrites the 5th= (clt=3D5) oldest refresh token (for clientId-userId combination). 2. Code grant tokens are only valid for 1 hour. When the token expires, ref= resh token is not removed. 3. When an "active" token is revoked, Token and it's refresh token is also = revoked. 4. When an "expired" token is revoked, only the corresponding refresh token= is revoked. The above example explicitly specify how to handle revocation of refresh to= kens when the client has not informed the OAuth server about how expiry of = refresh tokens should be handled. This also allows clients to specify certa= in constrains (like default time to live for tokens, and client level thres= hold for number of refresh tokens to keep active for each client-user combi= nation). Are you planning to update the RFC on the scheme to handle revocation of re= fresh token? If not, would you be willing to include the proposed changes t= o RFC7009? Please let me know. -- Thanks, Amit --_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi Torsten, Stefanie, Marius 
 
I wanted to suggest an addition to the token revocation rfc7009 t=
o provide more clarity on how revocation of refresh tokens should be handle=
d. I feel the rfc should,
1. Describe how the client/resource-owner ca=
n provide “standing instructions” to the OAuth server to revoke=
 refresh tokens. 
2. Describe the default way to for the OAuth=
 server to define constrains for revocation of refresh token if this constr=
ains are not specified by the client/resource owner.

 


The way it could be handled is:


1. Store a Client level threshold (clt) of number of vali=
d refresh tokens per “user-client” combination (and OAuth serve=
r can store the default value for clt, if undefined by the client or resour=
ce owner). 


2. Keep the “time to live” for t=
he access token reasonably small (few minutes to couple of hours). 


a. Revocation of active token removes the to=
ken ad the refresh token.


b. When new tokens are generated, up to R=
20;clt” number of Refresh tokens is maintained by the OAuth server (t=
he most recent refresh token over writes the cltth  refresh=
 token for user-client combination).


c. Revocation of inactive token removes the =
refresh token.


 


We have implemented such a scheme for our OAuth server, whereby &=
#8220;clt” is set to five by default (if not specified in client the =
properties). Therefore, 


1. Whenever a new token and refresh token is=
 created, it overwrites the 5th (clt=3D5) oldest refresh token (=
for clientId-userId combination). 


2. Code grant tokens are only valid for 1 ho=
ur. When the token expires, refresh token is not removed.=



3. When an “active” token is rev=
oked, Token and it’s refresh token is also revoked. 


4. When an “expired” token is re=
voked, only the corresponding refresh token is revoked. <=
/pre>

 


The above example explicitly specify how to handle revocation of =
refresh tokens when the client has not informed the OAuth server about how =
expiry of refresh tokens should be handled. This also allows clients to spe=
cify certain constrains (like default time to live for tokens, and client l=
evel threshold for number of refresh tokens to keep active for each client-=
user combination). 


 


Are you planning to update the RFC on the scheme to handle revoca=
tion of refresh token? If not, would you be willing to include the proposed=
 changes to RFC7009? Please let me know.


--


Thanks,


Amit


 
--_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_-- From nobody Fri Jan 16 05:37:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9806D1ACE01 for ; Fri, 16 Jan 2015 05:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1U-MYxjj_zn for ; Fri, 16 Jan 2015 05:37:44 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930B21ACDFC for ; Fri, 16 Jan 2015 05:37:44 -0800 (PST) X-AuditID: 12074423-f797b6d000000cfe-9b-54b914275eea Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.06.03326.72419B45; Fri, 16 Jan 2015 08:37:43 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t0GDbgbN015762; Fri, 16 Jan 2015 08:37:42 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0GDbdqb030752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 16 Jan 2015 08:37:40 -0500 Message-ID: <54B9141D.9040403@mit.edu> Date: Fri, 16 Jan 2015 08:37:33 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Amit Gupta , "torsten@lodderstedt.net" , "mscurtescu@google.com" , "sdronia@gmx.de" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040602050103080108060101" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixG6nrqsusjPEYOYlMYsZZx6zWdw6u4bJ 4uTbV2wWn2/PZbZ4dewpiwOrx4ePcR4LNpV6LFnyk8nj3uEbTB7HevpZA1ijuGxSUnMyy1KL 9O0SuDJu75zEVtA+ibHi4oklTA2MT+q6GDk5JARMJGa0/GaEsMUkLtxbz9bFyMUhJLCYSWLD tUZWCGcjo8S7o6+gnNtMEosOnWEHaeEVUJM4uPAnmM0ioCrxftU0ZhCbDcievqaFCcQWFYiS mH3+AStEvaDEyZlPWEBsEYFzjBJzj7iB2MxA9etXXwSrFxaolTjU9wxsppBAkMTZTzvAzuMU CJbYcP41M0R9mMTZl81sExgFZiEZOwtJCsK2lbgzdzczhC0v0bx1NpStK7Fo2wp2ZPEFjGyr GGVTcqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxgqPFRXkH45+DSocYBTgYlXh4Z2zZ ESLEmlhWXJl7iFGSg0lJlNdMaGeIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeDAGgHG9KYmVV alE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBC+fMFCjYFFqempFWmZOCUKaiYMT ZDgP0HB7kBre4oLE3OLMdIj8KUZFKXFeBZCEAEgiozQPrheWzF4xigO9IsxbDlLFA0yEcN2v gAYzAQ3Of7wDZHBJIkJKqoGR486f2l1Hj7retM1gMuY9dyv/3NUdt6NubFlo8kNTquneuky9 +TNZUmqVJ5VmSZcrLHkd22WsK/L0xVneO1rfbq1jjju0/p5fdpgSu+2W0IdntgnOL3y4R2vL WysNl5glbKmadhnCrd2d+x1suxedi/32P9NWasadmSeSG30nPH9qPZl5kXO6EktxRqKhFnNR cSIA8CUQYkEDAAA= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 13:37:52 -0000 This is a multi-part message in MIME format. --------------040602050103080108060101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit This seems to be more of an implementation of revocation and handling refresh token lifetimes than anything that the spec would talk about. In what's described below, it doesn't seem that the client ever specifies the threshold, nor would the AS desire the client to do so. This is all something that can happen server-side, out of the view of the client. In other words, I don't (personally) see what would have to change in the RFC for someone to implement this scheme. Can you please clarify what I'm missing? -- Justin On 1/16/2015 3:39 AM, Amit Gupta wrote: > Hi Torsten, Stefanie, Marius > > I wanted to suggest an addition to the token revocation rfc7009 to provide more clarity on how revocation of refresh tokens should be handled. I feel the rfc should, > 1. Describe how the client/resource-owner can provide “standing instructions” to the OAuth server to revoke refresh tokens. > 2. Describe the default way to for the OAuth server to define constrains for revocation of refresh token if this constrains are not specified by the client/resource owner. > > The way it could be handled is: > 1. Store a Client level threshold (clt) of number of valid refresh tokens per “user-client” combination (and OAuth server can store the default value for clt, if undefined by the client or resource owner). > 2. Keep the “time to live” for the access token reasonably small (few minutes to couple of hours). > a. Revocation of active token removes the token ad the refresh token. > b. When new tokens are generated, up to “clt” number of Refresh tokens is maintained by the OAuth server (the most recent refresh token over writes the clt^th refresh token for user-client combination). > c. Revocation of inactive token removes the refresh token. > > We have implemented such a scheme for our OAuth server, whereby “clt” is set to five by default (if not specified in client the properties). Therefore, > 1. Whenever a new token and refresh token is created, it overwrites the 5^th (clt=5) oldest refresh token (for clientId-userId combination). > 2. Code grant tokens are only valid for 1 hour. When the token expires, refresh token is not removed. > 3. When an “active” token is revoked, Token and it’s refresh token is also revoked. > 4. When an “expired” token is revoked, only the corresponding refresh token is revoked. > > The above example explicitly specify how to handle revocation of refresh tokens when the client has not informed the OAuth server about how expiry of refresh tokens should be handled. This also allows clients to specify certain constrains (like default time to live for tokens, and client level threshold for number of refresh tokens to keep active for each client-user combination). > > Are you planning to update the RFC on the scheme to handle revocation of refresh token? If not, would you be willing to include the proposed changes to RFC7009? Please let me know. > -- > Thanks, > Amit > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040602050103080108060101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
This seems to be more of an implementation of revocation and handling refresh token lifetimes than anything that the spec would talk about. In what's described below, it doesn't seem that the client ever specifies the threshold, nor would the AS desire the client to do so. This is all something that can happen server-side, out of the view of the client.

In other words, I don't (personally) see what would have to change in the RFC for someone to implement this scheme. Can you please clarify what I'm missing?

 -- Justin

On 1/16/2015 3:39 AM, Amit Gupta wrote:
Hi Torsten, Stefanie, Marius 
 
I wanted to suggest an addition to the token revocation rfc7009 to provide more clarity on how revocation of refresh tokens should be handled. I feel the rfc should,
1. Describe how the client/resource-owner can provide “standing instructions” to the OAuth server to revoke refresh tokens. 
2. Describe the default way to for the OAuth server to define constrains for revocation of refresh token if this constrains are not specified by the client/resource owner.
 
The way it could be handled is:
1. Store a Client level threshold (clt) of number of valid refresh tokens per “user-client” combination (and OAuth server can store the default value for clt, if undefined by the client or resource owner). 
2. Keep the “time to live” for the access token reasonably small (few minutes to couple of hours). 
a. Revocation of active token removes the token ad the refresh token.
b. When new tokens are generated, up to “clt” number of Refresh tokens is maintained by the OAuth server (the most recent refresh token over writes the cltth  refresh token for user-client combination).
c. Revocation of inactive token removes the refresh token.
 
We have implemented such a scheme for our OAuth server, whereby “clt” is set to five by default (if not specified in client the properties). Therefore, 
1. Whenever a new token and refresh token is created, it overwrites the 5th (clt=5) oldest refresh token (for clientId-userId combination). 
2. Code grant tokens are only valid for 1 hour. When the token expires, refresh token is not removed.
3. When an “active” token is revoked, Token and it’s refresh token is also revoked. 
4. When an “expired” token is revoked, only the corresponding refresh token is revoked. 
 
The above example explicitly specify how to handle revocation of refresh tokens when the client has not informed the OAuth server about how expiry of refresh tokens should be handled. This also allows clients to specify certain constrains (like default time to live for tokens, and client level threshold for number of refresh tokens to keep active for each client-user combination). 
 
Are you planning to update the RFC on the scheme to handle revocation of refresh token? If not, would you be willing to include the proposed changes to RFC7009? Please let me know.
--
Thanks,
Amit

 



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

--------------040602050103080108060101-- From nobody Fri Jan 16 08:10:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54AC1ACD77 for ; Fri, 16 Jan 2015 08:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWUwArKwlEeX for ; Fri, 16 Jan 2015 08:10:14 -0800 (PST) Received: from server506.appriver.com (server506h.appriver.com [50.56.144.38]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364B91ACE2B for ; Fri, 16 Jan 2015 08:10:12 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/16/2015 10:10:10 AM X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Primary: amit.gupta@insideview.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-455/SG:5 1/16/2015 10:10:00 AM X-GBUdb-Analysis: 1, 169.254.1.45, Ugly c=0.978586 p=-0.996694 Source White X-Signature-Violations: 0-0-0-21850-c X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->United States X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: smtp.exg6.exghost.com X-Note-Return-Path: amit.gupta@insideview.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 233655338; Fri, 16 Jan 2015 10:10:10 -0600 Received: from DAGN10A-E6.exg6.exghost.com ([169.254.1.45]) by HT03-E6.exg6.exghost.com ([50.56.144.21]) with mapi id 14.03.0210.002; Fri, 16 Jan 2015 10:10:10 -0600 From: Amit Gupta To: Justin Richer Thread-Topic: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens Thread-Index: AdAxpuZuaRyw+19oS/CIjljjczH2vw== Date: Fri, 16 Jan 2015 16:10:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_EC5D50A28C853445B767C0962CAD45720F7F2132DAGN10ae6exg6ex_" MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:10:16 -0000 --_000_EC5D50A28C853445B767C0962CAD45720F7F2132DAGN10ae6exg6ex_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByZXNlbnQgcmZjIGRvZXMgbm90IHNwZWNpZnkgaWYgdGhlIHNlcnZlciBzaG91bGQgaW5k ZWZpbml0ZWx5IGtlZXAgdGhlIHJlZnJlc2ggdG9rZW4gZnVuY3Rpb25hbCBmb3IgZXZlcnkgdG9r ZW4gKGV4Y2VwdCByZXZva2VkIG9uZXMpLCBhbmQgbW9zdCByZWZyZXNoIHRva2VucyBhcmUgbm90 IHVzZWQgKGR1ZSB0byBhdXRob3JpemUgd29ya2Zsb3cgaXMgdHJpZ2dlcmVkIGJ5IGNsaWVudHMg Zm9yIGF1dGhlbnRpY2F0aW9uIGFuZCByZXNvdXJjZSBhY2Nlc3MpLg0KDQpIZW5jZSwgSSBmZWVs IHRoZSByZmMgc2hvdWxkIHByb3ZpZGUgZ3VpZGFuY2UgZm9yIHRoZSB0cmFuc3BhcmVudCB3YXlz IHRvIGxpbWl0IHZhbGlkaXR5IG9mIHJlZnJlc2ggdG9rZW5zIGFuZCB3aGF0IHByb3BlcnR5L3Nl dHRpbmcgc2hvdWxkIGJlIHVzZWQgdG8gYXV0b21hdGljYWxseSBleHBpcmUgcmVmcmVzaCB0b2tl bnMsIGFuZCB3aG8gKGJldHdlZW4gdGhlIHNlcnZlciwgY2xpZW50IG9yIHVzZXQpIHNob3VsZCBi ZSBhYmxlIHRvIHNwZWNpZnkvbW9kaWZ5L3NlZSB0aGlzIHByb3BlcnR5KHMpLg0KDQpJbiBvdXIg aW1wbGVtZW50YXRpb24sIHRoZSBjbGllbnQgY2FuIHNwZWNpZnkvbW9kaWZ5IHRoaXMgcHJvcGVy dHkgKG9yIHNlcnZlciB0byBzZXQgZGVmYXVsdCkgdG8gbGltaXQgcmVmcmVzaCB0b2tlbnMuIEl0 cyBub3QgY2xlYXIgaWYgdGhlIHVzZXIgaGF2ZSB2aXNpYmlsaXR5IGluIG51bWJlciBvZiByZWZy ZXNoIHRva2VucyBiZWZvcmUgY29uc2VudCAob3IgYSBzYXkgaW4gcmVmcmVzaCB0b2tlbiByZXZv Y2F0aW9uKS4NCi0tDQpUaGFua3MsDQpBbWl0IEd1cHRhDQpTb2Z0d2FyZSBTZWN1cml0eSBBcmNo aXRlY3QsDQpJbnNpZGVWaWV3IEluYy4NCg0KU2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UsDQpQ bGVhc2UgZXhjdXNlIHNwZWxsaW5nIHR5cG9zLg0KDQpPbiBKYW4gMTYsIDIwMTUgNzowNyBQTSwg SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNClRoaXMgc2VlbXMgdG8gYmUg bW9yZSBvZiBhbiBpbXBsZW1lbnRhdGlvbiBvZiByZXZvY2F0aW9uIGFuZCBoYW5kbGluZyByZWZy ZXNoIHRva2VuIGxpZmV0aW1lcyB0aGFuIGFueXRoaW5nIHRoYXQgdGhlIHNwZWMgd291bGQgdGFs ayBhYm91dC4gSW4gd2hhdCdzIGRlc2NyaWJlZCBiZWxvdywgaXQgZG9lc24ndCBzZWVtIHRoYXQg dGhlIGNsaWVudCBldmVyIHNwZWNpZmllcyB0aGUgdGhyZXNob2xkLCBub3Igd291bGQgdGhlIEFT IGRlc2lyZSB0aGUgY2xpZW50IHRvIGRvIHNvLiBUaGlzIGlzIGFsbCBzb21ldGhpbmcgdGhhdCBj YW4gaGFwcGVuIHNlcnZlci1zaWRlLCBvdXQgb2YgdGhlIHZpZXcgb2YgdGhlIGNsaWVudC4NCg0K SW4gb3RoZXIgd29yZHMsIEkgZG9uJ3QgKHBlcnNvbmFsbHkpIHNlZSB3aGF0IHdvdWxkIGhhdmUg dG8gY2hhbmdlIGluIHRoZSBSRkMgZm9yIHNvbWVvbmUgdG8gaW1wbGVtZW50IHRoaXMgc2NoZW1l LiBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoYXQgSSdtIG1pc3Npbmc/DQoNCiAtLSBKdXN0aW4N Cg0KT24gMS8xNi8yMDE1IDM6MzkgQU0sIEFtaXQgR3VwdGEgd3JvdGU6DQoNCkhpIFRvcnN0ZW4s IFN0ZWZhbmllLCBNYXJpdXMNCg0KDQoNCkkgd2FudGVkIHRvIHN1Z2dlc3QgYW4gYWRkaXRpb24g dG8gdGhlIHRva2VuIHJldm9jYXRpb24gcmZjNzAwOSB0byBwcm92aWRlIG1vcmUgY2xhcml0eSBv biBob3cgcmV2b2NhdGlvbiBvZiByZWZyZXNoIHRva2VucyBzaG91bGQgYmUgaGFuZGxlZC4gSSBm ZWVsIHRoZSByZmMgc2hvdWxkLA0KDQoxLiBEZXNjcmliZSBob3cgdGhlIGNsaWVudC9yZXNvdXJj ZS1vd25lciBjYW4gcHJvdmlkZSDigJxzdGFuZGluZyBpbnN0cnVjdGlvbnPigJ0gdG8gdGhlIE9B dXRoIHNlcnZlciB0byByZXZva2UgcmVmcmVzaCB0b2tlbnMuDQoNCjIuIERlc2NyaWJlIHRoZSBk ZWZhdWx0IHdheSB0byBmb3IgdGhlIE9BdXRoIHNlcnZlciB0byBkZWZpbmUgY29uc3RyYWlucyBm b3IgcmV2b2NhdGlvbiBvZiByZWZyZXNoIHRva2VuIGlmIHRoaXMgY29uc3RyYWlucyBhcmUgbm90 IHNwZWNpZmllZCBieSB0aGUgY2xpZW50L3Jlc291cmNlIG93bmVyLg0KDQoNCg0KVGhlIHdheSBp dCBjb3VsZCBiZSBoYW5kbGVkIGlzOg0KDQoxLiBTdG9yZSBhIENsaWVudCBsZXZlbCB0aHJlc2hv bGQgKGNsdCkgb2YgbnVtYmVyIG9mIHZhbGlkIHJlZnJlc2ggdG9rZW5zIHBlciDigJx1c2VyLWNs aWVudOKAnSBjb21iaW5hdGlvbiAoYW5kIE9BdXRoIHNlcnZlciBjYW4gc3RvcmUgdGhlIGRlZmF1 bHQgdmFsdWUgZm9yIGNsdCwgaWYgdW5kZWZpbmVkIGJ5IHRoZSBjbGllbnQgb3IgcmVzb3VyY2Ug b3duZXIpLg0KDQoyLiBLZWVwIHRoZSDigJx0aW1lIHRvIGxpdmXigJ0gZm9yIHRoZSBhY2Nlc3Mg dG9rZW4gcmVhc29uYWJseSBzbWFsbCAoZmV3IG1pbnV0ZXMgdG8gY291cGxlIG9mIGhvdXJzKS4N Cg0KYS4gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW4gcmVtb3ZlcyB0aGUgdG9rZW4gYWQgdGhl IHJlZnJlc2ggdG9rZW4uDQoNCmIuIFdoZW4gbmV3IHRva2VucyBhcmUgZ2VuZXJhdGVkLCB1cCB0 byDigJxjbHTigJ0gbnVtYmVyIG9mIFJlZnJlc2ggdG9rZW5zIGlzIG1haW50YWluZWQgYnkgdGhl IE9BdXRoIHNlcnZlciAodGhlIG1vc3QgcmVjZW50IHJlZnJlc2ggdG9rZW4gb3ZlciB3cml0ZXMg dGhlIGNsdHRoICByZWZyZXNoIHRva2VuIGZvciB1c2VyLWNsaWVudCBjb21iaW5hdGlvbikuDQoN CmMuIFJldm9jYXRpb24gb2YgaW5hY3RpdmUgdG9rZW4gcmVtb3ZlcyB0aGUgcmVmcmVzaCB0b2tl bi4NCg0KDQoNCldlIGhhdmUgaW1wbGVtZW50ZWQgc3VjaCBhIHNjaGVtZSBmb3Igb3VyIE9BdXRo IHNlcnZlciwgd2hlcmVieSDigJxjbHTigJ0gaXMgc2V0IHRvIGZpdmUgYnkgZGVmYXVsdCAoaWYg bm90IHNwZWNpZmllZCBpbiBjbGllbnQgdGhlIHByb3BlcnRpZXMpLiBUaGVyZWZvcmUsDQoNCjEu IFdoZW5ldmVyIGEgbmV3IHRva2VuIGFuZCByZWZyZXNoIHRva2VuIGlzIGNyZWF0ZWQsIGl0IG92 ZXJ3cml0ZXMgdGhlIDV0aCAoY2x0PTUpIG9sZGVzdCByZWZyZXNoIHRva2VuIChmb3IgY2xpZW50 SWQtdXNlcklkIGNvbWJpbmF0aW9uKS4NCg0KMi4gQ29kZSBncmFudCB0b2tlbnMgYXJlIG9ubHkg dmFsaWQgZm9yIDEgaG91ci4gV2hlbiB0aGUgdG9rZW4gZXhwaXJlcywgcmVmcmVzaCB0b2tlbiBp cyBub3QgcmVtb3ZlZC4NCg0KMy4gV2hlbiBhbiDigJxhY3RpdmXigJ0gdG9rZW4gaXMgcmV2b2tl ZCwgVG9rZW4gYW5kIGl04oCZcyByZWZyZXNoIHRva2VuIGlzIGFsc28gcmV2b2tlZC4NCg0KNC4g V2hlbiBhbiDigJxleHBpcmVk4oCdIHRva2VuIGlzIHJldm9rZWQsIG9ubHkgdGhlIGNvcnJlc3Bv bmRpbmcgcmVmcmVzaCB0b2tlbiBpcyByZXZva2VkLg0KDQoNCg0KVGhlIGFib3ZlIGV4YW1wbGUg ZXhwbGljaXRseSBzcGVjaWZ5IGhvdyB0byBoYW5kbGUgcmV2b2NhdGlvbiBvZiByZWZyZXNoIHRv a2VucyB3aGVuIHRoZSBjbGllbnQgaGFzIG5vdCBpbmZvcm1lZCB0aGUgT0F1dGggc2VydmVyIGFi b3V0IGhvdyBleHBpcnkgb2YgcmVmcmVzaCB0b2tlbnMgc2hvdWxkIGJlIGhhbmRsZWQuIFRoaXMg YWxzbyBhbGxvd3MgY2xpZW50cyB0byBzcGVjaWZ5IGNlcnRhaW4gY29uc3RyYWlucyAobGlrZSBk ZWZhdWx0IHRpbWUgdG8gbGl2ZSBmb3IgdG9rZW5zLCBhbmQgY2xpZW50IGxldmVsIHRocmVzaG9s ZCBmb3IgbnVtYmVyIG9mIHJlZnJlc2ggdG9rZW5zIHRvIGtlZXAgYWN0aXZlIGZvciBlYWNoIGNs aWVudC11c2VyIGNvbWJpbmF0aW9uKS4NCg0KDQoNCkFyZSB5b3UgcGxhbm5pbmcgdG8gdXBkYXRl IHRoZSBSRkMgb24gdGhlIHNjaGVtZSB0byBoYW5kbGUgcmV2b2NhdGlvbiBvZiByZWZyZXNoIHRv a2VuPyBJZiBub3QsIHdvdWxkIHlvdSBiZSB3aWxsaW5nIHRvIGluY2x1ZGUgdGhlIHByb3Bvc2Vk IGNoYW5nZXMgdG8gUkZDNzAwOT8gUGxlYXNlIGxldCBtZSBrbm93Lg0KDQotLQ0KDQpUaGFua3Ms DQoNCkFtaXQNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQoNCg0K --_000_EC5D50A28C853445B767C0962CAD45720F7F2132DAGN10ae6exg6ex_ Content-Type: text/html; charset="utf-8" Content-ID: <94813BBA314C9F4AB95C99362829D937@fwd6.exghost.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi PjwvcD4NCjxwIGRpcj0ibHRyIj5UaGUgcHJlc2VudCByZmMgZG9lcyBub3Qgc3BlY2lmeSBpZiB0 aGUgc2VydmVyIHNob3VsZCBpbmRlZmluaXRlbHkga2VlcCB0aGUgcmVmcmVzaCB0b2tlbiBmdW5j dGlvbmFsIGZvciBldmVyeSB0b2tlbiAoZXhjZXB0IHJldm9rZWQgb25lcyksIGFuZCBtb3N0IHJl ZnJlc2ggdG9rZW5zIGFyZSBub3QgdXNlZCAoZHVlIHRvIGF1dGhvcml6ZSB3b3JrZmxvdyBpcyB0 cmlnZ2VyZWQgYnkgY2xpZW50cyBmb3IgYXV0aGVudGljYXRpb24NCiBhbmQgcmVzb3VyY2UgYWNj ZXNzKS4gPC9wPg0KPHAgZGlyPSJsdHIiPkhlbmNlLCBJIGZlZWwgdGhlIHJmYyBzaG91bGQgcHJv dmlkZSBndWlkYW5jZSBmb3IgdGhlIHRyYW5zcGFyZW50IHdheXMgdG8gbGltaXQgdmFsaWRpdHkg b2YgcmVmcmVzaCB0b2tlbnMgYW5kIHdoYXQgcHJvcGVydHkvc2V0dGluZyBzaG91bGQgYmUgdXNl ZCB0byBhdXRvbWF0aWNhbGx5IGV4cGlyZSByZWZyZXNoIHRva2VucywgYW5kIHdobyAoYmV0d2Vl biB0aGUgc2VydmVyLCBjbGllbnQgb3IgdXNldCkgc2hvdWxkIGJlIGFibGUNCiB0byBzcGVjaWZ5 L21vZGlmeS9zZWUgdGhpcyBwcm9wZXJ0eShzKS48L3A+DQo8cCBkaXI9Imx0ciI+SW4gb3VyIGlt cGxlbWVudGF0aW9uLCB0aGUgY2xpZW50IGNhbiBzcGVjaWZ5L21vZGlmeSB0aGlzIHByb3BlcnR5 IChvciBzZXJ2ZXIgdG8gc2V0IGRlZmF1bHQpIHRvIGxpbWl0IHJlZnJlc2ggdG9rZW5zLiBJdHMg bm90IGNsZWFyIGlmIHRoZSB1c2VyIGhhdmUgdmlzaWJpbGl0eSBpbiBudW1iZXIgb2YgcmVmcmVz aCB0b2tlbnMgYmVmb3JlIGNvbnNlbnQgKG9yIGEgc2F5IGluIHJlZnJlc2ggdG9rZW4gcmV2b2Nh dGlvbikuPGJyPg0KLS08YnI+DQpUaGFua3MsPGJyPg0KQW1pdCBHdXB0YTxicj4NClNvZnR3YXJl IFNlY3VyaXR5IEFyY2hpdGVjdCwgPGJyPg0KSW5zaWRlVmlldyBJbmMuPC9wPg0KPHAgZGlyPSJs dHIiPlNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNlLDxicj4NClBsZWFzZSBleGN1c2Ugc3BlbGxp bmcgdHlwb3MuPC9wPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEphbiAxNiwgMjAxNSA3 OjA3IFBNLCBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7IHdyb3RlOjxiciB0 eXBlPSJhdHRyaWJ1dGlvbiI+DQo8YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXY+DQo8ZGl2PlRoaXMgc2VlbXMgdG8gYmUgbW9yZSBvZiBhbiBpbXBsZW1lbnRhdGlv biBvZiByZXZvY2F0aW9uIGFuZCBoYW5kbGluZyByZWZyZXNoIHRva2VuIGxpZmV0aW1lcyB0aGFu IGFueXRoaW5nIHRoYXQgdGhlIHNwZWMgd291bGQgdGFsayBhYm91dC4gSW4gd2hhdCdzIGRlc2Ny aWJlZCBiZWxvdywgaXQgZG9lc24ndCBzZWVtIHRoYXQgdGhlIGNsaWVudCBldmVyIHNwZWNpZmll cyB0aGUgdGhyZXNob2xkLCBub3Igd291bGQgdGhlIEFTIGRlc2lyZQ0KIHRoZSBjbGllbnQgdG8g ZG8gc28uIFRoaXMgaXMgYWxsIHNvbWV0aGluZyB0aGF0IGNhbiBoYXBwZW4gc2VydmVyLXNpZGUs IG91dCBvZiB0aGUgdmlldyBvZiB0aGUgY2xpZW50Ljxicj4NCjxicj4NCkluIG90aGVyIHdvcmRz LCBJIGRvbid0IChwZXJzb25hbGx5KSBzZWUgd2hhdCB3b3VsZCBoYXZlIHRvIGNoYW5nZSBpbiB0 aGUgUkZDIGZvciBzb21lb25lIHRvIGltcGxlbWVudCB0aGlzIHNjaGVtZS4gQ2FuIHlvdSBwbGVh c2UgY2xhcmlmeSB3aGF0IEknbSBtaXNzaW5nPzxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjxi cj4NCjxicj4NCk9uIDEvMTYvMjAxNSAzOjM5IEFNLCBBbWl0IEd1cHRhIHdyb3RlOjxicj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGU+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy cHQ7Y29sb3I6YmxhY2siPkhpIFRvcnN0ZW4sIFN0ZWZhbmllLCBNYXJpdXMgPC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNr Ij5JIHdhbnRlZCB0byBzdWdnZXN0IGFuIGFkZGl0aW9uIHRvIHRoZSB0b2tlbiByZXZvY2F0aW9u IHJmYzcwMDkgdG8gcHJvdmlkZSBtb3JlIGNsYXJpdHkgb24gaG93IHJldm9jYXRpb24gb2YgcmVm cmVzaCB0b2tlbnMgc2hvdWxkIGJlIGhhbmRsZWQuIEkgZmVlbCB0aGUgcmZjIHNob3VsZCw8L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDowLjVpbjt0ZXh0LWluZGVudDotMC4y NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPjEuPHNwYW4gc3R5 bGU9ImZvbnQ6N3B0ICd0aW1lcyBuZXcgcm9tYW4nIj4gPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPkRlc2NyaWJlIGhvdyB0aGUgY2xpZW50L3Jl c291cmNlLW93bmVyIGNhbiBwcm92aWRlIOKAnHN0YW5kaW5nIGluc3RydWN0aW9uc+KAnSB0byB0 aGUgT0F1dGggc2VydmVyIHRvIHJldm9rZSByZWZyZXNoIHRva2Vucy4gPC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MC41aW47dGV4dC1pbmRlbnQ6LTAuMjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNrIj4yLjxzcGFuIHN0eWxlPSJmb250Ojdw dCAndGltZXMgbmV3IHJvbWFuJyI+IDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMnB0O2NvbG9yOmJsYWNrIj5EZXNjcmliZSB0aGUgZGVmYXVsdCB3YXkgdG8gZm9yIHRoZSBP QXV0aCBzZXJ2ZXIgdG8gZGVmaW5lIGNvbnN0cmFpbnMgZm9yIHJldm9jYXRpb24gb2YgcmVmcmVz aCB0b2tlbiBpZiB0aGlzIGNvbnN0cmFpbnMgYXJlIG5vdCBzcGVjaWZpZWQgYnkgdGhlIGNsaWVu dC9yZXNvdXJjZSBvd25lci48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTJwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPlRoZSB3YXkgaXQgY291bGQgYmUgaGFuZGxl ZCBpczo8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDowLjVpbjt0ZXh0LWlu ZGVudDotMC4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPjEu PHNwYW4gc3R5bGU9ImZvbnQ6N3B0ICd0aW1lcyBuZXcgcm9tYW4nIj4gPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPlN0b3JlIGEgQ2xpZW50IGxl dmVsIHRocmVzaG9sZCAoPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5jbHQ8L3NwYW4+ KSBvZiBudW1iZXIgb2YgdmFsaWQgcmVmcmVzaCB0b2tlbnMgcGVyIOKAnHVzZXItY2xpZW504oCd IGNvbWJpbmF0aW9uIChhbmQgT0F1dGggc2VydmVyIGNhbiBzdG9yZSB0aGUgZGVmYXVsdCB2YWx1 ZSBmb3IgY2x0LCBpZiB1bmRlZmluZWQgYnkgdGhlIGNsaWVudCBvciByZXNvdXJjZSBvd25lciku IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjAuNWluO3RleHQtaW5kZW50 Oi0wLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+Mi48c3Bh biBzdHlsZT0iZm9udDo3cHQgJ3RpbWVzIG5ldyByb21hbiciPiA8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+S2VlcCB0aGUg4oCcdGltZSB0byBs aXZl4oCdIGZvciB0aGUgYWNjZXNzIHRva2VuIHJlYXNvbmFibHkgc21hbGwgKGZldyBtaW51dGVz IHRvIGNvdXBsZSBvZiBob3VycykuIDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjFpbjt0ZXh0LWluZGVudDotMC4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7 Y29sb3I6YmxhY2siPmEuPHNwYW4gc3R5bGU9ImZvbnQ6N3B0ICd0aW1lcyBuZXcgcm9tYW4nIj4g PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPlJl dm9jYXRpb24gb2YgYWN0aXZlIHRva2VuIHJlbW92ZXMgdGhlIHRva2VuIGFkIHRoZSByZWZyZXNo IHRva2VuLjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjFpbjt0ZXh0LWlu ZGVudDotMC4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPmIu PHNwYW4gc3R5bGU9ImZvbnQ6N3B0ICd0aW1lcyBuZXcgcm9tYW4nIj4gPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPldoZW4gbmV3IHRva2VucyBh cmUgZ2VuZXJhdGVkLCB1cCB0byDigJxjbHTigJ0gbnVtYmVyIG9mIFJlZnJlc2ggdG9rZW5zIGlz IG1haW50YWluZWQgYnkgdGhlIE9BdXRoIHNlcnZlciAodGhlIG1vc3QgcmVjZW50IHJlZnJlc2gg dG9rZW4gb3ZlciB3cml0ZXMgdGhlIGNsdDxzdXA+dGg8L3N1cD4gJm5ic3A7cmVmcmVzaCB0b2tl biBmb3IgdXNlci1jbGllbnQgY29tYmluYXRpb24pLjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjFpbjt0ZXh0LWluZGVudDotMC4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEycHQ7Y29sb3I6YmxhY2siPmMuPHNwYW4gc3R5bGU9ImZvbnQ6N3B0ICd0aW1lcyBuZXcg cm9tYW4nIj4gPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6 YmxhY2siPlJldm9jYXRpb24gb2YgaW5hY3RpdmUgdG9rZW4gcmVtb3ZlcyB0aGUgcmVmcmVzaCB0 b2tlbi48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDowLjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+V2UgaGF2ZSBpbXBs ZW1lbnRlZCBzdWNoIGEgc2NoZW1lIGZvciBvdXIgT0F1dGggc2VydmVyLCB3aGVyZWJ5IOKAnGNs dOKAnSBpcyBzZXQgdG8gZml2ZSBieSBkZWZhdWx0IChpZiBub3Qgc3BlY2lmaWVkIGluIGNsaWVu dCB0aGUgcHJvcGVydGllcykuIFRoZXJlZm9yZSwgPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MC41aW47dGV4dC1pbmRlbnQ6LTAuMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMnB0O2NvbG9yOmJsYWNrIj4xLjxzcGFuIHN0eWxlPSJmb250OjdwdCAndGltZXMgbmV3 IHJvbWFuJyI+IDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9y OmJsYWNrIj5XaGVuZXZlciBhIG5ldyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBpcyBjcmVhdGVk LCBpdCBvdmVyd3JpdGVzIHRoZSA1PHN1cD50aDwvc3VwPiAoY2x0PTUpIG9sZGVzdCByZWZyZXNo IHRva2VuIChmb3IgY2xpZW50SWQtdXNlcklkIGNvbWJpbmF0aW9uKS4gPC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MC41aW47dGV4dC1pbmRlbnQ6LTAuMjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNrIj4yLjxzcGFuIHN0eWxlPSJmb250Ojdw dCAndGltZXMgbmV3IHJvbWFuJyI+IDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMnB0O2NvbG9yOmJsYWNrIj5Db2RlIGdyYW50IHRva2VucyBhcmUgb25seSB2YWxpZCBmb3Ig MSBob3VyLiBXaGVuIHRoZSB0b2tlbiBleHBpcmVzLCByZWZyZXNoIHRva2VuIGlzIG5vdCByZW1v dmVkLjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjAuNWluO3RleHQtaW5k ZW50Oi0wLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+My48 c3BhbiBzdHlsZT0iZm9udDo3cHQgJ3RpbWVzIG5ldyByb21hbiciPiA8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+V2hlbiBhbiDigJxhY3RpdmXi gJ0gdG9rZW4gaXMgcmV2b2tlZCwgVG9rZW4gYW5kIGl04oCZcyByZWZyZXNoIHRva2VuIGlzIGFs c28gcmV2b2tlZC4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MC41aW47 dGV4dC1pbmRlbnQ6LTAuMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJs YWNrIj40LjxzcGFuIHN0eWxlPSJmb250OjdwdCAndGltZXMgbmV3IHJvbWFuJyI+IDwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNrIj5XaGVuIGFuIOKA nGV4cGlyZWTigJ0gdG9rZW4gaXMgcmV2b2tlZCwgb25seSB0aGUgY29ycmVzcG9uZGluZyByZWZy ZXNoIHRva2VuIGlzIHJldm9rZWQuIDwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+VGhlIGFib3ZlIGV4YW1wbGUgZXhw bGljaXRseSBzcGVjaWZ5IGhvdyB0byBoYW5kbGUgcmV2b2NhdGlvbiBvZiByZWZyZXNoIHRva2Vu cyB3aGVuIHRoZSBjbGllbnQgaGFzIG5vdCBpbmZvcm1lZCB0aGUgT0F1dGggc2VydmVyIGFib3V0 IGhvdyBleHBpcnkgb2YgcmVmcmVzaCB0b2tlbnMgc2hvdWxkIGJlIGhhbmRsZWQuIFRoaXMgYWxz byBhbGxvd3MgY2xpZW50cyB0byBzcGVjaWZ5IGNlcnRhaW4gY29uc3RyYWlucyAobGlrZSBkZWZh dWx0IHRpbWUgdG8gbGl2ZSBmb3IgdG9rZW5zLCBhbmQgY2xpZW50IGxldmVsIHRocmVzaG9sZCBm b3IgbnVtYmVyIG9mIHJlZnJlc2ggdG9rZW5zIHRvIGtlZXAgYWN0aXZlIGZvciBlYWNoIGNsaWVu dC11c2VyIGNvbWJpbmF0aW9uKS4gPC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEycHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNrIj5BcmUgeW91IHBsYW5uaW5nIHRvIHVw ZGF0ZSB0aGUgUkZDIG9uIHRoZSBzY2hlbWUgdG8gaGFuZGxlIHJldm9jYXRpb24gb2YgcmVmcmVz aCB0b2tlbj8gSWYgbm90LCB3b3VsZCB5b3UgYmUgd2lsbGluZyB0byBpbmNsdWRlIHRoZSBwcm9w b3NlZCBjaGFuZ2VzIHRvIFJGQzcwMDk/IFBsZWFzZSBsZXQgbWUga25vdy48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+LS08L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+VGhh bmtzLDwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9y OmJsYWNrIj5BbWl0PC9zcGFuPjwvcHJlPg0KPHA+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8YnI+DQo8 ZmllbGRzZXQ+PC9maWVsZHNldD4gPGJyPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EC5D50A28C853445B767C0962CAD45720F7F2132DAGN10ae6exg6ex_-- From nobody Sun Jan 18 00:41:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436291AC39B for ; Sun, 18 Jan 2015 00:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 eHMMjVLffvUY for ; Sun, 18 Jan 2015 00:41:31 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) (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 690701A9023 for ; Sun, 18 Jan 2015 00:41:30 -0800 (PST) Received: from [79.253.63.146] (helo=[192.168.71.131]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YClQF-00050h-Gs; Sun, 18 Jan 2015 09:41:27 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2030D8F2-8187-4320-A02E-3B02166ECAEF Content-Transfer-Encoding: 7bit Message-Id: <355AFCFE-64A7-4F7F-AA12-F57B291BE5F2@lodderstedt.net> X-Mailer: iPad Mail (12B440) From: Torsten Lodderstedt Date: Sun, 18 Jan 2015 09:41:28 +0100 To: Amit Gupta X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 08:41:34 -0000 --Apple-Mail-2030D8F2-8187-4320-A02E-3B02166ECAEF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Amit, as far as I understand you are asking for a documentation of guidelines for r= efresh token lifecycle management. Such guidlines are not in scope for RFC 7= 009, as it only wants to add a request to the AS to give the client an (inte= roperable) way to explicitly revoke tokens. Tokens lifecycle (incl. expirati= on) and respective policies are at the discretion of the AS. Those topics ar= e intentionally left unspecified by this and other OAuth RFC in order to not= limit the design options of AS implementations. Note for example that our (= Deutsche Telekom's) AS treats refresh token expiration differently then your= implementation. But thanks to RFC 7009, a client could revoke tokens using t= he same code snippet at both ASs. Guidelines could be documented in an additional BCP (best current practice) R= FC. If you like, you can post an individual draft and ask the WG to adopt it= as WG document. Best regards, Torsten. > Am 16.01.2015 um 17:10 schrieb Amit Gupta : >=20 > The present rfc does not specify if the server should indefinitely keep th= e refresh token functional for every token (except revoked ones), and most r= efresh tokens are not used (due to authorize workflow is triggered by client= s for authentication and resource access). >=20 > Hence, I feel the rfc should provide guidance for the transparent ways to l= imit validity of refresh tokens and what property/setting should be used to a= utomatically expire refresh tokens, and who (between the server, client or u= set) should be able to specify/modify/see this property(s). >=20 > In our implementation, the client can specify/modify this property (or ser= ver to set default) to limit refresh tokens. Its not clear if the user have v= isibility in number of refresh tokens before consent (or a say in refresh to= ken revocation). > -- > Thanks, > Amit Gupta > Software Security Architect,=20 > InsideView Inc. >=20 > Sent from my mobile device, > Please excuse spelling typos. >=20 > On Jan 16, 2015 7:07 PM, Justin Richer wrote: > This seems to be more of an implementation of revocation and handling refr= esh token lifetimes than anything that the spec would talk about. In what's d= escribed below, it doesn't seem that the client ever specifies the threshold= , nor would the AS desire the client to do so. This is all something that ca= n happen server-side, out of the view of the client. >=20 > In other words, I don't (personally) see what would have to change in the R= FC for someone to implement this scheme. Can you please clarify what I'm mis= sing? >=20 > -- Justin >=20 > On 1/16/2015 3:39 AM, Amit Gupta wrote: > Hi Torsten, Stefanie, Marius=20 > =20 > I wanted to suggest an addition to the token revocation rfc7009 to provide= more clarity on how revocation of refresh tokens should be handled. I feel t= he rfc should, > 1. Describe how the client/resource-owner can provide =E2=80=9Cstanding in= structions=E2=80=9D to the OAuth server to revoke refresh tokens.=20 > 2. Describe the default way to for the OAuth server to define constrains f= or revocation of refresh token if this constrains are not specified by the c= lient/resource owner. > =20 > The way it could be handled is: > 1. Store a Client level threshold (clt) of number of valid refresh tokens p= er =E2=80=9Cuser-client=E2=80=9D combination (and OAuth server can store the= default value for clt, if undefined by the client or resource owner).=20 > 2. Keep the =E2=80=9Ctime to live=E2=80=9D for the access token reasonably= small (few minutes to couple of hours).=20 > a. Revocation of active token removes the token ad the refresh token. > b. When new tokens are generated, up to =E2=80=9Cclt=E2=80=9D number of Re= fresh tokens is maintained by the OAuth server (the most recent refresh toke= n over writes the cltth refresh token for user-client combination). > c. Revocation of inactive token removes the refresh token. > =20 > We have implemented such a scheme for our OAuth server, whereby =E2=80=9Cc= lt=E2=80=9D is set to five by default (if not specified in client the proper= ties). Therefore,=20 > 1. Whenever a new token and refresh token is created, it overwrites the 5t= h (clt=3D5) oldest refresh token (for clientId-userId combination).=20 > 2. Code grant tokens are only valid for 1 hour. When the token expires, re= fresh token is not removed. > 3. When an =E2=80=9Cactive=E2=80=9D token is revoked, Token and it=E2=80=99= s refresh token is also revoked.=20 > 4. When an =E2=80=9Cexpired=E2=80=9D token is revoked, only the correspond= ing refresh token is revoked.=20 > =20 > The above example explicitly specify how to handle revocation of refresh t= okens when the client has not informed the OAuth server about how expiry of r= efresh tokens should be handled. This also allows clients to specify certain= constrains (like default time to live for tokens, and client level threshol= d for number of refresh tokens to keep active for each client-user combinati= on).=20 > =20 > Are you planning to update the RFC on the scheme to handle revocation of r= efresh token? If not, would you be willing to include the proposed changes t= o RFC7009? Please let me know. > -- > Thanks, > Amit > =20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-2030D8F2-8187-4320-A02E-3B02166ECAEF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Amit,

as f= ar as I understand you are asking for a documentation of guidelines for refr= esh token lifecycle management. Such guidlines are not in scope for RFC 7009= , as it only wants to add a request to the AS to give the client an (interop= erable) way to explicitly revoke tokens. Tokens lifecycle (incl. expiration)= and respective policies are at the discretion of the AS. Those topics are i= ntentionally left unspecified by this and other OAuth RFC in order to not li= mit the design options of AS implementations. Note for example that our (Deu= tsche Telekom's) AS treats refresh token expiration differently then your im= plementation. But thanks to RFC 7009, a client could revoke tokens using the= same code snippet at both ASs.

Guidelines could be= documented in an additional BCP (best current practice) RFC. If you like, y= ou can post an individual draft and ask the WG to adopt it as WG document.

Best regards,
Torsten.


<= /div>

Am 16.01.2015 um 17:10 schrieb Amit Gupta <amit.gupta@insideview.com>:

The present rfc does not specify if the server should indefin= itely keep the refresh token functional for every token (except revoked ones= ), and most refresh tokens are not used (due to authorize workflow is trigge= red by clients for authentication and resource access).

Hence, I feel the rfc should provide guidance for the transpa= rent ways to limit validity of refresh tokens and what property/setting shou= ld be used to automatically expire refresh tokens, and who (between the serv= er, client or uset) should be able to specify/modify/see this property(s).

In our implementation, the client can specify/modify this pro= perty (or server to set default) to limit refresh tokens. Its not clear if t= he user have visibility in number of refresh tokens before consent (or a say= in refresh token revocation).
--
Thanks,
Amit Gupta
Software Security Architect,
InsideView Inc.

Sent from my mobile device,
Please excuse spelling typos.

On Jan 16, 2015 7:07 PM, Justin Richer <jricher@mit.edu> wrote:
This seems to be more of an implementation of revocation and handling r= efresh token lifetimes than anything that the spec would talk about. In what= 's described below, it doesn't seem that the client ever specifies the thres= hold, nor would the AS desire the client to do so. This is all something that can happen server-side, out= of the view of the client.

In other words, I don't (personally) see what would have to change in the RFC= for someone to implement this scheme. Can you please clarify what I'm missi= ng?

 -- Justin

On 1/16/2015 3:39 AM, Amit Gupta wrote:
Hi Torsten, Stefanie, Marius=
 
 
I wanted to suggest an addit=
ion to the token revocation rfc7009 to provide more clarity on how revocatio=
n of refresh tokens should be handled. I feel the rfc should,
1. Describe how the client/resou=
rce-owner can provide =E2=80=9Cstanding instructions=E2=80=9D to the OAuth s=
erver to revoke refresh tokens. 
2. Describe the default way to f=
or the OAuth server to define constrains for revocation of refresh token if t=
his constrains are not specified by the client/resource owner.
 
The way it could be handled i=
s:
1. Store a Client level threshol=
d (clt) of number of valid refresh t=
okens per =E2=80=9Cuser-client=E2=80=9D combination (and OAuth server can st=
ore the default value for clt, if undefined by the client or resource owner)=
. 
2. Keep the =E2=80=9Ctime to liv=
e=E2=80=9D for the access token reasonably small (few minutes to couple of h=
ours). 
a. Revocation of active token remo=
ves the token ad the refresh token.
b. When new tokens are generated, u=
p to =E2=80=9Cclt=E2=80=9D number of Refresh tokens is maintained by the OAu=
th server (the most recent refresh token over writes the cltth &n=
bsp;refresh token for user-client combination).
c. Revocation of inactive token re=
moves the refresh token.
=
 
We have implemented such a s=
cheme for our OAuth server, whereby =E2=80=9Cclt=E2=80=9D is set to five by d=
efault (if not specified in client the properties). Therefore,
= 
1. Whenever a new token and refr=
esh token is created, it overwrites the 5th (clt=3D5) oldest refr=
esh token (for clientId-userId combination). 
2. Code grant tokens are only va=
lid for 1 hour. When the token expires, refresh token is not removed.=

3. When an =E2=80=9Cactive=E2=80=
=9D token is revoked, Token and it=E2=80=99s refresh token is also revoked. <=
/span>
4. When an =E2=80=9Cexpired=E2=80=
=9D token is revoked, only the corresponding refresh token is revoked. 
 
The above example explicitly=
 specify how to handle revocation of refresh tokens when the client has not i=
nformed the OAuth server about how expiry of refresh tokens should be handle=
d. This also allows clients to specify certain constrains (like default time=
 to live for tokens, and client level threshold for number of refresh tokens=
 to keep active for each client-user combination). 
 
Are you planning to update t=
he RFC on the scheme to handle revocation of refresh token? If not, would yo=
u be willing to include the proposed changes to RFC7009? Please let me know.=

--
Thanks,
Amit

 



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

= --Apple-Mail-2030D8F2-8187-4320-A02E-3B02166ECAEF-- From nobody Sun Jan 18 05:59:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B751B29E7 for ; Sun, 18 Jan 2015 05:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI0hjYfms7JO for ; Sun, 18 Jan 2015 05:59:44 -0800 (PST) Received: from server506.appriver.com (server506b.appriver.com [50.56.144.14]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA34B1ACD09 for ; Sun, 18 Jan 2015 05:59:43 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/18/2015 7:59:41 AM X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Policy: insideview.com - insideview.com X-Primary: amit.gupta@insideview.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-110/SG:5 1/18/2015 7:59:14 AM X-GBUdb-Analysis: 1, 169.254.1.45, Ugly c=0.883451 p=-0.995839 Source White X-Signature-Violations: 0-0-0-32767-c X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->United States X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: smtp.exg6.exghost.com X-Note-Return-Path: amit.gupta@insideview.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 233923911; Sun, 18 Jan 2015 07:59:41 -0600 Received: from DAGN10A-E6.exg6.exghost.com ([169.254.1.45]) by HT06-E6.exg6.exghost.com ([10.242.230.113]) with mapi id 14.03.0210.002; Sun, 18 Jan 2015 07:59:41 -0600 From: Amit Gupta To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens Thread-Index: AdAxpuZuaRyw+19oS/CIjljjczH2vwBhfEEAAAHINXA= Date: Sun, 18 Jan 2015 13:59:40 +0000 Message-ID: References: <355AFCFE-64A7-4F7F-AA12-F57B291BE5F2@lodderstedt.net> In-Reply-To: <355AFCFE-64A7-4F7F-AA12-F57B291BE5F2@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.61.191.157] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_EC5D50A28C853445B767C0962CAD45720F7F24A1DAGN10ae6exg6ex_" MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 13:59:47 -0000 --_000_EC5D50A28C853445B767C0962CAD45720F7F24A1DAGN10ae6exg6ex_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9yc3RlbiwNCg0KSSBnZXQgdGhlIHBvaW50IGZvciBhIEJDUCBhcm91bmQgdGhlIHJldm9j YXRpb24vdmFsaWRpdHkgb2YgcmVmcmVzaCB0b2tlbnMuIEnigJlsbCBjb21waWxlIGEgZG9jdW1l bnRzIGZvciB3aGF0IHdlIHRob3VnaHQgc2hvdWxkIGJlIHRoZSBiZXN0IHByYWN0aWNlIGFyb3Vu ZCBsaW1pdGluZyB0aGUgdmFsaWRpdHkgb2YgcmVmcmVzaCB0b2tlbnMgKHRvbyBtYW55IG9mIHRo ZXNlIHdlcmUgdW51c2VkLCBhbmQga2VlcGluZyB0aGVtIGFsaXZlIHdhcyBib3RoIGEgc2VjdXJp dHkgbGlhYmlsaXR5LCBhbmQgcGVyZm9ybWFuY2Ugb3ZlcmhlYWQpLiBXb3VsZCBJIGhhdmUgdG8g c2VuZCB0aGUgZHJhZnQgdG8gb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj8g b3IgYSBzcGVjaWZpYyB3b3JraW5nIGdyb3VwIGVtYWlsPw0KDQpUaGFua3MgYWdhaW4gZm9yIHlv dXIgcmVzcG9uc2UuDQotLQ0KVGhhbmtzDQpBbWl0DQoNCkZyb206IFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NClNlbnQ6IFN1bmRheSwgSmFudWFy eSAxOCwgMjAxNSAyOjExIFBNDQpUbzogQW1pdCBHdXB0YQ0KQ2M6IEp1c3RpbiBSaWNoZXI7IHNk cm9uaWFAZ214LmRlOyBvYXV0aEBpZXRmLm9yZzsgbXNjdXJ0ZXNjdUBnb29nbGUuY29tDQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBSRkMgNzAwOSBPQXV0aCAyLjAgVG9rZW4gUmV2b2NhdGlvbiAv L3Byb3Bvc2VkIGNoYW5nZSB3cnQgdG8gImRlZmF1bHQiIHJldm9jYXRpb24gb2YgcmVmcmVzaCB0 b2tlbnMNCg0KSGkgQW1pdCwNCg0KYXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB5b3UgYXJlIGFza2lu ZyBmb3IgYSBkb2N1bWVudGF0aW9uIG9mIGd1aWRlbGluZXMgZm9yIHJlZnJlc2ggdG9rZW4gbGlm ZWN5Y2xlIG1hbmFnZW1lbnQuIFN1Y2ggZ3VpZGxpbmVzIGFyZSBub3QgaW4gc2NvcGUgZm9yIFJG QyA3MDA5LCBhcyBpdCBvbmx5IHdhbnRzIHRvIGFkZCBhIHJlcXVlc3QgdG8gdGhlIEFTIHRvIGdp dmUgdGhlIGNsaWVudCBhbiAoaW50ZXJvcGVyYWJsZSkgd2F5IHRvIGV4cGxpY2l0bHkgcmV2b2tl IHRva2Vucy4gVG9rZW5zIGxpZmVjeWNsZSAoaW5jbC4gZXhwaXJhdGlvbikgYW5kIHJlc3BlY3Rp dmUgcG9saWNpZXMgYXJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBBUy4gVGhvc2UgdG9waWNz IGFyZSBpbnRlbnRpb25hbGx5IGxlZnQgdW5zcGVjaWZpZWQgYnkgdGhpcyBhbmQgb3RoZXIgT0F1 dGggUkZDIGluIG9yZGVyIHRvIG5vdCBsaW1pdCB0aGUgZGVzaWduIG9wdGlvbnMgb2YgQVMgaW1w bGVtZW50YXRpb25zLiBOb3RlIGZvciBleGFtcGxlIHRoYXQgb3VyIChEZXV0c2NoZSBUZWxla29t J3MpIEFTIHRyZWF0cyByZWZyZXNoIHRva2VuIGV4cGlyYXRpb24gZGlmZmVyZW50bHkgdGhlbiB5 b3VyIGltcGxlbWVudGF0aW9uLiBCdXQgdGhhbmtzIHRvIFJGQyA3MDA5LCBhIGNsaWVudCBjb3Vs ZCByZXZva2UgdG9rZW5zIHVzaW5nIHRoZSBzYW1lIGNvZGUgc25pcHBldCBhdCBib3RoIEFTcy4N Cg0KR3VpZGVsaW5lcyBjb3VsZCBiZSBkb2N1bWVudGVkIGluIGFuIGFkZGl0aW9uYWwgQkNQIChi ZXN0IGN1cnJlbnQgcHJhY3RpY2UpIFJGQy4gSWYgeW91IGxpa2UsIHlvdSBjYW4gcG9zdCBhbiBp bmRpdmlkdWFsIGRyYWZ0IGFuZCBhc2sgdGhlIFdHIHRvIGFkb3B0IGl0IGFzIFdHIGRvY3VtZW50 Lg0KDQpCZXN0IHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQoNCkFtIDE2LjAxLjIwMTUgdW0gMTc6MTAg c2NocmllYiBBbWl0IEd1cHRhIDxhbWl0Lmd1cHRhQGluc2lkZXZpZXcuY29tPG1haWx0bzphbWl0 Lmd1cHRhQGluc2lkZXZpZXcuY29tPj46DQoNClRoZSBwcmVzZW50IHJmYyBkb2VzIG5vdCBzcGVj aWZ5IGlmIHRoZSBzZXJ2ZXIgc2hvdWxkIGluZGVmaW5pdGVseSBrZWVwIHRoZSByZWZyZXNoIHRv a2VuIGZ1bmN0aW9uYWwgZm9yIGV2ZXJ5IHRva2VuIChleGNlcHQgcmV2b2tlZCBvbmVzKSwgYW5k IG1vc3QgcmVmcmVzaCB0b2tlbnMgYXJlIG5vdCB1c2VkIChkdWUgdG8gYXV0aG9yaXplIHdvcmtm bG93IGlzIHRyaWdnZXJlZCBieSBjbGllbnRzIGZvciBhdXRoZW50aWNhdGlvbiBhbmQgcmVzb3Vy Y2UgYWNjZXNzKS4NCg0KSGVuY2UsIEkgZmVlbCB0aGUgcmZjIHNob3VsZCBwcm92aWRlIGd1aWRh bmNlIGZvciB0aGUgdHJhbnNwYXJlbnQgd2F5cyB0byBsaW1pdCB2YWxpZGl0eSBvZiByZWZyZXNo IHRva2VucyBhbmQgd2hhdCBwcm9wZXJ0eS9zZXR0aW5nIHNob3VsZCBiZSB1c2VkIHRvIGF1dG9t YXRpY2FsbHkgZXhwaXJlIHJlZnJlc2ggdG9rZW5zLCBhbmQgd2hvIChiZXR3ZWVuIHRoZSBzZXJ2 ZXIsIGNsaWVudCBvciB1c2V0KSBzaG91bGQgYmUgYWJsZSB0byBzcGVjaWZ5L21vZGlmeS9zZWUg dGhpcyBwcm9wZXJ0eShzKS4NCg0KSW4gb3VyIGltcGxlbWVudGF0aW9uLCB0aGUgY2xpZW50IGNh biBzcGVjaWZ5L21vZGlmeSB0aGlzIHByb3BlcnR5IChvciBzZXJ2ZXIgdG8gc2V0IGRlZmF1bHQp IHRvIGxpbWl0IHJlZnJlc2ggdG9rZW5zLiBJdHMgbm90IGNsZWFyIGlmIHRoZSB1c2VyIGhhdmUg dmlzaWJpbGl0eSBpbiBudW1iZXIgb2YgcmVmcmVzaCB0b2tlbnMgYmVmb3JlIGNvbnNlbnQgKG9y IGEgc2F5IGluIHJlZnJlc2ggdG9rZW4gcmV2b2NhdGlvbikuDQotLQ0KVGhhbmtzLA0KQW1pdCBH dXB0YQ0KU29mdHdhcmUgU2VjdXJpdHkgQXJjaGl0ZWN0LA0KSW5zaWRlVmlldyBJbmMuDQoNClNl bnQgZnJvbSBteSBtb2JpbGUgZGV2aWNlLA0KUGxlYXNlIGV4Y3VzZSBzcGVsbGluZyB0eXBvcy4N Ck9uIEphbiAxNiwgMjAxNSA3OjA3IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8 bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVGhpcyBzZWVtcyB0byBiZSBtb3JlIG9m IGFuIGltcGxlbWVudGF0aW9uIG9mIHJldm9jYXRpb24gYW5kIGhhbmRsaW5nIHJlZnJlc2ggdG9r ZW4gbGlmZXRpbWVzIHRoYW4gYW55dGhpbmcgdGhhdCB0aGUgc3BlYyB3b3VsZCB0YWxrIGFib3V0 LiBJbiB3aGF0J3MgZGVzY3JpYmVkIGJlbG93LCBpdCBkb2Vzbid0IHNlZW0gdGhhdCB0aGUgY2xp ZW50IGV2ZXIgc3BlY2lmaWVzIHRoZSB0aHJlc2hvbGQsIG5vciB3b3VsZCB0aGUgQVMgZGVzaXJl IHRoZSBjbGllbnQgdG8gZG8gc28uIFRoaXMgaXMgYWxsIHNvbWV0aGluZyB0aGF0IGNhbiBoYXBw ZW4gc2VydmVyLXNpZGUsIG91dCBvZiB0aGUgdmlldyBvZiB0aGUgY2xpZW50Lg0KDQpJbiBvdGhl ciB3b3JkcywgSSBkb24ndCAocGVyc29uYWxseSkgc2VlIHdoYXQgd291bGQgaGF2ZSB0byBjaGFu Z2UgaW4gdGhlIFJGQyBmb3Igc29tZW9uZSB0byBpbXBsZW1lbnQgdGhpcyBzY2hlbWUuIENhbiB5 b3UgcGxlYXNlIGNsYXJpZnkgd2hhdCBJJ20gbWlzc2luZz8NCg0KIC0tIEp1c3Rpbg0KDQpPbiAx LzE2LzIwMTUgMzozOSBBTSwgQW1pdCBHdXB0YSB3cm90ZToNCg0KSGkgVG9yc3RlbiwgU3RlZmFu aWUsIE1hcml1cw0KDQoNCg0KSSB3YW50ZWQgdG8gc3VnZ2VzdCBhbiBhZGRpdGlvbiB0byB0aGUg dG9rZW4gcmV2b2NhdGlvbiByZmM3MDA5IHRvIHByb3ZpZGUgbW9yZSBjbGFyaXR5IG9uIGhvdyBy ZXZvY2F0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHNob3VsZCBiZSBoYW5kbGVkLiBJIGZlZWwgdGhl IHJmYyBzaG91bGQsDQoNCjEuIERlc2NyaWJlIGhvdyB0aGUgY2xpZW50L3Jlc291cmNlLW93bmVy IGNhbiBwcm92aWRlIOKAnHN0YW5kaW5nIGluc3RydWN0aW9uc+KAnSB0byB0aGUgT0F1dGggc2Vy dmVyIHRvIHJldm9rZSByZWZyZXNoIHRva2Vucy4NCg0KMi4gRGVzY3JpYmUgdGhlIGRlZmF1bHQg d2F5IHRvIGZvciB0aGUgT0F1dGggc2VydmVyIHRvIGRlZmluZSBjb25zdHJhaW5zIGZvciByZXZv Y2F0aW9uIG9mIHJlZnJlc2ggdG9rZW4gaWYgdGhpcyBjb25zdHJhaW5zIGFyZSBub3Qgc3BlY2lm aWVkIGJ5IHRoZSBjbGllbnQvcmVzb3VyY2Ugb3duZXIuDQoNCg0KDQpUaGUgd2F5IGl0IGNvdWxk IGJlIGhhbmRsZWQgaXM6DQoNCjEuIFN0b3JlIGEgQ2xpZW50IGxldmVsIHRocmVzaG9sZCAoY2x0 KSBvZiBudW1iZXIgb2YgdmFsaWQgcmVmcmVzaCB0b2tlbnMgcGVyIOKAnHVzZXItY2xpZW504oCd IGNvbWJpbmF0aW9uIChhbmQgT0F1dGggc2VydmVyIGNhbiBzdG9yZSB0aGUgZGVmYXVsdCB2YWx1 ZSBmb3IgY2x0LCBpZiB1bmRlZmluZWQgYnkgdGhlIGNsaWVudCBvciByZXNvdXJjZSBvd25lciku DQoNCjIuIEtlZXAgdGhlIOKAnHRpbWUgdG8gbGl2ZeKAnSBmb3IgdGhlIGFjY2VzcyB0b2tlbiBy ZWFzb25hYmx5IHNtYWxsIChmZXcgbWludXRlcyB0byBjb3VwbGUgb2YgaG91cnMpLg0KDQphLiBS ZXZvY2F0aW9uIG9mIGFjdGl2ZSB0b2tlbiByZW1vdmVzIHRoZSB0b2tlbiBhZCB0aGUgcmVmcmVz aCB0b2tlbi4NCg0KYi4gV2hlbiBuZXcgdG9rZW5zIGFyZSBnZW5lcmF0ZWQsIHVwIHRvIOKAnGNs dOKAnSBudW1iZXIgb2YgUmVmcmVzaCB0b2tlbnMgaXMgbWFpbnRhaW5lZCBieSB0aGUgT0F1dGgg c2VydmVyICh0aGUgbW9zdCByZWNlbnQgcmVmcmVzaCB0b2tlbiBvdmVyIHdyaXRlcyB0aGUgY2x0 dGggIHJlZnJlc2ggdG9rZW4gZm9yIHVzZXItY2xpZW50IGNvbWJpbmF0aW9uKS4NCg0KYy4gUmV2 b2NhdGlvbiBvZiBpbmFjdGl2ZSB0b2tlbiByZW1vdmVzIHRoZSByZWZyZXNoIHRva2VuLg0KDQoN Cg0KV2UgaGF2ZSBpbXBsZW1lbnRlZCBzdWNoIGEgc2NoZW1lIGZvciBvdXIgT0F1dGggc2VydmVy LCB3aGVyZWJ5IOKAnGNsdOKAnSBpcyBzZXQgdG8gZml2ZSBieSBkZWZhdWx0IChpZiBub3Qgc3Bl Y2lmaWVkIGluIGNsaWVudCB0aGUgcHJvcGVydGllcykuIFRoZXJlZm9yZSwNCg0KMS4gV2hlbmV2 ZXIgYSBuZXcgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW4gaXMgY3JlYXRlZCwgaXQgb3ZlcndyaXRl cyB0aGUgNXRoIChjbHQ9NSkgb2xkZXN0IHJlZnJlc2ggdG9rZW4gKGZvciBjbGllbnRJZC11c2Vy SWQgY29tYmluYXRpb24pLg0KDQoyLiBDb2RlIGdyYW50IHRva2VucyBhcmUgb25seSB2YWxpZCBm b3IgMSBob3VyLiBXaGVuIHRoZSB0b2tlbiBleHBpcmVzLCByZWZyZXNoIHRva2VuIGlzIG5vdCBy ZW1vdmVkLg0KDQozLiBXaGVuIGFuIOKAnGFjdGl2ZeKAnSB0b2tlbiBpcyByZXZva2VkLCBUb2tl biBhbmQgaXTigJlzIHJlZnJlc2ggdG9rZW4gaXMgYWxzbyByZXZva2VkLg0KDQo0LiBXaGVuIGFu IOKAnGV4cGlyZWTigJ0gdG9rZW4gaXMgcmV2b2tlZCwgb25seSB0aGUgY29ycmVzcG9uZGluZyBy ZWZyZXNoIHRva2VuIGlzIHJldm9rZWQuDQoNCg0KDQpUaGUgYWJvdmUgZXhhbXBsZSBleHBsaWNp dGx5IHNwZWNpZnkgaG93IHRvIGhhbmRsZSByZXZvY2F0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdo ZW4gdGhlIGNsaWVudCBoYXMgbm90IGluZm9ybWVkIHRoZSBPQXV0aCBzZXJ2ZXIgYWJvdXQgaG93 IGV4cGlyeSBvZiByZWZyZXNoIHRva2VucyBzaG91bGQgYmUgaGFuZGxlZC4gVGhpcyBhbHNvIGFs bG93cyBjbGllbnRzIHRvIHNwZWNpZnkgY2VydGFpbiBjb25zdHJhaW5zIChsaWtlIGRlZmF1bHQg dGltZSB0byBsaXZlIGZvciB0b2tlbnMsIGFuZCBjbGllbnQgbGV2ZWwgdGhyZXNob2xkIGZvciBu dW1iZXIgb2YgcmVmcmVzaCB0b2tlbnMgdG8ga2VlcCBhY3RpdmUgZm9yIGVhY2ggY2xpZW50LXVz ZXIgY29tYmluYXRpb24pLg0KDQoNCg0KQXJlIHlvdSBwbGFubmluZyB0byB1cGRhdGUgdGhlIFJG QyBvbiB0aGUgc2NoZW1lIHRvIGhhbmRsZSByZXZvY2F0aW9uIG9mIHJlZnJlc2ggdG9rZW4/IElm IG5vdCwgd291bGQgeW91IGJlIHdpbGxpbmcgdG8gaW5jbHVkZSB0aGUgcHJvcG9zZWQgY2hhbmdl cyB0byBSRkM3MDA5PyBQbGVhc2UgbGV0IG1lIGtub3cuDQoNCi0tDQoNClRoYW5rcywNCg0KQW1p dA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cg0K --_000_EC5D50A28C853445B767C0962CAD45720F7F24A1DAGN10ae6exg6ex_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRvcnN0ZW4sDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZ2V0IHRoZSBwb2ludCBmb3IgYSBCQ1Ag YXJvdW5kIHRoZSByZXZvY2F0aW9uL3ZhbGlkaXR5IG9mIHJlZnJlc2ggdG9rZW5zLiBJ4oCZbGwg Y29tcGlsZSBhIGRvY3VtZW50cyBmb3Igd2hhdCB3ZSB0aG91Z2h0IHNob3VsZCBiZSB0aGUgYmVz dCBwcmFjdGljZSBhcm91bmQgbGltaXRpbmcNCiB0aGUgdmFsaWRpdHkgb2YgcmVmcmVzaCB0b2tl bnMgKHRvbyBtYW55IG9mIHRoZXNlIHdlcmUgdW51c2VkLCBhbmQga2VlcGluZyB0aGVtIGFsaXZl IHdhcyBib3RoIGEgc2VjdXJpdHkgbGlhYmlsaXR5LCBhbmQgcGVyZm9ybWFuY2Ugb3ZlcmhlYWQp LiBXb3VsZCBJIGhhdmUgdG8gc2VuZCB0aGUgZHJhZnQgdG8NCjxhIGhyZWY9Im1haWx0bzpvYXV0 aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PyBvciBhIHNwZWNpZmljIHdvcmtpbmcgZ3Jv dXAgZW1haWw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFu a3MgYWdhaW4gZm9yIHlvdXIgcmVzcG9uc2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFtaXQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEphbnVh cnkgMTgsIDIwMTUgMjoxMSBQTTxicj4NCjxiPlRvOjwvYj4gQW1pdCBHdXB0YTxicj4NCjxiPkNj OjwvYj4gSnVzdGluIFJpY2hlcjsgc2Ryb25pYUBnbXguZGU7IG9hdXRoQGlldGYub3JnOyBtc2N1 cnRlc2N1QGdvb2dsZS5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUkZD IDcwMDkgT0F1dGggMi4wIFRva2VuIFJldm9jYXRpb24gLy9wcm9wb3NlZCBjaGFuZ2Ugd3J0IHRv ICZxdW90O2RlZmF1bHQmcXVvdDsgcmV2b2NhdGlvbiBvZiByZWZyZXNoIHRva2VuczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbWl0LDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcyBm YXIgYXMgSSB1bmRlcnN0YW5kIHlvdSBhcmUgYXNraW5nIGZvciBhIGRvY3VtZW50YXRpb24gb2Yg Z3VpZGVsaW5lcyBmb3IgcmVmcmVzaCB0b2tlbiBsaWZlY3ljbGUgbWFuYWdlbWVudC4gU3VjaCBn dWlkbGluZXMgYXJlIG5vdCBpbiBzY29wZSBmb3IgUkZDIDcwMDksIGFzIGl0IG9ubHkgd2FudHMg dG8gYWRkIGEgcmVxdWVzdCB0byB0aGUgQVMgdG8gZ2l2ZSB0aGUgY2xpZW50IGFuIChpbnRlcm9w ZXJhYmxlKQ0KIHdheSB0byBleHBsaWNpdGx5IHJldm9rZSB0b2tlbnMuIFRva2VucyBsaWZlY3lj bGUgKGluY2wuIGV4cGlyYXRpb24pIGFuZCByZXNwZWN0aXZlIHBvbGljaWVzIGFyZSBhdCB0aGUg ZGlzY3JldGlvbiBvZiB0aGUgQVMuIFRob3NlIHRvcGljcyBhcmUgaW50ZW50aW9uYWxseSBsZWZ0 IHVuc3BlY2lmaWVkIGJ5IHRoaXMgYW5kIG90aGVyIE9BdXRoIFJGQyBpbiBvcmRlciB0byBub3Qg bGltaXQgdGhlIGRlc2lnbiBvcHRpb25zIG9mIEFTIGltcGxlbWVudGF0aW9ucy4NCiBOb3RlIGZv ciBleGFtcGxlIHRoYXQgb3VyIChEZXV0c2NoZSBUZWxla29tJ3MpIEFTIHRyZWF0cyByZWZyZXNo IHRva2VuIGV4cGlyYXRpb24gZGlmZmVyZW50bHkgdGhlbiB5b3VyIGltcGxlbWVudGF0aW9uLiBC dXQgdGhhbmtzIHRvIFJGQyA3MDA5LCBhIGNsaWVudCBjb3VsZCByZXZva2UgdG9rZW5zIHVzaW5n IHRoZSBzYW1lIGNvZGUgc25pcHBldCBhdCBib3RoIEFTcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3VpZGVsaW5lcyBjb3VsZCBiZSBkb2N1 bWVudGVkIGluIGFuIGFkZGl0aW9uYWwgQkNQIChiZXN0IGN1cnJlbnQgcHJhY3RpY2UpIFJGQy4g SWYgeW91IGxpa2UsIHlvdSBjYW4gcG9zdCBhbiBpbmRpdmlkdWFsIGRyYWZ0IGFuZCBhc2sgdGhl IFdHIHRvIGFkb3B0IGl0IGFzIFdHIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub3JzdGVuLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQW0gMTYu MDEuMjAxNSB1bSAxNzoxMCBzY2hyaWViIEFtaXQgR3VwdGEgJmx0OzxhIGhyZWY9Im1haWx0bzph bWl0Lmd1cHRhQGluc2lkZXZpZXcuY29tIj5hbWl0Lmd1cHRhQGluc2lkZXZpZXcuY29tPC9hPiZn dDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwPlRoZSBwcmVzZW50IHJmYyBk b2VzIG5vdCBzcGVjaWZ5IGlmIHRoZSBzZXJ2ZXIgc2hvdWxkIGluZGVmaW5pdGVseSBrZWVwIHRo ZSByZWZyZXNoIHRva2VuIGZ1bmN0aW9uYWwgZm9yIGV2ZXJ5IHRva2VuIChleGNlcHQgcmV2b2tl ZCBvbmVzKSwgYW5kIG1vc3QgcmVmcmVzaCB0b2tlbnMgYXJlIG5vdCB1c2VkIChkdWUgdG8gYXV0 aG9yaXplIHdvcmtmbG93IGlzIHRyaWdnZXJlZCBieSBjbGllbnRzIGZvciBhdXRoZW50aWNhdGlv biBhbmQgcmVzb3VyY2UNCiBhY2Nlc3MpLiA8bzpwPjwvbzpwPjwvcD4NCjxwPkhlbmNlLCBJIGZl ZWwgdGhlIHJmYyBzaG91bGQgcHJvdmlkZSBndWlkYW5jZSBmb3IgdGhlIHRyYW5zcGFyZW50IHdh eXMgdG8gbGltaXQgdmFsaWRpdHkgb2YgcmVmcmVzaCB0b2tlbnMgYW5kIHdoYXQgcHJvcGVydHkv c2V0dGluZyBzaG91bGQgYmUgdXNlZCB0byBhdXRvbWF0aWNhbGx5IGV4cGlyZSByZWZyZXNoIHRv a2VucywgYW5kIHdobyAoYmV0d2VlbiB0aGUgc2VydmVyLCBjbGllbnQgb3IgdXNldCkgc2hvdWxk IGJlIGFibGUgdG8gc3BlY2lmeS9tb2RpZnkvc2VlDQogdGhpcyBwcm9wZXJ0eShzKS48bzpwPjwv bzpwPjwvcD4NCjxwPkluIG91ciBpbXBsZW1lbnRhdGlvbiwgdGhlIGNsaWVudCBjYW4gc3BlY2lm eS9tb2RpZnkgdGhpcyBwcm9wZXJ0eSAob3Igc2VydmVyIHRvIHNldCBkZWZhdWx0KSB0byBsaW1p dCByZWZyZXNoIHRva2Vucy4gSXRzIG5vdCBjbGVhciBpZiB0aGUgdXNlciBoYXZlIHZpc2liaWxp dHkgaW4gbnVtYmVyIG9mIHJlZnJlc2ggdG9rZW5zIGJlZm9yZSBjb25zZW50IChvciBhIHNheSBp biByZWZyZXNoIHRva2VuIHJldm9jYXRpb24pLjxicj4NCi0tPGJyPg0KVGhhbmtzLDxicj4NCkFt aXQgR3VwdGE8YnI+DQpTb2Z0d2FyZSBTZWN1cml0eSBBcmNoaXRlY3QsIDxicj4NCkluc2lkZVZp ZXcgSW5jLjxvOnA+PC9vOnA+PC9wPg0KPHA+U2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UsPGJy Pg0KUGxlYXNlIGV4Y3VzZSBzcGVsbGluZyB0eXBvcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMTYsIDIwMTUgNzowNyBQTSwgSnVzdGluIFJpY2hl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNlZW1zIHRvIGJlIG1vcmUgb2YgYW4gaW1wbGVtZW50 YXRpb24gb2YgcmV2b2NhdGlvbiBhbmQgaGFuZGxpbmcgcmVmcmVzaCB0b2tlbiBsaWZldGltZXMg dGhhbiBhbnl0aGluZyB0aGF0IHRoZSBzcGVjIHdvdWxkIHRhbGsgYWJvdXQuIEluIHdoYXQncyBk ZXNjcmliZWQgYmVsb3csIGl0IGRvZXNuJ3Qgc2VlbSB0aGF0IHRoZSBjbGllbnQgZXZlciBzcGVj aWZpZXMgdGhlIHRocmVzaG9sZCwgbm9yIHdvdWxkDQogdGhlIEFTIGRlc2lyZSB0aGUgY2xpZW50 IHRvIGRvIHNvLiBUaGlzIGlzIGFsbCBzb21ldGhpbmcgdGhhdCBjYW4gaGFwcGVuIHNlcnZlci1z aWRlLCBvdXQgb2YgdGhlIHZpZXcgb2YgdGhlIGNsaWVudC48YnI+DQo8YnI+DQpJbiBvdGhlciB3 b3JkcywgSSBkb24ndCAocGVyc29uYWxseSkgc2VlIHdoYXQgd291bGQgaGF2ZSB0byBjaGFuZ2Ug aW4gdGhlIFJGQyBmb3Igc29tZW9uZSB0byBpbXBsZW1lbnQgdGhpcyBzY2hlbWUuIENhbiB5b3Ug cGxlYXNlIGNsYXJpZnkgd2hhdCBJJ20gbWlzc2luZz88YnI+DQo8YnI+DQombmJzcDstLSBKdXN0 aW48YnI+DQo8YnI+DQpPbiAxLzE2LzIwMTUgMzozOSBBTSwgQW1pdCBHdXB0YSB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+SGkgVG9yc3RlbiwgU3RlZmFuaWUsIE1hcml1cyA8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SSB3YW50ZWQgdG8gc3VnZ2VzdCBhbiBh ZGRpdGlvbiB0byB0aGUgdG9rZW4gcmV2b2NhdGlvbiByZmM3MDA5IHRvIHByb3ZpZGUgbW9yZSBj bGFyaXR5IG9uIGhvdyByZXZvY2F0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHNob3VsZCBiZSBoYW5k bGVkLiBJIGZlZWwgdGhlIHJmYyBzaG91bGQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm O2NvbG9yOmJsYWNrIj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5EZXNjcmliZSBob3cgdGhlIGNsaWVudC9yZXNvdXJjZS1vd25lciBjYW4gcHJvdmlk ZSDigJxzdGFuZGluZyBpbnN0cnVjdGlvbnPigJ0gdG8gdGhlIE9BdXRoIHNlcnZlciB0byByZXZv a2UgcmVmcmVzaCB0b2tlbnMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj4yLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RGVzY3JpYmUgdGhlIGRlZmF1bHQgd2F5IHRvIGZvciB0aGUgT0F1dGggc2VydmVyIHRvIGRlZmlu ZSBjb25zdHJhaW5zIGZvciByZXZvY2F0aW9uIG9mIHJlZnJlc2ggdG9rZW4gaWYgdGhpcyBjb25z dHJhaW5zIGFyZSBub3Qgc3BlY2lmaWVkIGJ5IHRoZSBjbGllbnQvcmVzb3VyY2Ugb3duZXIuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlRoZSB3YXkgaXQgY291bGQgYmUg aGFuZGxlZCBpczo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+MS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiA8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlN0b3JlIGEg Q2xpZW50IGxldmVsIHRocmVzaG9sZCAoPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5j bHQ8L3NwYW4+KSBvZiBudW1iZXIgb2YgdmFsaWQgcmVmcmVzaCB0b2tlbnMgcGVyIOKAnHVzZXIt Y2xpZW504oCdIGNvbWJpbmF0aW9uIChhbmQgT0F1dGggc2VydmVyIGNhbiBzdG9yZSB0aGUgZGVm YXVsdCB2YWx1ZSBmb3IgY2x0LCBpZiB1bmRlZmluZWQgYnkgdGhlIGNsaWVudCBvciByZXNvdXJj ZSBvd25lcikuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4yLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+IDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+S2VlcCB0aGUg 4oCcdGltZSB0byBsaXZl4oCdIGZvciB0aGUgYWNjZXNzIHRva2VuIHJlYXNvbmFibHkgc21hbGwg KGZldyBtaW51dGVzIHRvIGNvdXBsZSBvZiBob3VycykuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+YS48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWY7Y29sb3I6YmxhY2siPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPlJldm9jYXRpb24gb2YgYWN0aXZlIHRva2VuIHJlbW92ZXMgdGhlIHRv a2VuIGFkIHRoZSByZWZyZXNoIHRva2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Yi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPldoZW4gbmV3IHRva2VucyBhcmUgZ2VuZXJhdGVkLCB1cCB0byDigJxjbHTigJ0gbnVt YmVyIG9mIFJlZnJlc2ggdG9rZW5zIGlzIG1haW50YWluZWQgYnkgdGhlIE9BdXRoIHNlcnZlciAo dGhlIG1vc3QgcmVjZW50IHJlZnJlc2ggdG9rZW4gb3ZlciB3cml0ZXMgdGhlIGNsdDxzdXA+dGg8 L3N1cD4gJm5ic3A7cmVmcmVzaCB0b2tlbiBmb3IgdXNlci1jbGllbnQgY29tYmluYXRpb24pLjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4 dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+Yy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiA8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJldm9jYXRpb24gb2YgaW5hY3Rp dmUgdG9rZW4gcmVtb3ZlcyB0aGUgcmVmcmVzaCB0b2tlbi48L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPldlIGhhdmUgaW1wbGVt ZW50ZWQgc3VjaCBhIHNjaGVtZSBmb3Igb3VyIE9BdXRoIHNlcnZlciwgd2hlcmVieSDigJxjbHTi gJ0gaXMgc2V0IHRvIGZpdmUgYnkgZGVmYXVsdCAoaWYgbm90IHNwZWNpZmllZCBpbiBjbGllbnQg dGhlIHByb3BlcnRpZXMpLiBUaGVyZWZvcmUsIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4xLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp Zjtjb2xvcjpibGFjayI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+V2hlbmV2ZXIgYSBuZXcgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW4gaXMgY3JlYXRl ZCwgaXQgb3ZlcndyaXRlcyB0aGUgNTxzdXA+dGg8L3N1cD4gKGNsdD01KSBvbGRlc3QgcmVmcmVz aCB0b2tlbiAoZm9yIGNsaWVudElkLXVzZXJJZCBjb21iaW5hdGlvbikuIDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4yLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+Q29kZSBncmFudCB0b2tlbnMgYXJlIG9ubHkgdmFsaWQg Zm9yIDEgaG91ci4gV2hlbiB0aGUgdG9rZW4gZXhwaXJlcywgcmVmcmVzaCB0b2tlbiBpcyBub3Qg cmVtb3ZlZC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+My48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPldoZW4gYW4g4oCc YWN0aXZl4oCdIHRva2VuIGlzIHJldm9rZWQsIFRva2VuIGFuZCBpdOKAmXMgcmVmcmVzaCB0b2tl biBpcyBhbHNvIHJldm9rZWQuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ V2hlbiBhbiDigJxleHBpcmVk4oCdIHRva2VuIGlzIHJldm9rZWQsIG9ubHkgdGhlIGNvcnJlc3Bv bmRpbmcgcmVmcmVzaCB0b2tlbiBpcyByZXZva2VkLiA8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+VGhlIGFib3ZlIGV4YW1wbGUgZXhwbGljaXRseSBzcGVjaWZ5IGhvdyB0 byBoYW5kbGUgcmV2b2NhdGlvbiBvZiByZWZyZXNoIHRva2VucyB3aGVuIHRoZSBjbGllbnQgaGFz IG5vdCBpbmZvcm1lZCB0aGUgT0F1dGggc2VydmVyIGFib3V0IGhvdyBleHBpcnkgb2YgcmVmcmVz aCB0b2tlbnMgc2hvdWxkIGJlIGhhbmRsZWQuIFRoaXMgYWxzbyBhbGxvd3MgY2xpZW50cyB0byBz cGVjaWZ5IGNlcnRhaW4gY29uc3RyYWlucyAobGlrZSBkZWZhdWx0IHRpbWUgdG8gbGl2ZSBmb3Ig dG9rZW5zLCBhbmQgY2xpZW50IGxldmVsIHRocmVzaG9sZCBmb3IgbnVtYmVyIG9mIHJlZnJlc2gg dG9rZW5zIHRvIGtlZXAgYWN0aXZlIGZvciBlYWNoIGNsaWVudC11c2VyIGNvbWJpbmF0aW9uKS4g PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFyZSB5b3UgcGxhbm5pbmcg dG8gdXBkYXRlIHRoZSBSRkMgb24gdGhlIHNjaGVtZSB0byBoYW5kbGUgcmV2b2NhdGlvbiBvZiBy ZWZyZXNoIHRva2VuPyBJZiBub3QsIHdvdWxkIHlvdSBiZSB3aWxsaW5nIHRvIGluY2x1ZGUgdGhl IHByb3Bvc2VkIGNoYW5nZXMgdG8gUkZDNzAwOT8gUGxlYXNlIGxldCBtZSBrbm93Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+LS08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFtaXQ8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EC5D50A28C853445B767C0962CAD45720F7F24A1DAGN10ae6exg6ex_-- From nobody Sun Jan 18 07:31:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF301B2A03 for ; Sun, 18 Jan 2015 07:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Lnrd44sM3Ubt for ; Sun, 18 Jan 2015 07:30:57 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) (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 D24A71ACD8D for ; Sun, 18 Jan 2015 07:30:56 -0800 (PST) Received: from [79.253.63.146] (helo=[192.168.71.100]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YCroU-0007O9-4l; Sun, 18 Jan 2015 16:30:54 +0100 Message-ID: <54BBD1AB.1030203@lodderstedt.net> Date: Sun, 18 Jan 2015 16:30:51 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Amit Gupta References: <355AFCFE-64A7-4F7F-AA12-F57B291BE5F2@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070203000302040105010800" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 15:31:02 -0000 This is a multi-part message in MIME format. --------------070203000302040105010800 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Amit, there are guidelines on format and process regarding Internet Drafts - see http://www.ietf.org/ietf-ftp/1id-guidelines.txt. You may submit an individual draft using the submission tool and mark it as relevant to the OAuth working group. To get an impression you may take a look at http://datatracker.ietf.org/wg/oauth/documents/. On the bottom of this page you find a couple of individual draft proposing additions to OAuth. best regards, Torsten. Am 18.01.2015 um 14:59 schrieb Amit Gupta: > > Hi Torsten, > > I get the point for a BCP around the revocation/validity of refresh > tokens. I’ll compile a documents for what we thought should be the > best practice around limiting the validity of refresh tokens (too many > of these were unused, and keeping them alive was both a security > liability, and performance overhead). Would I have to send the draft > to oauth@ietf.org ? or a specific working group > email? > > Thanks again for your response. > > -- > > Thanks > > Amit > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, January 18, 2015 2:11 PM > *To:* Amit Gupta > *Cc:* Justin Richer; sdronia@gmx.de; oauth@ietf.org; mscurtescu@google.com > *Subject:* Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation > //proposed change wrt to "default" revocation of refresh tokens > > Hi Amit, > > as far as I understand you are asking for a documentation of > guidelines for refresh token lifecycle management. Such guidlines are > not in scope for RFC 7009, as it only wants to add a request to the AS > to give the client an (interoperable) way to explicitly revoke tokens. > Tokens lifecycle (incl. expiration) and respective policies are at the > discretion of the AS. Those topics are intentionally left unspecified > by this and other OAuth RFC in order to not limit the design options > of AS implementations. Note for example that our (Deutsche Telekom's) > AS treats refresh token expiration differently then your > implementation. But thanks to RFC 7009, a client could revoke tokens > using the same code snippet at both ASs. > > Guidelines could be documented in an additional BCP (best current > practice) RFC. If you like, you can post an individual draft and ask > the WG to adopt it as WG document. > > Best regards, > > Torsten. > > > Am 16.01.2015 um 17:10 schrieb Amit Gupta >: > > The present rfc does not specify if the server should indefinitely > keep the refresh token functional for every token (except revoked > ones), and most refresh tokens are not used (due to authorize > workflow is triggered by clients for authentication and resource > access). > > Hence, I feel the rfc should provide guidance for the transparent > ways to limit validity of refresh tokens and what property/setting > should be used to automatically expire refresh tokens, and who > (between the server, client or uset) should be able to > specify/modify/see this property(s). > > In our implementation, the client can specify/modify this property > (or server to set default) to limit refresh tokens. Its not clear > if the user have visibility in number of refresh tokens before > consent (or a say in refresh token revocation). > -- > Thanks, > Amit Gupta > Software Security Architect, > InsideView Inc. > > Sent from my mobile device, > Please excuse spelling typos. > > On Jan 16, 2015 7:07 PM, Justin Richer > wrote: > > This seems to be more of an implementation of revocation and > handling refresh token lifetimes than anything that the spec > would talk about. In what's described below, it doesn't seem > that the client ever specifies the threshold, nor would the AS > desire the client to do so. This is all something that can > happen server-side, out of the view of the client. > > In other words, I don't (personally) see what would have to > change in the RFC for someone to implement this scheme. Can > you please clarify what I'm missing? > > -- Justin > > On 1/16/2015 3:39 AM, Amit Gupta wrote: > > Hi Torsten, Stefanie, Marius > > > > I wanted to suggest an addition to the token revocation rfc7009 to provide more clarity on how revocation of refresh tokens should be handled. I feel the rfc should, > > 1. Describe how the client/resource-owner can provide “standing instructions†to the OAuth server to revoke refresh tokens. > > 2. Describe the default way to for the OAuth server to define constrains for revocation of refresh token if this constrains are not specified by the client/resource owner. > > > > The way it could be handled is: > > 1. Store a Client level threshold (clt) of number of valid refresh tokens per “user-client†combination (and OAuth server can store the default value for clt, if undefined by the client or resource owner). > > 2. Keep the “time to live†for the access token reasonably small (few minutes to couple of hours). > > a. Revocation of active token removes the token ad the refresh token. > > b. When new tokens are generated, up to “clt†number of Refresh tokens is maintained by the OAuth server (the most recent refresh token over writes the clt^th refresh token for user-client combination). > > c. Revocation of inactive token removes the refresh token. > > > > We have implemented such a scheme for our OAuth server, whereby “clt†is set to five by default (if not specified in client the properties). Therefore, > > 1. Whenever a new token and refresh token is created, it overwrites the 5^th (clt=5) oldest refresh token (for clientId-userId combination). > > 2. Code grant tokens are only valid for 1 hour. When the token expires, refresh token is not removed. > > 3. When an “active†token is revoked, Token and it’s refresh token is also revoked. > > 4. When an “expired†token is revoked, only the corresponding refresh token is revoked. > > > > The above example explicitly specify how to handle revocation of refresh tokens when the client has not informed the OAuth server about how expiry of refresh tokens should be handled. This also allows clients to specify certain constrains (like default time to live for tokens, and client level threshold for number of refresh tokens to keep active for each client-user combination). > > > > Are you planning to update the RFC on the scheme to handle revocation of refresh token? If not, would you be willing to include the proposed changes to RFC7009? Please let me know. > > -- > > Thanks, > > Amit > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --------------070203000302040105010800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Amit,

there are guidelines on format and process regarding Internet Drafts - see http://www.ietf.org/ietf-ftp/1id-guidelines.txt.

You may submit an individual draft using the submission tool and mark it as relevant to the OAuth working group. To get an impression you may take a look at http://datatracker.ietf.org/wg/oauth/documents/. On the bottom of this page you find a couple of individual draft proposing additions to OAuth.

best regards,
Torsten.

Am 18.01.2015 um 14:59 schrieb Amit Gupta:

Hi Torsten,

 

I get the point for a BCP around the revocation/validity of refresh tokens. I’ll compile a documents for what we thought should be the best practice around limiting the validity of refresh tokens (too many of these were unused, and keeping them alive was both a security liability, and performance overhead). Would I have to send the draft to oauth@ietf.org? or a specific working group email?

 

Thanks again for your response.

--

Thanks

Amit

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, January 18, 2015 2:11 PM
To: Amit Gupta
Cc: Justin Richer; sdronia@gmx.de; oauth@ietf.org; mscurtescu@google.com
Subject: Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens

 

Hi Amit,

 

as far as I understand you are asking for a documentation of guidelines for refresh token lifecycle management. Such guidlines are not in scope for RFC 7009, as it only wants to add a request to the AS to give the client an (interoperable) way to explicitly revoke tokens. Tokens lifecycle (incl. expiration) and respective policies are at the discretion of the AS. Those topics are intentionally left unspecified by this and other OAuth RFC in order to not limit the design options of AS implementations. Note for example that our (Deutsche Telekom's) AS treats refresh token expiration differently then your implementation. But thanks to RFC 7009, a client could revoke tokens using the same code snippet at both ASs.

 

Guidelines could be documented in an additional BCP (best current practice) RFC. If you like, you can post an individual draft and ask the WG to adopt it as WG document.

 

Best regards,

Torsten.

 


Am 16.01.2015 um 17:10 schrieb Amit Gupta <amit.gupta@insideview.com>:

The present rfc does not specify if the server should indefinitely keep the refresh token functional for every token (except revoked ones), and most refresh tokens are not used (due to authorize workflow is triggered by clients for authentication and resource access).

Hence, I feel the rfc should provide guidance for the transparent ways to limit validity of refresh tokens and what property/setting should be used to automatically expire refresh tokens, and who (between the server, client or uset) should be able to specify/modify/see this property(s).

In our implementation, the client can specify/modify this property (or server to set default) to limit refresh tokens. Its not clear if the user have visibility in number of refresh tokens before consent (or a say in refresh token revocation).
--
Thanks,
Amit Gupta
Software Security Architect,
InsideView Inc.

Sent from my mobile device,
Please excuse spelling typos.

On Jan 16, 2015 7:07 PM, Justin Richer <jricher@mit.edu> wrote:

This seems to be more of an implementation of revocation and handling refresh token lifetimes than anything that the spec would talk about. In what's described below, it doesn't seem that the client ever specifies the threshold, nor would the AS desire the client to do so. This is all something that can happen server-side, out of the view of the client.

In other words, I don't (personally) see what would have to change in the RFC for someone to implement this scheme. Can you please clarify what I'm missing?

 -- Justin

On 1/16/2015 3:39 AM, Amit Gupta wrote:

Hi Torsten, Stefanie, Marius 
 
I wanted to suggest an addition to the token revocation rfc7009 to provide more clarity on how revocation of refresh tokens should be handled. I feel the rfc should,
1. Describe how the client/resource-owner can provide “standing instructions†to the OAuth server to revoke refresh tokens. 
2. Describe the default way to for the OAuth server to define constrains for revocation of refresh token if this constrains are not specified by the client/resource owner.
 
The way it could be handled is:
1. Store a Client level threshold (clt) of number of valid refresh tokens per “user-client†combination (and OAuth server can store the default value for clt, if undefined by the client or resource owner). 
2. Keep the “time to live†for the access token reasonably small (few minutes to couple of hours). 
a. Revocation of active token removes the token ad the refresh token.
b. When new tokens are generated, up to “clt†number of Refresh tokens is maintained by the OAuth server (the most recent refresh token over writes the cltth  refresh token for user-client combination).
c. Revocation of inactive token removes the refresh token.
 
We have implemented such a scheme for our OAuth server, whereby “clt†is set to five by default (if not specified in client the properties). Therefore, 
1. Whenever a new token and refresh token is created, it overwrites the 5th (clt=5) oldest refresh token (for clientId-userId combination). 
2. Code grant tokens are only valid for 1 hour. When the token expires, refresh token is not removed.
3. When an “active†token is revoked, Token and it’s refresh token is also revoked. 
4. When an “expired†token is revoked, only the corresponding refresh token is revoked. 
 
The above example explicitly specify how to handle revocation of refresh tokens when the client has not informed the OAuth server about how expiry of refresh tokens should be handled. This also allows clients to specify certain constrains (like default time to live for tokens, and client level threshold for number of refresh tokens to keep active for each client-user combination). 
 
Are you planning to update the RFC on the scheme to handle revocation of refresh token? If not, would you be willing to include the proposed changes to RFC7009? Please let me know.
--
Thanks,
Amit

 



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

 


--------------070203000302040105010800-- From nobody Wed Jan 21 18:22:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996FF1A900A; Wed, 21 Jan 2015 18:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF6d9Rj6vK81; Wed, 21 Jan 2015 18:22:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EADB91A901F; Wed, 21 Jan 2015 18:22:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122022235.19741.40036.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 18:22:35 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 02:22:41 -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 Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-06.txt Pages : 16 Date : 2015-01-21 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 26 00:05:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B697E1A3B9D for ; Mon, 26 Jan 2015 00:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFtpeWzPbhqo; Mon, 26 Jan 2015 00:05:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A921A7017; Mon, 26 Jan 2015 00:05:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126080518.3175.14137.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 00:05:18 -0800 From: IETF Secretariat Archived-At: Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 08:05:24 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ From nobody Mon Jan 26 15:07:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3D51B2AFC for ; Mon, 26 Jan 2015 15:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS7u0kbAeGqz; Mon, 26 Jan 2015 15:07:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 851511B2AED; Mon, 26 Jan 2015 15:07:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126230720.425.28587.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 15:07:20 -0800 From: IETF Secretariat Archived-At: Subject: [OAUTH-WG] ID Tracker State Update Notice: X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 23:07:22 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ From nobody Tue Jan 27 08:15:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7981A8831 for ; Tue, 27 Jan 2015 08:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDiA5s8P1kVC for ; Tue, 27 Jan 2015 08:15:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF991A017D for ; Tue, 27 Jan 2015 08:15:55 -0800 (PST) Received: from [192.168.131.153] ([80.92.115.149]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M3igT-1XP01I0Qgj-00rDY7 for ; Tue, 27 Jan 2015 17:15:53 +0100 Message-ID: <54C7BA9A.4010501@gmx.net> Date: Tue, 27 Jan 2015 17:19:38 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MnqtmJET0rJKQNkVvimSueCTQCkwCV4ED" X-Provags-ID: V03:K0:lwuop947lsFabZD6uJg4VoyeG5P4C3R1wLUCQw8yarUg6Xceh0v iHIemFTZX+IJOIuGfJs0W1RH5x0Abn26ajW+CqB9iDePPP66QAokhFGVSlaPxjuIWUDlvBE A718vCfCYPhQmFXGDU/GAMlfInaJHWx0SYuhQuEdjWr028kmXpX4Huxee0eqXPwHVyQ3QSh PSJAfITnDlRUhtHYzMo0g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Nits regarding draft-ietf-oauth-spop-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 16:15:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MnqtmJET0rJKQNkVvimSueCTQCkwCV4ED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nat, Hi John, Hi Naveen, Hi all, in the appendix you include C# code. I was wondering where the code came from? Did you write the code or did you copy it from somewhere else? This question is relevant from a copyright point of view. RFC 5226 is mentioned in the document but missing in the informative reference section. A minor wording suggestion for the following paragraph: " All the OAuth security analysis presented in [RFC6819] applies so readers SHOULD carefully follow it. " I think the RFC 2119 language use of the word 'SHOULD' isn't appropriate here. I think it would be better to just say the following: " The OAuth security analysis presented in [RFC6819] applies to this document. Implementers are strongly encouraged to follow the recommended security practice. " (I guess it is not possible to highlight a few aspects since the entire document, i.e., RFC 6819, may be relevant depending on the chosen OAuth features.) I noticed a funny thing about the ABNF. When I used this ABNF code " ALPHA =3D %x41-5A / %x61-7A DIGIT =3D %x30-39 code_verifier =3D 42*128unreserved unreserved =3D ALPHA / DIGIT / "-" / "_" " I get an error from 'Bill's ABNF Parser'. The tool complains about the use of the "_" in the code_verifier label. It turns out that this is not an allowed token in ABNF as defined in RFC 5234 (at least that's my current understanding). Of course that is a bit inconvenient since we have been using "_" already in many OAuth parameters before, as the IANA OAuth parameter registry shows: http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml So, I hope that my understanding of ABNF is incorrect since otherwise we have messed things up a bit (at least when it comes to compliance with the ABNF syntax). This does, of course, not have any impact on implementations. Feedback appreciated. Ciao Hannes --MnqtmJET0rJKQNkVvimSueCTQCkwCV4ED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUx7qaAAoJEGhJURNOOiAt1boIAJzJUCmJ7eSz5ELoZAo+eWF0 GRtpzIhQgW03zyodCQj/ZkElfMuMcCZK+u053zrFdKHvzkFyRgp3SFEg1zoNw5vd KobfDm3Qy6Po9WWj/4TjTgQdEgmZ8NcIfzcWiikMn4hxdZYwxNSxEobxQ+aEe34F +TmGLmHWTFxVxcILHEOYwbpuj9XTQw7p1O0irewuUhVLfDxWYy734doDIsQjSLYU vfUGSq6jegIOZAny5YrREyFNe+hu5YlOjPWeSpQu1MBFVlu2Zx8kyezGWb7NMyRO t+AEXN8sfLQJFLif4IGl2rV1G3iDJinX8Xjou8jLX0EfW3i+rXk11odkJo4iAk4= =4UoG -----END PGP SIGNATURE----- --MnqtmJET0rJKQNkVvimSueCTQCkwCV4ED-- From nobody Tue Jan 27 08:30:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1043A1A887B for ; Tue, 27 Jan 2015 08:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCMzibHBKaLP for ; Tue, 27 Jan 2015 08:30:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5401A1BE6 for ; Tue, 27 Jan 2015 08:20:20 -0800 (PST) Received: from [192.168.131.153] ([80.92.115.149]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LezI3-1XuDwE0ZsV-00qgIZ; Tue, 27 Jan 2015 17:20:17 +0100 Message-ID: <54C7BBA4.4030702@gmx.net> Date: Tue, 27 Jan 2015 17:24:04 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Bradley , "naa@google.com >> Naveen Agarwal" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hPifKeaHXjPm4pKG9u9sQmJXLq39kKVCD" X-Provags-ID: V03:K0:Sqy5cULR+wMjGpxELv6LQepUIIOGvp5AnZRt1Oa/EQmZxlVjYWB ECxOv4ipNriFv7fKAoKIFkrZXmPfFh1KFLKZnfRPxJKYFaHj3+nC2pOcO2TBJlGGOkuyuOx 0mP7S/1CEfhMq9ojjoNu2S1WzX0BhmOoHmiC8GCxl3sTmMlEWWdg+IrRjF0McnLjxc55TKt gTVSHl1l/9c/lfEZzGPRw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 16:30:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hPifKeaHXjPm4pKG9u9sQmJXLq39kKVCD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nat, Hi John, Hi Naveen, thank you for the update and the all the changes you have made in response to the review comments. I am working on the shepherd write-up and I would need the following information. 1) What implementations of the spec are you aware of? 2) As document authors you need to confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Please confirm. Ciao Hannes PS: Here is the work in progress shepherd writeup: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-w= riteups/Writeup_OAuth_SPOP.txt --hPifKeaHXjPm4pKG9u9sQmJXLq39kKVCD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUx7ukAAoJEGhJURNOOiAt8kUIAIIoEJTZcGunYnHp7eWjivdH kAFvqt8lJ4p2brUncSqo2Jeti3aehzln2rNL28VTanqoEplVeVgsMBDEviRG9jQH UJzceKq7GDQG2TnwvEX8mjdPAkY08Uf9m3aMcqAxzmaTwYZFEWTUmcJV1bjohVbW Kjwx83kUdFxNRxhycCd+ZBLcZ8ZZL/xYhwcbACaYRBHGV2SFeM1i+5EuM1uUy15y mf+qe5CWbxXb9z8DFAalBVPHcy8v4Bg0jCXfDZxXt3X5cE+hlVQvNZZe3/ZHFxSr F2v+tqe1S+6QwzbtyJydGb/GtlqjAiU7xItXqdfv0u/wyNdI7ntaaxdQ8wA5bKE= =egHo -----END PGP SIGNATURE----- --hPifKeaHXjPm4pKG9u9sQmJXLq39kKVCD-- From nobody Tue Jan 27 11:38:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14981A897E for ; Tue, 27 Jan 2015 11:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAEr4IEIrJAu for ; Tue, 27 Jan 2015 11:38:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0361A8974 for ; Tue, 27 Jan 2015 11:38:00 -0800 (PST) Received: from [192.168.131.153] ([80.92.115.149]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOOJl-1YJEl10mt3-005rAf for ; Tue, 27 Jan 2015 20:37:58 +0100 Message-ID: <54C7E915.1080505@gmx.net> Date: Tue, 27 Jan 2015 20:37:57 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6FTpQ8Rp0jMglMKrXQo46sv0WJbkUcgFn" X-Provags-ID: V03:K0:WgTgmT0zDUnBcHLja+MOIkjmtK6m+Uf9uQpgNS2qDStNM7VZ5nh QKOD5dgXa+t69RSA26gvU9BK5+qtv/mkUXJvpNSzfxq7G6rjOGihS0r4uFoHC3exlBJkZnQ BWnoNb4RBSG5Po7k4XlsyKQQy0I4Mydeow45GHA4SGlQXJMoWo0P3ehNOGXCY6B8ldZhy6R CoyjBiIG4GSwlMeQoe60g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Shepherd Write-Up for draft-ietf-oauth-dyn-reg-management-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 19:38:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6FTpQ8Rp0jMglMKrXQo46sv0WJbkUcgFn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: Here is my write-up for the dynamic client registration management document: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-w= riteups/Writeup_OAuth_DynRegManagement.txt --6FTpQ8Rp0jMglMKrXQo46sv0WJbkUcgFn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUx+kVAAoJEGhJURNOOiAtOasH/1oeYK1+sQSYPGO93PjV7mxH YVYoou4Sa2UhkI1Xu8cTLMr2N2YPMLsE8u8tksY+hSZ9CWO9u0FI8yZzSvu5yro+ kHw3u0Uf6yVT74cS/SN21lds78i1+6O1Co85ErH5IC+S2jyc6pHu9tTL8vlY6y0K aXpwK7cOsuLpXwb5JllS1Ns9GZUjbmMp3diOm5qLxYx8QWqTpVyPp9OEMpc67wKK 5LRT6c9NnZwhD1dGxXMQbTftSSr6G537HSEw/SlAStTvmtkLKFMdClN4CU7iboQY cIBi9FbAZxVpLtpUAscM8Rm+8JZS+ygzSsgLma2iux+pMM/5nkHRfminx3JGQK8= =HBQY -----END PGP SIGNATURE----- --6FTpQ8Rp0jMglMKrXQo46sv0WJbkUcgFn-- From nobody Tue Jan 27 12:09:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1E41A8A75; Tue, 27 Jan 2015 12:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOyarZjvHPV3; Tue, 27 Jan 2015 12:09:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C74DC1A8A50; Tue, 27 Jan 2015 12:08:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127200853.10805.16064.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 12:08:53 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 20:09:09 -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 Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-08.txt Pages : 17 Date : 2015-01-27 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 27 12:11:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDC41A8A71 for ; Tue, 27 Jan 2015 12:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDn0B6h5qRZg for ; Tue, 27 Jan 2015 12:10:56 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95A01A8A8F for ; Tue, 27 Jan 2015 12:10:43 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-15-54c7f0c101b4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 68.8A.03762.2C0F7C45; Tue, 27 Jan 2015 15:10:42 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t0RKAfv4023003 for ; Tue, 27 Jan 2015 15:10:41 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0RKAZGl028512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 27 Jan 2015 15:10:40 -0500 Message-ID: <54C7F0B7.9050209@mit.edu> Date: Tue, 27 Jan 2015 15:10:31 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20150127200853.10805.16064.idtracker@ietfa.amsl.com> In-Reply-To: <20150127200853.10805.16064.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixCmqrHvow/EQg64/LBYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxql5L5kLtvFX/Lh/lKWB8Q53FyMnh4SAicTXy98YIWwxiQv3 1rN1MXJxCAksZpKYt/kGM4RzjFGi7UwzI4TzgUli4Z5n7CAtvAJqEuv+d4G1swioSry9sB/M ZgOyp69pYQKxRQWiJGaff8AKUS8ocXLmExYQW0RASOL5zj6wGmEBP4lNnUfB4kICjhK/Dv0C i3MKOEms3HyOGcRmFrCVuDN3N5QtL7H97RzmCYwCs5CMnYWkbBaSsgWMzKsYZVNyq3RzEzNz ilOTdYuTE/PyUot0DfVyM0v0UlNKNzGCw1KSZwfjm4NKhxgFOBiVeHgjrh8LEWJNLCuuzD3E KMnBpCTKe+b98RAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrz33wHleFMSK6tSi/JhUtIcLEri vJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeN+ADBUsSk1PrUjLzClBSDNxcIIM5wEazvYBZHhx QWJucWY6RP4Uo6KUOO9VkGYBkERGaR5cLyxtvGIUB3pFmFcapJ0HmHLgul8BDWYCGty38gjI 4JJEhJRUA2PojXunXbpVhdM9vW0sz33+JHtImeniYd3SkHUv3KQ+XHQKtZg7NfK7wP+z7qc/ VnV4d8WfDRNdxlabcVnC88dt+bvn/nAtMXK9qM5fOutjoV2OxLGvgcfkAm7e2rIkq15EWday letE8IU195ynL5BsXPK24ObsjvWbfP/OFsyY1Rk+WaLRTUqJpTgj0VCLuag4EQCHWv8v9gIA AA== Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 20:11:01 -0000 Hannes noticed that we were still pointing to the old HTTP RFC (2616), so we've simply bumped the reference to the new version (7231) and haven't changed anything else. -- Justin On 1/27/2015 3:08 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : OAuth 2.0 Dynamic Client Registration Management Protocol > Authors : Justin Richer > Michael B. Jones > John Bradley > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-management-08.txt > Pages : 17 > Date : 2015-01-27 > > Abstract: > This specification defines methods for management of dynamic OAuth > 2.0 client registrations for use cases in which the properties of a > registered client may need to be changed during the lifetime of the > client. Not all authorization servers supporting dynamic client > registration will support these management methods. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jan 27 12:30:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9321A8A29 for ; Tue, 27 Jan 2015 12:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 SLUj7p4nNad3 for ; Tue, 27 Jan 2015 12:30:03 -0800 (PST) Received: from nm39-vm1.bullet.mail.bf1.yahoo.com (nm39-vm1.bullet.mail.bf1.yahoo.com [72.30.239.145]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72AAF1A1ADA for ; Tue, 27 Jan 2015 12:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422390602; bh=HoSjVEX4QnDxQJO+4JwNsLLQ+ibMEFPuwGTlqk3S3pw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=XVPupmomjv0Kssgzzyjb7kOAJEpV3u5cimgswIZB29cD0oRibcIVDyUsY90kCDHDBshVAR5QEVnBkjF97LJW3oqZE9FX1XHZ1M7OV6M0gHjQY9tmsKGF7qPvPErWiZ6b05teZZN89g6z9dIRE8pgZZiqXFN+aSzUoxJvHJ1w4T6o+OwHxBW+QbQphuZH6ad3dMinPDdHhsdTK9i8omeIrfM5uMsaRRTU0cHhLFCveoYpBx3gBjznAUgsrmT7crqu9dfv3FphBSTlVXe4Li9wETb+tfhlZRkrBC6GLZ+r5PLsmW9Ty2dzQvrxIberS7pFWCqpmDVCaH+xJ8z1L5cXGg== Received: from [98.139.214.32] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jan 2015 20:30:02 -0000 Received: from [98.139.212.215] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jan 2015 20:30:02 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 27 Jan 2015 20:30:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 623969.30222.bm@omp1024.mail.bf1.yahoo.com X-YMail-OSG: e4k6I98VM1l25Dy_6d56npX3D_SAEXC5jhyS2Fy7Odlxdnvgl8h19_e55vSr9Rc d_vEkMvDBfghDGhKy6EDSzv7y72WbsHCEjs67I0caXqnvYLFmfdG605secNyMiHaEcO43OkpFFXU hl7nf7vIy5719mIc2Eh.6pakIt68Fdxx6b3nb5IsZIAmvdrO18Uk4y87neNBkE5AAXP9YnPHZvQU SPxSogvPUFacDFedkpXBeZyaWWeQDVy8XtgXHFbj1uRkSHWiMmwSniN1uTWwF569.QD8LtHLCxhR NgH_67jiXRJBedylA6wLQSsLSt7xtiR7YNPX3LvV.dcVYgJY_Bu67eM6fEHeJo_bV3w.UUXuTXfN p_UeEBxAfL8c2vVwpPHRv0GfQ2BhGoGOd2VtKIvnKasSKm8tP98CcoHSDjxlzoRchwD.qjEEyLGi momURn.8sUr4XwWEBXFNRNs0k1DQFAB_tNvazzw.D6aIjHYpSUdXlvzgU7UlUoHH00KZLUkwcJJh oi60h9pUPDLvYoud1.Pairvk3MlAxHkntA7qEyOXqvVUmfwUqup6Tl133lxqHdq1VnA-- Received: by 76.13.26.79; Tue, 27 Jan 2015 20:30:02 +0000 Date: Tue, 27 Jan 2015 20:30:01 +0000 (UTC) From: Bill Mills To: "oauth@ietf.org" Message-ID: <2113997045.1403215.1422390601736.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150122022235.19741.40036.idtracker@ietfa.amsl.com> References: <20150122022235.19741.40036.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1403214_1309327360.1422390601733" Archived-At: Subject: [OAUTH-WG] Feedback Re: I-D Action: draft-ietf-oauth-spop-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 20:30:05 -0000 ------=_Part_1403214_1309327360.1422390601733 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 7.2 -- =C2=A0"If the server does not support PKCE, it does not generate err= or." should read "If the server does not support PKCE it does not generate = an error." Otherwise read to go in my opinion.=20 On Wednesday, January 21, 2015 6:23 PM, "internet-drafts@ietf.org" wrote: =20 =20 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 Working Group = of the IETF. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Proof= Key for Code Exchange by OAuth Public Clients =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Nat Sakimu= ra =C2=A0 =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 Naveen Agarwal =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-s= pop-06.txt =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 16 =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-01-= 21 Abstract: =C2=A0 OAuth 2.0 public clients utilizing the Authorization Code Grant are =C2=A0 susceptible to the authorization code interception attack.=C2=A0 Thi= s =C2=A0 specification describes the attack as well as a technique to mitigat= e =C2=A0 against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-06 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 ------=_Part_1403214_1309327360.1422390601733 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
7.2 --  "If the server does not support PKCE, it does not generate error." = should read "If the server does not support PKCE it does not generate an error."

Otherwise read to go in my opinion.


=
On Wednesday, January 21, 2015 6:23 PM, "internet-dr= afts@ietf.org" <internet-drafts@ietf.org> wrote:
=


A New Internet-Draft is availab= le from the on-line Internet-Drafts directories.
This draft is a work i= tem of the Web Authorization Protocol Working Group of the IETF.

&nb= sp;       Title          : Proof K= ey for Code Exchange by OAuth Public Clients
       = Authors        : Nat Sakimura
     =                     John= Bradley
                  =         Naveen Agarwal
    Filename&n= bsp;       : draft-ietf-oauth-spop-06.txt
  &nb= sp; Pages          : 16
    Dat= e            : 2015-01-21

Abstract:  OAuth 2.0 public clients utilizing the Authorization Code Grant ar= e
  susceptible to the authorization code interception attack.&nbs= p; This
  specification describes the attack as well as a techniqu= e to mitigate
  against the threat.


The IETF datatracke= r status page for this draft is:
https://datatracker.ietf.org= /doc/draft-ietf-oauth-spop/

There's also a htmlized version avai= lable at:
http://tools.ietf.org/html/draft-ietf-oauth-spop-06=

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-06

Please note that it may take a couple of minutes from the time of submissi= on
until the htmlized version and diff are available at tools.ietf.org.<= br>
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.o= rg/internet-drafts/

____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/lis= tinfo/oauth


------=_Part_1403214_1309327360.1422390601733-- From nobody Wed Jan 28 03:36:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2081A1A91 for ; Wed, 28 Jan 2015 03:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwa2F-_rvt3I for ; Wed, 28 Jan 2015 03:36:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C5E1A1A8A for ; Wed, 28 Jan 2015 03:36:36 -0800 (PST) Received: from [192.168.131.154] ([80.92.115.149]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mg42v-1Y4YoJ0Zmf-00NTLa for ; Wed, 28 Jan 2015 12:36:34 +0100 Message-ID: <54C8CA75.4040007@gmx.net> Date: Wed, 28 Jan 2015 12:39:33 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="brJ0XOgMJBHXdWgQVSm2hC6tiVT83fw2J" X-Provags-ID: V03:K0:Y1nfpmnUIdMrcQJeK4DSxE7GP102HhdeCyzWsQ0g4hYtglzj7YD 9pWcUOoPaemOqCxXuQuOueqwh2zgjXbo+WfdD2C0/EJ8tcOp9EtrewIq9l/Q36ulPYrmmJW N5ivUA95rfbNMUVL3M4ox4FTx7ZvQK8SVeGqptMrIsJRtU5vcWWBOs/TrMp+KdD5oJLivJq jGy3xp4JYE+7NWtAhi0sA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Token Introspection Spec: Implementations & IPR disclosure confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:36:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --brJ0XOgMJBHXdWgQVSm2hC6tiVT83fw2J Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, Hi all, I am working on the shepherd write-up and I would need the following information: 1) To all: What implementations of the spec are you aware of? 2) To Justin: You need to confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Please confirm. Ciao Hannes --brJ0XOgMJBHXdWgQVSm2hC6tiVT83fw2J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUyMp1AAoJEGhJURNOOiAtzAoIAJ/Tbw3iZb/7Z5hFC0jETgq2 p+tN0qZpIfRDT1quINYWDR4L0L09NmkaZyGhGRsUAmUrgQvLhNtdXrPsPMBz9Swx AEMpa7WSjBDGoz9Lk/w8ZlGxneA8KfmRUJefXqiNN5uRrkeqSznGM9sTUY9mvfHQ axHJeAdYus7rB7sqYF4zPkDUBKQPxud7U75/83Dmot8n9YOoEq4KzkGHob9CvHra 3/WeK8NKrE5nymR5k1K2oGHscKlEO3PDXYrhw9EawuS6t1eNXeD34guaX0TaVLh4 QnKPu1KDYRasFmNPmHIs2FMtDvvT4lKDpRrRGq3q01Dv0ptA1/hG3jPN/Owf9gk= =7fUx -----END PGP SIGNATURE----- --brJ0XOgMJBHXdWgQVSm2hC6tiVT83fw2J-- From nobody Wed Jan 28 04:42:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE46C1A1BF1 for ; Wed, 28 Jan 2015 04:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-pD7Mdz1Mur for ; Wed, 28 Jan 2015 04:42:56 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0831F1A1B20 for ; Wed, 28 Jan 2015 04:42:55 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 36D1A42E064; Wed, 28 Jan 2015 07:42:55 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 2E52442E056; Wed, 28 Jan 2015 07:42:55 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0224.002; Wed, 28 Jan 2015 07:42:54 -0500 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Token Introspection Spec: Implementations & IPR disclosure confirmation Thread-Index: AQHQOu6x1e7SKN/4YkGjDD4M+pqFDpzVzd2A Date: Wed, 28 Jan 2015 12:42:53 +0000 Message-ID: <82A7ABB7-5869-43D5-9E4E-075724813E1B@mitre.org> References: <54C8CA75.4040007@gmx.net> In-Reply-To: <54C8CA75.4040007@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.12.52] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Introspection Spec: Implementations & IPR disclosure confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 12:42:58 -0000 I am not aware of an IPR disclosures required for this. There are implementations in MITREid Connect: https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/ And in the WSO2 suite: http://pzf.fremantle.org/2013/11/oauth2-introspection-with-wso2-esb-and.htm= l I also found this PHP AS implementation (haven't tested it): https://github.com/fkooman/php-oauth-as As well as any compliant UMA implementation (so, CloudIdentity, Gluu oxAuth= , etc.). -- Justin On Jan 28, 2015, at 6:39 AM, Hannes Tschofenig = wrote: > Hi Justin, Hi all, >=20 > I am working on the shepherd write-up and I would need the following > information: >=20 > 1) To all: What implementations of the spec are you aware of? >=20 > 2) To Justin: You need to confirm that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. Please confirm. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 28 09:22:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BFE1A8842 for ; Wed, 28 Jan 2015 09:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONF5zDghHaZf for ; Wed, 28 Jan 2015 09:22:38 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B8E1A884C for ; Wed, 28 Jan 2015 09:22:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4E20EE2039 for ; Wed, 28 Jan 2015 12:22:36 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22275-03 for ; Wed, 28 Jan 2015 12:22:35 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D6770E2035 for ; Wed, 28 Jan 2015 12:22:34 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t0SHMYCF019359; Wed, 28 Jan 2015 12:22:34 -0500 From: Derek Atkins To: oauth@ietf.org Date: Wed, 28 Jan 2015 12:22:33 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [OAUTH-WG] Call for Agenda Items for IETF-92 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 17:22:39 -0000 HI, IETF-92 in Dallas is 50-some days away. If you feel you want agenda time to talk about a draft or topic please get your requests into the chairs. Thanks, -derek and hannes -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jan 28 10:38:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B9D1A1B04 for ; Wed, 28 Jan 2015 10:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZgXxb4FnyAp for ; Wed, 28 Jan 2015 10:38:44 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B5F1A3BA5 for ; Wed, 28 Jan 2015 10:38:44 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so20283424lbv.13 for ; Wed, 28 Jan 2015 10:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=wshlxQzwJ9EF4bRfmrLB2kJcrAOftIuyN6EKo3+XpcE=; b=qlmLkOILvhHb9EFljhe9O+8vbcEcyMSfV+HG/Dfku4Bfht74pFZTt9VBIks46L29gL LnfhmFW3yCuJwQQrJoOLm8JJF04kznu5I5Ky/FamsMhL8izeFpwRjpCkN54nglxlT9r3 popH9ncuJccsGoABa1P96VxXqFF640lk64cp9FTQoF3IiBwowaG9JLJYY1Y2mLbhyDc1 JN6I815ccE47CBiYQ/fq4pBVNC9NWzES4pG+A5Har98a++7+L+U6d55Zg+fqyyV+JJpP mWQfMcHk0Dmhc+AVDctYWKEqZy9UPe5eAPhcW9Vo8BzsE3tn3YKvbQXXoH15XXhP+W+Y z1xg== X-Received: by 10.152.4.200 with SMTP id m8mr10296156lam.2.1422470322506; Wed, 28 Jan 2015 10:38:42 -0800 (PST) MIME-Version: 1.0 References: <54C8CA75.4040007@gmx.net> From: Thomas Broyer Date: Wed, 28 Jan 2015 18:38:41 +0000 Message-ID: To: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=089e013d115246d363050dbaaeb6 Archived-At: Subject: Re: [OAUTH-WG] Token Introspection Spec: Implementations & IPR disclosure confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 18:38:47 -0000 --089e013d115246d363050dbaaeb6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have one implementation (docs should be made public very soon), and we've also made https://github.com/pole-numerique/oasis-php-integration (repo will soon be renamed) as a client to the API for implementers of RPs in PHP= . Le mer. 28 janv. 2015 12:36, Hannes Tschofenig a =C3=A9crit : > Hi Justin, Hi all, > > I am working on the shepherd write-up and I would need the following > information: > > 1) To all: What implementations of the spec are you aware of? > > 2) To Justin: You need to confirm that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. Please confirm. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e013d115246d363050dbaaeb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have one implementation (docs should be made public very s= oon), and we've also made https://github.com/pole-numerique/oasis-php-integrat= ion (repo will soon be renamed) as a client to the API for implementers= of RPs in PHP.


Le=C2=A0mer. 28 janv. 2015 12:36,=C2=A0Hanne= s Tschofenig <hannes.tschof= enig@gmx.net> a =C3=A9crit=C2=A0:
= Hi Justin, Hi all,

I am working on the shepherd write-up and I would need the following
information:

1) To all: What implementations of the spec are you aware of?

2) To Justin: You need to confirm that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. Please confirm.

Ciao
Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--089e013d115246d363050dbaaeb6-- From nobody Wed Jan 28 11:34:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFB51A1A1B for ; Wed, 28 Jan 2015 11:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDU1Picw9U6Y for ; Wed, 28 Jan 2015 11:34:45 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A451A01A8 for ; Wed, 28 Jan 2015 11:34:44 -0800 (PST) Received: from mail-wi0-f179.google.com ([209.85.212.179]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKVMk507na8KzwOdyLKpoF/CFm/O/7MJ5j@postini.com; Wed, 28 Jan 2015 11:34:44 PST Received: by mail-wi0-f179.google.com with SMTP id l15so14383473wiw.0 for ; Wed, 28 Jan 2015 11:34:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7+XS16tmuAkajHVaTcOGgdizNCs1zAdGUpq+a9Ak+zE=; b=VmYPc2glYC4Tb5r2tuAkvvPLcPS/fkkHPeonVjnGP38R7K65fRtKDaqZOcuJkJwEGX wo/BT94DJ/08KervE7pGCdjHreUg+2WTZ4wDOF0zFaWgKKKe/pjNDrsPc5Fo3fu2vCeh awiO2Sq6Ne+Jew8ZJahZLhaBmbfPE8MnEMbYmTVjFIMnJu7Jf1odminZAsRYwTca4hbo Ub62EB76oI6/kvuLQUHZdHEWEBhqLPbjR5Acko0gogbAOEhpnwPwrhsrnkNqPOmnpcse WQty5OkQtGIqFlrlejRUO3djmkpTEvPP+68N+dlyPxqWW7E1nFWXr/KPUUZG0dSGMDgo ySag== X-Gm-Message-State: ALoCoQkm45WMDXtUxaECEDM5qFShrfhbox3sU5BY3IGOoqLJjJYAi2ZWve59/Q1GDfZ0aEC0zYcF7jOuMI0Lp08ewBe3CpQzr7pZzpmaDHdtkdddA1aaJRVbtc8Sz9Uw3aR1ce/XngQf X-Received: by 10.180.207.211 with SMTP id ly19mr10244491wic.73.1422473682003; Wed, 28 Jan 2015 11:34:42 -0800 (PST) X-Received: by 10.180.207.211 with SMTP id ly19mr10244479wic.73.1422473681915; Wed, 28 Jan 2015 11:34:41 -0800 (PST) Received: from ?IPv6:2001:470:78f6::3166:ba5f:e11d:ae6b? ([2001:470:78f6:0:3166:ba5f:e11d:ae6b]) by mx.google.com with ESMTPSA id p6sm4094356wia.14.2015.01.28.11.34.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 11:34:41 -0800 (PST) Message-ID: <54C939CF.4080609@pingidentity.com> Date: Wed, 28 Jan 2015 20:34:39 +0100 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <54C8CA75.4040007@gmx.net> In-Reply-To: <54C8CA75.4040007@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Token Introspection Spec: Implementations & IPR disclosure confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 19:34:47 -0000 I have added client support to mod_auth_openidc as of version 1.7.0: https://github.com/pingidentity/mod_auth_openidc/releases/tag/v1.7.0 [1]. Hans. [1] the release notes say draft 00 as of last november but it should still be compliant with the latest draft On 1/28/15 12:39 PM, Hannes Tschofenig wrote: > Hi Justin, Hi all, > > I am working on the shepherd write-up and I would need the following > information: > > 1) To all: What implementations of the spec are you aware of? > > 2) To Justin: You need to confirm that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. Please confirm. > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Wed Jan 28 15:31:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03F31A701F for ; Wed, 28 Jan 2015 15:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGFwkoc16bIX for ; Wed, 28 Jan 2015 15:31:43 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690AA1A7021 for ; Wed, 28 Jan 2015 15:31:42 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id u14so22379206lbd.2 for ; Wed, 28 Jan 2015 15:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XiPKCmy56dT+gaHqhWLXL0qxx+6uaW/wv0K1H5lN3MU=; b=H3tCMTeNfkovarRnvz3xG4pg8HmEiptOTjSiqFSY4r+hq6RoJIIpPrgcl79sE6t9tE RSrJW1mX+wp8Get4lXUGtFFNEXhhyouGE+W8jNfuUSpk5YWNNqLlZHUyFRh5g9rw8O+H 8Fc7QVkh8wHLz8lNBo21XgrwkejE4S7OrS3YAeGj2H4RS++FfXmTGvII2pkDqgT3+82v CV2C/nBq0hFLQ9c7YSF7RAC7wfqLrIbyS+BosXNIvjZeaboTwEcXqtMlG+NeEnnVU5S1 RykSQ9gGQBW7YRHGAHi5BAVwtS7ovp4bjy8Qw2ctcPPVHnvjxWFGIBfMzPsZ4Sw35EV3 Eb8A== MIME-Version: 1.0 X-Received: by 10.152.30.6 with SMTP id o6mr11469281lah.64.1422487900766; Wed, 28 Jan 2015 15:31:40 -0800 (PST) Received: by 10.112.167.134 with HTTP; Wed, 28 Jan 2015 15:31:40 -0800 (PST) Date: Wed, 28 Jan 2015 18:31:40 -0500 Message-ID: From: Kathleen Moriarty To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Shepherd report for draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 23:31:46 -0000 Hi Hannes, I am going through the shepherd report for draft-ietf-oauth-dyn-reg and see that this still lists an open question around IPR, has that been answered and is just a matter of updating the shepherd report? If not, how can I help resolve these questions? I also found a nit in #7 that you may want to fix, "did" should be "didn't". "The working group did seem to worry about these aspects though." Thanks for the report and your work shepherding the draft. Copying Oauth because of the IPR concern. -- Best regards, Kathleen From nobody Wed Jan 28 18:14:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438551A8ABF; Wed, 28 Jan 2015 18:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P705nfHjQEsi; Wed, 28 Jan 2015 18:14:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC13F1A19EC; Wed, 28 Jan 2015 18:14:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129021450.19598.80182.idtracker@ietfa.amsl.com> Date: Wed, 28 Jan 2015 18:14:50 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 02:14:52 -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 Working Group of the IETF. Title : Proof-Of-Possession Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-01.txt Pages : 11 Date : 2015-01-28 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 28 18:18:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C334C1A0263 for ; Wed, 28 Jan 2015 18:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiQW9ZFZ-SCM for ; Wed, 28 Jan 2015 18:18:33 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8E81A19F7 for ; Wed, 28 Jan 2015 18:18:32 -0800 (PST) Received: from BY2PR03CA071.namprd03.prod.outlook.com (10.141.249.44) by BN3PR0301MB0833.namprd03.prod.outlook.com (25.160.154.143) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 02:18:30 +0000 Received: from BL2FFO11FD008.protection.gbl (2a01:111:f400:7c09::173) by BY2PR03CA071.outlook.office365.com (2a01:111:e400:2c5d::44) with Microsoft SMTP Server (TLS) id 15.1.65.19 via Frontend Transport; Thu, 29 Jan 2015 02:18:30 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Thu, 29 Jan 2015 02:18:29 +0000 Received: from TK5EX14MBXC291.redmond.corp.microsoft.com ([169.254.2.242]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0224.003; Thu, 29 Jan 2015 02:18:18 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-01.txt Thread-Index: AQHQO2l2JVKWQz09SkKBEblwNwhBLZzWXC0A Date: Thu, 29 Jan 2015 02:18:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A21FD638@TK5EX14MBXC291.redmond.corp.microsoft.com> References: <20150129021450.19598.80182.idtracker@ietfa.amsl.com> In-Reply-To: <20150129021450.19598.80182.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=microsoft.com; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(377424004)(230783001)(47776003)(55846006)(15975445007)(2900100001)(2920100001)(104016003)(2501002)(1720100001)(92566002)(102836002)(77156002)(450100001)(62966003)(66066001)(2950100001)(50466002)(110136001)(2351001)(23726002)(46406003)(106466001)(86612001)(86362001)(106116001)(46102003)(6806004)(50986999)(54356999)(76176999)(107886001)(19580395003)(33656002)(2656002)(19580405001)(87936001)(97756001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0833; H:mail.microsoft.com; FPR:; SPF:None; MLV:sfv; LANG:en; X-DmarcStatus-Test: Passed X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(3003004)(3005004); SRVR:BN3PR0301MB0833; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN3PR0301MB0833; X-Forefront-PRVS: 0471B73328 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0833; X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2015 02:18:29.8472 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0833 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 02:18:35 -0000 This version updates the references to other drafts, including referencing = draft-ietf-oauth-pop-architecture instead of draft-hunt-oauth-pop-architect= ure. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Wednesday, January 28, 2015 6:15 PM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-01.txt 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 Working Group = of the IETF. Title : Proof-Of-Possession Semantics for JSON Web Tokens= (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-01.txt Pages : 11 Date : 2015-01-28 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-proof-of-possession-01 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 From nobody Thu Jan 29 01:08:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A0E1A01D8 for ; Thu, 29 Jan 2015 01:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRyASDK6bhTo for ; Thu, 29 Jan 2015 01:08:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6931A0102 for ; Thu, 29 Jan 2015 01:08:54 -0800 (PST) Received: from [192.168.131.128] ([80.92.115.149]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0ME33j-1YT51o1P3f-00HQmB; Thu, 29 Jan 2015 10:08:51 +0100 Message-ID: <54C9F89D.4060101@gmx.net> Date: Thu, 29 Jan 2015 10:08:45 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rLNpgVjS77K51t2DukP2cUnCvwLacGHMk" X-Provags-ID: V03:K0:MezZXc0Gm96pnGffmS7F90OMGpcEZcT66xEPOb7g2ZVlmx81NAS o6giEbpoSiqmCnV82Kt4iRjN4772/M8H/2+pkl/GvZRvvAWiDtS0SX84T/kJrC1sFMqFYlo LYPSsyOYeSETZCUF6G6qbCApxA1dMAjSLhJsawDmWZyg4EpkM1y+/n0hSUIxPwt+QjFvYx+ XcKFlDs+skSFSKQJ+Ws1A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd report for draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 09:08:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rLNpgVjS77K51t2DukP2cUnCvwLacGHMk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for catching the typo. Regarding the IPR (or more copyright) there is an open issue that I was not able to resolve since neither Scott Bradner nor Jorge (the IETF lawyer) responded to me. I updated the write-up! Ciao Hannes On 01/29/2015 12:31 AM, Kathleen Moriarty wrote: > Hi Hannes, >=20 > I am going through the shepherd report for draft-ietf-oauth-dyn-reg > and see that this still lists an open question around IPR, has that > been answered and is just a matter of updating the shepherd report? > If not, how can I help resolve these questions? >=20 > I also found a nit in #7 that you may want to fix, "did" should be "did= n't". >=20 > "The working group did seem to worry about these aspects though." >=20 > Thanks for the report and your work shepherding the draft. Copying > Oauth because of the IPR concern. >=20 >=20 --rLNpgVjS77K51t2DukP2cUnCvwLacGHMk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUyfidAAoJEGhJURNOOiAtDIYIAJHwuSDYsvD2ISfAO6loXKAE v+fKUf23DhdouE3UGlaNGYrxG1pUu4XqFV3kvg45Rxaja1RW8cLTdTSq2GAg8qmr CAyA+NLC/XbL6/bq7r9AFck8Hl4EQuNNwuxDiU9bKJrFrzvwXHQMOLl0eCAc5gne C4YP15xJTRxOF2xlXL8WpKWuy/oNwl+A9rOoXQFPZszejw5pkp1VLZNOGf7axrsO /zzeFR9tIha06l6RXpL/lEeNG39uDFHOjKwjGzMOyUpkmdMyG+NfvUwBNvqDQRtE DZ/T0uiKRASawz9CAORBXPcCN0yoT4zGmIsV6abAmAmm9tOd7ZvOUP9I8K9CXQI= =cCc6 -----END PGP SIGNATURE----- --rLNpgVjS77K51t2DukP2cUnCvwLacGHMk-- From nobody Thu Jan 29 04:30:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE721A0033 for ; Thu, 29 Jan 2015 04:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCUKfETWhXuF for ; Thu, 29 Jan 2015 04:30:41 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3AA1A01D8 for ; Thu, 29 Jan 2015 04:30:40 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id l89so27243751qgf.3 for ; Thu, 29 Jan 2015 04:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nHv/cavm1mE/eJ3jmsL/BJWO3DQR04fZ3Ky/bq4uu0Q=; b=Ti+Pi4wr/1CaXRRFiosKY8C6eqni+jKzQdgC4gnrPT2Z0mu5jJDat5n7Bp+KxXQCiI rDwIA22+u7lFXyfCPVJ9YliM8ujBJTzF2EbapewL1t8c4JTsdrsphWrdNoc1W9aqahpF EyhRCjCGih6yb4wKVzBw6UJKo+L1hKYJa1lbfeyqF7lVhwNqxlPUzUQlkB1vP4y5NOtY z26IbXcnuLi0bWT3ZBIarHCpvGbQ9uoTzD5/ooeC5k7MkyGZJlT4zT19THfD5ygUAQhW rlqWGwEFk6BTHf5RcfeA6hX+sPiZ2p2OVMvPP7rhwjbmVhBI7Uvth7SOyqQ0SE/2CaL7 9m9A== X-Received: by 10.224.75.7 with SMTP id w7mr756117qaj.6.1422534640130; Thu, 29 Jan 2015 04:30:40 -0800 (PST) Received: from [10.227.93.89] (mobile-166-171-185-041.mycingular.net. [166.171.185.41]) by mx.google.com with ESMTPSA id e2sm6853207qaf.49.2015.01.29.04.30.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 04:30:39 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54C9F89D.4060101@gmx.net> Date: Thu, 29 Jan 2015 07:30:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54047443-E7B7-4D04-BC74-927F73B1F36F@gmail.com> References: <54C9F89D.4060101@gmx.net> To: Hannes Tschofenig Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Shepherd report for draft-ietf-oauth-dyn-reg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 12:30:42 -0000 Hi Hannes, Sent from my iPhone > On Jan 29, 2015, at 4:08 AM, Hannes Tschofenig = wrote: >=20 > Thanks for catching the typo. >=20 > Regarding the IPR (or more copyright) there is an open issue that I was > not able to resolve since neither Scott Bradner nor Jorge (the IETF > lawyer) responded to me. >=20 Thanks for the updated info. I'm reviewing the draft and will see what I ca= n do about getting you a response as this would be good to resolve before IE= SG review. > I updated the write-up! Thank you! Kathleen=20 >=20 > Ciao > Hannes >=20 >> On 01/29/2015 12:31 AM, Kathleen Moriarty wrote: >> Hi Hannes, >>=20 >> I am going through the shepherd report for draft-ietf-oauth-dyn-reg >> and see that this still lists an open question around IPR, has that >> been answered and is just a matter of updating the shepherd report? >> If not, how can I help resolve these questions? >>=20 >> I also found a nit in #7 that you may want to fix, "did" should be "didn'= t". >>=20 >> "The working group did seem to worry about these aspects though." >>=20 >> Thanks for the report and your work shepherding the draft. Copying >> Oauth because of the IPR concern. >=20 From nobody Thu Jan 29 14:02:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4161A039C for ; Thu, 29 Jan 2015 14:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnSDG2s9lLsE for ; Thu, 29 Jan 2015 14:02:30 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CED1A00DF for ; Thu, 29 Jan 2015 14:02:30 -0800 (PST) Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKVMqt9ZlUwNYm01zDRXLJosVB/61DfDI9@postini.com; Thu, 29 Jan 2015 14:02:30 PST Received: by mail-ie0-f179.google.com with SMTP id x19so39957195ier.10 for ; Thu, 29 Jan 2015 14:02:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=9FFjtoGDrJ5+1hOBTxctv+l3YRp1pO3E31t6EIH+Gw4=; b=aKyPviisJcIlPcJzUUBqmRRqH+IrrKkYc/qlIVv5KIQP3zD2eR5iiLV5b7eitVD05h cIxKHc1fRgainq3BXE77KtERbFOXSFoO6tUARFBbTi6SJWZCveI1IErScNQSqNq1mcnE zCmKR7WSkrXazoh8vNNLWpTx6Yp81J8sEGF7b+2fGBmGKQWQIAbSaS6eBbXaL6QQfnEf XiuZFhvHZMONWPoBpSX4eBx4Ejy9qt2Z0Tlx8gcKFvwRfpDHNKV137ITwmwr1CK8dtMl Y1NhhBhMrsw+s5LbUbz/A1C4NyYL/yafdAGmSk7obTS8LChqdVttXL/24nTA8BlEti+J eOHA== X-Gm-Message-State: ALoCoQlnjRnjjDwSQ7wImBgi2ZtYGbIED6OslSxCKjxSRKja2zbNE3tmkLIS9x4IxuTCsDfe9GMbctLEPvRd66cSwKQH/B2rx2V/AQ6VrM3NVG7Z1y/QY/uMRrLIhNmBZ+h4bSUfQkZ+ X-Received: by 10.107.10.17 with SMTP id u17mr3597929ioi.45.1422568948745; Thu, 29 Jan 2015 14:02:28 -0800 (PST) X-Received: by 10.107.10.17 with SMTP id u17mr3597915ioi.45.1422568948649; Thu, 29 Jan 2015 14:02:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 14:01:58 -0800 (PST) From: Brian Campbell Date: Thu, 29 Jan 2015 15:01:58 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a113ee77eda68ff050dd1a48e Archived-At: Cc: Naveen Agarwal Subject: [OAUTH-WG] Misplaced Resource Owner in PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:02:33 -0000 --001a113ee77eda68ff050dd1a48e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have the authorizatio= n request going to the "Resource Owner" and goes on to say that 'the resource owner responds as usual, but records "t(code_verifier)" and the transformation method.' That's not what the resource owner does. I know the protocol flow in RFC 6749 tries to have authorization grants be these abstract things that sorta come from the resource owner but, in the context of the the authorization request and authorization code grant type, it really doesn't work like that. The content in =C2=A71.1 seems, at best, = to be more abstract and complicated than it needs to be and is bordering on being just kinda wrong. The RO and AS boxes should probably be consolidated into just the AS. The RO could be omitted from the diagram, I think. Or stick it over with the client, if you really want it in there, and have it authenticating and approving authorization though an interaction with the AS. Or something like that... [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 1.1 . Protocol Flow +--------+ +---------------+ | |--(A)-- Authorization Request --->| | | | + t(code_verifier), t | Resource | | | | Owner | | |<-(B)--- Authorization Grant -----| | | | +---------------+ | Client | | | +---------------+ | |--(C)--- Access Token Request --->| | | | + code_verifier | Authorization | | | | Server | | |<-(D)------ Access Token ---------| | +--------+ +---------------+ Figure 2: Abstract Protocol Flow This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form in Figure 1. A. The client creates and records a secret named the "code_verifier", and derives a transformed version "t(code_verifier)" (referred to as the "code_challenge") which is sent in the OAuth 2.0 Authorization Request, along with the transformation method "t". B. The resource owner responds as usual, but records "t(code_verifier)" and the transformation method. C. The client then sends the code to the Access Token Request as usual, but includes the "code_verifier" secret generated at (A). D. The authorization server transforms "code_verifier" and compares it to "t(code_verifier)" from (B). Access is denied if they are not equal. --001a113ee77eda68ff050dd1a48e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have= the authorization request going to the "Resource Owner" and goes= on to say that 'the resource owner responds as usual, but records &quo= t;t(code_verifier)" and the transformation method.' That's not= what the resource owner does.

I know the protocol flow in RFC 6749 = tries to have authorization grants be these abstract things that sorta come= from the resource owner but, in the context of the the authorization reque= st and authorization code grant type, it really doesn't work like that.= The content in =C2=A71.1 seems, at best, to be =C2=A0more abstract and com= plicated than it needs to be and is bordering on being just kinda wrong.
The RO and AS boxes should probably be consolidated into just the AS. = The RO could be omitted from the diagram, I think. Or stick it over with th= e client, if you really want it in there, and have it authenticating and ap= proving authorization though an interaction with the AS. Or something like = that...



[1] https://tools.ietf.org/html/draft-ietf-oauth-s= pop-06#section-1.1
<=
h3>1.1.  Protocol Flow

       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     |   Resource    |
       |        |                                  |     Owner     |
       |        |<-(B)--- Authorization Grant -----|               |
       |        |                                  +---------------+
       | Client |
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         | Authorization |
       |        |                                  |     Server    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier=
",
      and derives a transformed version "t(code_verifier)" (refer=
red to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t&q=
uot;.
   B. The resource owner responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code to the Access Token Request as
      usual, but includes the "code_verifier" secret generated at=
 (A).
   D. The authorization server transforms "code_verifier" and com=
pares
      it to "t(code_verifier)" from (B).  Access is denied if the=
y are
      not equal.

--001a113ee77eda68ff050dd1a48e-- From nobody Thu Jan 29 14:14:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDE71A8883 for ; Thu, 29 Jan 2015 14:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7up8HveIGeM6 for ; Thu, 29 Jan 2015 14:14:25 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C431A039C for ; Thu, 29 Jan 2015 14:14:25 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id z60so35149671qgd.6 for ; Thu, 29 Jan 2015 14:14:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=a3p/SG4Ds4V9z4lGA2vc43qKtIxuAeVrg0Qgb8+pUuk=; b=Ad6DvRhgnGBsEIn7c83wmMQrg7trETxMKnh0BUJ3a6dR1B7NFyS5xvN98XRuKU/224 vPjxi/8/rbNHotqk1Qr23EYgGFQLrlEcKuhC5IiTSg4bijloGs10h+p25OLsKDwThv2F M8anh3cYEgUSGNV5x3hONEWN5jLcEefqn9EFPNNBz52KTe5SfUsx1hxquo8TLLO975xH WQSF2qryMIEIGxktP/qtvBHeNguydcWtJUDINwR36BPoSRF4MarPpAaxLpXp+NaD0Drc GVIdSLLzA6GKnFceFEwz231uGpeVyt+3A948YmeaQtqEUeb/mzbcUupMSHqTYE1nj+1t 79+w== X-Gm-Message-State: ALoCoQkgGexPLgjjssSDJD2BBFlozhYbW5RwuKDQQZpUkDuHNBiU9U5erk5ayvD7sV6fq2HuP5Wa X-Received: by 10.224.72.8 with SMTP id k8mr6204807qaj.26.1422569664529; Thu, 29 Jan 2015 14:14:24 -0800 (PST) Received: from [192.168.8.101] ([181.202.1.158]) by mx.google.com with ESMTPSA id t12sm8223058qam.48.2015.01.29.14.14.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 14:14:23 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_29317EAB-6085-4816-AAA6-8F0D4495DFCF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Thu, 29 Jan 2015 19:14:19 -0300 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Misplaced Resource Owner in PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:14:29 -0000 --Apple-Mail=_29317EAB-6085-4816-AAA6-8F0D4495DFCF Content-Type: multipart/alternative; boundary="Apple-Mail=_4A0EC875-D718-4B19-9D29-FFF2178FE177" --Apple-Mail=_4A0EC875-D718-4B19-9D29-FFF2178FE177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 How about +--------+ +---------------+ | |--(A)-- Authorization Request --->| | | | + t(code_verifier), t | Authorization | | | | Endpoint | | |<-(B)- Authorization Code Grant --| | | | +---------------+ | Client | =20 | | +---------------+ | |--(C)--- Access Token Request --->| | | | + code_verifier | Token | | | | Endpoint | | |<-(D)------ Access Token ---------| | +--------+ +--------------- > On Jan 29, 2015, at 7:01 PM, Brian Campbell = wrote: >=20 > In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have the = authorization request going to the "Resource Owner" and goes on to say = that 'the resource owner responds as usual, but records = "t(code_verifier)" and the transformation method.' That's not what the = resource owner does. >=20 > I know the protocol flow in RFC 6749 tries to have authorization = grants be these abstract things that sorta come from the resource owner = but, in the context of the the authorization request and authorization = code grant type, it really doesn't work like that. The content in =C2=A71.= 1 seems, at best, to be more abstract and complicated than it needs to = be and is bordering on being just kinda wrong. >=20 > The RO and AS boxes should probably be consolidated into just the AS. = The RO could be omitted from the diagram, I think. Or stick it over with = the client, if you really want it in there, and have it authenticating = and approving authorization though an interaction with the AS. Or = something like that... >=20 >=20 >=20 > [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 = > 1.1 = . = Protocol Flow >=20 >=20 >=20 > +--------+ +---------------+ > | |--(A)-- Authorization Request --->| | > | | + t(code_verifier), t | Resource | > | | | Owner | > | |<-(B)--- Authorization Grant -----| | > | | +---------------+ > | Client | > | | +---------------+ > | |--(C)--- Access Token Request --->| | > | | + code_verifier | Authorization | > | | | Server | > | |<-(D)------ Access Token ---------| | > +--------+ +---------------+ >=20 > Figure 2: Abstract Protocol Flow >=20 >=20 > This specification adds additional parameters to the OAuth 2.0 > Authorization and Access Token Requests, shown in abstract form in > Figure 1. >=20 > A. The client creates and records a secret named the = "code_verifier", > and derives a transformed version "t(code_verifier)" (referred = to > as the "code_challenge") which is sent in the OAuth 2.0 > Authorization Request, along with the transformation method "t". > B. The resource owner responds as usual, but records > "t(code_verifier)" and the transformation method. > C. The client then sends the code to the Access Token Request as > usual, but includes the "code_verifier" secret generated at (A). > D. The authorization server transforms "code_verifier" and compares > it to "t(code_verifier)" from (B). Access is denied if they are > not equal. >=20 --Apple-Mail=_4A0EC875-D718-4B19-9D29-FFF2178FE177 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 How about

    +--------+           =                     =    +---------------+
    |   =      |--(A)-- Authorization Request --->|   =             |
  =   |        |        + = t(code_verifier), t     | Authorization |
  =   |        |           =                     =    |    Endpoint   |
  =   |        |<-(B)- Authorization Code Grant = --|               |
  =   |        |           =                     =    +---------------+
    | Client | =  
    |        |     =                     =          +---------------+
  =   |        |--(C)--- Access Token Request = --->|               = |
    |        |     =      + code_verifier         |   =  Token      |
    |   =      |               =                    | =   Endpoint    |
    |   =      |<-(D)------ Access Token ---------|   =             |
  =   +--------+               =                   =  +---------------



On = Jan 29, 2015, at 7:01 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have = the authorization request going to the "Resource Owner" and goes on to = say that 'the resource owner responds as usual, but records = "t(code_verifier)" and the transformation method.' That's not what the = resource owner does.

I know the protocol = flow in RFC 6749 tries to have authorization grants be these abstract = things that sorta come from the resource owner but, in the context of = the the authorization request and authorization code grant type, it = really doesn't work like that. The content in =C2=A71.1 seems, at best, = to be  more abstract and complicated than it needs to be and is = bordering on being just kinda wrong.

The RO = and AS boxes should probably be consolidated into just the AS. The RO = could be omitted from the diagram, I think. Or stick it over with the = client, if you really want it in there, and have it authenticating and = approving authorization though an interaction with the AS. Or something = like that...



[1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.= 1
1.1.  Protocol Flow


       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     |   Resource    |
       |        |                                  |     Owner     |
       |        |<-(B)--- Authorization Grant -----|               |
       |        |                                  +---------------+
       | Client |
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         | Authorization |
       |        |                                  |     Server    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier",
      and derives a transformed version "t(code_verifier)" (referred to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t".
   B. The resource owner responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code to the Access Token Request as
      usual, but includes the "code_verifier" secret generated at (A).
   D. The authorization server transforms "code_verifier" and compares
      it to "t(code_verifier)" from (B).  Access is denied if they are
      not equal.


= --Apple-Mail=_4A0EC875-D718-4B19-9D29-FFF2178FE177-- --Apple-Mail=_29317EAB-6085-4816-AAA6-8F0D4495DFCF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMjkyMjE0MTlaMCMGCSqGSIb3DQEJBDEWBBQb5I0OYNmrwV++xR+Zc8Tr MDfTyzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAZwAf2Orfwd35tJ1RRDwv2qrx75TsIhgrhlQNa1XEm4NhVRI/X2e5t 0tqtZKpPhAkz/VtzwtNoUh+3e56OxEuJEmcBWnPjF0anIVOvZ9aO4A/9btIgpL7TR8LUh1NWB9mQ KBNBCSLWDkFotAE+WUBA/gJ6z3wilg4wmXq2195dmIqp6o8DOEqCKJRoLECkYJiOh0Ok1sLTeEOc c5Bshx0GapiTFNrvtTDZTaf8ERY9HCRLmkAGtszpBCEuDSVhLmmODK8mCZWbpxJWB1kpog8SAZLh MuLnZv+kjjgLracvSJRtMI6sVtxHsUkoV1sOSCg8P2XJUOzDQtwKgrFfCKUkAAAAAAAA --Apple-Mail=_29317EAB-6085-4816-AAA6-8F0D4495DFCF-- From nobody Thu Jan 29 14:22:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFD41A8870 for ; Thu, 29 Jan 2015 14:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP4dr03zq-Lw for ; Thu, 29 Jan 2015 14:22:23 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA971A8884 for ; Thu, 29 Jan 2015 14:22:08 -0800 (PST) Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKVMqykC4wTDtWup1ei2GRDUP7Zpd0z6HW@postini.com; Thu, 29 Jan 2015 14:22:08 PST Received: by mail-ie0-f169.google.com with SMTP id rl12so617555iec.0 for ; Thu, 29 Jan 2015 14:22:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i9xo8d16M4qr0iU+1zqfsROHlBLD4PObiWkI+1xIAeo=; b=REJulqARSuCJOuAuSCAhJa53+dQp+Nr2zqRXzjqCZ1aAEKvCePlhLvmU5HqF+gwd3i Zgt8C0E0o3Y10Y/D3S2fN7lRn+J8wf7i8sRIMYa9YS+aojgaQxyunbYTIXzYn/5IDKI/ ESDTyChsIzDfnymMUghfsbDTSTPHB/g/AAI00U6/LT9hQxpiU95dJKX0bNAvE5Um8Lpg 05O4FAAxWRIKz1vqFy82zIbvCd7PKP1YXK+WPsH9lN0JU4TIE+DdSe8ZymfCkqJanFvd 5cFzuei8r+NvGtJmsGuCxuLTQnif40itj9033kNgikWXUx3Ek9SXkaI0OKUh5MlcdEyd cAiw== X-Received: by 10.107.5.79 with SMTP id 76mr3690867iof.15.1422569804353; Thu, 29 Jan 2015 14:16:44 -0800 (PST) X-Gm-Message-State: ALoCoQmWEY3TLsAszKi7T9KMGCmpQDynAufqLtske0YXOKp4FPKA9Sgl3xeZ/KE2jqX+hGYEwdgRP4qm0I/8CbOxLunCdtEVVD7iMqJB403IYzEqdkvO5Xp3ndH/HPlldILgLneMVezq X-Received: by 10.107.5.79 with SMTP id 76mr3690852iof.15.1422569804238; Thu, 29 Jan 2015 14:16:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 14:16:14 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Thu, 29 Jan 2015 15:16:14 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113ee646d9ad95050dd1d7fc Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Misplaced Resource Owner in PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:22:26 -0000 --001a113ee646d9ad95050dd1d7fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Works for me. The text below needs to be fixed up to match too. On Thu, Jan 29, 2015 at 3:14 PM, John Bradley wrote: > How about > > +--------+ +---------------+ > | |--(A)-- Authorization Request --->| | > | | + t(code_verifier), t | Authorization | > | | | Endpoint | > | |<-(B)- Authorization Code Grant --| | > | | +---------------+ > | Client | > | | +---------------+ > | |--(C)--- Access Token Request --->| | > | | + code_verifier | Token | > | | | Endpoint | > | |<-(D)------ Access Token ---------| | > +--------+ +--------------- > > > > On Jan 29, 2015, at 7:01 PM, Brian Campbell > wrote: > > In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have the authorizat= ion > request going to the "Resource Owner" and goes on to say that 'the resour= ce > owner responds as usual, but records "t(code_verifier)" and the > transformation method.' That's not what the resource owner does. > > I know the protocol flow in RFC 6749 tries to have authorization grants b= e > these abstract things that sorta come from the resource owner but, in the > context of the the authorization request and authorization code grant typ= e, > it really doesn't work like that. The content in =C2=A71.1 seems, at best= , to be > more abstract and complicated than it needs to be and is bordering on > being just kinda wrong. > > The RO and AS boxes should probably be consolidated into just the AS. The > RO could be omitted from the diagram, I think. Or stick it over with the > client, if you really want it in there, and have it authenticating and > approving authorization though an interaction with the AS. Or something > like that... > > > > [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 > > 1.1 . = Protocol Flow > > +--------+ +---------------+ > | |--(A)-- Authorization Request --->| | > | | + t(code_verifier), t | Resource | > | | | Owner | > | |<-(B)--- Authorization Grant -----| | > | | +---------------+ > | Client | > | | +---------------+ > | |--(C)--- Access Token Request --->| | > | | + code_verifier | Authorization | > | | | Server | > | |<-(D)------ Access Token ---------| | > +--------+ +---------------+ > > Figure 2: Abstract Protocol Flow > > > This specification adds additional parameters to the OAuth 2.0 > Authorization and Access Token Requests, shown in abstract form in > Figure 1. > > A. The client creates and records a secret named the "code_verifier", > and derives a transformed version "t(code_verifier)" (referred to > as the "code_challenge") which is sent in the OAuth 2.0 > Authorization Request, along with the transformation method "t". > B. The resource owner responds as usual, but records > "t(code_verifier)" and the transformation method. > C. The client then sends the code to the Access Token Request as > usual, but includes the "code_verifier" secret generated at (A). > D. The authorization server transforms "code_verifier" and compares > it to "t(code_verifier)" from (B). Access is denied if they are > not equal. > > > > --001a113ee646d9ad95050dd1d7fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Works for me. The text below needs to be fixed up to = match too.

On Thu, Jan 29, 2015 at 3:14 PM, John Bradley &l= t;ve7jtb@ve7jtb.com<= /a>> wrote:
How about

=C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|--(A)= -- Authorization Request --->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0+ t= (code_verifier), t =C2=A0 =C2=A0 | Authorization |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Endpoint =C2=A0= |
=C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(B)- Authorization Code Grant --| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+
=C2=A0 =C2=A0 | Clien= t | =C2=A0
=C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|--(C)--- Access Token = Request --->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<= /div>
=C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ code_verifier= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0Token =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = Endpoint =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(D)-= ----- Access Token ---------| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0= +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------

=
<= div class=3D"h5">


=
In SPOP/PKCE =C2=A71.1 [1] the figure and explanation= have the authorization request going to the "Resource Owner" and= goes on to say that 'the resource owner responds as usual, but records= "t(code_verifier)" and the transformation method.' That'= s not what the resource owner does.

I know the protocol flow in RFC = 6749 tries to have authorization grants be these abstract things that sorta= come from the resource owner but, in the context of the the authorization = request and authorization code grant type, it really doesn't work like = that. The content in =C2=A71.1 seems, at best, to be =C2=A0more abstract an= d complicated than it needs to be and is bordering on being just kinda wron= g.

The RO and AS boxes should probably be consolidated into just the= AS. The RO could be omitted from the diagram, I think. Or stick it over wi= th the client, if you really want it in there, and have it authenticating a= nd approving authorization though an interaction with the AS. Or something = like that...



[1] https://tools.ietf.org/= html/draft-ietf-oauth-spop-06#section-1.1
=

1.1.  Pro=
tocol Flow


       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     |   Resource    |
       |        |                                  |     Owner     |
       |        |<-(B)--- Authorization Grant -----|               |
       |        |                                  +---------------+
       | Client |
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         | Authorization |
       |        |                                  |     Server    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier=
",
      and derives a transformed version "t(code_verifier)" (refer=
red to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t&q=
uot;.
   B. The resource owner responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code to the Access Token Request as
      usual, but includes the "code_verifier" secret generated at=
 (A).
   D. The authorization server transforms "code_verifier" and com=
pares
      it to "t(code_verifier)" from (B).  Access is denied if the=
y are
      not equal.


--001a113ee646d9ad95050dd1d7fc-- From nobody Thu Jan 29 14:36:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5412B1A6FF6 for ; Thu, 29 Jan 2015 14:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Reu51ZY1mp0T for ; Thu, 29 Jan 2015 14:36:00 -0800 (PST) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8471A012D for ; Thu, 29 Jan 2015 14:36:00 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id a108so35345262qge.12 for ; Thu, 29 Jan 2015 14:35:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6c/XwMLebQsvAjrgY734+2YmcWSkHUyYoCGvFV/GHFY=; b=YO2ZS7OP6SF96cnD9U44boAXNXwG0xaQF7qap3aPrLPf7x//1EJwVKwr4jILrHa9zk 5PTChMyRkCcP/FFnf5ufpTUfnd+gt6/WxtUS1Q9Jj4zwF18iszQQM/0Mra+P6wl5jNG6 L5FTOWngcR1QWRhin8HhwZELgH90nFLEmKwAqeXoiGUzsdEGTAd2YTXaGkYBIESMAeoo SQoJilvr85I89naFKi4o0U51B8FB4/srmL4MQIeygfj5dEVoLTeW8DEGGyQ6FRziJvoy GN89TgRps/zw7qoQ1J/j07SdRIn8Ied2WIiNHyOAcR1ztm08fBvYMbDNw5ym5fUO5sa9 mFJA== X-Gm-Message-State: ALoCoQm/lYJSFZfKYQY5c+DVLnf/TT50ua22z9808Uvmc0jrSeAsCPnrqWGc1UKXJKAX/Pyc2ZJN X-Received: by 10.140.37.39 with SMTP id q36mr2512508qgq.89.1422570959421; Thu, 29 Jan 2015 14:35:59 -0800 (PST) Received: from [192.168.8.101] ([181.202.1.158]) by mx.google.com with ESMTPSA id q10sm7035581qaq.9.2015.01.29.14.35.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 14:35:58 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4DEB8145-5498-4A08-A493-DC82A9AEF63E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Thu, 29 Jan 2015 19:35:53 -0300 Message-Id: <3E4FF4CB-DEF4-4C3A-A09C-7B157DDEE2E2@ve7jtb.com> References: To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Misplaced Resource Owner in PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:36:03 -0000 --Apple-Mail=_4DEB8145-5498-4A08-A493-DC82A9AEF63E Content-Type: multipart/alternative; boundary="Apple-Mail=_4B31CE2E-020C-4B66-8D7D-D42C1737980F" --Apple-Mail=_4B31CE2E-020C-4B66-8D7D-D42C1737980F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +--------+ +---------------+ | |--(A)-- Authorization Request --->| | | | + t(code_verifier), t | Authorization | | | | Endpoint | | |<-(B)---- Authorization Code -----| | | | +---------------+ | Client | Authz Server | | +---------------+ | |--(C)--- Access Token Request --->| | | | + code_verifier | Token | | | | Endpoint | | |<-(D)------ Access Token ---------| | +--------+ +---------------+ Figure 2: Abstract Protocol Flow Sakimura, et al. Expires August 2, 2015 [Page 4] =0C Internet-Draft oauth_pkce January 2015 This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form in Figure 1. A. The client creates and records a secret named the "code_verifier", and derives a transformed version "t(code_verifier)" (referred to as the "code_challenge") which is sent in the OAuth 2.0 Authorization Request, along with the transformation method "t". B. The Authorization Endpoint responds as usual, but records "t(code_verifier)" and the transformation method. C. The client then sends the code in the Access Token Request as usual, but includes the "code_verifier" secret generated at (A). D. The authorization server transforms "code_verifier" and compares it to "t(code_verifier)" from (B). Access is denied if they are not equal. > On Jan 29, 2015, at 7:16 PM, Brian Campbell = wrote: >=20 > Works for me. The text below needs to be fixed up to match too. >=20 > On Thu, Jan 29, 2015 at 3:14 PM, John Bradley > wrote: > How about >=20 > +--------+ +---------------+ > | |--(A)-- Authorization Request --->| | > | | + t(code_verifier), t | Authorization | > | | | Endpoint | > | |<-(B)- Authorization Code Grant --| | > | | +---------------+ > | Client | =20 > | | +---------------+ > | |--(C)--- Access Token Request --->| | > | | + code_verifier | Token | > | | | Endpoint | > | |<-(D)------ Access Token ---------| | > +--------+ +--------------- >=20 >=20 >=20 >> On Jan 29, 2015, at 7:01 PM, Brian Campbell = > wrote: >>=20 >> In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have the = authorization request going to the "Resource Owner" and goes on to say = that 'the resource owner responds as usual, but records = "t(code_verifier)" and the transformation method.' That's not what the = resource owner does. >>=20 >> I know the protocol flow in RFC 6749 tries to have authorization = grants be these abstract things that sorta come from the resource owner = but, in the context of the the authorization request and authorization = code grant type, it really doesn't work like that. The content in =C2=A71.= 1 seems, at best, to be more abstract and complicated than it needs to = be and is bordering on being just kinda wrong. >>=20 >> The RO and AS boxes should probably be consolidated into just the AS. = The RO could be omitted from the diagram, I think. Or stick it over with = the client, if you really want it in there, and have it authenticating = and approving authorization though an interaction with the AS. Or = something like that... >>=20 >>=20 >>=20 >> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 = >> 1.1 = . = Protocol Flow >>=20 >>=20 >>=20 >> +--------+ +---------------+ >> | |--(A)-- Authorization Request --->| | >> | | + t(code_verifier), t | Resource | >> | | | Owner | >> | |<-(B)--- Authorization Grant -----| | >> | | +---------------+ >> | Client | >> | | +---------------+ >> | |--(C)--- Access Token Request --->| | >> | | + code_verifier | Authorization | >> | | | Server | >> | |<-(D)------ Access Token ---------| | >> +--------+ +---------------+ >>=20 >> Figure 2: Abstract Protocol Flow >>=20 >>=20 >> This specification adds additional parameters to the OAuth 2.0 >> Authorization and Access Token Requests, shown in abstract form in >> Figure 1. >>=20 >> A. The client creates and records a secret named the = "code_verifier", >> and derives a transformed version "t(code_verifier)" (referred = to >> as the "code_challenge") which is sent in the OAuth 2.0 >> Authorization Request, along with the transformation method = "t". >> B. The resource owner responds as usual, but records >> "t(code_verifier)" and the transformation method. >> C. The client then sends the code to the Access Token Request as >> usual, but includes the "code_verifier" secret generated at = (A). >> D. The authorization server transforms "code_verifier" and = compares >> it to "t(code_verifier)" from (B). Access is denied if they = are >> not equal. >>=20 >=20 >=20 --Apple-Mail=_4B31CE2E-020C-4B66-8D7D-D42C1737980F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 

       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     | Authorization |
       |        |                                  |    Endpoint   |
       |        |<-(B)---- Authorization Code -----|               |
       |        |                                  +---------------+
       | Client |                                     Authz Server
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         |    Token      |
       |        |                                  |   Endpoint    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow





Sakimura, et al.         Expires August 2, 2015                 [Page 4]
=0C
Internet-Draft                 oauth_pkce                   January 2015


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier",
      and derives a transformed version "t(code_verifier)" (referred to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t".
   B. The Authorization Endpoint responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code in the Access Token Request as
      usual, but includes the "code_verifier" secret generated at (A).
   D. The authorization server transforms "code_verifier" and compares
      it to "t(code_verifier)" from (B).  Access is denied if they are
      not equal.

On Jan 29, 2015, at 7:16 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Works for me. The text below needs to be = fixed up to match too.

On Thu, = Jan 29, 2015 at 3:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
How about

    +--------+ =                     =             =  +---------------+
    |       =  |--(A)-- Authorization Request --->|       =         |
    |   =      |        + t(code_verifier), t =     | Authorization |
    |   =      |               =                    | =    Endpoint   |
    |   =      |<-(B)- Authorization Code Grant --|   =             |
    |        |     =                     =          +---------------+
  =   | Client |  
    |       =  |                   =               =  +---------------+
    |       =  |--(C)--- Access Token Request --->|       =         |
    |   =      |          + code_verifier =         |    Token     =  |
    |        |     =                     =          |   Endpoint   =  |
    |       =  |<-(D)------ Access Token ---------|       =         |
    +--------+ =                     =             =  +---------------



On Jan 29, 2015, at 7:01 PM, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

In = SPOP/PKCE =C2=A71.1 [1] the figure and explanation have the = authorization request going to the "Resource Owner" and goes on to say = that 'the resource owner responds as usual, but records = "t(code_verifier)" and the transformation method.' That's not what the = resource owner does.

I know the protocol = flow in RFC 6749 tries to have authorization grants be these abstract = things that sorta come from the resource owner but, in the context of = the the authorization request and authorization code grant type, it = really doesn't work like that. The content in =C2=A71.1 seems, at best, = to be  more abstract and complicated than it needs to be and is = bordering on being just kinda wrong.

The RO = and AS boxes should probably be consolidated into just the AS. The RO = could be omitted from the diagram, I think. Or stick it over with the = client, if you really want it in there, and have it authenticating and = approving authorization though an interaction with the AS. Or something = like that...



[1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.= 1
1.1.  Protocol Flow


       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     |   Resource    |
       |        |                                  |     Owner     |
       |        |<-(B)--- Authorization Grant -----|               |
       |        |                                  +---------------+
       | Client |
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         | Authorization |
       |        |                                  |     Server    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier",
      and derives a transformed version "t(code_verifier)" (referred to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t".
   B. The resource owner responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code to the Access Token Request as
      usual, but includes the "code_verifier" secret generated at (A).
   D. The authorization server transforms "code_verifier" and compares
      it to "t(code_verifier)" from (B).  Access is denied if they are
      not equal.




= --Apple-Mail=_4B31CE2E-020C-4B66-8D7D-D42C1737980F-- --Apple-Mail=_4DEB8145-5498-4A08-A493-DC82A9AEF63E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMjkyMjM1NTRaMCMGCSqGSIb3DQEJBDEWBBS5oI25qvHkvnqQUt6IomUF l4qZXDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCt2mVSYP+szq/htMS4svMkVbAol99EMumd/aq6zyxnbYJqiytv9iVh xk0RTZSQ9KuO1zoxEXYDvj/1uL4/RAXcXsh+CiJryQEFAekEDnd3BYiIHYaj5eXwlpwWm/A8dqaJ VD5HsLLfXdWvcfyQNf9meLRpp37EjT0VZLdnym63dbYXdqt34hzfcLNg/m7NGUyoOq8UotDZLmfW EH8jtuFpTimgkNJVXYSVyrFxjK5lgEnB3fPBRVGT5guaF2EdIiFgsz/TKDyxWjFzBFWaQw/VXpHP 81SOAdUWFuPfHa5XHcoZxMCjE7rkZ7iZgP9varxinCAbkRclxln53kuVwI5lAAAAAAAA --Apple-Mail=_4DEB8145-5498-4A08-A493-DC82A9AEF63E-- From nobody Thu Jan 29 14:38:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E6E1A023E for ; Thu, 29 Jan 2015 14:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XdVLlScdTXP for ; Thu, 29 Jan 2015 14:38:26 -0800 (PST) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2666D1A000D for ; Thu, 29 Jan 2015 14:38:26 -0800 (PST) Received: from mail-ie0-f173.google.com ([209.85.223.173]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKVMq2YYHig9Z8Ac5Q1XZeHFQdsMSXbH6H@postini.com; Thu, 29 Jan 2015 14:38:26 PST Received: by mail-ie0-f173.google.com with SMTP id tr6so715112ieb.4 for ; Thu, 29 Jan 2015 14:38:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=/9zLYKBQrLNa/tyZR55orjtp0R/uMosMtXfznumS48E=; b=nANpBkBwrbUPTVrPcx2l6b9xb9VSEcMLmY5ON+eluTYqrN/rxLVqWjPdru3CGiTCNH 7SSgCBwHnuUhsnTOTcEf6pmJRpFcR1kYB0XPUFzyTnDMT4jpkWkltMj0P1p9a9aqmBBG pvaEEbiejl5XATHKvw9Zok7NEFR79ZIyCr15Ivz6sad2lgu1VRNqqV84vqhuQqQR4Mvb Knf2sPU3Oiz/dv9HzzHxGXTRBJWNI2uSm3xkx2q8kC1wxoom1F1oRVIXP6ous1NiNR3M F9EcT4tDplbHRQ3Vx1U+wMN/ou9cZCQYax4G0mp+2htMAlluSD1AK/h4wngW1ZtS5frT lHEg== X-Gm-Message-State: ALoCoQnB+7DdmRIXdsvTb/K+zfxUo0Js+lVuNyJybOMaTTQZneGnvPsHIiyXHawFfXHZjztk/seofP1gY/ZUwqWgeseIVOFh9orqK4JbhLF+WanzaLsvHeSjIM4M5aF+qfj4fs4aClUI X-Received: by 10.107.155.197 with SMTP id d188mr3727968ioe.29.1422571105424; Thu, 29 Jan 2015 14:38:25 -0800 (PST) X-Received: by 10.107.155.197 with SMTP id d188mr3727958ioe.29.1422571105304; Thu, 29 Jan 2015 14:38:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 14:37:55 -0800 (PST) From: Brian Campbell Date: Thu, 29 Jan 2015 15:37:55 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a1140c8fe665ee2050dd22545 Archived-At: Subject: [OAUTH-WG] unused || in PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:38:27 -0000 --001a1140c8fe665ee2050dd22545 Content-Type: text/plain; charset=UTF-8 "The concatenation of two values A and B is denoted as A || B" is in https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 but the "||" notation is never actually used anywhere else in the document. --001a1140c8fe665ee2050dd22545 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"The concatenation of two values A and B is denoted a= s A || B" is in https://tools.ietf.org/html/draft-ietf-oauth-spop-06#s= ection-2 but the "||" notation is never actually used anywher= e else in the document.
--001a1140c8fe665ee2050dd22545-- From nobody Thu Jan 29 14:40:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E36F1A012D for ; Thu, 29 Jan 2015 14:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebsJ-38TnEwm for ; Thu, 29 Jan 2015 14:40:18 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0291A000D for ; Thu, 29 Jan 2015 14:40:18 -0800 (PST) Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKVMq20l9A/1egllW8EXLWuLFCrvBQKXWy@postini.com; Thu, 29 Jan 2015 14:40:18 PST Received: by mail-ie0-f179.google.com with SMTP id x19so413673ier.10 for ; Thu, 29 Jan 2015 14:40:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MSgX2G70WrPKnMFfTld6lAo+A0EWntnYqM4ZfF+wr04=; b=AoU3yWj3fspYWXxruS4ymL2GkvWKtKRUzFEK461JcAdvRJSQpRuN2sZyneAmYYkAgt dCXYblID2C7c1jjomfSCG4lnejmRWsoT0rqfc7c4gnY+Iz3Ra2tHUA6UDrv0LXESQjlf lryntPT6GnFtGJvzVNe8Ra5sQqMtOMqo8ja528Wx96Arw8tUZ/aihhp+bTIiHSciEE0N HGnNkfsELy/87x1YHsUh3jysGjnCGjgxhLo3uxjvaoo665u3n4A5sN31E0lA1SaWguNy peb8mxZQ/el2qr2OSSZu8WTSQh+Su/Gf4Je51DaKJO9EcwrHN5xIWbzE8IZKy4m4F9dv tO3Q== X-Gm-Message-State: ALoCoQnC9/p7arJN3dh1yAudrBhxdklPuZO3cYCWlIBwoIkS1/CWV3+TAz9QPDygL983+B2qC3kevFVrrcPJbLur1rSxBR7XJTJ3oDFcWVkJFX7GzJYbZy7p3xi2yfF5JTfqpIa5depa X-Received: by 10.43.95.2 with SMTP id ca2mr3178362icc.89.1422571218033; Thu, 29 Jan 2015 14:40:18 -0800 (PST) X-Received: by 10.43.95.2 with SMTP id ca2mr3178349icc.89.1422571217904; Thu, 29 Jan 2015 14:40:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 14:39:47 -0800 (PST) In-Reply-To: <3E4FF4CB-DEF4-4C3A-A09C-7B157DDEE2E2@ve7jtb.com> References: <3E4FF4CB-DEF4-4C3A-A09C-7B157DDEE2E2@ve7jtb.com> From: Brian Campbell Date: Thu, 29 Jan 2015 15:39:47 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=bcaec51969551cbc28050dd22cf2 Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] Misplaced Resource Owner in PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 22:40:22 -0000 --bcaec51969551cbc28050dd22cf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good by me. On Thu, Jan 29, 2015 at 3:35 PM, John Bradley wrote: > > +--------+ +---------------+ > | |--(A)-- Authorization Request --->| | > | | + t(code_verifier), t | Authorization | > | | | Endpoint | > | |<-(B)---- Authorization Code -----| | > | | +---------------+ > | Client | Authz Server > | | +---------------+ > | |--(C)--- Access Token Request --->| | > | | + code_verifier | Token | > | | | Endpoint | > | |<-(D)------ Access Token ---------| | > +--------+ +---------------+ > > Figure 2: Abstract Protocol Flow > > > > > > Sakimura, et al. Expires August 2, 2015 [Page 4] > =0C > Internet-Draft oauth_pkce January 2015 > > > This specification adds additional parameters to the OAuth 2.0 > Authorization and Access Token Requests, shown in abstract form in > Figure 1. > > A. The client creates and records a secret named the "code_verifier", > and derives a transformed version "t(code_verifier)" (referred to > as the "code_challenge") which is sent in the OAuth 2.0 > Authorization Request, along with the transformation method "t". > B. The Authorization Endpoint responds as usual, but records > "t(code_verifier)" and the transformation method. > C. The client then sends the code in the Access Token Request as > usual, but includes the "code_verifier" secret generated at (A). > D. The authorization server transforms "code_verifier" and compares > it to "t(code_verifier)" from (B). Access is denied if they are > not equal. > > > On Jan 29, 2015, at 7:16 PM, Brian Campbell > wrote: > > Works for me. The text below needs to be fixed up to match too. > > On Thu, Jan 29, 2015 at 3:14 PM, John Bradley wrote: > >> How about >> >> +--------+ +---------------+ >> | |--(A)-- Authorization Request --->| | >> | | + t(code_verifier), t | Authorization | >> | | | Endpoint | >> | |<-(B)- Authorization Code Grant --| | >> | | +---------------+ >> | Client | >> | | +---------------+ >> | |--(C)--- Access Token Request --->| | >> | | + code_verifier | Token | >> | | | Endpoint | >> | |<-(D)------ Access Token ---------| | >> +--------+ +--------------- >> >> >> >> On Jan 29, 2015, at 7:01 PM, Brian Campbell >> wrote: >> >> In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have the authoriza= tion >> request going to the "Resource Owner" and goes on to say that 'the resou= rce >> owner responds as usual, but records "t(code_verifier)" and the >> transformation method.' That's not what the resource owner does. >> >> I know the protocol flow in RFC 6749 tries to have authorization grants >> be these abstract things that sorta come from the resource owner but, in >> the context of the the authorization request and authorization code gran= t >> type, it really doesn't work like that. The content in =C2=A71.1 seems, = at best, >> to be more abstract and complicated than it needs to be and is borderin= g >> on being just kinda wrong. >> >> The RO and AS boxes should probably be consolidated into just the AS. Th= e >> RO could be omitted from the diagram, I think. Or stick it over with the >> client, if you really want it in there, and have it authenticating and >> approving authorization though an interaction with the AS. Or something >> like that... >> >> >> >> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 >> >> 1.1 . = Protocol Flow >> >> +--------+ +---------------+ >> | |--(A)-- Authorization Request --->| | >> | | + t(code_verifier), t | Resource | >> | | | Owner | >> | |<-(B)--- Authorization Grant -----| | >> | | +---------------+ >> | Client | >> | | +---------------+ >> | |--(C)--- Access Token Request --->| | >> | | + code_verifier | Authorization | >> | | | Server | >> | |<-(D)------ Access Token ---------| | >> +--------+ +---------------+ >> >> Figure 2: Abstract Protocol Flow >> >> >> This specification adds additional parameters to the OAuth 2.0 >> Authorization and Access Token Requests, shown in abstract form in >> Figure 1. >> >> A. The client creates and records a secret named the "code_verifier", >> and derives a transformed version "t(code_verifier)" (referred to >> as the "code_challenge") which is sent in the OAuth 2.0 >> Authorization Request, along with the transformation method "t". >> B. The resource owner responds as usual, but records >> "t(code_verifier)" and the transformation method. >> C. The client then sends the code to the Access Token Request as >> usual, but includes the "code_verifier" secret generated at (A). >> D. The authorization server transforms "code_verifier" and compares >> it to "t(code_verifier)" from (B). Access is denied if they are >> not equal. >> >> >> >> > > --bcaec51969551cbc28050dd22cf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good by me.

On Thu, Jan 29, 2015 at 3:35 PM, John Bradley <ve7jtb= @ve7jtb.com> wrote:

       +--------+                                =
  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     | Authorization |
       |        |                                  |    Endpoint   |
       |        |<-(B)---- Authorization Code -----|               |
       |        |                                  +---------------+
       | Client |                                     Authz Server
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         |    Token      |
       |        |                                  |   Endpoint    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow





Sakimura, et al.         Expires August 2, 2015                 [Page 4]
=0C
Internet-Draft                 oauth_pkce                   January 2015


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier=
",
      and derives a transformed version "t(code_verifier)" (refer=
red to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t&q=
uot;.
   B. The Authorization Endpoint responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code in the Access Token Request as
      usual, but includes the "code_verifier" secret generated at=
 (A).
   D. The authorization server transforms "code_verifier" and com=
pares
      it to "t(code_verifier)" from (B).  Access is denied if the=
y are
      not equal.

=
On Jan 29, 2015, at 7:16 PM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:

Works for me. The text below n= eeds to be fixed up to match too.

On Thu, Jan 29, 2015 at 3:14 PM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
How about

=
=C2=A0 =C2=A0 +--------+ =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0|--(A)-- Authorization Request --->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0+ t(code_verifier), t =C2=A0 =C2=A0 | Authorization |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0E= ndpoint =C2=A0 |
= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(B)- Authorization Code Gr= ant --| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------= +
=C2=A0 =C2=A0 | C= lient | =C2=A0
=C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+---------------+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|--(C)--- Access To= ken Request --->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ code_veri= fier =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0Token =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 Endpoint =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(D)-----= - Access Token ---------| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0 =C2=A0 +--= ------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------=



On Jan 29, 2015, at 7:01 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

In SPOP/PKCE =C2=A71.1 [1] the figure and explanation have the author= ization request going to the "Resource Owner" and goes on to say = that 'the resource owner responds as usual, but records "t(code_ve= rifier)" and the transformation method.' That's not what the r= esource owner does.

I know the protocol flow in RFC 6749 tries to ha= ve authorization grants be these abstract things that sorta come from the r= esource owner but, in the context of the the authorization request and auth= orization code grant type, it really doesn't work like that. The conten= t in =C2=A71.1 seems, at best, to be =C2=A0more abstract and complicated th= an it needs to be and is bordering on being just kinda wrong.

The RO= and AS boxes should probably be consolidated into just the AS. The RO coul= d be omitted from the diagram, I think. Or stick it over with the client, i= f you really want it in there, and have it authenticating and approving aut= horization though an interaction with the AS. Or something like that...
=


[1] https://tools.ietf.org/html/draft-ietf-= oauth-spop-06#section-1.1
1.1.  Pr=
otocol Flow


       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     |   Resource    |
       |        |                                  |     Owner     |
       |        |<-(B)--- Authorization Grant -----|               |
       |        |                                  +---------------+
       | Client |
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         | Authorization |
       |        |                                  |     Server    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier=
",
      and derives a transformed version "t(code_verifier)" (refer=
red to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t&q=
uot;.
   B. The resource owner responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code to the Access Token Request as
      usual, but includes the "code_verifier" secret generated at=
 (A).
   D. The authorization server transforms "code_verifier" and com=
pares
      it to "t(code_verifier)" from (B).  Access is denied if the=
y are
      not equal.




--bcaec51969551cbc28050dd22cf2-- From nobody Thu Jan 29 15:16:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9306F1A802F for ; Thu, 29 Jan 2015 15:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SduOQAe1VAku for ; Thu, 29 Jan 2015 15:16:33 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FB41A1E0B for ; Thu, 29 Jan 2015 15:16:33 -0800 (PST) Received: from mail-ie0-f176.google.com ([209.85.223.176]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKVMq/SzRoatTbKkKfQdEJAp7sqH7rqbnm@postini.com; Thu, 29 Jan 2015 15:16:33 PST Received: by mail-ie0-f176.google.com with SMTP id at20so1078559iec.7 for ; Thu, 29 Jan 2015 15:16:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=urcUkMUM59Ccw84ioBgv2sEKO9yJAA3x+JMMRT9rpU4=; b=RRO8PTz5nNf6F0PzMv5ia2e4U6E/mAXm/I7pNwfqwLabPjAOInBD9KhWSzeejzGlNV x/z7iMOr4GX11R6lDO8XGfTv2grBDQKQq+QLncyJHtKZOzqO3hbE8VakDBUrKcIhgpLB WmVX4Bf1s+9iCV33d9Ls+8aTY/ZUP5KBcILunesyrU088Uqf9s1A9h+BwaLOPpc+aUVG jPRlbgK21vUUGNGZyGkzvHmnPgrbAFlLu2M8Ms8NxNMkCJWjcqS40O65H1n+bM3kT0AH sPU1A76xePTbGSz6C/63fJPnPFLeI5lzIa/HGl0yIxWNy4zBGhtY7G+zaBUfc9Z8dsKV 8YkA== X-Gm-Message-State: ALoCoQlsXtGJaEH2D58604zf+LLFMV4awxAVAUJb/CB5x9aZYDmm1eKILMx8nNO6t/7hNzVAV0q4v0d7PsvGXVBiPleNVhRfKai2QPwkhGgDmJZZWcIhytla5TXDmdAc5dpMZYYSNeCz X-Received: by 10.50.108.108 with SMTP id hj12mr3950033igb.47.1422573387186; Thu, 29 Jan 2015 15:16:27 -0800 (PST) X-Received: by 10.50.108.108 with SMTP id hj12mr3950025igb.47.1422573387102; Thu, 29 Jan 2015 15:16:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 15:15:56 -0800 (PST) From: Brian Campbell Date: Thu, 29 Jan 2015 16:15:56 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=089e0149392a67cff8050dd2adea Archived-At: Cc: Nat Sakimura , Naveen Agarwal Subject: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 23:16:35 -0000 --089e0149392a67cff8050dd2adea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC623= 4] of STRING." But, in the little cow town where I come from anyway, you hash bits/octets not character strings (BTW, "STRING" isn't defined anywhere but it's kind of implied that it's a string of characters). Should it say something more like "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING."? I know it's kind of pedantic but I find it kind of confusing because the code_verifier uses the url and filename safe alphabet, which has me second guessing if SHA256(STRING) actually means a hash of the octet produced by base64url decoding the string. Maybe it's just me but, when reading the text, I find the transform process to be much more confusing than I think it needs to be. Removing and clarifying some things will help. I hate to suggest this but maybe an example showing the computation steps on both ends would be helpful? Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72 bu= t not used anywhere. And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url deco= ding of STRING, per Section 3, producing a UTF-8 sequence of octets." But what is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC3629] reference, I think, could be removed. [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 --089e0149392a67cff8050dd2adea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In =C2=A72 [1] we've got "SHA= 256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING."

<= /div>But, in the little cow town where I come from anyway, you hash bits/oc= tets not character strings (BTW, "STRING" isn't defined anywh= ere but it's kind of implied that it's a string of characters).=C2= =A0

Should it say something more like "SHA256(STRING) de= notes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] rep= resentation of STRING."?

I know it's kind of pedanti= c but I find it kind of confusing because the code_verifier uses the url an= d filename safe alphabet, which has me second guessing if SHA256(STRING) ac= tually means a hash of the octet produced by base64url decoding the string.=

Maybe it's just me but, when reading the text, I fi= nd the transform process to be much more confusing than I think it needs to= be. Removing and clarifying some things will help. I hate to suggest this = but maybe an example showing the computation steps on both ends would be he= lpful?

Also "UTF8(STRING)" and "ASCI= I(STRING)" notations are defined in =C2=A72 but not used anywhere.
=
And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base6= 4url decoding of STRING, per Section 3, producing a UTF-8 sequence of octet= s." But what is a UTF-8 sequence of octets? Isn't it just a sequen= ce octets? The [RFC3629] reference, I think, could be removed.
--089e0149392a67cff8050dd2adea-- From nobody Thu Jan 29 20:43:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF3C1A6FFB for ; Thu, 29 Jan 2015 20:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 AhOHGcH5q0Ah for ; Thu, 29 Jan 2015 20:43:24 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0672A1A8850 for ; Thu, 29 Jan 2015 20:43:23 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id i138so33077626oig.12 for ; Thu, 29 Jan 2015 20:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sxvhOE7ab8aygq3He5VCkoXMk6phM+h/Ns2vH6YDLPI=; b=MZKZkOhGvSXvfm8KqxE5GNRwnmUa/c6YXRgJrzVHBxe1FVVW2jY9eESnvih+CduZVv 7qzEXrI/wm6aFkepp1Yavn3RifkaXAigMrXb5wgH+XsZTk3w6VJQyUxMs37EQU2L/FC0 ALWK2X04EIr4+uRQTRpJsnfUnKYNCb+kFaV+zu5x8vpY4qsIudvmTA3uWI+4SeTZ75k/ g/BezY+R3koKEl3G3xIOHDCeu7oWLMLVgvHVin3w7MnFoZMng877QsuLzqeP2VoIlJ70 7IN/glN2zbXof5H5LJD0pgvUbP4YRthzMZHW3O6tWrqrpj4YxkRSCk2GQwlm3QJ+QhHu 9AGA== MIME-Version: 1.0 X-Received: by 10.202.87.74 with SMTP id l71mr2540253oib.84.1422593003016; Thu, 29 Jan 2015 20:43:23 -0800 (PST) Sender: sakimura@gmail.com Received: by 10.60.171.196 with HTTP; Thu, 29 Jan 2015 20:43:22 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Jan 2015 13:43:22 +0900 X-Google-Sender-Auth: oXMM9ZB2M0-FzZoD6RIyB6lBI3E Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113b07449ada0b050dd73e1e Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 04:43:25 -0000 --001a113b07449ada0b050dd73e1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, we are now tracking this issue at: https://bitbucket.org/Nat/oauth-spop/issue/32/clean-up-definitions 2015-01-30 8:15 GMT+09:00 Brian Campbell : > In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6= 234] > of STRING." > > But, in the little cow town where I come from anyway, you hash bits/octet= s > not character strings (BTW, "STRING" isn't defined anywhere but it's kind > of implied that it's a string of characters). > > Should it say something more like "SHA256(STRING) denotes a SHA2 256bit > hash [RFC6234] of the octets of the ASCII [RFC0020] representation of > STRING."? > > I know it's kind of pedantic but I find it kind of confusing because the > code_verifier uses the url and filename safe alphabet, which has me secon= d > guessing if SHA256(STRING) actually means a hash of the octet produced by > base64url decoding the string. > > Maybe it's just me but, when reading the text, I find the transform > process to be much more confusing than I think it needs to be. Removing a= nd > clarifying some things will help. I hate to suggest this but maybe an > example showing the computation steps on both ends would be helpful? > > Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72 = but > not used anywhere. > > And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url de= coding > of STRING, per Section 3, producing a UTF-8 sequence of octets." But what > is a UTF-8 sequence of octets? Isn't it just a sequence octets? The > [RFC3629] reference, I think, could be removed. > > [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113b07449ada0b050dd73e1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI, we are now tracking this issue at:=C2=A0

2015-01-30 8:15 GMT+09:00 Brian Campbell <bcampbell@pingiden= tity.com>:
In =C2=A72 [1] we've got "SHA256(STRING) deno= tes a SHA2 256bit hash [RFC6234] of STRING."

But, in the= little cow town where I come from anyway, you hash bits/octets not charact= er strings (BTW, "STRING" isn't defined anywhere but it's= kind of implied that it's a string of characters).=C2=A0

Should it say something more like "SHA256(STRING) denotes a SHA2 256b= it hash [RFC6234] of the octets of the ASCII [RFC0020] representation of ST= RING."?

I know it's kind of pedantic but I find it k= ind of confusing because the code_verifier uses the url and filename safe a= lphabet, which has me second guessing if SHA256(STRING) actually means a ha= sh of the octet produced by base64url decoding the string.

Maybe it's just me but, when reading the text, I find the transform = process to be much more confusing than I think it needs to be. Removing and= clarifying some things will help. I hate to suggest this but maybe an exam= ple showing the computation steps on both ends would be helpful?
<= div>
Also "UTF8(STRING)" and "ASCII(STRING)" n= otations are defined in =C2=A72 but not used anywhere.

And =C2=A72 a= lso says, "BASE64URL-DECODE(STRING) denotes the base64url decoding of = STRING, per Section 3, producing a UTF-8 sequence of octets." But what= is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [R= FC3629] reference, I think, could be removed.

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


--001a113b07449ada0b050dd73e1e-- From nobody Fri Jan 30 05:52:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE95C1A0373 for ; Fri, 30 Jan 2015 05:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA0xJcUn2VfN for ; Fri, 30 Jan 2015 05:52:13 -0800 (PST) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193A21A01F2 for ; Fri, 30 Jan 2015 05:52:12 -0800 (PST) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKVMuMjHlYN8sdiumNN4PGMxgnW5z0Epe1@postini.com; Fri, 30 Jan 2015 05:52:13 PST Received: by mail-ie0-f174.google.com with SMTP id vy18so3439068iec.5 for ; Fri, 30 Jan 2015 05:52:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JOySFO0xRe3U63hYm4udsUTtUPVpzX71CGd/QMcB5CM=; b=i12+NZYNsn8szLB686W0Kg/scIZ1lZIEspWDkkumHz4Ve5YjF9oQhwCYUkvwt10xeU wSbXTxXR0517eQGC6nky240G9eTBjjCInEOvmZLVDHjia/qiSSkJ3SxRKyhKbjDRNeAC ASKScKi9VyMZbK33rojYRwfeiSM/20gB0XCtRamCrYWh/ixzZeMuR5llqZyBLYKYlUtf YJ/otXI+f7dO5PX+BpyWiJXcpDu6Z8VwQAUOkVw7VJir6BVG2ttiVS5apOKnb4qe9K22 fxc+i2rLdCZfaHdXMTRKkYb01bw9TCn1O2rIS2PKym91EkfkpV3GMw7SWQkbM/rFa3wY SW9g== X-Gm-Message-State: ALoCoQm/MqLHugamaT2pmLR3E9/Mfj/3jbnvzIDIKsC5ctsZE+NHRiBFtjUtyBf5QnaFlfPSkrFgh4+uk4HCWbvzDSjlajKsAeFVcjjkt1ZcTIV9xsdlG4oPRKbf0oBAatS8nkKKjf1O X-Received: by 10.107.149.203 with SMTP id x194mr7511361iod.12.1422625932204; Fri, 30 Jan 2015 05:52:12 -0800 (PST) X-Received: by 10.107.149.203 with SMTP id x194mr7511349iod.12.1422625932088; Fri, 30 Jan 2015 05:52:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Fri, 30 Jan 2015 05:51:41 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Fri, 30 Jan 2015 06:51:41 -0700 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a1140eed654db51050ddee979 Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 13:52:16 -0000 --001a1140eed654db51050ddee979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's definitely an improvement (to me anyway). Checking that the rest of the document uses those notations appropriately, I think, yields a few other changes. And probably begs for the "ASCII(STRING) denotes the octets of the ASCII representation of STRING" notation/function, or something like it, to be put back in. Those changes might look like the following: In 4.1.: OLD: code_verifier =3D high entropy cryptographic random ASCII [RFC0020] octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. NEW (maybe): code_verifier =3D high entropy cryptographically strong random STRING using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. In 4.2.: OLD: S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) NEW (maybe): S256 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier"))) In 4.6.: OLD: SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). NEW (maybe): SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challenge")= . On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) wrote: > I take your point, Brian. > > In our most recent manuscript, STRING is defined inside ASCII(STRING) as > > STRING is a sequence of zero or more ASCII characters > > but it is kind of circular, and we do not seem to use ASCII(). > > What about re-writing the section like below? > > STRING denotes a sequence of zero or more ASCII [RFC0020] > characters. > > OCTETS denotes a sequence of zero or more octets. > > BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 3 > producing a > ASCII[RFC0020] > STRING. > > BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Se= ction > 3 , producing a > sequence of octets. > > SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] > of OCTETS. > > > > > > > On Jan 30, 2015, at 08:15, Brian Campbell > wrote: > > In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6= 234] > of STRING." > > But, in the little cow town where I come from anyway, you hash bits/octet= s > not character strings (BTW, "STRING" isn't defined anywhere but it's kind > of implied that it's a string of characters). > > Should it say something more like "SHA256(STRING) denotes a SHA2 256bit > hash [RFC6234] of the octets of the ASCII [RFC0020] representation of > STRING."? > > I know it's kind of pedantic but I find it kind of confusing because the > code_verifier uses the url and filename safe alphabet, which has me secon= d > guessing if SHA256(STRING) actually means a hash of the octet produced by > base64url decoding the string. > > Maybe it's just me but, when reading the text, I find the transform > process to be much more confusing than I think it needs to be. Removing a= nd > clarifying some things will help. I hate to suggest this but maybe an > example showing the computation steps on both ends would be helpful? > > Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72 = but > not used anywhere. > > And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url de= coding > of STRING, per Section 3, producing a UTF-8 sequence of octets." But what > is a UTF-8 sequence of octets? Isn't it just a sequence octets? The > [RFC3629] reference, I think, could be removed. > > [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 > > > Nat Sakimura > nat@sakimura.org > > > > > > --001a1140eed654db51050ddee979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's definitely an improvement (to me anyway). =

Checking that the rest of the document uses those notati= ons appropriately, I think, yields a few other changes. And probably begs f= or the "ASCII(STRING) denotes the octets of the ASCII representation o= f STRING" notation/function, or something like it, to be put back in. = Those changes might look like the following:


In 4.1.:=

OLD:
=C2=A0=C2=A0 code_verifier =3D high entropy cryptographic = random ASCII [RFC0020]
=C2=A0=C2=A0 octet sequence using the url and fil= ename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" /= "_" from Sec 5 of RFC 4648 [RFC4648], with length
=C2=A0=C2= =A0 less than 128 characters.

NEW (maybe):
=C2=A0 code_verifier = =3D high entropy cryptographically strong random STRING
=C2=A0 using the= url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / &qu= ot;-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length=C2=A0=C2=A0 less than 128 characters.


In 4.2.:
=
OLD:
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64UR= L(SHA256("code_verifier"))

NEW (maybe):
=C2=A0=C2=A0 S2= 56=C2=A0 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_v= erifier")))


In 4.6.:

OLD:
=C2=A0=C2= =A0 SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_c= hallenge").

NEW (maybe):
=C2=A0=C2=A0 SHA256(ASCII("cod= e_verifier")) =3D=3D BASE64URL-DECODE("code_challenge").
=



On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) &= lt;nat@sakimura.org> wrote:
I take your point, Brian.=C2=A0
<= span style=3D"font-family:verdana,helvetica,arial,sans-serif;font-size:smal= l">
In our most recent manuscript, STRING is defined i= nside ASCII(STRING) as=C2=A0

STRI= NG is a sequence of zero or more ASCII characters

but it is kind of circular, and we do not seem to use ASCII().=C2= =A0
<= br>
W= hat about re-writing the section like below?=C2=A0

STRING denotes a sequence of zero o= r more ASCII =C2=A0[RFC0020]=C2= =A0characters.=C2=A0

OCTETS denotes a sequence of zero or more octets.=C2=A0

BASE64URL(OCTETS) d= enotes the base64url encoding of OCTETS, per=C2=A0Section 3=C2=A0producing a ASCII[RFC0020]=C2=A0STRING.

BASE64URL-DECODE(STRING) denotes the base64url decoding o= f STRING, per=C2=A0Section 3,= producing a sequence of octets.

SHA256(OCTETS) denotes a SHA2 256bit hash=C2=A0[RFC6234]=C2=A0of OCTETS.





=
On Jan 30, 2015, at 08:15, Brian Ca= mpbell <= bcampbell@pingidentity.com> wrote:

In =C2=A72 [1] we've got "SHA256(STRING) denotes= a SHA2 256bit hash [RFC6234] of STRING."

But, in the li= ttle cow town where I come from anyway, you hash bits/octets not character = strings (BTW, "STRING" isn't defined anywhere but it's ki= nd of implied that it's a string of characters).=C2=A0

Sh= ould it say something more like "SHA256(STRING) denotes a SHA2 256bit = hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRIN= G."?

I know it's kind of pedantic but I find it kind= of confusing because the code_verifier uses the url and filename safe alph= abet, which has me second guessing if SHA256(STRING) actually means a hash = of the octet produced by base64url decoding the string.

= Maybe it's just me but, when reading the text, I find the transform pro= cess to be much more confusing than I think it needs to be. Removing and cl= arifying some things will help. I hate to suggest this but maybe an example= showing the computation steps on both ends would be helpful?

Also "UTF8(STRING)" and "ASCII(STRING)" nota= tions are defined in =C2=A72 but not used anywhere.

And =C2=A72 also= says, "BASE64URL-DECODE(STRING) denotes the base64url decoding of STR= ING, per Section 3, producing a UTF-8 sequence of octets." But what is= a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC3= 629] reference, I think, could be removed.



--001a1140eed654db51050ddee979-- From nobody Fri Jan 30 06:15:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D8F1A037F for ; Fri, 30 Jan 2015 06:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI3yr_Hn-BGa for ; Fri, 30 Jan 2015 06:15:12 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FA71A0252 for ; Fri, 30 Jan 2015 06:15:11 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id i138so34718086oig.1 for ; Fri, 30 Jan 2015 06:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W0zYRNMIhtyWwRtgQhkSRDBhgP1/QvUaTWGPAXie9Lc=; b=lTd8n3SljSGYv8fDEIU0FYeYjNjYNO2fjgZ2LtOP69qZw+uz30bo9raeduiBiFva34 MU7Htycc3pTGcqW4aOxlHkXx8dceIr63LGAXZdh4weHfp/bNK/W7Hq0WZcNT3CKNpQGR vIeQny/u/eGabQDLg6V0BxaBj9nNRn+mIuQgwLxHwtogffgH5yC7XaDUV8fRsDFFcEud zICDTdChHSo4dyuP4/Y7S/lBkUrS88+boKdp7PqhMmmfA4ruUxisb8abCpklfbT/N95h mw8XO6L3n/W7TinJdyEmP9+1MKZjtrIaRO9G7mju+hJRJZmTw4qA6m/nJiD9WYFDtSNJ 2jEw== MIME-Version: 1.0 X-Received: by 10.60.44.70 with SMTP id c6mr3882462oem.36.1422627311039; Fri, 30 Jan 2015 06:15:11 -0800 (PST) Received: by 10.60.171.196 with HTTP; Fri, 30 Jan 2015 06:15:10 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Jan 2015 23:15:10 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c21c7085bb6c050ddf3bba Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 14:15:25 -0000 --001a11c21c7085bb6c050ddf3bba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do not think we need ASCII(). It is quite clear without it, I suppose. In 4.1, I would rather do like: code_verifier =3D high entropy cryptographic random octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length less than 128 characters. Nat 2015-01-30 22:51 GMT+09:00 Brian Campbell : > That's definitely an improvement (to me anyway). > > Checking that the rest of the document uses those notations appropriately= , > I think, yields a few other changes. And probably begs for the > "ASCII(STRING) denotes the octets of the ASCII representation of STRING" > notation/function, or something like it, to be put back in. Those changes > might look like the following: > > > In 4.1.: > > OLD: > code_verifier =3D high entropy cryptographic random ASCII [RFC0020] > octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > NEW (maybe): > code_verifier =3D high entropy cryptographically strong random STRING > using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > > In 4.2.: > > OLD: > S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) > > NEW (maybe): > S256 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier"))) > > > In 4.6.: > > OLD: > SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). > > NEW (maybe): > SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challenge= "). > > > > > On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) > wrote: > >> I take your point, Brian. >> >> In our most recent manuscript, STRING is defined inside ASCII(STRING) as >> >> STRING is a sequence of zero or more ASCII characters >> >> but it is kind of circular, and we do not seem to use ASCII(). >> >> What about re-writing the section like below? >> >> STRING denotes a sequence of zero or more ASCII [RFC0020] >> characters. >> >> OCTETS denotes a sequence of zero or more octets. >> >> BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section = 3 >> producing a >> ASCII[RFC0020] >> STRING. >> >> BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per S= ection >> 3 , producing a >> sequence of octets. >> >> SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] >> of OCTETS. >> >> >> >> >> >> >> On Jan 30, 2015, at 08:15, Brian Campbell >> wrote: >> >> In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC= 6234] >> of STRING." >> >> But, in the little cow town where I come from anyway, you hash >> bits/octets not character strings (BTW, "STRING" isn't defined anywhere = but >> it's kind of implied that it's a string of characters). >> >> Should it say something more like "SHA256(STRING) denotes a SHA2 256bit >> hash [RFC6234] of the octets of the ASCII [RFC0020] representation of >> STRING."? >> >> I know it's kind of pedantic but I find it kind of confusing because the >> code_verifier uses the url and filename safe alphabet, which has me seco= nd >> guessing if SHA256(STRING) actually means a hash of the octet produced b= y >> base64url decoding the string. >> >> Maybe it's just me but, when reading the text, I find the transform >> process to be much more confusing than I think it needs to be. Removing = and >> clarifying some things will help. I hate to suggest this but maybe an >> example showing the computation steps on both ends would be helpful? >> >> Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72= but >> not used anywhere. >> >> And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url >> decoding of STRING, per Section 3, producing a UTF-8 sequence of octets.= " >> But what is a UTF-8 sequence of octets? Isn't it just a sequence octets? >> The [RFC3629] reference, I think, could be removed. >> >> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 >> >> >> Nat Sakimura >> nat@sakimura.org >> >> >> >> >> >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c21c7085bb6c050ddf3bba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do not think we need ASCII(). It is quite clear without = it, I suppose.=C2=A0

In 4.1, I would rather do like:=C2= =A0

=C2=A0code_v= erifier =3D high entropy cryptographic random=C2=A0
=C2=A0=C2=A0 octet sequenc= e using the url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] = / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with leng= th
= =C2=A0=C2=A0 less than 128 characters.

Nat

2015-01-30 22:51 GMT+09:00 Brian Campbell = <bcampbell@pingidentity.com>:
That's definitely an improvement (t= o me anyway).

Checking that the rest of the document use= s those notations appropriately, I think, yields a few other changes. And p= robably begs for the "ASCII(STRING) denotes the octets of the ASCII re= presentation of STRING" notation/function, or something like it, to be= put back in. Those changes might look like the following:


In 4.1.:

OLD:
=C2=A0=C2=A0 code_verifier =3D high entropy = cryptographic random ASCII [RFC0020]
=C2=A0=C2=A0 octet sequence using t= he url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / &= quot;-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length<= br>=C2=A0=C2=A0 less than 128 characters.

NEW (maybe):
=C2=A0 cod= e_verifier =3D high entropy cryptographically strong random STRING
=C2= =A0 using the url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 = / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], w= ith length
=C2=A0=C2=A0 less than 128 characters.


= In 4.2.:

OLD:
=C2=A0=C2=A0 S256=C2=A0 "code_challenge"= =3D BASE64URL(SHA256("code_verifier"))

NEW (maybe):
= =C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(ASC= II("code_verifier")))


In 4.6.:

OLD:=
=C2=A0=C2=A0 SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE= ("code_challenge").

NEW (maybe):
=C2=A0=C2=A0 SHA256(AS= CII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challeng= e").




On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) <nat@s= akimura.org> wrote:
I take your point, Brian.=C2=A0

In our most recent manuscript, STRING= is defined inside ASCII(STRING) as=C2=A0

STRING is a sequence of zero or more ASCII characters
=

but it is kind of circular, and we do not seem to use= ASCII().=C2=A0

What about re-writing the section like below?=C2=A0
=

=

STRING denotes a sequen= ce of zero or more ASCII =C2=A0[RFC00= 20]=C2=A0characters.=C2=A0=

OCTETS denotes a sequence of zero or more octet= s.=C2=A0

BASE64URL= (OCTETS) denotes the base64url encoding of OCTETS, per=C2=A0Section 3=C2=A0producing a ASCII[RFC0020]=C2=A0STRING.

BASE64URL-DECODE(STRING) denotes the base64url = decoding of STRING, per=C2=A0Sect= ion 3, producing a sequence of octets.

SHA256(OCTETS) denotes a SHA2 256bit hash=C2=A0[RFC6234]=C2=A0of OCTETS.


=

<= /div>

<= /div>


On Jan 30, 2015= , at 08:15, Brian Campbell <bcampbell@pingidentity.com> wrote:

In =C2=A72 [1] we've got "SH= A256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING."

=
But, in the little cow town where I come from anyway, you hash bits/o= ctets not character strings (BTW, "STRING" isn't defined anyw= here but it's kind of implied that it's a string of characters).=C2= =A0

Should it say something more like "SHA256(STRING) de= notes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] rep= resentation of STRING."?

I know it's kind of pedanti= c but I find it kind of confusing because the code_verifier uses the url an= d filename safe alphabet, which has me second guessing if SHA256(STRING) ac= tually means a hash of the octet produced by base64url decoding the string.=

Maybe it's just me but, when reading the text, I fi= nd the transform process to be much more confusing than I think it needs to= be. Removing and clarifying some things will help. I hate to suggest this = but maybe an example showing the computation steps on both ends would be he= lpful?

Also "UTF8(STRING)" and "ASCI= I(STRING)" notations are defined in =C2=A72 but not used anywhere.
=
And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base6= 4url decoding of STRING, per Section 3, producing a UTF-8 sequence of octet= s." But what is a UTF-8 sequence of octets? Isn't it just a sequen= ce octets? The [RFC3629] reference, I think, could be removed.

Nat Sakimura

<= br>







--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--001a11c21c7085bb6c050ddf3bba-- From nobody Fri Jan 30 08:57:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BFD1A3BA4 for ; Fri, 30 Jan 2015 08:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0eOWS_-ljN6 for ; Fri, 30 Jan 2015 08:57:31 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8781A1AAC for ; Fri, 30 Jan 2015 08:57:30 -0800 (PST) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKVMu3+h4mJu/6BFsAppnY0CHnc65EVxLA@postini.com; Fri, 30 Jan 2015 08:57:30 PST Received: by mail-ie0-f170.google.com with SMTP id y20so4739067ier.1 for ; Fri, 30 Jan 2015 08:57:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Bn3x4wbOUz0QsKIIfAk+zJFmfmliIROTvinSrYtHLvM=; b=DE4ozwj8FelJnDFGFYcGrQjg6Cd8UlJDlI3YEaWxSiOsFNm3/7TKJt64TDKtFpC/7b RGleu3fsNGo/Rq5FG6g+ZbH6Cuuy4P5TmK+ZhUYbkJx5UeiBrukdIviTr+YxxYTIATiQ HzvHb3Qmj6y4t2z2JvocTnMfQpTHbTorbiHm4yD1aMmeqvr1nmZtHMkOhqmIgqAsnn1B aAfRgfvne1OMM/BCed20QY0afIBLo2HS4zfpqGFw5sFTWrURKaPM1yNzfUj1vtO2PbQk LV4UzpC3vgdo0SQFk8c+8Q6kGlOjmLQ+W33PD47QY020sbsd+yS0kN0lZ1/RBVRbqMSD 0jwg== X-Gm-Message-State: ALoCoQmasJIDDKKihItjtWkIZJtWeaw9rwjdZyjfLOtmO10NXhl5m70jjwr9/EgVWQihyjAjBaxn6v+ih8CS+prjR0QrkRzFEMAnpFvULgtyYLkuEXoLhGRxUUJJvQDwSiRTO8hvmwtc X-Received: by 10.50.30.3 with SMTP id o3mr3857740igh.44.1422637049599; Fri, 30 Jan 2015 08:57:29 -0800 (PST) X-Received: by 10.50.30.3 with SMTP id o3mr3857718igh.44.1422637049449; Fri, 30 Jan 2015 08:57:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Fri, 30 Jan 2015 08:56:59 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Fri, 30 Jan 2015 09:56:59 -0700 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=e89a8f83941ffa3b63050de17fd9 Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 16:57:34 -0000 --e89a8f83941ffa3b63050de17fd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But, while it may be clear to you, what I'm saying here is that it's not clear to a reader/implementer. Somehow the conversion from a character string to an octet string needs to be clearly and unambiguously stated. It doesn't have to be the text I suggested but it's not sufficient as it is now. Something like this might work, if you don't want to touch the parts in 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING." An "octet sequence using the url and filename safe Alphabet [...], with length less than 128 characters." is ambiguous. Octets and characters are intermixed with no mention of encoding. But they're not interchangeable. On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura wrote: > I do not think we need ASCII(). It is quite clear without it, I suppose. > > In 4.1, I would rather do like: > > code_verifier =3D high entropy cryptographic random > octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > Nat > > 2015-01-30 22:51 GMT+09:00 Brian Campbell : > >> That's definitely an improvement (to me anyway). >> >> Checking that the rest of the document uses those notations >> appropriately, I think, yields a few other changes. And probably begs fo= r >> the "ASCII(STRING) denotes the octets of the ASCII representation of >> STRING" notation/function, or something like it, to be put back in. Thos= e >> changes might look like the following: >> >> >> In 4.1.: >> >> OLD: >> code_verifier =3D high entropy cryptographic random ASCII [RFC0020] >> octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] >> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >> less than 128 characters. >> >> NEW (maybe): >> code_verifier =3D high entropy cryptographically strong random STRING >> using the url and filename safe Alphabet [A-Z] / [a-z] >> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >> less than 128 characters. >> >> >> In 4.2.: >> >> OLD: >> S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) >> >> NEW (maybe): >> S256 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier"))) >> >> >> In 4.6.: >> >> OLD: >> SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). >> >> NEW (maybe): >> SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challeng= e"). >> >> >> >> >> On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) >> wrote: >> >>> I take your point, Brian. >>> >>> In our most recent manuscript, STRING is defined inside ASCII(STRING) a= s >>> >>> STRING is a sequence of zero or more ASCII characters >>> >>> but it is kind of circular, and we do not seem to use ASCII(). >>> >>> What about re-writing the section like below? >>> >>> STRING denotes a sequence of zero or more ASCII [RFC0020] >>> characters. >>> >>> OCTETS denotes a sequence of zero or more octets. >>> >>> BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section >>> 3 producing a >>> ASCII[RFC0020] >>> STRING. >>> >>> BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per = Section >>> 3 , producing >>> a sequence of octets. >>> >>> SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] >>> of OCTETS. >>> >>> >>> >>> >>> >>> >>> On Jan 30, 2015, at 08:15, Brian Campbell >>> wrote: >>> >>> In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RF= C6234] >>> of STRING." >>> >>> But, in the little cow town where I come from anyway, you hash >>> bits/octets not character strings (BTW, "STRING" isn't defined anywhere= but >>> it's kind of implied that it's a string of characters). >>> >>> Should it say something more like "SHA256(STRING) denotes a SHA2 256bit >>> hash [RFC6234] of the octets of the ASCII [RFC0020] representation of >>> STRING."? >>> >>> I know it's kind of pedantic but I find it kind of confusing because th= e >>> code_verifier uses the url and filename safe alphabet, which has me sec= ond >>> guessing if SHA256(STRING) actually means a hash of the octet produced = by >>> base64url decoding the string. >>> >>> Maybe it's just me but, when reading the text, I find the transform >>> process to be much more confusing than I think it needs to be. Removing= and >>> clarifying some things will help. I hate to suggest this but maybe an >>> example showing the computation steps on both ends would be helpful? >>> >>> Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A7= 2 but >>> not used anywhere. >>> >>> And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url >>> decoding of STRING, per Section 3, producing a UTF-8 sequence of octets= ." >>> But what is a UTF-8 sequence of octets? Isn't it just a sequence octets= ? >>> The [RFC3629] reference, I think, could be removed. >>> >>> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 >>> >>> >>> Nat Sakimura >>> nat@sakimura.org >>> >>> >>> >>> >>> >>> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --e89a8f83941ffa3b63050de17fd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But, while it may be clear to you, what I'm saying her= e is that it's not clear to a reader/implementer.

Somehow the co= nversion from a character string to an octet string needs to be clearly and= unambiguously stated. It doesn't have to be the text I suggested but i= t's not sufficient as it is now.

Something like this might work,= if you don't want to touch the parts in 4.2 and 4.6: "SHA256(STRI= NG) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC002= 0] representation of STRING."

An "octet sequence using the= url and filename safe Alphabet [...], with length less than 128 characters= ." is ambiguous. Octets and characters are intermixed with no mention = of encoding. But they're not interchangeable.

<= div class=3D"gmail_extra">
On Fri, Jan 30, 20= 15 at 7:15 AM, Nat Sakimura <sakimura@gmail.com> wrote:
=
I do not= think we need ASCII(). It is quite clear without it, I suppose.=C2=A0
=
In 4.1, I would rather do like:=C2=A0

=C2=A0code_verifier = =3D high entropy cryptographic random=C2=A0
=C2=A0=C2= =A0 octet sequence using the url and filename safe Alphabet [A-Z] / [a-z]
=C2= =A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [R= FC4648], with length
=C2=A0=C2=A0 less than 128 characters.
Nat
=

2015-01-30 22:51 GMT+09:00 Brian Campbell <bcampbell@pingid= entity.com>:
That's definitely an improvement (to me anyw= ay).

Checking that the rest of the document uses those n= otations appropriately, I think, yields a few other changes. And probably b= egs for the "ASCII(STRING) denotes the octets of the ASCII representat= ion of STRING" notation/function, or something like it, to be put back= in. Those changes might look like the following:


In = 4.1.:

OLD:
=C2=A0=C2=A0 code_verifier =3D high entropy cryptogra= phic random ASCII [RFC0020]
=C2=A0=C2=A0 octet sequence using the url an= d filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / "-&qu= ot; / "_" from Sec 5 of RFC 4648 [RFC4648], with length
=C2=A0= =C2=A0 less than 128 characters.

NEW (maybe):
=C2=A0 code_verifie= r =3D high entropy cryptographically strong random STRING
=C2=A0 using t= he url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / &= quot;-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length<= br>=C2=A0=C2=A0 less than 128 characters.


In 4.2.:
OLD:
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64= URL(SHA256("code_verifier"))

NEW (maybe):
=C2=A0=C2=A0 = S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(ASCII("code= _verifier")))


In 4.6.:

OLD:
=C2=A0=C2= =A0 SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_c= hallenge").

NEW (maybe):
=C2=A0=C2=A0 SHA256(ASCII("cod= e_verifier")) =3D=3D BASE64URL-DECODE("code_challenge").
=



On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) &= lt;nat@sakimura.org> wrote:
<= div style=3D"word-wrap:break-word">
I take your point, Brian.=C2=A0=

In our most recent manuscript, = STRING is defined inside ASCII(STRING) as=C2=A0

STRING is a sequence of zero or more ASCII characters


STRING denotes a sequence of zero or more AS= CII =C2=A0[RFC0020]=C2=A0characters.=C2=A0

OCTETS denotes a seq= uence of zero or more octets.=C2=A0

BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per=C2= =A0Section 3=C2=A0producing a= ASCII[RFC0020]=C2=A0STRING.

<= p style=3D"margin-left:2em;margin-right:2em;font-family:verdana,helvetica,a= rial,sans-serif;font-size:13.3333px">BASE64URL-DECODE(STRING) denotes the b= ase64url decoding of STRING, per=C2=A0Section 3, producing a sequence of octets.

SHA256(OCTETS) denotes a SHA2 256bit hash=C2=A0[RFC6234]=C2=A0of OCTETS.





=
On Jan 30, 2015, at 08:15, Brian Ca= mpbell <= bcampbell@pingidentity.com> wrote:

In =C2=A72 [1] we've got "SHA256(STRING) denotes= a SHA2 256bit hash [RFC6234] of STRING."

But, in the li= ttle cow town where I come from anyway, you hash bits/octets not character = strings (BTW, "STRING" isn't defined anywhere but it's ki= nd of implied that it's a string of characters).=C2=A0

Sh= ould it say something more like "SHA256(STRING) denotes a SHA2 256bit = hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRIN= G."?

I know it's kind of pedantic but I find it kind= of confusing because the code_verifier uses the url and filename safe alph= abet, which has me second guessing if SHA256(STRING) actually means a hash = of the octet produced by base64url decoding the string.

= Maybe it's just me but, when reading the text, I find the transform pro= cess to be much more confusing than I think it needs to be. Removing and cl= arifying some things will help. I hate to suggest this but maybe an example= showing the computation steps on both ends would be helpful?

Also "UTF8(STRING)" and "ASCII(STRING)" nota= tions are defined in =C2=A72 but not used anywhere.

And =C2=A72 also= says, "BASE64URL-DECODE(STRING) denotes the base64url decoding of STR= ING, per Section 3, producing a UTF-8 sequence of octets." But what is= a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC3= 629] reference, I think, could be removed.






--
Nat Sakimura (=3Dnat)
Cha= irman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--e89a8f83941ffa3b63050de17fd9-- From nobody Fri Jan 30 09:51:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193E41A9144 for ; Fri, 30 Jan 2015 09:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSQk8blrgSPR for ; Fri, 30 Jan 2015 09:51:09 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF161A9142 for ; Fri, 30 Jan 2015 09:51:09 -0800 (PST) Received: from mail-ie0-f181.google.com ([209.85.223.181]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKVMvEjEowsrsS13kkXyobBH+HHvq+dhuV@postini.com; Fri, 30 Jan 2015 09:51:09 PST Received: by mail-ie0-f181.google.com with SMTP id rp18so4980791iec.12 for ; Fri, 30 Jan 2015 09:51:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LdEJQpNlw5AcErnKdqPnCuESxpNGfRFkVXg15YE8/T4=; b=KOWKB1ewcB6knBhuoWrW68HIt9VmsGne1MldnWqD4Bm7o1WpgRtV38lKHc44LCHqgk phvgfxGavQikVWO75lQR+e49K4JerI7jiTevLZ+fjhkJb7b+FU1CwU/BlsGM1al8qNYF v79cwE+iyqvg0Imsa8f2U03vRUNovEnuVs6ql+mJdozSKNUib+HS+qkVY4IymeBD2YaY WuIA66DwCNcP43sdx9DOyYcO+vNi8pKzNdXEBFSOUeTFB9aQp0+PiACSKOy4hJCSc2wm O6Yyg/5rPRxeGn0uQz/2WBK+50+SyHCUlcS1B1Pw5KdCGI4TlIxyZUggS9YUxklYtvM0 XZrQ== X-Gm-Message-State: ALoCoQnXHXjEoPhuiSoiNDs4+F/BjnjyqORJPJVQhVLj0i5fZF06mCoIUVvJWtQAD3FjaD1hz+X9cCM2+hZjsx/r6GQ5Nhy6BiPQkFgTgFbfHdrnxoRCSs8edGSZtTJJTLNl+6Qx7OWp X-Received: by 10.107.39.67 with SMTP id n64mr8675450ion.36.1422640267610; Fri, 30 Jan 2015 09:51:07 -0800 (PST) X-Received: by 10.107.39.67 with SMTP id n64mr8675440ion.36.1422640267519; Fri, 30 Jan 2015 09:51:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Fri, 30 Jan 2015 09:50:37 -0800 (PST) In-Reply-To: <54C7BBA4.4030702@gmx.net> References: <54C7BBA4.4030702@gmx.net> From: Brian Campbell Date: Fri, 30 Jan 2015 10:50:37 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11407bc4ca067c050de23f89 Archived-At: Cc: "oauth@ietf.org" , "naa@google.com >> Naveen Agarwal" Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 17:51:11 -0000 --001a11407bc4ca067c050de23f89 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > > 1) What implementations of the spec are you aware of? > We have an AS side implementation of an earlier draft that was released in June of last year: http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844 --001a11407bc4ca067c050de23f89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig <hannes.tschofe= nig@gmx.net> wrote:

1) What implementations of the spec are you aware of?
=
We have an AS side implementation of an earlier draft that w= as released in June of last year: http://documentation.pingidentity.com/pages/viewpage.action?pageId=3D2670= 6844
--001a11407bc4ca067c050de23f89-- From nobody Fri Jan 30 09:51:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC92E1A9142 for ; Fri, 30 Jan 2015 09:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-CAhSWe0lvT for ; Fri, 30 Jan 2015 09:51:38 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECAE01A913D for ; Fri, 30 Jan 2015 09:51:36 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-78-54cbc4a77d8c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.43.03365.7A4CBC45; Fri, 30 Jan 2015 12:51:35 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t0UHpZrc028193 for ; Fri, 30 Jan 2015 12:51:35 -0500 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (w92exedge6.exchange.mit.edu [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t0UHpYPD024618 for ; Fri, 30 Jan 2015 12:51:35 -0500 Received: from OC11EXHUB12.exchange.mit.edu (18.9.3.26) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 Jan 2015 12:50:38 -0500 Received: from OC11EXPO25.exchange.mit.edu ([169.254.1.131]) by OC11EXHUB12.exchange.mit.edu ([18.9.3.26]) with mapi id 14.03.0158.001; Fri, 30 Jan 2015 12:51:34 -0500 From: Zhanna Tsitkov To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-tsitkov-oauth-audit-02.txt Thread-Index: AQHQN0ULH4/mvfV0/ESS10XyYDgMMJzZUAmA Date: Fri, 30 Jan 2015 17:51:33 +0000 Message-ID: References: <20150123194427.30022.72182.idtracker@ietfa.amsl.com> In-Reply-To: <20150123194427.30022.72182.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.101.8.86] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBKsWRmVeSWpSXmKPExsUixG6nrrv8yOkQgwdrTCxOvn3F5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCf7zrEULBOomDX7KFsD41TeLkZODgkBE4mes51MELaYxIV7 69m6GLk4hAQWM0l8+t3FCOFcZZR4/WEBVOY2o0T7rzVMEM52RokXJ+9BOasZJZr+NjGDDGMT UJd4vHURK4gtIqAqse/oFXYQW1jAS2Lb78VAcQ6guLfEkQf6ECVGEgen/GcDsVmAyh+2TQFr 5RWwkjjVuBTMFhJwlLi56CvYGE4BJ4nPn/6B1TMC3f391BqwH5gFxCVuPZkP9Y+gxKLZe5hh fvu36yEbhC0vMXnxbTaIegOJ9+fmM0PY9hKrXx5nhLC1JZYtfM0McYOgxMmZT1gmMErOQrJi FpL2WUjaZyFpn4WkfQEj6ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTSTYzgCHVR 2cHYfEjpEKMAB6MSD++Cp6dChFgTy4orcw8xSnIwKYnyTl57OkSILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCO+USUA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJ3sDD QI2CRanpqRVpmTklCGkmDk6Q4TxAwzNAaniLCxJzizPTIfKnGBWlxHmTQRICIImM0jy4XlgC fcUoDvSKMO9KkCoeYPKF634FNJgJaHDg4hMgg0sSEVJSDYy1nuzL5h4TufWNcVfiiYW3boWt uWH9q82pbU2G2NS9RnVX4q58/DcrKFnwkJuK3ePjArzFrfoOwi/rgqsvGsvXpKxwdeiYc3hy k6LNoRdNKxR+twT8PD1tn/Jk5rWVy/3D/mXZVi89UnNI3EdDw5dzg1uPz/raW23uX4KStswM 2rBJqW3H57NKLMUZiYZazEXFiQBqqZ44ewMAAA== Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-tsitkov-oauth-audit-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 17:51:41 -0000 Hello, I have uploaded a new revision of the Audit draft. =20 It discusses an audit feature in OAuth 2.0 environments, namely,=20 - the parameters that are valuable for audit purposes,=20 - the audit log examination and querying,=20 - audit records privacy and security. =20 As it is currently stated in the draft, the Audit is presented as OAuth2 fe= ature, but can be potentially extended to UMA (with much stronger emphasis = on resource server=92s auditability), etc. Your feedback and comments, as always, are very much appreciated. Thanks, Zhanna On Jan 23, 2015, at 2:44 PM, internet-drafts@ietf.org wrote: >=20 > A new version of I-D, draft-tsitkov-oauth-audit-02.txt > has been successfully submitted by Zhanna Tsitkov and posted to the > IETF repository. >=20 > Name: draft-tsitkov-oauth-audit > Revision: 02 > Title: Audit in OAuth 2.0 > Document date: 2015-01-21 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-tsitkov-oauth-a= udit-02.txt > Status: https://datatracker.ietf.org/doc/draft-tsitkov-oauth-audi= t/ > Htmlized: http://tools.ietf.org/html/draft-tsitkov-oauth-audit-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tsitkov-oauth-au= dit-02 >=20 > Abstract: > This specification is an effort to provide guidelines for > implementing the Audit functionality for OAuth 2.0 enabled > environments. The data of interest for the OAuth 2.0 audit includes > scopes, permissions, policies and other authorization and > authentication related information. It can be used by resource and > authorization servers for detecting security-related problems in real > time and fast violation response, or by government agencies and > various institutions for after-the-fact forensic and compliance > analysis. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Jan 30 11:33:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE501A006F for ; Fri, 30 Jan 2015 11:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4asZ6uAEaoL for ; Fri, 30 Jan 2015 11:33:03 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776DC1A1ABC for ; Fri, 30 Jan 2015 11:33:02 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id p6so22126547qcv.1 for ; Fri, 30 Jan 2015 11:33:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=MdOKe27VXCsYrvRNSvhK7AE18/O/UhNP5Vqrxd7K5f0=; b=kWWv0j0iL3PEuXc+OJLQXlzMzhnCEHvhqZO/4nIDLXwE/zceAmiJ/ih0kzNwXbpqeM IQUHNlqnu8lOsnFGSb7+A98FhEYE0CXHd26DboPF67mrJP5fNt3rVWrnJ8HoiQY7+Sg0 iVtzhn7bstNFPZkHcPB5tu7LQImZ8Xv4W8IgP5LO64BayY3aA2c9EMBHIJ8vEHt74+Jd PPTHSBLOtrHct+gHJSD2DHMh7RWs7uzMULf/55tb4uj96zs5z+8stQWkqoXW8zmWNh4i M3UUt64br2RoALn4JDnG1v+rn0m10FbW1uOgjU+Bpxs8l/TkS7dIqdfrfmZWwFlg1m7u r6Fg== X-Gm-Message-State: ALoCoQkA9GzT6hiUqAl1yZRTbR3gZvdq/IhPsBECwLaJ94M8irVSM05tVV64p3wWlx0Y3xIqDVXQ X-Received: by 10.140.97.203 with SMTP id m69mr11372866qge.39.1422646381520; Fri, 30 Jan 2015 11:33:01 -0800 (PST) Received: from [192.168.1.36] (186-79-118-57.baf.movistar.cl. [186.79.118.57]) by mx.google.com with ESMTPSA id k3sm10958163qao.0.2015.01.30.11.32.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 11:33:00 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7875EE09-992C-44E7-994F-89D991D7F516"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Fri, 30 Jan 2015 16:32:55 -0300 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:33:06 -0000 --Apple-Mail=_7875EE09-992C-44E7-994F-89D991D7F516 Content-Type: multipart/alternative; boundary="Apple-Mail=_E1654815-7E4E-4814-B493-52882DEC4120" --Apple-Mail=_E1654815-7E4E-4814-B493-52882DEC4120 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Have a look at the latest version I added OCTETS(STRING) to show the = conversion. ASCII(STRING) seemed more confusing by drawing character = encoding back in. I was tempted to call it a octet array without the terminating NULL of = STRING but didn=E2=80=99t want to introduce array. Let me know what you think. > On Jan 30, 2015, at 1:56 PM, Brian Campbell = wrote: >=20 > But, while it may be clear to you, what I'm saying here is that it's = not clear to a reader/implementer. >=20 > Somehow the conversion from a character string to an octet string = needs to be clearly and unambiguously stated. It doesn't have to be the = text I suggested but it's not sufficient as it is now. >=20 > Something like this might work, if you don't want to touch the parts = in 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of = the octets of the ASCII [RFC0020] representation of STRING." >=20 > An "octet sequence using the url and filename safe Alphabet [...], = with length less than 128 characters." is ambiguous. Octets and = characters are intermixed with no mention of encoding. But they're not = interchangeable.=20 >=20 >=20 > On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura > wrote: > I do not think we need ASCII(). It is quite clear without it, I = suppose.=20 >=20 > In 4.1, I would rather do like:=20 >=20 > code_verifier =3D high entropy cryptographic random=20 > octet sequence using the url and filename safe Alphabet [A-Z] / = [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. >=20 > Nat >=20 > 2015-01-30 22:51 GMT+09:00 Brian Campbell >: > That's definitely an improvement (to me anyway).=20 >=20 > Checking that the rest of the document uses those notations = appropriately, I think, yields a few other changes. And probably begs = for the "ASCII(STRING) denotes the octets of the ASCII representation of = STRING" notation/function, or something like it, to be put back in. = Those changes might look like the following: >=20 >=20 > In 4.1.:=20 >=20 > OLD: > code_verifier =3D high entropy cryptographic random ASCII [RFC0020] > octet sequence using the url and filename safe Alphabet [A-Z] / = [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. >=20 > NEW (maybe): > code_verifier =3D high entropy cryptographically strong random = STRING > using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. >=20 >=20 > In 4.2.:=20 >=20 > OLD: > S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) >=20 > NEW (maybe): > S256 "code_challenge" =3D = BASE64URL(SHA256(ASCII("code_verifier"))) >=20 >=20 > In 4.6.:=20 >=20 > OLD: > SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). >=20 > NEW (maybe): > SHA256(ASCII("code_verifier")) =3D=3D = BASE64URL-DECODE("code_challenge"). >=20 >=20 >=20 >=20 > On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) = > wrote: > I take your point, Brian.=20 >=20 > In our most recent manuscript, STRING is defined inside ASCII(STRING) = as=20 >=20 > STRING is a sequence of zero or more ASCII characters >=20 > but it is kind of circular, and we do not seem to use ASCII().=20 >=20 > What about re-writing the section like below?=20 >=20 > STRING denotes a sequence of zero or more ASCII [RFC0020] = characters.=20 >=20 > OCTETS denotes a sequence of zero or more octets.=20 >=20 > BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per = Section 3 = producing a ASCII[RFC0020] = STRING. >=20 > BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per = Section 3 , = producing a sequence of octets. >=20 > SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] = of OCTETS. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Jan 30, 2015, at 08:15, Brian Campbell > wrote: >>=20 >> In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash = [RFC6234] of STRING."=20 >>=20 >> But, in the little cow town where I come from anyway, you hash = bits/octets not character strings (BTW, "STRING" isn't defined anywhere = but it's kind of implied that it's a string of characters). =20 >>=20 >> Should it say something more like "SHA256(STRING) denotes a SHA2 = 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] = representation of STRING."?=20 >>=20 >> I know it's kind of pedantic but I find it kind of confusing because = the code_verifier uses the url and filename safe alphabet, which has me = second guessing if SHA256(STRING) actually means a hash of the octet = produced by base64url decoding the string.=20 >>=20 >> Maybe it's just me but, when reading the text, I find the transform = process to be much more confusing than I think it needs to be. Removing = and clarifying some things will help. I hate to suggest this but maybe = an example showing the computation steps on both ends would be helpful? >>=20 >> Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A7= 2 but not used anywhere. >>=20 >> And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the = base64url decoding of STRING, per Section 3, producing a UTF-8 sequence = of octets." But what is a UTF-8 sequence of octets? Isn't it just a = sequence octets? The [RFC3629] reference, I think, could be removed. >>=20 >> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 = >=20 > Nat Sakimura > nat@sakimura.org >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 --Apple-Mail=_E1654815-7E4E-4814-B493-52882DEC4120 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Have a look at the latest version I added OCTETS(STRING) to = show the conversion.   ASCII(STRING) seemed more confusing by = drawing character encoding back in.

I was tempted to call it a octet array = without the terminating NULL of STRING but didn=E2=80=99t want to = introduce array.

Let me know what you think.

On = Jan 30, 2015, at 1:56 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

But, while it may be clear to you, what I'm saying here is = that it's not clear to a reader/implementer.

Somehow the conversion from a character string to an octet = string needs to be clearly and unambiguously stated. It doesn't have to = be the text I suggested but it's not sufficient as it is now.

Something like this might work, if you don't = want to touch the parts in 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 = 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] = representation of STRING."

An "octet = sequence using the url and filename safe Alphabet [...], with length = less than 128 characters." is ambiguous. Octets and characters are = intermixed with no mention of encoding. But they're not interchangeable. =


On Fri, = Jan 30, 2015 at 7:15 AM, Nat Sakimura <sakimura@gmail.com> wrote:
I do not think we need ASCII(). It is quite clear = without it, I suppose. 

In 4.1, I would rather do like: 

 code_verifier =3D high = entropy cryptographic random 
   octet sequence using the url and filename safe = Alphabet [A-Z] / [a-z]
   / = [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with = length
   less than 128 = characters.

Nat

2015-01-30 22:51 GMT+09:00 Brian = Campbell <bcampbell@pingidentity.com>:
That's definitely an improvement = (to me anyway).

Checking that the rest of the document uses those notations = appropriately, I think, yields a few other changes. And probably begs = for the "ASCII(STRING) denotes the octets of the ASCII representation of = STRING" notation/function, or something like it, to be put back in. = Those changes might look like the following:


In 4.1.:

OLD:
   code_verifier = =3D high entropy cryptographic random ASCII [RFC0020]
   octet sequence using the url and filename safe = Alphabet [A-Z] / [a-z]
   / [0-9] / "-" / "_" = from Sec 5 of RFC 4648 [RFC4648], with length
   = less than 128 characters.

NEW (maybe):
  code_verifier =3D high entropy cryptographically = strong random STRING
  using the url and filename = safe Alphabet [A-Z] / [a-z]
   / [0-9] / "-" / = "_" from Sec 5 of RFC 4648 [RFC4648], with length
   less than 128 characters.


In 4.2.:

OLD:
   S256  = "code_challenge" =3D BASE64URL(SHA256("code_verifier"))

NEW (maybe):
   S256  = "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier")))


In 4.6.: =

OLD:
   = SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge").

NEW (maybe):
   = SHA256(ASCII("code_verifier")) =3D=3D = BASE64URL-DECODE("code_challenge").




On Thu, Jan 29, 2015 at 8:37 PM, = Nat Sakimura (=3Dnat) <nat@sakimura.org> wrote:
I take your point, Brian. 

In our most = recent manuscript, STRING is defined inside ASCII(STRING) = as 

STRING is a sequence of zero or more ASCII = characters

but it is kind = of circular, and we do not seem to use ASCII(). 

What about = re-writing the section like below? 

STRING denotes a sequence = of zero or more ASCII  [RFC0020] characters. 

OCTETS denotes a sequence of = zero or more octets. 

BASE64URL(OCTETS) denotes = the base64url encoding of OCTETS, per Section = 3 producing a ASCII[RFC0020] STRING.

BASE64URL-DECODE(STRING) = denotes the base64url decoding of STRING, per Section = 3, producing a sequence of octets.

SHA256(OCTETS) denotes a = SHA2 256bit hash [RFC6234] of OCTETS.






On Jan 30, 2015, at 08:15, Brian Campbell <bcampbell@pingidentity.com> wrote:

In =C2=A72 = [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of = STRING."

But, in the little cow town = where I come from anyway, you hash bits/octets not character strings = (BTW, "STRING" isn't defined anywhere but it's kind of implied that it's = a string of characters). 

Should = it say something more like "SHA256(STRING) denotes a SHA2 256bit hash = [RFC6234] of the octets of the ASCII [RFC0020] representation of = STRING."?

I know it's kind of = pedantic but I find it kind of confusing because the code_verifier uses = the url and filename safe alphabet, which has me second guessing if = SHA256(STRING) actually means a hash of the octet produced by base64url = decoding the string.

Maybe it's just me but, when reading the text, I find the = transform process to be much more confusing than I think it needs to be. = Removing and clarifying some things will help. I hate to suggest this = but maybe an example showing the computation steps on both ends would be = helpful?

Also = "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72 but = not used anywhere.

And =C2=A72 also says, = "BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per = Section 3, producing a UTF-8 sequence of octets." But what is a UTF-8 = sequence of octets? Isn't it just a sequence octets? The [RFC3629] = reference, I think, could be removed.

[1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2<= /a>

Nat Sakimura
nat@sakimura.org









--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=


= --Apple-Mail=_E1654815-7E4E-4814-B493-52882DEC4120-- --Apple-Mail=_7875EE09-992C-44E7-994F-89D991D7F516 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMzAxOTMyNTVaMCMGCSqGSIb3DQEJBDEWBBTnETh1VD884Af5Em3Czg1m jI+H2zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB1iYkW9ntEzkivrRiiwYIjmo4fnCZOOZFPdfC3ST2rbCkw1J0ckSys /Mfzddct1DAmblZ/5p7s7mu2Zb/U1AJQlYtC3Q+nrc4mMspRzv2WN8ouI/xJUDLbGaN+lsVxHtbL 75ZgnMtnUSm2cy0sRuDP4PAlM3CXLjtL7fKnU3+nswEIoaa2MprxCKV3kNQwp5WrTWtz8SMz1DiH 4+wiU9Cx5T8Pg/qGV4v4QNhrazm0sE6nFSlsxz60q8so1OjVF55pBzVnQnwT53MtOc48VpPf522K BLQ0RTQanAr2f02qL9mk3WeXyiJS6Wv/t02ldGdowodIuCn5jmoY0uMIyGYGAAAAAAAA --Apple-Mail=_7875EE09-992C-44E7-994F-89D991D7F516-- From nobody Fri Jan 30 11:39:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4CB1A1B77 for ; Fri, 30 Jan 2015 11:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=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 Mo4VS9njooa5 for ; Fri, 30 Jan 2015 11:38:54 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F291A1B9C for ; Fri, 30 Jan 2015 11:38:54 -0800 (PST) Received: from CH1PR03CA010.namprd03.prod.outlook.com (10.255.156.155) by DM2PR0301MB1312.namprd03.prod.outlook.com (25.160.222.17) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 30 Jan 2015 19:38:51 +0000 Received: from BN1BFFO11FD038.protection.gbl (10.255.156.132) by CH1PR03CA010.outlook.office365.com (10.255.156.155) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Fri, 30 Jan 2015 19:38:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.1.75.11 via Frontend Transport; Fri, 30 Jan 2015 19:38:51 +0000 Received: from TK5EX14MBXC291.redmond.corp.microsoft.com ([169.254.2.242]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0224.003; Fri, 30 Jan 2015 19:38:07 +0000 From: Mike Jones To: John Bradley , Brian Campbell Thread-Topic: [OAUTH-WG] PKCE: SHA256(WAT?) Thread-Index: AQHQPBmnAv7fsfHclEyYI3e5SN6eHpzYr9IXgAAGSgCAAC02gIAAK5GAgAAAPbA= Date: Fri, 30 Jan 2015 19:38:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943A2201928TK5EX14MBXC291r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; ve7jtb.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(76104003)(24454002)(377454003)(52314003)(377424004)(77156002)(86612001)(50986999)(102836002)(15975445007)(62966003)(54356999)(76176999)(55846006)(512874002)(86362001)(2900100001)(46102003)(16236675004)(106116001)(92566002)(33656002)(19617315012)(2950100001)(2920100001)(19580405001)(6806004)(84326002)(87936001)(106466001)(66066001)(2656002)(104016003)(93886004)(19625215002)(19580395003)(19300405004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1312; H:mail.microsoft.com; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1312; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR0301MB1312; X-Forefront-PRVS: 04724A515E X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1312; X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2015 19:38:51.0921 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB1312 Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 19:38:57 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943A2201928TK5EX14MBXC291r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25h dHVyZS00MSNzZWN0aW9uLTEuMSB1c2VzIHRoaXMgbm90YXRpb246DQoNCiAgIFVURjgoU1RSSU5H KSBkZW5vdGVzIHRoZSBvY3RldHMgb2YgdGhlIFVURi04IFtSRkMzNjI5PGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzM2Mjk+XSByZXByZXNlbnRhdGlvbg0KICAgb2YgU1RSSU5HLCB3aGVy ZSBTVFJJTkcgaXMgYSBzZXF1ZW5jZSBvZiB6ZXJvIG9yIG1vcmUgVW5pY29kZQ0KICAgW1VOSUNP REU8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNp Z25hdHVyZS00MSNyZWYtVU5JQ09ERT5dIGNoYXJhY3RlcnMuDQoNCiAgIEFTQ0lJKFNUUklORykg ZGVub3RlcyB0aGUgb2N0ZXRzIG9mIHRoZSBBU0NJSSBbUkZDMjA8aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMjA+XSByZXByZXNlbnRhdGlvbg0KICAgb2YgU1RSSU5HLCB3aGVyZSBTVFJJ TkcgaXMgYSBzZXF1ZW5jZSBvZiB6ZXJvIG9yIG1vcmUgQVNDSUkNCiAgIGNoYXJhY3RlcnMuDQoN ClRoaXMgaXMgdW5hbWJpZ3VvdXMgYW5kIGhhcyBhbHJlYWR5IGJlZW4gdmV0dGVkIGJ5IHRoZSBJ RVNHIGFuZCBTZWNEaXIsIHNvIEkgd291bGQgdXNlIGV4YWN0bHkgdGhpcyB3b3JkaW5nLg0KDQpP Q1RFVFMoU1RSSU5HKSBpcyBhbWJpZ3VvdXMsIHNpbmNlIGZvciB0aGUgc2FtZSBzdHJpbmcgdGhl cmUgYXJlIG1hbnkgcG9zc2libGUgcmVwcmVzZW50YXRpb25zIGFzIG9jdGV0cywgaW5jbHVkaW5n IEFTQ0lJLCBVVEYtOCwgVVRGLTE2LCBVVEYtMzIsIGFuZCBFQkNESUMuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1IDExOjMz IEFNDQpUbzogQnJpYW4gQ2FtcGJlbGwNCkNjOiBvYXV0aDsgTmF2ZWVuIEFnYXJ3YWwNClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIFBLQ0U6IFNIQTI1NihXQVQ/KQ0KDQpIYXZlIGEgbG9vayBhdCB0 aGUgbGF0ZXN0IHZlcnNpb24gSSBhZGRlZCBPQ1RFVFMoU1RSSU5HKSB0byBzaG93IHRoZSBjb252 ZXJzaW9uLiAgIEFTQ0lJKFNUUklORykgc2VlbWVkIG1vcmUgY29uZnVzaW5nIGJ5IGRyYXdpbmcg Y2hhcmFjdGVyIGVuY29kaW5nIGJhY2sgaW4uDQoNCkkgd2FzIHRlbXB0ZWQgdG8gY2FsbCBpdCBh IG9jdGV0IGFycmF5IHdpdGhvdXQgdGhlIHRlcm1pbmF0aW5nIE5VTEwgb2YgU1RSSU5HIGJ1dCBk aWRu4oCZdCB3YW50IHRvIGludHJvZHVjZSBhcnJheS4NCg0KTGV0IG1lIGtub3cgd2hhdCB5b3Ug dGhpbmsuDQoNCk9uIEphbiAzMCwgMjAxNSwgYXQgMTo1NiBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bT4+IHdyb3RlOg0KDQpCdXQsIHdoaWxlIGl0IG1heSBiZSBjbGVhciB0byB5b3UsIHdoYXQgSSdt IHNheWluZyBoZXJlIGlzIHRoYXQgaXQncyBub3QgY2xlYXIgdG8gYSByZWFkZXIvaW1wbGVtZW50 ZXIuDQoNClNvbWVob3cgdGhlIGNvbnZlcnNpb24gZnJvbSBhIGNoYXJhY3RlciBzdHJpbmcgdG8g YW4gb2N0ZXQgc3RyaW5nIG5lZWRzIHRvIGJlIGNsZWFybHkgYW5kIHVuYW1iaWd1b3VzbHkgc3Rh dGVkLiBJdCBkb2Vzbid0IGhhdmUgdG8gYmUgdGhlIHRleHQgSSBzdWdnZXN0ZWQgYnV0IGl0J3Mg bm90IHN1ZmZpY2llbnQgYXMgaXQgaXMgbm93Lg0KDQpTb21ldGhpbmcgbGlrZSB0aGlzIG1pZ2h0 IHdvcmssIGlmIHlvdSBkb24ndCB3YW50IHRvIHRvdWNoIHRoZSBwYXJ0cyBpbiA0LjIgYW5kIDQu NjogIlNIQTI1NihTVFJJTkcpIGRlbm90ZXMgYSBTSEEyIDI1NmJpdCBoYXNoIFtSRkM2MjM0XSBv ZiB0aGUgb2N0ZXRzIG9mIHRoZSBBU0NJSSBbUkZDMDAyMF0gcmVwcmVzZW50YXRpb24gb2YgU1RS SU5HLiINCg0KQW4gIm9jdGV0IHNlcXVlbmNlIHVzaW5nIHRoZSB1cmwgYW5kIGZpbGVuYW1lIHNh ZmUgQWxwaGFiZXQgWy4uLl0sIHdpdGggbGVuZ3RoIGxlc3MgdGhhbiAxMjggY2hhcmFjdGVycy4i IGlzIGFtYmlndW91cy4gT2N0ZXRzIGFuZCBjaGFyYWN0ZXJzIGFyZSBpbnRlcm1peGVkIHdpdGgg bm8gbWVudGlvbiBvZiBlbmNvZGluZy4gQnV0IHRoZXkncmUgbm90IGludGVyY2hhbmdlYWJsZS4N Cg0KDQpPbiBGcmksIEphbiAzMCwgMjAxNSBhdCA3OjE1IEFNLCBOYXQgU2FraW11cmEgPHNha2lt dXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpJIGRvIG5v dCB0aGluayB3ZSBuZWVkIEFTQ0lJKCkuIEl0IGlzIHF1aXRlIGNsZWFyIHdpdGhvdXQgaXQsIEkg c3VwcG9zZS4NCg0KSW4gNC4xLCBJIHdvdWxkIHJhdGhlciBkbyBsaWtlOg0KDQogY29kZV92ZXJp ZmllciA9IGhpZ2ggZW50cm9weSBjcnlwdG9ncmFwaGljIHJhbmRvbQ0KICAgb2N0ZXQgc2VxdWVu Y2UgdXNpbmcgdGhlIHVybCBhbmQgZmlsZW5hbWUgc2FmZSBBbHBoYWJldCBbQS1aXSAvIFthLXpd DQogICAvIFswLTldIC8gIi0iIC8gIl8iIGZyb20gU2VjIDUgb2YgUkZDIDQ2NDggW1JGQzQ2NDhd LCB3aXRoIGxlbmd0aA0KICAgbGVzcyB0aGFuIDEyOCBjaGFyYWN0ZXJzLg0KDQpOYXQNCg0KMjAx NS0wMS0zMCAyMjo1MSBHTVQrMDk6MDAgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+Og0KVGhhdCdzIGRl ZmluaXRlbHkgYW4gaW1wcm92ZW1lbnQgKHRvIG1lIGFueXdheSkuDQpDaGVja2luZyB0aGF0IHRo ZSByZXN0IG9mIHRoZSBkb2N1bWVudCB1c2VzIHRob3NlIG5vdGF0aW9ucyBhcHByb3ByaWF0ZWx5 LCBJIHRoaW5rLCB5aWVsZHMgYSBmZXcgb3RoZXIgY2hhbmdlcy4gQW5kIHByb2JhYmx5IGJlZ3Mg Zm9yIHRoZSAiQVNDSUkoU1RSSU5HKSBkZW5vdGVzIHRoZSBvY3RldHMgb2YgdGhlIEFTQ0lJIHJl cHJlc2VudGF0aW9uIG9mIFNUUklORyIgbm90YXRpb24vZnVuY3Rpb24sIG9yIHNvbWV0aGluZyBs aWtlIGl0LCB0byBiZSBwdXQgYmFjayBpbi4gVGhvc2UgY2hhbmdlcyBtaWdodCBsb29rIGxpa2Ug dGhlIGZvbGxvd2luZzoNCg0KSW4gNC4xLjoNCg0KT0xEOg0KICAgY29kZV92ZXJpZmllciA9IGhp Z2ggZW50cm9weSBjcnlwdG9ncmFwaGljIHJhbmRvbSBBU0NJSSBbUkZDMDAyMF0NCiAgIG9jdGV0 IHNlcXVlbmNlIHVzaW5nIHRoZSB1cmwgYW5kIGZpbGVuYW1lIHNhZmUgQWxwaGFiZXQgW0EtWl0g LyBbYS16XQ0KICAgLyBbMC05XSAvICItIiAvICJfIiBmcm9tIFNlYyA1IG9mIFJGQyA0NjQ4IFtS RkM0NjQ4XSwgd2l0aCBsZW5ndGgNCiAgIGxlc3MgdGhhbiAxMjggY2hhcmFjdGVycy4NCg0KTkVX IChtYXliZSk6DQogIGNvZGVfdmVyaWZpZXIgPSBoaWdoIGVudHJvcHkgY3J5cHRvZ3JhcGhpY2Fs bHkgc3Ryb25nIHJhbmRvbSBTVFJJTkcNCiAgdXNpbmcgdGhlIHVybCBhbmQgZmlsZW5hbWUgc2Fm ZSBBbHBoYWJldCBbQS1aXSAvIFthLXpdDQogICAvIFswLTldIC8gIi0iIC8gIl8iIGZyb20gU2Vj IDUgb2YgUkZDIDQ2NDggW1JGQzQ2NDhdLCB3aXRoIGxlbmd0aA0KICAgbGVzcyB0aGFuIDEyOCBj aGFyYWN0ZXJzLg0KDQpJbiA0LjIuOg0KDQpPTEQ6DQogICBTMjU2ICAiY29kZV9jaGFsbGVuZ2Ui ID0gQkFTRTY0VVJMKFNIQTI1NigiY29kZV92ZXJpZmllciIpKQ0KDQpORVcgKG1heWJlKToNCiAg IFMyNTYgICJjb2RlX2NoYWxsZW5nZSIgPSBCQVNFNjRVUkwoU0hBMjU2KEFTQ0lJKCJjb2RlX3Zl cmlmaWVyIikpKQ0KDQpJbiA0LjYuOg0KDQpPTEQ6DQogICBTSEEyNTYoImNvZGVfdmVyaWZpZXIi ICkgPT0gQkFTRTY0VVJMLURFQ09ERSgiY29kZV9jaGFsbGVuZ2UiKS4NCg0KTkVXIChtYXliZSk6 DQogICBTSEEyNTYoQVNDSUkoImNvZGVfdmVyaWZpZXIiKSkgPT0gQkFTRTY0VVJMLURFQ09ERSgi Y29kZV9jaGFsbGVuZ2UiKS4NCg0KDQoNCk9uIFRodSwgSmFuIDI5LCAyMDE1IGF0IDg6MzcgUE0s IE5hdCBTYWtpbXVyYSAoPW5hdCkgPG5hdEBzYWtpbXVyYS5vcmc8bWFpbHRvOm5hdEBzYWtpbXVy YS5vcmc+PiB3cm90ZToNCkkgdGFrZSB5b3VyIHBvaW50LCBCcmlhbi4NCg0KSW4gb3VyIG1vc3Qg cmVjZW50IG1hbnVzY3JpcHQsIFNUUklORyBpcyBkZWZpbmVkIGluc2lkZSBBU0NJSShTVFJJTkcp IGFzDQoNClNUUklORyBpcyBhIHNlcXVlbmNlIG9mIHplcm8gb3IgbW9yZSBBU0NJSSBjaGFyYWN0 ZXJzDQoNCmJ1dCBpdCBpcyBraW5kIG9mIGNpcmN1bGFyLCBhbmQgd2UgZG8gbm90IHNlZW0gdG8g dXNlIEFTQ0lJKCkuDQoNCldoYXQgYWJvdXQgcmUtd3JpdGluZyB0aGUgc2VjdGlvbiBsaWtlIGJl bG93Pw0KDQpTVFJJTkcgZGVub3RlcyBhIHNlcXVlbmNlIG9mIHplcm8gb3IgbW9yZSBBU0NJSSAg W1JGQzAwMjBdPGh0dHA6Ly94bWwycmZjLmlldGYub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjUkZD MDAyMD4gY2hhcmFjdGVycy4NCk9DVEVUUyBkZW5vdGVzIGEgc2VxdWVuY2Ugb2YgemVybyBvciBt b3JlIG9jdGV0cy4NCkJBU0U2NFVSTChPQ1RFVFMpIGRlbm90ZXMgdGhlIGJhc2U2NHVybCBlbmNv ZGluZyBvZiBPQ1RFVFMsIHBlciBTZWN0aW9uIDM8aHR0cDovL3htbDJyZmMuaWV0Zi5vcmcvY2dp LWJpbi94bWwycmZjLmNnaSNUZXJtaW5vbG9neT4gcHJvZHVjaW5nIGEgQVNDSUlbUkZDMDAyMF08 aHR0cDovL3htbDJyZmMuaWV0Zi5vcmcvY2dpLWJpbi94bWwycmZjLmNnaSNSRkMwMDIwPiBTVFJJ TkcuDQpCQVNFNjRVUkwtREVDT0RFKFNUUklORykgZGVub3RlcyB0aGUgYmFzZTY0dXJsIGRlY29k aW5nIG9mIFNUUklORywgcGVyIFNlY3Rpb24gMzxodHRwOi8veG1sMnJmYy5pZXRmLm9yZy9jZ2kt YmluL3htbDJyZmMuY2dpI1Rlcm1pbm9sb2d5PiwgcHJvZHVjaW5nIGEgc2VxdWVuY2Ugb2Ygb2N0 ZXRzLg0KU0hBMjU2KE9DVEVUUykgZGVub3RlcyBhIFNIQTIgMjU2Yml0IGhhc2ggW1JGQzYyMzRd PGh0dHA6Ly94bWwycmZjLmlldGYub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2kjUkZDNjIzND4gb2Yg T0NURVRTLg0KDQoNCg0KDQoNCk9uIEphbiAzMCwgMjAxNSwgYXQgMDg6MTUsIEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20+PiB3cm90ZToNCg0KSW4gwqcyIFsxXSB3ZSd2ZSBnb3QgIlNIQTI1NihTVFJJTkcp IGRlbm90ZXMgYSBTSEEyIDI1NmJpdCBoYXNoIFtSRkM2MjM0XSBvZiBTVFJJTkcuIg0KQnV0LCBp biB0aGUgbGl0dGxlIGNvdyB0b3duIHdoZXJlIEkgY29tZSBmcm9tIGFueXdheSwgeW91IGhhc2gg Yml0cy9vY3RldHMgbm90IGNoYXJhY3RlciBzdHJpbmdzIChCVFcsICJTVFJJTkciIGlzbid0IGRl ZmluZWQgYW55d2hlcmUgYnV0IGl0J3Mga2luZCBvZiBpbXBsaWVkIHRoYXQgaXQncyBhIHN0cmlu ZyBvZiBjaGFyYWN0ZXJzKS4NClNob3VsZCBpdCBzYXkgc29tZXRoaW5nIG1vcmUgbGlrZSAiU0hB MjU2KFNUUklORykgZGVub3RlcyBhIFNIQTIgMjU2Yml0IGhhc2ggW1JGQzYyMzRdIG9mIHRoZSBv Y3RldHMgb2YgdGhlIEFTQ0lJIFtSRkMwMDIwXSByZXByZXNlbnRhdGlvbiBvZiBTVFJJTkcuIj8N Ckkga25vdyBpdCdzIGtpbmQgb2YgcGVkYW50aWMgYnV0IEkgZmluZCBpdCBraW5kIG9mIGNvbmZ1 c2luZyBiZWNhdXNlIHRoZSBjb2RlX3ZlcmlmaWVyIHVzZXMgdGhlIHVybCBhbmQgZmlsZW5hbWUg c2FmZSBhbHBoYWJldCwgd2hpY2ggaGFzIG1lIHNlY29uZCBndWVzc2luZyBpZiBTSEEyNTYoU1RS SU5HKSBhY3R1YWxseSBtZWFucyBhIGhhc2ggb2YgdGhlIG9jdGV0IHByb2R1Y2VkIGJ5IGJhc2U2 NHVybCBkZWNvZGluZyB0aGUgc3RyaW5nLg0KTWF5YmUgaXQncyBqdXN0IG1lIGJ1dCwgd2hlbiBy ZWFkaW5nIHRoZSB0ZXh0LCBJIGZpbmQgdGhlIHRyYW5zZm9ybSBwcm9jZXNzIHRvIGJlIG11Y2gg bW9yZSBjb25mdXNpbmcgdGhhbiBJIHRoaW5rIGl0IG5lZWRzIHRvIGJlLiBSZW1vdmluZyBhbmQg Y2xhcmlmeWluZyBzb21lIHRoaW5ncyB3aWxsIGhlbHAuIEkgaGF0ZSB0byBzdWdnZXN0IHRoaXMg YnV0IG1heWJlIGFuIGV4YW1wbGUgc2hvd2luZyB0aGUgY29tcHV0YXRpb24gc3RlcHMgb24gYm90 aCBlbmRzIHdvdWxkIGJlIGhlbHBmdWw/DQoNCkFsc28gIlVURjgoU1RSSU5HKSIgYW5kICJBU0NJ SShTVFJJTkcpIiBub3RhdGlvbnMgYXJlIGRlZmluZWQgaW4gwqcyIGJ1dCBub3QgdXNlZCBhbnl3 aGVyZS4NCg0KQW5kIMKnMiBhbHNvIHNheXMsICJCQVNFNjRVUkwtREVDT0RFKFNUUklORykgZGVu b3RlcyB0aGUgYmFzZTY0dXJsIGRlY29kaW5nIG9mIFNUUklORywgcGVyIFNlY3Rpb24gMywgcHJv ZHVjaW5nIGEgVVRGLTggc2VxdWVuY2Ugb2Ygb2N0ZXRzLiIgQnV0IHdoYXQgaXMgYSBVVEYtOCBz ZXF1ZW5jZSBvZiBvY3RldHM/IElzbid0IGl0IGp1c3QgYSBzZXF1ZW5jZSBvY3RldHM/IFRoZSBb UkZDMzYyOV0gcmVmZXJlbmNlLCBJIHRoaW5rLCBjb3VsZCBiZSByZW1vdmVkLg0KDQpbMV0gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc3BvcC0wNiNzZWN0aW9u LTINCg0KTmF0IFNha2ltdXJhDQpuYXRAc2FraW11cmEub3JnPG1haWx0bzpuYXRAc2FraW11cmEu b3JnPg0KDQoNCg0KDQoNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwg T3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0K DQo= --_000_4E1F6AAD24975D4BA5B1680429673943A2201928TK5EX14MBXC291r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtNDEjc2VjdGlvbi0xLjEiPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtNDEjc2VjdGlv bi0xLjE8L2E+DQogdXNlcyB0aGlzIG5vdGF0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVVRGOChTVFJJTkcpIGRlbm90ZXMg dGhlIG9jdGV0cyBvZiB0aGUgVVRGLTggWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzM2MjkiIHRpdGxlPSImcXVvdDtVVEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQg b2YgSVNPIDEwNjQ2JnF1b3Q7Ij5SRkMzNjI5PC9hPl0NCiByZXByZXNlbnRhdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvZiBTVFJJTkcsIHdoZXJlIFNUUklORyBpcyBh IHNlcXVlbmNlIG9mIHplcm8gb3IgbW9yZSBVbmljb2RlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTQxI3JlZi1VTklDT0RFIiB0aXRsZT0iJnF1b3Q7 VGhlIFVuaWNvZGUgU3RhbmRhcmQmcXVvdDsiPlVOSUNPREU8L2E+XSBjaGFyYWN0ZXJzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBBU0NJSShTVFJJTkcpIGRlbm90ZXMgdGhlIG9jdGV0cyBvZiB0aGUgQVNDSUkgWzxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIwIiB0aXRsZT0iJnF1b3Q7QVNDSUkg Zm9ybWF0IGZvciBOZXR3b3JrIEludGVyY2hhbmdlJnF1b3Q7Ij5SRkMyMDwvYT5dIHJlcHJlc2Vu dGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG9mIFNUUklORywgd2hl cmUgU1RSSU5HIGlzIGEgc2VxdWVuY2Ugb2YgemVybyBvciBtb3JlIEFTQ0lJPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNoYXJhY3RlcnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGlzIGlzIHVuYW1iaWd1b3VzIGFuZCBoYXMgYWxyZWFk eSBiZWVuIHZldHRlZCBieSB0aGUgSUVTRyBhbmQgU2VjRGlyLCBzbyBJIHdvdWxkIHVzZSBleGFj dGx5IHRoaXMgd29yZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPk9DVEVUUyhTVFJJTkcpIGlzIGFtYmlndW91cywgc2luY2UgZm9yIHRoZSBzYW1lIHN0cmlu ZyB0aGVyZSBhcmUgbWFueSBwb3NzaWJsZSByZXByZXNlbnRhdGlvbnMgYXMgb2N0ZXRzLCBpbmNs dWRpbmcgQVNDSUksIFVURi04LCBVVEYtMTYsIFVURi0zMiwgYW5kIEVCQ0RJQy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkpvaG4gQnJhZGxleTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkg MzAsIDIwMTUgMTE6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsPGJyPg0KPGI+ Q2M6PC9iPiBvYXV0aDsgTmF2ZWVuIEFnYXJ3YWw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gUEtDRTogU0hBMjU2KFdBVD8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGF2ZSBhIGxvb2sgYXQgdGhlIGxhdGVzdCB2ZXJzaW9uIEkgYWRk ZWQgT0NURVRTKFNUUklORykgdG8gc2hvdyB0aGUgY29udmVyc2lvbi4gJm5ic3A7IEFTQ0lJKFNU UklORykgc2VlbWVkIG1vcmUgY29uZnVzaW5nIGJ5IGRyYXdpbmcgY2hhcmFjdGVyIGVuY29kaW5n IGJhY2sgaW4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHdhcyB0ZW1wdGVkIHRvIGNhbGwgaXQgYSBvY3RldCBhcnJheSB3aXRob3V0IHRoZSB0ZXJtaW5h dGluZyBOVUxMIG9mIFNUUklORyBidXQgZGlkbuKAmXQgd2FudCB0byBpbnRyb2R1Y2UgYXJyYXku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxl dCBtZSBrbm93IHdoYXQgeW91IHRoaW5rLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDMwLCAyMDE1LCBhdCAxOjU2IFBNLCBCcmlh biBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t Ij5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0LCB3aGlsZSBpdCBtYXkgYmUgY2xl YXIgdG8geW91LCB3aGF0IEknbSBzYXlpbmcgaGVyZSBpcyB0aGF0IGl0J3Mgbm90IGNsZWFyIHRv IGEgcmVhZGVyL2ltcGxlbWVudGVyLjxicj4NCjxicj4NClNvbWVob3cgdGhlIGNvbnZlcnNpb24g ZnJvbSBhIGNoYXJhY3RlciBzdHJpbmcgdG8gYW4gb2N0ZXQgc3RyaW5nIG5lZWRzIHRvIGJlIGNs ZWFybHkgYW5kIHVuYW1iaWd1b3VzbHkgc3RhdGVkLiBJdCBkb2Vzbid0IGhhdmUgdG8gYmUgdGhl IHRleHQgSSBzdWdnZXN0ZWQgYnV0IGl0J3Mgbm90IHN1ZmZpY2llbnQgYXMgaXQgaXMgbm93Ljxi cj4NCjxicj4NClNvbWV0aGluZyBsaWtlIHRoaXMgbWlnaHQgd29yaywgaWYgeW91IGRvbid0IHdh bnQgdG8gdG91Y2ggdGhlIHBhcnRzIGluIDQuMiBhbmQgNC42OiAmcXVvdDtTSEEyNTYoU1RSSU5H KSBkZW5vdGVzIGEgU0hBMiAyNTZiaXQgaGFzaCBbUkZDNjIzNF0gb2YgdGhlIG9jdGV0cyBvZiB0 aGUgQVNDSUkgW1JGQzAwMjBdIHJlcHJlc2VudGF0aW9uIG9mIFNUUklORy4mcXVvdDs8YnI+DQo8 YnI+DQpBbiAmcXVvdDtvY3RldCBzZXF1ZW5jZSB1c2luZyB0aGUgdXJsIGFuZCBmaWxlbmFtZSBz YWZlIEFscGhhYmV0IFsuLi5dLCB3aXRoIGxlbmd0aCBsZXNzIHRoYW4gMTI4IGNoYXJhY3RlcnMu JnF1b3Q7IGlzIGFtYmlndW91cy4gT2N0ZXRzIGFuZCBjaGFyYWN0ZXJzIGFyZSBpbnRlcm1peGVk IHdpdGggbm8gbWVudGlvbiBvZiBlbmNvZGluZy4gQnV0IHRoZXkncmUgbm90IGludGVyY2hhbmdl YWJsZS4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZyaSwgSmFuIDMwLCAyMDE1IGF0IDc6MTUgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCB0aGluayB3ZSBuZWVkIEFTQ0lJKCkuIEl0IGlz IHF1aXRlIGNsZWFyIHdpdGhvdXQgaXQsIEkgc3VwcG9zZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIDQuMSwgSSB3b3VsZCByYXRoZXIgZG8g bGlrZTombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Y29kZV92ZXJpZmllciA9IGhpZ2ggZW50cm9weSBjcnlwdG9ncmFwaGlj IHJhbmRvbSZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyBvY3RldCBzZXF1ZW5jZSB1c2luZyB0aGUg dXJsIGFuZCBmaWxlbmFtZSBzYWZlIEFscGhhYmV0IFtBLVpdIC8gW2Etel08YnI+DQombmJzcDsm bmJzcDsgLyBbMC05XSAvICZxdW90Oy0mcXVvdDsgLyAmcXVvdDtfJnF1b3Q7IGZyb20gU2VjIDUg b2YgUkZDIDQ2NDggW1JGQzQ2NDhdLCB3aXRoIGxlbmd0aDxicj4NCiZuYnNwOyZuYnNwOyBsZXNz IHRoYW4gMTI4IGNoYXJhY3RlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTUtMDEtMzAgMjI6NTEgR01UJiM0 MzswOTowMCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208 L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhdCdzIGRlZmlu aXRlbHkgYW4gaW1wcm92ZW1lbnQgKHRvIG1lIGFueXdheSkuDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+Q2hlY2tpbmcgdGhhdCB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgdXNlcyB0aG9zZSBu b3RhdGlvbnMgYXBwcm9wcmlhdGVseSwgSSB0aGluaywgeWllbGRzIGEgZmV3IG90aGVyIGNoYW5n ZXMuIEFuZCBwcm9iYWJseSBiZWdzIGZvciB0aGUgJnF1b3Q7QVNDSUkoU1RSSU5HKSBkZW5vdGVz IHRoZSBvY3RldHMgb2YgdGhlIEFTQ0lJIHJlcHJlc2VudGF0aW9uIG9mIFNUUklORyZxdW90Ow0K IG5vdGF0aW9uL2Z1bmN0aW9uLCBvciBzb21ldGhpbmcgbGlrZSBpdCwgdG8gYmUgcHV0IGJhY2sg aW4uIFRob3NlIGNoYW5nZXMgbWlnaHQgbG9vayBsaWtlIHRoZSBmb2xsb3dpbmc6PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkluIDQuMS46IDxicj4NCjxicj4NCk9MRDo8YnI+ DQombmJzcDsmbmJzcDsgY29kZV92ZXJpZmllciA9IGhpZ2ggZW50cm9weSBjcnlwdG9ncmFwaGlj IHJhbmRvbSBBU0NJSSBbUkZDMDAyMF08YnI+DQombmJzcDsmbmJzcDsgb2N0ZXQgc2VxdWVuY2Ug dXNpbmcgdGhlIHVybCBhbmQgZmlsZW5hbWUgc2FmZSBBbHBoYWJldCBbQS1aXSAvIFthLXpdPGJy Pg0KJm5ic3A7Jm5ic3A7IC8gWzAtOV0gLyAmcXVvdDstJnF1b3Q7IC8gJnF1b3Q7XyZxdW90OyBm cm9tIFNlYyA1IG9mIFJGQyA0NjQ4IFtSRkM0NjQ4XSwgd2l0aCBsZW5ndGg8YnI+DQombmJzcDsm bmJzcDsgbGVzcyB0aGFuIDEyOCBjaGFyYWN0ZXJzLjxicj4NCjxicj4NCk5FVyAobWF5YmUpOjxi cj4NCiZuYnNwOyBjb2RlX3ZlcmlmaWVyID0gaGlnaCBlbnRyb3B5IGNyeXB0b2dyYXBoaWNhbGx5 IHN0cm9uZyByYW5kb20gU1RSSU5HPGJyPg0KJm5ic3A7IHVzaW5nIHRoZSB1cmwgYW5kIGZpbGVu YW1lIHNhZmUgQWxwaGFiZXQgW0EtWl0gLyBbYS16XTxicj4NCiZuYnNwOyZuYnNwOyAvIFswLTld IC8gJnF1b3Q7LSZxdW90OyAvICZxdW90O18mcXVvdDsgZnJvbSBTZWMgNSBvZiBSRkMgNDY0OCBb UkZDNDY0OF0sIHdpdGggbGVuZ3RoPGJyPg0KJm5ic3A7Jm5ic3A7IGxlc3MgdGhhbiAxMjggY2hh cmFjdGVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSW4gNC4yLjogPGJyPg0KPGJy Pg0KT0xEOjxicj4NCiZuYnNwOyZuYnNwOyBTMjU2Jm5ic3A7ICZxdW90O2NvZGVfY2hhbGxlbmdl JnF1b3Q7ID0gQkFTRTY0VVJMKFNIQTI1NigmcXVvdDtjb2RlX3ZlcmlmaWVyJnF1b3Q7KSk8YnI+ DQo8YnI+DQpORVcgKG1heWJlKTo8YnI+DQombmJzcDsmbmJzcDsgUzI1NiZuYnNwOyAmcXVvdDtj b2RlX2NoYWxsZW5nZSZxdW90OyA9IEJBU0U2NFVSTChTSEEyNTYoQVNDSUkoJnF1b3Q7Y29kZV92 ZXJpZmllciZxdW90OykpKTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JbiA0 LjYuOiA8YnI+DQo8YnI+DQpPTEQ6PGJyPg0KJm5ic3A7Jm5ic3A7IFNIQTI1NigmcXVvdDtjb2Rl X3ZlcmlmaWVyJnF1b3Q7ICkgPT0gQkFTRTY0VVJMLURFQ09ERSgmcXVvdDtjb2RlX2NoYWxsZW5n ZSZxdW90OykuPGJyPg0KPGJyPg0KTkVXIChtYXliZSk6PGJyPg0KJm5ic3A7Jm5ic3A7IFNIQTI1 NihBU0NJSSgmcXVvdDtjb2RlX3ZlcmlmaWVyJnF1b3Q7KSkgPT0gQkFTRTY0VVJMLURFQ09ERSgm cXVvdDtjb2RlX2NoYWxsZW5nZSZxdW90OykuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDI5LCAyMDE1IGF0IDg6MzcgUE0sIE5hdCBTYWtp bXVyYSAoPW5hdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpuYXRAc2FraW11cmEub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bmF0QHNha2ltdXJhLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SSB0YWtlIHlv dXIgcG9pbnQsIEJyaWFuLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3VyIG1vc3QgcmVjZW50IG1hbnVzY3JpcHQs IFNUUklORyBpcyBkZWZpbmVkIGluc2lkZSBBU0NJSShTVFJJTkcpIGFzJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+U1RSSU5HIGlzIGEgc2VxdWVuY2Ugb2YgemVybyBvciBtb3JlIEFTQ0lJIGNoYXJhY3Rl cnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWYiPmJ1dCBpdCBpcyBraW5kIG9mIGNpcmN1bGFyLCBhbmQgd2UgZG8gbm90IHNlZW0gdG8g dXNlIEFTQ0lJKCkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5XaGF0IGFib3V0IHJlLXdyaXRpbmcgdGhlIHNlY3Rpb24g bGlrZSBiZWxvdz8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tcmlnaHQ6MjQuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjI0 LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlNUUklORyBkZW5vdGVzIGEgc2VxdWVuY2Ugb2YgemVy byBvciBtb3JlIEFTQ0lJICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly94bWwycmZjLmlldGYub3JnL2Nn aS1iaW4veG1sMnJmYy5jZ2kjUkZDMDAyMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0 ZXh0LWRlY29yYXRpb246bm9uZSI+W1JGQzAwMjBdPC9zcGFuPjwvYT4mbmJzcDtjaGFyYWN0ZXJz LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6MjQuMHB0O21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjI0LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPk9D VEVUUyBkZW5vdGVzIGEgc2VxdWVuY2Ugb2YgemVybyBvciBtb3JlIG9jdGV0cy4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0LjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5CQVNFNjRVUkwoT0NU RVRTKSBkZW5vdGVzIHRoZSBiYXNlNjR1cmwgZW5jb2Rpbmcgb2YgT0NURVRTLCBwZXImbmJzcDs8 YSBocmVmPSJodHRwOi8veG1sMnJmYy5pZXRmLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1Rlcm1p bm9sb2d5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l Ij5TZWN0aW9uIDM8L3NwYW4+PC9hPiZuYnNwO3Byb2R1Y2luZw0KIGEgQVNDSUk8YSBocmVmPSJo dHRwOi8veG1sMnJmYy5pZXRmLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1JGQzAwMjAiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPltSRkMwMDIwXTwv c3Bhbj48L2E+Jm5ic3A7U1RSSU5HLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6MjQu MHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjI0LjBwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWYiPkJBU0U2NFVSTC1ERUNPREUoU1RSSU5HKSBkZW5vdGVzIHRoZSBiYXNlNjR1 cmwgZGVjb2Rpbmcgb2YgU1RSSU5HLCBwZXImbmJzcDs8YSBocmVmPSJodHRwOi8veG1sMnJmYy5p ZXRmLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpI1Rlcm1pbm9sb2d5IiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj5TZWN0aW9uDQogMzwvc3Bhbj48L2E+ LCBwcm9kdWNpbmcgYSBzZXF1ZW5jZSBvZiBvY3RldHMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1yaWdodDoyNC4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MjQu MHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+U0hBMjU2KE9DVEVUUykgZGVub3RlcyBhIFNIQTIgMjU2 Yml0IGhhc2gmbmJzcDs8YSBocmVmPSJodHRwOi8veG1sMnJmYy5pZXRmLm9yZy9jZ2ktYmluL3ht bDJyZmMuY2dpI1JGQzYyMzQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmUiPltSRkM2MjM0XTwvc3Bhbj48L2E+Jm5ic3A7b2YgT0NURVRTLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6MjQuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjI0LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiAzMCwgMjAxNSwgYXQgMDg6MTUsIEJyaWFuIENh bXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRh cmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SW4gwqcyIFsxXSB3 ZSd2ZSBnb3QgJnF1b3Q7U0hBMjU2KFNUUklORykgZGVub3RlcyBhIFNIQTIgMjU2Yml0IGhhc2gg W1JGQzYyMzRdIG9mIFNUUklORy4mcXVvdDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJ1dCwgaW4gdGhl IGxpdHRsZSBjb3cgdG93biB3aGVyZSBJIGNvbWUgZnJvbSBhbnl3YXksIHlvdSBoYXNoIGJpdHMv b2N0ZXRzIG5vdCBjaGFyYWN0ZXIgc3RyaW5ncyAoQlRXLCAmcXVvdDtTVFJJTkcmcXVvdDsgaXNu J3QgZGVmaW5lZCBhbnl3aGVyZSBidXQgaXQncyBraW5kIG9mIGltcGxpZWQgdGhhdCBpdCdzIGEg c3RyaW5nIG9mIGNoYXJhY3RlcnMpLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U2hvdWxkIGl0 IHNheSBzb21ldGhpbmcgbW9yZSBsaWtlICZxdW90O1NIQTI1NihTVFJJTkcpIGRlbm90ZXMgYSBT SEEyIDI1NmJpdCBoYXNoIFtSRkM2MjM0XSBvZiB0aGUgb2N0ZXRzIG9mIHRoZSBBU0NJSSBbUkZD MDAyMF0gcmVwcmVzZW50YXRpb24gb2YgU1RSSU5HLiZxdW90Oz8NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pkkga25vdyBpdCdzIGtpbmQgb2YgcGVkYW50aWMgYnV0IEkgZmluZCBpdCBraW5kIG9mIGNvbmZ1 c2luZyBiZWNhdXNlIHRoZSBjb2RlX3ZlcmlmaWVyIHVzZXMgdGhlIHVybCBhbmQgZmlsZW5hbWUg c2FmZSBhbHBoYWJldCwgd2hpY2ggaGFzIG1lIHNlY29uZCBndWVzc2luZyBpZiBTSEEyNTYoU1RS SU5HKSBhY3R1YWxseSBtZWFucyBhIGhhc2ggb2YgdGhlIG9jdGV0DQogcHJvZHVjZWQgYnkgYmFz ZTY0dXJsIGRlY29kaW5nIHRoZSBzdHJpbmcuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUgaXQncyBqdXN0IG1lIGJ1dCwgd2hlbiByZWFk aW5nIHRoZSB0ZXh0LCBJIGZpbmQgdGhlIHRyYW5zZm9ybSBwcm9jZXNzIHRvIGJlIG11Y2ggbW9y ZSBjb25mdXNpbmcgdGhhbiBJIHRoaW5rIGl0IG5lZWRzIHRvIGJlLiBSZW1vdmluZyBhbmQgY2xh cmlmeWluZyBzb21lIHRoaW5ncyB3aWxsIGhlbHAuIEkgaGF0ZSB0byBzdWdnZXN0IHRoaXMgYnV0 IG1heWJlIGFuIGV4YW1wbGUgc2hvd2luZyB0aGUgY29tcHV0YXRpb24NCiBzdGVwcyBvbiBib3Ro IGVuZHMgd291bGQgYmUgaGVscGZ1bD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbHNvICZxdW90O1VURjgoU1RSSU5HKSZxdW90OyBhbmQgJnF1b3Q7QVND SUkoU1RSSU5HKSZxdW90OyBub3RhdGlvbnMgYXJlIGRlZmluZWQgaW4gwqcyIGJ1dCBub3QgdXNl ZCBhbnl3aGVyZS48YnI+DQo8YnI+DQpBbmQgwqcyIGFsc28gc2F5cywgJnF1b3Q7QkFTRTY0VVJM LURFQ09ERShTVFJJTkcpIGRlbm90ZXMgdGhlIGJhc2U2NHVybCBkZWNvZGluZyBvZiBTVFJJTkcs IHBlciBTZWN0aW9uIDMsIHByb2R1Y2luZyBhIFVURi04IHNlcXVlbmNlIG9mIG9jdGV0cy4mcXVv dDsgQnV0IHdoYXQgaXMgYSBVVEYtOCBzZXF1ZW5jZSBvZiBvY3RldHM/IElzbid0IGl0IGp1c3Qg YSBzZXF1ZW5jZSBvY3RldHM/IFRoZSBbUkZDMzYyOV0gcmVmZXJlbmNlLCBJIHRoaW5rLCBjb3Vs ZCBiZSByZW1vdmVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5bMV0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtc3BvcC0wNiNzZWN0aW9uLTIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNwb3AtMDYjc2VjdGlvbi0yPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5OYXQgU2FraW11 cmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGEgaHJlZj0ibWFpbHRvOm5hdEBzYWtp bXVyYS5vcmciIHRhcmdldD0iX2JsYW5rIj5uYXRAc2FraW11cmEub3JnPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQu c2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwv YT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B1680429673943A2201928TK5EX14MBXC291r_-- From nobody Fri Jan 30 12:16:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349451A3B9D for ; Fri, 30 Jan 2015 12:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABLs903F6W43 for ; Fri, 30 Jan 2015 12:16:15 -0800 (PST) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D0B1A1EEF for ; Fri, 30 Jan 2015 12:16:13 -0800 (PST) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKVMvmjbTS6/PYoZiiCYo29Jbd2lSUXXpg@postini.com; Fri, 30 Jan 2015 12:16:13 PST Received: by mail-ie0-f177.google.com with SMTP id vy18so5900451iec.8 for ; Fri, 30 Jan 2015 12:16:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p6obOiPy6xFbMrjtorrsS33C1QmgQYIWZh1nigz0Aog=; b=J2PjPG6WEGSSCcpOnpfy7Eut8a2rtgiRR64v37M4jujlsf+JZ6eqTm5ArTg4V38X/I 7wmG7PHmbwGR2Oz3zH/XtG4Hz/YKgoL/o/SK1ekLlnnnXiuzga2SMsWjMUW9N04nBx1Q FBxcLec6Oknl793a7rTVwx5BT3cQvzm2d107U40IaA1b/cjhghUzwH6HRO0yeoGVjhvB 3utASmF5lloF6HM6yQ177nI4iWdzGg7TrZb1/z3sDDDRUqpws5/vKrDUsX7QtO2ZlUze 20fGcSPBu81H3y0KyBTdd65FoZT2vtMT4nI/p0EZqYT1MS4mD93I2LnupU6/JB25auX7 8GIA== X-Gm-Message-State: ALoCoQkihzhnIM533eczHp5SILRIM5TzbtEvvKz0oReYK2IBlHCdXbH+vUibyzd6kcSgPevzWl06mo4iNfRTWD9NxSEKdgdS8NOATFCLiHwUgmBDwkwNP518wjUyhyM/fRmZh7tU3kJd X-Received: by 10.42.200.82 with SMTP id ev18mr8062565icb.44.1422648972878; Fri, 30 Jan 2015 12:16:12 -0800 (PST) X-Received: by 10.42.200.82 with SMTP id ev18mr8062546icb.44.1422648972728; Fri, 30 Jan 2015 12:16:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Fri, 30 Jan 2015 12:15:42 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 30 Jan 2015 13:15:42 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf30223d83a8f18d050de44685 Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 20:16:19 -0000 --20cf30223d83a8f18d050de44685 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Mike here. Though PKCE only needs the ASCII(STRING) one. On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones wrote: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-= 1.1 > uses this notation: > > > > UTF8(STRING) denotes the octets of the UTF-8 [RFC3629 > ] representation > > of STRING, where STRING is a sequence of zero or more Unicode > > [UNICODE > ] > characters. > > > > ASCII(STRING) denotes the octets of the ASCII [RFC20 > ] representation > > of STRING, where STRING is a sequence of zero or more ASCII > > characters. > > > > This is unambiguous and has already been vetted by the IESG and SecDir, s= o > I would use exactly this wording. > > > > OCTETS(STRING) is ambiguous, since for the same string there are many > possible representations as octets, including ASCII, UTF-8, UTF-16, UTF-3= 2, > and EBCDIC. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Friday, January 30, 2015 11:33 AM > *To:* Brian Campbell > *Cc:* oauth; Naveen Agarwal > *Subject:* Re: [OAUTH-WG] PKCE: SHA256(WAT?) > > > > Have a look at the latest version I added OCTETS(STRING) to show the > conversion. ASCII(STRING) seemed more confusing by drawing character > encoding back in. > > > > I was tempted to call it a octet array without the terminating NULL of > STRING but didn=E2=80=99t want to introduce array. > > > > Let me know what you think. > > > > On Jan 30, 2015, at 1:56 PM, Brian Campbell > wrote: > > > > But, while it may be clear to you, what I'm saying here is that it's not > clear to a reader/implementer. > > Somehow the conversion from a character string to an octet string needs t= o > be clearly and unambiguously stated. It doesn't have to be the text I > suggested but it's not sufficient as it is now. > > Something like this might work, if you don't want to touch the parts in > 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the > octets of the ASCII [RFC0020] representation of STRING." > > An "octet sequence using the url and filename safe Alphabet [...], with > length less than 128 characters." is ambiguous. Octets and characters are > intermixed with no mention of encoding. But they're not interchangeable. > > > > > > On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura wrote: > > I do not think we need ASCII(). It is quite clear without it, I suppose. > > > > In 4.1, I would rather do like: > > > > code_verifier =3D high entropy cryptographic random > octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > > > Nat > > > > 2015-01-30 22:51 GMT+09:00 Brian Campbell : > > That's definitely an improvement (to me anyway). > > Checking that the rest of the document uses those notations appropriately= , > I think, yields a few other changes. And probably begs for the > "ASCII(STRING) denotes the octets of the ASCII representation of STRING" > notation/function, or something like it, to be put back in. Those changes > might look like the following: > > In 4.1.: > > OLD: > code_verifier =3D high entropy cryptographic random ASCII [RFC0020] > octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > NEW (maybe): > code_verifier =3D high entropy cryptographically strong random STRING > using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > > In 4.2.: > > OLD: > S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) > > NEW (maybe): > S256 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier"))) > > In 4.6.: > > OLD: > SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). > > NEW (maybe): > SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challenge= "). > > > > > > On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) > wrote: > > I take your point, Brian. > > > > In our most recent manuscript, STRING is defined inside ASCII(STRING) as > > > > STRING is a sequence of zero or more ASCII characters > > > > but it is kind of circular, and we do not seem to use ASCII(). > > > > What about re-writing the section like below? > > > > STRING denotes a sequence of zero or more ASCII [RFC0020] > characters. > > OCTETS denotes a sequence of zero or more octets. > > BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 3 > producing a > ASCII[RFC0020] > STRING. > > BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Se= ction > 3 , producing a > sequence of octets. > > SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] > of OCTETS. > > > > > > > > > > > > On Jan 30, 2015, at 08:15, Brian Campbell > wrote: > > > > In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6= 234] > of STRING." > > But, in the little cow town where I come from anyway, you hash bits/octet= s > not character strings (BTW, "STRING" isn't defined anywhere but it's kind > of implied that it's a string of characters). > > Should it say something more like "SHA256(STRING) denotes a SHA2 256bit > hash [RFC6234] of the octets of the ASCII [RFC0020] representation of > STRING."? > > I know it's kind of pedantic but I find it kind of confusing because the > code_verifier uses the url and filename safe alphabet, which has me secon= d > guessing if SHA256(STRING) actually means a hash of the octet produced by > base64url decoding the string. > > Maybe it's just me but, when reading the text, I find the transform > process to be much more confusing than I think it needs to be. Removing a= nd > clarifying some things will help. I hate to suggest this but maybe an > example showing the computation steps on both ends would be helpful? > > > > Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72 = but > not used anywhere. > > And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url de= coding > of STRING, per Section 3, producing a UTF-8 sequence of octets." But what > is a UTF-8 sequence of octets? Isn't it just a sequence octets? The > [RFC3629] reference, I think, could be removed. > > > > [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 > > > > Nat Sakimura > > nat@sakimura.org > > > > > > > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > --20cf30223d83a8f18d050de44685 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Mike here. Though PKCE only needs the ASCII(S= TRING) one.

On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

http:= //tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-1.1 uses this notation:

=C2=A0

=C2=A0=C2=A0 UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation

=C2=A0=C2=A0 of STRING, where STRING is a sequence of zero or m= ore Unicode

=C2=A0=C2=A0 [UNICODE] characters.

=C2=A0

=C2=A0=C2=A0 ASCII(STRING) denotes the octets of the ASCII [RFC20] representation

=C2=A0=C2=A0 of STRING, where STRING is a sequence of zero or m= ore ASCII

=C2=A0=C2=A0 characters.

=C2=A0

This is unambiguous and has already b= een vetted by the IESG and SecDir, so I would use exactly this wording.<= /u>

=C2=A0

OCTETS(STRING) is ambiguous, since fo= r the same string there are many possible representations as octets, includ= ing ASCII, UTF-8, UTF-16, UTF-32, and EBCDIC.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Friday, January 30, 2015 11:33 AM
To: Brian Campbell
Cc: oauth; Naveen Agarwal
Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?)

=C2=A0

Have a look at the latest version I added OCTETS(STR= ING) to show the conversion. =C2=A0 ASCII(STRING) seemed more confusing by = drawing character encoding back in.

=C2=A0

I was tempted to call it a octet array without the t= erminating NULL of STRING but didn=E2=80=99t want to introduce array.

=C2=A0

Let me know what you think.

=C2=A0

On Jan 30, 2015, at 1:56 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:

=C2=A0

But, while it may be clear to you, what I'm sayi= ng here is that it's not clear to a reader/implementer.

Somehow the conversion from a character string to an octet string needs to = be clearly and unambiguously stated. It doesn't have to be the text I s= uggested but it's not sufficient as it is now.

Something like this might work, if you don't want to touch the parts in= 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of = the octets of the ASCII [RFC0020] representation of STRING."

An "octet sequence using the url and filename safe Alphabet [...], wit= h length less than 128 characters." is ambiguous. Octets and character= s are intermixed with no mention of encoding. But they're not interchan= geable.

=C2=A0

=C2=A0

On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura <sakimura@gmail.com> wrote:

I do not think we need ASCII(). It is quite clear wi= thout it, I suppose.=C2=A0

=C2=A0

In 4.1, I would rather do like:=C2=A0<= /p>

=C2=A0

=C2=A0code_verifier =3D high entropy cryptographic r= andom=C2=A0
=C2=A0=C2=A0 octet sequence using the url and filename safe Alphabet [A-Z] = / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.

=C2=A0

Nat

=C2=A0

2015-01-30 22:51 GMT+09:00 Brian Campbell <bcampbell@pingide= ntity.com>:

That's definitely= an improvement (to me anyway).

Checking that the res= t of the document uses those notations appropriately, I think, yields a few= other changes. And probably begs for the "ASCII(STRING) denotes the o= ctets of the ASCII representation of STRING" notation/function, or something like it, to be put back in. Those changes = might look like the following:

In 4.1.:

OLD:
=C2=A0=C2=A0 code_verifier =3D high entropy cryptographic random ASCII [RFC= 0020]
=C2=A0=C2=A0 octet sequence using the url and filename safe Alphabet [A-Z] = / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.

NEW (maybe):
=C2=A0 code_verifier =3D high entropy cryptographically strong random STRIN= G
=C2=A0 using the url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.


In 4.2.:

OLD:
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(&qu= ot;code_verifier"))

NEW (maybe):
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(ASC= II("code_verifier")))

In 4.6.:

OLD:
=C2=A0=C2=A0 SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE(&qu= ot;code_challenge").

NEW (maybe):
=C2=A0=C2=A0 SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECO= DE("code_challenge").

=C2=A0

=C2=A0

On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dna= t) <nat@sakimura.o= rg> wrote:

I take your point, Brian.=C2=A0

=C2=A0

In our most recent manuscript, STRING is defined ins= ide ASCII(STRING) as=C2=A0

=C2=A0

STRING is a sequence of zero or more ASCII characte= rs

=C2=A0

but it is kind of circular, and we do not seem to use ASCII().=C2=A0=

=C2=A0

What about re-writing the section like below?=C2=A0=

=C2=A0

STRING denotes a sequence of zero or more ASCII =C2=A0[RFC0020]=C2=A0characters.=C2=A0

OCTETS denotes a sequence of zero or more octets.=C2=A0

BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per=C2=A0Section 3=C2=A0produc= ing a ASCII[RFC0020]=C2= =A0STRING.

BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per=C2= =A0Section 3, producing a sequence of octets.

SHA256(OCTETS) denotes a SHA2 256bit hash=C2=A0[RFC6234]=C2=A0of OCTETS.<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Jan 30, 2015, at 08:15, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

=C2=A0

In =C2=A72 [1] we'= ;ve got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING= ."

But, in the little co= w town where I come from anyway, you hash bits/octets not character strings= (BTW, "STRING" isn't defined anywhere but it's kind of i= mplied that it's a string of characters).=C2=A0

Should it say somethi= ng more like "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of t= he octets of the ASCII [RFC0020] representation of STRING."?

I know it's kind = of pedantic but I find it kind of confusing because the code_verifier uses = the url and filename safe alphabet, which has me second guessing if SHA256(= STRING) actually means a hash of the octet produced by base64url decoding the string.

Maybe it's just me but, when reading the text, I= find the transform process to be much more confusing than I think it needs= to be. Removing and clarifying some things will help. I hate to suggest th= is but maybe an example showing the computation steps on both ends would be helpful?

=C2=A0

Also "UTF8(STRING)" and "ASCII(STRING= )" notations are defined in =C2=A72 but not used anywhere.

And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url= decoding of STRING, per Section 3, producing a UTF-8 sequence of octets.&q= uot; But what is a UTF-8 sequence of octets? Isn't it just a sequence o= ctets? The [RFC3629] reference, I think, could be removed.

=C2=A0

Nat Sakimura=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0



=C2=A0

--

Nat Sakimura (=3Dnat)<= u>

Chairman, OpenID Found= ation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

=C2=A0


--20cf30223d83a8f18d050de44685-- From nobody Fri Jan 30 12:47:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E3E1A8706 for ; Fri, 30 Jan 2015 12:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6TtdW2dPa8l for ; Fri, 30 Jan 2015 12:47:44 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1B31A7007 for ; Fri, 30 Jan 2015 12:47:43 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id b13so22466643qcw.0 for ; Fri, 30 Jan 2015 12:47:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=jDMYPqttB94FYOkHRLgnJf5PjlPm92SvayyeP4o6Qdc=; b=BGHApfsRbZw9rv2Ba3lXHgpCZaxVRto9UyH5g6lab3kwOiZAX5501XiyDqi892TBJR lbkPuuIMsgstLCHZxoTw3cJKaM7DalK75uWG+6E6yIZ/hWwsnURTXND1cOFYRlmBWRoe c4ZgQujNp0g9PgQJfDzufGM7XhjqjEKSwKvkk/U+/EmX3cFCoTgDsA5S0bsLv85Cz9Pl wC05RnUX5fYXY9rvAnZoFzrY0injsOis6VRBSDeSYMSr9kcpy1YBvuK921vfjKGrHVd8 V/dWP+DjaL1Dmdw+b9timpSdgXBqIvpa0M1+p6ZEIdvHzbCcttO14HGL7MQjozhHMjV7 5RCQ== X-Gm-Message-State: ALoCoQnBItHTTtZCtiXGWVLErvBBAyqp9VDi+1Ncn+GZD/rL6KGczBpfZoZ+cwv+6WbdR4zCCmFB X-Received: by 10.140.34.177 with SMTP id l46mr15743469qgl.37.1422650862715; Fri, 30 Jan 2015 12:47:42 -0800 (PST) Received: from [192.168.1.36] (186-79-118-57.baf.movistar.cl. [186.79.118.57]) by mx.google.com with ESMTPSA id u16sm11099714qau.44.2015.01.30.12.47.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 12:47:41 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_04B26C63-8B90-4E70-818B-65C41A84E767"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Fri, 30 Jan 2015 17:47:36 -0300 Message-Id: <513A0CDA-514E-4ACD-AE78-574149288F01@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> To: Brian Campbell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 20:47:48 -0000 --Apple-Mail=_04B26C63-8B90-4E70-818B-65C41A84E767 Content-Type: multipart/alternative; boundary="Apple-Mail=_3A20E278-6924-474C-AF6C-484239AA9421" --Apple-Mail=_3A20E278-6924-474C-AF6C-484239AA9421 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK try that one. > On Jan 30, 2015, at 5:15 PM, Brian Campbell = wrote: >=20 > I agree with Mike here. Though PKCE only needs the ASCII(STRING) one. >=20 > On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones = > = wrote: > = http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-1= .1 = uses this notation: >=20 > =20 >=20 > UTF8(STRING) denotes the octets of the UTF-8 [RFC3629 = ] representation >=20 > of STRING, where STRING is a sequence of zero or more Unicode >=20 > [UNICODE = ] characters. >=20 > =20 >=20 > ASCII(STRING) denotes the octets of the ASCII [RFC20 = ] representation >=20 > of STRING, where STRING is a sequence of zero or more ASCII >=20 > characters. >=20 > =20 >=20 > This is unambiguous and has already been vetted by the IESG and = SecDir, so I would use exactly this wording. >=20 > =20 >=20 > OCTETS(STRING) is ambiguous, since for the same string there are many = possible representations as octets, including ASCII, UTF-8, UTF-16, = UTF-32, and EBCDIC. >=20 > =20 >=20 > -- = Mike >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of John Bradley > Sent: Friday, January 30, 2015 11:33 AM > To: Brian Campbell > Cc: oauth; Naveen Agarwal > Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) >=20 > =20 >=20 > Have a look at the latest version I added OCTETS(STRING) to show the = conversion. ASCII(STRING) seemed more confusing by drawing character = encoding back in. >=20 > =20 >=20 > I was tempted to call it a octet array without the terminating NULL of = STRING but didn=E2=80=99t want to introduce array. >=20 > =20 >=20 > Let me know what you think. >=20 > =20 >=20 > On Jan 30, 2015, at 1:56 PM, Brian Campbell = > wrote: >=20 > =20 >=20 > But, while it may be clear to you, what I'm saying here is that it's = not clear to a reader/implementer. >=20 > Somehow the conversion from a character string to an octet string = needs to be clearly and unambiguously stated. It doesn't have to be the = text I suggested but it's not sufficient as it is now. >=20 > Something like this might work, if you don't want to touch the parts = in 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of = the octets of the ASCII [RFC0020] representation of STRING." >=20 > An "octet sequence using the url and filename safe Alphabet [...], = with length less than 128 characters." is ambiguous. Octets and = characters are intermixed with no mention of encoding. But they're not = interchangeable. >=20 > =20 >=20 > =20 >=20 > On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura > wrote: >=20 > I do not think we need ASCII(). It is quite clear without it, I = suppose.=20 >=20 > =20 >=20 > In 4.1, I would rather do like:=20 >=20 > =20 >=20 > code_verifier =3D high entropy cryptographic random=20 > octet sequence using the url and filename safe Alphabet [A-Z] / = [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. >=20 > =20 >=20 > Nat >=20 > =20 >=20 > 2015-01-30 22:51 GMT+09:00 Brian Campbell >: >=20 > That's definitely an improvement (to me anyway). >=20 > Checking that the rest of the document uses those notations = appropriately, I think, yields a few other changes. And probably begs = for the "ASCII(STRING) denotes the octets of the ASCII representation of = STRING" notation/function, or something like it, to be put back in. = Those changes might look like the following: >=20 >=20 > In 4.1.:=20 >=20 > OLD: > code_verifier =3D high entropy cryptographic random ASCII [RFC0020] > octet sequence using the url and filename safe Alphabet [A-Z] / = [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. >=20 > NEW (maybe): > code_verifier =3D high entropy cryptographically strong random = STRING > using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. >=20 >=20 > In 4.2.:=20 >=20 > OLD: > S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) >=20 > NEW (maybe): > S256 "code_challenge" =3D = BASE64URL(SHA256(ASCII("code_verifier"))) >=20 >=20 > In 4.6.:=20 >=20 > OLD: > SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). >=20 > NEW (maybe): > SHA256(ASCII("code_verifier")) =3D=3D = BASE64URL-DECODE("code_challenge"). >=20 >=20 > =20 >=20 > =20 >=20 > On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) = > wrote: >=20 > I take your point, Brian.=20 >=20 > =20 >=20 > In our most recent manuscript, STRING is defined inside ASCII(STRING) = as=20 >=20 > =20 >=20 > STRING is a sequence of zero or more ASCII characters >=20 > =20 >=20 > but it is kind of circular, and we do not seem to use ASCII().=20 >=20 > =20 >=20 > What about re-writing the section like below?=20 >=20 > =20 >=20 > STRING denotes a sequence of zero or more ASCII [RFC0020] = characters.=20 >=20 > OCTETS denotes a sequence of zero or more octets.=20 >=20 > BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per = Section 3 = producing a ASCII[RFC0020] = STRING. >=20 > BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per = Section 3 , = producing a sequence of octets. >=20 > SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] = of OCTETS. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Jan 30, 2015, at 08:15, Brian Campbell > wrote: >=20 > =20 >=20 > In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash = [RFC6234] of STRING." >=20 > But, in the little cow town where I come from anyway, you hash = bits/octets not character strings (BTW, "STRING" isn't defined anywhere = but it's kind of implied that it's a string of characters).=20 >=20 > Should it say something more like "SHA256(STRING) denotes a SHA2 = 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] = representation of STRING."? >=20 > I know it's kind of pedantic but I find it kind of confusing because = the code_verifier uses the url and filename safe alphabet, which has me = second guessing if SHA256(STRING) actually means a hash of the octet = produced by base64url decoding the string. >=20 > Maybe it's just me but, when reading the text, I find the transform = process to be much more confusing than I think it needs to be. Removing = and clarifying some things will help. I hate to suggest this but maybe = an example showing the computation steps on both ends would be helpful? >=20 > =20 >=20 > Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72= but not used anywhere. >=20 > And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url = decoding of STRING, per Section 3, producing a UTF-8 sequence of = octets." But what is a UTF-8 sequence of octets? Isn't it just a = sequence octets? The [RFC3629] reference, I think, could be removed. >=20 > =20 >=20 > [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 = > =20 >=20 > Nat Sakimura >=20 > nat@sakimura.org > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 > =20 >=20 > -- >=20 > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > =20 >=20 > =20 >=20 >=20 --Apple-Mail=_3A20E278-6924-474C-AF6C-484239AA9421 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK try that one.

On Jan 30, 2015, at 5:15 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

I agree with Mike here. Though PKCE only needs the = ASCII(STRING) one.

On Fri, Jan 30, 2015 at 12:38 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-4= 1#section-1.1 uses this notation:

 

   UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation

   of STRING, where STRING is a = sequence of zero or more Unicode

   [UNICODE] characters.

 

   ASCII(STRING) denotes the octets of = the ASCII [RFC20] representation

   of STRING, where STRING is a sequence of zero or = more ASCII

   characters.

 

This is unambiguous and has already been vetted by = the IESG and SecDir, so I would use exactly this wording.

 

OCTETS(STRING) is ambiguous, since for the same = string there are many possible representations as octets, including = ASCII, UTF-8, UTF-16, UTF-32, and EBCDIC.

 

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

 

=

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Friday, January 30, 2015 11:33 AM
To: Brian Campbell
Cc: oauth; Naveen Agarwal
Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?)

 

Have a = look at the latest version I added OCTETS(STRING) to show the = conversion.   ASCII(STRING) seemed more confusing by drawing = character encoding back in.

 

I was tempted to call it a octet = array without the terminating NULL of STRING but didn=E2=80=99t want to = introduce array.

 

Let me know what you think.

 

On Jan 30, 2015, at 1:56 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

 

But, while it may be clear to = you, what I'm saying here is that it's not clear to a = reader/implementer.

Somehow the conversion from a character string to an octet string needs = to be clearly and unambiguously stated. It doesn't have to be the text I = suggested but it's not sufficient as it is now.

Something like this might work, if you don't want to touch the parts in = 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the = octets of the ASCII [RFC0020] representation of STRING."

An "octet sequence using the url and filename safe Alphabet [...], with = length less than 128 characters." is ambiguous. Octets and characters = are intermixed with no mention of encoding. But they're not = interchangeable.

 

 

On Fri, Jan 30, 2015 at 7:15 AM, = Nat Sakimura <sakimura@gmail.com> wrote:

I do not think we need ASCII(). = It is quite clear without it, I suppose. 

 

In 4.1, I would rather do = like: 

 

 code_verifier =3D high = entropy cryptographic random 
   octet sequence using the url and filename safe Alphabet = [A-Z] / [a-z]
   / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with = length
   less than 128 characters.

 

Nat

 

2015-01-30 22:51 GMT+09:00 Brian = Campbell <bcampbell@pingidentity.com>:

That's definitely an improvement (to me = anyway).

Checking that the rest of the document = uses those notations appropriately, I think, yields a few other changes. = And probably begs for the "ASCII(STRING) denotes the octets of the ASCII = representation of STRING" notation/function, or something like it, to be put back in. Those = changes might look like the following:

In = 4.1.:

OLD:
   code_verifier =3D high entropy cryptographic random ASCII = [RFC0020]
   octet sequence using the url and filename safe Alphabet = [A-Z] / [a-z]
   / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with = length
   less than 128 characters.

NEW (maybe):
  code_verifier =3D high entropy cryptographically strong random = STRING
  using the url and filename safe Alphabet [A-Z] / [a-z]
   / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with = length
   less than 128 characters.


In 4.2.:

OLD:
   S256  "code_challenge" =3D = BASE64URL(SHA256("code_verifier"))

NEW (maybe):
   S256  "code_challenge" =3D = BASE64URL(SHA256(ASCII("code_verifier")))

In = 4.6.:

OLD:
   SHA256("code_verifier" ) =3D=3D = BASE64URL-DECODE("code_challenge").

NEW (maybe):
   SHA256(ASCII("code_verifier")) =3D=3D = BASE64URL-DECODE("code_challenge").

 

 

On Thu, Jan 29, 2015 at 8:37 PM, = Nat Sakimura (=3Dnat) <nat@sakimura.org> wrote:

I take = your point, Brian. 

 

In our most recent manuscript, = STRING is defined inside ASCII(STRING) as 

 

STRING is a sequence of zero or more ASCII = characters

 

but it = is kind of circular, and we do not seem to use ASCII(). 

 

What = about re-writing the section like below? 

 

STRING denotes a sequence of zero or more ASCII  [RFC0020] characters. 

OCTETS denotes a sequence of zero or more octets. 

BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, = per Section 3 producing a ASCII[RFC0020] STRING.

BASE64URL-DECODE(STRING) denotes the base64url decoding of = STRING, per Section 3, producing a sequence of octets.

SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] of OCTETS.

 

 

 

 

 

On Jan 30, 2015, at 08:15, Brian = Campbell <bcampbell@pingidentity.com> wrote:

 

In = =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash = [RFC6234] of STRING."

But, in the = little cow town where I come from anyway, you hash bits/octets not = character strings (BTW, "STRING" isn't defined anywhere but it's kind of = implied that it's a string of characters). 

Should it = say something more like "SHA256(STRING) denotes a SHA2 256bit hash = [RFC6234] of the octets of the ASCII [RFC0020] representation of = STRING."?

I know it's = kind of pedantic but I find it kind of confusing because the = code_verifier uses the url and filename safe alphabet, which has me = second guessing if SHA256(STRING) actually means a hash of the octet produced by base64url decoding the string.

Maybe it's just me but, when = reading the text, I find the transform process to be much more confusing = than I think it needs to be. Removing and clarifying some things will = help. I hate to suggest this but maybe an example showing the = computation steps on both ends would be helpful?

 

Also "UTF8(STRING)" and "ASCII(STRING)" = notations are defined in =C2=A72 but not used anywhere.

And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url = decoding of STRING, per Section 3, producing a UTF-8 sequence of = octets." But what is a UTF-8 sequence of octets? Isn't it just a = sequence octets? The [RFC3629] reference, I think, could be removed.

 

[1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2

 

Nat Sakimura

nat@sakimura.org

 

 

 

 

 



 

-- =

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 

 



= --Apple-Mail=_3A20E278-6924-474C-AF6C-484239AA9421-- --Apple-Mail=_04B26C63-8B90-4E70-818B-65C41A84E767 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMzAyMDQ3MzdaMCMGCSqGSIb3DQEJBDEWBBRkMI9zIG0Se6djexcRalV/ 8BOp8TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAbCAPOUwe2e1jimiLIagSkufc2z5G9YZm2bJXpeg7obxsmoh01wSuV JtO6Tej2OqBvlUEvrVSCKM1m2leMGOKH2mJyoRGr0PbqlxQO0S/8cu+YMNeiZDUmr7Jc3fIqAwTy 3i5IQLxk1ZbHNhtppuH+uV6zvX5qRFtmOTgqD1Iq3YBLoDBiTh1JB+Uf6G1RyiNsWPUauJ2sJE86 tOLPfZ3exRxqIRviGHeBudlxeSDCAk7vx4vcgNAKFw0P90hh4jGaOITXkEGaphoJRM0IIEsuY9K/ enqEdqZY0JG16x/qcoU8VG2We9jCmQ0+tnIiBALrDAlyA350R3tpXD+I+pBuAAAAAAAA --Apple-Mail=_04B26C63-8B90-4E70-818B-65C41A84E767-- From nobody Fri Jan 30 13:07:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4251A872B for ; Fri, 30 Jan 2015 13:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09ErQaPHEhdV for ; Fri, 30 Jan 2015 13:07:00 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43DE1A8727 for ; Fri, 30 Jan 2015 13:06:58 -0800 (PST) Received: from mail-ie0-f181.google.com ([209.85.223.181]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKVMvycV0DRn4khwtVnSHU0Y1lYZV9K8wc@postini.com; Fri, 30 Jan 2015 13:06:58 PST Received: by mail-ie0-f181.google.com with SMTP id rp18so6144644iec.12 for ; Fri, 30 Jan 2015 13:06:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R9NCnhINLG18m4TXKpxFBAzFjdKzQcIidgnVYLDkN+c=; b=PWO5KJ8XDWiamlnFjcvxcUOmh4qJ9bRzR9lboo5wegUqqUpZJCuKYpW0Kz62WBKZKR xlClLYErKmTx1XyHznkplZicF7Op4EyuhWuLq6qY0ZmjvBHzYmz9X61y3DOdPAAg5hP+ e8NNfGdiqs65v0RLaqZBVL6ReXQe/r716sBevm6G0FSBCNWVQMvm15yU59+ovjiaHGtA 5h5cL2/Q0d3uBITMV9lx3umEwo20Y8OP1qTZTJCx35Jcw9n1Rega4O3KOMXUWw2u/gbM 3aR/6soEFtuWEExCrNg2IlO9RQ3LjWFJkzwtuddkG4zp7G/g6Kr0KjR6xCzXtDORivCH xjiA== X-Gm-Message-State: ALoCoQl0BAIKO4ehkqzsESg4x5omm3uLkte60CvNcO9szJ0J0VGzrWLsO/xqDaupLcfgWKOmhdOuAxzMncv/MJIJKoJLERD2vr4efO4fXRe3aKpjPMP77JLclNEwTOuZLgQqYpZoCiDH X-Received: by 10.107.151.80 with SMTP id z77mr9705398iod.51.1422652017618; Fri, 30 Jan 2015 13:06:57 -0800 (PST) X-Received: by 10.107.151.80 with SMTP id z77mr9705375iod.51.1422652017462; Fri, 30 Jan 2015 13:06:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Fri, 30 Jan 2015 13:06:27 -0800 (PST) In-Reply-To: <513A0CDA-514E-4ACD-AE78-574149288F01@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> <513A0CDA-514E-4ACD-AE78-574149288F01@ve7jtb.com> From: Brian Campbell Date: Fri, 30 Jan 2015 14:06:27 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1140f5ee23e681050de4fc80 Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 21:07:06 -0000 --001a1140f5ee23e681050de4fc80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://bitbucket.org/Nat/oauth-spop/commits/af9ce76988cd32b334e21c71289721= a3bf1c4ff1 looks good to me. Thanks John. On Fri, Jan 30, 2015 at 1:47 PM, John Bradley wrote: > OK try that one. > > On Jan 30, 2015, at 5:15 PM, Brian Campbell > wrote: > > I agree with Mike here. Though PKCE only needs the ASCII(STRING) one. > > On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones > wrote: > >> >> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section= -1.1 >> uses this notation: >> >> >> >> UTF8(STRING) denotes the octets of the UTF-8 [RFC3629 >> ] representation >> >> of STRING, where STRING is a sequence of zero or more Unicode >> >> [UNICODE >> ] >> characters. >> >> >> >> ASCII(STRING) denotes the octets of the ASCII [RFC20 >> ] representation >> >> of STRING, where STRING is a sequence of zero or more ASCII >> >> characters. >> >> >> >> This is unambiguous and has already been vetted by the IESG and SecDir, >> so I would use exactly this wording. >> >> >> >> OCTETS(STRING) is ambiguous, since for the same string there are many >> possible representations as octets, including ASCII, UTF-8, UTF-16, UTF-= 32, >> and EBCDIC. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradle= y >> *Sent:* Friday, January 30, 2015 11:33 AM >> *To:* Brian Campbell >> *Cc:* oauth; Naveen Agarwal >> *Subject:* Re: [OAUTH-WG] PKCE: SHA256(WAT?) >> >> >> >> Have a look at the latest version I added OCTETS(STRING) to show the >> conversion. ASCII(STRING) seemed more confusing by drawing character >> encoding back in. >> >> >> >> I was tempted to call it a octet array without the terminating NULL of >> STRING but didn=E2=80=99t want to introduce array. >> >> >> >> Let me know what you think. >> >> >> >> On Jan 30, 2015, at 1:56 PM, Brian Campbell >> wrote: >> >> >> >> But, while it may be clear to you, what I'm saying here is that it's not >> clear to a reader/implementer. >> >> Somehow the conversion from a character string to an octet string needs >> to be clearly and unambiguously stated. It doesn't have to be the text I >> suggested but it's not sufficient as it is now. >> >> Something like this might work, if you don't want to touch the parts in >> 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the >> octets of the ASCII [RFC0020] representation of STRING." >> >> An "octet sequence using the url and filename safe Alphabet [...], with >> length less than 128 characters." is ambiguous. Octets and characters ar= e >> intermixed with no mention of encoding. But they're not interchangeable. >> >> >> >> >> >> On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura wrote= : >> >> I do not think we need ASCII(). It is quite clear without it, I suppose. >> >> >> >> In 4.1, I would rather do like: >> >> >> >> code_verifier =3D high entropy cryptographic random >> octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] >> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >> less than 128 characters. >> >> >> >> Nat >> >> >> >> 2015-01-30 22:51 GMT+09:00 Brian Campbell : >> >> That's definitely an improvement (to me anyway). >> >> Checking that the rest of the document uses those notations >> appropriately, I think, yields a few other changes. And probably begs fo= r >> the "ASCII(STRING) denotes the octets of the ASCII representation of >> STRING" notation/function, or something like it, to be put back in. Thos= e >> changes might look like the following: >> >> In 4.1.: >> >> OLD: >> code_verifier =3D high entropy cryptographic random ASCII [RFC0020] >> octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] >> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >> less than 128 characters. >> >> NEW (maybe): >> code_verifier =3D high entropy cryptographically strong random STRING >> using the url and filename safe Alphabet [A-Z] / [a-z] >> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >> less than 128 characters. >> >> >> In 4.2.: >> >> OLD: >> S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) >> >> NEW (maybe): >> S256 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier"))) >> >> In 4.6.: >> >> OLD: >> SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). >> >> NEW (maybe): >> SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challeng= e"). >> >> >> >> >> >> On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) >> wrote: >> >> I take your point, Brian. >> >> >> >> In our most recent manuscript, STRING is defined inside ASCII(STRING) as >> >> >> >> STRING is a sequence of zero or more ASCII characters >> >> >> >> but it is kind of circular, and we do not seem to use ASCII(). >> >> >> >> What about re-writing the section like below? >> >> >> >> STRING denotes a sequence of zero or more ASCII [RFC0020] >> characters. >> >> OCTETS denotes a sequence of zero or more octets. >> >> BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section = 3 >> producing a >> ASCII[RFC0020] >> STRING. >> >> BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per S= ection >> 3 , producing a >> sequence of octets. >> >> SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] >> of OCTETS. >> >> >> >> >> >> >> >> >> >> >> >> On Jan 30, 2015, at 08:15, Brian Campbell >> wrote: >> >> >> >> In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC= 6234] >> of STRING." >> >> But, in the little cow town where I come from anyway, you hash >> bits/octets not character strings (BTW, "STRING" isn't defined anywhere = but >> it's kind of implied that it's a string of characters). >> >> Should it say something more like "SHA256(STRING) denotes a SHA2 256bit >> hash [RFC6234] of the octets of the ASCII [RFC0020] representation of >> STRING."? >> >> I know it's kind of pedantic but I find it kind of confusing because the >> code_verifier uses the url and filename safe alphabet, which has me seco= nd >> guessing if SHA256(STRING) actually means a hash of the octet produced b= y >> base64url decoding the string. >> >> Maybe it's just me but, when reading the text, I find the transform >> process to be much more confusing than I think it needs to be. Removing = and >> clarifying some things will help. I hate to suggest this but maybe an >> example showing the computation steps on both ends would be helpful? >> >> >> >> Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A72= but >> not used anywhere. >> >> And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url >> decoding of STRING, per Section 3, producing a UTF-8 sequence of octets.= " >> But what is a UTF-8 sequence of octets? Isn't it just a sequence octets? >> The [RFC3629] reference, I think, could be removed. >> >> >> >> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 >> >> >> >> Nat Sakimura >> >> nat@sakimura.org >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> > > > --001a1140f5ee23e681050de4fc80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 30, 2015 at 1:47 PM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
OK try that one.

On Jan 30, 2015, at 5:15 PM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

I agree with Mike h= ere. Though PKCE only needs the ASCII(STRING) one.

On Fri, Jan 30, 2015 at 12:38 PM= , Mike Jones <Michael.Jones@microsoft.com> wrote:<= br>

= http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-1.= 1 uses this notation:

=C2=A0

=C2=A0=C2=A0 UTF8(STRI= NG) denotes the octets of the UTF-8 [RFC3629] representation

=C2=A0=C2=A0 of STRING= , where STRING is a sequence of zero or more Unicode

=C2=A0=C2=A0 [UNICODE] characters.

=C2=A0

=C2=A0=C2=A0 ASCII= (STRING) denotes the octets of the ASCII [RFC20] representation

=C2=A0=C2=A0 of STRING, where STRING is a sequence of zero or more ASCII

=C2=A0=C2=A0 characters.

=C2=A0<= /p>

This is unambiguous and has alread= y been vetted by the IESG and SecDir, so I would use exactly this wording.<= u>

=C2=A0=

OCTETS(STRING) is a= mbiguous, since for the same string there are many possible representations= as octets, including ASCII, UTF-8, UTF-16, UTF-32, and EBCDIC.

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of John Bradley
Sent: Friday, January 30, 2015 11:33 AM
To: Brian Campbell
Cc: oauth; Naveen Agarwal
Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?)

=C2=A0

Have a look at the latest version I added OCTETS(STRING) to show= the conversion. =C2=A0 ASCII(STRING) seemed more confusing by drawing char= acter encoding back in.

=C2=A0

I was tempted to call it a octet array without = the terminating NULL of STRING but didn=E2=80=99t want to introduce array.<= u>

=C2=A0

Let me know what you think.

=C2=A0

On Jan 30, 2015, at 1:56 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

=C2=A0

But, while it may be clear to you, what I'm= saying here is that it's not clear to a reader/implementer.

Somehow the conversion from a character string to an octet string needs to = be clearly and unambiguously stated. It doesn't have to be the text I s= uggested but it's not sufficient as it is now.

Something like this might work, if you don't want to touch the parts in= 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of = the octets of the ASCII [RFC0020] representation of STRING."

An "octet sequence using the url and filename safe Alphabet [...], wit= h length less than 128 characters." is ambiguous. Octets and character= s are intermixed with no mention of encoding. But they're not interchan= geable.

=C2=A0

=C2=A0

On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura &= lt;sakimura@gmail.c= om> wrote:

I do not think we need ASCII(). It is quite cle= ar without it, I suppose.=C2=A0

=C2=A0

In 4.1, I would rather do like:=C2=A0=

=C2=A0

=C2=A0code_verifier =3D high entropy cryptograp= hic random=C2=A0
=C2=A0=C2=A0 octet sequence using the url and filename safe Alphabet [A-Z] = / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.

=C2=A0

Nat

=C2=A0

2015-01-30 22:51 GMT+09:00 Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com>:

That's defin= itely an improvement (to me anyway).

Checking that th= e rest of the document uses those notations appropriately, I think, yields = a few other changes. And probably begs for the "ASCII(STRING) denotes = the octets of the ASCII representation of STRING" notation/function, or something like it, to be put back in. Those changes = might look like the following:

In 4.1.:

OLD:
=C2=A0=C2=A0 code_verifier =3D high entropy cryptographic random ASCII [RFC= 0020]
=C2=A0=C2=A0 octet sequence using the url and filename safe Alphabet [A-Z] = / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.

NEW (maybe):
=C2=A0 code_verifier =3D high entropy cryptographically strong random STRIN= G
=C2=A0 using the url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.


In 4.2.:

OLD:
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(&qu= ot;code_verifier"))

NEW (maybe):
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(ASC= II("code_verifier")))

In 4.6.:

OLD:
=C2=A0=C2=A0 SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE(&qu= ot;code_challenge").

NEW (maybe):
=C2=A0=C2=A0 SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECO= DE("code_challenge").

=C2=A0

=C2=A0

On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (= =3Dnat) <nat@sakim= ura.org> wrote:

I take your point, Brian.=C2=A0

=C2=A0

In our most recent manuscript, STRING is define= d inside ASCII(STRING) as=C2=A0

=C2=A0

STRING is a sequence of zero or more ASCII cha= racters

=C2=A0

but it is kind of circular, and we do not seem to use ASCII().= =C2=A0

=C2=A0

What about re-writing the section like below?=C2=A0

=C2=A0

STRING denotes a sequence of zero or more ASCII =C2=A0[RFC0020]=C2=A0characters.=C2=A0

OCTETS denotes a sequence of zero or more octets.=C2=A0

BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per=C2=A0Section 3=C2=A0produc= ing a ASCII[RFC0020]=C2= =A0STRING.

BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per=C2= =A0Section 3, producing a sequence of octets.

SHA256(OCTETS) denotes a SHA2 256bit hash=C2=A0[RFC6234]=C2=A0of OCTETS.<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Jan 30, 2015, at 08:15, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

=C2=A0

In =C2=A72 [1] w= e've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of S= TRING."

But, in the lit= tle cow town where I come from anyway, you hash bits/octets not character s= trings (BTW, "STRING" isn't defined anywhere but it's kin= d of implied that it's a string of characters).=C2=A0

Should it say s= omething more like "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234= ] of the octets of the ASCII [RFC0020] representation of STRING."?

I know it's= kind of pedantic but I find it kind of confusing because the code_verifier= uses the url and filename safe alphabet, which has me second guessing if S= HA256(STRING) actually means a hash of the octet produced by base64url decoding the string.

Maybe it's just me but, when reading the te= xt, I find the transform process to be much more confusing than I think it = needs to be. Removing and clarifying some things will help. I hate to sugge= st this but maybe an example showing the computation steps on both ends would be helpful?

=C2=A0

Also "UTF8(STRING)" and "ASCII(= STRING)" notations are defined in =C2=A72 but not used anywhere.

And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url= decoding of STRING, per Section 3, producing a UTF-8 sequence of octets.&q= uot; But what is a UTF-8 sequence of octets? Isn't it just a sequence o= ctets? The [RFC3629] reference, I think, could be removed.

=C2=A0

Nat Sakimura

=C2=A0<= /u>

=C2=A0<= /u>

=C2=A0

=C2=A0

=C2=A0



=C2=A0

--

Nat Sakimura (=3D= nat)

Chairman, OpenID = Foundation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

=C2=A0



--001a1140f5ee23e681050de4fc80-- From nobody Fri Jan 30 15:07:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1181A876B for ; Fri, 30 Jan 2015 15:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_fCPzGgie2k for ; Fri, 30 Jan 2015 15:07:36 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC741A8727 for ; Fri, 30 Jan 2015 15:07:35 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id x12so22136869qac.11 for ; Fri, 30 Jan 2015 15:07:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QIG+mUkwSR9vlAL+XBe7J+3AcveOl7NPlD79viyAxz0=; b=Yzvl9cTDitgGc1I/TtSZdefiVzRllA+nbC9Z21mT8NIU6m3LinEacpLOPOETfjlekO XtJQIZZlTRvZiqOqiLFGWPTj0qSCrcTSxccNmYZmzQKUwrCR8hMJ30rz7vhTNQqeijda fYrklLc4+JrmAhf+01y53tmPsPBieYJTZPQHXDzsz/5UdhaFLObd5yI8ocnB/GO/avW1 vMow9WsOwvrP86bvOJkX2HOt8gJmkT36ho/AYjTBSKyOIWjBhjkexeawfLnhr1tB/rAq t/kIwbjL/Cq+T4FUEqWtnuBE9RB5vuygj87aIPjBOIatFVyqBD44FRGKrg47Qyzfknen +wkA== X-Gm-Message-State: ALoCoQm2c3dcAmYfVKFRZUkr+qJbXJRwa/C8vqtWfGNgEriDDsaurbQi2OvWVswqlSCnyoXo6dEr X-Received: by 10.140.97.7 with SMTP id l7mr13204871qge.66.1422659255030; Fri, 30 Jan 2015 15:07:35 -0800 (PST) Received: from [192.168.8.100] ([181.202.0.93]) by mx.google.com with ESMTPSA id 77sm11399978qgx.43.2015.01.30.15.07.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 15:07:34 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-F173D9F4-EB48-4E71-8A68-1CDAE79F139E Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Fri, 30 Jan 2015 20:07:31 -0300 Content-Transfer-Encoding: 7bit Message-Id: <228CF945-D861-49E5-AFE2-6CB48CC847A0@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> <513A0CDA-514E-4ACD-AE78-574149288F01@ve7jtb.com> To: Brian Campbell Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 23:07:40 -0000 --Apple-Mail-F173D9F4-EB48-4E71-8A68-1CDAE79F139E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok I will push out draft 7 to the doc tracker later today.=20 Sent from my iPhone > On Jan 30, 2015, at 6:06 PM, Brian Campbell w= rote: >=20 > https://bitbucket.org/Nat/oauth-spop/commits/af9ce76988cd32b334e21c7128972= 1a3bf1c4ff1 looks good to me. Thanks John.=20 >=20 >> On Fri, Jan 30, 2015 at 1:47 PM, John Bradley wrote: >> OK try that one. >>=20 >>> On Jan 30, 2015, at 5:15 PM, Brian Campbell = wrote: >>>=20 >>> I agree with Mike here. Though PKCE only needs the ASCII(STRING) one. >>>=20 >>>> On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones wrote: >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#sectio= n-1.1 uses this notation: >>>>=20 >>>> =20 >>>>=20 >>>> UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representatio= n >>>>=20 >>>> of STRING, where STRING is a sequence of zero or more Unicode >>>>=20 >>>> [UNICODE] characters. >>>>=20 >>>> =20 >>>>=20 >>>> ASCII(STRING) denotes the octets of the ASCII [RFC20] representation= >>>>=20 >>>> of STRING, where STRING is a sequence of zero or more ASCII >>>>=20 >>>> characters. >>>>=20 >>>> =20 >>>>=20 >>>> This is unambiguous and has already been vetted by the IESG and SecDir,= so I would use exactly this wording. >>>>=20 >>>> =20 >>>>=20 >>>> OCTETS(STRING) is ambiguous, since for the same string there are many p= ossible representations as octets, including ASCII, UTF-8, UTF-16, UTF-32, a= nd EBCDIC. >>>>=20 >>>> =20 >>>>=20 >>>> -- Mike= >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >>>> Sent: Friday, January 30, 2015 11:33 AM >>>> To: Brian Campbell >>>> Cc: oauth; Naveen Agarwal >>>> Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) >>>>=20 >>>> =20 >>>>=20 >>>> Have a look at the latest version I added OCTETS(STRING) to show the co= nversion. ASCII(STRING) seemed more confusing by drawing character encodin= g back in. >>>>=20 >>>> =20 >>>>=20 >>>> I was tempted to call it a octet array without the terminating NULL of S= TRING but didn=E2=80=99t want to introduce array. >>>>=20 >>>> =20 >>>>=20 >>>> Let me know what you think. >>>>=20 >>>> =20 >>>>=20 >>>> On Jan 30, 2015, at 1:56 PM, Brian Campbell wrote: >>>>=20 >>>> =20 >>>>=20 >>>> But, while it may be clear to you, what I'm saying here is that it's no= t clear to a reader/implementer. >>>>=20 >>>> Somehow the conversion from a character string to an octet string needs= to be clearly and unambiguously stated. It doesn't have to be the text I su= ggested but it's not sufficient as it is now. >>>>=20 >>>> Something like this might work, if you don't want to touch the parts in= 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the oc= tets of the ASCII [RFC0020] representation of STRING." >>>>=20 >>>> An "octet sequence using the url and filename safe Alphabet [...], with= length less than 128 characters." is ambiguous. Octets and characters are i= ntermixed with no mention of encoding. But they're not interchangeable. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura wrot= e: >>>>=20 >>>> I do not think we need ASCII(). It is quite clear without it, I suppose= .=20 >>>>=20 >>>> =20 >>>>=20 >>>> In 4.1, I would rather do like:=20 >>>>=20 >>>> =20 >>>>=20 >>>> code_verifier =3D high entropy cryptographic random=20 >>>> octet sequence using the url and filename safe Alphabet [A-Z] / [a-z= ] >>>> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >>>> less than 128 characters. >>>>=20 >>>> =20 >>>>=20 >>>> Nat >>>>=20 >>>> =20 >>>>=20 >>>> 2015-01-30 22:51 GMT+09:00 Brian Campbell := >>>>=20 >>>> That's definitely an improvement (to me anyway). >>>>=20 >>>> Checking that the rest of the document uses those notations appropriate= ly, I think, yields a few other changes. And probably begs for the "ASCII(ST= RING) denotes the octets of the ASCII representation of STRING" notation/fun= ction, or something like it, to be put back in. Those changes might look lik= e the following: >>>>=20 >>>>=20 >>>> In 4.1.:=20 >>>>=20 >>>> OLD: >>>> code_verifier =3D high entropy cryptographic random ASCII [RFC0020] >>>> octet sequence using the url and filename safe Alphabet [A-Z] / [a-z= ] >>>> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >>>> less than 128 characters. >>>>=20 >>>> NEW (maybe): >>>> code_verifier =3D high entropy cryptographically strong random STRING= >>>> using the url and filename safe Alphabet [A-Z] / [a-z] >>>> / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length >>>> less than 128 characters. >>>>=20 >>>>=20 >>>> In 4.2.:=20 >>>>=20 >>>> OLD: >>>> S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) >>>>=20 >>>> NEW (maybe): >>>> S256 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier")))= >>>>=20 >>>>=20 >>>> In 4.6.:=20 >>>>=20 >>>> OLD: >>>> SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). >>>>=20 >>>> NEW (maybe): >>>> SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challen= ge"). >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) wrote: >>>>=20 >>>> I take your point, Brian.=20 >>>>=20 >>>> =20 >>>>=20 >>>> In our most recent manuscript, STRING is defined inside ASCII(STRING) a= s=20 >>>>=20 >>>> =20 >>>>=20 >>>> STRING is a sequence of zero or more ASCII characters >>>>=20 >>>> =20 >>>>=20 >>>> but it is kind of circular, and we do not seem to use ASCII().=20 >>>>=20 >>>> =20 >>>>=20 >>>> What about re-writing the section like below?=20 >>>>=20 >>>> =20 >>>>=20 >>>> STRING denotes a sequence of zero or more ASCII [RFC0020] characters.=20= >>>>=20 >>>> OCTETS denotes a sequence of zero or more octets.=20 >>>>=20 >>>> BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section= 3 producing a ASCII[RFC0020] STRING. >>>>=20 >>>> BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per S= ection 3, producing a sequence of octets. >>>>=20 >>>> SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] of OCTETS. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Jan 30, 2015, at 08:15, Brian Campbell w= rote: >>>>=20 >>>> =20 >>>>=20 >>>> In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC= 6234] of STRING." >>>>=20 >>>> But, in the little cow town where I come from anyway, you hash bits/oct= ets not character strings (BTW, "STRING" isn't defined anywhere but it's kin= d of implied that it's a string of characters).=20 >>>>=20 >>>> Should it say something more like "SHA256(STRING) denotes a SHA2 256bit= hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRIN= G."? >>>>=20 >>>> I know it's kind of pedantic but I find it kind of confusing because th= e code_verifier uses the url and filename safe alphabet, which has me second= guessing if SHA256(STRING) actually means a hash of the octet produced by b= ase64url decoding the string. >>>>=20 >>>> Maybe it's just me but, when reading the text, I find the transform pro= cess to be much more confusing than I think it needs to be. Removing and cla= rifying some things will help. I hate to suggest this but maybe an example s= howing the computation steps on both ends would be helpful? >>>>=20 >>>> =20 >>>>=20 >>>> Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in =C2=A7= 2 but not used anywhere. >>>>=20 >>>> And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url d= ecoding of STRING, per Section 3, producing a UTF-8 sequence of octets." But= what is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [R= FC3629] reference, I think, could be removed. >>>>=20 >>>> =20 >>>>=20 >>>> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 >>>>=20 >>>> =20 >>>>=20 >>>> Nat Sakimura >>>>=20 >>>> nat@sakimura.org >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> Nat Sakimura (=3Dnat) >>>>=20 >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>>=20 >=20 --Apple-Mail-F173D9F4-EB48-4E71-8A68-1CDAE79F139E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ok I will push out draft 7 to the doc t= racker later today. 

Sent from my iPhone

On Jan 30= , 2015, at 6:06 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:


On Fri, Jan 30, 2015 at 1:47 PM, John Bradley <ve7jtb@ve7j= tb.com> wrote:
OK try that one.

<= blockquote type=3D"cite">
On Jan 30, 2015, at 5:15 PM, Brian Campbell &l= t;bcampbell@= pingidentity.com> wrote:

I agree with M= ike here. Though PKCE only needs the ASCII(STRING) one.

On Fri, Jan 30, 2015 at 12:38 P= M, Mike Jones <Michael.Jones@microsoft.com> wrote:

htt= p://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-1.1 uses this notation:

 

   UTF8(STRING) de= notes the octets of the UTF-8 [RFC3629] representation

   of STRING, wh= ere STRING is a sequence of zero or more Unicode

   [UNICODE] characters.

=  

   ASCII(STRING) denotes= the octets of the ASCII [RFC2= 0] representation

   of STR= ING, where STRING is a sequence of zero or more ASCII

   characters.

 

This is unambiguous and has already been vetted by the IESG a= nd SecDir, so I would use exactly this wording.

 

OCTETS(STRING) is ambiguous, since for the same str= ing there are many possible representations as octets, including ASCII, UTF-= 8, UTF-16, UTF-32, and EBCDIC.

 

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

<= u> 

From: OAuth [mailto:oauth-bounces@ietf.org]= On Behalf Of John Bradley
Sent: Friday, January 30, 2015 11:33 AM
To: Brian Campbell
Cc: oauth; Naveen Agarwal
Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?)

 

Have a look at the latest version I added OCTETS(STRING) to show t= he conversion.   ASCII(STRING) seemed more confusing by drawing charact= er encoding back in.

 

I was tempted to call it a octet array without t= he terminating NULL of STRING but didn=E2=80=99t want to introduce array.=

 

Let me know what you think.

 

On Jan 30, 2015, at 1:56 PM, Brian Campbell <= bcampbell@pi= ngidentity.com> wrote:

 

But, while it may be clear to you, what I'm sayi= ng here is that it's not clear to a reader/implementer.

Somehow the conversion from a character string to an octet string needs to b= e clearly and unambiguously stated. It doesn't have to be the text I suggest= ed but it's not sufficient as it is now.

Something like this might work, if you don't want to touch the parts in 4.2 a= nd 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets o= f the ASCII [RFC0020] representation of STRING."

An "octet sequence using the url and filename safe Alphabet [...], with leng= th less than 128 characters." is ambiguous. Octets and characters are interm= ixed with no mention of encoding. But they're not interchangeable.

 

 

On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura &l= t;sakimura@gmail.com= > wrote:

I do not think we need ASCII(). It is quite clea= r without it, I suppose. 

 

In 4.1, I would rather do like: <= /u>

 

 code_verifier =3D high entropy cryptograph= ic random 
   octet sequence using the url and filename safe Alphabet [A-Z] /= [a-z]
   / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with leng= th
   less than 128 characters.

 

Nat

 

2015-01-30 22:51 GMT+09:00 Brian Campbell <bcampbell@ping= identity.com>:

That's definitely= an improvement (to me anyway).

Checking that the= rest of the document uses those notations appropriately, I think, yields a f= ew other changes. And probably begs for the "ASCII(STRING) denotes the octet= s of the ASCII representation of STRING" notation/function, or something like it, to be put back in. Those changes m= ight look like the following:

In 4.1.:

OLD:
   code_verifier =3D high entropy cryptographic random ASCII [RFC0= 020]
   octet sequence using the url and filename safe Alphabet [A-Z] /= [a-z]
   / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with leng= th
   less than 128 characters.

NEW (maybe):
  code_verifier =3D high entropy cryptographically strong random STRING=
  using the url and filename safe Alphabet [A-Z] / [a-z]
   / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with leng= th
   less than 128 characters.


In 4.2.:

OLD:
   S256  "code_challenge" =3D BASE64URL(SHA256("code_verifier= "))

NEW (maybe):
   S256  "code_challenge" =3D BASE64URL(SHA256(ASCII("code_ve= rifier")))

In 4.6.:

OLD:
   SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challeng= e").

NEW (maybe):
   SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_ch= allenge").

 

 

On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3D= nat) <nat@sakimura.= org> wrote:

I take your point, Brian. 

 

In our most recent manuscript, STRING is defined= inside ASCII(STRING) as 

 

STRING is a sequence of zero or more ASCII chara= cters

 

but it is kind of circular, and we do not seem to use ASCII().&nb= sp;

 

What about re-writing the section like below? =

 

= STRING denotes a sequence of zero or more ASCII  [RFC0020] characters. 

= OCTETS denotes a sequence of zero or more octets. =

= = BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 3 producing a ASCII[RFC0020] = ;STRING.

= BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per = Section 3, producing a sequence of octets.

= SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] of OCTETS.

<= p class=3D"MsoNormal" style=3D"margin-right:24.0pt;margin-left:24.0pt"> =  

 

 

 

 

On Jan 30, 2015, at 08:15, Brian Campbell <bcampbell@ping= identity.com> wrote:

 

In =C2=A72 [1] we= 've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING."

But, in the litt= le cow town where I come from anyway, you hash bits/octets not character str= ings (BTW, "STRING" isn't defined anywhere but it's kind of implied that it'= s a string of characters). 

Should it say so= mething more like "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of th= e octets of the ASCII [RFC0020] representation of STRING."?

I know it's kind= of pedantic but I find it kind of confusing because the code_verifier uses t= he url and filename safe alphabet, which has me second guessing if SHA256(ST= RING) actually means a hash of the octet produced by base64url decoding the string.

Maybe it's just me but, when reading the text, I= find the transform process to be much more confusing than I think it needs t= o be. Removing and clarifying some things will help. I hate to suggest this b= ut maybe an example showing the computation steps on both ends would be helpful?

 

Also "UTF8(STRING)" and "ASCII(STRING)" notatio= ns are defined in =C2=A72 but not used anywhere.

And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url decod= ing of STRING, per Section 3, producing a UTF-8 sequence of octets." But wha= t is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC36= 29] reference, I think, could be removed.

 

Nat Sakimura

 

 

 

 

 



 

-- =

Nat Sakimura (=3Dn= at)

Chairman, OpenID Fo= undation
http://nat.sakimura.o= rg/
@_nat_en

 

 




= = --Apple-Mail-F173D9F4-EB48-4E71-8A68-1CDAE79F139E-- From nobody Fri Jan 30 17:51:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FB01A882A; Fri, 30 Jan 2015 17:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk_ZwQJ_jHli; Fri, 30 Jan 2015 17:51:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 056BD1A8830; Fri, 30 Jan 2015 17:51:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131015130.7664.98403.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 17:51:30 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 01:51:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-07.txt Pages : 16 Date : 2015-01-30 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-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 Sat Jan 31 08:34:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287BE1A1A33 for ; Sat, 31 Jan 2015 08:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 vfx5lXpB7izO for ; Sat, 31 Jan 2015 08:34:10 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) (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 F1F9D1A07BD for ; Sat, 31 Jan 2015 08:34:09 -0800 (PST) Received: from [79.253.34.96] (helo=[192.168.71.131]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YHazn-0000Qr-1D; Sat, 31 Jan 2015 17:34:07 +0100 References: <54C7BBA4.4030702@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-355A75EF-9976-439A-8CC3-378A2D8CD366 Content-Transfer-Encoding: 7bit Message-Id: <2E3D2EE7-8F5F-452D-880A-D62A513AC853@lodderstedt.net> X-Mailer: iPad Mail (12B466) From: Torsten Lodderstedt Date: Sat, 31 Jan 2015 17:34:04 +0100 To: Brian Campbell X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" , "naa@google.com >> Naveen Agarwal" Subject: Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 16:34:12 -0000 --Apple-Mail-355A75EF-9976-439A-8CC3-378A2D8CD366 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Deutsche Telekom also implemented an early version of the draft last year. > Am 30.01.2015 um 18:50 schrieb Brian Campbell = : >=20 >=20 >> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig wrote: >>=20 >> 1) What implementations of the spec are you aware of? >=20 > We have an AS side implementation of an earlier draft that was released in= June of last year: http://documentation.pingidentity.com/pages/viewpage.act= ion?pageId=3D26706844 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-355A75EF-9976-439A-8CC3-378A2D8CD366 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Deutsche Telekom also implemented an early version of the draft last year.



Am 30.01.2015 um 18:50 schrieb Brian Campbell <bcampbell@pingidentity.com>:


On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

1) What implementations of the spec are you aware of?

We have an AS side implementation of an earlier draft that was released in June of last year: http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-355A75EF-9976-439A-8CC3-378A2D8CD366--