From nobody Thu Apr 2 11:28:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A530F1A0262; Thu, 2 Apr 2015 11:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOlKyJj6YpD1; Thu, 2 Apr 2015 11:28:19 -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 02BB91A014E; Thu, 2 Apr 2015 11:28:18 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MUILK-1Z4muV41Uw-00Qz2B; Thu, 02 Apr 2015 20:28:14 +0200 Message-ID: <551D8A3C.1060300@gmx.net> Date: Thu, 02 Apr 2015 20:28:12 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tim McLean References: <551D6734.4010907@gmail.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PFs4ucScXfMpicxAbVaN6oNv7AA9LGG3A" X-Provags-ID: V03:K0:6FitXFfqv97UwoEHibY/suQAl8KD2uqIv91irJvzzCb3TUXpnnA aETd0jRzsQ9W+jaNbo24X9xnlHA7RruNPG8VElOS7ss0vL7rIg4jos9J6atpTdQdsjMkBl3 kYm5DZbMFc3BD+ycZ20s2T/RmiJKk2K3eZ0+G8GJgLqBKUWwCgK8t2bh5Nevfrz5WX8qvTa wBF2RaL/CpxQiBvNG8iyg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "oauth@ietf.org" , jose@ietf.org Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 18:28:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PFs4ucScXfMpicxAbVaN6oNv7AA9LGG3A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [[adding oauth@ietf.org]] On 04/02/2015 08:01 PM, Tim McLean wrote: > However, I do think one way of gauging the success of JWS/JOSE is to > measure how many implementers actually get the security details right. = I agree with you. If several people got this wrong then it is a good idea to write about it. Of course, it was a bit difficult to foresee this issue at the time of writing the specification. At a minimum we should put a version of your article at oauth.net. Since the JWT spec (which you reference in your article) is still in Auth48 state we can still add a warning remark to Section 7.2 of https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32. Ciao Hannes --PFs4ucScXfMpicxAbVaN6oNv7AA9LGG3A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHYo8AAoJEGhJURNOOiAtTQcH/jMMFwJaepulmTbIXeaQrZRo j3rnFq+gkw8ElGNcydmj2Q48AoYEUZEq3Mbphoo6rYjruhiHqoc9JZGuen+p422O +j3/OETb+kiGJJf1AviCfcmNNZ8dDTSBPEQxOGiz/cY9PImS/baIHpViiaP8ySg+ GGtCFsblmp6f/CyY2M+KtPwS4vzOZ1mO3olOqmzvi4dXpJscYeE0CB8rC+2W2hMj lnL8jPqe6KFW3heVV7X9UsjB00Q9aDeokSojg+2bMOLItYGY7y1HDkuISgFtSLxr q3uBuX0b0pt3915NxE5nEwRHSYhA3Sve/afJlizIc+0H6xttXRGZsFOdVaiI600= =Ul8M -----END PGP SIGNATURE----- --PFs4ucScXfMpicxAbVaN6oNv7AA9LGG3A-- From nobody Thu Apr 2 11:43:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85EE1A0191; Thu, 2 Apr 2015 11:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFGyJECwXD1Q; Thu, 2 Apr 2015 11:42:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0091A1AB4; Thu, 2 Apr 2015 11:42:45 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.125.14; Thu, 2 Apr 2015 18:42:44 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0125.002; Thu, 2 Apr 2015 18:42:43 +0000 From: Mike Jones To: Hannes Tschofenig , Tim McLean Thread-Topic: [OAUTH-WG] [jose] Security research on JWT implementations Thread-Index: AQHQbVnsrX5O/i4ek0WgSxoL/JpOip054RYAgAAiSwCAAAd4AIAAA4Kw Date: Thu, 2 Apr 2015 18:42:43 +0000 Message-ID: References: <551D6734.4010907@gmail.com> <551D8A3C.1060300@gmx.net> In-Reply-To: <551D8A3C.1060300@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.121.212.85] authentication-results: gmx.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(24454002)(13464003)(76176999)(54356999)(87936001)(99286002)(86612001)(86362001)(2656002)(50986999)(62966003)(106116001)(2950100001)(66066001)(2900100001)(92566002)(19580405001)(19580395003)(93886004)(33656002)(46102003)(122556002)(102836002)(77156002)(77096005)(74316001)(76576001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0534947130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 18:42:43.8837 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" , "jose@ietf.org" Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 18:42:55 -0000 This warning is already in place in https://tools.ietf.org/html/draft-ietf-= oauth-json-web-token-32#section-7.2. It says: Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithm(s) used in the JWT are acceptable to the application, it SHOULD reject the JWT. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, April 02, 2015 11:28 AM To: Tim McLean Cc: oauth@ietf.org; jose@ietf.org Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations [[adding oauth@ietf.org]] On 04/02/2015 08:01 PM, Tim McLean wrote: > However, I do think one way of gauging the success of JWS/JOSE is to=20 > measure how many implementers actually get the security details right. I agree with you. If several people got this wrong then it is a good idea to write about it. = Of course, it was a bit difficult to foresee this issue at the time of writ= ing the specification. At a minimum we should put a version of your article at oauth.net. Since the JWT spec (which you reference in your article) is still in Auth48 state we can still add a warning remark to Section 7.2 of https://to= ols.ietf.org/html/draft-ietf-oauth-json-web-token-32. Ciao Hannes From nobody Thu Apr 2 11:53:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6371A1A98 for ; Thu, 2 Apr 2015 11:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXopOyRh8o_X for ; Thu, 2 Apr 2015 11:53:14 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (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 F315C1A1A34 for ; Thu, 2 Apr 2015 11:53:13 -0700 (PDT) Received: by wiaa2 with SMTP id a2so116010902wia.0 for ; Thu, 02 Apr 2015 11:53:12 -0700 (PDT) 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:cc:content-type; bh=R8fjmaM3QNeyLmvtlCVt0AOQsN1gQ04HK5LGUBDX1C8=; b=M8VQo32Mh+WuQGJxCPNCbbtn3DwDcdy0UeecOE8VOKq4FR8jbLC8UhOKBTzdB83bgj K9cZh152ayqcoLh0LvssesppuSeoRVWCkAfkNvh4VShZRTXIE/IYhHNpPVNZiC7MhfOD fJvCqG9T048sxveZP27A8FPF/pRJVgRNqCA4acoHW4zQl/J9+A9wd9obj0H5uSYnFoHD AgmdN0cMbkUItZy0id//fRvzRprrN0kf7YNii+Vf7JXaohmWYfonWu9f4rVdVc5eXYKL CZjLE0LbsomRdPnnb3TuyqnmkPK/TGnnBDv/1u3ESvN0LBLiP+vxa8A5NcWFYt6Izk6a 7ing== X-Gm-Message-State: ALoCoQnd+9an8AWB5Rj9kxJX8/go9j5usu7q2ZfdfY5kHnDsmKJ7SSVxexXNtwi2sznIGqVju03n X-Received: by 10.180.7.169 with SMTP id k9mr26530950wia.48.1428000792707; Thu, 02 Apr 2015 11:53:12 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com. [209.85.212.171]) by mx.google.com with ESMTPSA id ln8sm2149402wjc.18.2015.04.02.11.53.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 11:53:11 -0700 (PDT) Received: by wiaa2 with SMTP id a2so116010194wia.0; Thu, 02 Apr 2015 11:53:11 -0700 (PDT) X-Received: by 10.194.83.66 with SMTP id o2mr98169998wjy.55.1428000791154; Thu, 02 Apr 2015 11:53:11 -0700 (PDT) MIME-Version: 1.0 References: <551D6734.4010907@gmail.com> <551D8A3C.1060300@gmx.net> In-Reply-To: From: Aaron Parecki Date: Thu, 02 Apr 2015 18:53:10 +0000 Message-ID: To: Mike Jones , Hannes Tschofenig , Tim McLean Content-Type: multipart/alternative; boundary=047d7bd6bbcae558f70512c2576e Archived-At: Cc: "oauth@ietf.org" , "jose@ietf.org" Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 18:53:19 -0000 --047d7bd6bbcae558f70512c2576e Content-Type: text/plain; charset=UTF-8 I'm not sure what article you're referring to, but feel free to add the article and send a pull request to oauth.net: https://github.com/aaronpk/oauth.net Here's an example of the PR for the Authentication article that Justin added: https://github.com/aaronpk/oauth.net/pull/81 Aaron Parecki On Thu, Apr 2, 2015 at 1:43 PM Mike Jones wrote: > This warning is already in place in https://tools.ietf.org/html/ > draft-ietf-oauth-json-web-token-32#section-7.2. It says: > > Finally, note that it is an application decision which algorithms may > be used in a given context. Even if a JWT can be successfully > validated, unless the algorithm(s) used in the JWT are acceptable to > the application, it SHOULD reject the JWT. > > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, April 02, 2015 11:28 AM > To: Tim McLean > Cc: oauth@ietf.org; jose@ietf.org > Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations > > [[adding oauth@ietf.org]] > > On 04/02/2015 08:01 PM, Tim McLean wrote: > > However, I do think one way of gauging the success of JWS/JOSE is to > > measure how many implementers actually get the security details right. > > I agree with you. > > If several people got this wrong then it is a good idea to write about it. > Of course, it was a bit difficult to foresee this issue at the time of > writing the specification. > > At a minimum we should put a version of your article at oauth.net. > > Since the JWT spec (which you reference in your article) is still in > Auth48 state we can still add a warning remark to Section 7.2 of > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --047d7bd6bbcae558f70512c2576e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure what article you're referring to, but= feel free to add the article and send a pull request to oauth.net:

https://github.com/aaronpk/oauth.net

Here'= ;s an example of the PR for the Authentication article that Justin added: <= a href=3D"https://github.com/aaronpk/oauth.net/pull/81">https://github.com/= aaronpk/oauth.net/pull/81

Aaron Parecki
<= div>=C2=A0



On Thu, Apr 2, 2015 at 1:43 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
This warning is already in place in https://tools.ietf.org/html/draft-ietf-oauth-= json-web-token-32#section-7.2.=C2=A0 It says:

=C2=A0 =C2=A0Finally, note that it is an application decision which algorit= hms may
=C2=A0 =C2=A0be used in a given context.=C2=A0 Even if a JWT can be success= fully
=C2=A0 =C2=A0validated, unless the algorithm(s) used in the JWT are accepta= ble to
=C2=A0 =C2=A0the application, it SHOULD reject the JWT.

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

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 02, 2015 11:28 AM
To: Tim McLean
Cc: oauth@ietf.org;= jose@ietf.org
Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations

[[adding oauth@ietf.org= ]]

On 04/02/2015 08:01 PM, Tim McLean wrote:
> However, I do think one way of gauging the success of JWS/JOSE is to > measure how many implementers actually get the security details right.=

I agree with you.

If several people got this wrong then it is a good idea to write about it. = Of course, it was a bit difficult to foresee this issue at the time of writ= ing the specification.

At a minimum we should put a version of your article at oauth.net.

Since the JWT spec (which you reference in your article) is still in
Auth48 state we can still add a warning remark to Section 7.2 of https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32.

Ciao
Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--047d7bd6bbcae558f70512c2576e-- From nobody Thu Apr 2 13:39:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8ED1A1A69 for ; Thu, 2 Apr 2015 13:39:23 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA6SZeS6-iIB for ; Thu, 2 Apr 2015 13:39:21 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 3A14E1A1A5A for ; Thu, 2 Apr 2015 13:39:21 -0700 (PDT) Received: by qgh3 with SMTP id 3so79576467qgh.2 for ; Thu, 02 Apr 2015 13:39:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=lVcCVLCkArOkRu6kJ/7l7/l3abedctGex6Gup0S/63s=; b=EBfatQBRT+n80s1Uh0FtNk7P53JHT+tHpQKHzHftKMM7u9T/Mq1KiJF5RBwwOCUsTW JgIuZ0Fe3voMwyz4mbvhJQGD6AQbPBPqw3ia0oSyx2QYwM8pwEhLU8SmVNsNMyLeXA7K pZ8EwljNHVE88Ozbu8aADs35RQjRAb/QTzDA7L+H1djEKER9OeU9UDd1n/aeOLbSCFWp 2ntEdnJJA+fMFHbg7lZYWkauC2SeeV7JD0SzBFAcxY3j9WoPeHQLQ/AdciT3XV78worT XjN2uqe1k/Cfgye96cfHc5f7s8T5xEPeUaB+INy3zHv1MHzMWnHw11ZDuY0vr4Vb7tfl OJ9A== X-Gm-Message-State: ALoCoQl5KTZszfTEg+FVnyvjwGLdgPbCjVTZfytW6GDafh2qUEszRm167peGwigDJrOmBFrq99nV X-Received: by 10.140.41.213 with SMTP id z79mr61451624qgz.103.1428007160468; Thu, 02 Apr 2015 13:39:20 -0700 (PDT) Received: from [192.168.8.100] ([181.202.169.108]) by mx.google.com with ESMTPSA id d36sm4213525qkh.45.2015.04.02.13.39.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 13:39:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C1F531E6-6569-4774-ABD8-19ACF856C012"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Thu, 2 Apr 2015 17:39:13 -0300 Message-Id: <37B89CA4-0242-41B8-841D-A4C88A1B2B76@ve7jtb.com> References: <551D6734.4010907@gmail.com> <551D8A3C.1060300@gmx.net> To: Michael Jones X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "jose@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 20:39:23 -0000 --Apple-Mail=_C1F531E6-6569-4774-ABD8-19ACF856C012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sec 10.6 and 10.7 of JWS also touch on algorithm substitution. Allowing keys to be used with multiple algorithms is a general problem, = and almost always turns out unhappily. I think that using a RSA key for HMAC is the most extreme case of that = principal. I do think that outside of the JOSE and JWT specs we need more = implementer guidance encouraging the use of "alg" and "use" in JWK=20 as well as propagating that information into local key stores so that = the wrong key is not selected. The problem applications in question simply took the "iss" and or the = "kid" and retuned a key without looking at the "alg". A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5 = and that would not be a problem until one of them is deprecated. =20 Having libraries assume that there can only be one alg per issuer would = not lead to useful crypto agility in my experience. John B. > On Apr 2, 2015, at 3:42 PM, Mike Jones = wrote: >=20 > This warning is already in place in = https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2= . It says: >=20 > Finally, note that it is an application decision which algorithms = may > be used in a given context. Even if a JWT can be successfully > validated, unless the algorithm(s) used in the JWT are acceptable to > the application, it SHOULD reject the JWT. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Thursday, April 02, 2015 11:28 AM > To: Tim McLean > Cc: oauth@ietf.org; jose@ietf.org > Subject: Re: [OAUTH-WG] [jose] Security research on JWT = implementations >=20 > [[adding oauth@ietf.org]] >=20 > On 04/02/2015 08:01 PM, Tim McLean wrote: >> However, I do think one way of gauging the success of JWS/JOSE is to=20= >> measure how many implementers actually get the security details = right. >=20 > I agree with you. >=20 > If several people got this wrong then it is a good idea to write about = it. Of course, it was a bit difficult to foresee this issue at the time = of writing the specification. >=20 > At a minimum we should put a version of your article at oauth.net. >=20 > Since the JWT spec (which you reference in your article) is still in > Auth48 state we can still add a warning remark to Section 7.2 of = https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32. >=20 > Ciao > Hannes >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_C1F531E6-6569-4774-ABD8-19ACF856C012 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA0MDIyMDM5MTNaMCMGCSqGSIb3DQEJBDEWBBSaGki4I68v+wg+29ohyqzl liIJNTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBjOlE/rK9aaXwWHHeTMygoa45lPiyvd2Qk2D8bQYIPyCgIGTRaDGHx cBB2wq86CdpnuWwBfqTXJS/4qayfJ3I5T2DvuLZHwe6b2+zo1JEmNKRgnrJ8qruPYVuBp4rB8WsJ QTliwsw+hXH0k5lIzMcgiajTkN0tuXm6UlaEY1HWQEF++tF48B9+MbRWMWU6lRCD4+YvooDEvKOj 7FeWc7sTV/S30+kGux3/5yUhE2MDn3gieUF9u8+uX9DQ6Ckqa/GYzeOa+ulGsVUJOI5Vob1h5uPU 8d63Zw7/3W4fC5HLu2jfYpqpfe6bD/iTVPkIo5Ti9J+oWQue+5qli8m7D3fkAAAAAAAA --Apple-Mail=_C1F531E6-6569-4774-ABD8-19ACF856C012-- From nobody Thu Apr 2 13:57:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7935B1A1B27 for ; Thu, 2 Apr 2015 13:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umSlkw8UouTh for ; Thu, 2 Apr 2015 13:56:59 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (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 1E22D1A1B0E for ; Thu, 2 Apr 2015 13:56:59 -0700 (PDT) Received: by obbec2 with SMTP id ec2so146531193obb.3 for ; Thu, 02 Apr 2015 13:56:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kRzp7Gl65/Zf1U1sgCP+HPqsdRzqmPUNBC+J4aCUqXo=; b=DjnKqzKQUqDRiSeUtu0FDJ2349tOrwEhh973z8xh3pmslAXAIQWSUHL6kQJKGFARjY 1TltS+pxKTvL4VeMPlRSrPXHlRIgd6zAiDaZEsx6xyULKMP4wmAh88TmWwmoq3UDGRCV 0irkLq9kAxx+3rnDRcmyCnt1IxQlPW79fPftaOXOkiM0EeiB9cle/YKS4BV8NKv87xCc 31B7mtzQmhxxSiPe+nqS4n7HhvRBNyXZOwhbC1LG6gPKXxtINi6BZ9y2rpfvvDtgdp3S nOjUsrXPVav4tuNka2KpWUpF6pjjxxI5U8i40O1el1fI4jEGjZHBRzoW1TCLDDrsn5pl o3OA== X-Gm-Message-State: ALoCoQn45d61oPs0Gr8kmKSZn45iw7oEp89QOFxzY7jrwZEQpOdZ4sUpc6uRYFNuW4nmZV1j1Bot X-Received: by 10.60.51.6 with SMTP id g6mr15831763oeo.45.1428008218601; Thu, 02 Apr 2015 13:56:58 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com. [209.85.214.169]) by mx.google.com with ESMTPSA id rd5sm5294538obc.20.2015.04.02.13.56.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 13:56:58 -0700 (PDT) Received: by obbec2 with SMTP id ec2so146530715obb.3; Thu, 02 Apr 2015 13:56:57 -0700 (PDT) X-Received: by 10.182.94.212 with SMTP id de20mr49588687obb.84.1428008217931; Thu, 02 Apr 2015 13:56:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.203.83 with HTTP; Thu, 2 Apr 2015 13:56:37 -0700 (PDT) In-Reply-To: References: <551D6734.4010907@gmail.com> <551D8A3C.1060300@gmx.net> From: Tim McLean Date: Thu, 2 Apr 2015 16:56:37 -0400 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8fb2020e90f72a0512c4123f Archived-At: Cc: "oauth@ietf.org" , "jose@ietf.org" Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 20:57:00 -0000 --e89a8fb2020e90f72a0512c4123f Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 2:42 PM, Mike Jones wrote: > This warning is already in place in > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2. > It says: > > Finally, note that it is an application decision which algorithms may > be used in a given context. Even if a JWT can be successfully > validated, unless the algorithm(s) used in the JWT are acceptable to > the application, it SHOULD reject the JWT. > > Thanks for highlighting this, Mike. I think it's interesting to note that this doesn't entirely prevent the HMAC/RSA (or HMAC/ECDSA) vulnerability, at least in the way this advice is usually implemented. Let's say an application legitimately wants to use both HMAC and RSA but with different keys (obviously). They would whitelist both algorithms, and would likely give each key a different key ID. This could still be exploitable in implementations that use the alg field, since alg would still determine how the key is used. Tim --e89a8fb2020e90f72a0512c4123f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 2, 2015 at 2:42 PM, Mike Jones <Michael.Jones@microsoft.= com> wrote:
This warning is= already in place in https://tools.ietf.org/h= tml/draft-ietf-oauth-json-web-token-32#section-7.2.=C2=A0 It says:

=C2=A0 =C2=A0Finally, note that it is an application decision which algorit= hms may
=C2=A0 =C2=A0be used in a given context.=C2=A0 Even if a JWT can be success= fully
=C2=A0 =C2=A0validated, unless the algorithm(s) used in the JWT are accepta= ble to
=C2=A0 =C2=A0the application, it SHOULD reject the JWT.


Thanks for high= lighting this, Mike.

I think it's interesting to note that this doesn'= ;t entirely prevent the HMAC/RSA (or HMAC/ECDSA) vulnerability, at least in= the way this advice is usually implemented.=C2=A0 Let's say an applica= tion legitimately wants to use both HMAC and RSA but with different keys (o= bviously).=C2=A0 They would whitelist both algorithms, and would likely giv= e each key a different key ID.=C2=A0 This could still be exploitable in imp= lementations that use the alg field, since alg would still determine how th= e key is used.

Tim
--e89a8fb2020e90f72a0512c4123f-- From nobody Thu Apr 2 14:23:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089FD1A6EEC for ; Thu, 2 Apr 2015 14:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCCdNx-R_Z3o for ; Thu, 2 Apr 2015 14:23:24 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (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 35A151A6EE0 for ; Thu, 2 Apr 2015 14:23:24 -0700 (PDT) Received: by obbec2 with SMTP id ec2so147416729obb.3 for ; Thu, 02 Apr 2015 14:23:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8Gr78TLpnpN8G8d6xRxXEMpFqOM7KcpsaImEtmj7SOw=; b=Q6EkgYIv3nHPHNdWh1vEVrzSXO1xjKTFplDh5aNU986UU5aUV1z5t0T5ThVcTL8IbJ yK+RqiUuejb2r6gHm3vr2a1drAEIyenN/cSoexAomO5S16dbRW4PXKlKJmpvfJRL8w7z 0qnNZfbkUkQcx7+EewZ/PPVwHBcEUeu4w0cCbRPhDCqAGSxZoMmvMM/vri8fVl4BDNn7 rMC+vaec4IMihZMiYWzvW/lu6z2jb/wjxdZa7cJYj4BLdXQz1iHxNN1dfLQlVRgHHBOm 3ZM+CppsEGoCtWGF6CUjFusMuHqBsfRKG6HKjSUJMJZOOXlyosX9Tc/F/6YGa2HeaJx3 rDPg== X-Gm-Message-State: ALoCoQlLe0pmPoy78IIVSI2WmFqSxePMduZdr0U1knwoA/AZ17ZxKdtjtRICay8uZ4un2toMVElK X-Received: by 10.60.103.80 with SMTP id fu16mr3821045oeb.52.1428009803699; Thu, 02 Apr 2015 14:23:23 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com. [209.85.214.169]) by mx.google.com with ESMTPSA id je2sm5349876oeb.5.2015.04.02.14.23.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 14:23:23 -0700 (PDT) Received: by obvd1 with SMTP id d1so148846390obv.0; Thu, 02 Apr 2015 14:23:23 -0700 (PDT) X-Received: by 10.60.47.104 with SMTP id c8mr15404200oen.51.1428009803202; Thu, 02 Apr 2015 14:23:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.203.83 with HTTP; Thu, 2 Apr 2015 14:23:03 -0700 (PDT) In-Reply-To: <37B89CA4-0242-41B8-841D-A4C88A1B2B76@ve7jtb.com> References: <551D6734.4010907@gmail.com> <551D8A3C.1060300@gmx.net> <37B89CA4-0242-41B8-841D-A4C88A1B2B76@ve7jtb.com> From: Tim McLean Date: Thu, 2 Apr 2015 17:23:03 -0400 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11c1f4020e45660512c4711c Archived-At: Cc: "oauth@ietf.org" , "jose@ietf.org" Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 21:23:25 -0000 --001a11c1f4020e45660512c4711c Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 4:39 PM, John Bradley wrote: > A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5 > and that would not be a problem until one of them is deprecated. > Having libraries assume that there can only be one alg per issuer would > not lead to useful crypto agility in my experience. > Note that I'm proposing one alg per key ID, not one alg per issuer (sorry in advance if I misunderstood what you meant here). Tim --001a11c1f4020e45660512c4711c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 2, 2015 at 4:39 PM, John Bradley <ve7jtb@ve7jtb.com>= wrote:
A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5 and= that would not be a problem until one of them is deprecated.
Having libraries assume that there can only be one alg per issuer would not= lead to useful crypto agility in my experience.

<= /div>
Note that I'm proposing one alg per key ID, not one alg per i= ssuer (sorry in advance if I misunderstood what you meant here).

Tim
--001a11c1f4020e45660512c4711c-- From nobody Thu Apr 2 16:06:30 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6749D1A878B for ; Thu, 2 Apr 2015 16:06:26 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJNgicsR8Cbh for ; Thu, 2 Apr 2015 16:06:25 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (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 417431A8798 for ; Thu, 2 Apr 2015 16:06:21 -0700 (PDT) Received: by qgh3 with SMTP id 3so82100573qgh.2 for ; Thu, 02 Apr 2015 16:06:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=t/9bosdb210PdnUul4nLU9HN/fzZ7kEEaZG5vArEmkY=; b=ODLk4yQRS1IG9bU1JAj2wfXfk7pTXO7huZNThwkW21fgtnwaPigIPzQTz5i5ZvTlw4 0aXmV2GihK2CiUiHNlcnQuN0UkGH1CtxNootpT0QLnyNWGQd9IlauS1FLAUyp4uGiIbr bhdjhVLaa0ouZ79fOvKHyKLfsIcjzz/aAbB2OM4SL+FNt2ZuGeVbOeneCfgblJMm0ahG BAe5huEHn9otpEJyHoby2GW8iXGb4ab3n20Nu7ws3PI7glQkvp9QX22Ub3y8NdbL5KiC 97+TGufLaKomR177E9iWqpDjMpVMXsWkDDOr2ckkuUAAlJyhvkDQ4TpJHor9h2ODxhTl NeRA== X-Gm-Message-State: ALoCoQn28JglsdpU+5QMwV5ZfZMjNIuwkGVw8iQsPnjkRJRq6EOaXgXZkrqYzSmZVOejKNE6DSkB X-Received: by 10.140.232.197 with SMTP id d188mr66914025qhc.80.1428015980289; Thu, 02 Apr 2015 16:06:20 -0700 (PDT) Received: from [10.231.205.236] ([201.220.243.161]) by mx.google.com with ESMTPSA id o186sm4481679qhb.10.2015.04.02.16.06.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 16:06:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1A876574-3034-41BE-A33B-40842249218D Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Thu, 2 Apr 2015 20:00:14 -0300 Content-Transfer-Encoding: 7bit Message-Id: <10432770-DDDE-40A7-B1A5-FD26F898F11B@ve7jtb.com> References: <551D6734.4010907@gmail.com> <551D8A3C.1060300@gmx.net> <37B89CA4-0242-41B8-841D-A4C88A1B2B76@ve7jtb.com> To: Tim McLean Archived-At: Cc: "oauth@ietf.org" , "jose@ietf.org" Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 23:06:26 -0000 --Apple-Mail-1A876574-3034-41BE-A33B-40842249218D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I agree that the best thing is one alg per kid.=20 However getting people especially those using x509 Certs to alg is a challen= ge.=20 People still want to do pkcs1.5 pss sha256 sha512 off of one key.=20 With composite keys you need the alg to know the hash using x509 Certs.=20 I think more advice for applications using JOSE libs to help them understand= key management and comparing the alg in the JWT with the specific alg in a J= WK or with a known subset of algs based on the key type is the best path.=20= John B.=20 Sent from my iPhone > On Apr 2, 2015, at 6:23 PM, Tim McLean wrote: >=20 >> On Thu, Apr 2, 2015 at 4:39 PM, John Bradley wrote: >> A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5 a= nd that would not be a problem until one of them is deprecated. >> Having libraries assume that there can only be one alg per issuer would n= ot lead to useful crypto agility in my experience. >=20 > Note that I'm proposing one alg per key ID, not one alg per issuer (sorry i= n advance if I misunderstood what you meant here).=20 >=20 > Tim --Apple-Mail-1A876574-3034-41BE-A33B-40842249218D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree that the best thing is one alg= per kid. 

However getting people especially t= hose using x509 Certs to alg is a challenge. 

= People still want to do pkcs1.5 pss sha256 sha512 off of one key. 

With composite keys you need the alg to know the hash u= sing x509 Certs. 

I think more advice for appl= ications using JOSE libs to help them understand key management and comparin= g the alg in the JWT with the specific alg in a JWK or with a known subset o= f algs based on the key type is the best path. 

John B. 

Sent from my iPhone

On Apr 2, 2015, at 6= :23 PM, Tim McLean <tim@timmclean.ne= t> wrote:

On Thu, Apr 2, 2015 a= t 4:39 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5 and t= hat would not be a problem until one of them is deprecated.
Having libraries assume that there can only be one alg per issuer would not l= ead to useful crypto agility in my experience.

Note that I'm proposing one alg per key ID, not one alg per issuer (s= orry in advance if I misunderstood what you meant here).

= Tim
= --Apple-Mail-1A876574-3034-41BE-A33B-40842249218D-- From nobody Fri Apr 3 05:08:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98881A8F3E for ; Fri, 3 Apr 2015 05:08:10 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aZ4XWaM78Kr for ; Fri, 3 Apr 2015 05:08:08 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 09F041A8AF8 for ; Fri, 3 Apr 2015 05:08:07 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so138024473wib.1 for ; Fri, 03 Apr 2015 05:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=qMqE61GgG7w5+QXRX8hdDgf3uH9LTB3GdX2y7J8KrTM=; b=IAiPb5nYVvFVyA7SXtR4fUoAmw5wgr0XPcUEQm4akR6HarkS4CzTSI+bBYguErNtoM P9nh1ai72qp/ZqK/0RGvqGTKt+0C5tUCYhMM3My/qrqus4K6ddjs+VIuqUw5HSkwnyPn 4v+XKvQukqly422cmVg0QGHNyg9hT2JHYpM5cvW4Wkbn/U6tAz3us2edH25yN2hrVM/Y gzQQB0bRLE5LSe4sW2Uj44ZVFAfkyU8VBqxk5fUBDgRWriH4hkR5UpKWae3auEUKPD7u 3tBKFry70khI9sVwVoK50T9Y6r0fUgTOObXCujZFKbpf7xefmWRwz2S+evLsY8jEecy/ JXBA== X-Received: by 10.194.193.69 with SMTP id hm5mr4379696wjc.43.1428062886673; Fri, 03 Apr 2015 05:08:06 -0700 (PDT) Received: from [10.12.70.58] (ip-109-47-194-224.web.vodafone.de. [109.47.194.224]) by mx.google.com with ESMTPSA id hj10sm11263444wjc.48.2015.04.03.05.08.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 05:08:05 -0700 (PDT) Date: Fri, 03 Apr 2015 14:07:55 +0200 Message-ID: From: Maik Mahn To: oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 78, Issue 1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 12:08:11 -0000 Ck0mTQoKb2F1dGgtcmVxdWVzdEBpZXRmLm9yZyBzY2hyaWViOgoKPlNlbmQgT0F1dGggbWFpbGlu ZyBsaXN0IHN1Ym1pc3Npb25zIHRvCj4Jb2F1dGhAaWV0Zi5vcmcKPgo+VG8gc3Vic2NyaWJlIG9y IHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0Cj4JaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+b3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1l c3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvCj4Jb2F1dGgtcmVxdWVzdEBpZXRm Lm9yZwo+Cj5Zb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQKPglv YXV0aC1vd25lckBpZXRmLm9yZwo+Cj5XaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1 YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljCj50aGFuICJSZTogQ29udGVudHMgb2Yg T0F1dGggZGlnZXN0Li4uIgo+Cj4KPlRvZGF5J3MgVG9waWNzOgo+Cj4gICAxLiBSZTogW2pvc2Vd IFNlY3VyaXR5IHJlc2VhcmNoIG9uIEpXVCBpbXBsZW1lbnRhdGlvbnMKPiAgICAgIChIYW5uZXMg VHNjaG9mZW5pZykKPiAgIDIuIFJlOiBbam9zZV0gU2VjdXJpdHkgcmVzZWFyY2ggb24gSldUIGlt cGxlbWVudGF0aW9ucyAoTWlrZSBKb25lcykKPiAgIDMuIFJlOiBbam9zZV0gU2VjdXJpdHkgcmVz ZWFyY2ggb24gSldUIGltcGxlbWVudGF0aW9ucwo+ICAgICAgKEFhcm9uIFBhcmVja2kpCj4KPgo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiAxCj5EYXRlOiBUaHUsIDAyIEFwciAyMDE1IDIwOjI4 OjEyICswMjAwCj5Gcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214 Lm5ldD4KPlRvOiBUaW0gTWNMZWFuIDx0aW1AdGltbWNsZWFuLm5ldD4KPkNjOiAib2F1dGhAaWV0 Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4sIGpvc2VAaWV0Zi5vcmcKPlN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIFtqb3NlXSBTZWN1cml0eSByZXNlYXJjaCBvbiBKV1QKPglpbXBsZW1lbnRhdGlvbnMK Pk1lc3NhZ2UtSUQ6IDw1NTFEOEEzQy4xMDYwMzAwQGdteC5uZXQ+Cj5Db250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9IndpbmRvd3MtMTI1MiIKPgo+W1thZGRpbmcgb2F1dGhAaWV0Zi5v cmddXQo+Cj5PbiAwNC8wMi8yMDE1IDA4OjAxIFBNLCBUaW0gTWNMZWFuIHdyb3RlOgo+PiBIb3dl dmVyLCBJIGRvIHRoaW5rIG9uZSB3YXkgb2YgZ2F1Z2luZyB0aGUgc3VjY2VzcyBvZiBKV1MvSk9T RSBpcyB0bwo+PiBtZWFzdXJlIGhvdyBtYW55IGltcGxlbWVudGVycyBhY3R1YWxseSBnZXQgdGhl IHNlY3VyaXR5IGRldGFpbHMgcmlnaHQuIAo+Cj5JIGFncmVlIHdpdGggeW91Lgo+Cj5JZiBzZXZl cmFsIHBlb3BsZSBnb3QgdGhpcyB3cm9uZyB0aGVuIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHdyaXRl IGFib3V0Cj5pdC4gT2YgY291cnNlLCBpdCB3YXMgYSBiaXQgZGlmZmljdWx0IHRvIGZvcmVzZWUg dGhpcyBpc3N1ZSBhdCB0aGUgdGltZQo+b2Ygd3JpdGluZyB0aGUgc3BlY2lmaWNhdGlvbi4KPgo+ QXQgYSBtaW5pbXVtIHdlIHNob3VsZCBwdXQgYSB2ZXJzaW9uIG9mIHlvdXIgYXJ0aWNsZSBhdCBv YXV0aC5uZXQuCj4KPlNpbmNlIHRoZSBKV1Qgc3BlYyAod2hpY2ggeW91IHJlZmVyZW5jZSBpbiB5 b3VyIGFydGljbGUpIGlzIHN0aWxsIGluCj5BdXRoNDggc3RhdGUgd2UgY2FuIHN0aWxsIGFkZCBh IHdhcm5pbmcgcmVtYXJrIHRvIFNlY3Rpb24gNy4yIG9mCj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0zMi4KPgo+Q2lhbwo+SGFubmVz Cj4KPi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQo+QSBub24tdGV4dCBh dHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLgo+TmFtZTogc2lnbmF0dXJlLmFzYwo+VHlwZTogYXBw bGljYXRpb24vcGdwLXNpZ25hdHVyZQo+U2l6ZTogNTEzIGJ5dGVzCj5EZXNjOiBPcGVuUEdQIGRp Z2l0YWwgc2lnbmF0dXJlCj5VUkw6IDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvYXR0YWNobWVudHMvMjAxNTA0MDIvMGY4NjI0MDEvYXR0YWNobWVudC5hc2M+Cj4K Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiAyCj5EYXRlOiBUaHUs IDIgQXByIDIwMTUgMTg6NDI6NDMgKzAwMDAKPkZyb206IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4KPlRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldD4sIFRpbSBNY0xlYW4KPgk8dGltQHRpbW1jbGVhbi5uZXQ+Cj5DYzogIm9hdXRo QGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+LCAiam9zZUBpZXRmLm9yZyIgPGpvc2VAaWV0Zi5v cmc+Cj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBbam9zZV0gU2VjdXJpdHkgcmVzZWFyY2ggb24g SldUCj4JaW1wbGVtZW50YXRpb25zCj5NZXNzYWdlLUlEOgo+CTxCWTJQUjAzTUI0NDJEOTc0NzEz MDlEQTE2QzcwQzgwQ0Y1RjIwQEJZMlBSMDNNQjQ0Mi5uYW1wcmQwMy5wcm9kLm91dGxvb2suY29t Pgo+CQo+Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSIKPgo+VGhp cyB3YXJuaW5nIGlzIGFscmVhZHkgaW4gcGxhY2UgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMzIjc2VjdGlvbi03LjIuICBJdCBz YXlzOgo+Cj4gICBGaW5hbGx5LCBub3RlIHRoYXQgaXQgaXMgYW4gYXBwbGljYXRpb24gZGVjaXNp b24gd2hpY2ggYWxnb3JpdGhtcyBtYXkKPiAgIGJlIHVzZWQgaW4gYSBnaXZlbiBjb250ZXh0LiAg RXZlbiBpZiBhIEpXVCBjYW4gYmUgc3VjY2Vzc2Z1bGx5Cj4gICB2YWxpZGF0ZWQsIHVubGVzcyB0 aGUgYWxnb3JpdGhtKHMpIHVzZWQgaW4gdGhlIEpXVCBhcmUgYWNjZXB0YWJsZSB0bwo+ICAgdGhl IGFwcGxpY2F0aW9uLCBpdCBTSE9VTEQgcmVqZWN0IHRoZSBKV1QuCj4KPgkJCQktLSBNaWtlCj4K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj5Gcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZwo+U2VudDogVGh1 cnNkYXksIEFwcmlsIDAyLCAyMDE1IDExOjI4IEFNCj5UbzogVGltIE1jTGVhbgo+Q2M6IG9hdXRo QGlldGYub3JnOyBqb3NlQGlldGYub3JnCj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBbam9zZV0g U2VjdXJpdHkgcmVzZWFyY2ggb24gSldUIGltcGxlbWVudGF0aW9ucwo+Cj5bW2FkZGluZyBvYXV0 aEBpZXRmLm9yZ11dCj4KPk9uIDA0LzAyLzIwMTUgMDg6MDEgUE0sIFRpbSBNY0xlYW4gd3JvdGU6 Cj4+IEhvd2V2ZXIsIEkgZG8gdGhpbmsgb25lIHdheSBvZiBnYXVnaW5nIHRoZSBzdWNjZXNzIG9m IEpXUy9KT1NFIGlzIHRvIAo+PiBtZWFzdXJlIGhvdyBtYW55IGltcGxlbWVudGVycyBhY3R1YWxs eSBnZXQgdGhlIHNlY3VyaXR5IGRldGFpbHMgcmlnaHQuCj4KPkkgYWdyZWUgd2l0aCB5b3UuCj4K PklmIHNldmVyYWwgcGVvcGxlIGdvdCB0aGlzIHdyb25nIHRoZW4gaXQgaXMgYSBnb29kIGlkZWEg dG8gd3JpdGUgYWJvdXQgaXQuIE9mIGNvdXJzZSwgaXQgd2FzIGEgYml0IGRpZmZpY3VsdCB0byBm b3Jlc2VlIHRoaXMgaXNzdWUgYXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGUgc3BlY2lmaWNhdGlv bi4KPgo+QXQgYSBtaW5pbXVtIHdlIHNob3VsZCBwdXQgYSB2ZXJzaW9uIG9mIHlvdXIgYXJ0aWNs ZSBhdCBvYXV0aC5uZXQuCj4KPlNpbmNlIHRoZSBKV1Qgc3BlYyAod2hpY2ggeW91IHJlZmVyZW5j ZSBpbiB5b3VyIGFydGljbGUpIGlzIHN0aWxsIGluCj5BdXRoNDggc3RhdGUgd2UgY2FuIHN0aWxs IGFkZCBhIHdhcm5pbmcgcmVtYXJrIHRvIFNlY3Rpb24gNy4yIG9mIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTMyLgo+Cj5DaWFvCj5I YW5uZXMKPgo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiAz Cj5EYXRlOiBUaHUsIDAyIEFwciAyMDE1IDE4OjUzOjEwICswMDAwCj5Gcm9tOiBBYXJvbiBQYXJl Y2tpIDxhYXJvbkBwYXJlY2tpLmNvbT4KPlRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20+LCAgSGFubmVzIFRzY2hvZmVuaWcKPgk8aGFubmVzLnRzY2hvZmVuaWdAZ214 Lm5ldD4sIFRpbSBNY0xlYW4gPHRpbUB0aW1tY2xlYW4ubmV0Pgo+Q2M6ICJvYXV0aEBpZXRmLm9y ZyIgPG9hdXRoQGlldGYub3JnPiwgImpvc2VAaWV0Zi5vcmciIDxqb3NlQGlldGYub3JnPgo+U3Vi amVjdDogUmU6IFtPQVVUSC1XR10gW2pvc2VdIFNlY3VyaXR5IHJlc2VhcmNoIG9uIEpXVAo+CWlt cGxlbWVudGF0aW9ucwo+TWVzc2FnZS1JRDoKPgk8Q0FHQlNHanJDUmN6Z1lMcEFSZnJOc09nLUc0 S05DVWUxRHVPZG1VNkJSeUdOTHIwc1RnQG1haWwuZ21haWwuY29tPgo+Q29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCIKPgo+SSdtIG5vdCBzdXJlIHdoYXQgYXJ0aWNsZSB5 b3UncmUgcmVmZXJyaW5nIHRvLCBidXQgZmVlbCBmcmVlIHRvIGFkZCB0aGUKPmFydGljbGUgYW5k IHNlbmQgYSBwdWxsIHJlcXVlc3QgdG8gb2F1dGgubmV0Ogo+Cj5odHRwczovL2dpdGh1Yi5jb20v YWFyb25way9vYXV0aC5uZXQKPgo+SGVyZSdzIGFuIGV4YW1wbGUgb2YgdGhlIFBSIGZvciB0aGUg QXV0aGVudGljYXRpb24gYXJ0aWNsZSB0aGF0IEp1c3Rpbgo+YWRkZWQ6IGh0dHBzOi8vZ2l0aHVi LmNvbS9hYXJvbnBrL29hdXRoLm5ldC9wdWxsLzgxCj4KPkFhcm9uIFBhcmVja2kKPgo+Cj4KPgo+ T24gVGh1LCBBcHIgMiwgMjAxNSBhdCAxOjQzIFBNIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4KPndyb3RlOgo+Cj4+IFRoaXMgd2FybmluZyBpcyBhbHJlYWR5IGluIHBs YWNlIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC8KPj4gZHJhZnQtaWV0Zi1vYXV0aC1q c29uLXdlYi10b2tlbi0zMiNzZWN0aW9uLTcuMi4gIEl0IHNheXM6Cj4+Cj4+ICAgIEZpbmFsbHks IG5vdGUgdGhhdCBpdCBpcyBhbiBhcHBsaWNhdGlvbiBkZWNpc2lvbiB3aGljaCBhbGdvcml0aG1z IG1heQo+PiAgICBiZSB1c2VkIGluIGEgZ2l2ZW4gY29udGV4dC4gIEV2ZW4gaWYgYSBKV1QgY2Fu IGJlIHN1Y2Nlc3NmdWxseQo+PiAgICB2YWxpZGF0ZWQsIHVubGVzcyB0aGUgYWxnb3JpdGhtKHMp IHVzZWQgaW4gdGhlIEpXVCBhcmUgYWNjZXB0YWJsZSB0bwo+PiAgICB0aGUgYXBwbGljYXRpb24s IGl0IFNIT1VMRCByZWplY3QgdGhlIEpXVC4KPj4KPj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlCj4+Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+IEZyb206 IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5l cyBUc2Nob2ZlbmlnCj4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwMiwgMjAxNSAxMToyOCBBTQo+ PiBUbzogVGltIE1jTGVhbgo+PiBDYzogb2F1dGhAaWV0Zi5vcmc7IGpvc2VAaWV0Zi5vcmcKPj4g U3ViamVjdDogUmU6IFtPQVVUSC1XR10gW2pvc2VdIFNlY3VyaXR5IHJlc2VhcmNoIG9uIEpXVCBp bXBsZW1lbnRhdGlvbnMKPj4KPj4gW1thZGRpbmcgb2F1dGhAaWV0Zi5vcmddXQo+Pgo+PiBPbiAw NC8wMi8yMDE1IDA4OjAxIFBNLCBUaW0gTWNMZWFuIHdyb3RlOgo+PiA+IEhvd2V2ZXIsIEkgZG8g dGhpbmsgb25lIHdheSBvZiBnYXVnaW5nIHRoZSBzdWNjZXNzIG9mIEpXUy9KT1NFIGlzIHRvCj4+ ID4gbWVhc3VyZSBob3cgbWFueSBpbXBsZW1lbnRlcnMgYWN0dWFsbHkgZ2V0IHRoZSBzZWN1cml0 eSBkZXRhaWxzIHJpZ2h0Lgo+Pgo+PiBJIGFncmVlIHdpdGggeW91Lgo+Pgo+PiBJZiBzZXZlcmFs IHBlb3BsZSBnb3QgdGhpcyB3cm9uZyB0aGVuIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHdyaXRlIGFi b3V0IGl0Lgo+PiBPZiBjb3Vyc2UsIGl0IHdhcyBhIGJpdCBkaWZmaWN1bHQgdG8gZm9yZXNlZSB0 aGlzIGlzc3VlIGF0IHRoZSB0aW1lIG9mCj4+IHdyaXRpbmcgdGhlIHNwZWNpZmljYXRpb24uCj4+ Cj4+IEF0IGEgbWluaW11bSB3ZSBzaG91bGQgcHV0IGEgdmVyc2lvbiBvZiB5b3VyIGFydGljbGUg YXQgb2F1dGgubmV0Lgo+Pgo+PiBTaW5jZSB0aGUgSldUIHNwZWMgKHdoaWNoIHlvdSByZWZlcmVu Y2UgaW4geW91ciBhcnRpY2xlKSBpcyBzdGlsbCBpbgo+PiBBdXRoNDggc3RhdGUgd2UgY2FuIHN0 aWxsIGFkZCBhIHdhcm5pbmcgcmVtYXJrIHRvIFNlY3Rpb24gNy4yIG9mCj4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTMyLgo+Pgo+ PiBDaWFvCj4+IEhhbm5lcwo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4gT0F1dGhAaWV0Zi5vcmcKPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pgo+LS0tLS0tLS0t LS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tCj5BbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNj cnViYmVkLi4uCj5VUkw6IDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1 dGgvYXR0YWNobWVudHMvMjAxNTA0MDIvMDk1ZWE5NGEvYXR0YWNobWVudC5odG1sPgo+Cj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+U3ViamVjdDogRGlnZXN0IEZvb3Rlcgo+Cj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+T0F1dGggbWFp bGluZyBsaXN0Cj5PQXV0aEBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aAo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5FbmQg b2YgT0F1dGggRGlnZXN0LCBWb2wgNzgsIElzc3VlIDEKPioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKgo= From nobody Fri Apr 3 10:57:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A156E1ACE7C for ; Fri, 3 Apr 2015 10:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwBx1q4ioaNW for ; Fri, 3 Apr 2015 10:57:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E931ACE77 for ; Fri, 3 Apr 2015 10:57:30 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MBVwM-1YlH7m3HOg-00AZMc for ; Fri, 03 Apr 2015 19:57:28 +0200 Message-ID: <551ED488.7000101@gmx.net> Date: Fri, 03 Apr 2015 19:57:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <551DADCB.9040803@cs.tcd.ie> In-Reply-To: <551DADCB.9040803@cs.tcd.ie> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <551DADCB.9040803@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5FHd7IQvUtFkPuKmWDULkSJbc7uiSBfQf" X-Provags-ID: V03:K0:um0CVySg+nLef3Ld0JWfPGxdOLi5H6OE6pR/kVcmrxeQolFrheS TWB+20jVxGwDc7rVylrPRupVhfCi5tna6zxCnXwYHrovu2b/MIClh2GZ3Oqul1QIW8MjXsd vX017YdoU1DhGB/r/5GtvF1kRTDyYv96Avtl9mXqqV3ZkIh+T53+r4noQUyu10FZ+QuwfY0 zQjeMX1r74UPOLwPT3xdQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 17:57:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5FHd7IQvUtFkPuKmWDULkSJbc7uiSBfQf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I learned something new: we can reference a BCP (instead of an RFC) and even if the RFC gets up-dated we will still have a stable reference. (See Stephen's response to my question below). This is what we should do for our documents when we reference TLS in the future. We would reference the yet-to-become BCP (currently UTA-TLS document) and we essentially point to the recommended usage for TLS (version, ciphersuite, everything). Isn't that great? -------------------------------------------------------- On 02/04/15 19:09, Hannes Tschofenig wrote: > Hi Stephen, >=20 > if I understand it correctly, you are saying if we reference a BCP # > (instead of the RFC) then a revised RFC will get the same BCP #. I have= > never heard about that and if that's indeed true that would be cool. I > might also have misunderstood your idea though. Yep, that's it. XML2RFC makes it hard but you can do it, worst case via an RFC editor note S. >=20 --5FHd7IQvUtFkPuKmWDULkSJbc7uiSBfQf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHtSIAAoJEGhJURNOOiAtSe0H/RvafoRsgIMs4CfxMgDm4ZuS 8VIPO/GiqE9xQrZ/ahF+JKO9B/DR2HchEucgXHf1NL7hdhl2h3bXHj762ocwtcZu Stt3iN28zI6QRHM3eRmVtPASr3qBlnBN/aP8pxl2MTe6HlvmONQwT4e3Yc8YXeLY ImWJR1Rk+3sgIB2PfRHvXPo1SyqnZQpZ3RNPOKdHExzAScJQELGhGM4/VzUjth7W xRBi00KH1x2JY+j4CCV0aDVY5ZwD0W63HptJnc5Mpdf3gSGMKW6VCaxkq28BReie n2NZK2Ij6eE5A/o/Q9y/iwpknyMGJEHs6qXubzgnt2rWmgi/N3XT89oi/VGbYMI= =fTNt -----END PGP SIGNATURE----- --5FHd7IQvUtFkPuKmWDULkSJbc7uiSBfQf-- From nobody Fri Apr 3 12:09:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1D1B2A23 for ; Fri, 3 Apr 2015 12:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28Ohzy0L45MK for ; Fri, 3 Apr 2015 12:09:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC87A1ACF6C for ; Fri, 3 Apr 2015 12:09:50 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MUoma-1YwjCr0sJA-00YBVw for ; Fri, 03 Apr 2015 21:09:49 +0200 Message-ID: <551EE57C.6090701@gmx.net> Date: Fri, 03 Apr 2015 21:09:48 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" References: <551DADCB.9040803@cs.tcd.ie> <551ED488.7000101@gmx.net> In-Reply-To: <551ED488.7000101@gmx.net> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XXUmukafmhtiBfusDhOtV5QckIPPmhsfV" X-Provags-ID: V03:K0:714oeKf/YylglUEeO47Y+4VsYpK63bMqDRyn0m/5cI2/NTbvuQn b+g+yI6E5PMiZwoS/dypMi7MeGhdpsouIgdsOSp6R/soS0l+iaEb/Z41Z7w9G2+9idvlJCZ 58zTWujRY3jcxjvgrCgx4lQbqwpNUX/uOYR3VRG9zGJPQkH8naH+zLo4ISLZUtIA4xOaDcq /vkXo0SROAse9bwWzyZig== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 19:09:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XXUmukafmhtiBfusDhOtV5QckIPPmhsfV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Here is an actual example. When 'Guidelines for Writing an IANA Considerations Section in RFCs' was published it got the BCP # 26. The document behind it was RFC 2434. Later an update was published, namely RFC 5226, that obsoleted RFC 2434. Now, BCP 26 points to RFC 5226, see https://tools.ietf.org/html/bcp26 On 04/03/2015 07:57 PM, Hannes Tschofenig wrote: > I learned something new: we can reference a BCP (instead of an RFC) and= > even if the RFC gets up-dated we will still have a stable reference. > (See Stephen's response to my question below). >=20 > This is what we should do for our documents when we reference TLS in th= e > future. We would reference the yet-to-become BCP (currently UTA-TLS > document) and we essentially point to the recommended usage for TLS > (version, ciphersuite, everything). >=20 > Isn't that great? >=20 > -------------------------------------------------------- >=20 > On 02/04/15 19:09, Hannes Tschofenig wrote: >> Hi Stephen, >> >> if I understand it correctly, you are saying if we reference a BCP # >> (instead of the RFC) then a revised RFC will get the same BCP #. I hav= e >> never heard about that and if that's indeed true that would be cool. I= >> might also have misunderstood your idea though. >=20 > Yep, that's it. XML2RFC makes it hard but you can do it, worst > case via an RFC editor note >=20 > S. >=20 >> >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --XXUmukafmhtiBfusDhOtV5QckIPPmhsfV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHuV8AAoJEGhJURNOOiAtxhcH/2yRzdjVTm0uTLu92wT/RsZn gB0EkdPtzhluygmkrxmSc4qYL19Vd3vlJ9KMgyNsDtls4p6MpwagnIy3uscuvQeD 02S9MhWpOm1pQh8rwO4KlIUU9jc3rUzcd84L/40bC7MhuXNvHeVb9KTHRjLg7JqU Uz63NQ20a+1Kq4HJq4BDj1A7UhiMhue2Xpk5B9fgeh/+uVoemvE8vxqZV4jrqxl3 XM+vRrwzWcs9u1xyyN4nIE6yUIBZkt8J/kNOvs2NTlltX9Fo5veW+iaDGyUNb7Ng DCCzPrgDntcJnLO+1CzELqZefj3FS0481B+HxInTxPcuUpFBGuZa56jT9j9zlgw= =aWpz -----END PGP SIGNATURE----- --XXUmukafmhtiBfusDhOtV5QckIPPmhsfV-- From nobody Fri Apr 3 12:40:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EB21A0191 for ; Fri, 3 Apr 2015 12:40:24 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5QOPrOCBNKp for ; Fri, 3 Apr 2015 12:40:22 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (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 8588C1A01E7 for ; Fri, 3 Apr 2015 12:40:22 -0700 (PDT) Received: by qcay5 with SMTP id y5so94749264qca.1 for ; Fri, 03 Apr 2015 12:40:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:content-transfer-encoding:from :mime-version:subject:date:message-id:references:cc:in-reply-to:to; bh=d0dmz9qQouzacJORJzHGmlC5Mx5Xxm76Ve+w0ZkJgHU=; b=IJlpBWKs3jimBl/J97BpkF3C5QctHkGpJDev7XdUet5rac75ndc73K70lJx48ArcTz LD8I41MQ5EFt2ff0Ci1CLLu4jsLgUy+9j7OVOy9HVmKGPH0lF7ZHKEdCwgXOa2l2syl5 g3AdmOTrDrsesmqAVmBrOXE8yVT/XY9RHSncDKKvnESXgnLIU2UyRIIkqdOjOnjyDp6m wPM/iumZzAnjm314M+dpyz0mweBnrW/t9l31MHMI2sgaKXZCh+OzQvO4CwdcGTm5hlOn ResjgqQMCaAV3jV7wRGOsKoMu/hkz67hqNAWCRFIpK22BMZv9CsiLYBznBFl61svepGo tTvQ== X-Gm-Message-State: ALoCoQmWTT3Lab+lEX/3n/RZazk7ILX9ej/D+OWjsefu+kxJbJzbEqRB/Eghr8JSCAxT6DYGjnpW X-Received: by 10.55.31.167 with SMTP id n39mr7116966qkh.59.1428090021562; Fri, 03 Apr 2015 12:40:21 -0700 (PDT) Received: from [192.168.1.36] (181-163-96-231.baf.movistar.cl. [181.163.96.231]) by mx.google.com with ESMTPSA id p8sm6259650qha.20.2015.04.03.12.40.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 12:40:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: John Bradley Mime-Version: 1.0 (1.0) Date: Fri, 3 Apr 2015 16:16:20 -0300 Message-Id: References: <551DADCB.9040803@cs.tcd.ie> <551ED488.7000101@gmx.net> In-Reply-To: <551ED488.7000101@gmx.net> To: Hannes Tschofenig X-Mailer: iPhone Mail (12D508) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 19:40:24 -0000 Yes it is good, though reading that BCP may scare off implementers who will j= ust ignore it.=20 We may still want to give the current advice of >=3D tls 1.2 at the point of= publication see BCP xx for additional considerations.=20 John B.=20 Sent from my iPhone > On Apr 3, 2015, at 2:57 PM, Hannes Tschofenig w= rote: >=20 > I learned something new: we can reference a BCP (instead of an RFC) and > even if the RFC gets up-dated we will still have a stable reference. > (See Stephen's response to my question below). >=20 > This is what we should do for our documents when we reference TLS in the > future. We would reference the yet-to-become BCP (currently UTA-TLS > document) and we essentially point to the recommended usage for TLS > (version, ciphersuite, everything). >=20 > Isn't that great? >=20 > -------------------------------------------------------- >=20 >> On 02/04/15 19:09, Hannes Tschofenig wrote: >> Hi Stephen, >>=20 >> if I understand it correctly, you are saying if we reference a BCP # >> (instead of the RFC) then a revised RFC will get the same BCP #. I have >> never heard about that and if that's indeed true that would be cool. I >> might also have misunderstood your idea though. >=20 > Yep, that's it. XML2RFC makes it hard but you can do it, worst > case via an RFC editor note >=20 > S. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Apr 3 12:50:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3381A01AE for ; Fri, 3 Apr 2015 12:50:18 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3Yt0mKy4JFA for ; Fri, 3 Apr 2015 12:50:16 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::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 7DBAF1A017D for ; Fri, 3 Apr 2015 12:50:16 -0700 (PDT) Received: by qcay5 with SMTP id y5so94887160qca.1 for ; Fri, 03 Apr 2015 12:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XO3LOcq/U6hk5RrZjZyEaSz4cI9HL6/xEDXM6UQW6G4=; b=a2fUCq2AFC/9K1AyfEsUSCAE6WI9SlmDHUuCHHG++gWhNlQqA85dnWnlK4unQU+DG/ QTrVKEPYsKwyh6/RE+H/6umykk0WWiVoTVa1zSw7ip2VfVOI3Kczl7O3tWgarUoLOnp6 Y2dgrvCPkXlXp1hHA1hBYJVkb9iLVYICLuVGvxsLqrPYZzINMgmoygQsZ86P0GA4vK1E B0ZNoE65KgfGxf82j7792sqNFB2Z2DDRkPW4l6QGFjrdmgMrOLNBkf8XeRg6Qa2xKzJP MjgljkcNwWhpCTjXpx2FVAt2yme43LMBn9otFSNtgEbUnwwehmxtBlnnpkX3pBs1oQyH YbXg== X-Received: by 10.55.55.137 with SMTP id e131mr7400537qka.14.1428090615810; Fri, 03 Apr 2015 12:50:15 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 2sm6308150qgg.31.2015.04.03.12.50.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 12:50:14 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 3 Apr 2015 15:50:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <019F554F-93E3-4931-B9CD-9DA55FAA8341@gmail.com> References: <551DADCB.9040803@cs.tcd.ie> <551ED488.7000101@gmx.net> To: John Bradley Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 19:50:18 -0000 Sent from my iPhone > On Apr 3, 2015, at 3:16 PM, John Bradley wrote: >=20 > Yes it is good, though reading that BCP may scare off implementers who wil= l just ignore it.=20 >=20 > We may still want to give the current advice of >=3D tls 1.2 at the point o= f publication see BCP xx for additional considerations.=20 >=20 I think it's fine to do that. Using the recommended version as the base at t= ime of publication with a pointer to the BCP is appropriate. Thanks, Kathleen=20 > John B.=20 >=20 >=20 > Sent from my iPhone >=20 >> On Apr 3, 2015, at 2:57 PM, Hannes Tschofenig = wrote: >>=20 >> I learned something new: we can reference a BCP (instead of an RFC) and >> even if the RFC gets up-dated we will still have a stable reference. >> (See Stephen's response to my question below). >>=20 >> This is what we should do for our documents when we reference TLS in the >> future. We would reference the yet-to-become BCP (currently UTA-TLS >> document) and we essentially point to the recommended usage for TLS >> (version, ciphersuite, everything). >>=20 >> Isn't that great? >>=20 >> -------------------------------------------------------- >>=20 >>> On 02/04/15 19:09, Hannes Tschofenig wrote: >>> Hi Stephen, >>>=20 >>> if I understand it correctly, you are saying if we reference a BCP # >>> (instead of the RFC) then a revised RFC will get the same BCP #. I have >>> never heard about that and if that's indeed true that would be cool. I >>> might also have misunderstood your idea though. >>=20 >> Yep, that's it. XML2RFC makes it hard but you can do it, worst >> case via an RFC editor note >>=20 >> S. >>=20 >>=20 >>=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 Fri Apr 3 13:08:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142381A000D for ; Fri, 3 Apr 2015 13:08:20 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iES4P1q5AYAp for ; Fri, 3 Apr 2015 13:08:18 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 DF23F1A0004 for ; Fri, 3 Apr 2015 13:08:17 -0700 (PDT) Received: by lagv1 with SMTP id v1so9501572lag.3 for ; Fri, 03 Apr 2015 13:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ffX7pUybbizWpjsfsLc2IWNpB685Ol8OOnAw+xkv2LM=; b=YT5/rhu7lZDG7z9+kmPoXh0bwMoHswTbuXiUmkX+tz69FyQCh2/pnvCnFEV3KXbKR3 Dzj4gam5w3KyBEqhY65g9CS0rfA/5L3xxQ6gO9xS+zN7par4RdqI6WWV0eLIVfBYnHj6 +SzFVFxTOGUc+erBuoykCGQqFo1jGM3zI26aPHR6bPN/IFrpJWGEOBWhahom8CYAp44I l/rFAZafLwzo2mxErjY/XLQ6hxMF4L9kSuf4vfrgEbXenCO5A1jqgJTjKqzXSv0DkBxp Povj8hEOrMeVv24hdjgMI0Siw2dXBObnPZTa6W0oLsHPEtHnn7lIlaWys0t+ujVxLC+1 3+Sg== X-Gm-Message-State: ALoCoQk+SLx8CJCJ7X67StaRSE7TtXLzCSn0mQg4BK1FOm6ksXA1pScuwlyonYASv7VhViit1Ne8 X-Received: by 10.112.198.40 with SMTP id iz8mr3486830lbc.101.1428091696265; Fri, 03 Apr 2015 13:08:16 -0700 (PDT) Received: from [192.168.1.85] (h165n2-ld-h-td2.ias.bredband.telia.com. [81.230.12.165]) by mx.google.com with ESMTPSA id xq2sm1763828lbb.49.2015.04.03.13.08.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 13:08:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Fri, 3 Apr 2015 22:08:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51BF88CA-290A-4F57-82E9-C2A536EDCA8C@mnt.se> References: <551DADCB.9040803@cs.tcd.ie> <551ED488.7000101@gmx.net> To: John Bradley Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:08:20 -0000 > 3 apr 2015 kl. 21:16 skrev John Bradley : >=20 > Yes it is good, though reading that BCP may scare off implementers who wil= l just ignore it.=20 Those people are gona ignore a bunch of other good advise too. Lets not chas= e the rabbit down every hole. >=20 > We may still want to give the current advice of >=3D tls 1.2 at the point o= f publication see BCP xx for additional considerations.=20 >=20 > John B.=20 >=20 >=20 > Sent from my iPhone >=20 >> On Apr 3, 2015, at 2:57 PM, Hannes Tschofenig = wrote: >>=20 >> I learned something new: we can reference a BCP (instead of an RFC) and >> even if the RFC gets up-dated we will still have a stable reference. >> (See Stephen's response to my question below). >>=20 >> This is what we should do for our documents when we reference TLS in the >> future. We would reference the yet-to-become BCP (currently UTA-TLS >> document) and we essentially point to the recommended usage for TLS >> (version, ciphersuite, everything). >>=20 >> Isn't that great? >>=20 >> -------------------------------------------------------- >>=20 >>> On 02/04/15 19:09, Hannes Tschofenig wrote: >>> Hi Stephen, >>>=20 >>> if I understand it correctly, you are saying if we reference a BCP # >>> (instead of the RFC) then a revised RFC will get the same BCP #. I have >>> never heard about that and if that's indeed true that would be cool. I >>> might also have misunderstood your idea though. >>=20 >> Yep, that's it. XML2RFC makes it hard but you can do it, worst >> case via an RFC editor note >>=20 >> S. >>=20 >>=20 >>=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 Fri Apr 3 13:20:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DA31A039C for ; Fri, 3 Apr 2015 13:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQjsNKjhZq48 for ; Fri, 3 Apr 2015 13:20:38 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4BF1A006F for ; Fri, 3 Apr 2015 13:20:37 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-0f-551ef6144cfc Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 27.6B.03451.416FE155; Fri, 3 Apr 2015 16:20:36 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t33KKaWN026218; Fri, 3 Apr 2015 16:20:36 -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 t33KKYZI014711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Apr 2015 16:20:35 -0400 From: Justin Richer X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_8E691AF7-FECE-4ED9-B20B-3150B64B1CC9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Fri, 3 Apr 2015 16:20:33 -0400 Message-Id: To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsUixCmqrSvyTS7UYP07a4uGnfkWJ9++YnNg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mk6tPsFWsEarYn/3F/YGxpsqXYwcHBICJhIf LrF2MXICmWISF+6tZ+ti5OIQEljMJNG77i+Us4FR4vTKI8wQzgMmie8rv4G1sAmoSsxfeYsJ ol1Koun1MUaQImaBKYwSX57tZQdJCAvoSLy5fZERxGYRUJE41DUPLM4rYCVxatInMJtZwEJi 2/L3bCC2iIC6xJrzP5kgagwk5p76wgRxqrxEz6b0CYz8s5CtmIWkbBZQGbNAksTrTRWzwKZq Syxb+JoZwtaU2N+9nAVTXEOi89tEVghbXmL72zlQcUuJxTNvQNXbStzqW8AEYdtJPJq2iHUB I/cqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoHhid1HawfjzoNIhRgEORiUe 3geBcqFCrIllxZW5hxglOZiURHk17wCF+JLyUyozEosz4otKc1KLDzGqAO16tGH1BUYplrz8 vFQlEd7Hj4HqeFMSK6tSi/JhyqQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8JZ/AWoU LEpNT61Iy8wpQUgzcXAeYpTg4AEaPh2khre4IDG3ODMdIn+KUVFKnDcdJCEAksgozYPrhaXB V4ziQG8J8waDVPEAUyhc9yugwUxAgx3mSYMMLklESEk1MC7iWy+7I8tKbAHL4Wmfyq3fNzWn P5r/YHd/1LQl/hduzMuYu9dVlNfbJPLvyaXFdmveesfN0Z3NdOOqYszubwLcVsYTimNXX92Y fGaXWGpX//6f9qsYTgnkPAmsVe410ny+oXD66k27LddFnZqZ90T/UOyHk2/3rCh/UL/TI0Xv CoeTwo0rwvJKLMUZiYZazEXFiQCTPmajXgMAAA== Archived-At: Subject: [OAUTH-WG] Rate limiting in Dyn-Reg-Management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:20:41 -0000 --Apple-Mail=_8E691AF7-FECE-4ED9-B20B-3150B64B1CC9 Content-Type: multipart/alternative; boundary="Apple-Mail=_B9007566-6460-40C4-8539-808B7204B9DA" --Apple-Mail=_B9007566-6460-40C4-8539-808B7204B9DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the current draft of Dyn-Reg-Management = (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 = ) = there=E2=80=99s a clause that=E2=80=99s causing some consternation in = the general review: Since the client configuration endpoint is an OAuth 2.0 protected resource, it SHOULD have some rate limiting on failures to prevent the registration access token from being disclosed though repeated access attempts. A comment has been raised arguing that this text isn=E2=80=99t helpful = to implementors as it doesn=E2=80=99t tell them what kind of rate = limiting to do or how to accomplish it. It has also been pointed out = that there=E2=80=99s not an obvious need for this recommendation if = there=E2=80=99s enough entropy in the registration access token to begin = with. The suggestion has been made to drop the above text, and potentially to = add a reference to the sections on token complexity in 6750 =C2=A75.2 = and 6819 =C2=A75.1.4.2.2. My suggested text in that regard is: Since possession of the registration access token authorizes the holder = to potentially read, modify, or delete a client=E2=80=99s registration = (including its credentials such as a client_secret), the registration = access token MUST contain sufficient entropy such as described in = [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2. I would add this as the last sentence to the first paragraph in the = security considerations section. What does the WG think of this suggested change? =E2=80=94 Justin --Apple-Mail=_B9007566-6460-40C4-8539-808B7204B9DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In the current draft of Dyn-Reg-Management (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management= -12) there=E2=80=99s a clause that=E2=80=99s causing some = consternation in the general review:

   Since the =
client configuration endpoint is an OAuth 2.0 protected
   resource, it SHOULD have some rate limiting on failures to prevent
   the registration access token from being disclosed though repeated
   access attempts.

A comment has been raised arguing that this text isn=E2=80=99t = helpful to implementors as it doesn=E2=80=99t tell them what kind of = rate limiting to do or how to accomplish it. It has also been pointed = out that there=E2=80=99s not an obvious need for this recommendation if = there=E2=80=99s enough entropy in the registration access token to begin = with. 

The = suggestion has been made to drop the above text, and potentially to add = a reference to the sections on token complexity in 6750 =C2=A75.2 and = 6819 =C2=A75.1.4.2.2. My suggested text in that regard is:

Since possession of the registration access = token authorizes the holder to potentially read, modify, or delete a = client=E2=80=99s registration (including its credentials such as a = client_secret), the registration access token MUST contain sufficient = entropy such as described in [RFC6750] Section 5.2 and [RFC6819] Section = 5.1.4.2.2.

I would add this as the last sentence = to the first paragraph in the security considerations = section. 

What does the WG think of this suggested change?

 =E2=80=94 = Justin
= --Apple-Mail=_B9007566-6460-40C4-8539-808B7204B9DA-- --Apple-Mail=_8E691AF7-FECE-4ED9-B20B-3150B64B1CC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVHvYSAAoJEDPAngkbd+w9rPQIAIBmB1Xl39K4acmn3aAPzXdX 1iClV02AEEpW8iSxFXUjI/118MdZZ5xa215kXk8TuMy2LcnzdjMqlhnzRtOyad+o 5fWD/s6HLMf5A3uBlQgw+31/4BXzy8/xBkBjLpIKY2MajSrmn/A3HHlQPbCHNmgu e5rlBmghGJEhdkahsSFI9F/sv6K68WWX5748itqqvZBm4X6H5uE6t3ch/i7QuACd Ue91foFXwdmhy/ZvYIvMRpjVIeM/qOip0ebBrmvdzcTmfAswqt3Jbf2FW06JIgh4 TL3gmIVXux0Yeslc9Uzyib0dKla8S0H5hMJjLa9SZlnc6jgHApaCAQbY7LpaarI= =yRVa -----END PGP SIGNATURE----- --Apple-Mail=_8E691AF7-FECE-4ED9-B20B-3150B64B1CC9-- From nobody Fri Apr 3 13:35:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8551A0250 for ; Fri, 3 Apr 2015 13:35:20 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr6aptNPp25J for ; Fri, 3 Apr 2015 13:35:18 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (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 331B21A000B for ; Fri, 3 Apr 2015 13:35:18 -0700 (PDT) Received: by qcay5 with SMTP id y5so95514172qca.1 for ; Fri, 03 Apr 2015 13:35:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xSWO6S5Hk1qISMQaZ8J4NdodofDYlv7u1uxNSxde76k=; b=COIZqmmaxCGOrUAUGkncoNoZMr9Sdk+AIKdx96lSozX0hXsosArkrvdR+lpfalh8PX Dnh+cm42b/DBcSse6HKxe5qWQaExlY1nqhR9PUrnTNxmUQkA5uWEkIhSksBuq0/fUXGA sngjJzB9san0si/I1GRdKDsdnnCTh9++tji3biuGix8SEM9dqJxa39rp0abQ6N7rSbHK 9UR5dSHGmZ7VehnBScioaoLLD4UfnZDWXkeCrCLCYI9Pe3oLU/L3e3VKv8QuzMu9MbkL NXq/VfJJZ/QnZFc7KMG6J6roNaA2+ryiUH/xSKbPisLsFV5lZNukv+Y+ZoMEPVt6gTx9 Fk/Q== X-Gm-Message-State: ALoCoQnOuoHRNxQK8Rv5xPXOPA7heNHbMb96xu8bvRVvIIYz2Yr1sCTILhWA9L5YOxy3ANAtEcaI X-Received: by 10.140.132.199 with SMTP id 190mr4878580qhe.24.1428093317327; Fri, 03 Apr 2015 13:35:17 -0700 (PDT) Received: from [192.168.8.100] ([181.202.138.91]) by mx.google.com with ESMTPSA id 33sm5732879qkv.22.2015.04.03.13.35.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 13:35:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <51BF88CA-290A-4F57-82E9-C2A536EDCA8C@mnt.se> Date: Fri, 3 Apr 2015 17:35:11 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551DADCB.9040803@cs.tcd.ie> <551ED488.7000101@gmx.net> <51BF88CA-290A-4F57-82E9-C2A536EDCA8C@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:35:20 -0000 Thats true, most will never make it to the security considerations in = the first place. =20 For those that do getting the message out that TLS versions below 1.2 = are not OK and pointing them to the BCP for the other 18 pages of info = on the finer points of cypher suite selection and other really good = stuff is probably the way to go. I thought the draft BCP was quite good, but the key point about TLS = version is down in 3.1.1 and many people won't get that far if I know = developers. Pointing at the BCP is defiantly the correct thing to do. Hitting the = highpoint in the main spec doesn't hurt and might just remind some = people who see stuff about DTLS and Cypher Suites in the BCP and have = there brains turn off. John B. > On Apr 3, 2015, at 5:08 PM, Leif Johansson wrote: >=20 >=20 >=20 >=20 >> 3 apr 2015 kl. 21:16 skrev John Bradley : >>=20 >> Yes it is good, though reading that BCP may scare off implementers = who will just ignore it.=20 >=20 > Those people are gona ignore a bunch of other good advise too. Lets = not chase the rabbit down every hole. >=20 >>=20 >> We may still want to give the current advice of >=3D tls 1.2 at the = point of publication see BCP xx for additional considerations.=20 >>=20 >> John B.=20 >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Apr 3, 2015, at 2:57 PM, Hannes Tschofenig = wrote: >>>=20 >>> I learned something new: we can reference a BCP (instead of an RFC) = and >>> even if the RFC gets up-dated we will still have a stable reference. >>> (See Stephen's response to my question below). >>>=20 >>> This is what we should do for our documents when we reference TLS in = the >>> future. We would reference the yet-to-become BCP (currently UTA-TLS >>> document) and we essentially point to the recommended usage for TLS >>> (version, ciphersuite, everything). >>>=20 >>> Isn't that great? >>>=20 >>> -------------------------------------------------------- >>>=20 >>>> On 02/04/15 19:09, Hannes Tschofenig wrote: >>>> Hi Stephen, >>>>=20 >>>> if I understand it correctly, you are saying if we reference a BCP = # >>>> (instead of the RFC) then a revised RFC will get the same BCP #. I = have >>>> never heard about that and if that's indeed true that would be = cool. I >>>> might also have misunderstood your idea though. >>>=20 >>> Yep, that's it. XML2RFC makes it hard but you can do it, worst >>> case via an RFC editor note >>>=20 >>> S. >>>=20 >>>=20 >>>=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 Fri Apr 3 13:37:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689F91A0318 for ; Fri, 3 Apr 2015 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLCI0ebYe-BX for ; Fri, 3 Apr 2015 13:36:57 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9667F1A0302 for ; Fri, 3 Apr 2015 13:36:57 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-77-551ef9e84446 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.C5.03700.8E9FE155; Fri, 3 Apr 2015 16:36:56 -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 t33KatBW009570; Fri, 3 Apr 2015 16:36:55 -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 t33KarDj020549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Apr 2015 16:36:54 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A6F35690-F205-428A-AF2D-564526FFA2BB"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <51BF88CA-290A-4F57-82E9-C2A536EDCA8C@mnt.se> Date: Fri, 3 Apr 2015 16:36:52 -0400 Message-Id: <32C746E3-ED37-4A9F-8E25-B5579E212A5E@mit.edu> References: <551DADCB.9040803@cs.tcd.ie> <551ED488.7000101@gmx.net> <51BF88CA-290A-4F57-82E9-C2A536EDCA8C@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOKsWRmVeSWpSXmKPExsUixCmqrPvip1yowcupkhaNfTOYLU6+fcVm sfruXzYHZo8lS34yeWxanupx+/ZGlgDmKC6blNSczLLUIn27BK6M9tuvWQrOyFS8/afRwNgq 0cXIySEhYCLxe/UmFghbTOLCvfVsXYxcHEICi5kkzr24wAjhbGCUWLtiNhtIlZDAAyaJgw0p ILawgLrEscutYN28AgYSc099YQKxmQWmMEocWAk1VUqi6fUxRhCbTUBVYvqaFrAaTgEriR9b usHiLAIqErd+XWaH6PWU2PMMZDEH0Ewrid+/I6AOYpRomX0ZrFdEQFHi4Zez7CA1EgLyEj2b 0icwCs5CcsUsJFdA2NoSyxa+ZoawNSX2dy+HistLbH87BypuKbF45g2ouK3Erb4FUHPsJB5N W8S6gJFjFaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRlAcsbso72D8c1DpEKMA B6MSD++DQLlQIdbEsuLK3EOMkhxMSqK8mneAQnxJ+SmVGYnFGfFFpTmpxYcYVYB2Pdqw+gKj FEtefl6qkgjv48dAdbwpiZVVqUX5MGXSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHh3 /QBqFCxKTU+tSMvMKUFIM3FwHmKU4OABGj4VpIa3uCAxtzgzHSJ/ilFRSpz3AUhCACSRUZoH 1wtLf68YxYHeEuY9DVLFA0ydcN2vgAYzAQ12mCcNMrgkESEl1cAY5RnHr5Qp9mVrfL5e+tb1 SnNVdiqUV3YlbbbxWxtd0sDR9lfaW3WzdQ6HQcjdL7Zmf+4xXhLaV9j78Z2ThOi7uZ735tjc uCJdF2pw9m246kP3qbWP+WQcGVMb1wbs3HK44EnRr813c4QuKsV6p866ve9Sv+CMDfN/+8dv +P/LO/7yue0SyrFKLMUZiYZazEXFiQCAZ/2VWgMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:36:59 -0000 --Apple-Mail=_A6F35690-F205-428A-AF2D-564526FFA2BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the end, I still say that 99.999% of implementors and deployers will = look at that and say: =E2=80=9CAm I doing HTTPS? I am, so I=E2=80=99m = good!=E2=80=9D and leave it at that. :) I=E2=80=99m in favor of Kathleen=E2=80=99s approach where we give the = minimum version and the BCP pointer for people who really care, and at = least say =E2=80=9Cgo do the right thing=E2=80=9D to people who might = otherwise ignore it. =E2=80=94 Justin > On Apr 3, 2015, at 4:08 PM, Leif Johansson wrote: >=20 >=20 >=20 >=20 >> 3 apr 2015 kl. 21:16 skrev John Bradley : >>=20 >> Yes it is good, though reading that BCP may scare off implementers = who will just ignore it. >=20 > Those people are gona ignore a bunch of other good advise too. Lets = not chase the rabbit down every hole. >=20 >>=20 >> We may still want to give the current advice of >=3D tls 1.2 at the = point of publication see BCP xx for additional considerations. >>=20 >> John B. >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Apr 3, 2015, at 2:57 PM, Hannes Tschofenig = wrote: >>>=20 >>> I learned something new: we can reference a BCP (instead of an RFC) = and >>> even if the RFC gets up-dated we will still have a stable reference. >>> (See Stephen's response to my question below). >>>=20 >>> This is what we should do for our documents when we reference TLS in = the >>> future. We would reference the yet-to-become BCP (currently UTA-TLS >>> document) and we essentially point to the recommended usage for TLS >>> (version, ciphersuite, everything). >>>=20 >>> Isn't that great? >>>=20 >>> -------------------------------------------------------- >>>=20 >>>> On 02/04/15 19:09, Hannes Tschofenig wrote: >>>> Hi Stephen, >>>>=20 >>>> if I understand it correctly, you are saying if we reference a BCP = # >>>> (instead of the RFC) then a revised RFC will get the same BCP #. I = have >>>> never heard about that and if that's indeed true that would be = cool. I >>>> might also have misunderstood your idea though. >>>=20 >>> Yep, that's it. XML2RFC makes it hard but you can do it, worst >>> case via an RFC editor note >>>=20 >>> S. >>>=20 >>>=20 >>>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A6F35690-F205-428A-AF2D-564526FFA2BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVHvnkAAoJEDPAngkbd+w9/sUH/Rddxwpib81H2NyUrWmZjc9i AmB0+yiOXa+4U9w264QjzzpS+5pncQ5TGEY5oUeKFbqt32McZxWN6o5OIHIFqYQK OE05X28Em7VCTlE4pEVieZEX9qzwXW7P768lJQNSdscCUyynruLgwFFK4H4Ih5ds fPfoZdsO44ByfGHMFs/rLUDG926LrBVZbZpLnt2OxjB0vXjq3Bq+UDCI+Eaqb5y2 PvCtG7dpYr6D3Wkby//x034GCoc0txQp84t/1jXInboiFPzVM3VzBBImN/sIXUxW t4Pix+eIR+qU4s8uEdbxKbKFpvZHxIgzW0tGLBnwmISo4RxriSOksp3akH+Y0gg= =65VE -----END PGP SIGNATURE----- --Apple-Mail=_A6F35690-F205-428A-AF2D-564526FFA2BB-- From nobody Fri Apr 3 14:55:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F01E1A1AB9 for ; Fri, 3 Apr 2015 14:55:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5PjjA6475FQ for ; Fri, 3 Apr 2015 14:55:54 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 F00191A1AAD for ; Fri, 3 Apr 2015 14:55:53 -0700 (PDT) Received: by qgdy78 with SMTP id y78so38510374qgd.0 for ; Fri, 03 Apr 2015 14:55:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=mQCmpEGjNyi+8hNvzBwxbw3VuQMLtx5cWbhLBG5Fga4=; b=UdUN1xP3CZFkoNA0f7NKJiKOVfX52fh7DM4sST9JXEX/w/+mi8XKzWsD1kGJjUp60J 1GuRk7tZ+na6aBdyGdbK6kPHR05sgS9cSmFc5UQ37tvI2M3U8KmIR72LxThu8oFlRdoS lJ1SGbCAZUO8dhOTlN+k/rY//kMAS1AohR74opL21D9kmnaZWPHQO4H1sJsY1egj6fWa 8jUF6IsscRNdPlictGDRrrPLw07qktH2cApZSGEkSoau3Pr5lKasj6XMHd8dS8jz0fcf Tp1HI+43NX8jab+SjUwtYe0igdCQr1CJuNO/XdKANIViOXb9INVVV3Nv8GQLjyrB9act ILmQ== X-Gm-Message-State: ALoCoQmkvfdd2ZBg4y2r6qs7HvgTdtd7oyuBqpb97ENd6PsEQn/RIyXS+NmnHeEOiviV0jg1y2gr X-Received: by 10.140.150.149 with SMTP id 143mr5243075qhw.4.1428098152941; Fri, 03 Apr 2015 14:55:52 -0700 (PDT) Received: from [192.168.8.100] ([181.202.138.91]) by mx.google.com with ESMTPSA id 91sm6536671qgl.2.2015.04.03.14.55.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 14:55:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_40A8640B-6800-4A72-98A4-CAAD66527CA9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Fri, 3 Apr 2015 18:55:47 -0300 Message-Id: References: To: Justin Richer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Rate limiting in Dyn-Reg-Management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 21:55:56 -0000 --Apple-Mail=_40A8640B-6800-4A72-98A4-CAAD66527CA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am OK with that. Rate limiting only really helps with denial of = service attacks, and that is a separate issue. In 6750 we were very slippery in avoiding specifying any entropy minimum = or structure for the token, given the nature of that applying to any = endpoint. In 6819 we did better by specifying a minimum 128 bits for keys and = references. That would require crushing the internet to do online brute force in any = reasonable amount of time or roughly the computing power of Google to do = a offline attack against a single token in a year (rough guess). The one thing we don=E2=80=99t caution against is using the same = registration_client_uri for every client. =20 If someone is doing that (not unreasonable in some cases) and if they = have a large number of clients then they probably should use higher = entropy tokens eg 256 bit. If there are millions of registered clients at a AS hypothetically your = chances of getting lucky against one of them are better.=20 It is still very unlikely at 128 bits but the attack surface is larger = if there is only one resource and you attack all the clients at once. It may not be worth mentioning however, I know I am the paranoid one. John B. > On Apr 3, 2015, at 5:20 PM, Justin Richer wrote: >=20 > In the current draft of Dyn-Reg-Management = (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 = ) = there=E2=80=99s a clause that=E2=80=99s causing some consternation in = the general review: >=20 > Since the client configuration endpoint is an OAuth 2.0 protected > resource, it SHOULD have some rate limiting on failures to prevent > the registration access token from being disclosed though repeated > access attempts. >=20 > A comment has been raised arguing that this text isn=E2=80=99t helpful = to implementors as it doesn=E2=80=99t tell them what kind of rate = limiting to do or how to accomplish it. It has also been pointed out = that there=E2=80=99s not an obvious need for this recommendation if = there=E2=80=99s enough entropy in the registration access token to begin = with.=20 >=20 > The suggestion has been made to drop the above text, and potentially = to add a reference to the sections on token complexity in 6750 =C2=A75.2 = and 6819 =C2=A75.1.4.2.2. My suggested text in that regard is: >=20 > Since possession of the registration access token authorizes the = holder to potentially read, modify, or delete a client=E2=80=99s = registration (including its credentials such as a client_secret), the = registration access token MUST contain sufficient entropy such as = described in [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2. >=20 > I would add this as the last sentence to the first paragraph in the = security considerations section.=20 >=20 > What does the WG think of this suggested change? >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_40A8640B-6800-4A72-98A4-CAAD66527CA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I am OK with that.  Rate limiting only really helps with = denial of service attacks, and that is a separate issue.

In 6750 we were very = slippery in avoiding specifying any entropy minimum or structure for the = token, given the nature of that applying to any endpoint.

In 6819 we did better by = specifying a minimum 128 bits for keys and references.

That = would require crushing the internet to do online brute force in any = reasonable amount of time or roughly the computing power of Google to do = a offline attack against a single token in a year (rough = guess).

The = one thing we don=E2=80=99t caution against is using the same = registration_client_uri for every client.  
If = someone is doing that (not unreasonable in some cases) and if they have = a large number of clients then they probably should use higher entropy = tokens eg 256 bit.

If there are millions of registered clients at a AS = hypothetically your chances of getting lucky against one of them are = better. 

It= is still very unlikely at 128 bits but the attack surface is larger if = there is only one resource and you attack all the clients at = once.

It may = not be worth mentioning however, I know I am the paranoid one.


John B.



On Apr 3, 2015, at 5:20 PM, Justin Richer <jricher@MIT.EDU> = wrote:

In the current = draft of Dyn-Reg-Management (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management= -12) there=E2=80=99s a clause that=E2=80=99s causing some = consternation in the general review:

   Since the =
client configuration endpoint is an OAuth 2.0 protected
   resource, it SHOULD have some rate limiting on failures to prevent
   the registration access token from being disclosed though repeated
   access attempts.

A comment has been raised arguing that this text isn=E2=80=99t = helpful to implementors as it doesn=E2=80=99t tell them what kind of = rate limiting to do or how to accomplish it. It has also been pointed = out that there=E2=80=99s not an obvious need for this recommendation if = there=E2=80=99s enough entropy in the registration access token to begin = with. 

The = suggestion has been made to drop the above text, and potentially to add = a reference to the sections on token complexity in 6750 =C2=A75.2 and = 6819 =C2=A75.1.4.2.2. My suggested text in that regard is:

Since possession of the registration access = token authorizes the holder to potentially read, modify, or delete a = client=E2=80=99s registration (including its credentials such as a = client_secret), the registration access token MUST contain sufficient = entropy such as described in [RFC6750] Section 5.2 and [RFC6819] Section = 5.1.4.2.2.

I would add this as the last sentence = to the first paragraph in the security considerations = section. 

What does the WG think of this suggested change?

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

= --Apple-Mail=_40A8640B-6800-4A72-98A4-CAAD66527CA9-- From nobody Fri Apr 3 18:15:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26241A1A06 for ; Fri, 3 Apr 2015 18:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVPxEx21M-BN for ; Fri, 3 Apr 2015 18:15:42 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33F41A19FA for ; Fri, 3 Apr 2015 18:15:40 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-28-551f3b3bfa36 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 07.5C.03678.B3B3F155; Fri, 3 Apr 2015 21:15: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 t341FcAj003812; Fri, 3 Apr 2015 21:15:39 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t341FbFj030479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Apr 2015 21:15:38 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t341FaQP009659; Fri, 3 Apr 2015 21:15:36 -0400 (EDT) Date: Fri, 3 Apr 2015 21:15:36 -0400 (EDT) From: Benjamin Kaduk To: Justin Richer In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-610231429-1428110136=:22210" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nomttLR9qsOOQlsXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XPvPqaCTqGKWy9sGxg/8HUxcnJICJhIHPh5jRXCFpO4cG89 WxcjF4eQwGImia0vu5hAEkICGxglWpZKQCQOMkl8ubGGFSJRL7Fg3Xl2EJtFQEti55yHYA1s AioSM99sZAOxRQSUJa4vOcMIYjMLqEu07N3GAmILC1hL7NzyD8zmBLL3LvwDNpNXwFHi7cV2 Zoj5VhKdXa1gcVEBHYnV+6ewQNQISpyc+YQFYmaAxPnO86wTGAVnIUnNQpKaBbW68cFZNghb W+L+zTa2BYwsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MYJD2EV1B+OEQ0qH GAU4GJV4eB8EyoUKsSaWFVfmHmKU5GBSEuXdZCofKsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE d50FUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYJ3kiVQo2BRanpq RVpmTglCmomDE2Q4D9BwaSuQ4cUFibnFmekQ+VOMilLivAdAmgVAEhmleXC9sBTzilEc6BVh 3gCQdh5geoLrfgU0mAlosMM8aZDBJYkIKakGRoZty6WOO6nET+T29P0Tq36nMID5A5dnSVnX y9Jf8cqf+EKOG+9rn1TZZXq7T7RpecGS51PLtW2Wrrhw5mwFi5ntE8YDHdb3M57nvDo4Y7Gp 1KE/0u1bxcp1Nlp/26MoI7ta7zj7t0b7y0YrEr9eqLk4Z55Rz9HY81qztaMPyzycUqO6u9Sq S4mlOCPRUIu5qDgRAFKbtiIMAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Rate limiting in Dyn-Reg-Management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 01:15:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-610231429-1428110136=:22210 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 3 Apr 2015, Justin Richer wrote: > In the current draft of Dyn-Reg-Management (https://tools.ietf.org/html/d= raft-ietf-oauth-dyn-reg-management-12 ) there=E2=80=99s a clause that=E2=80=99s ca= using some consternation in the general review: > > Since the client configuration endpoint is an OAuth 2.0 protected > resource, it SHOULD have some rate limiting on failures to prevent > the registration access token from being disclosed though repeated > access attempts. > > A comment has been raised arguing that this text isn=E2=80=99t helpful to > implementors as it doesn=E2=80=99t tell them what kind of rate limiting t= o do or > how to accomplish it. It has also been pointed out that there=E2=80=99s n= ot an > obvious need for this recommendation if there=E2=80=99s enough entropy in= the > registration access token to begin with. > > The suggestion has been made to drop the above text, and potentially to > add a reference to the sections on token complexity in 6750 =C2=A75.2 and > 6819 =C2=A75.1.4.2.2. My suggested text in that regard is: > > Since possession of the registration access token authorizes the holder > to potentially read, modify, or delete a client=E2=80=99s registration > (including its credentials such as a client_secret), the registration > access token MUST contain sufficient entropy such as described in > [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2. > > I would add this as the last sentence to the first paragraph in the > security considerations section. > > What does the WG think of this suggested change? I think it's a fine change, in general. But I also saw the discussion on the other list, so maybe I'm biased. In specific, RFC 6750 does not include the word "entropy", and we might want to explicitly mention that "sufficient" means "sufficient to prevent a random guessing attack". -Ben ---559023410-610231429-1428110136=:22210-- From nobody Fri Apr 3 23:52:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF771AD0BB for ; Fri, 3 Apr 2015 23:52: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-jAXJ2-wgw3 for ; Fri, 3 Apr 2015 23:52:53 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 5A6161AD0BA for ; Fri, 3 Apr 2015 23:52:53 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so73426586lbb.0 for ; Fri, 03 Apr 2015 23:52:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=eMXMbw/+50nmMfFS7t85uCuFkW7GfLKZe0a/+bGhUXU=; b=G6AlxFQJ3Ja6CfquNhMGjad7LR6N0i/15D23NYMdkpCJYpx5HmdHOCh3gsIdDxYAAY rHTgHZq3bCJlW55A1NDbSXzAhdEC1+kvjMpJo9+9+Lr1bSBqd7N9ITxVWzZyrp/FLGFK 6rKc7MunI96OKG20C7ZHnOimeSnTmCc5NJxaC9cfzxEJg4wAkVsU/FFCb2Y3UCmVd18z JMg4Heiq8E6vLKSy0Su3jNGOtcSFkrBvRUlvP/KYk7aaipSeRzzBXFZ5IP4cYZPXOpVQ xplsxg7lhi262x8U8cz2roQtRLSxwyAeOM7o0KoeNvRAARYK6Fk5MAThmW9szDYLFmK4 5qZA== X-Gm-Message-State: ALoCoQnl4LgRVkJ4UjSwlKHes8aXmPLZjfy/61ACccF5bAYoF4/pJ4ULs/CNlhZBHbF2np7FZ9Bs X-Received: by 10.152.37.164 with SMTP id z4mr5006193laj.5.1428130371874; Fri, 03 Apr 2015 23:52:51 -0700 (PDT) Received: from [192.168.1.85] (h165n2-ld-h-td2.ias.bredband.telia.com. [81.230.12.165]) by mx.google.com with ESMTPSA id m1sm1684286lbg.36.2015.04.03.23.52.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 23:52:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Sat, 4 Apr 2015 08:52:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551DADCB.9040803@cs.tcd.ie> <551ED488.7000101@gmx.net> <51BF88CA-290A-4F57-82E9-C2A536EDCA8C@mnt.se> To: John Bradley Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Referencing TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 06:52:56 -0000 > 3 apr 2015 kl. 22:35 skrev John Bradley : >=20 > Thats true, most will never make it to the security considerations in the f= irst place. =20 >=20 yup > For those that do getting the message out that TLS versions below 1.2 are n= ot OK and pointing them to the BCP for the other 18 pages of info on the fin= er points of cypher suite selection and other really good stuff is probably t= he way to go. until 1.3 is out, yeah maybe >=20 > I thought the draft BCP was quite good, but the key point about TLS versio= n is down in 3.1.1 and many people won't get that far if I know developers. >=20 maybe we need a BCP for reading BCPs that sais 'read all of it' (but then th= ere is that boilerplate to get through ;-)) > Pointing at the BCP is defiantly the correct thing to do. Hitting the hig= hpoint in the main spec doesn't hurt and might just remind some people who s= ee stuff about DTLS and Cypher Suites in the BCP and have there brains turn o= ff. yeah maybe >=20 > John B. >=20 >> On Apr 3, 2015, at 5:08 PM, Leif Johansson wrote: >>=20 >>=20 >>=20 >>=20 >>> 3 apr 2015 kl. 21:16 skrev John Bradley : >>>=20 >>> Yes it is good, though reading that BCP may scare off implementers who w= ill just ignore it. >>=20 >> Those people are gona ignore a bunch of other good advise too. Lets not c= hase the rabbit down every hole. >>=20 >>>=20 >>> We may still want to give the current advice of >=3D tls 1.2 at the poin= t of publication see BCP xx for additional considerations.=20 >>>=20 >>> John B.=20 >>>=20 >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Apr 3, 2015, at 2:57 PM, Hannes Tschofenig wrote: >>>>=20 >>>> I learned something new: we can reference a BCP (instead of an RFC) and= >>>> even if the RFC gets up-dated we will still have a stable reference. >>>> (See Stephen's response to my question below). >>>>=20 >>>> This is what we should do for our documents when we reference TLS in th= e >>>> future. We would reference the yet-to-become BCP (currently UTA-TLS >>>> document) and we essentially point to the recommended usage for TLS >>>> (version, ciphersuite, everything). >>>>=20 >>>> Isn't that great? >>>>=20 >>>> -------------------------------------------------------- >>>>=20 >>>>> On 02/04/15 19:09, Hannes Tschofenig wrote: >>>>> Hi Stephen, >>>>>=20 >>>>> if I understand it correctly, you are saying if we reference a BCP # >>>>> (instead of the RFC) then a revised RFC will get the same BCP #. I hav= e >>>>> never heard about that and if that's indeed true that would be cool. I= >>>>> might also have misunderstood your idea though. >>>>=20 >>>> Yep, that's it. XML2RFC makes it hard but you can do it, worst >>>> case via an RFC editor note >>>>=20 >>>> S. >>>>=20 >>>>=20 >>>>=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 >=20 From nobody Sat Apr 4 04:14:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD931B2AE9 for ; Sat, 4 Apr 2015 04:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF1QN8_3JE0I for ; Sat, 4 Apr 2015 04:14:51 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD5F1A8752 for ; Sat, 4 Apr 2015 04:14:49 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-28-551fc7a8cde0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.38.03488.8A7CF155; Sat, 4 Apr 2015 07:14:48 -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 t34BEgVd001967; Sat, 4 Apr 2015 07:14:43 -0400 Received: from [192.168.128.56] (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 t34BEf6a019821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 4 Apr 2015 07:14:42 -0400 Message-ID: <551FC796.1060605@mit.edu> Date: Sat, 04 Apr 2015 07:14:30 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrLviuHyowaRGXYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+7v9YwFMwQqtqx9y9TAOIW3i5GTQ0LARGLlntUsELaYxIV7 69m6GLk4hAQWM0kcO9XGCuFsYJRYtv0QO4Rzi0li26pOsBZeATWJc6+bmEBsFgFViYPXjjKC 2GxA9vQ1LWBxUYEoiYlfD0HVC0qcnPkEzBYRUJJYfLaFDcRmFlCX6P29khXEFhawlti55R9Y jZBAgcTKt/eAFnNwcAo4Sez9GQJRbiYxb/NDZghbXqJ562zmCYyCs5BsmIWkbBaSsgWMzKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCg1WSdwfju4NKhxgFOBiVeHg3BMuH CrEmlhVX5h5ilORgUhLlvbkaKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd+VKoBxvSmJlVWpR PkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgRvyDGgRsGi1PTUirTMnBKENBMHJ8hw HqDhsiA1vMUFibnFmekQ+VOMilLivKUgCQGQREZpHlwvLJm8YhQHekWYdy1IFQ8wEcF1vwIa zAQ0eMNksMEliQgpqQbGJTe79bwfhihI/lW7a8HCy9DoV1k8YQLfry6XrN2Md1Y2HnlRzv7l wPV3oXMjOET+70439TbqkxdabPVw6uVjfqm3EutDXRujzyqWPWiLTfxVsfVR3dJHyalne9g+ HNx5TeJu6nKLnocF2qx3WNYvqWno/qmXI/Nwwoe7ITKLX9eceDFj+fx3SizFGYmGWsxFxYkA 4HXLfwEDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Rate limiting in Dyn-Reg-Management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 11:14:52 -0000 On 4/3/2015 9:15 PM, Benjamin Kaduk wrote: > On Fri, 3 Apr 2015, Justin Richer wrote: > >> In the current draft of Dyn-Reg-Management (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 ) there’s a clause that’s causing some consternation in the general review: >> >> Since the client configuration endpoint is an OAuth 2.0 protected >> resource, it SHOULD have some rate limiting on failures to prevent >> the registration access token from being disclosed though repeated >> access attempts. >> >> A comment has been raised arguing that this text isn’t helpful to >> implementors as it doesn’t tell them what kind of rate limiting to do or >> how to accomplish it. It has also been pointed out that there’s not an >> obvious need for this recommendation if there’s enough entropy in the >> registration access token to begin with. >> >> The suggestion has been made to drop the above text, and potentially to >> add a reference to the sections on token complexity in 6750 §5.2 and >> 6819 §5.1.4.2.2. My suggested text in that regard is: >> >> Since possession of the registration access token authorizes the holder >> to potentially read, modify, or delete a client’s registration >> (including its credentials such as a client_secret), the registration >> access token MUST contain sufficient entropy such as described in >> [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2. >> >> I would add this as the last sentence to the first paragraph in the >> security considerations section. >> >> What does the WG think of this suggested change? > I think it's a fine change, in general. But I also saw the discussion on > the other list, so maybe I'm biased. > > In specific, RFC 6750 does not include the word "entropy", and we might > want to explicitly mention that "sufficient" means "sufficient to prevent > a random guessing attack". > > -Ben I think that's a reasonable addition, thanks! -- Justin From nobody Mon Apr 6 13:06:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1D01A910E; Mon, 6 Apr 2015 13:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw4TMmSY0FJC; Mon, 6 Apr 2015 13:06:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E15EB1A9117; Mon, 6 Apr 2015 13:06:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406200616.30684.28620.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 13:06:16 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 20:06:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-13.txt Pages : 18 Date : 2015-04-06 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 6 13:12:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD6F1A911E for ; Mon, 6 Apr 2015 13:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyD9qN-QkT23 for ; Mon, 6 Apr 2015 13:12:38 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5734B1A90FD for ; Mon, 6 Apr 2015 13:12:38 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-01-5522e8b5d053 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 9A.EF.03700.5B8E2255; Mon, 6 Apr 2015 16:12:37 -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 t36KCaVw007596 for ; Mon, 6 Apr 2015 16:12:37 -0400 Received: from [10.66.204.91] ([64.236.138.4]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t36KCY5B030927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Apr 2015 16:12:36 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_D6FC85EA-ECB2-4768-95E6-49DEB4BF10A4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <20150406200616.30684.28620.idtracker@ietfa.amsl.com> Date: Mon, 6 Apr 2015 13:12:34 -0700 Message-Id: References: <20150406200616.30684.28620.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUixCmqrLv1hVKowa2NQhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqQpB5gLJktWbP97k6WB8bxIFyMnh4SAicSLxX2MELaYxIV7 69m6GLk4hAQWM0ksuN/GBOEcZZTYt6uHHaRKSGA/k0TzxQqQBLPAFEaJGycPM4MkeAUMJOae +sIEYgsL+ElsePoLaqyURNPrY2A2m4CqxPQ1LWA1nAJOEq+WPAQbyiKgIvFyzxxGiDlWEkvm b2OGWOYosfftdbC4iIC6xJrzP4F6OYBmykv0bEqfwCgwC9kZs5CcAWIzC2hLLFv4mhnC1pTY 372cBcKWl9j+dg5U3FJi8cwbUHFbiVt9C6B67SQeTVvEuoCRYxWjbEpulW5uYmZOcWqybnFy Yl5eapGumV5uZoleakrpJkZQPLC7KO9g/HNQ6RCjAAejEg/vhFuKoUKsiWXFlbmHGCU5mJRE eVufKYUK8SXlp1RmJBZnxBeV5qQWH2JUAdr1aMPqC4xSLHn5ealKIrx5d4DqeFMSK6tSi/Jh yqQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8Io/B2oULEpNT61Iy8wpQUgzcXAeYpTg 4AEafgCkhre4IDG3ODMdIn+KUVFKnDcIJCEAksgozYPrhaWxV4ziQG8J864GqeIBpkC47ldA g5mABvM/AxtckoiQkmpgnJx3rib+Kfu9z8ote10mRx77mM7ysmovW3K/7I686p6D7azhFvdr 3+zbXMyt/mTyqy9pa63dp57zt4gp2z0nL0tmuZ9RpVp8ic7Pqqu2ukKms/fseuo312H1ct5D fyJurqzaZxSddS//YNNWV9v4hw5/rdJ+CJa23q9MX8hzY3HNYoXZUU71SizFGYmGWsxFxYkA Ing6eD4DAAA= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 20:12:40 -0000 --Apple-Mail=_D6FC85EA-ECB2-4768-95E6-49DEB4BF10A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This version of the management spec includes the changed language to the = security considerations section discussed on the list after IETF92, = changing the recommendation for rate-limiting for one of minimum token = entropy to prevent token guessing attacks against the registration = access token. Please review the diffs and comment on the list here if anything needs = to be tweaked. =E2=80=94 Justin > On Apr 6, 2015, at 1:06 PM, = wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Dynamic Client Registration = Management Protocol > Authors : Justin Richer > Michael B. Jones > John Bradley > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-management-13.txt > Pages : 18 > Date : 2015-04-06 >=20 > Abstract: > This specification defines methods for management of dynamic OAuth > 2.0 client registrations for use cases in which the properties of a > registered client may need to be changed during the lifetime of the > client. Not all authorization servers supporting dynamic client > registration will support these management methods. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-13 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-management-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D6FC85EA-ECB2-4768-95E6-49DEB4BF10A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVIuiyAAoJEDPAngkbd+w9QbcH/0VllqR/qXLS0yy9Y6S/myJX 6LrccWrx/vuqJDJrFvW9dVBtrvRTWwUPPM25OA1gChoTf4yPrjyl8CE56DIXXBc8 jJQO1V9J15uQpADcoQh4emgMdg5Dofk2cVX7+kh4onncUMmmt+vSqGiqCso2XJfb +Q/39o70A1nBhn/CDrUD1Mc7i5rePEpU0zOjB1ZAluqWs3JLPQygd1ZUoXmn5RoD WW+xCH/ljEFW8aWjGGuVSzDnWpsriHu0xgFTJXxg7/HbRjDNkdBBF/aDQFgi4T2x I8cYQ1bJ2legk4fM+9eqBBJ6bIiwaj4b3WgnbDWISdJ9Jd9M6SIhKkg330BRPDw= =AP2F -----END PGP SIGNATURE----- --Apple-Mail=_D6FC85EA-ECB2-4768-95E6-49DEB4BF10A4-- From nobody Tue Apr 7 03:58:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ABB1B341D for ; Tue, 7 Apr 2015 03:58:13 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCrmnMA-AHG0 for ; Tue, 7 Apr 2015 03:58:02 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A731B3423 for ; Tue, 7 Apr 2015 03:58:02 -0700 (PDT) Received: by wiax7 with SMTP id x7so7977639wia.0 for ; Tue, 07 Apr 2015 03:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=NPrcaLG7/ZGgQbrxQKOiKaAt6/6Sy57FQ8lFgKAlXys=; b=CcuQy8jyTe1lEwn73qZQqHKjXtesfWmdWYIZNkYFHpOiA0P3tEv0SypEuYQ3YlWFoD aG/eVtghp5ZrhlZ+5TGjmEicf9fr3KjO8qxozj7mu6Y4bBOFyVd2Q3HYAcP0VaTlAUZA 3bKNH2MH0WXhuFtwGpoK0wND31bmLJUvOyrYvFn2ZZgLxaqZ9fRLLYD0SX4jU5y2CL/j PDt8Gbv03AicbTfF/02veX3PqaPWjUBc9UeQyGgdR4CYGJGCdMiDE0K4jpjjdRHvM4CI fWvRJ30qQ4f9cNFXXM2YLogVlCTufl5wbWAyz0kMqEWpjLxrC359qBZIQNJwtUU9luFU oM2w== X-Received: by 10.180.95.102 with SMTP id dj6mr3523563wib.45.1428404281430; Tue, 07 Apr 2015 03:58:01 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id z13sm10402301wjr.44.2015.04.07.03.58.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 03:58:00 -0700 (PDT) Message-ID: <5523B838.80105@gmail.com> Date: Tue, 07 Apr 2015 11:58:00 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <5523B7BA.4@gmail.com> In-Reply-To: <5523B7BA.4@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] The best method to get generated bearer tokens encoded X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 10:58:13 -0000 Hi Would it be correct to assume that the best method for encoding the auto-generated bearer tokens is Base64URL ? I've spotted recently some of our code uses the Hex encoding which I believe is inferior compared to Base64URL given that the latter has a richer set of characters. Is it a correct assumption ? Thanks, Sergey From nobody Tue Apr 7 06:09:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2B11B3560 for ; Tue, 7 Apr 2015 06:09:22 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0RIUkW4c_mj for ; Tue, 7 Apr 2015 06:09:20 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (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 D48761B355D for ; Tue, 7 Apr 2015 06:09:20 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so78403438pab.3 for ; Tue, 07 Apr 2015 06:09:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QuFj9V358txkMVIZ9tYOdV4FqzuVTx6RZmaH7Qgo1FI=; b=b9nzePT7nEbUfGB18WcE+M7OaDAZ5M7w0VoZSnmWxNLprjvUNiRSgVGuU2Alf6YCYX SlTbLSZpc8VMXEbCiWSzeK4qAdXCFfSr7fcjEAFZoIcRhgedJ5bdkSnlPxSKv8QvQ9Qe GPuFv90KIw1c11rzw28LdjZDLEWjTuApScyav2L4iTw5gDYE+jitclRBULyPBUnz30si 9zVRlY6oPbbrMndpH0Oz9RmFwtoIBGtmG20a8ACIgIqInSd4pkaImNam8sJxVHnng3rg 4e/lhHy8NN0dRl1NaLbCOfIlXkYJE1X97yZrRfxEHMZC9U9pO41Pf5LHxy9p6T6f2yLV XisA== X-Gm-Message-State: ALoCoQnVwms8gbyHOOldoHvkghTkL8/JO8BG0lPNcIPBR73xvHflZ8fDJAFoINvCClvi1sD1v0hb X-Received: by 10.68.254.74 with SMTP id ag10mr36594657pbd.35.1428412160436; Tue, 07 Apr 2015 06:09:20 -0700 (PDT) Received: from [50.94.78.139] ([12.207.17.3]) by mx.google.com with ESMTPSA id y13sm8179166pas.37.2015.04.07.06.09.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Apr 2015 06:09:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <5523B838.80105@gmail.com> Date: Tue, 7 Apr 2015 06:09:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8198C2B1-8B6D-4DD8-8052-85D335AABB8E@ve7jtb.com> References: <5523B7BA.4@gmail.com> <5523B838.80105@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] The best method to get generated bearer tokens encoded X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:09:23 -0000 Best would depend on what you are encoding. If the thing you are = encoding is mostly URL safe then using URL escaping might give you the = smallest result.=20 If it is 8bit data then BASE64URL will give you a smaller result than = HEX encoding. JWT use BASE64URL as a datapoint. John B. > On Apr 7, 2015, at 3:58 AM, Sergey Beryozkin = wrote: >=20 > Hi >=20 > Would it be correct to assume that the best method for encoding the = auto-generated bearer tokens is Base64URL ? I've spotted recently some = of our code uses the Hex encoding which I believe is inferior compared = to Base64URL given that the latter has a richer set of characters. >=20 > Is it a correct assumption ? >=20 > Thanks, Sergey >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Apr 7 06:19:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9035F1B3580 for ; Tue, 7 Apr 2015 06:19:50 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO543Qy8aRhp for ; Tue, 7 Apr 2015 06:19:49 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 BDEC21B357B for ; Tue, 7 Apr 2015 06:19:48 -0700 (PDT) Received: by wgyo15 with SMTP id o15so44894100wgy.2 for ; Tue, 07 Apr 2015 06:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UYicq38JC5oeEoDjXpIHb731eorDDnvThhmPs5I8CYM=; b=O+1pHNjvlttt9uyEUoKDF7zuEfgWPJMmkzAWsJF8D2YGtGU6o0KjGIu86fkzR+Lpun NWfoudhMisy71s54oc+KuwS10JUz3kSRTcXQ+dVSVsMLfj9XZsedbXjO9zACbelGw1lg BZC1QytS1eulc0WpktM+Z0NvOPgMbIfJ1fz5PUJLXN+RUq8r09DAV3qyr8HkM9nZNoob 0KphCcTOBzJs32GCYOotzWlrhw4/FBRQqPpFHTHRxyGEGLbYIexSfDeTj7Zx37ogqQJW m+U90HnyVLDUewxGDj7cJtq7m1JDR+9pQo5LKlN1z9fPB23sYDq/+Vcow1qteBe7Ytf0 1AHw== X-Received: by 10.181.25.225 with SMTP id it1mr4626303wid.8.1428412787567; Tue, 07 Apr 2015 06:19:47 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id w3sm11024368wiz.5.2015.04.07.06.19.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 06:19:46 -0700 (PDT) Message-ID: <5523D971.8040304@gmail.com> Date: Tue, 07 Apr 2015 14:19:45 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Bradley References: <5523B7BA.4@gmail.com> <5523B838.80105@gmail.com> <8198C2B1-8B6D-4DD8-8052-85D335AABB8E@ve7jtb.com> In-Reply-To: <8198C2B1-8B6D-4DD8-8052-85D335AABB8E@ve7jtb.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] The best method to get generated bearer tokens encoded X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:19:50 -0000 Hi John Thanks for the comments, what I'm curious about is not how to get a generated (bearer) access token encoded with the encoded value having a fewer number of characters but how to better support a security requirement that it should be difficult for an attacker to reproduce a given access token value... So I've been wondering if the fact that Base64(URL) has a richer set of characters than HEX makes it a better alternative...Not 100% sure how important it can be... Thanks, Sergey On 07/04/15 14:09, John Bradley wrote: > Best would depend on what you are encoding. If the thing you are encoding is mostly URL safe then using URL escaping might give you the smallest result. > If it is 8bit data then BASE64URL will give you a smaller result than HEX encoding. > > JWT use BASE64URL as a datapoint. > > John B. >> On Apr 7, 2015, at 3:58 AM, Sergey Beryozkin wrote: >> >> Hi >> >> Would it be correct to assume that the best method for encoding the auto-generated bearer tokens is Base64URL ? I've spotted recently some of our code uses the Hex encoding which I believe is inferior compared to Base64URL given that the latter has a richer set of characters. >> >> Is it a correct assumption ? >> >> Thanks, Sergey >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Apr 7 06:36:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923A61A8860 for ; Tue, 7 Apr 2015 06:36:23 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gow1S3C5S1Kk for ; Tue, 7 Apr 2015 06:36:22 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (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 C7A8D1B3579 for ; Tue, 7 Apr 2015 06:36:19 -0700 (PDT) Received: by pdea3 with SMTP id a3so79306477pde.3 for ; Tue, 07 Apr 2015 06:36:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9Oqq4LHBRX44v8D9wgS5GizGONMeyuw1ADL/MmRE0Bg=; b=mOKnSJ/2C+2V1UD++++xJ1dd8z3PifeIKj8GTjDioqCRj/YptGhLqbYUSMqfwOrurS jNdIeSmxXXMityG06MdH5YXib3ZdSHFxudJU/q51JAEQCm2TEE+DwTTSAFtrWt+UJaX0 O5MZp9FfuFOb4b3E7YaBFIqWbBmJUnKa+1BuTLLQYcJCGnvq1uH153NPfYCoX7YBVORC tOkOMNmay6wxNEyMMwsFxKVgpJOm6EmHLPbr2hgr2HQ1aGjqoWeSPOySYlTowzC4J5z7 4v2BMFvayGEj807REySmrWG2vkrM5vTEDLcmkYkSZljZekhxSQ/sobJvrEMyaoQZqtmo beiA== X-Gm-Message-State: ALoCoQkQ+VXY1ho5VyKQvwio1qa97IZNg/fcXxOjil0LWZhoBGdJuWHV/KEqveRPzwxt/v7OjkyG X-Received: by 10.66.65.228 with SMTP id a4mr4539868pat.47.1428413779389; Tue, 07 Apr 2015 06:36:19 -0700 (PDT) Received: from [50.94.78.139] ([12.207.17.3]) by mx.google.com with ESMTPSA id ei17sm8250038pac.20.2015.04.07.06.36.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Apr 2015 06:36:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: <5523D971.8040304@gmail.com> Date: Tue, 7 Apr 2015 06:36:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <35A566E6-9ED1-4212-B069-2699DD6FF210@ve7jtb.com> References: <5523B7BA.4@gmail.com> <5523B838.80105@gmail.com> <8198C2B1-8B6D-4DD8-8052-85D335AABB8E@ve7jtb.com> <5523D971.8040304@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] The best method to get generated bearer tokens encoded X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:36:23 -0000 How difficult it is to brute force the token has to do with the = underlying entropy. For opaque access tokens the specs recommend = 128bits of entropy. How you encode that is not relevant to the = security. > On Apr 7, 2015, at 6:19 AM, Sergey Beryozkin = wrote: >=20 > Hi John >=20 > Thanks for the comments, what I'm curious about is not how to get a = generated (bearer) access token encoded with the encoded value having a = fewer number of characters but how to better support a security = requirement that it should be difficult for an attacker to reproduce a = given access token value... >=20 > So I've been wondering if the fact that Base64(URL) has a richer set = of characters than HEX makes it a better alternative...Not 100% sure how = important it can be... >=20 > Thanks, Sergey >=20 > On 07/04/15 14:09, John Bradley wrote: >> Best would depend on what you are encoding. If the thing you are = encoding is mostly URL safe then using URL escaping might give you the = smallest result. >> If it is 8bit data then BASE64URL will give you a smaller result than = HEX encoding. >>=20 >> JWT use BASE64URL as a datapoint. >>=20 >> John B. >>> On Apr 7, 2015, at 3:58 AM, Sergey Beryozkin = wrote: >>>=20 >>> Hi >>>=20 >>> Would it be correct to assume that the best method for encoding the = auto-generated bearer tokens is Base64URL ? I've spotted recently some = of our code uses the Hex encoding which I believe is inferior compared = to Base64URL given that the latter has a richer set of characters. >>>=20 >>> Is it a correct assumption ? >>>=20 >>> Thanks, Sergey >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From nobody Tue Apr 7 15:09:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC01AC3FC; Tue, 7 Apr 2015 15:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47j3QPzhS8mH; Tue, 7 Apr 2015 15:09:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDEB1AC3FB; Tue, 7 Apr 2015 15:09:24 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.136.17; Tue, 7 Apr 2015 22:09:03 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0136.014; Tue, 7 Apr 2015 22:09:03 +0000 From: Mike Jones To: Ben Campbell , Phil Hunt Thread-Topic: Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) Thread-Index: AQHQcLNvziIlymLSiU21Cpn+02CTDJ1B2QkAgAAB4QCAAECyoA== Date: Tue, 7 Apr 2015 22:09:03 +0000 Message-ID: References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> In-Reply-To: <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nostrum.com; dkim=none (message not signed) header.d=none; x-originating-ip: [64.71.18.60] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51914003)(24454002)(13464003)(51444003)(51704005)(377454003)(106116001)(77096005)(54356999)(99286002)(62966003)(76576001)(102836002)(40100003)(50986999)(77156002)(33656002)(86362001)(122556002)(2521001)(92566002)(2900100001)(230783001)(2950100001)(46102003)(19580405001)(19580395003)(76176999)(66066001)(87936001)(74316001)(2656002)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0539EEBD11 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2015 22:09:03.3296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , "oauth@ietf.org" , The IESG , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 22:09:26 -0000 SSB0aGluayB0aGF0IHRoZSBjdXJyZW50IFNIT1VMRCBpcyBtb3JlIHJlYWxpc3RpYy4gIEluIHRo ZSByZWFsIHdvcmxkLCBwYXJ0aWN1bGFybHkgd2hpbGUgZGV2ZWxvcGluZyBhbmQgdGVzdGluZywg cGVvcGxlIHdpbGwgaGF2ZSBtYW55IGl0ZXJhdGlvbnMgb2YgcHJlLXJlbGVhc2Ugc29mdHdhcmUg Zm9yIGEgZ2l2ZW4gdmVyc2lvbiwgYWxsIG9mIHdoaWNoIHdpbGwgbGlrZWx5IGJlIGlkZW50aWZp ZWQgd2l0aCB0aGUgaW50ZW5kZWQgdmVyc2lvbiBudW1iZXIgYmVmb3JlIHRoZSBmaW5hbCByZWxl YXNlIG9mIHRoYXQgdmVyc2lvbiBvZiB0aGUgc29mdHdhcmUgaXMgbWFkZS4NCg0KCQkJCS0tIE1p a2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCBbbWFp bHRvOmJlbkBub3N0cnVtLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwNywgMjAxNSAxMTox MSBBTQ0KVG86IFBoaWwgSHVudA0KQ2M6IFRoZSBJRVNHOyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZ0BpZXRmLm9yZzsgSnVzdGluIFJpY2hlcg0KU3ViamVj dDogUmU6IEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9hdXRoLWR5 bi1yZWctMjc6ICh3aXRoIENPTU1FTlQpDQoNCk9uIDcgQXByIDIwMTUsIGF0IDEzOjAzLCBQaGls IEh1bnQgd3JvdGU6DQoNCj4gU2VjdGlvbiAyOg0KPj4NCj4+IFRoZSBzb2Z0d2FyZV92ZXJzaW9u ICJTSE9VTEQgY2hhbmdlIG9uIGFueSB1cGRhdGUgaWRlbnRpZmllZCB3aXRoIHRoZSANCj4+IHNh bWUgc29mdHdhcmVfaWQiIC0td2h5IG5vdCBNVVNUPyBXaGF0IGhhcHBlbnMgaWYgdGhpcyBkb2Vz bid0IA0KPj4gaGFwcGVuPw0KPg0KPg0KPiBUaGUgZ3JvdXAgZGlkbuKAmXQgbmVjZXNzYXJpbHkg YWdyZWUgdG8gbWFrZSBzb2Z0d2FyZV92ZXJzaW9uIG1hbmRhdG9yeSANCj4gdG8gcHJvdmlkZS4g VGh1cyB0aGUgd29yZCwgU0hPVUxEIHNlZW1lZCBhcHByb3ByaWF0ZSB0byBpbmRpY2F0ZSB0aGF0 IA0KPiBpZiB1c2VkIGl0IFNIT1VMRCBjaGFuZ2UgZnJvbSB2ZXJzaW9uIHRvIHZlcnNpb24uIFRo YXQgc2FpZCwgSSBhbSBvayANCj4gd2l0aCBNVVNUIChlLmcuIGlmIHNvZnR3YXJlX3ZlcnNpb24g aXMgdXNlZCwgaXQgTVVTVCBjaGFuZ2UuLi4pLg0KPg0KPiBJbiBhbnN3ZXIgdG8geW91ciBxdWVz dGlvbiB3aGF0IGhhcHBlbnM6IHRoaXMgaXMgbm90IHNvIG11Y2ggYSANCj4gc2VjdXJpdHkgaXNz dWUgKGluIHRoZSB0cmFkaXRpb25hbCBzZW5zZSBvZiBhbiBhdHRhY2tlciksIGJ1dCByYXRoZXIg YSANCj4gcmVndWxhciBzb2Z0d2FyZSB2ZXJzaW9uaW5nL21haW50ZW5hbmNlIGlzc3VlLiBUaGUg aWRlYSBpcyB0aGF0IHNvbWUgDQo+IGNsaWVudCBzb2Z0d2FyZSB1cGRhdGVzIG1heSBwcm92ZSB0 byBiZSBidWdneSAob3IgaGF2ZSBwZXJmb3JtYW5jZQ0KPiBpc3N1ZXMpIGFuZCBzZXJ2aWNlIHBy b3ZpZGVycyBtYXkgd2FudCB0byBiZSBhYmxlIHRvIHJlZnVzZSBzb21lIA0KPiB2ZXJzaW9ucyBv ZiBjbGllbnQgc29mdHdhcmUgd2hpbGUgYWNjZXB0aW5nIG90aGVycyAoZS5nLiAyLjUgaXMgYnJv a2VuIA0KPiBhbmQgY2F1c2VzIERvUyBpc3N1ZXMsIHdoaWxlIDIuNS4xIGlzIGFjY2VwdGFibGUp LiAgSWYgYSB2ZXJzaW9uIGlzIA0KPiBub3QgcHJvdmlkZWQsIHRoYW4gYW4gQVPigJlzIG9ubHkg Y2hvaWNlIGlzIHRvIGJhbiBhbGwgdmVyc2lvbnMgYW5kIA0KPiBmb3JjZSB0aGUgY2xpZW50IGRl dmVsb3BlciB0byB1c2Ugb3Igb2J0YWluIGEgZGlmZmVyZW50IHNvZnR3YXJlX2lkIA0KPiBmb3Ig ZnV0dXJlIHJlZ2lzdHJhdGlvbnMuDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLiBJIGNhbiBs aXZlIHdpdGggZWl0aGVyIGEgU0hPVUxEIG9yIGEgTVVTVCwgYnV0IGlmIHRoZSBTSE9VTEQgc3Rh eXMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gYWRkIGEgc2VudGVuY2Ugb3IgdHdvIHRvIHRoZSBlZmZl Y3Qgb2YgdGhlIGFib3ZlIHBhcmFncmFwaC4gVGhhdCBiZWluZyBzYWlkLCAiSWYgdXNlZCwgaXQg TVVTVCBjaGFuZ2UiIHNlZW1zIHRvIGJlIG1vcmUgcHJlY2lzZSBpZiB0aGF0IGZpdHMgdGhlIFdH IGludGVudC4NCg== From nobody Tue Apr 7 17:51:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ABB1B2A56; Tue, 7 Apr 2015 17:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIhS7_bSXPmX; Tue, 7 Apr 2015 17:51:36 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2F71B2A54; Tue, 7 Apr 2015 17:51:34 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-7a-55247b952781 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 dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.BD.03355.59B74255; Tue, 7 Apr 2015 20:51:33 -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 t380pVFJ030449; Tue, 7 Apr 2015 20:51:32 -0400 Received: from [10.255.233.129] (sjspeed.wiline.com [64.71.18.60]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t380pRDs021823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Apr 2015 20:51:29 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D35C7900-5191-4270-85F1-8EAD2632D55C"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: Date: Tue, 7 Apr 2015 17:51:26 -0700 Message-Id: <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu> References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> To: Mike Jones X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA01Se0gTcRznd7vdzrHTc1r+nIV2LXrO7MmyUvMv8S8jTVJRL3e50W2TuynO gkyKXjMLzGwk+WpaCooRZqLVSnsSM6gsI3BphNNePkpQ6M5T87/P7/d5fX/8vrhMPSzX4CaL jeEsNEthSlStiNHqrhzTpkQNlhH6G+deKvQV0z5MXzlzWabvqviN6geqbmH652MjmH605qk8 TpFQXz+NJJy+N6tIcHYMoQlO52MkCU1T7jEwrKmA4TbHZCuNvptvsbyZjYXfy2uRYnBWex74 4ZDcDj2NJ4GEl0PP5xZMxGqyDoHdrzefB0oBtwLY2uDFpEM3ArvevZ9TBZGpsKesVS5igoyC VS8mEFEkI8sBfNbjlUuxGlji652rwMg18GrzKUTEfmQ6nHb1ChocR0kt9NTRkrdaaG5xoFJo NHT/bFdIzeMAtjTfnzMHk5vgl74pTDRDMhw62nIvgUDnkjmcS+cQCRm5EbpqfDIJr4cPLjSg Eg6H7WPX5+93wbpr/fP3e+HHi9WIhGOgt6JWXg3w22ClwVykM9MmlmdydHwObbEwnG5bpNlk i2QM+W1A/EG/UP97YPIR5QYkDigV0Ri2OkUtpwt4u9kNQnGEWkZMcdoUtf9hq8FupHljFpfP MrwbaIUub2uTB2hQi9XCUMGEmRV0hIG2FzGcdUEWhqNUCNH21z9ZTebSNuYow+Qx3AK7Ascp SNiLBGMgx+QyhUdMrO0/jeB+bgBxlRB+UNQQfB5t5k25Ev8CrNKESGZSJIz5lkXvwnaOgBDh WUFEtqhSCbu76B4RghEhOOArJQbb6P+Uphiw5zJ096OS/lTFbh2WT/bHZgSgmW5Xvi+aRq0f Bhw9jojZ0sr4iB9POpty+ja97Tg+q0qNSM4br3z6JnPigDNrZqrzTPvDE3dO7ztssKT1fnP1 331HnPnVnR41mHxokCXilPGBO5+Q+v2vShKb1u5gM9LH1w0llnZ8xNvZT6O74ymUN9JbNsg4 nv4HkNOaEngDAAA= Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , Ben Campbell , Phil Hunt , "oauth-chairs@ietf.org" , The IESG , "" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 00:51:42 -0000 --Apple-Mail=_D35C7900-5191-4270-85F1-8EAD2632D55C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Section 2: >=20 > The software_version "SHOULD change on any update identified with the > same software_id" --why not MUST? What happens if this doesn't happen? >=20 I agree with Mike that the SHOULD is more realistic, especially because = the definition of =E2=80=9Cversion=E2=80=9D isn=E2=80=99t something that = we can really lock down a lot from the spec=E2=80=99s perspective. What we can do though is add some text, as Ben suggests, that says why = the SHOULD ought to be applied in the common case and what kinds of = exceptions there are. I=E2=80=99ll try to work something out based on = the discussion threads here and add it to the draft. To the other issues: >=20 > "Extensions and profiles MAY expand this list.." -- That seems more = like > a statement of fact than a normative requirement. >=20 Noted, we=E2=80=99re just trying to say that there are others items that = could be in there. We can change the =E2=80=9CMAY=E2=80=9D to =E2=80=9Ccan= =E2=80=9D. > 3.2.1: >=20 > client_id "SHOULD NOT be currently valid for any other registered > client": Why not MUST? What happens if it is valid for another client? We=E2=80=99ve got some text on re-use of the client_id in the security = considerations section. >=20 > 4.1 and 4.2 allow the designated expert to accept preliminary > registrations if they are confident a spec will be published. = Shouldn't > this follow the normal processes for preliminary registrations? Is = there > a way to walk back registrations if the spec isn't published after = all? I=E2=80=99ll defer to others=E2=80=99 expertise on the right text for = the IANA section, this was imported from another example spec. >=20 > section 5: >=20 > 4th paragraph after bullet list: "... authorization server needs to = take > steps to > mitigate this risk...": Other statements like this have been > normative. Is there a reason this one is not? No specific reason that I recall, except that there=E2=80=99s not a = specific step that we prescribe. We can make that a MUST. >=20 > 2nd paragraph from end: "... treat the new registration as being > suspect": ... and do what? >=20 >=20 Good catch, I think that thought is unfinished. It=E2=80=99s up to the = AS in the end, but it should probably reject the registration. =E2=80=94 Justin > On Apr 7, 2015, at 3:09 PM, Mike Jones = wrote: >=20 > I think that the current SHOULD is more realistic. In the real world, = particularly while developing and testing, people will have many = iterations of pre-release software for a given version, all of which = will likely be identified with the intended version number before the = final release of that version of the software is made. >=20 > -- Mike >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, April 07, 2015 11:11 AM > To: Phil Hunt > Cc: The IESG; oauth-chairs@ietf.org; = draft-ietf-oauth-dyn-reg@ietf.org; Justin Richer > Subject: Re: Ben Campbell's No Objection on = draft-ietf-oauth-dyn-reg-27: (with COMMENT) >=20 > On 7 Apr 2015, at 13:03, Phil Hunt wrote: >=20 >> Section 2: >>>=20 >>> The software_version "SHOULD change on any update identified with = the >>> same software_id" --why not MUST? What happens if this doesn't >>> happen? >>=20 >>=20 >> The group didn=E2=80=99t necessarily agree to make software_version = mandatory >> to provide. Thus the word, SHOULD seemed appropriate to indicate that >> if used it SHOULD change from version to version. That said, I am ok >> with MUST (e.g. if software_version is used, it MUST change...). >>=20 >> In answer to your question what happens: this is not so much a >> security issue (in the traditional sense of an attacker), but rather = a >> regular software versioning/maintenance issue. The idea is that some >> client software updates may prove to be buggy (or have performance >> issues) and service providers may want to be able to refuse some >> versions of client software while accepting others (e.g. 2.5 is = broken >> and causes DoS issues, while 2.5.1 is acceptable). If a version is >> not provided, than an AS=E2=80=99s only choice is to ban all versions = and >> force the client developer to use or obtain a different software_id >> for future registrations. >=20 > Thanks for the response. I can live with either a SHOULD or a MUST, = but if the SHOULD stays, it would be good to add a sentence or two to = the effect of the above paragraph. That being said, "If used, it MUST = change" seems to be more precise if that fits the WG intent. --Apple-Mail=_D35C7900-5191-4270-85F1-8EAD2632D55C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVJHuPAAoJEDPAngkbd+w9WdsH/2OqZUD26ujfWQcHP0TIh3JU wMIR4LrUHa3nAv/S4KVEmVRaT5QFgqYzgVzJ+8TvOAZzKtOUpA+vVGlklErCQE3d vIUpew8rRCD/+pbBnkf9vTx3L8Wi0CfAqs2RBxGcewqxxNzRdqoRNl+PUtvbJnvS xtmj7WXSUJcy39t0WdMaTTnME+fuWvovEyAuNpWX5IYXAC3q/wCP6oehZpQdQ6px ck5xaidF8qmkpXyJ/wLVuT5uy1kO5oLy8RgGiRnyfMn6zAg5AlovBY0icR+rxOMs 4OvVPEQ/mV6+g1HT8fDTV9XTfV/2RYWyn/t3WkDsoYUHTYqW8BpGTv+Cgs8a/ec= =YGeQ -----END PGP SIGNATURE----- --Apple-Mail=_D35C7900-5191-4270-85F1-8EAD2632D55C-- From nobody Wed Apr 8 14:19:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8C81B36B2; Wed, 8 Apr 2015 14:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL0NxXckwLBl; Wed, 8 Apr 2015 14:19:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4451B36AD; Wed, 8 Apr 2015 14:19:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Hannes Tschofenig" To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408211902.23759.93179.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 14:19:02 -0700 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, oauth-chairs@tools.ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, iesg-secretary@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-introspection-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:19:12 -0000 Hannes Tschofenig has requested publication of draft-ietf-oauth-introspection-07 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ From nobody Wed Apr 8 14:20:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163F71B36AE for ; Wed, 8 Apr 2015 14:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e34xZIBEDAwa for ; Wed, 8 Apr 2015 14:19:58 -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 DF0C11B36B2 for ; Wed, 8 Apr 2015 14:19:57 -0700 (PDT) Received: from [192.168.10.168] ([64.71.18.60]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MbOoG-1YwWpr2aiS-00Ip21 for ; Wed, 08 Apr 2015 23:19:56 +0200 Message-ID: <55259B78.3020700@gmx.net> Date: Wed, 08 Apr 2015 23:19:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sSbbokj5EQNEwwg8OjIWkrOa9WpgE75QW" X-Provags-ID: V03:K0:wo8FMlSdy+8SXqwn0b7s9U98vRCRHh+hDQ5n2SxhijlESwIonKV +D0piMx5/nid1Zag+D6f7s7uxaWKakaNYPDquMQyS2mWHtM5PSTqKh6g/Ya1R5pkl+MPEjQ djkx5mkd9j+in7AUEogbBJCD22sYraO9TdgmZNOJThFw2DOS12/hGIIPf77ihN6sXCqnglQ TujzciZISF9FwRIKECe2g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-introspection-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:20:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sSbbokj5EQNEwwg8OjIWkrOa9WpgE75QW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: I have just submitted the OAuth2.0 Token Introspection specification to the IESG. Here is the shepherd writeup: http://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/shepherdwr= iteup/ --sSbbokj5EQNEwwg8OjIWkrOa9WpgE75QW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVJZt5AAoJEGhJURNOOiAtgvgIAIzexvlchJWP1q492qsRAWig 9hCAsgybTZBQKpXCWvKDHkChugXP4yLFIy6p432vsGWsCMfBPSS4Nx5W8SLuV/TX e6eL+Ip0sqvUDpMArAm68b2Ywabyg6LqrzN0Aviyq5fKsZsZkCFrF+ZtcGBVj+pv Z6XXT0cxmcR+PhrguFaWCVUVwvwr18uG26jeJ3Z38aN/isPKNyXriiUKLzcbFEUM Ewsk0UOHuAwOWML0uUX//jzdqO749ffnuhrECe2QwJ7GjkAw6eTZcTAItJtysrZP W22cDfgBtc29MgR5J4nAZOEvLBT/Xd1aLwGPTHdlb4ICSar8L41CvDYxB8j/gp8= =schf -----END PGP SIGNATURE----- --sSbbokj5EQNEwwg8OjIWkrOa9WpgE75QW-- From bhurt42@gmail.com Thu Apr 9 10:35:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ACC1B2FA7 for ; Thu, 9 Apr 2015 10:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7Ac_TvFOO-A for ; Thu, 9 Apr 2015 10:35:52 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::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 173851B2FBB for ; Thu, 9 Apr 2015 10:35:51 -0700 (PDT) Received: by wgsk9 with SMTP id k9so105162709wgs.3 for ; Thu, 09 Apr 2015 10:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=If3yrzrWx0sPlpwdVZ+V9hv8ahAv9EGKoQ3VnZvCKzo=; b=e/8V0xbmdfXhkEJFfACtHwxtLxGHnpUGO/lLZllQioYVkU7EJYYcIA3cikjNhYWsKb eDbK2lFe6BrpVDHvmQ4KUlPgDKnLVHpMpXVtoa5GePfCT6A/yOMTGH8ILppZpmxa89Nd Azp7IzKgiBVmHQipy5Rlf6rrkxOcoGhwjFsRUHanwJMfNhGh6fmxl3aDQiNTHoJ6faAk rlfCUcnzS2j/MbH2MvoldRaf3pkcIUtmH4RK5g/LIwbnKuahW3gxywownZnjP/H104+f 4ULhCH59nXLPN+PtBPazqSh58VwZApqusCG7VMBUC4/0+TxLQPO/h5vqHn9UINHTEnFj 7t1A== MIME-Version: 1.0 X-Received: by 10.194.61.133 with SMTP id p5mr32086111wjr.132.1428600947876; Thu, 09 Apr 2015 10:35:47 -0700 (PDT) Received: by 10.194.6.202 with HTTP; Thu, 9 Apr 2015 10:35:47 -0700 (PDT) Date: Thu, 9 Apr 2015 13:35:47 -0400 Message-ID: From: Brian Hurt To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7bacb5980627ea05134e1480 Archived-At: Subject: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:38:42 -0000 --047d7bacb5980627ea05134e1480 Content-Type: text/plain; charset=UTF-8 This is probably the wrong place to ask this question- if so, I apologize. But I'm trying to figure out how to get a username given only an access id (and client id, etc.) in oauth2. Is this possible, and if so, how? Thanks, Brian --047d7bacb5980627ea05134e1480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This is probably the wrong place to ask this ques= tion- if so, I apologize.=C2=A0 But I'm trying to figure out how to get= a username given only an access id (and client id, etc.) in oauth2.=C2=A0 = Is this possible, and if so, how?

Thanks,
Brian
--047d7bacb5980627ea05134e1480-- From nobody Thu Apr 9 11:45:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BBA1A1B87 for ; Thu, 9 Apr 2015 11:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg_M2Pmjr2KN for ; Thu, 9 Apr 2015 11:45:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F231A1B56 for ; Thu, 9 Apr 2015 11:45:54 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t39IjqDt007334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Apr 2015 18:45:52 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t39IjqKV029148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Apr 2015 18:45:52 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t39IjpmT012773; Thu, 9 Apr 2015 18:45:52 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Apr 2015 11:45:51 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Thu, 9 Apr 2015 11:45:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <799DB637-8C8C-4B9A-995C-C005B7491616@oracle.com> References: To: Brian Hurt X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:45:57 -0000 This has been a long standing issue. OAuth is an authorization protocol and n= ot an authentication protocol.=20 You might want to look at OpenID Connect for an OAuth profile that addresses= your case.=20 Phil > On Apr 9, 2015, at 10:35, Brian Hurt wrote: >=20 >=20 > This is probably the wrong place to ask this question- if so, I apologize.= But I'm trying to figure out how to get a username given only an access id= (and client id, etc.) in oauth2. Is this possible, and if so, how? >=20 > Thanks, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Apr 9 11:46:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DE11A1BDA for ; Thu, 9 Apr 2015 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKVYtb_oxcCx for ; Thu, 9 Apr 2015 11:46:41 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 51DDD1A1B87 for ; Thu, 9 Apr 2015 11:46:41 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so119181668obb.3 for ; Thu, 09 Apr 2015 11:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Tx8V0xo9Z2xBrevp4blqzqiecYB89doilOXjQYzpP5Q=; b=gjekfiPmLh032wDb6sGOtacZ+48KZHJEaNLTkSIFEp+u3PN71m9tNt46BhWdX/UCrt Db3FQABM7CtV8eDGeDSF1B8RP6PMZ4HwsQ6ZvWyMg3NEagg36syq49iYGEXP3bzDhlxO vbd6vo+atN9BWztpkne+Lm2lzhlbz7UmAQPfqAL309KpolDQU5o92awmeToKTAH9oHSQ wij8AEGX0v2tGZ+rDGP/lGA1fvWsrZgxfhj0NLG2ySxlLfTF7VSDiHYE/s1z0xVKOjTm qb0Xf4uEUmPXM+igcnn5NSUoC41VXUx52XD4BAuMzYwRtgW+bAlgAz/oioA7CzFv841z ow9w== X-Received: by 10.60.155.196 with SMTP id vy4mr6619930oeb.55.1428605200758; Thu, 09 Apr 2015 11:46:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.122.106 with HTTP; Thu, 9 Apr 2015 11:46:20 -0700 (PDT) In-Reply-To: References: From: Josh Mandel Date: Thu, 9 Apr 2015 11:46:20 -0700 Message-ID: To: Brian Hurt Content-Type: multipart/alternative; boundary=047d7bfeaa6e84177c05134f116c Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:46:43 -0000 --047d7bfeaa6e84177c05134f116c Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, In general, OAuth 2.0 is an authorization framework; as such it doesn't directly describe authentication claims like "who is the current user?" or "what is this user's e-mail address". OAuth 2.0 can be used as the basis for authentication protocols like OpenID Connect [1], which you may want to explore as a "complete package" that provides this kind of functionality. Best, Josh 1. http://openid.net/specs/openid-connect-core-1_0.html On Thu, Apr 9, 2015 at 10:35 AM, Brian Hurt wrote: > > This is probably the wrong place to ask this question- if so, I > apologize. But I'm trying to figure out how to get a username given only > an access id (and client id, etc.) in oauth2. Is this possible, and if so, > how? > > Thanks, > Brian > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bfeaa6e84177c05134f116c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Brian,

In general, OAuth 2.0 is an a= uthorization framework; as such it doesn't directly describe authentica= tion claims like "who is the current user?" or "what is this= user's e-mail address". OAuth 2.0 can be used as the basis for au= thentication protocols like OpenID Connect [1], which you may want to explo= re as a "complete package" that provides this kind of functionali= ty.

Best,

=A0 Josh
<= div>

On Thu, Ap= r 9, 2015 at 10:35 AM, Brian Hurt <bhurt42@gmail.com> wrote:=

This is probab= ly the wrong place to ask this question- if so, I apologize.=A0 But I'm= trying to figure out how to get a username given only an access id (and cl= ient id, etc.) in oauth2.=A0 Is this possible, and if so, how?
Thanks,
Brian

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


--047d7bfeaa6e84177c05134f116c-- From nobody Thu Apr 9 11:49:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D971A875B for ; Thu, 9 Apr 2015 11:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUIj0Mp5gkb1 for ; Thu, 9 Apr 2015 11:49:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E131A8756 for ; Thu, 9 Apr 2015 11:49:26 -0700 (PDT) Received: from [192.168.10.172] ([167.220.25.4]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M9NIY-1YY42X0Wi6-00CjFG; Thu, 09 Apr 2015 20:49:24 +0200 Message-ID: <5526C9AF.8040109@gmx.net> Date: Thu, 09 Apr 2015 20:49:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phil Hunt , Brian Hurt References: <799DB637-8C8C-4B9A-995C-C005B7491616@oracle.com> In-Reply-To: <799DB637-8C8C-4B9A-995C-C005B7491616@oracle.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q13lE951XgSb6bO2QHwhumn9pmjxT4PmL" X-Provags-ID: V03:K0:rw2DirkSwSnJ/yt80g7QYAQ2Y55p7fjQx5GmUXiedbqsNrE0mbq vnq9tO+h70BhZHtz/UaijSo/HK3nItpUuz2ig3bBcL7SPWXQ2N8iFz36kD5ZLrDIOEAYrt1 Gy/Lc1aTYyJlCLUn/2LM2ZMMj6aNGQVQRu84/L3D34XFs6Ph2DVBjugHwUcKDnQaCBOF4b+ SzjGeimZX4GU8pHhfDaHg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:49:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q13lE951XgSb6bO2QHwhumn9pmjxT4PmL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Brian, in addition to what Phil said let me provide you with two references: * Article about user authentication and OAuth: http://oauth.net/articles/authentication/ * OpenID Connect specification as a way to do what you seem to be looking for: http://openid.net/connect/ Ciao Hannes On 04/09/2015 08:45 PM, Phil Hunt wrote: > This has been a long standing issue. OAuth is an authorization protocol= and not an authentication protocol.=20 >=20 > You might want to look at OpenID Connect for an OAuth profile that addr= esses your case.=20 >=20 > Phil >=20 >> On Apr 9, 2015, at 10:35, Brian Hurt wrote: >> >> >> This is probably the wrong place to ask this question- if so, I apolog= ize. But I'm trying to figure out how to get a username given only an ac= cess id (and client id, etc.) in oauth2. Is this possible, and if so, ho= w? >> >> Thanks, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --q13lE951XgSb6bO2QHwhumn9pmjxT4PmL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVJsmvAAoJEGhJURNOOiAtEAoH/if8D9NkH/71YNgVoVhNZHi2 jipQUE4tWZz9lSx0jwC9fNHINPLmp1TyMtF+LCwNBJ+/R/vqOtwe/RW0uck/XqkH Q7qnH6NjGEDP/D1HEc/KS64k3s/f2kej7Wh/kgFK4wf2q3Ff5wYIZXroU0X44g76 oevWCQ6fA17TGco021wD4nKmqI1ynCYyFgfNwEQKFoj24SYlrMUxpprj9UIERTTj 7YVmL53boV8qO7t4i1a5670TQODHFE86q/La0xiXq3k0OP3DXsKF7pUX5TrhtiV3 N+e5KhgTOd8M8YE7GWFtUABNVrDWycx97/BeMhFfT8Deb0fwavGkmVV2z3rTOyM= =v51J -----END PGP SIGNATURE----- --q13lE951XgSb6bO2QHwhumn9pmjxT4PmL-- From nobody Thu Apr 9 15:44:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024971B34D5 for ; Thu, 9 Apr 2015 15:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjqj-s1wuhO9 for ; Thu, 9 Apr 2015 15:44:32 -0700 (PDT) Received: from mail-wi0-f182.google.com (na3sys009aog118.obsmtp.com [74.125.149.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72781B34D1 for ; Thu, 9 Apr 2015 15:44:31 -0700 (PDT) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKVScAzy05CO14NKOH4yz680asEzESPoHw@postini.com; Thu, 09 Apr 2015 15:44:31 PDT Received: by widdi4 with SMTP id di4so108925686wid.0 for ; Thu, 09 Apr 2015 15:44:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KmNCGfTLhkgPv/JTVlJNkiHyp4Oo3EbmPeOmz38neZQ=; b=JXA/BYkv4mT409MTr0GUYnCtnTWu76/JD0G88eqGq4BanNOaMC7MlBuBwnRkBTMq06 UQr0ar7m6buqeeodExq93ke+jeGTirnmBCyJv6kMaHluKYZ0MpDSq/ZhyuVUMPvcqMqg exHq7YLinA3HjQbtCBDpKTSUu1ofrFNsMDqjCArsg9P7PMuvOYSTwfNpxonjaWx3mkYL /Ho28SZdyo3uAZ3ScKPsemnyuzQFpc5qE0fcWiTD/uH0Y3wyoJtVMv9qG7MXONTDw1js t6XFVniXh0cZZfwrYJkinA9CJ32HOn3gzla1f+HYGNBhozCi4qaxnaijtgwGoJ/hM70u 5mPw== X-Gm-Message-State: ALoCoQnq+Z3ZnN/RLQkO8f4459S52U/xP+7cVJhzgLcWvZVYXr03v2BITgYdKWuzMCm9kKqi3xZbsA5ONjr7Ah/5ZhtrRGIWxb4vPOFIjKg0FdKhzBYpdTW/6ewcXiXWva4QwQEaTlla X-Received: by 10.180.97.225 with SMTP id ed1mr9840107wib.17.1428619470161; Thu, 09 Apr 2015 15:44:30 -0700 (PDT) X-Received: by 10.180.97.225 with SMTP id ed1mr9840095wib.17.1428619470082; Thu, 09 Apr 2015 15:44:30 -0700 (PDT) Received: from [10.207.195.55] ([31.55.31.230]) by mx.google.com with ESMTPSA id js3sm199270wjc.5.2015.04.09.15.44.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 15:44:29 -0700 (PDT) Message-ID: <552700CB.2030702@pingidentity.com> Date: Thu, 09 Apr 2015 23:44:27 +0100 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , Phil Hunt , Brian Hurt References: <799DB637-8C8C-4B9A-995C-C005B7491616@oracle.com> <5526C9AF.8040109@gmx.net> In-Reply-To: <5526C9AF.8040109@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:44:35 -0000 without further context the original question may be about retrieving the username of the user on whose behalf the OAuth 2.0 client is acting, which is a valid question with a valid (introspection) answer in a pure OAuth 2.0 scenario Hans. On 4/9/15 7:49 PM, Hannes Tschofenig wrote: > Brian, > > in addition to what Phil said let me provide you with two references: > > * Article about user authentication and OAuth: > http://oauth.net/articles/authentication/ > > * OpenID Connect specification as a way to do what you seem to be > looking for: > http://openid.net/connect/ > > Ciao > Hannes > > > On 04/09/2015 08:45 PM, Phil Hunt wrote: >> This has been a long standing issue. OAuth is an authorization protocol and not an authentication protocol. >> >> You might want to look at OpenID Connect for an OAuth profile that addresses your case. >> >> Phil >> >>> On Apr 9, 2015, at 10:35, Brian Hurt wrote: >>> >>> >>> This is probably the wrong place to ask this question- if so, I apologize. But I'm trying to figure out how to get a username given only an access id (and client id, etc.) in oauth2. Is this possible, and if so, how? >>> >>> Thanks, >>> Brian >>> _______________________________________________ >>> 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 > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Fri Apr 10 01:24:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA591B2ADE for ; Fri, 10 Apr 2015 01:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.324 X-Spam-Level: * X-Spam-Status: No, score=1.324 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxOeyY7hj6Nn for ; Fri, 10 Apr 2015 01:24:07 -0700 (PDT) Received: from nm44-vm8.bullet.mail.gq1.yahoo.com (nm44-vm8.bullet.mail.gq1.yahoo.com [67.195.87.31]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230FC1B2ADB for ; Fri, 10 Apr 2015 01:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1428654246; bh=Jujks65J3L2JLwnCrpbxjEKq2VC0gXqNdKNfP1HLuEs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=nxJewG64LoIUsF69d3mYifk+0+LL8S1scblCWU2y19Oa+eipTEuCkWe2mQCU3yQK38EttIv2TC67LAloRqw4ZkZZLauO76e+3TsJ+zIym8FNQXKPEjY/JCP9B24zPibQqOHNwK56Mn137/aRqAH4JM8N+7egvxiWhW8azqWQF+34MHQmDl7mWXqb1hpee5g+Go6i3wtnrVYYqSjhL6OOOvaL9HRajnObjGZOh6IN9FB43H92CvWnLXXYj2BiTYcv57TyLttgso/69MiUP4q6KtIqqkOmSMv6RhPEuwC5/V6eQkzG9BbdUIcfpJzMPpmT0WDhilQucuRWdf/iifD/Ug== Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 10 Apr 2015 08:24:06 -0000 Received: from [98.137.12.57] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 10 Apr 2015 08:21:25 -0000 Received: from [98.139.215.141] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 10 Apr 2015 08:21:25 -0000 Received: from [98.139.212.221] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 10 Apr 2015 08:21:25 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 10 Apr 2015 08:21:25 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 20884.52709.bm@omp1030.mail.bf1.yahoo.com X-YMail-OSG: nlrDSnEVM1nCTsY9ijsPJC03KVfcOI_8f_Euc_9bVANMQGnIHAwdSq3Q8qPhGiC BCuATEiJuOnNKmPWec53XPxKHX.9E2VrRCIdz3GUBRH2e60Dgek9SD.I85HBNGh.6Ehao7lCdFEW _U494ZcxoK0FLchEmw9mAoqKuVxJVwWHMYaLnQff_zgRfIRuEmerP9pCjish6MFGO8blAQgcGROF vhcx7kU1YYLjUv_KoUtPVK_3Ep_Vt900S_Q3jVBMzdru8I4HhVjU6fdXvK3YBI46yEGHsW5Dd0zT ECNu94294lhC5fOThCcd_oERhWXN5AL1BInFVrpcrBjPt68g9uMMfUyJLLLBaXsAEyhs03G0bksK Wq9V6ThbPKslvf5jvlCdY1aebmf6Q8gK5lSu3YHATbDN68OETY0QXetI6xSkVMTUNBsTMji2Mlwc slAaTr4vnpVV4MNSjpFBSvVcu5PrZ6mrhMgyT0b6uF46sU3OOvCDLRzZ7IUvozkWy.5NDyEWLSLt QKooPxERnzmoC6JUVWbyh1Nf6Xg-- Received: by 66.196.80.146; Fri, 10 Apr 2015 08:21:24 +0000 Date: Fri, 10 Apr 2015 08:21:24 +0000 (UTC) From: Bill Mills To: Brian Hurt , "oauth@ietf.org" Message-ID: <122920110.166336.1428654084156.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_166335_1840266053.1428654084150" Archived-At: Subject: Re: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 08:24:08 -0000 ------=_Part_166335_1840266053.1428654084150 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given only a user id or client the answer is no. =C2=A0You'd want to use so= mething like the old UNIX "finger". =C2=A0If you have a valid OAuth user to= ken then as someone already said the token introspection stuff *can* do exa= ctly this, but what info you get out of it may vary.=20 On Thursday, April 9, 2015 10:38 AM, Brian Hurt wr= ote: =20 =20 This is probably the wrong place to ask this question- if so, I apologize.= =C2=A0 But I'm trying to figure out how to get a username given only an acc= ess id (and client id, etc.) in oauth2.=C2=A0 Is this possible, and if so, = how? Thanks,Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_166335_1840266053.1428654084150 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given only a user id or client = the answer is no.  You'd want to use something like the old UNIX "fing= er".  If you have a valid OAuth user token then as someone already sai= d the token introspection stuff *can* do exactly this, but what info you ge= t out of it may vary.


On Thursday, Ap= ril 9, 2015 10:38 AM, Brian Hurt <bhurt42@gmail.com> wrote:



This is probably the wrong place to ask this qu= estion- if so, I apologize.  But I'm trying to figure out how to get a= username given only an access id (and client id, etc.) in oauth2.  Is= this possible, and if so, how?

Thanks,
= Brian

_______________________________________________<= br>OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth


------=_Part_166335_1840266053.1428654084150-- From nobody Fri Apr 10 06:04:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5181B33F2 for ; Fri, 10 Apr 2015 06:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQzrpvXJ_DRv for ; Fri, 10 Apr 2015 06:04:35 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 6F94E1B3397 for ; Fri, 10 Apr 2015 06:04:35 -0700 (PDT) Received: by wgin8 with SMTP id n8so17057578wgi.0 for ; Fri, 10 Apr 2015 06:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WqoRKeqFcZ3OXjkUNULRET+az7EyDUaH3kNYngAXEuA=; b=jAgJ81Tno7XiWyPGqr4d5gahW/r8RznCq2saRDu4pPy7u1KH50suIs7rKHSCXHYWYK sIkXyASppgF7Sg0JU0JRVsa1+fCd+bO3v/B3M3B4OiAPICuS3MQ1Zye6RLtfL7B2A23e C94V4/rKdiVHETY9v91+7AhIhuQcdU7IvHCr+ycmiFpNDJph1MEyFJShuB1tYX74PQFy dTz3XNpGvsPkVK4cfvNgCs1Fw19Hwj2RO7eg00G5UjhTjZhdEUQ9zDFYIDD/LVhMjqe3 c+evCrQQsNgfSqyGAfR8ao+DQkz6g8JQfpd9KabiF3ZBOhedJFEryv8/buiatL+LbaeF nXFA== MIME-Version: 1.0 X-Received: by 10.181.27.229 with SMTP id jj5mr4783418wid.87.1428671074190; Fri, 10 Apr 2015 06:04:34 -0700 (PDT) Received: by 10.194.6.202 with HTTP; Fri, 10 Apr 2015 06:04:34 -0700 (PDT) In-Reply-To: <552700CB.2030702@pingidentity.com> References: <799DB637-8C8C-4B9A-995C-C005B7491616@oracle.com> <5526C9AF.8040109@gmx.net> <552700CB.2030702@pingidentity.com> Date: Fri, 10 Apr 2015 09:04:34 -0400 Message-ID: From: Brian Hurt To: Hans Zandbelt Content-Type: multipart/alternative; boundary=001a1137fc02e0cc9405135e6702 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 13:04:37 -0000 --001a1137fc02e0cc9405135e6702 Content-Type: text/plain; charset=UTF-8 Yes. I'm being handed the access id, client id, etc. of an oauth session, but not the username. So I was wondering if I was missing something obvious, or that I really do need the user name passed in as well. And it's sounding like the latter. Thanks, everyone, for your help. Brian On Thu, Apr 9, 2015 at 6:44 PM, Hans Zandbelt wrote: > without further context the original question may be about retrieving the > username of the user on whose behalf the OAuth 2.0 client is acting, which > is a valid question with a valid (introspection) answer in a pure OAuth 2.0 > scenario > > Hans. > > > On 4/9/15 7:49 PM, Hannes Tschofenig wrote: > >> Brian, >> >> in addition to what Phil said let me provide you with two references: >> >> * Article about user authentication and OAuth: >> http://oauth.net/articles/authentication/ >> >> * OpenID Connect specification as a way to do what you seem to be >> looking for: >> http://openid.net/connect/ >> >> Ciao >> Hannes >> >> >> On 04/09/2015 08:45 PM, Phil Hunt wrote: >> >>> This has been a long standing issue. OAuth is an authorization protocol >>> and not an authentication protocol. >>> >>> You might want to look at OpenID Connect for an OAuth profile that >>> addresses your case. >>> >>> Phil >>> >>> On Apr 9, 2015, at 10:35, Brian Hurt wrote: >>>> >>>> >>>> This is probably the wrong place to ask this question- if so, I >>>> apologize. But I'm trying to figure out how to get a username given only >>>> an access id (and client id, etc.) in oauth2. Is this possible, and if so, >>>> how? >>>> >>>> Thanks, >>>> Brian >>>> _______________________________________________ >>>> 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 >> >> > -- > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity > --001a1137fc02e0cc9405135e6702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes.=C2=A0 I'm being handed the access id, client id, = etc. of an oauth session, but not the username.=C2=A0 So I was wondering if= I was missing something obvious, or that I really do need the user name pa= ssed in as well.=C2=A0 And it's sounding like the latter.=C2=A0
Thanks, everyone, for your help.

Brian=


On Thu, Apr 9, 2015 at 6:44 PM, Hans Zandbelt &= lt;hzandbel= t@pingidentity.com> wrote:
= without further context the original question may be about retrieving the u= sername of the user on whose behalf the OAuth 2.0 client is acting, which i= s a valid question with a valid (introspection) answer in a pure OAuth 2.0 = scenario

Hans.


On 4/9/15 7:49 PM, Hannes Tschofenig wrote:
Brian,

in addition to what Phil said let me provide you with two references:

* Article about user authentication and OAuth:
htt= p://oauth.net/articles/authentication/

* OpenID Connect specification as a way to do what you seem to be
looking for:
http://openid.net/= connect/

Ciao
Hannes


On 04/09/2015 08:45 PM, Phil Hunt wrote:
This has been a long standing issue. OAuth is an authorization protocol and= not an authentication protocol.

You might want to look at OpenID Connect for an OAuth profile that addresse= s your case.

Phil

On Apr 9, 2015, at 10:35, Brian Hurt <bhurt42@gmail.com> wrote:


This is probably the wrong place to ask this question- if so, I apologize.= =C2=A0 But I'm trying to figure out how to get a username given only an= access id (and client id, etc.) in oauth2.=C2=A0 Is this possible, and if = so, how?

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

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




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


--
Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Technic= al Architect
hzandbelt@p= ingidentity.com | Ping Identity

--001a1137fc02e0cc9405135e6702-- From nobody Fri Apr 10 06:18:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959C71B3538 for ; Fri, 10 Apr 2015 06:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XLJzhK6k3jj for ; Fri, 10 Apr 2015 06:18:19 -0700 (PDT) Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (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 1D8B11B3537 for ; Fri, 10 Apr 2015 06:18:18 -0700 (PDT) Received: from pps.filterd (m0074411.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.14.7/8.14.7) with SMTP id t3ADGthA026058 for ; Fri, 10 Apr 2015 08:18:18 -0500 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by mx0a-0019e102.pphosted.com with ESMTP id 1tpf1a00sk-1 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 10 Apr 2015 08:18:18 -0500 Received: by qkgx75 with SMTP id x75so29760590qkg.1 for ; Fri, 10 Apr 2015 06:18:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yCeqhjQBUKbOKaQwBvuTyo2skBk8rVdaZkjWkp749wY=; b=N6g+OkQKxdJryLt/T8TFYTTpWEg/xaDy05/9vrM9/YOS9c+1Wo+6hLxxCgeI9jghF6 pT54r4V/7C4DC80AkuWtpXCkJtb8WxGn9y+6dBiYd5uDkd9LOhGk5a3hJ76QuTTslth7 haJmZxrULHsAVLnfy5HJY8RRXSypvChsJ8DV1zf10TsptMA/4Pywl6yEqVIByRzjfC0r N/weDTa3yVygzVr9/ov5W6nic9wdxQ7geA4krxIe0fMA5pv/auyTTomV2s9SxJz1qhNi 0vUoe0KSw29V9Hj9WfdDPfFKbaRC9XKMZMs5eGIz/05oKOpcqnNyioLCVErxF9hxgArX 72fA== X-Gm-Message-State: ALoCoQk9HTGNCIQhQpY68LobnhSuTLIbbrQJLHxsPU5EQZEvw3GnQiplQKV9QVRYMM4uzJq8hNXs2CuLluQZrKGvII2VYTdPMpfIGEXB9lU1M7oorKQ5pss= X-Received: by 10.55.16.140 with SMTP id 12mr2563767qkq.39.1428671897034; Fri, 10 Apr 2015 06:18:17 -0700 (PDT) X-Received: by 10.55.16.140 with SMTP id 12mr2563756qkq.39.1428671896944; Fri, 10 Apr 2015 06:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.106 with HTTP; Fri, 10 Apr 2015 06:17:56 -0700 (PDT) In-Reply-To: References: <799DB637-8C8C-4B9A-995C-C005B7491616@oracle.com> <5526C9AF.8040109@gmx.net> <552700CB.2030702@pingidentity.com> From: Adam Lewis Date: Fri, 10 Apr 2015 08:17:56 -0500 Message-ID: To: Brian Hurt Content-Type: multipart/alternative; boundary=001a11475c7aeb11fe05135e9878 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=2.77555756156289e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.651376761684238 suspectscore=2 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.651376761684238 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.651376761684238 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504100110 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Getting a username from an access id in oauth2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 13:18:21 -0000 --001a11475c7aeb11fe05135e9878 Content-Type: text/plain; charset=UTF-8 Hi Brian, It can get confusing since OAuth doesn't define the contents/structure of the access token the way OIDC did for the id_token. Though to me it seems pretty obvious that in a delegated authorization framework where "alice" delegated approval to "client" to access her "protected resources" on a "resource server" that when "client" presents the "access token" to the "resource server" the token would need to indicate that it is "alice's" resources the token is good for, and not "bob's" Certainly in every implementation of OAuth that I've played with (at least half a dozen) all the access tokens are able to communicate that the access token is being used to access "alice's" resources. But maybe that is what the "access id" is in your implementation? Maybe the access id points to alice's resources? We have actually profiled our access token to look just like the id_token, with the RS being the audience instead of the client. In fact if you looked at our access token and look at a standard Id token you would have a hard time telling them apart. I've always argued that the RS as a relying party wants to know a lot of the same things as a traditional RP (e.g. when did the user authenticate to give you this access token (auth_time) and how did they authenticate it (amr/acr)). For access to high assurance protected resources, the RS might want to know that the person who delegated their authorization proved their identity to the AS using 2-factor authentication. Granted, the AS could also implement policy that would only return a scopes to the high assurance protected resource if the user used 2 factor ... but I guess that why OAuth is a "framework" because you can slice it half a dozen ways :-) -adam On Fri, Apr 10, 2015 at 8:04 AM, Brian Hurt wrote: > Yes. I'm being handed the access id, client id, etc. of an oauth session, > but not the username. So I was wondering if I was missing something > obvious, or that I really do need the user name passed in as well. And > it's sounding like the latter. > > Thanks, everyone, for your help. > > Brian > > > On Thu, Apr 9, 2015 at 6:44 PM, Hans Zandbelt > wrote: > >> without further context the original question may be about retrieving the >> username of the user on whose behalf the OAuth 2.0 client is acting, which >> is a valid question with a valid (introspection) answer in a pure OAuth 2.0 >> scenario >> >> Hans. >> >> >> On 4/9/15 7:49 PM, Hannes Tschofenig wrote: >> >>> Brian, >>> >>> in addition to what Phil said let me provide you with two references: >>> >>> * Article about user authentication and OAuth: >>> http://oauth.net/articles/authentication/ >>> >>> * OpenID Connect specification as a way to do what you seem to be >>> looking for: >>> http://openid.net/connect/ >>> >>> Ciao >>> Hannes >>> >>> >>> On 04/09/2015 08:45 PM, Phil Hunt wrote: >>> >>>> This has been a long standing issue. OAuth is an authorization protocol >>>> and not an authentication protocol. >>>> >>>> You might want to look at OpenID Connect for an OAuth profile that >>>> addresses your case. >>>> >>>> Phil >>>> >>>> On Apr 9, 2015, at 10:35, Brian Hurt wrote: >>>>> >>>>> >>>>> This is probably the wrong place to ask this question- if so, I >>>>> apologize. But I'm trying to figure out how to get a username given only >>>>> an access id (and client id, etc.) in oauth2. Is this possible, and if so, >>>>> how? >>>>> >>>>> Thanks, >>>>> Brian >>>>> _______________________________________________ >>>>> 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 >>> >>> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11475c7aeb11fe05135e9878 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

It can get confusing since OA= uth doesn't define the contents/structure of the access token the way O= IDC did for the id_token. =C2=A0

Though to me it s= eems pretty obvious that in a delegated authorization framework where "= ;alice" delegated approval to "client" to access her "p= rotected resources" on a "resource server" that when "c= lient" presents the "access token" to the "resource ser= ver" the token would need to indicate that it is "alice's&quo= t; resources the token is good for, and not "bob's" =C2=A0

Certainly in every implementation of OAuth that I= 9;ve played with (at least half a dozen) all the access tokens are able to = communicate that the access token is being used to access "alice's= " resources.=C2=A0 But maybe that is what the "access id" is= in your implementation?=C2=A0 Maybe the access id points to alice's re= sources?

We have actually profiled our access toke= n to look just like the id_token, with the RS being the audience instead of= the client.=C2=A0 In fact if you looked at our access token and look at a = standard Id token you would have a hard time telling them apart.
=
I've always argued that the RS as a relying party wants = to know a lot of the same things as a traditional RP (e.g. when did the use= r authenticate to give you this access token (auth_time) and how did they a= uthenticate it (amr/acr)).=C2=A0 For access to high assurance protected res= ources, the RS might want to know that the person who delegated their autho= rization proved their identity to the AS using 2-factor authentication.=C2= =A0 Granted, the AS could also implement policy that would only return a sc= opes to the high assurance protected resource if the user used 2 factor ...= but I guess that why OAuth is a "framework" because you can slic= e it half a dozen ways :-)


-adam

On Fri, = Apr 10, 2015 at 8:04 AM, Brian Hurt <bhurt42@gmail.com> wrot= e:
Yes.=C2=A0 I'm be= ing handed the access id, client id, etc. of an oauth session, but not the = username.=C2=A0 So I was wondering if I was missing something obvious, or t= hat I really do need the user name passed in as well.=C2=A0 And it's so= unding like the latter.=C2=A0

Thanks, everyone, for your= help.

<= div>Brian


On= Thu, Apr 9, 2015 at 6:44 PM, Hans Zandbelt <hzandbelt@pingiden= tity.com> wrote:
without = further context the original question may be about retrieving the username = of the user on whose behalf the OAuth 2.0 client is acting, which is a vali= d question with a valid (introspection) answer in a pure OAuth 2.0 scenario=

Hans.


On 4/9/15 7:49 PM, Hannes Tschofenig wrote:
Brian,

in addition to what Phil said let me provide you with two references:

* Article about user authentication and OAuth:
htt= p://oauth.net/articles/authentication/

* OpenID Connect specification as a way to do what you seem to be
looking for:
http://openid.net/= connect/

Ciao
Hannes


On 04/09/2015 08:45 PM, Phil Hunt wrote:
This has been a long standing issue. OAuth is an authorization protocol and= not an authentication protocol.

You might want to look at OpenID Connect for an OAuth profile that addresse= s your case.

Phil

On Apr 9, 2015, at 10:35, Brian Hurt <bhurt42@gmail.com> wrote:


This is probably the wrong place to ask this question- if so, I apologize.= =C2=A0 But I'm trying to figure out how to get a username given only an= access id (and client id, etc.) in oauth2.=C2=A0 Is this possible, and if = so, how?

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

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




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


--
Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Technic= al Architect
hzandbelt@p= ingidentity.com | Ping Identity


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


--001a11475c7aeb11fe05135e9878-- From nobody Fri Apr 10 16:01:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463821B2E24 for ; Fri, 10 Apr 2015 16:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohXX1-fJHdmV for ; Fri, 10 Apr 2015 16:01:13 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 2EFFE1B2E23 for ; Fri, 10 Apr 2015 16:01:13 -0700 (PDT) Received: by ignm3 with SMTP id m3so22808706ign.0 for ; Fri, 10 Apr 2015 16:01:12 -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:content-type; bh=sALDgBCuu13P2ZJO0KNs2ueVczYg/gki4jVhWsxMMsA=; b=FETkaSVU4QQBdkWdnaqOylr7B6Hgt+Ih2g6MIFlIweOr+7WoH2UTWHG6qo8cL3LMQJ 11ifCdHoREse4nip+39AcgnXip044r78qd9WI4VXMbWC5dkCqt8fN7EfQqgdvGg8kn9/ QbOiygXRkJzYIKPTa0xqfK8MKwrbLB35CuEO99/+3GryOOnhbCkQcoXEUN885IRwhXUM uPG2GgfQbMDMvMLDFntihA77LQi2gVbedzRRWXFcw/qVyRQlF+XxYgywTe6CJiaUzaZ0 B79idSvqtY0QghMIBt7S3ikeEaTYUfQb3ZVPb14gkmm58Y0XxKWgYtVLhUpY2QGt+Ff7 jv3Q== X-Received: by 10.42.12.197 with SMTP id z5mr6457379icz.71.1428706872582; Fri, 10 Apr 2015 16:01:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.2.202 with HTTP; Fri, 10 Apr 2015 16:00:52 -0700 (PDT) From: isciurus Date: Fri, 10 Apr 2015 16:00:52 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf301d4208a0e754051366bdb2 Archived-At: Subject: [OAUTH-WG] New header "Fragment-Scope" to prevent assertions leakage through redirects X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:01:15 -0000 --20cf301d4208a0e754051366bdb2 Content-Type: text/plain; charset=UTF-8 Hi, One of the recent drafts https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html was brought to my attention. Regarding the part "2.2. Security Compromise: The Authorization Server As Open Redirector": The legitimate OAuth Authorization response will include an access token in the URI fragment. Most web browsers will append the fragment to the URI sent in the location header of a 302 response if no fragment is included in the location URI. This browser behaviour with a url fragment reattaching is indeed used widely in attacks on OAuth (for example, one of the recent on the bitcoin exchange http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.html) and I am also aware of one attack on OpenID 2 implementation leaking a valid signature using the same technique. We are trying to propose a browser-level protection from sensitive url fragment data reattach on cross-domain redirects: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html A new header in the AS response would also block fragment reattach in the following scenario: https://AUTHORIZATION_SERVER/authorize?response_type=token &client_id=good-client&scope=VALID_SCOPE &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize %3Fresponse_type%3Dcode %26client_id%3Dattacker-client-id %26scope%3DINVALID_SCOPE %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com But it would additionally block exploitation of vulnerable clients which have open redirects on their domains and don't whitelist their redirect_uri: https://AUTHORIZATION_SERVER/authorize?response_type=token &client_id=good-client&scope=VALID_SCOPE &redirect_uri=https%3A%2F%2good-client.com%Fopen_redirect %3Furl%3Dhttps%253A%252F%252Fattacker.com This can improve the situation with already deployed clients in large scale. Let me know if this proposal is interesting to the OAuth WG. Thanks, Andrey --20cf301d4208a0e754051366bdb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

One of the recent drafts= https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.ht= ml was brought to my attention. Regarding the part "2.2. Security = Compromise: The Authorization Server As Open Redirector":
=C2=A0 =C2=A0 The legitimate OAuth Authorization response will= include an access token in the URI fragment.
=C2=A0 =C2=A0 Most = web browsers will append the fragment to the URI sent in the location heade= r of a 302 response if no fragment is included in the location URI.
=C2=A0 =C2=A0=C2=A0
This browser behaviour with a url fragment= reattaching is indeed used widely in attacks on OAuth (for example, one of= the recent on the bitcoin exchange http://sakurity.com/blog/2015/01/10= /hacking-bitcoin-exchanger.html) and I am also aware of one attack on O= penID 2 implementation leaking a valid signature using the same technique.<= /div>
We are trying to propose a browser-level protection from sensitiv= e url fragment data reattach on cross-domain redirects: http://lists= .w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html
A n= ew header in the AS response would also block fragment reattach in the foll= owing scenario:
=C2=A0=C2=A0
=C2=A0 &client_id= =3Dgood-client&scope=3DVALID_SCOPE
=C2=A0 &redirect_uri= =3Dhttps%3A%2F%2AUTHORIZATION_SERVER%Fauthorize
=C2=A0 %3Frespons= e_type%3Dcode
=C2=A0 %26client_id%3Dattacker-client-id
= =C2=A0 %26scope%3DINVALID_SCOPE
=C2=A0 %26redirect_uri%3Dhttps%25= 3A%252F%252Fattacker.com
=C2=A0=C2=A0
But it would addi= tionally block exploitation of vulnerable clients which have open redirects= on their domains and don't whitelist their redirect_uri:
=C2= =A0=C2=A0
=C2=A0 &client_id=3Dgood-client&scope=3DVA= LID_SCOPE
=C2=A0 &redirect_uri=3Dhttps%3A%2F%2good-client.com%Fopen_redirect
=C2=A0 %3= Furl%3Dhttps%253A%252F%252Fattacker.com
=C2=A0=C2=A0
Th= is can improve the situation with already deployed clients in large scale. = Let me know if this proposal is interesting to the OAuth WG.

=
Thanks,
Andrey
--20cf301d4208a0e754051366bdb2-- From nobody Fri Apr 10 16:08:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710471B2E35 for ; Fri, 10 Apr 2015 16:08:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJcJGPrdXrgF for ; Fri, 10 Apr 2015 16:08:26 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (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 A32961A906B for ; Fri, 10 Apr 2015 16:08:26 -0700 (PDT) Received: by paboj16 with SMTP id oj16so35335173pab.0 for ; Fri, 10 Apr 2015 16:08:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=lpb7PdH0xwWOKdvk645Qeay7QLBQkIog849ha8DJ6oY=; b=mdOyuA8yeeXxJd0T5MW4e+ObK/7N8oTW1ry1uXBvgyxIrj8BFsIJ3T9rGh9NzeV2CF NUsk/dXmXfGyt6iQOIq75fM8tMuXMUp/m18eoEqo9rKWavcS4sX06rrBohNCaSZaRchj aVpVdAScAh0MWh//uqulNSGDIpisYVAtO19VadHldZsZubkThFrkmsHTyJxqWIHjOyB3 wzJSM/0B17+jyJpN+2vZNpv5AHa+LalOEX0+WahnE/bEBz7tNxk42bGzrS6AjZCCn7vC F50W9KTqReRdU+UA2Val3rrtmpTM9AoPnzSWtg8rE/sRZRelPBFz/yoqn1qD63Q25f1K f/1g== X-Gm-Message-State: ALoCoQnYhZz97uRkkxSgV/H0T/yUfMfYwNGV8kd1KWAq6If+oiT1066/i/KYktT+muFgBZ1QW2vM X-Received: by 10.68.65.75 with SMTP id v11mr1403596pbs.91.1428707306078; Fri, 10 Apr 2015 16:08:26 -0700 (PDT) Received: from [192.168.5.97] ([12.207.17.3]) by mx.google.com with ESMTPSA id ic7sm101141pbc.70.2015.04.10.16.08.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Apr 2015 16:08:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0F615331-92BC-463E-A774-5D341C7656B1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Fri, 10 Apr 2015 16:08:21 -0700 Message-Id: References: To: isciurus X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New header "Fragment-Scope" to prevent assertions leakage through redirects X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:08:29 -0000 --Apple-Mail=_0F615331-92BC-463E-A774-5D341C7656B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, I have tried to document the response headers that can help stop leaking = referrer.=20 Being able to do the same thing to stop fragment leaking would be a good = thing. If the W3C adds that then I would add it to our recommendations. =20 In the Interim without browser support we may need to look at other = methods to pass tokens to clients in the browser. I am certainly interested in tracking your proposal. John B. > On Apr 10, 2015, at 4:00 PM, isciurus wrote: >=20 > Hi, >=20 > One of the recent drafts = https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html = = was brought to my attention. Regarding the part "2.2. Security = Compromise: The Authorization Server As Open Redirector": >=20 > The legitimate OAuth Authorization response will include an access = token in the URI fragment. > Most web browsers will append the fragment to the URI sent in the = location header of a 302 response if no fragment is included in the = location URI. > =20 > This browser behaviour with a url fragment reattaching is indeed used = widely in attacks on OAuth (for example, one of the recent on the = bitcoin exchange = http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.html = ) = and I am also aware of one attack on OpenID 2 implementation leaking a = valid signature using the same technique. > We are trying to propose a browser-level protection from sensitive url = fragment data reattach on cross-domain redirects: = http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html = > A new header in the AS response would also block fragment reattach in = the following scenario: > =20 > https://AUTHORIZATION_SERVER/authorize?response_type=3Dtoken = > &client_id=3Dgood-client&scope=3DVALID_SCOPE > &redirect_uri=3Dhttps%3A%2F%2AUTHORIZATION_SERVER%Fauthorize > %3Fresponse_type%3Dcode > %26client_id%3Dattacker-client-id > %26scope%3DINVALID_SCOPE > %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com > =20 > But it would additionally block exploitation of vulnerable clients = which have open redirects on their domains and don't whitelist their = redirect_uri: > =20 > https://AUTHORIZATION_SERVER/authorize?response_type=3Dtoken = > &client_id=3Dgood-client&scope=3DVALID_SCOPE > &redirect_uri=3Dhttps%3A%2F%2good-client.com = %Fopen_redirect > %3Furl%3Dhttps%253A%252F%252Fattacker.com > =20 > This can improve the situation with already deployed clients in large = scale. Let me know if this proposal is interesting to the OAuth WG. >=20 > Thanks, > Andrey > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_0F615331-92BC-463E-A774-5D341C7656B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks,

I = have tried to document the response headers that can help stop leaking = referrer. 

Being able to do the same thing to stop fragment leaking = would be a good thing.

If the W3C adds that then I would add it to our = recommendations.  

In the Interim without browser support we may need to look at = other methods to pass tokens to clients in the browser.

I am certainly = interested in tracking your proposal.

John B.

On = Apr 10, 2015, at 4:00 PM, isciurus <isciurus@gmail.com> = wrote:

Hi,

One of the recent drafts https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-0= 1.html was brought to my attention. Regarding the part "2.2. = Security Compromise: The Authorization Server As Open = Redirector":

    The legitimate OAuth Authorization response = will include an access token in the URI fragment.
    Most web browsers will append the fragment to = the URI sent in the location header of a 302 response if no fragment is = included in the location URI.
  =   
This browser behaviour with a url = fragment reattaching is indeed used widely in attacks on OAuth (for = example, one of the recent on the bitcoin exchange http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.h= tml) and I am also aware of one attack on OpenID 2 implementation = leaking a valid signature using the same technique.
We are trying to propose a browser-level protection from = sensitive url fragment data reattach on cross-domain redirects: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/006= 6.html
A new header in the AS response would = also block fragment reattach in the following scenario:
  
  https://AUTHORIZATION_SERVER/authorize?response_type=3Dtoken
  = &client_id=3Dgood-client&scope=3DVALID_SCOPE
  = &redirect_uri=3Dhttps%3A%2F%2AUTHORIZATION_SERVER%Fauthorize
  %3Fresponse_type%3Dcode
  = %26client_id%3Dattacker-client-id
  = %26scope%3DINVALID_SCOPE
  = %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com
  
But it would additionally = block exploitation of vulnerable clients which have open redirects on = their domains and don't whitelist their redirect_uri:
  
  https://AUTHORIZATION_SERVER/authorize?response_type=3Dtoken
  = &client_id=3Dgood-client&scope=3DVALID_SCOPE
  &redirect_uri=3Dhttps%3A%2F%2good-client.com%Fopen_redirect
 = %3Furl%3Dhttps%253A%252F%252Fattacker.com
  
This can improve the = situation with already deployed clients in large scale. Let me know if = this proposal is interesting to the OAuth WG.

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

= --Apple-Mail=_0F615331-92BC-463E-A774-5D341C7656B1-- From nobody Fri Apr 10 16:38:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BFD1A9039 for ; Fri, 10 Apr 2015 16:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnOLYvFFDN55 for ; Fri, 10 Apr 2015 16:38:09 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 71E9D1A903F for ; Fri, 10 Apr 2015 16:37:45 -0700 (PDT) Received: by igblo3 with SMTP id lo3so9971467igb.0 for ; Fri, 10 Apr 2015 16:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wXFKa0mRXNiT6uv+dudQxvb1eVdLYxZdakyrMyhNpUs=; b=mjYoVTt++Wtrj8Z+fwqfPGWnpbEfSbkko7Ufofo/MCEg/jO2gS5R34TVmxUL9wGWev OsIt6klot5fFeMDZPiT/TP1O4+8YyvyCncpDMNDiFkP4/53azGS/LTI6MO9mkjPDucPl 9JmWa8A3hyl9O48b0qC3YohhApLFuh8zDHa3kLXJcilibQH8AiIEpUIoxmSTPk3x0Wjh BdVZF1OK9AWhQh8jRPg+/QKUhu5q8Q2aSmQLZCoPByEJT9yQg1Jnt1FD6t6ljfshNP6l ilQmKwi6uswyzIUowvfl87WXvOfSiyCq6seAclHq2yLbjQ3mQ0FGjrkenCgyUowYI8EP okHw== X-Received: by 10.50.43.136 with SMTP id w8mr1815302igl.26.1428709064941; Fri, 10 Apr 2015 16:37:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.2.202 with HTTP; Fri, 10 Apr 2015 16:37:24 -0700 (PDT) In-Reply-To: References: From: isciurus Date: Fri, 10 Apr 2015 16:37:24 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e011602a84daa020513674039 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] New header "Fragment-Scope" to prevent assertions leakage through redirects X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:38:12 -0000 --089e011602a84daa020513674039 Content-Type: text/plain; charset=UTF-8 I would also be interested to know about the possible response headers for referrer (a draft?). Last time we brainstormed the problem with Brad Hill we thought it could break something with search engines flow and referrer policy. > I have tried to document the response headers that can help stop leaking referrer. On Fri, Apr 10, 2015 at 4:08 PM, John Bradley wrote: > Thanks, > > I have tried to document the response headers that can help stop leaking > referrer. > > Being able to do the same thing to stop fragment leaking would be a good > thing. > > If the W3C adds that then I would add it to our recommendations. > > In the Interim without browser support we may need to look at other > methods to pass tokens to clients in the browser. > > I am certainly interested in tracking your proposal. > > John B. > > On Apr 10, 2015, at 4:00 PM, isciurus wrote: > > Hi, > > One of the recent drafts > https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html was > brought to my attention. Regarding the part "2.2. Security Compromise: The > Authorization Server As Open Redirector": > > The legitimate OAuth Authorization response will include an access > token in the URI fragment. > Most web browsers will append the fragment to the URI sent in the > location header of a 302 response if no fragment is included in the > location URI. > > This browser behaviour with a url fragment reattaching is indeed used > widely in attacks on OAuth (for example, one of the recent on the bitcoin > exchange > http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.html) and I > am also aware of one attack on OpenID 2 implementation leaking a valid > signature using the same technique. > We are trying to propose a browser-level protection from sensitive url > fragment data reattach on cross-domain redirects: > http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html > A new header in the AS response would also block fragment reattach in the > following scenario: > > https://AUTHORIZATION_SERVER/authorize?response_type=token > > &client_id=good-client&scope=VALID_SCOPE > &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize > %3Fresponse_type%3Dcode > %26client_id%3Dattacker-client-id > %26scope%3DINVALID_SCOPE > %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com > > But it would additionally block exploitation of vulnerable clients which > have open redirects on their domains and don't whitelist their redirect_uri: > > https://AUTHORIZATION_SERVER/authorize?response_type=token > > &client_id=good-client&scope=VALID_SCOPE > &redirect_uri=https%3A%2F%2good-client.com%Fopen_redirect > %3Furl%3Dhttps%253A%252F%252Fattacker.com > > This can improve the situation with already deployed clients in large > scale. Let me know if this proposal is interesting to the OAuth WG. > > Thanks, > Andrey > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --089e011602a84daa020513674039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would also be interested to know about the possible= response headers for referrer (a draft?). Last time we brainstormed the pr= oblem with Brad Hill we thought it could break something with search engine= s flow and referrer policy.

>=C2=A0I have tried to document the response headers t= hat can help stop leaking referrer.=C2=A0

On Fri, Apr 10, 2015 at 4:08 PM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks,

I= have tried to document the response headers that can help stop leaking ref= errer.=C2=A0

Being able to do the same thing to st= op fragment leaking would be a good thing.

If the = W3C adds that then I would add it to our recommendations. =C2=A0
=
In the Interim without browser support we may need to look a= t other methods to pass tokens to clients in the browser.

I am certainly interested in tracking your proposal.

=
John B.

On Apr 10, 2015, at 4:00 PM, isciurus <isciurus@gmail.com> wrote:
Hi,

One of the recent drafts h= ttps://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html wa= s brought to my attention. Regarding the part "2.2. Security Compromis= e: The Authorization Server As Open Redirector":

<= div>=C2=A0 =C2=A0 The legitimate OAuth Authorization response will include = an access token in the URI fragment.
=C2=A0 =C2=A0 Most web brows= ers will append the fragment to the URI sent in the location header of a 30= 2 response if no fragment is included in the location URI.
=C2=A0= =C2=A0=C2=A0
This browser behaviour with a url fragment reattach= ing is indeed used widely in attacks on OAuth (for example, one of the rece= nt on the bitcoin exchange http://sakurity.com/blog/2= 015/01/10/hacking-bitcoin-exchanger.html) and I am also aware of one at= tack on OpenID 2 implementation leaking a valid signature using the same te= chnique.
We are trying to propose a browser-level protection from= sensitive url fragment data reattach on cross-domain redirects: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/= 0066.html
A new header in the AS response would also block fr= agment reattach in the following scenario:
=C2=A0=C2=A0
=C2=A0 https://AUTHORIZATION_SERVER/authorize?response_typ= e=3Dtoken
=C2=A0 &client_id=3Dgood-client&scope=3DVAL= ID_SCOPE
=C2=A0 &redirect_uri=3Dhttps%3A%2F%2AUTHORIZATION_SE= RVER%Fauthorize
=C2=A0 %3Fresponse_type%3Dcode
=C2=A0 %= 26client_id%3Dattacker-client-id
=C2=A0 %26scope%3DINVALID_SCOPE<= /div>
=C2=A0 %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com
=C2=A0=C2=A0
But it would additionally block exploitation of vulnerable clients= which have open redirects on their domains and don't whitelist their r= edirect_uri:
=C2=A0=C2=A0
=C2=A0= &client_id=3Dgood-client&scope=3DVALID_SCOPE
=C2=A0 &= ;redirect_uri=3Dhttps%3A%2F%2good-client.com%Fopen_redirect
=C2=A0 %3Furl%3Dhttps= %253A%252F%252Fattack= er.com
=C2=A0=C2=A0
This can improve the situation = with already deployed clients in large scale. Let me know if this proposal = is interesting to the OAuth WG.

Thanks,
= Andrey
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

--089e011602a84daa020513674039-- From nobody Sun Apr 12 06:29:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D961ACCED for ; Sun, 12 Apr 2015 06:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2WcVmPU5TvN for ; Sun, 12 Apr 2015 06:29:16 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 A33F01ACCEC for ; Sun, 12 Apr 2015 06:29:16 -0700 (PDT) Received: by iggg4 with SMTP id g4so27884040igg.0 for ; Sun, 12 Apr 2015 06:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hHR+ElP3RomDnPVn34k4KoI8OvaAXZDz8e4/BnoxihA=; b=xz2vzeNVzN1wh1sXZE1jAFKUoZZyk6Pkv6Yu65cjp0xP/H6e827ZDoWrD7LmcFwRlI uPeS6m2kzsBmkmNhM/8YGeGruFnf0LH3q5xkV+m4dW0X0OqwcU4mefSBVR+sucSkkXXe 0pp1z9KKAUFar1+99DFxLcmgYwPPP0jQSrEs9BpwHa+c492B0XkW7EOBl0FP8MmOus4r kxY7FHflu68m2gYfPecwT5dfsCHfD8BAS4aDL8WBBFT66Rd2XZoOfRwxK6xkQK0ShQnM hpHHUDFjZznIc2vgssXdIF/4Xs05zGMH5F9a3/35HXn+aqaRCglxD/txA+noPgQk0vDN ZWLA== MIME-Version: 1.0 X-Received: by 10.50.64.244 with SMTP id r20mr10354211igs.48.1428845356126; Sun, 12 Apr 2015 06:29:16 -0700 (PDT) Received: by 10.50.131.233 with HTTP; Sun, 12 Apr 2015 06:29:16 -0700 (PDT) Date: Sun, 12 Apr 2015 14:29:16 +0100 Message-ID: From: Spencer MacDonald To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7bea3d22e4191d051386fb6a Archived-At: Subject: [OAUTH-WG] Grant Type to Login via another Provider's OAuth Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 13:29:18 -0000 --047d7bea3d22e4191d051386fb6a Content-Type: text/plain; charset=UTF-8 Hi, I wondered if there was a best practise/standard/extension grant type for exchanging an OAuth Token from another provider (instead of a username and password) for an OAuth Token. The situation I am facing is that I am developing a native iOS application that makes use of the Facebook Graph API, whereby I fetch an OAuth Token using their native SDK on the device. I then want to login exchange their Facebook OAuth Token with my server (the OAuth Token is then used on the server to process data) in exchange for an OAuth Token to communicate with my server. Is there a best practise for this approach? Regards Spencer --047d7bea3d22e4191d051386fb6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I wondered if there was a best prac= tise/standard/extension grant type for exchanging an OAuth Token from anoth= er provider (instead of a username and password) for an OAuth Token.
<= div>
The situation I am facing is that I am developing a nati= ve iOS application that makes use of the Facebook Graph API, whereby I fetc= h an OAuth Token using their native SDK on the device. I then want to login= exchange their Facebook OAuth Token with my server (the OAuth Token is the= n used on the server to process data) in exchange for an OAuth Token to com= municate with my server.

Is there a best practise = for this approach?

Regards

Spencer --047d7bea3d22e4191d051386fb6a-- From nobody Sun Apr 12 09:16:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D11B2A33 for ; Sun, 12 Apr 2015 09:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au2acHNWzT-c for ; Sun, 12 Apr 2015 09:16:51 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 6F01B1A09C9 for ; Sun, 12 Apr 2015 09:16:51 -0700 (PDT) Received: by qkhg7 with SMTP id g7so132679881qkh.2 for ; Sun, 12 Apr 2015 09:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+eoWLGNPVGdIqzxuO82Kag1oRQ6scN8XhSv6YSp3Q9o=; b=GfVRCB/U/DBFU5jbvHEnnmzERuzi2DCHAl3vSROJfQXhIxof4MjeE05GZP5ugyOS5H PH8+V4BmQyMXBvrOOYAjBCAew0NG/Z8I90O9VUZyX8ZeLSnE6a7q5A2JqG+fjEq4YmjM Dvz1DjqHS1+VLIDtslVhZUtKdOu0m08YlRmQUYqJW1v/7OoocIidy+eAei7jjtyObKUo ELNsrUY80Ow5Zo8V5n9tl0vhbsUkctJiaOeI8SP2m5LnSn1xDkwzZDeZoxxpA9EINxkd hlXA3UDREUqBqzrIf4j1zRLCFJ45UQA3ffBEH9Zw45/hqRyrZv6CK1cJqSQdtFA14oJ/ yzIQ== MIME-Version: 1.0 X-Received: by 10.60.148.225 with SMTP id tv1mr6682976oeb.14.1428855410601; Sun, 12 Apr 2015 09:16:50 -0700 (PDT) Received: by 10.60.141.226 with HTTP; Sun, 12 Apr 2015 09:16:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Apr 2015 01:16:50 +0900 Message-ID: From: Nat Sakimura To: Spencer MacDonald Content-Type: multipart/alternative; boundary=047d7b3a7f7e2f395605138953a2 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Grant Type to Login via another Provider's OAuth Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 16:16:53 -0000 --047d7b3a7f7e2f395605138953a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable the best practice to log the user in general is to use IpenID Connect. For Facebook specifically, there is a closely related spec called signed request. You cannot just use a regular access token to log a user in. It's too dangerous. Nat via iPhone 2015=E5=B9=B44=E6=9C=8812=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5=E3=80=81Spenc= er MacDonald=E3=81=95=E3=82=93=E3=81=AF= =E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F: > Hi, > > I wondered if there was a best practise/standard/extension grant type for > exchanging an OAuth Token from another provider (instead of a username an= d > password) for an OAuth Token. > > The situation I am facing is that I am developing a native iOS applicatio= n > that makes use of the Facebook Graph API, whereby I fetch an OAuth Token > using their native SDK on the device. I then want to login exchange their > Facebook OAuth Token with my server (the OAuth Token is then used on the > server to process data) in exchange for an OAuth Token to communicate wit= h > my server. > > Is there a best practise for this approach? > > Regards > > Spencer > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b3a7f7e2f395605138953a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable the best practice to log the user in general=C2=A0is to use IpenID Connect.= =C2=A0

For Facebook specifically, there is a closely rel= ated spec called signed request.=C2=A0

You cannot just use a regular access token to log a user in. It's too= dangerous.=C2=A0

Nat via iPhone

2015=E5=B9= =B44=E6=9C=8812=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5=E3=80=81Spencer MacDona= ld<spencer.macdonal= d.other@gmail.com>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3= =81=BE=E3=81=97=E3=81=9F:
Hi,

I wondered if there was a best practise/standard/e= xtension grant type for exchanging an OAuth Token from another provider (in= stead of a username and password) for an OAuth Token.

<= div>The situation I am facing is that I am developing a native iOS applicat= ion that makes use of the Facebook Graph API, whereby I fetch an OAuth Toke= n using their native SDK on the device. I then want to login exchange their= Facebook OAuth Token with my server (the OAuth Token is then used on the s= erver to process data) in exchange for an OAuth Token to communicate with m= y server.

Is there a best practise for this approa= ch?

Regards

Spencer
=


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

--047d7b3a7f7e2f395605138953a2-- From nobody Sun Apr 12 09:41:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3639B1B2A96 for ; Sun, 12 Apr 2015 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gioJABb6x9zW for ; Sun, 12 Apr 2015 09:41:16 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC061B2A94 for ; Sun, 12 Apr 2015 09:41:15 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-93-552aa02ac93e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 46.7B.03700.A20AA255; Sun, 12 Apr 2015 12:41:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t3CGfD11017766; Sun, 12 Apr 2015 12:41:13 -0400 Received: from [10.61.200.11] ([216.124.63.141]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3CGfBMN015198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Apr 2015 12:41:12 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CFACC244-5426-4DDD-898A-A52EA2CCE169"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: Date: Sun, 12 Apr 2015 11:41:10 -0500 Message-Id: <3D1E24E1-867B-4135-B13B-066309117CCD@mit.edu> References: To: Spencer MacDonald X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPKsWRmVeSWpSXmKPExsUixCmqrau1QCvU4FynoMXJt6/YLJofHmZ2 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIOTE8tOGNScbN5D1sD41fdLkZODgkBE4m/ G84yQthiEhfurWfrYuTiEBJYzCTRcXcPC0hCSGAjo0TrkiCIxFomiUWr37GBJIQF/CRmL78M VsQrYCAx99QXJpAiZoEpjBJT3y5kgRgrJdH0+hjYCjYBVYnpa1qYQGxOgUCJtds+sYPYLEDx w2sPA9kcQM3qEu0nXSBmWkm0f/zDDHFEgMSO1j6wVhEBS4nlB98ygpRLCMhL9GxKn8AoOAvJ FbOQXQGSYBZIkliypJUZwtaWWLbwNZStKbG/ezkLpriGROe3iawQtrzE9rdzoOKWEotn3oCq t5W41beACcK2k3g0bRHrAkbuVYyyKblVurmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWbGEHx x+6ivIPxz0GlQ4wCHIxKPLwXfmuGCrEmlhVX5h5ilORgUhLljS3VChXiS8pPqcxILM6ILyrN SS0+xKgCtOvRhtUXGKVY8vLzUpVEeGfMA6rjTUmsrEotyocpk+ZgURLn3fSDL0RIID2xJDU7 NbUgtQgmq8HBIdC3BmGIBG8dyBDBotT01Iq0zJwShFImDs5DjBIcPECLToItKi5IzC3OTIfI n2JUlBLnfQKSEABJZJTmwfXC0ukrRnGgF4V5H4BU8QBTMVz3K6DBTECDs1TABpckIqSkGhib F+66qcYyxc71EtPbJ9ufSyjWba1vd/j6wHa1/7HujZ+1SyV3bslYF892XGTRDq3nerI+DzZt kplxsXJ26fSNM+2S3Wt9PUOt5i4s/+W6qYBr/hSeuUWO0inzrsUZT1CMlTnYH9qxJqRLyG+V +Q6eAz+mqHb9i1rs66K779vx2PstuWovv35UYinOSDTUYi4qTgQAJP51ZoIDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Grant Type to Login via another Provider's OAuth Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 16:41:18 -0000 --Apple-Mail=_CFACC244-5426-4DDD-898A-A52EA2CCE169 Content-Type: multipart/alternative; boundary="Apple-Mail=_B0ECBE10-87CB-460F-BE24-BC16876AF7D6" --Apple-Mail=_B0ECBE10-87CB-460F-BE24-BC16876AF7D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You can=E2=80=99t rely on the presence of an access token to log a user = in. Some more information is available here: http://oauth.net/articles/authentication/ = However, if you want to bridge authorization based on an external token = and you=E2=80=99re willing to do some validation of that token, you can = use something like the draft token chaining mechanism defined here: https://tools.ietf.org/html/draft-richer-oauth-chain-00 = For this, your AS will basically take in a Facebook token, validate it, = and spit out a domain-local token. This doesn=E2=80=99t, however, tell you much about someone being = =E2=80=9Clogged in=E2=80=9D from Facebook, just means you=E2=80=99ve got = an authorized application. Again, see the oauth.net = article for more details on common pitfalls. A standards-based way to do login is to use the OpenID Connect ID Token. =E2=80=94 Justin > On Apr 12, 2015, at 8:29 AM, Spencer MacDonald = wrote: >=20 > Hi, >=20 > I wondered if there was a best practise/standard/extension grant type = for exchanging an OAuth Token from another provider (instead of a = username and password) for an OAuth Token. >=20 > The situation I am facing is that I am developing a native iOS = application that makes use of the Facebook Graph API, whereby I fetch an = OAuth Token using their native SDK on the device. I then want to login = exchange their Facebook OAuth Token with my server (the OAuth Token is = then used on the server to process data) in exchange for an OAuth Token = to communicate with my server. >=20 > Is there a best practise for this approach? >=20 > Regards >=20 > Spencer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B0ECBE10-87CB-460F-BE24-BC16876AF7D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You can=E2=80=99t rely on the presence of an access token to = log a user in. Some more information is available here:
http://oauth.net/articles/authentication/

However, if you want to = bridge authorization based on an external token and you=E2=80=99re = willing to do some validation of that token, you can use something like = the draft token chaining mechanism defined here:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

For this, your AS = will basically take in a Facebook token, validate it, and spit out a = domain-local token.

This doesn=E2=80=99t, however, tell you much about someone = being =E2=80=9Clogged in=E2=80=9D from Facebook, just means you=E2=80=99ve= got an authorized application. Again, see the oauth.net article for more = details on common pitfalls. 

A standards-based way to do login is to = use the OpenID Connect ID Token.

 =E2=80=94 Justin

On Apr 12, 2015, at 8:29 AM, Spencer MacDonald <spencer.macdonald.other@gmail.com> wrote:

Hi,

I wondered if there was a best = practise/standard/extension grant type for exchanging an OAuth Token = from another provider (instead of a username and password) for an OAuth = Token.

The = situation I am facing is that I am developing a native iOS application = that makes use of the Facebook Graph API, whereby I fetch an OAuth Token = using their native SDK on the device. I then want to login exchange = their Facebook OAuth Token with my server (the OAuth Token is then used = on the server to process data) in exchange for an OAuth Token to = communicate with my server.

Is there a best practise for this approach?

Regards

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

= --Apple-Mail=_B0ECBE10-87CB-460F-BE24-BC16876AF7D6-- --Apple-Mail=_CFACC244-5426-4DDD-898A-A52EA2CCE169 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVKqAmAAoJEDPAngkbd+w9VIAIAIcIdx6b9FbuQUBI1VYaXAE5 SqkzA8ov+fuBnUR9zO71e+etV3giRiUNCHin3YAhTb+lpCLozpF5tFhzDfXbZ34a 5ChQfepYR7XwxfFNutO4mE0jHQGLcAtyNBN29rGlJhRBBBgLOpHpkaKvgBog7eAb SJbb13f+5V9jK/23384Bg0omO3cw7sXi/rsVrn5yFsuwTN3q7pUQBOekN6Ta+WO8 PyOfF5LOH/4Ck1PeL/FZFTEuJw6hynI8NoPy2aD6j8eb/0rYpgSw0RCMoP/PJEfg v9zJaEuXPcJleDheSBSPVh430Y19MZ8DD4NMlR5U9DyDFNL5oQU2oC+aLPajJdE= =lWaH -----END PGP SIGNATURE----- --Apple-Mail=_CFACC244-5426-4DDD-898A-A52EA2CCE169-- From nobody Mon Apr 13 07:28:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61991AC3C5 for ; Mon, 13 Apr 2015 07:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BknNnk-oW0Np for ; Mon, 13 Apr 2015 07:28:38 -0700 (PDT) Received: from mail-ie0-f174.google.com (na3sys009aog117.obsmtp.com [74.125.149.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC071AC3B6 for ; Mon, 13 Apr 2015 07:28:37 -0700 (PDT) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKVSvSlfoseqtR2YVWIfiAwomZI7cl7nms@postini.com; Mon, 13 Apr 2015 07:28:38 PDT Received: by iejt8 with SMTP id t8so65822208iej.2 for ; Mon, 13 Apr 2015 07:28:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T5eZ7hQAp9ommSx5M+TiIp2KbKcKoe85Diz9CSep+Vs=; b=Lk1ZKY9GVB3lcKTdC4+MFdTYPEsBZ/Zy3bTAZ31hWiH4xfiCeonPCyQQVr20nEjyeX W5hU16W29e2TOyN+WmVBhs6ej549dOvhsQXLgkPj27rsYd0HQCtHCKYMdrD2VK39Z0aF 5ORcTOhAhvjphKMBrs80B9QGDBWprWTBrttoWT5jrhA2oAQJ1u7LDzTeDNxS6L9pRo4X jwSCw78Douzv4KhUe/tY9HRANRN0Et9wVoskcBIrYMRLCw7GP6hlAangNopSqqbmhV8h +PBIXDFmpvvGvkWwRwEiBdbm1xpmTTPVSEoih5RM0kXkJz5nyJhDgf/mbm9llXHOfsTz Rmmg== X-Gm-Message-State: ALoCoQlwYBK6GSN8/Z/iuUL+SXjIX/eo9x1wvA16KT4+PX1P5qjEFBRvkIqeRYQmVkLBVhds4pFaRW906aXnvhrDGoaFxHeaJTpDvQAq7SyxjKO9uF01Q6aEVUSv6/LaqFIiOYNeBSUk X-Received: by 10.50.65.40 with SMTP id u8mr7774303igs.40.1428935316767; Mon, 13 Apr 2015 07:28:36 -0700 (PDT) X-Received: by 10.50.65.40 with SMTP id u8mr7774284igs.40.1428935316610; Mon, 13 Apr 2015 07:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.15 with HTTP; Mon, 13 Apr 2015 07:28:06 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 13 Apr 2015 08:28:06 -0600 Message-ID: To: isciurus Content-Type: multipart/alternative; boundary=047d7b41417cf4860405139bed84 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] New header "Fragment-Scope" to prevent assertions leakage through redirects X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 14:28:40 -0000 --047d7b41417cf4860405139bed84 Content-Type: text/plain; charset=UTF-8 I'm hardly speaking with any authority here but my hope/expectation is that using Origin Only for the Referrer Policy would provide enough info in the referer (the origin) so as to not break search engines flows or other analytics that are using data from the referer header. The referring domain is provided, which is useful data, but without there query or path that often leaks sensitive data or tokens. https://w3c.github.io/webappsec/specs/referrer-policy/ or http://www.w3.org/TR/referrer-policy/ is the work in progress on Referrer Policy. On Fri, Apr 10, 2015 at 5:37 PM, isciurus wrote: > I would also be interested to know about the possible response headers for > referrer (a draft?). Last time we brainstormed the problem with Brad Hill > we thought it could break something with search engines flow and referrer > policy. > > > I have tried to document the response headers that can help stop > leaking referrer. > > On Fri, Apr 10, 2015 at 4:08 PM, John Bradley wrote: > >> Thanks, >> >> I have tried to document the response headers that can help stop leaking >> referrer. >> >> Being able to do the same thing to stop fragment leaking would be a good >> thing. >> >> If the W3C adds that then I would add it to our recommendations. >> >> In the Interim without browser support we may need to look at other >> methods to pass tokens to clients in the browser. >> >> I am certainly interested in tracking your proposal. >> >> John B. >> >> On Apr 10, 2015, at 4:00 PM, isciurus wrote: >> >> Hi, >> >> One of the recent drafts >> https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html >> was brought to my attention. Regarding the part "2.2. Security Compromise: >> The Authorization Server As Open Redirector": >> >> The legitimate OAuth Authorization response will include an access >> token in the URI fragment. >> Most web browsers will append the fragment to the URI sent in the >> location header of a 302 response if no fragment is included in the >> location URI. >> >> This browser behaviour with a url fragment reattaching is indeed used >> widely in attacks on OAuth (for example, one of the recent on the bitcoin >> exchange >> http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.html) and >> I am also aware of one attack on OpenID 2 implementation leaking a valid >> signature using the same technique. >> We are trying to propose a browser-level protection from sensitive url >> fragment data reattach on cross-domain redirects: >> http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html >> A new header in the AS response would also block fragment reattach in the >> following scenario: >> >> https://AUTHORIZATION_SERVER/authorize?response_type=token >> >> &client_id=good-client&scope=VALID_SCOPE >> &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize >> %3Fresponse_type%3Dcode >> %26client_id%3Dattacker-client-id >> %26scope%3DINVALID_SCOPE >> %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com >> >> But it would additionally block exploitation of vulnerable clients which >> have open redirects on their domains and don't whitelist their redirect_uri: >> >> https://AUTHORIZATION_SERVER/authorize?response_type=token >> >> &client_id=good-client&scope=VALID_SCOPE >> &redirect_uri=https%3A%2F%2good-client.com%Fopen_redirect >> %3Furl%3Dhttps%253A%252F%252Fattacker.com >> >> This can improve the situation with already deployed clients in large >> scale. Let me know if this proposal is interesting to the OAuth WG. >> >> Thanks, >> Andrey >> _______________________________________________ >> 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 > > --047d7b41417cf4860405139bed84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm hardly speaking with any authority here but my hop= e/expectation is that using Origin Only for the Referrer Policy would provi= de enough info in the referer (the origin) so as to not break search engin= es flows or other analytics that are using data from the referer header. Th= e referring domain is provided, which is useful data, but without there que= ry or path that often leaks sensitive data or tokens.

http= s://w3c.github.io/webappsec/specs/referrer-policy/ or http://www.w3.org/TR/ref= errer-policy/ is the work in progress on Referrer Policy.



On Fri= , Apr 10, 2015 at 5:37 PM, isciurus <isciurus@gmail.com> wr= ote:
I would also b= e interested to know about the possible response headers for referrer (a dr= aft?). Last time we brainstormed the problem with Brad Hill we thought it c= ould break something with search engines flow and referrer policy.

>=C2=A0I have tried to document the response headers that can help stop l= eaking referrer.=C2=A0

On Fri, A= pr 10, 2015 at 4:08 PM, John Bradley <ve7jtb@ve7jtb.com> wro= te:
T= hanks,

I have tried to document the response headers tha= t can help stop leaking referrer.=C2=A0

Being able= to do the same thing to stop fragment leaking would be a good thing.
=

If the W3C adds that then I would add it to our recomme= ndations. =C2=A0

In the Interim without browser su= pport we may need to look at other methods to pass tokens to clients in the= browser.

I am certainly interested in tracking yo= ur proposal.

John B.

On Apr 10, 2015, at 4:00 PM, isciurus <isciurus@gmail.com> wrote:

Hi,<= /div>

One of the recent drafts = https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html w= as brought to my attention. Regarding the part "2.2. Security Compromi= se: The Authorization Server As Open Redirector":

=
=C2=A0 =C2=A0 The legitimate OAuth Authorization response will include= an access token in the URI fragment.
=C2=A0 =C2=A0 Most web brow= sers will append the fragment to the URI sent in the location header of a 3= 02 response if no fragment is included in the location URI.
=C2= =A0 =C2=A0=C2=A0
This browser behaviour with a url fragment reatt= aching is indeed used widely in attacks on OAuth (for example, one of the r= ecent on the bitcoin exchange http://sakurity.com/blo= g/2015/01/10/hacking-bitcoin-exchanger.html) and I am also aware of one= attack on OpenID 2 implementation leaking a valid signature using the same= technique.
We are trying to propose a browser-level protection f= rom sensitive url fragment data reattach on cross-domain redirects: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanM= ar/0066.html
A new header in the AS response would also block= fragment reattach in the following scenario:
=C2=A0=C2=A0
<= div>=C2=A0 https://AUTHORIZATION_SERVER/authorize?response= _type=3Dtoken
=C2=A0 &client_id=3Dgood-client&scope= =3DVALID_SCOPE
=C2=A0 &redirect_uri=3Dhttps%3A%2F%2AUTHORIZAT= ION_SERVER%Fauthorize
=C2=A0 %3Fresponse_type%3Dcode
= =C2=A0 %26client_id%3Dattacker-client-id
=C2=A0 %26scope%3DINVALI= D_SCOPE
=C2=A0 %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com
=C2=A0= =C2=A0
But it would additionally block exploitation of vulnerable= clients which have open redirects on their domains and don't whitelist= their redirect_uri:
=C2=A0=C2=A0
=C2=A0 &client_id=3Dgood-client&scope=3DVALID_SCOPE
=C2= =A0 &redirect_uri=3Dhttps%3A%2F%2good-client.com%Fopen_redirect
=C2=A0 %3Furl= %3Dhttps%253A%252F%25= 2Fattacker.com
=C2=A0=C2=A0
This can improve the si= tuation with already deployed clients in large scale. Let me know if this p= roposal is interesting to the OAuth WG.

Thanks,
Andrey
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth


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


--047d7b41417cf4860405139bed84-- From nobody Mon Apr 13 07:58:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22211ACC83; Mon, 13 Apr 2015 07:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAikQ4YYqWfF; Mon, 13 Apr 2015 07:57:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 779051ACC8A; Mon, 13 Apr 2015 07:57:57 -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: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413145757.2109.78040.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 07:57:57 -0700 Archived-At: Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org Subject: [OAUTH-WG] IPR Disclosure Kirsten Aldrich's Statement about IPR related to RFC 6750 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 14:58:00 -0000 Dear Michael Jones, Dick Hardt: An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 Authorization Framework: Bearer Token Usage" (RFC6750) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2572/). The title of the IPR disclosure is "Kirsten Aldrich's Statement about IPR related to RFC 6750" Thank you IETF Secretariat From nobody Tue Apr 14 06:05:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4811A908D for ; Tue, 14 Apr 2015 06:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGVZnM9BA5KD for ; Tue, 14 Apr 2015 06:05:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F501A90A6 for ; Tue, 14 Apr 2015 06:05:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414130537.23759.28826.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 06:05:37 -0700 From: IETF Secretariat Archived-At: Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:05:39 -0000 Changed milestone "Submit 'OAuth 2.0 Dynamic Client Registration Management Protocol' to the IESG for consideration as an Experimental RFC", resolved as "Done". Changed milestone "Submit 'Symmetric Proof of Possession (SPOP) for the OAuth Authorization Code Grant' to the IESG for consideration as a Proposed Standard", resolved as "Done". URL: http://datatracker.ietf.org/wg/oauth/charter/ From nobody Tue Apr 14 06:06:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC31A90A6 for ; Tue, 14 Apr 2015 06:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX2W67Nx7eaV for ; Tue, 14 Apr 2015 06:06:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D3A1A90B5 for ; Tue, 14 Apr 2015 06:06:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414130637.14561.40282.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 06:06:37 -0700 From: IETF Secretariat Archived-At: Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:06:46 -0000 Changed milestone "Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard", set due date to August 2015 from May 2015. Changed milestone "Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard", set due date to September 2015 from March 2015. Changed milestone "Submit 'Proof-of-Possession OAuth Security' document bundle for consideration as a Proposed Standard", set due date to October 2015 from April 2015. URL: http://datatracker.ietf.org/wg/oauth/charter/ From nobody Tue Apr 14 14:25:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F6F1A1AC6 for ; Tue, 14 Apr 2015 14:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c431oVZoHkWG for ; Tue, 14 Apr 2015 14:25:51 -0700 (PDT) Received: from mail-vn0-x235.google.com (mail-vn0-x235.google.com [IPv6:2607:f8b0:400c:c0f::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 C1E841A3B9C for ; Tue, 14 Apr 2015 14:21:17 -0700 (PDT) Received: by vnbg62 with SMTP id g62so8377729vnb.7 for ; Tue, 14 Apr 2015 14:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=yfIqb9dJInPY8IdFywBqusEnjDRSAl/Qo3tbiJPZv60=; b=h92Vk7q23aFwjSZRtDF2tN9+tjvc0h02rHLy3tA+LuO23sCCZtag71E8IM2WxAn9fp mTnBzOb37XI6scSYDNy3tlUh2VUqCiCaw48VBeOeXEP4xtTDGqqyfXmtAASEINKkmjzL f9D1ijDeSYoWERLKQBU38ty3yuhsGssBG5cFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=yfIqb9dJInPY8IdFywBqusEnjDRSAl/Qo3tbiJPZv60=; b=H81TeVa+tDPd0K0iZWBauMtmsciQLv0HqFZuOxcmwvYmLUDMDg0eOyXKo+RrwuNNAs Xt/9oSPvL2/zOpPN2WmtXsU+SFn8G7mYrvA8zbCqlwXxz8yW1S6CLITcVR24RUKbA9uY 9csQ2zfdQN4NTaZqdtvLRiiZBFkb6sRO1OBQF2ZotcdGk1Pa1nZGoB2mgsFZh8j+IKfo zwPycdGAtPslVceuKpuhWo9gAlXiiv2OYM4K5fzk7UCgc2ViMmTmfKACaXRW0m0z1tBM KaKNt+aDMXVIQ1rkHrLptyMbW3EFf6Uky7+4p6J8NMKwmymooE6KvcB928a7kjgcXw1+ ALEg== X-Gm-Message-State: ALoCoQkJJxiCa8IzwvK8AKddESlTc1rwosMBuomGX5AVneHVyQwxgz4FJk1XbtxOmhrVFb8/A/yF MIME-Version: 1.0 X-Received: by 10.182.22.167 with SMTP id e7mr17738238obf.31.1429046476908; Tue, 14 Apr 2015 14:21:16 -0700 (PDT) Received: by 10.202.72.198 with HTTP; Tue, 14 Apr 2015 14:21:16 -0700 (PDT) Date: Tue, 14 Apr 2015 14:21:16 -0700 Message-ID: From: Prabath Siriwardena To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11c2e0ba9fd38d0513b5cf87 Archived-At: Subject: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:25:54 -0000 --001a11c2e0ba9fd38d0513b5cf87 Content-Type: text/plain; charset=UTF-8 At the moment we only HTTP binding to transport the access token (please correct me if not).. This creates a dependency on the transport. How about creating a JWT binding for OAuth 2.0..? We can transport the access token as an encrypted JWT header parameter..? Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org --001a11c2e0ba9fd38d0513b5cf87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the moment we only HTTP binding to transport the access= token (please correct me if not)..

This creates a depen= dency on the transport.

How about creating a JWT b= inding for OAuth 2.0..? We can transport the access token as an encrypted J= WT header parameter..?


Thanks & Regards,
Prabath
Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriw= ardena

Mobile : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-securit= y.org
--001a11c2e0ba9fd38d0513b5cf87-- From nobody Tue Apr 14 14:42:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426751A1AFB for ; Tue, 14 Apr 2015 14:41:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH5DcskuAm3z for ; Tue, 14 Apr 2015 14:41:57 -0700 (PDT) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (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 28C8B1A1ADA for ; Tue, 14 Apr 2015 14:41:57 -0700 (PDT) Received: by qkhg7 with SMTP id g7so41600823qkh.2 for ; Tue, 14 Apr 2015 14:41:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wF4tfibdvnsrTkx5b5mnIXHNtcruetPCQ0dYg6Uftu0=; b=iYIQF1Xk+zBDk1CWLUqDINvRbpLt3ctIy1Wuf4XJmQdRzsStJTp3N1qarDkGBwcDzZ oAQQMYbg4O32x27i3ZZU+mLLsHE/zXDZJof5dwJllRBaRY2vzpyoaqSz8CtOoCBzraF2 LN+ahgPKkbJxPT+QhxsPx/cnk5+JUm5kFvZva/5tAzO/jiiDRvzn9u2drgyZQ72+gYM3 rkPdkk+7a2p8AiLI8nfzqELGm9+ja2w6fknbxZNGWVSNmBHHG0h4dsUBxKDtfB/W2pqO mIY+4JsllxakwWMrN2JIsgnBj0I9XwTmHfqAMWqlqIa0YcOYRHQNtizR2wfSD1JO9WEj AjsA== X-Gm-Message-State: ALoCoQk6icmjbD/m1WpX5GTdjWCWht/J9HvITl95DdQMIY2F61pTq2hdxnRN+H59FMbTGpAOzK8G X-Received: by 10.55.19.80 with SMTP id d77mr44450096qkh.92.1429047700534; Tue, 14 Apr 2015 14:41:40 -0700 (PDT) Received: from [192.168.1.216] (181-163-76-154.baf.movistar.cl. [181.163.76.154]) by mx.google.com with ESMTPSA id 186sm1668346qhd.11.2015.04.14.14.41.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Apr 2015 14:41:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3F2CDAAA-1362-4D09-9512-91AAE5F4FBDF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Tue, 14 Apr 2015 18:41:25 -0300 Message-Id: References: To: Prabath Siriwardena X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:41:59 -0000 --Apple-Mail=_3F2CDAAA-1362-4D09-9512-91AAE5F4FBDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is a OAuth binding to SASL = https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 = Google supports it for IMAP/SMTP, I think the latest iOS and OSX mail = client updates use it rather than passwords for Google. I also noticed Outlook on Android using it. The access token might be a signed or encrypted JWT itself. I don=E2=80=99= t know that wrapping it again necessarily helps. Yes we should have bindings to other non http protocols. =20 Is there something specific that you are looking for that is not covered = by SASL? John B. > On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena = wrote: >=20 > At the moment we only HTTP binding to transport the access token = (please correct me if not).. >=20 > This creates a dependency on the transport. >=20 > How about creating a JWT binding for OAuth 2.0..? We can transport the = access token as an encrypted JWT header parameter..? >=20 >=20 > Thanks & Regards, > Prabath >=20 > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena = >=20 > Mobile : +1 650 625 7950 >=20 > http://blog.facilelogin.com > http://blog.api-security.org = ___________________________________________= ____ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3F2CDAAA-1362-4D09-9512-91AAE5F4FBDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There is a OAuth binding to SASL https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19=

Google supports it = for IMAP/SMTP,  I think the latest iOS and OSX mail client updates = use it rather than passwords for Google.
I also = noticed Outlook on Android using it.

The access token might be a signed or = encrypted JWT itself.  I don=E2=80=99t know that wrapping it again = necessarily helps.

Yes we should have bindings to other non http protocols. =  

Is = there something specific that you are looking for that is not covered by = SASL?

John = B.



On Apr 14, 2015, at 6:21 PM, = Prabath Siriwardena <prabath@wso2.com> wrote:

At the moment we only HTTP binding to transport the access = token (please correct me if not)..

This creates a dependency on the = transport.

How = about creating a JWT binding for OAuth 2.0..? We can transport the = access token as an encrypted JWT header parameter..?


Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-security.org
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_3F2CDAAA-1362-4D09-9512-91AAE5F4FBDF-- From nobody Tue Apr 14 14:48:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1641A1EF6 for ; Tue, 14 Apr 2015 14:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvk4Hv8skytP for ; Tue, 14 Apr 2015 14:48:37 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::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 2E5841A1BC6 for ; Tue, 14 Apr 2015 14:48:37 -0700 (PDT) Received: by vnbg129 with SMTP id g129so8736689vnb.4 for ; Tue, 14 Apr 2015 14:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mld1fW51JZiBVCK7P3E4gXkBUixVcEsGqh7ip5+Sqek=; b=UCvFIFd4mzf80iCxUlazrDnUzesqHDgksS/L0tHH2ebeCeCaoRMo0E1lBeHXOtYSNl YLE0EzwMnzrqh7OuyBaiOPFHh869wbJPM2a4LSQquFRATbYmH79TrtLD5pOlFdcwsPGO 1Kceys+5IZu7bHL1l98R1cv1wmvafoyRD0Pzw= 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:content-type; bh=Mld1fW51JZiBVCK7P3E4gXkBUixVcEsGqh7ip5+Sqek=; b=HY/UFPACICgvTttsDVwbe/LzOlZ+tr5DWj3n6VrLq8iAy2lMokZNChe5MB+fGbYQYT Sx1WsGxdt55Jn10p7HtSoJvQmeKEVSGLms1HXPQN19nz+7Y9JZqIPCem4M6n4JjDt1pN eHDqV2RDaS+nQWG81mVtmEQWA43M0TFZMWuZSy3BHBHhaxXSWoDINcgkls5Ad3RminA8 Fiz1qT+6MbNQ8wFLLp2Ut9tRamztz6T3v8NF/75ZAnE25D2TVy+aAPhVgEm1mCYgr0di vYSs7xzVM8ZM90kRRKda7CsvO/XsCCID/44xNx6yy9Wt0m8MaV/uAgRpaagzomFgnz9e AFug== X-Gm-Message-State: ALoCoQmnyQ/IvXAF+DnjglH1lFrW4KXBzZgN77qpaiLc/QJx9Iw9gLpD81883omWzJFgMmWh7rnC MIME-Version: 1.0 X-Received: by 10.60.220.137 with SMTP id pw9mr18295674oec.47.1429048116399; Tue, 14 Apr 2015 14:48:36 -0700 (PDT) Received: by 10.202.72.198 with HTTP; Tue, 14 Apr 2015 14:48:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Apr 2015 14:48:36 -0700 Message-ID: From: Prabath Siriwardena To: John Bradley Content-Type: multipart/alternative; boundary=001a11347f905863ce0513b6313b Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:48:39 -0000 --001a11347f905863ce0513b6313b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks John for the pointer - will have look.. I am looking this for a pub/sub scenario.. Having JWT binding would benefit that.. Also - why I want access token to be inside a JWT is - when we send a JSON payload in this case, we already have the JWT envelope and the access token needs to be carried inside.. Thanks & regards, -Prabath On Tue, Apr 14, 2015 at 2:41 PM, John Bradley wrote: > There is a OAuth binding to SASL > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 > > Google supports it for IMAP/SMTP, I think the latest iOS and OSX mail > client updates use it rather than passwords for Google. > I also noticed Outlook on Android using it. > > The access token might be a signed or encrypted JWT itself. I don=E2=80= =99t know > that wrapping it again necessarily helps. > > Yes we should have bindings to other non http protocols. > > Is there something specific that you are looking for that is not covered > by SASL? > > John B. > > > > On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena wrote= : > > At the moment we only HTTP binding to transport the access token (please > correct me if not).. > > This creates a dependency on the transport. > > How about creating a JWT binding for OAuth 2.0..? We can transport the > access token as an encrypted JWT header parameter..? > > > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://blog.facilelogin.com > http://blog.api-security.org > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org --001a11347f905863ce0513b6313b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks John for the pointer - will have look..

I am looking this for a pub/sub scenario..=C2=A0 Having JWT binding= would benefit that..

Also - why I want access tok= en to be inside a JWT is - when we send a JSON payload in this case, we alr= eady have the JWT envelope and the access token needs to be carried inside.= .

Thanks & regards,
-Prabath





On Tue, Apr 14, 2015 at 2:4= 1 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
There is a OAuth bi= nding to SASL=C2=A0https://tools.ietf.org/html/draft-ietf-ki= tten-sasl-oauth-19

Google supports it for IMAP/SMTP,= =C2=A0I think the latest iOS and OSX mail client updates use it rather tha= n passwords for Google.
I also noticed Outlook on Android using i= t.

The access token might be a signed or encrypted= JWT itself.=C2=A0 I don=E2=80=99t know that wrapping it again necessarily = helps.

Yes we should have bindings to other non ht= tp protocols. =C2=A0

Is there something specific t= hat you are looking for that is not covered by SASL?

John B.



On Apr 14, 2015, at 6:21 PM, Prabath= Siriwardena <prab= ath@wso2.com> wrote:

At the moment we only HTTP binding to transport the acce= ss token (please correct me if not)..

This creates a dep= endency on the transport.

How about creating a JWT= binding for OAuth 2.0..? We can transport the access token as an encrypted= JWT header parameter..?


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



--
Thanks & Regards,=
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.co= m/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.= com
http:= //blog.api-security.org
--001a11347f905863ce0513b6313b-- From nobody Tue Apr 14 14:56:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64251A6F30 for ; Tue, 14 Apr 2015 14:56:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQmyyDQVFSe2 for ; Tue, 14 Apr 2015 14:56:18 -0700 (PDT) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) (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 D8F331A6F20 for ; Tue, 14 Apr 2015 14:56:17 -0700 (PDT) Received: by qku63 with SMTP id 63so41788447qku.3 for ; Tue, 14 Apr 2015 14:56:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FBuOeizz4EuSGLMZMXEfoTL8E9XNTQeKluLdHAosMsY=; b=RJuhsKpeJFkFLpkqFnizfXwfqPfQzf6g5szsT8u2Lcp7v3rqWS4Wr2+H6NfKzRhZ5h bEsp6zo//NwjljY7S3LEsTDn1PXfv2d4yVrcqxUaWw9N9ofpRsUFL/WDoxqB05VNF1hx 5VN7zxCvXRzpDOiFiAwiCKYQ1kvGLtxydeNbZASLZWoHvQjz14O3+Q0MCcOH3QiUBxUG OgeJ9a9HFncq/q8RsEfdGo6fF1jhiJGBRyubQmDdB0fyssJ3x7Vz6RfFeroF7jQc1q7w uIWBScwnymBpyZsFp2VYPeYHo7o4xxngcANRv0A7AdxFPZvueVs6BpfeTzCkXLnIm1nT IlCg== X-Gm-Message-State: ALoCoQlawBzRrPnIrWyLz8IBwdPh2k8xXLgX90MF1rZ9lwN7GSUahOlpVMPS2KfeFfDRoJrA6jP/ X-Received: by 10.140.237.67 with SMTP id i64mr27722304qhc.86.1429048556744; Tue, 14 Apr 2015 14:55:56 -0700 (PDT) Received: from [192.168.1.216] (181-163-76-154.baf.movistar.cl. [181.163.76.154]) by mx.google.com with ESMTPSA id q64sm342011qkh.33.2015.04.14.14.55.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Apr 2015 14:55:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_273B14D5-C9F6-4E49-974A-FD2D76336C96" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Bradley In-Reply-To: Date: Tue, 14 Apr 2015 18:55:42 -0300 Message-Id: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> References: To: Prabath Siriwardena X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 21:56:21 -0000 --Apple-Mail=_273B14D5-C9F6-4E49-974A-FD2D76336C96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Most of the pub sub things I have seen use HTTP transport. Do you have = a pointer to the protocol? > On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena = wrote: >=20 > Thanks John for the pointer - will have look.. >=20 > I am looking this for a pub/sub scenario.. Having JWT binding would = benefit that.. >=20 > Also - why I want access token to be inside a JWT is - when we send a = JSON payload in this case, we already have the JWT envelope and the = access token needs to be carried inside.. >=20 > Thanks & regards, > -Prabath >=20 >=20 >=20 >=20 >=20 > On Tue, Apr 14, 2015 at 2:41 PM, John Bradley > wrote: > There is a OAuth binding to SASL = https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 = >=20 > Google supports it for IMAP/SMTP, I think the latest iOS and OSX mail = client updates use it rather than passwords for Google. > I also noticed Outlook on Android using it. >=20 > The access token might be a signed or encrypted JWT itself. I don=E2=80= =99t know that wrapping it again necessarily helps. >=20 > Yes we should have bindings to other non http protocols. =20 >=20 > Is there something specific that you are looking for that is not = covered by SASL? >=20 > John B. >=20 >=20 >=20 >> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena > wrote: >>=20 >> At the moment we only HTTP binding to transport the access token = (please correct me if not).. >>=20 >> This creates a dependency on the transport. >>=20 >> How about creating a JWT binding for OAuth 2.0..? We can transport = the access token as an encrypted JWT header parameter..? >>=20 >>=20 >> Thanks & Regards, >> Prabath >>=20 >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena = >>=20 >> Mobile : +1 650 625 7950 >>=20 >> http://blog.facilelogin.com >> http://blog.api-security.org = ___________________________________________= ____ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > Thanks & Regards, > Prabath >=20 > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena = >=20 > Mobile : +1 650 625 7950 >=20 > http://blog.facilelogin.com > http://blog.api-security.org --Apple-Mail=_273B14D5-C9F6-4E49-974A-FD2D76336C96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Most of the pub sub things I have seen use HTTP transport. =  Do you have a pointer to the protocol?

On = Apr 14, 2015, at 6:48 PM, Prabath Siriwardena <prabath@wso2.com> = wrote:

Thanks John for the pointer - will have = look..

I am looking = this for a pub/sub scenario..  Having JWT binding would benefit = that..

Also - = why I want access token to be inside a JWT is - when we send a JSON = payload in this case, we already have the JWT envelope and the access = token needs to be carried inside..

Thanks & regards,
-Prabath





On Tue, Apr 14, 2015 at 2:41 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
There is a OAuth binding to = SASL https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19=

Google supports it = for IMAP/SMTP,  I think the latest iOS and OSX mail client updates = use it rather than passwords for Google.
I also = noticed Outlook on Android using it.

The access token might be a signed or = encrypted JWT itself.  I don=E2=80=99t know that wrapping it again = necessarily helps.

Yes we should have bindings to other non http protocols. =  

Is = there something specific that you are looking for that is not covered by = SASL?

John = B.



On Apr 14, 2015, at 6:21 PM, Prabath = Siriwardena <prabath@wso2.com> wrote:

At the moment we only HTTP = binding to transport the access token (please correct me if not)..

This creates a = dependency on the transport.

How about creating a JWT binding for = OAuth 2.0..? We can transport the access token as an encrypted JWT = header parameter..?


Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 = 7950

http://blog.facilelogin.com
http://blog.api-security.org
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-security.org

= --Apple-Mail=_273B14D5-C9F6-4E49-974A-FD2D76336C96-- From nobody Tue Apr 14 15:02:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6502B1A86E0 for ; Tue, 14 Apr 2015 15:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqWGVJcc2S17 for ; Tue, 14 Apr 2015 15:02:53 -0700 (PDT) Received: from mail-vn0-x22d.google.com (mail-vn0-x22d.google.com [IPv6:2607:f8b0:400c:c0f::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 7D3361A7D85 for ; Tue, 14 Apr 2015 15:02:53 -0700 (PDT) Received: by vnbf62 with SMTP id f62so8793883vnb.13 for ; Tue, 14 Apr 2015 15:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n98mAK/0LAlu6pOqhLX4BcH+zqgTtXFKBzDb6LuALEk=; b=Pth82yE+Ly//nML9L3MpSe5swdFoBEirdx+V6lvfJ5NZ29DZqtgl3ZZoTQDGi4NRYC XMm5es1NPd8FvzauDM2oSjg6x2QKzc9fKthIkUZ9ScKlL+iIH7LY4sgS7JUMdC1jP702 SxfU91NjEcdjFBC54PNeOEWLGpIsDGnkZerrU= 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:content-type; bh=n98mAK/0LAlu6pOqhLX4BcH+zqgTtXFKBzDb6LuALEk=; b=DewoTQCdgJez6+RdPxAggLKWv4aypLIHsA+/dB634+gsCO3JVHYvhd0S+nxYYr3BI2 zsJkE+JRBwbZRi7JM2GoY4AjM0W5j0IMDN1KuSTPuQXdU/AxB8Y4n6N1NkPHD94TxPU/ 1KBJyMWSzP1ENzGqyDRIxll33jR4xav974fX7G83vGXA7ev9juM/BRemzEyOuARy98Cv 8OB3sIMhSMfLG4hxqsvyrOQlzH5nLMeWnzL8CjcS1TzdwKSn+KwdFW2ujP3KVPX2rxjN WcBkArLB7InV82poOxDbkINNmoaiPijliwf6AK6E5PRyP1kn3E40JaGaoOYC7/H5JklD 5Cag== X-Gm-Message-State: ALoCoQn5GYtF/00tA0PdAJVQMN1zyCnloPEgXxkEwCljS0ndEgM+iW1LyodMRUc3eJwbjvH+W518 MIME-Version: 1.0 X-Received: by 10.60.15.133 with SMTP id x5mr17987820oec.80.1429048972714; Tue, 14 Apr 2015 15:02:52 -0700 (PDT) Received: by 10.202.72.198 with HTTP; Tue, 14 Apr 2015 15:02:52 -0700 (PDT) In-Reply-To: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> References: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> Date: Tue, 14 Apr 2015 15:02:52 -0700 Message-ID: From: Prabath Siriwardena To: John Bradley Content-Type: multipart/alternative; boundary=089e014945c062be9d0513b664ac Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 22:02:55 -0000 --089e014945c062be9d0513b664ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It can be a JSON payload over JMS or even MQTT.. I have seen some effort to create an MQTT binding for OAuth 2.0 - but then again for each transport we need to have a binding.. But - creating a message level binding would be much better IMHO.. Thanks & regards, -Prabath On Tue, Apr 14, 2015 at 2:55 PM, John Bradley wrote: > Most of the pub sub things I have seen use HTTP transport. Do you have a > pointer to the protocol? > > On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena wrote= : > > Thanks John for the pointer - will have look.. > > I am looking this for a pub/sub scenario.. Having JWT binding would > benefit that.. > > Also - why I want access token to be inside a JWT is - when we send a JSO= N > payload in this case, we already have the JWT envelope and the access tok= en > needs to be carried inside.. > > Thanks & regards, > -Prabath > > > > > > On Tue, Apr 14, 2015 at 2:41 PM, John Bradley wrote: > >> There is a OAuth binding to SASL >> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 >> >> Google supports it for IMAP/SMTP, I think the latest iOS and OSX mail >> client updates use it rather than passwords for Google. >> I also noticed Outlook on Android using it. >> >> The access token might be a signed or encrypted JWT itself. I don=E2=80= =99t know >> that wrapping it again necessarily helps. >> >> Yes we should have bindings to other non http protocols. >> >> Is there something specific that you are looking for that is not covered >> by SASL? >> >> John B. >> >> >> >> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena >> wrote: >> >> At the moment we only HTTP binding to transport the access token (please >> correct me if not).. >> >> This creates a dependency on the transport. >> >> How about creating a JWT binding for OAuth 2.0..? We can transport the >> access token as an encrypted JWT header parameter..? >> >> >> Thanks & Regards, >> Prabath >> >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >> >> Mobile : +1 650 625 7950 >> >> http://blog.facilelogin.com >> http://blog.api-security.org >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://blog.facilelogin.com > http://blog.api-security.org > > > --=20 Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org --089e014945c062be9d0513b664ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It can be a JSON payload over JMS or even MQTT..=C2=A0
I have seen some effort to create an MQTT binding for OAuth= 2.0 - but then again for each transport we need to have a binding..
<= div>
But - creating a message level binding would be much bet= ter IMHO..

Thanks & regards,
-Prabat= h

On Tue, Apr = 14, 2015 at 2:55 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:=
Most= of the pub sub things I have seen use HTTP transport.=C2=A0 Do you have a = pointer to the protocol?

On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena <prabath@wso2.com> w= rote:

Thanks John for the pointer - will hav= e look..

I am looking this for a pub/sub scenario..=C2= =A0 Having JWT binding would benefit that..

Also -= why I want access token to be inside a JWT is - when we send a JSON payloa= d in this case, we already have the JWT envelope and the access token needs= to be carried inside..

Thanks & regards,
-Prabath




<= /div>

On Tue= , Apr 14, 2015 at 2:41 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
There is a OAuth binding to SASL=C2=A0https://tools.ietf.o= rg/html/draft-ietf-kitten-sasl-oauth-19

Google suppo= rts it for IMAP/SMTP, =C2=A0I think the latest iOS and OSX mail client upda= tes use it rather than passwords for Google.
I also noticed Outlo= ok on Android using it.

The access token might be = a signed or encrypted JWT itself.=C2=A0 I don=E2=80=99t know that wrapping = it again necessarily helps.

Yes we should have bin= dings to other non http protocols. =C2=A0

Is there= something specific that you are looking for that is not covered by SASL?

John B.


On Apr 14, 2015, at 6:21 PM,= Prabath Siriwardena <prabath@wso2.com> wrote:

At the moment we only HTTP binding to transport the access to= ken (please correct me if not)..

This creates a dependen= cy on the transport.

How about creating a JWT bind= ing for OAuth 2.0..? We can transport the access token as an encrypted JWT = header parameter..?


Thanks & Regards,
Prabath

Twitter : @prabath
Linke= dIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-security.org
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



--



--
Thanks & Regards,
Prabath

Twitter : @praba= th
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

= Mobile : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-security.org
--089e014945c062be9d0513b664ac-- From nobody Tue Apr 14 15:06:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399FB1A8737 for ; Tue, 14 Apr 2015 15:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46jJGhUgxQyQ for ; Tue, 14 Apr 2015 15:06:08 -0700 (PDT) Received: from nm41.bullet.mail.bf1.yahoo.com (nm41.bullet.mail.bf1.yahoo.com [216.109.114.57]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9761A8735 for ; Tue, 14 Apr 2015 15:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1429049166; bh=as+ltZKTp8ZdSu+kGi3eIW84T9OPHuFrBl9npNpZQ28=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=n5YNok/ogZhDsRvd2b2cjr6VcJYaCibTWqNryId0EQs7efpkHwWiEIJrl+6hzs0kC+GpPdBAB6C1rX8aR12OXWxhhsRAd/gic0HCLXvm4+06B32xnvarSa3ZvZ9q0ZKiuijjDVxcLdQssRmSHJ/ogLIEpmi5gxAGzUDKY+fUSD+ZNZ0k8IAYANBUX6u7h5B5iW9aXGekulKrBssOlvaid5EVAFRjViS7ZvMmbvORsHENjVo102r1aztPFPnX6nxMpv9Ma7pK6GcP8jTnTRUY/2tkKMHXzLJJIBvBdjwqlrnaLcWkA9eKOyk7n+cqJ/gLIp7nnyFQVJ7gpVbPBmTq8Q== Received: from [98.139.170.179] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 14 Apr 2015 22:06:06 -0000 Received: from [98.139.212.222] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 14 Apr 2015 22:06:06 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 14 Apr 2015 22:06:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 835796.12946.bm@omp1031.mail.bf1.yahoo.com X-YMail-OSG: WUpcdJMVM1kE2fhKBr9drYJSmfvejtbjltaPfTrETxVoU_y43_OXa0ZTkcsnlrs bFS7N.pDT60jGZZFjIzT1_1yB.n4bDR3Wh_wEAJFmZBnD9NJRThwVTrfig9J1J_a_YGHoFHOYMAe ut3na8z4CFx9mjtbYWCTD9.m1K93soJSZSOVzw09pqUrtnoCs4gdU.zKRhPykwkgk2KlPQumI9zZ huhjnfz9Sztw0XzZwDFAzbXFRd7AM.dXFvH0IfvH5U.1mUUHEu_Ue4D9bWi_A8MzAfH0dNyLmDks 72xdwWHjAhwAksdZNU87WDToMAkh1soWWZ2bx50ybXv6GCR5rABepEOTz_CjQOoYwBdZ_5lETH.7 cWzVDSLbAN5k0GlONdldeuofEZHWX9OpUOQ63k07fsrT8ISQ8q3S0tNGgdjg8zuOHhHhTbHpRGQf HdBUZjtny80L306ms9QPTXnnbeikw9J8Qzg.tLv55dohPifvotszHmt4NEqY_sYggjLv0hADva21 F9PVj5p.ObbENSH0- Received: by 66.196.81.120; Tue, 14 Apr 2015 22:06:06 +0000 Date: Tue, 14 Apr 2015 22:06:05 +0000 (UTC) From: Bill Mills To: John Bradley , Prabath Siriwardena Message-ID: <660351144.3721997.1429049165503.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3721996_1012661116.1429049165497" Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 22:06:09 -0000 ------=_Part_3721996_1012661116.1429049165497 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, Microsoft supports this on Hotmail/Outlook.com and the Outlook client = supports it.=20 On Tuesday, April 14, 2015 2:42 PM, John Bradley w= rote: =20 There is a OAuth binding to SASL=C2=A0https://tools.ietf.org/html/draft-ie= tf-kitten-sasl-oauth-19 Google supports it for IMAP/SMTP, =C2=A0I think the latest iOS and OSX mail= client updates use it rather than passwords for Google.I also noticed Outl= ook on Android using it. The access token might be a signed or encrypted JWT itself. =C2=A0I don=E2= =80=99t know that wrapping it again necessarily helps. Yes we should have bindings to other non http protocols. =C2=A0 Is there something specific that you are looking for that is not covered by= SASL? John B. On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena wrote: At the moment we only HTTP binding to transport the access token (please co= rrect me if not).. This creates a dependency on the transport. How about creating a JWT binding for OAuth 2.0..? We can transport the acce= ss token as an encrypted JWT header parameter..? Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org_______________________________________________ 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 ------=_Part_3721996_1012661116.1429049165497 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, Microsoft supports this on Hotmai= l/Outlook.com and the Outlook client supports it.



On Tuesday, April 14, 2015 2:42 PM, John Bradley <ve7jtb@ve= 7jtb.com> wrote:


There is a OAuth binding to SASL <= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv2113216131" target=3D"_blank"= href=3D"https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19">https= ://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19

Google supports it for IMAP/SMTP,  I think the latest i= OS and OSX mail client updates use it rather than passwords for Google.
I also noticed Outlook on Android using it.<= /div>

The access token might be a signed or = encrypted JWT itself.  I don=E2=80=99t know that wrapping it again nec= essarily helps.

Yes we should have bi= ndings to other non http protocols.  

Is there something specific that you are looking for that is not cover= ed by SASL?

John B.



On Ap= r 14, 2015, at 6:21 PM, Prabath Siriwardena <prabath@wso2.com> wrot= e:

At t= he moment we only HTTP binding to transport the access token (please correc= t me if not)..

This creates a dependency on = the transport.

How about creating a = JWT binding for OAuth 2.0..? We can transport the access token as an encryp= ted JWT header parameter..?

Thanks & Regards,
Prabath=

Twitter : @prabath
Lin= kedIn : http://w= ww.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 795= 0

http://blog.facilelogin= .com
http://blog.api-security.org
_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/= mailman/listinfo/oauth


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


<= /div>
------=_Part_3721996_1012661116.1429049165497-- From nobody Tue Apr 14 16:01:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F6E1B3034 for ; Tue, 14 Apr 2015 16:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Asv2ze8NjJ for ; Tue, 14 Apr 2015 16:01:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125FA1B3033 for ; Tue, 14 Apr 2015 16:01:03 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3EN11ER015016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Apr 2015 23:01:01 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3EN10nF015843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Apr 2015 23:01:00 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3EN100d030224; Tue, 14 Apr 2015 23:01:00 GMT Received: from [172.31.147.139] (/216.9.110.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Apr 2015 16:00:59 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-2CBED7B1-6D64-4488-ABD9-A416DDB06DB8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Tue, 14 Apr 2015 16:00:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> To: Prabath Siriwardena X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 23:01:05 -0000 --Apple-Mail-2CBED7B1-6D64-4488-ABD9-A416DDB06DB8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The recent scim notify draft does pub sub using jwts.=20 Phil > On Apr 14, 2015, at 15:02, Prabath Siriwardena wrote: >=20 > It can be a JSON payload over JMS or even MQTT..=20 >=20 > I have seen some effort to create an MQTT binding for OAuth 2.0 - but then= again for each transport we need to have a binding.. >=20 > But - creating a message level binding would be much better IMHO.. >=20 > Thanks & regards, > -Prabath >=20 >> On Tue, Apr 14, 2015 at 2:55 PM, John Bradley wrote: >> Most of the pub sub things I have seen use HTTP transport. Do you have a= pointer to the protocol? >>=20 >>> On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena wrot= e: >>>=20 >>> Thanks John for the pointer - will have look.. >>>=20 >>> I am looking this for a pub/sub scenario.. Having JWT binding would ben= efit that.. >>>=20 >>> Also - why I want access token to be inside a JWT is - when we send a JS= ON payload in this case, we already have the JWT envelope and the access tok= en needs to be carried inside.. >>>=20 >>> Thanks & regards, >>> -Prabath >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Tue, Apr 14, 2015 at 2:41 PM, John Bradley wrote= : >>>> There is a OAuth binding to SASL https://tools.ietf.org/html/draft-ietf= -kitten-sasl-oauth-19 >>>>=20 >>>> Google supports it for IMAP/SMTP, I think the latest iOS and OSX mail c= lient updates use it rather than passwords for Google. >>>> I also noticed Outlook on Android using it. >>>>=20 >>>> The access token might be a signed or encrypted JWT itself. I don=E2=80= =99t know that wrapping it again necessarily helps. >>>>=20 >>>> Yes we should have bindings to other non http protocols. =20 >>>>=20 >>>> Is there something specific that you are looking for that is not covere= d by SASL? >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>=20 >>>>> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena wr= ote: >>>>>=20 >>>>> At the moment we only HTTP binding to transport the access token (plea= se correct me if not).. >>>>>=20 >>>>> This creates a dependency on the transport. >>>>>=20 >>>>> How about creating a JWT binding for OAuth 2.0..? We can transport the= access token as an encrypted JWT header parameter..? >>>>>=20 >>>>>=20 >>>>> Thanks & Regards, >>>>> Prabath >>>>>=20 >>>>> Twitter : @prabath >>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>>=20 >>>>> Mobile : +1 650 625 7950 >>>>>=20 >>>>> http://blog.facilelogin.com >>>>> http://blog.api-security.org >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> --=20 >>> Thanks & Regards, >>> Prabath >>>=20 >>> Twitter : @prabath >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>=20 >>> Mobile : +1 650 625 7950 >>>=20 >>> http://blog.facilelogin.com >>> http://blog.api-security.org >=20 >=20 >=20 > --=20 > Thanks & Regards, > Prabath >=20 > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >=20 > Mobile : +1 650 625 7950 >=20 > http://blog.facilelogin.com > http://blog.api-security.org > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2CBED7B1-6D64-4488-ABD9-A416DDB06DB8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The recent scim notify draft does pub s= ub using jwts. 

Phil

On Apr 14, 2015, at 15:02, Pr= abath Siriwardena <prabath@wso2.com> wrote:

I= t can be a JSON payload over JMS or even MQTT.. 

I h= ave seen some effort to create an MQTT binding for OAuth 2.0 - but then agai= n for each transport we need to have a binding..

Bu= t - creating a message level binding would be much better IMHO..
<= br>
Thanks & regards,
-Prabath

On Tue, Apr 14, 2015 at 2:55 PM, Joh= n Bradley <ve7jtb@ve7jtb.com> wrote:
Most of the pub sub things I have s= een use HTTP transport.  Do you have a pointer to the protocol?

On Apr 14, 2015,= at 6:48 PM, Prabath Siriwardena <prabath@wso2.com> wrote:

Thanks John for the pointer - will have look..

I am loo= king this for a pub/sub scenario..  Having JWT binding would benefit th= at..

Also - why I want access token to be inside a J= WT is - when we send a JSON payload in this case, we already have the JWT en= velope and the access token needs to be carried inside..

Thanks & regards,
-Prabath


=



On Tue, Apr 14, 2015 at 2:41 PM, John Bradley <ve7jtb= @ve7jtb.com> wrote:
There is a OAuth binding to SASL https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19

<= /div>
Google supports it for IMAP/SMTP,  I think the latest iOS and= OSX mail client updates use it rather than passwords for Google.
= I also noticed Outlook on Android using it.

The acc= ess token might be a signed or encrypted JWT itself.  I don=E2=80=99t k= now that wrapping it again necessarily helps.

Yes w= e should have bindings to other non http protocols.  

Is there something specific that you are looking for that is not cov= ered by SASL?

John B.


=

On Apr 14, 2015= , at 6:21 PM, Prabath Siriwardena <prabath@wso2.com> wrote:

At the moment we only HTTP binding to transport the= access token (please correct me if not)..

This creates a= dependency on the transport.

How about creating a J= WT binding for OAuth 2.0..? We can transport the access token as an encrypte= d JWT header parameter..?


Thanks & Regards,
Prabath

Twitter : @prabath
Lin= kedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-security.org
=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth




--
=


=

--
Thanks & Regards,
Prabath

Twitter : @prabathLinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile= : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-security.org
=
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-2CBED7B1-6D64-4488-ABD9-A416DDB06DB8-- From nobody Wed Apr 15 01:16:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3455B1B32D4 for ; Wed, 15 Apr 2015 01:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp-2LzjP-oQu for ; Wed, 15 Apr 2015 01:16:38 -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 27D1D1AD0CB for ; Wed, 15 Apr 2015 01:16:37 -0700 (PDT) Received: from [192.168.10.182] ([80.255.245.230]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LvPgd-1ZQG8H3ZpL-010Z0D; Wed, 15 Apr 2015 10:16:34 +0200 Message-ID: <552E1E60.8010602@gmx.net> Date: Wed, 15 Apr 2015 10:16:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Prabath Siriwardena , John Bradley References: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TkjX8OBhvvRkU4fn4gMCfFRVhuqx4vXAh" X-Provags-ID: V03:K0:sAyFWWyfRAfrfVHwGl+FUpjUuZsBKZva3Rf/ZLvj066X6wYSTjI 8qJ9+fb0M9rhTezHliJISi/MoH9v0COg8Rv2ia45gugtJn/cTXsIpU8CfKVzHT2xp5lo9s1 wu/Jo1lCzJ6SSZAXvIxz1T2GKeOFguns9f1m5SM4b5ldw2vb/LqSR4ZJxVFUkIrIGXjSUvo wdv0KboXpmxdTEqctePew== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 08:16:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TkjX8OBhvvRkU4fn4gMCfFRVhuqx4vXAh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Prabath, the reason we have documents that describe the transport of bearer tokens/proof-of-possession tokens over the different transports is a task is more than just conveying a JWT over some protocol. There are various documents that specify the transport of OAuth access tokens over some protocol: * Bearer Tokens over HTTPS: https://tools.ietf.org/html/rfc6750 * Proof-of-Possession Tokens over TURN http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13 * Bearer Tokens over SASL: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 * Bearer Tokens over CoAP: https://tools.ietf.org/html/draft-tschofenig-ace-oauth-bt-01 * OAuth over SIP: https://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-02 * Then, there is all the work on proof-of-possession tokens that requires thoughts on how to tie the access token to the request (see http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 or token binding at https://tools.ietf.org/html/draft-ietf-tokbind-protocol-= 00) If you look at these documents then you will see that the characteristics of the underlying protocol matter a lot from a security point of view. There are also encoding and discovery related aspects that need to be taken into account as well. If someone wants to figure out how to carry OAuth access tokens over MQTT then they will have to figure out whether there are some additional considerations to take into account. What we should probably doing in this group is to write a guidance document for using OAuth over <>. Ciao Hannes On 04/15/2015 12:02 AM, Prabath Siriwardena wrote: > It can be a JSON payload over JMS or even MQTT..=20 >=20 > I have seen some effort to create an MQTT binding for OAuth 2.0 - but > then again for each transport we need to have a binding.. >=20 > But - creating a message level binding would be much better IMHO.. >=20 > Thanks & regards, > -Prabath >=20 > On Tue, Apr 14, 2015 at 2:55 PM, John Bradley > wrote: >=20 > Most of the pub sub things I have seen use HTTP transport. Do you > have a pointer to the protocol? >=20 >> On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena > > wrote: >> >> Thanks John for the pointer - will have look.. >> >> I am looking this for a pub/sub scenario.. Having JWT binding >> would benefit that.. >> >> Also - why I want access token to be inside a JWT is - when we >> send a JSON payload in this case, we already have the JWT envelope= >> and the access token needs to be carried inside.. >> >> Thanks & regards, >> -Prabath >> >> >> >> >> >> On Tue, Apr 14, 2015 at 2:41 PM, John Bradley > > wrote: >> >> There is a OAuth binding to >> SASL https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-= 19 >> >> Google supports it for IMAP/SMTP, I think the latest iOS and >> OSX mail client updates use it rather than passwords for Googl= e. >> I also noticed Outlook on Android using it. >> >> The access token might be a signed or encrypted JWT itself. I= >> don=92t know that wrapping it again necessarily helps. >> >> Yes we should have bindings to other non http protocols. =20 >> >> Is there something specific that you are looking for that is >> not covered by SASL? >> >> John B. >> >> >> >>> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena >>> > wrote: >>> >>> At the moment we only HTTP binding to transport the access >>> token (please correct me if not).. >>> >>> This creates a dependency on the transport. >>> >>> How about creating a JWT binding for OAuth 2.0..? We can >>> transport the access token as an encrypted JWT header >>> parameter..? >>> >>> >>> Thanks & Regards, >>> Prabath >>> >>> Twitter : @prabath >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>> >>> Mobile : +1 650 625 7950 >>> >>> http://blog.facilelogin.com >>> http://blog.api-security.org >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> --=20 >> Thanks & Regards, >> Prabath >> >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >> >> Mobile : +1 650 625 7950 >> >> http://blog.facilelogin.com >> http://blog.api-security.org >=20 >=20 >=20 >=20 > --=20 > Thanks & Regards, > Prabath >=20 > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >=20 > Mobile : +1 650 625 7950 >=20 > http://blog.facilelogin.com > http://blog.api-security.org >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --TkjX8OBhvvRkU4fn4gMCfFRVhuqx4vXAh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVLh5hAAoJEGhJURNOOiAt6LYIAITqE/ELfJu8uLYlL+ZB5ipb deSZ5jGMuNLkG6UykvspQEeXilS/MgWRH9wmiiZRXWO2I+XRPEQo0wgd4rouN9WT kvGQ1LFlv62jlFxIs7u+t53OH+onjy7ivP4HsOOcCQC1pSC5304uvE1AznH9KH8Y LHOLZr3POTHwZo/XOABgplP5G2gvsIe246BQP4ledjDBPU6eLQosG+t1KXrR1jsf nudmuV4zgIlnAQyByWv4KK2dFmEZ38GbltXs4EclIHb3ZOXaIRbs0H8HoOT+Zt+I TyPKfNrAIx9jJ1LhjcwK45IWkZSsUpuTQMkpH3Eue9gs0wv+UWZbPM7VL3j5pMY= =ZW63 -----END PGP SIGNATURE----- --TkjX8OBhvvRkU4fn4gMCfFRVhuqx4vXAh-- From nobody Wed Apr 15 04:30:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0CB1A8779 for ; Wed, 15 Apr 2015 04:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpQiIXkV2Ctg for ; Wed, 15 Apr 2015 04:30:13 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::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 876F91A876D for ; Wed, 15 Apr 2015 04:30:13 -0700 (PDT) Received: by vnbg1 with SMTP id g1so13780307vnb.2 for ; Wed, 15 Apr 2015 04:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pGKumX2ehPmflY37FtRhDPdA38xb6eOHtRQ0HWkl8G0=; b=hZSPRjGF//q5R0qCeJv7XMUhOfWaty08d2FEG3z84aOuABFdE/3ll9e66KqQTUCFQG YRkgqExUdeOuhsHcZKhKlWzRbOJNM2iTpFF0v2dDDOP6B84TOvACZ+P2/kAaOuPDEn1U IqFH5SyGXpB1QHvB5/w19ccgsKOeqVqUjWH94= 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:content-type; bh=pGKumX2ehPmflY37FtRhDPdA38xb6eOHtRQ0HWkl8G0=; b=R5J0USDUGxNowv54SnTMOiVhOLMh1HOT0DFQQC8r8Lk4Rlg9mHAz4l/GYqCHYRGyIu YsTul5TB1qAJh7plAm9P5Y0mcgcZHFPdrcQr1AGmBWXhgpEOvg8/lSSzLyQ+Od8Y6Ikv lkMBPsQruJyZLWWuWOtECwg/vwDR+UDLYB2qvLgf3ElJdyCdwLhS9mJPXwpUx5XmY52B 9PjNBHG3Z5vibF10i/sI8HmLtgcFM1bGCxWdTFjsgQIq3ZRBggOjAcQ8GLB9JXE8fQQX kafvwt6paPA+V81rr+7L5jc12MQu4XQ1l7q4jP+j0srPCZpH+1iqGJ/nbdYfm8M1ZA5z 2ACg== X-Gm-Message-State: ALoCoQnZIkKI9bnhnrZYfoGbRBcwQZzx9olx+fLyIuNx9SF1K1RmsCvDhk118FkHEyCXphYoGziV MIME-Version: 1.0 X-Received: by 10.60.63.141 with SMTP id g13mr20219647oes.3.1429097412322; Wed, 15 Apr 2015 04:30:12 -0700 (PDT) Received: by 10.202.72.198 with HTTP; Wed, 15 Apr 2015 04:30:11 -0700 (PDT) In-Reply-To: <552E1E60.8010602@gmx.net> References: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> <552E1E60.8010602@gmx.net> Date: Wed, 15 Apr 2015 04:30:11 -0700 Message-ID: From: Prabath Siriwardena To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c1db349c7d6b0513c1ab5a Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 11:30:16 -0000 --001a11c1db349c7d6b0513c1ab5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hannes, I still think its equally important to have a transport independent binding .. If you look at the SOAP world, WS-Security is self-contained in the message itself.. and SAML SOAP binding is also another example... Thanks & regards, -Prabath On Wed, Apr 15, 2015 at 1:16 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Prabath, > > the reason we have documents that describe the transport of bearer > tokens/proof-of-possession tokens over the different transports is a > task is more than just conveying a JWT over some protocol. > > There are various documents that specify the transport of OAuth access > tokens over some protocol: > > * Bearer Tokens over HTTPS: > https://tools.ietf.org/html/rfc6750 > > * Proof-of-Possession Tokens over TURN > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13 > > * Bearer Tokens over SASL: > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 > > * Bearer Tokens over CoAP: > https://tools.ietf.org/html/draft-tschofenig-ace-oauth-bt-01 > > * OAuth over SIP: > https://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-02 > > * Then, there is all the work on proof-of-possession tokens that > requires thoughts on how to tie the access token to the request (see > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 or > token binding at > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-00) > > If you look at these documents then you will see that the > characteristics of the underlying protocol matter a lot from a security > point of view. There are also encoding and discovery related aspects > that need to be taken into account as well. > > If someone wants to figure out how to carry OAuth access tokens over > MQTT then they will have to figure out whether there are some additional > considerations to take into account. > > What we should probably doing in this group is to write a guidance > document for using OAuth over <>. > > Ciao > Hannes > > On 04/15/2015 12:02 AM, Prabath Siriwardena wrote: > > It can be a JSON payload over JMS or even MQTT.. > > > > I have seen some effort to create an MQTT binding for OAuth 2.0 - but > > then again for each transport we need to have a binding.. > > > > But - creating a message level binding would be much better IMHO.. > > > > Thanks & regards, > > -Prabath > > > > On Tue, Apr 14, 2015 at 2:55 PM, John Bradley > > wrote: > > > > Most of the pub sub things I have seen use HTTP transport. Do you > > have a pointer to the protocol? > > > >> On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena >> > wrote: > >> > >> Thanks John for the pointer - will have look.. > >> > >> I am looking this for a pub/sub scenario.. Having JWT binding > >> would benefit that.. > >> > >> Also - why I want access token to be inside a JWT is - when we > >> send a JSON payload in this case, we already have the JWT envelope > >> and the access token needs to be carried inside.. > >> > >> Thanks & regards, > >> -Prabath > >> > >> > >> > >> > >> > >> On Tue, Apr 14, 2015 at 2:41 PM, John Bradley >> > wrote: > >> > >> There is a OAuth binding to > >> SASL > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 > >> > >> Google supports it for IMAP/SMTP, I think the latest iOS and > >> OSX mail client updates use it rather than passwords for Googl= e. > >> I also noticed Outlook on Android using it. > >> > >> The access token might be a signed or encrypted JWT itself. I > >> don=E2=80=99t know that wrapping it again necessarily helps. > >> > >> Yes we should have bindings to other non http protocols. > >> > >> Is there something specific that you are looking for that is > >> not covered by SASL? > >> > >> John B. > >> > >> > >> > >>> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena > >>> > wrote: > >>> > >>> At the moment we only HTTP binding to transport the access > >>> token (please correct me if not).. > >>> > >>> This creates a dependency on the transport. > >>> > >>> How about creating a JWT binding for OAuth 2.0..? We can > >>> transport the access token as an encrypted JWT header > >>> parameter..? > >>> > >>> > >>> Thanks & Regards, > >>> Prabath > >>> > >>> Twitter : @prabath > >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > >>> > >>> Mobile : +1 650 625 7950 > >>> > >>> http://blog.facilelogin.com > >>> http://blog.api-security.org > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> -- > >> Thanks & Regards, > >> Prabath > >> > >> Twitter : @prabath > >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > >> > >> Mobile : +1 650 625 7950 > >> > >> http://blog.facilelogin.com > >> http://blog.api-security.org > > > > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Twitter : @prabath > > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > > > Mobile : +1 650 625 7950 > > > > http://blog.facilelogin.com > > http://blog.api-security.org > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > --=20 Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org --001a11c1db349c7d6b0513c1ab5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

I still think its equally im= portant to have a transport independent binding ..

If you look at the SOAP world, WS-Security is self-contained in the messag= e itself.. and SAML SOAP binding is also another example...

<= /div>
Thanks & regards,
-Prabath


On Wed, Apr 15,= 2015 at 1:16 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net= > wrote:
Hi Prabath,

the reason we have documents that describe the transport of bearer
tokens/proof-of-possession tokens over the different transports is a
task is more than just conveying a JWT over some protocol.

There are various documents that specify the transport of OAuth access
tokens over some protocol:

* Bearer Tokens over HTTPS:
https://t= ools.ietf.org/html/rfc6750

* Proof-of-Possession Tokens over TURN
http://tools.ietf.org/html/draft-ietf-tram-turn-thi= rd-party-authz-13

* Bearer Tokens over SASL:
https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19<= /a>

* Bearer Tokens over CoAP:
https://tools.ietf.org/html/draft-tschofenig-ace-oauth-bt-0= 1

* OAuth over SIP:
https://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-0= 2

* Then, there is all the work on proof-of-possession tokens that
requires thoughts on how to tie the access token to the request (see
http://tools.ietf.org/html/draft-ietf-oauth-signed-ht= tp-request-01 or
token binding at https://tools.ietf.org/html/draft-ietf-tokbi= nd-protocol-00)

If you look at these documents then you will see that the
characteristics of the underlying protocol matter a lot from a security
point of view. There are also encoding and discovery related aspects
that need to be taken into account as well.

If someone wants to figure out how to carry OAuth access tokens over
MQTT then they will have to figure out whether there are some additional considerations to take into account.

What we should probably doing in this group is to write a guidance
document for using OAuth over <<foo>>.

Ciao
Hannes

On 04/15/2015 12:02 AM, Prabath Siriwardena wrote:
> It can be a JSON payload over JMS or even MQTT..
>
> I have seen some effort to create an MQTT binding for OAuth 2.0 - but<= br> > then again for each transport we need to have a binding..
>
> But - creating a message level binding would be much better IMHO..
>
> Thanks & regards,
> -Prabath
>
> On Tue, Apr 14, 2015 at 2:55 PM, John Bradley <ve7jtb@ve7jtb.com
> <mailto:ve7jtb@ve7jtb.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Most of the pub sub things I have seen use HTTP tra= nsport.=C2=A0 Do you
>=C2=A0 =C2=A0 =C2=A0have a pointer to the protocol?
>
>>=C2=A0 =C2=A0 =C2=A0On Apr 14, 2015, at 6:48 PM, Prabath Siriwarden= a <prabath@wso2.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:prabath@wso2.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks John for the pointer - will have look..<= br> >>
>>=C2=A0 =C2=A0 =C2=A0I am looking this for a pub/sub scenario..=C2= =A0 Having JWT binding
>>=C2=A0 =C2=A0 =C2=A0would benefit that..
>>
>>=C2=A0 =C2=A0 =C2=A0Also - why I want access token to be inside a J= WT is - when we
>>=C2=A0 =C2=A0 =C2=A0send a JSON payload in this case, we already ha= ve the JWT envelope
>>=C2=A0 =C2=A0 =C2=A0and the access token needs to be carried inside= ..
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks & regards,
>>=C2=A0 =C2=A0 =C2=A0-Prabath
>>
>>
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0On Tue, Apr 14, 2015 at 2:41 PM, John Bradley &= lt;ve7jtb@ve7jtb.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:ve7jtb@ve7jtb.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There is a OAuth binding to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SASL https://tools= .ietf.org/html/draft-ietf-kitten-sasl-oauth-19
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Google supports it for IMAP/SMTP,= =C2=A0 I think the latest iOS and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OSX mail client updates use it ra= ther than passwords for Google.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also noticed Outlook on Android= using it.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The access token might be a signe= d or encrypted JWT itself.=C2=A0 I
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0don=E2=80=99t know that wrapping = it again necessarily helps.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes we should have bindings to ot= her non http protocols.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is there something specific that = you are looking for that is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not covered by SASL?
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0John B.
>>
>>
>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Apr 14, 2015, at 6:21 PM, = Prabath Siriwardena
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<= a href=3D"mailto:prabath@wso2.com">prabath@wso2.com <mailto:prabath@wso2.com>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0At the moment we only HTTP bi= nding to transport the access
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token (please correct me if n= ot)..
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This creates a dependency on = the transport.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How about creating a JWT bind= ing for OAuth 2.0..? We can
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transport the access token as= an encrypted JWT header
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parameter..?
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks & Regards,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Prabath
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Twitter : @prabath
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LinkedIn : http://www.linked= in.com/in/prabathsiriwardena
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mobile : +1 650 625 7950 <t= el:%2B1%20650%20625%207950>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://blog.facilelogin.com <http://blog.facilelogin.co= m/>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://blog.api-security.org <http://blog.api-securi= ty.org/>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________= __________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@= ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0--
>>=C2=A0 =C2=A0 =C2=A0Thanks & Regards,
>>=C2=A0 =C2=A0 =C2=A0Prabath
>>
>>=C2=A0 =C2=A0 =C2=A0Twitter : @prabath
>>=C2=A0 =C2=A0 =C2=A0LinkedIn : http://www.linkedin.com/in/prabaths= iriwardena
>>
>>=C2=A0 =C2=A0 =C2=A0Mobile : +1 650 625 7950 <tel:%2B1%20650%2062= 5%207950>
>>
>>=C2=A0 =C2=A0 =C2=A0http://blog.facilelogin.com <http://blog.facilelogin.com/>
>>=C2=A0 =C2=A0 =C2=A0http://blog.api-security.org <http://blog.api-security.org/>
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950
>
> http://blog.= facilelogin.com
> http://blog= .api-security.org
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>




--
=
Thanks & Regards,<= br>Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com= /in/prabathsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.= com
http:= //blog.api-security.org
--001a11c1db349c7d6b0513c1ab5a-- From nobody Wed Apr 15 07:34:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1371B35A8 for ; Wed, 15 Apr 2015 07:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64kXeb3r4hp3 for ; Wed, 15 Apr 2015 07:34:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A7F1B35A5 for ; Wed, 15 Apr 2015 07:34:16 -0700 (PDT) Received: from [192.168.10.182] ([80.255.245.230]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfiFU-1Z3CV81Jrw-00NBIa; Wed, 15 Apr 2015 16:34:14 +0200 Message-ID: <552E76E4.70409@gmx.net> Date: Wed, 15 Apr 2015 16:34:12 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Prabath Siriwardena References: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> <552E1E60.8010602@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2iX8r5UdaOK2Uppqv6RrghldotXPgJtVV" X-Provags-ID: V03:K0:gUiR1ckZqwfON2RvyqnmLN2xtSjUp0K+Pdpb9TV37eYbK9ioCRh AUktkdtZSract3jIli3wSH/enFvX0rzVf4u7X8NVM7hH8jqcDXyI7LOUcobSwhhJQmCXS1W j15QSjBjceFiSddu93krmttLWYIbFsOY45YpC1BZTqfU6mhjK23mzVVebB9dNwZIkcEH/2J pBhxvs62ayl4X7HupWzCA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:34:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2iX8r5UdaOK2Uppqv6RrghldotXPgJtVV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Although I am not a huge fan of SOAP feel free to write a document and make it available to the group so that we can look at the details. On 04/15/2015 01:30 PM, Prabath Siriwardena wrote: > Hi Hannes, >=20 > I still think its equally important to have a transport independent > binding .. >=20 > If you look at the SOAP world, WS-Security is self-contained in the > message itself.. and SAML SOAP binding is also another example... >=20 > Thanks & regards, > -Prabath >=20 >=20 > On Wed, Apr 15, 2015 at 1:16 AM, Hannes Tschofenig > > wrote: >=20 > Hi Prabath, >=20 > the reason we have documents that describe the transport of bearer > tokens/proof-of-possession tokens over the different transports is = a > task is more than just conveying a JWT over some protocol. >=20 > There are various documents that specify the transport of OAuth acc= ess > tokens over some protocol: >=20 > * Bearer Tokens over HTTPS: > https://tools.ietf.org/html/rfc6750 >=20 > * Proof-of-Possession Tokens over TURN > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-1= 3 >=20 > * Bearer Tokens over SASL: > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 >=20 > * Bearer Tokens over CoAP: > https://tools.ietf.org/html/draft-tschofenig-ace-oauth-bt-01 >=20 > * OAuth over SIP: > https://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-02 >=20 > * Then, there is all the work on proof-of-possession tokens that > requires thoughts on how to tie the access token to the request (se= e > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 = or > token binding at > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-00) >=20 > If you look at these documents then you will see that the > characteristics of the underlying protocol matter a lot from a secu= rity > point of view. There are also encoding and discovery related aspect= s > that need to be taken into account as well. >=20 > If someone wants to figure out how to carry OAuth access tokens ove= r > MQTT then they will have to figure out whether there are some addit= ional > considerations to take into account. >=20 > What we should probably doing in this group is to write a guidance > document for using OAuth over <>. >=20 > Ciao > Hannes >=20 > On 04/15/2015 12:02 AM, Prabath Siriwardena wrote: > > It can be a JSON payload over JMS or even MQTT.. > > > > I have seen some effort to create an MQTT binding for OAuth 2.0 -= but > > then again for each transport we need to have a binding.. > > > > But - creating a message level binding would be much better IMHO.= =2E > > > > Thanks & regards, > > -Prabath > > > > On Tue, Apr 14, 2015 at 2:55 PM, John Bradley > > >> wrote: > > > > Most of the pub sub things I have seen use HTTP transport. D= o you > > have a pointer to the protocol? > > > >> On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena > >> >> wrote: > >> > >> Thanks John for the pointer - will have look.. > >> > >> I am looking this for a pub/sub scenario.. Having JWT bindi= ng > >> would benefit that.. > >> > >> Also - why I want access token to be inside a JWT is - when = we > >> send a JSON payload in this case, we already have the JWT en= velope > >> and the access token needs to be carried inside.. > >> > >> Thanks & regards, > >> -Prabath > >> > >> > >> > >> > >> > >> On Tue, Apr 14, 2015 at 2:41 PM, John Bradley > >> >> wrote= : > >> > >> There is a OAuth binding to > >> SASL https://tools.ietf.org/html/draft-ietf-kitten-sasl-= oauth-19 > >> > >> Google supports it for IMAP/SMTP, I think the latest iO= S and > >> OSX mail client updates use it rather than passwords for= Google. > >> I also noticed Outlook on Android using it. > >> > >> The access token might be a signed or encrypted JWT itse= lf. I > >> don=E2=80=99t know that wrapping it again necessarily he= lps. > >> > >> Yes we should have bindings to other non http protocols.= > >> > >> Is there something specific that you are looking for tha= t is > >> not covered by SASL? > >> > >> John B. > >> > >> > >> > >>> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena > >>> >> wrote: > >>> > >>> At the moment we only HTTP binding to transport the acc= ess > >>> token (please correct me if not).. > >>> > >>> This creates a dependency on the transport. > >>> > >>> How about creating a JWT binding for OAuth 2.0..? We ca= n > >>> transport the access token as an encrypted JWT header > >>> parameter..? > >>> > >>> > >>> Thanks & Regards, > >>> Prabath > >>> > >>> Twitter : @prabath > >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwarden= a > >>> > >>> Mobile : +1 650 625 7950 > > >>> > >>> http://blog.facilelogin.com > >>> http://blog.api-security.org > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> -- > >> Thanks & Regards, > >> Prabath > >> > >> Twitter : @prabath > >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > >> > >> Mobile : +1 650 625 7950 > > >> > >> http://blog.facilelogin.com > >> http://blog.api-security.org = > > > > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Twitter : @prabath > > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > > > Mobile : +1 650 625 7950 > > > > http://blog.facilelogin.com > > http://blog.api-security.org > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 >=20 >=20 >=20 > --=20 > Thanks & Regards, > Prabath >=20 > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >=20 > Mobile : +1 650 625 7950 >=20 > http://blog.facilelogin.com > http://blog.api-security.org --2iX8r5UdaOK2Uppqv6RrghldotXPgJtVV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVLnbkAAoJEGhJURNOOiAtyRMH/1OVghTLmrZU+au+ireE2UE9 vuz46DT5+or41V3tsYaF43atERXsnr/GPuRvWGhOV7quu7TLjZd488x64qtws0K/ ur7ofFqDSvibkq8RVvpWHtH9LvBCt1hGcbpZmtHAFL2VY1CT+mlDEBxPYAyaa5xo 2e6CLGJUG/yvO78am/SBu/rb9vaniu7guX8d65QgRnxYRwo1fGmF0de+pTED0QvP rfF2u6F0+cetMlAaoa1U+MRi0exqombHDDzX/aicE0TOGutWVkacu/Tf8/7pjeaO 0D66mRQOGIDnK8iYPUYUHFzmpEZJSPYL379x/43sNL70n+mqK2H+4nuRZFHd8vE= =WskD -----END PGP SIGNATURE----- --2iX8r5UdaOK2Uppqv6RrghldotXPgJtVV-- From nobody Wed Apr 15 13:05:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878AC1A1A58 for ; Wed, 15 Apr 2015 13:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQilg-GoEfeI for ; Wed, 15 Apr 2015 13:05:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0057.outbound.protection.outlook.com [65.55.169.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA05A1A1A48 for ; Wed, 15 Apr 2015 13:05:44 -0700 (PDT) Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (25.161.203.148) by BY1PR0201MB1029.namprd02.prod.outlook.com (25.161.203.147) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 20:05:42 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([25.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([25.161.203.148]) with mapi id 15.01.0136.026; Wed, 15 Apr 2015 20:05:42 +0000 From: Antonio Sanso To: OAuth WG Thread-Topic: Open redirect blog post Thread-Index: AQHQd7eMz5604Z3jR0GR46/Wn46+rQ== Date: Wed, 15 Apr 2015 20:05:41 +0000 Message-ID: <39DBF00E-8F1F-49A9-A35C-EDAE0D67184F@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.104.215.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(69234005)(106356001)(83716003)(99286002)(2900100001)(36756003)(62966003)(77156002)(106116001)(15975445007)(102836002)(54356999)(15188555004)(107886001)(229853001)(92566002)(50986999)(450100001)(82746002)(86362001)(122556002)(40100003)(2656002)(558084003)(110136001)(87936001)(66066001)(46102003)(19580395003)(93376004)(33656002)(569964003)(104396002)(15302535012); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029; x-forefront-prvs: 0547116B72 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 20:05:41.8299 (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: Subject: [OAUTH-WG] Open redirect blog post X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 20:05:46 -0000 FYI http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oau= th-20.html thanks=20 antonio= From nobody Thu Apr 16 08:05:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1123D1A0151 for ; Thu, 16 Apr 2015 08:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8HceRZQtNij for ; Thu, 16 Apr 2015 08:05:05 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9DD1A00E0 for ; Thu, 16 Apr 2015 08:04:48 -0700 (PDT) Received: by qgej70 with SMTP id j70so7039264qge.2 for ; Thu, 16 Apr 2015 08:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rMdQFnBu+mbu7ZNT6muW+jynS9h/McYZy/02fiuz+S4=; b=I7q73mLZptRpcx3zX5sm/fSXE45W3vxy+WAYl0Jmq99fchcZTrrhro5JwYMhLIuesX k6P/q7ftltIudTrAFtMQgf4KHE8bveaqIK0FZVyMcUP6Q8EW3XaH9nhjylmYSvQbUlMM Ty5jOK7F++BKc8bDp6AL0B4QTFtGiLLpWoYiYaypWE6PPaKJQqpsGeHeCvtJm8Tj0fQu BjfaYcq/29SQUqsHxBHnydWYpxyZtXT7K7b6uNNe6i+OH5n6IWdj4kHO7QEjJD1QCEGa eB32Dp4fkOkk1G75h+96uob3SSFaEASxXGtpNNsDyMoZUFuVJwSNWuaIQQ/z5Q02syLZ SJJQ== MIME-Version: 1.0 X-Received: by 10.55.26.210 with SMTP id l79mr63767767qkh.31.1429196687955; Thu, 16 Apr 2015 08:04:47 -0700 (PDT) Received: by 10.140.48.11 with HTTP; Thu, 16 Apr 2015 08:04:47 -0700 (PDT) Date: Thu, 16 Apr 2015 11:04:47 -0400 Message-ID: From: hank williams To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11441c5ce65e520513d8c83f Archived-At: Subject: [OAUTH-WG] Does anyone know if AOL currently supports OAuth2? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:05:06 -0000 --001a11441c5ce65e520513d8c83f Content-Type: text/plain; charset=UTF-8 Sorry for this user focused question but I'm not sure where else to turn. I have found a few pages on the AOL website that talk about it but no mechanism for provisioning a developer ID. There is a mention on stackoverflow that the feature has been discontinued. I've sent emails to some folks at AOL that I thought might know with no response, so I thought someone here might be able to point me in the right direction. --001a11441c5ce65e520513d8c83f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for this user focused question but I'm not = sure where else to turn.

I have found a few pages on th= e AOL website that talk about it but no mechanism for provisioning a develo= per ID. There is a mention on stackoverflow that the feature has been disco= ntinued. I've sent emails to some folks at AOL that I thought might kno= w with no response, so I thought someone here might be able to point me in = the right direction.
--001a11441c5ce65e520513d8c83f-- From nobody Thu Apr 16 09:06:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1FD1A8AB9 for ; Thu, 16 Apr 2015 09:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPii_BdL31NO for ; Thu, 16 Apr 2015 09:06:08 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81F31A8915 for ; Thu, 16 Apr 2015 09:06:08 -0700 (PDT) Received: by oift201 with SMTP id t201so51485688oif.3 for ; Thu, 16 Apr 2015 09:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yMH/vyG+vPgRLi1g6+1/nw9AnzZU/vHDaOvy/RwS7LM=; b=XL/Vb+JV8vh1d1SLTNyADz4fZ8iXTQ0maUn40pQQuBULYICzT2wgqajfc7r6wJlke7 VefUoM90CGsKpD7FnIvgDAKSJVixTgxIBOzj0jlRVKhLHj6nizspOsnXboCQIPhGvcKy lkPLsGh1LePITdDtUggH6CU8LTq+ikOLisecw= 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:content-type; bh=yMH/vyG+vPgRLi1g6+1/nw9AnzZU/vHDaOvy/RwS7LM=; b=fhw8oE9SEPwfN9OkQVogn6g50/JY5BsXXey6ERS2s6AqJokLc1expeq8Py7hBuZ0I+ /sJFjDFFNsayFvc6MXCmw4EGSwzBYUtQWxRDr+rcfYwU/cPnSwEnFh1BMtMFj2VUNz95 QFFwmrJdOcFM3NL2hMMrfR7+XB4JuSJlFarcwKwgule0LHWwuizk1Sp0ATtjzag98cLD IU3/DbDoP3uxsIagT0uG84XfzKMb3RydNpxqP24A8P1ZieI6PnrwFmxfWvD8NFIk1BL4 xl9vSKTMGC4qwXviXWEP2qIAHjTId1Q9qM+2FOmG8kSV8N3Q+Qi/cvHW8AO3GsjslbTj N1HQ== X-Gm-Message-State: ALoCoQkkBGOMXkkqbf+UgmJhOG9JVYDZ4utE4MZG4ydbDHjgUaZpojO99j3JWAt2hXl7/nf3FDtx MIME-Version: 1.0 X-Received: by 10.202.230.11 with SMTP id d11mr20801545oih.6.1429200368002; Thu, 16 Apr 2015 09:06:08 -0700 (PDT) Received: by 10.202.72.198 with HTTP; Thu, 16 Apr 2015 09:06:07 -0700 (PDT) In-Reply-To: <552E76E4.70409@gmx.net> References: <422C5670-7D2D-4E1C-9E06-74CCB9054260@ve7jtb.com> <552E1E60.8010602@gmx.net> <552E76E4.70409@gmx.net> Date: Thu, 16 Apr 2015 09:06:07 -0700 Message-ID: From: Prabath Siriwardena To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1140761a3f7d490513d9a4a6 Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] JWT binding for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 16:06:12 -0000 --001a1140761a3f7d490513d9a4a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure - I will come up with draft proposal for this... Thanks & regards, -Prabath On Wed, Apr 15, 2015 at 7:34 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Although I am not a huge fan of SOAP feel free to write a document and > make it available to the group so that we can look at the details. > > On 04/15/2015 01:30 PM, Prabath Siriwardena wrote: > > Hi Hannes, > > > > I still think its equally important to have a transport independent > > binding .. > > > > If you look at the SOAP world, WS-Security is self-contained in the > > message itself.. and SAML SOAP binding is also another example... > > > > Thanks & regards, > > -Prabath > > > > > > On Wed, Apr 15, 2015 at 1:16 AM, Hannes Tschofenig > > > wrote: > > > > Hi Prabath, > > > > the reason we have documents that describe the transport of bearer > > tokens/proof-of-possession tokens over the different transports is = a > > task is more than just conveying a JWT over some protocol. > > > > There are various documents that specify the transport of OAuth > access > > tokens over some protocol: > > > > * Bearer Tokens over HTTPS: > > https://tools.ietf.org/html/rfc6750 > > > > * Proof-of-Possession Tokens over TURN > > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-1= 3 > > > > * Bearer Tokens over SASL: > > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 > > > > * Bearer Tokens over CoAP: > > https://tools.ietf.org/html/draft-tschofenig-ace-oauth-bt-01 > > > > * OAuth over SIP: > > https://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-02 > > > > * Then, there is all the work on proof-of-possession tokens that > > requires thoughts on how to tie the access token to the request (se= e > > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 > or > > token binding at > > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-00) > > > > If you look at these documents then you will see that the > > characteristics of the underlying protocol matter a lot from a > security > > point of view. There are also encoding and discovery related aspect= s > > that need to be taken into account as well. > > > > If someone wants to figure out how to carry OAuth access tokens ove= r > > MQTT then they will have to figure out whether there are some > additional > > considerations to take into account. > > > > What we should probably doing in this group is to write a guidance > > document for using OAuth over <>. > > > > Ciao > > Hannes > > > > On 04/15/2015 12:02 AM, Prabath Siriwardena wrote: > > > It can be a JSON payload over JMS or even MQTT.. > > > > > > I have seen some effort to create an MQTT binding for OAuth 2.0 - > but > > > then again for each transport we need to have a binding.. > > > > > > But - creating a message level binding would be much better IMHO.= . > > > > > > Thanks & regards, > > > -Prabath > > > > > > On Tue, Apr 14, 2015 at 2:55 PM, John Bradley > > > >> wrote: > > > > > > Most of the pub sub things I have seen use HTTP transport. D= o > you > > > have a pointer to the protocol? > > > > > >> On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena < > prabath@wso2.com > > >> >> wrote: > > >> > > >> Thanks John for the pointer - will have look.. > > >> > > >> I am looking this for a pub/sub scenario.. Having JWT bindi= ng > > >> would benefit that.. > > >> > > >> Also - why I want access token to be inside a JWT is - when = we > > >> send a JSON payload in this case, we already have the JWT > envelope > > >> and the access token needs to be carried inside.. > > >> > > >> Thanks & regards, > > >> -Prabath > > >> > > >> > > >> > > >> > > >> > > >> On Tue, Apr 14, 2015 at 2:41 PM, John Bradley < > ve7jtb@ve7jtb.com > > >> >> wrote= : > > >> > > >> There is a OAuth binding to > > >> SASL > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 > > >> > > >> Google supports it for IMAP/SMTP, I think the latest iO= S > and > > >> OSX mail client updates use it rather than passwords for > Google. > > >> I also noticed Outlook on Android using it. > > >> > > >> The access token might be a signed or encrypted JWT > itself. I > > >> don=E2=80=99t know that wrapping it again necessarily he= lps. > > >> > > >> Yes we should have bindings to other non http protocols. > > >> > > >> Is there something specific that you are looking for tha= t > is > > >> not covered by SASL? > > >> > > >> John B. > > >> > > >> > > >> > > >>> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena > > >>> prabath@wso2.com > > >> wrote: > > >>> > > >>> At the moment we only HTTP binding to transport the > access > > >>> token (please correct me if not).. > > >>> > > >>> This creates a dependency on the transport. > > >>> > > >>> How about creating a JWT binding for OAuth 2.0..? We ca= n > > >>> transport the access token as an encrypted JWT header > > >>> parameter..? > > >>> > > >>> > > >>> Thanks & Regards, > > >>> Prabath > > >>> > > >>> Twitter : @prabath > > >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwarden= a > > >>> > > >>> Mobile : +1 650 625 7950 > > > > >>> > > >>> http://blog.facilelogin.com < > http://blog.facilelogin.com/> > > >>> http://blog.api-security.org < > http://blog.api-security.org/> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> OAuth@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >> > > >> > > >> > > >> > > >> -- > > >> Thanks & Regards, > > >> Prabath > > >> > > >> Twitter : @prabath > > >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > >> > > >> Mobile : +1 650 625 7950 > > > > >> > > >> http://blog.facilelogin.com > > >> http://blog.api-security.org > > > > > > > > > > > > > > > -- > > > Thanks & Regards, > > > Prabath > > > > > > Twitter : @prabath > > > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > > > > > Mobile : +1 650 625 7950 > > > > > > http://blog.facilelogin.com > > > http://blog.api-security.org > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Twitter : @prabath > > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > > > Mobile : +1 650 625 7950 > > > > http://blog.facilelogin.com > > http://blog.api-security.org > > --=20 Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org --001a1140761a3f7d490513d9a4a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure - I will come up with draft proposal for this...
<= div>
Thanks & regards,
-Prabath

On Wed, Apr 15, 2015 = at 7:34 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Although I am not a huge fan= of SOAP feel free to write a document and
make it available to the group so that we can look at the details.

On 04/15/2015 01:30 PM, Prabath Siriwardena wrote:
> Hi Hannes,
>
> I still think its equally important to have a transport independent > binding ..
>
> If you look at the SOAP world, WS-Security is self-contained in the > message itself.. and SAML SOAP binding is also another example...
>
> Thanks & regards,
> -Prabath
>
>
> On Wed, Apr 15, 2015 at 1:16 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Prabath,
>
>=C2=A0 =C2=A0 =C2=A0the reason we have documents that describe the tran= sport of bearer
>=C2=A0 =C2=A0 =C2=A0tokens/proof-of-possession tokens over the differen= t transports is a
>=C2=A0 =C2=A0 =C2=A0task is more than just conveying a JWT over some pr= otocol.
>
>=C2=A0 =C2=A0 =C2=A0There are various documents that specify the transp= ort of OAuth access
>=C2=A0 =C2=A0 =C2=A0tokens over some protocol:
>
>=C2=A0 =C2=A0 =C2=A0* Bearer Tokens over HTTPS:
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/rfc6750
>
>=C2=A0 =C2=A0 =C2=A0* Proof-of-Possession Tokens over TURN
>=C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/= draft-ietf-tram-turn-third-party-authz-13
>
>=C2=A0 =C2=A0 =C2=A0* Bearer Tokens over SASL:
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ie= tf-kitten-sasl-oauth-19
>
>=C2=A0 =C2=A0 =C2=A0* Bearer Tokens over CoAP:
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-t= schofenig-ace-oauth-bt-01
>
>=C2=A0 =C2=A0 =C2=A0* OAuth over SIP:
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-y= usef-sipcore-sip-oauth-02
>
>=C2=A0 =C2=A0 =C2=A0* Then, there is all the work on proof-of-possessio= n tokens that
>=C2=A0 =C2=A0 =C2=A0requires thoughts on how to tie the access token to= the request (see
>=C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dr= aft-ietf-oauth-signed-http-request-01 or
>=C2=A0 =C2=A0 =C2=A0token binding at
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-iet= f-tokbind-protocol-00)
>
>=C2=A0 =C2=A0 =C2=A0If you look at these documents then you will see th= at the
>=C2=A0 =C2=A0 =C2=A0characteristics of the underlying protocol matter a= lot from a security
>=C2=A0 =C2=A0 =C2=A0point of view. There are also encoding and discover= y related aspects
>=C2=A0 =C2=A0 =C2=A0that need to be taken into account as well.
>
>=C2=A0 =C2=A0 =C2=A0If someone wants to figure out how to carry OAuth a= ccess tokens over
>=C2=A0 =C2=A0 =C2=A0MQTT then they will have to figure out whether ther= e are some additional
>=C2=A0 =C2=A0 =C2=A0considerations to take into account.
>
>=C2=A0 =C2=A0 =C2=A0What we should probably doing in this group is to w= rite a guidance
>=C2=A0 =C2=A0 =C2=A0document for using OAuth over <<foo>>.<= br> >
>=C2=A0 =C2=A0 =C2=A0Ciao
>=C2=A0 =C2=A0 =C2=A0Hannes
>
>=C2=A0 =C2=A0 =C2=A0On 04/15/2015 12:02 AM, Prabath Siriwardena wrote:<= br> >=C2=A0 =C2=A0 =C2=A0> It can be a JSON payload over JMS or even MQTT= ..
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I have seen some effort to create an MQTT bind= ing for OAuth 2.0 - but
>=C2=A0 =C2=A0 =C2=A0> then again for each transport we need to have = a binding..
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> But - creating a message level binding would b= e much better IMHO..
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks & regards,
>=C2=A0 =C2=A0 =C2=A0> -Prabath
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, Apr 14, 2015 at 2:55 PM, John Bradley = <ve7jtb@ve7jtb.com <mailto:<= a href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com>
>=C2=A0 =C2=A0 =C2=A0> <mailto:ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Most of the pub sub things = I have seen use HTTP transport.=C2=A0 Do you
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0have a pointer to the proto= col?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0On Apr 14, 2015, at 6:4= 8 PM, Prabath Siriwardena <prabath@w= so2.com <mailto:prabath@wso2.com= >
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2= =A0<mailto:prabath@wso2.com <= mailto:prabath@wso2.com>>>= wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0Thanks John for the poi= nter - will have look..
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0I am looking this for a= pub/sub scenario..=C2=A0 Having JWT binding
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0would benefit that.. >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0Also - why I want acces= s token to be inside a JWT is - when we
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0send a JSON payload in = this case, we already have the JWT envelope
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0and the access token ne= eds to be carried inside..
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0Thanks & regards, >=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0-Prabath
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0On Tue, Apr 14, 2015 at= 2:41 PM, John Bradley <ve7jtb@ve7j= tb.com <mailto:ve7jtb@ve7jtb.co= m>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2= =A0<mailto:ve7jtb@ve7jtb.com &l= t;mailto:ve7jtb@ve7jtb.com>>= > wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There is = a OAuth binding to
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SASL https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19=
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Google su= pports it for IMAP/SMTP,=C2=A0 I think the latest iOS and
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OSX mail = client updates use it rather than passwords for Google.
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also no= ticed Outlook on Android using it.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The acces= s token might be a signed or encrypted JWT itself.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0don=E2=80= =99t know that wrapping it again necessarily helps.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes we sh= ould have bindings to other non http protocols.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is there = something specific that you are looking for that is
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not cover= ed by SASL?
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0John B. >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Ap= r 14, 2015, at 6:21 PM, Prabath Siriwardena
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<prabath@wso2.com <mailto:= prabath@wso2.com> <mailto:prabath@wso2.com
>=C2=A0 =C2=A0 =C2=A0<mailto:prabath@wso2.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0At th= e moment we only HTTP binding to transport the access
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token= (please correct me if not)..
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This = creates a dependency on the transport.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How a= bout creating a JWT binding for OAuth 2.0..? We can
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trans= port the access token as an encrypted JWT header
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0param= eter..?
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank= s & Regards,
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Praba= th
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Twitt= er : @prabath
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Linke= dIn : http://www.linkedin.com/in/prabathsiriwardena
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mobil= e : +1 650 6= 25 7950 <tel:%2B1%20650%20625%207950>
>=C2=A0 =C2=A0 =C2=A0<tel:%2B1%20650%20625%207950>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://blog.facilelogi= n.com <ht= tp://blog.facilelogin.com/>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://blog.api-secur= ity.org <http://blog.api-security.org/>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____= __________________________________________
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth= mailing list
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:OAuth@ietf.org <mailto:OAuth@ietf= .org>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/oauth
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0Thanks & Regards, >=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0Prabath
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0Twitter : @prabath
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0LinkedIn : http://www.= linkedin.com/in/prabathsiriwardena
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0Mobile : +1 650 625 7950 <te= l:%2B1%20650%20625%207950>
>=C2=A0 =C2=A0 =C2=A0<tel:%2B1%20650%20625%207950>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0http://blog.facilelogin.com <http://blog.facilelo= gin.com/>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0http://blog.api-security.org <http://blog.api-s= ecurity.org/>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> --
>=C2=A0 =C2=A0 =C2=A0> Thanks & Regards,
>=C2=A0 =C2=A0 =C2=A0> Prabath
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Twitter : @prabath
>=C2=A0 =C2=A0 =C2=A0> LinkedIn : http://www.linkedin.com/in/prabath= siriwardena
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Mobile : +1 650 625 7950 <t= el:%2B1%20650%20625%207950>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> http://blog.facilelogin.com
>=C2=A0 =C2=A0 =C2=A0> http://blog.api-security.org
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0> OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0> OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listinfo/oauth=
>=C2=A0 =C2=A0 =C2=A0>
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950
>
> http:= //blog.facilelogin.com
> http://blog= .api-security.org




--
Thanks & Regards,
Prabath=

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabat= hsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.com
<= a href=3D"http://blog.api-security.org" target=3D"_blank">http://blog.api-s= ecurity.org
--001a1140761a3f7d490513d9a4a6-- From nobody Sat Apr 18 08:39:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06A71A6F10 for ; Sat, 18 Apr 2015 08:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0s6vk5VVLo1 for ; Sat, 18 Apr 2015 08:39:31 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 4F0091A00C8 for ; Sat, 18 Apr 2015 08:39:31 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so102826763lbb.0 for ; Sat, 18 Apr 2015 08:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HR/YhY5Uc2kHvf4+F4MrPxus1S2Z8IyNVPdAluKpC0k=; b=tjRZWe/TmHQTmL6OWCT1XkGeFCdlqxpSrd+bjZCBvXQKXaB1BSvurRDEM6XBtgnDtd vtJXLdSPHJ+rWRAsOVNfzRcOgAYBbjhGnNCehrC+s08E0JNP5318gmKeTgPJpfJVOppr kus7j+OGNvEcb3Er0MpdhiKVVmPN3FSEDB1Vvk3s/5tOuzgyvfTCbkwCrWeSI5gi8fOs lakmY/NNu+WGhI12dF62elx61XH7cFOCTVkpXcdhS+7ANM1SOG4x4xRWE57jbbJ8O6oU 74j/PAradQKS2e3XS3jH7Gj6+L1poG5x0fdG+G0gSKlFEcGtqL2uWDMAqIL+lvxJD5Oq dWkw== MIME-Version: 1.0 X-Received: by 10.152.178.197 with SMTP id da5mr8970904lac.56.1429371569604; Sat, 18 Apr 2015 08:39:29 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Sat, 18 Apr 2015 08:39:29 -0700 (PDT) Date: Sat, 18 Apr 2015 11:39:29 -0400 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11340c68a88f3c051401801c Archived-At: Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 15:39:33 -0000 --001a11340c68a88f3c051401801c Content-Type: text/plain; charset=UTF-8 Hello, I just reviewed draft-ietf-oauth-spop-10 and am thinking more should be said about TLS 1.2 in the security recommendations. I see that it is recommended through RFC6819 that just says: Attacks can be mitigated by using transport-layer mechanisms such as TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec VPNs [RFC4301], may be considered as well. And more has been said in recent publications. Since this particular draft is addressing a threat exposed when TLS is not in use, the language from the last draft would be better, requiring at least TLS 1.2 and referring to the TLS BCP. The only other point from my review is a nit: At the end of section 4.4, there should be quotes around both instances of "plain". Once this has been addressed, we can start IETF last call. Thank you! -- Best regards, Kathleen --001a11340c68a88f3c051401801c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I just reviewed=C2=A0draft-ietf-= oauth-spop-10 and am thinking more should be said about TLS 1.2 in the secu= rity recommendations.=C2=A0 I see that it is recommended through RFC6819 th= at just says:

=C2=A0Attacks can be mitigated by using transport-lay= er mechanisms such as
=C2=A0 =C2=A0TLS [RFC5246].=C2=A0 A virtual privat= e network (VPN), e.g., based on IPsec
=C2=A0 =C2=A0VPNs [RFC4301], may b= e considered as well.


And more has been said in recent publicati= ons.=C2=A0 Since this particular draft is addressing a threat exposed when = TLS is not in use, the language from the last draft would be better, requir= ing at least TLS 1.2 and referring to the TLS BCP.

The only other point from my review is a nit:
At the end of sect= ion 4.4, there should be quotes around both instances of "plain".=

Once this has been addressed, we can start IE= TF last call.

Thank you!
--

Best regards,
Ka= thleen
--001a11340c68a88f3c051401801c-- From nobody Sun Apr 19 03:01:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776381A0373 for ; Sun, 19 Apr 2015 03:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87HMyTJywq9R for ; Sun, 19 Apr 2015 03:01:21 -0700 (PDT) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9D11A0370 for ; Sun, 19 Apr 2015 03:01:20 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa12-10.prod.phx3.secureserver.net with id Hm1K1q00A15ZTut01m1KHV; Sun, 19 Apr 2015 03:01:20 -0700 Message-ID: <55337CEE.2090605@connect2id.com> Date: Sun, 19 Apr 2015 13:01:18 +0300 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [OAUTH-WG] Disable JWK "use" parameter for octet sequence keys? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 10:01:22 -0000 A developer working with the Nimbus jose+jwt library raised the question whether setting of the public "use" [1] parameter should be disabled for JWKs of type "oct". This appears to make sense, even though the JWA spec [2] doesn't mention it. Is this correct? Thanks, Vladimir [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-40#section-4.= 2 [2] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section= -6.4 From nobody Sun Apr 19 16:01:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23471A00C0 for ; Sun, 19 Apr 2015 16:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHlqdoSKFfcZ for ; Sun, 19 Apr 2015 16:01:08 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 44CC21A00BF for ; Sun, 19 Apr 2015 16:01:08 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so117984259lbb.0 for ; Sun, 19 Apr 2015 16:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OkZFiW5kBXusDBarUk4IPr5Pm8VM8HXLlvhmDKBeGks=; b=htCE1IzGCnFJYwr/RQT2hLnCM0W6XfR0YI8z0CPph62T1GHrQM9622DYrRzhYV37eH NycUYFoZ9gGvnW1nj4iSGtxVIe9wlRlBWLbnrjLyfhoeG/T2hVtoQrtrwxTpKQiQGeuz S+1ivSJ7TN3lMwRY/BUqOiYf4jztyL5hOOIOv53lzBZ9gqYx3dqxr5p/Tu9cVVHtoUCT imVkgpW3+FiSFzRPvudq1/7qn6jYjkpp21moHgnYYG+63BxDuFxsfrBJBaJGKFThf7Rn aNKg/bETxcylsiVdsOzHLzEbhP4C4qDSSY5qOl5RpZFUFGETl43EMcNfV6d2e7gyC+Fl bSpQ== MIME-Version: 1.0 X-Received: by 10.152.19.199 with SMTP id h7mr13559722lae.32.1429484466701; Sun, 19 Apr 2015 16:01:06 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Sun, 19 Apr 2015 16:01:06 -0700 (PDT) Date: Sun, 19 Apr 2015 19:01:06 -0400 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=089e014942aad98a6d05141bc939 Archived-At: Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-introspection-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 23:01:10 -0000 --089e014942aad98a6d05141bc939 Content-Type: text/plain; charset=UTF-8 Hello, Thank you for your work on draft-ietf-oauth-introspection-07. The security considerations appear to be addressed well and I was glad to see how a response is handled when the response code is false, to not reveal information as to why. The privacy considerations look good, but I do have another question that should be addressed in the draft in regard to privacy. Section 2.1 says an IP address (or something else) might be used to provide context of the query, the authorization server could have other information about the client. It would be good to mention privacy related considerations for the client in this case in addition to what gets returned in the Introspection Response (already covered). Thank you. -- Best regards, Kathleen --089e014942aad98a6d05141bc939 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thank you for your work on=C2=A0= draft-ietf-oauth-introspection-07.=C2=A0 The security considerations appear= to be addressed well and I was glad to see how a response is handled when = the response code is false, to not reveal information as to why.
=
The privacy considerations look good, but I do have another = question that should be addressed in the draft in regard to privacy.
<= div>
Section 2.1 says an IP address (or something else) = might be used to provide context of the query, the authorization server cou= ld have other information about the client.=C2=A0 It would be good to menti= on privacy related considerations for the client in this case in addition t= o what gets returned in the Introspection Response (already covered).
=

Thank you.


--

Best regards,
<= div>Kathleen
--089e014942aad98a6d05141bc939-- From nobody Mon Apr 20 05:25:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791011A1AC9 for ; Mon, 20 Apr 2015 05:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yjet2Iix244D for ; Mon, 20 Apr 2015 05:24:58 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F013A1A1AB9 for ; Mon, 20 Apr 2015 05:24:57 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-8c-5534f017d4de 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id CB.03.03678.710F4355; Mon, 20 Apr 2015 08:24:55 -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 t3KCOtaQ023545; Mon, 20 Apr 2015 08:24:55 -0400 Received: from [192.168.128.56] (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 t3KCOrpd023365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 08:24:54 -0400 Message-ID: <5534F011.8030200@mit.edu> Date: Mon, 20 Apr 2015 08:24:49 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , "oauth@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080102090901090600060009" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0RX/YBJqsHi3tUXDznyLk29fsTkw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGZvmORUs16zY1v+VrYHxq1wXIyeHhICJxOxd u1khbDGJC/fWs3UxcnEICSxmkjjx+jkrhLORUeLZzG5mCOc2k0TL+1vsIC28AmoS37ftZAGx WQRUJRY2nQQbxQZkT1/TwgRiiwpESUz8eogFol5Q4uTMJ2C2iECKxOXeJ8wgtrCAm8TBr3PA ZgoJBEjMOfiBEcTmFAiUePPkD9hMZoEwid+bn7FOYOSfhWTULCQpCNtW4s7c3cwQtrzE9rdz oGxdiUXbVrDDxJu3zmZewMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIzis XVR3ME44pHSIUYCDUYmH1/GVSagQa2JZcWXuIUZJDiYlUV79B0AhvqT8lMqMxOKM+KLSnNTi Q4wSHMxKIrxvrwDleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeG+9 A2oULEpNT61Iy8wpQUgzcXCCDOcBGs75HmR4cUFibnFmOkT+FKOilDjvCpBmAZBERmkeXC8s 7bxiFAd6RZg3CKSdB5iy4LpfAQ1mAhoctw1scEkiQkqqgXF5kP8+HzvmCNeu0vPFylMOzSjm ODDhhlnmtY3XWXLMTpRdOds6vV2/PdNkT3ym3f/bOz7VCHRMLmSxMSlWf7DOb/3XZDffjulP QvJrEi+7SicKic5vFQ8VP+O1s/QU389brM5VV8v2sCSbmHSnKx6Pc9xous9ryrtcwZuPqvRc 5DZNktr5V4mlOCPRUIu5qDgRAAoc6L0WAwAA Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-introspection-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 12:25:00 -0000 This is a multi-part message in MIME format. --------------080102090901090600060009 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Kathleen, Thanks for the update. How would we best handle this situation, since it's really referring to additional information that's outside the scope of the interoperable core? Since we're not specifying what the data is, we're not really in a position to say what the concerns are in a concrete manner. I'm thinking a sentence or two like this in the privacy considerations section: If the protected resource sends additional information about the client's request to the authorization server using an extension of this specification, such as the client's IP address or other information, such information could have have additional privacy considerations. -- Justin On 4/19/2015 7:01 PM, Kathleen Moriarty wrote: > Hello, > > Thank you for your work on draft-ietf-oauth-introspection-07. The > security considerations appear to be addressed well and I was glad to > see how a response is handled when the response code is false, to not > reveal information as to why. > > The privacy considerations look good, but I do have another question > that should be addressed in the draft in regard to privacy. > > Section 2.1 says an IP address (or something else) might be used to > provide context of the query, the authorization server could have > other information about the client. It would be good to mention > privacy related considerations for the client in this case in addition > to what gets returned in the Introspection Response (already covered). > > Thank you. > > > -- > > Best regards, > Kathleen > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080102090901090600060009 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Kathleen,

Thanks for the update. How would we best handle this situation, since it's really referring to additional information that's outside the scope of the interoperable core? Since we're not specifying what the data is, we're not really in a position to say what the concerns are in a concrete manner. I'm thinking a sentence or two like this in the privacy considerations section:

If the protected resource sends additional information about the client's request to the authorization server using an extension of this specification, such as the client's IP address or other information, such information could have have additional privacy considerations.


-- Justin

On 4/19/2015 7:01 PM, Kathleen Moriarty wrote:
Hello,

Thank you for your work on draft-ietf-oauth-introspection-07.  The security considerations appear to be addressed well and I was glad to see how a response is handled when the response code is false, to not reveal information as to why.

The privacy considerations look good, but I do have another question that should be addressed in the draft in regard to privacy.

Section 2.1 says an IP address (or something else) might be used to provide context of the query, the authorization server could have other information about the client.  It would be good to mention privacy related considerations for the client in this case in addition to what gets returned in the Introspection Response (already covered).

Thank you.


--

Best regards,
Kathleen


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

--------------080102090901090600060009-- From nobody Mon Apr 20 06:03:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D021AC42B for ; Mon, 20 Apr 2015 06:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ckwFyhhmX1M for ; Mon, 20 Apr 2015 06:03:54 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::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 B87C11AC407 for ; Mon, 20 Apr 2015 06:03:53 -0700 (PDT) Received: by lagv1 with SMTP id v1so126170573lag.3 for ; Mon, 20 Apr 2015 06:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pNnfnkgvckh83SmQWHKsw8MrSAURdLXqFWJTQhosxf0=; b=PfrlBgzH/D4zbiVjboesE2Lv9zidJMMw5sqN2Ig4KWWMKBQX6ferWLd9fXHo/Y25oE HUF6Lt2fRZ9yckkxWYbfe2lJejQdNkoU7jQVM+rv7oIb5wViMm+dejra1r70lvpiL67F gZBqe3o+nMfvIlBNETbYVE/qeUrzVPFEB8I6+nN7tmjF3HIiX9Os/3u6BVUCqS3rjzql R/tb/DPR1RPl/BeCtEST5oEGqXOZHZt0rChg3IJV8FRBAmmuw0EdGjbJYL/7B6wDlrOg ZMXjPSdMezTrGwFJTDHEGIyVk8Ikm416NcMoqunzx/ht61Pda7/q7fGih3HensmyAQi8 NLGA== MIME-Version: 1.0 X-Received: by 10.152.27.194 with SMTP id v2mr15276510lag.75.1429535032218; Mon, 20 Apr 2015 06:03:52 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Mon, 20 Apr 2015 06:03:52 -0700 (PDT) In-Reply-To: <5534F011.8030200@mit.edu> References: <5534F011.8030200@mit.edu> Date: Mon, 20 Apr 2015 09:03:52 -0400 Message-ID: From: Kathleen Moriarty To: Justin Richer Content-Type: multipart/alternative; boundary=089e0158c2acca1a420514278f12 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-introspection-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:03:56 -0000 --089e0158c2acca1a420514278f12 Content-Type: text/plain; charset=UTF-8 Hi Justin, On Mon, Apr 20, 2015 at 8:24 AM, Justin Richer wrote: > Kathleen, > > Thanks for the update. How would we best handle this situation, since it's > really referring to additional information that's outside the scope of the > interoperable core? Since we're not specifying what the data is, we're not > really in a position to say what the concerns are in a concrete manner. I'm > thinking a sentence or two like this in the privacy considerations section: > > If the protected resource sends additional information about the client's > request to the authorization server using an extension of this > specification, such as the client's IP address or other information, such > information could have have additional privacy considerations. > > I think that looks good and you may want to say it is out-of scope for this draft so no one asks why you didn't go deeper. Let me know once it is ready and I'll kick off last call. Thanks. Kathleen > > > -- Justin > > > On 4/19/2015 7:01 PM, Kathleen Moriarty wrote: > > Hello, > > Thank you for your work on draft-ietf-oauth-introspection-07. The > security considerations appear to be addressed well and I was glad to see > how a response is handled when the response code is false, to not reveal > information as to why. > > The privacy considerations look good, but I do have another question > that should be addressed in the draft in regard to privacy. > > Section 2.1 says an IP address (or something else) might be used to > provide context of the query, the authorization server could have other > information about the client. It would be good to mention privacy related > considerations for the client in this case in addition to what gets > returned in the Introspection Response (already covered). > > Thank you. > > > -- > > Best regards, > Kathleen > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- Best regards, Kathleen --089e0158c2acca1a420514278f12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Justin,

On Mon, Apr 20, 2015 at 8:24 AM, Justin Richer <jricher@mit.ed= u> wrote:
=20 =20 =20
Kathleen,

Thanks for the update. How would we best handle this situation, since it's really referring to additional information that's ou= tside the scope of the interoperable core? Since we're not specifying wha= t the data is, we're not really in a position to say what the concern= s are in a concrete manner. I'm thinking a sentence or two like this in the privacy considerations section:

If the protected resource sends additional information about the client's request to the authorization server using an extension of this specification, such as the client's IP address or other information, such information could have have additional privacy considerations.

<= /div>
I think that looks good and you may want to say it is out-of scop= e for this draft so no one asks why you didn't go deeper.
Let me know once it is ready and I'll kick off last call.

Thanks.
Kathleen=C2=A0


-- Justin


On 4/19/2015 7:01 PM, Kathleen Moriarty wrote:
=20
Hello,

Thank you for your work on=C2=A0draft-ietf-oauth-introspection-07.=C2=A0 The security considerations appear to be addressed well and I was glad to see how a response is handled when the response code is false, to not reveal information as to why.

The privacy considerations look good, but I do have another question that should be addressed in the draft in regard to privacy.

Section 2.1 says an IP address (or something else) might be used to provide context of the query, the authorization server could have other information about the client.=C2=A0 It would be good to mention privacy related considerations for the client in this case in addition to what gets returned in the Introspection Response (already covered).

Thank you.


--

Best regards,
Kathleen


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




--

Best regards,
Kath= leen
--089e0158c2acca1a420514278f12-- From nobody Mon Apr 20 11:08:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1567A1B2CD4 for ; Mon, 20 Apr 2015 11:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9NzhpQG1Eba for ; Mon, 20 Apr 2015 11:08:03 -0700 (PDT) Received: from mail-ig0-f170.google.com (na3sys009aog104.obsmtp.com [74.125.149.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E631B2CD9 for ; Mon, 20 Apr 2015 11:08:02 -0700 (PDT) Received: from mail-ig0-f170.google.com ([209.85.213.170]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKVTVAgUXafTWc8+CqTvNnHbpuHSTfjU5b@postini.com; Mon, 20 Apr 2015 11:08:02 PDT Received: by igbyr2 with SMTP id yr2so66610418igb.0 for ; Mon, 20 Apr 2015 11:08:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QyLL8A50YE2e25pey7UdoVrphSwMYX01EByGUQ90nS0=; b=MdahZ69jlN/A79Gw4RE2ycR5+Nmzlr1PHAUle5irsWec8HGTvgKE+uV5r5KJgUwIlp E2QWFI7XRomtsxTJru4sE9TdsWepXQZCEtWHjDlkJKE16MHcNaYi+d004iUizIrHBI4x bWw4b4dbFd+I1jE+rsa4tgUnyrIbvCEeli8cbG+4mjJszgz1OjSO0OkG5epD1AJ0m4pE ARmpbtIYokCS0PBOSH0hvpmDX4xHLv4bv3s5bL8PgaUEQMHTdV2r1vvQJWUYIpM3AXNZ VkVh6wBViMPqCLDCC30NukuDCQiGAfLxajQkcDS7GZXrUTph1R6Qe3XUCUF2Wk5UqFQ9 yqDQ== X-Gm-Message-State: ALoCoQn+4dhwvu3alzqPNTByFu1L5TvGJ4xDzos2RxDJZMK9jasYfIU6sgypi693gx6hS9SvZhQnYJpa//5M/fU4yj6Ga/brEmeTqj7sDa9yeuuAMqXeOlx1kDWmIupJHWDM+QYm60Dr X-Received: by 10.107.41.72 with SMTP id p69mr23169543iop.58.1429553281532; Mon, 20 Apr 2015 11:08:01 -0700 (PDT) X-Received: by 10.107.41.72 with SMTP id p69mr23169534iop.58.1429553281444; Mon, 20 Apr 2015 11:08:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.15 with HTTP; Mon, 20 Apr 2015 11:07:30 -0700 (PDT) In-Reply-To: <55337CEE.2090605@connect2id.com> References: <55337CEE.2090605@connect2id.com> From: Brian Campbell Date: Mon, 20 Apr 2015 12:07:30 -0600 Message-ID: To: Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary=001a1141f3c4874d7505142bcf65 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Disable JWK "use" parameter for octet sequence keys? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 18:08:07 -0000 --001a1141f3c4874d7505142bcf65 Content-Type: text/plain; charset=UTF-8 IMHO "use" is less useful for JWKs of type "oct" but not to the point of disallowing it. Your question is probably better suited for the JOSE WG list though, rather than OAUTH. On Sun, Apr 19, 2015 at 4:01 AM, Vladimir Dzhuvinov wrote: > A developer working with the Nimbus jose+jwt library raised the question > whether setting of the public "use" [1] parameter should be disabled for > JWKs of type "oct". This appears to make sense, even though the JWA spec > [2] doesn't mention it. Is this correct? > > Thanks, > > Vladimir > > [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-40#section-4.2 > [2] > > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-6.4 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1141f3c4874d7505142bcf65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO "use" is less useful for JWKs of type = "oct" but not to the point of disallowing it.

Your q= uestion is probably better suited for the JOSE WG list though, rather than = OAUTH.=C2=A0



On Sun, Apr 19, 2015 at 4:01 AM, Vladim= ir Dzhuvinov <vladimir@connect2id.com> wrote:
A developer working with the Nimbus jose+jwt libr= ary raised the question
whether setting of the public "use" [1] parameter should be disab= led for
JWKs of type "oct". This appears to make sense, even though the J= WA spec
[2] doesn't mention it. Is this correct?

Thanks,

Vladimir

[1] http://tools.ietf.org/html/draft-ietf-jose-js= on-web-key-40#section-4.2
[2]
http://tools.ietf.org/html/draft-ietf-jose= -json-web-algorithms-40#section-6.4


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

--001a1141f3c4874d7505142bcf65-- From nobody Tue Apr 21 05:52:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237781ACD80 for ; Tue, 21 Apr 2015 05:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkJ4g6t0iYYV for ; Tue, 21 Apr 2015 05:52:56 -0700 (PDT) Received: from p3plsmtpa08-10.prod.phx3.secureserver.net (p3plsmtpa08-10.prod.phx3.secureserver.net [173.201.193.111]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F221ACD7C for ; Tue, 21 Apr 2015 05:52:56 -0700 (PDT) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa08-10.prod.phx3.secureserver.net with id Jcsu1q00115ZTut01csufu; Tue, 21 Apr 2015 05:52:55 -0700 Message-ID: <55364825.8020609@connect2id.com> Date: Tue, 21 Apr 2015 15:52:53 +0300 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 CC: "oauth@ietf.org" References: <55337CEE.2090605@connect2id.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Disable JWK "use" parameter for octet sequence keys? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 12:52:57 -0000 I'm sorry, I've unintentionally posted here instead of to JOSE. On 20.04.2015 21:07, Brian Campbell wrote: > IMHO "use" is less useful for JWKs of type "oct" but not to the point of > disallowing it. > > Your question is probably better suited for the JOSE WG list though, rather > than OAUTH. > > > > On Sun, Apr 19, 2015 at 4:01 AM, Vladimir Dzhuvinov > wrote: >> A developer working with the Nimbus jose+jwt library raised the question >> whether setting of the public "use" [1] parameter should be disabled for >> JWKs of type "oct". This appears to make sense, even though the JWA spec >> [2] doesn't mention it. Is this correct? >> >> Thanks, >> >> Vladimir >> >> [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-40#section-4.2 >> [2] >> >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-6.4 >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> -- Vladimir Dzhuvinov :: vladimir@connect2id.com From nobody Tue Apr 21 18:17:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95D1B2FFB; Tue, 21 Apr 2015 18:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOv8Sx3B_Y8A; Tue, 21 Apr 2015 18:17:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8AE1B3011; Tue, 21 Apr 2015 18:17:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422011727.14234.79729.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 18:17:27 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-28.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 01:17:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Phil Hunt Filename : draft-ietf-oauth-dyn-reg-28.txt Pages : 41 Date : 2015-04-21 Abstract: This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 21 18:17:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EE11B3029; Tue, 21 Apr 2015 18:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKX1bX3mklu2; Tue, 21 Apr 2015 18:17:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 593731B301C; Tue, 21 Apr 2015 18:17:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422011737.15680.5975.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 18:17:37 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 01:17:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer Michael B. Jones John Bradley Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-management-14.txt Pages : 18 Date : 2015-04-21 Abstract: This specification defines methods for management of dynamic OAuth 2.0 client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 21 18:18:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9A11B300E; Tue, 21 Apr 2015 18:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRLFAYLphDOc; Tue, 21 Apr 2015 18:17:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7651B3023; Tue, 21 Apr 2015 18:17:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422011747.19703.61765.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 18:17:47 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 01:18:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-08.txt Pages : 16 Date : 2015-04-21 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-introspection-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 21 18:24:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F701B301E for ; Tue, 21 Apr 2015 18:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvaFJWtarUdq for ; Tue, 21 Apr 2015 18:24:45 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA131B3024 for ; Tue, 21 Apr 2015 18:24:44 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-0f-5536f85b0431 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 46.39.03359.B58F6355; Tue, 21 Apr 2015 21:24:43 -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 t3M1OhE6013071 for ; Tue, 21 Apr 2015 21:24:43 -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 t3M1Ofi2004060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Apr 2015 21:24:42 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Justin Richer In-Reply-To: <20150422011727.14234.79729.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 21:24:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3767BD47-37E3-47E5-9AF3-C5D790AC7936@mit.edu> References: <20150422011727.14234.79729.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrBv9wyzUYO06Q4uTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/TUA6wF+4QrWg79Y25gfM/XxcjJISFgIrFz8hcWCFtM4sK9 9WxdjFwcQgKLmSTWNXVAOccYJf4cnc8C4Xxjklj1bSFYC7OAusSfeZeYQWxeAQOJuae+MIHY wgLOErdv97OC2GwCqhLT17SAxTkFnCROLP7HCGKzAMXvtbYzQszRlli28DXUHCuJpskXwOYL CThKTPywkR3EFgHateb8T6A5HECnykv0bEqfwCgwC8kVs5BcMQvJ1AWMzKsYZVNyq3RzEzNz ilOTdYuTE/PyUot0DfVyM0v0UlNKNzGCg1KSZwfjm4NKhxgFOBiVeHhXTDANFWJNLCuuzD3E KMnBpCTKy/fBLFSILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO/SBUA53pTEyqrUonyYlDQHi5I4 76YffCFCAumJJanZqakFqUUwWRkODiUJ3sPfgRoFi1LTUyvSMnNKENJMHJwgw3mAhreC1PAW FyTmFmemQ+RPMSpKifMuAEkIgCQySvPgemFJ4xWjONArwrwSIFU8wIQD1/0KaDAT0OC4bSYg g0sSEVJSDYwbedyq9yu7LfvP/EBZ8F+p7xW96jAJTZm4ZY+ma7s9nrBu7WK14o2TPv62ty2W /P4ou09COOvY/0nhvg+Px/z3FPXcKOHPWbo7b1vPbWf12WccfulO5whMyb36zr4jr1N9ys0p BvZ2vkWKnGfnCT34+4ZBy9DRZX/niRVtfW6hh7vFTWfGyCmxFGckGmoxFxUnAgB2vkdM9QIA AA== Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-28.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 01:24:47 -0000 Latest change set from IESG review. Nothing crazy, mostly discussion, = some clarification on what=E2=80=99s normative and what=E2=80=99s not. = Please check the diffs and reply with comments to the changes. Same deal with the management spec so I=E2=80=99m not going to re-send = this message on that thread. Thanks, =E2=80=94 Justin > On Apr 21, 2015, at 9:17 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Dynamic Client Registration = Protocol > Authors : Justin Richer > Michael B. Jones > John Bradley > Maciej Machulak > Phil Hunt > Filename : draft-ietf-oauth-dyn-reg-28.txt > Pages : 41 > Date : 2015-04-21 >=20 > Abstract: > This specification defines mechanisms for dynamically registering > OAuth 2.0 clients with authorization servers. Registration requests > send a set of desired client metadata values to the authorization > server. The resulting registration responses return a client > identifier to use at the authorization server and the client = metadata > values registered for the client. The client can then use this > registration information to communicate with the authorization = server > using the OAuth 2.0 protocol. This specification also defines a set > of common client metadata fields and values for clients to use = during > registration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-28 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Apr 21 18:26:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEA41B3029 for ; Tue, 21 Apr 2015 18:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWVcxVMi6AUt for ; Tue, 21 Apr 2015 18:26:15 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637DD1B3010 for ; Tue, 21 Apr 2015 18:26:15 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-3a-5536f8b67180 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E2.49.03359.6B8F6355; Tue, 21 Apr 2015 21:26:14 -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 t3M1QD4V013306 for ; Tue, 21 Apr 2015 21:26:14 -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 t3M1QC78005192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Apr 2015 21:26:13 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Justin Richer In-Reply-To: <20150422011747.19703.61765.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 21:26:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <695AED74-9DEB-4891-A4DB-F18CC9726C15@mit.edu> References: <20150422011747.19703.61765.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrLvth1moweLfQhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtX9CxgLnvBXzFrC28B4jKeLkZNDQsBEYsbdF4wQtpjEhXvr 2boYuTiEBBYzSeyfsg3KOcYo8eLVOyjnG5PEne4ZLCAtzALqEn/mXWIGsXkFDCTmnvrCBGIL C3hKdN27AlbDJqAqMX1NC1Ccg4NTwEni/2kDkDALUHjWrLnMEGO0JZYtfA01xkri1eeVrCC2 kICjxJRN3WBjRIBWrTn/E2yMhIC8RM+m9AmMArOQHDELyRGzkExdwMi8ilE2JbdKNzcxM6c4 NVm3ODkxLy+1SNdQLzezRC81pXQTIzggJXl2ML45qHSIUYCDUYmHd8UE01Ah1sSy4srcQ4yS HExKorx8H8xChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwLl0AlONNSaysSi3Kh0lJc7AoifNu +sEXIiSQnliSmp2aWpBaBJOV4eBQkuA9/B2oUbAoNT21Ii0zpwQhzcTBCTKcB2j4QZAa3uKC xNzizHSI/ClGRSlx3gUgCQGQREZpHlwvLGG8YhQHekWYlx+YPoR4gMkGrvsV0GAmoMFx20xA BpckIqSkGhgrPDfL233+K6lVvsJDTmLCAZMVazg+Xt3Dvuav4f76rbmtX651RvhLGtRwmmtz W0+qqvQof1S6RE0oXLZRi53tYL+8VYRN4QWTErMHTG/X2zFdmL737JdtjQH/a0XnvonZoHXb WfH9m0k1Cc57fulcjswtYNt0aLFU3fW9yXN5/V+kPQr2jlBiKc5INNRiLipOBACiVyIa8wIA AA== Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 01:26:17 -0000 New introspection draft incorporating feedback from Kathleen and a few = others. I finally got around to adding the Acknowledgements section, so = if I butchered your name (or you=E2=80=99d rather not be associated with = the draft), please let me know. Thanks everyone, =E2=80=94 Justin > On Apr 21, 2015, at 9:17 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : OAuth 2.0 Token Introspection > Author : Justin Richer > Filename : draft-ietf-oauth-introspection-08.txt > Pages : 16 > Date : 2015-04-21 >=20 > Abstract: > This specification defines a method for a protected resource to = query > an OAuth 2.0 authorization server to determine the active state of = an > OAuth 2.0 token and to determine meta-information about this token. > OAuth 2.0 deployments can use this method to convey information = about > the authorization context of the token from the authorization server > to the protected resource. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-introspection-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Apr 21 18:31:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925731A006F; Tue, 21 Apr 2015 18:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl0WBn9Rq-eP; Tue, 21 Apr 2015 18:31:04 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2C61A0069; Tue, 21 Apr 2015 18:31:03 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-cd-5536f9d62c72 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 dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.69.03359.6D9F6355; Tue, 21 Apr 2015 21:31:02 -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 t3M1V123013398; Tue, 21 Apr 2015 21:31:01 -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 t3M1UvVZ008785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Apr 2015 21:30:59 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_8AFF8BA8-4E33-4F5F-8469-9D5035A72CA7" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Justin Richer In-Reply-To: <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu> Date: Tue, 21 Apr 2015 21:30:57 -0400 Message-Id: <82268A04-588C-4D43-A638-8D99E76727DD@mit.edu> References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixG6nonvtp1mowZ+z8hbzO0+zW0z7+ZrN YsaficwWe6d9YrG4PXclm8XJt6/YLN4sPM7qwO6xZMlPJo/WHX/ZPWbtfMLiMWvWYaYAligu m5TUnMyy1CJ9uwSujNffdjAVHMytuPfzBFsD452YLkZODgkBE4nN354xQdhiEhfurWfrYuTi EBJYzCQx+exzFghnI6PE7u4vUM5DJokTc3+xgLQwCyRIvPoxlRHE5hUwkJh76gvYKGGBJIkF M1aBxdkEVCWmr2kBinNwcApYSzy86A0SZgEJb9jJDjKTWeAUk8SKWVeh5lhJTFp9nwli2SIm ibUr7rKBJEQElCW2Pb7FCjJIQkBeomdT+gRGgVlIzpiF5AyIuLbEsoWvmSFsTYn93ctZMMU1 JDq/TWRdwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdQLzezRC81pXQTIyhyOCV5djC+Oah0 iFGAg1GJh3fFBNNQIdbEsuLK3EOMkhxMSqK8fB/MQoX4kvJTKjMSizPii0pzUosPMUpwMCuJ 8C5dAJTjTUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJIAygI1ChalpqdW pGXmlCCkmTg4QYbzAA1fB1LDW1yQmFucmQ6RP8WoKCXOOw8kIQCSyCjNg+uFJbZXjOJArwjz HgGp4gEmRbjuV0CDmYAGx20zARlckoiQkmpgXPAned/dk10T3vdMab4RHNy7TP3gPIcZ5+Zp vrJNm1M15wWP5r3H55u2sbwpsL8bdeaex3UD3aSmT932v47vX/D1QMkPJj6PF8vnm79k+2z2 2zDi5YXXp9VYv9kcPcm2ZH65ia38GqajIU+3rD2YMsPs7rG9d9SfdOX9y3YKPmX/1tnnyiK3 WAUlluKMREMt5qLiRACqROBVRwMAAA== Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , Ben Campbell , Phil Hunt , "" , The IESG , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 01:31:07 -0000 --Apple-Mail=_8AFF8BA8-4E33-4F5F-8469-9D5035A72CA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben et. al, We=E2=80=99ve incorporated feedback into the latest draft: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 = Hopefully this addresses all of the comments below. Thank you for your = review! =E2=80=94 Justin > On Apr 7, 2015, at 8:51 PM, Justin Richer wrote: >=20 >> Section 2: >>=20 >> The software_version "SHOULD change on any update identified with the >> same software_id" --why not MUST? What happens if this doesn't = happen? >>=20 >=20 > I agree with Mike that the SHOULD is more realistic, especially = because the definition of =E2=80=9Cversion=E2=80=9D isn=E2=80=99t = something that we can really lock down a lot from the spec=E2=80=99s = perspective. >=20 > What we can do though is add some text, as Ben suggests, that says why = the SHOULD ought to be applied in the common case and what kinds of = exceptions there are. I=E2=80=99ll try to work something out based on = the discussion threads here and add it to the draft. >=20 > To the other issues: >=20 >>=20 >> "Extensions and profiles MAY expand this list.." -- That seems more = like >> a statement of fact than a normative requirement. >>=20 >=20 > Noted, we=E2=80=99re just trying to say that there are others items = that could be in there. We can change the =E2=80=9CMAY=E2=80=9D to = =E2=80=9Ccan=E2=80=9D. >=20 >> 3.2.1: >>=20 >> client_id "SHOULD NOT be currently valid for any other registered >> client": Why not MUST? What happens if it is valid for another = client? >=20 > We=E2=80=99ve got some text on re-use of the client_id in the security = considerations section. >=20 >=20 >>=20 >> 4.1 and 4.2 allow the designated expert to accept preliminary >> registrations if they are confident a spec will be published. = Shouldn't >> this follow the normal processes for preliminary registrations? Is = there >> a way to walk back registrations if the spec isn't published after = all? >=20 > I=E2=80=99ll defer to others=E2=80=99 expertise on the right text for = the IANA section, this was imported from another example spec. >=20 >>=20 >> section 5: >>=20 >> 4th paragraph after bullet list: "... authorization server needs to = take >> steps to >> mitigate this risk...": Other statements like this have been >> normative. Is there a reason this one is not? >=20 > No specific reason that I recall, except that there=E2=80=99s not a = specific step that we prescribe. We can make that a MUST. >=20 >>=20 >> 2nd paragraph from end: "... treat the new registration as being >> suspect": ... and do what? >>=20 >>=20 >=20 >=20 > Good catch, I think that thought is unfinished. It=E2=80=99s up to the = AS in the end, but it should probably reject the registration. >=20 > =E2=80=94 Justin >=20 >> On Apr 7, 2015, at 3:09 PM, Mike Jones = wrote: >>=20 >> I think that the current SHOULD is more realistic. In the real = world, particularly while developing and testing, people will have many = iterations of pre-release software for a given version, all of which = will likely be identified with the intended version number before the = final release of that version of the software is made. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, April 07, 2015 11:11 AM >> To: Phil Hunt >> Cc: The IESG; oauth-chairs@ietf.org; = draft-ietf-oauth-dyn-reg@ietf.org; Justin Richer >> Subject: Re: Ben Campbell's No Objection on = draft-ietf-oauth-dyn-reg-27: (with COMMENT) >>=20 >> On 7 Apr 2015, at 13:03, Phil Hunt wrote: >>=20 >>> Section 2: >>>>=20 >>>> The software_version "SHOULD change on any update identified with = the >>>> same software_id" --why not MUST? What happens if this doesn't >>>> happen? >>>=20 >>>=20 >>> The group didn=E2=80=99t necessarily agree to make software_version = mandatory >>> to provide. Thus the word, SHOULD seemed appropriate to indicate = that >>> if used it SHOULD change from version to version. That said, I am ok >>> with MUST (e.g. if software_version is used, it MUST change...). >>>=20 >>> In answer to your question what happens: this is not so much a >>> security issue (in the traditional sense of an attacker), but rather = a >>> regular software versioning/maintenance issue. The idea is that some >>> client software updates may prove to be buggy (or have performance >>> issues) and service providers may want to be able to refuse some >>> versions of client software while accepting others (e.g. 2.5 is = broken >>> and causes DoS issues, while 2.5.1 is acceptable). If a version is >>> not provided, than an AS=E2=80=99s only choice is to ban all = versions and >>> force the client developer to use or obtain a different software_id >>> for future registrations. >>=20 >> Thanks for the response. I can live with either a SHOULD or a MUST, = but if the SHOULD stays, it would be good to add a sentence or two to = the effect of the above paragraph. That being said, "If used, it MUST = change" seems to be more precise if that fits the WG intent. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8AFF8BA8-4E33-4F5F-8469-9D5035A72CA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben et. al,

We=E2=80=99ve incorporated feedback into the latest = draft:

  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28

Hopefully this = addresses all of the comments below. Thank you for your = review!

 =E2=80=94 Justin

On = Apr 7, 2015, at 8:51 PM, Justin Richer <jricher@MIT.EDU> = wrote:

Section 2:

The software_version "SHOULD change on any = update identified with the
same software_id" --why not = MUST? What happens if this doesn't happen?


I agree with Mike that the SHOULD = is more realistic, especially because the definition of =E2=80=9Cversion=E2= =80=9D isn=E2=80=99t something that we can really lock down a lot from = the spec=E2=80=99s perspective.

What we can = do though is add some text, as Ben suggests, that says why the SHOULD = ought to be applied in the common case and what kinds of exceptions = there are. I=E2=80=99ll try to work something out based on the = discussion threads here and add it to the draft.

To the other issues:


"Extensions and profiles MAY = expand this list.." -- That seems more like
a statement of = fact than a normative requirement.


Noted, we=E2=80=99re just trying = to say that there are others items that could be in there. We can change = the =E2=80=9CMAY=E2=80=9D to =E2=80=9Ccan=E2=80=9D.

3.2.1:

client_id "SHOULD NOT be currently valid for any other = registered
client": Why not MUST? What happens if it is = valid for another client?

We=E2=80=99ve got some text on re-use of the client_id in the = security considerations section.



4.1 and = 4.2 allow the designated expert to accept preliminary
registrations if they are confident a spec will be published. = Shouldn't
this follow the normal processes for preliminary = registrations? Is there
a way to walk back registrations = if the spec isn't published after all?

I=E2=80=99ll defer to others=E2=80=99 expertise on the right = text for the IANA section, this was imported from another example = spec.


section 5:

4th = paragraph after bullet list: "... authorization server needs to take
steps to
  mitigate this risk...": =  Other statements like this have been
normative. Is = there a reason this one is not?

No specific reason that I recall, except that there=E2=80=99s = not a specific step that we prescribe. We can make that a MUST.


2nd paragraph from end: "... treat the new registration as = being
suspect": ... and do what?




Good = catch, I think that thought is unfinished. It=E2=80=99s up to the AS in = the end, but it should probably reject the registration.
=E2=80=94 Justin

On Apr 7, 2015, at 3:09 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I think that the current SHOULD is more realistic.  In = the real world, particularly while developing and testing, people will = have many iterations of pre-release software for a given version, all of = which will likely be identified with the intended version number before = the final release of that version of the software is made.

-- Mike

-----Original Message-----
From: Ben Campbell = [mailto:ben@nostrum.com]
Sent: Tuesday, = April 07, 2015 11:11 AM
To: Phil Hunt
Cc: = The IESG; oauth-chairs@ietf.org; draft-ietf-oauth-dyn-reg@ietf.org; Justin Richer
Subject: Re: Ben Campbell's No Objection on = draft-ietf-oauth-dyn-reg-27: (with COMMENT)

On 7 Apr 2015, at 13:03, Phil Hunt wrote:

Section 2:

The = software_version "SHOULD change on any update identified with the
same software_id" --why not MUST? What happens if this = doesn't
happen?


The group didn=E2=80=99t necessarily agree to = make software_version mandatory
to provide. Thus the word, = SHOULD seemed appropriate to indicate that
if used it = SHOULD change from version to version. That said, I am ok
with MUST (e.g. if software_version is used, it MUST = change...).

In answer to your question what = happens: this is not so much a
security issue (in the = traditional sense of an attacker), but rather a
regular = software versioning/maintenance issue. The idea is that some
client software updates may prove to be buggy (or have = performance
issues) and service providers may want to be = able to refuse some
versions of client software while = accepting others (e.g. 2.5 is broken
and causes DoS = issues, while 2.5.1 is acceptable).  If a version is
not provided, than an AS=E2=80=99s only choice is to ban all = versions and
force the client developer to use or obtain a = different software_id
for future registrations.

Thanks for the response. I can = live with either a SHOULD or a MUST, but if the SHOULD stays, it would = be good to add a sentence or two to the effect of the above paragraph. = That being said, "If used, it MUST change" seems to be more precise if = that fits the WG intent.

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

= --Apple-Mail=_8AFF8BA8-4E33-4F5F-8469-9D5035A72CA7-- From maradrianbelen@gmail.com Mon Apr 20 17:55:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3331B3625 for ; Mon, 20 Apr 2015 17:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfFSaK2cHlvn for ; Mon, 20 Apr 2015 17:55:26 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 3BCED1B3624 for ; Mon, 20 Apr 2015 17:55:26 -0700 (PDT) Received: by oign205 with SMTP id n205so140498202oig.2 for ; Mon, 20 Apr 2015 17:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1uOiqKJgtNS8ZDaymoKicKYcyPAV2cUEGev5JINvJEg=; b=tsavHBszQpR2U8uRKQyJa6SlOB9/ZRjRdOdH71Xp6+wek4R2OKfs5FCk6rCXMNs9Y+ W/yrRVyubTJx4zYDgwxQGGaceHXg74o5j86RRC7NqAPMZ58NfbKqUJMnIQAQuaTnUuvA xRtQJRDjhH76PtCi4HIu+yPfZ2zwAThspJF0lvVwYdavHgTclGzgGNuJT6qZP7Ow0vGD fsCLV+6epNUwjPL1mZwneog8Jponi44yamD7iYjabeR4wyMEPqEeYYfba/cVenOEXoAr AcF/geN/3dpl5/n+BybuF5CdcqZc4Lzkz9y+dYh0UYeJc4MRoA6CTfw3W9K6FqLEbmR3 6tdw== MIME-Version: 1.0 X-Received: by 10.182.68.103 with SMTP id v7mr12015323obt.82.1429577725726; Mon, 20 Apr 2015 17:55:25 -0700 (PDT) Received: by 10.76.98.136 with HTTP; Mon, 20 Apr 2015 17:55:25 -0700 (PDT) Date: Tue, 21 Apr 2015 08:55:25 +0800 Message-ID: From: mar adrian belen To: oauth@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1ef2c85549305143180de Archived-At: X-Mailman-Approved-At: Wed, 22 Apr 2015 07:28:34 -0700 Subject: [OAUTH-WG] hijacking client's user account X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 00:59:37 -0000 --e89a8fb1ef2c85549305143180de Content-Type: text/plain; charset=UTF-8 Some web application are using oauth 2 technology as login alternative , i found a way how can i access client application using unverified email(victim email) on oauth oauth provider, if oauth provider allows unverified email to use it's oauth service which can abuse by the attacker, this is possible if the client provider directly login the user(using oauth) if his email is already exists on they record. * user joe has account on CLIENT A using his email address victimjoe@test.com, but does not have oauth provider account. attacker knows that. * now the attacker create a new oauth provider account using victimjoe@test.com. * because an unverified email can used the oauth provider oauth and the CLIENT A is using oauth provider's oauth as an alternative login, the attacker can now access victim's Client Application(CLIENT A) account using the login alternative function. you can try github(oauth provider) and https://sprint.ly/ (client) https://www.dropbox.com/s/jhrgn311i0e28pc/hijackoauthclient_x264.mp4?dl=0 --e89a8fb1ef2c85549305143180de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some web application are using oauth 2 technology as = login alternative , i found a way how can i access client application using= unverified email(victim email) on=C2=A0

oauth oau= th provider, if oauth provider allows unverified email to use it's oaut= h service which can abuse by the attacker, this is possible if the client p= rovider=C2=A0

directly login the user(using oauth)= if his email is already exists on they record.

* user joe has account on CLIENT A using his email address victimjoe@test.com, but does not hav= e oauth provider account. attacker knows that.

* n= ow the attacker create a new oauth provider account using victimjoe@test.com.

* bec= ause an unverified email can used the oauth provider oauth and the CLIENT A= is using oauth provider's oauth as an alternative login, the attacker = can now access=C2=A0

victim's Client =C2=A0App= lication(CLIENT A) account using the login alternative =C2=A0function.


you can try github(oauth provider) and = =C2=A0https://sprint.ly/ =C2=A0(client)<= /div>


--e89a8fb1ef2c85549305143180de-- From nobody Wed Apr 22 08:02:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8111A8AB8 for ; Wed, 22 Apr 2015 08:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80Zd9la5S6mA for ; Wed, 22 Apr 2015 08:02:32 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E153A1B36A8 for ; Wed, 22 Apr 2015 08:02:04 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-a3-5537b7ea03fa 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 dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 67.CC.03359.AE7B7355; Wed, 22 Apr 2015 11:02:02 -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 t3MF21rS018911; Wed, 22 Apr 2015 11:02:02 -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 t3MF20sw019570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Apr 2015 11:02:01 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D339C6D7-DDFC-4D8F-9DBB-406D7035D7C5"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: Date: Wed, 22 Apr 2015 11:01:58 -0400 Message-Id: References: To: mar adrian belen X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixG6novtqu3mowf6b2hZ/jy1jtzj59hWb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxcFk3S8Etm4qPE/tYGxjnmHYxcnBICJhI zN2p1cXICWSKSVy4t56ti5GLQ0hgMZPE/2dPmSGcjYwS549fZoRwHjJJfDg+jR2kRVjAXGL6 lFlsIDavgIHE3FNfmECKmAWmMEp8mfyPDWKulETT62OMIDabgKrE9DUtTCCrOQUCJfbPcQAJ swCFP275zAgSZhZQl2g/6QIx0kpi+bOZYFOEBAIkHkzbywxiiwjoS7xqvskO8YC8RM+m9AmM grOQHDEL2REgCWaBJIkbV04wQdjaEssWvmaGsDUl9ncvZ8EU15Do/DaRFcKWl9j+dg5U3FJi 8cwbUPW2Erf6FkDNtJN4NG0R6wJG7lWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSml mxhB8ccpybOD8c1BpUOMAhyMSjy8K9jNQ4VYE8uKK3MPMUpyMCmJ8n5cBxTiS8pPqcxILM6I LyrNSS0+xKgCtOvRhtUXGKVY8vLzUpVEeOO2AtXxpiRWVqUW5cOUSXOwKInzbvrBFyIkkJ5Y kpqdmlqQWgSTleHgUJLgnbYNqFGwKDU9tSItM6cEIc3EwXmIUYKDB2j4ZpAa3uKCxNzizHSI /ClGRSlx3r0gCQGQREZpHlwvLG2+YhQHekuY9zRIFQ8w5cJ1vwIazARy9TYTkMEliQgpqQbG RimfCiv/pYcuVZY0ZX7+//ao8Os8iTefI+x7PKJ4Phe6buO2ERavepJucXphv71G1bVvEks3 /5jzqkO8f/ZOPf/1B16y3fd6s/vR3utpuVvOnjp91HhJwa/jP5bEffosnvbhvFre2v8Hw926 Vy4UOhvFHvNpu4HuxZJXD36WlMqkbZ2dPS/ptRJLcUaioRZzUXEiAH8gVwV2AwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] hijacking client's user account X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 15:02:34 -0000 --Apple-Mail=_D339C6D7-DDFC-4D8F-9DBB-406D7035D7C5 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E0AF7D7-B664-4A8F-9030-52BFAD15D682" --Apple-Mail=_6E0AF7D7-B664-4A8F-9030-52BFAD15D682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This seems to be not a problem with OAuth but with misusing OAuth as an = authentication protocol: http://oauth.net/articles/authentication/ = And with trusting unverified claims from a third party IdP (such as a = self-asserted email address), which is covered in the OpenID Connect = specification, an authentication protocol built on top of OAuth: http://openid.net/specs/openid-connect-core-1_0.html#ClaimStability You should probably let the client know in this case that they should = not be using the email address as a key if they=E2=80=99re not verifying = it themselves. If the authentication article can be updated to include = this misuse, please help us amend it! =E2=80=94 Justin > On Apr 20, 2015, at 8:55 PM, mar adrian belen = wrote: >=20 > Some web application are using oauth 2 technology as login alternative = , i found a way how can i access client application using unverified = email(victim email) on >=20 > oauth oauth provider, if oauth provider allows unverified email to use = it's oauth service which can abuse by the attacker, this is possible if = the client provider >=20 > directly login the user(using oauth) if his email is already exists on = they record. >=20 >=20 > * user joe has account on CLIENT A using his email address = victimjoe@test.com , but does not have oauth = provider account. attacker knows that. >=20 > * now the attacker create a new oauth provider account using = victimjoe@test.com . >=20 > * because an unverified email can used the oauth provider oauth and = the CLIENT A is using oauth provider's oauth as an alternative login, = the attacker can now access >=20 > victim's Client Application(CLIENT A) account using the login = alternative function. >=20 >=20 > you can try github(oauth provider) and https://sprint.ly/ = (client) >=20 >=20 > = https://www.dropbox.com/s/jhrgn311i0e28pc/hijackoauthclient_x264.mp4?dl=3D= 0 = _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6E0AF7D7-B664-4A8F-9030-52BFAD15D682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This seems to be not a problem with OAuth but with misusing = OAuth as an authentication protocol:

http://oauth.net/articles/authentication/

And with trusting = unverified claims from a third party IdP (such as a self-asserted email = address), which is covered in the OpenID Connect specification, an = authentication protocol built on top of OAuth:

http://openid.net/specs/openid-connect-core-1_0.html#ClaimStabi= lity

You = should probably let the client know in this case that they should not be = using the email address as a key if they=E2=80=99re not verifying it = themselves. If the authentication article can be updated to include this = misuse, please help us amend it!

 =E2=80=94 Justin

On Apr 20, 2015, at 8:55 PM, mar adrian belen <maradrianbelen@gmail.com> wrote:

Some web = application are using oauth 2 technology as login alternative , i found = a way how can i access client application using unverified email(victim = email) on 

oauth oauth provider, if oauth provider allows unverified = email to use it's oauth service which can abuse by the attacker, this is = possible if the client provider 

directly login the user(using oauth) if = his email is already exists on they record.


* = user joe has account on CLIENT A using his email address victimjoe@test.com, = but does not have oauth provider account. attacker knows that.

* now the attacker = create a new oauth provider account using victimjoe@test.com.

* because an unverified email can used = the oauth provider oauth and the CLIENT A is using oauth provider's = oauth as an alternative login, the attacker can now = access 

victim's Client  Application(CLIENT A) account using the = login alternative  function.


you = can try github(oauth provider) and  https://sprint.ly/  (client)


https://www.dropbox.com/s/jhrgn311i0e28pc/hijackoauthclient_x26= 4.mp4?dl=3D0
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_6E0AF7D7-B664-4A8F-9030-52BFAD15D682-- --Apple-Mail=_D339C6D7-DDFC-4D8F-9DBB-406D7035D7C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVN7fnAAoJEDPAngkbd+w9khEH/A6D7L1NcMcVMWbqm5YqfoWw fmvuhr9JHfXh8kP1gphG9ls9MnjV1W9/xzBOXvOhaG+dfSodMlySbAJ2gzyz2Y0I ZbZ7x1AqfInJ0NEjw8Po1B13LQc4aYnYn++ADMv/Ji93Bfbl5xaYUtIegz4H5bdD IbS+SriWJp8Sbha2iK4xW8iX8wNsohkoO5I5b0g8jj25gGD/+eElfUDvfVZamZD3 4FvIiM8BRM4TTstH2V2rxlX3BmYFQbFdiQ5gJpNZm8fMOtaZkc4eKKRKt6uQL7yp AdHmXLPFlyvE1C22K7grDJhYOrcfPXp34RqLEpDjBvAN3YcMniWkMyi46syfFjg= =DqWE -----END PGP SIGNATURE----- --Apple-Mail=_D339C6D7-DDFC-4D8F-9DBB-406D7035D7C5-- From nobody Wed Apr 22 09:20:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AD61B3760 for ; Wed, 22 Apr 2015 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOrxr15GyjV5 for ; Wed, 22 Apr 2015 09:20:15 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 4854F1B3773 for ; Wed, 22 Apr 2015 09:20:06 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so184173370lbb.3 for ; Wed, 22 Apr 2015 09:20:04 -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 :cc:content-type; bh=yXzqWCc7EbmhXEI3EPDFjR+bLBGmrD6X8cz/2uBvslA=; b=PqAvpd9kQZszCeETBj/oLW9BJHWKYF4s5WtSEkKfvwwzq4xEF1z2HYcLeMhEudVYG9 uDepfvXmZztNg7+NttGYB8vgKaiABXpsNgZFGFMPmIqCSSKEdHG69VPORhY2ZefeMpyS kskmkI/rwaYWvZ7SuMDk6GifQfHLsflEptT+Bh9jEJcREZTOaNP6KHVyFKDgfKO6nK6C 4KHgj1yxXvfqxOvXoQI9ud7+s/moGOK/bxYQjUCwOTfnZCUjFGuBsZBJzjwQYCbCsL8A vfQuXbSWTHaa/EQePycrCnIWeynq5tmgqpUlkH+velcBKg8QIjGUHjmWhJpogumG9Zq3 yOmw== X-Received: by 10.152.27.35 with SMTP id q3mr25111428lag.24.1429719604814; Wed, 22 Apr 2015 09:20:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Broyer Date: Wed, 22 Apr 2015 16:20:03 +0000 Message-ID: To: Justin Richer , mar adrian belen Content-Type: multipart/alternative; boundary=089e0160b7ca2c6c220514528962 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] hijacking client's user account X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:20:16 -0000 --089e0160b7ca2c6c220514528962 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also, this is not news: http://securityintelligence.com/spoofedme-social-login-attack-discovered-by= -ibm-x-force-researchers/ On Wed, Apr 22, 2015 at 5:02 PM Justin Richer wrote: > This seems to be not a problem with OAuth but with misusing OAuth as an > authentication protocol: > > http://oauth.net/articles/authentication/ > > And with trusting unverified claims from a third party IdP (such as a > self-asserted email address), which is covered in the OpenID Connect > specification, an authentication protocol built on top of OAuth: > > http://openid.net/specs/openid-connect-core-1_0.html#ClaimStability > > You should probably let the client know in this case that they should not > be using the email address as a key if they=E2=80=99re not verifying it t= hemselves. > If the authentication article can be updated to include this misuse, plea= se > help us amend it! > > =E2=80=94 Justin > > On Apr 20, 2015, at 8:55 PM, mar adrian belen > wrote: > > Some web application are using oauth 2 technology as login alternative , = i > found a way how can i access client application using unverified > email(victim email) on > > oauth oauth provider, if oauth provider allows unverified email to use > it's oauth service which can abuse by the attacker, this is possible if t= he > client provider > > directly login the user(using oauth) if his email is already exists on > they record. > > > * user joe has account on CLIENT A using his email address > victimjoe@test.com, but does not have oauth provider account. attacker > knows that. > > * now the attacker create a new oauth provider account using > victimjoe@test.com. > > * because an unverified email can used the oauth provider oauth and the > CLIENT A is using oauth provider's oauth as an alternative login, the > attacker can now access > > victim's Client Application(CLIENT A) account using the login alternativ= e > function. > > > you can try github(oauth provider) and https://sprint.ly/ (client) > > > https://www.dropbox.com/s/jhrgn311i0e28pc/hijackoauthclient_x264.mp4?dl= =3D0 > _______________________________________________ > 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 > --089e0160b7ca2c6c220514528962 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 22, 2015 at 5:02 PM Justin Richer <jricher@mit.edu> wrote:
This seems to be not a problem with= OAuth but with misusing OAuth as an authentication protocol:


A= nd with trusting unverified claims from a third party IdP (such as a self-a= sserted email address), which is covered in the OpenID Connect specificatio= n, an authentication protocol built on top of OAuth:

http://openid.net/specs/openid-connect-core-1_0.h= tml#ClaimStability

You should probably let the= client know in this case that they should not be using the email address a= s a key if they=E2=80=99re not verifying it themselves. If the authenticati= on article can be updated to include this misuse, please help us amend it!<= /div>

=C2=A0= =E2=80=94 Justin

On Apr 20, 2015, at 8:55 PM, mar adrian b= elen <mara= drianbelen@gmail.com> wrote:

Som= e web application are using oauth 2 technology as login alternative , i fou= nd a way how can i access client application using unverified email(victim = email) on=C2=A0

oauth oauth provider, if oauth pro= vider allows unverified email to use it's oauth service which can abuse= by the attacker, this is possible if the client provider=C2=A0
<= br>
directly login the user(using oauth) if his email is already = exists on they record.


* user joe h= as account on CLIENT A using his email address victimjoe@test.com, but does not have oauth= provider account. attacker knows that.

* now the = attacker create a new oauth provider account using victimjoe@test.com.

* because an unverified email can used the oauth provider oauth and t= he CLIENT A is using oauth provider's oauth as an alternative login, th= e attacker can now access=C2=A0

victim's Clien= t =C2=A0Application(CLIENT A) account using the login alternative =C2=A0fun= ction.


you can try github(oauth pro= vider) and =C2=A0https://s= print.ly/ =C2=A0(client)


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--089e0160b7ca2c6c220514528962-- From nobody Wed Apr 22 16:35:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0B01B2B71; Wed, 22 Apr 2015 16:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tEXOsZnqGt2; Wed, 22 Apr 2015 16:35:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCA81B2B49; Wed, 22 Apr 2015 16:35:26 -0700 (PDT) Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB305.namprd03.prod.outlook.com (10.141.68.13) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 22 Apr 2015 23:35:26 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) with Microsoft SMTP Server (TLS) id 15.1.148.15; Wed, 22 Apr 2015 23:35:25 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0148.008; Wed, 22 Apr 2015 23:35:25 +0000 From: Mike Jones To: Ben Campbell , Justin Richer Thread-Topic: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) Thread-Index: AQHQcLNvziIlymLSiU21Cpn+02CTDJ1B2QkAgAAB4QCAAECyoIAAL0UAgBYLroCAAU9agIAAIo1Q Date: Wed, 22 Apr 2015 23:35:25 +0000 Message-ID: References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu> <82268A04-588C-4D43-A638-8D99E76727DD@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nostrum.com; dkim=none (message not signed) header.d=none; x-originating-ip: [64.134.226.84] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB433; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB305; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(13464003)(377454003)(24454002)(77096005)(15975445007)(102836002)(87936001)(40100003)(122556002)(76176999)(54356999)(5001770100001)(2656002)(86362001)(50986999)(86612001)(77156002)(62966003)(92566002)(19580395003)(93886004)(2900100001)(2950100001)(19580405001)(230783001)(2171001)(99286002)(33656002)(106116001)(46102003)(76576001)(74316001)(66066001)(1720100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB433; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BL2PR03MB433; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB433; x-forefront-prvs: 0554B1F54F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2015 23:35:25.5478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB433 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , Phil Hunt , "oauth-chairs@ietf.org" , "" , The IESG Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 23:35:29 -0000 SSdkIGJlIGZpbmUgYWRkaW5nIHRoZSBCQ1AgMTAwIHJlZmVyZW5jZS4gIEknZCByYXRoZXIgdGhh dCB3ZSBrZWVwIHRoZSBlYXJseSByZWdpc3RyYXRpb24gcHJvY2VkdXJlcyBsYW5ndWFnZS4NCg0K CQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBDYW1w YmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIy LCAyMDE1IDI6MzEgUE0NClRvOiBKdXN0aW4gUmljaGVyDQpDYzogZHJhZnQtaWV0Zi1vYXV0aC1k eW4tcmVnQGlldGYub3JnOyBQaGlsIEh1bnQ7IDxvYXV0aEBpZXRmLm9yZz47IE1pa2UgSm9uZXM7 IFRoZSBJRVNHOyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWct Mjc6ICh3aXRoIENPTU1FTlQpDQoNCk9uIDIxIEFwciAyMDE1LCBhdCAyMDozMCwgSnVzdGluIFJp Y2hlciB3cm90ZToNCg0KPiBCZW4gZXQuIGFsLA0KPg0KPiBXZeKAmXZlIGluY29ycG9yYXRlZCBm ZWVkYmFjayBpbnRvIHRoZSBsYXRlc3QgZHJhZnQ6DQo+DQo+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0yOCANCj4gPGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0yOD4NCj4+DQoNCkkgdGhpbmsgdGhh dCByZXNvbHZlcyBhbGwgbXkgY29tbWVudHMgc2F2ZSBvbmU6DQoNClsuLi5dDQoNCj4+DQo+Pj4N Cj4+PiA0LjEgYW5kIDQuMiBhbGxvdyB0aGUgZGVzaWduYXRlZCBleHBlcnQgdG8gYWNjZXB0IHBy ZWxpbWluYXJ5DQo+Pj4gcmVnaXN0cmF0aW9ucyBpZiB0aGV5IGFyZSBjb25maWRlbnQgYSBzcGVj IHdpbGwgYmUgcHVibGlzaGVkLiANCj4+PiBTaG91bGRuJ3QNCj4+PiB0aGlzIGZvbGxvdyB0aGUg bm9ybWFsIHByb2Nlc3NlcyBmb3IgcHJlbGltaW5hcnkgcmVnaXN0cmF0aW9ucz8gSXMgDQo+Pj4g dGhlcmUNCj4+PiBhIHdheSB0byB3YWxrIGJhY2sgcmVnaXN0cmF0aW9ucyBpZiB0aGUgc3BlYyBp c24ndCBwdWJsaXNoZWQgYWZ0ZXIgDQo+Pj4gYWxsPw0KPj4NCj4+IEnigJlsbCBkZWZlciB0byBv dGhlcnPigJkgZXhwZXJ0aXNlIG9uIHRoZSByaWdodCB0ZXh0IGZvciB0aGUgSUFOQSANCj4+IHNl Y3Rpb24sIHRoaXMgd2FzIGltcG9ydGVkIGZyb20gYW5vdGhlciBleGFtcGxlIHNwZWMuDQo+Pg0K DQpCQ1AgMTAwIChSRkMgNzEyMCkgZGVzY3JpYmVzIHRoZSBJQU5BIGVhcmx5IGFsbG9jYXRpb24g cHJvY2VkdXJlcy4gWW91IA0KbWlnaHQgY29uc2lkZXIgYSByZWZlcmVuY2UgdG8gdGhhdCwgc28g eW91IGNhbiBjYXB0dXJlIHRoZSBwcm9jZXNzZXMgZm9yIA0Kd2Fsa2luZyBiYWNrIGFsbG9jYXRp b25zIHRoYXQgZG9uJ3QgZ2V0IGZpbmFsaXplZC4gT3IsIHVubGVzcyB5b3Ugd2FudCANCmFkZGl0 aW9uYWwgcmVzdHJpY3Rpb25zIG5vdCBpbiB0aGUgQkNQLCB5b3UgY291bGQgbGVhdmUgb3V0IG1l bnRpb24gb2YgDQplYXJseSBhbGxvY2F0aW9ucyBjb21wbGV0ZWx5LCBhbmQgbGV0IElBTkEgZGVh bCB3aXRoIGl0IGFjY29yZGluZyB0byANCnN0YW5kYXJkIHByb2NlZHVyZXMuDQoNCg0KWy4uLl0N Cg0K From nobody Wed Apr 22 19:13:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7148D1A0167; Wed, 22 Apr 2015 19:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaddCqsgWnDi; Wed, 22 Apr 2015 19:13:09 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 18D0C1A0163; Wed, 22 Apr 2015 19:13:09 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so3012264lbb.3; Wed, 22 Apr 2015 19:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ycpUBpLkRTw80yFgvDnprbgP01UAtt1IbsrfjHX3MX0=; b=J/voN3Q4UYTunV5kAhWNRaSLOWjU4YGeIiAFVyKGXcuBUAH53Zz+LpR2BE/vOK0594 gYCzZj3l4f2hI+mbojbvPDIDL9XEqjsc/Q1Js8A0xSJrf2NqTRdHWVhPy0NQuQoncFNz xC+jN6Kcg0LCCz3JW2H6MUoHNIZTDT6cm060mXxXYrLkHX3EEraf6XhnXmVDwT778Pfk EbKZrWrwa+0/ivZIu3tKVFmv/TIvpZCGPGJtCZZp29/KrJw8Qs7VFTwyIbox7HQRDQWQ MEE8bJrnEnJMlKJfJC4ajVcrMmK0o6xpWJ3XUgt66DMryhqS/I4MOaklhwhu9K3nJJiy nrRA== MIME-Version: 1.0 X-Received: by 10.152.204.40 with SMTP id kv8mr402492lac.113.1429755187658; Wed, 22 Apr 2015 19:13:07 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Wed, 22 Apr 2015 19:13:07 -0700 (PDT) In-Reply-To: References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu> <82268A04-588C-4D43-A638-8D99E76727DD@mit.edu> Date: Wed, 22 Apr 2015 22:13:07 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a11347da613830d05145ad289 Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , Ben Campbell , Phil Hunt , "" , The IESG , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 02:13:11 -0000 --001a11347da613830d05145ad289 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, guys. Let me know when tis has been addressed. Kathleen On Wed, Apr 22, 2015 at 7:35 PM, Mike Jones wrote: > I'd be fine adding the BCP 100 reference. I'd rather that we keep the > early registration procedures language. > > -- Mike > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, April 22, 2015 2:31 PM > To: Justin Richer > Cc: draft-ietf-oauth-dyn-reg@ietf.org; Phil Hunt; ; Mike > Jones; The IESG; oauth-chairs@ietf.org > Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on > draft-ietf-oauth-dyn-reg-27: (with COMMENT) > > On 21 Apr 2015, at 20:30, Justin Richer wrote: > > > Ben et. al, > > > > We=E2=80=99ve incorporated feedback into the latest draft: > > > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 > > > >> > > I think that resolves all my comments save one: > > [...] > > >> > >>> > >>> 4.1 and 4.2 allow the designated expert to accept preliminary > >>> registrations if they are confident a spec will be published. > >>> Shouldn't > >>> this follow the normal processes for preliminary registrations? Is > >>> there > >>> a way to walk back registrations if the spec isn't published after > >>> all? > >> > >> I=E2=80=99ll defer to others=E2=80=99 expertise on the right text for = the IANA > >> section, this was imported from another example spec. > >> > > BCP 100 (RFC 7120) describes the IANA early allocation procedures. You > might consider a reference to that, so you can capture the processes for > walking back allocations that don't get finalized. Or, unless you want > additional restrictions not in the BCP, you could leave out mention of > early allocations completely, and let IANA deal with it according to > standard procedures. > > > [...] > > --=20 Best regards, Kathleen --001a11347da613830d05145ad289 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, guys.=C2=A0 Let me know when tis has been addresse= d.

Kathleen

On Wed, Apr 22, 2015 at 7:35 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
I'd be fine adding the BCP 100 reference.=C2=A0 I'd = rather that we keep the early registration procedures language.

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

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.c= om]
Sent: Wednesday, April 22, 2= 015 2:31 PM
To: Justin Richer
Cc: draft-ietf-oauth-d= yn-reg@ietf.org; Phil Hunt; <oauth= @ietf.org>; Mike Jones; The IESG; oauth-chairs@ietf.org
Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth= -dyn-reg-27: (with COMMENT)

On 21 Apr 2015, at 20:30, Justin Richer wrote:

> Ben et. al,
>
> We=E2=80=99ve incorporated feedback into the latest draft:
>
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 > <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28>
>>

I think that resolves all my comments save one:

[...]

>>
>>>
>>> 4.1 and 4.2 allow the designated expert to accept preliminary<= br> >>> registrations if they are confident a spec will be published.<= br> >>> Shouldn't
>>> this follow the normal processes for preliminary registrations= ? Is
>>> there
>>> a way to walk back registrations if the spec isn't publish= ed after
>>> all?
>>
>> I=E2=80=99ll defer to others=E2=80=99 expertise on the right text = for the IANA
>> section, this was imported from another example spec.
>>

BCP 100 (RFC 7120) describes the IANA early allocation procedures. You
might consider a reference to that, so you can capture the processes for walking back allocations that don't get finalized. Or, unless you want<= br> additional restrictions not in the BCP, you could leave out mention of
early allocations completely, and let IANA deal with it according to
standard procedures.


[...]




--
=

Best regards,
Kathleen
--001a11347da613830d05145ad289-- From nobody Thu Apr 23 08:03:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147741B2A1F; Wed, 22 Apr 2015 14:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f6MCASDvv4C; Wed, 22 Apr 2015 14:31:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6A9F01B2A24; Wed, 22 Apr 2015 14:31:24 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3MLVDqd059556 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2015 16:31:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Justin Richer" Date: Wed, 22 Apr 2015 16:31:13 -0500 Message-ID: In-Reply-To: <82268A04-588C-4D43-A638-8D99E76727DD@mit.edu> References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu> <82268A04-588C-4D43-A638-8D99E76727DD@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Thu, 23 Apr 2015 08:03:50 -0700 Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , Phil Hunt , "" , The IESG , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:31:34 -0000 On 21 Apr 2015, at 20:30, Justin Richer wrote: > Ben et. al, > > We’ve incorporated feedback into the latest draft: > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 > >> I think that resolves all my comments save one: [...] >> >>> >>> 4.1 and 4.2 allow the designated expert to accept preliminary >>> registrations if they are confident a spec will be published. >>> Shouldn't >>> this follow the normal processes for preliminary registrations? Is >>> there >>> a way to walk back registrations if the spec isn't published after >>> all? >> >> I’ll defer to others’ expertise on the right text for the IANA >> section, this was imported from another example spec. >> BCP 100 (RFC 7120) describes the IANA early allocation procedures. You might consider a reference to that, so you can capture the processes for walking back allocations that don't get finalized. Or, unless you want additional restrictions not in the BCP, you could leave out mention of early allocations completely, and let IANA deal with it according to standard procedures. [...] From nobody Thu Apr 23 08:03:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A701B2E5A; Wed, 22 Apr 2015 20:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY-jeLnoA_C6; Wed, 22 Apr 2015 20:06:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C17ED1B2E57; Wed, 22 Apr 2015 20:06:15 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3N364jO089960 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2015 22:06:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Mike Jones" Date: Wed, 22 Apr 2015 22:06:04 -0500 Message-ID: In-Reply-To: References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu> <82268A04-588C-4D43-A638-8D99E76727DD@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Thu, 23 Apr 2015 08:03:50 -0700 Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , Phil Hunt , "" , The IESG , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 03:06:19 -0000 On 22 Apr 2015, at 18:35, Mike Jones wrote: > I'd be fine adding the BCP 100 reference. I'd rather that we keep the > early registration procedures language. That would work for me. > > -- Mike > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, April 22, 2015 2:31 PM > To: Justin Richer > Cc: draft-ietf-oauth-dyn-reg@ietf.org; Phil Hunt; ; > Mike Jones; The IESG; oauth-chairs@ietf.org > Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on > draft-ietf-oauth-dyn-reg-27: (with COMMENT) > > On 21 Apr 2015, at 20:30, Justin Richer wrote: > >> Ben et. al, >> >> We’ve incorporated feedback into the latest draft: >> >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 >> >>> > > I think that resolves all my comments save one: > > [...] > >>> >>>> >>>> 4.1 and 4.2 allow the designated expert to accept preliminary >>>> registrations if they are confident a spec will be published. >>>> Shouldn't >>>> this follow the normal processes for preliminary registrations? Is >>>> there >>>> a way to walk back registrations if the spec isn't published after >>>> all? >>> >>> I’ll defer to others’ expertise on the right text for the IANA >>> section, this was imported from another example spec. >>> > > BCP 100 (RFC 7120) describes the IANA early allocation procedures. You > might consider a reference to that, so you can capture the processes > for > walking back allocations that don't get finalized. Or, unless you want > additional restrictions not in the BCP, you could leave out mention of > early allocations completely, and let IANA deal with it according to > standard procedures. > > > [...] From nobody Thu Apr 23 21:53:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB251B2C88 for ; Thu, 23 Apr 2015 21:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJfeJ0rrYT_5 for ; Thu, 23 Apr 2015 21:53:23 -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 EDC1E1B2C62 for ; Thu, 23 Apr 2015 21:52:45 -0700 (PDT) Received: by oign205 with SMTP id n205so31920165oig.2 for ; Thu, 23 Apr 2015 21:52:45 -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 :cc:content-type; bh=8NwyKv9DaqwR8eBDnLk5Odx6JJ4eCS9CRMhPQ/5u0Wo=; b=zGiFu6e/FqUarZrG7KH0mk26FdktYGLZcDv6MDkdoc6hQNoy3y2l+rponEi/z0L8NJ LgpB03iozUw4MABfkjFx1oqPSLBuJ81akvckSfRzhYs5s4IprTL82eCZDzSUz+GQ9TEj kOTMQ4V2uJ8r5SZ+1RIHD4fyP9dOMkXwzH303Q9TJr126BleHRzwYT/dA87sbn0KaeL7 rEUJXMjQKLV6yPRLX27COQuINZcepZK9MHngd20NE7gV8EQPtahH75OsLDt6bosgrCEA 3ilie2p1nE8364zug3jJZ9BqucLf8O88Jjm63NYsX44A3FpYYLv3M84tiZgQWKg/lzE3 JZ/A== X-Received: by 10.60.148.225 with SMTP id tv1mr5552372oeb.14.1429851165302; Thu, 23 Apr 2015 21:52:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Fri, 24 Apr 2015 04:52:44 +0000 Message-ID: To: Thomas Broyer , Justin Richer , mar adrian belen Content-Type: multipart/alternative; boundary=047d7b3a7f7eca269c0514712a9e Archived-At: Cc: "" Subject: Re: [OAUTH-WG] hijacking client's user account X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 04:53:24 -0000 --047d7b3a7f7eca269c0514712a9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You know, using email address as a verified user identifier is appallingly bad idea. Even if it were verified at the enrollment time, if the mail address was recycled, the original account holder is screwed. It has been known for so many years now and finding that sites still do that makes me sad. Nat 2015=E5=B9=B44=E6=9C=8822=E6=97=A5(=E6=B0=B4) 9:22 Thomas Broyer : > Also, this is not news: > http://securityintelligence.com/spoofedme-social-login-attack-discovered-= by-ibm-x-force-researchers/ > > On Wed, Apr 22, 2015 at 5:02 PM Justin Richer wrote: > >> This seems to be not a problem with OAuth but with misusing OAuth as an >> authentication protocol: >> >> http://oauth.net/articles/authentication/ >> >> And with trusting unverified claims from a third party IdP (such as a >> self-asserted email address), which is covered in the OpenID Connect >> specification, an authentication protocol built on top of OAuth: >> >> http://openid.net/specs/openid-connect-core-1_0.html#ClaimStability >> >> You should probably let the client know in this case that they should no= t >> be using the email address as a key if they=E2=80=99re not verifying it = themselves. >> If the authentication article can be updated to include this misuse, ple= ase >> help us amend it! >> >> =E2=80=94 Justin >> >> On Apr 20, 2015, at 8:55 PM, mar adrian belen >> wrote: >> >> Some web application are using oauth 2 technology as login alternative , >> i found a way how can i access client application using unverified >> email(victim email) on >> >> oauth oauth provider, if oauth provider allows unverified email to use >> it's oauth service which can abuse by the attacker, this is possible if = the >> client provider >> >> directly login the user(using oauth) if his email is already exists on >> they record. >> >> >> * user joe has account on CLIENT A using his email address >> victimjoe@test.com, but does not have oauth provider account. attacker >> knows that. >> >> * now the attacker create a new oauth provider account using >> victimjoe@test.com. >> >> * because an unverified email can used the oauth provider oauth and the >> CLIENT A is using oauth provider's oauth as an alternative login, the >> attacker can now access >> >> victim's Client Application(CLIENT A) account using the login >> alternative function. >> >> >> you can try github(oauth provider) and https://sprint.ly/ (client) >> >> >> https://www.dropbox.com/s/jhrgn311i0e28pc/hijackoauthclient_x264.mp4?dl= =3D0 >> _______________________________________________ >> 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 > --047d7b3a7f7eca269c0514712a9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You know, using email address as a verified user identifier is appallingly = bad idea. Even if it were verified at the enrollment time, if the mail addr= ess was recycled, the original account holder is screwed. It has been known= for so many years now and finding that sites still do that makes me sad. <= br>
Nat

2015=E5=B9=B44=E6=9C=8822=E6= =97=A5(=E6=B0=B4) 9:22 Thomas Broyer <t.broyer@gmail.com>:

On Wed, Apr 22, 2015 at 5:02 PM Justin Richer <jricher@mit.edu> wrote:
This se= ems to be not a problem with OAuth but with misusing OAuth as an authentica= tion protocol:




You should probably let the client know in this case that they should not = be using the email address as a key if they=E2=80=99re not verifying it the= mselves. If the authentication article can be updated to include this misus= e, please help us amend it!
=

=C2=A0=E2=80=94 Justin

On Apr 20, 2015= , at 8:55 PM, mar adrian belen <maradrianbelen@gmail.com> wrote:

Some web application are using oauth 2 technology as= login alternative , i found a way how can i access client application usin= g unverified email(victim email) on=C2=A0

oauth oa= uth provider, if oauth provider allows unverified email to use it's oau= th service which can abuse by the attacker, this is possible if the client = provider=C2=A0

directly login the user(using oauth= ) if his email is already exists on they record.

<= br>
* user joe has account on CLIENT A using his email address victimjoe@test.com, but does not have oauth provider account. attacker knows that.

* now the attacker create a new oauth provider account usin= g victimjoe@test.co= m.

* because an unverified email can used the = oauth provider oauth and the CLIENT A is using oauth provider's oauth a= s an alternative login, the attacker can now access=C2=A0

victim's Client =C2=A0Application(CLIENT A) account using the l= ogin alternative =C2=A0function.


yo= u can try github(oauth provider) and =C2=A0https://sprint.ly/ =C2=A0(client)

=

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--047d7b3a7f7eca269c0514712a9e-- From nobody Fri Apr 24 04:52:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218E41A900A; Fri, 24 Apr 2015 04:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc7BL3e5-RS4; Fri, 24 Apr 2015 04:52:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9FA1A902B; Fri, 24 Apr 2015 04:52:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 04:52:05 -0700 Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 11:52:09 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-oauth-dyn-reg-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) cleared (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the "https" requirement (1st bullet in section 5) is useful there. We had some mail discussion on this but I'd like to continue that a bit more to understand if the changes in -28 address the issue. I'll send mail. (3) cleared ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My previous DISCUSS point (1) is below. That has been handled via new text in section 5 (on p27). I do wonder though if you ought also say a bit about, or point at a reference describing, the possible bad outcomes if one of these URLs goes bad. The new text I think assumes that the developer will get how bad that can be, but I'm not sure if they would or not. (1) General: there are many URIs sent to the AS from the client here. Nothing prevents the client messing about with the content served from those later, after registration. What mechanism holds clients accountable for such misbehaviours? (Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5 does say that the AS "SHOULD check" but does not say what "checking" means, nor what to do if the check fails. I think a bit more security considerations-like text here, reflecting what is (or ought;-) actually be done would be good. Do you agree? --- OLD COMMENTS, I didn't check if they'd been handled - s2, software_version: what is the impact if the s/w is updated twice a day, every day? - 3.2.1 - why is the response status 201? That may be correct, but seems to subtle if so to only state in an exmaple. - s5, last para - "be very particular" is not good spec language - what do you actually mean that can be implemented? - thanks for section 6 - it's great to see thought being devoted to these issues. - Did the secdir review [1] get a response? And I think I quite agree with Charlie's point#2 about versions. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html From nobody Fri Apr 24 05:09:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9EA1ACD27; Fri, 24 Apr 2015 05:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VTfcvtoSUXp; Fri, 24 Apr 2015 05:09:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C83B1ACD0C; Fri, 24 Apr 2015 05:09:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3EEC7BE54; Fri, 24 Apr 2015 13:09:44 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g18rmxCQTdUU; Fri, 24 Apr 2015 13:09:44 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16DDEBE53; Fri, 24 Apr 2015 13:09:44 +0100 (IST) Message-ID: <553A3289.2000401@cs.tcd.ie> Date: Fri, 24 Apr 2015 13:09:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: The IESG References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> In-Reply-To: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:09:50 -0000 So this is to follow up on my discuss point#2, which said: (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the "https" requirement (1st bullet in section 5) is useful there. In -28 you added a bit of text to 3.2.1. saying: "The client or developer can check the values in the response to determine if the registration is sufficient for use (e.g., the registered "token_endpoint_auth_method" is supported by the client software) and determine a course of action appropriate for the client software. The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider." That new text may be fine, but I'd like to check that I understand it correctly and that it addresses the issue sensibly. Say I'm a developer who writes and distributes a client that uses this and I test it with the BIGreg.example.com registration endpoint and it works, but for my application to work I need a specific token_endpoint_auth_method, say client_secret_basic. Say time passes, and we discover that client_secret_basic is bad for some reason and client_secret_supergood is invented and gets used a lot. At that point BIGreg.example.com would like to turn off the (now-crappy) client_secret_basic and only allow use of client_secret_supergood. If it does that, then new installs of our application will fail at registration time with an (opaque) error to the human user and we need the application developer to do an update to add client_secret_supergood. Or, what seems more likely is that BIGreg.example.com will have to keep offering the now insecure client_secret_basic until essentially no interesting applications remain that don't support the new, better thing. And that's the bit I don't like so much. This spec could (maybe, I'm not 100% sure) have been written to allow for the client and registration endpoint to first try to use the new better things and, if that doesn't work, to try fallback to the old not so good things, but that is not supported here afaics - once the client sees response metadata it doesn't like, there's no way for the client to say "bummer, I'd have been fine if only you'd said foo and not bar, can we try register again and use foo?" And I also don't see how the client who is really stuck can tell the registration endpoint "actually, I'm not successfully registered because your said bar and I don't like that bit of metadata" - won't that lead to our BIGreg.example.com ending up with a misleading picture of what clients were successfully registered? So my question is: is all that really ok, or am I confused in the above? (And confused is quite possible - this is OAuth after all:-) Cheers, S. From nobody Fri Apr 24 05:20:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715B41ACE17; Fri, 24 Apr 2015 05:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJcSP7A-MzeY; Fri, 24 Apr 2015 05:20:31 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB251ACE27; Fri, 24 Apr 2015 05:20:30 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-ca-553a350c54be Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 79.AF.03700.D053A355; Fri, 24 Apr 2015 08:20:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t3OCKSEx009790; Fri, 24 Apr 2015 08:20:28 -0400 Received: from [192.168.128.56] (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 t3OCKPlM010414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2015 08:20:26 -0400 Message-ID: <553A34FE.8@mit.edu> Date: Fri, 24 Apr 2015 08:20:14 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> In-Reply-To: <553A3289.2000401@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1uU1tQo1aD/GbjHt52s2ixl/JjJb 3J67ks3i5NtXbBbT915jd2D1WNt9lc1jyZKfTAFMUVw2Kak5mWWpRfp2CVwZp27/YyzYoV3x tncecwPjPaUuRk4OCQETiZVn/jJD2GISF+6tZwOxhQQWM0nM+WbYxcgFZG9klHh85z0rhHOb SeLw+wVAHRwcvAIKEhMPRoA0sAioSvQe+wA2iA3Inr6mhQnEFhWIkpj49RALiM0rIChxcuYT MFtEwFPiYd8pMJtZwEeid9plsHphgTyJjkNdUEfESixesQbM5hTQlOj7s58Zot5W4s7c3VC2 vMT2t3OYJzAKzkKyYhaSsllIyhYwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p 3cQICm52F+UdjH8OKh1iFOBgVOLhnTHHMlSINbGsuDL3EKMkB5OSKG+nlFWoEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHeZwZAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZ Dg4lCV4xY6BGwaLU9NSKtMycEoQ0EwcnyHAeoOFhIDW8xQWJucWZ6RD5U4yKUuK8oSAJAZBE RmkeXC8s+bxiFAd6RZi3GaSKB5i44LpfAQ1mAho8c6kFyOCSRISUVANjy7nXJ86nFeXxVp29 G8V6L2zvfoX73JuuKZ6dmX9ebPOus5tsrzbo/+ZbeXbntt7tt+MfbZieI/YsRaVfMLstt4bx 5Ddx9qLo2OnzudYsSD4x4caFFXelE+533ZGMMunz+Vrlq7Kz2vWYgbH43evcL9796GR4sSEi pV/OqKWybavyyyalfRzLlViKMxINtZiLihMBhDb/oBkDAAA= Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:20:33 -0000 Stephen, thanks for the comments. We discussed but decided to stop short of a full back-and-forth multi-trip information negotiation protocol in order to keep things as simple as possible for the simple case. The model here is that the client *requests* a certain set of information in the registration, and the server *dictates* to the client what actually occurred. This is to allow sensible defaults for blank fields, and other mechanisms like that. Instead of just saying "no", the server here has an opportunity to do something slightly reasonable. It's up to the client if it agrees with the reasonableness, and most clients (in my experience) are going to be super dumb and just do what they're told by the server if they're able to. If they're unable to, they'll just fail to use the OAuth protocol with that AS and users will complain (rightly) of an incompatibility bug. A smarter client can try to re-register and see if that works instead, but the vast majority of OAuth clients are really dumb (by design). However, there's a bit more to the story: As it turns out, when coupled with the management protocol and a discovery mechanism, you actually can do more of a negotiated registration with the existing mechanism: client says "I want foo", server says "you get bar", client sends an UPDATE that says "can I have baz instead?", and so forth. Without the update mechanism, you don't have a way to tie one registration request to a subsequent one. If you've got server capability discovery (such as is defined in OpenID Connect and still-ignored by this working group) then you've got the ability for a smart client to see which values might work ahead of time. This gets a little tricky with values that have relationships (such as grant_types and response_types), but it's still workable when they've got well-defined relationships (as is required in the Dyn Reg spec). So it really is out of scope for us to say what the client does when it gets information back it doesn't want: it can ignore it, fail on it, or use it. With management and discovery, it can try to re-negotiate, but that's a fairly sophisticated behavior. Hope this helps, -- Justin On 4/24/2015 8:09 AM, Stephen Farrell wrote: > So this is to follow up on my discuss point#2, which said: > > (2) If the response (defined in 3.2.1) includes metadata that > the server has altered, but that the client doesn't like, then > what does the client do? (It may be that that's ok, but I'm > not following why that is the case.) I'm also not sure the > "https" requirement (1st bullet in section 5) is useful there. > > In -28 you added a bit of text to 3.2.1. saying: > > "The client or developer can check the values in the response to > determine if the registration is sufficient for use (e.g., the > registered "token_endpoint_auth_method" is supported by the client > software) and determine a course of action appropriate for the client > software. The response to such a situation is out of scope for this > specification but could include filing a report with the application > developer or authorization server provider." > > That new text may be fine, but I'd like to check that I > understand it correctly and that it addresses the issue > sensibly. > > Say I'm a developer who writes and distributes a client > that uses this and I test it with the BIGreg.example.com > registration endpoint and it works, but for my application > to work I need a specific token_endpoint_auth_method, say > client_secret_basic. > > Say time passes, and we discover that client_secret_basic > is bad for some reason and client_secret_supergood is > invented and gets used a lot. > > At that point BIGreg.example.com would like to turn off > the (now-crappy) client_secret_basic and only allow use > of client_secret_supergood. If it does that, then new > installs of our application will fail at registration > time with an (opaque) error to the human user and we > need the application developer to do an update to add > client_secret_supergood. > > Or, what seems more likely is that BIGreg.example.com > will have to keep offering the now insecure > client_secret_basic until essentially no interesting > applications remain that don't support the new, better > thing. And that's the bit I don't like so much. > > This spec could (maybe, I'm not 100% sure) have been > written to allow for the client and registration endpoint > to first try to use the new better things and, if that > doesn't work, to try fallback to the old not so good > things, but that is not supported here afaics - once > the client sees response metadata it doesn't like, > there's no way for the client to say "bummer, I'd have > been fine if only you'd said foo and not bar, can we > try register again and use foo?" > > And I also don't see how the client who is really stuck > can tell the registration endpoint "actually, I'm not > successfully registered because your said bar and I don't > like that bit of metadata" - won't that lead to our > BIGreg.example.com ending up with a misleading picture > of what clients were successfully registered? > > So my question is: is all that really ok, or am I confused > in the above? (And confused is quite possible - this is > OAuth after all:-) > > Cheers, > S. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Apr 24 05:24:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1268F1AD377; Fri, 24 Apr 2015 05:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSXR-u0CkOGx; Fri, 24 Apr 2015 05:24:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E871B29FC; Fri, 24 Apr 2015 05:24:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91582BE54; Fri, 24 Apr 2015 13:24:03 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32GXEUPBbh8A; Fri, 24 Apr 2015 13:24:03 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6756ABE53; Fri, 24 Apr 2015 13:24:03 +0100 (IST) Message-ID: <553A35E4.1000904@cs.tcd.ie> Date: Fri, 24 Apr 2015 13:24:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Justin Richer , The IESG References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> In-Reply-To: <553A34FE.8@mit.edu> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:24:07 -0000 On 24/04/15 13:20, Justin Richer wrote: > Stephen, thanks for the comments. > > We discussed but decided to stop short of a full back-and-forth > multi-trip information negotiation protocol in order to keep things as > simple as possible for the simple case. The model here is that the > client *requests* a certain set of information in the registration, and > the server *dictates* to the client what actually occurred. This is to > allow sensible defaults for blank fields, and other mechanisms like > that. Instead of just saying "no", the server here has an opportunity to > do something slightly reasonable. It's up to the client if it agrees > with the reasonableness, and most clients (in my experience) are going > to be super dumb and just do what they're told by the server if they're > able to. If they're unable to, they'll just fail to use the OAuth > protocol with that AS and users will complain (rightly) of an > incompatibility bug. A smarter client can try to re-register and see if > that works instead, but the vast majority of OAuth clients are really > dumb (by design). > > However, there's a bit more to the story: As it turns out, when coupled > with the management protocol and a discovery mechanism, you actually can > do more of a negotiated registration with the existing mechanism: client > says "I want foo", server says "you get bar", client sends an UPDATE > that says "can I have baz instead?", and so forth. Without the update > mechanism, you don't have a way to tie one registration request to a > subsequent one. If you've got server capability discovery (such as is > defined in OpenID Connect and still-ignored by this working group) then > you've got the ability for a smart client to see which values might work > ahead of time. This gets a little tricky with values that have > relationships (such as grant_types and response_types), but it's still > workable when they've got well-defined relationships (as is required in > the Dyn Reg spec). > > So it really is out of scope for us to say what the client does when it > gets information back it doesn't want: it can ignore it, fail on it, or > use it. With management and discovery, it can try to re-negotiate, but > that's a fairly sophisticated behavior. So could we just point at the relevant specs for that behaviour? (Not normatively, and I don't care if they're not RFCs.) S. > > Hope this helps, > -- Justin > > On 4/24/2015 8:09 AM, Stephen Farrell wrote: >> So this is to follow up on my discuss point#2, which said: >> >> (2) If the response (defined in 3.2.1) includes metadata that >> the server has altered, but that the client doesn't like, then >> what does the client do? (It may be that that's ok, but I'm >> not following why that is the case.) I'm also not sure the >> "https" requirement (1st bullet in section 5) is useful there. >> >> In -28 you added a bit of text to 3.2.1. saying: >> >> "The client or developer can check the values in the response to >> determine if the registration is sufficient for use (e.g., the >> registered "token_endpoint_auth_method" is supported by the client >> software) and determine a course of action appropriate for the client >> software. The response to such a situation is out of scope for this >> specification but could include filing a report with the application >> developer or authorization server provider." >> >> That new text may be fine, but I'd like to check that I >> understand it correctly and that it addresses the issue >> sensibly. >> >> Say I'm a developer who writes and distributes a client >> that uses this and I test it with the BIGreg.example.com >> registration endpoint and it works, but for my application >> to work I need a specific token_endpoint_auth_method, say >> client_secret_basic. >> >> Say time passes, and we discover that client_secret_basic >> is bad for some reason and client_secret_supergood is >> invented and gets used a lot. >> >> At that point BIGreg.example.com would like to turn off >> the (now-crappy) client_secret_basic and only allow use >> of client_secret_supergood. If it does that, then new >> installs of our application will fail at registration >> time with an (opaque) error to the human user and we >> need the application developer to do an update to add >> client_secret_supergood. >> >> Or, what seems more likely is that BIGreg.example.com >> will have to keep offering the now insecure >> client_secret_basic until essentially no interesting >> applications remain that don't support the new, better >> thing. And that's the bit I don't like so much. >> >> This spec could (maybe, I'm not 100% sure) have been >> written to allow for the client and registration endpoint >> to first try to use the new better things and, if that >> doesn't work, to try fallback to the old not so good >> things, but that is not supported here afaics - once >> the client sees response metadata it doesn't like, >> there's no way for the client to say "bummer, I'd have >> been fine if only you'd said foo and not bar, can we >> try register again and use foo?" >> >> And I also don't see how the client who is really stuck >> can tell the registration endpoint "actually, I'm not >> successfully registered because your said bar and I don't >> like that bit of metadata" - won't that lead to our >> BIGreg.example.com ending up with a misleading picture >> of what clients were successfully registered? >> >> So my question is: is all that really ok, or am I confused >> in the above? (And confused is quite possible - this is >> OAuth after all:-) >> >> Cheers, >> S. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Apr 24 05:28:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8C61B2C27; Fri, 24 Apr 2015 05:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfEuFAOjDiKv; Fri, 24 Apr 2015 05:28:30 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC9F1ACE15; Fri, 24 Apr 2015 05:28:29 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-1d-553a36ecd36d 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 dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2F.84.03359.CE63A355; Fri, 24 Apr 2015 08:28:28 -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 t3OCSRXN013175; Fri, 24 Apr 2015 08:28:27 -0400 Received: from [192.168.128.56] (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 t3OCSPDY012514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2015 08:28:26 -0400 Message-ID: <553A36DE.5040501@mit.edu> Date: Fri, 24 Apr 2015 08:28:14 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: oauth@ietf.org, Stephen Farrell , The IESG , oauth-chairs@ietf.org, draft-ietf-oauth-dyn-reg@ietf.org References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> In-Reply-To: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixG6novvGzCrUoL9X02Laz9dsFjP+TGS2 uD13JZvFybev2Cym773G7sDqsbb7KpvHkiU/mQKYorhsUlJzMstSi/TtErgyOvbcZSloU6jY tHgnewPjNckuRk4OCQETie37XrJA2GISF+6tZ+ti5OIQEljMJPG+4TsjhLORUWL1rlNQzm0m iSlPf4O18AqoSbx8+54ZxGYRUJXYtuw8K4jNBmRPX9PCBGKLCkRJTPx6CKpeUOLkzCcsIINE BJYySiw8vg+sQVggT6LjUBcbiC0k4CDx5O4PoGYODk4BR4mPU8pAwswCthJ35u5mhrDlJba/ ncM8gVFgFpKxs5CUzUJStoCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuoV5uZoleakrpJkZQ IHNK8uxgfHNQ6RCjAAejEg/vjDmWoUKsiWXFlbmHGCU5mJREeTulrEKF+JLyUyozEosz4otK c1KLDzFKcDArifA+MwDK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8P4xAWoULEpNT61Iy8wpQUgzcXCCDOcBGl5uCjK8uCAxtzgzHSJ/ilFRSpzXDiQhAJLIKM2D 64UlmleM4kCvCPMuA6niASYpuO5XQIOZgAbPXGoBMrgkESEl1cDYb14ueP1dgcS3v03b+q6f PrDxn/zucy9XiJ/xWH3/7e8MJU5f2SvHHveVtuxaPkHtX9kqvc55AjaxdzO5jCau8JTZ1cBe 6nOge/fNmQIlc1TcTA48m6u64XpmT0Lr2k36dfLr+5f0NEeWNhsvX/EwlGl60LOGR/5LS30X GH1QOME6/x3X7G4/JZbijERDLeai4kQATlco7Q8DAAA= Archived-At: Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:28:32 -0000 > I do wonder > though if you ought also say a bit about, or point at a > reference describing, the possible bad outcomes if > one of these URLs goes bad. The new text I think > assumes that the developer will get how bad that can > be, but I'm not sure if they would or not. It can get as bad as the web, which is pretty bad, but I hope we don't have to point that out in great detail in every RFC that deals with the web. :) I think the drive-by-download malware example is a good one, and we could add another concrete one if you've got an idea, but I think the advice we have is sound and actionable and we should avoid having this spec be a catalogue of "bad things what can happen on the web". If there is such a reference, I'm happy to point to it! -- Justin On 4/24/2015 7:52 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-dyn-reg-28: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) cleared > > (2) If the response (defined in 3.2.1) includes metadata that > the server has altered, but that the client doesn't like, then > what does the client do? (It may be that that's ok, but I'm > not following why that is the case.) I'm also not sure the > "https" requirement (1st bullet in section 5) is useful there. > > We had some mail discussion on this but I'd like to > continue that a bit more to understand if the changes > in -28 address the issue. I'll send mail. > > (3) cleared > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > My previous DISCUSS point (1) is below. That has been > handled via new text in section 5 (on p27). I do wonder > though if you ought also say a bit about, or point at a > reference describing, the possible bad outcomes if > one of these URLs goes bad. The new text I think > assumes that the developer will get how bad that can > be, but I'm not sure if they would or not. > > (1) General: there are many URIs sent to the AS from the > client here. Nothing prevents the client messing about with > the content served from those later, after registration. What > mechanism holds clients accountable for such misbehaviours? > (Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5 > does say that the AS "SHOULD check" but does not say what > "checking" means, nor what to do if the check fails. I think > a bit more security considerations-like text here, reflecting > what is (or ought;-) actually be done would be good. Do you > agree? > > > --- OLD COMMENTS, I didn't check if they'd been handled > > - s2, software_version: what is the impact if the s/w is > updated twice a day, every day? > > - 3.2.1 - why is the response status 201? That may be correct, > but seems to subtle if so to only state in an exmaple. > > - s5, last para - "be very particular" is not good spec > language - what do you actually mean that can be implemented? > > - thanks for section 6 - it's great to see thought being > devoted to these issues. > > - Did the secdir review [1] get a response? And I think I > quite agree with Charlie's point#2 about versions. > > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Apr 24 05:30:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977661B2CA2; Fri, 24 Apr 2015 05:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XejhRnxtJ0tH; Fri, 24 Apr 2015 05:30:50 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0329C1B2CEB; Fri, 24 Apr 2015 05:30:49 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-6d-553a377877a0 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 85.67.03678.8773A355; Fri, 24 Apr 2015 08:30:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t3OCUlOV010740; Fri, 24 Apr 2015 08:30:48 -0400 Received: from [192.168.128.56] (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 t3OCUj8G013062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2015 08:30:46 -0400 Message-ID: <553A376A.1070806@mit.edu> Date: Fri, 24 Apr 2015 08:30:34 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> In-Reply-To: <553A35E4.1000904@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IR4hTV1q0wtwo1OLtS12Laz9dsFjP+TGS2 uD13JZvFybev2Cym773G7sDqsbb7KpvHkiU/mQKYorhsUlJzMstSi/TtErgy7v3+zl7wxrCi Y15MA+MMjS5GTg4JAROJxmetbBC2mMSFe+uBbC4OIYHFTBL7l59jB0kICWxklFh4LQsicZtJ 4tq1hSwgCV4BNYnvU4+AdbMIqErcfbQSzGYDsqevaWECsUUFoiQmfj0EVS8ocXLmEzBbRMBT 4mHfKTCbWcBHonfaZbB6YYE8iY5DXVBX9DNKPLz+GayIU0BT4suiGUwQDWYS8zY/ZIaw5SW2 v53DPIFRcBaSHbOQlM1CUraAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRroVebmaJXmpK6SZG UHizu6juYJxwSOkQowAHoxIP74w5lqFCrIllxZW5hxglOZiURHk7paxChfiS8lMqMxKLM+KL SnNSiw8xSnAwK4nwPjMAyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAo SfBqmAE1ChalpqdWpGXmlCCkmTg4QYbzAA2fB1LDW1yQmFucmQ6RP8WoKCXOOwMkIQCSyCjN g+uFpZ9XjOJArwjz5oBU8QBTF1z3K6DBTECDZy61ABlckoiQkmpgZLlUO4lD/8ivBVs/On58 enPzzapd9QlTw1bc/qZkZ9j6gpHryMq2W3YsXsfFrnTvXve34h/L0Wr77fwr5qxS47N19pHO dbjJH7D88W7BhUmNtassBEqOzFvDdt3fSrpA2a/B7QHf+yfnfNyC0zmazO9envoj6frZC4d3 56h3P/nKx2fEkfPBR4mlOCPRUIu5qDgRANGJmZ4aAwAA Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:30:52 -0000 On 4/24/2015 8:24 AM, Stephen Farrell wrote: > > On 24/04/15 13:20, Justin Richer wrote: >> Stephen, thanks for the comments. >> >> We discussed but decided to stop short of a full back-and-forth >> multi-trip information negotiation protocol in order to keep things as >> simple as possible for the simple case. The model here is that the >> client *requests* a certain set of information in the registration, and >> the server *dictates* to the client what actually occurred. This is to >> allow sensible defaults for blank fields, and other mechanisms like >> that. Instead of just saying "no", the server here has an opportunity to >> do something slightly reasonable. It's up to the client if it agrees >> with the reasonableness, and most clients (in my experience) are going >> to be super dumb and just do what they're told by the server if they're >> able to. If they're unable to, they'll just fail to use the OAuth >> protocol with that AS and users will complain (rightly) of an >> incompatibility bug. A smarter client can try to re-register and see if >> that works instead, but the vast majority of OAuth clients are really >> dumb (by design). >> >> However, there's a bit more to the story: As it turns out, when coupled >> with the management protocol and a discovery mechanism, you actually can >> do more of a negotiated registration with the existing mechanism: client >> says "I want foo", server says "you get bar", client sends an UPDATE >> that says "can I have baz instead?", and so forth. Without the update >> mechanism, you don't have a way to tie one registration request to a >> subsequent one. If you've got server capability discovery (such as is >> defined in OpenID Connect and still-ignored by this working group) then >> you've got the ability for a smart client to see which values might work >> ahead of time. This gets a little tricky with values that have >> relationships (such as grant_types and response_types), but it's still >> workable when they've got well-defined relationships (as is required in >> the Dyn Reg spec). >> >> So it really is out of scope for us to say what the client does when it >> gets information back it doesn't want: it can ignore it, fail on it, or >> use it. With management and discovery, it can try to re-negotiate, but >> that's a fairly sophisticated behavior. > So could we just point at the relevant specs for that behaviour? > (Not normatively, and I don't care if they're not RFCs.) > > S. OK, so are you asking for something like: "If the server supports an update mechanism such as [Dyn-Reg-Management] and a discovery mechanism such as [OIDC-Discovery], then a smart client could use these components to renegotiate undesirable metadata values." With both of these being informative references? I'm not opposed to it. -- Justin > >> Hope this helps, >> -- Justin >> >> On 4/24/2015 8:09 AM, Stephen Farrell wrote: >>> So this is to follow up on my discuss point#2, which said: >>> >>> (2) If the response (defined in 3.2.1) includes metadata that >>> the server has altered, but that the client doesn't like, then >>> what does the client do? (It may be that that's ok, but I'm >>> not following why that is the case.) I'm also not sure the >>> "https" requirement (1st bullet in section 5) is useful there. >>> >>> In -28 you added a bit of text to 3.2.1. saying: >>> >>> "The client or developer can check the values in the response to >>> determine if the registration is sufficient for use (e.g., the >>> registered "token_endpoint_auth_method" is supported by the client >>> software) and determine a course of action appropriate for the client >>> software. The response to such a situation is out of scope for this >>> specification but could include filing a report with the application >>> developer or authorization server provider." >>> >>> That new text may be fine, but I'd like to check that I >>> understand it correctly and that it addresses the issue >>> sensibly. >>> >>> Say I'm a developer who writes and distributes a client >>> that uses this and I test it with the BIGreg.example.com >>> registration endpoint and it works, but for my application >>> to work I need a specific token_endpoint_auth_method, say >>> client_secret_basic. >>> >>> Say time passes, and we discover that client_secret_basic >>> is bad for some reason and client_secret_supergood is >>> invented and gets used a lot. >>> >>> At that point BIGreg.example.com would like to turn off >>> the (now-crappy) client_secret_basic and only allow use >>> of client_secret_supergood. If it does that, then new >>> installs of our application will fail at registration >>> time with an (opaque) error to the human user and we >>> need the application developer to do an update to add >>> client_secret_supergood. >>> >>> Or, what seems more likely is that BIGreg.example.com >>> will have to keep offering the now insecure >>> client_secret_basic until essentially no interesting >>> applications remain that don't support the new, better >>> thing. And that's the bit I don't like so much. >>> >>> This spec could (maybe, I'm not 100% sure) have been >>> written to allow for the client and registration endpoint >>> to first try to use the new better things and, if that >>> doesn't work, to try fallback to the old not so good >>> things, but that is not supported here afaics - once >>> the client sees response metadata it doesn't like, >>> there's no way for the client to say "bummer, I'd have >>> been fine if only you'd said foo and not bar, can we >>> try register again and use foo?" >>> >>> And I also don't see how the client who is really stuck >>> can tell the registration endpoint "actually, I'm not >>> successfully registered because your said bar and I don't >>> like that bit of metadata" - won't that lead to our >>> BIGreg.example.com ending up with a misleading picture >>> of what clients were successfully registered? >>> >>> So my question is: is all that really ok, or am I confused >>> in the above? (And confused is quite possible - this is >>> OAuth after all:-) >>> >>> Cheers, >>> S. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Apr 24 05:38:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D39F1B2D9D; Fri, 24 Apr 2015 05:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amIfuthyG2Bf; Fri, 24 Apr 2015 05:38:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8150A1B2D9A; Fri, 24 Apr 2015 05:38:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58ABCBE55; Fri, 24 Apr 2015 13:38:00 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byQvqkE_Mvqg; Fri, 24 Apr 2015 13:38:00 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 30EF2BE50; Fri, 24 Apr 2015 13:38:00 +0100 (IST) Message-ID: <553A3929.3000002@cs.tcd.ie> Date: Fri, 24 Apr 2015 13:38:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Justin Richer , The IESG References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> In-Reply-To: <553A376A.1070806@mit.edu> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:38:02 -0000 On 24/04/15 13:30, Justin Richer wrote: >> > > OK, so are you asking for something like: > > "If the server supports an update mechanism such as [Dyn-Reg-Management] > and a discovery mechanism such as [OIDC-Discovery], then a smart client > could use these components to renegotiate undesirable metadata values." > > With both of these being informative references? I'm not opposed to it. That'd work for me, yes, thanks. S. From nobody Fri Apr 24 06:00:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5C21B2F01; Fri, 24 Apr 2015 06:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHz_2LUJxAJb; Fri, 24 Apr 2015 06:00:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E891B2F00; Fri, 24 Apr 2015 06:00:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D6E10BE55; Fri, 24 Apr 2015 14:00:26 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v05gHk7vXTQV; Fri, 24 Apr 2015 14:00:26 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A682DBE54; Fri, 24 Apr 2015 14:00:26 +0100 (IST) Message-ID: <553A3E6B.4040603@cs.tcd.ie> Date: Fri, 24 Apr 2015 14:00:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Justin Richer , oauth@ietf.org, The IESG , oauth-chairs@ietf.org, draft-ietf-oauth-dyn-reg@ietf.org References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A36DE.5040501@mit.edu> In-Reply-To: <553A36DE.5040501@mit.edu> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 13:00:30 -0000 On 24/04/15 13:28, Justin Richer wrote: >> > > It can get as bad as the web, which is pretty bad, but I hope we don't > have to point that out in great detail in every RFC that deals with the > web. :) I think the drive-by-download malware example is a good one, and > we could add another concrete one if you've got an idea, but I think the > advice we have is sound and actionable and we should avoid having this > spec be a catalogue of "bad things what can happen on the web". If there > is such a reference, I'm happy to point to it! That's fair. I'm not aware of a really good reference tbh. I wonder is there any relevant bits in the OAuth threat analysis? (I've not looked.) Or just a pointer to some well known incident might help. But this is a non-blocking comment, so you should feel entirely free to handle it as you think best. Cheers, S. From nobody Fri Apr 24 14:28:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1501AC437; Fri, 24 Apr 2015 14:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbnfiGACf5ga; Fri, 24 Apr 2015 14:28:04 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF29F1AC430; Fri, 24 Apr 2015 14:28:03 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-e4-553ab562f184 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 36.23.03678.265BA355; Fri, 24 Apr 2015 17:28:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t3OLS0bV032096; Fri, 24 Apr 2015 17:28:01 -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 t3OLRwbw013043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Apr 2015 17:27:59 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_14263F66-25AE-426B-A9CE-982D48DFD177"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <553A3929.3000002@cs.tcd.ie> Date: Fri, 24 Apr 2015 17:27:57 -0400 Message-Id: References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRmVeSWpSXmKPExsUixG6nrpu01SrU4OYLKYtpP1+zWcz4M5HZ 4vbclWwWJ9++YrOYvvcauwOrx9ruq2weS5b8ZApgiuKySUnNySxLLdK3S+DK2Hguo+C/SMXX +UuZGhi/CXQxcnJICJhIXNz+ghHCFpO4cG89WxcjF4eQwGImiVubm1ggnI2MEnMWNjJCOA+Z JFZf3M4G0iIskCMxb+cxJhCbV8BAYu6pL0wgRcwCUxglljdeY4aYKyXR9PoY2A42AVWJ6Wta wBo4BTQl5jQ+B7NZgOLb/r5hhWhuYZS4f2kxM8RUK4kft2HuOM4oMe31bLBJIgL6Ens3n2Pv YuQA2iAv0bMpfQKj4Cwkh8xCdghIgllAW2LZwtdQtqbE/u7lLBC2vMT2t3Og4pYSi2fegIrb StzqW8AEYdtJPJq2iHUBI8cqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXQu93MwSvdSU0k2M4Ohy Ud3BOOGQ0iFGAQ5GJR7eGXMsQ4VYE8uKK3MPMUpyMCmJ8nr3W4UK8SXlp1RmJBZnxBeV5qQW H2JUAdr1aMPqC4xSLHn5ealKIrz8vUB1vCmJlVWpRfkwZdIcLErivJt+8IUICaQnlqRmp6YW pBbBZGU4OJQkeHu3ADUKFqWmp1akZeaUIKSZODgPMUpw8AANDwCp4S0uSMwtzkyHyJ9iVJQS 5y0ASQiAJDJK8+B6YUnxFaM40FvCvNs2A1XxABMqXPcroMFMQINnLrUAGVySiJCSamC8dGPJ +4lX9kqYae5wy088/dd2ziUzg09/t9yb/OV63WfrB284i1bef7A3enXUSgaJXLY5v7O1L+e1 SCuvaX0rZrDlY02fod9R811es0vb/0b03bMK4I407Hn6aPmEA+2vt5rP2DedsXD+rSVrvFc0 5fTey8oKtp3fpxS0R7P2wK6mG22rTdatU2Ipzkg01GIuKk4EACng0nxlAwAA Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, "" , The IESG , oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:28:09 -0000 --Apple-Mail=_14263F66-25AE-426B-A9CE-982D48DFD177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, I=E2=80=99ve worked on this this afternoon and this is my = proposed text: The response to such a situation is out of scope for this specification but could = include filing a report with the application developer or = authorization server provider, attempted re-registration with different = metadata values, or various other methods. For instance, if the server = also supports a registration management mechanism such as that = defined in , the client = or developer could attempt to update the registration with = different metadata values. This process could also be aided by a service discovery protocol such as = which can list a server's capabilities, allowing a client to make a = more informed registration request. The use of any such management = or discovery system is OPTIONAL and outside the scope of this specification. Does this text work for you? =E2=80=94 Justin > On Apr 24, 2015, at 8:38 AM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 24/04/15 13:30, Justin Richer wrote: >>>=20 >>=20 >> OK, so are you asking for something like: >>=20 >> "If the server supports an update mechanism such as = [Dyn-Reg-Management] >> and a discovery mechanism such as [OIDC-Discovery], then a smart = client >> could use these components to renegotiate undesirable metadata = values." >>=20 >> With both of these being informative references? I'm not opposed to = it. >=20 > That'd work for me, yes, thanks. >=20 > S. --Apple-Mail=_14263F66-25AE-426B-A9CE-982D48DFD177 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVOrVeAAoJEDPAngkbd+w90VoH/2XlH1orGZcL03k0fBPrvH9O PQcBqMmvdROdHHqQ2r+rX4l6Ew8fYilDpTm9FTOqt50O509kXZHS2zL+l4aYP4wY QbS1HjPmhJkXGxE06qYgYxObE3B5tLK5WF23TDRgb84jw9nm6dU3Bb0FqW0R7r4b Y2Tt1YQio65t109gIMLLD6A3+nXxsisVyCmpnqu1edrUcnEJpdYnwXCY6RlB6SMI TD/nTuAo/aqBY2jw7h506rNGv+FFHJeOg4nDyPvs3VIfc4f2VJXeQvde4juk3jtv br0DzVlLArndQ0mt3WJvMn1tLT1Fl/CzVWJsFw9swelA4Yuv58XjFfpb+epLhPk= =GEPR -----END PGP SIGNATURE----- --Apple-Mail=_14263F66-25AE-426B-A9CE-982D48DFD177-- From nobody Fri Apr 24 14:32:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8B91AC3FF; Fri, 24 Apr 2015 14:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCKzjtDpJqmo; Fri, 24 Apr 2015 14:32:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3AE1ACD09; Fri, 24 Apr 2015 14:32:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3EEFCBE56; Fri, 24 Apr 2015 22:32:25 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-KPq27y8PCD; Fri, 24 Apr 2015 22:32:24 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DD6E0BE54; Fri, 24 Apr 2015 22:32:23 +0100 (IST) Message-ID: <553AB662.7010303@cs.tcd.ie> Date: Fri, 24 Apr 2015 22:32:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Justin Richer References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ewxTdCwvsVLkIAgq5tBOfJij7QeB1NGeG" Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, "" , The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:32:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ewxTdCwvsVLkIAgq5tBOfJij7QeB1NGeG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/04/15 22:27, Justin Richer wrote: > Stephen, I=E2=80=99ve worked on this this afternoon and this is my prop= osed text: >=20 > The response to such a > situation is out of scope for this specification but could i= nclude > filing a report with the application developer or authorizat= ion > server provider, attempted re-registration with different met= adata > values, or various other methods. For instance, if the server= also > supports a registration management mechanism such as that def= ined in > , the client = or > developer could attempt to update the registration with diffe= rent > metadata values. This process could also be aided by a servic= e > discovery protocol such as which > can list a server's capabilities, allowing a client to make a= more > informed registration request. The use of any such management= or > discovery system is OPTIONAL and outside the scope of this > specification. >=20 > Does this text work for you? It does, nicely. Thanks, S. >=20 > =E2=80=94 Justin >=20 >> On Apr 24, 2015, at 8:38 AM, Stephen Farrell wrote: >> >> >> >> On 24/04/15 13:30, Justin Richer wrote: >>>> >>> >>> OK, so are you asking for something like: >>> >>> "If the server supports an update mechanism such as [Dyn-Reg-Manageme= nt] >>> and a discovery mechanism such as [OIDC-Discovery], then a smart clie= nt >>> could use these components to renegotiate undesirable metadata values= =2E" >>> >>> With both of these being informative references? I'm not opposed to i= t. >> >> That'd work for me, yes, thanks. >> >> S. >=20 --ewxTdCwvsVLkIAgq5tBOfJij7QeB1NGeG 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) iQEcBAEBAgAGBQJVOrZnAAoJEC88hzaAX42idWcIAJyCWUx6htNPr3BPgyES72/B vbDLy7JJbuYXeTgDix4xu26/4viiOCA/hxk7mErnNPreG3V0+fOZCLVISLHx4Kum wF/e4iPpTrZTD9LY7vzTuP9fTDPfi4+frrM80phpCFa9PRJHmhkbJBcoN3NM3ukF LDa9vo9zJHJvt8+yYi+bb+8/z6Zr65oX3lLgssWmL7LpaP3cJkJDbl2wZE8NOkp6 BcIbFDP3b6A20XLffEbm6vyoH+8DQeZtlq3txRlrBs+bBGjn/tAdHU/pZU4wa8ZF D1vKhP2TMZpNz/mWxjfs7cp5cCDwEgBiI9lNKV/8HYN6NtApz5MMj6igb7wxVPk= =dypu -----END PGP SIGNATURE----- --ewxTdCwvsVLkIAgq5tBOfJij7QeB1NGeG-- From nobody Fri Apr 24 15:02:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F51ACE41; Fri, 24 Apr 2015 15:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T_IB7-knosd; Fri, 24 Apr 2015 15:01:59 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::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 225081ACE30; Fri, 24 Apr 2015 15:01:59 -0700 (PDT) Received: by layy10 with SMTP id y10so44683208lay.0; Fri, 24 Apr 2015 15:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YMQ+oHtsowIA6CBsqrSkaZ/KsyXfZl/v9g8i8UkTiPI=; b=zI9Qz7fTpiEaFTYew/IHaWSE1Nc/9XIRFnur/FjEcFr1YagczuZ1vRNKhehEsXJT3O 83HMtDrm+OMPs5hDDpzFe0Z6wyXpR3nDFyhStfHujwGTxE2YWkqZ5/lvoLyR41XU6+Zt +d0r09kFxqvIbMHvrD0flYB/80sAfcJBr9p52LKKRxLbu+NTNyXwEv3A8S5Hs051aRUO ynjViW5JkHkSurYfW1LgbPGq/f3OxdPU6mshul+QIOL1lAowupt/NG/yD+enbsAXLbh0 YBgQY9z6WYEcfKrAp8LCONHxLKkkchkH8HlyDIsyIMybvBJdeD3A7izB7WY7hih+dpln NTjA== MIME-Version: 1.0 X-Received: by 10.152.19.199 with SMTP id h7mr444028lae.32.1429912917711; Fri, 24 Apr 2015 15:01:57 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Fri, 24 Apr 2015 15:01:57 -0700 (PDT) In-Reply-To: <553AB662.7010303@cs.tcd.ie> References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> <553AB662.7010303@cs.tcd.ie> Date: Fri, 24 Apr 2015 18:01:57 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e014942aa85214305147f8bc9 Archived-At: Cc: draft-ietf-oauth-dyn-reg@ietf.org, The IESG , oauth-chairs@ietf.org, "" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 22:02:01 -0000 --089e014942aa85214305147f8bc9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you, both! On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell wrote: > > > On 24/04/15 22:27, Justin Richer wrote: > > Stephen, I=E2=80=99ve worked on this this afternoon and this is my prop= osed text: > > > > The response to such a > > situation is out of scope for this specification but could > include > > filing a report with the application developer or > authorization > > server provider, attempted re-registration with different > metadata > > values, or various other methods. For instance, if the server > also > > supports a registration management mechanism such as that > defined in > > , the client = or > > developer could attempt to update the registration with > different > > metadata values. This process could also be aided by a servic= e > > discovery protocol such as > which > > can list a server's capabilities, allowing a client to make a > more > > informed registration request. The use of any such management > or > > discovery system is OPTIONAL and outside the scope of this > > specification. > > > > Does this text work for you? > > It does, nicely. > > Thanks, > S. > > > > > > =E2=80=94 Justin > > > >> On Apr 24, 2015, at 8:38 AM, Stephen Farrell > wrote: > >> > >> > >> > >> On 24/04/15 13:30, Justin Richer wrote: > >>>> > >>> > >>> OK, so are you asking for something like: > >>> > >>> "If the server supports an update mechanism such as > [Dyn-Reg-Management] > >>> and a discovery mechanism such as [OIDC-Discovery], then a smart clie= nt > >>> could use these components to renegotiate undesirable metadata values= ." > >>> > >>> With both of these being informative references? I'm not opposed to i= t. > >> > >> That'd work for me, yes, thanks. > >> > >> S. > > > > --=20 Best regards, Kathleen --089e014942aa85214305147f8bc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, both!

On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 24/04/15 22:27, Justin Richer wrote:
> Stephen, I=E2=80=99ve worked on this this afternoon and this is my pro= posed text:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The response to such a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 situation is out of scope for= this specification but could include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 filing a report with the appl= ication developer or authorization
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server provider, attempted re-= registration with different metadata
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0values, or various other metho= ds. For instance, if the server also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0supports a registration manage= ment mechanism such as that defined in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<xref target=3D"OAuth.= Registration.Management"/>, the client or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0developer could attempt to upd= ate the registration with different
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0metadata values. This process = could also be aided by a service
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discovery protocol such as <= ;xref target=3D"OpenID.Discovery"/> which
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can list a server's capabi= lities, allowing a client to make a more
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0informed registration request.= The use of any such management or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discovery system is OPTIONAL a= nd outside the scope of this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specification.
>
> Does this text work for you?

It does, nicely.

Thanks,
S.


>
>=C2=A0 =E2=80=94 Justin
>
>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>>
>> On 24/04/15 13:30, Justin Richer wrote:
>>>>
>>>
>>> OK, so are you asking for something like:
>>>
>>> "If the server supports an update mechanism such as [Dyn-= Reg-Management]
>>> and a discovery mechanism such as [OIDC-Discovery], then a sma= rt client
>>> could use these components to renegotiate undesirable metadata= values."
>>>
>>> With both of these being informative references? I'm not o= pposed to it.
>>
>> That'd work for me, yes, thanks.
>>
>> S.
>




--
=

Best regards,
Kathleen
--089e014942aa85214305147f8bc9-- From nobody Fri Apr 24 15:25:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C331AD358; Fri, 24 Apr 2015 15:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zet7-NLoH6sT; Fri, 24 Apr 2015 15:25:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D2C1AD0CC; Fri, 24 Apr 2015 15:25:28 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.148.15; Fri, 24 Apr 2015 22:25:27 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0148.008; Fri, 24 Apr 2015 22:25:28 +0000 From: Mike Jones To: Kathleen Moriarty , Stephen Farrell Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) Thread-Index: AQHQfoUalSOc/4LV0kOyMMcWs5xAgZ1cEhCAgAAC7gCAAAESAIAAAdEAgAACFYCAAJQPgIAAATgAgAAISICAAAaSrw== Date: Fri, 24 Apr 2015 22:25:27 +0000 Message-ID: References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> <553AB662.7010303@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [166.171.251.144] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(51704005)(377454003)(24454002)(479174004)(2656002)(93886004)(50986999)(40100003)(19580405001)(86362001)(122556002)(230783001)(87936001)(46102003)(74316001)(106116001)(76176999)(33656002)(16236675004)(5001770100001)(77096005)(76576001)(102836002)(2950100001)(62966003)(99286002)(66066001)(86612001)(54356999)(77156002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 05568D1FF7 Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44233B10FB71EAA0DA6A620F5EC0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2015 22:25:27.8286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , The IESG , "oauth-chairs@ietf.org" , "" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 22:25:31 -0000 --_000_BY2PR03MB44233B10FB71EAA0DA6A620F5EC0BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Thanks all. Justin, please add a comma after the OpenID.Discovery reference= . ________________________________ From: Kathleen Moriarty Sent: =FD4/=FD24/=FD2015 3:02 PM To: Stephen Farrell Cc: Justin Richer; draft-ietf-oauth-dyn-reg@ietf.or= g; oauth-chairs@ietf.org; ; The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-r= eg-28: (with DISCUSS and COMMENT) Thank you, both! On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell > wrote: On 24/04/15 22:27, Justin Richer wrote: > Stephen, I=92ve worked on this this afternoon and this is my proposed tex= t: > > The response to such a > situation is out of scope for this specification but could inc= lude > filing a report with the application developer or authorizatio= n > server provider, attempted re-registration with different metad= ata > values, or various other methods. For instance, if the server a= lso > supports a registration management mechanism such as that defin= ed in > , the client or > developer could attempt to update the registration with differe= nt > metadata values. This process could also be aided by a service > discovery protocol such as = which > can list a server's capabilities, allowing a client to make a m= ore > informed registration request. The use of any such management o= r > discovery system is OPTIONAL and outside the scope of this > specification. > > Does this text work for you? It does, nicely. Thanks, S. > > =97 Justin > >> On Apr 24, 2015, at 8:38 AM, Stephen Farrell > wrote: >> >> >> >> On 24/04/15 13:30, Justin Richer wrote: >>>> >>> >>> OK, so are you asking for something like: >>> >>> "If the server supports an update mechanism such as [Dyn-Reg-Management= ] >>> and a discovery mechanism such as [OIDC-Discovery], then a smart client >>> could use these components to renegotiate undesirable metadata values." >>> >>> With both of these being informative references? I'm not opposed to it. >> >> That'd work for me, yes, thanks. >> >> S. > -- Best regards, Kathleen --_000_BY2PR03MB44233B10FB71EAA0DA6A620F5EC0BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thanks all. J= ustin, please add a comma after the OpenID.Discovery reference.
From: Kathleen Moriarty=
Sent: =FD4/= =FD24/=FD2015 3:02 PM
To: Stephen Farrell
Cc: Justin Richer; draft-ietf-oauth-dyn-r= eg@ietf.org; oauth-chairs@ietf.org; <oauth@ietf.org>; The IESG
Subject: Re: [= OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with D= ISCUSS and COMMENT)

Thank you, both!

On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell= <stephen.= farrell@cs.tcd.ie> wrote:


On 24/04/15 22:27, Justin Richer wrote:
> Stephen, I=92ve worked on this this afternoon and this is my proposed = text:
>
>           The response to such a
>            situation is out of scope for= this specification but could include
>            filing a report with the appl= ication developer or authorization
>           server provider, attempted re-= registration with different metadata
>           values, or various other metho= ds. For instance, if the server also
>           supports a registration manage= ment mechanism such as that defined in
>           <xref target=3D"OAuth.= Registration.Management"/>, the client or
>           developer could attempt to upd= ate the registration with different
>           metadata values. This process = could also be aided by a service
>           discovery protocol such as <= ;xref target=3D"OpenID.Discovery"/> which
>           can list a server's capabiliti= es, allowing a client to make a more
>           informed registration request.= The use of any such management or
>           discovery system is OPTIONAL a= nd outside the scope of this
>           specification.
>
> Does this text work for you?

It does, nicely.

Thanks,
S.


>
>  =97 Justin
>
>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>>
>> On 24/04/15 13:30, Justin Richer wrote:
>>>>
>>>
>>> OK, so are you asking for something like:
>>>
>>> "If the server supports an update mechanism such as [Dyn-= Reg-Management]
>>> and a discovery mechanism such as [OIDC-Discovery], then a sma= rt client
>>> could use these components to renegotiate undesirable metadata= values."
>>>
>>> With both of these being informative references? I'm not oppos= ed to it.
>>
>> That'd work for me, yes, thanks.
>>
>> S.
>




--

Best regards,
Kathleen
--_000_BY2PR03MB44233B10FB71EAA0DA6A620F5EC0BY2PR03MB442namprd_-- From nobody Sat Apr 25 05:13:30 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96B1A1A00; Sat, 25 Apr 2015 05:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CpnzgvfqBQx; Sat, 25 Apr 2015 05:13:26 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8591A19F6; Sat, 25 Apr 2015 05:13:26 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-7d-553b84e41d66 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 56.14.03488.4E48B355; Sat, 25 Apr 2015 08:13:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t3PCDNGE009430; Sat, 25 Apr 2015 08:13:24 -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 t3PCDJhw009410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Apr 2015 08:13:21 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_34465EDF-85B3-401E-985C-C2E0039C08E9"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: Date: Sat, 25 Apr 2015 08:13:19 -0400 Message-Id: <1472E417-E22A-4CF3-B1C2-BA5E88F0EE03@mit.edu> References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu> <553A35E4.1000904@cs.tcd.ie> <553A376A.1070806@mit.edu> <553A3929.3000002@cs.tcd.ie> <553AB662.7010303@cs.tcd.ie> <, <>> To: Mike Jones X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupik+LIzCtJLcpLzFFi42IR4hTV1n3SYh1q0HnCxmLaz9dsFjP+TGS2 aNiZb7F32icWi9tzV7JZnHz7is1i+t5r7A7sHmu7r7J57Jx1l91jyZKfTB6tO/6yB7BEcdmk pOZklqUW6dslcGXMWvSdseBCVMW27w2sDYyXfLsYOTkkBEwkNu05wA5hi0lcuLeerYuRi0NI YDGTxNEVrUwQzkZGicfXPjBCOA+ZJNa8vcsG0iIskCMxb+cxJhCbV8BAYu6pL2AdzAJTGCXO bJ/FBDFXSqLp9TFGEJtNQFVi+poWsDinQLTEvZaZzCA2C1B866RuRojmQ0wSHx/3s0JMtZJo vXAfavVaZomOvXvBukUEdCQeX/wGdAYH0AZ5iZ5N6RMYBWchOWQWskNAEswCSRJbLk+HsrUl li18zQxha0rs717OgimuIdH5bSIrhC0vsf3tHKi4pcTimTeg6m0lbvUtgJppJ/Fo2iLWBYzc qxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MYKjWZJ3B+O7g0qHGAU4GJV4eG8w WIcKsSaWFVfmHmKU5GBSEuV9Ww8U4kvKT6nMSCzOiC8qzUktPsSoArTr0YbVFxilWPLy81KV RHhfNQLV8aYkVlalFuXDlElzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4NUHJjMhwaLU 9NSKtMycEoQ0EwfnIUYJDh6g4T+aQYYXFyTmFmemQ+RPMSpKifOeAkkIgCQySvPgemFJ+BWj ONBbwrxRIFU8wAQO1/0KaDAT0OCZSy1ABpckIqSkGhjnl0XsfHtSYNGX62d3vnMwyHh5sCJJ 58eqCRs6OOZGL6rl3P+T5dfh7um39LSts90enO7I6dru9lX3imCcePovR8Ub29NLWasi6ktv eDZatBV/d0yLuW784JnjtcqJHszbzBVfT/8VUzb3xoRnBjOk7Je7lwbOu7Kw6ewuhZUHS1/9 8WYWmzVfiaU4I9FQi7moOBEA6Aelop0DAAA= Archived-At: Cc: "draft-ietf-oauth-dyn-reg@ietf.org" , "oauth-chairs@ietf.org" , The IESG , "" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 12:13:28 -0000 --Apple-Mail=_34465EDF-85B3-401E-985C-C2E0039C08E9 Content-Type: multipart/alternative; boundary="Apple-Mail=_97D3B3CC-362A-40BE-858F-AEFEDCD284AF" --Apple-Mail=_97D3B3CC-362A-40BE-858F-AEFEDCD284AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the catch. I=E2=80=99ll add that and put in a reference to = BCP100 in the next revision. =E2=80=94 Justin > On Apr 24, 2015, at 6:25 PM, Mike Jones = wrote: >=20 > Thanks all. Justin, please add a comma after the OpenID.Discovery = reference. > From: Kathleen Moriarty > Sent: =E2=80=8E4/=E2=80=8E24/=E2=80=8E2015 3:02 PM > To: Stephen Farrell > Cc: Justin Richer ; = draft-ietf-oauth-dyn-reg@ietf.org = ; oauth-chairs@ietf.org = ; = ; The IESG > Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on = draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT) >=20 > Thank you, both! >=20 > On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell = > wrote: >=20 >=20 > On 24/04/15 22:27, Justin Richer wrote: > > Stephen, I=E2=80=99ve worked on this this afternoon and this is my = proposed text: > > > > The response to such a > > situation is out of scope for this specification but = could include > > filing a report with the application developer or = authorization > > server provider, attempted re-registration with different = metadata > > values, or various other methods. For instance, if the = server also > > supports a registration management mechanism such as that = defined in > > , the = client or > > developer could attempt to update the registration with = different > > metadata values. This process could also be aided by a = service > > discovery protocol such as which > > can list a server's capabilities, allowing a client to = make a more > > informed registration request. The use of any such = management or > > discovery system is OPTIONAL and outside the scope of this > > specification. > > > > Does this text work for you? >=20 > It does, nicely. >=20 > Thanks, > S. >=20 >=20 > > > > =E2=80=94 Justin > > > >> On Apr 24, 2015, at 8:38 AM, Stephen Farrell = > wrote: > >> > >> > >> > >> On 24/04/15 13:30, Justin Richer wrote: > >>>> > >>> > >>> OK, so are you asking for something like: > >>> > >>> "If the server supports an update mechanism such as = [Dyn-Reg-Management] > >>> and a discovery mechanism such as [OIDC-Discovery], then a smart = client > >>> could use these components to renegotiate undesirable metadata = values." > >>> > >>> With both of these being informative references? I'm not opposed = to it. > >> > >> That'd work for me, yes, thanks. > >> > >> S. > > >=20 >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen --Apple-Mail=_97D3B3CC-362A-40BE-858F-AEFEDCD284AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the catch. I=E2=80=99ll add that and put in a = reference to BCP100 in the next revision.

 =E2=80=94 Justin

On Apr 24, 2015, at 6:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks all. Justin, please add a comma after the = OpenID.Discovery reference.
From: Kathleen Moriarty
Sent: =E2=80=8E4/=E2=80=8E24/=E2=80=8E2015 3:02 PM
To: Stephen= Farrell
Cc: Justin = Richer; draft-ietf-oauth-dyn-reg@ietf.org; oauth-chairs@ietf.org; <oauth@ietf.org>; The IESG
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on = draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)

Thank you, both!

On Fri, Apr 24, 2015 at 5:32 PM, Stephen = Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 24/04/15 22:27, Justin Richer wrote:
> Stephen, I=E2=80=99ve worked on this this afternoon and this is my = proposed text:
>
>           The response to such a
>            situation is out of scope = for this specification but could include
>            filing a report with the = application developer or authorization
>           server provider, attempted = re-registration with different metadata
>           values, or various other = methods. For instance, if the server also
>           supports a registration = management mechanism such as that defined in
>           <xref = target=3D"OAuth.Registration.Management"/>, the client or
>           developer could attempt to = update the registration with different
>           metadata values. This = process could also be aided by a service
>           discovery protocol such as = <xref target=3D"OpenID.Discovery"/> which
>           can list a server's = capabilities, allowing a client to make a more
>           informed registration = request. The use of any such management or
>           discovery system is = OPTIONAL and outside the scope of this
>           specification.
= >
> Does this text work for you?

It does, nicely.

Thanks,
S.


>
>  =E2=80=94 Justin
>
>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>>
>> On 24/04/15 13:30, Justin Richer wrote:
>>>>
>>>
>>> OK, so are you asking for something like:
>>>
>>> "If the server supports an update mechanism such as = [Dyn-Reg-Management]
>>> and a discovery mechanism such as [OIDC-Discovery], then a = smart client
>>> could use these components to renegotiate undesirable = metadata values."
>>>
>>> With both of these being informative references? I'm not = opposed to it.
>>
>> That'd work for me, yes, thanks.
>>
>> S.
>




--

Best regards,
Kathleen

= --Apple-Mail=_97D3B3CC-362A-40BE-858F-AEFEDCD284AF-- --Apple-Mail=_34465EDF-85B3-401E-985C-C2E0039C08E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVO4TfAAoJEDPAngkbd+w93awIAJeGMJIOkFHcuC3Lc50619yd hrmQ7IutPNoukUp9MEylphQKCae+WNhMqeQh7kfOz07lT0foICXYb5MiBFMKGjsR kwGD4p8T/oGvvYhi9ipAYYjzjEbskvsuArnsxyP1xcsO4IwPsshhCMNW9hMN8DgD TMB47dP8loYiJLVf9d2tKkyF15nAaERjJIzFjSF74Prp13NYIkHwFmUYpNusiCyF /6e3PH1ubm49fkyrkzbz3i2ZRLr/s4A96AFx9kvSc4DVfjBtdPf0UqrOeD42j15d 2G1HaWnaLktHwoZFn/9v4fnPltKzEIKeFHovXjzWvPdpsoRPmzaCY5sxs/Scw8k= =GvrP -----END PGP SIGNATURE----- --Apple-Mail=_34465EDF-85B3-401E-985C-C2E0039C08E9-- From nobody Thu Apr 30 11:37:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A621ACDE0 for ; Thu, 30 Apr 2015 11:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7puA7uS0aqH5 for ; Thu, 30 Apr 2015 11:37:41 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6471ACDCC for ; Thu, 30 Apr 2015 11:37:40 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-8e-5542767383fc Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 68.A8.03389.37672455; Thu, 30 Apr 2015 14:37:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t3UIbcmG028165 for ; Thu, 30 Apr 2015 14:37:39 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3UIbafw010272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Apr 2015 14:37:38 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3UIbZKw027665; Thu, 30 Apr 2015 14:37:35 -0400 (EDT) Date: Thu, 30 Apr 2015 14:37:35 -0400 (EDT) From: Benjamin Kaduk To: oauth@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixG6nrltc5hRq8GyzlsXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMe9YRsEs0YptS2ewNzAuF+xi5OSQEDCRmLR9LiOELSZx4d56 ti5GLg4hgcVMEmu3zGaGcI4xSmxYfw7Kuc4k8WjqURYIp4FRYsukRhaQfhYBbYkpX18xg9hs AioSM99sZAOxRQSEJJ7v7GMCsYUFqiT+z57KCmLzCjhKXNv8BWy3qICOxOr9U1gg4oISJ2c+ AbOZBbQklk/fxjKBkW8WktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJT SjcxgsKJU5J/B+O3g0qHGAU4GJV4eD+0O4YKsSaWFVfmHmKU5GBSEuVtynUKFeJLyk+pzEgs zogvKs1JLT7EKMHBrCTCq5YJlONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV 4eBQkuB9VQLUKFiUmp5akZaZU4KQZuLgBBnOAzRctxRkeHFBYm5xZjpE/hSjopQ4bxBIQgAk kVGaB9cLi/dXjOJArwjzTgWp4gGmCrjuV0CDmYAGn7/lADK4JBEhJdXAmJNhcGnN/Qldy/Zc 79dpTD7hpf30otRFNcUXbcqc4qr2L3N8fDf2b2Db+LffPfWmk870+59aSzkfZKzdsPlxcfFV 55cvtlvFSXN28VsZHDysMqVE623CmoykVf5tTlESy08JTnP48EvrvSGj/URBzwWFRXxbtYwm zJ34au4qtidNaukGr3auUWIpzkg01GIuKk4EADIZvzTSAgAA Archived-At: Subject: [OAUTH-WG] Fwd: Last Call: (A set of SASL Mechanisms for OAuth) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 18:37:42 -0000 Hi all, I just wanted to call attention to this IETF Last Call; there were some changes since the -18 which is the last one that we sent to this list. -Ben ---------- Forwarded message ---------- Date: Thu, 30 Apr 2015 14:31:47 -0400 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce Cc: kitten@ietf.org Subject: [kitten] Last Call: (A set of SASL Mechanisms for OAuth) to Proposed Standard The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'A set of SASL Mechanisms for OAuth' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ballot/ No IPR declarations have been submitted directly on this I-D. This defines a way to use the obsolete OAUTH1.0a mechanism as well an OAUTH2 mechanism. That is deliberate and reasonable. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten