From nobody Sun Jun 5 15:57:00 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14CD12D56C for ; Sun, 5 Jun 2016 15:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDaRVmHvf7lV for ; Sun, 5 Jun 2016 15:56:57 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C2512B00A for ; Sun, 5 Jun 2016 15:56:57 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id k23so201948947oih.0 for ; Sun, 05 Jun 2016 15:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=UUmn4I1BbwpLIYxF4aofkAG1VsZAZpLHpJALM0SiZA8=; b=plJEseB1sPj75mn45YsngXvSBE/XiDk1o8LARAIW3gi1fs0xwKsd5WyQiFQ6JRf6ak FoYfv8CL6nm8iJUGSDtbyCq8dZUk07AMgNPeOHuXe+Uv5kP/Fv9WGjP7DtA3v3wVPrOy 11T48P7cs33Kppaxty9yH6hjLuQtCeKKT02bNNnl2F2xYkMAQUC0fF6SFs1VvxiVy44L aIh4OJhwcHR3A4WhtT2BoZ+tVtMGcyqvWvkr079biEwfXYI4NFQQw1FPNWub8CkWeaHi wl1tIsfvkJd9wZg/fFB2Fix+paMKdppJhool+lsq7FaVvQr2E0WD1zFCcbMU22xH470l O5mA== 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; bh=UUmn4I1BbwpLIYxF4aofkAG1VsZAZpLHpJALM0SiZA8=; b=hz5Jm9yWxNuANY+ryB97us08oBeW61Y4+f/GIjAhcJGJziW7sQ/v1jmO8RRW86yXJP S9A/hxjNkj4id541eo8LeQkiPDpACUAxndNVjzVjMZS3C7mitny+SRdlDIY4h4WlWomv crw8Nzjq6jPwKjjxwdTsO892TFbosYnMIm45rxV3eAkFEPCD06xWVnWFQPQJ2AzlS/o1 0Cj/gVBGUwJpcOjYA5HKKsOCaszTHT+Kgwh425OnHZ3zgYpzAEl4zjsYem3OSa2NKHks sZtNDEmdzbZVBiJv2lT7KO2+TGW+OySXE5wAiacK7ZDaSNVrHbGCvEZf0W6ue3wTVr+5 LrHw== X-Gm-Message-State: ALyK8tL0WmNqXctGw6wZ8NjOBl+Gzu/Xgfpwx7pyyORKHam/dleGyosYyu/uHkwptnXntQVn5ft+GD3bpfeMo33N X-Received: by 10.202.183.131 with SMTP id h125mr7366568oif.189.1465167416276; Sun, 05 Jun 2016 15:56:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.78.66 with HTTP; Sun, 5 Jun 2016 15:56:36 -0700 (PDT) From: William Denniss Date: Sun, 5 Jun 2016 15:56:36 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113ccc8662b26605348fdfc0 Archived-At: Subject: [OAUTH-WG] Notes from the Mix-up/Cut-n-Paste Mitigation Session at IIW X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 22:56:58 -0000 --001a113ccc8662b26605348fdfc0 Content-Type: text/plain; charset=UTF-8 Some of us in this working group had a session on Mix-up mitigation at the Spring Internet Identity Workshop. Some rough notes I took during that session: https://docs.google.com/document/d/15JetlsX2Wk3OvNqdjmi-wPoBr1-KIm1lDIfMgF6sB74/edit Look forward to seeing those of you who are at the Cloud Identity Summit this week! --001a113ccc8662b26605348fdfc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some of us in this working group had a session on Mix-up m= itigation at the Spring Internet Identity Workshop.


--001a113ccc8662b26605348fdfc0-- From nobody Fri Jun 17 04:44:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96D712B016 for ; Fri, 17 Jun 2016 04:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.226 X-Spam-Level: X-Spam-Status: No, score=-4.226 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9Glmn5_1Zsc for ; Fri, 17 Jun 2016 04:44:27 -0700 (PDT) Received: from mx2.uni-trier.de (mx2.uni-trier.de [136.199.224.18]) (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 2A98812D10C for ; Fri, 17 Jun 2016 04:44:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,483,1459807200"; d="scan'208";a="19421319" Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx2i.uni-trier.de with ESMTP; 17 Jun 2016 13:44:23 +0200 Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id C5F77407DA for ; Fri, 17 Jun 2016 13:44:23 +0200 (CEST) To: "oauth@ietf.org" From: Daniel Fett Message-ID: <5763E297.6090701@uni-trier.de> Date: Fri, 17 Jun 2016 13:44:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] OAuth Security Workshop: Call for Participation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:44:30 -0000 Call for Participation OAuth Security Workshop 2016 University of Trier Trier, Germany July 14-15, 2016 The workshop program and further information is available on the workshop website: https://infsec.uni-trier.de/events/osw2016 * Registration is open until: July 24th, 2016 * The OAuth Security Workshop (OSW) brings together the IETF OAuth Working Group and security experts from research, industry, and standardization to improve the security of OAuth and related Internet protocols. The workshop is hosted by the Chair for Information Security and Cryptography at the University of Trier. Invited Speakers ---------------- Karthikeyan Bhargavan (INRIA Paris-Rocquencourt) Andrey Labunets (Facebook) From nobody Fri Jun 17 04:48:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E015D12D533 for ; Fri, 17 Jun 2016 04:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKxf1Ddeyb3e for ; Fri, 17 Jun 2016 04:48:18 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0070.outbound.protection.outlook.com [207.46.100.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A02312B016 for ; Fri, 17 Jun 2016 04:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v3dFLswgficSA/0W0eAvrucIcIVYyih9NoJr9oN83ew=; b=rNOzSCPn57fe3l+eeczPWAF97D0yfV9Jm18iJsVXxjqsKpIhuW22c5axNeyKsg6oXisU/yVtL2FWZ3WgMJAoUQuPoh5HvXM/M4N8D6GpQv5N1CVzLStroqfcq516agVMYUbaQMbG4dw4Mc1yanrDXWwMWN6dGQEQj2i8vMpo9ak= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1029.namprd02.prod.outlook.com (10.161.203.147) with Microsoft SMTP Server (TLS) id 15.1.523.12; Fri, 17 Jun 2016 11:48:17 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0523.015; Fri, 17 Jun 2016 11:48:11 +0000 From: Antonio Sanso To: Daniel Fett Thread-Topic: [OAUTH-WG] OAuth Security Workshop: Call for Participation Thread-Index: AQHRyI2f1CD6mRFTIkOW9g848WfPcZ/tiyAA Date: Fri, 17 Jun 2016 11:48:10 +0000 Message-ID: References: <5763E297.6090701@uni-trier.de> In-Reply-To: <5763E297.6090701@uni-trier.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a02:1205:34c2:a720:bd33:794a:d236:5b3b] x-ms-office365-filtering-correlation-id: 0d666630-a320-4ae7-ec71-08d396a541fb x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1029; 6:jYTtipK3xTGrOtFuC0ctnq+PTHqjprSu+apwjg4mmc6ugzIAm+QL5zypv9IhuBVKbz1dVFVI4CG1N/oAiSnnodwxkWk181Gij0PATFKyfD4Bq/qpj0T5ZHYmQZjw6/kBrGZSI+NQ0ZC7dXi6SsjXJNLKqcGSDy3OKtq0QCpbUK8LvhnRK25hl3Ecczk9fvIon15iMFv87f+CUvyP/AoVknsO9LcLUx8t8ClDBPik/VSxTfXkZfj9QC/9PwwdIFJq9HYxI1sq2/wQTIsBJSI/1L2NHf9L4gfFY3RZYJhkSnourL9590nJevw7TomYSxBMONjatPC1rJcgvwVhIs8Aag==; 5:fzx7OWsY2KGz1sDnYiSOIFDWF6ygRFFGNq4wEpnVdeq4ZVj2tA5/U80rkCzkleh2EoiDRzsbj+3Ji+q3NkYPJ66QI78AZi9w46tcxhbZD1NlfnTyVheXRAX78Tg6y+XzOHmRyv0PshXWCl4iE2eQyg==; 24:isqmSyadQ2L4s0zh/LNJnRa+U2ZO5xYDwaBCy6pOYkcHrKDstwK+8kXmvesephfSD0SDgIfIFn6dqAp/r0rg89+h22buU5qWFjecScbBriM=; 7:1trZaclejTRJqOdkJXU9QKEuDrQ1kb1nnRBor9eYEcp6KjRRGHFd5pAYZveABHVy0ZjyG3WvFsevh/LT1Ibsx/jX87NoSmfdcDiuPwW9gxKmcSmviGnAHXr0TIgdmqKbw2tUnL/8o4GuBNesliOrCulduox70JgKBy4zTAh6oKXOw4FlDt5xvRc51rEHEmBV+sHOIQzh/lJ+LJhFeBW4X4gSy1fhMLIO61PZv6qJU3Du++oQEsBEyf7g8RMzIwpl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029; x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(377454003)(189002)(5002640100001)(105586002)(81156014)(5004730100002)(68736007)(10090500001)(102836003)(106356001)(81166006)(97736004)(77096005)(2906002)(6116002)(586003)(101416001)(8936002)(15650500001)(122556002)(83716003)(36756003)(106116001)(19580395003)(19580405001)(3280700002)(82746002)(3660700001)(4326007)(2950100001)(2900100001)(92566002)(33656002)(110136002)(15975445007)(5008740100001)(76176999)(54356999)(8676002)(86362001)(189998001)(50986999)(87936001)(10400500002)(99286002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <72D8DEF9F677A647AF662B31FE343BDA@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 11:48:10.3996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1029 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Security Workshop: Call for Participation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:48:20 -0000 hi Daniel, On Jun 17, 2016, at 1:44 PM, Daniel Fett wrote: > Call for Participation >=20 > OAuth Security Workshop 2016 > University of Trier > Trier, Germany > July 14-15, 2016 >=20 > The workshop program and further information is available on the > workshop website: >=20 > https://infsec.uni-trier.de/events/osw2016 >=20 > * Registration is open until: July 24th, 2016 * did you mean Registration is open until: June 24th, 2016 * ? :) >=20 > The OAuth Security Workshop (OSW) brings together the IETF OAuth Working > Group and security experts from research, industry, and standardization > to improve the security of OAuth and related Internet protocols. The > workshop is hosted by the Chair for Information Security and > Cryptography at the University of Trier. >=20 >=20 > Invited Speakers > ---------------- >=20 > Karthikeyan Bhargavan (INRIA Paris-Rocquencourt) > Andrey Labunets (Facebook) >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jun 17 04:50:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BFF12D534 for ; Fri, 17 Jun 2016 04:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdxTzgI1cSAj for ; Fri, 17 Jun 2016 04:50:32 -0700 (PDT) Received: from mx1.uni-trier.de (mx1.uni-trier.de [136.199.224.17]) (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 76EAB12B047 for ; Fri, 17 Jun 2016 04:50:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,483,1459807200"; d="scan'208";a="20668235" Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx1i.uni-trier.de with ESMTP; 17 Jun 2016 13:50:29 +0200 Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id CECFE408B6 for ; Fri, 17 Jun 2016 13:50:29 +0200 (CEST) References: <5763E297.6090701@uni-trier.de> To: "oauth@ietf.org" From: Daniel Fett Message-ID: <5763E405.6060808@uni-trier.de> Date: Fri, 17 Jun 2016 13:50:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] OAuth Security Workshop: Call for Participation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:50:33 -0000 Am 17.06.2016 um 13:48 schrieb Antonio Sanso: >> * Registration is open until: July 24th, 2016 * > > did you mean Registration is open until: June 24th, 2016 * ? :) Yes, of course! Thanks! -- Informationssicherheit und Kryptografie Universität Trier - Tel. 0651 201 2847 - H436 From nobody Mon Jun 20 01:20:11 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E5512B00F for ; Mon, 20 Jun 2016 01:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSwU5iZh1y6l for ; Mon, 20 Jun 2016 01:20:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 875C712D0CB for ; Mon, 20 Jun 2016 01:20:07 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LkfdE-1bmrk90GgO-00aWXB for ; Mon, 20 Jun 2016 10:20:05 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5767A735.4040207@gmx.net> Date: Mon, 20 Jun 2016 10:20:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Qt3voIVKnnKtsSQT4QXmNhOXRAk4aP89H" X-Provags-ID: V03:K0:1DgnNMBjTRL6wqV3FN7XlqkQOINQyNKFfcU6tTWiPsI0z9/iJAV E6YKYsW3mdEse5PWQjR8fUE9mfFaylOrC91sDWSyebKDzcSy4gjXxcGs7exTFV+LoYfS8Hz qtQ+Gfi4yiS4cbhuCh6USO4poJBsqn184xbPYdcu2dr6lCbxG36C3O5GZcMNaXB+HsYbDTV bXHq3eeSDOirdHPfYAaUw== X-UI-Out-Filterresults: notjunk:1;V01:K0:avz/utUZXME=:PFF+ngbWQM1Hb6XnXUcpIU BSxv6VR09aaQrO/yKL5tAQBJ1BXk3yRVhbb1FK0SZ0kSB4kFGnuMmsbgBkQzdx9NvyMv8d5+1 e4oQFQYxIR5oBU90ySkHiyLFjjF8z5j9wWWENMcwhkwOS/gvTSnBKR100JHPx0OUn7x03M1FB fEXZ2g9/fZegeSj/dE/uCt5t+7UyaadzT0UUv60sEwxA+5QK/6fQloSzpH7Q/ez7APhplds3V U+IgVbYxBjs3hdmJLkauweD+nUbPSbpfZrtMTFLZxnTIl6GOZYktmoRzYWgaQ4Lem/T/yIg7E MdUEfpseXHSVzuOD3raioUedsa00djkeiO1ameSIFrGVwL+3xGvTSE5gXd3/4B3je3qZ2HSxk rEbmd8R++/2OmTRQgJVjCGsCiDGljuPxwDFxpe7eJUq6Sf49UWufOGcibymK27PLJV3A8f1dT 4mivWrwG7elPjOA0lBarVatfdXalee9CoEXToniDKWtrOdiDDvvtSmu19Jtvr8CdFz04DNxbF eW8xbfhtJGQ25/f7zNjy+j+XBLvA11lWOjpxaS6wavO4UWsg4icxauWs38Sc2fiouw1fMXSs4 jKlSb+fBcIW2rxPMquSrFVtgqzhC8Q8oHI8/cqn7GRQFQnURWQlHW9Qw+VcT9K49lY+jzZcwN 1CFD11PDjlzRmhx5iemYTW69tsAMkKBZg7dpBMUhvCDmYlKEpBrk8SuQYkfejHscMBnbKoI4/ 0eShsEYzh4gXrBLjYiBielYy0J3fCLfq2HMD/K00WER8z4ZfURfiOuMbXGM= Archived-At: Subject: [OAUTH-WG] OAuth Sessions @ IETF 96 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 08:20:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qt3voIVKnnKtsSQT4QXmNhOXRAk4aP89H Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, you may have seen that the preliminary agenda for the Berlin IETF meeting is available online at https://datatracker.ietf.org/meeting/96/agenda.html We have two OAuth WG meetings this time and they are scheduled for: - Monday, 14:00-15:30 - Wednesday, 15:50-17:20 Ciao Hannes --Qt3voIVKnnKtsSQT4QXmNhOXRAk4aP89H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXZ6c1AAoJEGhJURNOOiAtJCEH/11kszwC5oUlkOvlT+9aTt0m pf4uRvzqJXBcp0LiVzCOuBm6bl3BTzMb84mTCevSElBMWiDdsrl9m24KndGUgrr9 TArdve23gDebQYlJfEcWnNJ2PR95s5fbVNOcOI/9KwkwvBIJ1WRk0jcPoopyX5Ta X5RZ01CkZLjpcoCkXa3IfOqCUgc5yA9DYpIkovaHyNwNNyuI0buW5xk0YzNl+X2V oVwRpT3kJmc2fJUgX4fXC80k3XVLraRUcjA4LfkJ4sXbJaEVrZtcqYqPr7xnjWAk ycXKFpWkAacDY/dD9qHQ8hK7Qed/7l5P7wuz3MAE7EaavQGQYslaQ8kO37go/wc= =kRKq -----END PGP SIGNATURE----- --Qt3voIVKnnKtsSQT4QXmNhOXRAk4aP89H-- From nobody Mon Jun 20 10:16:57 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE12012D806 for ; Mon, 20 Jun 2016 10:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gdygg-AZihv for ; Mon, 20 Jun 2016 10:16:54 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA50A12D5B5 for ; Mon, 20 Jun 2016 10:16:53 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id 5so136794806ioy.1 for ; Mon, 20 Jun 2016 10:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=Awp6zmDiVUWMQ4700IXjxugHn4KuBJ8ZiIoljr1Uues=; b=nE/KPhXEooQcCBmvuu1MZHKfMb7F8XK1lnYlt2pfqJ7kYVX/112PqEBMYuYT7mvkvd 77BIVo8uPrJsgNioM6mUNYmdOyZ+4fduKNt19oR/QJ76AVmUlvuvRNc6bhmAAUS1d6ct P7MiVrlPeRJ8AhUa78a7RS2a7SsVVaRjJDwkk= 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; bh=Awp6zmDiVUWMQ4700IXjxugHn4KuBJ8ZiIoljr1Uues=; b=BvzWkR+bBdge8SQxmGKRHtIucZLRREdO6MwkOLmQmP2AvoJ8TlNpJPTVCLDWMMrdPG G9Bpt5TMvLvWV8DMrdjgOI6/MfP0Je3/I3BvJ9T7HM1cWHCVZ1kbGwa/WcKit814u00v wxqx72AQVHqODgzKvI3r8nWRMe2V7hsDEgSqRJdv5TCnwbSJbNbQxdr/dBPw0/66wD6u yi4heK62nztJZol/g6/kzvcyIdURr5ajMwhRqK6qLb6riHRLwdMDtNNjgKsjqCnfOfnr rpKuiaALGmC2kNoNwV6AmtE6QJufE/D2LI80rW0dwpSUvqk8K4zQ9ij6/sQXCYCkNMQm fgiA== X-Gm-Message-State: ALyK8tJX4ZWw+wQKXv1ZGrbuYHH+OLytyA7oFvaQDA4n/hzs8piBQoV5/JHXcOF6pireffYPAoS2mh/E8b20VTUZ X-Received: by 10.107.8.220 with SMTP id h89mr24673119ioi.95.1466443013133; Mon, 20 Jun 2016 10:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.155 with HTTP; Mon, 20 Jun 2016 10:16:23 -0700 (PDT) From: Brian Campbell Date: Mon, 20 Jun 2016 11:16:23 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a113f980ae1cb810535b8de0c Archived-At: Subject: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 17:16:56 -0000 --001a113f980ae1cb810535b8de0c Content-Type: text/plain; charset=UTF-8 A good while back in an off list conversation about Token Exchange, Chuck Mortimore mentioned that they "had a use-case for custom claims in where they essentially wanted to carry along metadata about a client or device for association to objects in our cloud." As a result of that conversation I added the bullet item to the Open Issues section that says, "Provide a way to include supplementary claims or information in the request that would/could potentially be included in the issued token.", which has just been kinda sitting there ever since with no action being taken on it. I recently had the opportunity to see Chuck present about some work that they are doing for IoT, which utilizes a number of items from this WG including Token Exchange. It turns out that they were able to accommodate that use-case of expressing metadata about a client or device by using the actor_token. There's a paper about the work at https://www.salesforceidentity.info/Using_Asset_Tokens.pdf if anyone is interested in more details. Because the use-case behind that open issue is met by the existing constructs of the document, I'm proposing that no new parameters or tokens be introduced and that the open issue be removed and considered done in the next revision of the Token Exchange draft. Please speak up soon, if you believe this is a mistake. Thanks, Brian --001a113f980ae1cb810535b8de0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A good while back in an off list conversation ab= out Token Exchange, Chuck Mortimore mentioned that they "had a use-cas= e for custom claims in where they essentially wanted to carry along metadat= a about a client or device for association to objects in our cloud." A= s a result of that conversation I added the bullet item to the Open Issues = section that says, "Provide a way to include supplementary claims or i= nformation in the request that would/could potentially be included in the i= ssued token.", which has just been kinda sitting there ever since with= no action being taken on it.

I recently had = the opportunity to see Chuck present about some work that they are doing fo= r IoT, which utilizes a number of items from this WG including Token Exchan= ge. It turns out that they were able to accommodate that use-case of expres= sing metadata about a client or device by using the actor_token.=C2=A0 Ther= e's a paper about the work at https://www.salesforceidentity.info/Using_Asset_Tokens.pdf if anyon= e is interested in more details.

Becau= se the use-case behind that open i= ssue is met by the existing constructs of the document, I'm prop= osing that no new parameters or tokens be introduced and that the open issu= e be removed and considered done in the next revision of the Token Exchange= draft. Please speak up soon, if you believe this is a mistake.
<= div>

Thanks,
Brian
=C2= =A0

=C2=A0 =C2=A0
--001a113f980ae1cb810535b8de0c-- From nobody Mon Jun 20 11:52:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1E612D51A for ; Mon, 20 Jun 2016 11:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wduZf9vx1rlH for ; Mon, 20 Jun 2016 11:52:46 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB6512D65E for ; Mon, 20 Jun 2016 11:47:16 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id f6so40893805ith.0 for ; Mon, 20 Jun 2016 11:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=IC4lHkrSNPXzt5Vebo+OEUYKkISBAxY+S0sMFRFkUag=; b=onr+TxSOhqsSoulr5NPZtmXq0m0up/QohVxdf2m/b5vruRMV4OU6JqpASANqpXrAEL I2el3+yc6CLB/AIBhrdUqUOlL4zzgt7kkZP0MQpPNteN1PXJk3sDXYZXV6DhszR+PlDF LqZb/vkWiPyt9hs9W7Bat1ZprJ00iS7mGOWgw= 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; bh=IC4lHkrSNPXzt5Vebo+OEUYKkISBAxY+S0sMFRFkUag=; b=XvlwO/5QxD0lpXytR/6Ovw9qoXm3peS5K4iCrRyS2YIMTKSdsMB+Hc3HVEcPHKgiTF ebzCFk0xX+ZvttVrzXwgdVCgoHXxUYPaRUkwS9LVn9RXGcklVIDwvQlCpGUJa3RNhd6J P47liUuO53En/NdMX2ZnTv26Zm17v0uuzylZVfW3oyDcYiB+z0lGqdbTvXbZuKLycYxt 6BpBBhivEUlsWZSTy04mhKeJCVsb+pqjs9c/kuuRxGtq/BU7Ly2AnSKb9nrbPwzNXo+W //FBiFbF8t8u7FjgHCdR6JrFIMsliCpRfBxn2Tn7+L2bia0SljN3VZ5USyaKbsJ2clHm 8vDg== X-Gm-Message-State: ALyK8tKMPojYZf8dKCVJGi0vZcpzKfAYjzLwontEQmTfFvnASyGp0kxsJxeqTsQEJ/LWlVP4Gtnd4IkLYV3tmwbZ X-Received: by 10.36.4.23 with SMTP id 23mr1309870itb.11.1466448435287; Mon, 20 Jun 2016 11:47:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.155 with HTTP; Mon, 20 Jun 2016 11:46:45 -0700 (PDT) From: Brian Campbell Date: Mon, 20 Jun 2016 12:46:45 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11c141b61134a40535ba22e6 Archived-At: Subject: [OAUTH-WG] Token Exchange's act and may_act claims also registered for Introspection Endpoint responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:52:48 -0000 --001a11c141b61134a40535ba22e6 Content-Type: text/plain; charset=UTF-8 The question of if the act and may_act claims defined in Token Exchange should also be registered/defined for Introspection Endpoint responses was raised on this list a while back. Not much was said about it at the time but I did put an issue in github to keep track of it. I'd like to close out that issue and I believe that it does make sense to also register those two claims as Introspection Response members. Do any WG members have strong feelings one way or the other about that? In the absence of strong objections, I plan to make the change in the next revision. --001a11c141b61134a40535ba22e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The question of if the act and may_act claims defined= in Token Exchange should also be registered/defined for Introspection Endp= oint responses was raised on this list a while back. Not much was said abou= t it at the time but I did put an issue in github to keep track of it. I= 9;d like to close out that issue and I believe that it does make sense to a= lso register those two claims as Introspection Response members.

Do any WG members have strong feelings one way or the other about that?= In the absence of strong objections, I plan to make the change in the next= revision.




--001a11c141b61134a40535ba22e6-- From nobody Mon Jun 20 12:13:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809DC12D67F for ; Mon, 20 Jun 2016 12:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZKqBsI_AKd6 for ; Mon, 20 Jun 2016 12:13:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A19112D65E for ; Mon, 20 Jun 2016 12:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PA8W9NF8TsaXVsKefko2yQLH73KCoANoKJreV09/gSk=; b=Jf2YxVF3jsBmc3Ug7DGdcFdqR3gQlmKHPr8DkLq+RvUtDHUPYeV51N3xwAtVlBOL7qKaMK547pIPmRen0oCYc04CDUza/mv1in6YurQ5UAi8/tOJXdepyiBDjQ/SMdOdlBsouiSObMwhIGPTJ1CRY7DCa9Id0BQhaRiCTDY4g0c= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Mon, 20 Jun 2016 19:13:31 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0523.015; Mon, 20 Jun 2016 19:13:31 +0000 From: Anthony Nadalin To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request Thread-Index: AQHRyxeTSgu9ki0C/EibknSPwB+m/5/yuUpA Date: Mon, 20 Jun 2016 19:13:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [131.107.174.172] x-ms-office365-filtering-correlation-id: e2428160-00a1-4fe2-22f7-08d3993ef7f8 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 6:pdw8lgYJ/zlCpemhsCeYAxhO3JJ72ugJzH3rNHZX71xIZMQUiJmZmbk456UWEsEFTRf0i3HCnm0Yr32Cczr6j7thxdGK9Svv/fQm5MTq5PISFuyKrpWkNDkeRe/k8lKHjT+pfcLoyzHhbggMAsXnxDJVJatAfciSKhp15UIJj7G6W/Vk4tl8jz5MgnVmQC9CSKfLvkiQBZJLVLHO41JKCgVU1Mrl8QqcD7CAeHU8lI1KaK3PFmbnj6iJPW7XHnxoZ5HW/Kq0nZ5rvYrFXI8ksxcUMrxACy4x3gfvsssMt7HcGHgvO/V8kqxttZ/BA652zhN6reO7jOz3Zbuzcj9fHw==; 5:cZ0dWcrOyvhQ+QoedzaeSajYevG7Me8Ot/BztabIQ8/FzKL7qgStK0nKfW3/profPkZLp0E2N6XAw/5K4V+5UkzDkk7N6yMKVSORJrfVpeMw19wUiqBTUQYYADNEFix7sI0xx7vUpmQ30MDj0gSqzQ==; 24:nGGBG5WcH4nHpYUdAmbolpLuSijkYzO0uDEKkpu68ktFJ41fGL47PMrTKCVZFWUhIWp2X0bF5tuhznTa728dfxSN/6hzRnQwwuYLuRFfE7Q=; 7:mxNiLa1/1oyhLF7u/K8dZSvf6kCJW9z/PY/PX7NdE2Vo2VO35cOMFahoNU0sM8e8Wqv8LDbxt6lVsdPqBkBZTN5aaXW+b+bUNWBvvcZYQ+m0SYY4IK3HYWz09zGWC/Ff/XmbTE/qc/GaSMbhA4v/ZPhYOMvZbgkk6/7I6Y7Mba6arpCQTzXDkk4AjXnvvAZ14aZxf3c6HCTOm3LkzouJ75ljnIgD6o2I2KAJMnA5U+WRjUX0tsHY/F5LocS0anGx x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(377454003)(199003)(189002)(19580395003)(19617315012)(5005710100001)(77096005)(8990500004)(106356001)(10290500002)(10400500002)(33656002)(19609705001)(790700001)(3280700002)(586003)(105586002)(87936001)(3660700001)(2900100001)(86362001)(2906002)(5003600100003)(7696003)(10090500001)(3846002)(6116002)(102836003)(2950100001)(16236675004)(106116001)(15975445007)(76576001)(74316001)(86612001)(81166006)(99286002)(8676002)(81156014)(19625215002)(7846002)(8936002)(5002640100001)(66066001)(19580405001)(97736004)(107886002)(5001770100001)(189998001)(54356999)(76176999)(50986999)(19300405004)(7906002)(68736007)(101416001)(122556002)(92566002)(9686002)(7736002)(11100500001)(42262002)(6606295002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123424E66646E2C7E5B45929A62A0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2016 19:13:31.3936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Subject: Re: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 19:13:35 -0000 --_000_BN3PR0301MB123424E66646E2C7E5B45929A62A0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U291bmRzIGFwcHJvcHJpYXRlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBNb25kYXksIEp1bmUg MjAsIDIwMTYgMTA6MTYgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb T0FVVEgtV0ddIGNsb3NpbmcgYW4gb3BlbiBpc3N1ZSBhYm91dCBzdXBwbGVtZW50YXJ5IGluZm8g aW4gdGhlIFRva2VuIEV4Y2hhbmdlIHJlcXVlc3QNCg0KQSBnb29kIHdoaWxlIGJhY2sgaW4gYW4g b2ZmIGxpc3QgY29udmVyc2F0aW9uIGFib3V0IFRva2VuIEV4Y2hhbmdlLCBDaHVjayBNb3J0aW1v cmUgbWVudGlvbmVkIHRoYXQgdGhleSAiaGFkIGEgdXNlLWNhc2UgZm9yIGN1c3RvbSBjbGFpbXMg aW4gd2hlcmUgdGhleSBlc3NlbnRpYWxseSB3YW50ZWQgdG8gY2FycnkgYWxvbmcgbWV0YWRhdGEg YWJvdXQgYSBjbGllbnQgb3IgZGV2aWNlIGZvciBhc3NvY2lhdGlvbiB0byBvYmplY3RzIGluIG91 ciBjbG91ZC4iIEFzIGEgcmVzdWx0IG9mIHRoYXQgY29udmVyc2F0aW9uIEkgYWRkZWQgdGhlIGJ1 bGxldCBpdGVtIHRvIHRoZSBPcGVuIElzc3VlcyBzZWN0aW9uIHRoYXQgc2F5cywgIlByb3ZpZGUg YSB3YXkgdG8gaW5jbHVkZSBzdXBwbGVtZW50YXJ5IGNsYWltcyBvciBpbmZvcm1hdGlvbiBpbiB0 aGUgcmVxdWVzdCB0aGF0IHdvdWxkL2NvdWxkIHBvdGVudGlhbGx5IGJlIGluY2x1ZGVkIGluIHRo ZSBpc3N1ZWQgdG9rZW4uIiwgd2hpY2ggaGFzIGp1c3QgYmVlbiBraW5kYSBzaXR0aW5nIHRoZXJl IGV2ZXIgc2luY2Ugd2l0aCBubyBhY3Rpb24gYmVpbmcgdGFrZW4gb24gaXQuDQpJIHJlY2VudGx5 IGhhZCB0aGUgb3Bwb3J0dW5pdHkgdG8gc2VlIENodWNrIHByZXNlbnQgYWJvdXQgc29tZSB3b3Jr IHRoYXQgdGhleSBhcmUgZG9pbmcgZm9yIElvVCwgd2hpY2ggdXRpbGl6ZXMgYSBudW1iZXIgb2Yg aXRlbXMgZnJvbSB0aGlzIFdHIGluY2x1ZGluZyBUb2tlbiBFeGNoYW5nZS4gSXQgdHVybnMgb3V0 IHRoYXQgdGhleSB3ZXJlIGFibGUgdG8gYWNjb21tb2RhdGUgdGhhdCB1c2UtY2FzZSBvZiBleHBy ZXNzaW5nIG1ldGFkYXRhIGFib3V0IGEgY2xpZW50IG9yIGRldmljZSBieSB1c2luZyB0aGUgYWN0 b3JfdG9rZW4uICBUaGVyZSdzIGEgcGFwZXIgYWJvdXQgdGhlIHdvcmsgYXQgaHR0cHM6Ly93d3cu c2FsZXNmb3JjZWlkZW50aXR5LmluZm8vVXNpbmdfQXNzZXRfVG9rZW5zLnBkZjxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3 dy5zYWxlc2ZvcmNlaWRlbnRpdHkuaW5mbyUyZlVzaW5nX0Fzc2V0X1Rva2Vucy5wZGYmZGF0YT0w MSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M2YjhkMGExZjQyNDk0MjhhNDhlNzA4 ZDM5OTJlYjBlYSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT0x S1pTMXFtdU9oU0FDR0JxbjBLVElZbTFLWUlycURaSWxZdUlXMXNTNTJvJTNkPiBpZiBhbnlvbmUg aXMgaW50ZXJlc3RlZCBpbiBtb3JlIGRldGFpbHMuDQpCZWNhdXNlIHRoZSB1c2UtY2FzZSBiZWhp bmQgdGhhdCBvcGVuIGlzc3VlIGlzIG1ldCBieSB0aGUgZXhpc3RpbmcgY29uc3RydWN0cyBvZiB0 aGUgZG9jdW1lbnQsIEknbSBwcm9wb3NpbmcgdGhhdCBubyBuZXcgcGFyYW1ldGVycyBvciB0b2tl bnMgYmUgaW50cm9kdWNlZCBhbmQgdGhhdCB0aGUgb3BlbiBpc3N1ZSBiZSByZW1vdmVkIGFuZCBj b25zaWRlcmVkIGRvbmUgaW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIFRva2VuIEV4Y2hhbmdl IGRyYWZ0LiBQbGVhc2Ugc3BlYWsgdXAgc29vbiwgaWYgeW91IGJlbGlldmUgdGhpcyBpcyBhIG1p c3Rha2UuDQoNClRoYW5rcywNCkJyaWFuDQoNCg0KDQo= --_000_BN3PR0301MB123424E66646E2C7E5B45929A62A0BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9z ZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvdW5kcyBhcHByb3By aWF0ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+ PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIEp1bmUgMjAsIDIwMTYgMTA6MTYgQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRo ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBj bG9zaW5nIGFuIG9wZW4gaXNzdWUgYWJvdXQgc3VwcGxlbWVudGFyeSBpbmZvIGluIHRoZSBUb2tl biBFeGNoYW5nZSByZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkEgZ29vZCB3aGlsZSBi YWNrIGluIGFuIG9mZiBsaXN0IGNvbnZlcnNhdGlvbiBhYm91dCBUb2tlbiBFeGNoYW5nZSwgQ2h1 Y2sgTW9ydGltb3JlIG1lbnRpb25lZCB0aGF0IHRoZXkgJnF1b3Q7aGFkIGEgdXNlLWNhc2UgZm9y IGN1c3RvbSBjbGFpbXMgaW4gd2hlcmUgdGhleSBlc3NlbnRpYWxseSB3YW50ZWQgdG8gY2Fycnkg YWxvbmcgbWV0YWRhdGEgYWJvdXQgYSBjbGllbnQNCiBvciBkZXZpY2UgZm9yIGFzc29jaWF0aW9u IHRvIG9iamVjdHMgaW4gb3VyIGNsb3VkLiZxdW90OyBBcyBhIHJlc3VsdCBvZiB0aGF0IGNvbnZl cnNhdGlvbiBJIGFkZGVkIHRoZSBidWxsZXQgaXRlbSB0byB0aGUgT3BlbiBJc3N1ZXMgc2VjdGlv biB0aGF0IHNheXMsICZxdW90O1Byb3ZpZGUgYSB3YXkgdG8gaW5jbHVkZSBzdXBwbGVtZW50YXJ5 IGNsYWltcyBvciBpbmZvcm1hdGlvbiBpbiB0aGUgcmVxdWVzdCB0aGF0IHdvdWxkL2NvdWxkIHBv dGVudGlhbGx5IGJlDQogaW5jbHVkZWQgaW4gdGhlIGlzc3VlZCB0b2tlbi4mcXVvdDssIHdoaWNo IGhhcyBqdXN0IGJlZW4ga2luZGEgc2l0dGluZyB0aGVyZSBldmVyIHNpbmNlIHdpdGggbm8gYWN0 aW9uIGJlaW5nIHRha2VuIG9uIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5JIHJlY2VudGx5IGhhZCB0aGUgb3Bwb3J0dW5pdHkgdG8gc2VlIENodWNr IHByZXNlbnQgYWJvdXQgc29tZSB3b3JrIHRoYXQgdGhleSBhcmUgZG9pbmcgZm9yIElvVCwgd2hp Y2ggdXRpbGl6ZXMgYSBudW1iZXIgb2YgaXRlbXMgZnJvbSB0aGlzIFdHIGluY2x1ZGluZyBUb2tl biBFeGNoYW5nZS4gSXQgdHVybnMNCiBvdXQgdGhhdCB0aGV5IHdlcmUgYWJsZSB0byBhY2NvbW1v ZGF0ZSB0aGF0IHVzZS1jYXNlIG9mIGV4cHJlc3NpbmcgbWV0YWRhdGEgYWJvdXQgYSBjbGllbnQg b3IgZGV2aWNlIGJ5IHVzaW5nIHRoZSBhY3Rvcl90b2tlbi4mbmJzcDsgVGhlcmUncyBhIHBhcGVy IGFib3V0IHRoZSB3b3JrIGF0DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5zYWxlc2ZvcmNlaWRlbnRp dHkuaW5mbyUyZlVzaW5nX0Fzc2V0X1Rva2Vucy5wZGYmYW1wO2RhdGE9MDElN2MwMSU3Y3Rvbnlu YWQlNDBtaWNyb3NvZnQuY29tJTdjNmI4ZDBhMWY0MjQ5NDI4YTQ4ZTcwOGQzOTkyZWIwZWElN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTFLWlMxcW11T2hT QUNHQnFuMEtUSVltMUtZSXJxRFpJbFl1SVcxc1M1Mm8lM2QiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LHNlcmlmIj5odHRwczovL3d3dy5zYWxl c2ZvcmNlaWRlbnRpdHkuaW5mby9Vc2luZ19Bc3NldF9Ub2tlbnMucGRmPC9zcGFuPjwvYT4gaWYg YW55b25lIGlzIGludGVyZXN0ZWQgaW4gbW9yZSBkZXRhaWxzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPkJlY2F1c2UgdGhlIHVzZS1jYXNlIGJlaGluZCB0aGF0IG9wZW4gaXNzdWUgaXMgbWV0 IGJ5IHRoZSBleGlzdGluZyBjb25zdHJ1Y3RzIG9mIHRoZSBkb2N1bWVudCwgSSdtIHByb3Bvc2lu ZyB0aGF0IG5vIG5ldyBwYXJhbWV0ZXJzIG9yIHRva2VucyBiZSBpbnRyb2R1Y2VkIGFuZCB0aGF0 IHRoZSBvcGVuIGlzc3VlIGJlIHJlbW92ZWQgYW5kIGNvbnNpZGVyZWQNCiBkb25lIGluIHRoZSBu ZXh0IHJldmlzaW9uIG9mIHRoZSBUb2tlbiBFeGNoYW5nZSBkcmFmdC4gUGxlYXNlIHNwZWFrIHVw IHNvb24sIGlmIHlvdSBiZWxpZXZlIHRoaXMgaXMgYSBtaXN0YWtlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJp YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQom bmJzcDsgJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB123424E66646E2C7E5B45929A62A0BN3PR0301MB1234_-- From nobody Mon Jun 20 12:45:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02F612D749 for ; Mon, 20 Jun 2016 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wykMs-olxGxy for ; Mon, 20 Jun 2016 12:45:53 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72D812D745 for ; Mon, 20 Jun 2016 12:45:53 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id 5so140461553ioy.1 for ; Mon, 20 Jun 2016 12:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=QfwcnNtyD8HNyGoxP0hWb/uGqXP8SKnqPDiuFOPeS7k=; b=GxSc9sjw0ke9RVmDDTkGaPPIpBpGR+6pmizmB5aen7IsEsJdaJdVG2RwNg5tyOy1zk bOgSyCff65hBj5kVp+rDp9HP6Vh9olFrP3oMDP5wS1DygyeU86y0IqYAfQ/j4j0xd3es waFdqROUSylkW4jKq6Wil/N5p89vXoM9yz/OA= 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; bh=QfwcnNtyD8HNyGoxP0hWb/uGqXP8SKnqPDiuFOPeS7k=; b=CAWulcJ9ZYfAnW6C2dB0pm07ttYOWZ36dXDprVUW/LsMWFImPArOgqfhQcV7GVAhA8 08ALFdZGWA0ca7SulepPaHXjGKCugtPxlyo/qrUMlhTv97Ic7Z6PB1giGG0/8szJfpLg 7S1MCnIbGZl3CbFjGg/Rj11KNvLhO8zZGAuem9A9+vSWvUVR9LYJonRkfqKdJSmBzWze XZhWU5lNM6IQBSORypN+0j9pzhVZoBrs1p1zRpyBFwpbSRdQK9q9CvsaVDNHQ6LQWsxE UlPhyhtPdlzOL+L8kQh2OnmF2475CnxiDQx+te3kp7uPJSv1WDOgj/otcdrp22bgOBMs TcNg== X-Gm-Message-State: ALyK8tIk//6SAuUFaZmhmdPm+bhFmgOH/4WG4l7nU7uOFv7e4pEvDOXH4Zin+dAhKySWQ4+62H1nGitb+hRq7N4f X-Received: by 10.107.28.14 with SMTP id c14mr24705454ioc.86.1466451952792; Mon, 20 Jun 2016 12:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.155 with HTTP; Mon, 20 Jun 2016 12:45:23 -0700 (PDT) From: Brian Campbell Date: Mon, 20 Jun 2016 13:45:23 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a1140aa78ba10d40535baf3a1 Archived-At: Subject: [OAUTH-WG] another open issue in Token Exchange: short names for some common token type identifiers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 19:45:55 -0000 --001a1140aa78ba10d40535baf3a1 Content-Type: text/plain; charset=UTF-8 Another open issue in Token Exchange is the question of should there be a way to use short names for some common token type identifiers? URIs are necessary in the general case for extensibility and vendor/deployment specific types. But short names like access_token and jwt are aesthetically appealing and slightly more efficient in terms of bytes on the wire and url-encoding. There seemed to be rough consensus in Prague ('No objection to use the proposed mechanism for a default prefix' from https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for supporting a shorthand for commonly used types - i.e. when the value does not contain a ":" character, the value would be treated as though urn:ietf:params:oauth:token-type: were prepended to it. So, for example, the value jwt for requested_token_type would be semantically equivalent to urn:ietf:params:oauth:token-type:jwt and the value access_token would be equivalent to urn:ietf:params:oauth:token-type:access_token. However, it was a fairly brief discussion during a long meeting in Prague with rather fatigued participants. And it has since been suggested that making protocol participants handle both syntaxes will unnecessarily complicate the supporting code. With that suggestion the text that allowed for the short names was pulled out of a pre-published draft of the draft. So the WG draft currently only supports the use of full URIs as the *_type values. I'd like to close out this issue sometime soon. So please speak now, if you have a preference. I was personally in favor of allowing for the shorthand but don't feel all that strongly about it. So unless there's some support expressed on this list for allowing the shorthand, I'm inclined to leave the core text of the draft as it is thus using only full URI values and remove the open issue about it in the next revision. --001a1140aa78ba10d40535baf3a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another open issue in Token Exchange is the question = of should there be a way to use short names for some common token type iden= tifiers?

URIs are necessary in the general case for extensibility an= d vendor/deployment specific types. But short names like access_token and j= wt are aesthetically appealing and slightly more efficient in terms of byte= s on the wire and url-encoding.

There seemed to be rough consensus = in Prague ('No objection to use the proposed mechanism for a default pr= efix' from https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for supporting a shorthand for commonly used types - i.e. when the valu= e does not contain a ":" character, the value would be treated as= though urn:ietf:params:oauth:token-type: were prepended to it. So, for exa= mple, the value jwt for requested_token_type would be semantically equivale= nt to urn:ietf:params:oauth:token-type:jwt and the value access_token would= be equivalent to urn:ietf:params:oauth:token-type:access_token.

Ho= wever, it was a fairly brief discussion during a long meeting in Prague wit= h rather fatigued participants. And it has since been suggested that making= protocol participants handle both syntaxes will unnecessarily complicate t= he supporting code. With that suggestion the text that allowed for the shor= t names was pulled out of a pre-published draft of the draft. So the WG dra= ft currently only supports the use of full URIs as the *_type values.
<= br>
I'd like to close out this issue sometime soon. So please spea= k now, if you have a preference. I was personally in favor of allowing for = the shorthand but don't feel all that strongly about it. So unless ther= e's some support expressed on this list for allowing the shorthand, I&#= 39;m inclined to leave the core text of the draft as it is thus using only = full URI values and remove the open issue about it in the next revision.

=C2=A0


--001a1140aa78ba10d40535baf3a1-- From nobody Mon Jun 20 13:37:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2990212D7B0 for ; Mon, 20 Jun 2016 13:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdGicXYn5CcQ for ; Mon, 20 Jun 2016 13:37:51 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A9F12D7A3 for ; Mon, 20 Jun 2016 13:37:51 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id a5so57288204ita.1 for ; Mon, 20 Jun 2016 13:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=1PBKeIQh4UUEK0FOGMo1rlSwy8LOe91KSTD6rAJbyZw=; b=mQRgtf09IPQxmqR7cry/T11/tsXw8FVY6fbI1OE32JNZBKgDcaKGZp94iMdTzf/geg K2RR+B6O+ITQyewdLRWT9/xym1d/vz8Gr8aCnUr3g35kHoCXsBmkLoAfim3Qrlgs+F/r mGJjzBwss/I5dchVyHS9sdvt8EBbaOsj087fs= 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; bh=1PBKeIQh4UUEK0FOGMo1rlSwy8LOe91KSTD6rAJbyZw=; b=W/kLAwmicp3RBhPyPWn5a4wQN252zyj7dMreYejQGcea3hXB+q9zRzt7RjEIW7LRwg DmbCVMOfwzcy7EzZnhP31wGAXnE3IWAIIaqDogLLXb/vlRUYR3F/RcOKXXI3xDjaK2LS 93/6cdvN/RMZJPN9lGs9ZkI/YMAu2ZPkzJR3AezpXOPvxH7Q6xE+Lq2Wnx/SoxXB0PYx L32KpoaQUnTZF6T2IXjRrHy/v5rfmN6fOVKJvIEJ62LRCIkDZaoXNmHpN/oH3cclFc9Y 6NBahJhxtVTsnKkPgc+g0siWJ7Ims5513YJb16lflAFHaDVSKjnYChDkT/7Jl5LDyr8O SqNw== X-Gm-Message-State: ALyK8tInYokrM2X7Z1EebNrif8BNxr+aBXpAVRvrncXRfKM1NXi5dVnAcB2rzXRZX/pn3U5dZI9fJ+8L93TuJ6cy X-Received: by 10.36.4.23 with SMTP id 23mr2099527itb.11.1466455070986; Mon, 20 Jun 2016 13:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.155 with HTTP; Mon, 20 Jun 2016 13:37:21 -0700 (PDT) From: Brian Campbell Date: Mon, 20 Jun 2016 14:37:21 -0600 Message-ID: To: oauth , Justin Richer Content-Type: multipart/alternative; boundary=001a11c141b695f27c0535bbad36 Archived-At: Subject: [OAUTH-WG] nit RFC 7662 Errata? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 20:37:53 -0000 --001a11c141b695f27c0535bbad36 Content-Type: text/plain; charset=UTF-8 Because of my earlier message about act and may_act also being registered for Introspection Endpoint responses I was looking at the IANA Considerations of RFC 7662 and it seems like some text in the 2nd paragraph of Sec 3.1 was inadvertently copied from the IANA Considerations RFC 7591 / Token Introspection and not changed to match the new context. The text in Token Introspection says, "OAuth registration client metadata names and descriptions are registered..." which doesn't seem right. I'd expect it to say something like, "OAuth token introspection response parameters are registered...". Is this the sort of thing that should be reported as errata? --001a11c141b695f27c0535bbad36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Because of my earlier message about act and ma= y_act also being registered for Introspection Endpoint responses I was = looking at the IANA Considerations of RFC 7662 and it seems like some text = in the 2nd paragraph of Sec 3.1 was inadvertently copied from the IANA Considerations RFC 7591 / Toke= n Introspection and not changed to match the new context.

The text in Token Introspection says, "OAuth registration client meta= data names and descriptions are registered..." which doesn't seem = right. I'd expect it to say something like, "OAuth token introspec= tion response parameters are registered...".

Is this the= sort of thing that should be reported as errata?




--001a11c141b695f27c0535bbad36-- From nobody Mon Jun 20 14:02:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6A912DA3F for ; Mon, 20 Jun 2016 14:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95hN6O4-pV6c for ; Mon, 20 Jun 2016 14:02:42 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D49C12D7C1 for ; Mon, 20 Jun 2016 14:02:42 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id t74so134473406ioi.0 for ; Mon, 20 Jun 2016 14:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zl92r4xq0rTpx981EKsWwlpjdxXle0yDcIt+4wl8QO0=; b=F0aBkuYJWwO2xNoTtobg2aW9WF30EDhs+oqOxHX+50PMpm2Z+nHJ0DW+NbeADX+Sxc 5SUBzATyANbe6Glm6NtWpzwsSnduWbJVd9w4JKdVj/jbWAMRqmOPQ1U19AD9QXVnD6eb IWf1oK6OM2Ean11b0csRqtUc4rcK9w9uc/92g= 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; bh=zl92r4xq0rTpx981EKsWwlpjdxXle0yDcIt+4wl8QO0=; b=lzHqbEaPvXBafrfoIe2esI4yEbegja+/9A7gmnPvP4jT5qBa9frbQ2LGOvXVaAUrnK dFYlfmkrRaQgsXcFwcU11P58Dev6pihWMhrPaCk8wkXrrAdb+C4qdRlXTiuVPM3WdjtJ XtY2Mb/hlZoudbFMMhSmAgsdhQmaLjMVi3Sa7PRGZ2lR869T15B2yPyoSINQRMB+nrBQ 1ztWBbj6malJiUAHQSF9b5Zis/Rtr9lspzBvwfSDzH1ruhYyynVneHbKi5DL0DGO/lBl gWoruQBkwPs53ffkxo63YyHtpwA1Bxz/9evAhs3iUNHAeYwSEz16K2tjiKGuHFKi6HrZ qpuQ== X-Gm-Message-State: ALyK8tIIK/LoyVv3G6X1IzAq1gpB3D0a6g/F3aXBqfHD6o9WFmTiWCU5l8l8lqZrDNEY6Go+YLbdQuieO45Kn6xa X-Received: by 10.107.8.220 with SMTP id h89mr26268904ioi.95.1466456561410; Mon, 20 Jun 2016 14:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.155 with HTTP; Mon, 20 Jun 2016 14:02:12 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 20 Jun 2016 15:02:12 -0600 Message-ID: To: oauth , Justin Richer Content-Type: multipart/alternative; boundary=001a113f980a6bfb3c0535bc06f3 Archived-At: Subject: Re: [OAUTH-WG] nit RFC 7662 Errata? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:02:43 -0000 --001a113f980a6bfb3c0535bc06f3 Content-Type: text/plain; charset=UTF-8 Some good irony in that message as I made a very similar mistake. The "IANA Considerations RFC 7591 / Token Introspection" link/text should say "IANA Considerations RFC 7591 / Client Registration ". Sigh. On Mon, Jun 20, 2016 at 2:37 PM, Brian Campbell wrote: > Because of my earlier message about act and may_act also being registered > for Introspection Endpoint responses > I was > looking at the IANA Considerations of RFC 7662 and it seems like some text > in the 2nd paragraph of Sec 3.1 > was inadvertently > copied from the IANA Considerations RFC 7591 / Token Introspection > and not changed to > match the new context. > > The text in Token Introspection says, "OAuth registration client metadata > names and descriptions are registered..." which doesn't seem right. I'd > expect it to say something like, "OAuth token introspection response > parameters are registered...". > > Is this the sort of thing that should be reported as errata? > > > > > --001a113f980a6bfb3c0535bc06f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some good irony in that message as I made a very simi= lar mistake. The "IANA Considerations RFC 7591 / Token Introspection&q= uot; link/text should say "IANA Considerations RFC 7591 / Client Registration&quo= t;.

Sigh.=C2=A0

On Mon, Jun 20, 2016 at 2:37 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Because of my earlier message abou= t act and may_act also being registered for Introspecti= on Endpoint responses I was looking at the IANA Considerations of RFC 7= 662 and it seems like some text in the 2nd paragraph of Sec 3.1 was = inadvertently copied from the IANA Considerations RFC 7591 / Token Intro= spection and not changed to match the new context.

The te= xt in Token Introspection says, "OAuth registration client metadata na= mes and descriptions are registered..." which doesn't seem right. = I'd expect it to say something like, "OAuth token introspection re= sponse parameters are registered...".

Is this the sort o= f thing that should be reported as errata?





--001a113f980a6bfb3c0535bc06f3-- From nobody Mon Jun 20 14:22:02 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956012DA50 for ; Mon, 20 Jun 2016 14:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsKTpV9nkURL for ; Mon, 20 Jun 2016 14:22:00 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42D312DA57 for ; Mon, 20 Jun 2016 14:22:00 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id f30so134103681ioj.2 for ; Mon, 20 Jun 2016 14:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=OnzTG3oKOoKZNx3JgRlWbecF4Uv5eZV7i8LKeABtb1Y=; b=Aza3NRegNZfHJQkxvgU5hw9uBctLTvNin0dEuvF5eiQqWdKGsWB1ltqXTyBE+8Y6Y+ C2mPiyQdIOug/NKFHIIBzLksWAEFAZRR1sifOG7aMV7XFm7GML8NSohznrlw2W+1TM7y udWWm8khpY7/FO8tpww0bPQqDcUqzrericg34= 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; bh=OnzTG3oKOoKZNx3JgRlWbecF4Uv5eZV7i8LKeABtb1Y=; b=HjPJJYe83PXLgPIkIt1CCpUne2+OKUbeeymgJAn4F8zVwAbwSsHIz6CBBtpwRedtW9 L9DM88HTbGDYXg86Tiigi8Shf8A4lZGxEqJB+UExH6NXLEi5/j/Cwq9J23ZelACI7iaz ydKnpbJZ1NvUmtq9cqb2ytqvIE+NJmGiltAX/7hPz1Ok1gBKZFr76Ek2gbUbIkReJ47i wUYQ7BaGonqDvng7r3XUzkyixGntiKyfC1pxS8aZf96lVs/tyyZANiciGXBoUfy7Sox5 l9IlsdxlD39IgrxogUtaodWJpRvQyEpeAKhrho3cOk9FUkTISdzMNDXBsMDSy5bfNdLE U47A== X-Gm-Message-State: ALyK8tI7RlwNtQubsaRXCy7MNxCMcZvvlkw6/yUoG5bV7Q0c3sEkirG45wgBLrGH5YPoYVULaM0N9sy/yTd/PByQ X-Received: by 10.107.44.71 with SMTP id s68mr25595802ios.174.1466457719658; Mon, 20 Jun 2016 14:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.139.133 with HTTP; Mon, 20 Jun 2016 14:21:30 -0700 (PDT) From: Brian Campbell Date: Mon, 20 Jun 2016 15:21:30 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11399c907568e40535bc4bdb Archived-At: Subject: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:22:02 -0000 --001a11399c907568e40535bc4bdb Content-Type: text/plain; charset=UTF-8 There is a somewhat poorly worded open issue in Token Exchange about being able to represent the client in the token. There is currently no standard claim for the client in JWT while Token Introspection defines a "client_id" parameter. It's maybe not the ideal place for it but Token Exchange could define such a claim for JWT. I'm looking for some feedback from the WG on if/how to proceed with this in Token Exchange. As I see it, there are basically 3 options: 1) Define and register a "client_id" JWT claim (consistent with the name in Token Introspection) to carry the client id of the OAuth 2.0 client that requested the token. 2) Define and register a "cid" JWT claim (consistent with the shorter names typical for JWT) to carry the client id of the OAuth 2.0 client that requested the token. 3) Do not define/register any new JWT claim for the client identifier (in the Token Exchange draft anyway). Feedback/preferences would be appreciated from the WG so as to make some progress on the draft. If pressed, I guess I'd lean towards option #1 myself. --001a11399c907568e40535bc4bdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is a somewhat poorly worded= open issue in Token Exchange about being able to represent the client in t= he token.

There is currently no standard claim for the client in JW= T while Token Introspection defines a "client_id" parameter. It&#= 39;s maybe not the ideal place for it but Token Exchange could define such = a claim for JWT.

I'm looking for some feedback = from the WG on if/how to proceed with this in Token Exchange. As I see it, = there are basically 3 options:

1) Define and register a "= client_id" JWT claim (consistent with the name in Token Introspection)= to carry the client id of the OAuth 2.0 client that requested the token.
2) Define and register a "cid" JWT claim (consistent = with the shorter names typical for JWT) to carry the client id of the OAuth= 2.0 client that requested the token.

3) Do not define/registe= r any new JWT claim for the client identifier (in the Token Exchange draft = anyway).

Feedback/preferences would be appreciated from = the WG so as to make some progress on the draft.

If pres= sed, I guess I'd lean towards option #1 myself.



--001a11399c907568e40535bc4bdb-- From nobody Mon Jun 20 15:14:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9502312DA80 for ; Mon, 20 Jun 2016 15:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH3lJMznG14c for ; Mon, 20 Jun 2016 15:14:18 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C2812D67D for ; Mon, 20 Jun 2016 15:14:18 -0700 (PDT) X-AuditID: 1209190c-473ff70000004085-28-57686ab83b92 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 (Symantec Messaging Gateway) with SMTP id B1.D0.16517.8BA68675; Mon, 20 Jun 2016 18:14:17 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u5KMEFou024038; Mon, 20 Jun 2016 18:14:16 -0400 Received: from [192.168.6.175] (ip-64-134-241-184.public.wayport.net [64.134.241.184]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5KMECZo019909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jun 2016 18:14:15 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Mon, 20 Jun 2016 18:14:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26C70593-212C-4798-A950-64D2C55AE99D@mit.edu> References: To: Brian Campbell X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrLszKyPc4N8vbYvV/28yWpx8+4rN gcljyZKfTB53j15kCWCK4rJJSc3JLEst0rdL4Mp4eGYLU0Eve8W7qYYNjDdZuxg5OSQETCTa v3cxdTFycQgJtDFJ3P+xkBXC2cgo0bNvNQtIlZDAZSaJs7sjQWxmAXWJP/MuMYPYvAJ6EpvW v2UCsYUFSiW2374LFmcTUJWYvqYFLM4pECjR/e042BwWoPj7e2uA4hxgc9pPukCM1JZYtvA1 1EgriRsTj7NBrA2QuNh7nx3EFhHQl7j9dA47xNGyEk9OLmKZwCgwC8lFs5BcNAvJ2AWMzKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0DfVyM0v0UlNKNzGCg1SSZwfjmTdehxgFOBiVeHgrDDPC hVgTy4orcw8xSnIwKYnyMisDhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwqqQD5XhTEiurUovy YVLSHCxK4ryF+0+HCQmkJ5akZqemFqQWwWRlODiUJHhPZQI1ChalpqdWpGXmlCCkmTg4QYbz AA1/BlLDW1yQmFucmQ6RP8Woy7Hgx+21TEIsefl5qVLivJwgRQIgRRmleXBzQMnFoe3jjleM 4kBvCfMuBKniASYmuEmvgJYwAS1Z1p8OsqQkESEl1cAoEswTeXw5u69X1qyuGIZfOrpPH7+/ smFPYfsPMfcql87nTxdyPXE45rDg9p/3OZZSp1375ObcNtve9tntAKth0ap/nHsdnv7z97OV d+nJbNWw059qtflr4fRml6k/82yble7nn5+/e3vgO96VbFOeTM15JOtzs8hH0tR8219d7c9x p5KEvq5SYinOSDTUYi4qTgQAk7WRzQkDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Exchange's act and may_act claims also registered for Introspection Endpoint responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 22:14:20 -0000 Makes sense to me. =E2=80=94 Justin > On Jun 20, 2016, at 2:46 PM, Brian Campbell = wrote: >=20 > The question of if the act and may_act claims defined in Token = Exchange should also be registered/defined for Introspection Endpoint = responses was raised on this list a while back. Not much was said about = it at the time but I did put an issue in github to keep track of it. I'd = like to close out that issue and I believe that it does make sense to = also register those two claims as Introspection Response members.=20 >=20 > Do any WG members have strong feelings one way or the other about = that? In the absence of strong objections, I plan to make the change in = the next revision.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jun 20 15:18:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE86812D1ED for ; Mon, 20 Jun 2016 15:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKRyEOzLcoIb for ; Mon, 20 Jun 2016 15:18:40 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0253E12D18C for ; Mon, 20 Jun 2016 15:18:39 -0700 (PDT) X-AuditID: 1209190c-45fff70000004085-a8-57686bbe7701 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CA.11.16517.EBB68675; Mon, 20 Jun 2016 18:18:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5KMIcVI005844; Mon, 20 Jun 2016 18:18:38 -0400 Received: from [192.168.6.175] (ip-64-134-241-184.public.wayport.net [64.134.241.184]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5KMI3N2020967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jun 2016 18:18:37 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_EA47DF3C-AEDB-43D3-AD90-DACFBE99EAF2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Mon, 20 Jun 2016 18:18:38 -0400 Message-Id: <988ECA60-58CE-42F5-9D39-D1038984E063@mit.edu> References: To: Brian Campbell X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0d2fnRFusO8tk8Xq/zcZLU6+fcXm wOSxZMlPJo+7Ry+yBDBFcdmkpOZklqUW6dslcGUcPLWbrWCfZsWrNTPZGhgXqHQxcnJICJhI 7FjTwNjFyMUhJNDGJNHUepMJwtnIKPH7yiKozGUmiQl3pjKDtDALJEgsO90PZvMK6ElsWv+W CcQWFtCROL28jRHEZhNQlZi+pgUszikQKHHq2AMwmwUo/uBfE5DNATRHXaL9pAvEGCuJ+x/n s0Dsmsoo0bT+NRtIQkRAX+L20znsEKfKSjw5uYhlAiP/LCRnzEJyBkRcW2LZwtfMELamxP7u 5SyY4hoSnd8msi5gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mil5pSuokRFNqckjw7 GM+88TrEKMDBqMTDW2GYES7EmlhWXJl7iFGSg0lJlJdZGSjEl5SfUpmRWJwRX1Sak1p8iFGC g1lJhFclHSjHm5JYWZValA+TkuZgURLnLdx/OkxIID2xJDU7NbUgtQgmK8PBoSTBuzoLqFGw KDU9tSItM6cEIc3EwQkynAdo+BWQGt7igsTc4sx0iPwpRkUpcd4AkIQASCKjNA+uF5R6HNo+ 7njFKA70ijDvFJAqHmDagut+BTSYCWjwsv50kMEliQgpqQbGqJRHJbNSJ9te9rmfVDztserm oNZHy+P/f85ZP+GFrqPonNe376VJ3ag4XLpQZGm8fejNlrr75ZpXPhzaKnfmFdvzx/lCh5U3 754SGfAyxTfm853f03qLLd7aNoqWlccxBYexFnh8blSI+PBe/UfM17dWfgnJTyf/+H5wqv20 ty463YcMPf7uVGIpzkg01GIuKk4EAOmEo3MYAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] nit RFC 7662 Errata? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 22:18:42 -0000 --Apple-Mail=_EA47DF3C-AEDB-43D3-AD90-DACFBE99EAF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s definitely a mistake, and I think an errata is the right = track for it. Not positive though =E2=80=94 chairs?=20 =E2=80=94 Justin > On Jun 20, 2016, at 5:02 PM, Brian Campbell = wrote: >=20 > Some good irony in that message as I made a very similar mistake. The = "IANA Considerations RFC 7591 / Token Introspection" link/text should = say "IANA Considerations RFC 7591 / Client Registration = ". >=20 > Sigh. =20 >=20 > On Mon, Jun 20, 2016 at 2:37 PM, Brian Campbell = > wrote: > Because of my earlier message about act and may_act also being = registered for Introspection Endpoint responses = I was = looking at the IANA Considerations of RFC 7662 and it seems like some = text in the 2nd paragraph of Sec 3.1 = was inadvertently = copied from the IANA Considerations RFC 7591 / Token Introspection = and not changed to = match the new context.=20 >=20 > The text in Token Introspection says, "OAuth registration client = metadata names and descriptions are registered..." which doesn't seem = right. I'd expect it to say something like, "OAuth token introspection = response parameters are registered...".=20 >=20 > Is this the sort of thing that should be reported as errata?=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_EA47DF3C-AEDB-43D3-AD90-DACFBE99EAF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It=E2=80=99s definitely a mistake, and I think an errata is = the right track for it. Not positive though =E2=80=94 chairs? 

 =E2=80=94 = Justin

On Jun 20, 2016, at 5:02 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Some good irony = in that message as I made a very similar mistake. The "IANA = Considerations RFC 7591 / Token Introspection" link/text should say "IANA = Considerations RFC 7591 / Client Registration".

Sigh. 

On Mon, = Jun 20, 2016 at 2:37 PM, Brian Campbell <bcampbell@pingidentity.com> = wrote:
Because of my earlier message = about act and may_act also being registered for = Introspection Endpoint responses I was looking at the IANA = Considerations of RFC 7662 and it seems like some text in the 2nd = paragraph of Sec 3.1 was inadvertently copied from = the IANA Considerations RFC 7591 / Token = Introspection and not changed to match the new context.

The text in Token Introspection says, = "OAuth registration client metadata names and descriptions are = registered..." which doesn't seem right. I'd expect it to say something = like, "OAuth token introspection response parameters are registered...". =

Is this the sort of thing that = should be reported as errata?





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

= --Apple-Mail=_EA47DF3C-AEDB-43D3-AD90-DACFBE99EAF2-- From nobody Mon Jun 20 15:22:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1B312D6B3 for ; Mon, 20 Jun 2016 15:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Cq7Hf1BaAGt for ; Mon, 20 Jun 2016 15:22:17 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C04712D50D for ; Mon, 20 Jun 2016 15:22:17 -0700 (PDT) X-AuditID: 12074424-90fff700000018c9-73-57686c9813f3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 4A.9E.06345.89C68675; Mon, 20 Jun 2016 18:22:16 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5KMMF9t006132; Mon, 20 Jun 2016 18:22:16 -0400 Received: from [192.168.6.175] (ip-64-134-241-184.public.wayport.net [64.134.241.184]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5KMMC99021895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jun 2016 18:22:15 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Mon, 20 Jun 2016 18:22:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62762050-2D3E-4837-A707-74265326FFBA@mit.edu> References: To: Brian Campbell X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nojsjJyPcYNsnKYvV/28yWpx8+4rN gcljyZKfTB53j15kCWCK4rJJSc3JLEst0rdL4Mq4/LmDpeAhd8WrV5ENjHs5uxg5OSQETCSm /bvNCGILCbQxSbT9Fupi5AKyNzJKXF54nh3CucwkcfzKbiaQKmYBdYk/8y4xg9i8AnoSm9a/ BYsLC3hKPO4/AhZnE1CVmL6mBSzOKRAocfr2RTCbBSh+ddp1oKEcYHPaT7pAjNSWWLbwNdRI K4m9PZfYIA4KkPjS/oodxBYR0Je4/XQOO8TRshJPTi5imcAoMAvJRbOQXDQLydgFjMyrGGVT cqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL9FJTSjcxgoPURWUHY3eP9yFGAQ5GJR5eBf2McCHW xLLiytxDjJIcTEqivMzKQCG+pPyUyozE4oz4otKc1OJDjBIczEoivCrpQDnelMTKqtSifJiU NAeLkjgvIwMDg5BAemJJanZqakFqEUxWhoNDSYL3YxZQo2BRanpqRVpmTglCmomDE2Q4D9Bw 4WyQ4cUFibnFmekQ+VOMilLivAkgCQGQREZpHlwvKIk4tH3c8YpRHOgVYd4gkCoeYAKC634F NJgJaPCy/nSQwSWJCCmpBkaWqfe++HgvZnl6cnXumm8LWX4e/1b9LPIX481PtQfaJ/zhmcPx apJhpojKTmt78arjF5taLer4z8d+5Q5mSZbblpz5quhjxdGE6U+7pRgiPjLaM++JdDU3VX6t c7NXdYPKqhWWWo5frwf0FnPNy7t88KHHvLlvhTcx5Obc6vwS37B61cFcl5VKLMUZiYZazEXF iQDe9sLD/QIAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 22:22:20 -0000 +1 for =E2=80=9Ccid=E2=80=9D, consistent with other JWT claims. =E2=80=94 Justin > On Jun 20, 2016, at 5:21 PM, Brian Campbell = wrote: >=20 > There is a somewhat poorly worded open issue in Token Exchange about = being able to represent the client in the token.=20 >=20 > There is currently no standard claim for the client in JWT while Token = Introspection defines a "client_id" parameter. It's maybe not the ideal = place for it but Token Exchange could define such a claim for JWT. >=20 > I'm looking for some feedback from the WG on if/how to proceed with = this in Token Exchange. As I see it, there are basically 3 options: >=20 > 1) Define and register a "client_id" JWT claim (consistent with the = name in Token Introspection) to carry the client id of the OAuth 2.0 = client that requested the token. >=20 > 2) Define and register a "cid" JWT claim (consistent with the shorter = names typical for JWT) to carry the client id of the OAuth 2.0 client = that requested the token. >=20 > 3) Do not define/register any new JWT claim for the client identifier = (in the Token Exchange draft anyway).=20 >=20 > Feedback/preferences would be appreciated from the WG so as to make = some progress on the draft.=20 >=20 > If pressed, I guess I'd lean towards option #1 myself.=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jun 21 07:35:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E6F12D08D for ; Tue, 21 Jun 2016 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfNX7ZE9YpSH for ; Tue, 21 Jun 2016 07:34:58 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C2712B069 for ; Tue, 21 Jun 2016 07:34:58 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id c73so23261901qkg.2 for ; Tue, 21 Jun 2016 07:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JWnG5T+gdraoRBCiDpgWJBN+cHCo2wF+3aKrr3qWn4s=; b=GKYObzS7GD74h2SxKhb0y0Yx6D0bDCcfhteGtWNXTFVESoYVRSjVItOr9GndTimrMi FzhQ4K1V8h4mOMYJhAVhuRloMU/rVcVp4AqUjdLxODa4lRLhMNkR88o2L8Z8pP6KoUnf 2SgY7lPdoadr737IYnotqnmBDnGlwzwBo0CxZCmdfeSPUebwXOMtx+1LkICxs2lnDS6t 44TjOqC4o+eCeyrmx+/N3utO9AYZYWk1zbJCyC0TVsRfzu4feZltkAHBqEpoKuYW+5Sl noNa7GZTtXWSIwOFciXsDUBBdKuBvZU6aVrEiLjBIiKEbITlDFwsDBKwSkwHVgoewPIy n1ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JWnG5T+gdraoRBCiDpgWJBN+cHCo2wF+3aKrr3qWn4s=; b=WAJyPfRV0JcDHeaySjKa4hPgHokOs4hl95vsYyitrr+xQlfglf3QGBwSPaS8rANWxS I2TeJJxXqHo/ufFlh2ThkxLtw8m1PUUcsji2LuKUg6hf9x530DWTRsGKyZA60FGMCY/v utJsedUnO7UG31OoKYR1tI75NyAYpdBxY/J7Ao5IZ2/ljDuqTFs2siwrkxiJq7wNd1jN uKgUjcTRC8hAK/M/wmKHnkWtPZXLkZlzQPTwEaOXYwmTkeq1B582z9YJRhqZwhMtWByx LuXcVo2sdtMXCROpkOeHm1pvD/u0aP2oJxxiK/qA2R0ibyzUiUkImaoUYkxJv3mpeN0p 6NDg== X-Gm-Message-State: ALyK8tIdCjwnJ00ut+IiA5yUHzYcc+OcpQYHE0XXzrG5AA71zd/6r44+xYpsgRm42gQotQ== X-Received: by 10.55.184.5 with SMTP id i5mr30452195qkf.33.1466519697530; Tue, 21 Jun 2016 07:34:57 -0700 (PDT) Received: from [192.168.1.39] ([191.115.37.147]) by smtp.gmail.com with ESMTPSA id w67sm23444161qkd.26.2016.06.21.07.34.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 07:34:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <62762050-2D3E-4837-A707-74265326FFBA@mit.edu> Date: Tue, 21 Jun 2016 10:34:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86C7F65C-398C-46BF-95C5-46B4CA5EEDC1@ve7jtb.com> References: <62762050-2D3E-4837-A707-74265326FFBA@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 14:35:00 -0000 I prefer =E2=80=9Ccid=E2=80=9D as the claim name rather than trying to = match the parameter name. John B. > On Jun 20, 2016, at 6:22 PM, Justin Richer wrote: >=20 > +1 for =E2=80=9Ccid=E2=80=9D, consistent with other JWT claims. >=20 > =E2=80=94 Justin >=20 >> On Jun 20, 2016, at 5:21 PM, Brian Campbell = wrote: >>=20 >> There is a somewhat poorly worded open issue in Token Exchange about = being able to represent the client in the token.=20 >>=20 >> There is currently no standard claim for the client in JWT while = Token Introspection defines a "client_id" parameter. It's maybe not the = ideal place for it but Token Exchange could define such a claim for JWT. >>=20 >> I'm looking for some feedback from the WG on if/how to proceed with = this in Token Exchange. As I see it, there are basically 3 options: >>=20 >> 1) Define and register a "client_id" JWT claim (consistent with the = name in Token Introspection) to carry the client id of the OAuth 2.0 = client that requested the token. >>=20 >> 2) Define and register a "cid" JWT claim (consistent with the shorter = names typical for JWT) to carry the client id of the OAuth 2.0 client = that requested the token. >>=20 >> 3) Do not define/register any new JWT claim for the client identifier = (in the Token Exchange draft anyway).=20 >>=20 >> Feedback/preferences would be appreciated from the WG so as to make = some progress on the draft.=20 >>=20 >> If pressed, I guess I'd lean towards option #1 myself.=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jun 21 08:35:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F2512D97C for ; Tue, 21 Jun 2016 08:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syMQxbhCtbk7 for ; Tue, 21 Jun 2016 08:35:04 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08C712D978 for ; Tue, 21 Jun 2016 08:35:03 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id g127so5436926ith.1 for ; Tue, 21 Jun 2016 08:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=Q1XK5mI8Inb7EqO3XrJdcLcAUtq1EgHRdVb2bJXHZCI=; b=T1DuRxSmILZbNxdWQT8dzEaZq9LSEw1JiMKvhX6DOTQlU15G6aQpKxV7NfSfVimxzM uFC756X1s+27J93htntOLtT9M6t0L6Jzmm1WakwkYCztH8a2RV8Xabfzy/ZEiMCywWWp Uvne3nJ04B53+S4RNzVEbZBjk9qDcwSMY3hYc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=Q1XK5mI8Inb7EqO3XrJdcLcAUtq1EgHRdVb2bJXHZCI=; b=B0NluZXLPQGp0pt0Ghgwx7L6G1Zulmhq0W9sjwCMU0xvz5PDMoAu2213kvGprvFOEo otV/I7/sJ0CIc+PQUkPJLusIVdZwDAmlbebufeV8JQ5WM7T7lo4mUMthNXCoBbicjUz7 LGPnWu9tUMBuvJQEpY8b3ZYiiemkuAHsFPcfnTaDukREeztRxQ2klUFENlDOX6brNQdW F/dJOTqt2EXXQvwysMmE3zbAnmJFcXkfvjeerHxxAM0iGuoKQOeP5QCW9ZoYkygBD/e4 /D8muEpRyPr3AQX5dqrM/oA+kDeJ4KIkBC1pNJ3yDwbQdximEsCYLboypjxQ6iA/qjJN 5fxw== X-Gm-Message-State: ALyK8tIvL2xYEnngBvcfD1BGSMfFQ3f5NpUamSlY4MPvOv51F4pdS514v5uyr4tX2cQi5WCdz+Enbb8Zs7N3OIoZ X-Received: by 10.36.4.210 with SMTP id 201mr6821498itb.1.1466523302981; Tue, 21 Jun 2016 08:35:02 -0700 (PDT) From: Chuck Mortimore Mime-Version: 1.0 (1.0) References: <62762050-2D3E-4837-A707-74265326FFBA@mit.edu> <86C7F65C-398C-46BF-95C5-46B4CA5EEDC1@ve7jtb.com> In-Reply-To: <86C7F65C-398C-46BF-95C5-46B4CA5EEDC1@ve7jtb.com> Date: Tue, 21 Jun 2016 08:35:02 -0700 Message-ID: <3101288118852482777@unknownmsgid> To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:35:05 -0000 +1 for cid > On Jun 21, 2016, at 7:35 AM, John Bradley wrote: > > I prefer =E2=80=9Ccid=E2=80=9D as the claim name rather than trying to ma= tch the parameter name. > > John B. >> On Jun 20, 2016, at 6:22 PM, Justin Richer wrote: >> >> +1 for =E2=80=9Ccid=E2=80=9D, consistent with other JWT claims. >> >> =E2=80=94 Justin >> >>> On Jun 20, 2016, at 5:21 PM, Brian Campbell wrote: >>> >>> There is a somewhat poorly worded open issue in Token Exchange about be= ing able to represent the client in the token. >>> >>> There is currently no standard claim for the client in JWT while Token = Introspection defines a "client_id" parameter. It's maybe not the ideal pla= ce for it but Token Exchange could define such a claim for JWT. >>> >>> I'm looking for some feedback from the WG on if/how to proceed with thi= s in Token Exchange. As I see it, there are basically 3 options: >>> >>> 1) Define and register a "client_id" JWT claim (consistent with the nam= e in Token Introspection) to carry the client id of the OAuth 2.0 client th= at requested the token. >>> >>> 2) Define and register a "cid" JWT claim (consistent with the shorter n= ames typical for JWT) to carry the client id of the OAuth 2.0 client that r= equested the token. >>> >>> 3) Do not define/register any new JWT claim for the client identifier (= in the Token Exchange draft anyway). >>> >>> Feedback/preferences would be appreciated from the WG so as to make som= e progress on the draft. >>> >>> If pressed, I guess I'd lean towards option #1 myself. >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jun 21 14:49:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A5D12DE33 for ; Tue, 21 Jun 2016 14:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELXAanOcOXZ8 for ; Tue, 21 Jun 2016 14:49:48 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FD012DE30 for ; Tue, 21 Jun 2016 14:49:48 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id g13so21965587ioj.1 for ; Tue, 21 Jun 2016 14:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HqatZt8aLiFHgN4eSMy7pJmh55TYqSPzeTm6gN+Us1Q=; b=k1bmrSHWQjxmKu+RE6Bh5iSjRJgGj8IlcQues+PIM386fh9KEs/DP/pHD1eAvXyqOj u3qwCyB3V+W+a15EfKck3lrrdcADPS9fEbFSuG6n+ahVC29QnhxLan8iDMiLyPv/49yu 2ekVeJavrJAK6MOp/cNj7pmf7BBljVcQg28mk= 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; bh=HqatZt8aLiFHgN4eSMy7pJmh55TYqSPzeTm6gN+Us1Q=; b=P6gw7d9vIgPeQhtINgrB1OA0R3/eV3mDENT521voybzsOerKZe1M1R2HZzAQxk6MuS HYpup69JWP/EFJ/nkPExQfG5X9JA+qx5WVOPSAPIDL31TRkYIiFz+YL9ezQGDhH3OFxR d+Tp81vb/2DRVLFoVhp/P1LnuYXDxdlunUEjP5lmMjbEhhVPoF3+FezRpefn/JhqCd3t Wc9Rl4c9yQXjvJ2Ob66WnNxAjTUcuMY7BDiwNIBDYFsH3psZVoKdXL3cxSyAkP82r660 t/DIb3FVSkYLle6D0yR9TOw7Nu4lB8HrErhaoH37BTq21Tqs8gy++7V4K4xQiNC9YDc7 UE+Q== X-Gm-Message-State: ALyK8tLLbp5FxFOorIVY4Jkb11vw1peOERmlfpMI39++ZNxZUPUCzeKQvIKRVwPYQs/pHoPMex6Ug3c9S6p5rFXu X-Received: by 10.107.8.220 with SMTP id h89mr35628107ioi.95.1466545787697; Tue, 21 Jun 2016 14:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.155 with HTTP; Tue, 21 Jun 2016 14:49:18 -0700 (PDT) In-Reply-To: <3101288118852482777@unknownmsgid> References: <62762050-2D3E-4837-A707-74265326FFBA@mit.edu> <86C7F65C-398C-46BF-95C5-46B4CA5EEDC1@ve7jtb.com> <3101288118852482777@unknownmsgid> From: Brian Campbell Date: Tue, 21 Jun 2016 15:49:18 -0600 Message-ID: To: Chuck Mortimore Content-Type: multipart/alternative; boundary=001a113f980ab9157b0535d0cc5e Archived-At: Cc: "" Subject: Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:49:50 -0000 --001a113f980ab9157b0535d0cc5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Seems like there's roughly rough condenses for "cid". Thanks. On Tue, Jun 21, 2016 at 9:35 AM, Chuck Mortimore wrote: > +1 for cid > > > On Jun 21, 2016, at 7:35 AM, John Bradley wrote: > > > > I prefer =E2=80=9Ccid=E2=80=9D as the claim name rather than trying to = match the > parameter name. > > > > John B. > >> On Jun 20, 2016, at 6:22 PM, Justin Richer wrote: > >> > >> +1 for =E2=80=9Ccid=E2=80=9D, consistent with other JWT claims. > >> > >> =E2=80=94 Justin > >> > >>> On Jun 20, 2016, at 5:21 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >>> > >>> There is a somewhat poorly worded open issue in Token Exchange about > being able to represent the client in the token. > >>> > >>> There is currently no standard claim for the client in JWT while Toke= n > Introspection defines a "client_id" parameter. It's maybe not the ideal > place for it but Token Exchange could define such a claim for JWT. > >>> > >>> I'm looking for some feedback from the WG on if/how to proceed with > this in Token Exchange. As I see it, there are basically 3 options: > >>> > >>> 1) Define and register a "client_id" JWT claim (consistent with the > name in Token Introspection) to carry the client id of the OAuth 2.0 clie= nt > that requested the token. > >>> > >>> 2) Define and register a "cid" JWT claim (consistent with the shorter > names typical for JWT) to carry the client id of the OAuth 2.0 client tha= t > requested the token. > >>> > >>> 3) Do not define/register any new JWT claim for the client identifier > (in the Token Exchange draft anyway). > >>> > >>> Feedback/preferences would be appreciated from the WG so as to make > some progress on the draft. > >>> > >>> If pressed, I guess I'd lean towards option #1 myself. > >>> > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113f980ab9157b0535d0cc5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Seems like there's roughly rough condenses for "c= id". Thanks.

On Tue, Jun 21, 2016 at 9:35 AM, Chuck Mortimore <cmorti= more@salesforce.com> wrote:
+1 for cid

> On Jun 21, 2016, at 7:35 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> I prefer =E2=80=9Ccid=E2=80=9D as the claim name rather than trying to= match the parameter name.
>
> John B.
>> On Jun 20, 2016, at 6:22 PM, Justin Richer <jricher@MIT.EDU> wrote:
>>
>> +1 for =E2=80=9Ccid=E2=80=9D, consistent with other JWT claims. >>
>> =E2=80=94 Justin
>>
>>> On Jun 20, 2016, at 5:21 PM, Brian Campbell <bcampbell@pingidentity.com> wrote: >>>
>>> There is a somewhat poorly worded open issue in Token Exchange= about being able to represent the client in the token.
>>>
>>> There is currently no standard claim for the client in JWT whi= le Token Introspection defines a "client_id" parameter. It's = maybe not the ideal place for it but Token Exchange could define such a cla= im for JWT.
>>>
>>> I'm looking for some feedback from the WG on if/how to pro= ceed with this in Token Exchange. As I see it, there are basically 3 option= s:
>>>
>>> 1) Define and register a "client_id" JWT claim (cons= istent with the name in Token Introspection) to carry the client id of the = OAuth 2.0 client that requested the token.
>>>
>>> 2) Define and register a "cid" JWT claim (consistent= with the shorter names typical for JWT) to carry the client id of the OAut= h 2.0 client that requested the token.
>>>
>>> 3) Do not define/register any new JWT claim for the client ide= ntifier (in the Token Exchange draft anyway).
>>>
>>> Feedback/preferences would be appreciated from the WG so as to= make some progress on the draft.
>>>
>>> If pressed, I guess I'd lean towards option #1 myself.
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--001a113f980ab9157b0535d0cc5e-- From nobody Wed Jun 22 08:46:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AC812DE36 for ; Wed, 22 Jun 2016 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuHGccfLxZMt for ; Wed, 22 Jun 2016 08:45:58 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A016812D865 for ; Wed, 22 Jun 2016 08:34:01 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g13so40463150ioj.1 for ; Wed, 22 Jun 2016 08:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=t9ltQZIefumm+Q/yPwoD2BPJOII/enqCl5o30kax4qs=; b=GcTh856me+YghYB0apg/Mqdr+LfhWGvPCqHCl9KbddPiW9nmmObiqQBUnprNpPZZQf EtscwW3YUUJ3IOzdDNilcKCltmA28+NeVAJqefkd6+BDtWdcHEw4N48YW0LaR99VoBLR 0BAM07QGDDg7giGdHh/te/dyy29FtI7vrDoBU= 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:date :message-id:subject:from:to:cc; bh=t9ltQZIefumm+Q/yPwoD2BPJOII/enqCl5o30kax4qs=; b=bCdWRBwDPMxk76wtShiNiQ8oJrSBQqmDKSpxBv/4X8++0RreVNvA2pkEisw5kAl8mH OAGXvWfaH1CKjlAiRDvCGlU+99hYOX7R4lmYVwqmJnMW2ICfWkVOI7a0EXrySXgBiA2e ke0CIJHxTGjmZj/iv5+vY0FbbNWAdeO3gYgdSvR2IBhDhMPjf2ae7bWbPHcPWaQX3LiR CV/zoJUJfM3lEIa4PjMW9q2e1LSBSKHfQ6BymPj+gPpw5mlAR6EsogUYBMDGgprt2yVl K7NEOnWiBQDt5IN438cSmzzolx7hjWy4ogJ8SPdCNN+oFxVREHAo1Rd2tnrj8UDniZFk zFcQ== X-Gm-Message-State: ALyK8tIS/fJ+jDYdKJAwR8oQ/GvQBZCVzLbxneKUEkXg+kJBcrkLGuCM4b756YpSCBvmBgmnPxJLwFcY+7SoUaEH MIME-Version: 1.0 X-Received: by 10.107.44.71 with SMTP id s68mr40120084ios.174.1466609640755; Wed, 22 Jun 2016 08:34:00 -0700 (PDT) Received: by 10.79.28.140 with HTTP; Wed, 22 Jun 2016 08:34:00 -0700 (PDT) Received: by 10.79.28.140 with HTTP; Wed, 22 Jun 2016 08:34:00 -0700 (PDT) In-Reply-To: References: <62762050-2D3E-4837-A707-74265326FFBA@mit.edu> <86C7F65C-398C-46BF-95C5-46B4CA5EEDC1@ve7jtb.com> <3101288118852482777@unknownmsgid> Date: Wed, 22 Jun 2016 09:34:00 -0600 Message-ID: From: Brian Campbell To: Chuck Mortimore Content-Type: multipart/alternative; boundary=001a11399c90a976650535dfaa9d Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:46:05 -0000 --001a11399c90a976650535dfaa9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable er... s:/condenses/consensus/ Seems like there's roughly rough condenses for "cid". Thanks. On Tue, Jun 21, 2016 at 9:35 AM, Chuck Mortimore wrote: > +1 for cid > > > On Jun 21, 2016, at 7:35 AM, John Bradley wrote: > > > > I prefer =E2=80=9Ccid=E2=80=9D as the claim name rather than trying to = match the > parameter name. > > > > John B. > >> On Jun 20, 2016, at 6:22 PM, Justin Richer wrote: > >> > >> +1 for =E2=80=9Ccid=E2=80=9D, consistent with other JWT claims. > >> > >> =E2=80=94 Justin > >> > >>> On Jun 20, 2016, at 5:21 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >>> > >>> There is a somewhat poorly worded open issue in Token Exchange about > being able to represent the client in the token. > >>> > >>> There is currently no standard claim for the client in JWT while Toke= n > Introspection defines a "client_id" parameter. It's maybe not the ideal > place for it but Token Exchange could define such a claim for JWT. > >>> > >>> I'm looking for some feedback from the WG on if/how to proceed with > this in Token Exchange. As I see it, there are basically 3 options: > >>> > >>> 1) Define and register a "client_id" JWT claim (consistent with the > name in Token Introspection) to carry the client id of the OAuth 2.0 clie= nt > that requested the token. > >>> > >>> 2) Define and register a "cid" JWT claim (consistent with the shorter > names typical for JWT) to carry the client id of the OAuth 2.0 client tha= t > requested the token. > >>> > >>> 3) Do not define/register any new JWT claim for the client identifier > (in the Token Exchange draft anyway). > >>> > >>> Feedback/preferences would be appreciated from the WG so as to make > some progress on the draft. > >>> > >>> If pressed, I guess I'd lean towards option #1 myself. > >>> > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11399c90a976650535dfaa9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

er... s:/condenses/consensus/

Seems like t= here's roughly rough condenses for "cid". Thanks.

On Tue, Jun 21, 201= 6 at 9:35 AM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
+1 for cid

> On Jun 21, 2016, at 7:35 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> I prefer =E2=80=9Ccid=E2=80=9D as the claim name rather than trying to= match the parameter name.
>
> John B.
>> On Jun 20, 2016, at 6:22 PM, Justin Richer <jricher@MIT.EDU> wrote:
>>
>> +1 for =E2=80=9Ccid=E2=80=9D, consistent with other JWT claims. >>
>> =E2=80=94 Justin
>>
>>> On Jun 20, 2016, at 5:21 PM, Brian Campbell <bcampbell@pingidentity.co= m> wrote:
>>>
>>> There is a somewhat poorly worded open issue in Token Exchange= about being able to represent the client in the token.
>>>
>>> There is currently no standard claim for the client in JWT whi= le Token Introspection defines a "client_id" parameter. It's = maybe not the ideal place for it but Token Exchange could define such a cla= im for JWT.
>>>
>>> I'm looking for some feedback from the WG on if/how to pro= ceed with this in Token Exchange. As I see it, there are basically 3 option= s:
>>>
>>> 1) Define and register a "client_id" JWT claim (cons= istent with the name in Token Introspection) to carry the client id of the = OAuth 2.0 client that requested the token.
>>>
>>> 2) Define and register a "cid" JWT claim (consistent= with the shorter names typical for JWT) to carry the client id of the OAut= h 2.0 client that requested the token.
>>>
>>> 3) Do not define/register any new JWT claim for the client ide= ntifier (in the Token Exchange draft anyway).
>>>
>>> Feedback/preferences would be appreciated from the WG so as to= make some progress on the draft.
>>>
>>> If pressed, I guess I'd lean towards option #1 myself.
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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

--001a11399c90a976650535dfaa9d-- From nobody Fri Jun 24 04:10:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76ED12D0C7; Fri, 24 Jun 2016 04:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvCehclwKCBV; Fri, 24 Jun 2016 04:10:00 -0700 (PDT) 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 AAEC512D0BF; Fri, 24 Jun 2016 04:09:59 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.20]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M0gww-1bVSsE1KV4-00unBs; Fri, 24 Jun 2016 13:09:56 +0200 To: "Ace@ietf.org" , "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <576D1500.3030403@gmx.net> Date: Fri, 24 Jun 2016 13:09:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB" X-Provags-ID: V03:K0:zO4xZNfsMmZhLXzAe8QZcZO/f3YaJfMQtQWIE4oC3MFjgfXt624 6rf+OWASZLurr8pkzFsMpsTfuZutJi0VhJP/WUuQDCdTFlhv29x6u+HFEboWslWuotR48q/ PT3HUDzeGekfulkkO/SPEAbslAUcNnM2fJnAip5VKPloqtgWENAeaPd/2UDmNvkhXgA7TvY kq0rqpy06Ky74YqeDamhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:NT8ZL6wd/zE=:6AC3d8Gy7cr/miCuYAdJPH 62wMn2lV1PiyIjsmgwoTEawj+dtocdoeg5Xg2+PA/NTgQ3+1/pTIJfmZZ5UZXT+/xcxe3zVGd OJVbmHjs9ow0esjVaB7tyLoOS15u5778j6zEftEHwK3lAltoshY1xLruJUnlHd6o0oaRlrIaH h5E2FTWnM3fzXH0LPuDLyu+LgSmG9MjN65+JJb4xwWz8EHDde308KXaPBn8iMfP4Vedi+0RMp l5A0aBav8oz/h3oLKyMqc1VplJSwEJAF54KDICwbfUlatikjYYpqYFfMlF2xZe0YBywO9DMkP e9jsghWFx1H37s3qUGPhSQmfBGlENV51nAv3U3CHLozePD8rXnesCfN4fYjA054S/4muNbMiH QjUeWgxFzhp8Ge0Tvv8KTD+3+0yGkXVyDL8wTLig6gqxgsaEyWLN0aXyEbr0Kd7ymB2WfVo4n oBgi/33qu1YAzqhQAdBdZc//0SSNDIiH8aKoWXwKAiipV8dmFoBc5pAWLcfmNvbp0yuZjGbXE GW7m+OKHcYsmy5nO6JI85dgDOrPGKFHX6mgRqfU9oN+nVdLidl7gpUtIcDDsHHUKDg9aI9u1V z5oO9tcg1sMXN7/rCcQp69VV8qYLmNB+dN4ayj1GGfuDUL61QkGK3Ff4fTfTxMl+qbOVn7Cbm yJc4YfmJ0oMts+89xqB5VK6sAgcBeY3E1n4IIBR2UHBJu5I8umPsSc1m0OPezKhurAcGVVGql KWN0LyS0fZ350laPeDOv3tp6/dzjUG3ijnxU8d93O6X/AA4QWoJfOFxNk3g= Archived-At: Subject: [OAUTH-WG] Reminder: OAuth Security Workshop Registration Deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 11:10:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, if you are planning to attend the OAuth Security Workshop in Trier/Germany, 14th & 15th July (i.e, during the week before the Berlin IETF meeting) then please registering today (since today is the deadline)= =2E Here is the link to the webpage again: https://infsec.uni-trier.de/events/osw2016 I will again be an interesting security workshop. We have great keynote speakers, interesting papers, and also left time for discussing future work. Ciao Hannes --HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXbRUCAAoJEGhJURNOOiAtjRoH/iZhnP7h/+7XCEAGgretNzIs GClKEpYoBuGQNTJ96662udw7cPqQJcZJuVdon+DGoxwlvl5lzIFJaj2M258rOVQV IPIlj3uPHezN0Q+TFJ2D1a5u6m7YCYUWrUDmMBV0wXX08Fu/jxlI1GqaCCvSOUHG GE48S/8Ylr4T4mMmYIZEC3p/oj5H+meXYTqZuYjFFpdGti8bbQYZGbraGzuiR/tG Ea9/Lss1yHFr3MThuwFZbNiqcRbRttCC42huRBsOSaQSJTfiKthMbDm1uIKkfKDb zr/EBSIhG8jAUsNJsxNJf3dg3ACBRvsf4I6SmtdjGTr3W/PEtpL+QpJyof1xlqU= =G8qA -----END PGP SIGNATURE----- --HwSuAgEbDp8EiobdHQfTTdBgSEkCri6nB-- From nobody Fri Jun 24 09:04:44 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE1212DC99; Fri, 24 Jun 2016 09:00:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160050.10933.14909.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:50 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 96 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:50 -0000 Dear Hannes Tschofenig, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (1:30:00) Monday, Afternoon Session I 1400-1530 Room Name: Potsdam II size: 175 --------------------------------------------- oauth Session 2 (1:30:00) Wednesday, Afternoon Session II 1550-1720 Room Name: Lincke size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: core cose oauth saag lwig tokbind tls Special Requests: Please avoid conflict with sec area BoFs. Due a person from NIST attending the OAuth meeting could you schedule one OAuth session on Monday or Tuesday and none on Friday? --------------------------------------------------------- From nobody Mon Jun 27 05:18:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7012D0E2 for ; Mon, 27 Jun 2016 05:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSmcDEsQ8xeY for ; Mon, 27 Jun 2016 05:18:15 -0700 (PDT) Received: from mx2.uni-trier.de (mx2.uni-trier.de [136.199.224.18]) (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 2AC7F12D08C for ; Mon, 27 Jun 2016 05:18:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,536,1459807200"; d="scan'208";a="19543454" Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx2i.uni-trier.de with ESMTP; 27 Jun 2016 14:18:12 +0200 Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id 3F411408E9; Mon, 27 Jun 2016 14:18:12 +0200 (CEST) From: Daniel Fett To: "oauth@ietf.org" Message-ID: <57711984.5090207@uni-trier.de> Date: Mon, 27 Jun 2016 14:18:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Archived-At: Cc: Guido Schmitz Subject: [OAUTH-WG] Updated version of our paper (IdP Mix-Up and other attacks) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 12:18:18 -0000 Hi all, we released an updated version of our paper "A Comprehensive Formal Security Analysis of OAuth 2.0" in which we present the IdP Mix-Up attack. In this update, we clarified some of the assumptions for the IdP Mix-Up attack. We now also analyzed the resistance of OAuth against cross-site request forgery and found some new attacks. (We at least briefly described the attacks in separate posts here on the mailinglist over the last months.) Please find the updated paper here: https://arxiv.org/abs/1601.01229 Cheers, Daniel -- Informationssicherheit und Kryptografie Universität Trier - Tel. 0651 201 2847 - H436 From nobody Wed Jun 29 06:57:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2942212DE99 for ; Wed, 29 Jun 2016 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBeEZy4rHNHg for ; Wed, 29 Jun 2016 06:57:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 2AA4012DE9C for ; Wed, 29 Jun 2016 06:57:42 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.20]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MgKoE-1awixx0t1y-00NkjO for ; Wed, 29 Jun 2016 15:57:39 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5773D3D1.9070105@gmx.net> Date: Wed, 29 Jun 2016 15:57:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GGsl678ssjXkDdmoamiAqlWhusafsAfsq" X-Provags-ID: V03:K0:DauHB9I97LWtegLNpxPLDMHl9Wv6n0qRoPsu1dBNAJgv/4OsPhu iL278OIyHNXKiZvBETb7R6LvDGKDmFLv82CyFdUTkpeRID6H7xcEcAHa5ilyU+4cIQ2Aqnw 0SLJ1H0uGYhu52P5ENbd5WoV9zXzbJW6oDLzuO4+B0lY89fAW5qfT+Zum+PVkQg4tQVppAh /jjDKnFuZwrcoWTmo7hwg== X-UI-Out-Filterresults: notjunk:1;V01:K0:9GY/CLU2RMQ=:PAKk+aPmMzNPoB6Nw40ljm 5BOUB3V8FFnUIiiW2LGsxegCKavygaa9ykLFJ0MamN/UuwiePnvQjPFa7ZCeJxhtQbMdM5yA+ qJRDqYN2EjRAP+r4Y62DCfKNUecenfnihDmm5lzUX+BXrxYODfOA2z+PwX4Tp7HF580TZ6LGL A75jBkNtB+QK3EcU4cBhxOBbEatjqPHUNn7/W+N2e8WCYVuePsGfGes2H65qfqA7sp/Hec5m6 WkZTIXUw585/mmCwzlminURlLFMMadVvIyl0aIXUHq6FFHRsAIgbNUKXYy8Gnpi9HpFAaOpix OAEez/eV8OKiq42U/yO++dPk2FEODmR1CYEdwrCijF+vLNImwvoBP4eijqTr9TaHWiRxdWh01 dLHTGEU96nATvO80/xC4GHMhlwMtkHR2RZ4bvy0f61z+Rx+6ANQyN3CGqswvyzEUuM4L52Teu mz4Nqod/i+nC6UKYahCqoW4utTC19y1Nn46P7er0Bq6HnObnjyRa4C8igj8b6CUn5aUmljfmc 90FFLdWs8Mo9XTDu9JgIZIQTgXne9G3O2a05V2uiUE+9pB1H0PFxa9PCCbzFc8I9DpjT3Guls LFXdpap2g/yqq2WGj0snBPb4THBcWdNUrvg/VKHHGXQQr9dYuwZINBpwLj+OalM9VmmYiK3Pn gm/qi351STlBn4lELtHnZyjymrcxoWhsA06R8p03pBICXPc/Gg2/kM/ODkoEndoSoWf2ayfDi DnU5N1hIkcN1w3S5y22ixTncRMXXuqTz/AQ6gtyKjh+o8GNXHvVY4iWuCBg= Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 13:57:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GGsl678ssjXkDdmoamiAqlWhusafsAfsq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nat, Hi John, thanks for your work on draft-ietf-oauth-jwsreq. I would like to get the document ready for the IESG and have therefore reviewed it. Despite some minor issues I believe the document is in good shape. Here are my comments: ** Introduction The example request in the introduction is longer than 72 characters. s/textaual nature/textual nature s/The request may be encrypted so that end-to-end confidentiality may be obtained even if in the case TLS connection is terminated at a gateway or a similar device. /The request may be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at a gateway. FROM: 1. The request can be signed so that an integrity check can be implemented. If a suitable algorithm is used for the signing, then it will provide verification of the client making the request. TO: 1. The request may be signed so that the signer can be authenticated and the integrity of the request can be checked. There are a few cases that request by reference are useful such as: FROM: 1. When it is desirable to reduced the size of transmitted request. Since we are using application layer security, it may substantially increase the size of the request particulary in the case of using public key cryptography. TO: 1. When it is desirable to reduce the size of transmitted request. The use of application layer security increases the size of the request, particularly when public key cryptography is used. You write: 2. Static signature: The client can make a signed Request Object and put it at a place that the Authorization Server can access. This may just be done by a client utility or other process, so that the private key does not have to reside on the client, simplifying programming. Downside of it is that the signed portion just become a token. The downside is that there is that there is no indication of freshness and I believe this is what you mean by "just became a token". I am not sure that the term 'static signature' is the right term here. Just delete the 'Static Signature:'. Is the JWT a good match to encode the parameters of the request? Why don't you just use a regular JSON object and apply the JOSE security mechanisms to it. Section 3: Request Object You write: " To encrypt, JWE [RFC7516] is used. Note that JWE is always integrity protected, so if only integrity protection is desired, JWS signature is not needed. " I think the last sentence should say: "... if only integrity protection is desired then JWE is not needed." You write: " It can also be signed then encrypted. This is sometimes desired to reduced the repudiation risk from the point of view of the receiver. In this case, it MUST be signed then encrypted, with the result being a Nested JWT, as defined in JWT [RFC7519]. "client_secret What do you mean by "reduced the repudiation risk"? It may help if you reference the example in Appendix A.2 of RFC 7519 regarding a nest JWT. You write: " REQUIRED OAuth 2.0 Authorization Request parameters that are not included in the Request Object MUST be sent as query parameters. If a required parameter is missing from both the query parameters and the Request Object, the request is malformed. " s/REQUIRED/Required That's a bit unfortunate that you have to send parameters twice -- once as query parameters and then again in the request object. Is there no better way to design this? Section 4: Authorization Request You write: " The authorization request object MAY be signed AND/OR encrypted. " Why is this sentence needed when you have extensively spoken about this topic already in earlier chapters? If you include it then write "The authorization request object MAY be signed and/or encrypted." For the entire document I believe it is worthwhile to state in the terminology section that your usage of the term "signed" means digitally signing with asymmetric crypto system as well as using a MAC (which is a symmetric key primitive). You write: " Servers MAY cache the contents of the resources referenced by Request URIs. If the contents of the referenced resource could ever change, the URI SHOULD include the base64url encoded SHA-256 hash as defined in FIPS180-2 [FIPS180-2] of the referenced resource contents as the fragment component of the URI. If the fragment value used for a URI changes, that signals the server that any cached value for that URI with the old fragment value is no longer valid. " I am not sure what this means. Can you provide an example? You list a couple of restrictions of the request URI below" " The entire Request URI MUST NOT exceed 512 ASCII characters. There are three reasons for this restriction. 1. Many WAP / feature phones do not accept large payloads. The restriction are typically either 512 or 1024 ASCII characters. 2. The maximum URL length supported by older versions of Internet Explorer is 2083 ASCII characters. 3. On a slow connection such as 2G mobile connection, a large URL would cause the slow response and using such is not advisable from the user experience point of view. " I wonder how relevant they are (given that the size of the URI is substantially increased due to the use of JWT & the JOSE work). For example, are there still many WAP phones around that want to use this mechanism? Are old versions of the Internet Explorer still an issue?= Is a request by value even an option for a 2g mobile phone? Section 5. Validating JWT-Based Requests You write: "The Authorization Server MUST return an error if decryption fails." and "The Authorization Server MUST return an error if signature validation fails." Could you be a bit more precise about the error message that is returned? From Section 6 I don't see what the right error response would be. Section 8. Security Considerations: FROM: In addition to the all the security considerations discussed in OAuth= 2.0 [RFC6819], the following security considerations SHOULD be taken into account. TO: In addition to the all the security considerations discussed in OAuth= 2.0 [RFC6819], the following security considerations should be taken into account. You write: " When sending the authorization request object through "request" parameter, it SHOULD be signed with then considered appropriate algorithm using [RFC7515]. The "alg=3Dnone" SHOULD NOT be used in suc= h a case. " The use cases presented in the document talk about end-to-end security and signed / encrypted requests. Now, in the security consideration section it almost appears if there is the possibility that the request object would not experience any security protection at all. That does not appear right. It does not make sense to just send the parameters in a different encoding only, or does it? I would only see a disadvantage doing that, namely the much larger size. You write: " If the request object contains personally identifiable or sensitive information, the "request_uri" MUST be of one-time use and MUST have large enough entropy deemed necessary with applicable security policy. For higher security requirement, using [RFC7516] is client_secretstrongly recommended. " Why is this so? Today, we send the same request in OAuth over TLS. Why is there only a problem with the request_uri and not with sending the request object? I believe the biggest issue that should be discussed in the security consideration section is the possibility that the request object may not be fresh. This introduces the possibility for replay attacks and lowers the quality of the end-to-end security protection. It may also be good to motivate the application layer security mechanisms a bit more. For example, what information is in the request itself that requires encryption? When I looked at the example I noticed the client_id and the absence of the client_secret. I wonder how the mechanism intersects with the client_id and the client_secret. If a client has, for example, a public / private key pair configured then the use of JWS (with those credentials) would provide much better security than a client_id and a client_secret. ** Section 11: References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . Could you reference the TLS BCP instead? https://tools.ietf.org/html/rfc7525 [FIPS180-2] U.S. Department of Commerce and National Institute of Standards and Technology, "Secure Hash Signature Standard", FIPS 180-2, August 2002. Defines Secure Hash Algorithm 256 (SHA256) Could you reference RFC 6234 instead? https://tools.ietf.org/html/rfc6234 Ciao Hannes --GGsl678ssjXkDdmoamiAqlWhusafsAfsq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXc9PSAAoJEGhJURNOOiAtdZMH+wVBMSmF8KX/d5uuH4uw/7Rg 2eiDBvgEisjQ9NR3gTS5xufHVPy705LegxSaqBG7I1hjpzZUojYhErS8jP+G8WY0 sNB8POg7qYs5yqYrJAjqIzFkrygIWKToHXc+/Z8KWqDcox1AgWogy3cG6Mf0MZSi JcQTR+wDZKhRx0DGMD7phmSooIKAaI0v72TpqGr+zQUl7YHNbtHenEPArr2fEX50 dsWayTIrdvLjL+ZwasME1/NRamL/CHVSEalxNGIMXY3T9OrYGL0GaeTWwfPAl5Xm dH2D66xBZ2UN8X3VjU0rXWKDg82IpCRTHKC9m1WfVlmkRQTPcyDZof81w+MGEYU= =oige -----END PGP SIGNATURE----- --GGsl678ssjXkDdmoamiAqlWhusafsAfsq-- From liyuyi@gmail.com Mon Jun 27 12:30:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEB2127071 for ; Mon, 27 Jun 2016 12:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn-WC_yvhaja for ; Mon, 27 Jun 2016 12:30:48 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB68512D0B2 for ; Mon, 27 Jun 2016 12:30:47 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p10so222977999qke.3 for ; Mon, 27 Jun 2016 12:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=jDth3877vQgNkNT9Nw4/yjzt0qVrbfWvG2BJqB+bLXM=; b=vJR2zfR4ksfXhtJwjUKDZ8S1/PwE+IWiu8B8Z+QIGt8Lnnxc1OQle2PM0JA7i3HVry 2qt8MdnyFTMAHODE7GqE7xsYxxHq+c6RuW/sxYUt4hZPnN+YdD3brFYdBbapC79ns9Fj HXLO8U+ia1P+RCy4vEAMh7dgrtpz9cSJcGa3jycXhAGy7whhGh2JwDzBjULyf46AAidq CYw+Bcla49h534mFE1CgEr9L7FdQYgR6MxokKzhbtJ6v9aPmCVs0o4g/20edr7W0iL3V YOqhgxIg3z+VlutdCMcHyMbJ4K6QrDqYaQIvn/2I/UeSRj8e3/gXLZ0L9sONaSK3y5HI TrLQ== 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; bh=jDth3877vQgNkNT9Nw4/yjzt0qVrbfWvG2BJqB+bLXM=; b=Ywtj2eNailI5hCF4E5VFrlGN+PFkabpYyCZMcwGnjlKp3tQHh4MQP5hPSK30m6CBEQ OAUy5fs7S/ihDo9/62qGrWSLW0620YDDGjzac2YXrW5LFuhettjzM7o8v7MTXjpmXwC4 pH+7S/0BCQnV5JXzkZcewtQqWw5r0q4lp2tb+ySrz7RwiJCDdbo+2Aw7nExZP6feSbIp cfYJeZb0eE2JCl24DPM9Ujn9koLvmvBREp7eTBLNw7T+KlZcZMnfMM9qdR3aboHeD0JT P7PVEmFo11Y7nzUPiy6iQEe/AUqbKN1POM+XBUft0/R7HhEgRh/TDGhi/Oz/BDVULKdH /4Ug== X-Gm-Message-State: ALyK8tICg2ahK924nqkTsY9uuiybTgRBwLUpeMATDZ2eJT/qDBHV28EJs2FLCKPmjV1KoQYCuDQVzzf08rtTrA== X-Received: by 10.129.82.135 with SMTP id g129mr13361170ywb.163.1467055846845; Mon, 27 Jun 2016 12:30:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.13 with HTTP; Mon, 27 Jun 2016 12:30:46 -0700 (PDT) From: Liyu Yi Date: Mon, 27 Jun 2016 12:30:46 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a114ddbaa9df2690536478ea9 Archived-At: X-Mailman-Approved-At: Wed, 29 Jun 2016 07:08:08 -0700 Subject: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 20:14:22 -0000 --001a114ddbaa9df2690536478ea9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable While we are working on a project with OAuth2 implementation, one question arises from our engineers. We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that (C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment. For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer. Shouldn=E2=80=99t it be more secure if we change to use a post method for a= ccess token, similar to the SAML does? I feel there might be something I missed here. Any advices will be appreciated. --001a114ddbaa9df2690536478ea9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

While we are working on a project with OAuth= 2 implementation, one question arises from our engineers.

We noticed at https://tools.iet= f.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that<= /span>

=C2=A0=C2=A0

(C)=C2=A0 Assuming the resource owner grants= access, the authorization

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s= erver redirects the user-agent back to the client using the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r= edirection URI provided earlier.=C2=A0 The redirection URI includes<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 t= he access token in the URI fragment.

=C2=A0

For my understanding, the browser keeps the = URI fragment in the history, and this introduces unexpected exposure of the= access token. A user without authorization for the resource can get the ac= cess token as long as he has the access to the browser. This can happen in = a shared computer in library, or for an IT staff who works on other employe= e=E2=80=99s computer.

=C2=A0

Shouldn=E2=80=99t it be more secure if we ch= ange to use a post method for access token, similar to the SAML does?

I feel there might be something I missed her= e. Any advices will be appreciated.

--001a114ddbaa9df2690536478ea9-- From nobody Wed Jun 29 07:29:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A930D12DB4B for ; Wed, 29 Jun 2016 07:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib8n9PgRn6Pl for ; Wed, 29 Jun 2016 07:29:41 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262E812DEDE for ; Wed, 29 Jun 2016 07:29:41 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a66so76668965wme.0 for ; Wed, 29 Jun 2016 07:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iVqTv22CsRoNsXYpWmvLaQlws1fNKGjDoFu2f+NiHo4=; b=J95c+Ln4qksrb0/MmOoKZ0fSfS2mKWYUI9T7C64hoOp13zdFlkZiK0nDnpXbjA+F9r bLt3/WRU05QLHJSfbckvNiU5klW+mDxi7xYM0JdkLZG71BLJ7HY8M7nGucIQ/q8niY3o 9s76aUjRiLYGkI11ZNiolt+IL1vRJPvoLjgoLQd5N3hR7oBEKTMSO2pl3PEGzLipnyWY 4k0XjDLEDNrGSabRYHaIGKljdctAx/5fH6cjSKy/JxVHPrpo5ajKzCkgD7I+rik4OxCc aIXxcGIhZyWaNpF1WuXUM3RSM1au/QdCb5z5oCl2PuU6FStM5VSt075u0Z+rDNU3pWVV qtjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iVqTv22CsRoNsXYpWmvLaQlws1fNKGjDoFu2f+NiHo4=; b=O6kY4N40bMkUZ7lr4V0UfQeyPscCtTFAl+QTiX6Q+p0nXRFcIdFjBpldV4gTxKGk2U /kIeOQFpZx7y8dZng7LAgZccoOHzraNE6XYfoDhx4yIU9n9MfGcYV/2cEIfnywSyCI5Y 2Uk93TkXOQUKcNd3vCRhG3vPoCYxzxOXahyIrkuzU3QLzEZ+ihm1Or10i/bneOFhQnHQ fej5fRVeWg8np0hUbf+SoMprUf/lqfzP8iTl2l1V9trgupEmAv0U4sXvIzUaLRE7XTs1 F8BpRa5ZHi4PNIy2Rdsr5IVSnPTIwzpM4oYEXDy/ZQ4BQAKBWfIMSurSeuf44sW2zieY G32g== X-Gm-Message-State: ALyK8tJQqcQH+36JJPjrrxpzdOLalmeiw9MVdtrYb4ESUaj8MDp2mO8utZ7Bi88rI+j3AxKlRLeZhbfQAgBpNA== X-Received: by 10.28.111.215 with SMTP id c84mr9041848wmi.21.1467210578802; Wed, 29 Jun 2016 07:29:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Broyer Date: Wed, 29 Jun 2016 14:29:26 +0000 Message-ID: To: Liyu Yi , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1146ddb85c658405366b95c1 Archived-At: Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:29:44 -0000 --001a1146ddb85c658405366b95c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The client app could (and should) do a window.location.replace or window.history.replaceState to remove the entry from the browser history. AFAICT, this is out of scope of the OAuth specs because they're about the protocol and interactions between the parties involved, not about securing each one on its own. That said, if the computer is shared between users, they should take care of properly signing out, which should (in most cases) revoke tokens and, in the case of client apps should also involve explicitly revoking the tokens they've been handed out. So even if a token is present in the browser history it shouldn't be usable. If the previous user hasn't signed out, then he has bigger problems. See also https://tools.ietf.org/html/rfc6819#section-4.4.2.2 As for the form post, see https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html On Wed, Jun 29, 2016 at 4:08 PM Liyu Yi wrote: > While we are working on a project with OAuth2 implementation, one questio= n > arises from our engineers. > > We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, > it is specified that > > > > (C) Assuming the resource owner grants access, the authorization > > server redirects the user-agent back to the client using the > > redirection URI provided earlier. The redirection URI includes > > the access token in the URI fragment. > > > > For my understanding, the browser keeps the URI fragment in the history, > and this introduces unexpected exposure of the access token. A user witho= ut > authorization for the resource can get the access token as long as he has > the access to the browser. This can happen in a shared computer in librar= y, > or for an IT staff who works on other employee=E2=80=99s computer. > > > > Shouldn=E2=80=99t it be more secure if we change to use a post method for= access > token, similar to the SAML does? > > I feel there might be something I missed here. Any advices will be > appreciated. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1146ddb85c658405366b95c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The client app could (and should) do a window.location.rep= lace or window.history.replaceState to remove the entry from the browser hi= story.
AFAICT, this is out of scope of the OAuth specs because they'= ;re about the protocol and interactions between the parties involved, not a= bout securing each one on its own.

That said, if t= he computer is shared between users, they should take care of properly sign= ing out, which should (in most cases) revoke tokens and, in the case of cli= ent apps should also involve explicitly revoking the tokens they've bee= n handed out. So even if a token is present in the browser history it shoul= dn't be usable. If the previous user hasn't signed out, then he has= bigger problems.


On W= ed, Jun 29, 2016 at 4:08 PM Liyu Yi <liyuyi@gmail.com> wrote:

While we are working on a project with OAuth2 implementation, one = question arises from our engineers.

We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that

=C2=A0=C2=A0

(C)=C2=A0 Assuming the resource owner grants access, the authoriza= tion

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the us= er-agent back to the client using the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI provide= d earlier.=C2=A0 The redirection URI includes

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the access token in the= URI fragment.

=C2=A0

For my understanding, the browser keeps the URI fragment in the hi= story, and this introduces unexpected exposure of the access token. A user = without authorization for the resource can get the access token as long as = he has the access to the browser. This can happen in a shared computer in l= ibrary, or for an IT staff who works on other employee=E2=80=99s computer.<= /span>

=C2=A0

Shouldn=E2=80=99t it be more secure if we change to use a post met= hod for access token, similar to the SAML does?

I feel there might be something I missed here. Any advices will be= appreciated.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1146ddb85c658405366b95c1-- From nobody Wed Jun 29 07:30:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8307512DF1A for ; Wed, 29 Jun 2016 07:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpJTmgZK7oJK for ; Wed, 29 Jun 2016 07:30:16 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55C412DF0C for ; Wed, 29 Jun 2016 07:30:10 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a66so76692095wme.0 for ; Wed, 29 Jun 2016 07:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=uy4OFyCFoFRj+tfUMBtpfqpUIFGKNARJ6763i+LRhbI=; b=n1FFZyBlUkdN8OBjAVHE/o40JwYt2eaRgS4RaN6Sjj+vjW92f4ZEkHHVpuILt4YgtU 2Q8ctHDhtCTg6VpessXmfK96n+pm7rgyoIuCuOizHyPvAInMVzGP6nRfdmUxJgefSzxH YT7S1EmSMtadKDOE4xOCDRvlo9ygnpS6b6wL5wR6fLbq6fz14ueEhbrs6/GJ0cJTdY0O oEz0dopbGBXQ4y0Naf24W2Jo4pw77RHU4UasM44RBr8KXG2cIBOfnx/32CQOz2Op1tl5 dP7pIYOhEjq5DTMEsiGa/W6jqGb0CASeGxdOkUAHWbsLPBweHVqPd9RvSoe0ZU3UOCtL Ewrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=uy4OFyCFoFRj+tfUMBtpfqpUIFGKNARJ6763i+LRhbI=; b=ia6ymFkNUTM4MnwbIbGOwVZh7SmwrwQzfmtpf6mpYFzf2hYA3KLWMJNUcZNnSk2pfo cN/QrjeY+JHh/hL5LMdkeZ13Z1V76WjsKWjW5xHtWJWTh4d2zyp58e672V7K2LSR8Ryx sekKaMDwGrALT8KIXscptA41d3oBPFtns5BCePAxISsjhpI7Dgvul1zJXk2pR7qg9LXs NySreXIoyg3aSNj+KqNHUwGqvH49dTgxIhnwNDtYTt/v/79dFIvkCHp256gw7S4tRu0l fKvGNJYdcyFDsX8O3FnuzNte7kCc5EkkZGTInG5C/meG+xS/9telzkyUKRxKhNuMvpCd IXvA== X-Gm-Message-State: ALyK8tJdpVB5zjtqbFJWh93Zhyd50dnYQboFc+qfyXMubO2oX9thXUvBVD7RZHx8O+8tZhaF X-Received: by 10.194.168.225 with SMTP id zz1mr9828526wjb.114.1467210609321; Wed, 29 Jun 2016 07:30:09 -0700 (PDT) Received: from heembo.local ([213.215.138.237]) by smtp.googlemail.com with ESMTPSA id a84sm4570071wma.0.2016.06.29.07.30.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jun 2016 07:30:07 -0700 (PDT) To: Liyu Yi , oauth@ietf.org References: From: Jim Manico Message-ID: Date: Wed, 29 Jun 2016 16:30:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------05744D1283C991FAFF4158AE" Archived-At: Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:30:27 -0000 This is a multi-part message in MIME format. --------------05744D1283C991FAFF4158AE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > Shouldn=92t it be more secure if we change to use a post method for access token, similar to the SAML does? I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se. 2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com On 6/27/16 9:30 PM, Liyu Yi wrote: > > While we are working on a project with OAuth2 implementation, one > question arises from our engineers. > > We noticed at > https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is > specified that > > =20 > > (C) Assuming the resource owner grants access, the authorization > > server redirects the user-agent back to the client using the > > redirection URI provided earlier. The redirection URI includes= > > the access token in the URI fragment. > > =20 > > For my understanding, the browser keeps the URI fragment in the > history, and this introduces unexpected exposure of the access token. > A user without authorization for the resource can get the access token > as long as he has the access to the browser. This can happen in a > shared computer in library, or for an IT staff who works on other > employee=92s computer. > > =20 > > Shouldn=92t it be more secure if we change to use a post method for > access token, similar to the SAML does? > > I feel there might be something I missed here. Any advices will be > appreciated. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 --------------05744D1283C991FAFF4158AE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

> Shouldn’t it be more secure if we change to use a post method for access token, similar to the SAML does?

I say yes. But please note I'm very new at this and someone with more experience will have more to say or correct my comments.

Here are a few more details to consider.

1) OAuth is a framework and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.

2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.

3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.

4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.

Aloha,
Jim Manico
Manicode Security
https://www.manicode.com

On 6/27/16 9:30 PM, Liyu Yi wrote:

While we are working on a project with OAuth2 implementation, one question arises from our engineers.

We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that

  

(C)  Assuming the resource owner grants access, the authorization

        server redirects the user-agent back to the client using the

        redirection URI provided earlier.  The redirection URI includes

        the access token in the URI fragment.

 

For my understanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee’s computer.

 

Shouldn’t it be more secure if we change to use a post method for access token, similar to the SAML does?

I feel there might be something I missed here. Any advices will be appreciated.



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


--
--------------05744D1283C991FAFF4158AE-- From nobody Wed Jun 29 07:31:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1019912DF2F for ; Wed, 29 Jun 2016 07:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNnyEmCKzTpp for ; Wed, 29 Jun 2016 07:30:57 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7FF12DF16 for ; Wed, 29 Jun 2016 07:30:43 -0700 (PDT) X-AuditID: 1209190d-41fff70000007da9-e0-5773db91bdfe Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id A4.7B.32169.19BD3775; Wed, 29 Jun 2016 10:30:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5TEUeAm017229; Wed, 29 Jun 2016 10:30:40 -0400 Received: from artemisia.richer.local (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 u5TEUciC001074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2016 10:30:39 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_C10F1922-D1AC-4B0B-A301-C12267097BCB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Wed, 29 Jun 2016 10:30:38 -0400 Message-Id: References: To: Liyu Yi X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0Z14uzjc4PJ2M4uWt4/YLU6+fcXm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGWcnP6YqeCWecXvj7OYGhgX6XcxcnJICJhI 3F7dz9LFyMUhJNDGJLHsUA8ThLORUWLDlbWsIFVCAg+ZJM5fkQCxmQUSJJY2bWcDsXkF9CQ2 rX/LBGILC3hLzG3dDFbPJqAqMX1NC1icUyBQoql9PzOIzQIU/799PVCcA2iOukT7SReIMVYS k/aeYYNYFSBx4+9JsHIRATmJaZPuskIcKivx5OQilgmM/LOQXDELyRUQcW2JZQtfM0PYmhL7 u5ezYIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6RXm5miV5qSukmRlBYc0ry 7mD8d9frEKMAB6MSD6/GoaJwIdbEsuLK3EOMkhxMSqK8+nnF4UJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeM2uAeV4UxIrq1KL8mFS0hwsSuK8MTePhgkJpCeWpGanphakFsFkZTg4lCR4RW4B NQoWpaanVqRl5pQgpJk4OEGG8wANXwZSw1tckJhbnJkOkT/FqCglzrsJJCEAksgozYPrBaWd hLeHTV8xigO9IswrC0xCQjzAlAXX/QpoMBPQYOZSsMEliQgpqQbGvCkttb4KWw4u+s0YKpOr yTnHwley+OxG5uuqVx5ouf+p65QruSF7Q7rTU7ik+M2j7v+v3xZ952frCvwpdPJtyf2/H9+y lHNKrz/KElhR++5N49OtrFVnauZo/i5zFFYLW6rbs+9lou52pXtivlOr1ljFcOm8W/fqxL1j AYpKTsqTv7W922SmxFKckWioxVxUnAgAPX+lqxYDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:31:05 -0000 --Apple-Mail=_C10F1922-D1AC-4B0B-A301-C12267097BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The implicit flow was designed for in-browser clients that don=E2=80=99t = have a server back-end. In these cases, keeping the data inside the = browser entirely is exactly the goal: you don=E2=80=99t want to use = query or form parameters because those get sent by the browser back to = the server. That was the idea anyway, except that now new versions of = Chrome also send the fragment back (as I understand things) so we=E2=80=99= re in a bit of a lurch with our assumed security model.=20 Even so, you=E2=80=99re absolutely right that the fragment can leak all = over the browser. There are a few tricks you can do to mitigate this, = like messing about with the history, but they=E2=80=99re patches at = best. This is why the implicit flow is considered fairly insecure by = most people in the community, and it really needs to be used only in the = very limited context of an in-browser application, with limited lifetime = access tokens (perhaps even tied to a live session at the AS). What = you=E2=80=99re doing with the implicit flow, when used properly, is = really more like a cross-domain session sharing. =E2=80=94 Justin > On Jun 27, 2016, at 3:30 PM, Liyu Yi wrote: >=20 > While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >=20 > We noticed at = https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >=20 > =20 > (C) Assuming the resource owner grants access, the authorization >=20 > server redirects the user-agent back to the client using the >=20 > redirection URI provided earlier. The redirection URI = includes >=20 > the access token in the URI fragment. >=20 > =20 > For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >=20 > =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method = for access token, similar to the SAML does? >=20 > I feel there might be something I missed here. Any advices will be = appreciated. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C10F1922-D1AC-4B0B-A301-C12267097BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The implicit flow was designed for in-browser clients that = don=E2=80=99t have a server back-end. In these cases, keeping the data = inside the browser entirely is exactly the goal: you don=E2=80=99t want = to use query or form parameters because those get sent by the browser = back to the server. That was the idea anyway, except that now new = versions of Chrome also send the fragment back (as I understand things) = so we=E2=80=99re in a bit of a lurch with our assumed security = model. 

Even = so, you=E2=80=99re absolutely right that the fragment can leak all over = the browser. There are a few tricks you can do to mitigate this, like = messing about with the history, but they=E2=80=99re patches at best. = This is why the implicit flow is considered fairly insecure by most = people in the community, and it really needs to be used only in the very = limited context of an in-browser application, with limited lifetime = access tokens (perhaps even tied to a live session at the AS). What = you=E2=80=99re doing with the implicit flow, when used properly, is = really more like a cross-domain session sharing.

 =E2=80=94 Justin

On Jun 27, 2016, at 3:30 PM, Liyu Yi <liyuyi@gmail.com> = wrote:

While we are working on a project with OAuth2 implementation, = one question arises from our engineers.

We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that

  

(C)  Assuming the resource owner grants access, the = authorization

        server redirects = the user-agent back to the client using the

        redirection URI = provided earlier.  The redirection URI includes

        = the access token in the URI fragment.

 

For my understanding, the browser keeps the = URI fragment in the history, and this introduces unexpected exposure of = the access token. A user without authorization for the resource can get = the access token as long as he has the access to the browser. This can = happen in a shared computer in library, or for an IT staff who works on = other employee=E2=80=99s computer.

 

Shouldn=E2=80=99t it be more secure if we = change to use a post method for access token, similar to the SAML = does?

I feel there might be = something I missed here. Any advices will be = appreciated.

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

= --Apple-Mail=_C10F1922-D1AC-4B0B-A301-C12267097BCB-- From nobody Wed Jun 29 08:10:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF9212DEF0 for ; Wed, 29 Jun 2016 08:10:55 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1fi2qszr1jl for ; Wed, 29 Jun 2016 08:10:42 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D598C12DF21 for ; Wed, 29 Jun 2016 08:10:38 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id j2so37488458qkf.3 for ; Wed, 29 Jun 2016 08:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=taZWkaeW/N1bIhzIiUziRtVEIikg7iMVw3S3tPTwq4M=; b=iLrg5xxT/VQuKCI8dO6vdGmf01DPssaCHYnjAKAeyFne/msFl8UJRx2xOu27ptq2Lv p6JpZaOTEr75jx9DMhnr80wIZPYRQhh0ObSIH2tT9pdAH0SuMQZxe2sfwMVYDffc3QC1 jyrahlGPigAVOBiXbEXc1kpqVyUHv9TGb7ReROMAxsNRRICROUOBszlaAGheZombIiOf B0prhccgaCWlThcm0GSMTH4OthyQSzyCY9Viv4FPuKZXnECWKluPkRUqZNVKhEbYpVP7 YKJ9dFjTi5yQd5tXFRVb42o6cHlqcNRUvfrnVAuFsAU7oM6cd4mnGfoXVOujmeCvwNRT JSbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=taZWkaeW/N1bIhzIiUziRtVEIikg7iMVw3S3tPTwq4M=; b=aJTFVQ0XtNZxG/S4o1eh33eheRg6bQx6VigQqOtfdf1pbDl61Z1GbY9TMIt3S+27sU NrQldBUFHdMBTqbeDSBFEoeIMWKpRogZ1+AeX9nYz7eTOZhzHVvg+2zXcwrT4EL1xbJn F8kZKrqoLcP5d48Unk4EPM3AIfIJFmNQ3D9Is4Q5cYtc8lWzs62YAX6dov5sm7Uea9L5 9OskQlSWBTClwK5cdZPAnbDd+L7zv6u//HLT4eWQfcFSM+1mMYuptZd2aM1H1JfM0Tlx ZumSZhp/2Qivj1cMMjyLvg1Uo0ErTmU9XXxrzx/JcA+ajdZQBa/8d3yT1BTBSJnYs1BV uf0g== X-Gm-Message-State: ALyK8tJdwIxIb273BU2rMvZbp9X1EzJm0rgp3ZJAdldKofJExYD8AKsC7QveGDDmCUp0Eg== X-Received: by 10.55.168.137 with SMTP id r131mr11535754qke.24.1467213037833; Wed, 29 Jun 2016 08:10:37 -0700 (PDT) Received: from [192.168.8.101] ([181.202.212.65]) by smtp.gmail.com with ESMTPSA id z65sm2082837qkd.36.2016.06.29.08.10.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Jun 2016 08:10:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B2BB5C95-BE89-42D1-B7C0-B52C437218F5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 29 Jun 2016 11:10:33 -0400 Message-Id: <7281CBDE-5D9A-43A3-944C-DF5FDAC70505@ve7jtb.com> References: To: Justin Richer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 15:10:56 -0000 --Apple-Mail=_B2BB5C95-BE89-42D1-B7C0-B52C437218F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Justin. You should be using the code flow if it is a server based client. The OAuth WG is considering better alternatives to using fragment = encoding for in browser JS clients as well. =20 For the moment the only standard for the in browser client is fragment = encoding. In the future we hope to have more modern methods based on = post message. For people using openID Connect who want a id_token in the front channel = (Hybrid flow) they should use the form post response mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html = Browsers now re-append fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified. John B. > On Jun 29, 2016, at 10:30 AM, Justin Richer wrote: >=20 > The implicit flow was designed for in-browser clients that don=E2=80=99t= have a server back-end. In these cases, keeping the data inside the = browser entirely is exactly the goal: you don=E2=80=99t want to use = query or form parameters because those get sent by the browser back to = the server. That was the idea anyway, except that now new versions of = Chrome also send the fragment back (as I understand things) so we=E2=80=99= re in a bit of a lurch with our assumed security model.=20 >=20 > Even so, you=E2=80=99re absolutely right that the fragment can leak = all over the browser. There are a few tricks you can do to mitigate = this, like messing about with the history, but they=E2=80=99re patches = at best. This is why the implicit flow is considered fairly insecure by = most people in the community, and it really needs to be used only in the = very limited context of an in-browser application, with limited lifetime = access tokens (perhaps even tied to a live session at the AS). What = you=E2=80=99re doing with the implicit flow, when used properly, is = really more like a cross-domain session sharing. >=20 > =E2=80=94 Justin >=20 >> On Jun 27, 2016, at 3:30 PM, Liyu Yi > wrote: >>=20 >> While we are working on a project with OAuth2 implementation, one = question arises from our engineers. >>=20 >> We noticed at = https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30 = , it is = specified that >>=20 >> =20 >> (C) Assuming the resource owner grants access, the authorization >>=20 >> server redirects the user-agent back to the client using the >>=20 >> redirection URI provided earlier. The redirection URI = includes >>=20 >> the access token in the URI fragment. >>=20 >> =20 >> For my understanding, the browser keeps the URI fragment in the = history, and this introduces unexpected exposure of the access token. A = user without authorization for the resource can get the access token as = long as he has the access to the browser. This can happen in a shared = computer in library, or for an IT staff who works on other employee=E2=80=99= s computer. >>=20 >> =20 >> Shouldn=E2=80=99t it be more secure if we change to use a post method = for access token, similar to the SAML does? >>=20 >> I feel there might be something I missed here. Any advices will be = appreciated. >>=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=_B2BB5C95-BE89-42D1-B7C0-B52C437218F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree with Justin.

You should be using the code flow if it is a server based = client.

The = OAuth WG is considering better alternatives to using fragment encoding = for in browser JS clients as well.  
For the = moment the only standard for the in browser client is fragment encoding. =  In the future we hope to have more modern methods based on post = message.

For = people using openID Connect who want a id_token in the front channel = (Hybrid flow) they should use the form post response mode
 https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.h= tml

Browsers= now re-append  fragments across 302 redirects unless they are = explicitly cleared this makes fragment encoding less safe than it was = when originally specified.

John B.

On Jun 29, 2016, at 10:30 AM, = Justin Richer <jricher@MIT.EDU> wrote:

The implicit = flow was designed for in-browser clients that don=E2=80=99t have a = server back-end. In these cases, keeping the data inside the browser = entirely is exactly the goal: you don=E2=80=99t want to use query or = form parameters because those get sent by the browser back to the = server. That was the idea anyway, except that now new versions of Chrome = also send the fragment back (as I understand things) so we=E2=80=99re in = a bit of a lurch with our assumed security model. 
Even so, you=E2=80=99re absolutely = right that the fragment can leak all over the browser. There are a few = tricks you can do to mitigate this, like messing about with the history, = but they=E2=80=99re patches at best. This is why the implicit flow is = considered fairly insecure by most people in the community, and it = really needs to be used only in the very limited context of an = in-browser application, with limited lifetime access tokens (perhaps = even tied to a live session at the AS). What you=E2=80=99re doing with = the implicit flow, when used properly, is really more like a = cross-domain session sharing.

 =E2=80=94 Justin

On Jun 27, 2016, at 3:30 PM, Liyu Yi <liyuyi@gmail.com> = wrote:

While we are working on a project with OAuth2 implementation, = one question arises from our engineers.

We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified that

  

(C)  Assuming the resource owner grants access, the = authorization

        server redirects = the user-agent back to the client using the

        redirection URI = provided earlier.  The redirection URI includes

        = the access token in the URI fragment.

 

For my understanding, the browser keeps the = URI fragment in the history, and this introduces unexpected exposure of = the access token. A user without authorization for the resource can get = the access token as long as he has the access to the browser. This can = happen in a shared computer in library, or for an IT staff who works on = other employee=E2=80=99s computer.

 

Shouldn=E2=80=99t it be more secure if we = change to use a post method for access token, similar to the SAML = does?

I feel there might be = something I missed here. Any advices will be = appreciated.

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

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

= --Apple-Mail=_B2BB5C95-BE89-42D1-B7C0-B52C437218F5-- From nobody Thu Jun 30 16:24:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52420127058 for ; Thu, 30 Jun 2016 16:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.145 X-Spam-Level: X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwztp6-3-9_h for ; Thu, 30 Jun 2016 16:24:47 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120C512B004 for ; Thu, 30 Jun 2016 16:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1467329085; bh=oWK9j4woutBs6bwvwS3DHhglxhVLLWF6ziSlmRoiQ1U=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=JqgzcZPA0OIGBXI+nBIjMq/b/2knhTmdNGm760/1/hNVOywTybKC3chaPng16TLg5XQF/t2QPQt+2Hm4zemIU6zkafd9dFpi8vu/pK59ChG50z8wUfN0RLDSnaIXaI8TiaaPiyB+8N8Lom59rztRZuBAsUqJIJi2FJkQtnAzHQiMeDf8+DBM4v2cVmvioFGNoQKtZ3zoaaoWbMBg2zijbxe8S0Iiu2El3WHe58kNqGyMlQ5neqjfhFAnQR/75/s+UuDmv4GGdYb1qMKU7veTYOJnJcwU+yrVddq8y9XR53bJPcMgJococME9AbaAShq7IwH/w2RIVwOOFPGs5JwVhQ== Received: from [98.139.170.181] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jun 2016 23:24:45 -0000 Received: from [98.139.212.221] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jun 2016 23:24:44 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 30 Jun 2016 23:24:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 971375.59824.bm@omp1030.mail.bf1.yahoo.com X-YMail-OSG: IMl1rvcVM1nXJcU09_k88aDKSCNYCagyxTcjPyx8MqBE0ur9VL.Og.HDQ4Y9JK8 xkLz7jo3i..SDUoAjcM_kvdkYMO_j6mDa8ith7BLmaKSjE9Sio8OFCZeMHeH4lpIb6KUgz.6B.Ny nWfD9pTpVP5DeQVT6Oi5NlbviEFybUWQr0GJ0kgFaiPBU0oPRoH7PsxK8UO4SBHE_VipystsP91B 0Pkvf07TOZtTnrV1_9XWfj1UPv_oST.qSu_0xASsiWg9T9Tfam88u81g4Q0yd39ICw5lsFka0nGn nFRugO_xTfacIfx2TpFpr2p3sCn.LCTS6XjD2odAyS94S4cQKR5dpXF6vjMAWu6..GLzeCowz4pB _CWpQHFEgM9iCyUc29VLzPq3REKyFObQyr.IS6pkrJ0FTDtrnPWF3rMjiPzDcGhNhRxsFf3CxZl5 Qx5569jEE0qluNIAl.f4Sg4jJM5HWr7HOKZlgCCTvwKUHzT74iGAigJjBxvCnUktd6WEFvOgcc7t smR5MQhhZtgQTDtaweDXt5YtVfYHlZSFE6Z_SaA-- Received: from jws106105.mail.bf1.yahoo.com by sendmailws122.mail.bf1.yahoo.com; Thu, 30 Jun 2016 23:24:44 +0000; 1467329084.528 Date: Thu, 30 Jun 2016 23:24:44 +0000 (UTC) From: Oleg Gryb To: Jim Manico , Liyu Yi , "oauth@ietf.org" Message-ID: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_55004_937889292.1467329084194" Archived-At: Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 23:24:49 -0000 ------=_Part_55004_937889292.1467329084194 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We've discussed access tokens in URI back in 2010 (https://www.ietf.org/mai= l-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer.2. Replaci= ng with POST would mean a significant performance impact in some high volum= e implementations (I think it was Goole folks who were saying this, but I d= on't remember now). AFAIR, nobody was arguing about browsing history, so it's valid. So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. BTW, Jim, if you can come up with other scenarios when fragments can leak, = please share. It'll probably help the community with solving this problem f= aster than in 6 years. Thanks,Oleg. =20 From: Jim Manico To: Liyu Yi ; oauth@ietf.org=20 Sent: Wednesday, June 29, 2016 7:30 AM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t =20 > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? I say yes. But please note I'm ve= ry new at this and someone with more experience will have more to say or co= rrect my comments. Here are a few more details to consider. 1) OAuth is a framework and not a standard, per se. Different authorizati= on servers will have different implementations that are not necessarily com= patible with other service providers. So there is no standard to break, per= se. 2) Sensitive data in a URI is a bad idea. They leak all over the place ev= en over HTTPS. Even in fragments. 3) Break the "rules" and find a way to submit sensitive data like access = tokens, session information or any other (even short term) sensitive data i= n a secure fashion. This includes POST, JSON data payloads over PUT/PATCH a= nd other verbs - all over well configured HTTPS. 4) If you really must submit sensitive data over GET , consider JWT/JWS/J= WE (with limited scopes/lifetimes) to provide message level confidentiality= and integrity. Aloha, Jim Manico Manicode Security https://www.manicode.com=20 On 6/27/16 9:30 PM, Liyu Yi wrote: =20 While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. We noticed at https://tools.ietf.org/html/draf= t-ietf-oauth-v2-31#page-30, it is specified that =C2=A0=C2=A0 (C)=C2=A0 Ass= uming the resource owner grants access, the authorization =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 server redirects the user-agent back to the cli= ent using the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirection URI pr= ovided earlier.=C2=A0 The redirection URI includes =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 the access token in the URI fragment. =C2=A0 For my unde= rstanding, the browser keeps the URI fragment in the history, and this intr= oduces unexpected exposure of the access token. A user without authorizati= on for the resource can get the access token as long as he has the access t= o the browser. This can happen in a shared computer in library, or for an I= T staff who works on other employee=E2=80=99s computer. =C2=A0 Shouldn=E2= =80=99t it be more secure if we change to use a post method for access toke= n, similar to the SAML does? I feel there might be something I missed here.= Any advices will be appreciated. =20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =20 --=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_55004_937889292.1467329084194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've discussed access tokens in URI back in 2010 (<= a href=3D"https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html= ">https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). T= here were two major objectives when I was saying that it's not secure:

1. Fragment is no= t sent to a server by a browser. When I've asked if this is true for every = browser in the world, nobody was able to answer.
2. Replacing with POST would mean a= significant performance impact in some high volume implementations (I thin= k it was Goole folks who were saying this, but I don't remember now).
=

AFAIR, nobody was = arguing about browsing history, so it's valid.

So, 6 years later we're at square one wit= h this and I hope that this time the community will be more successful with= getting rid of secrets in URL.

BTW, Jim, if you can come up with other scenarios when f= ragments can leak, please share. It'll probably help the community with sol= ving this problem faster than in 6 years.

Thanks,
Oleg.


=
From: Jim Manico <jim@manicode.com>
To: Liyu Yi <liyuyi@gmail.com>= ; oauth@ietf.org
Se= nt: Wednesday, June 29, 2016 7:30 AM
Subject: Re: [OAUTH-WG] Security con= cern for URI fragment as Implicit grant

> Shouldn=E2=80=99t = it be more secure if we change to use a post method for access token, similar to the SAML does?
I say yes. But please = note I'm very new at this and someone with more experience will have more to say or correct my comments.
Here are a few more de= tails to consider.
1) OAuth is a framewor= k and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manic=
ode.com

=
On 6/27/16 9:30 PM, Liyu Yi wro= te:
While we= are working on a project with OAuth2 implementation, one question arises from our engineers.
We notic= ed at https://tools.ietf.org/html/draft-ietf-oa= uth-v2-31#page-30, it is specified that
  
(C) = ; Assuming the resource owner grants access, the authorization
 &n= bsp;      server redirects the user-agent back to the client using the
 &n= bsp;      redirection URI provided earlier.  The redirection URI includes
 &n= bsp;      the access token in the URI fragment.
 
For my u= nderstanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn= =E2=80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel t= here might be something I missed here. Any advices will be appreciated.


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


--=20

____________= ___________________________________
OAuth mailing listOAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth

------=_Part_55004_937889292.1467329084194-- From nobody Thu Jun 30 22:25:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90E712D15A for ; Thu, 30 Jun 2016 22:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNkYIXbrhD_7 for ; Thu, 30 Jun 2016 22:25:32 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9157312D16B for ; Thu, 30 Jun 2016 22:25:31 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f126so11750983wma.1 for ; Thu, 30 Jun 2016 22:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5+eiJ0z67MHyFQRnuSBpZYZB/q/P6jxkNgVWqV6AZPs=; b=mPiFL940XMYG/r+hoNKXNw1xx3RDy+FIKPBhKdzN4tG51TH3TjOjczXQjnzdJDSPEE Pk1uA9rcjHv8/QBNJIV81QTBby7LcBO3bucUF81k0zvKdQ6xTWnPYL+r8zrAWYcaBVVB JwnUCTnusv5qLGVFMudl+W4ZB8HtezqC766Mtn97zdq/eoYO+bTjxbaFW2P+3w8EWNtM ZvAyyn9zrqMhUiPvEzcnLYvKMuXEmMLVYCcbOUM0wRy1VWrBFyXzek63ew5NlNNDfjrK JOlZ6p6ZGnzN2iaeRQJBPMoVOBASz+VLR4BTsxjD19mCbGyfWd85nvuRmXOm/E85pzCC Hekg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5+eiJ0z67MHyFQRnuSBpZYZB/q/P6jxkNgVWqV6AZPs=; b=Kmir6PsX2WC/JbGx7x350Js172Q+L/5/OBpOSKSF4CMFKBT9YMbobgDCiEp94ZEANS bVEfrRXTUXafB+3xoHNe8cS1tUkSqXRodwFQe+dzypQ2MQhdkCdv9Vq7PxhLn91v+B9d 8c5CQsrn7+DlsiNfe9u0fERMP9EfmMwMvaEw2fiSpD8s7XBQajw2oJkOD3QgPx9dKuyg ehI/BcDelpnQ7ajA5BS7ODAT/lS5nsRcoLjzmTfkj3R/no4/nxQmlVVaaM5XOBROVPtx 0Zr1Jlkpuu2/xMwu3TsaOkcPCaQnoOOvV/92a2DaZNtdTQb5rwqMzloBDaiEMNRIMcgK xTTA== X-Gm-Message-State: ALyK8tImtHGh35PXFltVIFVsormyXmzHrOMH3cE4dSbILGqtJGFHFBq8JD354W/9O2POO7mZ X-Received: by 10.28.10.66 with SMTP id 63mr31607693wmk.54.1467350730005; Thu, 30 Jun 2016 22:25:30 -0700 (PDT) Received: from [198.18.208.168] ([213.215.138.237]) by smtp.gmail.com with ESMTPSA id wo9sm1054035wjb.8.2016.06.30.22.25.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Jun 2016 22:25:29 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D1E61562-C604-42F3-A7DC-AA065E0DC799 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13F69) In-Reply-To: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 1 Jul 2016 07:25:26 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <994121658.55005.1467329084208.JavaMail.yahoo@mail.yahoo.com> To: Oleg Gryb Archived-At: Cc: "oauth@ietf.org" , Liyu Yi Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 05:25:35 -0000 --Apple-Mail-D1E61562-C604-42F3-A7DC-AA065E0DC799 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Oleg! Hello! Great to see you pop up here with a similar concern. John Bradley just answered this thread with the details I was looking for (t= hanks John, hat tip your way). He also mentioned details about fragment leakage: "Browsers now re-append fragments across 302 redirects unless they are expl= icitly cleared this makes fragment encoding less safe than it was when origi= nally specified" Again, I'm new here but I'm grateful for this conversation. Aloha, -- Jim Manico @Manicode > On Jul 1, 2016, at 1:24 AM, Oleg Gryb wrote: >=20 > We've discussed access tokens in URI back in 2010 (https://www.ietf.org/ma= il-archive/web/oauth/current/msg04043.html). There were two major objectives= when I was saying that it's not secure: >=20 > 1. Fragment is not sent to a server by a browser. When I've asked if this i= s true for every browser in the world, nobody was able to answer. > 2. Replacing with POST would mean a significant performance impact in some= high volume implementations (I think it was Goole folks who were saying thi= s, but I don't remember now). >=20 > AFAIR, nobody was arguing about browsing history, so it's valid. >=20 > So, 6 years later we're at square one with this and I hope that this time t= he community will be more successful with getting rid of secrets in URL. >=20 > BTW, Jim, if you can come up with other scenarios when fragments can leak,= please share. It'll probably help the community with solving this problem f= aster than in 6 years. >=20 > Thanks, > Oleg. >=20 >=20 > From: Jim Manico > To: Liyu Yi ; oauth@ietf.org=20 > Sent: Wednesday, June 29, 2016 7:30 AM > Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit gran= t >=20 > > Shouldn=E2=80=99t it be more secure if we change to use a post method fo= r access token, similar to the SAML does? > I say yes. But please note I'm very new at this and someone with more expe= rience will have more to say or correct my comments. > Here are a few more details to consider. > 1) OAuth is a framework and not a standard, per se. Different authorizatio= n servers will have different implementations that are not necessarily compa= tible with other service providers. So there is no standard to break, per se= . > 2) Sensitive data in a URI is a bad idea. They leak all over the place eve= n over HTTPS. Even in fragments. > 3) Break the "rules" and find a way to submit sensitive data like access t= okens, session information or any other (even short term) sensitive data in a= secure fashion. This includes POST, JSON data payloads over PUT/PATCH and o= ther verbs - all over well configured HTTPS. > 4) If you really must submit sensitive data over GET , consider JWT/JWS/JW= E (with limited scopes/lifetimes) to provide message level confidentiality a= nd integrity. > Aloha, > Jim Manico > Manicode Security > https://www.manicode.com >=20 >> On 6/27/16 9:30 PM, Liyu Yi wrote: >> While we are working on a project with OAuth2 implementation, one questio= n arises from our engineers. >> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30,= it is specified that >> =20 >> (C) Assuming the resource owner grants access, the authorization >> server redirects the user-agent back to the client using the >> redirection URI provided earlier. The redirection URI includes >> the access token in the URI fragment. >> =20 >> For my understanding, the browser keeps the URI fragment in the history, a= nd this introduces unexpected exposure of the access token. A user without a= uthorization for the resource can get the access token as long as he has the= access to the browser. This can happen in a shared computer in library, or f= or an IT staff who works on other employee=E2=80=99s computer. >> =20 >> Shouldn=E2=80=99t it be more secure if we change to use a post method for= access token, similar to the SAML does? >> I feel there might be something I missed here. Any advices will be apprec= iated. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > --=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail-D1E61562-C604-42F3-A7DC-AA065E0DC799 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Oleg! Hello! Great to see you pop up h= ere with a similar concern.

John Bradley just answered this thread with the= details I was looking for (thanks John, hat tip your way).

He also mention= ed details about fragment leakage:

<= /div>
"Browsers now re-append  fragments across 302 redirec= ts unless they are explicitly cleared this makes fragment encoding less safe= than it was when originally specified"

Again, I'm new here but I'm g= rateful for this conversation.

Aloha,
<= div>--
Jim Manico
@Manicode

On Jul 1= , 2016, at 1:24 AM, Oleg Gryb <ole= g_gryb@yahoo.com> wrote:

=
We've discuss= ed access tokens in URI back in 2010 (https://www.ietf.org/mail-arc= hive/web/oauth/current/msg04043.html). There were two major objectives w= hen I was saying that it's not secure:

1. Fragment is not sent to a server by a browser. Wh= en I've asked if this is true for every browser in the world, nobody was abl= e to answer.
2. Replacing with POST would mean a significant performance impact in som= e high volume implementations (I think it was Goole folks who were saying th= is, but I don't remember now).

AFAIR, nobody was arguing about browsing history, so it's va= lid.

<= /div>
So, 6 year= s later we're at square one with this and I hope that this time the communit= y will be more successful with getting rid of secrets in URL.

BTW, Jim, if you can come up w= ith other scenarios when fragments can leak, please share. It'll probably he= lp the community with solving this problem faster than in 6 years.

Thanks,
Oleg.


From: Jim Manico <jim@manicode.com>
To:= Liyu Yi <liyuyi@gmail.com= >; oauth@ietf.org
Sent: Wednesday, June 2= 9, 2016 7:30 AM
Subjec= t: Re: [OAUTH-WG] Security concern for URI fragment as Implicit g= rant

> Shouldn=E2=80=99t it= be more secure if we change to use a post method for access token, similar to the SAML does?=
I say yes. But please n= ote I'm very new at this and someone with more experience will have more to say or correct my comments.
Here are a few more det= ails to consider.
1) OAuth is a framework= and not a standard, per se. Different authorization servers will have different implementations that are not necessarily compatible with other service providers. So there is no standard to break, per se.
2) Sensitive data in a URI is a bad idea. They leak all over the place even over HTTPS. Even in fragments.
3) Break the "rules" and find a way to submit sensitive data like access tokens, session information or any other (even short term) sensitive data in a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other verbs - all over well configured HTTPS.
4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level confidentiality and integrity.
Aloha,
Jim Manico
Manicode Security
https://www.manicod=
e.com

<= div class=3D"yiv5114557498moz-cite-prefix">On 6/27/16 9:30 PM, Liyu Yi wrote= :
While we a= re working on a project with OAuth2 implementation, one question arises from our engineers.
We notice= d at https://tools.ietf.org/html/draft-ietf-oauth-v2= -31#page-30, it is specified that
  
(C) = Assuming the resource owner grants access, the authorization
 &nb= sp;      server redirects the user-agent back to the client using the
 &nb= sp;      redirection URI provided earlier.  The redirection URI includes
 &nb= sp;      the access token in the URI fragment.
 
For my un= derstanding, the browser keeps the URI fragment in the history, and this introduces unexpected exposure of the access token. A user without authorization for the resource can get the access token as long as he has the access to the browser. This can happen in a shared computer in library, or for an IT staff who works on other employee=E2=80=99s computer.
 
Shouldn=E2= =80=99t it be more secure if we change to use a post method for access token, similar to the SAML does?
I feel th= ere might be something I missed here. Any advices will be appreciated.


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


--=20

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


= --Apple-Mail-D1E61562-C604-42F3-A7DC-AA065E0DC799--